S-Param: Analysis report

Preface:

A S-parameter model can be obtained from lab measurement using VNA, full-wave field solved from a 3D structure, analytically computed via AC simulation or analysis process such as cascading of various stages. There are many situations when more than one s-parameters will be generated for similar setup. When dealing with multiple s-parameters, one should be able to quickly batch process and generate a summarized report for desired performance or measurements. Equality important is to be able to investigate and debug on a case by case basis. Both of these functions are also must haves for an EDA tool supporting S-parameter models.

Example report from the PLTS tool

In this post, we would like to discuss points of considerations when planning for these types of analysis and reporting capabilities. We would also demonstrate how they are accomplished in our SPIPro tool. Most of the mathematics for these processing can be found on website such as RFCafe or matlab RF toolbox.

 

Analysis:

There are many analyses often used so far as s-parameter is concerned.  They can be classified into several categories:

  • Conversion: such as converting a single ended S-parameter to a differential one or one with mixed mode (mixed single and differential), converting between S and Y, Z, ABCD formats, etc
  • Extraction: such as trimming unwanted frequency data points, extracting subset of S-parameter, or calculating physical properties such as impedance, effective inductance etc
  • Generation:  such as cascading different stages together, either assuming generalized 2N port in a point-to-point topology, or arbitrary ports branching out like those multi-drop situations in DDR, combining S-parameter data in other fashions such as merging, synchronizing frequency samples etc.
  • Processing: such as smoothing the data using moving average, extrapolating toward DC and high frequency based on physical properties, renormalizing reference impedance to different values.

10 of 30 SPIPro’s S-Param analysis capabilities.

Based on our experience, Convert, Cascade, Renormalization and Quality check are most frequently used. For mixed mode conversion, several port ordering scheme should be supported: incremental, interleaved or even-odd mode.

The outcome of the processing above are mostly another s-parameter. Thus one should be able to inspect selected individual Sij element either visually or textually further. For the same set of data, it can be plot in different format to reveal different properties or behaviors. For example, X-Y format by default, polar plot for causality inspection and smith chart in either Y or Z format etc. Since only several Sij elements are plot instead of the full S-parameter, some analysis can be done almost in real time to provide feedback: time domain reflection (TDR), time domain transmission (TDT), worst case eye analysis based on pulse distortion analysis or even passivity plot etc.

Texture representation can be useful when one needs to copy part of the calculated data for further analysis, such as taking effective inductance for power integrity simulation. Color coded matrix at the first and last frequencies are also useful for quickly checking connectivity or high inductance ports.

 

Report figure:

The analysis process mentioned above are good for investigation or experiment purpose. When there are more than several s-parameters need to go through similars sequence of operations, being able to batch process and report becomes important. In this case, the input conditions such as number of ports, their mode (single ended or differential etc) port ordering and reference impedance etc are specified up front (via GUI or a template). This settings will be applied to all the given s-parameter such that after they are read in by the tool, this sequence of actions will be performed automatically. After calculation,  report in the form of various figures, statistics and csv can be generated:

  • Frequency domain figure: one or more selected Sij traces from the processed data can be plot in the X-Y chart in linear or log scale. Waveform calculation using real or complex number with various operator including log and power should also be supported. Multi stage limit line can be added to identify boundaries which signal traces should not cross.

One or more such figures can be defined for different data and measurements.

  • Time domain figure: For time domain, Sij needs to be converted using iFFT first. To achieve certain time domain resolution, extrapolation to higher frequency and data smoothing using moving average may be needed. There are several time domain metrics often used: TDT, TDR, crosstalk, inter-pair and intra-pair skews etc. Input pulse’s rise time may affect the resulting slew rate so it needs to be part of the settings. Again, one or more such time domain figures can be pre-configured so that their settings will be applied to all s-parameter data.
  • Statistics figure: The timing or skew measurement can be summarized using a histogram with distribution curve. Their data in csv format can provide more detailed info. for individual cases.

Allowing further customization such as various font size, frequency unit, grid line etc will make the generated reports more appealing aesthetically. Finally, these settings should be allowed to be imported or exported for later use. Resulting report can be in html or pdf format with indexing at the top of the page. With this kind of capability, analyzing a set of s-parameters become easy and efficient.

 

Report data:

When there are even more s-parameters to be processed, such as hundreds or even thousands of cases from analysis methodology such as design-of-experiment or multi-dimensional sweep, even visually check with reporting becomes time consuming. In this situation, batch processing to extract performance value, summarized in a multi-column csv fashion to be used for statistic tool such as our MPro or JMP is more practical.

User first specify all the files to be processed, then specify one or more time domain or frequency domain performance targets. The processed results can be visualized as a summary plot. Interested cases or outliers can then be selected to generate more detailed report or investigate individually.

Unless specified, all the screen captures used in this post are from our SPIPro product. All the mentioned functions and capabilities are also supported in this product.

S-Param: Quality checklist

Preface:

In a typical system, there are usually three type of models involving in simulation or analysis:

  1. IBIS/IBIS-AMI: At the both ends of the channel are driver and receiver models, usually in the forms of spice, IBIS and/or AMI.
  2. RLGC: Interconnects with homogeneous structure such as transmission line and/or layer stackup are usually 2D/2.5D field solved and represented with frequency dependent RLGC matrices
  3. S-Parameter: Complicated passive structures such as package, connector or via must be solved with full-wave simulation to have accurate representations, which are almost always S-parameter.

In the recent years, due to the popularity of link analysis for low BER requirement (i.e. various SERDES interfaces), S-parameter has become more and more important. A s-parameter is now often used to represent the full channel (package + t-line + via + connector etc). In addition, there are lab measurements from VNA which are also in the form of S-parameter. Even when behavior models (broadband spice circuit) of these components are used for time domain simulation, they are also converted originally from S-param via algorithms like rational fitting.

Each of these S-parameter may have their own noise sources, bandwidth limitation or numerical inaccuracies. As a result, one has to check the quality of the S-parameter models to avoid numerical errors or instability (e.g. simulation convergence) of the analysis at the later stages.

There have been several documents floating on the web discussing about checking list for a given S-parameter, albeit lack of systematic approach or industrial support across different vendors. For this purpose, IEEE P370 committee was formed in 2015 to discuss and define a spec. as a reference. Task group 3 of this committee focuses in particularly on the S-parameter quality check. As a participating company in this joint effort since the very beginning, also as the spec. draft is coming into shape at this moment, we think it’s a good time now to share the collective thoughts and also demonstrate how these ideas are implemented in tool like our flag ship product, SPIPro.

 

S-Parameter quality check:

A S-parameter checking list can usually be classified into two categories: generic check and application specific check. This post focuses on the generic check, which is defined as checking based on their physical properties. For the latter one, application specific condition such as signaling speed, typologies, modulation method or even coding are further imposed. Generally speaking, there are several generic checks need to be done:

  • Passivity: to make sure data is passive and has no amplification
  • Causality: to make sure properties of cause and consequence are maintained
  • Reciprocity: to make sure data is symmetric
  • Even/Odd/Asymptotic behavior: to make sure even and odd behaviors are maintained at both DC and high frequencies
  • Connectivity: to make sure connectivity of structure extracted is correct and has no broken link(s)

