Subject: RE: [sv-bc] Re: Separate Compilation
From: Maidment, Matthew R (matthew.r.maidment@intel.com)
Date: Thu May 08 2003 - 11:30:08 PDT
That's not _exactly_ what I asked for.
What I asked for was that variables and nets of the same shape
be assignment compatible. This limits the types to arrays of
built-in integer types. Since Verilog already allows bits/vectors
of variables to be assigned to nets then it seems natural to
extend this to matching shapes of variables and wires. It
saves me the tedium of iterating through the shapes to form
assignments of bits/vectors.
Since nets cannot be structs, enums or unions, I did not request
that two structs of the same shape but different typedefs are
the type-compatible. It seems expensive to check the assignment
compatibility of two or more unpacked, arbitrarily-defined types
of structs or unions. Yes, that's inconsistent, but it doesn't
bother me.
As for Karen's type compatibility example, I believe those to be
type compatible since they are both integer types. To me those
need to be type compatible just like these need to be type compatible:
typedef logic [3:0] foo;
typedef logic [3:0] bar;
foo a;
bar b;
a = b;
Matt
> -----Original Message-----
> From: Jay Lawrence [mailto:lawrence@cadence.com]
> Sent: Thursday, May 08, 2003 10:43 AM
> To: Karen Pieper; Kevin Cameron x3251; sv-bc
> Subject: RE: [sv-bc] Re: Separate Compilation
>
>
>
> The question here is what is the meaning of "different type".
>
> As long as 2 types are the same "shape" (topology) they are still
> assignment compatible and can be associated on ports, task arguments,
> etc. So who cares if they are declared in a different place and are
> called different types, they are completely interchangeable.
>
> Now if we are talking strong typing, then the 2 different typedefs
below
> would be different types and not be assignment compatible, this is
> certainly not the intent in SystemVerilog.
>
> I think the only place where there is still confusion on this is in
the
> area of enum's and whether they are strongly typed, the LRM is
> self-contradictory and allows casting to enums. All other packed and
> unpacked types are compatible just on shape. We added this explicitly
> due to Matt's feedback.
>
> Jay
>
>
> ===================================
> Jay Lawrence
> Senior Architect
> Functional Verification
> Cadence Design Systems, Inc.
> (978) 262-6294
> lawrence@cadence.com
> ===================================
>
> > -----Original Message-----
> > From: Karen Pieper [mailto:Karen.Pieper@synopsys.com]
> > Sent: Thursday, May 08, 2003 1:29 PM
> > To: Kevin Cameron x3251; sv-bc
> > Subject: Re: [sv-bc] Re: Separate Compilation
> >
> >
> > I've been told two or three times that
> >
> > typedef int x;
> >
> > x a;
> >
> > always begin {
> > typedef int x;
> >
> > x b;
> > }
> >
> > does not make a and b the same type. That would imply that
> > seeing typdef
> > of the same type several
> > times in $root results in different types?
> >
> > K
> >
> >
> > At 09:43 AM 5/8/03 -0700, Kevin Cameron x3251 wrote:
> > >>http://www.eda.org/sv-bc/hm/0587.html
> > >...
> > >>The original purpose of $root was to share symbols,
> > especially types.
> > >>'include wouldn't work because you couldn't put a type
> > declaration on a
> > >>port. Two types declared in two separate places aren't the
> > same even if
> > >>they are identical.
> > >
> > >Can someone expand on this for me, why wouldn't identical
> > types be the
> > >same?
> > >
> > >Kev.
> > >
> > >--
> > >National Semiconductor, Tel: (408) 721 3251
> > >2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA
> > 95052-8090
> > >
> > >
> >
> >
> >
>
This archive was generated by hypermail 2b28 : Thu May 08 2003 - 11:50:57 PDT