[ibis-macro] Re: BIRD-124: Dependency tables - question?
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <Arpad_Muranyi@xxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 19 Jan 2011 14:14:24 -0500 (EST)
Arpad,
We agree, that IBIS as is, is insufficient, the question is how do we
improve IBIS to make it sufficient.
We also agree that the settings in the AMI file need to determine the
subckt and how the subckt is to be used by the EDA tool to generate the
impulse response and any other useful channel data that either the EDA
tool or the AMI DLL uses.
So there is no functional difference between defining the analog model as
parameterized subckts in the .AMI file or as instances of parameterized
subckts defined as [External Model] or a new section [AMI ISS Model] in
the IBIS file. It is simply a matter of defining conventions, and keywords
so that the EDA tool can choose and parameterize canned or user defined
subckts.
Please also remember that the interested parties are not only the EDA
Vendors, but the IC Vendors that need to make the models. One must ensure
that the models are easy to create and to maintain.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, January 19, 2011 1:14 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: BIRD-124: Dependency tables - question?
Walter,
I did not say that IBIS can describe devices using S-parameter
(broad band) data today.
I was saying that there are no "fundamental" or theoretical reasons
why it could not do that if appropriate keywords were introduced to
the specification. My emphasis is on the usage of the word
"fundamental" which may imply that IBIS cannot, and will never be
able to do this due to its "fundamental" nature. This is the part
I was referring to being not true.
Sincerely,
Arpad
======================================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Wednesday, January 19, 2011 11:16 AM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: BIRD-124: Dependency tables - question?
Arpad,
You said the following statement is simply wrong "IBIS fundamentally does
not have the ability to represent broadband differential drivers or
receivers"
I cannot disagree with you more. How can IBIS today support broadband
differential models.
I agree that RC circuit is not necessarily more accurate that using IBIS
IV and VT curves, but the statement I made was
"the (IBIS v-i/v-t model) has been proven to be an inaccurate
representation of high speed SerDes devices"
And I made this statement as another way of saying that these do not
support broadband models.
Please let me know if there is something that have been missing all these
years and that IBIS has been able to support broadband buffer models. If
so, please give me an example of an IBIS file that supports broadband
buffer models.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, January 19, 2011 11:57 AM
To: IBIS-ATM
Subject: [ibis-macro] Re: BIRD-124: Dependency tables - question?
Walter,
I understand that you are not a big fan of IBIS I-V/V-t [Model]s,
but please do not make it look worse than it is.
"IBIS fundamentally does not have the ability to represent broadband
differential drivers or receivers"
This statement is simply wrong. This is almost like saying that
behavioral modeling fundamentally cannot model high frequency stuff.
I agree, IBIS does have limitations as it stands today, but these
limitations are not fundamental to IBIS because it is IBIS. These
limitations are there because we didn't provide the necessary
keywords to let it happen. However, as you can see in BIRDs 116
and 125, these limitations can be removed relatively easily from
IBIS.
"Opal, and BIRD 122 describe a simple parameterized generic buffer model
that does a sufficient job of describing many SerDes Tx and Rx buffer
analog models."
You seem to be saying that the RC model defined in Opal (and BIRD 122)
does a better job than the IBIS I-V/V-t curve based [Model]. Taking a
better look at the circuit:
I must tell you that there is nothing in this circuit that a legacy
IBIS [Model] cannot do. The Voh, Vol, Vt parameters can all be
modeled with the various I-V curve reference voltages. Tf, Tr
can be modeled with [Ramp] or the V-t curves. Rt can be modeled
with any of the clamp I-V curves. Rs can be modeled with the
PU or PD I-V curves. Cc can be modeled with C_comp. Rd and Cd
can be modeled with the [R Series] and [C Series] keywords.
"the (IBIS v-i/v-t model) has been proven to be an inaccurate
representation of high speed SerDes devices"
Show me the proof that the above RC circuit is more accurate than
a legacy IBIS [Model]. As far as I can tell, you are not going to
be able to do that because they are equivalent. I agree that the
S-parameter version may give you a more accurate "broad band" model,
but IBIS can be fixed easily, as proposed in BIRD 116 and 125.
Sincerely,
Arpad
====================================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Wednesday, January 19, 2011 7:55 AM
To: kukal@xxxxxxxxxxx; 'IBIS-ATM'
Subject: [ibis-macro] Re: BIRD-124: Dependency tables - question?
Kukal,
There are two fundamental things going on here. First, IBIS fundamentally
does not have the ability to represent broadband differential drivers or
receivers. More important to your question is the fact that SerDes drivers
(and to a lesser extent receivers), are configurable. They contain
registers that control equalization, strength and drive impedance. Each
configuration of the buffer, particularly when modifying the strength of
the Tx, changes the impedance (i/v) of the buffer.
There are two choices, the first is to use a model selector and a large
number of IBIS models, each one pointing to a different .ami file
configuration. This become rapidly unwieldy, and uses v-i/v-t models that
are demonstrably inaccurate for SerDes AMI buffers. So it is only natural
that when the buffer programming (as defined in the .ami file) is chosen,
the .ami file must determine the analog model that the EDA tool must use
to determine the impulse response of the channel.
Opal, and BIRD 122 describe a simple parameterized generic buffer model
that does a sufficient job of describing many SerDes Tx and Rx buffer
analog models. The broadband (Touchstone) buffer model, an alternative
option described in Opal and BIRD 122 is a more accurate representation of
SerDes Tx and Rx buffer analog models. BIRD 124 is a method that we and
several IC Vendors came up with that documents to the EDA tool how the
Touchstone file, or the values of the parameters that control the generic
buffer model.
The short answer is that the selection of values of .ami parameters
determine the analog model that the EDA tools needs to use to generate the
impulse response of the channel. This is uncontested, and accepted by the
IBIS-ATM committee.
If you believe your tool can give more accurate results using (IBIS
v-i/v-t model) then BIRD 124 allows you to do that by letting you use the
reserved dependency table "In" or "Independent" parameter [Model]. A
simple example is a Tx model that had an AMI parameter "Strength" that has
128 allowed values (0:127). IBIS file can have a model selector for this
Tx buffer with [Model] Tx_0 to Tx_127. The dependency table would have two
columns [Model} and Strength. The user can select a specific [Model] (e.g.
Tx_107), and the dependency table would map that into Strength 107. BIRD
124 does support his flow, but we very much do not recommend it because
the (IBIS v-i/v-t model) has been proven to be an inaccurate
representation of high speed SerDes devices.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Taranjit Kukal
Sent: Tuesday, January 18, 2011 10:57 PM
To: wkatz@xxxxxxxxxx; 'IBIS-ATM'
Subject: [ibis-macro] Re: BIRD-124: Dependency tables - question?
Hi Walter,
I am confused here. The parent is the IBIS model and has a pointer to AMI
dll (Child) - the association is fixed - so how can AMI dll decide the
analog-IO model that needs to be picked. Please explain with an
example/flow-steps on how the analog model (IBIS v-i/v-t model) would be
registered.
rgds
..kukal
_____
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Monday, January 17, 2011 8:26 PM
To: Taranjit Kukal; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: BIRD-124: Dependency tables - question?
Kukal,
Your first sentence is not correct, it should have said:
"Looks like the Intent is to associate Analog IO model (different IO-model
strengths) to AMI-parameter so that correct Analog IO-model is picked when
s specific portion of AMI-code gets executed."
Point being that the user configures the registers in a model, and that
the registers in the model not only determine how the algorithmic model
works but also determine the analog model needed to generate the impulse
response of the channel for the algorithmic simulation.
Walter
From: Taranjit Kukal [mailto:kukal@xxxxxxxxxxx]
Sent: Monday, January 17, 2011 9:17 AM
To: wkatz@xxxxxxxxxx; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: BIRD-124: Dependency tables - question?
Hi Walter,
Help me understand this further. Looks like the Intent is to associate
Analog IO model (different IO-model strengths) to AMI-parameter so that
correct portion of AMI-code gets executed according to Analog IO-model
that is picked.
However, what I fail to understand is that how this association gets
utilized. If the user has to manually set a Key-parameter as per the IBIS
buffer-strength to allow picking of dependent parameters then why are not
let ami-code do it (Let tables be coded inside of AMI dll).
To me, it looks like "Good to have" rather than a real need. Please
explain with small example if I am missing the point.
rgds
..kukal
_____
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Thursday, January 13, 2011 8:32 PM
To: Taranjit Kukal; 'IBIS-ATM'
Subject: [ibis-macro] Re: BIRD-124: Dependency tables - question?
Kukai,
The impulse response of the channel must be determined before the AMI DLL
is called. The AMI file contains the switches that program the Tx or Rx
model. The value of these switches determine the analog model of the
driver that is required to determine the impulse response of the channel.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Taranjit Kukal
Sent: Thursday, January 13, 2011 2:11 AM
To: IBIS-ATM
Subject: [ibis-macro] BIRD-124: Dependency tables - question?
Hi,
The dependency tables would be useful only if we want to keep same
AMI-code (dll) and just change the dependency outside of the code using
.ami file.
However, I do not see this as common use-model - I would assume that all
such dependency should be handled inside of c-code (Algorithmic...) and
that we should avoid overloading of .ami file such tables. AMI-code should
be able to handle such dependency by coding the right values for dependent
parameters based on Key parameters in ami file.
Please let me know if I am missing a use-case where this cannot be handled
inside the dll.
rgds
..kukal
Taranjit Kukal | Product Engineering Architect
P: 91 120 3984000 <http://www.cadence.com/> www.cadence.com
Other related posts:
