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