Best Practices for Modeling PAM4 SerDes Systems and Improving IBIS-AMI Correlation

This video introduces best practices for modeling SerDes systems and improving the correlation of IBIS-AMI models.  

My name is Giorgia Zucchelli, and I am the marketing manager for MathWorks RF and mixed-signal product areas. Together with me is Aleksey Tyshchenko, the founder of SeriaLink systems.   

In the next 20 minutes, I will provide an introduction to SerDes design using MATLAB and SerDes Toolbox. We will see how to get started, how to use measurement data to improve the fidelity of your SerDes model, and how to generate and verify dual IBIS-AMI models. 

After me, Aleksey will present a real-life use case, where SeriaLink Systems developed a COM-compliant model of a PAM4 ADC-based SerDes operating above 100Gbps. 

The reason for this video is that the design of high-speed digital interconnects is a very analog discipline. When transmitting a digital signal, either binary or multilevel, as frequencies move in the GHz range, analog effects cannot be neglected and must be mitigated. The result is that the algorithmic content in SerDes equalizers is constantly increasing. Such complexity requires more accurate IBIS-AMI models to guarantee the successful integration of innovative SerDes IPs in high-speed links. 

If you are not familiar with the concept, this is how a typical SerDes system looks like. 

It is composed by a transmitter, a channel representing the physical interconnect, and the receiver.  

Most of the equalization complexity is in the receiver, where the digital signal is recovered after being distorted by the channel. 

The design of a typical SerDes system starts from given specifications or standard requirements (for example, to design a USB, Ethernet, or PCI Express link). Based on the specs, a system architecture is chosen. At this stage, for example, you determine if the system includes pre-emphasis, or if it is based on ADC, or if it uses global or local optimization. 

Once the architecture is locked down, the design of the integrated circuit starts, involving both analog and digital teams.  

This is a very iterative process, involving both IC design teams and system architects, where tradeoffs are negotiated based on cost and performance.  

After the design is completed, the verification phase starts.  

During this phase, the fidelity of system-level models is improved by back-annotating design information and measurements. Such improved models can be used to validate the original specs and to debug potential issues in the designed IC. 

System-level models are a possible outcome of the verification phase. IBIS-AMI or SystemVerilog models can be used to further verify the integration of the SerDes IP. 

Such design flow can be more or less formalized at your company, but for sure it is not flawless. Developing SerDes IPs is complex. It involves multiple disciplines and design teams and requires in-depth understanding of mixed-signal design and the creation of accurate behavioral models. 

The result is that often errors are introduced early in the design process but detected very late.  

<click> 

This is a well-known issue as reported here by Maxfield and Goyal. Finding specification problems while testing an IP is bad news, as it essentially means that the entire design is flawed. 

<click> 

To reduce these issues, you need to start the verification process earlier, as early as possible. 

<click> 

And the best way to do it is by building behavioral models of your IP that are continuously improved and reused during the design process. 

By spending more time in developing system-level models early in the design phase, you gain a much deeper understanding of the specifications, of the alternative architectures, and of the emerging trends. 

Design team managers often don’t like this, as it might delay the start of the actual implementation process. However, the time spent at the beginning greatly pays back by shortening the implementation and the verification phases.   

<click> 

As summarized by Kundert and Chang, top down design, especially if implemented with MATLAB and Simulink, can be greatly beneficial in managing complex mixed-signal designs. 

To specifically help for the design of SerDes systems, MathWorks has launched SerDes Toolbox in release 2019a. 

SerDes Toolbox provides blocks and algorithms to model the typical building blocks of SerDes systems such as FFE, DFE, CTLE, CDR, AGC, and so forth. 

With these blocks, you can describe your arbitrary SerDes architecture or model standard systems. You can perform both statistical and time domain simulation and automatically generate standard compliant IBIS-AMI models.  

If all of this sounds very complicated, don’t worry. With SerDes Toolbox, we made simple things easy and complex things possible. 

You can use the SerDes Designer app to get started, even if you know very little about SerDes design. 

