Philipp A Hartmann

Quoting my earlier reply (emphasis added): "Otherwise, you can create a wrapper (or a derived class), with no own sc_object/sc_module members and construct the real SystemC module from within C++." The module/object hierarchy creation is closely related to the sc_module_name stack. Once the sc_module_name instance is destroyed (after the completion of your ExampleModule (base class) constructor), the "current module" is removed from this stack. Therefore, the ports you create afterwards can not be assigned to the correct module. Again, a workaround may be to create the ports via Python from within before_end_of_elaboration callback, where the module hierarchy is correctly restored without having a proper sc_module_name stack. The deprecated constructor comes from very old versions of SystemC (before the introduction of sc_module_name) and requires you to manually call the (similarly non-standard) function end_module after the creation of all sc_object members at the end of the constructor. Otherwise, your hierarchy will be messed up in case of multiple (nested) modules. I would not recommend this approach. Greetings from Oldenburg, Philipp

As said before, you have to have an sc_module_name parameter in the (leaf) constructor of your module class hierarchy. Using the deprecated constructor will likely mess up your object hierarchy during elaboration. You can directly call such a constructor with a const char* argument, as you can implicitly construct an sc_module_name from a const char*. Maybe this is all you need. Otherwise, you can create a wrapper (or a derived class), with no own sc_object/sc_module members and construct the real SystemC module from within C++. hth, Philipp

In your case, the Timer module (or a dedicated interrupt controller, wherever your "interrupt clear register" is located) would be responsible for actually writing to the interrupt signal. This can then be locally resolved to a single control process within the module. However, especially for interrupt signals, SC_MANY_WRITERS is a common use model. Note that SC_MANY_WRITERS is perfectly safe to use, because you are still not allowed to write to a signal from multiple processes in the same delta cycle (as that could lead to non-deterministic behaviour). /Philipp

You can't let the second process write to the same signal (deassert) without using SC_MANY_WRITERS. (This wouldn't make much sense in real HW without additional logic either.) Solution: Restructure your design to have a single writer to each signal instead. Hard to be more specific with the available details. hth, Philipp

Short answer: You can't. /Philipp

Yes, the segmentation fault is caused by trying to access the terminated process instance (to format the error message), which has been deleted already. This problem will be fixed in the next public release of the Accellera proof-of-concept implementation. Thanks for your report, Philipp

Why can't you just use a tlm_fifo instead, which already provides peek/poke? /Philipp

Strictly speaking, it is your fault. Quoting 1666-2011, section 5.2.3 (sc_module, constraints on usage), emphasis mine: So the last variant posted by Ralph is the correct definition. /Philipp

The events of an sc_signal are triggered during the update phase of the simulation. Therefore, you can't cancel the event from a SystemC process. What are you trying to achieve? Why are you sensitive to an sc_signal event, if you don't want to be triggered?

You try to create a primitive channel (sc_signal, sc_fifo, ...) during the simulation. This is not allowed in SystemC. You have to create all of these channels during elaboration (i.e. before the simulation is started). hth, Philipp

In SystemC, you can't partially change the (new) value of a signal. Instead, you can simply use a local temporary variable: sc_signal<des_struct> xyz,abc; des_struct tmp = xyz.read(); tmp.attrib = 4; abc.write(tmp); If you want to keep things in a single line, add a setter with a "fluent API" (i.e. returning the object itself) to the des_struct: class des_struct { public: // ... des_struct& set_attrib(uint16_t a) { attrib = a; return *this; } }; // allows: abc.write( des_struct(xyz.read()).set_attrib(4) ); hth, Philipp

In general, it's perfectly fine to use sc_signal with a custom data type, provided that you have a properly defined comparison operator (and an sc_trace overload). In your case, I think your comparison operator is broken: In the code above, you update "end" with a != expression. This seems to be strange. Shouldn't this be ==? hth, Philipp

It's documented in the IEEE Std. 1666-2011, downloadable at no cost at http://standards.ieee.org/getieee/1666/download/1666-2011.pdf (including SystemC and TLM-2.0). Greetings from Oldenburg, Philipp

