SystemVerilog interface-based design made simple

A SystemVerilog interface is a distributed state machine, with the state represented by its variables, partitioned into subsets managed by two or more cooperating modules. At the clock, each module first observes the variables it doesn’t manage, and then updates the variables it does manage. The purpose of the interface is to compose the modules into a larger machine that can still be reasoned about.

For example, a module might be given a modport

modport mp1(
   import observe1, update1,
   input a, b, c,
   output x, y, z);

and an interface method

  function automatic void update1(
    ...
  );
      x <= ...;
      y <= ...;
      z <= ...;
  endfunction

and use it in a procedure like

  always @(posedge clk) begin
     ...
     ifc.update1(...);
  end

When interface-based design goes wrong, it’s usually because interfaces are pushed beyond their intended purpose. There’s a reason this construct is called ‘interface’, not ‘interconnnect’. If you want to model, say, a channel operating across a network-on-chip, use a module, and connect it with simple interfaces to both ends. Interfaces make it easy to configure the module different ways, such as a fast simulation model using bounded mailboxes and a synthesizable model. As long as both versions support the same modports, the communicating blocks won’t even notice the difference.

Advertisements

2 Comments

  1. Do you have any idea what items inside an interface (functions, imported variables, clocked blocks, FlipFlops…) are synthesizable and what isn’t ?

    Like

    • There’s not much difference between an interface and a module except that a reference to an interface can be passed around and that the interface can declare modports to restrict access via that reference. (An artificial, but annoying difference, is this.) So there’s no reason to think that familiar features such as always_ff blocks would have any special issue in interfaces. (In real designs, I think it’s rare to see always_ff used in interfaces.)

      The only interesting issues are about references across an interface-type port, such as whether your synthesis tool will allow an imported interface function to access interface variables that are not listed in the modport, and how your synthesis tool handles ‘ref’ variables, especially when no modport is used. My advice, avoid those issues by always using a modport, and always listing all the variables that will be used by imported functions.

      Like

Tell me (anonymous OK)

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s