SystemC supporting several instances of a simulation in one application

[chunrong]

We have some different use-cases where SystemC models have to be created

dynamically during application life time. According to our understanding, this

is not officially supported.

 

Our workaround is based on creating a new instance of sc_core::sc_simcontext

and assign the instance to sc_default_global_context and sc_curr_simcontext.

When having several instance in parallel, sc_curr_simcontext is assigned with

the proper simcontext instance prior SystemC method invocations.

 

The risk with this workaround is that sc_curr_simcontext is not mentioned in

the documentation and might just disappear during further enhancements of

SystemC. Class sc_simcontext is already listed as deprecated features.

 

What do you suggest in our case to minimize the risk of not being compatible

with upcoming versions of SystemC ? I would also like to point out that with

the current workaround, unit testing can easily being achieved by using some of

the common unit test frameworks available. They use to create different

instances of the class under test when running the unit tests of a test suite.

I think that other users might appreciate to perform not only model testing but

perform tests on a finer granularity as well.

[karthickg]

 

We have some different use-cases where SystemC models have to be created

dynamically during application life time. According to our understanding, this

is not officially supported.

 

[snip]

It is possible to support "dynamic" model creation using SystemC, for example by reading command line parameters or a configuration file - if done before simulation starts. Once simulation starts, we can't create new models or add more ports.

 

As an example, the following can be done:

a. Have multiple top-levels, select one specific during a simulation run (using a command line argument or an environment variable or a config file, etc)

b. Create models and connections "on the fly", based on a connection topology in a configuration file. An example can be, a network simulation where the number of end-stations change in every simulation run.

c. Create bridges/switches that should add ports as and when connections are being made

 

I do not know enough to answer to your questions in the later part of the post.

[Philipp A Hartmann]

We have some different use-cases where SystemC models have to be created dynamically during application life time. According to our understanding, this is not officially supported.

 

Yes, running multiple evaluation phases (sequentially and/or concurrently/interleaved) is not mandated by the standard, see e.g. 4.3.2:

 

Whether the application may call function sc_elab_and_sim more than once is implementation-defined.

 

Our workaround is based on creating a new instance of sc_core::sc_simcontext and assign the instance to sc_default_global_context and sc_curr_simcontext.

When having several instance in parallel, sc_curr_simcontext is assigned with the proper simcontext instance prior SystemC method invocations.

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.

 

 

The risk with this workaround is that sc_curr_simcontext is not mentioned in the documentation and might just disappear during further enhancements of

SystemC. Class sc_simcontext is already listed as deprecated features.

 

 As said above, the non-standard function name is likely the least of your problems. ;-)

 

 

What do you suggest in our case to minimize the risk of not being compatible with upcoming versions of SystemC ? I would also like to point out that with

the current workaround, unit testing can easily being achieved by using some of the common unit test frameworks available. They use to create different

instances of the class under test when running the unit tests of a test suite. I think that other users might appreciate to perform not only model testing but

perform tests on a finer granularity as well.

 

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