Developing and Releasing Compact Models Using Verilog-A

1
Developing and Releasing Compact Models Using
Verilog-A 

• Marek Mierzwinski, Patrick O'Halloran, and Boris
  Troyanovsky
• Tiburon Design Automation Santa Rosa, CA

1st International MOS-AK MeetingDec 13, 2008,
San Francisco
2
Outline

• Some motivation and background history
• Implementation issues
• Performance
• Debugging
• Practical considerations in distributing models
• Future directions/Conclusions

3
Compact Model Distribution
Model extracted
Design verified
Model and simulation flow verified
Independent implementations
4
Motivation

• Compact model development is challenging
• Adding new models to circuit simulators can prove
  just as challenging
• Proprietary (non-portable) interfaces
• Limited capabilities
• Burden on model developer to
• hand-calculate derivatives
• write analysis-specific code
• handle software engineering details

5
Motivation (cont.)

• Analog Hardware Description Languages (AHDLs) can
  provide important benefits
• Ease of development
• Model portability
• Across different simulators
• Across various analysis types
• Suitable for full range of model types
• Behavioral level down to transistor level

6
Why Verilog-A

• Natural language for compact model development
• Succinct
• derivatives, loads all handled by compiler
• simple parameter support
• Standard
• Implemented in most simulators

7
History

• Verilog-A is a precisely defined subset of the
  Hardware Description Language, Verilog-AMS
• Development overseen by OVI/Accellera
• late 1990s
• Active effort to merge with SystemVerilog

8
Barriers to Adoption

• Performance
• Important for transistor-level models
• Must eventually be comparable w/ built-ins
• Compact modeling constructs
• Greatly improved with v2.2 language standard

9
Barriers to Adoption (Cont.)

• Inertia
• Misconceptions regarding language capabilities
• Existing code base of non-AHDL-based device
  models
• Lack of familiarity within model development
  community
• Lack of comprehensive debugging/development
  methodology

10
Overcoming the Barriers

• Performance
• No theoretical reason for Verilog-A to be
  inferior in performance to built-ins
• Availability
• Verilog-A now supported by virtually all major
  commercial vendors
• Support for all analysis types, e.g. transient,
  harmonic balance, shooting, nonlinear noise.
• Advanced features
• noise
• paramsets

11
Overcoming the Barriers

• For the user
• End user experience must be as good as or better
  than using existing model distribution method

12
Existing Models

• Most compact transistor models have been
  implemented in Verilog-A
• BSIM3, BSIM4, BSIM5
• SPICE Gummel-Poon, diode, MOS1, MOS3, pTFT, aTFT
• NXP MEXTRAM 504, MOS Model 9/11
• PSP (Penn State/NXP MOSFET)
• EKV
• HiCUM Level 0/Level 2, VBIC, VBIC, FBHBT
• Parker-Skellern, Angelov, Curtice, TOM MESFET

implemented by developers
13
Writing Compact Models
Excellent primer on implementing compact device
models in Verilog-A
www.bmas-conf.org/2004/papers/bmas04-coram.pdf
14
Performance

• Model can have a big influence
• execution speed
• memory use
• Choice of particular constructs can result in
  performance degradation
• Avoidable state variables

15
Nodal Analysis

• f(x(t)) ddt(q(x(t))) u(t)
• f gt resistive
• q gt reactive (inductors, capacitors)
• u gt current sources
• For a hypothetical circuit with current sources,
  resistors, capacitors
• x is vector of voltages, all the equations are
  standard KCL, and so PURE NODAL ANALYSIS.

16
Voltage Sources in Verilog-A

• However, if we have a voltage source
• V(a, b) lt K
• this necessitates adding an extra state variable
  "I" (the flow through the source) into the x
  vector, with the corresponding extra equation
  branch
• xa - xb K
• ( or in reality -xa xb K 0 )

17
Inductances

• Similarly, inductances in Verilog-A also add an
  additional state variable
• V(a, b) lt L ddt(I(a,b))
• translates to
• - xa xb ddt(L Iab) 0
• where Iab is the flow through the inductor.

18
Performance Impact

• Extra equations introduced from
• Voltage contributions on the left-hand-side, or
• Current access on the right-hand side
• Result extra state variables impact efficiency
  for compact models.
• Work-around Use current contributions, avoid
  unnecessary current probes

19
Branch-ddt Equations

• Branch-ddt equations are state variables related
  to implementing ddt() equations
• How they arise  
• From the basic nodal KCL
• f(x(t)) ddt(q(x(t))) u(t)
• Note that it does not support terms of the form
• g(x(t))ddt(h(x(t)))

20
Branch-ddt (cont)

• The Verilog-A code
• x V(a, b)
• I(a, b) lt x ddt(x)
• introduces extra state variable phi,
• phi - ddt(x) 0
• to effectively contribute
• xphi
• which fits into the f(x(t)) ddt(q(x(t))) form.
• Should be avoided in compact models. 

21
Branches from Conditionals

• When variables that depend on ddt() are used in
  conditionals, the compiler must create extra
  branch equations