In addition, reports from all of these check should be presented clearly with an overview and further details available. The overview summary should also use a single number for each check as well as quality metric coded with color for different level:

  • Good: Green
  • Acceptable: Blue
  • Inconclusive: Yellow
  • Bad: Red
  • NA: for information only, such as connectivity

Numerical criteria for these levels depends on the types of check. Lastly, visual checks should also be used in some cases to provide frequency specific information such as where the issue happened.

Full mathematical details and explanations of the sections below will be in IEEE P370 spec.. It will be made available free to public upon completion. We will not duplicate the details here but only giving high level description and demonstration usage below.

 

Passivity:

Power injected into a S-parameter, which includes those from incident and reflected waves, should be preserved without amplification. When this is true, then S-parameter is passive and does not contain any energy source. Mathematical requirement is:

Visually, we can plot the given traces (Sij) and see whether they cross threshold of 1.0:

And/or compute a summarized metric, Passive Quality Metric (PQM):

reported as a single value:

One way to fix a non-passive system can be use the largest (violated) value to normalize the rest such that no value is larger than 1.0, thus passive.

 

Causality:

Causality check is the most important, yet more complicated one for a S-parameter. A necessary but non sufficient condition of being causal is that the even and odd function behavior of the real and imaginary data at DC should be satisfied. Adding being passive across full frequency range will make the condition sufficient. So a causality check essentially includes many of the other checks needed for a s-param.

Due to the complexity of the math, such comprehensive check is not easy. As a result, a visual check (heuristic) may be used. This check is based on the observation that a polar plot of a causal system rotates mostly clockwise and is often very smooth. The small inner circle is usually where resonant happens which may degrade the causality of the overall data:

The progress of phase between two adjacent vectors (Sf0, i, j to Sf1, i, j) can be calculated and normalized with their dot product and magnitude. The results should be a value falling between -1 ~ 1. Negative value represents decreasing group delay and thus a counter-clockwise phase change between these two vectors. This is where resonance has occurred. One can plot such measure against each frequency and got its visual representation:

Often time, through type traces of a given s-parameter (S12 or S21) are used for iFFT for corresponding pulse or impulse responses. One can calculate this for each frequency of each through through type signal and have a summarized metric: Causality Quality Metric (CQM)

And report can contain more details about violations of different frequencies:

The fix of a non-causal system usually involves reconstructing a causal system with parameters fit the given data. Vector fitting or rational approximation are such approaches, which will be discussed in future post in more details.

 

Reciprocity:

As a s-parameter is passive, it should not be directional regarding input and output ports. Thus a S-parameter’s content should be symmetric across the diagonal part. Note that this may not be the case for materials which has non-diagonalizable property such as ferrites, yet it should hold true for most of the materials used in system elements and materials.

For a large multi-port system, color coded cell values can be used as a visual check for symmetry (reciprocity):

This needs to be done at least at the first (low) and last (high) frequency content. Regarding an overall evaluation, a Reciprocity Quality Metric (RQM) can be used:

A reciprocity violation’s fix is usually the easiest… one may average values from both sides of diagonal and replace in place.

 

Even/Odd/Asymptotic behavior:

This check is based on the fact that a transfer function should be equal to its conjugate in the negative frequency domain:

As a result, the real part of the data should be an even function while the imaginary part should be an odd one. That means at the dc level, the real data should be flat across freq = 0 axis while the image should cross origin point. Also at the highest frequency, the imaginary data should approach zero. One can think of all the inductive and reactive elements such as capacitors and inductors are either open or short at the lowest (DC) and highest (infinity) frequency point, thus make the transfer function real only.

This even/odd/asymptotic behavior is very useful when the extrapolation toward DC and highest frequency points are needed, such as the case for TDR/TDT from iFFT. DC point in frequency domain will affect the corresponding DC value at the time domain, while the highest frequency available will decide the resolution in the converted data in the time domain.

 

Connectivity:

This is to make sure the structure the s-parameter extracted from does not contain any broken channel. A simple conversion of S-parameter to Y or Z parameter and check their value should reveal the connectivity. Usually doing so at the first data point (low frequency) is enough. Color coded matrix value again will be very useful especially for large s-parameter matrix:

The example shown above is for a full DDR byte lane which involves many DQ and a pair of DQS signals. As DQS is differential, it may also be useful to separate them from the rest of the data with proper scaling for better distinction.

 

Report and summary:

To apply these checks to more than one  s-parameter, a batch mode process is often preferred and will save lots of mouse clickings:

The produced summary should contain with color coded cell and various quality metric number, plus further details for each check of different data. This will certainly gives user better idea about the quality of their s-parameter files.

All the screen captures used in this post are from our SPIPro product, which also implemented all the checks according to the IEEE P370 spec. draft.

 

Differential modeling flow: Development

Flow considerations:

Two major considerations when developing a modeling flow are consistency and flexibility. This is particular true when it comes to differential buffer modeling. As discussed in our previous post, a half/true differential buffer goes through most of the same steps as single ended buffer yet certain process must be elaborated (e.g. modeling of the 2d surface sweep) and order needs to be preserved (i.e. extract C_Diff, I_Diff before performing VT simulation). In this post, we will briefly discuss how these considerations are incorporated into design concepts and realized in our SPIBPro modeling flow.

Design setup:

Conceptually, user does not need to know whether a buffer is true/half/pseudo differential before modeling. The IBIS cookbook V4 also states this and also use encrypted hspice as an example… as it’s black box and can’t be deciphered, a model developer needs to assume coupling exists between P and N (thus true differential). The computed differential current from both 2D sweeps of IV and C_Diff will reveal whether such (true differential) assumption is valid. The decision can then be made based on the value of current.. if it’s in uA or nA range, then coupling is insignificant and can be modeled as pseudo differential.

In reality, we may argue that one should start with pseudo-differential approach and switch to half/full differential only if the final validation suggest so. This is because modeling engineer usually can get insights about buffer to be modeled by talking to the circuit designer (usually in the same company, also no needs to reveal or know much of the design details during such inquiry). In addition, the DC sweep of extra dimension and modelings of the half/true differential flow are often overkill for many of the designs.

In terms of modeling setup, only input and output (for N pin) are needed in addition to common single-ended buffer. A model type selection of “differential” is sufficient to indicate the differential modeling flow rather than linear single-ended modeling.

DiffDrvCfg

Modeling flow overview:

The modeling flow is summarized in the picture below: the key change here is that flow is not linear anymore. The simulation and post-processing stages need to be gone through twice. When simulating for the first time, only IV/C_Die sweep are needed. The data is then post-process for the first time to extract the common-mode and differential-mode current. The latter will also be modeled as a separated component in this stage. This differential component is then inserted between P and N pins in the transient netlist and simulated in the second iteration of the simulation step. However, only VT data is needed this time. When that’s done, all IV, VT and C-Die data are now available and the flow can continue linearly just like that of single-ended buffer.DiffMdlFlow

Modeling of the IV data:

