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>; 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
Mobile 303.335-6156
