Two for One: Leveraging SerDes Flows for AMI Model Development

Transcription

1 DesignCon 2016 Two for One: Leveraging SerDes Flows for AMI Model Development Ren Sang Nah, MathWorks Corey Mathis, MathWorks Richard Allred, SiSoft Todd Westerhoff, SiSoft

2 Abstract This paper presents the authors experiences leveraging SerDes design flows to create IBIS-AMI models for system level simulations. Simulink models are used at the outset of a SerDes design effort to define a SerDes architecture and control loop behaviors. Design goals for different blocks (e.g., peaking filter curves) are established at this stage. If this information can be used to efficiently create IBIS-AMI models, customer design-in activities can proceed in parallel with SerDes circuit design, providing valuable feedback on whether the intended design targets will allow customers to achieve their system performance goals. This requires fast and efficient creation of IBIS-AMI models, without requiring extensive code changes that can cause AMI model development to become a project by itself. This paper discusses the effort required to create an IBIS-AMI receiver model including CTLE, DFE, and CDR behavior. The performance of that model in commercial EDA simulation tools and correlation to lab measurement are also presented. Authors Biographies Ren Sang Nah, Principal Pilot Engineer at MathWorks, is focused on modeling and code generation using the Simulink product family. His primary role is to help MATLAB users adopt Model-Based Design via pilot program engagements. Ren has more than 14 years of experience driving the adoption of MathWorks code generation technologies. He holds a B.S. and M.S. in aerospace engineering from Texas A&M University, specializing in guidance, controls, and astrodynamics. Corey Mathis, Industry Marketing Manager at MathWorks, is responsible for the communications, electronics, and semiconductor market segments. Prior to joining MathWorks, Corey managed a global automotive sensors business at Sensata Technologies, and spent nine years at Agilent Technologies in a variety of roles including applications engineering and business development. Corey has an MBA from Boston University and a bachelor s in electrical engineering from Union College in Schenectady, NY. Richard Allred, Senior Staff Engineer at SiSoft, is responsible for creating high quality IBIS- AMI models of SerDes transmitters and receivers that support both statistical and time-domain simulation. He works closely with customers to ensure that models correlate well with lab measurements. Richard also develops new modeling and simulation techniques as part of this effort. Prior to joining SiSoft, Richard designed and analyzed serial and parallel computer interfaces for Inphi and Intel. He received his MSEE from the University of Utah and has five publications. Todd Westerhoff, VP Semiconductor Relations at SiSoft, has over 36 years of experience in modeling and simulation, including 19 years of signal integrity experience. He is responsible for SiSoft's activities working with semiconductor vendors to develop high-quality simulation models. Todd has been heavily involved with the IBIS-AMI modeling specification since its inception. He has held senior technical and management positions for Cisco and Cadence and worked as an independent signal integrity consultant. Todd holds a B.E.E.E. degree from the Stevens Institute of Technology in Hoboken, New Jersey. 2

3 1. Background Systems designers using the latest technologies need to make architectural tradeoffs and key design decisions long before silicon is available. For high-speed serial links, channel simulations using IBIS-AMI models are used when simulation models are available. Unfortunately, IBIS- AMI model development often occurs after the fact, in a different group from the one actually designing the SerDes, and only once detailed implementation (as in SPICE) or lab measurement data is available. This happens because most SerDes designers approach the creation of IBIS-AMI models the same way many of us approach personal income taxes with reluctance, procrastination, and dread. When IBIS-AMI model creation requires rewriting or changing key parts of the code used for SerDes design, engineers naturally put that task off for as long as possible. The gap between SerDes design and AMI model creation is large and won t close unless the fundamental model creation process can be changed. Finding a way to incorporate IBIS-AMI modeling as part of the SerDes design flow can help ensure that a SerDes design meets real-world customer needs. Allowing internal and external customers early access to SerDes models while detailed implementation is still in process helps ensure the design is fine-tuned to the final application, thereby providing SerDes designers with the insights that broad system level analysis brings. This paper presents the results of a collaborative effort between MathWorks, SiSoft and a major semiconductor vendor to leverage the SerDes design process for IBIS-AMI model generation. This effort involved the use of Simulink from MathWorks for SerDes design and exploration, and Quantum Channel Designer (QCD) from SiSoft for AMI model validation. AMI model generation was performed with a pilot support package (PSP) from MathWorks that configures Simulink for IBIS-AMI code generation [1]. The AMI model generation flow evolved over the course of this effort and we present the process in its current form, along with areas for future investigation and improvement. We present the process and tools we used generically where possible, using the term AMI simulator to represent our IBIS-AMI model validation environment (QCD in this case) and the terms architectural model and behavioral simulator to refer to our SerDes design and analysis environment (Simulink and MATLAB in this case). We use the term IBIS-AMI to refer to the complete IBIS-AMI model, and the term AMI when we are referring just to the algorithmic (compiled) part of the model and its associated control (.ami) file. 3

