[ibis-macro] Re: AMI Info Model_Specific parameters: Market Speed vs Standards Speed

  • From: Scott McMorrow <scott@xxxxxxxxxxxxx>
  • To: Walter Katz <wkatz@xxxxxxxxxx>
  • Date: Thu, 24 Mar 2011 17:13:47 -0400

I'll will retract the word "sneak" and modify my comments as follows:
So essentially these mechanisms are being used create a technical and competitive market advantage with new IBIS_AMI non-standard features, without going through the standardization process first. This allows the model to be "advertised" as IBIS-AMI compliant. Afterwards, once the implementation is fait accompli, a model maker comes back to the committee to standardize what has become a de facto standard for that model.
The EDA vendor whose tool was used for development of the initial non-standard IBIS-AMI model that complies with the standard (because the parameters passed are just "information") gains certain market advantages. The silicon vendor also gains a technical market advantage by enabling new features that are fully exploited by one EDA tool. Documentation of the "parameters" is most likely provided in a document delivered with the IBIS-AMI models, describing how the "parameters" are to be used, but ... the EDA vendor whose tool was used for development of the initial non-standard standard model has already implemented automation of the documented "parameters", such that this is the only EDA tool that the initial models will have full operational capability in. That's all well and good. As long as we all understand and accept that the features will eventually be standardized in due time. (Although it would be really nice for this to occur before the press releases come out.)
From my perspective an informational parameter that is being used to alter modeling or simulation is not standard, and should not be advertised as standard, until it has been turned into a reserved parameter and documented. There are too many cases of model makers introducing features to solve one problem, while ignoring (or even creating) others. 

respectfully

Scott


Scott McMorrow
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
(401) 284-1827 Business
(401) 284-1840 Fax

http://www.teraspeed.com

Teraspeed® is the registered service mark of
Teraspeed Consulting Group LLC


On 3/24/2011 4:53 PM, Walter Katz wrote:


Scott,
We have a problem to solve, we did not sneak this in. We published everything we have done and entertained all reasonable requests for change. I do not think you can ask us to do anything else. 

Walter
*From:*ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] *On Behalf Of *Scott McMorrow 
*Sent:* Thursday, March 24, 2011 4:43 PM
*To:* ibis-macro@xxxxxxxxxxxxx
*Subject:* [ibis-macro] Re: AMI Info Model_Specific parameters: Market Speed vs Standards Speed 

Walter
So essentially these mechanisms are being used to sneak in new IBIS_AMI features without going through the standardization process first. And this allows the model to be "advertised" as IBIS-AMI compliant. Afterwards, once the implementation is fait accompli, a model maker comes back to the committee to standardize what has become a de facto standard for that model. Is my understanding correct? 

Scott




Scott McMorrow
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
(401) 284-1827 Business
(401) 284-1840 Fax
http://www.teraspeed.com Teraspeed® is the registered service mark of 
Teraspeed Consulting Group LLC


On 3/24/2011 4:30 PM, Walter Katz wrote:

Arpad,
The fundamental problem that we face is the need for IC Vendors to supply System Companies with models that they can use today to design next generation high speed products. Info parameters in BIRDS 121-124 are required to do this today. The market cannot wait for IBIS to approve this, and then wait for EDA vendors to support it. It is critical that when it is required to add information to a .ami file that a simulator must use (e.g. a Model_Specific Info parameter), that the parameter be published by submitting a BIRD to make it a Reserved_Parameters. The need for this was described in the Opal^(TM) document, and in numerous IBIS-ATM discussions. In the meantime EDA Vendors have the information they need to support these advanced capabilities as their markets require them. This is exactly what Sigrity and Gennum have done with their backchannel proposed BIRD, and SiSoft will determine when the specification of backchannel is firm enough, and then support it in our tool when our customers require it. 

Walter
*From:*ibis-macro-bounce@xxxxxxxxxxxxx <mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] *On Behalf Of *Muranyi, Arpad 
*Sent:* Thursday, March 24, 2011 2:54 PM
*To:* IBIS-ATM
*Subject:* [ibis-macro] Re: Table Clarification BIRD

If I remember correctly, we spent a considerable time

on this topic in the last ATM teleconference.  In that

discussion I think I heard Walter state something

along the lines of who cares, the EDA tool just copies

everything to the parameter string for DLL and doesn't

need to know whether the first column is a row number

or useful data.

Then the question was raised, how about (Usage Info)

in which case the table is to be consumed by the tool,

and in that case the tool would have to know what the

first column is.

This brought us to the topic of syntax consistency and

ease of parsing, etc...

But this also raises another issue, namely whether the

Model_Specific parameters should ever be (Usage Info).

Note that this is not a problem with Reserved_Parameters,

which supposed to be well defined in the spec.

Comments?

Arpad

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

Walter Katz

wkatz@xxxxxxxxxx <mailto:wkatz@xxxxxxxxxx>

Phone 303.449-2308

Mobile 720.333-1107

Other related posts:

  1. Home
  2. ibis-macro
  3. Archive
  4. 03-2011