Jump to content


Recommended Posts

Hi,  ngspice has a nice documentation on how it can be compiled as a shared library and also makes available a C-API for the application code to use it. examples.. ngspice-octave, etc... See chapter 19 of: http://ngspice.sourceforge.net/docs/ngspice-27-manual.pdf

Is this something the folks on the SC-AMS committee or in the working group could consider. A C-API for SC-AMS would be an added value and make the standard more attractive. In the meantime, I have seen some books and searched online but there is not much I found. Does anyone has some links ?


Link to comment
Share on other sites

Well, SystemC and SystemC AMS are just C++ libraries, which define the functions and classes that form a domain-specific language suitable for modeling complex digital and mixed-signal systems at a high level of abstraction based on different models of computation (e.g. Discrete Event, Timed Data Flow, Electrical Linear Networks, Linear Signal Flow) as well as their simulation using the embedded simulation kernel. As they are C++ libraries, it is straightforward to wrap any SystemC (AMS) model into a custom C function (or set of C functions), which respects the specific API that you need to integrate it into your top-level model. You just have to limit yourself to the basic C datatypes in the function interface and to declare the functions as extern "C". From these C functions, you will have to set up the model and control its execution by providing stimuli and feeding the SystemC models reactions back to your external model. You may also implement a custom primitive channel as a co-simulation bridge to another model running in a different simulator. To facilitate synchronisation in such scenarios, IEEE Std 1666-2011 provides async_request_update() (see clause 5.15.6).

That said, the main purpose of SystemC (AMS) is create virtual prototypes of entire complex SoCs early on in their design process to enable, e.g., architecture exploration, Hw/Sw partitioning, and early firmware development. This virtual prototype serves as a kind of golden reference during refinement. Therefore, your SystemC virtual prototype usually "sits on top", i.e., refined component models executed in external simulators are usually embedded via a module wrapper, which provides the SystemC interface for communication and makes use of the C API of the external simulator to communicate with the foreign model.

Given that, I don't see much need for any additional dedicated C API. What are you missing?

Link to comment
Share on other sites


Thanks, for the explanation. 

If the intention is that of staying within SystemC/C/C++ then, this is a closed System which works well. It can do great things in a cost-effective way. 

However, I think this would be a minimalist way of looking at the application. In the everyday work, models do exist in different environments and I would like to reuse them rather than redo them.  If someone has a model in Octave, I want to link to it (Octave,  also describes ways to use it with other applications). If there is a model in spice (ngspice) I want to link to it and use it. If someone has a model in Verilog. I want to use it too. In the same way, models available in SC/SC-AMS should be easily re-used in other application/external tools without needed to REwrite the SC* model into another language (which might come with pain anyway). So this is really not trying to reinvent the wheel all the time and being productive.

Also, REDOing them means spending extra money and time and if these are not an issue, there might be technical implications like missing expertise in teams and/or limitation of that particular environment.

Other examples are: 

  • connecting the output of your model to different processing libraries (could use a file but is not the point here) in real time and based on that, change the stimuli/parameters.
  • Shipping to costumes and/or interfacing with their environments
  • Interacting with hardware (an FPGA or an analogue test-chip)

If as you say we develop a system and prototype it within SC-AMS, It would be good to move vertically between prototype level and implementation level by means of REusing the already developed model. This is the best way to communicate intention and execute the model at different levels vertically.  If the environments, system-level design and implementation level design, are different there need to be a way to enable what I mentioned. 

So, I believe that an expert programmer can get around and find more solutions, but I am an engineer and I design circuits and do models of them, and I feel my time needs to go more into this direction rather than trying to solve the software problem. 

In my simple example, I have an RC filter (ELN) with a TDF driver. Self-contained all is fine. But when I want to use a C-Program to change the input of the filter instead... I can get into so many troubles and I am already wrapping C++ into C- supported structured and referring to them as "extern" all in a "C-API".

I will accept that I have limited knowledge to cover this topic, but I am also seeing that there are not many examples around (books, LRM, SC-AMS user guide, conferences). Other tools (some I mentioned) are seeing integration and interfacing being important and therefore they provide documentation, examples and eventually the full API. The same applies to SC/SC-AMS. 

Answering your question... This is what is missing. I think.


I like this quote from Ezra Pound.

“The sum of human wisdom is not contained in any one language, and no single language is capable of expressing all forms and degrees of human comprehension" 

Link to comment
Share on other sites

Your arguments for foreign model reuse are valid and this is recognised by the people behind the modeling language definitions and simulators. That's why basically all common simulation tools provide some API to control the simulation programmatically from a foreign process including some means for data exchange (for stimuli and monitoring). Also, these tools usually provide a way to import foreign functions (usually at least those following the C calling conventions). By these ways, you can implement the synchronisation and data exchange mechanism between your models according to your needs. SystemC (AMS) only differs that the models are already written in C++, which provides even less friction to interact with the C APIs of other simulators. However, you have to keep in mind the simulation semantics of these models, which are imposed by the embedded simulation kernel during simulation. You have to make sure that you don't interfere with them through your API use in a way that disturbs the model execution. To that end, you should read up on the elaboration and simulation semantics of SystemC (AMS) in the respective LRMs. You will see there that both language standards define dedicated callbacks, which allow you to take action during all phases of elaboration and simulation, which facilitate the coupling of SystemC models with other simulators/modeling languages. You either have to implement the interface yourself or use the EDA tool vendor-specific solutions, which have been available for years, e.g., QuestaSim is capable to mixed SystemC/VHDL/SystemVerilog models. Another example is the SystemC AMS IDE COSIDE, which provides tool couplings to all major HDL simulators as well as to MATLAB/Simulink, dSPACE, and ngspice.

For simple cases like you describe with your C application, which shall provide stimuli to your TDF model, you often get away with doing model synchronisation/data exchange via blocking read/write calls from within your SC_METHODs, SC_THREADs, or TDF processing() callbacks on some communication channel to your foreign model executed by another simulator. In the simplest case, this could be your stdin/stdout streams. Other popular options would be named pipes, sockets, or some some RPC API. The choice will largely depend on the modeling language/simulation tool, which you have on the other side. If they provide the possibility to import foreign C functions, they usually support all mentioned options.

I think you might find interesting the technology demonstrator, which was presented by David C. Black at DVCon 2013 as part of the "Increasing Productivity with SystemC in Complex System Design and Verification" tutorial and made available on GitHub a while back:



The goal of the project was to demonstrate multiple technologies

- ZedBoard containing Xylinx Zynq-7000 FPGA technology (contains dual Cortex
  A9's and many peripherals)
- How to have OS threads safely communicate with SystemC
- Use of TCPIP sockets, POSIX threads, and mutexes in C
- SystemC code using both IEEE 1666-2011 (C++) and ISO-IEC 14882-2011 (C++)
  features. These included:
  * SystemC async_request_update
  * SystemC ensuring sc_stop is called
  * C++ user-defined literals
  * C++ override keyword for safety
  * C++ threads
  * C++ mutexes
  * C++ unique_ptr<>
- Other features incidentally used:
  * SystemC dumping a netlist
  * Managing sc_reporting

You might also find other videos interesting, which are available from the Accellera website:


Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...