Re: [sv-bc] Instantiating gates, primitives and modules in interfaces

Jay,

I agree that the only thing new under the sun here is using the mechanism
of passing instances by-reference as a way to write a more sane,
constrained form of XMRs.  Even the choice of the keyword "modport"
hints that your interpretation is also a sensible way of seeing things.

I wasn't personally a player in the syntax battles back then, but
I can imagine that the practical argument against your suggestion
may have been framed thus:  It is surely possible to do this, but
might not be prudent.  Passing a module/interface takes
space proportional to the number of wires in it.  Control of design
complexity demands a good way to distinguish between entities suited
to this usage, and those that should probably be left as legacy code.

The syntactic difference is meant to solve a "human factors" problem
not to claim any technical differentiation at the implementation level.
If it hadn't been done via the new keyword, it would have turned up as
some other form of access control modifier.  "Interface/endinterface"
is as good as any of the alternatives.

Interconnects are a design paradigm with their own constraints and
conventions which designers ignore at their peril.  Syntax exists
to express design intent.  If Verilog is viewed as just an assembly
language, then syntax to capture higher-order intent is out of place.
System Verilog tries to take that step up.  In practice, the edit from
module to interface or vice versa is not hard to do.  Maybe it will give
the author pause to review current best practice in interconnect design
along the way.

Greg Jaxon

Discalimer: This is a personal opinion, and may or may not coincide
with future Synopsis positions or products.


Jay Lawrence wrote:
> OK, I can't resist this one.
>  
> This was discussed ad nauseum in Accellera SV 3.1.
>  
> The basic issue debated was whether there was difference between 
> interfaces and modules. As many of you recall, I held the position that 
> an interface was simply the passing of an entire module on a port list 
> (equivalent to what is now a SystemC channel). Others (mostly Peter 
> Flake), held that they were a new unique object intended to model the 
> behavior of interconnect.
>  
> If we now allow all the same content as modules in interfaces then we 
> should once and for all get rid of the artificial distinction. Modules 
> and interfaces are aliases and modules should be passable as ports.
>  
> Hi everybody,
>  
> Jay
>  
> 
> ===================================
> Jay Lawrence
> Senior Architect
> Functional Verification
> Cadence Design Systems, Inc.
> (978) 262-6294
> lawrence@cadence.com
> ===================================
> 
>  
> 
>     ------------------------------------------------------------------------
>     *From:* owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] *On Behalf
>     Of *Brad Pierce
>     *Sent:* Thursday, April 27, 2006 3:52 PM
>     *To:* sv-bc@eda.org
>     *Subject:* [sv-bc] Instantiating gates, primitives and modules in
>     interfaces
> 
>     In http://eda.org/svdb/bug_view_page.php?bug_id=902 Brad suggests
>     allowing gates, primitives and modules to be instantiated inside
>     interfaces.  See also Yulik’s comments in
>     http://www.eda.org/sv-bc/hm/3473.html .
> 
>      
> 
>     Opinions?
> 
>      
> 
>     -- Brad
> 
>      
> 
>      
>