RE: [sv-bc] Resolving a forward typedef via a package import

Brad,

You must not have any kids, or they must very young. I have no memory of
this.

The issue that you found explains the re-wording of the first sentence.
But I can't find anything that explains the addition of the second
sentence, especially because the e-mail discussion it refers to took
place before packages were created.

Dave



> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
On
> Behalf Of Brad Pierce
> Sent: Thursday, September 28, 2006 10:30 PM
> To: sv-bc@server.eda.org
> Subject: RE: [sv-bc] Resolving a forward typedef via a package import
> 
> Here's some background on that sentence --
> 
>    http://www.eda.org/sv-bc/display_issue.cgi?issue_num=41
> 
> -- Brad
> 
> -----Original Message-----
> From: Rich, Dave [mailto:Dave_Rich@mentor.com]
> Sent: Thursday, September 28, 2006 10:20 PM
> To: Greg Jaxon; Vreugdenhil, Gordon
> Cc: Brad Pierce; sv-bc@eda.org
> Subject: RE: [sv-bc] Resolving a forward typedef via a package import
> 
> Let's get practical here. Why would someone need to forward typedef a
> type that is defined in a package? The purpose of a forward typedef is
> to break circular type dependencies within a local scope. You can't
have
> circular package dependencies; therefore you should never need to
> forward typedef a type that will be later imported.
> 
> So I agree with Greg in that this final sentence in 4.9 should be
> removed.
> 
> Dave
> 
> 
> > -----Original Message-----
> > From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
> On
> > Behalf Of Greg Jaxon
> > Sent: Thursday, September 28, 2006 5:43 PM
> > To: Vreugdenhil, Gordon
> > Cc: Brad Pierce; sv-bc@server.eda.org
> > Subject: Re: [sv-bc] Resolving a forward typedef via a package
import
> >
> > This also makes me uneasy.
> >
> > Consider the problem of establishing the unique identity
> > of this type in the instantiation hierarchy.   I assume
> > that a typedef forward can only be completed by a full typedef /in
the
> 
> > same scope/, so that both have the same
> > full hierarchical name.   If it helps to consider an
> > implementation, imagine that the forward typedef actually produces
the
> 
> > basic type identity sans structural info.
> > References to the incomplete type may refer to this record location,
> > and the completion simply fills in the details under the previously
> > reserved identity.
> >
> > An import affects the receiving scope like a declaration.
> > But so does the forward typedef.  I say they collide and do not form
a
> 
> > completed pair.
> >
> > Greg
> >
> > Gordon Vreugdenhil wrote:
> > >
> > > I'm not quite sure that I buy your example.
> > >
> > > If you have:
> > >    typedef ab;
> > > ....
> > >    import pkg1::ab;
> > >
> > > I can buy that as a completion of the forward, but what you are
> > > asserting is that the forward typedef is completed *upon its
> > > declaration* if the type is is a candidate from some package.
> > >
> > > That isn't an obvious conclusion from the text and is one that I
am
> > > not sure I agree with.
> > >
> > > An implication of such a statement is that if ANY package has a
> > > visible type "T" then you can't forward declare "T"  even if your
> > > intent was to have the declaration complete locally.
> > >
> > > I would contend that the forward declaration does NOT count as a
> > > reference and the the completion must either be via an explicitly
> > > named import or by a subsequent typedef.
> > >
> > > So
> > >    typedef ab;
> > > ...
> > >    typedef pkg1::ab ab;
> > > would be fine as would my earlier example, but your example would
> > > not.
> > >
> > > Gord.
> > >
> > >
> > > Brad Pierce wrote:
> > >
> > >> According to the final sentence of 4.9,
> > >>
> > >>    "Importing a typedef from a package into a local scope can
also
> > >>     resolve a type definition."
> > >>
> > >> It would be helpful to add an example of that, such as,
> > >>
> > >>     package pkg1;
> > >>       typedef struct {logic a, b;} ab;
> > >>     endpackage
> > >>
> > >>     package pkg2;
> > >>       import pkg1::*;
> > >>       typedef ab;
> > >>     endpackage
> > >>
> > >>     module test(input a1, b1, output a2, b2);
> > >>       import pkg2::*;
> > >>       assign '{a2, b2} = ab'{a1, b1};
> > >>     endmodule
> > >>
> > >> -- Brad
> > >>
> > >>
> > >
>