While PU/PD is steady state DC sweep in theory, their simulation is performed in “pseudo DC” most of the time due to likely existence of clock signal, thus not possible for true DC sweep. In “pseudo-DC” simulation, voltage are swept very slowly. In addition, sweeping along X coordinate of different Y values are mutually independent. So they can be simulated in parallel (multi threaded or can be distributed). Simulation under certain biasing condition may have convergence issue, so a flow must be tolerant about missing sweep data on some grid points due to non-convergence.

In our SPIBPro example below, sweep of different Y bias points (e.g. voltage at output N) are separated in different .sp files and they can be simulated in parallel.IVSweep

The task of post-processing step in the first iteration is to extract the simulation data just swept, calculate common-mode current, shift the surface data vertically, summarized as a table output and also perform initial modeling. Such a table is important for user to validate the the result and also perform some what-if modeling using tool like Excel if neded.

DiffMdlCsv

  • Surface modeling:

    Depending on the symmetric differential mode data of shifted surface table (data on the surface alone the blue line), one may decide whether it’s pure resistive, linear or non-linear. The symmetric differential mode is orthogonal to the zeroed common mode curve (red straight line) and it represents the most likely differential operation (i.e. symmetric output of P and N)  For example, the surface plot below suggest a resistor will suffice for the content of the series element:

DiffMdlSerR

With the csv table, one can quickly confirm whether the resistance is same across different voltage or not. If positive, then a linear resistor can be used. Otherwise, the non-linear resistance need to be modeled either with PWL spice element or as a series current (another IV table) in the series element. To be able to visualize the data with certain degrees of manipulation, a flow needs to have such 3D plotting capabilities. Otherwise, tool like matlab and familiarity of its syntax becomes necessary.

DiffMdlSurf

If the sweeping data shows surface like above, then either a surface modeling is needed or a “series MOSFET” needs to be created  as a series element. For surface modeling, one can use “response surface modeling” like method to calculate fitting coefficients in minimizing the mean squared error sense. Other general modeling approach like neural network is certainly also possible.

DiffMdlRSM

One should also check the residue of the prediction formula and maybe visualized as a scattered plot. SPIMPro’s general modeling and plotting functions are demonstrated below:

DiffMdlRSM2

DiffMdlRSM3

A good fit should have very small residue, shown as grey line across 0.0 in the picture above (other red dots are nominal values from sweeping grids). With valid results, one will need to translate this “prediction formula” into spice netlist using E/F/G/H control elements.

In matlab, similar process can be done using “lsfit” function.

  • Series element:DiffMdlSerThe same table content is sufficient to construct a series element. The steps needed here is to translate data into a IBIS compatible format. Such process is trivial when the model is simply R/L/C. For series current and series MOSFET (can have up to 100 tables of different bias condition), the attention needed to perform such work manually is not economical and a tool/flow should be used instead.

Modeling of the C-Diff:

CDiff

Similar process (tabulated and modeling) can be applied to calculated C_Diff. However, it’s much more limited in terms of series element’s syntax and E/F/G/H equation such that describing such surface (both frequency and voltage dependent) for C_Diff is not practical using either spice or series element. As a result, a trade-off needs to be made when picking values (or to average) from the surface and a single value is used when constructing model for C_Diff.

Verilog-A modeling:

In our submission to the IBIS summit later this year, we proposed another flow which is Verilog/VHDL based. One of the advantages of this implementation is that the raw, table-like data can be used directly using built-in $table_model function. Its usage also enables polarity differentiation and elaborated description of C_Diff, which is very crucial to the transient data accuracy. The details about this will be published here once our paper is accepted.

Combined model:

In previous post, we mentioned that in addition to the “series element” for differential model, pure [External Model] of the differential model type may also be used. Using the proposed Verilog-A/VHDL for series element only model, these two methods can then work together, as shown below:

CombSer

A series model is still declared in the “[Series PIn Mapping]” section to be connected between buffer’s N and P outputs. Its definition, can optionally include an external model such as the one implemented with behavioral language. This “[external model]”  works on top of existing series model definitions and can provide extra info. such as frequency/voltage dependent C_Diff if the simulator supports. Optionally, the “top” series model can be simply a  shell (e.g. with high impedance) and all the info. regarding the differential current is encapsulated inside the added model. When comparing to external model attached under output/IO buffer, this external model can be significantly less complicated and also provide more tuning capabilities.

Differential flow validation:

To validate a differential modeling flow,  one may construct a differential buffer by creating an artificial coupling (e.g. using some R/C elements) and then connect it between two known IBIS buffers. During the validation, the calculated common-mode data from DC sweep should reconstruct exactly the same PU/PD/PC/GC tables as those in the known IBIS buffer. Differential current will reveal the resitive element of the coupling portion. Calculated C_Diff should reveal the coupling capacitive element. Both of these steady state differential current and C_Diff can be validated using generated csv table or raw data. User should then find that with both captured accurately, the transient VT data calculated will also correlate to those of original IBIS buffer very well.

Paper and audio recording:

We presented this study at the 2016 Asian IBIS Summits. Readers may download the presentation from IBIS website or [HERE]. Audio recording at Tokyo is also available [HERE]

Differential modeling flow: Revisit

In the past, we have blogged several articles regarding buffer modeling. The flow and focus there are mainly for single-ended. The considerations are that:

  • Single ended (SE) buffer modeling is a good introduction to modeling flow in general without further complication;
  • (Pseudo) differential buffer can actually be modeled as two single-ended buffers;
  • Many (true/half) differential buffer can be modeled like pseudo differential buffer without significant loss of accuracy [LINK]
  • Differential buffer modeling involve several steps which are a little more complicated.

During our workshops in Taiwan last month, several attendees asked about CML (current-mode logic) modeling. With the maturing of the concepts in SE modeling and the prevalence of SERDES interfaces such as USB, SATA, PCIe etc, we think it’s a good time to revisit the differential modeling flow in more details. We will also show how this design concepts are realized in our SPIBPro in next post.

Note that the contents of this and next posts are also written in conjunction with the paper submission to the IBIS summit later this year.

Model descriptions:

[The info. here are summarized from the IBIS cookbook V4]

A differential buffer can be categorized into three different types:

  • Pseudo differential: shown in the rightmost of the picture below. The “P” and “N” driving portion are mutually independent. There is no coupling between these two pins in the circuit.
  • Half differential: shown in the middle. the pull-down portion of the “P” and “N” are coupled via a current source or shared load.
  • True differential: shown in the leftmost. Both the pull-up and pull-down circuits are coupled via “current-mirror” and shared current source.

DiffBuffer

For pseudo differential type buffer, the single ended buffer modeling flow can be applied directly. One only needs to generate these two “uncoupled” buffer separately (or use the same model with input flipped) and describe their differential behavior using the “diff pin” IBIS keyword:

DiffPin

Note that this “Diff Pin” keyword is also optional. So one may also simply instantiates two instance of the single ended buffer and use them together outside the IBIS file, such as in the spice netlist.

True/half differential buffer:

