Interfaces provide a means to group wires into bundles with specified uses, described by methods.

Bluespec does not have input, output, and inout pins like verilog and VHDL. Signals and buses are driven in and out of modules with methods. Most modules with have several methods to drive all the busses in and out of a module. These methods are grouped together into interfaces.

Overview

In Verilog, interfaces for modules are port lists; conceptually a bundle of independent wires which connect the module to its parent. SystemVerilog extends the port list concept by providing interfaces which encapsulate interconnect and communication thus separating communication from functionality and enabling abstraction in the design.

SystemVerilog interfaces have many similarities to Verilog modules in that interfaces must be defined and instantiated before use. Moreover, interfaces or modules can provide tasks and functions to further encapsulate communication between modules.

In the Bluespec environment, interfaces contain members called methods, that is, specific functions which may be invoked by the caller. These functions take zero or more arguments, can return values or cause actions to occur. The main difference between methods and functions is that a method carries with it implicit conditions, the appropriate handshaking signals and logic which are automatically generated by the Bluespec compiler.

An example of a FIFO interface and its generated inputs and outputs.

An example of a multiplier interface and its generated inputs and outputs

Method Types

Bluespec classifies interface methods into three types:

• Value Methods: These are methods which return a value to the caller. When these methods are called, there is no change of state.
• Action Methods: These are methods which cause actions (state changes) to occur. One may consider these as input methods, since they typically take data into the module.
• ActionValue Methods: These methods couple Action and Value methods, providing an action to the module which provided the method, and returning a value to the caller.

Method arguments are input ports and method results are output ports.

Interfaces only specify the methods which a module provides, they do not say anything about the implementation of the methods. 

Interface Example

Consider the following interface definition for a FIFO-like device:

interface Fifo_ifc#(type any_t);
       method  any_t               first_element() ;
       method  Action              clear() ;
       method  Action              enqueue( any_t data_in ) ;
       method  ActionValue#(any_t) dequeue() ;
endinterface 

In this example, first_element delivers (as an output) a value of type any_t, without any change to the module which provides this interface. The method clear is an Action method, which takes no argument, and returns nothing, but it does impact the state of the module, that is it causes a state change (clearing the FIFO). Likewise, the enqueue method causes a state change without returning a value, but it does take an argument. The dequeue method causes a state change and returns a value.

Interfaces only specify the methods which a module provides, they do not say anything about any implementation of the methods. The above FIFO-like interface can be used for FIFO of any size. It can also be provided by a module which dequeues the square of the number enqueued, or one which dequeues the sum of a n consecutive enqueues.

Note that in this example the interface takes a type parameter; thus this interface can be used (reused) in situations which differ by data types:

   // declaring a module with an interface of Fifo_ifc
   module mkFifo1( Fifo_ifc#(any_t) ) ;
       ...
   endmodule 
   ...
   // instantiate a interface with a specific type Bit#(32)
   Fifo_ifc#(Bit#(32))  fifo32_inst1 <- mkFifo1 ;
   ... 

Complete FIFO example, including generated Verilog

Basic Interfaces from the Bluespec Library

Interface Design Tips