[ibis-macro] Re: Questions/comments on the draft AMI BIRD document

  • From: "Walter Katz" <wkatz@xxxxxxxxxx>
  • To: <Arpad_Muranyi@xxxxxxxxxx>, "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Tue, 8 Dec 2009 08:42:01 -0500

All,

Here are my answers to the posted questions.

1. Rx_Clock_Recovery_Mean and Rx_Clock_Recovery_Rj are the <mean> and
<sigma> in
a. (Rx_Clock_PDF (Usage Info)(Type Float)(Format Gaussian <mean> <sigma>))
b. When GetWave Exists and returns clock ticks, then the EDA tool can infer
the clock recovery distribution from the clock tick distribution.
Rx_Clock_Recovery_Mean is the offset of the average (mean) clock tick from
the center of the eye. Rx_Clock_Recovery_Rj is the Gaussian sigma of this
distribution, and are used when GetWave clock ticks are not available.
c. IC Vendors require that the values of these parameters are a function of
process corner, and therefore Rx_Clock_PDF was found to be useless.
2.  The Reserved_Parameters keyword and the Model_Specific keyword should be
dropped because new useful parameters (such as Rx_Clock_Recovery_Mean and
Rx_Clock_Recovery_Rj) must be added as Model_Specific parameters. These are
useful as Reserved_Parameters for all tools. By requiring  the
Reserved_Parameters branch and the Model_Specific branch it would make ami
files valid if IBIS made these parameters  Reserved_Parameters. Note that I
am not proposing that they be dropped, I am just proposing that they be
ignored.
3. (See 2.)
4. I do not object if the Description keyword be optional throughout. We
have our own internal standard that requires it for models we produce for IC
Vendors.
5. Again we are not dropping Format, just ignoring it. Format violates the
basic principle of parameter trees. The principle is that a keyword defines
the data that follows. In the case of Format it is the keyword Format plus
the secondary keyword that follows it that defines the data that follows. It
was a mistake to put it in in the first place, and it was objected to at the
time, and we were told it was going to be removed. It slipped through crack
because simultaneously the spec was put into .txt format with out
highlighting changes, and we just did not pick it up. This is the time clean
this up.
6. The jitter distribution function for Tx_Dj is a uniform distribution
within [-Tx_Dj/2, Tx_Dj/2]. This, along with many of the parameters should
have improved description/definition.
7. A List is a list of things of "Type". So if Type is Integer, then the
list must only contain integers. If a Type is float the List must contains
floats. Note that an integer can also be a float. If Type is String then the
list must only contain strings. Note that a string requires "" is it
contains blank space and other special characters. Also note that Integers
and Floats can make valid Strings.
8. List no longer contains typ, but a list of values. In a separate table on
the used of Default and default values I document that if Default is not
specified, then the first value in the list is the default or nominal or typ
value. No real change in functionality, just my attempt to clean up the
document.

Walter

Walter Katz
303.449-2308
Mobile 720.333-1107
wkatz@xxxxxxxxxx
www.sisoft.com

-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]On Behalf Of Muranyi, Arpad
Sent: Monday, December 07, 2009 12:23 PM
To: IBIS-ATM
Subject: [ibis-macro] Questions/comments on the draft AMI BIRD document

Hello everyone,

Per our discussion in the last IBIS-ATM teleconference,
here is a list of the questions and suggestions raised
about Walter's IBIS-AMI BIRD draft which is located at:

http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20091118/walterkatz/
Algorithmic_Modeling_API_AMI_Improvements_BIRD.zip

The purpose of doing this is to keep hose who didn't
attend the teleconference informed, and to be able to
make some progress between the meetings on questions
which may have a simple answer.  We don't have to write
long emails discussing questions which are more involved,
we can discuss those in the teleconference more effectively.

So here are the questions, in no particular order:

1)   Please clarify the usage of the new Rx_Clock_Recovery_Mean
     parameter

2)   Why should the Reserved_Parameters keyword be dropped?

3)   Why should the Model_Specific keyword be dropped?

4)   The Description keyword should be optional throughout

5)   Why eliminate "Format" when it is currently required?

6)   What is the jitter distribution function for Tx_Dj?
     Dual-Dirac at +/-Tx_Dj/2, or uniform distribution
     within [-Tx_Dj/2, Tx_Dj/2]?

7)   If Tx_Rj is of Usage In, does it mean simulator does not
     need to add Rj to Tx_GetWave input waveform?  What if Tx
     does not have GetWave?

8)   As list being a type, what is the data type of 0, 1,
     and 2 in list(0, 1, 2), integer, or float?

9)   Why does list type no longer have <typ>?


I am going to paraphrase some of Bob's thoughts that he
mentioned in the last meeting and in an email afterwards:

The prototype BIRD represents very good work to get the issues
out on the table.  Thanks to Walter for the work he put into
this.  However, every bit of syntax must remain documented now
and forever, even if we decide to note in some cases as obsolete,
do not use - such as Table.  Some other cases might just be
"optional" alternatives that must remain supported - such as
Format, Reserved_parameters, Model_specific and other words.
Simply deleting something and pretending that something never
existed is not the proper baseline for this BIRD.

We should have a compelling reason to abandon any current
syntax.  If there is a need to scrap something that we have,
then we should open the door to new approaches from other
vendors (which according to Summit presentations have features
beyond our syntax).


I have a comment of my own.  Considering the amount of changes
and new suggested features, I am starting to think that we will
have to do this in two stages, just like we did it in the flow
discussions.  Let's have a smaller set of changes for IBIS v5.1
in which we include only absolutely necessary changes to fix
things that don't work, or don't make sense, and let's put all
other feature additions and broader changes into a later version
of the specification.


Thanks,

Arpad
=================================================================
---------------------------------------------------------------------
IBIS Macro website  :  http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector:  //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
  To: ibis-macro-request@xxxxxxxxxxxxx
  Subject: unsubscribe

---------------------------------------------------------------------
IBIS Macro website  :  http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector:  //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
  To: ibis-macro-request@xxxxxxxxxxxxx
  Subject: unsubscribe

Other related posts: