Philipp A Hartmann

No. These process flavors are subject to the dont_initialize() setting. See IEEE 1666-2011, 4.2.1.1, step (b): Greetings from Duisburg, Philipp

Because clocked threads are sensitive to an explicit clock. This clock does not have to be active during the start of the simulation. Greetings from Duisburg, Philipp

Yes, creating a process with dont_initialize() set just keeps it off the runnable queue until it is triggered by its static sensitivity (or through an explicit reset() on a process handle of it). Without dont_initialize(), static process are marked as runnable during the initialization phase, while dynamic processes are made runnable immediately (i.e. in the current/next evaluation phase). Hope that helps, Philipp

Hi Antonio, as I understand it, the SystemC AMS proof-of-concept implementation is now provided by COSEDA, see http://www.coseda-tech.com/systemc-ams-proof-of-concept Hope that helps, Philipp

Recommended practice is to put SC_HAS_PROCESS within the scope of the module itself: SC_MODULE(Module) { SC_HAS_PROCESS(Module); // ... }; Hope that helps, Philipp

For an up-to-date documentation of SystemC, please refer to the IEEE Std. 1666-2011, available free of charge (thanks to the Accellera Systems Initiative) from http://standards.ieee.org/getieee/1666/download/1666-2011.pdf.

Try using the current public review release of SystemC 2.3.2 (see the following announcement): This version has been tested successfully on Visual Studio 2015. Hope that helps, Philipp

Hi Ameya, thanks for testing the 2.3.2 public review release! You mentioned, that you saw 15 errors when running the regressions on your platform? Would it be possible to share the list of failing tests and your platform/compiler versions? As you may have seen, I have opened a new topic about your C++ standard question here: Thanks for the analysis and the reporting of the issue. I have prepared a fix for the 2.3.2 final release which avoids the need for the synthesis of the ..._FILTER variable in test script. Instead, the optional filter is substituted directly from within the Makefile and GNU make supports variables starting with a digit. This topic is under discussion since quite some time both inside and outside of Accellera. The best option to contribute patches/fixes to the SystemC proof-of-concept implementations is of course to join the corresponding Accellera Working Groups. If this is not an option, let's continue to use this community forum for public discussions around SystemC and its proof-of-concept implementation. Greetings from Duisburg, Philipp

Hi Ahmed, apologies for the late reply. This is indeed an surprising behavior on your system. It seems the default "--libdir" setting from Autoconf is different on your platform - which is not expected. Can you please post the output of running ../configure --help In order to create the canonical "classic installation layout" of SystemC, you can override the --libdir default via (please note the single quotes): ../configure --libdir='${prefix}/lib' I'll look into the TESTNAME incompatibility for the final 2.3.2 release as well. Thanks and Greetings from Duisburg, Philipp

Hi Ameya, you're right: The SystemC 2.3.2 release selects a particular C++ standard to build upon and enforces consistency of this selection between the model and the library at link-time. Users can override the detection by setting the SC_CPLUSPLUS macro at build time to a (usually earlier) C++ version, as documented in the RELEASENOTES and INSTALL files of the SystemC 2.3.2 public review release. RELEASENOTES: 5) Initial support for C++11/14 =============================== This package includes an initial implementation of the C++11/14 proposal, presented at DVCon Europe 2016 ("Moving SystemC to a new C++ Standard"). This includes the addition of two new preprocessor symbols: - IEEE_1666_CPLUSPLUS (read-only) This symbol indicates the availability of certain SystemC features which depend on a particular version of the ISO C++ standard (see below). - SC_CPLUSPLUS (overridable) By default, the most recent supported version of the C++ standard for the current platform/compiler is automatically detected and reflected by the SC_CPLUSPLUS macro. Users can override (i.e. usually downgrade) the assumed C++ standard to an earlier version for compatiblity. The value of this macro has to be set consistently across the SystemC library build and all linked models (see INSTALL). The values of these macros follow the values defined by the C++ standards. Currently supported versions are: - 199711L (C++03, ISO/IEC 14882:1998, 14882:2003) - 201103L (C++11, ISO/IEC 14882:2011) - 201402L (C++14, ISO/IEC 14882:2014) The following features currently require a dedicated C++ standard version beyond ISO/IEC 14882:2003 (aka C++03): - C++11 (IEEE_1666_CPLUSPLUS==201103L) o explicit sc_bitref_r<>::operator bool() const Restricts direct boolean conversion of bitvector element references to explicit boolean contexts (e.g. `if` expressions). Use the `to_bool()` function on earlier setups. In the future, further language features depending on modern C++ language constructs may be added. INSTALL: * SC_CPLUSPLUS - Override automatically detected C++ standard support This setting allows downgrading the assumed version of the underlying C++ standard on the current platform. By default, the latest supported version is chosen. Supported values are * SC_CPLUSPLUS=199701L (C++03, ISO/IEC 14882:1998, 14882:2003) * SC_CPLUSPLUS=201103L (C++11, ISO/IEC 14882:2011) * SC_CPLUSPLUS=201402L (C++14, ISO/IEC 14882:2014) Note: This symbol needs to be consistently defined in the library and any application linking against the built library. Especially the last note in the RELEASENOTES is relevant to your question: In order to reduce the complexity of all the different C++ language support differences across compiler versions, the LWG decided to at least enforce a consistent selection of the C++ baseline in the proof-of-concept implementation. Of course, other vendors may chose to allow more flexibility here, although sometimes even a consistent compiler version selection is mandated. With this decision, the implementation does not have to worry about binary compatibility across different (C++ standard dependent) feature sets in the future. As of today, the (currently internal) classes sc_type_index, sc_string_view differ depending on the platform's C++ standard support. Future extensions might change other classes as well. Not worrying about the ABI compatibility is a helpful simplification here. As described above, you can set -DSC_CPLUSPLUS=... consistently on the compiler command-line to build a single library build across several GCC versions. If supported by your platform/compiler, you can still use the different -std=c++XY flags (or their defaults) from the compilers, provided that they generate compatible code across the selected C++ standard version. Hope that clarifies the rationale behind the current implementation. Greetings from Duisburg, Philipp

In the SystemC 2.3.2 review thread Ameya Vikram Singh (@AmeyaVS) reported the following observation: I'll open a separate topic to discuss the details.

Did you include the required "extensions ctor" in your extension? template<unsigned DA_WIDTH> class scv_extensions<item_c<DA_WIDTH> > : public scv_extensions_base<item_c<DA_WIDTH> > { public: scv_extensions<sc_uint<DA_WIDTH> > addr; // ... SCV_EXTENSIONS_CTOR(item_c<DA_WIDTH>) { SCV_FIELD(addr); // ... } }; That said, (depending on your compiler) the current implementation of SCV_EXTENSIONS_CTOR is missing some "this->" qualifications in its body to cope with the different lookup rules for templated base classes. Hope that helps, Philipp

Unfortunately, the fix for this issue didn't make it into the 2.3.2 public review release. But we have now a possible fix, which is under review for the final 2.3.2 release: In src/tlm_utils/multi_passthrough_target_socket.h, add the following lines before the loop in multi_passthrough_target_socket::end_of_elaboration(): // complete binding only if there has been a real bind bool unbound = (binders.size() == 1 && m_export_callback_created); // no call to get_base_interface has consumed the export - ignore if (unbound) return; Hope that helps, Philipp

In general: Yes, this implementation is sufficient to implement a TLM2 extension. Still, there is a more reliable pattern to implement the copy_from and clone methods by using the copy constructor and assignment operator of your extension type (which you may need to implement in some cases anyway and will be provided for free in your particular example): class reg_extension : public tlm::tlm_extension<reg_extension> { public: tlm::tlm_extension_base* clone() const { return new reg_extension(*this); } // use copy constructor void copy_from(tlm::tlm_extension_base const & that ) { *this = static_cast<const reg_extension&>(that); } // use assignment operator // ... }; This pattern works very well for all Copyable and CopyAssignable classes without having to enumerate the members in clone and copy_from. Hope that helps, Philipp

Exactly. Hope that helps, Philipp

Hi S., The biggest issue in your code is that you set up the tracing before you initialize the "payload_data" pointer. Nothing good can come out of this. Secondly, sc_trace requires stable memory locations to trace, as it stores a pointer internally. So you can't easily reallocate the extension over and over again (or even later than the sc_trace call). Instead, I would suggest to reuse the extension across transactions and move it to a plain member in the class (changes added below): Hope that helps, Philipp

Side note: You can't use virtual inheritance with SystemC modules. See the following thread for a related discussion: Your example doesn't require this, so it should be fine to simply drop the virtual keyword in the sc_module inheritance. Hope that helps, Philipp

Maybe we can just reject "--enable-pthreads" on this platform explicitly. Generally speaking, you usually want to avoid pthreads, also on Linux, unless you have specific requirements. Greetings from Duisburg, Philipp

Can you explain, why you try to use Pthreads on the Msys/MinGW platform? This environment doesn't come with a Pthreads library by default, you would need to install a separate one. And Pthreads will certainly be less efficient than the WinFiber-based process implementation. Thanks, Philipp

Thanks for the reproducer, Sumit! This is indeed a regression compared to SystemC 2.3.0. I'll forward the issue to the SystemC Language Working Group. Greetings from Duisburg, Philipp

The instance specific extension is tied to a specific accessor object (usually a member in a module, e.g. an interconnect). So each accessor can have its own extension object and is responsible for cleaning it up later. For regular TLM extensions, yes, there can only be one extension object of each type in a transaction payload.

You can have a look at the "nb2b_adapter" test in the SystemC regression test suite, located at tests/tlm/nb2b_adapter/nb2b_adapter.cpp. In this example, you find the usage of an instance-specific extension for exactly that purpose: struct route_extension: tlm_utils::instance_specific_extension<route_extension> { int id; }; // ... virtual tlm::tlm_sync_enum nb_transport_fw( int id, tlm::tlm_generic_payload& trans, tlm::tlm_phase& phase, sc_time& delay ) { route_extension* ext = 0; if (phase == tlm::BEGIN_REQ) { ext = new route_extension; ext->id = id; // <-- store ID in the extension accessor(trans).set_extension(ext); } // ... virtual tlm::tlm_sync_enum nb_transport_bw( int id, tlm::tlm_generic_payload& trans, tlm::tlm_phase& phase, sc_time& delay ) { route_extension* ext = 0; accessor(trans).get_extension(ext); sc_assert(ext); tlm::tlm_sync_enum status; status = targ_socket[ ext->id ]->nb_transport_bw( trans, phase, delay ); // use ID from the extension Hope that helps, Philipp

In line 33 of your producer.h, it seems you accidentally try to copy an interface (something derived from sc_interface). In order to give more detailed feedback, please share the code around the offending line. Hope that helps, Philipp

Hi Sumit, even if the sockets are optional, you still need to bind at least one socket callback, right? Can you please check, that you actually do this? Greetings from Duisburg, Philipp

On modern GCC versions (starting with 5.x), you the binary interface changed between C++03 and C++11 mode. You need to build your SystemC library with the same compiler (settings) to get the C++11 version of the functions. Hope that helps, Philipp