Philipp A Hartmann

May 30, 2017

2 minutes ago, SystemCInDepth said:

So, if SC_METHOD or SC_THREADis sensitive to some clock event. It will also be excluded from the initialization phase. Is it ?

No. These process flavors are subject to the dont_initialize() setting.

See IEEE 1666-2011, 4.2.1.1, step (b):

Quote

Add every method and thread process instance in the object hierarchy to the set of runnable
processes, but exclude those process instances for which the function dont_initialize has been
called, and exclude clocked thread processes.

Greetings from Duisburg,
Philipp

maehne · May 28, 2017

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

maehne · May 28, 2017

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

maehne · May 28, 2017

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

maehne · May 19, 2017

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

May 18, 2017

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.

May 3, 2017

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

maehne · April 30, 2017

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:

On 3/1/2017 at 8:09 AM, AmeyaVS said:

The first failure I hit was the built-in make check tests failing under newer build environment.

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.

On 3/1/2017 at 8:09 AM, AmeyaVS said:

Would it be possible to have an official publicly hosted repository? (Something on the lines of Github/Bitbucket, where one can provide patches or fixes to the issues).

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

maehne · April 30, 2017

Hi Ahmed,

apologies for the late reply.

On 1/23/2017 at 10:21 PM, donpalavi said:

When I compile with my amd64 system the systemc code, I get the

"lib64-linux64" library,

while the leader of the course get the

"lib-linux64" library.

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

David Black · April 30, 2017

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.

On 3/4/2017 at 7:14 PM, AmeyaVS said:

Can anyone comment why C++ standard specific API specs are required?

For now I can circumvent the issue while setting either no compiler standard flags, or commenting out the compiler standard is passed into the build system.

Is the SystemC library will be following this trend to build different version supporting different compiler standard flags?

Note: As per cursory look into the source code I don't see any other API dependency to have information about the C++ standard being used to build and compile the SystemC library and the SystemC models.

Especially the last note in the RELEASENOTES is relevant to your question:

Quote

In the future, further language features depending on modern C++ language constructs may be added.

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

April 30, 2017

In the SystemC 2.3.2 review thread

Ameya Vikram Singh (@AmeyaVS) reported the following observation:

On 3/4/2017 at 7:14 PM, AmeyaVS said:
Hello,

Also hit a build issue when mixing different compiler standard compiler flags:

The build error:
SystemC review error: when building example using c++11 option and compiler supports: C++14 also.

CMakeFiles/systemc.run.dir/src/main.cpp.o: In function `__static_initialization_and_destruction_0':
/home/ameya/sysc2.3.2_rew/include/sysc/kernel/sc_ver.h:179: undefined reference to `sc_core::sc_api_version_2_3_2_cxx201103L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201103L(sc_core::sc_writer_policy)'
Compiler used g++ 6.3

Using same compiler to build systemc-2.3.1a results in no issues, also when mixing C++ standard compiler flags to build SystemC models.

While building the SystemC_2.3.2_draft one has to maintain the C++ standard compiler flags(-std=c++11 or -std=c++14), that is supported by the g++ compiler by default and any project using overridden standard compiler flags also needed to be updated to to default compiler standard flags.

Here are the differences in the symbols generated by the same compiler over different versions of systemc:

SystemC-2.3.1a: (Using g++ 6.3.0)
000000000000023e T sc_core::sc_api_version_2_3_1<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_1(sc_core::sc_writer_policy)
000000000000023e T sc_core::sc_api_version_2_3_1<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_1(sc_core::sc_writer_policy)
000000000000002c b sc_core::sc_api_version_2_3_1<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_1(sc_core::sc_writer_policy)::default_writer_policy_config
000000000000002a b sc_core::sc_api_version_2_3_1<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_1(sc_core::sc_writer_policy)::default_writer_policy_config_seen
SystemC-2.3.2-draft review:(Using g++ 6.3.0)
00000000000007d0 T sc_core::sc_api_version_2_3_2_cxx201402L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201402L(sc_core::sc_writer_policy)
00000000000007d0 T sc_core::sc_api_version_2_3_2_cxx201402L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201402L(sc_core::sc_writer_policy)
0000000000000028 b sc_core::sc_api_version_2_3_2_cxx201402L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201402L(sc_core::sc_writer_policy)::default_writer_policy_config
000000000000002c b sc_core::sc_api_version_2_3_2_cxx201402L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201402L(sc_core::sc_writer_policy)::default_writer_policy_config_seen
Can anyone comment why C++ standard specific API specs are required?

For now I can circumvent the issue while setting either no compiler standard flags, or commenting out the compiler standard is passed into the build system.

