Jump to content

SystemVerilog Interface packaging


Recommended Posts



I am investigating how to handle SV interface in IP-XACT 2009 (and 2014).


From the PSS written by Mark Noll "System Verilog Support", the idea is to describe the SVinterface instance with the SVmodule:

- Represent each SVinterface as a transactional port : <interface.modport>

- Represent port to be passed to the interface as <transactionalport.wire>

- And similarly, even if not explicitly written, same for parameters to be passed to the interface.



interface bus #(parameter width = 0,parameter offset = 0)(

input clk);

  logic [7:0] Addr, Data;

  logic RWn;

  modport slave  (input  Addr, inout Data);

  modport master (output Addr, inout Data);



module proc(bus.master procbus);



module ram(bus.slave membus);



module top();

  reg thebus_clk;

  bus #(.width (4),.offset (2)) thebus (.clk( thebus_clk ));

  proc theproc (.procbus( thebus.master ));

  ram theram (.membus( thebus.slave ) );


Corresponding IPXACT description:

proc.xml :

  • transtactional port “procbus”, typeName = “bus.master”
  • wire port “procbus.clk”
  • parameters: “procbus.width” and “procbus.offset”


  • transactional port “membus”, typeName = “bus.slave”.

During netlisting, this is the tool responsibility to detect and build the corresponding SVinterface from the IPXACT module (instance name thebus is automatically generated).


From my point of view, this approach has the following benefits:

  1. It is simple, efficient, it works.
  2. Even if the port is mapped inside an IPXACT bus interface, netlister is still able to build the SV interface.

But also the following limitations:

  1. It is not clear which component (here this is proc, but it could also be ram) must handle the interface description. How to manage conflict? The problem is more complex if the interface has several modport.
  2. All legacy generator for IP-XACT component, particularly the one manipulating ports and parameters, must be updated to take care that some element are not related to the verilog module itself, but to the corresponding SVinterface instance.
  3. Since the SVinterface instance is implicit in the IP-XACT design, it is difficult to set additional properties for this object: instance name, vendor extensions, …

The overall idea is this packaging is a kind of IP-XACT wrapper over a module and its Svinterfaces.

From my humble opinion, point 2 is a real problem.


So to tackle these 3 limitations, I am wondering if SV interfaces can be explicitly packaged and instantiated as an ordinary IPXACT module:


IP-XACT component for SVInterface:

  • All ports, parameters, fileset, default values, documentation, etc as usual.
  • ModPort packaged as transactional

IP-XACT component for verilog module for modport reference:

  • ModPort packaged as transactional + typeName : <svinterface.modport>.

And for design:

  • All IPXACT components (for module and SVinterface) explicitly instantiated, parameterized and connected.
  • Checkers ensures <svinterface.modport> is actually connected to a module with name “svinterface” and port “modport”.
  • Optionally, IP-XACT component instances for SvInterface can be omitted in the design, a generator will automatically add necessary corresponding instances for all connection crossing from <svinterface.modportA> to <svinterface.modportB> before netlisting (port connexion and configuration must be done manually).

This proposition seems to resolve limitations 1, 2 3, but we lose benefit 2 regarding IP-XACT bus connections.


Anyone have an opinion on the matter?


Best regards,


Grégoire Avot.

Link to comment
Share on other sites

  • 2 weeks later...

Hello Gregoire,


Thanks for addressing this topic. I think it is better to discuss it over the phone in a special interest meeting of the IP-XACT Technical Committee rather than have discussion in this forum. I will propose this in the next TC meeting. If we come to agreement then we can post the outcome here.


Best regards,


Link to comment
Share on other sites

  • 11 months later...

Hello ,

I am trying to package an System Verilog Interface as an IP-XACT Component. I see that the IP_XACT spec if not well defined to specify the SV Interface . Are there any guidelines on using this ?



Link to comment
Share on other sites

  • 1 month later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...