0001481: Specify how tag value is handled in 4-state packed union

Notes
(0002736) Steven Sharp (developer) 2006-06-29 11:57	I don't care for the wording in the proposal. A mixed 2/4-state struct or union always uses 4-state format for the storage of the members. A 2-state tag in a 4-state union would presumably act just like a 2-state member in a 4-state struct. The wording in the proposal could be interpreted as saying otherwise. I assume that the intent of the proposal is actually to say that the tag would be stored in 4-state format but using only the 2-state value set, i.e. the 2-state tag would be converted to 4-state when being written into the 4-state storage for the tag field. Or another way of putting it is that the B-bits would be present for the tag field, but would always be zero. The statement in the proposal that the value would be stored entirely in the 2-state bits is presumably an attempt to say that the value would be stored entirely in the A-bits, leaving the B-bits zero. These things are awkward to say clearly, but it is very important to do so, since they are also easy to misunderstand.

(0002782) ralph_duncan (developer) 2006-07-14 13:39	Mr. Sharp is right. BTW the ultimate goal is to let item 1482 say where a DPI user finds a tag value on the C side for a packed, 4-state union. "If any data type within a packed structure is 4-state, the structure as a whole is treated as a 4-state vector. If there are also 2-state members in the structure, there is an implicit conversion from 4-state to 2-state when reading those members and from 2-state to 4-state when writing them." (2005 LRM, 4.11, para. 2 on p.33). a. The SV user can expect the simulator to perform "implicit conversion" when reading/writing any "2-state member" of a packed, 4-state union (as described above). The DPI user on the C side has no system agent doing this; DPI-C users get a sequence of bits and extract relevant bits for members and the tag value on their own. They must know where the tag will be. b. If the simulator treats the tag as it would a "2-state member," (reasonable for an ordinal value), then the DPI C user should be able to get the tag value from the a-bits. (This assumes user code hasn't hosed the tag value on the SystemVerilog side, e.g., via operations on the entire packed union). If the LRM explicitly states that the tag value is treated like a "2-state member" or that the relevant b-bits are zero for the packed, 4-state case, then DPI C users can know to get the tag value from the right a-bits. Otherwise, they have to guess whether the simulator used a-bits only or split the value between a-bits and b-bits to save space, etc. The wording of any changes is up to SV-BC but an explict statement on how the tag value is represented in the packed, 4-state case will be very helpful.

(0002816) Steven Sharp (developer) 2006-07-31 11:12	I also don't like the statement that the tag is "left-justified". The meaning of "left-justified" when describing text involves padding on the right to get the leftmost edge to a particular margin. This could be interpreted as padding with bits on the right to get the leftmost bit onto some boundary, such as a word boundary. I would suggest replacing the sentence - The tag bits are always left-justified (i.e., towards the MSBs) with the sentence - The tag bits occupy the most significant bits.

(0002820) ralph_duncan (developer) 2006-08-01 15:54	The language used to describe tag storage in packed unions should ultimately handle the case where the tag bits straddle word boundaries. Consider the case of a packed, tagged union where: . The largest member is 31 bits, e.g., 'bit [30:0] b' . There are 3 or more union members (tag requires > 1 bit). Reasonable expectations in this case include: . The tag value's least signifciant bit is stored in the most significant bit of the word allocated to hold the members' value, . The remaining tag value bits are stored in the least significant bits of an additional word, presumably allocated for the tag bits. It may be challenging to word 4.11 in a way that is both concise and that accurately describes all the possible situations.

Issue History
Date Modified	Username	Field	Change
2006-05-19 15:42	ralph_duncan	New Issue
2006-05-19 15:42	ralph_duncan	Type	=> Errata
2006-05-19 15:46	ralph_duncan	File Added: prop1481.htm
2006-05-19 16:20	Brad Pierce	Status	new => assigned
2006-05-19 16:20	Brad Pierce	Assigned To	=> ralph_duncan
2006-05-19 16:20	Brad Pierce	Priority	normal => immediate
2006-05-20 23:33	shalom	Issue Monitored: shalom
2006-05-22 10:04	ralph_duncan	Assigned To	ralph_duncan => doug_warmke
2006-06-29 11:57	Steven Sharp	Note Added: 0002736
2006-07-14 13:39	ralph_duncan	Note Added: 0002782
2006-07-31 11:12	Steven Sharp	Note Added: 0002816
2006-08-01 15:54	ralph_duncan	Note Added: 0002820
2006-09-21 23:31	mmaidment	Priority	immediate => normal

Relationships