[ibis-macro] Re: redriver in spice simulation

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Wed, 13 Mar 2013 21:08:51 +0000

Walter,

Thanks for the details about your BIRD.  As far as
I remember, this thread was a result of comments on
Fangyi’s BIRD, not yours…

My personal opinion is that the two BIRDs should be
combined into one and address both retimers and
redrivers.  Or, if you insist to keep them two
separate BIRDs, they should be written very
consistently.

Thanks,

Arpad
======================================================


From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Wednesday, March 13, 2013 2:08 PM
To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: redriver in spice simulation

Arpad,

From my repeater BIRD:

STATEMENT OF THE ISSUE:

A Differential SerDes Repeater is a four pin model consisting of a differential 
SerDes Rx model and a SerDes differential Tx model. Both the Rx and Tx models 
must also contain AMI models. The Rx model may or may not have a clock and data 
recovery loop (CDR). The Rx model may or may not return clock ticks. The output 
of the Rx model is connected to the input of the Tx model.

This BIRD introduces a new IBIS keyword [Repeater Pin] which associates 
Repeater Pins.

The  repeater BIRD specifically ties together a SerDes Rx differential model 
containing an AMI model with a SerDes Tx differential model containing an AMI 
model. So unless someone submits a BIRD to generalize Repeaters to be between 
two pins with legacy IBIS models this whole e-mail thread is a total waste of 
time.

Walter



From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, March 13, 2013 2:49 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: redriver in spice simulation

Walter,

I would like to encourage everyone to use crisper language in this
conversation to avoid these kinds of confusion.

An “output” is not driven by anything, otherwise you have two outputs
connected which is a contention.  Logic simulators don’t even allow
you to make such connections, it is an error. It seems that you mean
an “an output buffer’s input is driven by something – it’s stimulus”.

Regarding “So there is never a need to do a SPICE simulation from the channel 
Tx to the
channel Rx through the retimer or redriver.”, I don’t want to put words into
the mouth of the person who asked the question, but I don’t think that
the motivation was channel characterization.  One could potentially
use these repeater analog models for normal legacy simulations as well,
and it seems that it would be convenient to define how the Rx output
goes into the Tx input of a repeater analog model.

I tend to agree with the rest of your comments about the need for
defining a few more things in Fangyi’s proposal as I described it
in my previous posting on this thread.

Thanks,

Arpad
========================================================================



From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Wednesday, March 13, 2013 1:09 PM
To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: redriver in spice simulation

Arpad,

Of course an output is driven by something – it’s stimulus. In the case of a 
redriver, the stimulus is a continuous waveform. In the case of a retimer the 
stimulus is a “digital” waveform that transitions between -.5 and +.5. There 
are no constraints on the voltage range of the stimulus input to a redriver 
output.

Note that both a redriver and a retimer are “repeaters”.

As far as SPICE simulation with a redriver or retimer (the retimer flow is 
identical to a redriver flow, except that jitter can be inserted by the EDA 
tool in a retimer), the requirement is that the EDA tool generate an impulse 
response from the initial Tx to the Repeater Rx, and a separate impulse 
response from the repeater Tx to the next Rx. The is two separate SPICE 
simulations (if you choose to do SPICE simulations to generate the two impulse 
responses). So there is never a need to do a SPICE simulation from the channel 
Tx to the channel Rx through the retimer or redriver.

I stated before, and I repeat my concern that the EDA tool does need to know 
how to generate the impulse response from redriver Tx to the channel Rx, and 
the Redriver BIRD is not clear on how to do this. Since the redriver Tx is a 
true analog circuit it can be represented by an s4p (BIRD 158), and if the 
analog circuit is defined using BIRD 158 generating this impulse response is 
trivial and can be done using SPICE or S parameter arithmetic (assuming the RX 
is LTI). Because the redriver Tx is an analog object it cannot be represented 
by a legacy IBIS model or a BIRD 116 External Model (which has a D/A converter).

Walter

Other related posts: