[ibis-macro] Re: BIRD-124: Dependency tables - question?
- From: Taranjit Kukal <kukal@xxxxxxxxxxx>
- To: "wkatz@xxxxxxxxxx" <wkatz@xxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 20 Jan 2011 12:12:15 +0530
Thanks for detailed explanation Walter
I understand that we need different IO-driver-strength models corresponding to
different AMI-dll parameter settings; and I am not contesting that -
(I also understand that v-i/v-t model has limitations)
My concern is on the way we are building this dependency - the whole use-flow
becomes round-robin.
I start with IBIS-model1 -> This gives me a pointer to AMI-model -> Tool reads
.ami settings and then picks IBIS-model2 for characterization - this seems ODD.
We should come out with a better use-model so that it is clean/straight-forward
and scalable.
Top of my head, I see following ways:
1. Keep different ami files (with different settings) for different IBIS-models
- so same dll but different ami files
(Enhance the AMI section to allow different names of ami files)
2. Move AMI section out of IBIS-model and bring to a MODEL SELECTOR level - and
let dependency tables work to pick the model...
[Model Selector] iobuf_hss
[AMI SECTION HERE]
iobuf34_hss iobuf34
iobuf40_hss iobuf40
iobuf48_hss iobuf48
3. Use combination of 1) and 2) and get rid of dependency tables (I prefer this
:) )
[Model Selector] iobuf_hss
[AMI SECTION HERE pointing to only dll and not ami-file]
iobuf34_hss iobuf34 <ami_file1>
iobuf40_hss iobuf40 <ami_file2>
iobuf48_hss iobuf48 <ami_file3>
My 2 cents...
rgds
..kukal
________________________________
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Wednesday, January 19, 2011 7:25 PM
To: Taranjit Kukal; 'IBIS-ATM'
Subject: RE: [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:
