Quartus seems to be having trouble with some parameter values

[alexforencich]

I have not gotten to the bottom of this yet, but Quartus seems to be having trouble with computing the values of some parameters correctly in sv2v generated code.

My original suspicion is that this may have to do with the way sv2v shadows parameters by defining a new parameter with the same name inside of an if (1) block, instead of simply mangling the name. But after manually renaming some of the parameters in question, I didn't see any change in the behavior. The only thing that DID change the behavior was making bogus modifications to the assignments.

Take the following sv2v output, for example:

			localparam CL_DEPTH = 6;
			localparam CL_KEEP_W = 0;
			localparam FIFO_AW = CL_DEPTH;
			localparam OUTPUT_FIFO_AW = 3;
			// snip
			function [FIFO_AW:0] gray2bin;
				input [FIFO_AW:0] g;
				integer i;
				for (i = 0; i <= FIFO_AW; i = i + 1)
					gray2bin[i] = ^(g >> i);
			endfunction

quartus reports the following:

Error (10232): Verilog HDL error at fpga.v(4303): index 1 cannot fall outside the declared range [0:0] for vector "gray2bin" File: ...
Error (10903): Verilog HDL error at fpga.v(4621): failed to elaborate task or function "gray2bin" File: ...

However, if I add a bogus +0 like so, it works:

			localparam CL_DEPTH = 6;
			localparam CL_KEEP_W = 0;
			localparam FIFO_AW = CL_DEPTH+0;
			localparam OUTPUT_FIFO_AW = 3;
			// snip
			function [FIFO_AW:0] gray2bin;
				input [FIFO_AW:0] g;
				integer i;
				for (i = 0; i <= FIFO_AW; i = i + 1)
					gray2bin[i] = ^(g >> i);
			endfunction

There were a couple of other cases of similar behavior. But it doesn't seem to be consistently localparam X = Y; that fails in this way, much of the sv2v generated parameters are in this form and work just fine.

[zachjs]

It's not obvious to me what's wrong with this output. For example, this isn't the same "technically illegal" pattern discussed in #298. This is another case where I wonder if the downstream tool has a straightforward bug.

Do you think it would be possible to pass the sv2v output through Yosys for further elaboration, and then back to Verilog with write_verilog? With any luck, this might remove some of the (perfectly valid) constructs giving those downstream tools trouble.

[alexforencich]

Yeah, I agree that this smells like some sort of Quartus tool bug particularly since the behavior doesn't seem very consistent. I'm not familiar with yosys, but that might be an interesting option to try. I suppose a potential problem is that the more the code gets re-processed, the harder it is to debug and constrain the resulting code.