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

As written, your suggestion both imports and locally declares
the same name:

import pkg1::*;
typedef   ab   ab;
// import ^^ & ^^ local decl

  so that's a collision.  You could write...

typedef pkg1::ab ab; // or
parameter cd = pkg::cd;  // or similarly
function automatic bit [7:0] ef( integer gh, ij );
   return pkg1::ef( gh, ij );
endfunction

because the content extractions do not add names to
the local scope.  This is how you'd have /rename/ imports
to workaround collision too.

... but this is tedious and error prone, and I haven't
considered the other entities that simulator packages
might want to chain.

Greg


Brad Pierce wrote:
> So, without 'export', I have to redeclare the type, even when I don't
> wish to alias it?
> 
>      package pkg1;
>        typedef struct {logic a, b;} ab;
>      endpackage
> 
>      package pkg2;
>        import pkg1::*;
>        typedef ab ab;  //<-----
>      endpackage
> 
>      module test(input a1, b1, output a2, b2);
>        import pkg2::*;
>        assign '{a2, b2} = ab'{a1, b1};
>      endmodule
> 
> -- Brad
> 
> -----Original Message-----
> From: Greg Jaxon [mailto:Jaxon@synopsys.COM] 
> Sent: Thursday, September 28, 2006 5:43 PM
> To: Gordon Vreugdenhil
> Cc: Brad Pierce; sv-bc@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
>>>
>>>
> 
>