For a true/half differential buffers, the existence of “coupling” between P and N circuits must be described using existing IBIS syntax. There are two ways to do so: either using “series” or “external model” keywords:

  • Series: There are two places series needs to be declared: the first one is “[series pin mapping]” in the model headers and the other one is “series model” of the “coupling” circuit in the “[model]” descriptions:SerPinTake the picture shown above as an example. Under the “Series Pin Mapping” keyword, a model named “R_SERIES_100” is declared to connect pin 1 to and 2. Another instance of such model also sit between pin 3 and 4. Pin 1~4 each has its own model defined in other part of the ibis file already. For example, pin 1, 2 may have an output buffer connected while pin 3, 4 have open-drain buffers. This R_SERIES_100 model must have type “Series” defined as part of the IBIS file. Since “Series” is one of predefined IBIS model type, its contents (keywords) are not free form and must be one or more of the following series elements: R, L, C, Series current and Series MOSFET which contains up to 100 I/V tables under different biasing voltages.SerElem
  • External Model:  In the IBIS spec, four different differential specific model types are also support.:DiffMdlTypeThese differential model types must be implemented with language such as Spice, VHDL-AMS, Verlog-AMS, IBIS Interconnect Spice Sub-circuits (IBIS ISS) and declared with the “External” model section. These languages provides much more flexibility in terms of modeling capabilities, yet they also diminish the portability of the generated IBIS model.DiffMdlDescIn the example above, a separate file “ideal_driver.vhd” must be provided outside the IBIS file and an “entity” of name “driver_ideal” needs to be defined. The port connections is described using reserved keywords after the “Ports” statement. In the IBIS Spec, all possible ports are pre-defined and the declaring order here must match their definitions in the associated Verilog/VHDL etc file.

Modeling process:

Pure method 2 implementation, i.e. coding in language like Verilog/VHDL, is up to the model developer. On the other hand, the syntax and structure of series elements, used in method 1, is strictly limited. Thus the modeling process below focuses on method 1 above, i.e. the series model method.

As the coupled half/true buffer described by separated single drivers and connected via a series model for the coupling, the modeling flow must somehow be able to extract the data for these blocks independently so that they can be described with conformed IBIS keyword and reproduce the response when putting together.

For the “Driver” block, it’s a generic input/output/IO type buffer. So tables such as pull-up/pull-down/power-clamp/ground-clamp, when applicable, must be extracted. So are the transient waveform under different test loads. The extraction must be done such that the coupling with other half can be separately as an independent “series element” model.DiffDrvDataExt

  • PU/PD: A two dimensional table produced by sweeping at both the P and N outputs are performed, as shown in the upper right block above. One major assumption for PU/PD extraction is that when both output pins are at the same voltage level, there will be no current flowing through the series model (i.e. the coupling portion). So in that condition, we can assume the series model does not exist at all. The current flows into or out of the buffer at that point is considered as “common-mode” current. This common-mode info is than extracted from surface table and modeled as pull-up and pull-down IV. The whole surface is then shifted vertically by subtracting this common-mode current at every x/y grids. The resulting surface table is considered as the differential current (resistance portion of the series model) and will affect the output when voltage at N and P are different. Note that to satisfy the aforementioned assumption of zero current through series element at common mode voltages, the sweep done at the P/N pins must step very slowly such that the charging/discharging of the reactive components, such as C_Comp or C_Diff can be neglected.
  • PC/GC: Clamp table in IBIS are always optional. On the other hand, when a circuit have current which always exist and can’t be turned-off, these data must go to PC/GC to avoid being double counted. That is, the PC/GC table must account for current which always exist and this current will be subtracted from the PU/PD table during the modeling process to avoid being double counted. Situations like this include the ESD circuitry and/or pull-up portion of the half-differential buffer. For PC/GC extraction, common mode sweep like that for PU/PD needs to be performed while buffer is disabled (put into high-Z state). The common mode current will then be extracted as the PC/GC table. Differential mode current is disregarded as it has been accounted for in the PU/PD differential data.DiffDrvCDifExt
  • C_Comp/C_Diff: An important step here is to extract and compute the differential capacitance, C_Diff. This has to be done before VT simulation. It is because C_Diff will affect the transient state differential current, thus it must be accounted for before VT transient simulation. The extracted value will be part of the series element model by adding as C_series. In real design, the C_Comp and C_Diff are both frequency and voltage dependent. So an user can perform 2D sweep in these two dimensions and select a proper value for C_Diff. This formula to calculate c_diff/c_comp is shown above.
  • VT waveform: With both static (resistive) data being processed from PU/PD/PC/GC simulation, and the reactive data, i.e. C_Diff, computed from the C_Die simulation. these two info can then be modeled together to be eliminated during VT simulation. The considerations is that: once the effect of coupling part is removed, then the remaining data can be considered as single ended and model accordingly. Having that said, reader should realize that there are much more details involved in this step. For example, how do you model these data? Two approaches may be considered:
    • Use E/F/G/H control element: the surface data can be fit to minimize the mean squared error. Resulting coefficients are then realized using poly function or like of a control sources.
    • Create a series element: decide the proper components and then create a series element.

Interested user may find some study presented in IBIS summit, such as [this one]

As one can see, the modeling process for a differential buffer is not linear and a certain order must be followed. Inaccurate common-mode extraction will affect IV tables and cause dc-mismatch of the steady state. In addition, failure to extract C_Diff and model different current accurately will greatly impact the accuracy of the transient data. We will see how a modeling flow should take these into account and be validated easily. These are also design concepts behind our SPIBPro flow.

 

Optimization for PI: Layout synthesis & Cap selections

In system analysis, signal integrity is done in either pre-layout and post-layout phase. Power integrity (PI), on the other hand, deals with mostly post-layout data. Layout is usually generated manually and then simulated in time consuming 3D solving process. As a result, optimization flow for PI is quite different from that for SI and is also very problem specific.

Power Integrity:

Power delivery model

Power delivery model

Power integrity aims at providing “clean” voltage supply to active elements in the channel such as driver and receiver. A typical representation of power delivery network is shown above, it starts with the voltage regulation and includes the motherboard, the package, and the die itself. Due to the impedance associated with the power delivery loop, any current through this loop will cause a drop in the voltage available to the die. Current is supplied from voltage regulator ultimately but is also stored in the de-coupling capacitors on the conducting path.This drawing current (Icct or Iload) varies due to different number of buffers switching at different frequency or work load… This drop in the voltage at the die directly impacts the maximum operating frequency of the design. Thus a spec. must be provided and met for the droop voltage to assure design quality.

The impedance in the power delivery loop can be classified as both resistive and inductive. The resistive drop is proportional to the current through the loop while the inductive drop is proportional to the rate of change of current. It is desired to have small loop inductance as Ldi/dt will contribute to the droop. This inductive drop is typically countered by adding several stages of decoupling caps at various points in the power delivery network. This helps reduce the overall impedance of the power delivery loop over a broad frequency range.

The conducting paths are layout design, rather than spice-like electrical netlist. The decoupling caps are usually provided by external vendors (e.g. Murata) and the designer needs to decide where and how to place them. So a power integrity analysis usually includes the following aspects:

  • stackup, power via arrangement and pin out;
  • decoupling strategy, choice of location, number and value of caps

Optimization w/ Design synthesis:

The power delivery network is layout design solved with 3D field solver. If designs can be generated via rule-based synthesis, then the design cycle can be shortened and many designs can be generated in advance. A batch-mode like process is then used to solve for different PDN models for comparison and trade-off study.