4 2. SerDes Design It is helpful to frame the SerDes design process in terms of both architectural and implementation models. An architectural model is one that is initially based on back-of-theenvelope calculations, industry specifications, and previous SerDes generations. Architectural models are used to validate key design decisions and establish budgets for the implementation of individual sub-blocks. Architectural models are also great for evaluating control loop behavior and block level tradeoffs. An implementation model is one that reflects the actual silicon implementation as closely as possible and is a snapshot in time of the SerDes design. The implementation model can be a mixture of RTL code, gate level detail and individual analog circuits, depending on the SerDes architecture and the level of detail being represented. Some SerDes design teams choose to evolve the architectural model into to the implementation model by replacing the initial architectural blocks with their more detailed counterparts as the design progresses. Mixed level simulations are used to validate that the detailed blocks function properly in the overall design context. Other SerDes design teams maintain a clear boundary between architectural and implementation models, keeping the architectural model as the spec that the implementation team designs to. In these cases, the individual blocks are characterized after implementation and their architectural counterparts are updated to reflect the implemented behavior as closely as possible. 3. Guiding Design-in Efforts Once a SerDes architecture has been established, designers may need to create simulation models that can be used outside the SerDes design environment. This can occur for multiple reasons the designers may want to run the proposed SerDes design against a large number of test channels in an automated batch environment. They may need to provide models of the proposed SerDes to internal or external customers to evaluate in the context of their system designs. Providing simulation models to key customers before first silicon helps secure design wins and can provide valuable feedback about features needed in the design. Where practical, IBIS-AMI is a logical choice for providing simulation models to users, since IBIS-AMI models can be run in multiple simulation tools and mixed with simulation models from other vendors. Most system designs use more than one vendor s components, making it necessary to validate how well the new SerDes design works with other parts in a system context. The challenge is creating IBIS-AMI models for an evolving SerDes design in a practical way creating the code for an IBIS-AMI model without turning IBIS-AMI model generation into a big project in its own right. The demand for user simulation models exists as soon as the SerDes architecture has been defined and continues through the lifecycle of the SerDes. Thus, it may be desirable to create an AMI model from either the architectural or implementation model branches at any point in the SerDes lifecycle. Of course, customers always want simulation models that reflect the final silicon implementation as closely as possible. The conventional thinking is that this may allow exploitation of implementation-specific features to boost design performance. However, silicon typically goes through multiple spins on its way to production, tuning device performance and design yield along the way. Thus, detailed silicon-accurate models can be a liability if customer 4

