[ibis-macro] Re: Revised Info_Out_InOut_BIRD draft
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <Arpad_Muranyi@xxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
- Date: Sat, 11 Jun 2011 11:27:53 -0400 (EDT)
Arpad,
The presentations I made on Compliancy at the DAC IBIS Summit made it
clear that System Companies require IBIS and AMI models that are compliant
with todays (and foreseeable) model and simulation requirements. It is
important to them that IBIS enable IC Vendors to satisfy these requirement
with IBIS and AMI models that comply with the IBIS specification.
It is incontroversial that such models need to be broadband, properly
support power delivery, and support the configurability of modern driver
and receiver buffers. It is logical that we first focus on improving the
IBIS specification so that IBIS and AMI model developers can create
compliant IBIS models that satisfy the requirement that these IBIS and AMI
models comply with the needs of the industry we are chartered to support.
This e-mail contains an overview of what I believe we need to do to comply
with current and foreseeable industry requirements. At the end of this
e-mail I am proposing alternative language for the Info_Out_InOut_BIRD
that clearly defines a compliant AMI model, and clearly defines how models
define their compliance with the formally approved IBIS specification, and
BIRDs that have been approved. It also defines how models that require
features that are not compliant with either the approved specification or
approved BIRDs shall document such non-compliant features.
Finally, I am recommending specific procedures that the IBIS-ATM committee
should proceed with to speed up the completion of IBIS 5.1 and 5.x.
What we need to do to enhance IBIS so that IC Vendors can create models
that are both compliant with the IBIS Specification and comply with the
needs of the industry.
1. To satisfy the need to be able to generate compliant Channel
Impulse Responses
a. Broadband Analog Buffer Models
i.
There are now two proposals to use IBIS-ISS to represent AMI Buffer
Models. My Compliant Analog Buffer Model DAC Summit presentation proposed
one method of enhancing IBIS to do this. The presentation described the
functionality required, one syntactical implementation, and examples. You
have presented an alternative method by enhancements to the existing
[External Model] syntax. I requested that you implement these examples
using [External Model] presented with my approach. With a side by side
comparison IBIS-ATM can first verify which (or both) implementations
comply with the needs of the industry, and then decide which approach we
should move forward on. Once a decision on the path IBIS-ATM chooses we
can write the details of a BIRD in move forward on a timely basis.
b. Broadband Package Models
i. My
Compliant Package Model DAC Summit presentation proposed an IBIS and EBD
syntax, functionality required and examples. Again, I requested that you
implement these examples using your proposals. With a side by side
comparison IBIS-Interconnect can verify the compliance of each of these
methods with the needs of the industry, decide the approach, and implement
a BIRD.
c. Model Configurability
i.
BIRD 124 defines a method to configure AMI Analog Buffer models based on
the configuration of AMI parameters selected for a simulation. This is
independent of either of the proposed syntaxes of Analog Buffer Models.
2. To satisfy the need to account for Jitter and Noise in AMI
simulations, and to comply with standard industry methods of defining
Jitter we need to move forward on the Jitter BIRD 123.
3. The Data Management BIRD 121 defines a way that AMI models can
find supporting files (such as additional DLL's and data files. It also
defines a standard method that DLL's can open output files with unique
names to avoid corruption of data when simulations contain more than one
instance of a model (e.g. crosstalk simulations) and multiple simulations
in a directory.
Alternative wording for the Info_Out_InOut BIRD:
An AMI model that uses Model_Specific parameters of (Usage Out), (Usage
InOut) or (Usage Info) that influence the EDA platform in how it prepares
the input data for the algorithmic models, and/or how it processes the
data returned by the algorithmic models shall be considered as
non-compliant with this specification. A model may use such Model_Specific
parameters that have been defined as Reserved_Parameters in BIRDs approved
by the IBIS Open Forum. While not compliant with this specification, the
model shall document that it complies with this specification and the
specific BIRDs that have been approved by the IBIS Open Forum. Am AMI
model that uses such Model_Specific parameters that have not been approved
by the IBIS Open Forum is non-compliant, the model shall document these
Model_Specific parameters and what the model expects the EDA Tool to use
these Model_Specific parameters. The documentation of these model
Model_Specific parameters shall be included in the (Description section of
the AMI Reserved Parameter Version.
IBIS-ATM Procedural Changes
I also propose that we set up an AMI editorial committee now that will be
charged with re-writing the AMI sections in IBIS incorporating the BIRDs
that have been approved by the IBIS Open Forum, and those BIRDs that
IBIS-ATM choose to move to the Editorial Committee for finalization. I
think this will streamline the process of getting a clean IBIS AMI section
in IBIS 5.1, and allow IBIS-ATM to focus on the enhancements to IBIS-AMI
that will go into IBIS 5.x.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Friday, June 10, 2011 8:47 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: Revised Out_InOut_BIRD draft
Walter,
I addressed two requests in this draft.
1) I was asked to add words before "must not" to
indicate that this refers to wanting to be in
compliance with the spec, and is not applicable
in general. So I added the words:
".in order to be compliant with this specification,
Model_Specific parameters . must not."
2) You requested that I define the word "simulation".
Instead of defining "simulation", I changed the text
so that it does not use the word "simulation":
".to influence the EDA platform in how it prepares the
input data for the algorithmic models, and/or how it
processes the data returned by the algorithmic models."
So in this version of the draft I made the changes that
were requested of me. I wasn't asked to include anything
to "reflect the issues raised in my [your] DAC IBIS Summit presentation
I [you] gave on Compliant IBIS-AMI Models". There was a comment
in the last ATM teleconference that we should wait with
the discussion of this BIRD draft until after DAC, which
is now.
I made the changes, the time is here, let's review the
draft and finalize it. Comments and suggestions are
welcome from everyone interested in the wellbeing of
the AMI specification.
Thanks,
Arpad
===========================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Friday, June 10, 2011 7:08 PM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: [ibis-macro] Revised Out_InOut_BIRD draft
Arpad,
I do not think these words reflect the issues raised in my DAC IBIS Summit
presentation I gave on Compliant IBIS-AMI Models. I think that my comments
should be discussed and considered in the committee.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Friday, June 10, 2011 4:44 PM
To: IBIS-ATM
Subject: [ibis-macro] Revised Out_InOut_BIRD draft
Hello everyone,
Here is a revised version of the Out_InOut_BIRD draft.
Please read it over carefully and send me your comments.
I would like to discuss this in the upcoming ATM
teleconference on Tuesday, and if all goes well,
vote on it for submission to the Open Forum and put
it to rest.
Thanks,
Arpad
=========================================================
Other related posts:
- » [ibis-macro] Re: Revised Info_Out_InOut_BIRD draft - Walter Katz
