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.