Subject: Re: requirements of ibis generation tools

From: Syed Huq <[email-masked]>
Date: Fri, 2 Nov 2001 11:12:13 -0800 (PST)

The link was removed from the IBIS site. Here is the doc. 

Syed

> Importance: Normal
> Subject: requirements of ibis generation tools
> To: "[email-masked]":
> From: "Sathish K Krishnamurthi" <[email-masked]>
> 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: [email-masked]
> 

		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
   
============================================================================