[ibis-macro] Re: Out-InOut BIRD, lets get real

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
  • Date: Thu, 24 Sep 2015 15:55:16 +0000

Walter,

Your answer is like: Is it hot or cold? Yes.

Thanks a lot...

Arpad
================================================

From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Thursday, September 24, 2015 10:41 AM
To: Muranyi, Arpad; IBIS-ATM
Subject: RE: [ibis-macro] Re: Out-InOut BIRD, lets get real

Arpad,

Yes, and that is when the User reads the documentation. At least he knows he
has to read the documentation and ask his EDA vendor what the EDA vendor does.

Walter

From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Thursday, September 24, 2015 11:28 AM
To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Subject: [ibis-macro] Re: Out-InOut BIRD, lets get real

Walter,

In summary, the two purposes you describe are

#1 Control the AMI DLL,
#2 Control the EDA tool.

But the second one can still be done in two different ways:

#A Without breaking the basic functionality of the model, i.e.
all tool can generate the basic eye diagrams and BER plots
correctly, and the tool that is capable of doing extra stuff
for that particular model can do more than the basics for
their user
#B The model would only work correctly in those EDA tool(s) which
understand these special Model_Specific parameters and other
tools will not be able do anything useful with the model.


Should the new Reserved parameter flag case B only, or both A and B?

Thanks,

Arpad
=====================================================================


From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Thursday, September 24, 2015 9:46 AM
To: IBIS-ATM
Subject: [ibis-macro] Out-InOut BIRD, lets get real

All,

Let's step back and discuss what AMI Model Specific parameters are all about:


1. There are two primary purposes of Model Specific AMI parameters

a. Control what the DLL does

i. The DLL
should be controlled the way the silicon works

1. These usually map into the hardware registers that control the actual
buffer

2. Tx Tap settings

3. Rx CTLE settings

ii. Model
maker want to allow the user to turn on and off model features

iii. Use to
configure the DLL when the DLL supports multiple buffer implementations

b. Report to the user what the DLL did

i. DFE tap
values

2. The model maker wants to convey information to the User/EDA tool on
how to control simulations

a. An example of this is a requirement that this Tx model has 8b10b
encoding built into it

b. Another example is that analog model required to generate the impulse
response of the channel is a function of the CTLE AMI setting

c. Another example is that the Rx model returns a parameter that the
Model maker wants the EDA tool to use in some waveform analysis calculation

The issue here is that the Model Maker, the User and the EDA Vendor wants the
Model Maker to add Model Specific parameters to allow the EDA tool to
programmatically do the functions described in 2. Above. The perpous of this
BIRD should be a mechanism that the Model Make can convery to the User and the
EDA tool that such Model Specific parameters exists, and a standard place for
him to document the parameters and what he is expecting the EDA tool to do with
them, whether they are Info parameters, In parameters, Out parameters, or InOut
parameters.

Walter


Walter Katz
wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308
Mobile 303.335-6156

Other related posts: