[ibis-macro] Re: Question on dividing up the Tx behavior between the AMI and analog portions of the model

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
  • Date: Wed, 14 Mar 2012 00:22:14 +0000

James,

If reading the specification leads to different interpretations
we are in trouble.  Please let the IBIS editorial group know if
you think there are ambiguous areas in the specification.

http://www.eda.org/ibis/editorial_wip/

Thanks,

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

From: James Zhou [mailto:james.zhou@xxxxxxxxxx]
Sent: Tuesday, March 13, 2012 7:15 PM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: Question on dividing up the Tx behavior between 
the AMI and analog portions of the model

Hi Arpad,

Thank you very much for clarifying your interpretation of the Specification.  
Although I still believe that the existing Specification and BIRDs do not 
necessarily lead to these interpretations, I am sure some of these issues (such 
as A2) will be addressed in future ATM meetings.

Regards,
James Zhou
QLogic Corp.


From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]>
 On Behalf Of Muranyi, Arpad
Sent: Tuesday, March 13, 2012 4:44 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Question on dividing up the Tx behavior between the 
AMI and analog portions of the model

James,

I don't understand why you want to "apply the output of Tx AMI waveform to the 
input of the analog channel".
There is a separate simulation in which we generate the impulse response
of the channel hAC(t) and it is this impulse response that is convolved with
the output of Tx GetWave.  What do you want to do with the analog model in
the AMI simulation?  The analog model is not used or needed in the AMI flow
or its convolutions.


A1:  Yes
A2:  No the IBIS specification doesn't and shouldn't describe how to obtain
     the impulse response hAC(t).  There are a lot of different ways to do that
     some of which may even be proprietary.  This is similar to field solvers,
     for example.  There are many different ways to convert a physical 
description
     of a PCB trace to an electrical model, but we don't put all that into a
     SPICE User's Manual.  We only talk about how to format that data so that
     the SPICE engine can read it and use it.

Pg. 11 (and subsequent drawings) in that presentation illustrate real-life
systems, not the way AMI simulations are constructed.  If you want to get
an idea for how AMI simulations flow, I would suggest to look at pg. 9 of
this presentation:

http://www.eda.org/ibis/summits/jul09/katz1.pdf

where the top panel with the green background illustrates the statistical
flow using the AMI_Init functions only, and the lower half with the light
blue background illustrates the Time Domain flow using the AMI_GetWave
functions.  BEWARE:  this drawing illustrates the flow in IBIS v5.0 which
will change in v5.1 so that the Tx GetWave's input is the "Stimulus"
only and the impulse response of the channel is convolved with the output
of Tx GetWave.  Either way, there is no analog model on this slide.  The
impulse response is generated in a separate step before you start doing
what is shown on this slide.

The flows described in BIRD 120.1 attempt to verbalize this slide in a
step-by-step fashion.  Read the BIRD while looking at this slide (keeping
in mind the change in the order the impulse response is convolved).

By the way, regarding "it is the same "digital stimulus" as referred by your 
email",
they are not the same.  For the Tx GetWave input, step 4 in BIRD 120
states that the levels are +/- 0.5 volt, while the stimulus to the
analog model is a logic '1' or logic '0'.

Regarding: "then,  what is driving it in IBIS AMI simulations?".  Nothing, you 
don't use
the analog models in AMI simulations.  You use them before you start your
AMI simulations in the preparatory channel characterization simulation.

Hope this helps...

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




From: James Zhou 
[mailto:james.zhou@xxxxxxxxxx]<mailto:[mailto:james.zhou@xxxxxxxxxx]>
Sent: Tuesday, March 13, 2012 5:13 PM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: Question on dividing up the Tx behavior between 
the AMI and analog portions of the model

Hi Arpad,

Please see my comments in red color. In case any email client cannot display in 
color, all replies are marked by <JZ_reply> </JZ_reply>.

Thanks,
James Zhou

From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]>
 On Behalf Of Muranyi, Arpad
Sent: Tuesday, March 13, 2012 2:02 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Question on dividing up the Tx behavior between the 
AMI and analog portions of the model

James,

Regarding:

"please clarify what is actually driving  the input terminals of Tx analog 
block (which is the first stage of the entire analog channel, represented by 
hAC(t))",

there are several different ways to generate hAC(t), but one way to
do it is to run a time domain simulation using a step function and
take the derivative of the resulting waveform at the Rx.  In order
to do this, the EDA tool would give a stimulus to the Tx analog model
corresponding to a rising or falling step function, such as a digital
'0' and '1'  or  '1' and '0' to get a rising or falling step waveform.

How this is implemented is entirely up to the EDA vendor, that's why
the IBIS specification doesn't give you these details.  But the point
is that this stimulus has nothing to do with x(t) which is what goes
into AMI_GetWave during an AMI simulation.
<JZ_reply>: I agree with above statements. However my original statement is not 
about how to generate hAC(t). By "driving  the input terminals of Tx analog 
block", I mean to apply the output of Tx AMI waveform to the input of the 
analog channel (i.e. hAC(t)). Mathematically, the EDA tool convolves the Tx AMI 
output waveform with hAC(t). I fully agree with you that the IBIS Specification 
does not need to give mathematical details on how to obtain hAC(t) from 
existing data (provided that necessary data do exist per Specification).

This issue can be viewed from another perspective in the form of these 
questions:
Q1: is it permissible in IBIS Specification to obtain hAC(t) using Tx Analog 
circuit represented by [Ramp] or [Rising/Falling Waveform]?
Q2: if answer to Q1 is yes, does or should the IBIS Specification provide 
sufficient information such that different EDA tools would obtain the same 
hAC(t) using the same data in [Ramp] or [Rising/Falling Waveform]  ?
</JZ_reply>

Regarding:

"(a)  Instead of  "driving the channel topology by the Tx I-V, [Ramp], or V-t 
based analog model", the "digital stimulus" actually drives the Tx AMI input. 
The Tx AMI output should drive these analog models, if such practices are 
allowed by the Specification. It neither makes sense to me (to drive a legacy 
IBIS model with x(t) or Tx AMI output) nor specified by IBIS 5.0 or BIRDs that 
this is permissible and doable."

Which digital stimulus are you talking about in "the "digital stimulus" 
actually drives the Tx AMI input"?
<JZ_reply> it is the same "digital stimulus" as referred by your email. 
Mathematically it is x(t) = b(t) *p (t)   </JZ_reply>
There are two digital stimuli.  One that is used to stimulate the
analog Tx model to generate the impulse response (hAC(t)) for the
channel, and another one that is the input to the Tx AMI_GetWave
function during the AMI simulation. <JZ_reply> my email refers to the latter 
</JZ_reply>


Why do you say "The Tx AMI output should drive these analog models"?  I don't
see that in the AMI flow diagram.
<JZ_reply> it is clearly shown on page 11 of "Serial Link Analysis Terminology" 
(URL given in your email). Tx AMI output is marked by an arrow with text 
"Equalized Tx Data".
This is also evident in BIRD120, section 3.2 Step 5 and 6a. The texts in Step 5 
and 6a. literally says: "The output of the Tx AMI_GetWave function is passed on 
to Step 6."  and,  " ... is convoled with the output of Step 1" (i.e. hAC(t)). 
</JZ_reply>

Even though you might want to do
that in your approach, this is not what the IBIS AMI flow suggests.
<JZ_reply> My intention is to correctly interpret the IBIS Specification.  </ 
JZ_reply>


Regarding: "since the "digital stimulus" x(t) is in fact amplitude continuous, 
if it is used to drive the D_to_A in Tx",
this statement is not correct.  x(t) is not used to drive the D_to_A
(or the input) of the Tx analog model.  It is used as the input to the
Tx GetWave function.
<JZ_reply> we have agreement on this.
This is the perfect place to ask this question again: since  we have agreed 
that "x(t) is not used to drive the D_to_A
(or the input) of the Tx analog model", then,  what is driving it in IBIS AMI 
simulations?
</JZ_reply>

I hope this helps.
<JZ_reply> yes, very much. Thank you again for respond with technical details.  
</JZ_reply>

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


From: James Zhou 
[mailto:james.zhou@xxxxxxxxxx]<mailto:[mailto:james.zhou@xxxxxxxxxx]>
Sent: Tuesday, March 13, 2012 1:15 PM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: Question on dividing up the Tx behavior between 
the AMI and analog portions of the model

