[ibis-macro] Re: redriver in spice simulation

  • From: Ambrish Varma <ambrishv@xxxxxxxxxxx>
  • To: "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Mon, 25 Mar 2013 16:02:11 -0700

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> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ambrish Varma
Sent: Friday, March 22, 2013 4:07 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto: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> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, March 18, 2013 10:23 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto: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> 
[mailto:fangyi_rao@xxxxxxxxxxx]
Sent: Monday, March 18, 2013 4:19 PM
To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx<mailto: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: