Posted by mike demler on December 22, 2008
My recent post on AMS Verification at ICCAD has generated some detailed comments, which provide great opportunities for continuing the discussion. My response is somewhat overdue, so let’s begin with this 1st comment from Martin, who is associated with the System-C AMS initiative.
In response to my statement that “A hierarchical verification methodology is the only way to go for complex, high-performance mixed-signal SoCs” Martin said:
Gluing tools together (hierarchically or not) is probably not the solution for this problem, as this will introduce fuzzy inter-tool communication (example: co-simulation between tool ‘A’ and ‘B’). What we need is a transparent design flow to support a (top-down) design refinement methodology, complemented with bottom-up verification elements. As soon as the methodology becomes clear, we should _not_ start a discussion on tools, but first look at the modeling language: which language is most suitable to do the job? Is there any? Today’s complex AMS systems are not just a bit of analog transistors and some RTL; it’s about having digital HW/SW and AMS subsystems that interact. This is one of the main reasons why the SystemC AMS extensions are being standardized.
Martin, I hope you did not think I was suggesting “gluing” together tools. In fact, I said quite the opposite in my 2nd statement that “EDA vendors need to focus more attention on flows, not just point tools“. I’m not exactly sure what you mean by a “transparent” design flow, but I absolutely agree that the challenges of AMS design and verification (the two activities being more inseparable than in digital) must be addressed from a complete top-to-bottom flow perspective and not just as a pursuit for better point tools.
The first problem though, is in the definition of any “one-size-fits all” methodology. Are you suggesting that one methodology could be developed across the EDA and semiconductor industries, that would cover all types of AMS/RF SoCs? I think that it would be unrealistic to expect that such a methodology could be created, and/or that customers would ever give up on their internal processes and proprietary methods. However, I believe that a set of best practices for a comprehensive set of relevant prototype circuits is sorely needed. What a waste it is for each company that designs ΣΔ ADCs, for example, to develop a verification methodology from scratch.
But this begs a lot of questions. EDA vendors generally do not possess the design domain expertise to develop such methodologies, and those EDA vendors that have invested in AMS methodology services and packaging of AMS verification IP have struggled to get customers to pay for them. I think that the only practical answer is to elevate the practice of AMS verification through collaborative industry efforts, so that we can develop and publish more best practices. Digital verification has been elevated to this level, but AMS is lagging.
You then propose that we should not “start a discussion on tools, but first look at the modeling language“. I have been active in the current Accellera discussions on defining a language for assertion-based AMS verification, and going further back I was involved in the early development of Verilog-AMS. There is a very significant difference in how these two efforts originated. In the case of Verilog-AMS, it started with efforts to standardize Verilog-A, which was based on commercial development of a tool and language for analog behavioral modeling by Cadence. In the case of AMS assertions there is no commercial implementation of even a first prototype, just a general consensus on the need to merge some functionality of System Verilog with Verilog-AMS.
Even if the EDA industry was not under such severe economic stress as it is today, the notion of developing a standardized language before there are tools upon which to run it is naive. It is unavoidable – a language is just the user interface for driving the tools. Academic exercises belong in academia. EDA and semiconductor companies are in business to make money. What is the point of developing a language without considering implementation requirements at the same time?
However, I am personally not very familiar with the System-C/AMS effort, as it is mostly a European initiative. How are users and vendors collaborating on that project?