Calculating width of input port in Verilog module

[HerrNamenlos123]

I want to create a Verilog module which can be parameterized, but the width of the input port must be calculated at compile time. I'm using Intel Quartus Prime Lite 20.1.

I want it to be exactly like this LPM_CLSHIFT block:

Here data's width is specified and distance's width is calculated with CEIL(LOG2(LPM_WIDTH)), no matter what value you enter.

I tried it like this, but when creating the symbol files it complains that iADDRESS has unsupported type:

module MyModule #(
    parameter NUMBER_OF_REGISTERS = 8
) (
    iADDRESS
);

localparam ADDRESS_WIDTH = $clog2(NUMBER_OF_REGISTERS);
input [ADDRESS_WIDTH-1:0] iADDRESS;

//...

endmodule

I also tried it like this but here it complains that ADDRESS_WIDTH must be a number:

module MyModule #(
    parameter NUMBER_OF_REGISTERS = 8,
    parameter ADDRESS_WIDTH = $clog2(NUMBER_OF_REGISTERS)
) (
    input [ADDRESS_WIDTH-1:0] iADDRESS
    // ...
);

//...

endmodule

The formula $clog2(NUMBER_OF_REGISTERS) works fine when using it on a wire or reg, which is internal to the module. However, as soon as this wire is attached to an input, the symbol file creation fails.

Both methods from above compile fine when instantiated in Verilog, but i need to create symbol files and instantiate it in a block design file. I also noticed that in LPM_CLSHIFT the data width is not specified in the symbol.

How can i do this myself?

[SyafieqS]

Herr,

Are you able to work on this?

[HerrNamenlos123]

No,

I found a workaround which works for my case. Since i do not strictly need the port with dynamic width at the very top i hid it in another verilog file. That way i implemented all the logic and width calculations in verilog and then wrapped it in another block design file which doesn't have the dynamic width port exposed. Its ports are all derived straight-forward from the parameters and the ports with the width calculated at compile time are all hidden within verilog.

Nevertheless I would still like to know if it's possible since this workaround only works if the dynamic port does not need to be exposed.

[SyafieqS]

Herr,

The workaround is possible since you are able to pass the flow otherwise it would the other way around.