Philipp A Hartmann

Hi Jens, There is none. According to the 1666-2011 standard (5.2.3), every module (at least in the most derived class) requires an sc_module_name parameter: As you have correctly described, the building of the hierarchy fails when creating the sc_module_name object inside the initialisation list. This is one of the reasons, the above restriction exists. I won't comment on the strong coupling you introduced between your XML-based "configuration/setup" mechanism and the model(s) itself. If you want to keep that scheme, you can introduce a static create function and make the constructor protected. Something like: static my_module* // or something like std::unique_ptr<my_module> create( pugi::xml_node node ) { return new my_module( node, node->attribute("name").value() ); } protected: ///Constructor my_module ( pugi::xml_node *node ///< xml node pointer , sc_core::sc_module_name ///< name (no need to give a parameter name) ) : // sc_module() <- explicit call not needed ... { ... } Hope that helps, Philipp

It's hard to say anything about this except for: Check your compiler/toolchain setup, the library directories and the build settings in general.

It seems as if the problem is with your "64-bit application", not with the SystemC library itself. The message says, the module were of type 'x64', while your current target is 'x86'. Please ckeck. Also note that SystemC on 64-bit Windows is not really tested. You should see an awful lot of compiler warnings and most of them are not known to be ignorable. /Philipp

There is no sleep in SystemC. If you refer to POSIX sleep, /* #include <unistd.h> */ unsigned int sleep(unsigned int seconds); then no, it is not the same thing. wait( sc_time ) refers to the simulation time, while sleep refers to the host's system time./Philipp

See sections 10.1 Introduction to TLM-2.0 – Background 17.1.1 TLM-1 Message passing interface and analysis ports – Put, get, peek, and transport interfaces – Description of the IEEE 1666-2011 SystemC Standard. Greetings from Oldenburg, Philipp

Your solution is correct. That's why my example said "untested". Sorry. /Philipp

I'm afraid there is no builtin way to do this. You can't just trace the value returned from ch_a_fix.to_double() as this is returned as a temporary double (and you can only trace persistent objects). You may need to use a helper process doing the translation. Something like (untested): double ch_a_fix_tr; void update_ch_a_fix() { ch_a_fix_tr = ch_a_fix.to_double(); } // in constructor ... SC_METHOD(update_ch_a_fix); sensitive << ch_a_fix; and then trace ch_a_fix_tr instead.Of course, you can wrap all of this in a helper class and implement your own sc_trace_fixed_as_double function based on it. hth, Philipp

Amit, both cases are valid simulation runs, as the internal scheduling (i.e. the order, in which processes are evaluated) is implementation-defined. You need to ensure within your models, that there is no (implicit) dependency on any particluar ordering of processes within a single evaluation phase. Otherwise, you may see unexpected behaviour due to things like the event cancellation example, you quoted from the standard. Greetings from Oldenburg, Philipp

There has been a discussion on tracing all signals (and ports) in a design in this forum before, see http://forums.accellera.org/topic/138-why-sc-object-menber-function-trace-deprecated/ Short answer: sc_object::trace is not part of the IEEE 1666 SystemC standard and won't work the way you expect. Secondly, sc_simcontext is also not part of the standard. You should not use it within your designs. To traverse the SystemC object hierarchy, use the sc_get_top_level_objects() and [sc_object::get_child_objects()[/i] functions. An example can be found in the thread linked above. Greetings from Oldenburg, Philipp

As a general remark: You should push your HLS vendor to bundle SystemC 2.3.0 with their next release. It should be no problem, since there are very few changes that affect synthesisable code (or rather the synthesis of the models) in the first place. Secondly, there are some nice features for synthesis as well, like async_reset_signal_is (or even sc_vector, but this may be more difficult to support). Why bother? As I said in my previous post(s), you can silence the warnings originating from SystemC by using the -isystem switch:$ g++ -Wall -isystem ${SYSTEMC_HOME}/include ...If you insist to change the SystemC 2.2.0 implementation in that area, you can compare the differences in the sysc/datatypes directory between 2.2.0 and 2.3.0. This will show (in addition to quite some "real" bugfixes) the required changes to silence the operator precedence warnings. hth, Philipp