5 designs are tuned to reflect pre-production silicon behavior that is not guaranteed. In such cases, architectural performance target models may be preferred, as they represent the intended performance of production silicon instead of a current implementation snapshot. Having customers run simulations with these models provides more predictable behaviors for silicon design-in. One additional benefit is that architectural models also run faster than their implementation-specific counterparts, since they have less design detail. This paper discusses the use of architectural models to create IBIS-AMI models for customer use, both inside and outside the semiconductor provider. The development of implementationspecific models and resolving their behavior against the architectural model is a key part of the overall process but outside the scope of this paper. 4. An AMI Model Primer IBIS Algorithm Modeling Interface (IBIS-AMI) models have two parts an analog model and a corresponding algorithmic model. The analog model is used by the simulator to derive the impulse response of the analog channel, which consists of the TX analog output impedance, the passive interconnect for the channel and the RX termination network. The analog model is defined by tabular text data contained within the model s main (.ibs) text file. The algorithmic model is used by the simulator to represent the SerDes equalization and clock recovery behavior. The algorithmic model is supplied as compiled executable code (.dll or.so) that gets linked into the simulator at runtime, and a text control (.ami) file that documents the simulation methods the model supports and the control inputs the model responds to. More details on IBIS-AMI models and how they are used by EDA tools can be found in [2] and [3]. For algorithmic model creation purposes, we need to focus on how the algorithmic code gets linked into an AMI simulator at runtime and interacts with the simulator to model SerDes equalization and clock recovery behavior. The algorithmic model can be as simple or as complicated as the model maker desires, but the way that the model interacts with the simulator always remains the same. The boundary between each algorithmic model and the simulator is an application programming interface (API) defined as part of the IBIS Specification [4]. This API provides three entry points that simulators use to pass data to and from algorithmic models: AMI_Init is always present, only called once, and always used to pass control information (parameter settings) into the model. When you specify the TX tap settings you want to use for simulation, they become part of the data passed into AMI_Init. This entry point can optionally be used to model linear and time-invariant (LTI) equalization behavior. The simulator passes in an impulse response waveform and the model adds its equalization to the impulse response and passes it back. For an AMI model to support statistical simulations, the model must equalize the impulse response passed in by the simulator using this method. 5

6 AMI_Getwave is an optional entry point. When present, it is called multiple times to allow the simulator to pass in waveform data that the model applies its equalization to and passes back. Waveform data is passed in blocks the simulation waveform is broken into pieces, since processing the whole waveform at once would be inefficient from a memory and compute standpoint. When an RX is being modeled, Getwave processing can also return clock ticks to the simulator from the simulated CDR. Clock ticks are returned for times ½ UI before the sampling latch is triggered. Effectively, this marks the start of each UI from the sampling latch s viewpoint. AMI_Close is always present and only called once. It tells the algorithmic model to clean up shop finish processing, output any final data, and release any memory that the model has allocated. The AMI API is defined in the C programming language. The exact data passed back and forth is defined as follows: long AMI_Init (double *impulse_matrix, long number_of_rows, long aggressors, double sample_interval, double bit_time, char *AMI_parameters_in, char **AMI_parameters_out, void **AMI_memory_handle, char **msg) long AMI_GetWave (double *wave, long wave_size, double *clock_times, char **AMI_parameters_out, void *AMI_memory) long AMI_Close(void * AMI_memory) Getting into the details of these variables is beyond the scope of this paper; however, we wanted to outline the data passed between the simulator and AMI models. When the algorithmic model equalizes impulse response data (AMI_Init), an EDA simulator can generate statistical eyes and waveforms for time-domain simulation through convolution. Because AMI_Init is only called once and only one impulse response is passed, adaptation and clock recovery behavior cannot be modeled literally. A model processing impulse response data can predict the final, settled value of equalization and clock recovery loops and then create the corresponding impulse response, but it cannot model the intermediate states and the settling process itself. Algorithmic models that process impulse response data are often referred to as linear, time-invariant or LTI models. 6

7 When the algorithmic model equalizes waveform data as part of a time-domain simulation, the AMI simulator can accumulate persistent eye diagrams by compiling eye statistics for each data bit. Bit by bit, or Getwave, processing allows the adaptive behavior of equalization and clock recovery loops to be modeled literally. These models are often referred to as nonlinear, timevariant or NLTV models. Unlike SPICE, AMI simulations utilize impulse and waveform data with a fixed time step. The ratio between the data unit interval (bit_time in AMI_Init) and the fixed time step (sample_interval in AMI_Init) is the waveform oversampling ratio, often referred to as the samples_per_bit setting. The AMI model developer s task is therefore to create code that takes in waveform data (impulse response or bit by bit) with a fixed time step, determines what equalization should be applied, and then writes out updated waveform data. The final result should approximate the behavior of real silicon as closely as possible. Creating IBIS-AMI algorithmic model code therefore requires considerable skill in: 1. Software programming 2. Applying signal processing techniques in sampled data systems 3. Semiconductor circuit design 4. AMI simulation and debugging Not surprisingly, there aren t many people who can create high-quality AMI models from scratch. Those who can were probably already deeply involved with the development of internal models and simulation tools, and as such, AMI models represent a different form of applying skills they already have. The challenge is to find an effective way to leverage the data that already exists in a typical SerDes process for AMI model generation, in a way that allows models to be generated at different points in the SerDes design cycle, without incurring substantial impact on the project. This is not to say that AMI model generation should be a simple, push-button process that requires little AMI knowledge. The goal is a modeling flow that allows a SerDes designer to convert an existing SerDes representation into an AMI model and validate it with a reasonable amount of effort. We assume that the designer will have a good understanding of IBIS-AMI and how IBIS-AMI models are used by commercial AMI simulators. It s worth reiterating that an AMI model consists of an analog model and an algorithmic model, both of which have to be designed to work together to model the device in its entirety. The analog model represents certain characteristics of the device, most notably frequency-dependent insertion and return loss. The partitioning between the analog and algorithmic models has been a source of much confusion, often resulting in idealized analog models that don t represent insertion and return loss correctly, or AMI models where analog effects are double-counted and produce pessimistic results. A process that allows the analog and algorithmic sections of an AMI model to be developed and validated together should be a fundamental part of any IBIS-AMI modeling environment. 7

