[IBIS] RE: [ibis-macro] Re: Minutes from the 26 Apr 2011 ibis-atm meeting Proposed

Doug,

I would appreciate it very much if you would stop making false

accusations and fuel unproductive mudslinging conversations.

This is a useless time sink hindering us from making progress.

Why don't you join our meetings and help us fix the countless

ridiculous things which are in the specification, like Default

values for Required parameters, or Reserved Parameters of

(Usage Out) or (Usage InOut) without mentioning which function

will return them, or Model_Specific (Usage Info) parameters

where the meaning of the parameter is not defined in the

specification due to its nature of being Model_Specific, yet

being (Usage Info) it supposed to pass information to the tool,

and the list goes on and on...

For your information, what we have done in ATM ever since IBIS

5.0 was released is a massive cleanup work of the mess that the

authors of the AMI specification left behind themselves. If

we didn't do that first and allowed an even bigger chunk of

mess to be piled on top of that with a bunch of half baked

proposals, we would have successfully render the specification

completely unintelligible and useless... Is that what you are

trying to achieve in a big hurry?

Sincerely,

Arpad

================================================================

From: ibis-macro-bounce@freelists.org
[mailto:ibis-macro-bounce@freelists.org] On Behalf Of Doug Burns
Sent: Wednesday, April 27, 2011 9:36 PM
To: ibis-macro@freelists.org; ibis@eda.org
Subject: [ibis-macro] Re: Minutes from the 26 Apr 2011 ibis-atm meeting
Proposed

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 1993