The Designer's Guide Community Forum

The Designer's Guide Community Forum
https://designers-guide.org/forum/YaBB.pl
Simulators >> AMS Simulators >> Case/If Statements in VerilogA
https://designers-guide.org/forum/YaBB.pl?num=1210435810

Message started by Stefan on May 10^th, 2008, 9:10am

Title: Case/If Statements in VerilogA
Post by Stefan on May 10^th, 2008, 9:10am

Hi,

does anyone know how the cadence (spectre) or any other spice-like simulator does handle if/case statements in verilogA during simulation ?
Does it affect the definition of convergence of the matrix?
The typical Raphson-Newton does not include those statements in its simulation description.

Regards,

Stefan

Title: Re: Case/If Statements in VerilogA
Post by sheldon on May 11^th, 2008, 7:39am

Stefan,

It really depends on what you are doing with the conditional statements. There
used to be Verilog-A modeling best practices class at the Cadence User Meeting,
by Ron Vogelsong. Included in the class was some discussion of this issue. BTW,
this material should also be included in the Verilog-A training class, I think it is in
the, "Analog Modeling with Verilog-A" class.

To more directly answer your question, yes, conditionals can be challenging for
simulators so model developers need to carefully consider the potential effect of
a conditional on a model's convergence. You might want to compare, the sw cell
from ahdlLib with the sw_no cell from bmslib. In general, my experience is that
simulating with the sw_no is faster and better behaved. Also, the effect of the
conditional may be dependent on how the block is used. For example, using an
if/then based inverter, inv cell from bmslib, for control logic is usually not an issue.
However, using the inv [bmslib] and sw [ahdlLib] to build build an auto-zeroed
comparator, then the there will serious convergence issues. This point can be
an issue because designers sometimes misunderstand how to effectively use
behavioral modeling. When using behavioral modeling, just replacing the existing
blocks with "ideal", behavioral, equivalents is not always the best approach. In the
case of the auto-zeroed comparator, instead of using ideal elements, a better
approach would be "raise the level of abstraction". Writing a black box model for
the comparator, sample the input when the clock is high, subtract the reference
from the sampled input, amplify, and output when the clock is low, works well.
When modeling a flash converter with auto-zeroed comparators, the simulation
time was reduced from days, "ideal" components, to minutes, black box model.
Yet, both simulations relied on using conditionals. BTW, a little more explanation
on the comment about switches. When simulating sample-and-holds, grounded
back-plate, etc., the "sw_no" switch is faster and better behaved. The "sw"
maybe better when simulating muxes but I have never tried it.

So my two cents worth is that using conditionals in general is not a problem,
however, there are caveats that you need to aware of. For example, avoid using
conditionals to model continuous behavior. I'm sure there are others but I will
leave that for others :-)

Best Regards,

Sheldon