The idea behind "interface" as a seperate entity seemed to be that it maps to a bunch of wires representing an old fashioned bus. Since Sonics (where I work now) and Nat Semi where I was working at the time this was first discussed don't use anything that simple for communicating between IP blocks it's of very limited use. If there was an abstract way of describing the protocol for the interface (e.g. OCP, AXI, MBA etc.) as part of the interface then that might hold up as an argument for keeping it seperate. The interconnects we create at Sonics are much better described by modules than interfaces, but it would be nice to be able to decompose a purely behavioral description (as would be supported by an interface) which performs the same function down into RTL without having to rewrite everything so I've always voted for just extending modules with the interface functionality. This was one of the reasons I voted against moving the standard forward at Accellera and I think turning it into an IEEE standard was premature since a lot of it is "half baked" and should have been cleaned up. Kev. PS: I'd also like module inheritance so that you can describe all the port stuff (and maybe assertions) seperately and then inherit it into a module with either behavior or implemantation (a bit like entity/architecture in VHDL) - but then modules might be too much like classes and I suspect there's a lobby against that (still) :-) Greg Jaxon wrote: > 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 >> >> >> > >Received on Sat Apr 29 02:06:46 2006
This archive was generated by hypermail 2.1.8 : Sat Apr 29 2006 - 02:07:13 PDT