8 5. SerDes Architectural Exploration Semiconductor companies have internal simulation environments that SerDes designers use to model, refine, and validate design ideas. These environments usually combine commercial modeling and simulation software with custom libraries and tool flows. For this effort, we used Simulink from MathWorks for SerDes architectural modeling. Simulink provides a block diagram environment that supports multi-domain simulation, automatic code generation, and continuous test and verification of embedded systems. The combination of discrete-time and continuous-time component libraries, along with a fast variable step ODE solver, allows SerDes designers to interactively explore various architectures and design alternatives. An example of a complete end-to-end serial link model is shown in Figure 1. This model represents a 10 Gb/s SerDes TX driving a forward channel with a crosstalk aggressor. The channel models are created from a rational fit of measured S-parameter data. The receiver is modeled using both analog and digital equalization, with clock recovery and 8b/10b decoding used to recover the data. Figure 1. An end-to-end architectural model for a 10 Gb/s serial link. From an IBIS-AMI standpoint, this block diagram includes both the TX and RX models as well as the channel model. Before we generate AMI code, we will need to define the individual boundaries of the TX and RX models, as IBIS-AMI simulation requires these models to be provided independently. In our effort, we found it useful to create a test bench block diagram for each individual AMI model, as shown in Figure 2. This proved useful in correlating the architectural and AMI models and is discussed in more detail later. 8

9 Figure 2. A test bench for AMI model generation and correlation. SerDes architectural models are typically modeled at the behavioral level, while detailed circuit level capture and synthesis is later performed in EDA tools that also drive physical layout and post-layout extraction. The architectural model provides golden reference behavior for each block to the designers responsible for implementing those blocks. At appropriate points in the design process, individual blocks are characterized and the corresponding behavioral blocks in the architectural model are updated to reflect the current implementation. Increasingly, SerDes equalization is driven from the digital domain with components like FFEs and DFEs. The architectural model provides an opportunity to streamline algorithm development by converting certain digital equalization blocks into fixed-point implementation versions in VHDL and Verilog. Figure 3 provides an example of a basic FIR DFE equalizer translated to VHDL for the purpose of driving a gate level implementation. Figure 3. Fixed-point FIR DFE and auto-generated VHDL. 9

10 Creating IBIS-AMI models for system level analysis involves a similar process. Instead of an HDL target, we direct the process to produce portable ANSI C or C ++ code and configure it for a particular embedded application, namely AMI. The embedded code generation process creates extension files or wrappers needed by specific software environments. In this case, it interfaces the generated C++ code to the AMI API we identified earlier, as well as creating the.ami control file that goes with the algorithmic model. The.ami file identifies what type of equalization the algorithmic model supports and declares the model parameters the user can set for AMI simulations. This process is shown in Figure 4. Figure 4. Behavioral model generation for IBIS-AMI. There are several preparatory steps required when creating an IBIS-AMI model from a Simulink block diagram: 1) Specifying the code generation target 2) Configuring the solver 3) Selecting the appropriate subsystem 4) Specifying tunable (AMI) parameters The code generation target tailors the steps of code generation, compilation, and linking for a specific purpose. The IBIS-AMI Pilot Support Package sets up various parameters such as the AMI version, the AMI model type (LTI/Init or NLTV/Getwave), the number of crosstalk aggressors the model should support, and so on. The user interface for specifying these parameters is shown in Figure 5. 10

