Fix dsim support

[akashlevy]

This PR fixes up Ibex UVM support for dsim simulator. Several things had to be fixed:

• Simulator compatibility: dsim requires that enum values must use enum constants
  • Use ZERO enum constant instead of '0 and 0 for instr enums: dv/uvm/core_ibex/riscv_dv_extension/ibex_directed_instr_lib.sv
  • Add Ibex-specific CSRs (CPUCTRLSTS, SECURESEED) to privileged_reg_t and replace enum constants into implemented_csr[]: vendor/google_riscv-dv/src/riscv_instr_pkg.sv, vendor/google_riscv-dv/euvm/riscv/gen/riscv_instr_pkg.d, dv/uvm/core_ibex/riscv_dv_extension/riscv_core_setting.tpl.sv
• Simulator compatibility: dsim does not appear to respect "re-exports"
  • Replace all re-exported ibex_mem_intf_agent_pkg::ADDR_WIDTH and ibex_mem_intf_agent_pkg::DATA_WIDTH with ibex_mem_intf_pkg::ADDR_WIDTH and ibex_mem_intf_pkg::DATA_WIDTH: dv/uvm/core_ibex/tests/core_ibex_base_test.sv, dv/uvm/core_ibex/tests/core_ibex_test_lib.sv, dv/uvm/core_ibex/tests/core_ibex_vseq.sv
• Simulator compatibility: Unroll loops for 2D arrays to support dsim in rtl/ibex_core.sv
• Simulator compatibility: Add #0 to allow clock to properly start in dv/uvm/core_ibex/tb/core_ibex_tb_top.sv
• Script fix: Add co-simulation support for dsim in dv/uvm/core_ibex/yaml/rtl_simulation.yaml
• Script fix: Add dsim case for reloc_word in dv/uvm/core_ibex/scripts/run_instr_gen.py
• Script fix: Replace dsim_compile_opts with dsim_opts and apply correct defparams and +defines in util/ibex_config.py
• Misc. fix: PC mismatch should remove 64-bit sign extension when printing ISS PC dv/cosim/spike_cosim.cc

With these fixes, I was able to get most of the UVM tests running with SIMULATOR=dsim ITERATIONS=1:

82.14% PASS 46 PASSED, 10 FAILED

Future enhancements:

• Fix remaining dsim failures
• Add Dockerfile for dsim setup
• Coverage support for dsim
• Fix METADATA-DIR make variable issue
• Add support for Verific elaboration (needs a few more defines, etc.)

[hcallahan-lowrisc]

Hey Akash, thanks for the PR getting dsim support going again! This is looking pretty good. Please mark as ready for review when you're happy with the state of things. If there is still some minor breakages, it would be better to get the bulk of things merged and then follow up with some smaller PRs, just to keep this changeset from getting too large.

[akashlevy]

Thanks @hcallahan-lowrisc! I'm still working on cleaning this up a bit and making sure that all the tests are consistently passing. Will let you know when it's ready!

I will need help testing on Xcelium/VCS, as I don't have immediate access to those tools.

[hcallahan-lowrisc]

Thanks @hcallahan-lowrisc! I'm still working on cleaning this up a bit and making sure that all the tests are consistently passing. Will let you know when it's ready!

I will need help testing on Xcelium/VCS, as I don't have immediate access to those tools.

Sounds great. We primarily test using Xcelium and VCS, and the "Ibex Private CI" actions that run against PRs use Xcelium, so seeing those checks pass is the main criteria to be aware of.

[akashlevy]

Perfect!

[akashlevy]

Hey @hcallahan-lowrisc, this is ready for review. Most of the dsim tests pass, so I think this can be reviewed and merged as a starting point as I root cause the remaining failures. Most are probably the same as the outstanding regression failures with xcelium

[hcallahan-lowrisc]

Hey @hcallahan-lowrisc, this is ready for review. Most of the dsim tests pass, so I think this can be reviewed and merged as a starting point as I root cause the remaining failures. Most are probably the same as the outstanding regression failures with xcelium

Great. Will review this now. For a point of reference going forward, you can see the latest set of Ibex regression results (ran with Xcelium) here : https://ibex.reports.lowrisc.org/opentitan/latest/report.html. (linked at the top of the Ibex README.md)

[hcallahan-lowrisc]

A couple of general comments:

• We use a rebase-only flow for this repo, so all the merge commits will need to be rebased away before merging.
• We also try not to have working commits adding/reverting changes within a PR, so those should all be dropped.
• Changes to vendored repos (in vendor/) shouldn't be applied directly, but rather as patches if we aren't going to push changes upstream. You can use the vendor.py tool in OpenTitan to do this by 1) adding your changes as .patch files in vendor/patches, then 2) running <opentitan>/util/vendor.py vendor/google_riscv-dv.vendor.hjson --commit to automatically create a commit that applies the new patch file. Let me know if you need any help doing this.
• Generally we try and squash changes into a few concise commits before merging, rather than many smaller commits as you might do while doing development. For example, most of the changes to rtl_simulation.yaml could be squashed into maybe 1 or 2 commits. Overall, I think less than 8 commits for this many changes would be ideal, something like commits that fix the build system, fixup DV code incompatabilities, fixup RTL incompatabilities, apply vendoring fixes, fix existing bugs and formatting errors.

But other than the minor style things above, this looks great! I will try and get a dsim installation going and run through a regression myself, but I think this should be easy to approve and merge. Thanks again!

[hcallahan-lowrisc]

Ah that's unfortunate it needs to be done as a seperate step. But this seems pretty clean. Thanks

[akashlevy]

Yes definitely unfortunate. I tried everything to get dsim to link it, but it doesn't seem possible

[akashlevy]

Could we potentially just squash this whole thing to one commit?

[akashlevy]

And thanks for the feedback on the vendor patches, I will go do that!

[akashlevy]

Also I have a nice Dockerfile setup for dsim+ibex if you'd like to speed up the process of testing out the dsim changes. Happy to share that if helpful

[hcallahan-lowrisc]

Could we potentially just squash this whole thing to one commit?

I think a handful of commits is probably right for changes of this scope. Certainly we would want to keep the RTL changes on their own, and also any standalone bugfixes / cleanups to existing code should be isolated commits.

Also I have a nice Dockerfile setup for dsim+ibex if you'd like to speed up the process of testing out the dsim changes. Happy to share that if helpful

Thanks, that might be really useful if you could drop it in a comment. At lowRISC we've generally been leaning towards using Nix for dependency management and tool isolation, so I would prefer not to merge a Dockerfile at this point. But it will be a useful reference, thanks.
If I remember rightly, Dsim, even the free tier, requires a login / registration step. How are you handling this? Is it just a manual login process after entering the container? Thanks

[akashlevy]

No worries I can split it up; just thought I'd ask to save myself some work ;)

[akashlevy]

Continuing this in #2297, which is ready for review.