Arpad,
There are multiple solutions to this problem, but I do not think that it can
be resolved as part of IBIS 7.0.
I suggest that we end up tabling BIRD 166 and 190 in the IBIS Open Forum.
In any case we have well documented the issue,
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 1:07 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Response to BIRD-190
Could it be turned off, or its results be simply discarded when not needed?
Thanks,
Arpad
============================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Miller
Sent: Tuesday, June 20, 2017 12:04 PM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx
<mailto:Arpad_Muranyi@xxxxxxxxxx> >
Cc: ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Response to BIRD-190
One problem with the "multiple pass" approach is that Model_Specific
adaptation, if turned on, gets in the way.
Bob
On Tue, Jun 20, 2017 at 11:00 AM, Bob Miller (APD) <bob.miller@xxxxxxxxxxxx
<mailto:bob.miller@xxxxxxxxxxxx> > wrote:
In the past, there has been proposal to make AMI_Init re-entrant by
specifying that if the AMI memory_handle passed in is NULL, AMI_Init starts
from scratch like today. If not NULL, AMI_Init assumes it is valid and skips
creating/initializing the memory structure.
Such an AMI_Init works already in legacy simulations with multiple EDA
platforms (many pass a NULL memory_handle in as SOP).
We did not get agreement on that, though, and when we quit pursuing BCI in
Init it went away.
Bob
On Tue, Jun 20, 2017 at 10:49 AM, Bob Miller (APD) <bob.miller@xxxxxxxxxxxx
<mailto:bob.miller@xxxxxxxxxxxx> > wrote:
Does Fangyi's proposal solve the adaptation problem (rx2 init needs the
complete upstream info in it's impulse_in)? I don't think so unless I've
forgotten something therein...
Bob
On Tue, Jun 20, 2017 at 10:32 AM, Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx
<mailto:Arpad_Muranyi@xxxxxxxxxx> > wrote:
Good question. Let’s discuss it in ATM today…
But there were a few “implementation options” to Fangyi’s proposed solution
too.
For example, instead of adding more IR inputs and outputs to the Init
function, we
could execute the Init functions multiple times to generate the different
IRs that
are needed for the “correct flow”. This might work without changing the
models,
as far as the IR input/output is concerned. However, we would need to
figure out
how to prevent the Init functions to initialize/optimize twice, though… I
didn’t think
all this through in detail yet. This is why we need all the experts come
together and
find a good way to do this…
The fundamental concept in Fangyi’s proposal that we need to aim to
implement is
that we need to find a way to have the Init functions generate “self IR-s”
and
“cumulative IR-s” in each channel. Without having both of these, I don’t
think we
can solve the problems we are discussing…
Thanks,
Arpad
=================================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx ;<mailto:wkatz@xxxxxxxxxx> ]
Sent: Tuesday, June 20, 2017 10:59 AM
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,
If we approve Fangyi’s BIRD today, what do we do in the Redriver flow for
legacy models that do not return the new IR from the AMI_Init function.
Walter
Walter Katz
wkatz@xxxxxxxxxx <mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308 <tel:(303)%20449-2308>
Mobile 303.335-6156 <tel:(303)%20335-6156>
From: ibis-macro-bounce@xxxxxxxxxxxxx
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Tuesday, June 20, 2017 11:44 AM
To: ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Response to BIRD-190
Walter,
I don’t think any of us is trying to block innovation here. But there are
reasons to have
a specification and have consistency in it. We can twist the rules and
intent of a spec
only so far before chaos takes over. But in the name of serving the user
and innovation,
let’s approve and implement Fangyi’s proposal right now! This is the only
proposal at
this time that I am aware of that solves the problem as it should be solved.
You keep saying that BIRD166 does this and that while BIRD190 doesn’t, but
you seem
to forget that it has been demonstrated that while BIRD166 may fix the
statistical flow,
it introduces problems in the time domain flow which weren’t there before.
Also, you
haven’t responded to some of the questions related to your latest version
regarding
the “8b” paragraph, which basically says that if any of the GetWave
functions are missing,
the analysis should be done with all of the Init functions. It is not
guaranteed that all
models will have Init_Returns_Impulse=true. If any of the models has a
false for that,
and any of the other models have no GetWave function, you won’t be able to
simulate
at all. BIRD166 needs some work. It simply can’t be approved as it stands
today.
Thanks,
Arpad
=====================================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Tuesday, June 20, 2017 7:20 AM
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,
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 <tel:(303)%20449-2308>
Mobile 303.335-6156 <tel:(303)%20335-6156>
