Tag Archives: buffer model

A quick and easy IBIS modeling flow

Posted on by
1

For engineers who are new to IBIS modeling, the “IBIS CookBook” [LINK HERE] is a very good reference document to get started. The latest version, V4.0, was created back in 2005. While most of the documented extraction procedures still hold true to this date, some of them may be tedious or even ambiguous in terms of executions. This is particular true for processes mentioned in Chapter 4, differential buffer modeling. Further more, most recent IBIS summit presentations focus on “new and hot” topics like IBIS-AMI modeling methodologies and not many are for the traditional IBIS. In this post, I would like to first review these “formal” process, dive into how each modeling table is extracted and used in simulation, then propose a “quick and easy” method particular for differential buffer. I will then summarize with and this approach’s pros and cons.

IBIS model components:

The most basic IBIS building block, as defined in Spec. Version 3.2, is shown above. Typically at least six tables will be included in an output type buffer. They are IV (Pull-up, Pull-down) and Vt( Rising and falling) under two different test load conditions. Additional clamp IV table (Power and Ground clamp) may be added for input type buffer. After Spec version V5.1, Six additional IT tables for ISSO_PU/PD/Composite currents have also been added to address PDN effects. To create an IBIS model, the data extraction processes start with exciting particular portion of the buffer so that measured data can be post-processed to formulate as a spec-compatible table format. Because a model also has TYP/MIN/MAX skews, so the number of simulations are basically the aforementioned number of tables times three. That is, for a most basic IBIS modeling, one may need to simulate at least eighteen cases (or simulation  “decks”).

To explain a little bit more regarding blocks untouched by proposed new method, I list them in the bullets below:

  • Package/Pin parasitics: IBIS cookbook and normal modeling flow do not mention about this part. Usually a buffer package’s model is extracted using tools such as HFSS or Q3d into a form of S-parameters or equivalent broad-band spice model. An IBIS model can use a lumped R+L+C structure to describe pin specific or package (apply to all pins) specific parasitics. Alternatively, an IBIS model can also use a more detailed tree structure package model shown below for non-lumped structure. Regardless, it’s HFSS or Q3D’s task to convert such extracted S-parameter or multi-terminal sub-circuit into these simple lumped RLC values or tree structures to be included in an IBIS file. It’s a separated process and not discussed here as a part of the buffer modeling.

  • C_Comp: At the very beginning, there is only a C_Comp value between pad and ground and it is used to describe frequency dependent behavior besides the parasitics. Later on, tool like HSpice introduces extra simulation syntax to split this single C_Comp value into branches between pad and various power terminals for better accuracy. Even later, this type of syntax was adopted as part of the IBIS spec. Still, user may only find how a single C_Comp value is computed in most materials. Briefly speaking, they can be calculated using time-domain method based on RC charging/discharging time constant or freq-domain method based on the imaginary current at a particular frequency. How to split this single value into several ones to match the frequency plot best remains an art (i.e. not standardize). In addition, the value C_Comp is not visible during modeling… their effects are only shown when there are reflections back from the other end due to impedance mismatch. What we have found is that usually an IC designer has a better idea about how this value should be and the aforementioned time/frequency domain calculation method may not produce an accurate estimate.

  • Clamp current: Power/Ground clamp currents and Pull-up/Pull-down currents are both IV based (i.e. dc steady state). So they are combined for load-line analysis during simulation. The difference between Pull-up/Pull-down and Clamp is that the latter one (i.e. Clamp) can’t be turned-off. So its effect is always there even when we are extracting IV for Pull-up/Pull-down structures. Thus to avoid “double-counting”, the post-processing stage needs to remove the clamp current from pull-up/pull-down currents first before putting them into separated table. To simplify the situation… particular for an output differential buffer, we may just use IV data even though this is an IO buffer.
  • IT current: These are different dc or transient based sweep in order to obtain buffer’s drawing current when power or ground are not “ideal”. This is important in DDR case when the DQ is single ended and it’s subjective to PDN’s noise. For differential application like SERDES, PDN’s effects are usually present at both the P and N terminals and will cancel with each other. Thus their extraction may be skipped for a differential buffer mostly. One may also note that the IT extraction of composite current is “synchronized” with VT extraction of rising/falling waveform so these current data are extracted with additional “probes” rather than separated simulation.

Full IBIS modeling flow:

The process suggested in IBIS’s cookbook can be summarized as the following steps. They are also implemented in our “Full IBIS modeling flow” within SPIBPro:

  • 0, Collect design data and collateral: A modeler needs to gather PVT (process, voltage, temperature) data, silicon design, buffer terminals’ definitions and bias conditions etc. A buffer may have several tuning “legs” and bit-set settings so a modeler needs to determine which will be used for TYP, MIN and MAX corners.
  • 1, Prepare working space: Create a working space on the disk.
  • 2, Generate simulation inputs: Generate simulation “decks” to excite different block of the buffer…one at a time. So one will have eighteen or more decks at the end of this stage waiting to be simulated.
  • 3, Perform simulations: Perform simulation either sequentially on a local machine or with a simulation “farm”. Double check the results and make sure they make sense, otherwise, go back to step 0 to see which settings may be incorrect or missing.
  • 4, Generate IBIS model: Post-process the simulation data and generate IBIS model. This is usually done by the tool like ours as manual process is tedious and error prone.
  • 5, Syntax check: First quality check of an IBIS model is that it must pass the golden checker. The check here is mostly syntax-wise though there are also basic behavior check such as monotonicity or DC mismatch etc.
  • 6, Validate IBIS model: A formal validation for an IBIS model is to hook-up test load and make sure they produce correlated results comparing to those from silicon at the end of step 3 above.
  • 7, Performance report: The modeler needs to extract the performance such as PU/PD impedance values and slew rate etc. for documentation purpose and check against the spec. or data sheet.

Full step-by-step modeling flow in SPIBPro

Data extraction for a single-ended buffer:

For a single-ended buffer, the first hurdle in the modeling process is to make sure each blocks are excited properly and simulation results make sense. As mentioned, there are at least eighteen simulation needs to be done:

There are also some complications regarding the DC simulation part: some of the buffer may have “clocking” and it’s not easy to separate them from the buffer iteself. Also,  there may be many RC parasitics between nodes for a buffer netlist extracted from post-layout. In other cases one can’t even separate the actual IO part from the pre-driving portions and the resulting circuits to be simulated become huge and time consuming. These situations will make IV data extraction slow and often problematic. As a result, a simple step 0~7 modeling process may not work properly and one need to iterate to tune the set-up such that simulation will always converge and resulting IV curve be monotonic. Nevertheless, the single buffer’s modeling is easier to manage.

Data extraction for a differential buffer:

Differential buffer’s IBIS modeling extends the challenge and effort to another dimension…literally! First of all, each pin in an IBIS file or component connect to an IBIS model and the possible structures and connections between different pins are very limited. So for a differential buffer, a series element needs to be created to describe the coupling relations between pins. All the pictures used in this paragraph are from IBIS cookbook and user may find further descriptions there.

In order to construct such series model, the IV sweep needs to be performed in two dimensions, both at similar resolutions. So if say a typical single-ended IV curve has one hundred points, then the second dimension should also have that much data. That means for one particular corner, there will be one hundred IV simulation in order to construct the 2D response surface shown below. First stage post-processing also needs to be preformed so that common-mode current can be eliminated. All these need to be done before formulating a 2D data view. Only after one can visualize the resulting data, he or she can determine what components are needed to create such series model. This presents the first challenges on top of the IV simulation issues mentioned for single-ended buffer.

The second challenge is regarding the VT simulation. The current flow through this newly constructed series element needs to be “eliminated” to avoid being double counted. For spice-like simulator, there is no such thing as “negative resistance”, “negative capacitance” etc. So one has to resort to approaches like control elements or even Verilog-A (as we presented in IBIS Summit 2016) to have proper VT data extracted. For control-source based approach, it is only limited describe pin couplings of a simple R/C but not non-linear resistance or surface such as series mosfet. For that, an intermediate step to map device or equation parameters to the calculated 2d surface is needed. Even using Verilog-A’s look-up table, the grid resolution is limited by the step size used in first two-dimensional IV step and may have non-convergence issue if it’s to coarse. That’s why in the cook book (the first two lines in the picture below), it doesn’t suggest any approach as it’s really not that easy!

Due to these two great challenges, we have found that differential modeling may not be easy for most modeler. We feel more this way when providing modeling service to clients who wants to perform simulations themselves then send us data. They may want to do so due to IP concern or they knowing more about the design. In those cases, the back-and-forth tuning and tweaking process become a burden on their side and also delay the whole schedule. Thus we are motivated to find an alternative “quick-and-easy” approach to substitute the “formal” modeling steps mentioned above. While being able to simulate accurately w/ great performance is still number one priority, we are ok that they can only be used under some context (such as channel simulation).

Quick and easy approach:

