Arpad,
As you said, I was trying to answer your question about original intent.
IBIS is a triangle with three corners:
1. EDA Tool
2. IC Vendor
3. User
We can dissect original intent, and history of a standard that is 22 years
old and has gone through 11 factors of two (according to Moore’s law). We
have gone from 25 Megahertz to 56 Gigahertz. It is amazing that 2^11
=56G/25M, and now designing 116 Gigahertz for two years from now.
Ultimately, we are here to serve the User, and his requirements. It is our
duty as EDA vendors and IC Vendors to deliver models and tools that serve
Users well. This is not accomplished by dissecting original intent, or is
DFE LTI, and how LTI is it. We do not serve our Users well if we try to
block innovation that is demonstrably and successfully being used today to
design systems that are driving technology such as autonomous driving,
WebEx, Facebook, and Google.
IBIS-AMI was specifically designed to support innovation: InOut Parameters
and Model Specific Parameters. Innovation has let IBIS-AMI meet the needs of
the SerDes (and now DDR5) market with relatively few substantive changes
over a 10 year life span.
Ultimately, IBIS-AMI Users require a solution that “Predicts the operations
of a channel with sufficient accuracy to design robust products”.
We should be making sure that the IBIS standard allows IC Vendors to produce
“Compliant” models that allow EDA vendors to deliver a software product that
Users can use to address this requirement. I believe BIRD 166 does that, I
believe BIRD 190 does not. I also support the extensions that Keysight has
proposed does additional things in line with this fundamental User
requirement.
Walter
Walter Katz
wkatz@xxxxxxxxxx <mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308
Mobile 303.335-6156
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Tuesday, June 20, 2017 12:25 AM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Response to BIRD-190
Walter,
It is indeed amusing to go back and look at things in retrospect…
However, consider this timeline:
2008 August 29 - IBIS v5.0 released
2009 October 12 - Fangyi’s comment on the Init function being
over loaded
2011 April 21 - BIRD131 (repeater) submitted
2012 August 24 - IBIS v5.1 released
2013 January 11 - BIRD156 (repeater) submitted
2013 June 13 - BIRD131 rejected, BIRD156 approved
2013 September 20 - IBIS v6.0 released
2015 September 11 - IBIS v6.1 released
I don’t remember how actively we were discussing BIRD131 before v5.1 was
released, but I doubt that we talked a lot about it, because we were
consumed
neck deep by the flow correction discussions we had for v5.1 (removing the
channel IR convolution from the Tx GetWave’s input and do it with the output
of Tx GetWave).
I don’t deny that we had discussions on optimization around that time, but I
find
it important to note that we were discussing the very same problems already
way
back then. We are struggling with the same exact fundamental problem today,
except the issues are magnified by orders of magnitude in the redriver flow.
Quote from Fangyi’s email in your attachment:
“The problem of all these confusion and broken flows is that AMI is letting
the Init function provide multiple functionalities including
Prepare for GetWave or optimize taps
Return approximate LTI model for statistical simulation
Return Tx/Rx EQ information
It is too much to put in one single function.”
The fact that this comment was written by Fangyi in October 2009 and we did
not
address this problem in the IBIS v5.1 spec that was released in August 2012
indicates
to me that we were not serious with our intentions to make provisions to
support
optimizations properly in the Init function(s). In other words, if we would
have
been dead serious about our intent to support optimizations in Init, we
wouldn’t
have left such a gaping hole in the AMIM flows. After all, we seemed to be
fully
aware of the problem already then.
But, instead of lamenting over the past, let’s try to figure out what we can
do about
it today. I only brought up the past to see if we can answer the question
about what
the real intent was regarding optimizing in Init or not, so we can decide
whether
BIRD190 is the appropriate way to go in the short term while we refine a
“real”
solution for the long run.
Thanks,
Arpad
=================================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Monday, June 19, 2017 8:28 PM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx
<mailto:Arpad_Muranyi@xxxxxxxxxx> >; ibis-macro@xxxxxxxxxxxxx
<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: RE: [ibis-macro] Re: Response to BIRD-190
Arpad,
There are a large number of e-mails relating to optimization and IBIS
models. I pulled out the following quote from this e-mail from you to me on
12/1/2010
1. However, let’s consider an example when the Init function contains
an optimizer which takes initial values for the tap coefficients
and after some number crunching returns better coefficients.
I would think that in this case the tap coefficients will be
declared as InOut arguments, and the initial values given to the
Init function will be overwritten by the Init function when the
optimizer is done. Now, how is this result propagated to the
GetWave function? Notice that the GetWave function doesn’t have an
AMI_parameters_in argument. This makes me think that the
AMI_parameters_in argument of the Init function is also visible to
the GetWave function, and the modified tap coefficients from the
Init function are passed to GetWave through the AMI_parameters_in
memory location. This implies that the return value of an InOut
argument should be returned in place (which is #1 above). Using
this thinking we won’t need the AMI_parameters_out argument for
returning the values of InOut arguments.
This describes exactly how Bob Miller’s models work, and it is in words you
wrote.
There are tons of references to this in many e-mails. It is clear that the
original intent of IBIS AMI models were to enable the AMI_Init, the
AMI_Getwave and both combined to optimize tap coefficients.
I am also included a random relevant e-mail from 2009 from Kumar.
There are literally hundreds of e-mails between 2007 and today talking about
various methods of optimization. It is very interesting to see some of these
discussions in retrospect.
Walter
Walter Katz
wkatz@xxxxxxxxxx <mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308
Mobile 303.335-6156
From: ibis-macro-bounce@xxxxxxxxxxxxx
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, June 19, 2017 8:18 PM
To: ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Response to BIRD-190
Aren’t those Model_Specific parameters? If so, no one else but
the model maker knows what they mean or can be used for…
Thanks,
Arpad
==================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Monday, June 19, 2017 7:01 PM
To: ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> ; Muranyi,
Arpad <Arpad_Muranyi@xxxxxxxxxx <mailto:Arpad_Muranyi@xxxxxxxxxx> >
Subject: Re: [ibis-macro] Re: Response to BIRD-190
Why would an initial function return tap coeficients based on the input ir?
Get <https://aka.ms/ghei36> Outlook for Android