I didn't try this very recently, but you can download the AC datatypes separately. I don't expect any particular problems to use them with SystemC 2.3. If there should be any issues, they should be easily fixable. If you already have company-wide installs, maintained by other people than yourself, why can't you just use the -isystem option in your compiler flags and be done with it? Accellera did the "right thing" and fixed the distribution. The version including the fixes is called 2.3.0. I fail to see how a version 2.2.1 would solve any of your problems. This version would not be "bundled" with the AC datatypes, you would need to convince your company to install it, you'd still have your "simulation / synthesis" mismatches (whatever your concern is, in that regard). Greetings from Oldenburg, Philipp

When using a specific tool, you should stick with their SystemC version (and compiler) anyhow. If you want to do a separate simulation with a new compiler, why can't you use SystemC 2.3 for this? (Esp. synthesizable) SystemC models compatible with 2.2.0 should work fine with SystemC 2.3. You can add the SystemC headers via -isystem, instead of a plain -I to your compiler's include path. This way, warnings from these headers won't clutter the warnings originating from your model. I don't think that there will be a 2.2.1 version of the proof-of-concept library released by Accellera. The bandwidth in the LWG is way too limited to maintain more than one version of the proof-of-concept library. You should fix the "mutable reference" issues by dropping the "mutable" keyword in the reported lines. You'll probably need to add some missing headers as well, IIRC. The other warnings can be safely ignored (e.g. via -isystem). hth, Philipp

No. Some future version of the ASI SystemC proof-of-concept implementation may add support for Clang, but there is no release schedule for this at the moment. Upcoming releases and their call for public review will be announced via these forums, though. /Philipp

Kocha, Basically, your edit should work as expected. SystemC 2.3 is in fact tested with Clang >= 2.9. You should not edit the configure file, though. If you want to add clang++ to the detection script, add the case to configure.in and run autoreconf instead. Another option is to have symlinks for cc and c++ in your path, pointing to the Clang compilers. On my Debian workstation, I use the alternatives mechanism (see man update-alternatives) for cc/c++ to point to Clang: [philipph@tethys:~]$ update-alternatives --display cc | head -2 cc - manual mode link currently points to /usr/bin/clang [philipph@tethys:~]$ update-alternatives --display c++ | head -2 c++ - manual mode link currently points to /usr/bin/clang++ and then use../configure CC=cc CXX=c++ to configure SystemC for Clang.Greetings from Oldenburg, Philipp

This is a plain C++ question. The meaning of this line is not specific to SystemC. The line defines a const (member) function, returning a pointer to const char (known as "C string"). In the implementation, the constant character string "Hello world" is returned. Greetings from Oldenburg, Philipp

You should read up on C++ functions (and overloading) in general to learn about signatures. In the owning class of the simple_target_socket, a callback is registered instead of an explicit socket binding. One function is called reset_counter, the other one read_counter The stimulus class' socket (called read_increment) is bound in sc_main. But, as I said, the code is a rather bad example to learn about such basic things. /Philipp

The increment_request_transport just implements the b_transport interface for this component. It is registered on the forward path with the simple_target_socket, as you can see in the constructor. The name of this callback function can be chosen arbitrarily, as you can see (as long as the signature matches). That said, you should not adopt the coding style of this example. The target is not supposed to modify the data pointer (just its contents). Even worse, a pointer to a local variable is returned, which just happens to work by chance and may break at any moment (undefined behaviour). /Philipp

You're supposed to call the function, not to pass the function (pointer) to the bind call. Try something like sc_in<int> p_in; p_in( vh_const(42) ); You'll need to make sure that the parameter passed to vh_const matches the type of the port exactly, otherwise the binding will fail as well. If needed, you can add the type explicitly to the vh_const call: p_in( vh_const<int>(42L) ); // should work, even though argument is of type 'long' hth, Philipp

