Lance,
Your statement assumes that people can build accurate IBIS-AMI models for
state of the art applications with nothing but what you consider to be
fully compliant IBIS-AMI syntax.
Unfortunately, that's not true and never has been.
Signal Integrity is, by its very nature, a fast moving business (Hah! Pun
intended) and we shouldn't expect that model standardization efforts will
keep up with technology in development. In fact, it's a paradox - you need
to be able to model it to design it, and you don't even know if it's worth
standardizing until you've achieved a level of customer production
commitment.
Telling model makers and systems designers that they can use nothing but
"approved" IBIS-AMI syntax is tantamount to telling customers that they
either aren't going to be able to design at the state of the art, or that
if they choose to do so, they must accept reduced accuracy for the sake of
model standardization. Perhaps your customers are willing to accept that -
mine aren't.
So, we see it as an unfortunate fact of life that real work will lead the
IBIS standard, and that a responsible method of using "pre-standard"
syntax is required. In our view, this requires
1. Collaborating closely with model makers to understand which
behaviors need to be modeled
2. Careful evaluating the use of standard versus pre-standard syntax
to ensure there is a measurable and justifiable benefit
3. Defining pre-standard syntax to be as compatible with existing
IBIS-AMI syntax and conventions as possible
4. Implementing and verifying new syntax to ensure it delivers the
expected benefit
5. MOST CRITICALLY, BRINGING PROPOSED NEW SYNTAX BACK TO THE
COMMITTEE AND STANDARDS PROCESS AS SOON AS POSSIBLE
6. Driving the standards process forward as quickly as possible and
updating models/tools to conform to the standard as it evolves
We have followed this formula since 2007 and it works for us.
Todd.
<https://mailsrv.sisoft.com/service/home/~/?auth=co&id=232523&part=2>
Todd Westerhoff
VP, Semiconductor Relations
Signal Integrity Software Inc. . www.sisoft.com
6 Clock Tower Place . Suite 250 . Maynard, MA 01754
(978) 461-0449 x24 . twesterh@xxxxxxxxxx
"I want to live like that"
-Sidewalk Prophets
From: Lance Wang [mailto:lwang@xxxxxxxxxx]
Sent: Wednesday, June 10, 2015 10:56 AM
To: twesterh@xxxxxxxxxx; esayre@xxxxxxxx; bob@xxxxxxxxxxxxxxxxx;
ibis@xxxxxxxxxxxxx
Subject: Re: [ibis] Re: BIRD175.2: Extending IBIS-AMI for PAM4 Analysis
Well said, Todd.
I do think the root cause of this frustration is because the "particular"
model only works (or works as expected) in the "particular" tool(s).
Sometimes, It even had been modeled on purposely and using the word "IBIS"
to fool the users. It may be passed thru the IBIS golden parser (e.g.
Putting special keywords in the commented line, in the executables, in the
external models, etc.). This is not only happened for IBIS-AMI models but
also for the traditional IBIS models.
They are not IBIS Compliant. So, they are not the Standard IBIS models.
Please remember that the inter-operability feature is the most important
feature for any Standards as well as IBIS.
Here are my suggestions as the extension of Todd's comments:
1. For the users, we should stop using the non-standard models. If it
is so called IBIS/IBIS-AMI model, it should be IBIS Standard Compliant.
2. The model vendors/EDA vendors, let's stop to make the
"fooled-IBIS" models. We can have our own model format. But don't call it
is IBIS model or "IBIS something" to fool the users
3. IBIS Open Forum should come out a detailed validation flow in
order to stop non-IBIS Compliant models
4. Finally, I would echo Todd's #2 comment again. Let's work with
IBIS Open Forum for identifying and resolving the weakness in the spec.
IBIS Open Forum welcomes any comments, suggestions and solutions to make
IBIS more robust. But not another way around.
Best regards,
Lance Wang
IO Methodology Inc.
978-764-2298
On 6/10/15, 9:35 AM, "Todd Westerhoff" <twesterh@xxxxxxxxxx
<mailto:twesterh@xxxxxxxxxx> > wrote:
Ed,
That's a pretty broad topic. I have no doubt that your customers are
experiencing issues; it's been our experience that different model makers
and EDA vendors are interpreting key sections of the IBIS-AMI spec
differently, and that is affecting how models run and the results they
produce.
In our opinion, there are two parallel paths to solving this problem:
1) Work directly with model makers to understand why a *particular*
model doesn't work in a *particular* tool. In other words, the details
matter.
2) Identify and resolve weaknesses in the spec that affect model
robustness and portability - particularly areas where a model/tool can
produce different results and *still* conform to the spec (I like to call
this condition under-specified)
As you would expect, we do both. Obviously, we focus our efforts on the
EDA tool we have access to (ours) and seek to bring our learnings back to
the IBIS committee.
Bottom line, there's no easy answer to your question - if you're in a
position to help us create examples and guides, we'll take all the help we
can get!
Todd.
<https://mailsrv.sisoft.com/service/home/~/?auth=co&id=232523&part=2>
Todd Westerhoff
VP, Semiconductor Relations
Signal Integrity Software Inc. . www.sisoft.com
6 Clock Tower Place . Suite 250 . Maynard, MA 01754
(978) 461-0449 x24 . twesterh@xxxxxxxxxx
"I want to live like that"
-Sidewalk Prophets
From: ibis-bounce@xxxxxxxxxxxxx <mailto:ibis-bounce@xxxxxxxxxxxxx>
[mailto:ibis-bounce@xxxxxxxxxxxxx] On Behalf Of Ed Sayre
Sent: Tuesday, June 9, 2015 5:25 PM
To: bob@xxxxxxxxxxxxxxxxx <mailto:bob@xxxxxxxxxxxxxxxxx> ;
ibis@xxxxxxxxxxxxx <mailto:ibis@xxxxxxxxxxxxx>
Subject: [ibis] Re: BIRD175.2: Extending IBIS-AMI for PAM4 Analysis
Bob:
A number of folks that I communicate with have expressed great frustration
with the use of IBIS-AMI models in their simulators of choice. Are there
examples and a user guide which go beyond the specification?
ed
From: ibis-bounce@xxxxxxxxxxxxx <mailto:ibis-bounce@xxxxxxxxxxxxx>
[mailto:ibis-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
Sent: Tuesday, June 09, 2015 11:39 AM
To: ibis@xxxxxxxxxxxxx <mailto:ibis@xxxxxxxxxxxxx>
Subject: [ibis] Re: BIRD175.2: Extending IBIS-AMI for PAM4 Analysis
All,
On re-reading BIRD175.2, I have a few comments:
1. Both "PAM4_UpperThreshold" and "PAM4_Upper_Threshold" appear in
BIRD175.2.
(Same for *Center_Threshold and *Lower_Threshold.)
I would prefer using the underbar "_" for these parameters and also for
the *Offset parameters.
2. For the *Threshold parameters, the rule:
* If the Reserved AMI Parameter Modulation is set to "PAM4" and
these threshold values are not declared, the model maker shall assume that
the EDA tool may choose a value for each of these three parameters.
should be changed.
All three parameters definitions should be declared if Modulation is set
to "PAM4" with Value
or in a List. Otherwise we are using "implicit" parameter definitions in
IBIS-AMI on unpredictable
results between EDA tools. However, the EDA tool can re-assign the
values.
3. The defaults of 0.0 are OK for the *Offset* parameters, if they are
missing.
(I will be out today, so I may not be able to respond.)
Bob
From: ibis-bounce@xxxxxxxxxxxxx <mailto:ibis-bounce@xxxxxxxxxxxxx>
[mailto:ibis-bounce@xxxxxxxxxxxxx] On Behalf Of Mirmak, Michael
Sent: Friday, June 05, 2015 11:34 AM
To: ibis@xxxxxxxxxxxxx <mailto:ibis@xxxxxxxxxxxxx>
Subject: [ibis] BIRD175.2: Extending IBIS-AMI for PAM4 Analysis
An updated BIRD175.2, Extending IBIS-AMI for PAM4 Analysis, has been
submitted on behalf of Walter Katz, Mike Steinberger, and Todd Westerhoff
of SiSoft; Fangyi Rao of Keysight Technologies; Bob Miller of Avago
Technologies; and Hongtao Zhang of Xilinx. It will be discussed at the
next IBIS Open Forum teleconference.
The text of the BIRD can be viewed at
http://www.eda.org/ibis/birds/bird175.2.docx.
Michael Mirmak
Intel Corp.
Chair, IBIS Open Forum
http://www.eda.org/ibis/
