avot Posted May 31, 2016 Report Share Posted May 31, 2016 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: It is simple, efficient, it works. 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: 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. 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. 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. Quote Link to comment Share on other sites More sharing options...
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.