Using AMI Retimer Models in ADS ChannelSim

Transcription

1 Retimer Models in ADS ChannelSim Jan. 23, 2012 John Baprawski

2 Designing an AMI Retimer in SystemVue Use the SystemVue workspace AMI_Retimer_System.wsv. The associated Visual Studio Solution is AMI_Retimer_System. Observe the AMI_System_Schematic. This is a generic schematic relevant for any Retimer design. There are two channels. There are four AMI models. The Retimer Rx/Tx models are between the two channels. The TxCTLE model is at the input of Channel 1. The RxFFE_CDR_DFE model is at the output of Channel 2. 2

3 Designing an AMI Retimer in SystemVue Note that this schematic has test points before and after each channel, between the Retimer Rx/Rx models and at the final Rx AMI model output. The AMI models TxCTLE, Retimer_Rx, Retimer_Tx, and RxFFE_CDR_DFE are subnetworks that are designed and plugged into this schematic. Follow existing SystemVue practices for designing and testing these subnetworks. The Channels are S-Parameter channels. Here, both Channels are the same. Follow existing SystemVue practices for importing S-Parameter files. Each Channel should be characterized for its Impulse response when needed by the AMI models. These Channels are analyzed in the SerDes_Channel folder. The Channel Impulse response should be truncated to a shorter length using the Calculate_Channel_Impulse equations. 3

4 Designing an AMI Retimer in SystemVue Custom models are used in the Retimer_Rx design: ClockRecovery and DataRecovery. These models are loaded into SystemVue using the dll at AMI_Retimer_Demo\Retimer_Models\ReleaseSystemVue\Retimer_Models.dll The Retimer_Rx design has this schematic: DataRecovery implements waveform retiming (for input jitter removal) using an internally derived clock and resampling between the clock edges. ClockRecovery implements clock recovery based on input signal zero crossing detection and provides output delayed waveform, clock times, and clock. These models provide infinitesimal timing resolution on waveform zero crossings. Documentation on these models is available. 4

5 Designing an AMI Retimer in SystemVue When the SerDes Retimer system design is complete, follow the established practice to export the AMI models to C++ code. First export the Retimer AMI models as C++ SystemVue models. This is done with the CodeGen_Validation code generator. After export, use these custom C++ SystemVue models in place of the Retimer subnetwork models. This validation step ensures that the generated C++ code works the same as expected with the subnetwork models. Next export the Retimer AMI subnetwork models as C++ AMI models. This is done with the AMI_Retimer_CodeGen code generator. Be sure to compile and link in Release mode for customer delivery. This step generates the necessary files for AMI model use in the ChannelSim. Each model has files *.ami, *_ibs.txt, *.dll (32-bit Windows), *_64.dll (for 64-bit Windows), *.so (for Linux). 5

6 Retimer models in ADS ChannelSim Use the AMI Retimer models in the ADS Channel Sim. Use the ADS workspace AMI_Retimer_System_wrk. The AMI Retimer models are used in ADS by copying the relevant files from the AMI_Retimer_System Visual Studio project to the ADS workspace data directory (AMI_Retimer_System_wrk\data). These files were copied: AMI_Retimer_System\ReleaseAMI\Retimer_Rx.dll, Retimer_Tx.dll, RxFFE_CDR_DFE.dll, TxCTLE.dll AMI_Retimer_System\AMI\Retimer_Rx\Retimer_Rx.ami AMI_Retimer_System\AMI\Retimer_Tx\Retimer_Tx.ami AMI_Retimer_System\AMI\RxFFE_CDR_DFE\RxFFE_CDR_DFE.ami AMI_Retimer_System\AMI\TxCTLE\TxCTLE.ami Additionally, these files are copied from the AMI_Redriver_System Visual Studio project: AMI_Redriver_System\ReleaseAMI\AMI_Rx_Through.dll, AMI_Tx_Through.dll AMI_Redriver_System\AMI\AMI_Rx_Through\AMI_Rx_Through.ami AMI_Redriver_System\AMI\AMI_Tx_Through\AMI_Tx_Through.ami 6

7 Retimer models in ADS ChannelSim The AMI models are used in ADS by setting up *.ibs files. These files were setup: AMI_Channel_1_Tx.ibs: Used for the Channel 1 Tx_AMI model (uses model TxCTLE) AMI_Channel_2_Rx.ibs: Used for the Channel 2 Rx_AMI model (uses model RxFFE_CDR_DFE) AMI_Rx_Through.ibs: Rx_AMI through model (uses model AMI_Rx_Through) AMI_Tx_Through.ibs: Tx_AMI through model (uses model AMI_Tx_Through) Retimer.ibs: AMI Retimer model (uses models Retimer_Rx and Retimer_Tx) 7

