[ibis-macro] Re: AMI Info Model_Specific parameters: Market Speed vs Standards Speed
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 24 Mar 2011 14:12:12 -0700
Walter,
The problem is (as I already told you in our private
conversation) that this mechanism can be exploited by
anyone to implement a new feature in their tool, make
models for it, get a bunch of customers hooked on their
proprietary solution, all of which is blessed by the
specification.
You claim that you provided an open "specification" by
releasing the Opal document. But you have to admit that
the Opal document was published publicly after your tool
already had most if not all of it implemented with a
bunch of models in customer's hands. We, your competitors
were automatically put in a competitive disadvantage by
that simple delay in the publishing of the Opal document.
In addition, the Opal documentation is written in a very
ambiguous manner for the most fundamental aspect of the
methodology, the analog modeling, and I don't think anyone
could successfully implement a competing product based on
that...
Note that I am not trying to point fingers here or accuse
anyone of doing anything illegal (that is the lawyers' job),
but this picture is simply not healthy.
Arpad
===========================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Thursday, March 24, 2011 3:53 PM
To: scott@xxxxxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: AMI Info Model_Specific parameters: Market
Speed vs Standards Speed
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(r) 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] 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
Phone 303.449-2308
Mobile 720.333-1107
Other related posts:
