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, KrishanuReceived 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