Add GPR Information to UDB

[AnimeshAgarwal28]

Is your feature request related to a problem? Please describe.
Yes. The UDB currently lacks information about General Purpose Registers in YAML format. The information currently is hardcoded in downstream projects. RISC-V ABIs Specification's first few sections define these neatly.

Describe the solution you'd like
Ideally ABI specification's should be a part of the UDB but it is a big change, we can start with RISC-V Calling Conventions and add information about all the GPRs.

Describe alternatives you've considered
The only alternative is the current situation, where each software tool maintains its own internal, hardcoded mapping of the RISC-V GPRs. This approach lacks a single source of truth and is less flexible for automation and verification.

[ThinkOpenly]

I presume you'd want to describe all non-CSR registers:

• GPRs
• FPRs
• VRs
• maybe accumulators and what-not from the emerging matrix-y extensions

[AnimeshAgarwal28]

Yes, I think UDB should have the information for all registers CSR or not, correct me if I am wrong. I was proposing we can start with GPRs.

[dhower-qc]

I have thought about this before, and I agree we should add it. It is probably necessary to eventually support additional bases like E or CHERI.

Right now, the X registers are built-in to the IDL language (along with the implicit behavior like x0 and sign extension when effective xlen < MXLEN). That should change. The F and V registers are ordinary global state. That should also change.

[ThinkOpenly]

We probably should come up with a YAML template to describe a general register. What attributes are needed? Once we have a good template, let's build a schema for that.

Looking at a random CSR, the relevant fields should include at least:

• $schema (to be created)
• kind ("register?")
• name
• long name
• description
• length in bits
• aliases ("x0" is also known as "zero"; "x5" is also known as "t0"; etc.)

I wonder if each YAML should describe a register, or a register file?
If a register file, then additional fields might include:

• count (possibly subject to conditions, like "rv32e" only has 16 GPRs, so we'd need some way to represent that)
• array/mapping of index to name/aliases