[sv-bc] Tagged packed union

From: Krishanu Debnath <krishanu_at_.....>
Date: Wed Mar 01 2006 - 05:48:18 PST
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
Received on Wed Mar 1 05:47:13 2006

This archive was generated by hypermail 2.1.8 : Wed Mar 01 2006 - 05:47:40 PST