[ibis] Re: Flexibility of a specification

  • From: Ed Sayre <esayre@xxxxxxxx>
  • To: "Arpad_Muranyi@xxxxxxxxxx" <Arpad_Muranyi@xxxxxxxxxx>, "ibis@xxxxxxxxxxxxx" <ibis@xxxxxxxxxxxxx>
  • Date: Thu, 11 Jun 2015 02:00:42 +0000

Arpad and fellow IBIS workers:

I agree with your comments about future developments. However, I have a couple
of pertinent questions for you and other IBIS pioneers:


1. How do we use what we have to evaluate channel and driver/receiver
designs when there is so little in the use of user guides?

2. How do we deal with models that don't run at all or models that run on
one simulation engine but not another?

3. Can we define the qualifications of model makers since it seems the
quality of the model depends heavily on the experience of the model maker and
what they know about how devices actuall work?

4. How do we deal with models that run alone but not with another model,
i.e., interoperability?

I find these questions not addressed in any of the the IBIS documents.

As an alternate, the COM tool and Stat-eye, which are MatLab based tools, seem
to have certain limitations as well when the Tx and Rx analog behavior behavior
are included in the simulation. Do you see that semiconductor manufacturers
are going to provide MatLab based behavioral models?

ed

From: ibis-bounce@xxxxxxxxxxxxx [mailto:ibis-bounce@xxxxxxxxxxxxx] On Behalf Of
Muranyi, Arpad
Sent: Wednesday, June 10, 2015 1:17 PM
To: ibis@xxxxxxxxxxxxx
Subject: [ibis] Flexibility of a specification

Todd,

(Changing the subject line again).

Your comments are well taken, but I am having some concerns about the
future of the IBIS specification in general.

Around the time AMI was introduced to the spec IBIS was almost dead.
One of the biggest reason was rooted in its inflexibility. IC vendors
were continually inventing more complex buffers and the spec could
never quite keep up with the new buffer behaviors due to the rigid
nature of the specification.

True, AMI gave a new life to IBIS, but we did NOT solve the inflexibility
and rigidity problem in the spec. In the AMI portions of the specification
we are following the same "predefined" or "canned" style with the various
features and capabilities. And now that the industry has warmed up to the
signal processing buffers and people are starting to get really elaborate
with these types of buffers I am sensing that the IBIS-AMI specification's
rigidity seems to be getting in our way again.

For example, we are starting to learn that the order in which the various
blocks (CTLE, DFE, Tx EQ, etc...) are optimized (with adaptation algorithms)
makes a difference, but the best order of executing these optimizations
also depends on the characteristics of the channel. The AMI specification
has no provisions for letting the model maker or user select the order in
which these blocks are optimized. This is a prime example for how the
predefined flows in the AMI specification are falling short. There are
other issues which suffer from the same problem of inflexibility in the
spec. I am starting to sense that our IBIS committee is not going to be
able to keep up with the speed at which these new capabilities are needed.

I am still convinced that we should eventually come up with a good modeling
language and stay away from a rigid, predefined structures and flows based
specification. The model maker and user should be able to write any model
and use them any way they want to. That's what Matlab does, that's what
VHDL-AMS and Verilog-A(MS) do. Users of these languages are not constrained
by rules that certain functions can only be executed in a pre-defined order,
or the functions are not limited to have a predefined footprint, etc...

I think we are going to have to face these issues soon again...

Thanks,

Arpad
===============================================================================


From: ibis-bounce@xxxxxxxxxxxxx [mailto:ibis-bounce@xxxxxxxxxxxxx] On Behalf Of
Todd Westerhoff
Sent: Wednesday, June 10, 2015 11:26 AM
To: Lance Wang; esayre@xxxxxxxx; bob@xxxxxxxxxxxxxxxxx; ibis@xxxxxxxxxxxxx
Subject: [ibis] Re: BIRD175.2: Extending IBIS-AMI for PAM4 Analysis

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.

Todd Westerhoff
VP, Semiconductor Relations
Signal Integrity Software Inc. * www.sisoft.com
6 Clock Tower Place * Suite 250 * Maynard, MA 01754
(978) 461-0449<978-461-0449> x24 * twesterh@xxxxxxxxxx
"I want to live like that"
-Sidewalk Prophets

JPEG image

Other related posts:

  1. Home
  2. ibis
  3. Archive
  4. 06-2015