AMS and SystemC Scheduler

[NickIlieskou]

Hello everybody, 

 

I would like to know if AMS and SystemC have two different schedulers. If yes then how do they interact? 

Moreover i would like to ask how many extensions does SystemC has? Thanks in advance

 

 

[maehne]

Each model of computation (MoC) of SystemC AMS uses an independent solver, which are specialised to the needs of the respective MoC. An individual solver instance is created for each topological cluster of connected modules of the same MoC. The LSF and ELN MoCs use a linear DAE solver to advance their local solution. The TDF MoC uses a static scheduler to execute the processing member functions of the TDF modules situated in the TDF cluster. The schedule is calculated during elaboration based on the Synchronous Data Flow (SDF) theory.

 

These different solvers have to be able to interact with each other to exchange information at the cluster boundaries and synchronize their local advancements of the model execution. The SystemC AMS standard defines the necessary synchronisation semantics but leaves it open how a SystemC AMS implementation shall achieve it. However, for your understanding, you can assume that:

 

- Each cluster is assigned to a solver instance. This solver instance represents the whole cluster with respect to the outside world (i.e., the communication through converter ports).

 

- An LSF or ELN solver can be thought of a TDF module, which is embedded into the connected TDF cluster.

 

- All TDF modules of a cluster are handled by a TDF scheduler instance, which is implemented as an SC_THREAD that is sensitive to the sc_signals connected to its DE->TDF input converter ports. While executing the TDF schedule in the SC_THREAD, it will issue discrete-event wait() statements as necessary to sample the DE signals and generate events on the signals connected to the TDF->DE output converter ports.

 

I hope this answers your first question in enough details.

 

Regarding your second question: SystemC has many extensions. However, not all are maintained as standards by the Accellera Systems Initiative. Accellera working groups standardised in the past as extensions to SystemC: TLM, the SystemC Verification library, and the SystemC AMS extensions. There are currently efforts to standardise CCI (configuration, control, and inspection) and UVM-SystemC.

[NickIlieskou]

Thank you for your elaborate response. Though I still have to ask a question regarding schedulers. 

 

I have a system with n independent DE clusters and one TDF cluster. The latter cluster is implemented inside an hierarchical SystemC module. This module is feeding the TDF cluster with values through DE->TDF input ports. Let's assume that at a time instant all the clusters (DE and TDF) have to execute. I noticed that the TDF cluster is executing first. Even before the SystemC hierarchical module gives an input. In other words the TDF cluster will execute with the old input values because the SystemC hierarhical module will run after the TDF modules. 

 

For this scenario can I assume that even if I had more than one TDF cluster, they would all execute before the DE clusters? 

Thank you in advance.

[maehne]

The SystemC AMS LRM states that each DE->TDF converter ports will always sample DE signals at delta cycle 0 of a given point in time. This means that if a DE process activates at time t (delta cycle 0) to immediately change a signal, this change won't be seen by the TDF cluster, which samples the DE signals in the very same delta cycle 0. However, the DE signal change won't be visible until delta cycle as the evaluate and update phase have to first finish.

 

For DE signals generated by TDF->DE converter ports, the new value will always get visible at delta cycle 1 (as the TDF cluster got activated in delta cycle 0).

 

Only with SystemC AMS 2.0, there's a limited way to react to events instantly that are happening at delta cycles > 0. For this, you have to use the Dynamic TDF features: all TDF modules of the cluster have to be marked to accept attribute changes. The module, which shall instantly react to an event has to be marked to also do attribute changes. Then that module can use request_next_activation on a DE->TDF input converter port to react instantly to an event. However, be aware that request_next_activation() only works at the very beginning of a cluster period. If your cluster is multi-rate, many activations of the TDF modules in the cluster will follow according to the pre-determined static schedule for the execution of the TDF cluster's processing functions. Only when the static schedule has been completed, a TDF module gets the chance to issue a new request_next_activation().

[NickIlieskou]

Thanks for your answer Now it's clear !!