In previous post, we explained how IBIS model’s data are used in a circuit simulation. Simply speaking, the “VT” data is considered as “target” while “IV” tables are used to compute so called “switching coefficients” so that appropriate amount of current will be injected or withdrawn from the buffer pad to achieve. When this is true, the nodal voltage specified by that VT table at that particular time point will be satisfied due to KCL/KVL. Now there are switching coefficients for both pull-up and pull-down structures… thus it takes two equations to solve these two unknowns. That’s why two set of VT, each under different test loads, are required. Based on this algorithm, an IV data and calculated coefficients are actually “coupled” and affect each other. If current in IV table is larger, than the calculated coefficients will become smaller and vice versa. This way the overall injected/withdrawn current will still meet KCL/KVL required for VT. In this sense, the actual IV data is not that important as it will always be “adjusted” or “weighted” by the parameters.

On the other hand, the VT data also contains several DC points and they need to be correlate to the IV table, otherwise DC mismatch errors will be thrown by the golden checker. In addition, the IV data is limited to 100 points and they need to be monotonic to avoid convergence issue. So if we have several sets of VT data and one under normal test load (say 100 ohms for a differential buffer), then they will give us “hints” regarding how IV data will look like.

With this assumption, we propose the following quick-N-easy modeling steps:

  • Connect the silicon buffer to nominal loading conditions and obtain VT simulation data
    • For Single-ended, these are simple VT waveform under two different test loads;
    • For Differential, say use nominal 100 ohms first and see voltage range between V1 and V2
      • Let V3 = (V1 + V2) / 2, use VFixture = V3 and RFixture = say 40 & 60 respectively to obtain two waveforms;
      • Alternatively, use RFixture = 50 and VFixture = say (V1 + V3) / 2, (V2 + V3) / 2 respectively to obtain two waveforms;
      • The main goals is to have two set or set-up covering operating range when a nominal test load (say 100 ohms) is used.
  • Obtain C_Comp values from buffer IC designer
  • Obtain voltage range, temperature etc parameters.

And that’s all, through carefully implemented algorithm and computation, we can generate an IBIS model based on these data with minimal simulation requirements. An the generated model is guaranteed to be error/warning free.

While we will not disclose how these are actually done in details, we can show how they are incorporated in our SPIBPro… as shown below. As a matter of fact, this process has been used in the modeling projects of past year and shown great success.

Only two VT simulation data are required to create an IBIS model

Pros and cons:

We use this approach to create differential IBIS for channel analysis purpose (together with AMI) and have not yet found any problems. Having that said, I would offer several pros and cons for reader’s considerations:

Pros:

  • Minimal simulation required and easy to perform;
  • Will be mathematically correct: no DC mismatch or monotonic warnings, output will match provided VT waveform under nominal test load.

Cons:

  • May not be accurate if the model is used for DC sweep as the IV data in the model are artificially generated;
  • No “disable” or High-Z state as clamp currents (if there are any) has been incorporate into IV data without separation;
  • No Power-aware consideration as ISSO_PU/ISSO_PD generation are not taken into account.

Summary:

In this blog post, we reviewed the formal IBIS modeling process described in the cook book, challenges modelers will face and proposed an alternative “quick-and-easy” approach to address these issues. The proposed flow uses minimum simulation data while maintaining great accuracy. There might be limitations on models generated this way such as neither disable state nor power-aware data are accounted. However, in the context of channel analysis particular when a differential model is used together with its IBIS-AMI model, we have found great success with this flow. We have also incorporated this algorithm to our SPIBPro so our tool users can benefit from this efficient yet effective flow.

IBIS model: How to create an IBIS model

Posted on by
Reply

In previous post, we described the required data inside an IBIS model. These data are mostly various IV, VT and IT look-up tables under different test loading conditions. The IBIS modeling process thus is to create these tables from original buffer’s simulation results, then format and output as IBIS compatible syntax. Basically, the IBIS modeling process includes the following steps:

  • Collect: Collect design collateral, such as spice netlist and parameters;
  • Generate: Create schematic net list to excite the buffer into operations mode;
  • Simulate: Simulate the schematic net list using original buffer design;
  • Calculate: Check and post-process simulation waveform, compute data;
  • Model: Output the processed data into IBIS format;
  • Check: Use golden parse to check syntax, fix any errors and address warnings.
  • Validate: Create schematic net list to excite the generated IBIS model, obtain its performance parameters and simulation waveform under test load. Correlate the performance from original buffer design and that from created IBIS model;
  • Report: Document the IBIS model, annotate manufacturer information etc. and ready for release.
SPISim BPro's IBIS modeling flow

SPISim BPro’s IBIS modeling flow

