Posted by mike demler on November 19, 2008
This is a follow up to comments on my post AMS assertions… a violation of “the 10 commandments”?
I think that defining an interface between Verilog-AMS and SV is exactly what is needed. But, instead of doing that, the Accellera committee is trying to define a new “merged” language that can translate analog signal properties into the digital property syntax of SV. This effort fails to understand that what may be an interesting exercise academically does not necessarily equate to the best (or even a viable) solution for the real world.
There are two simple facts that frame this problem.
So how should analog meet digital here? If you try to (syntactically) put analog instrumentation in the digital checker it’s pointless, because the execution still must be performed by an analog engine. (Hence all the examples with “special functions”).
In a real-world solution, it makes much more sense to utilize whatever instrumentation fits in the analog engine to test analog properties, rather than obscure that reality in a new language that must be parsed and elaborated for execution in the analog engine anyway.
We can easily communicate boolean values from analog property checkers to SV through a co-simulation interface. A rough implementation of that has already been demonstrated by IIT Kharagpur in their research project “Instrumenting AMS Assertion Verification on Commercial Platforms”.
My proposal is this: create an “AMSproperty” command to complement the current digital “property” functions in SV. Consider this…
The property types would match those in a taxonomy of analog properties. I firmly believe that my taxonomy is a more viable starting point than where this activity sits today, but I would be more than thrilled to see one that represents a consensus of a cross-functional industry committee.
In an integration of analog engines (SPICE, FastSPICE, whatever… with or without Verilog-AMS) with SV, as in the IIT example, parsing of a netlist with an AMSproperty would immediately invoke functions that the analog engine understands. No new language required!
Furthermore, this solution would enable complete coverage of all the property types in the analog taxonomy, which the current SV-constrained discussion does not address. EDA vendors could then build interfaces to whatever analog tool best fits with the properties being checked, and not be limited to time-domain simulation.
Let’s develop a solution that fits the problem, rather than the other way around!