Hi Arpad,

I agree with the first part of your response, which basically states that x(t) 
= b(t) * p(t) and, x(t) drives Tx AMI block. In case of using AMI_GetWave, x(t) 
is passed to AMI_GetWave through *wave variable. Even though labeled as 
"digital stimulus", x(t) is amplitude continuous and time discrete.

With reference to "The analog model was used in generating the channel's impulse
response hAC(t), but it is not driven by the output of Tx
GetWave as you concluded",
If this is the case, please clarify what is actually driving  the input 
terminals of Tx analog block (which is the first stage of the entire analog 
channel, represented by hAC(t)).

With reference to "As far as I know the analog models are
exercised the same way as in a usual legacy IBIS simulation using the
tool's digital stimulus (though the D_to_A converters in Tx), driving
the channel topology by the Tx I-V, [Ramp] or V-t based analog model,
to obtain an impulse response as seen at the Rx",
there are several issues here:
(a)  Instead of  "driving the channel topology by the Tx I-V, [Ramp], or V-t 
based analog model", the "digital stimulus" actually drives the Tx AMI input. 
The Tx AMI output should drive these analog models, if such practices are 
allowed by the Specification. It neither makes sense to me (to drive a legacy 
IBIS model with x(t) or Tx AMI output) nor specified by IBIS 5.0 or BIRDs that 
this is permissible and doable.
(b)  since the "digital stimulus" x(t) is in fact amplitude continuous, if it 
is used to drive the D_to_A in Tx, all amplitude information would be lost, 
except the rise/fall transitions.

Thanks,
James Zhou



From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]>
 On Behalf Of Muranyi, Arpad
Sent: Monday, March 12, 2012 9:36 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Question on dividing up the Tx behavior between the 
AMI and analog portions of the model

James,

Knowing that Walter is enjoying the IEEE meetings in Hawaii,
I will try to help a little.  Please refer to the flow
diagram that was used in the discussions towards the new
flow.  See pg. 17 in this presentation:

http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20100713/toddwesterhoff/IBIS-AMI%20Flows/Flows_July2010-v2.pdf

Note that the input to the Tx GetWave function is labeled
"Digital stimulus" and x(t).  Also note that x(t) is
explained in more detail in this presentation on pg. 13-14:

http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20061212/toddwesterhoff/Serial%20Link%20Terminology/serial_link_terminology.pdf

where "TX data" is b(t) convolved with p(t) which we later
simply referred to as x(t) in our flow diagrams.

Please note also that on pg. 17 of the first presentation
above, the output of Tx GetWave is convolved with the channel
impulse response hAC(t) and the result of that is the input
to Rx GetWave.  There is no analog model present in this flow.
The analog model was used in generating the channel's impulse
response hAC(t), but it is not driven by the output of Tx
GetWave as you concluded.

So your conclusions that:

" Equivalently, the legacy IBIS [Ramp] and [Rising/Falling Waveform] keywords 
have no roles in this process."

and

"D_to_A  is not needed in IBIS AMI, or at least in between Tx AMI block and its 
analog block. Because the output of Tx AMi is already analog, why bother using 
a D_to_A? "

seem to be incorrect to me.  As far as I know the analog models are
exercised the same way as in a usual legacy IBIS simulation using the
tool's digital stimulus (though the D_to_A converters in Tx), driving
the channel topology by the Tx I-V, [Ramp] or V-t based analog model,
to obtain an impulse response as seen at the Rx.

Of course there are other techniques to achieve equivalent results, but
it is not the role of the IBIS specification to enumerate all possible
methods in the trade.

I hope this helps...

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



From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]>
 On Behalf Of James Zhou
Sent: Monday, March 12, 2012 9:02 PM
To: Walter Katz; Terry.Chen@xxxxxxxxxx<mailto:Terry.Chen@xxxxxxxxxx>; 
DBanas@xxxxxxxxxx<mailto:DBanas@xxxxxxxxxx>; 'IBIS-ATM'
Subject: [ibis-macro] Re: Question on dividing up the Tx behavior between the 
AMI and analog portions of the model

Hi Walter,

