HDL Coder generated Verilog code for 2-D LUT block propogates X in Vivado Simulator

When generating HDL code with HDL Coder for a 2-D Look Up Table block, I observed different behavior between VHDL and Verilog for the same lookup table access:

• In VHDL, the generated code uses

to_integer(add_cast + resize(mul_temp, 32))

which ensures that everything is resized into a 32-bit signed domain, producing a deterministic index.

• In Verilog, however, the generated code was:

$signed({1'b0, prelookup_idx}) + alpha2_D_Lookup_Table_mul_temp_2

Here, prelookup_idx is only 2 bits, while mul_temp_2 is 35 bits signed. The result is a 35-bit signed expression, and if any bit in the operands propagates X, the whole lookup table output becomes X in Vivado simulator.

Solution

To mimic the VHDL resize behavior, the Verilog code needs explicit truncation and casting:

wire signed [31:0] add_cast_2 = $signed({{30{1'b0}}, prelookup_idx});
wire signed [31:0] mul_temp_2_resized = alpha2_D_Lookup_Table_mul_temp_2[31:0];
wire signed [31:0] idx2 = add_cast_2 + mul_temp_2_resized;

assign alpha2_D_Lookup_Table_tableout3 = alpha2_D_Lookup_Table_7[idx2[5:0]];

With this change:

• The 35-bit value is truncated to 32 bits (matching the VHDL resize).
• The addition is performed in a 32-bit signed domain.
• The X propagation issue in Verilog simulation disappears.

Conclusion

There is a subtle difference between HDL Coder’s VHDL and Verilog backends regarding resize handling.

• VHDL always produces a deterministic integer with resize + to_integer.
• Verilog can leave the expression at a wider signed width, which increases the chance of X propagation.

Explicit truncation/casting in Verilog aligns its behavior with VHDL and resolves the simulation mismatch.

HDL Coder version is 25.1.

Answer 1

[Kiran Kintali]

Could you please share the sample model?

The input types and block parameters are essential for generating HDL code.

Additionally, the testbench surrounding the subsystem shown in the image helps reproduce the simulation behavior, making it easier to validate the design.

[albs975]

Hi. The code is generated from Jacobi SVD Optimized for HDL example. I will attach the generated original code and updated version by me. Relative hierarchy under example model is included in the codes. Thanks.

Answer 2

[Kiran Kintali]

Could you please share your test model along with the version of MATLAB you are using?

We tested with R2025b using the attached model (types selected based on your HDL code), but we did not observe any 'X' propagation in the generated code or testbench using HDL Coder.

[albs975]

Hi. I generated design and testbench Verilog codes with provided model with MATLAB R2025b. Exact same problem can be seen during Vivado behavioral simulation. The below figure original codes shows X propagation situation. Figure 2 shows updated code's results. X's are gone. Maybe a simulator issue. Did you do your simulation in Vivado?

Figure 1: original code, X propagation in Out1_2

Figure 2: updated code, X propagation gone in Out1_2

I'm attaching 2 Vivado projects folders that include design and simulation code files. Vivado version is v2025.1.

[Kiran Kintali]

We have used QuestaSim/ModelSim to verify the standalone functionality of the 2D LUT block. The generated HDL code and testbench from HDL Coder are consistent and behave as expected. Next, we will evaluate the design using Vivado Simulator and share our findings if we find any issues.

[albs975]

Hi. Is there any progress?

[Kiran Kintali]

Thank you for the follow-up. We’ve confirmed that a technical support case has been raised regarding this issue. The MathWorks Support Team will respond directly, and we’ll continue to follow up with you to ensure it’s resolved. The issues here involves AMD Vivado Simulator that needs additional investigation.