antenna

Take the different on-chip antennas shown above as an example, they are specified with different geometry parameters so that software algorithms is used to synthesize the design quickly. Do so manually may not be accurate or efficient. For a PD design, the rules are much more complicated than just the geometrical based parameters. Nevertheless, best practice or experienced based rules can still be summarized so that algorithm can perform the following tasks automcatically:

  • Modify layer stackup thickness and material properties
  • Generate pin, nodes, traces and shapes on specific layer either based on net name or reference location to other (signal or power) pins
  • Generate (power) vias in certain pattern and connect to power/ground planes. Voids and proper pad-stacks are also generated as part of the process
  • Duplicate certain region of the design (template) to other area as a X-Y array
  • Perform DRC alone the way and generate warnings

The flow mentioned above is purposely built for a certain solver, it’s because different solver has its own definitions for different design object (via, traces, nodes etc) and the layout syntax is also solver specific. Nevertheless, this flow has great potential of shorten design cycle, permit design optimization via quick analysis of different design, and even reduce the needs for engineering layout resources.

Decoupling analysis:

Once decoupling strategy (land side caps and/or die-side caps) and corresponding layout is generated, a S-parameter for the PDN can be obtained via 3D field solving. With proper provision (not stuffing cap in advance in the design), this generated S-parameter may be used directly again and again for what-if decoupling analysis. If there is no layout/stackup change, 3D solving does not need to be repeated.

CapEff

As shown above, different combination of caps “stuffed” at the output ports will cause impedance seeing into the die ports to vary. Conceptually, one may simulate the given S-parameter with cap connected and measure the impedance using simulation in frequency domain. In practice, such simulation is not needed as S-parameter can be converted into Y/Z-parameters and lumped together with cap’s FD impedance and be analyzed directly. As a result, we can post-process the PDN’s S-parameter for a certain decoupling cap arrangement to gain the following insights very quickly:

  • The impedance (both inductive and resistive) of the PDNLac
  • Current contributed by each de-caps at certain frequencyZIAC
  • Input impedance seen at each die-portZf
  • Effective analysis: by removing a particular de-cap, how much impact does it have to the die’s impedance.ZFCIF
  • How does this compare to different configuration: repeat the same “what-if” analysis for different configuration.

Optimization for SI & PI: Systematic approach

In previous post, we talked about exploring solution space linearly using what-if analysis. When more comprehensive or a near global search for best/worst performance is desired, a systematic approach must be used.

Response surface modeling (RSM):

System output responses Y1, Y2 shown below may have both controllable and uncontrollable input variables X and Z. In system analysis, the output is obtain via circuit simulation mostly and is thus deterministic. As a result uncontrollable factors maybe lumped into constant term and the mapping between controllable factor, X, to its output can be viewed as a multi-dimensional surface like shown in the right below. Search of optimized combination is like searching for maximum or minimum on the curvature.

doersm

This type of “mapping” from x to y is called “response surface modeling (RSM). It takes many sampling points to construct such response surface. A design of experiments (DOE) method is often used in this RSM approach.

Design of experiment (DOE):

When more than several variables are involved and each of them has a range of possible values, using full grid (full combination)  to do exhaustive search for best combination is really not feasible.

If a performance measurement, Y, is represented as a function f(x) of design variables x1, x2 ~ xn, then we can use a Taylor series to approximate f(x)

The higher order (bigger value of alpha above) to be included as part of the series, the more accurate it will resemble the original function f(x). It’s a little like decomposing time domain square wave in frequency domain using FFT. In system analysis, just like in many phenomenons in real world, f(x) is dominated by lower order terms. Take two variable and two order maximum as an example, the equation above can be further simplified as the following quadratic form:

quadraeq

Different value of input variables (X1, X2.. etc) will have different output performance Y. When more than several sampling points are taken, then the equations can be written as an matrix form, each row represents a sampling run:

quadramtx

When further generalize to all the variables, a linear system is formed:

DOERSMMtx

With this, one can use linear algebra technique such as pseudo inverse and/or singular value decomposition to solve for coefficients beta such that the error is minimized (optimized) in the mean squared error (MSE) sense.

modelfit

Using this DOE/RSM methodology, several decisions needs to be made in advacne:

  • Selection of input variable X and order: only dominate variables should be used to minimize the number of columns;
  • Selection of output target Y: output target obtained by mathematical operation (post-processing) may loose the lower order relation to original variable x;
  • Choice of sampling algorithms and number of samples: each row of the matrix corresponds to a “simulation” run, the samples must cover enough design space to make solution meaningful while minimize impact due to the noise of modeling.

DOE analysis flow:

A systematic optimization flow based on DOE/RSM thus includes the following steps:

  • Define variables: only dominate variable should be used in the analysis. A trivial variable will increase the matrix size and have very small coefficient (beta). The selection of dominated variable may be identified from experience, previous analysis run, linear sweep or what-if analysis. The DOE flow may also be performed several times, with non-significant variables being removed at the end of each iteration.
  • Create sampling points: There are several sampling algorithms when choosing sampling points. The choice should be made based on design’s coverage, optimality and efficiency. For SI/PI, when number of variables is around 10, central composite design is a good choice as it is full quadratic with only about 1000 design to run. D-Optimal is a good choice when number of variables is bigger (up to 30). When using neural network for final modeling, full quadratic is not needed and a space filling type design is a good choice. All these designs are available in statistic software package and subset of them have been implemented in our MPro module.

Design

  • Create corresponding test cases: Regardless of the design, a variable’s range needs to be decided. Depending on whether a variable is categorical (non-continuous) or numerical (continuous), possible step value may be decided. A generic representation usually use -1, 0, and 1 in the design table to represent minimum, typical and maximum variable values. Then next step is to translate such settings into corresponding design. For netlist type circuit representation, pattern replacement is sufficient. For geometric synthesis which require further mathematical manipulation using these design variables, a more flexible mapping mechanism should be provided. At the end of the stage, each row of the design table will be translate to a corresponding circuit design in order to be simulated.

Collect

  • Simulate and post-processing: A simulation manager is often desired in this step in order to distribute testcases to run on different CPU threads or different machines. A post-process step is executed right after simulation ends to extract performance matrices from the results. Outcome of this step is a row of output measurement for each test case run.

SimMgr

  • Map inputs to outputs:  Form a second or third order equations using defined independent variable, then solve for their coefficients using SVD solver. Residues values which is difference between original response and “predicted” one based on solved formula can then be calculated. A well fit model will have very small residue. A R^2 value, which is the portion of variation attributed to the model can be used to indicate the fit. A R^2 >= 0.95 is usually desired.

modeling

Prediction

  • Optimize: Constraints such as non-negative value and must fall within variable range needs to be imposed. Based on these restriction, solution to minimize or maximizing a cost function, which can be weighted sum of several performance targets, can be searched. Depending on the order of the prediction formula constructed, different type of optimization method can be used:
    • Linear programming: good for formula with only first order variable, which is usually the case for stackup performance based on geometric parameters;
    • Non-linear method: when formula has higher order terms, method like Nelder algorithm may be used;
    • Genetic algorithm: when model is highly non-linear or neural network based, this algorithm is best to search for optimized solution.

