Jump to content

Philipp A Hartmann

Members
  • Content Count

    533
  • Joined

  • Last visited

  • Days Won

    129

Everything posted by Philipp A Hartmann

  1. For the port widths based on integer generics, you should use the -createtemplate option of scgenmod.
  2. Yes, this is possible in a standardized way since IEEE 1666-2005, via the hierarchy traversal functions, since all of these objects are elements of the SystemC object hierarchy. See "Here's Exactly What You Can Do with the SystemC 2005 Standard" from John Aynsley (Doulos) in the section "The object in question" for some examples. Greetings from Oldenburg, Philipp
  3. 1. Change the signal to an sc_buffer (triggers an event upon every write): sc_buffer<bool> sig; 2. Add an event to the controller, wait for it in controller thread, notify it from increase method sc_event sensor_ev; // ... void Controller::controller() { while(true) { while(value == 0) // wait(); //this could/should wait for an event trigger fired by increase() instead. wait( sensor_ev ); if(value > 0) { value = 0; wait(20, SC_SEC); } Some_Other_Stuff(); } } void Controller::increase(){ //if(sensor == 1) { ++value; sensor_ev.notify( SC_ZERO_TIME ); // } } Something like this? It's not clear, if the actual "value" is important. If it is not, you can only use the event for internal synchronisation. Greetings from Oldenburg, Philipp
  4. Yes, it has. See http://lmgtfy.com/?q...version to COFF http://stackoverflow...le-invalid-or-c http://social.msdn.m...16-2bfc039faa80 Greetings from Oldenburg, Philipp
  5. Problems in the C++ standard library usually indicate a problem in your environment configuration. Make sure that the compiler options (inclusing #defines) used within your SystemC project match the ones used during the compilation of the SystemC library itself.
  6. Yes, this is correct and usually the right thing to do.
  7. It's quite hard to tell the actual cause of the crash from your description and from the stacktrace alone. I assume a memory corruption in your part of the code. Do you store references or iterators to elements in the deque? Those can be invalidated by operations on the container. Are you sure, the object has not been destroyed? Dangling references can be quite hard to track down. Do you have a custom copy-constructor, assignment operator, or destructor in your class? Then you probably need all three of them (rule of three), to make it work correctly. You should try to strip down your problem to a minimal, self-contained test case. Take your custom class and write a separate function trying to reproduce the problem. If this does not help, try to check the differences. Of course, you can post this example here to ask for feedback. Greetings from Oldenburg, Philipp
  8. Assuming you're using plain signal ports, you can use the event member function to check, whether a specific port has been triggered in the current delta cycle: sc_vector< sc_in< int> > in_vec; // ... SC_METHOD(proc); for( unsigned i= 0; i<in_vec.size(); ++i ) sensitive << in_vec[i]; // ... void proc() { for( unsigned i= 0; i<in_vec.size(); ++i ) if( in_vec[i]->event() ) std::cout << "in_vec[" << i << "] triggered." << std::endl; } Greetings from Oldenburg, Philipp
  9. You need to instantiate the sub-module as a member in the parent module. Modules are just regular C++ classes, same rules apply. SC_MODULE(module1) { SC_CTOR(module1) : mod0( "mod0" ) // initialise member in constructor { // ... } private: // sub-module member declaration module0 mod0; }; Greetings from Oldenburg, Philipp
  10. First of all, you should refer to the standardized API in the IEEE Std. 1666-2011, instead of looking at the source code of the proof-of-concept implementation. This way you make sure that your solution works in other standards-compliant implementations as well. I assume there are specific reasons, why you can't use a proper sc_port (e.g. sc_fifo_in/out), connected to the particular sc_fifo instance of interest? Looping through the design hierarchy to manipulate the model structure is a rather special case in SystemC. No. As you have seen in your tests, the add_static function is private and non-standard. It is an implementation artefact. Instead, you should spawn a process, which is then sensitive to the events. Processes are the natural way to specify event-triggered functionality in SystemC. If you need to keep a handle to an event, you can use a C++ reference (or pointer), instead of creating a new event instance. Events have "identity" and can not be copied or assigned. This is the case for many structural elements in SystemC. sc_event const & ev_ref = sc_fifo_obj->data_written_event(); In the easiest case, you can just create a plain SC_METHOD process, being sensitive to your event. Of course, this requires to wrap the "callback" in a module instance. To make sure your FIFO has been created already, you should create this process in the end_of_elaboration callback of the module: SC_MODULE( fifo_callback_handler ) { // ... void callback_process(); void end_of_elaboration() { // ... find fifo object SC_METHOD(callback_process); sensitive << sc_fifo_obj->data_written_event(); dont_initialize(); // do not run at start of simulation } }; You can also use dynamic processes (sc_spawn, sc_bind) to create processes dynamically during the simulation. See 1666-2011, Section 5.5. Greetings from Oldenburg, Philipp
  11. In order to help other users with similar questions in the future, please keep the original question/contents of the discussion, instead of deleting them add your solution as a reply to your own question, if you have been able to resolve the problem on your own Thanks & Greetings from Oldenburg, Philipp
  12. Side note: Can you try to keep your reply outside of the "[ quote ]" blocks? Otherwise, it's hard to parse what's new and what's quoted. It is as accurate as you can be in SystemC. As David said in his reply, the SystemC time is represented as a 64-bit value itself. You can adjust the resolution (as a power of 10) with the function call (before using sc_time for the first time!): sc_set_time_resolution( 10, SC_NS ); to increase the maximum simulation time (but lose local precision). In case of very big differences, I would suggest to generate a warning and ignore the notification. It is unlikely, that you need/want both very high time resolution (below a single clock cycle) and very long simulated time periods (several years). Greetings from Oldenburg, Philipp
  13. What about something like this: sc_time delay = (x+1) * sc_time(50,SC_NS) * (val_2 - val_1); Greetings from Oldenburg, Philipp
  14. Have a look at the (brief) introductions to TLM-2.0, given by John Aynsley at Youtube: [media=] For a more detailed coverage of TLM-2.0, you can watch more videos on the Accellera website, e.g. TLM-2.0 in Action The OSCI TLM-2.0 Standard and Synthesis Subset Greetings from Oldenburg, Philipp
  15. Do you see a comppiler error, or is the file physically missing on your system? The official release of the Accellera SystemC PoC simulator contains this file. Make sure you have correctly unpacked the archive. $ md5sum systemc-2.3.0.tgz c26b9116f29f1384e21ab8abdb2dd70f systemc-2.3.0.tgz Secondly, you need to add the top-level include directory (<install-directory>/include) to your compiler's include path during compilation, but this is needed for SystemC itself already. Greetings from Oldenburg, Philipp
  16. I would say, an "image" is already "binary" in most cases. For the other cases, you may find the following documentation very useful: How to Ask Questions the Smart Way Greetings from Oldenburg, Philipp
  17. First note: You should not run your simulations as the root user. If you want to link statically against SystemC (libsystemc.a), you need to add "-pthread" to your compiler and linker flags (on Linux). This dependency is caused by the "async_request_update" feature in SystemC 2.3.0. Alternatively, you can add "--disable-async-updates" to your SystemC configure options, if you don't need this functionality. Greetings from Oldenburg, Philipp
  18. There is no way to model an asynchronous reset with a thread process in SystemC 2.2. If you need to stick with the old version, I'm afraid you need to use method processes instead. Greetings from Oldenburg, Philipp
  19. How do you see, whether a value has a decimal or hexadecimal representation? Most probably, it is stored in some form of binary in the memory. ;-) But you can directly assign both hex literals (C++ feature) and hex strings (SystemC datatypes feature) to sc_uint variables: #include <systemc.h> int sc_main(int,char*[]) { sc_uint<32> pippo; // ... pippo = 0x2A; // assign from hex literal pippo = "0x0A2"; // assign from hex string std::cout << pippo // decimal value by default << "=" << pippo.to_string(SC_HEX) // SystemC hex representation << " (0x" << std::hex << pippo <<")" // C++ hex representation (with manual '0x' prefix) << std::endl; return 0; } Gotcha: In SystemC, hex strings are signed literals by default. When dealing with unsigned variables (sc_uint, et.al), you should make sure that the hex string contains a leading 0 to avoid unexpected sign extension, when converting from the hex string. Greetings from Oldenburg, Philipp
  20. Hmm, how would the grammar of "just a SystemC/TLM program" be simpler than parsing plain C++? I'd say that if you indeed would want to define a specific grammar for SystemC/TLM programs, this would be way more complex instead. IMHO, any (decent) SystemC/TLM language frontend needs to contain (or be based on) a plain C++ frontend. For detailed references to existing projects, you should check the references in the survey paper I mentioned. Greetings from Oldenburg, Philipp
  21. Ok, I think you have messed up the file permissions in your "objdir" directory by calling "configure" through sudo. (Why?!) You should start afresh by removing the "objdir" directory first, or try the following from within a "new" build directory. Call "configure" without the "CPPFLAGS=-fpermissive" (Where did you get that from anyway?), and compile as regular user. Afterwards you can install via sudo: ../configure --prefix=/usr/local/systemc-2.3 make sudo make install Greetings from Oldenburg, Philipp
  22. In general, a failing libtool indicates a local problem with your environment. Please check for free space, directory permission, etc. You use a filesystem with sipport for symbolic links, right? (i.e. not NTFS, FAT32)? Do you try to cross-compile? That said, can you please post the output of the call (incl. the parameters given to) the 'configure' script? You somehow added -fpermissive to the compiler flags, which is a bad, if not very bad idea. /Philipp
  23. Make sure you have the RTTI-information enabled in your VC++ project and that the /vmg switch is added to your compiler settings. See INSTALL file in the SystemC package: http://msdn.microsof...y/we6hfdy0.aspx http://msdn.microsof...y/yad46a6z.aspx Greetings from Oldenburg, Philipp
  24. SystemC(/TLM) is not a first-class language on its own. Instead, it is a C++ class library. Therefore, you can find the language definition in the C++ standard itself, see http://isocpp.org/std/the-standard). That said, you should probably not try to write a C++ parser from scratch. Instead, you may want to look at existing (open-source) parsers, like Clang/LLVM or GCC. There are several projects working on reconstructing the SystemC elements from a C++/SystemC model (SystemC frontends). There has been an overview paper at FDL'2010 about this (Maguet et.al, A Theoretical and Experimental Review of SystemC Front-ends"). Greetings from Oldenburg, Philipp
×
×
  • Create New...