I think, your error message does not match the code you've shown. The compiler complains about an sc_in, not an sc_out as you've shown in your code. For input ports, you can apply a similar trick, but instead converting to an sc_signal_in_if<T> const&. If you need to provide a non-zero constant value, you'll need to assign this value to the signal that is created before returning it for the binding. It can be done via a free-standing function then (to avoid duplicating the datatype template argument). Something like the following (untested) snippet: template<typename T> sc_core::sc_signal_in_if<T> const & vh_const( T const & v ) // keep the name consistent with vh_open { // Yes, this is an (elaboration-time) memory leak. You can avoid it with some extra effort sc_core::sc_signal<T>* sig_p = new sc_core::sc_signal<T>( sc_core::sc_gen_unique_name("vh_const") ); sig_p->write( v ); return *sig_p; } Which version of MSVC do you use? You may want to try a newer one instead... hth, Philipp

Running your example program in a debugger prints the full expected information here: (gdb) print integer $1 = {<sc_dt::sc_int_base> = {<sc_dt::sc_value_base> = {_vptr.sc_value_base = 0x804a628}, m_val = 12, m_len = 30, m_ulen = 34}, <No data fields>} (gdb) print integer.m_val $2 = 12 Since some debugging information is present, I assume that the symbols in the linked library were not found. Read the INSTALL information that is part of the SystemC 2.3.0 package (quoting): ... Several options are available to the configure script to modify the compiler configuration and the selection of certain features: --disable-shared do not build shared library (libsystemc.so) --enable-debug include debugging symbols --disable-optimize disable compiler optimization --disable-async-updates disable request_async_update support --enable-pthreads use POSIX threads for SystemC processes As you can see, there are specific options supported by the configure script to build the library variant you want. You seem to want something like: ../configure --enable-debug --disable-optimize --prefix=/usr/local/systemc230 Some comments on your build process: This won't work reliably (if at all). You should never mess with (internal) configure/Automake variables via the environment. Pass them as arguments to the configure call instead. Secondly, use standardized user-customisation variables like CXXFLAGS here. ../configure --enable-debug --disable-optimize --prefix=/usr/local/systemc230 CXXFLAGS="-Werror" hth, Philipp

Short answer: The standard requires an sc_trace overload for a user-defined (signal) datatype if and only if you actually trace this particular type. Defining the virtual function sc_object::trace would require an overload for each and every data type used within a primitive channel supporting traces, even if those signals are never traced. This would be quite inconvenient. /Philipp

I agree with Alan here. Moreover, when you look at the backtrace, you'll most probably see that the problem is within the sender part: The name thread_p_2 refers to the third dynamically created process in this module. Based on your loop above, this would be the second sender process. You didn't show the body of the sender. That said, it is always a good idea to add explicit names to the design elements you create. Something like: sc_spawn( sc_bind(&hermes_with_pkt_codec_vhd_bfm::sender, this, i), sc_core::sc_gen_unique_name("sender") ); Greetings from Oldenburg, Philipp

A small addition to Alan's nice explanation: If you don't target synthesis (which may not support this), you can avoid inconsistency errors due to the duplicated width information by using the arbitrary width base classes as well: result = sc_unsigned(sc_bv_base( rdata.range(127, 0) )) + sc_unsigned(sc_bv_base( wdata.range(63, 0) )); /Philipp

You need to jump through a temporary bit-vector (at least for the widerer range), I'm afraid. You can try something like the following untested snippet sc_biguint<128> temp1 = sc_bv<128>(rdata.range(127,0)); temp1 += wdata.range(63,0).to_uint64(); result = temp1; Greetings from Oldenburg, Philipp

I have two comments on the above snippet, assuming you're using sc_mutex. Firstly, your check should never print FAILURE, unless the unlock itself failed. Therefore, you should check for the return value of the unlock call instead. You need to unlock the mutex from within the same SystemC process you have locked the mutex from, otherwise the unlock will be rejected. Secondly, there is no delta delay required (or enforced) between the unlock and a subsequent lock. The pending lock calls (or any subsequent trylock during the same evaluation cycle) will succeed to lock the mutex again. The internal event used to notify blocked processes is triggered immediately, not within the next delta cycle. This may help to track down your problem. Greetings from Oldenburg, Philipp