[ibis-macro] Re: IBIS AMI Specification Questions/Proposal
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <Arpad_Muranyi@xxxxxxxxxx>, "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 18 Aug 2009 19:22:19 -0400
All,
"(Default "and "(Format" where added late in the process, and their usage
was not well defined and added inconsistently to the examples. Also
Tx_Jitter and Tx_DCD were not very well thought out, nor the usages of
Rx_Clock_PDF and Rx_Receiver_Sensitivity.
As I indicated earlier all of this needs to be clear and well though out,
and this is no small task. I would limit any AMI Parsing to simply meeting
the nested parameter string format, and for each format (e.g. Range, Value,
List), and for that parameters Type (e.g. String, Integer, Float, ...), the
rest of the values in the Format are consistent with the Type and Format.
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: Tuesday, August 18, 2009 6:51 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: IBIS AMI Specification Questions/Proposal
Bob,
Thanks for posting this summary of the problem.
I read trough the attached file and I am not sure what
the reasons are for these inconsistencies. In order to
make the right decisions, I feel we need to ask those
who wrote these portions of the AMI spec to find out
what was their intent. Authors, please speak up...
Thanks,
Arpad
========================================================
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
Sent: Tuesday, August 18, 2009 5:11 PM
To: IBIS-ATM
Subject: [ibis-macro] IBIS AMI Specification Questions/Proposal
All:
This is being sent out per the issue raised at the Aug. 18
meeting concerning parser interpretation of the AMI Spec.
The ibischk5 parser with the -ami flag will check the
syntax of the <file name>.ami file. The attached document
shows several forms for <parameter_name> that are in the
specification. Some of the forms imply a restricted set of
parameters, but then this is contradicted by the example
at the end.
This implies that some parameters are really optional and
not excluded according to the syntaxes given.
The propposal is simply to make all parameters at least
optional, and some required according to a draft Table 4
that is NOT in the specification.
Do the choices in Table 4 look reasonable?
Bob
--
Bob Ross
Teraspeed Consulting Group LLC Teraspeed Labs
121 North River Drive 13610 SW Harness Lane
Narragansett, RI 02882 Beaverton, OR 97008
401-284-1827 503-430-1065
http://www.teraspeed.com 503-246-8048 Direct
bob@xxxxxxxxxxxxx
Teraspeed is a registered service mark of Teraspeed Consulting Group LLC
---------------------------------------------------------------------
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:
