1 / 44

Developing and Releasing Compact Models Using Verilog-A

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 Meeting Dec 13, 2008, San Francisco. Outline. Some motivation and background history

nuri
Download Presentation

Developing and Releasing Compact Models Using Verilog-A

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related