Re: [sv-bc] Tagged packed union

Krishanu,

      Your suggestion 1 changes tagged union semantics in a way
which introduces the problem you discuss in question 2.

      Unions are being tagged as "type-checking" aid, not as
a way to avoid using the correct field access name when you
want to read the last stored value.

     "Members of tagged unions can be read or assigned using
      the usual dot notation."

      I have two editorial quibbles on this topic.  LRM says
that the tag does "type checking", but then describes a tag
scheme that indexes all the declared fields.  I'm left unsure
about whether my read access MUST use the same field name
as the write access that created the value, or merely one
whose type is "consistent".  The word consistent is not one
of the special terms used in 6.9 Type Compatibility.

     "The member value can only be read with a type that is consistent
      with the current tag value (i.e., member name).
      Thus, it is impossible to store a value of one type and
      (mis)interpret the bits as another type."

I don't know what it means to read "with a type".

Later in 8.14 tagged union expressions pick up an uncanny
similarity to RHS assignment patterns:

    "The type of a tagged union expression must be known from
     its context (e.g., it is used in the right-hand side of an
     assignment to a variable whose type is known, or it is has
     a cast, or it is used inside another expression from
     which its type is known)."

I think the term we have for this is "assignment-like context"
and it covers a few other settings where type can be inferred.

Greg Jaxon

Krishanu Debnath wrote:
> Hello,
> 
> I have two issues to discuss here about tagged packed union.
> 
> 1) SV LRM Sec 4.11(page 35) says ...
> 
> <lrm>
> When the packed qualifier is used on a tagged union, all the members 
> must have
> packed types, but they do not have to be of the same size. The (standard)
> representation for a packed tagged union is the following:
> 
> — The size is always equal to the number of bits needed to represent the 
> tag
>   plus the maximum of the sizes of the members.(Clause 1)
> 
> — The size of the tag is the minimum number of bits needed to code for 
> all the
>   member names (e.g., 5 to 8 members would need 3 tag bits).(Clause 2)
> 
> — The tag bits are always left-justified (i.e., towards the 
> MSBs).(Clause 3)
> 
> — For each member, the member bits are always right-justified [i.e., 
> towards the
>   least significant bits (LSBs)].(Clause 4)
> 
> — The bits between the tag bits and the member bits are undefined. In the
>   extreme case of a void member, only the tag is significant and all the
>   remaining bits are undefined.(Clause 5)
> 
> The representation scheme is applied recursively to any nested tagged 
> unions.
> </lrm>
> 
> Tagged union is introduced for better type-checking, to avoid type 
> loop-hole
> problem that other language like c/c++ has. Clause 1 includes tagged bit
> encoding part into the value part of a packed union object when used as 
> a bit-vector type. And this *breaks* type-safe tagged union concept. 
> Consider this:
> 
> module sample;
>     union tagged packed {
>         reg [3:0] first;
>         reg [3:0] second;
>     } u;
>     reg [4:0] value;
> 
>     initial
>     begin
>         u = tagged first(10);
>         u = 5'b11111;
>         value = u.second;
>         $display("value of value %b\n", value);
>     end
> endmodule
> 
> Above is completely *legal* code. :-)
> 
> I would suggest to keep tag encoding bit parts out from union value 
> part. In
> other words, tag encoding bits will not contribute to size and value 
> part of
> tagged packed union. Tag encoding will be implementation defined and not 
> visible
> to user. (Note Clause 5 makes padding between tag bits and member bits 
> implementation defined, but it talks about representation, and it does not
> contribute to value part). BTW once tag encoding is implementation 
> defined, Clause 2 does not apply anymore.
> 
> 
> 2) Note my contrived choosing of equal size union members. Tagged qualified
> packed union can have members of different sizes(Clause 1). Now my 
> question is
> what will be the semantics If tagged member is not the largest member in 
> the
> union and you are trying to read that union as a bit-vector type. 
> Consider this:
> 
>     union tagged packed {
>         reg [3:0] first;
>         reg [7:0] second;
>     } u;
>     reg [8:0] value;
> 
>     u = tagged first(10);
>     value = u;
> 
> Probably this is simple. First, tagged member will be read, then it will be
> extended to sizeof(u) depending on the sign of member 'first'. Well, 
> Does LRM
> talk about the semantic of the following line?
> 
> u = 9'b111111111;
>      or
> u[8:0] = 9'b111111111;
> 
> Let me know what others think about this Or If this has been discussed 
> before
> a pointer to the database.
> 
> Thanks,
> Krishanu