Martin Barnasconi
-
Posts
89 -
Joined
-
Last visited
-
Days Won
18
Content Type
Profiles
Forums
Downloads
Events
Posts posted by Martin Barnasconi
-
-
RNM is a simple approach to represent analog signals by a real-value (amplitude) on a (discrete) event driven time axis. Depending on the type of signal, you need to generate a lot of samples (events) to follow the shape of the waveform (i.e. Nyquist rule). The event scheduling in a digital solver results in some simulation overhead, because the event list is dynamically scheduled and executed. The more events, the slower the simulation. Especially when you start modeling RF systems in RNM, your system simulation will get slow. In addition, the more input and outputs, the more events at these inputs and outputs, which need to be added to the sensitivity-list of the discrete-event solver. So the bigger the RNM system, the slow its gets.
Thanks to the Dataflow based simulation concept in SystemC-AMS, we do not have these issues. In SystemC-AMS the dataflow graph is based on the interconnected TDF modules, and computed before simulation starts. For each time step, this graph is executed only once, including signal input/output updates for all associated TDF modules. As such, the size of the TDF system does not matter much. Especially for bigger systems you will clearly see a difference between RNM in Verilog-AMS or SystemVerilog versus TDF modeling in Systemc-AMS, the latter being much faster.
-
Thanks for reporting this issue. We will look into this.
Just to be clear, I guess you refer to the example which is part of the crave version 0.9-alpha ?
-
UVM-SystemC simulation will automatically finish if all UVM phases have been executed (without any pending objections). You can look in the examples/simple/objections/basic example how to get the objection count. I expect somewhere you raise an objection, but you do not drop it.
The SystemC sc_stop will trigger end_of_simulation. So this is expected behaviour. However, in UVM-SystemC you should not call sc_stop yourself (in a similar way, as a user you do not start the simulation with sc_start)
-
The xutility and the _Adopt method you mentioned are not from the SystemC-AMS library. Who is calling this function? Perhaps you can send a backtrace.
-
Some remarks/questions:
- Please try the latest 2.1 version, which can be found here: http://www.coseda-tech.com/systemc-ams-proof-of-concept
- Can you supply some additional information on the compiler you use on windows: is this gcc in mingw/cygwin or using the msvc compiler. Please supply version
- Did you try starting the execution using gdb?
- Is your design using TDF modules only or also LSF and/or ELN?
-
This could be caused by the famous CRLF incompatibility between Windows/Dos and Unix/Linux.
Please try to run dos2unix for all files in the entire systemc tree, and then try again.
-
This is not a UVM-SystemC library but Eclipse configuration issue.
Some things you could check:
- In the Project Explorer view, the project should be labeled as C/C++ project and contain a subdirectory "Includes". In this list you should see the cygwin and uvm-systemc include directories. If this is not the case, then your project properties are not well defined.
- Do a Index >> Rebuild
- Just build the example and see if the error disappear (such build also does start a reindexing
Also note that UVM-SystemC puts all classes in the uvm namespace. This means you should explicitly prefix with uvm:: or define a using namespace uvm (only inside method implementations, not in global scope of header files)
-
There are some commercial and proprietary functional coverage approaches in C++/SystemC, but these are not contributed for standardization.
Therefore the WG will work on a new and open standard proposal, along the lines of the initial ideas as presented at NASCUG at DAC2014 (slide 30, 31):
http://nascug.org/events/20th/1-NASCUG20-UVMforSystemC-Karsten.pdf
Of course this is subject to change. For example, the prefixes will change, as well as some methods and arguments, since we aim for integration in UVM-SystemC.
-
I expect your SystemC module, as leave cell, uses regular ports (sc_in/sc_out). The SystemC AMS TDF module should use the converter ports (sca_tdf::sca_de::sca_in, sca_tdf::sca_de::sca_out), so it can be connected to regular SystemC modules.
This means that the top-level module, which instantiates this SystemC module and the SystemC AMS TDF module, should then a sc_signal, since the input for the SystemC AMS TDF module needs to see this type of signals.
-
The SystemC AMS 2.1 proof-of-concept in indeed licensed under Apache License, Version 2.0, January 2004.
Distribution need to comply to the rules as defined in this Apache 2.0 license.
Your package website indeed mentions under license "custom:SystemC-AMS Open Source License". Instead it should state "Apache License Version 2.0, January 2004".
My advice is to also contact the developer/maintainer of the PoC, which is COSEDA Technologies GmbH, to inform them on this initiative and to confirm your packaging initiative is recognized/supported:
info@coseda-tech.com
-
In your State-space function you did not explicitly specify the time step. In such case, the State-space function will take the module time step. It could be that this module time step is too coarse for your analog State-space equation. In that case, you should specify a more fine-grained timestep as argument for the State-space function.
-
This is work-in-progress in the Accellera SystemC Verification Working Group. Too difficult to give any estimations on availability, but I suggest to watch for the announcements around Accellera's DVCon events planned later this year.
Accellera member companies are encouraged to join the working groups to help in the creation, testing and debug of these important functionalities.
-
Could you please check with SystemC AMS 2.1 PoC and report if the warning is still there?
-
The SystemC class library itself does not support this configuration functionality. The UVM-SystemC class library obviously adds this functionality, since we target exactly the same functionality and features as UVM-SystemVerilog.
-
Please further explain your question:
- A system-level in SystemC model is often at a higher abstraction than RTL.
- Do you mean a UVM-SV or UVM-SystemC testbench?
Please have a look if your answer is in this FAQ
http://www.accellera.org/activities/working-groups/systemc-verification/uvm-systemc-faq
-
-
Can you give some more background on the HLS you are aiming for? Is this HLS for digital or analog functions?
For analog HLS (often called analog sizing), I suggest you to contact Laboratoire d’Informatique de Paris 6 (LIP6) at Université Pierre et Marie Curie (UPMC) in Paris, France. More info:
-
As stated in the FAQ UVM-SystemC does not support multi-language, and we advice you to contact your local EDA solution provider to check if UVM-SystemC can be combined with your RTL design.
There are other initiatives and libraries to address the multi-language challenge. I would also advice you to contact your local EDA solution provider for this.
-
Perhaps you can run some profiling tools (e.g. gprof) to examine where most of the simulation computation time is spend. My expectation is, with such a simple example, that you are primarily looking at the SystemC simulation kernel performance, not so much the AMS extensions. But profiling should reveal some insight in this.
-
The Accellera SystemC Verification Working Group is working hard to make a stable release of the UVM-SystemC library and Language Reference Manual.
Standardization of the API is still ongoing and there are still changes proposed to both library as well as LRM. As soon as things are getting stable, we will consider releasing it. Timing will be defined by the Accellera VWG.
-
some other proposed fixes:
- remove the #define SC_INCLUDE_DYNAMIC_PROCESSES as you do not need this
- the method sca_get_time() does not exist, use get_time() instead
- it would be more logical to move the ampl=1000 to the constructor
-
Procedure is something like this:
* follow the INSTALL in the SystemC directory to install the SystemC libraries (e.g. configure, make, make install, make test)
* follow the INSTALL in the SystemC-AMS directory to install the SystemC-AMS libraries (e.g. configure, make, make install, make test)
* make a simple Makefile pointing to the include and library directories, specify the compiler used, and specify the objects to build
* execute the make file
If you are not familiar with a makefile and gcc based flow, I suggest to do some reading, studying and experimenting first and start with normal C++ programs and libraries, before juming on SystemC and SystemC-AMS.
-
The standardization of SCV and UVM-SystemC in Accellera do not cover integration of eVC.
I suggest you ask your EDA tool supplier on the capabilities to support this, since you need to have an simulator supporting the e language (IEEE1647). A possible solution could be UVM-ML :
http://forums.accellera.org/files/file/65-uvm-ml-open-architecture/
-
Please check the paragraph at the bottom of this page:
http://www.accellera.org/community/systemc/about-systemc-ams
Tool support for SystemC-AMS
in SystemC AMS (Analog/Mixed-Signal)
Posted
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.