Issue #405
generate-conditional always succeeds
| Status: | Closed | Start date: | 10/26/2011 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | Wilson Snyder | % Done: | 0% |
|
| Category: | Unsupported | |||
| Target version: | - |
Description
The tests in a generate conditional block always appear to succeed. The attached example modulegen.v contains two such conditional blocks, only the first of which should be generated. In fact both are generated, leading to an error due to a missing module.
module foobar
#( parameter
FOO_START = 0,
FOO_NUM = 2,
FOO_TYPE = 0 // This means we should instatiate foo0
)
(
input wire[FOO_NUM-1:0] foo,
output wire[FOO_NUM-1:0] bar);
generate
begin: g
genvar j;
for (j = FOO_START; j < FOO_NUM+FOO_START; j = j + 1)
begin: foo_inst;
if (FOO_TYPE == 0)
begin: foo_0
// instatiate foo0
foo0 i_foo(.x(foo[j]), .y(bar[j]));
end
if (FOO_TYPE == 1)
begin: foo_1
// instatiate foo1
foo1 i_foo(.x(foo[j]), .y(bar[j]));
end
end // block: foo_inst;
end // block: g
endgenerate
endmodule // foobar
module foo0(input wire x, output wire y);
assign y = ~x;
endmodule
We build with verilator:
verilator -cc --language 1364-2001 --top-module foobar modulegen.v
The error message is:
$ verilator -cc --language 1364-2001 --top-module foobar modulegen.v %Error: modulegen.v:31: Cannot find file containing module: foo1 %Error: modulegen.v:31: Looked in: %Error: modulegen.v:31: foo1 %Error: modulegen.v:31: foo1.v %Error: modulegen.v:31: foo1.sv %Error: modulegen.v:31: obj_dir/foo1 %Error: modulegen.v:31: obj_dir/foo1.v %Error: modulegen.v:31: obj_dir/foo1.sv %Error: Exiting due to 8 warning(s) %Error: Command Failed $VERILATOR_ROOT/verilator_bin -cc --language 1364-2001 --top-module foobar modulegen.v
This shows that the second conditional block has been generated, which it should not, because FOO_TYPE is 0.
Found with Verilator 3.824.
History
Updated by Wilson Snyder over 1 year ago
- Category set to Unsupported
- Status changed from New to Feature
It doesn't always succeed, it just requires the other module to be resolvable and parseable, but will not use the code inside it. For example, having a "module foo1; endmodule" is sufficient, it won't complain about the pins mismatching as the instantiation is not done.
I believe this is compliant with the spec. One possibility would to be to delay module reading until the if completes, but this cannot be easily changed without requiring all of the filenames to be listed on the command line. (Which is how at least two other simulators get around the problem, but a method I despise on usability grounds.) Another possibility is to delay the not found error until it's determined that the module is really needed, which is probably not too bad.
Updated by Wilson Snyder over 1 year ago
P.S. if you could provide examples in verilator test format (see BUGS in the docs) it would be helpful, and I think it will make your running it easier for you too, thanks!
Updated by Wilson Snyder over 1 year ago
Actually I tried an experiment and the pins do need to match up, as it does the interconnection linting before parameter trimming. Perhaps a misfeature.
Updated by Wilson Snyder over 1 year ago
- Status changed from Feature to Resolved
- Assignee set to Wilson Snyder
It now reports missing module after parameters are resolved. This isn't perfect, but was easy.
In git towards 3.825.
Also available in: Atom
![[logo]](/img/veripool_small.png)