Scott, Arpad, Ken, and Fangyi
We all agree that everyone should be free to innovate. But, respectfully,
what is happening here is a concerted effort to make sure that any new
capabilities are squashed until slower implementers can provide a
solution. I interpret this as a deliberate intent to slow the usage and
adoption of new capabilities that customers require today.
I know that Scott's so called "Red Herring" (i.e. Innovation: i.e. the
ability to bring new user capabilities to the market) is a distressing
issue. From his comment
"I've seen way too much "innovation" in IBIS-AMI that did not go through
the committee, and did not have input from a broader community."
I've learned that there is a belief that the proper way to get an idea
drafted is to bring a rough idea to a large committee for discussion
before there are concrete examples. Fortunately, wasting people's time is
not a pastime we enjoy as much as others. In that light, we drafted OPAL
tm which provided not only our thoughts on model development, but
parameters and associated definitions we wanted to see in the IBIS
specification. Key insights that we believed would be considered by the
EDA/Model developer community over 10 months ago. We then broke those down
into individual IBIS Birds for group discussion which has been happening
for the last 6 months.
Did we implement the concepts in the BIRD? YES! They were needed for
design work we were doing and we are fully committed to updating those
models once the final definition of parameters is agreed upon within IBIS.
We just are not willing to wait years for this to happen!
The discussion about how IBIS-AMI should mature and develop is so twisted
that at times it defies belief. I quote
"There seems to be an implicit assumption in this discussion that what the
"innovators" decide to do should not be modified at such time that the
"innovation" is submitted to the IBIS-ATM committee for consideration."
As a group submitting a proposal, of course we will defend what we wrote.
Make a good suggestion or counter proposal and as all committee members we
will debate the merits. No one assumes that everyone will agree with
everything they write, but I guess some get offended when you defend your
ideas.
Another term that gets bantered around is the term "Compliant". This is a
major issue since any model that a vendor develops with advanced
capability would now get labeled as non-compliant. What exactly is a
compliant model? Let's take 2 cases:
Case 1: I add the capability to add back-channel communication to a model
and that such capability is fully documented and runs in only my simulator
upon introduction. In other vendor tools the model runs correctly, but
without the back channel operation.
Case 2: Same model and code as above, but with the back-channel code
disabled in all simulators
In other simulators, Case 1 and Case 2 provide the same results. Only in
my simulator can alternative results be obtained due to the advanced
function. Why should the Case 1 model be considered "non-compliant"? Yes,
it has parameters beyond those in the released specification version, but
its usage is documented and available for review, discussion, acceptance,
or rejection by the open forum and it besides its advanced capability, it
is no different from Case 2
The group must come to terms with a fair way of allowing advanced models
without penalty before it takes actions to outlaw such models!
Scott, two things I direct to you:
1. One: I wish you would stop being only a rock thrower and instead be
a constructive influence and contributor. In your last sermon you
complained specifically about the S-parameter proposal and Jitter
proposal. This is not the first time you have expressed such an opinion
and you claim they are incomplete and that there are:
"deep practical and technical issues that require clear and precise
communication, so that we are all absolutely sure that these parameters
meet present and future needs"
But your specific inputs, alternative Bird proposal, or other action to
advance the state of the art in these areas is sorely lacking.
2. All IBIS AMI files that we have developed for suppliers are fully
compliant with IBIS 5.0 and run in all simulators without modification. I
have had no feedback from IC vendors to the contrary except on the first
models we provided. If you have received an improper model, please
communicate the model and vendor to me privately so I can make sure that
they are providing only fully standard IBIS models. Given your
characterization of us as a dog, I will happily choose to be the Greyhound
since the scenery only changes for the lead dog.
The last item I will touch upon is how the committee uses it's time. While
I appreciate everyone's commitment, it is truly amazing that of all the
important topics to be discussed, at the forefront is making sure that new
features in a model can be immediately labeled as non-compliant. I'm
sorry, but this smells like an agenda for companies that can't or won't
keep up with customer demands. IBIS has long been criticized as being
behind in the times and this type of action is making sure it stays there.
I would argue that the specification should be supporting ways that
designers can add new features in a way that is compliant. Instead, what I
hear being proposed is that every idea must pass through the 1-2 year
process of this committee before it can be used. Given the preciousness of
a person's time, I wonder why that time is not being spend on critical
customer issues such as?
* Sparameter support
* Jitter handling
* Back Channel/Optimization
* Repeaters/Retimer
* 25G extensions
* Etc
Best regards,
Doug
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis <optional e-mail address, if different> | subscribe ibis-users <optional e-mail address, if different> | unsubscribe ibis <optional e-mail address, if different> | unsubscribe ibis-users <optional e-mail address, if different> | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993Received on Wed Apr 27 19:36:47 2011
This archive was generated by hypermail 2.1.8 : Wed Apr 27 2011 - 19:37:24 PDT