Posted by mike demler on February 28, 2008
The second paper from the Analog/Mixed-Signal Verification session at DVCon-08 was presented by Jeff McNeal of Synopsys’ Intellectual Property Solutions Group:
7.2 Methodology for Modeling Analog Circuits Using Behavioral Verilog
Chris Jones, Jeff McNeal – Synopsys, Inc.
The work that was described in this presentation also addressed the problem of verifying the interaction between digital and analog circuits in mixed-signal designs (as in the 1st paper: Thomas J. Sheffler Functional Verification in the Presence of Linear Analog Circuits), but went further by describing a comprehensive methodology to integrate synthesized and custom digital blocks as well as the interaction between analog modules that communicate across different levels of a chip’s hierarchy.
The verification methodology described here can itself be thought of as hierarchical, since it employs progressive refinement from higher level behavioral models all the way to transistor-level circuit models (for analog blocks) as a design proceeds from the top-level architectural definition through implementation and signoff. The Verilog PLI is also used extensively in this verification flow, with analog behavior represented by a small library of primitive functions that convert (to or from) real-number variables that are assigned to represent voltage or current values on digital wires. Here is an example from the author’s paper at last year’s DVCon (ref: C. S. Jones, J. McNeal, and R. Segelken, “Sending Analog Values Along Digital Wires”, DVCon 2007) of a PLI function to convert a real-number variable to a value on an output net:
In the earlier paper by Sheffler, the objectives for the analog behavior to be modeled were simpler – representing the conversion of a digital control word to an analog voltage. There is a requirement to model higher level analog/mixed-signal functions in the methodology described in this paper, so rather than solve for DC voltages and currents Verilog behavioral models are used to directly calculate analog values, such as in this example of a DAC (also from the same author’s paper at DVCon 2007):
The paper provides a comprehensive set of rules for applying this verification methodology, which I won’t go into here, but I highly recommend getting a copy if you are interested in more details.
Once again; this paper provides another alternative for modeling the type of mixed-signal behavior that Verilog-AMS was developed for. To be fair; the Verilog-AMS language provides the capability to model much more elaborate analog and mixed-signal behavior, but that analog behavior must be calculated by a SPICE engine. Developing Verilog-AMS models is a difficult skill to master, and it is easy to create a model that is functionally correct but is bad in terms of how it affects simulation performance.
It is also apparent that for purposes of functional verification, at least in these examples of D/a designs, the event-driven approach controlled by a digital simulator is sufficient. It is also clear that the simulation performance during verification is of utmost importance when Analog meets Digital. Of course, much verification time is still consumed outside of this flow, by the analog block designers running SPICE and Fast-SPICE.
One obvious problem with any hierarchical verification methodology is how to check the behavioral models against the actual circuitry. In many cases the models are checked manually, and the assumption is that the analog designers have sufficiently verified their transistor-level blocks. I like that the methodology presented in this paper is more robust, because co-simulation of Verilog with Fast-SPICE is used as the final sign-off verification. The authors point out that judicious use of co-simulation is a requirement for catching subtle model mismatches, and is considered a necessity to increase confidence before tapeout.
Have you used SPICE or Fast-SPICE co-simulation with Verilog or VHDL? What about Verilog or VHDL AMS extensions? Are AMS behavioral modeling languages useful, or do they just slow down digital simulations?
I’m looking forward to your comments.