Let’s talk about these steps in more details.

  • Collect:  Take this buffer design as an example. If we are going to create an IBIS model for this buffer, first we need to obtain the original spice net list which mostly contains many transistors. Besides, we also need to know under which condition this buffer is manufactured. That means we will need manufacturing process info. We also need to know its nominal operation condition, i.e. voltage supply. Lastly, we need to know at what temperature this buffer is expected to be operated at… as transistor’s performance is affected by the temperature quite a bit. Together, these are usually called P/V/T corners (Process, Voltage, Temperature). Lastly, we need to know what each of the buffer terminals should connect to (bias condition) in order to operate. Normally, a buffer will have many control “legs” which circuit designers can use to fine tune its performance such as slew rate and output impedance. Different settings for control legs will yield buffer with different performance. As an IBIS modeling engineer, you will need to obtains the settings, usually are series of bits flags, for these control legs. With all these information ready, you then can create schematic net list to excite the buffer for modeling.
Transistor and process info. for a buffer design

Transistor and process info. for a buffer design

 

  • Generate: In this step, one needs to excite buffer in order to extract simulation data for different IV/VT/IT tables. Different buffer model type requires different tables. The following give simple overview of how buffer needs to behave for different table’s extractions needs:
    • IV for PU: enable the buffer to output high state, sweep voltage at output pad from -Vcc to 2Vcc to get input current;
    • IV for PD: enable the buffer to output low state, sweep voltage at output pad  from -Vcc to 2Vcc to get input current;
    • IV for PC: put it in high Z state while provide input to like it will output high state, sweep voltage at output pad from -Vcc to 2Vcc to get input current;
    • IV for GC: put it in high Z state while provide input to like it will output low state, sweep voltage at output pad from -Vcc to 2Vcc to get input current;
    • ISSO PU: put a variable voltage source between ideal supply voltage and buffer’s pull-up terminals, then measure input current at output pad while the voltage sweep from -Vcc to Vcc. This mimics buffer operating under non-ideal voltage supply condition (i.e. voltage droop).
    • ISSO PD: put a variable voltage source between ideal ground and buffer’s pull-down terminals, then measure input current at output pad while the voltage sweep from -Vcc to Vcc. This mimics buffer operating under non-ideal grounding condition (i.e. ground bounce).
    • VT for rising/falling waveform: Connect buffer’s output to test loads and make buffer operate for low to high and high to low transition. Note that the input stimulus’s ramp rate should be practical (e.g. 100ps) as there is no instantaneous logic transition in real world. Do this again for different test loads. At least two VT simulation should be performed, with these two test loading conditions cover the actual usage range of the generated buffer.
    • IT for composite current: Put a zero-volt voltage source between ideal voltage source and buffer’s pull-up circuitry. Monitor its drawing current as buffer runs during operations for previous VT simulation. Typically IT and VT set-up can be combined in one simulation;

BPro_ISSO

IBISIT

  • Simulate:  The aforementioned net lists file can be generated either separately, i.e. one net list targeted for one IV/IT/VT table extractions, or be combined in one single deck and simulate sequentially using like HSpice’s “.alter” statement. The advantage of doing it separately is that these netlist can be simulated in parallel either using different threads on the same machine or using simulation farm/pool. One might need to perform “pseudo transient” simulation instead of true DC sweep as either some of the buffer design has clock signal or they tends to have convergence issue when doing pure DC sweep.

BPro generated netlist files

BPro generated netlist files


 

  • Calculate: In this step, the simulation results need to be visually inspected first to make sure the buffer outputs are desired. If not, one needs to go back to the first step and see whether there are missing bias condition needed to apply to buffer or the simulation setup is incorrect. Remember… garbage in, garbage out! If the simulation waveform is as expected, then the calculation step usually involve subtracting the always existed PC/GC reverse bias current portion from IV data for PU and PD, and switch the voltage for PC and PU such that they will be Vcc relative. If there is on die termination, the PC/GC current will be significant and may needs other special treatment. [Linked to Bob Ross’s paper]

 

  • Model: This step involves translating the calculated data table, along with its operation and loading conditions when the buffer is simulated, into IBIS syntax compatible format. To make data table compact and accurate, an optimization process is usually needed such that best 100 or 1000 points of data are selected from the sometime lengthy time-domain simulation results. Also, all Typ/Min/Max waveform columns have same time point at particular time. so the optimization process needs to take these into account. This optimization process is important for IBIS V3.2 model which only allows 100 data points in the table, and IBIS V5.0 model as well as the composite current is usually very “spiky” and best points need to be selected properly in order to capture most of the current behavior.
BPro's algorithm selects best 100/1000 points