Thanks for your response and clarification. The issues can be separated as the 
following:

(1) "determine the Impulse Response of a channel": I fully agree with you that 
"Tx analog portion takes the output of the algorithmic section of an AMI 
model". Equivalently, the legacy IBIS [Ramp] and [Rising/Falling Waveform] 
keywords have no roles in this process. This is a subject that has caused much 
confusion in the end-user community and we need to clarify it in terms of both 
(a) what are the intentions of model makers when IBIS AMI analog model data is 
put in [Ramp] [Raising/Falling Waveform] keywords and (b) What should the EDA 
tools do about those data in IBIS AMI modeling (i.e. when deriving impulse 
response)

(2)  "the fundamental confusion of using [External Model] with IBIS-ISS 
subckts": in my opinion,  D_to_A  is not needed in IBIS AMI, or at least in 
between Tx AMI block and its analog block. Because the output of Tx AMi is 
already analog, why bother using a D_to_A?  ( I understand D_to_A is useful for 
general IBIS [External Model] not involving AMI).

(3)  "one must be very careful to make sure that return loss is properly 
accounted for": I fully agree. IBIS Specification should provide clear 
guidelines on how to achieve this both at model creation time and model 
simulation time. I think enforcing reverse isolation is too restrictive for 
existing silicon implementation and it will cause larger errors when return 
loss is lower. It is much simpler and better to require the disclosure 
(knowledge) of Tx AMI block output impedance (which is assumed to be high 
impedance by many, anyway) and, not imposing any artificial requirements on the 
AMI analog block (such as reverse isolation which in fact does not exist in 
many silicon).

Thanks,
James Zhou


From: Walter Katz [mailto:wkatz@xxxxxxxxxx]<mailto:[mailto:wkatz@xxxxxxxxxx]>
Sent: Monday, March 12, 2012 4:50 PM
To: James Zhou; Terry.Chen@xxxxxxxxxx<mailto:Terry.Chen@xxxxxxxxxx>; 
DBanas@xxxxxxxxxx<mailto:DBanas@xxxxxxxxxx>; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: Question on dividing up the Tx behavior between 
the AMI and analog portions of the model

James,

The IBIS analog model is only useful to determine the Impulse Response of a 
channel. You are absolutely correct that in reality a SerDes Tx analog portion 
takes the output of the algorithmic section of an AMI model to drive an analog 
model (e.g. an on-die S-parameter s4p, a simpler RC circuit at described in 
BIRD 122, or an ISS subckt as defined in BIRD 116). IBIS AMI assumes an LTI 
channel, and IBIS-ISS defines all of the LTI elements available in HSPICE.

This is the fundamental confusion of using [External Model] with IBIS-ISS 
subckts describing the analog section. As written now, BIRD 116 identifies the 
input of the Tx ISS subckt using the D_to_A statement, which essentially 
defines a voltage swing and rise time - equivalent to Ramp. The correct 
interpretation is that the D_to_A statement is only to define the input to the 
Tx analog circuit, and is valid to determine the Impulse Response of the 
channel.

Because of silicon drivers are in fact LTI, one can do the shaping of the 
waveform in the algorithmic section, but one must be very careful to make sure 
that return loss is properly accounted for.

Walter

From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]>
 On Behalf Of James Zhou
Sent: Monday, March 12, 2012 5:11 PM
To: Terry.Chen@xxxxxxxxxx<mailto:Terry.Chen@xxxxxxxxxx>; 
DBanas@xxxxxxxxxx<mailto:DBanas@xxxxxxxxxx>; 'IBIS-ATM'
Subject: [ibis-macro] Re: Question on dividing up the Tx behavior between the 
AMI and analog portions of the model

Hi David and Terry,

Both of your emails mentioned "analog IBIS model" and "IBIS-analog portion" 
represented by [Ramp] and/or [Rising/Falling Waveform] keywords in IBIS file.  
However, these "analog" IBIS models only take digital input signals,  as stated 
in IBIS Specification 5.0, page 71-72 and section 6b. The output of the 
"analog" IBIS model is not capable of tracking the amplitude changes in the 
input (other than a rise/fall transition). It would not make sense to feed the 
Tx AMI output to such digital inputs based on IBIS Specification 5.0.

