I have a full AXI interface and a lite AXI interface as shown below:
interface axi_full ();
logic [63:0] wdata;
logic . wid;
logic wcredit;
endinterface
interface axi_lite();
logic [63:0] wdata;
logic wcredit;
endinterface
Is there a way I can use only one interface with a parameter lite something like below instead of two separate interfaces? The only difference is there is no wid in the case of AXI lite.
interface axi #(bit Lite = 1'b0) ();
...
...
endinterface
Unfortunately not. You should be able to use the axi_full and leave the wid signal unused.
There is nothing in the standard that would prevent from using generate blocks inside the interfaces. So, the following is supposed to work:
interface axi #(FULL=1)();
logic [63:0] wdata;
logic wid;
if (FULL != 0) begin: fff
logic wcredit;
end
endinterface
module top;
axi#(1) full();
axi#(0) lite();
imod fm(full);
//imod lm(lite);
endmodule
module imod(axi i);
initial begin
$display(i.wdata, i.wid, i.fff.wcredit);
end
endmodule
The problem as always is in vendor implementation. The above seems to work nicely in the cadence's nc. Uncommenting the 'lite' string will cause it to generate an error.
However, synopsys vcs, at least the one in eda playground refuses to compile it complaining about unimplemented feature of xmrs into interfaces.
Synthesis might have their own thoughts about this. So, the best way is to use separate definitions.
Also it depends on how you use them, modports can be handy. They are implemented better and the following example should work everywhere:
interface axi_if;
logic [63:0] wdata;
logic wid;
logic wcredit;
modport full (input wdata, wid, wcredit);
modport lite(input wdata, wid);
endinterface
module top;
axi_if intf();
fmod fm(intf);
lmod lm(intf);
endmodule
module fmod(axi_if.full i);
initial begin
$display(i.wdata, i.wid, i.wcredit);
end
endmodule
module lmod(axi_if.lite i);
initial begin
$display(i.wdata, i.wid); //, i.wcredit);
end
endmodule
What you are saying is not possible, but you can place wid signal inside `ifdef compile directive like following
interface axi();
logic [63:0] wdata;
`ifdef AXI_FULL
logic wid;
`endif
logic wcredit;
endinterface
define AXI_FULL when you are not using AXI-Lite
also take this thing into consideration while connecting axi interface
Related
In SystemVerilog I CAN do
typedef logic [15:0] bus16;
typedef reg [15:0] reg16;
interface myif;
bus16 mybus;
wor [15:0] myotherbus;
endinterface
But I CAN'T do
typedef wor [15:0] wor16;
interface myif;
wor16 myotherbus;
endinterface
I get "unknown variable declaration type"
It seems, at least in my Synplicity version, typedefs of 'wor' is not permitted.
Is this a limitation defined in the IEEE1800 spec or is it perhaps a bug?
SystemVerilog separates the concepts of network/net types (which are like resolved signals in VHDL) and variables (unresolved) from data types. The net types wire, wand, wor, etc. have built-in resolution functions with a default data type of logic. The following net declarations are equivalent:
wor [15:0] w;
wor logic [15:0] w;
typedef logic [15:0] bus16;
wor bus16 w;
Similarly the following variable declarations are equivalent:
logic [15:0] v;
var logic [15:0] v;
typedef logic [15:0] bus16;
var bus16 v;
bus16 v;
In most places, the var keyword is implicit when declaring variables.
There is a nettype declaration that binds a data type with a user-defined resolution function. Unfortunately there no way to define a nettype with one of the built-in resolution functions, so you would have to write your own or function.
It is disallowed because System Verilog Standard does not allow using nets in typedefs. Sorry, no other explanation.
You can look at the syntax in paragraph 6.18. Follow data_type definition. It is based on system verilog vars but does not include nets (6.8).
You can define a new net type using the nettype construct, but it still does no allow you to use other net types. However, you can create them with a custom resolution behavior (check 6.6.7). It is a special syntax and does not fit for simple renaming. BTW, neither wor nor this are synthesizable.
So, your best bet is to use macros: `define wor16 wor[15:0]
Here is a snippet of some interface code that has some parameterized sizes to it. The fourth parameter, HAS_BURST is something I have experimented with, but it has only resulted in compilation errors.
Effectively I am looking for a way to ADD/REMOVE a signal from a interface based on parameter. Is there a way to have a generic interface with removable signals?
interface axi_if
#(parameter ID_WIDTH = 4,
ADDR_WIDTH = 40,
DATA_WIDTH = 64,
HAS_BURST = 0)
();
logic aw_ready;
logic aw_valid;
logic [ID_WIDTH-1:0] aw_bits_id;
logic [ADDR_WIDTH-1:0] aw_bits_addr;
logic [7:0] aw_bits_len;
logic [2:0] aw_bits_size;
generate
if (HAS_BURST)
logic [1:0] aw_bits_burst;
endgenerate
logic [2:0] aw_bits_size;
modport slave (
output aw_ready,
input aw_valid,
input aw_bits_id,
input aw_bits_addr,
input aw_bits_len,
generate
if (HAS_BURST)
input aw_bits_burst,
endgenerate
input aw_bits_size
);
modport master (
input aw_ready,
output aw_valid,
output aw_bits_id,
output aw_bits_addr,
output aw_bits_len,
generate
if (HAS_BURST)
output aw_bits_burst,
endgenerate
output aw_bits_size
);
endinterface
`endif
No, there isn't. Ports aren't valid in generate blocks. Parameters can be used to asjust the width of a port but not remove it entirely. You could use an `ifdef to compile it conditionally but that's an all-or-none solution. There can't be some instances with the signal and others without it.
Having the signal unconditionally present is fine in many situations and it's the easiest way to handle this problem. Tie any unused inputs to logic 0 and unused outputs can remain unconnected.
If neither of these options work there's no other way than to define two different interfaces. Doing this by hand quickly becomes unmaintainable. If there are two variations now you can be sure a third one will be needed soon, then a fourth, a fifth... Many chip design companies have SystemVerilog code generators which create customized modules for each instance.
I have a fundamental understanding problem with System Verilog. I am working on a processor design, where some bus systems should be shared between several processing units (System Verilog modules). With an arbiter only one module at a time should be active, driving the bus, while all other are high impedance.
I got rid of the multidriven nets warnings in Vivado during synthesis and there are not anymore any bus conflicts, but the simulator gives a warning, that the bus signals 'might' be multidriven. I made a tiny example code and I would expect to get for 'data' '11', when 'select' is '10'?
While simulation stops at all in Vivado, it works with Cadence simulator, but with wrong results - screenshot simulation
testbench.sv
`timescale 1ns / 1ps
module testbench_top();
logic [1:0] select;
logic [1:0] data;
top top_inst(.*);
initial
begin
select = 0;
#2 select = 1;
#2 select = 2;
#2 select = 0;;
end
initial
begin
$monitor("t=%3d s=%b,d=%b\n",$time,select,data);
end
endmodule
design.sv
`timescale 1ns / 1ps
module top
(
input logic [1:0] select,
output logic [1:0] data
);
driver_1 driver_1_inst(.*);
driver_2 driver_2_inst(.*);
endmodule
module driver_1
(
input logic [1:0] select,
output logic [1:0] data
);
always_comb
begin
if (select == 2'b10)
data = 2'b11;
else
data = 'z;
end
endmodule
module driver_2
(
input logic [1:0] select,
output logic [1:0] data
);
always_comb
begin
if (select == 2'b01)
data = 2'b01;
else
data = 'z;
end
endmodule
I'm assuming you expect the value of data signal the top module, which is driven by the two outputs of your driver modules, to be resolved (e.g. when one drive 'z, the other gets the bus.
This will happen if you declare the top.data signal as output wire logic [1:0] data.
Section 23.2.2.3 Rules for determining port kind, data type, and direction of the IEEE 1800-2012 standard states that
For output ports, the default port kind depends on how the data type
is specified: — If the data type is omitted or declared with the
implicit_data_type syntax, the port kind shall default to a net of
default net type. — If the data type is declared with the explicit
data_type syntax, the port kind shall default to variable.
In your case, the second clause applies, since you declared data as output logic[1:0], meaning that it was interpreted as a variable and not a net. Multiple values on variables aren't resolved (and in some tools are also illegal).
I'm implementing a system that uses an interface to connect two blocks that implements AXI4 lite functions.
Problem is the master and the slave blocks are inside other blocks.
The code above shows an example of what I'm trying to do:
interface bus
logic [ADDR_WIDTH-1:0] wr_addr; // Write address
logic [DATA_WIDTH-1:0] wr_data; // Write data
logic [ADDR_WIDTH-1:0] rd_addr; // Read address
logic [DATA_WIDTH-1:0] rd_data; // Read data
modport master (
output wr_addr,
output wr_data,
input rd_addr,
input rd_data
);
modport slave (
input wr_addr,
input wr_data,
output rd_addr,
output rd_data
);
endinterface
// innermost master block
module m0(bus.master bus_inst_m0);
// write/ read data from/to master modport
bus_inst_m0.wr_addr <= ...
if(bus_inst_m0.rd_addr == ...
endmodule
// instance of m0 block connected
// to interface
module m1(bus.master bus_inst_m1);
m0 m0_inst(.bus_inst_m0 (bus_inst_m1))
endmodule
// innermost slave block
module s0(bus.slave bus_inst_s0);
// write/ read data from/to slave modport
bus_inst_s0.rd_addr <= ...
if(bus_inst_s0.wd_addr == ...
endmodule
// instance of ms block connected
// to interface
module s1(bus.slave bus_inst_s1);
s0 s0_inst(.bus_inst_s0 (bus_inst_s1))
endmodule
// top module
module top();
bus local_bus;
m1 m1_inst (.bus_inst_m1 (local_bus));
s1 s1_inst (.bus_inst_s1 (local_bus));
endmodule
In Cadence Incisive simulator, the code compiles, but it not works. Looking in the schematic I see that the top interface is connected, but the inner interfaces are just open.
I made a small test connecting directly the master and slave blocks and it worked fine.
I have tried other combinations of interface/modport too, like using modport just in the innermost blocks, but it didn't work.
I read the LRM and did not found any clue about what I'm doing wrong.
Can anyone help?
Thanks
Rods
First of all, you have a bunch of options to use.
You can use generic interfaces as module parameters to avoid type errors. In this case, as long as the connected interface has all the signals that the module use, you will be okay. (And if the tool finds the proper interface...) Eg.:
module mod_gen_inf(interface gen_if);
endmodule
...
module top();
m_bus_if m_bus;
m_1 slave_actor(.gen_if(m_bus.master));
endmodule: top
Secondly, you can, but you are not required to specify the modport (type) at the module declaration. You can use the interface's name, and connect the specific modport at the module instantiation. Eg.:
module slave_actor(m_bus m_bus_if);
endmodule
...
module top();
m_bus_if m_bus;
m_1 slave_actor(.m_bus_if(m_bus.slave));
endmodule: top
Think of this as the modport is a compatible type of the given interface.
Thus a corrected/shortened version of your code:
interface m_bus;
logic [1:0] a;
modport master(input a);
modport slave (output a);
endinterface
module m1(m_bus.master bus_inst_m1);
m2 m2_inst(.bus_inst_m2(bus_inst_m1));
endmodule
module m2 (m_bus.master bus_inst_m2);
endmodule
module s1(m_bus.slave bus_inst_s1);
endmodule
module top();
m_bus local_bus();
m1 m1_inst (.bus_inst_m1 (local_bus.master));
s1 s1_inst (.bus_inst_s1 (local_bus.slave));
endmodule
This worked me fine in QuestaSim 10.5c.
If your code compiled but does not work, make sure that your innermost block sees the interface as well. (include the library that your IF is compiled into.)
I'm verilog user and unfamiliar with systemverilog.
I have found what to used modport and instanciate between DUT and interface in systemverilog.
But I don't no why use the modport and how to use and interconnect between interface and DUT in systemverilog?
Modport is short for module port. They allow for the definition of different views of the signals within the interface. In many cases, just two modports, or views, are needed - One for the source-side of the interface, and one for the sink-side. A simple example is below:
interface simple_if ();
wire we;
wire wdata;
wire full;
// source-side view
modport src (
output we,
output wdata,
input full
);
// sink-side view
modport snk (
input we,
input wdata,
output full
);
endinterface
The interface can be used to connect two module instances together, and which view, or modport to use can be specified at each module instance using the dot notation. Example below using the interface definition above:
module top();
// first, instantiate the interface
simple_if simple_if ();
// source-side module instantiation
src_side_module u_src_side_module (
.clk (clk),
.rstl (rstl),
.if(simple_if.src) // .src specifies the modport
);
// sink-side module instantiation
snk_side_module u_snk_side_module (
.clk (clk),
.rstl (rstl),
.if(simple_if.snk) // .snk specifies the modport
);
endmodule
Couple other notes:
The clocks and resets can also be passed around inside the interface.
Alternatively, the modport can be specified down in the module where you specify the IO, like this:
module src_side_module (
input wire clk,
input wire rstl,
simple_if.src if
);
....
Hope this helps.