[dv] Add RV32ZC handling to ISA strings

[AnastasiyaChernikova]

Use the RV32ZC configuration parameter when constructing the ISA string passed to the cosimulator. This lets DV runs distinguish between Zca, ZcaZcb, ZcaZcmp and ZcaZcbZcmp configurations.

[AnastasiyaChernikova]

Hi, @nasahlpa!
To simplify future testing of Ibex, I suggest adding the ability to select different extensions at startup. Please review this commit. Also, unfortunately, I can't view the hidden stages of your pipeline to fix the crash.
Thanks in advance!

[SamuelRiedel]

Thanks @AnastasiyaChernikova for looking into this. Your changes look good at first glance to me. However, we won't be able to merge them until we update our compiler version. Some changes are similar to commits in the PR adding DV for the Zc* extensions (#2324), but as noted there, this cannot be merged until we update the compiler. For more context please also check out this comment on why the Zicsr and Zifencei flags currently lead to CI failing: #2288 (comment)

I am afraid we cannot merge this currently, but I'll leave the PR open and revisit it once we update the compiler.

[AnastasiyaChernikova]

@SamuelRiedel, thanks for the explanation and for keeping the PR open.

I understand that this is currently blocked by the toolchain/compiler version used in CI rather than by the patch itself, and I would like to help unblock it if possible.
For reference, I tested this locally with the lowRISC toolchain release lowrisc-toolchain-rv32imcb-x86_64-20250710-1, and with that toolchain the build and tests I ran complete successfully. So I am not currently able to reproduce the CI failure locally.
The main difficulty for me is that I do not have access to the full CI pipelines/logs, so I cannot see which exact stage is failing or what additional constraints need to be satisfied before the toolchain can be updated.
I could contribute to the toolchain migration if that would be useful — for example by preparing a follow-up PR, adjusting the ISA flags, updating the affected DV/simple-system flows, or running additional checks locally. At the moment I am mostly missing context on what the remaining difficulties are and what still needs to be done before these changes can be merged.
It would be great to find a way forward here, because this change allows the DV flow to distinguish the concrete RV32ZC configuration passed to the cosimulator. In particular, this is critical for my current work, so I would really appreciate any guidance on the remaining blockers and on whether there is a useful way for me to contribute to resolving them.

[AnastasiyaChernikova]

Hi @SamuelRiedel, sorry for the ping.

Just gently following up on this PR. Is there any update on the toolchain/compiler blocker, or anything I could help with from my side?

This is still relevant for my current work, so I would appreciate any guidance on the next steps.

Thanks!