Re: [sv-bc] RE: [sv-ec] restriction on typedef on net.

From: Steven Sharp <sharp_at_.....>
Date: Wed Jan 16 2008 - 15:09:17 PST
>From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
>danielm

>LRM defines integral type as:
>"The term integral is used throughout this standard to refer to the data
>types that can represent a single basic
>integer data type, packed array, packed struct, packed union, enum, or
>time."
>
>In restriction for net types LRM uses that term:
>"Certain restrictions apply to the data type of a net. A valid data type
>for a net shall be one of the following:
>a) A 4-state integral type, including a packed array or packed struct
>b) An unpacked array or unpacked struct, where each element has a valid
>data type for a net"
>
>Reading both above it is unclear to me which types are allowed as net
>type  - why only packed array and packed struct are explicitly included
>while they are in integral type definition same as union and enums.

The fact that they are explicitly included does not change the meaning
of the sentence.  It says that integral types include packed arrays and
packed structs, which is true.  That does not cause any other integral
type to be excluded.

Presumably, the reason they are explicitly included is that they are more
complex than the other integral types, and the reader is more likely to
forget that they are integral types.  Also, it provides symmetry with the
following statement about unpacked arrays or unpacked structs.  Without
it, the reader might be puzzled why unpacked arrays and structs are
mentioned, but packed ones are not.

So while the phrase is not necessary, it does no actual harm.  It may
clarify things for many readers, at the small cost of confusing a few
others such as yourself.

> what
>about packed  union and enum.
>Is packed union allowed or not: 
>
>wire union packed {integer i, reg[31:0] r} wire_union;

It is an integral type, so yes.

Steven Sharp
sharp@cadence.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Wed Jan 16 15:10:03 2008

This archive was generated by hypermail 2.1.8 : Wed Jan 16 2008 - 15:10:21 PST