Fix Index Out-of-Bounds Compilation Error in adder_tree.sv

[JacyCui]

Description

The current implementation of adder_tree.sv contains a potential ​​compile-time index out-of-bounds error​​ due to unsafe always_comb logic inside the generate block. When INPUTS_NUM is not a power of two (e.g., 125), the generate loop may attempt to access idata[adder] with adder >= INPUTS_NUM , even if the else branch is logically unreachable.
This violates SystemVerilog's requirement that ​​constant indices must be compile-time valid​​, regardless of runtime conditions.

Current Problematic Code

always_comb begin
    if (adder < INPUTS_NUM) begin
        data[stage][adder][ST_WIDTH-1:0] <= idata[adder][ST_WIDTH-1:0]; // May OOB if adder >= INPUTS_NUM
        data[stage][adder][ODATA_WIDTH-1:ST_WIDTH] <= '0;
    end else begin
        data[stage][adder][ODATA_WIDTH-1:0] <= '0;
    end
end

Proposed Fix

if (adder < INPUTS_NUM) begin
    always_comb begin
        data[stage][adder][ST_WIDTH-1:0] <= idata[adder][ST_WIDTH-1:0];
        // Safe: only generated if adder < INPUTS_NUM
        data[stage][adder][ODATA_WIDTH-1:ST_WIDTH] <= '0;
    end
end else begin
    always_comb begin
        data[stage][adder][ODATA_WIDTH-1:0] <= '0;
    end
end

Impact

• ​​No functional change​​: The logic remains identical.
• ​Compilation safety​​: Eliminates "constant index out of bounds" errors.

[pConst]

Hi! There is no point to fix "potential" and "theoretical" errors.
I suspect your PRs are GPT-generated. If so, please don`t bother me with this shit anymore

[JacyCui]

Hi, thanks for your reply—I truly appreciate your contributions to this project.

I understand your perspective, and I agree that some issues may seem purely theoretical at first glance. That said, Verilog/SystemVerilog is a notoriously complex language, and real-world toolchains often diverge subtly from the spec. In our experience, writing more defensively around constant index expressions improves portability and avoids surprises across different simulators and synthesis tools.

In this particular case, I actually encountered a real compile-time error during development. Our internal toolchain performs stricter static checks and flagged the original code for potential constant index out-of-bounds—even though the branch is unreachable at runtime. The fix in this PR resolved the issue in our setup, which is why I proposed it. Unfortunately, I’m unable to share a reproducible artifact due to internal restrictions.

Lastly, I sincerely apologize if the PR came off as intrusive or annoying—that was never my intention. I simply wanted to share a fix that helped in my own use case.

Thanks again for your time and for maintaining the project.