[ibis-macro] Re: BIRD-124: Dependency tables - question?
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: "'Taranjit Kukal'" <kukal@xxxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 20 Jan 2011 10:23:28 -0500 (EST)
Kukal,
I agree that the use model in BIRD 116-118 is convoluted and ODD. Opal,
and BIRD 122 (which SiSoft introduced and supports) has the following
flow:
I start with IBIS-model1 -> This gives me a pointer to AMI-model -> Tool
reads .ami settings and then picks AMI-Analog model for characterization -
this quite natural.
The only real objection to BIRD 122 from the IBIS-ATM committee is that is
has only four predefined analog templates; Tx Touchstone, Rx Touchstone,
Tx simple RC circuit Rx simple RC circuit. Many members of the IBIS-ATM
committee (the other EDA Vendors) objected to this because they wanted to
have the ability to have more flexible and user definable RC (IBIS-ISS)
circuits. I do not object to this at all, I just think that the definition
of these subckts should be done in the .ami file, not as [External Model]
in the IBIS file.
Walter
From: Taranjit Kukal [mailto:kukal@xxxxxxxxxxx]
Sent: Thursday, January 20, 2011 1:42 AM
To: wkatz@xxxxxxxxxx; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: BIRD-124: Dependency tables - question?
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 <http://www.cadence.com/> www.cadence.com
Other related posts:
