S2IBIS Process Flow 1. Introduction This document explains the current state of s2ibis process flow and the enhancements being made in phase 2. 2. Product Description 2.1 Overview of current use model To understand the use model targeted for this functionality, it is necessary to first understand how the s2ibis2 shareware works, as it will be leveraged in this effort. In s2ibis2, the user is made to embed information in the header of the input SPICE deck as SPICE comments in order to produce a completed IBIS file. Then s2ibis2 is run on the file, and the deck is stimulated to produce SPICE output data. This data is concatenated into the final IBIS file. In our use model, a single IO buffer model is generated at a time, with the process driven from the UI. Rather than create a text header in the SPICE deck with SPICE comment lines, all of the required data to generate the complete IOCell is filled into fields in a form. This will contain a means to specify the input SPICE deck, as well as items like Polarity, whether VT waveforms for Rising_ and Falling_Waveform data are to be produced, etc., that are relevant to the SPICE translation process. Then the s2ibis2 code is invoked. This fills in the data for the following: · rising and falling slew rates · rising and falling waveforms (if requested) · VI curves This will create the output .ibs file in IBIS format. 2.2 Dependencies · For the translator to run, the required host simulator executable is licensed and in your path. The UI must provide a means to point to this. · s2ibis code from NCSU · ibischk code · SigNoise License (required ONLY for full checks to ensure that the model works fine with the simulator) 2.3 Current State The s2i tool developed in Phase 1 provides UI for accepting all user inputs, creates the necessary SPICE stimulus. Using s2ibis2, it creates the IBIS model which is checked using ibischk2. User can view/edit the IBIS file that has been created. 2.4 New Features 2.4.1 Preparation of SPICE file (this is currently done manually and would have to be facilitated to the extent possible). 2.4.2 SPICECheck to ensure that all prerequisites are complete and the model runs and converges with a typical load (50 pF OR as specified in the spec sheet). 2.4.3 Postprocessing of IBIS data 2.4.4 ibis2signoise to generate .dml file 2.4.5 dmlcheck and postprocessing of .dml file if required. 2.4.6 Verification of Model in SPICE, necessary SPICE file preparation and comparing the output of SPICE run with Signoise output The above three features (4.4.4 to 4.4.6) are all model development process features for optimization and verification of models. These are absolutely required for our model development process and to enable advanced customers to develop and optimize .dml files but the SPICE to IBIS utility itself should be independent and produce an intermediary IBIS file as an industry standard supporter. 2.4.7 Graphics Feature: To view the plots 2.4.8 S2IBIS2 fixes 2.5 Functional Description 2.5.1 SPICECheck This module must verify that (this can be merged with premodeling step): · all prerequisites are complete · the model runs and converges, by running a simple test case driving a test (ex. 50 pF load) · 2.5.2 Preparation of SPICE file (premodeling) The required changes need to be done in the SPICE file should either get done automatically with inputs given by the user OR the feature should guide the user to perform necessary edits through required checks on SPICE file and issue of messages, warnings and errors statements. This includes: · Check that the file set is complete from simulation perspective. · Removal of statements which are for analysis (ex: transient, DC) or act as test stimulus (ex: pulse, piecewise linear) and test loads. · Building of subcircuit which connects to the converted SPICE deck to s2ibis program. · Verify that there are no floating nodes. · Providing options for printing, method, DC-step, Time step, ingold value, post, list. · Adding reference supplies for buffers which use more than one supply · Addition of behavioral inverter for handling ECL devices. · Ensure that package parasitics do not affect VI and VT curves and that package parasitics included for power and gnd bus and removed from SIGNAL pins (as per IBIS). 2.5.3 Removal of Non-monotonicity of .ibs file · Only non-monotonicities would be removed. The algorithm would be to extend the value of previous point for the non monotonic point. This step could be executed irrespective of whether user would go ahead with SigNoise or not to have a first order cleaned-up .ibs file (Pullup and Pulldown data may be non-monotonic for tri-state buffers without the POWER and GND Clamp and should be left as is). Code from enhanced "dmlcheck" will be used to remove monotonicity. This feature should solve the following two problems: 1) remove non-monotonicities yes/no to allow for some cases that do have inherent non-monotonicities. 2) extrapolation that would chop off the anomalous extreme V/I data that sometimes results from SPICE and simply replace with extrapolated data. 2.5.4 "ibis2signoise" and Postprocessing of .dml The post processing phase shall include extrapolation of the data to the required ranges to facilitate convergence and simulation. Note that part of the post-processing is being incorporated in the "dmlcheck" utility. · Smoothening the curves. This should help eliminate problems like jagged VI curves, or insufficient data points around the knee of a curve · Extrapolation over the required -VCC to 2VCC range. SPICE decks often produce bogus data outside of their normal ranges of operation. It is often required to delete the last section of curve generated by s2ibis2 and extrapolate over the rest of the required voltage range. The user should be able to specify whether linear or logarithmic extrapolation is to be used as a minimum (this may be debatable). · ibis2signoise and .dml processing to add - VOH/VOL - Technology - Temperature Coefficients for VOH/VOL for ECL outputs 2.5.5 Model Verification · Verification of model by simulating at the test load. · The verification of the model against SPICE simulation results at same test load as for SigNoise and reporting any mismatches. If the mismatches exceed 5%, these should be investigated and possible explanation provided (the criteria for comparison could be to take difference of values on Y axis (Voltage) between SPICE and SigNoise simulation every 1/10th of stimulus duration and get the average value of deviation). · This should be done for all the cells for a given device. 2.5.6 Graphical Interface (To view the plots) · These capabilities should be similar to IBIS Center features (scaling, zoom fit, scale selection for X and Y axis at a minimum). This feature should be derived from SigWave (by plugging in relevant code). 2.5.7 Derive Model · Based on the IBIS data available for the cells, it should be possible to derive the model for a new device by selecting Pullup, Pulldown, GND Clamp and Power Clamp data from different cells. 2.5.8 Device Level Model · It should be possible to create a device level model based on the IOCell level models by associating these with device terminals. · "dml2ibis" should be available to get the correct .ibs file from the post-processed .dml file. Model Verification features are absolutely essential for an optimized model development process. These are really critical features for SigNoise to make it essential to the model development process. Basic Spice to IBIS feature is required as an industry standard enabler and leverage this to provide the steps of entire process.