[ibis-macro] Re: Typos_Format_Value_Default_BIRD_4 discussion
- From: Bob Ross <bob@xxxxxxxxxxxxx>
- To: Arpad_Muranyi@xxxxxxxxxx
- Date: Thu, 21 Oct 2010 08:17:28 -0700
Arpad:
There are probably several effective ways to document the
general syntax, such as with your proposal shown here. In fact
it could be reduced to the last choice with some notes nearby.
|* All parameters must be in one of the two following
|* formats (order not important):
|*
|* (parameter_name (Usage <usage>)
|* (Type <data_type>)
|* (<data_format> <data>)
|* (Default <value>)
|* (Description <string>))
|*
|* (parameter_name (Usage <usage>)
|* (Type <data_type>)
|* (Format <data_format> <data>)
|* (Default <value>)
|* (Description <string>))
1. The word 'Format' is optional and can be ignored by EDA tools.
The examples in this section not show the word 'Format'.
2. Certain Reserved_Parameter names allow only certain <data_format>
selections, as sumarized in Table ....
3. When permitted, the <data_format> selection of Value and Default
are always mutually exclusive. Value or Default are required, but
Value and Default cannot be used together.
4. <data_format> is always required for selections other than Value
5. Default is optional when <data format> is not Value.
------
These clarification should be documented with the syntax, even if they
repeat what is stated 3 or pages elsewhere.
Note, rule 3. The current specification requires Format for all
parameters except the first four Reserved_Parameters, and makes
Default optional. So the cases for Value and Default together are
currently allowed. However, due to lack of clarity, it does make
sense to make this awkward situation illegal, as proposed. The
few models that have this can be fixed.
Finally the more general rule, at least for Model_Specific
parameters at this time, is that parameter_structures are
optionally part of the syntax - recursively. If the whole
syntax can be referred to as a 'parameter_structure', the
more general syntax is:
|* (parameter_name (Usage <usage>)
|* (Type <data_type>)
|* (Format <data_format> <data>)
|* (Default <value>)
|* (Description <string>)
(paramater_structure_1)
(parameter_structure_2)
....
|* )
The example for txtaps illustrates this. The parameter_name
'txtaps' encloses parameter structures for each tap parameter
name: '-2' to '2'. This is consistent with the general
tree-structure basis of the .ami file.
Bob
Muranyi, Arpad wrote:
Hello everyone,
I am working on incorporating the comments I received
yesterday on the Typos_Format_Value_Default_BIRD draft.
One of the comments I received was to remove the following
lines:
These four reserved
|* parameters must be in one of the three following formats
|* (order not important):
|
|* (parameter_name (Usage <usage>)
|* (Type <data_type>)
|* (Value <value>)
|* (Description <string>))
|*
|* (parameter_name (Usage <usage>)
|* (Type <data_type>)
|* (Default <value>)
|* (Description <string>))
|*
|* (parameter_name (Usage <usage>)
|* (Type <data_type>)
|* (Format Value <value>)
|* (Description <string>))
Removing these lines doesn't make sense to me because each
of the four parameter type description (Reserved, Tx only,
Rx only, and Model Specific) begin with a general syntax
rule, and removing these lines means that we are removing
the general syntax rule description for the Reserved parameters.
To try making sense, I looked at what the existing v5.0
specification does when it defines the various parameter
syntaxes. Pulling the four occurrences of the syntax rules
and putting them closely together, I don't see too many
variations between them, except that the reserved parameters
have "Default <value>" only, while the rest of them also have
"Format <data format>":
Reserved parameters:
====================
| (<parameter_name> (Usage <usage>)
| (Type <data_type>)
| (Default <values>)
| (Description <string>))
Tx only parameters:
===================
| (<parameter_name> (Usage <usage>)
| (Type <data_type>)
| (Format <data format>)
| (Default <values>)
| (Description <string>))
Rx only parameters:
===================
| (<parameter_name> (Usage <usage>)
| (Type <data_type>)
| (Format <data format>)
| (Default <values>)
| (Description <string>))
Model Specific parameters:
==========================
| (<parameter_name> (Usage <usage>)
| (Type <data type>)
| (Format <data format>)
| (Default <values>)
| (Description <string>))
Making "Value" available (on Walter's request) for the reserved
parameters (first group above) makes the syntax of the four
groups identical (as far as I can tell), with the rule that the
first group's data_format can only use "Value" (and the additional
rule that Value and Default are mutually exclusive). If this
conclusion is correct, I would just "factor out" this syntax
description and mention it once and apply it to all parameter
types in their text. Is that acceptable to all of you?
The rule about Value and Default being mutually exclusive is
still valid for all parameter types, and the backward compatible
"Format Value" will also have to be allowable for the reserved
parameters then. So I propose to have this once in the spec:
|* All parameters must be in one of the two following
|* formats (order not important):
|*
|* (parameter_name (Usage <usage>)
|* (Type <data_type>)
|* (<data_format> <data>)
|* (Default <value>)
|* (Description <string>))
|*
|* (parameter_name (Usage <usage>)
|* (Type <data_type>)
|* (Format <data_format> <data>)
|* (Default <value>)
|* (Description <string>))
and refer to this in the descriptions of the various parameter
groups. At that level we can then specify for the Reserved
parameters that they can only use data_format "Value".
This would make the specification clearer and more consistent.
Please let me know what you think of making these changes.
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
--
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
Other related posts:
