[hw,dv,sw] Add support for HW_ID for SW

[martin-velay]

• Related to issue [DV infra] Extend the dv_window register to support querying the platform #423
• This commit adds support for a HW_ID register that can be used by SW DV tests to identify the hardware they are running on. This is useful for SW DV tests that need to run on multiple hardware platforms and need a way to differentiate between them.

[engdoreis]

Thanks for working on this, can you read the HW_ID in the test_framework and print it as test?

[marnovandermaas]

We should also have an ID for the FPGA platform.

[martin-velay]

@marnovandermaas, about:

We should also have an ID for the FPGA platform.

I am unsure how this can be implemented for the FPGA platform. Maybe I can add something similar as done for Verilator?

[martin-velay]

@engdoreis

I have tested, and indeed there was an issue. Now I can see this in the trace_hart_0.log:

547633ns    27228 M 00000000100016e6 0 00056603 lwu            a2, 0(a0)             a2  :000000000000002a a0  :0000000020020008 VA: 0000000020020008 PA: 00000020020008

With this patch: diff_sw_dv_hw_id.patch

[martin-velay]

I have added similar thing for the FPGA via an "AXI sink". I have never done any FPGA, can I have guidance on how I can verify it works?

[engdoreis]

I'm sorry for accidentally closing the PR,

[elliotb-lowrisc]

I'm a bit concerned that the current changes are affecting the Mocha RTL despite this being for DV purposes. In particular, I think the strange range of the 'rest of chip' entry could make the AXI crossbar harder for the tool to implement (possibly affecting timing/area/performance). I'd like to see a before/after pair of FPGA bitstream builds to check if the impact is negligible or not.

[martin-velay]

@elliotb-lowrisc, your comment is fair (except that it's not DV purposes only 😄). Do you see another cleaner way of doing it?

[elliotb-lowrisc]

@martin-velay Nevermind, it seems I was mistaken in thinking that the axi_xbar address mapping mattered from a synthesis perspective. I had imagined the mapping being synthesised into fixed logic gates like our TL-UL crossbars, but instead it seems the axi_xbar address map is dynamic (specified via a port rather than a parameter or template). If changing the address map doesn't change the synthesis inputs, then it shouldn't worsen timing/area/performance.

Might be worth updating the tag in the PR title if this is not a DV-only change though.

[martin-velay]

I have added a C check which should verify the FPGA logic will work too. I haven't verified on the board, but I rather rely on CI with this test.

[elliotb-lowrisc]

Alright, I think this is ready to be merged

[martin-velay]

@ziuziakowska or maybe @marnovandermaas, as Douglas is on holidays, could you confirm that you are OK with these SW changes?

[martin-velay]

I've just added the test_framework_test for the UVM based regression

[marnovandermaas]

I think we shouldn't use the rest of chip crossbar for the DV window. Can we change this before merging this?

[marnovandermaas]

You're adding these before the tests are added.

[martin-velay]

I think the C test were already existing before this PR. Is that what you meant?

[marnovandermaas]

You shouldn't add the DV window to the rest of chip bus. It should be a separate AXI port.

[martin-velay]

I am not sure I understand, do you want a new dedicated AXI port on top_chip_system (e.g. sw_dv_req_o / sw_dv_resp_i) similar to how rest_of_chip_req_o is exposed today - so chip_mocha_genesys2 connects it directly to the axi_to_mem sink, and the UVM/Verilator tb ties it off? Or do you have a different topology in mind?

[raylau1]

Yes I think that's what Marno meant. sw_dv_req_o and sw_dv_resp_i should be connected as a new device on the AXI crossbar inside top_chip_system.

[martin-velay]

I have addressed the easy bits. There are still some pending comments though

[martin-velay]

@ziuziakowska, as discussed by chat, the last pushed is an attempt to address this #584 (comment)

[raylau1]

I think the HW_ID can be tested with separate binaries for each platform. For example hw_id_verilator_test.c expects the verilator HW_ID and hw_id_fpga_test.c expects the FPGA HW_ID. This way if reading the HW_ID on FPGA returns the verilator ID, the test will fail.

[ziuziakowska]

I think this would be a lot of extra build system work for just testing the read value of a register, as long as it can be seen to work I think it is fine.

[ziuziakowska]

With @martin-velay's permission I've made some changes to the software side to make it in line with the rest of the HAL.