Most of the tools I use allow it but one doesn't. I've read the specs, IEEE1800-2017 I couldn't find it.
module mymod (
input logic clk,
input logic reset,
input struct packed {
logic [1:0] var0;
logic [1:0] var1;
logic [8:0] var2;
} addr,
...
I saw some examples here and there, using even typedef structures in ports.
Is it allowed by the specs? Where?
Cf. 7.2 Structures and 7.2.1 Packed structures
A port can be any data type. (section 23.2.2) There are some restrictions on whether that datatype can be represented by a variable or net signal that interact with the port direction.
But I would strongly discourage the use of an anonymous type (struct in your example) and instead declare a user defined type with a typedef in a common package and use that typedef when declaring that port. That eliminates type compatibility issues when trying to connect unpacked struct and enums.
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]
I am using modlesim for my design and in this we are passing an option -svinputport=var, what is the use of this option? we are passing `default_nettype none before compiling each design files. Does these both are dependent? Could anyone help me with an example.
The description is as below for the option
svinputport=net|var|compat|relaxed
Select the default kind for an input port that is
declared with a type, but without the var keyword.
Select 'net' for strict LRM compliance, where the
kind always defaults to wire. Select 'var' for
non-compliant behavior, where the kind always defaults
to var. Select 'compat', where only types compatible with
net declarations default to wire. The default is 'relaxed',
where only a type that is a 4-state scalar or 4-state single
dimension vector type defaults to wire.
Question (2)
Thank you very much for the detailed explanation. I have one more doubt related to this. I am getting a warning when I run the following code:
`default_nettype none
module test(
input reg sig1,
output logic sig2);
reg [1:0] ab;
endmodule
xmvlog: *W,NODNTW (test.sv,4|14): Implicit net port (sig1) is not allowed since `default_nettype is declared as 'none'; 'wire' used instead [19.2(IEEE 2001)]. why it is referring input reg sig1 as an implicit net port, I already explicitly declared it as reg? As per the message it is changing to wire so will the statement be like "input wire reg sig1" ?
Can we declare input reg a; in systemverilog(input port with reg type) ? Is this implicitly equivalent to input wire reg a; (if I dont use `default_nettype none)
Verilog is littered with implicit defaults all over the place. When you write
module m(a);
initial $disaply(a);
endmodule
this is implicitly the same as
// direction kind type range signal
module m(inout wire logic [0:0] a);
initial $disaply(a);
endmodule
For inout and input directions, if you omit the kind the default is wire or taken from the `default_nettype setting. The none setting generates an error. However, the default kind for an output is different. As soon as you add a datatype to an output, the default kind goes to var, which is similar to non-port declarations. See this post for more details and examples.
However, very early versions of SystemVerilog/Superlog had input and inout with the same kind default as output. The -svinputport=var switch was added for a very large microprocessor developer customer whose name I cannot mention who did not want to change their code. The =net options is the behavior I mentioned above and is the way current LRM is defined.
The other two options are hybrids between the var/net options, mainly for lazy people using the default_nettype none options and don't want to see errors in their port declarations.
I'm pretty sure there is no way to do what I am trying, but just in case there is an interesting clever solution, I thought I'd ask around. I have a parameterized SystemVerilog interface, inside of which I am generating modports
interface some_interface #(parameter NUM_READERS=3);
logic [`kBitsPerProgramCounter-1:0] read_addr[NUM_READERS];
logic [`kBitsPerProgramCounter-1:0] write_addr;
genvar i;
generate
// generates Reader[n].Modport
for (i = 0; i < NUM_READERS; ++i) begin : Reader
modport Modport
(
output .read_addr(read_addr[i])
);
end
endgenerate
endinterface
Using this is easy if I have different module types taking different modports. However, what I wanted to try doing is to have multiple instances of the same module. I tried this by parameterizing on type
module some_block#(parameter type SOMETYPE) (
input logic CLK200MHZ,
SOMETYPE aarrgghh);
But getting it to work syntactically has been challenging. Giving SOMETYPE a default value doesn't work because Vivado complains about not allowing hierarchical types, so right off the bat I don't think this will work. When instantiating, I tried using the full modport name, the full modport name with the instantiated interface, and a few others, but nothing seems to work.
So I am curious if there is a clever way I can have multiple instantiations of some_block, each taking a different generated modport. And if not, is there some fun clever trick I can do to use the generated modports? The idea in the first place was that I have a thing that has one writer and multiple readers. I wanted to generate a modport for each reader so that it could only touch it's own read address. I guess I could always just parameterize some_block on an integer, pass some_block the whole interface, and then rely on some_block to only touch the read address corresponding to the passed in integer, but that might be error prone.
Assuming that 'generate' works, there is nothing to be concerned about modules. There is no need to pass a type parameter. The module port is just supposed to be of the type of your interface.
module top();
some_interface ifc;
for (genvar gi = 0; gi < NUM_REASDERS; gi++) begin: inst
some_block sb(ifc.Reader[gi].Modport);
end
endmodule
module some_block (some_interface ifc);
always_comb myvar = ifc.read_addr;
some_block just always references the 'read_addr' which is the modport var. You can use a generate block in the 'top' module.
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 two modules and a class and I would like to move that class from one module to the other. Something like this:
class foo;
int x;
int y;
endclass
module mod_A(output foo foo_inst, output event trig);
initial begin
foo my_foo = new;
my_foo.x = 1;
my_foo.y = 2;
foo_inst = my_foo;
->trig;
end
endmodule
module mod_B(input foo foo_inst, input event trig);
always #(trig) begin
$display("%d%d, is a funky number.", foo_inst.x, foo_inst.y);
end
endmodule
module top();
event trig;
foo foo_inst;
mod_A mod_A(.trig, .foo_inst);
mod_B mod_B(.trig, .foo_inst);
endmodule
Of course there're also some functions defined in the class which are used in each module.
The issue with this setup is that I'm seeing errors for each ports of mod_B:
Error-[RIPLIP] Register in low conn of input port
Non-net variable 'foo_inst' cannot be an input or inout port.
Non-net variable 'trig' cannot be an input or inout port.
EDAplayground does not support class objects as module ports and 1800-2012 only mentions interface declarations, events, arrays structures or unions in Port declarations (23.2.2) so my questions are:
Is it even legal to pass classes through ports? If not, what is an elegant
method of accomplishing this?
What does "Register in low conn of
input port" mean? I'm aware that this might be a compiler specific
error and nothing indicative but if I knew what it was trying to tell me I might be a step closer to fixing this.
A variable of any type can be an input or output port. You might have to write for your compiler
input var foo foo_inst,
But it would be better to use a ref when a port is really a handle.
module mod_A(ref foo foo_inst, ref event trig);
Note that you have a typo with foo_o or foo_inst and a race condition between a trigger ->trig and an event control #(trig).