[ibis-macro] Re: redriver in spice simulation

  • From: "Walter Katz" <wkatz@xxxxxxxxxx>
  • To: <Arpad_Muranyi@xxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
  • Date: Wed, 13 Mar 2013 14:09:15 -0400 (EDT)

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



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



Fangyi,



I am confused, what do you mean by “Tx output is driven by”?

How can an output be driven by something?  Isn’t that

a contention condition?



Thanks,



Arpad

========================================================



From: fangyi_rao@xxxxxxxxxxx [mailto:fangyi_rao@xxxxxxxxxxx]
Sent: Wednesday, March 13, 2013 12:04 PM
To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: redriver in spice simulation



Arpad;



The option you proposed won’t work for redriver, whose Tx output is driven 
by continuous analog waveform but not trigger events (see my original 
email).



Regards,

Fangyi



From: ibis-macro-bounce@xxxxxxxxxxxxx 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, March 13, 2013 9:54 AM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: redriver in spice simulation



Another option could be to make a statement in the spec

that the (digital) output of the analog Rx model should

be used as the (digital) stimulus for the analog Tx model

when this keyword exists for normal analog simulations.



Arpad

==========================================================



From: ibis-macro-bounce@xxxxxxxxxxxxx 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of 
radek_biernacki@xxxxxxxxxxx
Sent: Wednesday, March 13, 2013 11:49 AM
To: fangyi_rao@xxxxxxxxxxx; twesterh@xxxxxxxxxx; ambrishv@xxxxxxxxxxx
Cc: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: redriver in spice simulation



Hi All,



I think a very simple solution is to limit the scope of the [Repeater Pin] 
to AMI applications. In legacy IBIS simulations that keyword can simply be 
ignored, exactly the same way the keyword [Algorithmic Model] is ignored 
today.



Also, the Maxim-Agilent BIRD on redrivers can go as is. When the repeater 
BIRD is ratified, it can simply then apply to redrivers (and perhaps 
repeaters).



Radek



From: ibis-macro-bounce@xxxxxxxxxxxxx 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of fangyi_rao@xxxxxxxxxxx
Sent: Wednesday, March 13, 2013 9:11 AM
To: twesterh@xxxxxxxxxx; ambrishv@xxxxxxxxxxx
Cc: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: redriver in spice simulation



Hi, Todd;



We got into this discussion because if we introduce a new keyword for 
redriver/repeater such as the one in Walter’s repeater BIRD, we will have to 
define the redriver behavior in non-AMI simulations. That’s why I didn’t 
introduce new keyword in the Maxim-Agilent redriver BIRD and limited it to 
the AMI context.



Regards,

Fangyi



From: Todd Westerhoff [mailto:twesterh@xxxxxxxxxx]
Sent: Wednesday, March 13, 2013 8:48 AM
To: 'Ambrish Varma'
Cc: RAO,FANGYI (A-USA,ex1); ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: redriver in spice simulation



Ambrish,



If you’re not including the algorithmic part, then the equalization isn’t 
getting modeled.  Why bother?



Todd.





Todd Westerhoff

VP, Software Products

Signal Integrity Software Inc. • www.sisoft.com

6 Clock Tower Place • Suite 250 • Maynard, MA 01754

(978) 461-0449 x24  •  twesterh@xxxxxxxxxx



“I want to live like that”

                                             -Sidewalk Prophets



From: Ambrish Varma [mailto:ambrishv@xxxxxxxxxxx]
Sent: Wednesday, March 13, 2013 11:46 AM
To: Todd Westerhoff
Cc: fangyi rao; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: redriver in spice simulation



Todd,

We were discussing how a normal time domain (non-AMI) simulation will work 
with a redriver in the middle of a channel. I suggested that shorting the 
redriver Rx pins with the related Tx should work as the simulator will take 
care of the analog waveforms going out from the Rx and in the Tx – but that 
will not work as we describe below.



Thanks,

Ambrish.



From: Todd Westerhoff [mailto:twesterh@xxxxxxxxxx]
Sent: Tuesday, March 12, 2013 9:24 PM
To: Ambrish Varma
Cc: fangyi rao; ibis-macro@xxxxxxxxxxxxx
Subject: Re: [ibis-macro] Re: redriver in spice simulation



Ambrish,



I guess I missed part of this conversation.  What problem are you trying to 
solve?



Todd.

Image removed by sender. Description: 
cid:EAFF2D52-4B63-4A05-9D24-B96BE375B7E0@eau.wi.charter.com

Todd Westerhoff

VP, Software Products

Signal Integrity Software Inc. • www.sisoft.com

6 Clock Tower Place • Suite 250 • Maynard, MA 01754

(978) 461-0449 x24  •  twesterh@xxxxxxxxxx

“I want to live like that”

                                             -Sidewalk Prophets



  _____

From: "Ambrish Varma" <ambrishv@xxxxxxxxxxx>
To: "fangyi rao" <fangyi_rao@xxxxxxxxxxx>, ibis-macro@xxxxxxxxxxxxx
Sent: Tuesday, March 12, 2013 7:34:02 PM
Subject: [ibis-macro] Re: redriver in spice simulation

Fangyi,

Actually, if we short the Rx and Tx of the redriver, regular spice 
simulations using IBIS models and analog repeaters will have issues with the 
Tx trying to pullup to power and pulldown to ground.



In that case, redriver simulation within the realm of an IBIS cct, solutions 
can be:



1)      No  spice (non AMI) simulation allowed for redrivers (easier)

2)      Series switch like implementation (harder)



Thanks,
Ambrish.



From: fangyi_rao@xxxxxxxxxxx [mailto:fangyi_rao@xxxxxxxxxxx]
Sent: Tuesday, March 12, 2013 4:58 PM
To: Ambrish Varma; ibis-macro@xxxxxxxxxxxxx
Subject: redriver in spice simulation



Hi, Ambrish;



I am not sure if your suggestion of shorting redriver Rx ibis output pin to 
the redriver Tx ibis input pin in spice simulations will work because in 
spice simulations



1.       legacy Tx ibis model is driven by input signal threshold crossing 
events. That’s not how a redriver Tx half is driven by input signal.

2.       legacy Rx ibis model output is a digital signal of 1’s and 0’s 
(hopefully I am correct here). That’s not what redriver Rx half outputs.



Due to the uncertainties in redriver model behavior in non-AMI simulations, 
I prefer to keep my redriver BIRD separate from Walter’s repeater BIRD, at 
least for now.



Regards,

Fangyi

JPEG image

Other related posts:

  1. Home
  2. ibis-macro
  3. Archive
  4. 03-2013