Subject: [sv-bc] FW: UPDATED: SystemVerilog3.1 interfaces: Synthesizing using modp orts
From: Vassilios.Gerousis@infineon.com
Date: Fri Feb 27 2004 - 02:50:06 PST
I am forwarding this "UPDATED" email on behalf of Peter Jensen, who is
helping Infineon on SystemVerilog Methodology and Usage
-----Original Message-----
From: Peter Jensen [mailto:peter@syosil.dk]
Sent: Thursday, February 26, 2004 9:39 PM
To: sv-bc@eda.org; johny.srouji@intel.com
Cc: Ecker Wolfgang (CL DAT TI MF); Kruse Thomas (CL DAT DF V); Peter Jensen
Subject: UPDATED: SystemVerilog3.1 interfaces: Synthesizing using modports
Hi SV-BC,
the mail I sent earlier today has minor flaws, which are corrected below.
Please disregard the mail sent earlier today.
Thank you,
Peter Jensen
-----Original Message-----
From: Peter Jensen [mailto:peter@syosil.dk]
Sent: 26. februar 2004 13:27
To: johny.srouji@intel.com
Cc: Wolfgang Ecker; Kruse Thomas
Subject: SystemVerilog3.1 interfaces: Synthesizing using modports
Hi SV-BC,
I have been using SystemVerilog3.1 interfaces for a while now, in
conjunction with a commercial EDA synthesis tool. This has caused a number
of questions regarding modports to arise - I hope you can clarify these for
me, as the SV3.1 LRM is unclear on some minor issues.
Feel free to mail or phone me if any of these issues are unclear.
I thank you very much in advance for your reply.
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 Access to objects when using modports.
-----------------------------------------
If using a modport while connecting an interface to a module, the modport
will define the input/output capabilities of the interface objects listed in
the modport. How about objects NOT listed in the modport? Are these not
accessible?
Example:
interface intf;
bit a, b, q;
modport mp (input a, output q);
endinterface
module m1 (intf.mp);
assign intf.q = intf.a & intf.b; // Is object "intf.b" accessible even
though not in modport?
endmodule
#3 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 usethe 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
assign intf_i.q = intf_i.a & intf_i.b; // inconsistent with
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
Question: Should the LRM prescribe that connection bewteen different
modport-subsets of the same interface is allowed, assuming these subsets are
compatible?
#4 Local extension modports [This assumes that connection between different
modport-subsets is possible, refer to #3]
---------------------------
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 #3 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.
#5 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
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.
Furthermore, no notification was given if objects a, b, q were left out -
the synthesis tool simply returned an empty module m2, as nothing was
connected to the logic inferred by f_calc.
This archive was generated by hypermail 2b28 : Fri Feb 27 2004 - 05:55:02 PST