Compact model standardization a GNU perspective

1
Compact model standardization a GNU perspective

• Paolo Nenzi - CNR-INFM
• Wladek Grabinski - GMC

2
Standard

• What a standard is ?
• a documented agreement containing technical
  specifications or other precise criteria to be
  used consistently as rules, guidelines, or
  definitions of characteristics, to ensure that
  materials, products, processes, and services are
  fit for their purpose.

3
Perspectives

• Actual
• The standard is the compact model.
• Not all candidates for a given technology are
  standardized.

• GNU
• The standard specifies the rules to develop
  compact models.
• The standard must be open.
• The compact model must be free.

4
Consequences

• Actual perspective
• The models are standards.
• First class models (BSIM, PSP) and second class
  models.
• Long delays in model release in circuit
  simulators.
• Lack of models for new or less common devices.

• GNU perspective
• Models conform to an open standard.
• All models are equals.
• Faster development and acceptance.
• Development of model for frontier devices (MEMS,
  etc.)

5
An Open Standard

• The GNU compact model standard should be open (as
  defined by OSI)
• No intentional secrets.
• Availability (publicly available, royalty-free).
• Based on royalty free patents.
• No agreements (NDAs, etc.) to deploy conforming
  implementations.
• No dependencies on non open technology (according
  to this definitions)

6
A free model

• The compact models should give the 4 freedoms
• The freedom to run the model, for any purpose.
• The freedom to study how the model works, and
  adapt it to your needs.
• The freedom to redistribute copies so you can
  help your neighbor.
• The freedom to improve the model, and release the
  improvements to the public, so that the whole
  community benefits.

7
Key points of the standard

• What should be standardized
• How model equations are formulated.
• How model is coded.
• How model is implemented into simulators.
• A benchmarking procedure and the benchmarks
  required to validate the model.
• How to extract parameters and verify libraries.

8
A GNU Compact Model DevKit

• The open standard should lead to a free compact
  model development kit.
• The DevKit will be an integrated suite of tools
  that will interface with the parametric
  measurement instrumentation on one end and with
  circuit simulators on the other.
• The DevKit will integrate into IC-CAD flows to
  evaluate models on real circuits.

9
A GNU Compact Model DevKit

• The bottleneck today is the implementation of
  compact models into circuit simulators.
• CM-DevKit must allow for easily integration of
  the models into each simulators compiled model
  interface (compliant approach).
• CM-DevKit must be able to process measured data
  to generate parameters sets.

10
The CM DevKit key tools

• A compact model capture tool (to generate a
  Verilog-A or VHDL-AMS description of the model).
• A compact model analyzer/synthesizer (to generate
  an intermediate form).
• A set of intermediate form languages compiler and
  interpreters to assist in model development,
  playback and debug.
• Circuit simulators to evaluate the model (both
  free and commercial).
• A parameter extraction tool.

11
The CM DevKit Model Capture

• Existing tools
• gEDA is an extensible schematic capture tool able
  to generate spice netlist from schematics.
• Paragon (?)

• Open Issue
• There is no gEDA verilog-A or VHDL-AMS extension.
• There is no capture environment specifically
  targeted to CM development.

12
The CM DevKit Model synthesizer

• Existing tools
• ADMS (Laurent - Freescale).
• This tool generate codes that can be compiled
  into simulators using their CM extensions.
• Generated code runs almost at the same speed of
  human written code.

• Open Issues
• ADMS is under development.
• ADMS translation script writing is poorly
  documented.

13
The CM DevKit Intermediate languages

• Languages
• Tcl/Tk
• Python
• C / C

• Open Issues
• None! Tcl/Tk and Python are already used in CAD
  flows and most of the simulators provide a C/C
  API for CM integration.

14
The CM DevKit - Simulators

• Existing tools
• fREEDA
• GNUcap
• Ngspice
• QUCS

• Open Issues
• Input language compatibility.
• Common set of analyses.
• Common set of modeling API.
• Common data output format.

15
The CM DevKit Simulators

• The ADMS approach of translating the model
  description into each simulators API is winning
  as does not require any intervention on the
  simulator itself.
• Faster development time, no more implementation
  bottleneck.

16
The CM DevKit - Extraction

• Existing tools
• None! Octave (free Matlab-like software) should
  be used to process IC-CAP .mdm data.

• Open Issues
• Need to write an extraction tool based on a
  standard measurement language that can
  interface to IC-CAP data server.
• Writing a parser for .mdm files.

17
Benefits of the GNU perspective

• No discrimination between models and availability
  of models for new devices (MEMS/NEMS, etc.)
• Model developers will be receive feedback on the
  models shortly after release as designers can
  test them on their simulators without the need to
  wait for CAD vendors implementations.
• Model acceptance speed-up, as the end-users
  entered in the development loop have had more
  time to evaluate the model (on real circuits)
  and, by contributing to it, were able to direct
  the development effort toward what they really
  needed.

18
GNU perspective - Summary

• The EDA community will benefit by using free
  compact models conforming to an open standard.
• A CM DevKit to integrate CM development into
  IC-CAD flow can be built using only free/open
  source software.
• The core tools of this DevKit are already in
  place (ADMS, simulators).

19
CM Standardization A GNU perspective
Thank you !
20
Modeling overall goal
ITRS 2007
21
DevKit EKV example 1

• Simulator independence

22
DevKit EKV Example 2