Range must be bounded by constant expressions

[stackprogramer]

When I want to develop a Verilog code, I am faced with errors can anyone help? Any Idea or offer?

integer low_index,high_index;
    always @(posedge clk) begin
      //Save samples in samples buffer
      low_index=m+0;
      high_index=m+31;
      data_samples_i_buffer[high_index:low_index]=config_tdata[31:0];
      data_samples_i_buffer[63+m:32+m]=config_tdata[63:31];
      if(m==96) begin
      {
        m=0;
      }
      end else begin
      {
        m=m+32;
      }
      end
end

Errors:

ERROR: [VRFC 10-2951] 'high_index' is not a constant [/home/sp/correlate.vh:35]
ERROR: [VRFC 10-1775] range must be bounded by constant expressions [/home/sp/rfnoc_block_correlate/correlate.vh:35]
ERROR: [VRFC 10-2951] 'm' is not a constant [/home/sp/correlate.vh:36]
ERROR: [VRFC 10-1775] range must be bounded by constant expressions [/home/sp/correlate.vh:36]

 

[FlyingDutch]

Hello,

see this link:

How to use const in verilog

Instead of using module ... ( .. ) ; #15 endmodule I want use module ... ( ... ) ; // GateDelay is a const, like in c language const int GateDelay = 15 ; # GateDelay endmodule...

stackoverflow.com

Best Regards

 

[FvM]

The error message is reminding you to write Verilog in accordance with the language specification.

You can e.g. write a loop

for (int i=0;i<32;i++)
      data_samples_i_buffer[i+m]=config_tdata[i];

--- Updated Apr 20, 2022 ---

Alternatively the variable indexing can be performed with indexed part-select syntax.

data_samples_i_buffer[m +: 0]=config_tdata[31:0];

 

[ads-ee]

@FvM neither of your suggestions will work as m is a variable and at compile time the range in a slice must be a constant.

Indexed ranges can work if the index is defined at compile time, i.e. defined to a constant value in a for loop.
e.g. for (int i=0; i<3;i=i+1) data[32*i +:32] <= config_data[31:0];
Note: i++ will only work if compiled with SV
use non-blocking (<=) in all edge triggered always blocks, i.e. always @(posedge ....
use blocking (=) in combinational always blocks, i.e. always @(*) or always @(sig1, sig2...

@stackprogramer your code looks way to much like a software implementation of what you are attempting to do. You need to drop your software programming paradigm and think logic design. Translate that logic design into Verilog code that describes those logic elements.

See http://asic-world.com/examples/verilog/index.html to see templates for various logic elements and how they are coded in Verilog.

If you really need to have a variable index into a vector then you will likely need a multiplexer and demultiplexer to do what you want. This is where drawing what you want to do helps determine how the logic is designed.

 

[FvM]

Please review Verilog LRM

An indexed part-select is given with the following syntax:

logic [15:0] down_vect;
logic [0:15] up_vect;
down_vect[lsb_base_expr +: width_expr]
up_vect[msb_base_expr +: width_expr]
down_vect[msb_base_expr -: width_expr]
up_vect[lsb_base_expr -: width_expr]

The msb_base_expr and lsb_base_expr shall be integer expressions, and the width_expr shall be a positive constant integer expression. Each of these expressions shall be evaluated in a self-determined context. The lsb_base_expr and msb_base_expr can vary at run time.

Obviously indexed part-select is a method to infer mux/demux logic. Also the simple bit select can vary at run time.

I agree with the additional comments.

--- Updated Apr 21, 2022 ---

@stackprogramer your code looks way to much like a software implementation of what you are attempting to do. You need to drop your software programming paradigm and think logic design. Translate that logic design into Verilog code that describes those logic elements.

The original problem of this thread is syntax related and can be solved by correcting the Verilog syntax.

Which problems are involved when you write HDL code in a "software programming" style?
- the synthesis result can be ineffective (consuming more logic resources, not running at intended clock speed)
- the code can be hard to read, either not clearly show the function and/or the expected hardware implementation

I'd however like to make a reservation. While logic complexity increases, the logic design paradigm may become less productive. At a certain degree of complexity, high level features like behavioral logic description or structured variable definitions are increasingly effective, although or even because they abstract from the synthesis result. The code looks more software-like but quite different from HDL misunderstood as sequential programming language.