<click> 

First, you define the system specifications: the symbol rate, the type of modulation (either NRZ or PAM4), the type of signaling (differential or single ended). 

<click> 

You can then add to your system the building blocks of the SerDes chain. 

<click> 

For each block, you can change the properties (for example, the poles and zeros or the number of taps). 

<click> 

And once you have built your chain… 

<click> 

You can analyze it… 

<click> 

And then export it. 

Let’s see in action the SerDes Designer app. 

We start by adding blocks to our chain and visualize the statistical eye. 

For example, we can disable the adaptation of the DFE and add more filter taps. 

We can easily change the modulation to PAM4, or change the specs of the CTLE. 

We can analyze results, such as pulse response or received waveform, that are rapidly calculated with convolution of the block responses. 

At last, we can export the design. 

You have three options to export your design. 

You can generate a MATLAB script to automate the design space exploration and programmatically analyze your system, rather than by point and click. 

You can export the design to Simulink and perform time domain simulation. By executing your system bit by bit, you can take into account non-linear effects and adaptation transients. 

At last, you can immediately generate a dual IBIS-AMI model.  

The exported Simulink model will have the same system-level configuration options as the app.  

<click> 

It will allow you to describe the channel either specifying the attenuation, or by providing an impulse response.  

<click> 

Under the mask of the transmitter and receiver, you will find the same building blocks that you specified in the app.  

<click> 

And for each of the building blocks, you can see, understand, and eventually modify the implemented algorithms, as everything is white boxed and exposed to the users. 

<click> 

As we mentioned earlier, SerDes Toolbox makes the simple things easy, and complex things possible. 

Let’s see it in action. We start from where we left before: we export a Simulink model from the app. When we run the Simulink model, the simulation is executed bit by bit, and we see the eye diagram updating. At the end of the simulation, statistical analysis results are reported and consistent with the app. 

In the Simulink library browser, you find the same building blocks as in the app. You can add these blocks to the transmitter or receiver to further elaborate the design. 

All the building blocks provided by SerDes Toolbox are implemented in MATLAB, and you can easily access the source code. If you want to modify it, you can just edit the code after having created a copy. 

As I mentioned, you can take the existing algorithms and modify them; however, there might be simpler ways to improve the fidelity of your SerDes model without engaging in such an advanced maneuver. 

A very convenient method to improve the model fidelity is by using bottom-up data, either coming from IC simulation or from actual silicon measurements.  

At RF frequencies, often characterization data is provided in the frequency domain, either as a transfer function or as S-parameters.  

MATLAB and RF Toolbox provide many built-in functions for the manipulation, analysis, and visualization of frequency domain data. And more importantly, provide an approach to make frequency domain data suitable for time domain simulation. 

<click> 

To simulate frequency domain data in the time domain, the data needs to be converted. RF Toolbox uses a rational fitting approach. The word rational is derived from ratio, and simply means that we fit the data with an equivalent Laplace transfer function given by a polynomial ratio of residues and zeros. 

With this approach we can analyze and enforce passivity, the resulting fitting is causal by construction as we enforce the poles to be on the left hand-side of the complex plane, and we can make sure to apply model order reduction, fit only the dominant poles, and avoid over-fitting of measurement noise.  

<click> 

Once the Laplace transfer function is available, it provides a state-space representation that can be used for time- domain simulation. 

Let’s see an example of using the rational fitting approach to model the transfer function of a CTLE and improve the fidelity of a SerDes model. 

<click> 

After importing the data, we apply rational fitting. What it might sound as a very complex and sophisticated algorithm is actually just a single line of MATLAB code. Here we give the maximum number of poles for the fitting, but we can also just rely on the default settings. 

<click> 

From the fitted object, we extract the gain and the poles and zeros that are complex conjugate and real. 

<click> 

We can directly use this data in the SerDes Toolbox CTLE object for statistical analysis and time domain processing. 

<click> 

At last, we can sandwich the frequency dependent behavior with non-linear blocks to further enhance the fidelity of the CTLE model. 