BPro’s algorithm selects best 100/1000 points

 

  • Check: Once we have generated an IBIS model, the first step of sanity check is to invoke golden parser to check the syntax. Besides, it will also detect possible dc mismatch issue which implies the quality problem of the generated model. If the difference is beyond certain percentage, it will be flagged as error by the golden parser and most industry circuit simulator will refuse to run on these models. So it’s crucial to iron out and fix any errors and minimize the warning messages.
BPro uses golden parser to check syntax and detect errors

BPro uses golden parser to check syntax and detect errors

 

  • Validation: Once a syntax valid IBIS model is generated, one needs to further validate its performance and ensure it correlates to the original buffer design well. The validation net list contains instantiated IBIS instance alone with same test loading condition used for original buffer excitation. A good IBIS model is not only accurate, compact, but also run very fast without any convergence issue. So this step should run very fast. One can then visually check and correlate the simulation waveform produced by both original buffer in the “simulation” step and those produced by this just created buffer. Except for the leading delay which IBIS model is not intended to capture, the transition waveform shape and dc steady state should correlate very well.

 

  • Report: A quantitative report is usually expected to demonstrate the quality of the generated buffer. IBIS accuracy handbook and quality spec give spec. on these as industry standard. A “figure of merits” (FOM) is usually used to represent how well the generated IBIS model correlate to original buffer design.
BPro's visual inspection and FOM reporting

BPro’s visual inspection and FOM reporting

The above is a brief overview of the eight-step IBIS modeling process. There are many details which worth further discussion but are beyond the scope of this post. As one can see, there are many steps involved. While creating IBIS model manually is possible, yet it’s time consuming and error prone. That is why we SPISim developed the BPro module to address the needs for the streamlined modeling process.

 

IBIS model: What is buffer model and why IBIS

Posted on by
Reply

Before we are going to dive into details about buffer model, we need talk about why we care…

Buffers sit at the driving and receiving ends of a channel. So while the passive channel is composed of models like transmission lines, vias and connectors, the models sit at both ends are buffer.
Channel
If you are a circuit designer, in particular, a chipset designer, you pay attentions to the transistor sizing and the associated process, voltage and temperature corners (so called PVT corners) so that you will be assure that the designed buffer, when connected to the system, will have desired strength, impedance and timing.

Transistor and process info. for a buffer design

Transistor and process info. for a buffer design

However, if you are a system designer, or a signal integrity engineer. You pay attentions to higher level of the system design, such as component placement, routing, topology, termination etc. A buffer or an IC to you is just a component off the shelf. Those design details like transistor sizing, silicon doping concentration etc are too much details for you and are mostly not needed to what you are doing. Just like when software designer make connections between libraries, they make use of application interface (API). A much simplified model to represent these buffers are thus needed to enable system design.

Thus from the perspective of needs to interface between transistor level and system level design, a behavioral model representing a buffer is certainly needed.

System level design use buffer as component.

System level design use buffer as component.

Now when we talk about buffer modeling, there are several requirements derived from different perspectives:
A good buffer model needs to be:

  • Accurate: This is most important consideration. Garbage in, garbage out. By accurate, it’s usually considered to be within 5% tolerance of corresponding original, transistor design.
  • Protect IP: From IC/Chip set manufacturer’s perspective, they release buffer model mostly publicly to enable their customers adopt the design. However, they also do not want to reveal any IP such as how the buffer is designed and the manufacturing process info.
  • Run very fast: From system designer’s view, a buffer needs to run very fast, typically at 100X ~ 1000X of the corresponding transistor design. Only so then system design, which usually includes hundreds’ or even thousands’ of buffer, is made possible.
  • Easy to generate: For a model generation engineer’s perspective, if it takes lots of effort to generate and correlate the buffer model from its transistor counterparts, then the model generation process will become error prone and cause accuracy concern. Black-box type modeling is desired mostly as the model generation engineer does not need to know how these buffers are designed yet he/she can still generate buffer model which matches its original transistor’s performance.
  • Follow industry standard: A good buffer model should follow industrial spec. or format such that it can be simulated with different vendor’s tool, such as Synopsis’s Hspice, Cadence’s SystemSI or Agilent’s ADS. A model locked in to a particular tool is usually just to hide potential accuracy and easy generation issues down the road.Often in such considerations, one may consider using encrypted transistor netlist, such as encrypted Hspice, for model release. However, this will defeat the requirement of speedy simulation performance as encrypted model is usually run at the same speed of their transistor originals.From these considerations, several industrial standard have been proposed and widely used for buffer modeling used in system level analysis. They includes: IBIS and Verilog-A. In which, IBIS is most widely used and has been around since mid 1990. More info. about IBIS spec can be obtained from the ANSI’s IBIS website [HERE].