11 Figure 5. Specifying the code generation target. The AMI model type the user chooses is determined by the elements in the Simulink block diagram or the MATLAB code. When the architectural model is linear (as in TX models with basic FIR filtering), the model type should be set as LTI (Init_Returns_Impulse). The AMI simulator can generate time-domain waveforms through convolution, and when there are no nonlinear or time-varying behaviors represented, there s no advantage to creating an NLTV (Getwave_Exists) model. When the Simulink block diagram includes adaptive control loops, saturation blocks, or active CDR models, the AMI model type should be set to NLTV (Getwave_Exists). Specifying the AMI code generation target for a particular block diagram will restrict the choice of solver to one of the fixed-step types shown in Figure 6. Figure 6. Configuring the Simulink solver. Note that choice of the ode3 solver in this example, as opposed to the discrete solver, means that the block diagram can include blocks with continuous states, such as the transfer function or continuous integrator block. The solver algorithms will be included with the generated code to handle the conversions between the continuous-time elements in the model and the sampled time format used by IBIS-AMI models. 11

12 When selecting a subsystem for AMI code generation, the primary consideration is to make sure it has a single input and single output. Inside the subsystem there can be blocks with multiple inputs and outputs, with continuous or discrete states and sample times, operating under control of triggers or enables, connected in feedback loops, etc. We have a mixture of all of these in the example of a receiver subsystem shown in Figure 7 below. The important thing is to ensure proper behavior of the subsystem at the boundary, which defines the interface of the generated AMI model. Figure 7. A subsystem suitable for code generation. It is important to distinguish between signals and parameters in the block diagram. Signals are designated by directional lines connecting the blocks. Parameters are specified in the block mask (properties dialog), such as the one shown in Figure 8. Values for parameters can be set to fixed numerical constants, assigned to a MATLAB variable, or in some cases, determined from the block diagram connections, such as inherited sample time designated by the value -1. Figure 8. Specifying parameters in Simulink. 12

13 At the code generation step, fixed parameter values allow for as much code optimization as possible. In the case of AMI models, we want the ability to set model control parameters at IBIS- AMI simulation runtime. We designate those parameters in the block diagram as global parameters prior to code generation. The example shown in Figure 9 illustrates the process for designating parameters as tunable in the compiled AMI model. Figure 9. Specifying tunable parameters. These parameters will also be declared in the model-specific" section of the model s.ami control file. The code generation process for the IBIS-AMI target produces the compiled library function (.dll or.so, depending on platform), the.ami file, and a text file that contains the algorithmic model reference for the.ibs file. 13

14 6. IBIS-AMI Model Development Flow The partitioning of an IBIS-AMI model between analog and algorithmic sections is problematic. The analog and algorithmic models need to be designed to work together, but the hypothetical boundary that IBIS-AMI assumes (the high impedance node ) doesn t always exist in real designs. One possible solution is to start with the analog model, then design the equalization behavior based on that, such that the correct composite response is produced. The analog model doesn t need to be complete to start with; an assumption will do, since the analog model can be refined as the design progresses. For our efforts, we partitioned the IBIS-AMI modeling process between the architectural model and the AMI simulator as in Figure 10. Figure 10. IBIS-AMI development flow. Thus, we leverage the natural strengths of the AMI simulator analog and complex channel modeling to create the input waveforms for our architectural equalization model. We also save the output waveforms from the architectural model for reference, so that when we load the compiled AMI model into the AMI simulator, we can compare the AMI and architectural behavior to ensure the model is behaving identically. In Figure 1, we showed an end-to-end serial link analysis with the TX, channel, and RX all part of the block diagram. In the flow we have just described, we have rearranged that partitioning so that the architectural model is focused around the AMI model we want to compile. Figure 11 shows the relationship of these two different methods. 14

