RE: [sv-bc] Packed arrays of bytes -- are they legal?

See Mantis 1570.

Shalom 

> >> An argument in favor of that viewpoint is 6.9
> >>
> >>    "SystemVerilog does not require a category for 
> identical types to 
> >> be defined here because there is no construct in the SystemVerilog 
> >> language that requires it. For example, as defined below, 
> int can be 
> >> interchanged with bit signed [31:0] wherever it is 
> syntactically legal to do so.
> >> Users can define their own level of type identity by using the 
> >> $typename system function (see 22.2) or through use of the PLI."
> > 
> > This text is erroneous, or at least misleading, if it is 
> interpreted 
> > as meaning that these two types behave identically.  For one thing, 
> > these two types behave differently when passed to DPI.  I 
> think this 
> > statement must be discounted.
> 
> Appendix F.6.4 describes DPI type matching as making the 
> distinction you expect.
> > The input mode arguments of type byte unsigned and shortint 
> unsigned 
> > are not equivalent to bit[7:0] or bit[15:0], respectively, 
> because the 
> > former are passed as C types unsigned char and unsigned 
> short and the 
> > latter are both passed by reference as svBitVecVal types. A similar 
> > lack of equivalence applies to passing such parameters by 
> reference for output and inout modes, e.g., byte unsigned is 
> passed as C type unsigned char* while bit[7:0] is passed by 
> reference as svBitVecVal.
> 
> Since integer and my_integer types "match", will there be any 
> DPI difficulty when an integer variable passes via a function 
> or interface port to a my_integer variable?  Perhaps these 
> types should /not/ match?  They can continue to be
> "equivalent": a matter which always admits some small 
> coercion of bounds values or bit width.
> 
> If a semantic property of keyword integral types is being 
> specified, I'd prefer to see a type-query capable of 
> distinguishing the new types, so that strict binding rules 
> can enforce identical DPI compatibility of the data.
---------------------------------------------------------------------
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, and is
believed to be clean.