This example ships with SerDes Toolbox. If you open the MATLAB documentation, open the example called “Find Zeros, Poles, and Gains for CTLE from Transfer Function.” 

The example starts by importing and plotting the CTLE data from a CSV file. The transfer function is measured up to 25GHz, and it is fairly regular. 

We fit the data using rationalfit as shown before. In this case, we arbitrarily use 8 poles. We compare the fitting with the original results. In this case, the fidelity is really good, with an error tolerance of –126dB. 

We now extract the gain, poles, and zeros of the fitted function as a MATLAB array. We use this data in the CTLE block in the SerDes receiver.  

Once we are happy with the simulation results, we can generate an IBIS-AMI model. 

An IBIS-AMI model is composed of three elements. The IBIS file or .ibs is an ASCII file representing the channel with physical RC components or using lookup tables to describe the amplifiers and drivers I/V curves and transient responses.  

The transmitter and receiver are modeled with an AMI file that is essentially a C code DLL representing the signal processing algorithms for the channel equalization. 

An IBIS-AMI model can be executed in two ways: statistical (also known as Init) or in time domain (also known as GetWave).  

Statistical processing is entirely based on the convolution of the transfer function representing the SerDes components. It is very fast to execute, and it provides a first order estimate of the system behavior. However, it cannot model non-linear effects, and it cannot be used for exploring transient behaviors such as the one introduced by adaptation. 

Time domain simulation works bit by bit. It is significantly less fast, but it allows including non-linearity in your model and in exploring transient behaviors due to adaptation or filters. 

A dual IBIS-AMI model supports both ways of operation, and it provides consistent results. The benefit of a dual model is that it enables trading off accuracy and simulation time. Another benefit of a dual model is that a statistical model can provide a better starting point for time domain simulation to actually speed up adaptation and shorten simulation. 

With SerDes Toolbox you can generate dual IBIS-AMI models. A simple IBIS file is also generated to allow easily invoking the resulting model in any third-party channel simulator.  

For both transmitter and receiver, you can generate dual AMI files and customize the interface with the desired AMI parameters. 

Once you have generated the required IBIS, AMI and DLL files, you can use them in any standard compliant channel simulators for regression testing and for analyzing all the different channel configurations.  

If you have access to SiSoft QCD and QSI, you can automatically create a project from SerDes Toolbox and import the required models. Once you run the simulation in QCD or QSI, and for example you find a use case that is critical and does not pass your specifications, you can back-annotate in the Simulink model the AMI parameters, the stimuli, and the channel configuration. 

A bidirectional link between the two simulators enables an integrated workflow and facilitates the communication between the SerDes architect and the signal integrity engineer. 

Lets’ see how it works. From the SerDes Toolbox model in Simulink, you open the IBIS-AMI Manager. 

You can inspect the simple IBIS reference file that will be generated.  

You can also inspect, add, or remove AMI parameters to the transmitter or receiver. 

You can then generate a dual, GetWave only, or Init only model for each transmitter and receiver. When the process is finished, in your MATLAB current folder you will find the .ami files as well as the DLL. If you generate the model on Linux, you will get shared objects or .so.  

Once the model is generated, you can launch the SiSoft Link app to import the generated model in QCD or QSI. 

The QCD model for the transmitter and receiver will have the same AMI parameters that you identified in the Simulink IBIS-AMI manager. In this case, we are going to run two simulations, both statistical and time domain: one with receiver adaptation enabled and one with adaptation disabled. 

After the results are completed, you can visualize the eye diagrams for the two cases.  

At last, if you identify a critical set of results, you can import the given configuration back into the Simulink model and further elaborate on your SerDes algorithms. 

With this, I invite you to try SerDes Toolbox in your next design. With many trusted functions and blocks, you can design equalization algorithms more rapidly and achieve system-level verification earlier in the design process. 

With the automatic generation of standard-compliant IBIS-AMI models and the direct integration with SiSoft QCD/QSI channel simulator, you can spend more time in innovating your design—finding critical cases earlier rather than tool fighting and C coding.  

