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

  • From: "Walter Katz" <wkatz@xxxxxxxxxx>
  • To: <Arpad_Muranyi@xxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Thu, 24 Mar 2011 16:30:06 -0400 (EDT)

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 OpalT 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: