Synthesis error while using interface parameters

[PWzorek]

Hi

I have come across an issue with Quartus synthesis. As shown in the code below, I have defined a simple `data_stream_i` interface and a simple `demux` module (Demux 1 channels to 2 channels using dest signal for routing). I was trying to use parameters from the input interface (`i_in`) to instance another, internal interface (`i_in_reg`). Unfortunately, the module fails to synthesize - I get `Error(13433): Verilog HDL Defparam Statement error at demux.sv(8): value for parameter "TDATA_T_WIDTH" must be constant expression`. 

I have come to the conclusion that the `i_in_reg` interface can not be created with the `data_t` type, as long as the `TDATA_WIDTH` parameter is assigned to any of the `data_stream_i` interface parameters. 

This error’s cause is described as: “In a Defparam Statement at the specified location in a Verilog Design File (.v), you specified a value for the specified parameter that is not a constant expression. You must specify only constant expressions for parameter values.” (here). However, all values used by me are, in fact, constant. Moreover, this code can be synthesized with Vivado. 

Could you help me with this issue? 

Thank you in advance!

Steps to replicate: 

1. Use `Quartus Prime Pro Edition 20.4.0` with any devices installed
2. Create a new project, add following code to `demux.sv` file.
3. Set `demux.sv` as Top-level Entity
4. Run `Analysis & Synthesis`
   

Used code:

/*
 * Demux 1 channels to 2 channels using dest signal for routing
 */
 
 interface data_stream_i #(
    parameter DATA_WIDTH = 512,
    type TDATA_T = logic [DATA_WIDTH-1:0],
    parameter TDATA_T_WIDTH = $bits(TDATA_T)
) ();
    logic   tvalid;
    logic   tready;
    TDATA_T tdata;

    modport master (
        output tdata,
        input  tready,
        output tvalid
    );

    modport slave (
        input  tdata,
        output tready,
        input  tvalid
    );

endinterface : data_stream_i

 
module demux #()(
    input logic          clk,
    input logic          reset,
    data_stream_i.slave  i_in,
    data_stream_i.master i_out[1:0],
    input logic			 dest
);

    localparam TDATA_WIDTH = i_in.TDATA_T_WIDTH;

	 //Using data_t as TDATA_T type triggers: Error(13433): Verilog HDL Defparam Statement error at axis_demux.sv(8): value for parameter "TDATA_T_WIDTH" must be constant expression 
	 //This is true for: TDATA_WIDTH = i_in.TDATA_T_WIDTH; TDATA_WIDTH = $bits(i_in.TDATA_T); and TDATA_WIDTH = i_in.DATA_WIDTH
	 //Defining TDATA_WIDTH = 512; results in successful synthesis
    typedef struct packed {
        logic [TDATA_WIDTH-1:0] base;
        logic                   dest;
    } data_t;

    data_stream_i #(.TDATA_T(data_t)) i_in_reg();
    logic [1:0] out_reg_tready;

    assign i_in_reg.tvalid  	 = i_in.tvalid;
    assign i_in.tready      	 = out_reg_tready[i_in_reg.tdata.dest];
    assign i_in_reg.tdata.base = i_in.tdata;
    assign i_in_reg.tdata.dest = dest;

    generate
        for (genvar i=0; i < 2; i++) begin : OUTPUT_REG
            assign out_reg_tready[i] = i_out[i].tready;
            assign i_out[i].tvalid 	= i_in_reg.tdata.dest == i ? i_in_reg.tvalid : 1'b0;
            assign i_out[i].tdata  	= i_in_reg.tdata;;
        end
    endgenerate

endmodule : demux

[sstrell]

Did you mean to use "typedef" instead of "type"?

[PWzorek]

No - I did not. "type" is a keyword for TDATA_T parameter.
This module can be synthesized if I pass `512` value to TDATA_WIDTH parameter:

localparam TDATA_WIDTH = 512;

The rest of this code is correct and does not cause any errors..

[RichardTanSY_Intel]

This could be potential bug. I have filed a case to engineering team to check on this. 
Please do expect that any work that involve engineering may takes some time, depending on the issue complexity. 

Best Regards,
Shyan Yew (Richard)