I’d like to pass now to Aleksey, who is going to show how SeriaLink Systems used the SerDes Toolbox to develop a cutting-edge model for a PAM4 ADC-based SerDes system. 

Thank you for the introduction, Giorgia! 

My name is Aleksey Tyshchenko, and today I will be presenting 106Gb/s ADC-based SerDes model in Simulink and IBIS-AMI intended for 802.3ck applications. We have built this model using the SerDes Toolbox from MathWorks. 

SeriaLink is a consulting team based in Toronto, Canada, focusing on system modeling of high-speed serial links, IBIS AMI modeling, signal integrity, model correlation, and system validation. 

Let me start with a brief outline of my presentation. 

First of all, I would like to introduce our system modeling vision. Then we will take a look at the challenges of modeling ADC-based SerDes architectures in IBIS-AMI. After that, I would like to look at COM as an architecture definition tool, and introduce our main contribution: a SerDes model with COM parametrization. Next, we will look into the model building blocks, touch upon the adaptation flow, and consider noise modeling and SNR. Correlation results will conclude this presentation. 

At SeriaLink, our vision is to maintain a unified system model through the entire project lifecycle: from architecture definition, though the design, and all the way to validation. 

At the onset, the project specifications and standards data populate the model for architectural exploration and to drive the block-level specs. 

The same model would support analog and digital design by providing a quantifiable feedback on design trade-offs. As the simulation data becomes available, the model components get updated with design data, which gradually brings the model closer to a correlated version. 

This correlated model enables regressions and generates the external views for validation and simulations on the customer side. 

Of course, building this unified model requires careful consideration of the block interfaces, implementation details suitable for various use cases and external views, and an easy-to-maintain correlation flow. 

The remainder of this presentation focuses on the top left sector of this diagram: the architectural version of the unified model that can be populated with standards information and that is suitable for architectural exploration. 

IBIS AMI is a common customer-oriented view of the behavioural models. In order to support it with the unified system model, the model needs to be structured in an IBIS-compatible way.  

The IBIS AMI framework decouples the model from the simulator by standardizing the interface between the two. This decoupling relies on the concept of a decision point: it’s a fully equalized waveform at the input of the sampler. The sampler is triggered by the recovered clock. As long as the simulator has access to the waveform at the decision point and the recovered clock, the simulator can evaluate the link margins.  

The sampler is assumed to be a relatively simple block whose performance is communicated through the margin requirements or the eye mask. 

As we can see, the IBIS-AMI framework suits well the binary-sampling SerDes architectures with a well-defined decision point which captures the equalization effects of the analog equalizers. 

Let’s see how an ADC-based SerDes architecture would fit into the IBIS AMI framework. 

First of all, a time-interleaved ADC samples a partially equalized signal at one sample per UI, and then the ADC samples are de-muxed to support a reasonable frequency of the remaining equalization blocks in the digital domain. FFE and DFE further equalize the sampled and de-muxed signal, and a baud-rate, or a Mueller-Müller, CDR recovers the clock from the equalized samples. FFE, DFE, and CDR are implemented as a DSP block that operates at sub-1GHz frequencies. 

The decision point is now located in the digital portion of the CDR, and there is no easy-to-abstract sampling circuit that would allow us to decouple the model from the simulator. 

As a result, the ADC-based SerDes architectures do not fit well into the IBIS-AMI framework. 

In order to support the model export to IBIS-AMI, we modeled the ADC as a time-agnostic quantizer, and we ran the FFE, DFE, and CDR at baud rate as opposed to the de-muxed rate. For the architectural exploration purposes, this allows us to account for non-linearities and ADC quantization effects while supporting the current version of the IBIS standard. 

In the statistical domain, we recover phase from the pulse response using Mueller-Müller timing functions. We adapt the equalization components to the channel, and if necessary, we readjust the recovered phase. 

In the time domain, the ADC quantizes all samples in a UI. The Mueller-Müller CDR runs continuously to maintain the phase lock, and we keep the equalization parameters constant, which allows us to focus on the equalization performance rather than on the equalization convergence details at the project onset. This approach to adaptation also helps us maintain a reasonable simulation time. 

Now, let’s take a look at COM from a slightly different point of view. 

COM is used as a normative part of standards to verify a channel’s compliance with the standard requirements. At the same time, COM script is used to define the reference transceiver for the purpose of the standard development. In a sense, COM can be used for SerDes architectural exploration. 

COM framework consists of a generic script in MATLAB. This generic script takes standard-specific reference transceiver parameters in the form of a configuration spreadsheet. When COM is populated with specific parameters, it tests channels for compliance with the standard. This approach makes COM widely used across several standard bodies and multiple standards. 

This extensive usage gave COM several important benefits. COM is distributed as MATLAB code, and it has been vetted by a large number of experts in the area. The generic code base has very flexible parametrization to support a wide range of reference transceiver models. COM relies on pulse and noise analysis, which are essentially statistical methods, and this makes the simulations fast. 

However, the statistical nature of COM leads to the major limitation of the script for the link analysis. It lacks non-linearities, transient clock recovery details, and ADC quantization effects. COM is well suited for linear analysis of analog architectures. Furthermore, the generic COM script combines the model and simulator portions of the code together. The functional blocks are not well separated in terms of the code structure. As a result, the script is non-expandable, and it’s difficult to use beyond basic architectural exploration. 

This slide illustrates our contribution. 

We built a parametrized ADC-based SerDes model in MATLAB and Simulink. We populate this model with COM parameters to build a standard-specific model instance. In this example, we are presenting the model for 106Gb/s 802.3ck standard. In addition to COM parameters, the model can also accept design parameters, which makes the model usable beyond the architecture definition phase of the project. We use an automation script to configure the generic model. 

Using SerDes Toolbox, we export the model to an IBIS-AMI view, which allows us to leverage the signal integrity simulation infrastructure. At the same time, the model’s code base remains in MATLAB and Simulink, which makes the code easy to maintain. The ability to generate IBIS AMI models early in the project development enables more efficient interaction between the SerDes IP vendors and their customers, contributing to the overall efficiently of the system development. 

The model supports statistical and time domain simulations, and this enables non-linearities, ADC, and CDR to be properly represented in the analysis. In a sense, this model augments COM by adding support for non-linear and time-varying aspects of SerDes behavior. 

A clear model partitioning into functional blocks, as well as ability to absorb analog design data, makes the model extensible and suitable for use through a project lifecycle. 

In the following slides, I will talk about the components of this model in greater detail. 

To build the model, we used the SerDes Toolbox in Simulink. The toolbox has a set of readily available functional blocks, and it allows the creation of custom blocks. In this model, we use both. The available blocks are colored purple, while custom blocks are colored orange. We add the receiver noise at the input of the model to account for the setting-dependent noise shaping by the subsequent equalizer components.  

The non-linearity and ADC are enabled only in the time domain simulations. Since these are non-linear blocks, they are bypassed in the statistical simulations. 

We also added an SNR block that measures the sampler SNR in statistical and time domains. The SNR value is used to guide adaptation, and we report the measured SNR to the signal integrity simulator. 

Let’s review the block details, starting with the CTLE. 

We implemented the CTLE using three instances of a CTLE block from the SerDes Toolbox. These instances correspond to a high-pass, a boost, and a receiver bandwidth filters in COM.  

In order to configure the CTLE with COM parameters, we have a MATLAB script that convers COM CTLE definition into gain-pole-zero matrices suitable for the SerDes Toolbox CTLE. If you are familiar with COM configuration spreadsheets, then you will immediately recognize that the configuration script consumes COM parameters directly. 

The configuration script also updates the block properties and parameter ranges in Simulink to eliminate the need for manual updates. 

Please note that even though both COM and SerDes Toolbox define the CTLE curve sets in terms of gain, poles, and zeros, these definitions are slightly different. So, some parameter mapping is required. 

