Subject: Re: requirements of ibis generation tools
From: Syed Huq (shuq@cisco.com)
Date: Fri Nov 02 2001 - 11:12:13 PST
The link was removed from the IBIS site. Here is the doc.
Syed
> Importance: Normal
> Subject: requirements of ibis generation tools
> To: "ibis-users@eda.org":
> From: "Sathish K Krishnamurthi" <sathish@us.ibm.com>
> Date: Fri, 2 Nov 2001 11:29:25 -0500
> X-MIMETrack: Serialize by Router on D01ML253/01/M/IBM(Release 5.0.8 |June 18,
2001) at 11/02/2001 11:29:29 AM
> MIME-Version: 1.0
>
>
> Hello All,
>
> I am a new user of ibis generation tools. I got some information that, a
> committe had been set up for defining the requirements of the ibis
> generation tool( probably an enhancement of s2ibis2) and also there was
> some documentation on the web regarding that. But now I am unable to get to
> that documentation. I would greatly appreciate if anyone could guide me as
> to where I can find the documentation defining the requirements of IBIS
> generation tools.
>
> Thanks
>
> Sathish Krishnamurthi
> ASIC Timing and Methodology
> IBM Microelectronics, Burlington
> Tel: 1-802-769-3509 Tieline : 446-3509
> Fax: 1-802-769-7509
> email: sathish@us.ibm.com
>
PROJECT REQUIREMENTS FOR SPICE-TO-IBIS TRANSLATOR
-------------------------------------------------
Rev1.0 Nov19th, 1999
1.0 Scope of Project:
---------------------
Generate a user friendly IBISv3.2 complaint SPICE-to-IBIS translator that can
run on multiple OS platforms and be easily upgradable to meet the requirements
of future IBIS standards.
This project will be identified as s2ibis3.
2.0 General Requirements:
-------------------------
2.1 OS platform independence
----------------------------
2.1.1 s2ibis3 must be developed for UNIX (Solaris 2.x) and NT4.0 (sp5)
at a minimum. Recent stable OS versions should be used.
s2ibis3 should eventually support Linux, AIX, HP
among other platforms using a single Makefile.
2.1.2 A Java based development scheme or C or C++ is preferred.
2.1.3 Avoid using LEX, YACC, FLEX and BISON as there are
portability issues with future upgrades.
2.2 Modular coding for future upgrade
Code generation should be done with the intent in mind that
future IBIS specification be easily integratable without
rewriting the core code sets.
2.3 Hooks to other SPICE engines
--------------------------------
2.3.1 Contractor to test s2ibis3 on Berkeley SPICE2G.6, SPICE3 and
HSPICE at a minimum.
2.3.2 s2ibis3 to have hooks to SPICE2G.6, SPICE3 and commercial
SPICE simulators through configuration files.
2.3.3 The IBIS forum will co-ordinate testing of s2ibis3 on the
all the simulators mentioned above.
2.4 SpiTran GUI
SpiTran GUI is a Java based freeware from Cadence. The usage
of the SpiTran GUI along with all the above requirements needs
to be investigated. If possible, the SpiTran GUI needs to be
incorporated into s2ibis3. All source code regarding SpiTran
will be made available upon request.
2.5 Graphical Viewer (Optional - This is a highly desired feature
and separate quote is strongly requested)
A graphical viewer needs to be created that will plot out
the V/I and V/T tables showing all three Typ, Min and Max
tables and the [Model] name displayed on the graph.
The Graphical Viewer needs to include GOOD zooming (auto and
fixed) and cursor capabilities with dual cursor and x, dx
and y, dy displays. Also have a feature to superimpose load
lines over IV curves with selectable slope, reference
voltage, and display cross points.
(For reference, see s2iplt perl script from NCSU using
GNUplot).
2.6 Parser integration (Optional)
The IBIS parser is to be embedded into s2ibis3 and invoked
automatically after the completion of the IBIS model. Output
of parser can be displayed on stdout or to a machine readable
file (user selectable).
2.7 Project Manager (Optional - separate quote requested)
A project manager needs to be implemented that tracks all
intermediate files, error messages etc. This could further
assist in maintaining IBIS buffer libraries. Model developers
could use this project manager to link various buffer models
to make a complete IBIS component model.
3.0 Specific Requirements:
--------------------------
3.1 Extrapolation
The user will have the flexibility to extrapolate the V/I data
or not to extrapolate the data to the IBIS required end points.
3.2 Sweep range
The user will have the flexibility to define the sweep range
to any value he/she chooses for each V/I tables irrespective
of the defined [Voltage range]. Allow selection of sweeping
direction and multi-section sweeps starting at 0 volts and
going outwards. Add features to clock buffers with F/F to get
them into a known output state. This could be a user selectable
'time delay' before sweep. These are necessary to avoid
non-convergence issues on sensitive circuits and particularly
useful when data is generated from measurements.
3.3 Clamp subtraction
[Pullup] and [Pulldown] V/I tables for tri-stateable buffers
will NOT include the [*_clamp] structures.
First, disable the output structure and perform a sweep. This
will capture the V/I data of the two clamp structure(if present).
Then, Enable the output structre and perform a sweep one more
time. This second sweep with capture the V/I data of the [Pullup]
and [Pulldown](if present).
For non-tri-stateable buffers, the [Pullup] and [Pulldown]
V/I tables includes the [*_clamp] data.
(refer to s2ibis2 problem on this)
3.4 Vdd ramping
The user will have the flexibility to ramp up Vdd (or any other
sensitive nodes) with SPICE supported PULSE or other methods.
Example-
Instead of this:
VCCS2I VDDIO 0 DC 3.3
Be able to do this:
VCCS2I VDDIO 0 PULSE 0.0 +3.00E+00 0.0 10E-9 10E-9 50E-6 55E-6
3.5 .OPTIONS feature
For simulations with non-convergence issues, the user should be
able to add various .OPTIONS parameters supported by SPICE
compatible simulators to solve problem. This will allow users to
change the default settings of control cards. One suggested
scheme would be to implement this feature through simulator
specific configuration files.
3.6 Flow Control
3.6.1If a test fails during the translation flow, a user
selectable option needs to be provided to continue with
the rest of the translation if the user choose to do so.
A failure to generate a particular V/I table should not
stop the user from continuing and generate the V/T
tables or other V/I tables instead. Debug of a failed test
through GUI control is recommended.
3.6.2 Use of [Iterate] feature in s2ibis2 should be implemented.
If a Spice output file for the curve in question already
exists, s2ibis3 will read the data from that file without
re-running the simulation. In this way, you can make
incremental changes to your s2ibis2 files without having to
re-simulate the entire set of models.
3.7 File Naming Convention
It is recommended to follow the s2ibis2 file naming convention
for simulation input/output files (except for Rising/Falling
waveforms). Alternate proposals for Filenaming convention are
also welcome.
Example -
put7.spi: Pullup Typical
rdn7.spi: Ramp Down Min
ddx7.spi: Disabled Pulldown Max
3.8 User selectable voltage step and time step
For DC and Transient analysis, the user should be able
to change the voltage or time steps and other fields supported
by the respective control cards. A user selectable sweep
speed support is also required.
3.9 User selectable number of data points.
As a minimum the tool should extract the most points from the
regions where data changes rapidly and fewer points where it
is linear, according to the requirements of the IBIS v3.2
specification.
Optionally (separate quote requested), the number of extracted
points, the axis on which the counting should be performed
(x or y), and whether the routine should be count or error
limited should be user selectable. User selectable number of
digits after the decimal.
3.10 Choice of Process Simulation
s2ibis3 should be flexible to create a TYP only
IBIS model if the model developer choose to do so
instead of all three TYP, MIN and MAX process corners.
3.11[C_comp] extraction (Optional-separate quote requested)
The translator should simulate the value of [C_comp] by
having a reserved keyword "Calc" for the value of [C_comp]
By default, no simulations would then be done, as a real
value would be present.
3.12 Buffer with on-die resistor or termination require a specific
correction algorithm to avoid double counting. The tool
should be able to handle these kids of buffers. This may
also require flexible Clamp IV curve range intelligence.
3.13 Starting and ending points of Vt curves should be checked
against the IV curve - load line intersection and corrected
based on user response. (This should include non zero clamp
curve currents for cases when the buffer has on-die resistors
or terminators).
3.14 Non monotonocity of IV curves should be checked after summation
of IV curves (if done by the tool).
3.15 Guardbanding feature for IV and Vt curves.
(Optional-separate quote requested)
3.16 Intelligent pin list based model concatanation routine to
avoid electrically identical models being repeated.
(Optional-separate quote requested)
4.0 IBISv3.2 specifics:
-----------------------
4.1 Text extensions
It is desirable that the interface allow including text
extensions for IBIS Version 3.2 keywords and features
such as [Model Selector],[Model Spec], etc., even if they
do not relate directly to the actual Spice to IBIS extraction
process. These features can also include [Driver Schedule],
[Add Submodel] and [Submodel] definitions as text only
extensions where no direct extraction is specified.
Normally these elements may be added "by construction" or may
be based on a knowledgable individual decomposing a
non-available, proprietary Spice model to extract partial
IBIS information.
4.2.0 Spice to IBIS Extraction and full formatting is expected for
the keywords listed below. However, a separate utility
dedicated to Series and Series_switch extractions (as a
minimum) could be proposed. The elements below do not
involve V-T table extractions
4.2.1 [Series MOSFET]:
At least a two terminal, [Series MOSFET] model without the
associated elements at each pin (terminators, i/o models,
etc.)- which are covered already covered in other sections.
The extraction will support the syntax for a Series_switch
and for multiple [Series MOSFET] tables for different Vds
selections.
Both the [On] and [Off] characteristics shall be covered, but
the [Off] table may also be implemented (by default) using a
high value [R Series] element and no extraction.
4.2.2 [Series Current]:
At least a two terminal [Series Current] without the
associated elements at each pin (terminators, i/o models,
etc.) - which are covered in other sections.
5.0 Documentation:
------------------
5.1 README File
----------------------
A text README file describing the contents of the software package
and installation instructions must be provided.
5.1.1 Installation Guide
The procedure for installing the software on each supported
platform must be described. The instructions should assume that
the files have been unpacked from an archive file, with a file
hierarchy exactly as provided by the developer.
It is also recommended to provide a decent installer/uninstaller
software if it is not a simple installation, such as
unzipping/copying all files into a directory. Installation
software should be flexible and allow for user selectable
location, etc...
5.1.2 Directory Tree
The README file should describe the contents of each sub-directory
within the directory tree structure. Detailed explanation
to be provided if required. (see /doc/README)
Suggested sub-directory structure could be:
/bin /doc /examples /src /plot etc
(see /s2ibis2 dir structure)
5.2 User Guide
--------------
A user guide document describing how to use s2ibis3 must be provided.
The source document (word processor format) of the user guide along
with a pdf format is required. This user guide will be the first
documentation a user may consult to understand the usage of the
translator and the steps required to run the translator. The user
guide must include the following items.
5.2.1 Contents
A table of contents must be included.
5.2.2 Reference
The format, meaning, usage, and default values for the control
file accepted by the program. Also the program invocation and
usage of all command line parameters, if any.
The data file format generated by the simulators should also
be explained including how they are parsed, so that one could
"fake" them from other sources.
A definition for how simulation output files are searched
and processed so that someone could "fake" data from other
non-supported simulators and/or measurements.
5.2.3 Error/Warning messages
A detailed explanation of each Error/Warning message that may be
issued by the program needs to be described sufficiently so as to
enable the user to take corrective action. The Error/Warning
messages themselves should be as clear and descriptive as is
practical.
5.2.4 Algorithms
A detailed description of the algorithms used to generate the V/I
and V/T tables, and other calculated values needs to be included
as an appendix. (see /doc/curves.txt).
5.2.5 Tutorial (quoted separately)
Optionally, a tutorial description of step by step program
operation may be provided. This should reference supplied example
data, and should explain how to obtain required data. Examples of
debugging problems should be included, also.
5.3 Software Coding Standards and Documentation
-----------------------------------------------
5.3.1 Code explanation
Every function needs to have comments describing what it
does. All variables within a function needs to be defined
as to what it contains. Additional comments should be provided
for any loops and other areas of the code.
(see src/s2ianlyz.c)
5.3.2 Flow Chart
A flow chart of the project is suggested that describes all the
paths the software takes if it encounters an error or how it
searches through each program to generate the final IBIS model.
5.3.3 Code Maintenance
The code should be easily maintainable by any volunteer from
The IBIS forum. This may require minor changes, compilation
of code for specific platform. Minor bug fixes may be required.
Bug fixes and code maintenance will be coordinated with the
software contractor.
(see /src/sources and src/tags files)
6.0 Acceptance Criteria:
------------------------
6.1 The software design must meet or exceed the functional
requirements above.
6.2 Successful operation must be demonstrated by converting a test
suite of SPICE files to IBIS. The test suite will consist of
not more than 10 SPICE files, to be supplied by the s2ibis3
subcommittee of the IBIS committee. Each SPICE file will be
accompanied by all instructions needed for simulation, including
identification of which simulator(s)the SPICE file will run on.
All SPICE files will be compatible with one of the simulators
specified in 2.3.1. The resulting IBIS files are to be checked
using ibischk3. The requirement is a clean check, with no syntax
warnings or errors. It is recommended that test be performed on
6.3 The software and documentation will be reviewed by members of the
s2ibis3 subcommittee of the IBIS committee. Additional SPICE
conversion testing may be performed by the s2ibis3 subcommittee.
Resolution of issues will be coordinated with the developer.
An understanding of the usage/features/limitations of NCSU's s2ibis2 is
preferred.
An itemized quote is also welcome. This may allow modification to the
project requirement if the initial cost exceeds budgetary constraints.
Regards,
IBIS sub-committee
Michael Cohen(Chairperson) IBM Personal Systems Group
Syed Huq Cisco Systems
Christian Klein Fairchild Semiconductors
Mike LaBonte Cadence Design Systems
Arpad Muranyi Intel Corporation
Bob Ross Mentor Graphics
Mohamed Nasef Mentor Graphics
Jerry Hayes IBM
Sherif Hammad Mentor Graphics
============================================================================
This archive was generated by hypermail 2b28 : Fri Nov 02 2001 - 11:31:48 PST