The templated SystemC datatypes all build upon a "dynamic bitwidth" implementation (e.g. sc_uint_base) that has its bitwidth set upon construction. The templates themselves only provide constructors (initializing the length of the base class), assignment operators, and related functions. It would of course be possible to add a static member to the sc_(big)(u)int templates to provide direct access to the template argument: template< int W > class sc_int : public sc_int_base { static const int static_length = W; // or some other name // ... }; For these classes, an external helper can be defined easily as well: template< typename T > struct number_traits; // undefined by default // specialization for SystemC integer datatypes template< int W > struct number_traits< sc_dt::sc_int<W> > { static const int length = W; }; // same for sc_uint, sc_bigint, ... But for true generic programming, the concatenation and range classes would require additional meta programming to make this fully usable. Secondly, as the base classes should provide access to the length() of the instances as well, this function would require to be declared virtual (as the base classes are non-templated). This would increase the size (and eventually the runtime cost) again. That said, if you're interested in bit true datatypes implemented with fully deduced widths etc., you might want to use the Mentor/Calypto "Algorithmic C datatypes", see http://calypto.com/en/products/catapult/overview/. Greetings from Oldenburg, Philipp

Of course you can use members of your class without inheriting from their type. Otherwise, C++ would be an even stranger language than it is already, wouldnt it? Assuming that you do more than just forwarding the dut_input to the sc_output (by calling the write function) in your implementation, yes this can be seen as the right way. Indirectly, yes. You can bind the dut_input either to a port or to another export. As your class claimed to be "both", the compiler can't tell which bind function to call. /Philipp

Why does your "eq_wrapper_top" inherit from an interface and a port? Maybe, you probably just want to drop the tlm_analysis_port<eq_transaction> base class. Or why do you need it? hth, Philipp

Looking at the output of your 2.3.1 build, something is seriously wrong here: vahdaneh@vahdaneh-SVT14126CXS:~/Desktop/systemc-2.3.1/objdir$ make /bin/bash: -c: line 0: syntax error near unexpected token `do' /bin/bash: -c: line 0: `fail= failcom='exit 1'; forf in x $MAKEEFLAGS; do case f in *=* -- [!kk]*);; *k*) failcomm='fail=yes';; esac; don;\ o_seenn=no; taget=`eccho aall-recursive | sed s/- recursive/; list='docs src examples''; for subdir in $$llist; do echo "aking $$target in $subdir"; f test "$subddir" = "."; then \ dot_seen=yes; local_tagett="$targett-am"; else \ loccal_targget="$target"; i; (CDPAATH=${ZSSH_VERSIO+}:" && cd $suubdir && make $local_target) ||eval $faillcom ' make: *** [all-recursive] Error 1 There are a many (randomly) duplicated characters in the command, and sometimes letters are missing. It seems that your configure call failed to generate working Makefiles. This is quite strange, and I have not seen this effect before. Maybe it is indeed related to broken line endings. /Philipp

Oh, and I should have said: Please use "make V=1" and post the full command, make is failing to run.

No, unfortunately, there is no API to determine which events have fired and triggered the execution of a given process. You need to add additional information to your system, e.g. by storing the value of sc_delta_count for each event notification and check its value in the triggered process (which is how the event() method of sc_signal works internally). Immediate notifications are even more difficult to track reliably. Yes, the method would be evaluated once, even if multiple events from the sensitivity list fired in the same update phase (notify(SC_ZERO_TIME);). So this could be an appropriate modeling style. Again, immediate notifications are more difficult to handle reliably: Here, the method may be triggered twice in the same evaluation phase, depending on the (implementation-defined) order of evaluation of runnable processes. hth, Philipp

First of all, you should use SystemC 2.3.1, released a couple of months ago. Secondly, according to the information you provide, your setup should work right out of the box. Can you post the full output of your configure and make calls? Additionally, please post the output of your environment variables, e.g. from the command env. From the error message, it seems you may be having a stray semicolon in e.g. your CXXFLAGS variable, leading to the breakage of the compiler call (then suddenly beginning with "-c"). But it's hard to tell without more information… hth, Philipp

Yes, running multiple evaluation phases (sequentially and/or concurrently/interleaved) is not mandated by the standard, see e.g. 4.3.2: If you have separated the use of the different simcontexts properly, this may work with the current proof-of-concept implementation. If you intend to run these simulations concurrently, it will most probably fail due to the current non-reentrancy of some parts of the kernel (and the datatypes). In case you need communication between the models, it will be even more complicated. Still, there are other parts of the simulator state, which are currently not fully encapsulated by the/an explicit simcontext. You may see strange artefacts and interferences between the simulations, especially in some corner cases. Also the reporting mechanism is not routed through the simcontext. There is work ongoing in the LWG to address that topic, although I can't promise any timeline or "standardized API" around this feature request. It will probably stay implementation-defined in IEEE 1666. As said above, the non-standard function name is likely the least of your problems. ;-) I agree that there are several use cases for that and it has been discussed in the past multiple times. I don't see a way to reduce the "risk of not being compatible with upcoming versions of SystemC" from the user perspective. You are of course welcome to join the Accellera Systems Initiative and actively contribute towards a solution for this in the LWG. Greetings from Oldenburg, Philipp

This is not true. The OS scheduler has nothing to do with the SystemC process scheduler, see my recent answer here. /Philipp

The OS scheduler has nothing to do with the SystemC process scheduler. SystemC uses a custom, cooperative scheduler following the simulation semantics as defined in IEEE 1666-2011: Only one SystemC process is guaranteed to run at all times. Even if SystemC processes might be implemented as OS threads, their scheduling is enforced to follow the SystemC rules. You can't tell. All of them are "equal". Whether or not this is sufficient for the original poster's use case depends on his/her requirements. /Philipp

The same would be the case for a plain C assert: #include <cassert> #define NDEBUG int main() { assert( false ); } I'll leave the solution as an exercise for the reader. ;-) (Hint: look for the word "before" in the link above.) /Philipp

Yes, defining NDEBUG also disables the sc_assert statements in the SystemC proof-of-concept implementation. Having said that, I don't think it is a good idea to do so globally. You usually want your simulation to reliably abort in case of an error/bug, instead of running into arbitrary undefined behaviour. I would recommend to leave assertions active by default until profiling proves that (specific) assertions have a significant performance impact. In such cases, selectively disable only these assertions in optimized configurations. /Philipp