[ibis-macro] Questions/comments on the draft AMI BIRD document
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Mon, 7 Dec 2009 09:23:12 -0800
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
Other related posts:
