RE: [sv-bc] Querry regarding Interface

From: Jonathan Bromley <jonathan.bromley_at_.....>
Date: Thu Apr 03 2008 - 06:05:45 PDT
Surya,

>     The main aim of interface as we all know is to encapsulate
> communication. If that is the motto then bundling variables 
> and wires in
> interfaces and declaring communication protocol should be 
> enough.So what
> is the motivation behind supporting always blocks or concurrent
> assignment statements inside interface 

Speaking purely for myself, I believe your argument is moving
in precisely the wrong direction.  Interfaces offer a wonderful
opportunity to abstract the details of communication out of
modules, leaving the module to concentrate on its own 
functionality and not on the communication functionality
(which is shared by any modules that use the same interconnect
arrangements).

In fact, I would complain that interfaces do not go far enough
in facilitating this abstraction; in particular, I have long
argued that modports should be first-class objects (data types?)
declared outside of any interface, so that they represent the
abstraction of the link between a module and its communications
medium (interface).  Mantis 1861 contains some imperfect and
incomplete sketches for this idea.

For an interesting early example of the use of interfaces to
provide an abstraction of more than just the wiring of a
communications setup, see a paper by Jensen, Kruse and 
Ecker from SNUG Boston 2004.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223                   Email: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: http://www.doulos.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Apr 3 06:06:44 2008

This archive was generated by hypermail 2.1.8 : Thu Apr 03 2008 - 06:06:54 PDT