[PWzorek]

Thank you for your response.

Is there any way I could track progress of resolving this issue?

Moreover, could You suggest any workaround for this bug?

Best regards,
Piotr Wzorek

[RichardTanSY_Intel]

Here's the feedback from the engineering team: 

-start-

SystemVerilog 1800-2012 LRM section 23.10.4.1 explains the order of elaboration and it says

"The following algorithm defines an order that produces the correct hierarchy:
a) A list of starting points is initialized with the list of top-level modules.
b) The hierarchy below each starting point is expanded as much as possible
without elaborating generate constructs. All parameters encountered during this
expansion are given their final values by applying initial values, parameter
overrides, and defparam statements."

In this case, the value of parameter in one interface depends on parameter declared in sibling hierarchy (interface). So it is not possible to evaluate such parameter expressions in hier-tree creation process.

Also if you will try the design in VCS and QuestaSim you will see similar errors.

We have a new more advanced hierachy tree flow enables in later builds e.g. 21.1 where we have better and more stricter language standard checks. So that is the reason we slipped this in previous release but erroring it out now.

-end-

Based on the feedback, it seems that this will not be supported in the Quartus, attached the workaround wrote by the engineer though it may not be robust enough. Attached the .zip file with the .sv file in it. 

Let me know if you have further question. 

Best Regards,
Richard Tan

p/s: If any answer from the community or Intel support are helpful, please feel free to give Kudos. 

[PWzorek]

Thank you for your response. You are right about the code I have provided. I was unable to simulate it with QuestaSim as well.

** Error: (vsim-8894) q_bug.sv(37): In instance "demux", parameter reference "i_in.TDATA_T_WIDTH" through interface port "i_in" is not valid when the actual interface in the instance is an arrayed instance element or below a generate construct.

But, all I have to do in order to be in line with SystemVerilog 1800-2012 LRM is to add following top module.

module top(

	input  logic clk,
	input  logic reset,
	input  logic dest,
	input  logic        in_tvalid,
	output logic        in_tready,
	input  logic[511:0] in_tdata,
	
	output logic        out0_tvalid,
	input  logic        out0_tready,
	output logic[511:0] out0_tdata,
	
	output logic        out1_tvalid,
	input  logic        out1_tready,
	output logic[511:0] out1_tdata
);

    data_stream_i in();
    data_stream_i out[1:0]();
	 
	 assign in.tvalid = in_tvalid;
	 assign in.tdata  = in_tdata;
	 assign in_tready = in.tready;
	 
	 assign out0_tvalid   = out[0].tvalid;
	 assign out0_tdata    = out[0].tdata;
	 assign out[0].tready = out0_tready;
	 
	 assign out1_tvalid   = out[1].tvalid;
	 assign out1_tdata    = out[1].tdata;
	 assign out[1].tready = out1_tready;
    
    demux dut(
        .clk   ( clk   ),
        .reset ( reset ),
        .dest  ( dest  ),
        .i_in  ( in    ),
        .i_out ( out   )
    );

endmodule

 Now, this code can be simulated with QuestaSim, but I still get an error with Quartus:

Error(13433): Verilog HDL Defparam Statement error at demux.sv(8): value for parameter "TDATA_T_WIDTH" must be constant expression 

Could you please help me with this issue? Thank you in advance!

Best regards,
Piotr Wzorek

[RichardTanSY_Intel]

Hi Piotr Wzorek, 

The engineering feedback to me that we are already past code complete in 21.2 and may decide to fix this issue in 21.3 or later. 
In other word, you may have to use the workaround provided or wait till the respective Quartus release with the issue fixed.
Will that be alright with you? 

Best Regards,
Richard Tan

p/s: If any answer from the community or Intel support are helpful, please feel free to give Kudos. 

[RichardTanSY_Intel]

Hi Piotr Wzorek, 

This issue will be fixed in Quartus Pro 21.3. While waiting for the respective Quartus release, you may have to use the workaround provided. 
With that, I believe I have answered your question. I will now transition this thread to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.

Best Regards,
Richard Tan

p/s: If any answer from the community or Intel support are helpful, please feel free to give Kudos.