With proper mapping, we can get identical sets of CTLE transfer functions in COM and in our model. For the boost stage, the plot on the left shows COM transfer functions, while the plot on the right shows the SerDes Toolbox CTLE transfer functions. 

For the CTLE, COM defines the DC gain as the gain before the zero frequency, while SerDes Toolbox uses a broadband gain definition in the GPZ matrix. These definitions are most likely coming from slightly different points of view on the transfer functions. To map from COM to SerDes Toolbox, we scaled the zero frequency by the gain values. 

We added a non-linearity block at the output of CTLE, right before the ADC. This block adds a soft amplitude limit to the ADC input waveform. It’s a SerDes Toolbox block, and its behavior is described by an input-to-output DC transfer curve. It could be provided either parametrically early in the project development or populated with analog design data later on. 

The ADC is a custom block that we built for our model. We started with a PassThrough block that gave us a framework compatible with the rest of the SerDes blocks, and then we populated this pass-through with the ADC code. We built the ADC as a quantizer, and its output are quantized voltage levels that play well within the IBIS-AMI modeling flow. Initially, the ADC is parametrized by a nominal resolution and dynamic range. Of course, further details can be added as they become available so that they can be reflected in the model. 

To maintain fast simulation time, and to focus on the equalization performance rather than on adaptation convergence, the adaptation is implemented in the statistical domain. We co-adapt the equalization components based on SNR, similar to COM. A Mueller-Müller CDR recovers the phase from the equalized pulse response in order to guide the adaptation of the FFE and DFE taps.  

Since both FFE and DFE can equalize first post-cursor ISI, we need to make the FFE aware about the DFE’s correction range. This way, we can put the equalization priority on the DFE, which reduces noise amplification. COM follows a similar approach to balance the FFE and DFE. 

The plot shows the pulse response progression from the channel through each equalization stage. 

Now, let’s turn our attention to noise modeling. 

Receiver noise and jitter can be added by the signal integrity simulator to the output of the receiver model. This approach captures the noise impact on the eye margins as calculated by the simulator. However, these noise sources are not visible to the SNR measurement block that is inside the receiver model.  

Since noise has an impact on the adaptation convergence point, we would like to make sure it’s visible inside the receiver model. The output-referred noise depends on the equalizer configuration. Therefore, the best way to model noise is to apply input-referred noise, and allow the equalization blocks to shape it so that it accurately represents the output noise. 

We also need to make sure that the noise is modeled in the statistical domain so that it impacts adaptation convergence. 

In the statistical domain, we would like to apply white noise up to the simulation bandwidth. The noise power spectral density is a parameter in the COM spreadsheet. It’s eta_0. 

To get the output noise power spectral density, we need to apply linear equalization to the input noise to achieve the noise shaping effect. Then we integrate the output noise over frequency to get the RMS value. This output RMS noise degrades the adaptation figure of merit, which is the SNR.  

However, the statistical domain is intended to operate on impulse responses rather than on power spectral densities. Of course, we could add extra functionality to the equalizer blocks to support the noise modeling, but that would increase the model build up effort. 

So, we had to find a way to get the output noise power spectral density using impulse processing. This would allow us to continue using readily available blocks from the SerDes Toolbox instead of maintaining custom blocks. 

We used a unity impulse to probe the filtering effect of the linear equalization blocks: CTLE, VGA, and FFE. The unity probing impulse is used as the input impulse in statistical processing functions. Therefore, we used statistical methods, and the filtered impulse includes everything except for the channel and the DFE, as we intended. 

We can now convert the output filtered impulse to frequency domain, and it would represent the noise transfer function. Next, we scale this noise transfer function by the input power spectral density to get the output PSD. We integrate the output noise PSD up to 100 GHz to obtain the noise RMS value, which degrades the SNR. 

In the time domain, we convert the input white noise into an RMS value, and we add a Gaussian noise source to the input waveform. The filtering of the waveform in time domain naturally accounts for noise, and output waveform now includes the filtered noise. 

