avot

SystemVerilog Interface packaging

2 posts in this topic

Hello,

 

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.

 

Ex:

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);

endinterface

 

module proc(bus.master procbus);

endmodule

 

module ram(bus.slave membus);

endmodule

 

module top();

  reg thebus_clk;

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

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

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

endmodule
 

Corresponding IPXACT description:

proc.xml :

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

ram.xml:

  • 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.

Share this post


Link to post
Share on other sites

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,

Erwin

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now