Why Do We Need SystemC-AMS?

Recently, on March 19, Accellera announced SystemC AMS 2.0 providing an extended set of capabilities for system-level mixed-signal modeling. They described it as a set of extensions that define a uniform and standardized modeling approach that can be used in combination with digitally-oriented ESL design methods, supporting a design refinement methodology for functional modeling, architecture exploration, and virtual prototyping of embedded analog/mixed-signal systems.

So, now we have Verilog-AMS, VHDL-AMS, SystemVerilog-AMS, UML-MS and SystemC-AMS. I don't know if I am the only one but I am left scratching my head wondering why we need so many? Now I understand that SystemC addresses a different market than say Verilog or even SystemVerilog and that the merging of OSCI and Accellera happened much later than this work was started but it seems to me as if there is a huge amount of wasted effort going on here. It was bad enough during the language wars when Verilog and VHDL both had to be supported by all of the tools, but what a mess we are creating for the poor EDA companies that are being asked to support four languages and interfaces.

I talked to one person in the industry who asked to be anonymous because that company is still evaluating their strategy for SystemC-AMS. He said the roots of the language came from a European funded program. At present, there appeared to be little market interest outside of Europe. This starts to smell very much to me like the language wars all over again. The other problem for the EDA companies — and this has been a consistent problem with SystemC — is that there are reference implementations. This makes it a lot more difficult for an EDA company to provide the necessary investment and to get a return from it. The market expects a price of zero and that means no incentive for the EDA companies to provide support.

Having painted a negative picture, I need to provide some balance. The first is that SystemC is somewhat unique in that it provides the ability to directly integrate different models of computation into a single kernel and that is what they are doing here. Version 1.0 contained a type of dataflow engine and with the 2.0 release that has been extended to a Dynamic Timed Data Flow. This enables intelligent control of things such as the time step, rate or delay and that means greater efficiency. Modeling oscillators with variable frequencies (e.g., clock recovery) or capturing jitter is not possible when using constant time steps. In order to allow modeling of such systems, it is required to be able to change the time step continuously during simulation. So, it would appear as if SystemC-AMS has something to offer that the others don't have. Time will tell if that is important enough to the entire community.

However, I can't help but wonder if there isn't a better way. The DPI in SystemVerilog allows SystemC to be easily incorporated with little no performance penalty. If this is true (and please correct me if I am wrong) we should only need one set of AMS extensions to serve both environments. Within SystemVerilog it is also important that those extensions extend from the design part of the language into the testbench so that mixed-signal verification environments can be created and things such as coverage are equally extended to measure progress on all parts of the design.

I would love to hear the opinions of others but I certainly need to see some evidence to show that all of these are necessary and useful to the community.

