[ibis] Re: Flexibility of a specification

From: "C. Kumar" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "kumarchi@xxxxxxxxx" for DMARC)
To: "Arpad_Muranyi@xxxxxxxxxx" <Arpad_Muranyi@xxxxxxxxxx>, "ibis@xxxxxxxxxxxxx" <ibis@xxxxxxxxxxxxx>
Date: Thu, 11 Jun 2015 02:13:48 +0000 (UTC)

arpad:
ami spec is not following a canned spec. The interface is extremely simple , ie
waveforms in waveforms out nothing more nothing less. The model maker has all
the flexibility. The flexibility can cause of course can pose a learning curve
for model makers but that is much superior to a predefined notion what a model
or device should be in this fast paced world.
By the way you cannot arbitrarily choose how to arrange the blocks. That is
part of the architecture of the device

From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
To: "ibis@xxxxxxxxxxxxx" <ibis@xxxxxxxxxxxxx>
Sent: Wednesday, June 10, 2015 1:16 PM
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 x24 •  twesterh@xxxxxxxxxx “I want to live
like that”                                              -Sidewalk Prophets

Follow-Ups:
- [ibis] Re: Flexibility of a specification
  - From: Scott McMorrow
- [ibis] Re: Flexibility of a specification
  - From: Muranyi, Arpad

References:
- [ibis] Flexibility of a specification
  - From: Muranyi, Arpad

[ibis] Re: Flexibility of a specification

Other related posts: