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.

Hire the stars you’ve already got

According to Aaron Shapiro

Performance evaluations for managers should include assessment of the volume and quality of new ideas they brought to the table.

But instead there is usually no significant reward for teaching the wider organization new and better ways. And no employee smart enough to have a “secret sauce” is stupid enough to give a company the recipe for free. If the only way to profit from an idea or insight is to keep it a personal trade secret, then that’s what smart people will do.

If CEOs really want their companies to be innovative, they need to pay for it, and translate the spreading of great ideas into significant cold hard cash.

Why not approach your most effective people, who are getting the most measurable results, and offer them a 100% bonus for the year if they teach their methods to everybody?

Would you hire one person for a year if they could greatly increase the effectiveness of the organization? Well, why not just hire the stars you’ve already got?

SV12 — how much distance from SystemVerilog to SystemC?

Now that SV12 has channels/interfaces, what’s left that sets SystemC significantly apart as a system-level modeling language?

SV12 — towards a standard language for basic design concepts

A major SV12 productivity gap is the lack of a standard way to express the most common design concepts. For example, many designs use leading-zero detectors or priority encoders, yet everybody must write these well-understood old ideas again and again, or at best instantiate them from whatever IP library is being used locally.

It would be a major contribution to the SystemVerilog community for someone to define a standard collection of design packages and modules. (A modest initial version to get the ball rolling might be feasible as a student project?)

A secret to making it work would be resisting the temptation to provide a reference implementation. According to Brian Bailey

The other problem for the EDA companies — and this has been a consistent problem with SystemC — is that there are reference implementations. This makes it a lot more difficult for an EDA company to provide the necessary investment and to get a return from it. The market expects a price of zero and that means no incentive for the EDA companies to provide support.

A reference executable SVA specification might be nice to have though.

SV12 – deliver parameterized functions with let expressions

As discussed in SV12 13.8, parameterized functions can be declared as static methods of abstract classes.

This is a much more powerful coding style than traditional Verilog functions, but the function calls look ugly and redundant, hence error-prone and difficult for a human to read. A typical style will be to specialize the class with a type parameter for each argument, because most particulars, such as widths, can be derived from the types.

  ... C#(type(a+b),type(c+d))::f(a+b,c+d) ...

So don’t call the function directly, but instead use a let expression. (See 11.13.)

    package pkg;
      virtual class C ...
      endclass
      let f(arg1,arg2) =
         C#(type(arg1),type(arg2))::f(arg1,arg2);
    endpackage

    import pkg::*;
    
    ... f(a+b,c+d) ...

Package the abstract class with let declarations for each of its parameterized functions. At a call site, a let expression will be indistinguishable from a traditional Verilog function call.

If you update the package definition to use an entirely different class behind the scenes, with a different class name, different function names, and different parameters, then the consumers of the package won’t need to change even a character of code.

Standards are the high-speed rail to innovation

5 Ways That Standardization Can Lead To Innovation | Co. Design fastcodesign.com/1664682/5-ways… It's a balancing act we humans do very well. Sometimes.

—
leslie gadman (@lesliegadman) August 04, 2011

Accelerating innovation with standards. synopsys.com/Company/Public… via @ytrivedi #snps #semieda

—
Learning Loving (@learningloving) April 11, 2013

"Standards play a key role in the virtuous cycle of innovation." intel.com/content/www/us…

—
Learning Loving (@learningloving) April 16, 2013

SV12 — good-bye modules, hello object-oriented design

There are some obvious advantages vs. Verilog modules of the object-oriented descriptions of SV12. Classes are true types supported by the full modern toolbox of inheritance, interfaces, and virtual methods.

Instead of always blocks, an object-oriented hardware description in SV12 would use forever-methods that are forked off at time-0 by the constructor in the style of 13.4.4.

For arrays of class objects, you wouldn’t be hobbled, as you are for arrays of instances and generate-for scopes, by a restriction against dynamic indexing, because you’d be liberated from defparam. (See C.4.1.)

What would you lose today by laying things out at time-0 instead of at elaboration time? (“Today”, because it’s possible that a future revision of the LRM could recuperate them for time-0.) The only Verilog things that come to mind are configurations and conditional generate.

For SV12, there are probably various restrictions left to cope with, such as footnote A.10.11 about package imports.

But it’s not as if we must purge modules entirely. They would still be needed at least at the boundaries, such as for initial blocks that construct the highest-level objects and for the generic interconnect used in discrete real modeling.

Aside: According to Malcolm Gladwell, “If everyone has to think outside the box, maybe it’s the box that needs fixing.”