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 > >> > >> > >Received on Thu Sep 28 22:30:36 2006
This archive was generated by hypermail 2.1.8 : Thu Sep 28 2006 - 22:30:47 PDT