Does an Interface use resources when there is no Module instantiation?

[jrmejiaa]

Hi all,

I am working right now in a code that looks like this:

// Instantiate FIFO in case flag is set
FIFOF#(Bit#(10)) stats_fifo = ?;
if (mk_stats) begin
    stats_fifo <- mkFIFOF();
end

My questions are simple, in the section 9.1. Don’t-care expressions - BSV Reference Guide, it says:

When the value of an expression does not matter, a don’t-care expression can be used. It is written with just a question mark and can be used at any type. The compiler will pick a suitable value.

• This statement means that even with the ? the Verilog is going to have a working version of a FIFOF? Or there is a gain in terms of resources by leaving this as Don't-care.
• If I want to have a zero resource utilization penalty when the boolean mk_stats is not True, it is necessary to use a wraping flag? Something like this:

`ifdef MK_STATS_FLAG
// Instantiate FIFO in case flag is set
FIFOF#(Bit#(10)) stats_fifo <- mkFIFOF();
`endif

Thank you for your time,

JM

[quark17]

An interface is not state, it is a value. An interface just a struct of functions. Usually, those functions are connected to state that you have instantiated, but the functions can also just be values that don't refer to any state.

When you instantiate a module (with <-), that is when state is created:

stats_fifo <- mkFIFOF;

At a statement like the above, new state is added to an implicit collection that BSC is building up behind the scenes, and what is returned from the instantiation (and assigned to the name on the left-hand side of the arrow) is an interface -- a struct -- whose methods are connected to the ports of that state. The interface itself does not have state.

So, for example, you could write this:

  FIFOF#(Bit#(10)) stats_fifo;

  if (mk_stats)
    stats_fifo <- mkFIFOF;
  else
    stats_fifo = interface FIFOF;
                   method first() = ?;
                   method enq(x) = noAction;
                   method deq() = noAction;
                   method notFull = ?;
                   method notEmpty = ?;
                   method clear = noAction;
                 endinterface;

This either instantiates real state or it returns an interface whose methods are defined as no-ops. You could also abstract this into a function:

function FIFOF#(t) stubFIFOF();
  return (interface FIFOF;
            method first() = ?;
            method enq(x) = noAction;
            method deq() = noAction;
            method notFull = ?;
            method notEmpty = ?;
            method clear = noAction;
          endinterface);
endfunction

...
  if (mk_stats)
    stats_fifo <- mkFIFOF;
  else
    stats_fifo = stubFIFOF;

Or it could be abstracted into a module with no state -- which is equivalent to a function:

module mkStubFIFOF (FIFOF#(t));
  method first() = ?;
  method enq(x) = noAction;
  method deq() = noAction;
  method notFull = ?;
  method notEmpty = ?;
  method clear = noAction;
endmodule

...
  if (mk_stats)
    stats_fifo <- mkFIFOF;
  else
    stats_fifo <- mkStubFIFOF;

What you've written assigns a don't-care value (?) to the interface, in the else case:

  if (mk_stats)
    stats_fifo <- mkFIFOF;
  else
    stats_fifo = ?;

That is probably OK to write. It won't introduce any state. And in general, BSC will pick noAction when it sees a don't-care of Action type -- so when you try to call enq or deq on the don't-care interface, BSC should usually pick noAction. However, I can't always guarantee that.

In expressions like this:

if (c)
  x = 17;
else
  x = ?;

BSC is allowed to pick the don't-care value to be the same as the other branch, so that the entire if-condition can be removed, leaving just x = 17 in all cases. In theory, if BSC encountered an expression like this:

Action a;
if (c)
  a = fifo.deq;
else
  a = ?;

Then BSC would be allowed to reduce this to a = fifo.deq, meaning that the action would cause a dequeue in all cases, not just when c is True. BSC isn't creating any state, that's not the risk. The risk is that BSC might perform a side-effect, when you weren't expecting it. That's why it'd be better to write this:

if (c)
  a = fifo.deq;
else
  a = noAction;

In your example, this situation may not come up. So it's probably OK to use ? for the interface, when not instantiating a FIFO module. But to be safe, you might want to explicitly define the interface (in one of the three ways that I showed above). A preprocessor macro can also be used, as you wrote.