Re: [sv-bc] part selects on arbitrary expressions

From: Brad Pierce <Brad.Pierce_at_.....>
Date: Sun Mar 11 2007 - 22:50:32 PDT
> So? My question was about arrays of bits.

The only question in your e-mail was 

> By the way, is matching transitive?

Yes, it is.

And if

   bit signed [31:0] x;
   bit signed [31:0] y;

then the types of x and y match. 

When a type is created, all of the array types over it are created.
Because 'bit' is a pre-existing type, so is 'bit signed [31:0]'.

Uses of array types do not create those types, so the lines on which an
array type is used or the instance in which it is used is never relevant
for matching, because matching of array types depends only on the
number/packedness/range/signedness of dimensions and on the matching of
their underlying types.

If
 
    bit x, y;
    bit z;
 
    var type(x) ax[100];
    var type(y) ay[100];
    var type(z) az[100];
 
then
  
     1)  x and y and z have matching types
  
     2)  ax and ay and az have matching types

-- Brad
    
-----Original Message-----
From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] 
Sent: Sunday, March 11, 2007 8:24 PM
To: Brad Pierce; sv-bc@eda-stds.org
Subject: RE: [sv-bc] part selects on arbitrary expressions

So? My question was about arrays of bits.

Shalom

> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
> On Behalf Of Brad Pierce
> Sent: Sunday, March 11, 2007 10:22 PM
> To: sv-bc@server.eda-stds.org
> Subject: RE: [sv-bc] part selects on arbitrary expressions
> 
> Shalom,
> 
> A struct type is created by a 'struct' construct in some particular 
> user instance.
> 
> When the struct type is created, all of the array types over that 
> struct type are also brought into existence.
> 
> For example, if
> 
>    struct {logic field;} x, y;
>    struct {logic field;} z;
> 
>    var type(x) ax[100];
>    var type(y) ay[100];
>    var type(z) az[100];
> 
> then
> 
>    1)  x and y have matching types
> 
>    2)  The types of x and z don't match, and are not even 
> interassignable.
> 
>    3)  ax and ay have matching types
> 
>    4)  The types of ax and az don't match and are not even 
> interassignable.
> 
> The type shared by ax and ay was already brought into existence by the

> 'struct' construct which created the type used by the variable 
> declarations of x and y.
> 
> -- Brad
> 
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of 
> Bresticker, Shalom
> Sent: Sunday, March 11, 2007 7:43 AM
> To: Gordon Vreugdenhil
> Cc: sv-bc@eda-stds.org
> Subject: RE: [sv-bc] part selects on arbitrary expressions
> 
> This is actually not clear to me.
> 
> > No it hasn't been specified.  You'll likely be unhappy about what
> > "type(...) == type(...)" means in any case.
> >
> > 6.10 says:
> >    Two type references shall be considered equal in such comparisons
> >    if, and only if, the types to which they refer match (see 6.9.1).
> >
> > 6.9.1 boils down to saying that a packed vector can match a
> predefined
> 
> > but it is NEVER the case that two "anonymous"
> > packed vectors will match.  So, for a packed item "bit [1:0] a",
> even
> > the trivial condition
> >     type(a[1:0]) == type(a[1:0])
> > will be false.
> >
> > Such types are equivalent but not matching.
> 
> [SB] 6.9 says,
> "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."
> 
> Well, if 'int' can be interchanged with 'bit signed [31:0]', and two 
> int's match, then so should two 'bit signed [31:0]'s.
> 
> It also says,
> "To have type matching or equivalence among multiple instances of the 
> same module, interface, or program, a class, enum, unpacked structure,

> or unpacked union type must be declared at a higher level in the 
> compilation-unit scope than the declaration of the module, interface, 
> or program, or imported from a package. For type matching, this is 
> true even for packed structure and packed union types."
> 
> The last sentence, by specifying structures and unions, implies that 
> the statement is not true for packed arrays.
> 
> Even using the same paragraph from 6.9.1, the example, "typedef bit 
> signed [7:0] BYTE; // matches the byte type", I would certainly expect

> two 'bit signed [7:0]'s to be as least as close as one of them and a 
> 'byte'. If each of them matches a byte, which is less identical, then 
> I would certainly expect them to match each other, which are more 
> identical to each other.
> 
> By the way, is matching transitive?
> 
> Shalom
> 
> --
> This message has been scanned for viruses and dangerous content by 
> MailScanner, and is believed to be clean.
> 
> 
> 
> --
> This message has been scanned for viruses and dangerous content by 
> MailScanner, and is believed to be clean.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Sun Mar 11 22:50:53 2007

This archive was generated by hypermail 2.1.8 : Sun Mar 11 2007 - 22:51:04 PDT