If this approach of using [Ramp] and/or [Rising/falling Waveform] keywords to 
represent "analog IBIS model" is adopted by IBIS AMI flow, some clarification 
is needed on how to interpret and implement it.

Regards,
James Zhou
QLogic Corp.


From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]>
 On Behalf Of Chen, Terry
Sent: Thursday, March 08, 2012 10:33 AM
To: DBanas@xxxxxxxxxx<mailto:DBanas@xxxxxxxxxx>; 'IBIS-ATM'
Subject: [ibis-macro] Re: Question on dividing up the Tx behavior between the 
AMI and analog portions of the model

Hi David,

Actually I am interested in other's response to this question as well...

But, for the TX Driver I am currently modeling, I am doing exactly what you 
have prescribed and using the IBIS-analog portion as effectively an ideal step 
function (by setting my ramp with extremely high rise/fall dv/dt) and letting 
the step response filter inside my AMI model to shape my output waveform. Now, 
I am not sure if this is the "right" or "ideal" way to do it, but I am getting 
a reasonably good correlation in my Re-driver model with the actual lab 
measurements (the max jitter mismatch is < 8ps).

I hope this is at least an useful data point for you.

Regards,
Terry

From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]>
 On Behalf Of David Banas
Sent: Thursday, March 08, 2012 1:15 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Question on dividing up the Tx behavior between the AMI 
and analog portions of the model

Hi all,

Is it customary to split up the Tx behavior, such that the FFE is modeled in 
the AMI model and the pulse shaper in the analog model?
Or, is there a different dividing line that has been identified as "best 
practice".
(Or, am I completely off in the weeds?)

The context for this question: I just managed to get good correlation between 
our latest Tx AMI model and the HSPICE model.
And then I realized that, having dumped all of the behavior into the AMI model, 
I would need to put an ideal step function into the V-T curves of the analog 
IBIS model. And I wasn't sure that would be a good idea. (I'm guessing that 
that would reek havoc in most simulators; is that correct?)

Thanks,

David Banas
Sr. Member Technical Staff
Altera<http://www.altera.com/>
+1-408-544-7667 - desk

Did you know Altera offers over 150 free online technical training 
courses<http://www.altera.com/servlets/searchcourse?coursetype=Online&WT.mc_id=t9_ot_mi_mi_tx_a_311>?
 Take one today!


________________________________
Confidentiality Notice.
This message may contain information that is confidential or otherwise 
protected from disclosure. If you are not the intended recipient, you are 
hereby notified that any use, disclosure, dissemination, distribution, or 
copying of this message, or any attachments, is strictly prohibited. If you 
have received this message in error, please advise the sender by reply e-mail, 
and delete the message and any attachments. Thank you.

________________________________
This message and any attached documents contain information from QLogic 
Corporation or its wholly-owned subsidiaries that may be confidential. If you 
are not the intended recipient, you may not read, copy, distribute, or use this 
information. If you have received this transmission in error, please notify the 
sender immediately by reply e-mail and then delete this message.

________________________________
This message and any attached documents contain information from QLogic 
Corporation or its wholly-owned subsidiaries that may be confidential. If you 
are not the intended recipient, you may not read, copy, distribute, or use this 
information. If you have received this transmission in error, please notify the 
sender immediately by reply e-mail and then delete this message.

________________________________
This message and any attached documents contain information from QLogic 
Corporation or its wholly-owned subsidiaries that may be confidential. If you 
are not the intended recipient, you may not read, copy, distribute, or use this 
information. If you have received this transmission in error, please notify the 
sender immediately by reply e-mail and then delete this message.

________________________________
This message and any attached documents contain information from QLogic 
Corporation or its wholly-owned subsidiaries that may be confidential. If you 
are not the intended recipient, you may not read, copy, distribute, or use this 
information. If you have received this transmission in error, please notify the 
sender immediately by reply e-mail and then delete this message.

________________________________
This message and any attached documents contain information from QLogic 
Corporation or its wholly-owned subsidiaries that may be confidential. If you 
are not the intended recipient, you may not read, copy, distribute, or use this 
information. If you have received this transmission in error, please notify the 
sender immediately by reply e-mail and then delete this message.

Other related posts: