Re: [sv-bc] Assignment compatibility after elaboration

Gordon Vreugdenhil wrote:
> 
> For modules, why not just pull the type into the
> compilation unit if you want to share it?

Although that's often the right answer, it is not a panacea.
If defparams do affect the specializations, it might be important
to preserve that hierarchical access to the type's parameters.

> 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.

There is clearly some binary or ascii encoding of the type's
signature that encapsulates its "identity", and travels with
the type parameter.  This has its nuances, but the scoping
rules are much simpler when they are based only on (elaborated)
lexical scoping - before hierarchical considerations apply.
Most type comparisons in simulation (and all in synthesis) are
evaluable when they are elaborated for a module or interface
specialization.  Without XMRs or instance-dependence,
synthesis can allow type comparisons to control Generate-IFs/CASEs.

  Of course, for some class types, instance-specificity will
arise when the type signature picks up a dependence on a static
data reference relative to the hierarchy.  Any types above there
in a compound signature will then all have an instance-specific
subfield.  Such fields will frustrate the recursive type equivalence
comparison.  I suppose the elaboration time type signature will
have some $instance_id_XYZ free variables which the linkage step
fills in.

> 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?

No, I think that ruins the "strong" typing initiative.  I see
the goal for that project to be insuring that exactly one source
location is responsible for each attribute of a strong type.
For the benefit of large designs, we want to prevent accidental
type alignments, which evaporate or malfunction when the separate
parts next diverge.  Of course structural equivalence is still
necessary in SV type matching, but scope and source file provenance
are equally important from the project management perspective.

We might both be using version 4.3 of a common include file.
However, if we don't, in fact, obtain it from the same distribution site,
in what sense are we using the same datatype?  You could move up to
version 4.3.1 several builds before my team finishes qualifying that
release, until then should our type comparisons come out structurally
different on assorted items?  I'd rather see our failure to agree
on a single source site manifest itself as an absolute type mismatch.
Interface details are worth stopping the build to get right.


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