Why would an initial function return tap coeficients based on the input ir?
Get Outlook for Android
On Mon, Jun 19, 2017 at 5:12 PM -0600, "Muranyi, Arpad"
<Arpad_Muranyi@xxxxxxxxxx> wrote:
Walter,
Maybe I wasn’t clear with what I was trying to say, but when I raised the
question “So what was the original intent?”, I was referring to the intent
of the ORIGINAL IBIS-AMI specification (v5.0) for the Init function. In those
days there was no mention of optimization and/or repeater flows. The
text I quoted from pg. 175 of the v6.1 spec:
appears exactly the same way in the v5.1 spec on pg. 159:
(I couldn’t find anything along these lines in the v5.0 spec).
What I wanted to point out was that this text was written before repeaters and
optimization
were mentioned in the spec and this text seems to indicate that the primary
purpose of the
Init function was to do what its name implies, initialize the AMI DLLs. The
ability to put signal
processing into the Init function seemed to be a bonus (for statistical
simulations).
With that in the back of my mind, I was trying to make the point that whether
the statistical
(Init) flow is correct or wrong for the purpose of redriver simulations with
optimization
depends on what the original intent was for the Init functions, i.e. was the
original intent to
use the Init function for optimization or not. If the answer is yes, the
redriver reference flow
is wrong, but if the answer is no (which I what I sense from the quoted text
above), then the
redriver reference flow is good the way it is.
Optimization arrived on the horizon before redrivers. As early as in the v5.1
specification, we
added Abrish’s favorite text (on pg. 162 of the v5.1 PDF file), apparently for
that reason:
which seems to indicate that at the time v5.1 was written, we didn’t intend to
provide full
support or a robust solution for optimizations in the Init flow/function.
Otherwise we would
have figured out how to change the flow right then and there. After all, v5.1
was the version
when we made another correction on the flow and got rid of the Use_Init_Output
parameter.
We could have fixed the optimization problem too in the same sitting. Why did
we not do it?
We probably couldn’t see into the future to know how important that might
become one day.
But this is exactly the proof that it must not have been the original intended
purpose for the
Init function at that time.
So once again, if that was not the intended purpose of the Init function, than
the redriver
flow that followed in a later version is correct according to what the intent
was at the time.
It is a different question now that we are trying to shoehorn a new purpose
into the Init
function that the redriver flow seems wrong to us with that new purpose.
I am not opposed at fixing that, but it doesn’t seem that BIRD166 provides a
universal solution
for the problem without making some other model combinations worse. And this
is what
we need to resolve. We need to find a solution that does not break something
else…
Regarding “why is the input to the Tx2 the IR of the downstream channel”, I
tend to agree
with Ambrish, the input any Tx Init function, regardless of which channel it
belongs to, is the
channel’s IR that it belongs to, so that its EQ can modify it. The main reason
for this is not that
it should be able to optimize itself to the channel, however, that is certainly
an added benefit…
Thanks,
Arpad
=========================================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Walter Katz
Sent: Monday, June 19, 2017 4:38 PM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx>; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Response to BIRD-190
Arpad,
The original intent was to allow users to:
Define repeater records in an IBIS file so that an Rx could be paired with a Tx
to form a repeater
Define two kinds of repeaters, a Retimer and a RedriverDefine the sequence of
Init flows and GetWave flows for both Redrivers and RetimersSelf-Optimization
was always considered
for both the Tx2 and Rx2. If not, why is the input to the Tx2 the IR of the
downstream channel? The answer was so the Tx2 could optimize itself. For
Retimers, the input to the Rx2 was just the output of the Tx2. For the
Redriver, it was an oversite to
not include the output of Rx1 in either the input to the Tx2 or the input to
the Rx2.
No flow is valid unless it incorporates the ability of an Rx to optimize
itself. AMI specifically supports this because the AMI_Init can return the
values of AMI parameters such at tap coefficients. There are examples of this
in the specification
(e.g. mySampleAMI on page 210.
Walter
Walter Katz
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: Monday, June 19, 2017 5:13 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Response to BIRD-190
Walter,
In this case, whether the redriver reference flow is correct or wrong seems
to depend on what you want to do in the simulation. What I am hearing in
this conversation is that the flow is only wrong if the Init function contains
optimization. But if the original intent of the spec did not include such
optimizations, then the flow seems to be OK.
So what was the original intent?
Thanks,
Arpad
===========================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Monday, June 19, 2017 4:04 PM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx>;
ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: Response to BIRD-190
Arpad,
Yes, there are reference flows, and the Redriver reference flow is wrong. It
has an error in it. The error should be corrected because it gives the wrong
result. I announced that this error existed as soon as I found it. The error is
there
whether Rx2 has a DFE or not. Even if the Rx2 was LTI in your definition of
LTI (e.g. it has a CTLE that can be changed as a function of the IR of the
upstream channel).
If the standard gives the wrong answer and if IBIS is unable to correct it,
then all we can do is document that IBIS 6.1 flow is incorrect, and that SiSoft
follows a flow that is correct.
Walter
Walter Katz
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: Monday, June 19, 2017 4:30 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Response to BIRD-190
Walter,
What happened to the promise of interoperability and portability?
Also, pg. 177 states the following:
So while the flows are not a requirement, the purpose of them is to
establish something that can be followed to arrive to the same results…
If all EDA vendors can do anything they want, and generate different
results because they feel it is the correct answer, we might as well
kiss the spec good bye…
Thanks,
Arpad
========================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Monday, June 19, 2017 3:21 PM
To: Bob Miller (APD) <bob.miller@xxxxxxxxxxxx>; Ambrish Varma
<ambrishv@xxxxxxxxxxx>
Cc: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx>;
ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: Response to BIRD-190
All,
Ultimately, AMI is a specification of the format and syntax of a .ami file and
what the inputs and outputs are of a DLL. It is important that the model makers
write DLLs in accordance with the standards defines of their inputs and outputs.
It is not a requirement of an EDA tool follow the flows suggested in the
standard. SiSoft and other companies believe the flow in IBIS 6.1 gives the
wrong answer, as we stated three years ago. SiSoft uses a flow that gives the
correct answer,
and submitted BIRD 166 to document this.
If other EDA companies state that they are getting the correct answer because
they religiously execute the flows documented in IBIS 6.1, so be it.
Bottom line is when a customer gets a different results from different EDA
vendors we can point them to this discussion and they can decide who is right,
since we cannot.
Walter
Walter Katz
wkatz@xxxxxxxxxx
Phone 303.449-2308
Mobile 303.335-6156
