[ibis-macro] Re: redriver in spice simulation

  • From: "Walter Katz" <wkatz@xxxxxxxxxx>
  • To: <Arpad_Muranyi@xxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
  • Date: Tue, 26 Mar 2013 13:20:45 -0400 (EDT)

All,



There certainly are changes that are required for BIRD 131.



First, it must be clear that the two pins in each Repeater Pin record exist 
in the [Pin] sections, and that the first pin must be a non-inverting pin in 
a [Diff Pin] record and that pin must have a [Model] of type Input, and that 
the [Model] must contain an [Algorithmic Model] section. Similarly, the 
second pin must be a non-inverting pin in a [Diff Pin] record and that pin 
must have a [Model] of type Output, and that the [Model] must contain an 
[Algorithmic Model] section.



What also needs to be added is that the differential Input pins and 
differential outputs pins shall be treated as either a Redriver or Retimer. 
In both cases, the time domain AMI simulation flow shall take the 
AMI_GetWave output of the Input (Rx) DLL and pass it as input to the 
AMI_GetWave of the Output (Tx) DLL. In the case of a Retimer, the waveform 
that gets passed from the Rx to the Tx is a “digital” waveform in the sense 
that it’s values shall either be -1/2 or +1/2 (except it shall be 
between -1/2 and +1/2 at transitions such that the waveform shall cross 0 at 
the time of the transition). In the case of a Redriver, there shall be no 
constrains on the value of the waveform passed from the Rx to the Tx.



In both the Retimer and Redriver flow, the impulse response input to the Rx 
of the Repeater shall be the impulse response output of the Tx AMI_Init that 
is driving the channel to the Rx of the Repeater, and the impulse response 
input to the Tx of the Repeater shall be the impulse response of the channel 
between the Repeater Tx and the Rx that the Repeater Tx is driving.



In the case of a Retimer, the impulse response input to the Retimer Tx is 
calculated by the EDA tool in a similar (but poorly defined) way as done 
currently for a normal Tx/Rx AMI analysis.  In the case of a Redriver, the 
impulse response input to the Redriver Tx is calculated by the EDA tool in a 
similar (but even more poorly defined) way as done currently for a normal 
Tx/Rx AMI analysis. For a Redriver, the EDA tool must either use the IBIS 
Legacy Model Ramp, VT curves, and IV curves (or the BIRD 158 Tstonefile) 
even though the Tx is not a traditional model in the sense that it has a 
digital input.



Walter





From: ibis-macro-bounce@xxxxxxxxxxxxx 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Tuesday, March 26, 2013 12:46 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: redriver in spice simulation



Fangyi,



It seems that miscommunication and confusion is building…



The last comments I wrote in this thread were strictly on

BIRD 131.  Your response seems to mix BIRD 156 into the

answers.  Until we don’t have a combined BIRD, I would like

to discuss them one at a time.  I want to do this so that

we can find a path for editing these BIRDs and bring them

to a state which is unambiguous, understandable and consistent

with the current v5.1 specification.



Reading BIRD 131 ***as is***, I get the following mental image

of the proposal:



[Component]

   [Pin]

   [Repeater Pin]

[Model]

   [Algorithmic Model]



Here the [Pin] keyword is responsible to associate a pin with

a [Model].  The [Repeater Pin] keyword associates two pins and

consequently their [Model]s with each other so that they are

connected in series.  In v5.1 a [Model] has a digital input

when it is an Output (Tx) and a digital output when it is an

Input (Rx) type, regardless of whether the [Model] contains an

[Algorithmic Model] keyword or not.



So based on what is in the current specification and BIRD 131,

I see no reason that the [Repeater Pin] keyword couldn’t tell

the simulator to make use of the digital output of the [Model]

that is an Input type and drive the other [Model] that is an

Output type with that digital signal as opposed to the tool’s

internal stimulus.



This is what I read from the spec and BIRD 131.  This is what

we should work with as the baseline in our discussions to make

changes to BIRD 131.



Unfortunately the words (rules) in the “Statement of the issue”

section:



“Both the Rx and Tx models must also contain AMI models.”

