[chip, gpio, sw] Adding Verilator as an option to .cmake#437
Merged
KinzaQamar merged 1 commit intolowRISC:mainfrom Apr 13, 2026
Merged
[chip, gpio, sw] Adding Verilator as an option to .cmake#437KinzaQamar merged 1 commit intolowRISC:mainfrom
KinzaQamar merged 1 commit intolowRISC:mainfrom
Conversation
KinzaQamar
force-pushed
the
cmake_verilator_option
branch
from
c480d17 to
658caeb
Compare
KinzaQamar
force-pushed
the
cmake_verilator_option
branch
from
658caeb to
1dca8c3
Compare
KinzaQamar
force-pushed
the
cmake_verilator_option
branch
from
1dca8c3 to
a94ab48
Compare
The motivation of this PR comes from lowRISC#382 which is adding a chip level GPIO smoke test. That test fails on verilator. Reason being different tops used for different platforms (DVSim(Xcelium), Verilator, FPGA). For Xcelium, an interface is connecting the UVM to the GPIO. UVM has the control to drive GPIOs inputs. In 382, SW waits for a specific pattern driven by UVM to arrive in data_in reg. If we run the exacttest with the verilator top, which is using GPIO DPI, then the abilty to drive inputs depends on a host SW infrastructure which is currently missing. Second problem is that we use cmake to build software images for DVSim, verilator and FPGA. We run tests on FPGA and Verilator in CI. If the build system develops an Xcelium compatible image and feed that image to Verilator and FPGA to execute the test in CI then the test will fail due to the reason given in the first paragraph. Hence, the best way forward is to make images only for the compatible plaforms. Signed-off-by: Kinza Qamar <kqzaman@lowrisc.org>
KinzaQamar
force-pushed
the
cmake_verilator_option
branch
from
a94ab48 to
9bd5b90
Compare
engdoreis
approved these changes
Apr 13, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Merge 406 first as a dependency
The motivation of this PR comes from 382 which is adding a chip level GPIO smoke test. That test fails on verilator. Reason being different tops used for different platforms ( DVSim(Xcelium), Verilator, FPGA). For Xcelium, an interface is connecting the UVM to the GPIO. UVM has the control to drive GPIOs inputs. In 382, SW waits for a specific pattern driven by UVM to arrive in data_in reg. If we run the exact test with the verilator top, which is using GPIO DPI, then the abilty to drive inputs depends on a host SW infrastructure which is currently missing.
Second problem is that we use cmake to build software images for DVSim, verilator and FPGA. We run tests on FPGA and Verilator in CI. If the build system develops an Xcelium compatible image and feed that image to Verilator and FPGA
to execute the test in CI then the test will fail due to the reason given in the first paragraph.
Hence, the best way forward is to make images only for the compatible paltforms.