Optimize

  • Prune variables for next iterations: As the variables’ coefficients reveal their significance toward the output Y, some of them may be removed for next iteration analysis. A significance list may also be formed as a reference in the design process.

As one can see, a systematic flow such as DOE/RSM requires much more efforts and intermediate steps comparing to a simple linear sweep or what-if analysis. On the other hand, a well fit prediction model can also be served as a base of quick “what-if” analysis to replace time consuming simulation and be used as an initial guidance when using design variables.

A stackup what-if based on model built via DOE/RSM flow

A stackup what-if based on model built via DOE/RSM flow

 

Optimization for SI: What-if analysis

Optimization for system performance:

For electrical analysis such as signal integrity, a “system” is usually defined from end to end, i.e. from IO buffers of an IC, going through passive interconnect such as package, traces and vias, then connector or package again down to final receiver. There are many components involved in such a channel. Each of them has their own design parameters, so there are many factors affecting this system’s performance. In addition, there are also different performance matrices, such as eye height, width and timing margin etc. There maybe trade-offs between these performance targets. For example, the largest eye width may not produce the largest eye height, so either one is more preferred than the others or a weighting scheme needs to be used.

Selection_006Sources of noise affecting performance:

While the end goal is to maximize desired performances, they are actually affected by several electrical functions in the form of noise sources. We can imagine variables from individual channel components as x1, x2 ~ xn, these noise function g1(x1, x2), g2(x1, x3..) etc are part of performance function f(g1(x), g2(x)…) = f(x1, x2 ~ xn). This partition usually makes connections between variables and the noise response, i.e. x1, x2 to g(x), more meaningful and easier to understand. Not doing so, the big system function f(x) will have all variables lumped together. Another considerations is that many of the variables are orthogonal to each other, so by lumping strongly coupled ones into same g(x) functions, we reduce the efforts required to search for the whole solution space.

In a system, sources of noise can be categorized roughly as the followings:

  • Inter-symbol interference (ISI): this is usually caused by signal dispersion along the channel and the reflections due to impedance mismatch. A symbol (lone 1 pulse) starting as a nearly square wave at the driver may end up as a distorted one at the receiver due to this interference with itself.
  • Cross channel interference (CCI, or crosstalk): This is caused by inductive and/or capacitive coupling between victim and aggressors, they are mostly dominant at higher frequency and are very material and geometry (relative distance) sensitive. Componentwise, they maybe from on chip source (mainly capacitive) and off chip such as transmission line or vias etc.
  • Power supply noise: Different workload of the buffers may affect the terminal supply voltage. For example, when all buffers are driving, current supply may be limited and thus voltage will drop, and the slew rate will change accordingly as well.
  • Random noise: This is due to thermal noise (usually Gaussian distribution) or other jitters.

By exploring relations between x and g(x), it will help achieving end goal of optimizing f(x).

 

Optimization approaches:

Giving so many variables  (x1, x2 ~ xn) and either intermediate (g(x)) or final performance (f(x)) functions, how do we find the best xi values such that f(x) will be optimized (either maximize or minimize, by itself or weighted among several f(x)s)?

A channel being designed must have a spec. to meet. Different industry standards such as PCIe GenX, HDMI, SATA, USB, DDR etc each has its own compliance matrices before the designed final product can be certified to use such logo. For a smaller design company or when time to market is a constraint, a designer usually only want to look for “a” solution rather than the best solution. For bigger companies which provide design guides, they may need to do full analysis to make sure even in the worst condition, their product will still functional properly when being used by other companies in their own designs. In addition, perform a “full analysis” usually requires lots of simulations so computing resource available also imposes a constraint. Generally speaking, there are two approaches for system optimization:

  • What-if analysis: In this approach, many of the design variables have been set to a “fixed” value and a designer linearly explore impacts of limited remaining variables to the noise function or performance. Since each variable is adjust linearly, it’s not likely global best/worst values can be found this way. On the other hands, this what-if flow has the following benefits:
    • Can run with limited computing resource;
    • Can find “a” solution more easily and quickly;
    • Can help a designer gaining more insights regarding a variable’s impact on the performance, thus help a better design in the future.
  • Systematic methods: This approach can be considered as “what-if” analysis in multi-dimensions. Much more variables are taking into account with their respective ranges of values (thus still not “global” strictly speaking). The following steps are then taken to find min/max solutions in such a multi-dimension design spaces. (They will be explained in more details in separate post.)
    • Create sampling points:
    • Create corresponding test cases:
    • Simulate and post-processing:
    • Map inputs to outputs:
    • Optimize:
    • Study non-fitted results:

More on what-if analysis:

What-if analysis explores solution spaces linearly and usually provides instant response/feedback to the designer, so the chosen variables should have dominate impact on performances and the channel setup should be simplified. If only ISI and CCI are considered, one may break the aforementioned channel and lump related variables into the following sections to explore individually:

  • Driver: driver’s strength, slew rate, supply voltage, EQ settings
  • Interconnect:
    • transmission lines: layer stackup and materials Dk/Df, trace width, distances and layout etc
    • vias: pad, anti-pad size, barrel width, back-drill etc
    • package/connectors: change of reference and reference impedance etc
  • Receiver: termination scheme and different terminator values, EQ response and settings etc.

Note that driver/receiver variables here are behavioral already rather than original design parameters such as transistor sizing, doping concentration etc. So a behavioral model like IBIS, AMI etc need to come into play. For interconnects, solving transmission line using 2D/2.5D solver based on their physical and geometrical properties are more feasible, comparing to solving those for 3D structures like vias or even connectors.  For these via/connectors, a simplified model may again need to be built and come into play for quick what-if analysis.

Via model into PI model

Via model into PI model based on TDR results

The trade-off:

We think the value of a signal/power integrity engineer is very much on his or her insights on the design variables involved and their impacts to system’s performance. Such insights can be obtained from direct what-if analysis and/or detailed study of prediction model constructed via systematic optimization approach. The pitfall of the later one is that, with established flow and design cycle constraints, an engineer may easily become a “simulation engineer”, who just execute the flow and produce report without detailed study or understanding of interaction between different design variables.

SPISim’s support for system optimization:

With the spirits mentioned in this post in mind, we have flows for both what-if and systematic approaches. In our XPro module, variables in simplified setup has been categorized in advance to explore their impacts on ISI, CCI and power:

Selection_008

IBISWIF

TLineWIF

Not only will they provide instant analysis results via built-in simulator, the final model can also be generated in place based on the variables’ values used. These features are not available on may other commercial offerings and will be valuable capabilities to a system engineer.

Simulator development: Modeling (S & P)

System channel is usually represented in S-parameters. They can be extracted in frequency domain using a 3D field solver, and/or cascaded stage by stage using tool like SPISim’s SPro. With LTI (linear time invariant) assumption, it’s possible to synthesize eye or BER plot of millions of bits using statistically analysis… using single time domain pulse for these parameters. However, it’s still often desired to be able to simulate the s-parameter in time domain for defined bit patterns. Thus, a system simulator like our SSolve must be able to support such requirement. In addition, one may also want to know the frequency response when given a broadband spice converted spice elements, such as via, package or connector models. So the reversed process, i.e. extract S-parameters from spice elements, is also often required. In this post, we will briefly talk about how these may be developed in simulator like SSolver.

