[ibis-macro] Re: I would like to un-table BIRD 154, and request that there be a vote on BIRD 154 at the next Open Forum meeting.
- From: "Bob Ross" <bob@xxxxxxxxxxxxx>
- To: <wkatz@xxxxxxxxxx>
- Date: Mon, 20 May 2013 11:34:24 -0700
Walter:
The proposal is a syntactical variation and must be handled carefully.
I am not confused about the intent below, but these are not the
words in BIRD154. Also, some rules within BIRD 154 need to be
discussed. Entries within a List could be repeated, but Labels
should optionally be different, e.g,,
(List 1 2 3 2 1)
(Labels "a" "b" "c" "d" "e")
If you want to enter a sequence of values in conjunction
with another sequence of values.
I still maintain that BIRD154 needs more. The statement that
Labels is an optional leaf WITHIN List is wrong.
Bob
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Monday, May 20, 2013 11:13 AM
To: 'Bob Ross'
Cc: 'IBIS-ATM'
Subject: [ibis-macro] Re: I would like to un-table BIRD 154, and request
that there be a vote on BIRD 154 at the next Open Forum meeting.
Bob,
(My_Parameter
(List 1 2 3)
(Labels "a" "b" "c")
In my example (I changes the name of the parameter to My_Parameter to avoid
confusion), My_Parameter is a List parameter (i.e. it is a parameter whose
format is List - as opposed to Corner parameter or Value parameter or Range
parameter, or String parameter, . I think "List parameter" is a clear
definition, but if you want it to say a Parameter that has Format List, I
could make that change - but really?
It is your opinion that BIRD 154 needs more work before it is approved. You
are but one vote.
Walter
From: Bob Ross [mailto:bob@xxxxxxxxxxxxx]
Sent: Monday, May 20, 2013 2:04 PM
To: 'Walter Katz'
Cc: 'IBIS-ATM'
Subject: RE: [ibis-macro] I would like to un-table BIRD 154, and request
that there be a vote on BIRD 154 at the next Open Forum meeting.
Walter:
BIRD154 states "Labels is an optional Leaf within List parameters .".
Yes, Labels can be a Leaf of the Parameter. So are {Format} <data_format>,
Type, Default, Usage, and Description. If Labels is added then Labels
needs to be added to the list of rules on page 175 and documented
that it requires {Format} List. However, using an existing
word in two different manners is confusing, so I suggest a name
change.
You are correct that others need to decide if they really want/need
this feature. If so, then BIRD154 needs more work before its approval.
Bob
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Monday, May 20, 2013 10:34 AM
To: 'Bob Ross'
Cc: 'IBIS-ATM'
Subject: RE: [ibis-macro] I would like to un-table BIRD 154, and request
that there be a vote on BIRD 154 at the next Open Forum meeting.
Bob,
You need to draw the picture correctly:
(Parameter
(List 1 2 3)
(Labels "a" "b" "c")
Both node List and node Labels are Leaves of the node Parameter
There are many users that very much want and appreciate the fact that there
is a standard way of naming entries in a List parameter. I think it would be
useful that there be a standard way of doing this. SiSoft has non-standard
ways of doing this and would like to standardize it for the benefit of all
EDA vendors, IC Vendors and Users. If IBIS chooses not to define such a
standard so be it, but this is not being responsive to the user community.
Walter
From: Bob Ross [mailto:bob@xxxxxxxxxxxxx]
Sent: Monday, May 20, 2013 1:07 PM
To: wkatz@xxxxxxxxxx
Cc: 'IBIS-ATM'
Subject: RE: [ibis-macro] I would like to un-table BIRD 154, and request
that there be a vote on BIRD 154 at the next Open Forum meeting.
All:
I have concerns about BIRD154 as written. While we can vote on it,
I do not recall it being fully discussed at the ATM meeting. BIRD154
is not ready for approval for a number of reasons.
1. Labels, as documented, is not a Leaf, but a co-dependent Format
word with List. This is totally inconsistent with the usage of Labels
for Table.
If it were a Leaf, then the format would be
(List (Labels "a" "b" "c") 1 2 3),
not
(List 1 2 3) (Labels "a" "b" "c")
So the format needs to be changed or the word Labels needs
to be changed to something like (List_Labels)
2. The added rules about the content of Labels are inconsistent
with the rules for Labels under Table (a point of confusion):
Labels, as documented, places extra burden on the parser
to (a) check for unique List entries and unique Labels for all
Types (Float, String, Boolean), (b) if List entries are the same
then the Labels must be the same. I can think of exceptions (b).
Furthermore not allowing a Null Label "" is inconsistent with the
the rule in Table. Also, the handling of Default is not mentioned
(illegal for Table, but legal for List)
3. The bottom line is that while Labels in Lists might be handy in
a few tools, Labels in Lists is an optional, but not necessary
feature that will cause extra documentation and parser
work for little general benefit. Since Labels are optional, all
tools must still be able to work without Labels. Also the BIRD154
needs more work before its approved.
Bob
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Sunday, May 19, 2013 5:42 PM
To: Michael Mirmak
Cc: IBIS-ATM
Subject: [ibis-macro] I would like to un-table BIRD 154, and request that
there be a vote on BIRD 154 at the next Open Forum meeting.
MM,
I would like to un-table BIRD 154, and request that there be a vote on BIRD
154 at the next Open Forum meeting. I would very much like this in IBIS 6.0.
It allows the Leaf (Labels in (List parameters, thus assigning intelligent
text to coded values in list parameters. It is simple used for "Tool Tips"
or equivalent information to the user about the various value of List
parameters. It is optional and has no effect on flows. It in fact worked
with the IBIS 5.0 parser. The IBIS 5.1 parser complains about this. So the
only effect on IBIS 6.0 would be to relax the rule that is currently being
enforced.
Walter
Walter Katz
wkatz@xxxxxxxxxx
Phone 303.449-2308
Mobile 303.335-6156
Other related posts:
