Forum Discussion
Kocsonya
New Member
22 hours agoTypedef inheritance in nested modules
Sorry for the formatting, but for some reason proper switching between paragraph and preformatted does not work.
I have an interface, which contains a structure, which, in turn, contains a parametrised width vector:
interface myif
#(
parameter int W = 1
)();
typedef struct packed
{
logic one;
logic [W-1:0] many;
} MYSTRUCT;
MYSTRUCT x;
modport src ( output x );
modport dst ( input x );
endinterface
Now, there is a module which gets this interface. It needs to work with the data defined in the interface, so it needs to extract the structure definition (note that everything here is simplified to absolute bare bones). Easy enough:
module my_outer_module
(
myif.dst dest
);
// Extract the typedef from the port
typedef dest.MYSTRUCT MYSTRUCT;
...
// other stuff
...
// here will be a nested module, described below
...
endmodule
So far so good, the entity that instantiates my_outer_module also instantiates the interface, with whatever W parameter value it deems necessary and my_outer_module will use the correct MYSTRUCT definition, even though W has not been passed to it
.
Furthermore, if my_outer_module contains a nested module, as per SystemVerilog rules, it can refer to all types and parameters in the enclosing scope, so it will also be able to use MYSTRUCT without further ado.
And, indeed, this works:
module my_nested_module
(
... some signals in and out ...
);
MYSTRUCT some_variable;
...
endmodule
However, if the typedef is used in the module port definition, Quartus Pro 24.1 spits the dummy:
module my_nested_module
(
input MYSTRUCT going_in,
output MYSTRUCT coming_out
);
assign coming_out = going_in;
endmodule
Quartus complains about undefined net type for both going_in and coming_out.
How come?
Help with this particular issue would be appreciated. I know that there are other ways of passing types to modules. There are reasons why I try to solve the problem this particular way and not through packages or macro trickery or anything else.
I am looking for an explanation why Quartus reports an error on, I believe, perfectly valid SV source. I know that the simulator is a very different animal, but it accepts the code without a pip, and it works as expected.
Thanks in advance.
Interesting addendum: using old (non-ANSI) style module declaration makes Quartus happy. Which makes the whole thing more intriguing. This is accepted:
module my_nested_module ( going_in, coming_out );
input MYSTRUCT going_in;
output MYSTRUCT coming_out;
assign coming_out = going_in;
endmodule
So Quartus clearly understands the concept of using a structure defined in the enclosing scope as the type of a port, but refuses to remember how to do it while processing an ANSI style module header.
No RepliesBe the first to reply