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

thank you for all the answers

DANiel

On 4/27/2011 2:01 AM, Steven Sharp wrote:
>
> 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.