The Designer's Guide Community
Forum
Welcome, Guest. Please Login or Register. Please follow the Forum guidelines.
Jul 17th, 2024, 11:37am
Pages: 1
Send Topic Print
Case/If Statements in VerilogA (Read 5117 times)
Stefan
Senior Member
****
Offline



Posts: 124

Case/If Statements in VerilogA
May 10th, 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
Back to top
 
 
View Profile 16731287   IP Logged
sheldon
Community Fellow
*****
Offline



Posts: 751

Re: Case/If Statements in VerilogA
Reply #1 - May 11th, 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 Smiley

                                                                Best Regards,

                                                                   Sheldon
Back to top
 
 
View Profile   IP Logged
Pages: 1
Send Topic Print
Copyright 2002-2024 Designer’s Guide Consulting, Inc. Designer’s Guide® is a registered trademark of Designer’s Guide Consulting, Inc. All rights reserved. Send comments or questions to editor@designers-guide.org. Consider submitting a paper or model.