8 Retimer models in ADS ChannelSim The AMI Retimer simulation flow in ADS is described here: Rx bits output / Tx bits input A Retimer AMI model consists of two back-to-back regular AMI models which represent receiving and transmitting parts of the device Each half model has its own.ami and.dll (or.so) files. Both models are contained in the same.ibs file. The.ami and.dll files of the Rx part are specified under the [Algorithmic Model] keyword in the Rx model section of the.ibs file. The.ami and.dll files of the Tx part are specified under the [Algorithmic Model] keyword in the Tx model section. Rx AMI_Init takes upstream channel impulse matrix as input. Tx AMI_Init takes downstream channel impulse matrix as input. Rx algorithmic model s output waveform is the input signal to the Tx algorithmic model. If Rx DLL generates clock times, they will be ignored by simulator. Retimer can be cascaded in a channel. 8

9 Retimer models in ADS ChannelSim The workspace folder view is shown to the right. The AMI Retimer simulation in ADS is split into 2 parts. The AMI Retimer simulation process is similar to the Redriver process defined in the Retimer_Release_doc.docx document. The first part is with schematic Retimer_Part1. The second part is with schematic Retimer_Part2. 9

10 Retimer models in ADS ChannelSim Retimer_Part1 schematic. The Tx_AMI models uses the AMI_Channel_1_Tx.ibs file. The Rx_AMI model uses the Retimer.ibs file The channel is the 4 port representation of the 2 port channel used in the SystemVue simulations. Variable debug_outputretimerclock=1 results in saving the ChannelSim output of the Rx_AMI model for use as the Tx_AMI model input in the Part 2 simulation. It produces this file in the data directory: retimer1.txt

11 Retimer models in ADS ChannelSim Retimer_Part2 schematic. The Tx_AMI uses the Retimer.ibs file. The Rx_AMI model uses the AMI_Channel_2_Rx.ibs file. The channel is the same as used in Part 1. Variable debug_inputretimerclock=1 results in using file retimer1.txt, which was saved in the Part 1 simulation, as the input to the Tx_AMI model. Jitter inherent in clocktimes from the Retimer_Rx AMI model Part 1 simulation is retained in the input to the Retimer_Tx AMI model Part 2 simulation

12 Retimer models in ADS ChannelSim Note on using 4 Port S-Parameters in place of a detail channel design. The detail 4-port differential channel is shown in the schematic SParam_4Port_test 12 For convenient and fast Channel Simulation, it is often desirable to convert the detail channel design into its equivalent 4-port S-Parameter file. This conversion is done using the SParam_4Port_test schematic and the Tools > Data File Tool with Write data file from dataset enabled to generate the PCI_sparam_2.s4p file which is used in the AMI Retimer simulations.

13 Retimer models in ADS ChannelSim Note on using 2 Port S-Parameters in place of a detail channel design for use in SystemVue. Typically, one starts with ADS to characterize the SerDes channel of interest to obtain its 2 port S-Parameter data for use in SystemVue The PCI_Sparam_2.s2p data used in SystemVue was obtained from the SParam_test schematic. That schematic uses the detail 4-port differential channel. The 4-port channel is converted to 2-port S-Parameters using the Tools > Data File Tool with Write data file from dataset enabled to generate the PCI_sparam_2.s2p file. Notice the use of the Balun4Ports to convert from the 4 port channel to a 2 port channel. 13

14 Retimer models in ADS ChannelSim With the AMI Retimer models operable in the Part 1 and Part 2 schematics, full validation is required before the final AMI Retimer models can be bundled with all associated files and documentation for delivery to customers. The validation process may require iterations between all the processes discussed in this presentation. It is important to be clear on the sequential validation process to minimize confusion or extra work. BE SURE TO ONLY DELIVER TO COSTOMERS DLLs THAT ARE BUILT (compiled and linked) FOR THE RELEASE MODE and not the DEBUG MODE. 14

15 15 About John Baprawski John Baprawski is Systems Engineer with over 35 years designing RF and communications systems and EDA system design products for the RF, Communications, and High Speed Digital markets. John was formerly with Agilent EEsof for 22 year as the R&D manager who led the R&D team for development of system level design tools. Currently, John is a consulting engineer for modeling high speed digital (HSD) integrated circuits (ICs) based on the industry Input/Output Buffer Information Specification (IBIS) Algorithmic Model Interface (AMI) standard. John Baprawski can be contacted through his Web site: his Linked-In Web page or by at john.baprawski@gmail.com