03-13-2019 03:45 AM
I'm trying to read parameters from a parameterized interface, but have run into some issues. As others have noted in similar forum posts, some methods of accessing interface parameters result in a compilation error. However I have found at least two cases in which the interface parameter access does *not* cause a compilation error, but instead seems to yield the wrong value without a warning.
In order to recreate the issue, please place the attached files "top.v" and "project.tcl" in the same folder and issue the shell command: vivado -mode batch -source project.tcl (For reference, I'm using Vivado 2018.2). There are two distinct tests with the same result; "Test 1" is uncommented by default but "Test 2" can be run by commenting out line 23 and uncommenting line 26.
The result is that an interface parameter that has been set to a non-default value will be read back as its default value when the interface parameter is used in defining a localparam or parameter value. As a further detail, this only seems to happen when the interface is passed into the submodule that is reading the interface parameter value.
With that in mind, I wondered if this is the expected behavior or if it is a bug? In addition, I would like to know if there is a way to read interface parameters correctly in submodules that is supported for both simulation and synthesis.
03-13-2019 03:47 AM
Note: please use the project.tcl file that references "top.v", not "top.sv". For some reason I was not able to attach the original *.sv file.
09-02-2019 02:27 PM
I've just been banging my head against this issue. It seems you can work around it by wrapping the body of the module in generate/endgenerate.
If anyone from Xilinx wants a test case for this bug:
interface A #(parameter int X = 1) (); endinterface module B #(parameter int Y = 1); endmodule module C (A ain); generate localparam int Z1 = ain.X; B #(ain.X) b1(); endgenerate endmodule module D (A ain); localparam int Z2 = ain.X; B #(ain.X) b2(); endmodule module top (); A #(2) a1(); C c1(.ain(a1)); D d1(.ain(a1)); endmodule
On 2019.1 I get a1.X = 2, c1.Z1 = 2, c1.b1.Y = 2, d1.Z2 = 1, d1.b2.Y = 1. So module C works as expected and module D doesn't. In systemverilog the generate block is supposed to be optional and have no effect.
In my actual code I'm also seeing a case where Z = 2 and b.Y = 1, i.e. I get different behaviour with localparam vs module parameter, but I can't reproduce that in this simple test case. Maybe it needs more layers of hierarchy, or only happens when each part is in its own file or something.