[ibis-macro] Re: BIRD-124: Dependency tables - question?
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 19 Jan 2011 08:57:25 -0800
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 www.cadence.com
<http://www.cadence.com/>
Other related posts:
