Re: [sv-bc] Proposal for 216

I have the following comments and questions concerning errata 216

1. Using an enumerated variable that has been assigned an out of range value

   The proposal for errata 216 contains the following change.

      In 3.10.3, DELETE

       "The result of any operation on an enumeration variable after the
        variable has been assigned an out of range value shall be undefined."

   You are proposing to modify the enum built-in methods to clearly specify
   their semantics when they get called in this situation.

   I don't see anything in your proposal that mentions what happens when one
   of these enumerated variables is used in an expression. In your email you
   were suggesting that they reflect the last assigned value, regardless of
   whether the last assigned value was in-range or not. If this is the intent
   of your proposal I suggest that it be explicitly stated. Having a defined
   behavior is probably better than having it completely undefined.

   Another objection to the statement you want to delete is the following.
   As it is written, I am unable to use an enumerated variable once it has
   been assigned an out of range value. Instead it should be possible to
   reclaim this variable by explicitly assigning it a valid value for this
   enumerated variable. If this statement is retained it will need to
   be clarified for this case.

   There is a statement in the LRM that mentions the legality of using
   an explicit cast to assign an otherwise illegal value to an enumerated
   variable. I wasn't involved in the creation of this portion of the LRM
   but I suspect that it was added in order to allow users to get around the
   type checking in those cases where it is "convenient" to do so. Those
   users that want the strong type checking capability would simply not
   allow such casts to occur in their code.

   To sum up, I agree with your email suggestion of having en enumerated
   variable reflect the last value it was set to, regardless of whther it
   is a legal value or not. Your proposal for errata 216 should be updated to
   state this intention.

2. Allowing an "illegal" initial value

   A 4-state enumerated variable can be defined such that the all-x state is
   not specified as a legal value.

      enum integer {Red,Green,Yellow} streetlight; // defaults to values {0,1,2}

   The intent of the proposal for errata 216 is to initialize all 4-state
   enumerated variables to the all-x state. The reasoning for this is to
   make it harder for designers to unwittingly design their hardware such
   that it works in a simulator but fails when turned into actual devices.
   This is a worthy objective.

   It would be useful in the testbench world to be able to avoid
   initializing 4-state enumerated types to the x-state. One way to
   accomplish this would be to slightly refine the definition of the
   semantics for variable declaration assignments for enumerated variables.

      enum integer {Red,Green,Yellow} streetlight=Red; // initialize to Red

   The description in 1364 3.2.2 for variable intialization is a bit
   inconsistent. For real and realtime it mentions a "default" initialization,
   but for reg, time and integer it leaves out the word "default".

      "The initialization value for reg, time and integer data types shall
      be the unknown value, x. The default initialization value for real
      and realtime variable data types shall be 0.0."

   Section 3.2.2 then goes on to say

      "If a variable declaration assignment is used, the variable shall take
      this value as if the assignment occurred in a blocking assignment in
      an initial construct."

   Based on this, it appears that a variable will first take on the default
   initial value and then be followed by an assignment to the value specified
   in the variable declaration assignment (when one is specified).

   Defining the "default initial value" for an enumerated type to be the
   value specified in the enum variable declaration assignment would be
   sufficient to prevent an enumerated variable from being arbitarily
   initialized to an illegal value. When there is no variable declaration
   assignment the defined default value would be used for initialization. When
   there is a variable declaration assignment the value specified in this
   assignment would become the initial value. I believe that this allows
   people to get stronger type checking when they desire it while still
   allowing designers to get 4-state x initialization without having to
   remember to do any extra work.

3. 2-state versus 4-state enum variable initialization

   I would like to see consistent rules apply to both.

4. Iterating

   The proposal for errata 216 could cause a value to be assigned to an
   enumerated variable that was not specified in the list of valid values
   for the enum.

   How do the built-in methods treat the default initial value if it is
   not one of the values specified in the enum list?

   Do they simply ignore it when iterating through the list of valid values?
   What label would be assigned to it if they are part of the iteration list?

   Right now it appears that we are unable to iterate through the list of
   enumerated values for an enumerated variable that is set to an out of
   range value, which could inlcude the default initial value.

   Given the current proposal it appears that the example of section 3.10.4.7
   produces an infinite loop.

      typedef enum {red,green,blue,yellow} Colors;
      Colors c = c.first;
      forever begin
         $display("%s: %d\n", c.name,c);
         if (c==c.last) break;
         c=c.next; // <-- may sit at the default value
      end

   I would think that it would be useful to be able to explicitly check
   for the initial value. This would allow a user to differentiate between
   an enum variable that is set to the default initial value versus an enum
   variable that is at an out of range value. Do we need to specify a
   value at the end of the enumeration list of values that expicitly
   specifies the initialization value to do this? (e.g. 'x for a 4-state enum)

At a minimum I believe that more discussion is required on this errata.

Neil

Steven Sharp wrote:
> I have uploaded a proposal for 216, about default initial values for enums.
> Because of Mark's comments, the proposal contains two variations: one that
> just changes 4-state enums, and the other that changes all enums.
>
> Steven Sharp
> sharp@cadence.com
>

-- 
---------------------------------------------------------------------
Neil Korpusik                                     Tel: 408-720-4852
Member of Technical Staff                         Fax: 408-720-4850
Frontend Technologies - ASICs & Processors (FTAP)
Sun Microsystems
email: neil.korpusik@sun.com
---------------------------------------------------------------------