[ibis-macro] Re: Typos_Format_Value_Default_BIRD_4 discussion

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Fri, 22 Oct 2010 10:50:28 -0700

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

 

Other related posts: