Re: [sv-bc] Assignment compatibility after elaboration

For modules, why not just pull the type into the
compilation unit if you want to share it?

I think that getting to a completely defined
calculus for scope type equivalence is going to
be very tricky, particularly when you then pass
such "equivalent" types onwards as type parameters
and want to reason about resulting second or
third order type equivalence.

If we follow this route, I'd likely advocate
for a much more major change and ditch the current
rules altogether in favor of structural type
equivalence;  after all that is a better model
for synthesis anyways, isn't it?


Gord.


Jonathan Bromley wrote:
> Just my preliminary "user" $0.02-worth:
> 
> If I declare a *data object* in a module, I don't
> for a moment expect to be able to make use of it
> other than in a specific instance of the module.
> 
> If, on the other hand, I define a *type* in a module,
> I think I would be very happy to see it as something
> that's not instance-specific.  Indeed, I would rather
> like to be able to treat the module as something like
> a package, pulling type definitions out of it with
> 
>   module_name::type_name
> 
> syntax (although I suspect this would raise all manner
> of tricky issues and it's probably best ignored).  
> And I certainly would like any data member of a module 
> to be copy-compatible from one instance to another,
> even if that data member has a rather elaborate type
> definition.
> 
> Naturally, I'd expect that overriding any parameter of
> a module would specialize the module, thereby rendering
> types in it distinct from the same-named types in 
> other specializations - even if that parameter does not
> obviously affect the type definition.  However, since we
> can't typedef a module, I would expect that multiple 
> module instances with identical parameterization would 
> count as identical specializations - this would cover
> the array-of-instances issue.
> 
> I would need careful arguments to convince me that 
> binding an instance into a module cannot alter the
> target module's specialization, although my instinct
> is that the rather conservative rules about 'bind' and
> parameters probably mean that this is OK.
> 
> Finally, I think that there may be one problem that
> won't go away until we either get rid of defparam
> completely, or severely restrict its use.  It's
> possible I've missed something obvious here, but
> it worries me; please humour me.  Consider:
> 
>   module bot #(parameter N = 3);
>   endmodule : bot
> 
>   module mid;
>     bot B();
>     typedef int A [1:B.N];  // is this legal???
>   endmodule : mid
> 
>   module top;
>     mid M1();
>     mid M2();
>     defparam M2.B.N=2;
>   endmodule : top
> 
> It seems to me that I've now specialized M2.B without
> directly altering M2's parameters, and plainly the
> type M2.A is different from M1.A.  Is this a problem?

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.