[sv-bc] Interface modports vs. logic synthesis

Hello,

I have been using SystemVerilog3.1 interfaces for a while now, in
conjunction with a commercial EDA synthesis tool. This has caused a few
questions regarding modports to arise - I hope you can clarify these for
me, as the SV3.1a Draft5 LRM is unclear on some minor issues.

Thank you in advance.

Kind regards,
Peter Jensen

Peter Jensen
SyoSil Consulting
Himmelev Bygade 53
DK-4000 Roskilde
Tel/Fax +45 46 36 11 32
Mobile +45 40 58 10 00
mailto:peter@syosil.dk
 

#1 Compatibility between different modport (subtypes) of same interface.
------------------------------------------------------------------------

We have an interface with 4 input bits (a,b,c,d) and two result bits (q,w).
The module m1 instantiates module m2, which again instantiates module m3.
As we want the driver of q=a&b to be in m2 and the driver of w=c|d in m3
we cannot use the same modport when connecting the interface m1<->m2 as
for m2<->m3.
This would result in both having a driver of q in m2 and m3.
Yes, an EDA synthesis tool can remove the q port on m3 if unconnected in
this module, but this is rather unclean. Also, a,b would be accessible
within m3, this probably is not desired. Rather, we need to use
another modport (mp3) which is a subset of modport m2.

interface intf;
          bit a;
          bit b;
          bit c;
          bit d;
          bit q;
          bit w;
          modport mp2 (input a, input b, input c, input d, output q, output w);
          modport mp3 (input c, input d, output w);
endinterface

module m1;
       intf intf_i ();
       m2 m2_i (.intf_i(intf_i.mp2));
endmodule;

module m2 (intf intf_i);
       m3 m3_i (.intf_i(intf_i.mp3)); // EDA TOOL ERROR: interface/modport
                                                                // port intf_i is inconsistent with
       assign intf_i.q = intf_i.a & intf_i.b; // other instances
                                                                // [tool cannot find mp3 in intf_i]
endmodule

module m3 (intf intf_i);
       assign intf_i.w = intf_i.c | intf_i.d;
endmodule

Using a synthesis tool, the error inlined in the comments above was encountered.
This happens becausee mp2 has restricted the interface scope to view exactly
what is in the modport, thus mp3 cannot be found.

Question: Should the LRM prescribe that connection bewteen different
modport-subsets of the same interface is allowed, assuming these subsets are
compatible?

#2 Local extension modports
---------------------------

[This assumes that connection between different
modport-subsets is possible, refer to #1]

When an interface is connected to a module, the interface has no notion of
what hierarchical level inside the module drives the output signals.
Therefore, the interface modports withheld inside the interface must be
repeatedly modified with design specific information, which is rather
unclean.

Has it been considered to allow "local extension" of an interface by adding
modport within the interface client? This would allow the interface client
to keep information about its hierarchies local.

Example:

In case #1 above, the modport mp3 could be defined within the scope of
module m2, where it would extend the intf interface type. By doing this,
intf does not need to know whether m2 or m3 drive the intf "w" object.

#3 Access to interfaces through methods rather than objects
-----------------------------------------------------------

When using interface methods (functions/tasks) to access objects (e.g.
variables) within interfaces, it is clear that such methods should be listed
in the modport using the import keyword. But should the objects be listed as
well?

Example:

interface intf;
          bit a, b, q;

          function void f_calc();
             q = a & b;
          endfunction

          modport mp1 (import function f_calc());
          modport mp2 (input a, input b, output q, import function f_calc());
endinterface

module m1;
       intf intf_i ();
       m2 m2_i (.intf_i(intf_i.mp1));
endmodule;

module m2 (interface intf_i);
       always_comb
          intf_i.f_calc();
endmodule

Question:
Should modport m1 or m2 be used when connecting the interface to m2?

If m1 cannot be used, the use of real generic interfaces is partly
inhibited, as the objects a, b, q also can be accessed by the interface
client. Modport m1 forces the interface client to access the interface by
methods.

An EDA tool used for synthesis required that m2 was used in this example.

 
Received on Fri Mar 19 03:50:35 2004