Two for One: Leveraging SerDes Flows for AMI Model Development

Transcription

1 TITLE Two for One: Leveraging SerDes Flows for AMI Model Development Todd Westerhoff, SiSoft Corey Mathis, MathWorks Image Authors: Corey Mathis, Ren Sang Nah (MathWorks) Richard Allred, Todd Westerhoff (SiSoft)

2 SPEAKERS Corey Mathis Industry Marketing Manager, MathWorks Corey 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. He has an MBA from Boston University and a bachelor s in electrical engineering from Union College in Schenectady, NY. Todd Westerhoff VP Semiconductor Relations, SiSoft twesterh@sisoft.com, Todd Westerhoff 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.

3 Background Good AMI models are hard to develop Analog / algorithmic partitioning IBIS-AMI requirements: samples per bit Portability issues between EDA tools AMI development typically occurs after the fact AMI Models are customer collateral Created by different group Limited testing before distribution

4 Architectural models SerDes Design Created up-front to define architecture & budgets Limited design detail, execute relatively fast Good for design budgets & control loop behavior Implementation models Detail varies from architectural to gate to circuit level A snapshot of the design at a point in time This presentation is based on Architectural models

5 An AMI Model Primer Fundamental Assumption Model Components

6 AMI_Init Model configuration parameters Impulse response processing Linear, Time-Invariant (LTI) AMI Simulation Primer AMI_Getwave Waveform processing Clock ticks Non-Linear, Time-Varying (NLTV) AMI_Close Clean up & exit Algorithmic Model Network Characterization (Circuit Simulation) Channel Simulation (Signal Processing) Channel Simulation For more info: Understanding IBIS-AMI Simulations, DesignCon 2015

7 SerDes Architectural Exploration Typical flow: end to end link in Architectural simulator Our flow: leverage strengths of Architectural and AMI simulators

8 IBIS-AMI Model Development Loop AMI Simulator Test case generation Batch & regression tests Architectural Simulator Interactive design & analysis Test case debugging

9 Leveraging Existing Infrastructure Build on existing capabilities for embedded software code generation

10 Mixing Structure and Code Key parts of SerDes designs are often implemented as code Ability to mix structure and code is critical

11 Creating Algorithmic Models Identify model type Identify AMI parameters Generate Code & Compile Based on design characteristics (Init/LTI or Getwave/NLTV) C++ code.ami file

12 IBIS-AMI Model Types TX: 4 tap filter Simple, linear, non-adaptive Init or LTI model Complex, non-linear, adaptive Getwave or NLTV model RX: CTLE, Saturation, 8 tap DFE, CDR Design characteristics drive proper IBIS-AMI model type

13 A Simple AMI Transmitter 4 tap TX with normalization captured two ways Structural model MATLAB code Channel behavior with & without equalization

14 Generated C++ Code AMI wrapper Model behavior

15 Architectural vs. AMI Results Architectural simulation ends, AMI simulation run for more bits Test bench Output waveform comparison

16 USB 3.0 Receiver Model Low power mobile receiver with multi-protocol support Design challenge: balance AGC, linear/non-linear EQ and CDR USB3.0 On-the-Go (OTG) support especially challenging

17 Model Correlation Simulator to Simulator Architectural Model AMI Model Simulator to Hardware Receiver hardware reports eye height and width based on sampling clock

18 Other Findings Internal models External (customer) models Expose extra controls and outputs Internal testing & design tuning Internal regression testing Fewer exposed controls & outputs Early models for key customer feedback

19 Throughput Other Findings AMI Compliance AMI models run 4-8x faster than their Architectural counterparts Running AMI simulations in parallel can provide ~150x speedup for regression testing AMI requires models run at any setting of samples per bit Architectural models can be set up to meet this requirements

20 Other Findings We ran AMI models created with this flow through SiSoft s standard IBIS-AMI test suite The models passed the first time through The models provided correct output clock behavior and handled multiple values of samples_per_bit and block_size

21 Summary AMI models can be created from Architectural models normally created during the SerDes design cycle The parameters exposed in an AMI model can be varied depending on the application Models produced with this process behave just like any other well-constructed AMI model

22 For More Information [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, 2010.

23 Thank you! --- Questions?