This year's DVCon session on Mixed-Signal Design and Verification included three presentations:
- Validating WiMAX OFDMA Using SystemVerilog and VMM
- Albert Chiang, Wei-Hua Han
- Synopsys, Inc.
- Synopsys, Inc.
- Bhanu Kapoor of Mimasic
- A SystemVerilog Approach for Analog/Mixed-Signal Verification
- Shyam Rapaka, Tapan Halder
- Verification Group, Synopsys Inc.
- Verification Group, Synopsys Inc.
- Vikas Chandra ARM R&D
- Get to ASICs Faster - A Novel Mixed Signal Design Methodology
- Dr. Greg Tumbush
- Tumbush Enterprises
- Tumbush Enterprises
- William Gonnason, Dustin Griesdorf , Alaa El-agha, Gareth Weale, Marc Matthey, Andreas Drollinger
- ON Semiconductor
- ON Semiconductor
- Holger Meiners
Paper #2
The authors of "A SystemVerilog Approach for Analog/Mixed-Signal Verification" go well beyond the application of System Verilog (SV) features in Paper #1, by showing an example implementation of an SV test bench with a SPICE DUT for true mixed analog-digital verification.
A four-bit flash ADC, which may (deceptively) appear to be the simplest form of analog-digital converter, is used as an example AMS circuit in this paper. In actuality, testing a flash ADC is much more complex than the example shown, but the concepts used are interesting nevertheless. (Self-serving advertisement: For more on real test and verification procedures for flash ADCs see my book "High-Speed Analog-to-Digital Conversion". J).
The Synopsys methodology is based on a mechanism they developed "for interleaving SystemVerilog and SPICE with direct connections using ports". Previous authors have described using SPICE-Verilog co-simulation to send real values over wires through PLI 2.0, but the authors claim that their approach is superior, since it enables SPICE subcircuits to be directly instantiated in SV testbenches. SPICE subcircuits can also instantiate SV checker modules, allowing the use of SV assertions.
SPICE circuit nodes can connect to either wires or real-valued ports. As in all Verilog-AMS implementations, analog connections to digital wires require automatic insertion of converters at the digital/analog
boundary. Driving and sensing of SPICE node voltages is enabled through direct connection to real ports. SV checker modules can then contain both real and wire ports. This appears to be a proprietary implementation, and several questions arose regarding the use of wreal, which is not supported in SystemVerilog.
In the ADC example, SV provided the input stimulus for Vin and CLK, and an analog clock was generated specifically to trigger SV monitors of the ADC outputs. An SV initial block is used to generate piece-wise constant (not PWL as the authors claim) inputs. In referring to the use of SV to define the stimulus, the authors also erred in asserting (excuse the pun) that there "is no such provision in SPICE to represent such recurring patterns in a succinct manner". It may be a matter of taste, but the SPICE PWL function is pretty succinct in its use of time/voltage pairs to define transitions. SPICE also provides for the specification of transition time, which SV cannot easily do without the use of finer granularity through many delay statements. Further, HSPICE and other SPICE simulators have the 'R' repeat parameter as part of PWL sources, which is quite succinct.
The more interesting aspect of the SV-SPICE example is in the use of checker modules, where expected behavior of the ADC comparators is tested using SV assertions.
assert (((cmpOut > 0.9) && (Vin > Vref)) ((cmpOut < 0.9) && (Vref > Vin)))
A compiler directive is used to display messages regarding Pass/Fail conditions during simulation. In many respects this example is similar to the use of Verilog-AMS "assertions" that has been proposed by Henry Chang and Ken Kundert at Designer's Guide. (see Top-Down Design and Verification of Mixed-Signal Circuits). The SV-centric approach would be a good fit with "digital on top" verification, and obviously is a better fit with current digital verification methodologies. (Though discussions of the merger of SV and V-AMS are underway).
This paper is also interesting for the limitations and challenges it reveals when one considers how to bring continuous-time analog behavior in to a discrete-time digital verification environment. I think the most important question is, after you adapt to make analog fit into digital (see Square Pegs and Round Holes), is the verification worth doing? The example shown in this paper would show us that yes, we have a 4-bit ADC and it is hooked up right. There is certainly some value in that, but it's still only one small piece of a full AMS SoC verification where a circuit like this might be used. Those challenges are being address by the Accellera AMS Assertions Requirements Gathering Group. You can follow the link to check out the latest status of the discussion on the group's twiki site.
-Mike
2 comments:
Mike,
this was the paper that fed the nightmare that woke me up this morning..
Interleaved SPICE and Verilog. Ugh!
Now, don't get me wrong, I want the SPICE functionality in my Verification simulator.. And I'm sure some vendors will find a few designers who practically think in SPICE, who will approve spending $$ for this feature.
But for my part, I think that some of the roots of SPICE are fairly incompatible with a robust verification language like Verilog, and Verilog is Quite adequate to specify the same structural interconnections that a spice netlist does, with the added benefit, (and I think this is key) of not only staying in the same language, but being able to use EXPLICIT connections.
I'd much rather see
rpolywo #(.r(10K)) R101 (.pos(net1), .neg(net2), .bulk(AGND);
as compared to
R101 10K net1, net2 $sub AGND model="rpolywo"
Anyway, thanks for the highlights, I'll be going back to look at these papers as soon a possible, to see If I can glean anything useful from them.
Jonathan
Hi Jonathan,
I think some of the "language geeks" (and I use the term affectionately :-)) may disagree about Verilog being robust.
Nevertheless, a few thoughts on your preference for Verilog:
1) It allows but does not require explicit node designations, so you would need to enforce a discipline in all netlist creation. That's not so robust.
2) Does Verilog have any notion of electrical terminal interchangeability? In analog, many device terminals are interchangeable electrically (e.g. the R1/R2 terminals, D/S on MOSFETs, etc.).
So, I miss the point about wanting explicit device terminal designations when they often have no meaning electrically. The simulator must be able to swap them anyway in order to perform the proper calculations of the behavior of a particular device instance. Isn't that also a requirement for LVS? Do you want explicit node designations on the layout?
Post a Comment