Including bsg_dff_chain.sv into a Lakeroad integration test causes test failure

[cknizek]

Including the file bsg_dff_chain.sv from BaseJump STL in a Lakeroad integration test can cause it to fail. I want to clarify that this failure is independent of any usage of bsg_dff_chain.sv itself within the integration test file. That is, simply including bsg_dff_chain.sv into an integration test will cause a test to fail.

To reproduce this issue:

1. Add the file bsg_dff_chain.sv to the local directory of an integration test
2. Add the file bsg_defines.sv to the local directory of an integration test
3. Insert the line "include bsg_dff_chain.sv" at the top of the file, after the section of Lakeroad // RUN: statements
4. In the top-level directory, run the command docker build -t lakeroad .
5. Once the Docker build is finished, run the command docker run lakeroad

After running the above steps, I receive the following terminal output [1].

In the example of [1], I include the statement into a known working file example_test_using_include.v. This file passes when no modifications are made.

When this file is modified by including the line "include bsg_defines.sv", it still passes.

When the file is modified by adding the line "include bsg_dff_chain.sv", the integration test consistently fails. I've produced this on other randomly selected, known working files (e.g. one_stage_mul_or_lattice.v or intel_cyclone10lp_mul_0_stage_unsigned_18_bit.v).

I'm still trying to figure out what's going on, but it seems like this might be related to the issue with module boundaries.

I think this issue occurs because (from what I've gathered), inserting an include statement in Verilog/SystemVerilog will basically copy + paste the contents of the included file directly into the file where the include statement exists.

And so, if there is an existing issue with multiple modules within the same file, it might cause conflict between the modules (and cause test failure).

The reason my PR was passing locally was likely because I was setting up the test incorrectly (i.e. using lit -v bsg_mul_add_unsigned.sv instead of re-building the Docker container and running it from there).

I think the solution to this issue would be to either figure out why this is failing (is it multiple modules within the same file?) and either:

• A) Modify Lakeroad to fix the issue
• B) Modify bsg_dff_chain.sv (and possibly other BaseJump STL files) to fix the issue (make them compatible with Lakeroad)

[1]

******************** TEST 'Lakeroad tests :: example_test_using_include.v' FAILED ********************
Script:
--
: 'RUN: at line 1'; outfile=$(mktemp)
: 'RUN: at line 2'; racket $LAKEROAD_DIR/bin/main.rkt --solver bitwuzla --verilog-module-filepath /root/lakeroad/integration_tests/lakeroad/example_test_using_include.v --architecture xilinx-ultrascale-plus --template dsp --out-format verilog --top-module-name combinational_multiplier --verilog-module-out-signal p:16 --pipeline-depth 0 --module-name out --input-signal a:16 --input-signal b:16 --timeout 90 > $outfile
: 'RUN: at line 16'; FileCheck /root/lakeroad/integration_tests/lakeroad/example_test_using_include.v < $outfile
: 'RUN: at line 17'; if [ -z ${LAKEROAD_PRIVATE_DIR+x} ]; then echo "Warning: LAKEROAD_PRIVATE_DIR is not set. Skipping simulation."; exit 0; else python3 $LAKEROAD_DIR/bin/simulate_with_verilator.py --test_module_name out --ground_truth_module_name combinational_multiplier --max_num_tests=10000 --verilog_filepath $outfile --verilog_filepath /root/lakeroad/integration_tests/lakeroad/example_test_using_include.v --pipeline_depth 1 --output_signal p:16 --input_signal a:16 --input_signal b:16 --verilator_include_dir "$LAKEROAD_PRIVATE_DIR/DSP48E2/" --verilator_extra_arg='-DXIL_XECLIB' --verilator_extra_arg='-Wno-UNOPTFLAT' --verilator_extra_arg='-Wno-LATCH' --verilator_extra_arg='-Wno-WIDTH' --verilator_extra_arg='-Wno-STMTDLY' --verilator_extra_arg='-Wno-CASEX' --verilator_extra_arg='-Wno-TIMESCALEMOD' --verilator_extra_arg='-Wno-PINMISSING'; fi
--
Exit Code: 1`

[gussmith23]

This is caused at least partly by not having a --top-module flag being passed to Verilator. Verilator is throwing a multiple top modules warning, causing an error. We can just statically pass --top-module testbench.

[gussmith23]

@cknizek you can add --top-module testbench to verilator.mk.template?

[cknizek]

@cknizek you can add --top-module testbench to verilator.mk.template?

Done!