Jump to content

Martin Barnasconi

Members
  • Content Count

    69
  • Joined

  • Last visited

  • Days Won

    13

Reputation Activity

  1. Like
    Martin Barnasconi got a reaction from maehne in Set timestep in ELN module   
    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.
  2. Like
    Martin Barnasconi got a reaction from maehne in Set timestep in ELN module   
    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.
  3. Like
    Martin Barnasconi got a reaction from maehne in Error: System not scheduable   
    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.
  4. Like
    Martin Barnasconi got a reaction from Bruno in Error: System not scheduable   
    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.
  5. Like
    Martin Barnasconi got a reaction from maehne in Tool support for SystemC-AMS   
    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.
  6. Like
    Martin Barnasconi got a reaction from mormathis in Error: System not scheduable   
    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.
  7. Like
    Martin Barnasconi got a reaction from maehne in AMS modeling   
    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.
  8. Like
    Martin Barnasconi got a reaction from verif_learner in AMS modeling   
    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.
  9. Like
    Martin Barnasconi got a reaction from maehne in Dynamic TDF implementation   
    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.
  10. Like
    Martin Barnasconi got a reaction from maehne in Reading in file + upsampling   
    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.
  11. Like
    Martin Barnasconi got a reaction from maehne in Combining SystemC with SystemC AMS   
    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.
  12. Like
    Martin Barnasconi got a reaction from maehne in Combining SystemC with SystemC AMS   
    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.
  13. Like
    Martin Barnasconi got a reaction from maehne in Float number to bitfield   
    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 );
  14. Like
    Martin Barnasconi got a reaction from maehne in DVCon 2014 SystemC AMS tutorial now available as webcast!   
    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.
  15. Like
    Martin Barnasconi got a reaction from Pruthvi015 in UVM-SystemC Availalability   
    @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.
  16. Like
    Martin Barnasconi got a reaction from NickIlieskou in Combining SystemC with SystemC AMS   
    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.
  17. Like
    Martin Barnasconi got a reaction from NickIlieskou in Combining SystemC with SystemC AMS   
    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.
  18. Like
    Martin Barnasconi got a reaction from Philipp A Hartmann in Float number to bitfield   
    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 );
  19. Like
    Martin Barnasconi got a reaction from AlexSax in DVCon 2014 SystemC AMS tutorial now available as webcast!   
    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
     
  20. Like
    Martin Barnasconi got a reaction from AlexSax in Embedding SystemC-AMS into Verilog(-AMS)   
    I propose to take one step back, and before diving into the technical challenges of your request, just briefly explain to us why would you like to embed SystemC-AMS in Verilog-AMS?
     
    For me this sounds a bit strange, as I expect you might need to embed a more refined or detailed models (e.g. in Verilog-AMS) into a System-level model (e.g. SystemC-AMS) and not the other way round. Furthermore, as SystemC AMS supports conservative and signal flow modeling, I could argue there is no need at all to use Verilog-AMS. So why not stick to SystemC and SystemC-AMS?
     
    When you use Incisive, you can do a SystemC-on-top design. SystemC on top gives you much more flexibility and power than Verilog on top, for example you can easily include C/C++ functions, use the concept of interfaces, transaction-level modeling, and all these essential features you need to create a good system-level testbench or virtual prototype for/of your system.
    I would recommed reading the manual how to use ncsc_run or irun to do SystemC on top.
     
    If you then want to include SystemC-AMS, just compile this library together with the build-in SystemC library of Incisive. This is feasible as the SystemC-AMS PoC fully relies on the SystemC standard API, which is supported and implemented by most EDA vendors. For example, you put  all SystemC-AMS source files in a fileset (.f) and pass it in one go to irun. 
     
    After this preparation you can make your design, and make the connections as suggested by Torsten, by using the TDF converter ports of type sca_tdf::sca_de::sca_in<T> or sca_tdf::sca_de::sca_out<T> to connect to a SystemC sc_in<T> or sc_out<T>.
     
    Such approach saves you from the big hassle to deal with multiple languages, and above all from the ugly and inefficient $bitstoreal and $realtobits.
     
    Just my 2 ct ;-)
  21. Like
    Martin Barnasconi got a reaction from AlexSax in Perform action on signal   
    Although I do not understand well your application (perhaps you can explain a bit more), here some things which might help.
     
    The SystemC AMS TDF modules are tiggered -or fired according to the synchronous data flow terminology-  if all samples are available at its input ports. In such case, the processing() method is called. You can add a simple data member counting the number of firings of this processing() method, As the time step is known, you should then know when to perform the additional calculations on your array.
    Alternatively, you can use the get_time() method to ask for the time in a TDF module (note: you should not use the sc_time_stamp(), as the SystemC time might differ from the SystemC AMS TDF time in a TDF module), and compare it with previous stored time (also using a data member) and take action if the time difference is what you expect.
     
    Note that the whole idea of SystemC AMS is to keep the number of digital discrete events (handled by the SystemC kernal) for signal-level interfaces as low as possible, and therefore time handled in the SystemC AMS kernel. Actually, the time in TDF models is annotated, based on the static schedule which can be calculated prior to simulation, and thus the number of discrete events processed by the SystemC kernel is kept as low as possible. So I would not introduce additional (SystemC) modules to generate additional events; instead, it is adviced to calculate the number of firings or time in a TDF module.
  22. Like
    Martin Barnasconi got a reaction from AlexSax in Derivative using ELN constructs   
    It seems your starting point is Verilog-A or Verilog-AMS, because the ddt keyword is defined in this langauge. Note that Verilog-A/MS do not offer electrical primitives as part of the language defintion, so you should create your own. The ddt keyword is invented to create equations to model inductors or capacitors. But for the SystemC AMS extensions, you do not need to do all this; you can simply instantiate an inductor or capacitor.
     
    So the lession is: do not blindly map Verilog-A/MS concepts on SystemC AMS.
     
    Instead, explore if and how to abstract the analog functionality, perferably to a signal flow (LSF) or data flow (TDF) model of computation. Remember: SystemC AMS is a system-level language. If this is not possible, I expect you are dealing with electrical signals or conservative behaviour, and you should be able to directly use the predefined electrical primitives to model your analog subsystem.
  23. Like
    Martin Barnasconi got a reaction from karandeep963 in UVM-SystemC Availalability   
    Indeed, UVM in SystemC is only available for Accellera members at this stage, because the API is still under review. The SystemC Verification Working Group will define when the associated proof-of-concept implementation becomes available for the public.
  24. Like
    Martin Barnasconi got a reaction from maehne in Derivative using ELN constructs   
    It seems your starting point is Verilog-A or Verilog-AMS, because the ddt keyword is defined in this langauge. Note that Verilog-A/MS do not offer electrical primitives as part of the language defintion, so you should create your own. The ddt keyword is invented to create equations to model inductors or capacitors. But for the SystemC AMS extensions, you do not need to do all this; you can simply instantiate an inductor or capacitor.
     
    So the lession is: do not blindly map Verilog-A/MS concepts on SystemC AMS.
     
    Instead, explore if and how to abstract the analog functionality, perferably to a signal flow (LSF) or data flow (TDF) model of computation. Remember: SystemC AMS is a system-level language. If this is not possible, I expect you are dealing with electrical signals or conservative behaviour, and you should be able to directly use the predefined electrical primitives to model your analog subsystem.
  25. Like
    Martin Barnasconi got a reaction from maehne in Embedding SystemC-AMS into Verilog(-AMS)   
    I propose to take one step back, and before diving into the technical challenges of your request, just briefly explain to us why would you like to embed SystemC-AMS in Verilog-AMS?
     
    For me this sounds a bit strange, as I expect you might need to embed a more refined or detailed models (e.g. in Verilog-AMS) into a System-level model (e.g. SystemC-AMS) and not the other way round. Furthermore, as SystemC AMS supports conservative and signal flow modeling, I could argue there is no need at all to use Verilog-AMS. So why not stick to SystemC and SystemC-AMS?
     
    When you use Incisive, you can do a SystemC-on-top design. SystemC on top gives you much more flexibility and power than Verilog on top, for example you can easily include C/C++ functions, use the concept of interfaces, transaction-level modeling, and all these essential features you need to create a good system-level testbench or virtual prototype for/of your system.
    I would recommed reading the manual how to use ncsc_run or irun to do SystemC on top.
     
    If you then want to include SystemC-AMS, just compile this library together with the build-in SystemC library of Incisive. This is feasible as the SystemC-AMS PoC fully relies on the SystemC standard API, which is supported and implemented by most EDA vendors. For example, you put  all SystemC-AMS source files in a fileset (.f) and pass it in one go to irun. 
     
    After this preparation you can make your design, and make the connections as suggested by Torsten, by using the TDF converter ports of type sca_tdf::sca_de::sca_in<T> or sca_tdf::sca_de::sca_out<T> to connect to a SystemC sc_in<T> or sc_out<T>.
     
    Such approach saves you from the big hassle to deal with multiple languages, and above all from the ugly and inefficient $bitstoreal and $realtobits.
     
    Just my 2 ct ;-)
×
×
  • Create New...