Shalom is right that there is evidence the loophole was not
intentional:
7.2.1 Packed
structures
Only packed data types and the integer data types summarized in
Table 6-8 (see 6.11) shall be legal in
packed structures.
Table 6-8 does not include enum types.
but it is still left gaping open:
7.4.1 Packed Arrays
Packed arrays can be made of only the single bit data types (bit,
logic, reg), enumerated types, and
recursively other packed arrays and packed structures.
Recall that explicit casting is also permitted to create
non-enumerated values of an enum type.
These openings increase the risks of exploiting any information
added by the restriction of possible values.
I would argue that by using these "unsafe" constructs, the user has
accepted the risk that a
compiler will use a fact their usage no longer supports, but not
everyone agrees on this point.
Greg Jaxon
On 6/20/2012 8:01 AM, Bresticker, Shalom wrote:
Hi,
This
was previously noted in
http://www.eda-stds.org/sv-bc/hm/5169.html.
However,
it is not clear to me that according to a strict reading of
the LRM, an enum may be a member of a packed struct.
Regards,
Shalom
Hi,
As per LRM, an enum variable can only be
assigned to another enum variable of same type or enum
member. But if it is part of a packed struct, then the
restriction can be overridden. Please see the following
e.g.:
module top;
typedef enum bit [1:0] {X, Y, Z} et;
typedef struct packed {
et e;
} st;
et e;
st s;
initial begin
s = 4; // Passing
e = 4; // Failing
end
endmodule
Does LRM say anything about that? Should
it not be disallowed by some way?
Regards
Surya
This email and any attachments are intended for the sole
use of the named recipient(s) and contain(s) confidential
information that may be proprietary, privileged or
copyrighted under applicable law. If you are not the
intended recipient, do not read, copy, or forward this
email message or any attachments. Delete this email
message and any attachments immediately.
---------------------------------------------------------------------
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.
Received on Wed Jun 20 12:18:08 2012