and

“The Rx model AMI_GetWave function output "wave" is used as the
input to the Tx AMI_GetWave "wave".”

are not going to become part of the specification (if left in
this section of the BIRD), so they are a moot point in this
discussion (until they become part of the usage rules or a
more relevant section of the BIRD which ensures that these
will become part of the specification).



Thanks,



Arpad

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





From: fangyi_rao@xxxxxxxxxxx [mailto:fangyi_rao@xxxxxxxxxxx]
Sent: Tuesday, March 26, 2013 11:05 AM
To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: redriver in spice simulation



Arpad;



Please see my input below.



In legacy simulations, the[Repeater Pin] keyword would simply associate a 
Tx(Output) and an Rx (Input) [Model] with each other so that the stimulus to 
the Tx (Output) [Model] is the output of the Rx (Input) [Model] instead of 
the tool’s internal stimulus.



As I pointed out before, it won’t work for redriver because the output of 
the Rx half of a redriver is analog signal but not digital signal, and the 
Tx half is not driven by crossing events.



The BIRD should also spell out what should happen when the[Model]s 
associated in the [Repeater Pin] keyword contain [Algorithmic Model].  For 
one, in that case both of the [Model]s should have the [Algorithmic Model] 
keyword.  We should not allow only one or the other to have it, or if we do, 
then the Repeater Model should only work in legacy simulations(?).  Also, we 
need to have words on how the [Algorithmic Model]s will be “connected” to 
each other, i.e. which GetWave output is the input to the other GetWave 
input, or which Init function gets the impulse response of the channel, in 
other words we need an AMI flow description for this case.



This is exactly what the Maxim-Agilent redriver BIRD addresses.



Regards,

Fangyi



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



From: ibis-macro-bounce@xxxxxxxxxxxxx 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of 
radek_biernacki@xxxxxxxxxxx
Sent: Monday, March 25, 2013 6:07 PM
To: ambrishv@xxxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: redriver in spice simulation



Hi Ambrish,



I am not sure whether it has any practical value or not, but I do not see 
any obstacles to simulate such models in non-AMI mode. That would be similar 
to simulating a single ended buffer for a [Pin] that also appears in the 
[Diff Pin] list.



Radek



From: ibis-macro-bounce@xxxxxxxxxxxxx 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ambrish Varma
Sent: Monday, March 25, 2013 4:02 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: redriver in spice simulation



Hi Michael,

We might have to go one step further. Currently, for an IBIS model with 
[Algorithmic Model]/[End Algorithmic Model] section, we can still use the 
models to simulate in an non-AMI mode. We will not be able to do that with a 
model with [Repeater Pin]. We might need:

New Model_type for Repeaters (Repeater_Input, Repeater_Output ??) to 
accurately distinguish them from ‘regular’ I/O buffers.

OR

Specifically note somewhere that models used in [Repeater Pin] ‘Shall not be 
used for NON-AMI simulations’



Thanks,
Ambrish.





From: Mirmak, Michael [mailto:michael.mirmak@xxxxxxxxx]
Sent: Monday, March 25, 2013 4:22 PM
To: fangyi_rao@xxxxxxxxxxx; Ambrish Varma; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: redriver in spice simulation



Just a suggestion: it’s easier to loosen a specification than to tighten it.



One simple possibility would be to add a line to BIRD131 that the 
[Algorithmic Model]/[End Algorithmic Model] keyword pair is required for any 
[Model] linked to a [Pin] number that appears under [Repeater Pin].  That 
would initially limit [Repeater Pin] to use with IBIS-AMI, and would be 
parsable, but that limitation could easily be removed in a future revision 
once non-IBIS-AMI support is more clear.



I would argue that demand for repeater support for non-IBIS-AMI buffers is 
much smaller than demand for IBIS-AMI repeater support.



-          MM



From: ibis-macro-bounce@xxxxxxxxxxxxx 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of fangyi_rao@xxxxxxxxxxx
Sent: Monday, March 25, 2013 9:02 AM
To: ambrishv@xxxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: redriver in spice simulation



Ambrish;



