[ibis-editorial] Re: Typ value confusion...

  • From: "Bob Ross" <bob@xxxxxxxxxxxxx>
  • To: <ibis-editorial@xxxxxxxxxxxxx>
  • Date: Mon, 5 Mar 2012 11:32:40 -0800

Arpad:

 

The statement 

 

"As far as I understand, we never had the second example

on our mind."

 

may be partially true.  We clearly had the first entry as the typ value, but

we never stated one way or the other whether it also had to be one of

the value entries.  The third choice would have been my interpretation::

 

(List 5 1 2 3 4 6 7 8 9)

      \----------------/

       this entire thing

       being the "list" with 5 as default and

       5 not included in the 1 ... 9 sequence.

 

The official V5.0 rules are.

 

|   Format: (default is range)

|     Value     <value> Single value data

|     Range     <typ value> <min value> <max value>

|     List      <typ value> <value> <value> <value> ... <value>

|     Corner    <typ value> <slow value> <fast value>

|     Increment <typ> <min> <max> <delta>

|               After expansion, the allowed values of the parameter are

|               typ+N*delta where N is any positive or negative integer

|               value such that:  min <= typ + N*delta <= max

|     Steps             <typ> <min> <max> <# steps>

|               Treat exactly like Increment with 

|               <delta> == (<max>-<min>)/<# steps>

 

 

Consistent throughout IBIS, a "typ" value is always specified.

 

Because we never stated any rules, my recommendation is to support all

cases and let the tool work out what to use and how to process the List.

There is no stated or implied processing order.  There is no harm if
duplicates

are shown or removed, or if the list is re-ordered by the EDA interface.

We are supporting both batch processing or user selection.

 

However, we can suggest, but not require - typical value first, and 0 or
more

remaining values follow.

 

Bob

 

 

 

 

From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, March 05, 2012 10:00 AM
To: ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] Re: Typ value confusion...

 

Bob,

 

Mike was asking the question whether a list looks like this:

 

(List 1 2 3 4 5 6 7 8 9)

      \----------------/

       this entire thing

       being the "list"

 

 

or:

 

(List 5   1 2 3 4 5 6 7 8 9)

      |   \----------------/

      |    this thing being

      |      the "list"

      |

      \ this being a value repeated from the list

        to indicate which value in the list is to

        be considered as the typical value

 

As far as I understand, we never had the second example

on our mind.  It is just an unfortunate misnomer to call

the first value in the list "typical", because the word

can have a misleading interpretation as shown in the 2nd

example.

 

Thanks,

 

Arpad

=========================================================

 

 

 

From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
Sent: Friday, March 02, 2012 9:12 PM
To: ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] Re: Typ value confusion...

 

Arpad:

 

(I was mostly focused on the optional Default and not focused

too closely on the duplicate entries  or giving the full list after <typ>

But Typ is part of the required syntax in case no selection is made.)

 

There are no rules to the contrary that exclude any of the

cases nor exclude repeated entries nor a requirement of

more than one entry (though at least two entries could be implied

if an element beyond <typ> is required, whether or not it is the

same as <typ>.

 

All the EDA tool has to do is use the <typ>  if no choice is

made (or Default is not given) and make available at least once

all of the distinct choices.   For List, the Default must be one

of the selections.

 

There is no problem if the choices are repeated or if duplicates

are screened out, if sorted or if ordered exactly as in the (List ..)

parameter, or if there is only one entry or choice.

 

-----

 

However, this is a good point.  If we need rules, we

then should write a BIRD that at least states a style recommendation.

But we need to cover all Types (integers, float, string, UI(float),
Tap(float)

and Boolean cases etc.  If we introduce specific requirements, then we

have several more rules and cases to check.

 

As long as all choices are available (whether provided once or with

duplicates) or in any order, there should not be any problem.

This is a tool processing issue.  So that is why I consider all choices

below legal.

 

Bob

 

 

 

From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Friday, March 02, 2012 4:37 PM
To: ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] Re: Typ value confusion...

 

Bob,

 

"All cases 4 below are correct for List. "

How could they be?

 

Arpad

===============================

 

From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
Sent: Friday, March 02, 2012 6:09 PM
To: ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] Re: Typ value confusion...

 

Michael:

 

Good questions and many more should follow.

 

So, I would hold off starting to write explanations until we

have the organization nailed down.  Your general question also

applies to Corner, Range, Increment, Step and maybe something

else.  There are different rules and limits for Default values for each

case as to what a member of the class may mean and the limits.

 

All cases 4 below are correct for List.  For List repeats are required,

so a new "unlisted value" (Default E) would be flagged as an error.

 

Bob

 

From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Friday, March 02, 2012 4:01 PM
To: ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] Re: Typ value confusion...

 

We can discuss that in the next editorial meeting.

 

Thanks,

 

Arpad

====================================================

 

From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Mirmak, Michael
Sent: Friday, March 02, 2012 5:48 PM
To: ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] Re: Typ value confusion...

 

Arpad,

 

Thanks.  If this is the consensus answer, we'll need to add some explanatory
text plus edit out the <typ value> mention in the List syntax definition.
The new text would state exactly what you did: if Default is not present for
a List, the first item in the list is assumed the Default value.

 

-          MM

 

From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Friday, March 02, 2012 3:45 PM
To: ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] Re: Typ value confusion...

 

Mike,

 

The list is just a list of A, B, C, D, where "A" is the first

item in the list.

 

If Default is not defined, the first item will be used from the

list.  I don't know why the name "typ" was given to this first

item, but that is just a bad naming convention (probably coming

from the Range, or Increment types).

 

Does this answer your question?

 

Thanks,

 

Arpad

================================================================

 

From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Mirmak, Michael
Sent: Friday, March 02, 2012 5:37 PM
To: ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] Typ value confusion...

 

(this may require cross-posting to ibis-macro)

 

In reviewing Section 10A in the draft 5.1 document, I have a question about
the "typ value" of a Model Specific parameter: for List, etc., must one list
a *duplicate* value for the typ value?  In other words, are repeats
required?

 

This should not be affected by the presence of "Default" (though "Default"
makes it confusing).  

 

Here's an example in four variations.  Which is correct?  My own vote is for
(1) and (4) being correct.  However, we only say that the Default value has
to be a member of the list, *not* that the typ value has to be a member of
the list!  ("Also, if Default is specified, <value> must be a member of the
set of allowed values of the parameter. If Default is not specified, the
default value of the parameters will be the <typ> value.")

 

1)

 

    (Informative_String (Usage In)(List B A B C D)(Type String)(Default B)

      (Description "This is an example with a repeated item, because the
first in the list should be the Typ Value"))

 

2) 

 

    (Informative_String (Usage In)(List A B C D)(Type String)(Default B)

      (Description "This is an example without a repeated item, because the
first in the list shouldn't have to be the Typ Value, as I have a Default
declared; but I risk declaring a typ that isn't actually in my list, if the
typ is A and the list consists only of B, C and D"))

 

3)

 

    (Informative_String (Usage In)(List A B C D)(Type String)

      (Description "This is an example without a repeated item, and without
a Default, I risk declaring a typ that isn't actually in my list, if the typ
is A and the list consists only of B, C and D"))

 

4)

 

    (Informative_String (Usage In)(List B A B C D)(Type String)

      (Description "This is an example with a repeated item, and without a
Default; this technically matches the spirit and letter of the 5.1 law"))

 

-          MM

Other related posts: