Philipp A Hartmann

There is information about the connectivity in the above snippet. You just need to store the relation between the ports you find (optr) and the connected channels (optr->get_interface()) in an appropriate data structure that fits your requirements. HTH and Greetings from Oldenburg, Philipp

The "right set of flags" obviously include (explicitly or implicitly) "-Wundef -Werror". From the C(++) preprocessor standard point of view, it is not a bug. All undefined symbols are supposed to be interpreted as 0: Side note: When using strict GCC compiler flags in your models (which is a very good idea!), you might want to include third-party libraries like SystemC as "system headers" to avoid such problems coming from external sources: $(CXX) $(CXXFLAGS) -isystem $(SYSTEMC_HOME)/include ... It is probably still a good idea to explicitly check for __SUNPRO_CC in sc_interface.h first. Thanks for reporting. Greetings from Oldenburg, Philipp

Raul, ok, I can confirm your problem and this is a bug in the ASI proof-of-concept implementation. Thanks for reporting it, I'll forward it to the LWG to get it fixed in the next release. As a workaround, you can work around the issue by using sc_time and SC_SEC as time unit: // traceFile->set_time_unit(10, SC_US); traceFile->set_time_unit(sc_time(10, SC_US).to_seconds(), SC_SEC); Greetings from Oldenburg, Philipp

I'd say, this depends on the X, you're supplying to the set_time_unit call. It is currently not enforced that this X needs to be a power of 10, according to 8.1.2 in the 1666-2011 standard. Can you post a minimal example demonstrating the problem? Opening a trace file, adding a single variable/signal, calling sc_start() and closing the file again should be enough. /Philipp

You need to disable the problematc redefinition of 'for' in src/sysc/kernel/sc_cmnhdr.h, which used to work around a bug in an ancient version of MSVC. See attached patch. Greetings from Oldenburg, Philipp 0001-Check-for-MSVC-version-in-for-scope-bug-hack.patch.txt

As I said in my previous post, nested classes are usually not a very good design pattern. Your example of the arbiter class is not very convincing either, as you may want to reuse (or replace) this arbiter as well. For a "real" use case of nested classes, you inherently need a very strong coupling between the outer and the inner class. Most likely, the inner class won't (or shouldn't) be used outside the implementation of the outer class. But this can of course include the above-mentioned SystemC-specific inheritance relationships as well. From the frontend/parsing point-of-view, you probably want to support such cases. If you want to (fully) parse the TLM-2.0 convenience sockets, you'll encounter an example of such a use-case. I'm not aware of SystemC-specific coding guidelines that talk about nested classes explicitly. From the (C++) language point-of-view, it's just another scoped identifier. Still, many widely adopted C++ coding guidelines discourage the use of nested classes. Greetings from Oldenburg, Philipp

I'm not convinced, that SystemC is the language of choice for gate-level models. It's hard to tell what went wrong in your model without seeing the code (especially the process declarations and definitions) of the NANDs and their composition. Two short recommendations: Instead of printing out values, you should consider to trace the signals to a proper trace file. You may need to prevent the "forbidden" state in your flip-flop by adding "dont_initialize();" to some of your processes. /Philipp

As in all C++ code, nested classes should be the exception, not the rule. I recommend the discussion given in the Google C++ Style Guide. My short SystemC-specific answer: In SystemC models, nested classes should not be defined. In SystemC methodology libraries (e.g. TLM-2.0, or your own support libraries), there are rare, but valid use cases for nested classes. Before discussing some of these exceptions, why do you want to use nested classes in the first place? /Philipp

As explained in detail in my previous answer, the output you see is as expected. All of these reports (which are no errors in a strict sense) can be seen as false positives. The additional "possible loss" reported (the one with pthread_create in the call tree) is related to the stack allocation of your process. /Philipp

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

(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

For the port widths based on integer generics, you should use the -createtemplate option of scgenmod.

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

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

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

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.

Yes, this is correct and usually the right thing to do.

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

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

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

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

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

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

What about something like this: sc_time delay = (x+1) * sc_time(50,SC_NS) * (val_2 - val_1); Greetings from Oldenburg, Philipp

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