RE: [sv-bc] packed struct with 2 and 4 val fields

I looked through the LRM and didn't find any rule saying there was a 4-state to 2-state coercion on writes to 2-state variables either. All I found was a statement about how automatic conversions from 4-state to 2-state are done (X/Z become zero). And elsewhere was a statement that all integral types are assignment compatible. From these we can infer that there must be such a coercion on assignment to objects of 2-state type, even though I didn't see any explicit rule. So the lack of an explicit statement in 7.2.1 doesn't mean that there isn't a 4-state to 2-state coercion on write (followed by the special coercion in 7.2.1 back to 4-state).

So the coercion occurs on the assignment, not on the RHS, and doesn't involve any context-determination rules. It isn't some special rule, just the normal coercion that we infer must occur when assigning to an object with a 2-state type. It isn't due to context-determination, but occurs as part of the assignment, like truncation of wide vectors assigned to a narrower LHS, or assignment of a real to an integer.

It may seem odd that there are two consecutive coercions on write, but the second one isn't really a coercion. The coercion back to 4-state does not conceptually change the value. It just involves a change in the representation of that same value, to the representation used by 4-state, to give reasonable values if the entire struct is read back. If the 2-state value were written using the 2-state representation, then reading back the entire struct could give garbage back, depending on exactly what representations the implementation used.

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Greg Jaxon
Sent: Tuesday, April 26, 2011 2:23 PM
To: sv-bc@eda.org
Cc: Bresticker, Shalom; Daniel Mlynek
Subject: Re: [sv-bc] packed struct with 2 and 4 val fields

As written, the 7.2.1 rule cited below does not mention 4-state to 2-state coercion on write.
Any coercion 4->2 would have to occur on the RHS of the assignment (pattern). So the question
becomes whether there is any other requirement to impose the LHS type on the RHS result (or expression).
The sole precedents here are the context-determination rules, and in the case of expression
bit width, the rule is that the RHS width can indeed be increased (but not decreased) when the
LHS type has more bits than would a self-determined RHS type. Note that this precedent does
not directly apply to state-size, only bit width. Still it suggests that not doing a 4->2 coercion
would be OK. It also challenges us to define whether 4-state contexts determine the state-resolution
of a RHS expression! I shudder at the conceptual damage already done by context determination
and only wish that its original authors be punished by the fullest possible consequences of
adopting their anti-algebraic policies.

Greg Jaxon

On 4/26/2011 7:42 AM, Bresticker, Shalom wrote:

Hi,

The LRM says in 7.2.1,

"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."

I agree this is not clear enough.

I believe the meaning is this:

The entire structure, i.e., all its members, become 4-state. The LRM says, "A packed structure can be used as a whole with arithmetic and logical operators."

When you read a 2-state member, like s.b, you expect to get a 2-state entity. However, internally it is 4-state. So, when the read operation is performed, a conversion is performed from 4-state to 2-state. However, internally it remains 4-state.

Less clear is the write operation. When you write a 2-state member, the value will get converted to 4-state internally, because it is being stored internally as 4-state.

I think the question is what happens when you write

s.b = 'x;

Does the 'x get written internally without change, or is 'x converted to a 2-state '0 since you are writing a 2-state variable, and then the 2-state '0 get converted to a 4-state '0?

I ran this test on 2 different simulators and indeed got different results.

One gave xxxxxxxx and another gave xxxx0000.

However, even the tool that returned xxxx0000 gave xxxxxxxx if the assignment was s = 'x.

Regards,

Shalom

-----Original Message-----

From: owner-sv-bc@eda.org<mailto:owner-sv-bc@eda.org> [mailto:owner-sv-bc@eda.org] On Behalf Of

Daniel Mlynek

Sent: Tuesday, April 26, 2011 1:57 PM

To: sv-bc@eda.org<mailto:sv-bc@eda.org>

Subject: [sv-bc] packed struct with 2 and 4 val fields

struct packed {reg[1:0][1:0] r; bit [1:0][1:0]b;} s;

module top;

     initial begin

         s.b='x;

         $display("%b", s); //should print all x or xxxx0000???

     end

endmodule

In above example s is 4 value as stated in LRM

My question is what should be written into s.b when it is assigned with

'x.

LRM says that when writing to a 2-val field then implicit 2val to 4

val

cast occurs.

But in this case I'm writing 4 value value into 2 val field.

In my opinion this LRM statement about 2val to 4val implicit cast is

not

clear.

DANiel

---------------------------------------------------------------------

Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for

the sole use of the intended recipient(s). Any review or distribution

by others is strictly prohibited. If you are not the intended

recipient, please contact the sender and delete all copies.

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.