Our noise methodology shows good correlation between statistical and time domains, as well as with COM. 

To illustrate the noise shaping through the receiver, we took the noise impulses after every stage and converted them to transfer functions in this plot. We start with the white noise, which is shown in blue, and as we progress through the equalization stages, we limit the bandwidth, and add boost and gain. 

If we take a look at the purple transfer function, then we can see that the receiver bandwidth filter is frequently called a noise filter for a good reason: out of all stages, it contributes the most towards reducing the high frequency noise content in the output.  

We are now moving on to the last functional block in the receiver model. This block measures the signal-to-noise ratio of the equalized waveform. To maintain consistency with baud rate ADC-based architectures, the SNR monitor looks at the signal only at the UI centers. The block supports NRZ and PAM4 modulations. 

In the statistical domain, the SNR monitor guides the adaptation convergence by providing the figure of merit. And in time domain, we use the SNR as the correlation parameter with COM.  

The baud rate implementation of the SNR monitor that we chose makes it a good candidate for post-Si correlation as well. A very similar methodology can be used in the digital components of the receiver that are implemented in RTL. Similar to our SNR block, the RTL components have access to the baud rate samples of the equalized signal. 

In the next two slides, we will look at the correlation results we achieved with this COM-parametric model. 

First of all, we tested our model in linear mode to establish a baseline correlation with COM. In this case, we disabled the soft limiter after the CTLE and the ADC. We simulated a number of IEEE channels at 53 and 106 Gb/s in COM and with our IBIS-AMI models. As a correlation parameter, we used the sampler SNR. The plot on the left compares the COM SNR with our time domain IBIS-AMI SNR for 10 channels at 53 Gb/s. The channel insertion loss ranges from 16 to 39 dB and includes the package loss. The plot on the right shows the same simulations at 106 Gb/s. In both cases, we see a good correlation between COM and the time domain IBIS-AMI. The black dashed line indicates the SNR level required to achieve a 10–4 BER level for PAM4 modulation, while the magenta dotted line shows a 3 dB COM margin above the minimum required SNR level. A simulated SNR value that is above the magenta reference line indicates a passing channel in COM. 

Both plots show a good correlation for most of the channels. At higher insertion loss, IBIS-AMI results are more pessimistic compared to COM. This pessimism is most likely coming from the CDR in the time domain simulations. 

Let’s now enable the non-linearity and ADC in our IBIS-AMI models. 

In this set of simulation results, we enabled the soft limiter in the IBIS-AMI models, and we ran the simulation with 4-, 5-, and 6-bit ADC resolution. We can see that the ADC resolution has a strong impact on the system performance.  

Since we are adding the implementation details, it is more appropriate to compare the time domain SNR value with the theoretical SNR limit required to achieve BER of 10–4, which is the black dotted line in the plots. 

A quick glance at the plots tells us that a 4-bit ADC is clearly insufficient for these applications. A 5-bit ADC increases the number of passing channels, and a 6-bit ADC gets us pretty close to COM. Note that the effective resolution is typically lower that the nominal resolution, and a more detailed analysis would be necessary here. 

Another way to interpret these simulation results is to notice that a lower resolution ADC is sufficient for lower loss channels, and a higher resolution is necessary for the high-loss channels. This trade-off between the ADC resolution and the channel insertion loss can be explored with our model to optimize the SerDes power depending on the expected channel loss. 

SeriaLink Systems has presented a COM-parametric SerDes model for ADC-based architectures in Simulink and IBIS-AMI. This model was configured for 106Gb/s operation using reference transceiver parameters from IEEE 802.3ck standard. We discussed some of the model implementation details, and we have shown that in the linear mode this model correlates well with COM. Enabling the non-linearity and ADC reduces SNR with decreasing ADC resolution. We have also shown that this model can guide the trade-off between the SerDes receiver power and the expected channel insertion loss. 

Please contact SeriaLink System for information on model availability, customization, or extension options. 

Thank you for your attention.