The problem is that BIRD131 has to answer the question of how a redriver 
model behave in non-AMI simulations, which what I try to avoid in my BIRD.



Thanks,

Fangyi



From: ibis-macro-bounce@xxxxxxxxxxxxx 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ambrish Varma
Sent: Friday, March 22, 2013 4:07 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: redriver in spice simulation



Fangyi,

“If this proposal is strictly for AMI purposes, and the analog

models are not designed to be used in non-AMI simulations in a

redriver configuration, than the BIRD should state that. ”



If this statement is true then there should be no issues with combining your 
version of the redriver BIRD with BIRD 131 – correct?

I believe we should do that for the sake of a uniform, concise and 
meaningful discussion.



Thanks,

Ambrish.



From: ibis-macro-bounce@xxxxxxxxxxxxx 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, March 18, 2013 10:23 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: redriver in spice simulation



Fangyi,



Thanks for the answers.



1)  By “that” I was referring to “namely ignoring the connection between the 
Rx half and Tx half in SPICE/non-AMI”.

If this proposal is strictly for AMI purposes, and the analog

models are not designed to be used in non-AMI simulations in a

redriver configuration, than the BIRD should state that.  Otherwise

we might have to answer questions like Ambish’s question every so

often…



2)  That’s an interesting point that I didn’t think of.  The redriver’s

Rx is a transmitter (Tx) for a link that might be tucked away between

the redriver’s Rx and Tx blocks, and the redriver’s Tx might be a

receiver (Rx) from that perspective.  But the concept of having a

channel inside the redriver is stretching the name of the redriver

a little bit, and even though it is possible, I would keep the naming

consistent with the primary purpose.



But this is not what I was hung up on when I first commented on this.

What bothered me the most is that people (you?) started to call blocks

as “input” or “output” which to me meant a terminal into which a signal

is going in or from where a signal is coming out.  As a result, I started

to read statements like “signal going into an output {terminal}”, which

sounded like nonsense to me.  Whatever we end up calling these repeater

blocks, I would like to use names which can’t be shortened so that

sentences could be grossly misinterpreted.



3)  Please spell out the nature of the input to Tx GetWave.  In the light of

recent discussions I feel this would be important to have in the BIRD to

eliminate any misinterpretations (and arguments) in the future.



4)  Please try to work with Walter if possible on a common proposal so that

the entire proposal/concept would be in one BIRD, and not sprinkled

around in several BIRDs.





Thanks,



Arpad

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





From: fangyi_rao@xxxxxxxxxxx [mailto:fangyi_rao@xxxxxxxxxxx]
Sent: Monday, March 18, 2013 4:19 PM
To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: redriver in spice simulation



Hi, Arpad;



My answers are inserted.



Regarding “So I tend to agree to Radek’s suggestion, namely ignoring the 
connection between the Rx half and Tx half in SPICE/non-AMI. But that’s 
beyond the scope of my BIRD.”, If that is the case, the BIRD

should state that explicitly, and propose verbiage for the

specification for a statement like that.  But I am not sure

how much of your BIRD text actually goes into the spec.

Could you explain that?



FR: what dose ‘that’ mean?



I would suggest to change the words “input *** model” and

“output *** model” to “receiver *** model” and “transmitter

*** model” to eliminate possible confusions along the lines

we just had in this thread.



FR: It’s fine for me to use Rx/Tx instead of input/output, but I know there 
are people who would argue strongly against using Rx/Tx because in optical 
redriver models the first half actually transmits signal and the second half 
receives signal. Any suggestion for better terminology is welcome.



Are you assuming that if the model is made for a redriver, the

model maker will know that the Rx GetWave output should be (a

+/- 0.5 V digital waveform) or make the Tx GetWave accept true

analog waveforms?



FR: Tx GetWave accepts continuous analog waveform. I can spell it out in the 
BIRD.



Another question, which was also mentioned yesterday in the ATM

meeting:  If an .ibs file has multiple Rx and Tx AMI models,

how would the simulator know which Rx goes with which Tx model?



That’s addressed in Walter’s BIRD.



Regards,

Fangyi



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



Other related posts: