Martin Barnasconi

You need to specify the timestep to at least one TDF module or TDF port, using method set_timestep. In a TDF module this method should be called in the callback set_attributes. See section 2.3.1 (Discrete-time modeling) and Example 2.11 in the SystemC-AMS User's Guide.
 

Accellera released the SystemC AMS user's guide application examples, which are available for download via this link.
These examples can be executed using your preferred EDA tools, as long as they support the SystemC and SystemC AMS language standard. Alternatively, you can use the open source SystemC and SystemC AMS reference implementations. Instructions for installation and execution can be found in the INSTALL or README files as part of these packages.
We welcome your feedback!

The SystemC AMS standard defines in section 9.1.2.6 (sca_util::sca_trace) that it can trace objects of type sca_traceable_object. Since all ELN primitives are derived of this type, you can simply trace the ELN component itself, see example below
 
SC_MODULE(eln_circuit) { // node declaration sca_eln::sca_node n1; // ELN node sca_eln::sca_node_ref gnd; // ELN ground // component declaration sca_eln::sca_vsource vin; sca_eln::sca_r r1; // constructor including ELN netlist eln_circuit( sc_core::sc_module_name nm ) : vin("vin", 0.0, 1.23), r1("r1", 1e3) { // Only ELN primitives requires explicit timestep assignment to one element vin.set_timestep(1.0, sc_core::SC_MS); // netlist vin.p(n1); vin.n(gnd); r1.p(n1); r1.n(gnd); } }; int sc_main(int argc, char* argv[]) { eln_circuit cir("eln_circuit"); sca_util::sca_trace_file* tf = sca_util::sca_create_tabular_trace_file("trace.dat"); sca_util::sca_trace(tf, cir.n1, "v_n1"); sca_util::sca_trace(tf, cir.vin, "i_through_vin"); sca_util::sca_trace(tf, cir.r1, "i_through_r1"); sc_core::sc_start(1.0, sc_core::SC_MS); sca_util::sca_close_tabular_trace_file(tf); return 0; }  

The Accellera SystemC AMS Working Group released the 2020 edition of the SystemC AMS User's Guide. You will find the user's guide on this page:
https://www.accellera.org/downloads/standards/systemc
This version of the user's guide is fully compatible with the SystemC AMS standard released as IEEE Std. 1666.1-2016. It describes all the features introduced in the SystemC AMS language standard during the last decade. For example, the user’s guide now explains the use of the dynamic timed data flow capabilities, to make AMS system simulations even more efficient and running even faster.
The SystemC AMS Working Group is currently preparing the release of the user's guide application examples as separate download. Availability of these application examples will be communicated at a later stage.
Please use this forum to post your questions or remarks on the user's guide.

The Accellera SystemC AMS Working Group released the 2020 edition of the SystemC AMS User's Guide. You will find the user's guide on this page:
https://www.accellera.org/downloads/standards/systemc
This version of the user's guide is fully compatible with the SystemC AMS standard released as IEEE Std. 1666.1-2016. It describes all the features introduced in the SystemC AMS language standard during the last decade. For example, the user’s guide now explains the use of the dynamic timed data flow capabilities, to make AMS system simulations even more efficient and running even faster.
The SystemC AMS Working Group is currently preparing the release of the user's guide application examples as separate download. Availability of these application examples will be communicated at a later stage.
Please use this forum to post your questions or remarks on the user's guide.

The Accellera SystemC AMS Working Group released the 2020 edition of the SystemC AMS User's Guide. You will find the user's guide on this page:
https://www.accellera.org/downloads/standards/systemc
This version of the user's guide is fully compatible with the SystemC AMS standard released as IEEE Std. 1666.1-2016. It describes all the features introduced in the SystemC AMS language standard during the last decade. For example, the user’s guide now explains the use of the dynamic timed data flow capabilities, to make AMS system simulations even more efficient and running even faster.
The SystemC AMS Working Group is currently preparing the release of the user's guide application examples as separate download. Availability of these application examples will be communicated at a later stage.
Please use this forum to post your questions or remarks on the user's guide.

The (old) SystemC AMS User's Guide is now directly accessible via this link:
http://www.accellera.org/images/downloads/standards/systemc/OSCI_SystemC_AMS_Users_Guide.pdf
And also listed in the overview of SystemC standards:
http://www.accellera.org/downloads/standards/systemc
As mentioned before, the AMS Working Group members are currently working on the update of the User's Guide by including the dynamic TDF timestep features which are also part of the IEEE 1666.1 standard.

Please note that the electrical primitives are predefined elements using the ELN model of computation; there is no mechanism to create your own electrical primitives. As such there is no such thing as a SCA_ELN_MODULE. Primitive modules can only be created for the TDF MoC, hence the SCA_TDF_MODULE macro as alternative to the class sca_tdf::sca_module.
Wrt the the SystemC AMS 1.0 User's Guide, I will start an action to make it available independently of the LRM.
Although the authors of the User's Guide are quite busy with other things, they full recognize the need to update the guide including the Dynamic TDF features as introduced in AMS 2.0 and IEEE1666.1. We hope to announce an update of the document in the coming period.

It looks like you have a multi-rate system, i.e. somewhere you defined a <port>.set_rate(..) in a set_attributes callback. Now you try to access the n-th sample at this port, like <port>.read(<sample>), but the nth sample is higher than the rate specified. This means you have either the wrong rate, or reading a sample outside the range defined by the rate.

I expect you have a loop (feedback path) in your design topology. This results in a circular dependency which cannot be resolved by the scheduler. To resolve this, add one time step delay, for example by specifying this delay in one of the output ports in the feedback path.

My advice is to ask your EDA vendor for support. If they are not able to support you, then download the SystemC-AMS open source implementation yourself and compile it against a commercial SystemC-based simulator.
After that create your (complex) design and show the simulation benefits to your EDA vendor, and explain (again) why SystemC-AMS is essential to have.

I expect you have a loop (feedback path) in your design topology. This results in a circular dependency which cannot be resolved by the scheduler. To resolve this, add one time step delay, for example by specifying this delay in one of the output ports in the feedback path.

This forum is related to SystemC-AMS, not Verilog-AMS. SystemC-AMS is used to model complex heterogeneous systems at an abstract level. Verilog-AMS is often used to model AMS blocks and circuits at the implementation level.
 
To answer your general questions
 
1) No. AMS modeling can be used to describe analog and/or digital behaviour, it is just a matter of abstraction. AMS modeling languages support different levels of abstraction. Low abstraction level relates to conservative behaviour, by solving Kirchhoff's voltage and current laws. Signal flow modeling approaches is an abstraction towards a non-conservative description, single quantity (voltage or current, not both) but still continuous in time. Further abstraction can be realized to data flow modeling approaches (discrete-time) or alternatively discrete-event modeling, or even transaction level.
SystemC-AMS allows you to model at different levels of abstraction, depending on the analog functionality or behaviour you would like to capture.
This is not only for analog subsystems, but also for digital subsystems. For example SystemC-AMS is very efficient to model Digital Signal Processing functions like FIR filters or IQ modulators/demodulators.
 
2) For sure, AMS modeling can be used to create AMS testbenches. Also here, it is just a matter of selecting the right abstraction level for the blocks in your testbench (stimuli, checkers, etc). Special care is always necessary at the boundary between 2 abstraction levels. This means there is not always the need to connect an analog stimuli to an analog input of the DUT, but you need to take care of the semantic difference and conversion if you cross such abstraction boundary. Often you need converter ports, modules or other interface elements in between to make the conversion from one domain (abstraction) to the other.
This is not only relevant for the interface between testbench and DUT, but also on-chip from analog subsystem A to digital subsystem B, where the abstraction level is thus different.

This forum is related to SystemC-AMS, not Verilog-AMS. SystemC-AMS is used to model complex heterogeneous systems at an abstract level. Verilog-AMS is often used to model AMS blocks and circuits at the implementation level.
 
To answer your general questions
 
1) No. AMS modeling can be used to describe analog and/or digital behaviour, it is just a matter of abstraction. AMS modeling languages support different levels of abstraction. Low abstraction level relates to conservative behaviour, by solving Kirchhoff's voltage and current laws. Signal flow modeling approaches is an abstraction towards a non-conservative description, single quantity (voltage or current, not both) but still continuous in time. Further abstraction can be realized to data flow modeling approaches (discrete-time) or alternatively discrete-event modeling, or even transaction level.
SystemC-AMS allows you to model at different levels of abstraction, depending on the analog functionality or behaviour you would like to capture.
This is not only for analog subsystems, but also for digital subsystems. For example SystemC-AMS is very efficient to model Digital Signal Processing functions like FIR filters or IQ modulators/demodulators.
 
2) For sure, AMS modeling can be used to create AMS testbenches. Also here, it is just a matter of selecting the right abstraction level for the blocks in your testbench (stimuli, checkers, etc). Special care is always necessary at the boundary between 2 abstraction levels. This means there is not always the need to connect an analog stimuli to an analog input of the DUT, but you need to take care of the semantic difference and conversion if you cross such abstraction boundary. Often you need converter ports, modules or other interface elements in between to make the conversion from one domain (abstraction) to the other.
This is not only relevant for the interface between testbench and DUT, but also on-chip from analog subsystem A to digital subsystem B, where the abstraction level is thus different.

The whitepaper was published long before the release of the SystemC AMS 2.0 LRM, so therefore there were some changes in the API. You will find the updated whitepaper in Annex A2 of the AMS 2.0 standard, which includes the updated language constructs. Here you can read that the member functions allow_dynamic_tdf() and disallow_dynamic_tdf() are replaced by does_attribute_changes() and does_no_attribute_changes(). The defintion of these methods are explained in the sections with the corresponding name.

I'm not familiar with this COSIDE library component, but it looks like your are facing a classical time step and rate inconsistency problem when different and incompatible time steps are defined in a single TDF cluster.
 
My advice is to read section 2.1.3 of the users guide (Time step assignment and propagation) and in particular the paragraph Consistency of time step assignment and propagation. Here you will see that you can have different time steps due to the rate setting. Please check carefully the time steps and rates defined in the methods set_attributes() of your TDF modules, and see if this is consistent with the formula given in the user guide: module time step = input port time step · input port rate = output port time step · output port rate
 
If changing the port time step is not possible (either by a parameter or changing the value in the method set_timestep(...) ), only then I would advice to apply the SystemC AMS 2.0 features. In this case, you basically split the TDF cluster in 2 independent TDF clusters, each having its own time step. Note that the complexity changes in this case, because you need to introduce dedicated decoupling ports.
 
But I expect you can resolve the issue easily by checking the consistency of time steps and rates.

1) A TDF cluster (in this case formed by modules A, B and C) runs dependently from any other part in the system. This other part can be another (not connected) TDF cluster or any other SystemC module which is executed following discrete-event semantics. Looking from an analog perspective on the matter, this is correct: the analog part is "always active" (assuming there is supply voltage - often we do not model this in system level models). As such, there is no dependency between the TDF cluster(s) and SystemC modules, and the execution order is then implementation defined. In the end, you define that both the TDF cluster as well as the SystemC modules need to be active each 10ms, and this will happen. If you would look at the results in a waveform viewer, you will not notice the difference, because you are not interested which samples are written to the screen (or file) first, as long as the samples appear at the right place in time.
 
2) Here you touch on one of the fundamental differences between SystemC AMS TDF modules using data flow semantics, and regular SystemC modules which work under a discrete-event regime. Due to the evaluate/update mechanism in the SystemC kernel, is it simply not possible using SystemC modules to write a value and read the value in the same simulation cycle. When using SystemC AMS TDF models, they will form a TDF cluster which defines the execution order, and this cluster can be computed prior to simulation. This means the signal values in the whole cluster are computed and thus known for each time step. In a pure SystemC topology however, there does not exists such dependency graph, and therefore the signal values through the system only propagate after each evaluate/update cycle. This effect is part of the discrete-event semantics and cannot be altered.

The SystemC AMS TDF model of computation follows the well known data flow semantics, which means that the module is activated (i.e. the SystemC AMS processing() callback is called) as soon as the samples are available at the input port(s). After this computation, the results are immediately available at the TDF output ports (assuming you write to output ports).
This means the SystemC AMS modules simply compute the signal as soon as TDF samples come in, and pass them after performing some signal processing to the output.
 
In SystemC AMS 2.0 we introduced the concept of "Dynamic TDF" which allows additional activation of the TDF module's processing() method as soon as discrete-events come in via the converter input ports (sca_tdf::sca_de::sca_in or sca_tdf::sc_in), but this concept should only be used to make reactive systems. I advice *not* to apply this in combination with your coordinator module.
 
Unfortunately your example of module A and B is incomplete (e.g. are module A and B connected?) to give good guidance. But the use of this coordinator module really sounds like overhead to the system simulation, as it is only meant to synchronize the execution of module A and B. Guess this is an artificial module to drive simulation only? This type of modules should be avoided. Architecture design in SystemC and SystemC AMS should represent the system by modules which are really available in the system.
Instead, you could implement this example using SystemC AMS only, where module A has a fixed time step of 10ms, and module B a time step of 20ms. You can connect them via a port with a rate of 2, which means module A is called twice, before module B is called. This gives you the right execution schedule. Furthermore, by following this approach, you basically skip the native SystemC discrete event semantics, and simulation even gets much more efficient.

I recommend to use the conversion as explained in this thread:
http://forums.accellera.org/topic/1637-type-casting-floating-point-nos/
 
note that the code of Philipp was untested and it contains some minor errors. Below the working code:
double val = ... sc_dt::scfx_ieee_double id(val); // convert to IEEE 754 bitfield bool sgn = id.negative(); sc_dt::sc_uint<11> exp = id.exponent(); sc_dt::sc_uint<52> mnt = ( sc_dt::uint64( id.mantissa1() ) << 20 ) | id.mantissa0(); // concatenate parts to bitvector sc_dt::sc_uint<64> bits; bits = ( sgn, exp, mnt );

We've added the PDFs of the different session to the same page. Please register/login via the URL given above to download the material.

@Steven: I expect it will be a matter of months to have the first (draft) material available. But again, it is the working group that decides on the schedule. Not sure if this will be LRM or proof-of-concept or both.
 
@Hans: UVM-SystemC is being developed and tested by end-user companies and system houses (of which only some are member in Accellera). Accellera supports the development of a multi-language verification standard, simply because UVM is available in different language flavors. UVM in SystemC/C++ is just one of them.

1) A TDF cluster (in this case formed by modules A, B and C) runs dependently from any other part in the system. This other part can be another (not connected) TDF cluster or any other SystemC module which is executed following discrete-event semantics. Looking from an analog perspective on the matter, this is correct: the analog part is "always active" (assuming there is supply voltage - often we do not model this in system level models). As such, there is no dependency between the TDF cluster(s) and SystemC modules, and the execution order is then implementation defined. In the end, you define that both the TDF cluster as well as the SystemC modules need to be active each 10ms, and this will happen. If you would look at the results in a waveform viewer, you will not notice the difference, because you are not interested which samples are written to the screen (or file) first, as long as the samples appear at the right place in time.
 
2) Here you touch on one of the fundamental differences between SystemC AMS TDF modules using data flow semantics, and regular SystemC modules which work under a discrete-event regime. Due to the evaluate/update mechanism in the SystemC kernel, is it simply not possible using SystemC modules to write a value and read the value in the same simulation cycle. When using SystemC AMS TDF models, they will form a TDF cluster which defines the execution order, and this cluster can be computed prior to simulation. This means the signal values in the whole cluster are computed and thus known for each time step. In a pure SystemC topology however, there does not exists such dependency graph, and therefore the signal values through the system only propagate after each evaluate/update cycle. This effect is part of the discrete-event semantics and cannot be altered.

The SystemC AMS TDF model of computation follows the well known data flow semantics, which means that the module is activated (i.e. the SystemC AMS processing() callback is called) as soon as the samples are available at the input port(s). After this computation, the results are immediately available at the TDF output ports (assuming you write to output ports).
This means the SystemC AMS modules simply compute the signal as soon as TDF samples come in, and pass them after performing some signal processing to the output.
 
In SystemC AMS 2.0 we introduced the concept of "Dynamic TDF" which allows additional activation of the TDF module's processing() method as soon as discrete-events come in via the converter input ports (sca_tdf::sca_de::sca_in or sca_tdf::sc_in), but this concept should only be used to make reactive systems. I advice *not* to apply this in combination with your coordinator module.
 
Unfortunately your example of module A and B is incomplete (e.g. are module A and B connected?) to give good guidance. But the use of this coordinator module really sounds like overhead to the system simulation, as it is only meant to synchronize the execution of module A and B. Guess this is an artificial module to drive simulation only? This type of modules should be avoided. Architecture design in SystemC and SystemC AMS should represent the system by modules which are really available in the system.
Instead, you could implement this example using SystemC AMS only, where module A has a fixed time step of 10ms, and module B a time step of 20ms. You can connect them via a port with a rate of 2, which means module A is called twice, before module B is called. This gives you the right execution schedule. Furthermore, by following this approach, you basically skip the native SystemC discrete event semantics, and simulation even gets much more efficient.

I recommend to use the conversion as explained in this thread:
http://forums.accellera.org/topic/1637-type-casting-floating-point-nos/
 
note that the code of Philipp was untested and it contains some minor errors. Below the working code:
double val = ... sc_dt::scfx_ieee_double id(val); // convert to IEEE 754 bitfield bool sgn = id.negative(); sc_dt::sc_uint<11> exp = id.exponent(); sc_dt::sc_uint<52> mnt = ( sc_dt::uint64( id.mantissa1() ) << 20 ) | id.mantissa0(); // concatenate parts to bitvector sc_dt::sc_uint<64> bits; bits = ( sgn, exp, mnt );

Hello all,

For those who were not able to attend the SystemC AMS tutorial at DVCon 2014, the full tutorial is now made available as webcast, including the presentations with voice-over, examples ("labs") and solutions.
 
Visit the following link (free registration required)

http://www.accellera.org/resources/videos/amsnextwave

We appreciate your feedback and your experience after following this SystemC AMS tutorial.

Regards,

Martin