Bob, I am looking at the "txtaps" example, and I don't understand what you are saying with "parameter_structure_x". Here is the example from pg. 150: (Model_Specific | Required heading (txtaps (-2 (Usage Inout)(Type Tap) (Format Range 0.1 -0.1 0.2)(Default 0.1) (Description "Second Precursor Tap")) (-1 (Usage Inout)(Type Tap) (Format Range 0.2 -0.4 0.4)(Default 0.2) (Description "First Precursor Tap")) (0 (Usage Inout)(Type Tap) (Format Range 1 -1 2)(Default 1) (Description "Main Tap")) (1 (Usage Inout)(Type Tap) (Format Range 0.2 -0.4 0.4)(Default2 0.2) (Description "First Post cursor Tap")) (2 (Usage Inout)(Type Tap) (Format Range 0.1 -0.1 0.2)(Default 0.1) (Description "Second Post cursor Tap")) ) | End txtaps As far as I understand, the "-2", "-1",... "2" entries are parameter names which are followed by Usage, Type, Format, Default and Description. This corresponds to: |* (parameter_name (Usage <usage>) |* (Type <data_type>) |* (Format <data_format> <data>) |* (Default <value>) |* (Description <string>) |* ) Where is "parameter_structure" in this? Also, what is "txtap"? Is it a parameter name, or branch name, or what? (I am still struggling with understanding what branches and leafs really are)... Thanks, Arpad ============================================================ -----Original Message----- From: Bob Ross [mailto:bob@xxxxxxxxxxxxx] Sent: Thursday, October 21, 2010 10:17 AM To: Muranyi, Arpad Cc: IBIS-ATM; bob@xxxxxxxxxxxxx Subject: Re: [ibis-macro] Typos_Format_Value_Default_BIRD_4 discussion 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