Posted by mike demler on September 19, 2008
Great comments from Jonathan on yesterday’s post, so I will continue the discussion here as a new post so that RSS readers get the latest. Jonathan, thanks again for contributing to the discussion.
I do think that it’s important to start with as broad a scope as possible, to be able to put the assertion-based verification (ABV) idea into proper perspective insofar as the value it may (or may not) bring to AMS verification. What we have so far is an idea that originates in digital verification, which we know is a very different domain based largely on language-based design. The adoption rate for AMS languages has been very slow, when you consider that Verilog-AMS and Verilog-A were first developed over 10 years ago. So… at least to play devil’s advocate… I think it warrants questioning the applicability of the ABV concept in AMS. ABV has not had a broad exposure in the analog design community. Hopefully, this will at least contribute to increased mutual understanding across the analog-digital divide.
>I wouldn’t talk about the electrical properties of circuits.. ONLY of signals
We can narrow down the scope of the properties we wish to assert, but how do you define a “signal”? By the way, in digital ABV assertions are closely related to formal verification of functions, and there is some research underway for AMS formal verification as well.
Signal – a detectable physical quantity or impulse (as a voltage, current, or magnetic field strength) by which messages or information can be transmitted.
Maybe it would be more accurate to refer to states, and state variables. I found this example of a digital assertion in one of the papers I read recently:
Now, are “r1” and “g1” the state of some flag bits that change very infrequenly, or do they represent rapidly changing pulse streams? I can’t tell. All I know reading this assertion is that the state of “r1” being high requires that “g1” stays high for at least two more clock cycles. Another assertion might replace the two clock cycles with an “ALWAYS” qualifier. In power-gated designs, even the supply rails become “signals”. I see increased usage of circuit checking functions that act the same as assertions; to identify disallowed electrical states (e.g. floating nodes, leakage paths, overvoltage conditions, etc.)
> Dynamic (instanteous) – these would be characteristics that could be evaluated by a small signal type of analysis.. – or could be done over time, but otherwise not requiring specific relation ships in time..
– Gain, BW, CMRR,
Small signal, or AC analysis is done with a frequency sweep of linearized models. In my taxonomy I had a category for frequency domain properties, so I think large and small signal behavior would both go there.
> I suspect you are not seeing how many are using Verilog-AMS models in their simulations, as these models DO speed up enough to justify the costs, at least in some simulators, and I know very few companies who are NOT using these models,
I actually do see some increased usage of Verilog-AMS, which has subsumed Verilog-A at least in terms of a language standard. The increased usage is driven by the need for higher verification productivity. However, my perspective is of the entire simulation market for both analog and digital tools. If you look at the total installed base of simulators (SPICE, FastSPICE, A-HDL, D-HDL), A-HDLs represent the smallest segment. This ties directly into the motivation for AMS assertions; when verification signoff is owned by the digital team, they want something that fits into their methodology without incurring any performance degradation. An A-HDL model will always be slower than a digital model. Perhaps faster then SPICE or FastSPICE, or perhaps not… but always slower than digital.
> IOW, you don’t see many AHDL models because your customers know you can’t run the types of tools they do have.
Not sure which tools you are referring too, but we (Synopsys) do have customers making extensive use of Verilog-AMS in our FastSPICE-VCS co-simulation solutions.
>and lets be clear.. the spice syntax is STILL based on archaic punch card technology which is NOT used any more,
Making me feel old there. My very first circuit simulation was a punched card run of ECAP back at the University of Buffalo. Sooooo last century! 🙂
>so while I applaud the idea of extending .measure type capabilites, lets also move to a modern syntax – where I will say that verilog has it all over spice..
Yeah, I actually wasn’t suggesting extending .MEASURE at all, just trying to provide the digital folks with some historical perspective. I’m all for getting to a more rubust language standard, but I also personally went through the painful early development of a Verilog-A language that was driven more by arguments over syntax and competitive stall tactics, instead of being driven by what the designers needed. (For more on this, ask me about Antrim’s attempts to introduce the $table function sometime).