if (Vds lt 0.0) Mode -1 // Inverse
mode else Mode 1 Qbd_ddt
ddt(Qbd) Qbs_ddt ddt(Qbs) if (Mode 1)
begin t0 TYPE Ibd Qbd_ddt t1
TYPE Ibs Qbs_ddt end else begin t1
TYPE Ibd Qbd_ddt t0 TYPE Ibs
Qbs_ddt end I(b,di) lt t0 I(b,si) lt t1
Typical MOSFET code
22
Avoiding Branches from Conditionals
if (Mode 1) begin t0 TYPE Ibd
arg0 Qbd t1 TYPE Ibs arg1
Qbs end else begin t1 TYPE Ibd
arg1 Qbd t0 TYPE Ibs arg0
Qbs end I(b,di) lt t0 ddt(arg0) I(b,si) lt
t1 ddt(arg1)

• Place the arguments to ddt() in the conditionals

Improved MOSFET code
23
Probing Mistakes

• Common mistake when probing port current
• strobe(I(port_name))
• Introduces unnamed branch
• Effectively shorts port_name to ground
• Adds additional state variable
• Instead use
• strobe(I(ltport_namegt))
• Easily detected at compile-time

24
Superfluous Assignments

• Consider
• (10) x V(a, b)/R(11) if(type 1)(12) x
  V(a, b)/R1(13) else(14) x V(b, a)/R2
• Diagnostic message from compiler
• Warning Assignment to x may be
  superfluous. filename.va, line 10

25
Memory States

• Variables are initialized to zero on first call
  to module
• The simulator retains the value between calls to
  module
• If used in assignment before it is assigned, it
  will have the value of the previous iteration
• Also known as hidden states
• Compact models should not use them
• could cause unexpected behavior

26
Collapsible Nodes

• Native models can remove or collapse unneeded
  nodes
• Common idiom for collapsible nodes if(Rc gt
  0.0) I(c, ci) lt V(c, ci)/Rc else V(c, ci)
  lt 0.0 // if not collapsed, adds state
  variables
• Implementations may treat as
• Collapsible node, or
• Switch branch
• Informative diagnostics should be issued

27
Performance Summary

• Be aware of what causes extra equations
• Collapse nodes when possible
• Watch out for
• memory states
• superfluous equations

28
Debugging

• Basic
• strobe outputs every converged iteration
• debug outputs every call to module
• Use macros to disable in general use
• ifdef DEBUG
• Compile time diagnostics
• Compiler flags for runtime
• Too expensive for production code
• Very useful during development phase
• Iteractive debugging

29
Compile-Time Diagnostics

• List of state variables
• List of branch types
• Voltage- / Current- / Switch- Branches
• Collapsible nodes
• Memory states
• Superfluous assignments
• Unused variables
• Floating nodes

30
Diagnostics (cont.)

• Check for addition of extra state variables
• Probing current through a branch
• Voltage branches
• Switch branches
• In many cases, not necessary/desired for compact
  modeling
• Invisible to developer unless diagnostics are
  issued

31
Diagnostics (cont.)

• Compiler output

Summary information for module
'mos3_va' Branch information
ltunnamedgt(b, di) Current Branch (implicit)
ltunnamedgt(b, si) Current Branch (implicit)
ltunnamedgt(di, d) Statically shorted
branch ltunnamedgt(di, si) Current Branch
(implicit) ltunnamedgt(g, di) Current
Branch (implicit) ltunnamedgt(g, si)
Current Branch (implicit) ltunnamedgt(si,
s) Statically shorted branch Branch ddt
operators line 685, col 15
line 686, col 15 Potential memory states
'Arga' 'Argb' 'Beta_T'
'CdOnCo' 'CsOnCo' 'Delta_L'
'Fermig' 'Fermis' 'Kappa'
'Vgst' 'Wkfng' 'Wkfngs'
End of summary information for module 'mos3_va'
32
Compiler Flag Example

1. Compile with flag
2. Simulate
3. Simulator runs until floating point exception
   occurs

33
Interactive Debugging

• Allows quick iterative investigation of module

34
Portability Across Analysis Types

• Certain language constructs are not supported by
  RF analyses (e.g, Harmonic Balance, Shooting,
  Envelope)
• Should be avoided for reasons of
• portability
• consistency across analyses
• efficiency
• Typically not required (or desired) for compact
  models

35
Additional RF Restrictions

• Explicit use of time abstime
• Analog Operators
• Allowed
• Differentiation ddt(), ddx()
• Delay absdelay()
• Laplace laplace()
• Integration idt() without initial conditions
• Others are
• Not safe for RF analysis
• Not (typically) useful for compact modeling

36
Model Distribution

• Complete model support requires
• model version control
• schematic capture information
• simulator dependent
• End-user experience
• easy installation
• look and feel of native device
• instance/modelcard
• multiplicity

37
Parameter Case

• Verilog-A is case sensitive
• Some simulators are case sensitive, others are
  not
• Provide aliases
• aliasparam AREAArea

38
IP Protection

• Compiled libraries effectively hides source code
  as well as built-in models
• Model parameters can be hidden in source code
  by assigning them as default values

39
Example ADS

• Design Kits provide a convenient mechanism for
  distributing complete model package
• End user opens a zipped file

40
Example
Users have a one-step process to install model
41
Example
Users see no difference when using Verilog-A
implemented models
42
Future Directions

• Tools for improved model development
• Automatic checking of smoothness, continuity,
  etc.
• Automated checks for passivity / stability / etc.
  where appropriate

43
Conclusion

• Continued growth and adoption of Verilog-A
  presents numerous benefits for
• Compact model developers
• Circuit designers
• Tool vendors
• Benefits include
• Portable, robust compact models
• Ease of development
• Fast model distribution and modification

44
(No Transcript)