SystemVerilog For Design phần 8 docx

Chapter 10: SystemVerilog Interfaces 277 An interface definition can be nested within a module, making the name of the interface local to that module. Only the containing module can instantiate a locally declared interface. This allows the use of an interface to be limited to just one portion of the design hierarchy, such as to just within an IP model. 10.3 Using interfaces as module ports With SystemVerilog, a port of a module can be declared as an inter- face type, instead of the Verilog input, output or inout port directions. 10.3.1 Explicitly named interface ports A module port can be explicitly declared as a specific type of inter- face. This is done by using the name of an interface as the port type. The syntax is: module <module_name> (<interface_name> <port_name>); For example: interface chip_bus; endinterface module CACHE (chip_bus pins, // interface port input clock); endmodule An explicitly named interface port can only be connected to an interface of the same name. An error will occur if any other inter- face definition is connected to the port. Explicitly named interface ports ensure that a wrong interface can never be inadvertently con- nected to the port. Explicitly naming the interface type that can be connected to the port also serves to document directly within the port declaration exactly how the port is intended to be used. i n t er f aces can be limited to specific hierarchy scopes a mo d u l e por t can be the name of an interface 278 SystemVerilog for Design 10.3.2 Generic interface ports A generic interface port defines the port type using the keyword interface, instead of a using the name of a specific interface type. The syntax is: module <module_name> (interface <port_name>); When the module is instantiated, any interface can be connected to the generic interface port. This provides flexibility in that the same module can be used in multiple ways, with different interfaces con- nected to the module. In the following example, module RAM is defined with a generic interface port: module RAM (interface pins, input clock); endmodule 10.3.3 Synthesis guidelines Both styles of connecting an interface to a module are synthesiz- able. 10.4 Instantiating and connecting interfaces An instance of an interface is connected to a port of a module instance using a port connection, just as a discrete net would be connected to a port of a module instance. This requires that both the interface and the modules to which it is connected be instantiated. The syntax for an interface instance is the same as for a module instance. If the definition of the interface has ports, then signals can be connected to the interface instance, using either the port order connection style or the named port connection style, just as with a module instance. Interface connection rules a por t can b e declared using the interface keyword i n t er f aces are instantiated the same way as modules It is illegal to leave an interface port unconnected. NOTE Chapter 10: SystemVerilog Interfaces 279 A module input, output or inout port can be left unconnected on a module instance. This is not the case for an interface port. A port that is declared as an interface, whether generic or explicit, must be connected to an interface instance or another interface port. An error will occur if an interface port is left unconnected. On a module instance, a port that has been declared as an interface type must be connected to an interface instance, or another interface port that is higher up in the hierarchy. If a port declaration has an explicitly named interface type, then it must be connected to an interface instance of the identical type. If a port declaration has a generic interface type, then it can be connected to an interface instance of any type. The SystemVerilog .name and .* port connection styles can also be used with interface instances, as is illustrated in example 10-4 on page 275. These port connection styles are discussed in section 9.4 on page 233. Interfaces connected to interface instances A port of an interface can also be defined as an interface. This capa- bility allows one interface to be connected to another interface. The main bus of a design, for example might have one or more sub-bus- ses. Both the main bus and its sub-busses can be modeled as inter- faces. The sub-bus interfaces can be represented as ports of the main interface. 10.5 Referencing signals within an interface Within a module that has an interface port, the signals inside the interface must be accessed using the port name, using the following syntax: <port_name>.<internal_interface_signal_name> In example 10-3 on page 274, the interface definition for main_bus contains declarations for clock and resetN. Module slave has an interface port, with the port name of bus. The slave model can access the clock variable within the interface by refer- encing it as bus.clock. For example: i n t er f ace por t s must be connected th e por t o f an interface can connect to another interface s i gna l s i n an interface are referenced using the port name 280 SystemVerilog for Design always @(posedge bus.clock, negedge bus.resetN) Example 10-5 lists partial code for module slave. The model con- tains several references to signals within the main_bus interface. Example 10-5: Referencing signals within an interface module slave ( // main_bus interface port main_bus bus // other ports ); // internal signals logic [15:0] slave_data, slave_address; logic [15:0] operand_A, operand_B; logic mem_select, read, write; assign bus.address = mem_select? slave_address: ’z; assign bus.data = bus.slave_ready? slave_data: ’z; enum logic [4:0] {RESET = 5'b00001, START = 5'b00010, REQ_DATA = 5'b00100, EXECUTE = 5'b01000, DONE = 5'b10000} State, NextState; always_ff @(posedge bus.clock, negedge bus.resetN) begin: FSM if (!bus.resetN) State <= START; else State <= NextState; end always_comb begin : FSM_decode unique case (State) START: if (!bus.slave_request) begin bus.bus_request = 0; NextState = State; end else begin operand_A = bus.data; slave_address = bus.address; bus.bus_request = 1; NextState = REQ_DATA; end // decode other states endcase end: FSM_decode endmodule Chapter 10: SystemVerilog Interfaces 281 Since signals within an interface are accessed by prepending the interface port name to the signal name, it is convenient to use short names for interface port names. This keeps the reference to the interface signal name short and easy to read. The names within the interface can be descriptive and meaningful, as within any Verilog module. 10.6 Interface modports Interfaces provide a practical and straightforward way to simplify connections between modules. However, each module connected to an interface may need to see a slightly different view of the connec- tions within the interface. For example, to a slave on a bus, an interrupt_request signal might be an output from the slave, whereas to a processor on the same bus, interrupt_request would be an input. SystemVerilog interfaces provide a means to define different views of the interface signals that each module sees on its interface port. The definition is made within the interface, using the modport key- word. Modport is an abbreviation for module port. A modport defi- nition describes the module ports that are represented by the interface. An interface can have any number of modport defini- tions, each describing how one or more other modules view the sig- nals within the interface. A modport defines the port direction that the module sees for the signals in the interface. Examples of two modport declarations are: interface chip_bus (input logic clock, resetN); logic interrupt_request, grant, ready; logic [31:0] address; wire [63:0] data; modport master (input interrupt_request, input address, output grant, ready, inout data, input clock, resetN); Use short names for the names of interface ports. TIP mo d por t s d e fi ne interface connections from the perspective of the module 282 SystemVerilog for Design modport slave (output interrupt_request, output address, input grant, ready, inout data, input clock, resetN); endinterface The modport definitions do not contain vector sizes or types. This information is defined as part of the signal type declarations in the interface. The modport declaration only defines whether the con- necting module sees a signal as an input, output, bidirectional inout, or ref port. 10.6.1 Specifying which modport view to use SystemVerilog provides two methods for specifying which modport view a module interface port should use: • As part of the interface connection to a module instance • As part of the module port declaration in the module definition Both of these specification styles are synthesizable. Selecting the modport in the module instance When a module is instantiated and an instance of an interface is connected to a module instance port, the specific modport of the interface can be specified. The connection to the modport is speci- fied as: <interface_instance_name>.<modport_name> For example: chip_bus bus; // instance of an interface primary i1 (bus.master); // use master modport The following code snippet illustrates connecting two modules together with an interface called chip_bus. The module called primary is connected to the master view of the interface, and the module called secondary is connected to the slave view of the same interface: th e mo d por t can be selected in the module instance Chapter 10: SystemVerilog Interfaces 283 Example 10-6: Selecting which modport to use at the module instance interface chip_bus (input logic clock, resetN); modport master ( ); modport slave ( ); endinterface module primary (interface pins); // generic interface port endmodule module secondary (chip_bus pins); // specific interface port endmodule module chip (input logic clock, resetN); chip_bus bus (clock, resetN); // instance of an interface primary i1 (bus.master); // use the master modport view secondary i2 (bus.slave); // use the slave modport view endmodule When the modport to be used is specified in the module instance, the module definition can use either a generic interface port type or an explicitly named interface port type, as discussed in sections 10.3.2 on page 278, and 10.3.1 on page 277. The preceding exam- ple shows a generic interface port definition for primary module, and an explicitly named port type for secondary module. Selecting the modport in the module port declaration The specific modport of an interface to be used can be specified directly as part of the module port declaration. The modport to be connected to the interface is specified as: <interface_name>.<modport_name> For example: module secondary (chip_bus.slave pins); endmodule th e mo d por t can be selected in the module definition 284 SystemVerilog for Design The explicit interface name must be specified in the port type when the modport to be used is specified as part of the module definition. The instance of the module simply connects an instance of the interface to the module port, without specifying the name of a mod- port. The following code snippet shows a more complete context of specifying which modport is to be connected to a module, as part of the definition of the module. Example 10-7: Selecting which modport to use at the module definition interface chip_bus (input logic clock, resetN); modport master ( ); modport slave ( ); endinterface module primary (chip_bus.master pins); // use master modport endmodule module secondary (chip_bus.slave pins); // use slave modport endmodule module chip (input logic clock, resetN); chip_bus bus (clock, resetN); // instance of an interface primary i1 (bus); // will use the master modport view secondary i2 (bus); // will use the slave modport view endmodule The modport view that a module is to use can only be specified in one place, either on the module instance or as part of the module definition. It is an error to select which modport is to be used in both places. A modport can be selected in either the module instance or the module definition, but not both. NOTE Chapter 10: SystemVerilog Interfaces 285 Connecting to interfaces without specifying a modport Even when an interface is defined with modports, modules can still be connected to the complete interface, without specifying a spe- cific modport. However, the port directions of signals within an interface are only defined as part of a modport view. When no mod- port is specified as part of the connection to the interface, all nets in the interface are assumed to have a bidirectional inout direction, and all variables in the interface are assumed to be of type ref. A ref port passes values by reference, rather than by copy. This allows the module to access the variable in the interface, rather than a copy of the variable. Module reference ports are covered in sec- tion 9.7 on page 255. Synthesis considerations Synthesis supports both styles of specifying which modport is to be used with a module. Most synthesis compilers will expand the interface port of a module into the individual ports represented in the modport definition. The following code snippets show the pre- and post-synthesis module definitions of a module using an inter- face with modports. Pre-synthesis model, with an interface port: module primary (chip_bus.master pins); endmodule interface chip_bus (input wire clock, resetN); logic interrupt_request, grant, ready; logic [31:0] address; wire [63:0] data; modport master (input interrupt_request, input address, output grant, ready, inout data, input clock, resetN); endinterface Post-synthesis model: module primary (interrupt_request, address, w h en no modport is used, nets are bidirectional, and variables are references 286 SystemVerilog for Design grant, ready, data, clock, resetN); input interrupt_request, input [31:0] address, output grant, ready, inout [63:0] data, input clock, resetN); // synthesized model functionality endmodule Synthesis compilers might create different names for the separate ports than those shown in the example above. If no modport is specified when the model is synthesized, then all signals within the interface become bidirectional inout ports on the synthesized module. 10.6.2 Using modports to define different sets of connections In a more complex interface between several different modules, it may be that not every module needs to see the same set of signals within the interface. Modports make it possible to create a custom- ized view of the interface for each module connected. Restricting module access to interface signals A module can only directly access the signals listed in its modport definition. This makes it possible to have some signals within the interface completely hidden from view to certain modules. For example, the interface might contain a net called test_clock that is only used by modules connected to the interface through the master modport, and not by modules connected through the slave modport. A modport does not prohibit the use of a full hierarchy path to access any object in an interface. However, full hierarchy paths are not synthesizable, and are primarily used for verification. It is also possible to have internal signals within an interface that are not visible through any of the modport views. These internal signals might be used by protocol checkers or other functionality contained within the interface, as discussed later in this chapter. If a module is connected to the interface without specifying a modport, the module will have access to all signals defined in the interface. mo d por t s li m it access to the contents of an interface [...]... raise the level of abstraction for the data representation In Verilog, the type set is rather limited in comparison to SystemVerilog What is needed is a set of types that reflects the nature of the design The two ATM formats used in this ATM design are the UNI format and the NNI format Chapter 11: A Complete Design Modeled with SystemVerilog 303 Figure 11-1: UNI and NNI cell formats 7 0 0 VPI7-4 VPI3-0... Verification of designs that use interfaces is covered in much greater detail in the companion book, SystemVerilog for Verification1 1 Spear, Chris SystemVerilog for Verification”, Norwell, MA: Springer 2006, 0- 387 -27036-1 Chapter 10: SystemVerilog Interfaces 299 10.11 Summary This chapter has presented one of more powerful additions to the Verilog language for modeling very large designs: interfaces... the CRC -8 syndrom table for (int unsigned i=0; i . resetN); Use short names for the names of interface ports. TIP mo d por t s d e fi ne interface connections from the perspective of the module 282 SystemVerilog for Design modport slave (output. as: <interface_name>.<modport_name> For example: module secondary (chip_bus.slave pins); endmodule th e mo d por t can be selected in the module definition 284 SystemVerilog for Design The explicit interface. slave_ready, input slave_instruction, input slave_request, input bus_grant, input data_ready, 288 SystemVerilog for Design input clock, input resetN ); modport mem (inout data, output data_ready, input