15 Figure 11. IBIS-AMI development flow: analog and algorithmic partitioning. We also use the IBIS-AMI simulator for batch and regression testing. We do this because the AMI simulator excels at large swept-parameter runs and automated extraction of simulation results. We set up tests for large numbers of reference channels and simulation conditions, running them using the compiled model in the AMI simulator. This can involve hundreds or thousands of cases, which can be run on a compute farm. The AMI models typically run 5-7x faster than their architectural counterparts and the AMI simulator allows us to run simulations in parallel on a compute farm, so we can perform large test runs x faster than we could running the same simulations using the architectural model. Test cases that fail to meet performance targets are identified and the corresponding test setups are created so the behavior can be investigated and debugged in the architectural modeling environment. While IBIS-AMI was originally adopted by semiconductor vendors as a means of sharing protected IP with their customers, many silicon providers are also using IBIS-AMI models for internal design purposes. Manufacturers designing both the SerDes and reference PCB designs can create an AMI model that can be given to the PCB designer. This allows a PCB solution to be verified before silicon tape-out, potentially optimizing the SerDes based on the target application. SerDes designers can expose additional model parameters to their internal PCB design teams that are not exposed externally. System-level AMI simulations can be used to establish key SerDes design decisions (such as control loop delays and equalization limits) that will be locked down in final silicon and in models released to external customers. 15

16 7. A Simple AMI Transmitter Let s walk through the IBIS-AMI model generation process with a simple model a four tap TX FIR filter, with one precursor and two postcursor taps. To make the model a bit more interesting, the model automatically scales the input tap values so the sum of their absolute tap values is equal to one. The block diagram for our transmitter is shown in Figure 12. Figure 12. TX FIR filter architectural model. The tap normalization logic is in the lower left corner; the delay line and tap summing logic is on the right. The logic in the top left takes the values of bit_time and sample_interval passed in during AMI_Init to compute the samples_per_bit setting being used in the simulation. This value is then used to adjust the length of the delay elements so they each delay the signal by exactly one UI. 16

17 The top level of the block diagram is shown in Figure 13. Figure 13.Top level AMI test bench. The analog_in block loads the waveform created by the AMI simulator using the analog models and the channel model being used for the test. It may seem odd that we re passing this waveform in to the TX equalization process. But since the TX circuitry is LTI, the order of convolution doesn t matter. The scope allows us to see the waveform with and without TX equalization applied. The ami_out block saves a formatted waveform that can be loaded into the AMI simulator and compared to the output of the compiled AMI model to validate it. This provides a closed-loop process that allows us to ensure the compiled model correctly reflects the behavior of the architectural model before starting the large batch runs. This process works with models written as MATLAB code, providing the code is compatible with the code generation process. Our TX example in MATLAB is shown below. Figure 14. TX FIR filter MATLAB model. 17

18 When we run the architectural model for our TX with the analog_in waveform, we get results as shown in Figure 15. Figure 15. TX FIR filter simulation results. The unequalized waveform is on top, the waveform after applying equalization is on the bottom. The salient characteristics of our simple test setup are shown in Table 1. TX output resistance 50 ohms TX output capacitance 0.5 pf TX output voltage supply 1 volt TX output rise/fall time 10 ps TX EQ applied Cursor = 0.715, 1 st Postcursor = Data rate 100ps Channel model Simple lossy stripline RX input resistance 50 ohms RX input capacitance Zero RX EQ applied None Table 1. TX FIR filter test setup. 18

19 When we set up code generation, we select the LTI/Init model and provide data for the.ami file to be created, as shown in Figure 16. Figure 16. Code generation setup for TX model. We identify which parameters we want the compiled code to respond to. Note that bit_time and sample_interval are treated the same as the user-defined tap parameters here, even though they are a defined part of the AMI API. Figure 17. Tunable parameters for TX FIR filter. 19

20 The build process generates the code for our TX filter and the code needed to link these functions into the standard AMI API. It also calls the compiler to build the appropriate executable model and creates the.ami control file to go with it. We can look at the code once the process is complete. Figure 18. TX FIR filter code. The readability of the generated code is a function of the complexity of the model, the behavior being represented, the coding style of the original Architectural model, as well as the specific code generation settings selected. Improving readability of the code was not the focus of this work, that notwithstanding, looking at generated code still helps to isolate certain problems. 20