S-Element… S-Parameters:

There have been many conference and journal papers proposing different methods of simulating S-parameter in time domain. However, at the most basic level, S-parameter can be considered as a transfer function or filter block. Thus DSP techniques can apply: transfer function multiplying inputs in frequency domain can be converted into time domain using convolution:

Convolusion

The time domain at the right hand side can be further separated into two parts: history up to this time point (integrate from -infinity to t=n-1) and the value at this particular moment t=n due to input. The first part is a constant as it’s already happened in the past and can’t be changed, the second part is, however, input dependent and must be updated within the “solve” and “stamp” hot loop inside newton iteration. When putting together, they form a Norton circuit form of I = Y * V + J where Y is value affected at this moment and J, a constant, is due to past history. This Norton form can then be “stamped” accordingly for matrix solving.

Interested reader may refer to the paper published by HP linked below for detailed explanations and math:

Integration of Transient S-Parameter Simulation into HSpice

The equation [18] and [19] is the aforementioned Norton equivalent circuit form and can be used accordingly.

The convolution method needs to update history with the solved results of this time step for next time step to be used. In addition, the basic convolution requires that the dt to be constant, thus a variable time step simulation will be greatly hampered by this requirement in terms of performance. So the convolution modeling has rooms for improvement.

One of the possible approach is using vector fitting technique mentioned in previous post about “W-element” modeling. With the S-parameter data in frequency domain, one may construct a Pade approximation using several poles and zeros. Then basis functions can be created for each of the pole in time domain and simulate accordingly. A benefit of this process is that the constructed form is a rational function which is guaranteed to be causal. So if there are issue regarding causality of the provided s-parameter, it can be fixed during the modeling process. Lastly, due to exact fitting of multi-port s-parameter across the frequency spectrum are not likely, some sort of error minimization (in the MSE sense) is needed to have a balance between accuracy and number of poles.

 

P-Element… Port element:

Often times after a package, connector or via modeling engineer created a model, he or she will use tool like broadband spice to convert such 3D extracted s-parameters to spice equivalent circuit composed of various basic elements. When a system designer or SI engineer receive such converted models, the original S-parameter may not be available already. Rather than insert this model into the channel and simulate blindly, it’s often beneficial to be able to reconstruct and inspect the model’s frequency domain response first before actually using them. S-Parameter extraction via simulation is basically a form of AC simulation, thus with AC model of the system elements constructed, the S-Parameter extraction part becomes easy.

The context here is small signal S-parameter extraction, thus all the AC signal is done very close to the operating point. That is, a DC solution needs to be obtained first for each port’s respecitve bias condition, then the AC stimulus is applied and solve for each frequency point.

A “Port” or “P-element” has several properties: dc bias condition, reference impedance, port-name and port-order. For a multi-port s-parameter extraction, one port is excited at a time with specified dc bias value. AC sweep is then performed while the other ports are terminated to their reference impedance. The power wave of input and output, measured and processed using current injection and nodal voltage measured, can then obtained for this input to the other output ports. Using simple math described in the link below:

S-parameter measurements

one can obtain S-parameter of Sij (i is port with input stimulus, j are the other ports) content easily this way. Repeat the same process for the other ports one at a time (with their respective dc bias condition) and the full S-parameter can be obtained. Finally, the order of ports are arranged according to the port properties, their respective port name are written out at the top of the touch stone file and the process is complete. Should there be needs to convert to other formats such as Y, Z parameter (sometimes good for checking connectivity), one can do so easily with formula (assuming generalized 2-N ports) or simply use developed tool like our SPro.

 

Back to the top:

Back from these modeling physics to the computer science domain, one also need to consider the following topics when doing simulator development:

  • Memory pool management (allocation, expansion and clean-up)
  • Multi-threading consideration
  • Plug-in architecture for future devices
  • ….

While the list can go on and on and the tasks may be daunting, the end results are definitely worthy to the analysis flow and methodologies development. With developed simulator, there is no longer absolute need to form a close-loop formula or equation in order to solve circuit equation. The module or flow running on top can simply create netlist and have this simulator solved for you. Not to mentioned this also make maintenance and testing much easier. For an EDA company like us, I would say this is a journey worth taking.

Simulator development: Modeling (B & W)

When modeling device for a circuit simulator, the raw netlist input needs to be converted into internal structure first, then a physical model is constructed during the “modeling” phase, and corresponding equivalent Norton or Thevenin circuits’ parameter are solved within each Newton iteration at each timestep. The solved parameters are finally “stamped”  into system matrix for Newton iteration solving. “Model” and “Solve” is the essential part of device modeling for a circuit simulator and that’s whey “Physics” come into play.

In these two posts, we will briefly talk about how system devices, in particular IBIS, Transmission line and S-parameter are “modeled” and “solved”.

B-Element… IBIS:

Looking at the IBIS’s structure, the modeling part is actually quite straight forward:

IBISEvolve

The four IV curve data: pull-up, pull-down, power clamp and ground clamp act like non-linear resistors. With terminal voltage known within each Newton iteration, the conductance can be look-up from these curve tables and obtained using linear interpolation.

The switching coefficients and composite currents are both time dependent. Their values are calculated in the “modeling” phase when simulation has not even started. The obtained coefficients is a multiplier which will further scale the conductance calculated for IV data and thus stamped value. These scaling are such that when test load specified in the waveform section is connected, driver at the pin will reproduce exactly the same waveform data given in the model. As to C-Comp, it can be inserted using simulator’s existing infrastructure so the integrator there will manage the stamping and error prediction.

The more complicated portion of IBIS modeling inside a simulator is due to the options available for the end user, thus model developer must plan in advance. For example, the c_comp may be split across different terminals. Each waveform, IV or components have different skews which book-keeping codes must take care of. There might be added submodel for pre-emphasis or de-emphasis so the class implementation-wise one should consider “composite” pattern such that recursive inclusion can happen. At the end, this is a relative simple device to model for simulator, particular when comparing to the transmission line.

 

W-Element… Transmission line:

Every electromagnetic text book will give transmission line structure as shown below:

RLGC

This is an uniform distributed model and is implemented early in various simulators as  the “U” element. While implements T-Line model this way is now outdated due to the performance issue, it’s still how the T-Line’s raw data, frequency dependent tabular model, are given:

TabModel

The tabular model are field solved of Maxwell’s equations based on layer stackup, trace layout, material properties and sometime special treatment (like surface roughness) and finally presented as R/L/G/C data at low (DC), high (Infinity) frequencies and many points in between. Thus to model T-Line for a simulator to use, one has to convert these data to a mathematical form first which can then be used in either time or frequency domain. For transmission line, this can starts with Telegrapher’s equations.

By solving the KCL/KVL of a unit length RLGC circuit above, one can derive and find the telegrapher’s equation:

And the solution to this equations, as explained in the wiki link above, involve a wave propagation function Gamma:

RLGCEq2

When realize this in the system model, it as the Norton equivalent circuit form:

