[chip, gpio, dv] Renaming GPIO's smoketest.c to reg_access_test.c

[KinzaQamar]

Merge this PR first as a dependency on #382

The motivation of this PR comes from #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 #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.

Renaming the gpio/smoketest.c to gpio/reg_access_test.c

[martin-velay]

I am unsure about this modification, as the mocha_add_test will call this other macro mocha_add_verilator_test and thus create a test with _sim_verilator suffix.

@engdoreis, how to handle this kind of situation?

[KinzaQamar]

Hi Martin,

My idea was to create another gpio_smoketest_xcelium and ask the build system to stop making FPGA and Verialtor images if the target name contains xcelium in it. So, we don't get gpio_smoketest_xcelium_sim_verilator. I am not sure if there is a better way to doing thing but that is making the CI happy on #382

[engdoreis]

In my understanding this test can run in any platform (FPGA, VERILATOR and DV_SIM) right? So, we should not name it after verilator.

I suggest keeping this tests exactly the same. Then copy it to another file, extend it with the features that's create another test only supported by DV_SIM (xcelium), then name it <feature_tested>.c, then adapt cmake to mark this new test as not runnable in verilator.

Does that make sense?