Is the SystemC library will be following this trend to build different version supporting different compiler standard flags?

Note: As per cursory look into the source code I don't see any other API dependency to have information about the C++ standard being used to build and compile the SystemC library and the SystemC models.

Would like to hear community members thoughts on this?

Best Regards,

Ameya Vikram Singh

I'll open a separate topic to discuss the details.

April 23, 2017

On 21/04/2017 at 6:01 PM, Loki5000 said:

I'm trying to use SCV_EXTENSIONS and scv_smart_ptr like Akhila do, but my scv_extensions class becomes not fully specialized in my case:

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

April 18, 2017

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

kartikkg · April 11, 2017

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

April 11, 2017

On 29/03/2017 at 6:57 PM, ankitks said:

My only confusion is that, if I look at code for instance specific extension, it already has pool class called 'instance_specific_extension_container_pool'. Is this class their to manager different extensions and not specific extension that I need to manage?

Exactly.

Hope that helps,
Philipp

April 11, 2017

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):

On 02/03/2017 at 7:12 PM, svinco said:


class testbench
  : public sc_module
  , public virtual tlm::tlm_bw_transport_if<>
{

public:

  tlm::tlm_initiator_socket<> initiator_socket;
  // reg_extension * payload_data;
  reg_extension payload_data; // <-- data member
  ...
}

void testbench::run()
{

  tlm::tlm_generic_payload * trans;	
  sc_time time;  
  
  mem = new mem_manager(); 
  trans = mem->allocate(); 
  // payload_data = new reg_extension; 
  
  // payload_data->value = sc_bv<16>("00001111"); 
  // payload_data->reset = 1; 
  payload_data.value = sc_bv<16>("00001111"); 
  payload_data.reset = 1; 

  trans->set_data_length(sizeof(register_data_t)); 
  // trans->set_auto_extension(payload_data); 
  trans->set_extension(&payload_data);

  trans->set_address(0); 
  trans->set_write(); 

  initiator_socket->b_transport(*trans, time); 
  ...
  // unset extension (no cleanup as it is a member of the module)
  trans->clear_extension(&payload_data);
}

Hope that helps,
Philipp

swami-cst · April 11, 2017

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

March 23, 2017

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

March 21, 2017

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

deeku · February 15, 2017

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

February 15, 2017

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.

February 8, 2017

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

February 7, 2017

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

February 5, 2017

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

AmeyaVS · February 1, 2017

On 1/21/2017 at 4:36 PM, bijoy said:

`sc_dt::sc_int_base::print(std::ostream&) const':
/usr/local/systemc-2.3/include/sysc/datatypes/int/sc_int_base.h:865: undefined reference to `sc_dt::sc_int_base::to_string[abi:cxx11](sc_dt::sc_numrep, bool) const'
collect2: error: ld returned 1 exit status
Makefile.rules:150: recipe for target 'a.x' failed

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

Sign In

Philipp A Hartmann

Posts

Joined

Last visited

Days Won

Content Type

Profiles

Forums

Downloads

Events

Posts posted by Philipp A Hartmann

Clocked thread SC_CTHREAD exclusion during initialization phase

Clocked thread SC_CTHREAD exclusion during initialization phase

Dynamic processes and initialization phase

SystemC AMS package unavailable for download

Scope of SC_HAS_PROCESS

How to implement parent-child relationship?

systemC on visual studio 2015

SystemC 2.3.2 Public Review Now Open

Fail to install SystemC 2.3.1 on OpenSUSE Tumbleweed

Support for C++11/14 in SystemC 2.3.2

Support for C++11/14 in SystemC 2.3.2

Randomizing sequence items in UVM-SC

Unbound multi_passthrough_initiator_socket/multi_passthrough_target_socket

TLM payload extension declaration

instance/tlm extension and memory manager

sc_trace and tlm_extensions compatibility

sc_module_name parameter for your constructor is required error

SystemC-2.3.1a clang build fail

SystemC-2.3.1a clang build fail

Unbound multi_passthrough_initiator_socket/multi_passthrough_target_socket

how can peq_cb have access to my socket's port_id

how can peq_cb have access to my socket's port_id

error of sc_interface private in UVM_ML bench

Unbound multi_passthrough_initiator_socket/multi_passthrough_target_socket

In function `sc_dt::sc_uint_base::print(std::ostream&) const': /usr/local/systemc-2.3/include/sysc/datatypes/int/sc_uint_base.h:844: undefined reference to `sc_dt::sc_uint_base::to_string[abi:cxx11](sc_dt::sc_numrep, bool) const'

Browse

Activity