Draft
Conversation
Author
|
I forgot that the core files are autogenerated :(( Failing lint |
KinzaQamar
force-pushed
the
gpio_smoke
branch
3 times, most recently
from
7d06a9f to
6ddb362
Compare
Contributor
martin-velay
left a comment
martin-velay
left a comment
There was a problem hiding this comment.
I have some initial comments. It's a very good start though!
hw/vendor/lowrisc_ip/ip_templates/gpio/dv/env/gpio_env.core.tpl
Outdated
Show resolved
Hide resolved
KinzaQamar
force-pushed
the
gpio_smoke
branch
8 times, most recently
from
d83b568 to
32c5f09
Compare
KinzaQamar
commented
Mar 31, 2026
hw/vendor/lowrisc_ip/ip_templates/gpio/dv/env/gpio_env.core.tpl
Outdated
Show resolved
Hide resolved
KinzaQamar
force-pushed
the
gpio_smoke
branch
4 times, most recently
from
8a5da04 to
93f0c4e
Compare
Author
|
HI @martin, Thanks for the detailed review. I realized yesterday that the comments I added in the test and vseq were way more difficult and I spent some time making it a bit easier to understanding. Do you mind take another look? Some of your comments are unresolved because either I asked for a go-ahead or a question in replies. |
martin-velay
reviewed
Apr 1, 2026
hw/vendor/lowrisc_ip/ip_templates/gpio/dv/env/gpio_env.core.tpl
Outdated
Show resolved
Hide resolved
KinzaQamar
force-pushed
the
gpio_smoke
branch
4 times, most recently
from
4534ce8 to
5ade54b
Compare
KinzaQamar
force-pushed
the
gpio_smoke
branch
2 times, most recently
from
9720343 to
e672964
Compare
engdoreis
reviewed
Apr 9, 2026
sw/cmake/tests.cmake
Outdated
Collaborator
There was a problem hiding this comment.
Suggested change
| set(options FPGA SIM_VERILATOR) |
engdoreis
reviewed
Apr 9, 2026
| # create artefacts | ||
| mocha_add_executable_artefacts(${NAME}) | ||
|
|
||
| if(SIM) |
Collaborator
There was a problem hiding this comment.
Suggested change
| if(SIM) | |
| if(SIM AND arg_SIM_VERILATOR) |
engdoreis
reviewed
Apr 9, 2026
sw/device/tests/CMakeLists.txt
Outdated
| @@ -6,14 +6,14 @@ set(LIBS hal runtime startup test_framework) | |||
|
|
|||
| mocha_add_test(NAME test_framework_test SOURCES test_framework/smoketest.c LIBRARIES ${LIBS} FPGA) | |||
Collaborator
There was a problem hiding this comment.
The same for the other tests below. Except the one that can't run in verilator.
Suggested change
| mocha_add_test(NAME test_framework_test SOURCES test_framework/smoketest.c LIBRARIES ${LIBS} FPGA) | |
| mocha_add_test(NAME test_framework_test SOURCES test_framework/smoketest.c LIBRARIES ${LIBS} FPGA SIM_VERILATOR) |
KinzaQamar
force-pushed
the
gpio_smoke
branch
2 times, most recently
from
1231460 to
4a50beb
Compare
KinzaQamar
added a commit
to KinzaQamar/mocha
that referenced
this pull request
Apr 9, 2026
The motivation of this PR comes from lowRISC#382 which is adding a chip level GPIO test for Xcelium. That test fails on verilator. The reason being different tops used for both of the tools. For Xcelium, an interface is connecting the UVM to the GPIO. The UVM have the control to drive GPIOs inputs. In lowRISC#382, the SW waits for a specific pattern driven by UVM to appear in `data_in` reg. If we run the exact test with the verilator top, which is using GPIO DPI, then the abilty to drive the inputs depends on a host SW infrastructure which is currently missing. With the above context, the best way forward is to separate the GPIO smoketest for both of the simulators for now to make the CI happy. Signed-off-by: Kinza Qamar <kqzaman@lowrisc.org>
KinzaQamar
added a commit
to KinzaQamar/mocha
that referenced
this pull request
Apr 11, 2026
The motivation of this PR comes from lowRISC#382 which is adding a chip level GPIO test for Xcelium. That test fails on verilator. The reason being different tops used for both of the tools. For Xcelium, an interface is connecting the UVM to the GPIO. The UVM have the control to drive GPIOs inputs. In lowRISC#382, the SW waits for a specific pattern driven by UVM to appear in `data_in` reg. If we run the exact test with the verilator top, which is using GPIO DPI, then the abilty to drive the inputs depends on a host SW infrastructure which is currently missing. With the above context, the best way forward is to separate the GPIO smoketest for both of the simulators for now to make the CI happy. Signed-off-by: Kinza Qamar <kqzaman@lowrisc.org>
KinzaQamar
added a commit
to KinzaQamar/mocha
that referenced
this pull request
Apr 11, 2026
The motivation of this PR comes from lowRISC#382 which is adding a chip level GPIO test for Xcelium. That test fails on verilator. The reason being different tops used for both of the tools. For Xcelium, an interface is connecting the UVM to the GPIO. The UVM have the control to drive GPIOs inputs. In lowRISC#382, the SW waits for a specific pattern driven by UVM to appear in `data_in` reg. If we run the exact test with the verilator top, which is using GPIO DPI, then the abilty to drive the inputs depends on a host SW infrastructure which is currently missing. With the above context, the best way forward is to separate the GPIO smoketest for both of the simulators for now to make the CI happy. Signed-off-by: Kinza Qamar <kqzaman@lowrisc.org>
KinzaQamar
added a commit
to KinzaQamar/mocha
that referenced
this pull request
Apr 11, 2026
The motivation of this PR comes from lowRISC#382 which is adding a chip level GPIO test for Xcelium. That test fails on verilator. The reason being different tops used for both of the tools. For Xcelium, an interface is connecting the UVM to the GPIO. The UVM have the control to drive GPIOs inputs. In lowRISC#382, the SW waits for a specific pattern driven by UVM to appear in `data_in` reg. If we run the exact test with the verilator top, which is using GPIO DPI, then the abilty to drive the inputs depends on a host SW infrastructure which is currently missing. With the above context, the best way forward is to separate the GPIO smoketest for both of the simulators for now to make the CI happy. Signed-off-by: Kinza Qamar <kqzaman@lowrisc.org>
KinzaQamar
force-pushed
the
gpio_smoke
branch
2 times, most recently
from
7dad408 to
44b2ba3
Compare
Signed-off-by: Kinza Qamar <kqzaman@lowrisc.org>
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 lowRISC#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. Signed-off-by: Kinza Qamar <kqzaman@lowrisc.org>
It is going to be useful in order to import GPIO related parameters in tb.sv Signed-off-by: Kinza Qamar <kqzaman@lowrisc.org>
Signed-off-by: Kinza Qamar <kqzaman@lowrisc.org>
Signed-off-by: Kinza Qamar <kqzaman@lowrisc.org>
Signed-off-by: Kinza Qamar <kqzaman@lowrisc.org>
Since we are using UVM, we have the control to drive the GPIOs inputs and hence can wait in SW for the driven pattern to appear. This will hang forever in case of verilator top. That is why two tests are required to be able to work on their corresponding top. For more context: visit lowRISC#406. Signed-off-by: Kinza Qamar <kqzaman@lowrisc.org>
Both SW and vseq works in pairs. The SW drives the pins in outputs and set each pin in walking 1's fashion and waits for the pattern driven by vseq. The vseq once seen all the W1's pattern on each pin will then drive a pattern on GPIO inputs and SW waits for that pattern by reading `data_in` reg. Signed-off-by: Kinza Qamar <kqzaman@lowrisc.org>
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
5 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 and #437 as dependencies
This PR added functionality to make the gpio smoketest working on the chip level.
Will close: #147