21 The compiled model can now be brought back into the AMI simulator and simulated with the same channel and equalization settings. Figure 19. QCD test bench. The waveform from the AMI simulation can then be compared to the waveform output from the Simulink run. Figure 20. Comparison of Simulink and AMI waveforms. Architectural model output is presented in blue; AMI model output in red. Where the waveform is blue, the two results overlap exactly. The red portion of the waveform is present because the AMI simulation was run longer to show that two sets of results are present. Otherwise, the waveforms are identical. 21

22 8. USB 3.0 Receiver Example TX equalization is straightforward to model and can usually be represented as a linear process. SerDes receivers are far more complex and challenging to model, so let s examine the results for a USB3 receiver architectural model correlated to lab measurements. This receiver is part of a low-power transceiver system that supports multiple protocols. This receiver required substantial design space exploration to meet the varying needs of different platforms and clients. One of the more challenging interconnect scenarios was USB3.0 On-the-Go (OTG) support, due to longer PCB routes and extra component loss in larger OTG devices (such as tablets). Because these OTG devices are also very power-sensitive, system design of these receivers presents a challenge: finding the ideal balance of amplification, linear / DFE equalization and clock-data recovery mechanisms for the target application. One such receiver is explored here, with a mix of linear equalization, amplification, and DFE, along with clocking based on a phase-interpolator CDR. System level exploration and simulation was performed in MATLAB and Simulink. The architectural receiver model included analog behavioral modeling as well as the underlying digital components. Transfer functions with poles/zeros were used to describe much of the analog front end s small signal behavior augmented with saturation/clipping to account for large signal compression. Jitter emanating from different sources (such as PLL and clock distribution) was included in the clock modeling as well as other various sources of timing error. Voltage noise and offsets were modeled at critical junctions in the receiver. The linear equalization solution space was explored with programmable transfer functions used to model intended as well as circuit-derived/extracted behaviors. Multiple samplers/slicers were employed that feed the digital subsystem input. Several adaptation blocks were implemented to steer adaptive configurations towards the desired signal metrics. This included linear equalization training as well as automatic gain control (AGC). The CDR along with its loop filter settings bears close resemblance to the cycle-by-cycle RTL implementations. In this particular architectural model, the clock is assumed to be stationary and ideal. Timing jitter (and duty cycle effects) are accrued on the incoming data through appropriately delaying the analog signal. Figure 21. High-speed serial receiver high-level architecture. 22

23 This model was exercised as part of a system level test bench that connects a transmitter model (similar to the LTI example earlier) as well as fitted channel responses (either rational fit all zero models or FIR representations) extracted from S-parameter representations. Both measured and synthesized S-parameter data was used. The model takes in an analog waveform as input, representing the signal at the receiver pin. The outputs include the equalized waveform, digital bits recovered, as well as other loop convergence metrics. Furthermore, each of the blocks contains relevant performance parameters that are representative of this block s behavior, such as programmable gain steps, saturation, and bandwidth effects for the variable gain amplifier (VGA), and residual offsets at several points along the chain. PVT variations are also expressed for the various parameter settings, with switches to apply any specific setting. Figure 22. Example design target channel support. This RX architectural model was used by multiple teams. The system designers used this model to develop preliminary specs based on design targets that satisfy certain signal fidelity metrics across the gamut of intended configurations, platform, and channel support. These specs were then provided to the team performing the PHY development. Figure 22 pictorially expresses the solution space for which a system designer budgets gain and equalization for a given set of possible channels and platforms. For the range of channels to be supported, an appropriate amplification range needs to be satisfied as well as ISI reduction through an adequate equalization range, whether using linear or multi-tap DFE equalization. For each such channel, a certain combination of amplification and equalization is desirable. With a sufficiently detailed and accurate behavioral model, system designers can then deconstruct the overall performance and budget the specifications of the building blocks in order to achieve the best solution given the constraints. In turn, the PHY circuit designers can feed back their circuit performance across PVT for system sensitivity analysis. This two-way communication repeats until a converged model is achieved representing the various components of the system with their appropriate settings. This model was also used by other teams, internal and external, for multiple other purposes. Platform electrical validation teams were interested in using the behavioral model to create appropriate recipes for multiple programmable registers, for example. This assisted them in starting from a list of vetted settings when silicon hit the labs. For these teams, a large set of 23

