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 1990’s • 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 => resistive q => reactive (inductors, capacitors) u => 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) <+ 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) <+ 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) <+ x * ddt(x); introduces extra state variable phi, phi - ddt(x) == 0 to effectively contribute x*phi which fits into the f(x(t)) + ddt(q(x(t))) form. • Should be avoided in compact models. 

21. Branches from Conditionals if (Vds < 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) <+ t0; I(b,si) <+ t1; • When variables that depend on ddt() are used in conditionals, the compiler must create extra branch equations Typical MOSFET code

22. Avoiding Branches from Conditionals if (Mode == 1) begin t0 = TYPE * Ibd; arg0 = Qbd; t1 = TYPE * Ibs; arg1 = Qbs; end elsebegin t1 = TYPE * Ibd; arg1 = Qbd; t0 = TYPE * Ibs; arg0 = Qbs; end I(b,di) <+ t0 + ddt(arg0); I(b,si) <+ 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(<port_name>)); • 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 > 0.0) I(c, ci) <+ V(c, ci)/Rc; else V(c, ci) <+ 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: <unnamed>(b, di) : Current Branch (implicit) <unnamed>(b, si) : Current Branch (implicit) <unnamed>(di, d) : Statically shorted branch <unnamed>(di, si) : Current Branch (implicit) <unnamed>(g, di) : Current Branch (implicit) <unnamed>(g, si) : Current Branch (implicit) <unnamed>(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 • Compile with flag • Simulate • 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 AREA=Area;

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