[chip, gpio, dv] GPIO smoke test by KinzaQamar · Pull Request #382 · lowRISC/mocha

KinzaQamar · 2026-03-26T10:34:41Z

Merge #442 as dependency

This PR added functionality to make the gpio smoketest working on the chip level.

Will close: #147

KinzaQamar · 2026-03-26T10:44:41Z

I forgot that the core files are autogenerated :(( Failing lint

martin-velay

I have some initial comments. It's a very good start though!

KinzaQamar · 2026-04-01T08:43:14Z

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.

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>

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>

Reason being that lowRISC#382 is adding another test which will check if every outputs and inputs can be driven in high/low combinations. That is a much refined definition of a smoke test. The second reason of renaming gpio/smoketest.c to gpio/reg_access_test.c is that the test added in the PR lowRISC#382 is incompatible for Verilator and FPGA tops. This also requires to ask the build system to only make images of GPIO tests for their compatible tops. So, the better approach is to rename the test after their features and add additional options to the build system in order to make their images for different platforms. Signed-off-by: Kinza Qamar <kqzaman@lowrisc.org>

Reason being that #382 is adding another test which will check if every outputs and inputs can be driven in high/low combinations. That is a much refined definition of a smoke test. The second reason of renaming gpio/smoketest.c to gpio/reg_access_test.c is that the test added in the PR #382 is incompatible for Verilator and FPGA tops. This also requires to ask the build system to only make images of GPIO tests for their compatible tops. So, the better approach is to rename the test after their features and add additional options to the build system in order to make their images for different platforms. 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>

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>

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 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>

engdoreis

The Software changes LGTM.

marnovandermaas · 2026-04-16T15:44:03Z

Converting to draft as it depends on #442

engdoreis · 2026-04-16T17:40:32Z

+  // Assignment to the GPIO pads. If dut_gpio_en_o[i] is disabled, then let the gpio_pad[i] float so
+  // an external device/driver can drive it.
+  for (genvar i = 0; i < NUM_GPIOS; i++) begin : gen_gpio_pads
+    assign gpio_pads[i] = dut_gpio_en_o[i] ? dut_gpio_o[i] : 1'bz;


I just bumped into this when trying to make the bootrom boostrap pin to work with dvsim. Is it possible to make the pin 8 high if output enable high rathen then floating?

I guess it is possible, can you explain a bit more the reason in order to document this behavior with an explicit comment

The gpio 8 is now used by the bootrom to decide if it should enter spi bootstrap or jump to the next stage (test). For now we only want to enter spi bootstrap in the FPGA. In sumulation we would load both (rom and test) and skip bootstrap. For that to work we need the gpio 8 to be pulled high during boot.
Maybe it's easier to pull all pin high (that's is what I'm going to do for verilator)?

Kinza showed me the pins_if.sv which already has a pull functionality. Hopefully we can use that and set all the pins to pull up.

Hi @engdoreis,

I've done it for every pin in this commit: fdbe886

I can pull out that commit along with 2b54119 in a separate PR if your work is urgent?

marnovandermaas

Two minor comments.

marnovandermaas · 2026-04-17T15:02:06Z

  clk_rst_if sys_clk_if(.clk(clk), .rst_n(rst_n));
  clk_rst_if peri_clk_if(.clk(peri_clk), .rst_n(peri_rst_n));
  uart_if uart_if();
+  pins_if #(NUM_GPIOS) gpio_if (.pins(gpio_pads));


A bit confusing that gpio_if is the name of pins_if, maybe gpio_pins_if?

marnovandermaas · 2026-04-17T15:21:15Z

+  // Assignment to the GPIO pads. If dut_gpio_en_o[i] is disabled, then let the gpio_pad[i] float so
+  // an external device/driver can drive it.
+  for (genvar i = 0; i < NUM_GPIOS; i++) begin : gen_gpio_pads
+    assign gpio_pads[i] = dut_gpio_en_o[i] ? dut_gpio_o[i] : 1'bz;


Kinza showed me the pins_if.sv which already has a pull functionality. Hopefully we can use that and set all the pins to pull up.

Signed-off-by: Kinza Qamar <kqzaman@lowrisc.org>

This test is supposed to work in pair with UVM and FPGA. Through UVM, we intend to drive the inputs but we can't yet achieve this functionality through verilator and FPGA tops. Thus, ask the build system to skip making verilator and FPGA images to run that test and this is only compatible for a DVSim top now. 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>

…le SW images Signed-off-by: Kinza Qamar <kqzaman@lowrisc.org>

Read the comment added in tb.sv to understand the context. Signed-off-by: Kinza Qamar <kqzaman@lowrisc.org>

GPIO pins are initialized with pulls high to support SW booting process. Disable them once booting is done. Signed-off-by: Kinza Qamar <kqzaman@lowrisc.org>

KinzaQamar requested a review from martin-velay March 26, 2026 10:37

KinzaQamar force-pushed the gpio_smoke branch 3 times, most recently from 7d06a9f to 6ddb362 Compare March 26, 2026 13:52

martin-velay reviewed Mar 26, 2026

View reviewed changes

KinzaQamar force-pushed the gpio_smoke branch 8 times, most recently from d83b568 to 32c5f09 Compare March 30, 2026 15:01

KinzaQamar marked this pull request as ready for review March 30, 2026 15:02

KinzaQamar requested review from elliotb-lowrisc and marnovandermaas March 30, 2026 16:16

KinzaQamar force-pushed the gpio_smoke branch from 32c5f09 to 0b3c095 Compare March 30, 2026 16:30

martin-velay reviewed Mar 31, 2026

View reviewed changes

KinzaQamar commented Mar 31, 2026

View reviewed changes

KinzaQamar force-pushed the gpio_smoke branch 4 times, most recently from 8a5da04 to 93f0c4e Compare March 31, 2026 23:23

martin-velay reviewed Apr 1, 2026

View reviewed changes

KinzaQamar force-pushed the gpio_smoke branch 4 times, most recently from 4534ce8 to 5ade54b Compare April 1, 2026 11:44

KinzaQamar force-pushed the gpio_smoke branch 2 times, most recently from 7dad408 to 44b2ba3 Compare April 11, 2026 11:15

KinzaQamar mentioned this pull request Apr 11, 2026

[chip, gpio, sw] Adding Verilator as an option to .cmake #437

Merged

KinzaQamar marked this pull request as draft April 11, 2026 14:09

KinzaQamar force-pushed the gpio_smoke branch from 44b2ba3 to e276d08 Compare April 11, 2026 14:13

martin-velay reviewed Apr 13, 2026

View reviewed changes

Comment thread sw/device/tests/CMakeLists.txt Outdated

engdoreis reviewed Apr 14, 2026

View reviewed changes

engdoreis reviewed Apr 15, 2026

View reviewed changes

Comment thread sw/device/tests/gpio/smoketest.c

KinzaQamar mentioned this pull request Apr 16, 2026

Update lowrisc_ip to lowRISC/opentitan@7daa08fc83 #442

Open

engdoreis reviewed Apr 16, 2026

View reviewed changes

marnovandermaas reviewed Apr 17, 2026

View reviewed changes

KinzaQamar added 8 commits April 18, 2026 16:39

[chip, gpio, dv] Connected GPIO ports into the tb

2b54119

Signed-off-by: Kinza Qamar <kqzaman@lowrisc.org>

[chip, gpio, dv] Feeded the gpio_vif inside the chip_dv_env

9ca99ad

Signed-off-by: Kinza Qamar <kqzaman@lowrisc.org>

[chip, gpio, dv] Added GPIO smoke vseq

ad02040

Signed-off-by: Kinza Qamar <kqzaman@lowrisc.org>

[chip, gpio, dv] Added a gpio_smoke_cheri entry to run cheri compatib…

1003ad2

…le SW images Signed-off-by: Kinza Qamar <kqzaman@lowrisc.org>

[Chip, gpio, dv] Initialized GPIO pins as pulled high

fdbe886

Read the comment added in tb.sv to understand the context. Signed-off-by: Kinza Qamar <kqzaman@lowrisc.org>

[chip, gpio, dv] Disable pull-ups once SW is in SwTestStatusInTest mode

8e92f59

GPIO pins are initialized with pulls high to support SW booting process. Disable them once booting is done. Signed-off-by: Kinza Qamar <kqzaman@lowrisc.org>

Conversation

KinzaQamar commented Mar 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

KinzaQamar commented Mar 26, 2026

Uh oh!

martin-velay left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

KinzaQamar commented Apr 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

engdoreis left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

marnovandermaas commented Apr 16, 2026

Uh oh!

engdoreis Apr 16, 2026

Choose a reason for hiding this comment

Uh oh!

martin-velay Apr 17, 2026

Choose a reason for hiding this comment

Uh oh!

engdoreis Apr 17, 2026

Choose a reason for hiding this comment

Uh oh!

marnovandermaas Apr 17, 2026

Choose a reason for hiding this comment

Uh oh!

KinzaQamar Apr 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

marnovandermaas left a comment

Choose a reason for hiding this comment

Uh oh!

marnovandermaas Apr 17, 2026

Choose a reason for hiding this comment

Uh oh!

marnovandermaas Apr 17, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

KinzaQamar commented Mar 26, 2026 •

edited

Loading

KinzaQamar commented Apr 1, 2026 •

edited

Loading

KinzaQamar Apr 18, 2026 •

edited

Loading