24 model parameters are within control, and they retain the ability to change them and perform debugging activities. As such, the system model designer exposes additional settings appropriately to internal customers. When the model is distributed to external teams, a large number of model parameters are fixed or hidden, retaining only settings of interest to that team. Figure 23 depicts the model use cases for internal and external teams, highlighting the degree of control allotted to each team s purposes. One example is CDR filter settings (proportional/integral scalars). Internal teams are interested in sweeping a large set of values to result in a single or few optimal settings per protocol, while external teams will not have that level of transparency into the design and their supplied model is molded as such. Figure 23. Internal versus external model parameters. To demonstrate that this complex design worked the same way in our architectural and AMI models, we ran identical test channels and simulation setups. The results for one such channel are shown in Figure 24. This particular channel provided modest loss (about 9dB) at the design s fundamental frequency. Figure 24. Test channel characteristics. 24

25 We used the AMI simulator to generate the waveform at the RX algorithmic input. This included the effect of TX equalization with the cursor set to and the first post-cursor set to ,000 bits were simulated and the last 10,000 bits were plotted as eye diagrams to compare the results. More comprehensive techniques for comparing results of two different simulation results can be found in [5]. The output eye diagrams from architectural and compiled AMI models show excellent correlation. Figure 25. Eye diagram comparison at RX output. Note the jitter apparent in the waveform due to the way the CDR was handled by the model. This was expected. It demonstrates that the code generation and compile process is faithfully preserving the behavior of the original model and that the various jitter sources are operating properly in both platforms. 25

26 9. Hardware Correlation Silicon correlation is critical as it establishes the credibility of the modeling and simulation results of the behavioral representations of the system. As such, the electrical validation teams work in concert with individual block designers to match and correlate circuit performance, as well as debug or explain any issues and discrepancies. This also feeds in to the system level models that now can have a parameter refresh. The correlation effort at this stage can be run by either the system designer responsible for the model or even the validation team with an appropriately parameterized model. One such correlation point is shown in Figure 26. Figure 26. Measured vs. simulated eye. The red area is the simulated eye; blue is the resultant area from on-silicon measurements that determine eye height at the sampling point and horizontal margin. The x marks in the plot represent these points. Lab measurements showed a timing margin of -48ps 37ps (85ps width) with the linear equalizer settled on code 16. Simulation results showed a timing margin of -50ps 40ps (90ps width) and with the linear equalizer settled to code 17. The results for eye height at the sampling point were within the step sizes of the slicers employed. These results were consistent within noise/run-to-run variability. 26

27 10. Summary We have outlined a process that allows AMI models to be generated from architectural models created as part of a SerDes design flow. This conversion can be performed with reasonable time and effort. We found these IBIS-AMI models useful for internal customer use (having additional tunable parameters that aid the SerDes designers in refining the SerDes architecture) and for generating IBIS-AMI models for end-user customer simulations. We developed a flow that leverages the respective strengths of architectural and IBIS-AMI environments and ensures correct partitioning between analog and algorithmic sections of an IBIS-AMI model. This flow also provides a batch simulation environment suitable for high-volume regression testing. 11. Future Activities This work was performed using a pilot support package for IBIS-AMI model generation from MathWorks. Areas we are investigating for future improvements include: Improved methods for correlating architectural and AMI model behaviors with quality metrics for measuring that correlation Improved interfacing between variable samples_per_bit settings in IBIS-AMI and the fixed oversampling assumptions built into some architectural models 27

28 Acknowledgements The authors wish to thank and acknowledge Mike Mulligan at MathWorks for his support and deep insights over the course of this effort. References [1] MathWorks, IBIS-AMI Pilot Support Package User Guide, Natick, MA, [2] Burns, D., Madsen, J., Westerhoff, T., Katz, W., Understanding IBIS-AMI Simulations, DesignCon 2015, Santa Clara, CA, [3] Steinberger, M., Westerhoff, T., White, C., Demonstration of SerDes Modeling Using the Algorithmic Model Interface (AMI) Standard, DesignCon 2008, Santa Clara, CA, [4] IBIS 6.1 Specification, IBIS Open Forum, September 2015, [5] Dramstad, K., Hawes, A., Katz, B., Katz, W., Westerhoff, T., Experiences Correlating IBIS- AMI Models and Measurement, DesignCon 2010, Santa Clara, CA,