9 comments on “Why Do We Need SystemC-AMS?

  1. amrutah
    April 12, 2013

    I feel, another problem is that the in case of reusability of some design, we have to port the model from one language to othe, since the customer would prefer a System C flow rather than the Verilog AMS flow.  Adding to a lot of confusion and wastage of time..

  2. BrianBailey
    April 12, 2013

    The original concept behind Ptolemy was a good one in that it allowed multiple models of computation (and thus languages) to be integrated together and the whole simulation extended at any time. I know that there were a few commercial adaptations of this but none that were successful – please corerect me if I am wrong on that. It still seems to me as if that was the right concept and not trying to cram everything into a single language.

  3. MartinB.
    April 12, 2013

    I do not understand the fuzz and your fustration of “yet another AMS language”. In the digital world we now have Verilog, VHDL, SystemVerilog and SystemC. The diversity started there. We all understand how history evolved and what the place is of these languages in the EDA eco-system. Would you really expect that for AMS extensions we can only have one definition, ignoring the fact that AMS at the system-level requires different triggering and synchronization schemes than AMS at the Verilog-AMS level?

    And to be clear, SystemVerilog-AMS does not exist. Sure, we had the SV-DC initiative, defining some discrete-type modeling features into the latest release of IEEE1800, but there is nothing related to analog, continuous-time modeling in SystemVerilog. And ever tried to pass an array of reals (from a sampled analog waveform, because there is no better way in SV) via the DPI to the SystemC/C++ world, to perform some smart signal processing? The DPI is far from perfect and complete to act as foundation for AMS signal processing and analysis.

    The SystemC AMS concepts are more than 10 years old, and were developed since there was a clear industry need to have AMS extensions based on C++, not because there was a European project. European projects offered a platform to get industrial partners together to further consolidate all requirements, use cases and work together on an API to develop a proof-of-concept.

    And the fact that reference implementations kill EDA business is incorrect. When published under the right license regime, EDA vendors can simply take the code and make it part of their commercial product. It allows them to focus on the right things: make it easy-to-use, offer smart GUI, waveform, tracing and debug integration, etc.

    Sorry to say, but I regret you negative attitude on the value of SystemC AMS and your belief there are better solutions out there…because they are simply not there. And Europe knows that already for more than 10 years.

  4. BrianBailey
    April 12, 2013

    I think you misunderstand me a little – I am not against SystemC-AMS, I am against the proliferation of languages – be they digital or extensions into the analog realm. I am also not suggesting that DPI or anything else is as good as it could be – I am suggesting that it is a shame that we have not invested the time and attention into the ceoncepts put forward by Ptolemy (or alternative) that would make everything work together better than they do today. Even in the digital world we are suffering because of the proliferation. I would ideally like to see one digital language (with multiple levels of abstraction), one analog language (also with several levels of abstraction) and perhaps other languages that address other physics and to have a standardized way of making them operate together. Allow vendors to compete on the algorithms to execute the languages and the optimization of the communications between them.

    I also wish that when langauges and interfaces were defined that they would consider synthesis semantics as well as simulation semantics. So many times progress has been slowed by the deifnition of langauges for only one purpose when the industry has at elast two purposes for them. Take TLM as an example today. We should be able to use this to communicate between models of different types and abstractions, but models that support this cannot be synthesized because of the way in shich it was defined.

    Now as to open-source and EDA investment – I think the state of the industryt speaks for itself. Yes – they have integrated SystemC, but they do not put the same dollars into – as an example – optimizing its execution as they do for Verilog/VHDL.


  5. Sumit Adhikari
    April 13, 2013

    I am glad that you asked. Let me give a try.

    Your comment “So, now we have Verilog-AMS, VHDL-AMS, SystemVerilog-AMS, UML-MS and SystemC-AMS” is like you pay same price for beef and chicken. But I do not. Because I undersatand abstraction and value it. SystemVerilog-AMS is surely a dream and I am not sure if you need something called UML-MS explicitely or you want that, I underatsnd that, but all others are meant to cater different levels of abstraction.

    Here are the levels :

    • SystemC-AMS + SystemC-TLM 
    • Verilog(or VHDL)-AMS + Verilog (or VHDL)

    SystemC class of libraries provides a solution to design architecture using data flow design philosophy, which is appropriate for architecture design. Whereas, Verilog/VHDL languages describes behaviour of hardware – practically they use event based simulator in digital domain and a conservative non-linear solver in analog domain. If I do not have SystemC-AMS, I have only one option – co-simulate SystemC-TLM + SW models with Verilog(or VHDL)-AMS models!, which is clearly:

    • Choosing wrong abstraction levels for simulation.
    • Co-simulation during architectural design process – How bad is that ?
    • Digital + SW all written in C/C++ and analog is written in some other language!
    • We are architects and we love C/C++.

    So, you see, introduction of SystemC-AMS is not “yet another AMS language”, rather it is an appropriate introduction of a missing abstraction level. So, as an answer to your statement “but what a mess we are creating”, they are not creating mess, they are giving appropriate solutions to solve immediate industry issues. “poor EDA companies” – that must be a joke, I take it as a joke. EDA has to adopt to the embedded thinking. They have to think how to change their business model to address the embedded world. “At present, there appeared to be little market interest outside of Europe” – I do not think so, and indeed, time will tell us. “So, it would appear as if SystemC-AMS has something to offer that the others don't have” – there is no other language which caters the abstraction of SystemC-AMS and hence this is a wrong statement. “However, I can't help but wonder if there isn't a better way. The DPI in SystemVerilog allows SystemC to be easily incorporated with little no performance penalty.” – Positioning SystemVerilog (with its basic DPI) in the center of the EDA universe is not the solution. Its semantics inherited from the HW domain makes it absolutely not suitable as (embedded) system language. Let's not call this the next language war, but respect the place of each language in the EDA eco system, and its users, instead.

    I want to know if “poor” EDA companies have very clean interfaces, what is the problem in interfacing with SystemC-AMS ?

    I see you have beginners hick ups on understanding the power of SystemC AMS and its role in the design cycle. There is an appropriate place in Accellera forum, called “SystemC AMS (Analog/Mixed-Signal)”, that's a great place to get your confusions corrected – I suggest you use that.


  6. Netcrawl
    April 13, 2013

    Well the company claims that SystemC AMS 2.0 standard fulfills the need of the electronics industry-  a standard system-level modeling language for mixed-signal applications. Did its really fulfills the industry's need? The problem here is compatibility because some designs need to be port from one platform to another one, and they need to work smoothly ( to yield a better results) but it seemed that the whole things has just adds to tech complexity and market confusion.  

  7. DKC
    April 14, 2013

    [copied from LinkedIn]

    I can understand your doubts Brian, there are a few things claiming an AMS badge that don't deserve it, not to mention there is no SystemVerilog-AMS. VHDL-AMS is really two languages under one standard with little attempt at integration, and Verilog-AMS is a good AMS language, and should have been developed for power management in digital flows and the like, but Cadence have hobbled it (and charge a lot too), so it has been left doing much the same work as Spice.

    So SystemC-AMS is (maybe) an attempt to break free of the shackles of the big EDA companies and standards committees to offer users something that no other languages cover. However, when it comes to digital, SystemC is rife with bad abstractions, and the language itself (C++) has no native support for either math (as needed for analog) or fine grained parallelism needed for hardware description.

    The competition for SystemC-AMS is probably more Matlab than any of the HDLs, but I have not had need to work at that level myself. However, should anyone want to fix this mess of languages and bad abstractions, I think it's more likely it will happen with C++ than any of the other languages currently in use.

  8. DKC
    April 16, 2013

    I think you are correct in that the proliferation is bad if it just replicates other stuff. A lot of what is in SystemVerilog could be done (better) in C++ and there was a distinct lack of clean-up in absorbing Vera into SV such that it would be synthesizable.

    I've spent plenty of time on developing better abstractions, but generally folks on language committees don't seem to want new abstractions. Two I remember from SV were:

    1) data channels – for self-timed FSM descriptions, which gets you above RTL

    2) assertion timing – modified sensitivity operators

    – (2) was something like using @-(clock) to trigger blocks before the @(clock) for assertion checks, instead there's some horrendous clock stratification scheme.

    I implemented versions of those in my extended C++ (ParC –, and it is intended to be a single language that goes through the whole stack down to Spice level (which no language does well as yet – VHDL could, but…).

    BTW C++ added physical units in its latest version – (page 19)

    – so you can see C++ is still under development. However the boost threading model was the wrong way to go.

    The EDA companies may be optimizing the hell out of VHDL and Verilog simulators, but they have not changed the simulation paradigm in 20 years, so I think they have become wedded to some outdated approaches whose use-by date is up.



  9. SunitaT
    April 16, 2013

    Its commendable that EDA companies are coming up with new solutions for the issues faced by the design and verification teams. But with this new development, issue of rework comes up. Design development/verification setup developed for one project(which is generalised to use in future project) can be resued in SystemC-AMS setup. Is SystemC-AMS portable enough to reuse the previous work? for example can the verification setup developed using SystemVerilog_AMS reused in SystemC-AMS setup?


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.