So on each side (near end and far end) of the transmission line, there are two components: Z (admittance) at that particular time step and current source due to the propagation delay originated from the other end. These two components (Z(s) and r(s)) can be obtained from the tabular data in frequency domain and then converted to integrate-able form in time domain so that they can be “stamped”. Generally, it includes the following steps:

  • Parse and store the raw tabular model;
  • Calculate the propagation delay and characteristic impedance using highest frequency data (or using extrapolation), these value will be used for interpolation later in time domain.
  • Construct the Z(s) or Y(s) and the wave function r(s) shown in the system model. As transmission lines are usually coupled, these curves are multi-dimensional in frequency domain;
  • Using vector fitting technique to represent this frequency domain functions using series of poles and zeros. In most of the cases, particular when the model data has insufficient bandwidth or low quality, exact fit is not possible with reasonable number of poles/zeros and thus best fit in the minimum-square-error sense needs to be performed.
  • Once pole and zeros are found, they can be converted into time domain as different order of terms. All these terms combined together will form the Y(t) or r(t) in time domain. Pade’s approximation may be used here.
  • During time domain simulation, use interpolation to find r(t)’s value in the past history (propagation delay ago) and use that data to construct the equivalent model of this end at this particular time point.
  • For frequency domain analysis, vector fitting and conversion to integral form is not needed. The Y(s) and r(s) data can be used directly for stamping at this frequency with some interpolation.

For the first three steps, I wrote a simple matlab codes to demonstrate how how they are done:

Impedance function:MatlabY

Propagation function:MatlabH

Plots:PlotY

PlotH

While the matlab codes above seems straightforward,  most simulator (including SPISim’s SSolver) will program with native codes (C/C++) for performance consideration. So a whole lots of matrix operation (inverse, eigen value, LU decomposition etc) will also come into play during the process.

It’s rarely the case that the developed model or codes will work the first try. With so many terms (of converted poles and zeros) for so many dimensions (coupled cases), it’s a daunting task to figure out what has gone wrong when waveform is not as expected. It’s often simpler to back to basic: check steady state solution first, use one line, no reflection with by matching impedance at the other end, use characteristic impedance to find nominal reflection value and so on to help identifying the issue:

TLDebug

Interested reader may find more details about SPISim’s implementation, same as HSpice’s, in the following paper:

“Optimal Transient Simulation of Transmission Lines” by Dmitri Borisovich Kuznetsov, Jose E. Schutt-Aine, IEEE Trans. on Circuit and Systems, I Feb. 1996

In terms of book, I have found that Chap. 5 of Dan Oh’s “High-speed Signaling” book, S6 in our reference book section, give best explanations among others. This maybe because Mr. Oh is from UIUC around the same time when the paper was published as well 🙂 It also worth mentioning that similar technique can be applied to other passive, homogeneous device modeling, such as the system channel. For example,  one common approach of checking and fixing casual issue of a s-parameter is by using vector fitting and convert to rational function form.

Simulator development: Abstraction

In previous post regarding simulator development, we mentioned that simulator at its core is linear algebra (with or without relaxation) solving matrices formed to describe netlist’s nodal cutset (KCL) and mesh loops (KVL). We also mentioned that the “hot-loop” of circuit simulation are the “solve” and “stamp” routines, i.e., device solve modeling equations at that particular dc point or time-step then put contents into the aforementioned matrix formation. So a lot of thinking needs to go into formulating these two steps such that simulator developed is stable, maintainable and extensible.

On the p170 of the classic “Computer Methods for Circuit Analysis and Design” book, stamping for basic elements are listed:

Stamp

So the first level of abstraction, also the main work of “Solve” routine within each device, is to solve the modeling equations using terminal conditions (i.e. voltage or current) in a particular iteration, then translate into corresponding I, V, Y (admittance), G (conductance) then put into the circuit matrix for simulator to solve. In addition, because Newton method requires first derivative to progress and find next possible root, the “partial” value (first derivative of matrix) also needs to be computed by the device model and provide to the simulator accordingly. Without this, simulator will need to perform numerical derivative (auto-partial) to call “solve” and “stamp” routine multiple times in order to find the derivative dV/dI, or dI/dV etc at that particular terminal conditions. This will result slowness and instability of the circuit simulation.

Each device, regardless how non-linear it is, may be “linearized” to simple equivalent circuit under certain condition. This “certain condition” can be fixed time point, or fixed terminal condition like voltage supply. That is, within each Newton iteration (thus only belong to that iteration and that time point), one may transform non-linear device model into a simple linear equivalent one. Mostly using Norton or Thevenin theorems:

EqCkt

As to how to represent a device model into such linear circuit depends on the device’s physics. In my mind, this is where (device) physics comes into play in the simulator development.

For example, for simple elements like R, V, I, one can simply “stamp” entries by the book. Control sources can also be considered as (controlled) conductance, admittance and “stamp” accordingly. Complicated devices such as transistor, transmission line or S-parameters certainly need some mathematical derivation in advance. Katzenelson algorithm may be used in some condition to solve PWL network. Even devices like L and C also needs special consideration, such as numerical integration and prediction.

LCDev

The derivative forms for C and L above show that there is no direct solution to find L and C’s conductance or admittance in time domain. So numerical differentiation approach like Backward Euler may be used to calculate conductance value based on circuit history, i,e, result of previous time steps. If this is a fixed-time step simulator, then task will be easier. A variable time step simulator will certainly need much more consideration: how big a time step can be taken, what is the integration or resulted differentiation error etc. Even within device level, such as transmission line and s-parameter, the device it self also must keep track of past history so that reflection from the other end will happen at the right time.  From the discussion up to this point, it should be convincing that the simulator development requires multiple disciplines.

CapCode

The second level of abstraction happened at the architecture level. There are only 26 English characters but there are much more for device types… some may be even custom made like antenna or macro circuits. So while elementary devices like R, L, C, I, V, E, F, G, H etc all have their own prefixes in the netlist, a mechanism must be in place such that the simulator can support more (some future) devices. This is mostly done using dynamic link library with predefined interfaces and access. The example below is API from Berkeley spice:

PortType

By defining these port types and access functions, the simulator limits the device’s accessibility to its internal structure and even matrices, thus can be more stable. At the same time, the defined interface also allows extensible for future devices. It is thus the device designers he or she needs to map the device under modeling to the limited, predefined interfaces such that the data can be used by simulator at the top and simulate accordingly.

After all these are sorted out, then the remaining part of the simulator development is to figure out physics of the devices, construct a model, realize that model using numerical techniques, solve and extract equivalent’s values at that particular time and iteration, and pass the data back to main caller functions then wait to see whether this solution converges for this iteration. If so, then perform book keeping either for future time step reference, or predict maximum time step simulator can take based on device’s limitation (e.g. break point in PWL sources or transmission line delay).

In SPISim’s SSolver, we reference the Berkeley architecture profoundly and focus more on the device modeling and integration. Existing spice does not have support of any devices required for system analysis, such as IBIS, Lossy coupled, transmission line, S-parameters. Even S-parameter extraction is also very tedious and limited to only two ports originally. While our experience in the past enables us to grasp the simulator architecture easily and build up functionalities much quickly, it is still respectful for us when reading the relative document and source codes when the Berkeley team developed such simulator in the first place several decades ago.