Re: [sv-bc] confusion in extern module and original module equivalence checking

Surya Pratik Saha wrote:
>   Consider the scenario ,
> 
>   extern module M (input enum {XX,YY} x );
>   ............
>   Module M ( input enum {X,Y} x);
>   ............
> 
>  Now  According  to system verilog LRM this is an error  scenario  as
> because type of x in extern definition and actual definition for module M
>  differ as the enum{X,Y} and enum{XX,YY} are different from each other.

These would be different from each other EVEN IF the labels had the
same spellings.  They differ because the types arise from two separate
appearances of the enum{...} syntax.  Whether the difference is detectable
may depend on file boundaries at the ... gaps.  Certainly when both
declarations become visible to the same tool invocation, the user is
owed an error.  But the purpose of an extern declaration is to
stand-in for the module declaration when it cannot be present, so
the juxtaposition might never arise in practice.  Separate compilation
tools won't necessarily be able to enforce SV type rules during
a later linkage phase; errors (if any) detected then might not
be able to pinpoint this coding mistake.  Best practice in C coding
brings together the declaration and definition at least once in
every build sequence to give the compiler a chance to cross-check
the externs.

Enums and unpacked structs and unions defined in a port list are
almost impossible to connect legally; this is not a productive
coding style.  Port types are the terms of a contract between the
module's user and its author.  To agree on those terms, the parties
should ideally acquire the types from a common source.  What constitutes
acceptable "sameness" of sources that may be being read by different
tool invocations is probably a matter of implementation quality and
operating procedures.  The goal of this level of strong typing is
to insure that there is exactly one reference definition responsible
for all applications of any given type.

> But Most of the Tools  passes this scenario ,though there is
>  missmatch  in type for x in extern and actual definition for module M.
> Also Same things happen if we use struct or union datatype in place of
> enum.

The types in an extern declaration must exactly match its definition.
We are not talking about assignment compatibility in this case - the
extern has to serve as a stand-in for the module definition for
the purposes of establishing correct port connections (coercions).

That said, not everyone appreciates the software engineering
benefits of strong typing and tools have had only a short exposure
to market pressures on this subject.  Getting type systems right
also takes development time.

>  Can someone tell me what would be the right  behaviour for the above
> scenario.
> 
> Thanks,
> Sumay

  Simple examples offer an insufficient motive to progress on this
issue.  Simple structural agreement across an API tends to be
adequate for getting the right functional effects.  To answer designers
who ask "what could go wrong?" you have to discuss meta-design issues
of how large RTL source code assets can be managed, reliably maintained
and reused, and eventually marketed.  Only in that context does code-
duplication show its corrosive nature.

Greg Jaxon

Disclaimer:  This is just my personal take on why we're trying
to set this standard.


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