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

Hi All,

It seems to me that the purpose of a standard is to promote the creation of portable models. Why go to all the trouble of a long series of tense committee meetings between competitors otherwise? Portability comes at a price and that price is that it takes longer to incorporate innovation.

The definition of a portable model isn't just that it is syntactically compliant with the standard, it must also be semantically compliant in that it should give the same answer (within some acceptable accuracy) on all compliant simulators.

If an model contains proprietary extensions it is, by this definition, non-compliant because it is deliberately engineered to give a radically different answer (when run on a simulator with the matching proprietary capability) than a model without the extension. Why bother adding the extension otherwise? Sure, the model might run in a simulator without the matching proprietary capability, but clearly it will then give the wrong answer, which is worse than not running at all.

It doesn't matter whether the proprietary extensions are documented or undocumented by the originator, nor whether they are proposed as a BIRD or not, nor whether they have technical flaws or not: they are still outside of the ratified standard, therefore controlled only by the author (who could change it at will to match their latest simulator release), and therefore models that use it are de facto non-portable.

I have no objections to proprietary extensions. They have the advantage that innovation can be included quickly, but the disadvantage is that models that include them are non-portable.

So my point (and I do have one) is that models with proprietary extensions should not be labeled "compliant." That label should be reserved for portable models that are both syntactically and semantically compliant with the ratified standard of the time.

My $0.02

-- Colin

From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Muranyi, Arpad
Sent: Thursday, April 28, 2011 4:14 AM
To: ibis-macro@freelists.org; ibis@eda.org
Subject: [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<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
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