Jump to content

Philipp A Hartmann

  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Philipp A Hartmann

  1. Admittedly, using Valgrind with SystemC has become more involved with 2.3. There are several reasons for this, some of them are new, some apply to SystemC 2.2 already. Let's have a look at your output: In order to reliably use SystemC with Valgrind, you should switch to the pthreads-based process implementation. Otherwise, you'll see many false positives when looking at "real" models. To enable this in 2.3, add "--enable-pthreads" to the configure options and recompile the library: cd objdir ../configure --enable-pthreads (...) make clean && make && make install These are false positives due to the internal name handling of SystemC. There are several global objects which are deliberately not freed. The unique name counters of the top-level objects are among them. Ignore those. (In principle, these have been present in 2.2 already. There were less instances, since events had no name.) All of these false positives are a result from using the shared library, instead of linking statically against SystemC. The global objects (and the memory allocated by them) can not be tracked down by Valgrind in this case. Moreover, there are still object instances from the shared library present in the running program and the dynamic library will not be unloaded. To link statically against the (pthreads-enabled) SystemC library in your environment, add -pthread to your compiler flags and use -Wl,-Bstatic -lsystemc -Wl,-Bdynamic -pthread for the SystemC library linker flags. The most important result here is that no definite or indirect losses are reported. These are the real leaks. Some of reported "possible losses" can further be suppressed by exporting the following environment variable: export SYSTEMC_MEMPOOL_DONT_USE=1 # (or setenv, in case of csh-compatible shells) Greetings from Oldenburg, Philipp
  2. (Rather wild guess based on the output:) At 3ns, you start the simulation via sc_start() (with no parameters), although there is no pending activity in your system (no processes need to be run, no events unprocessed, …). Therefore, the simulation returns immediately, without any changes and the simulation time stays the same. The following trace warning is probably a follow-up problem caused by the testbench code. You can avoid such empty calls, by checking for pending activity first: if( sc_pending_activity() ) sc_start(); Alternatively, you can run the simulation with an explicit time step, which at least moves the simulation time (depending on the sc_starvation_policy). /Philipp
  3. For the port widths based on integer generics, you should use the -createtemplate option of scgenmod.
  4. 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
  5. 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
  6. 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
  7. 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.
  8. Yes, this is correct and usually the right thing to do.
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. What about something like this: sc_time delay = (x+1) * sc_time(50,SC_NS) * (val_2 - val_1); Greetings from Oldenburg, Philipp
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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
  • Create New...