Use riscv section for RISC-V targets

[romancardenas]

This PR uses my proposed riscv SVD section to generate RISC-V PACs using the new set of traits in riscv-pac.

In this PR, the mod interrupt in RISC-V targets is handled differently, and includes:

• ExternalInterrupts (very similar to current Interrupts)
• CoreInterrupts (this is new, previously it just assumed the peripheral follows the RISC-V standard)
• Priority levels (necessary for interfacing standard peripherals with trait bounds)
• HartIds (necessary for interfacing standard peripherals with trait bounds).

Also, the PAC does not directly generate all the handlers array and so on. Instead, it relies on macros exposed in riscv-pac.

I still need some time to pollish everything, but feedback is more than welcome :)

Solves #786

[romancardenas]

This PR shows how an updated PAC would look like over e310x chips

[romancardenas]

Added the unstable-riscv feature to optionally activate the proposed new functionality. I still have to include support for riscv-peripheral implementations depending on the name of the peripheral.

[Emilgardis]

good start! should probably be marked as a draft, I see a bunch of todos

[romancardenas]

Yes! I'm currently working on a bunch of changes to use standard peripherals when possible, so it will take a few more iterations until it is ready to merge

[romancardenas]

As shown in this PR, now it is possible to use riscv-peripheral standard implementations (i.e., CLINT and PLIC) instead of the ones generated by svd2rust. This shows the new outcome. Note that it only takes one macro call per standard peripheral:

riscv_peripheral :: clint_codegen ! (base 0x2000000 , mtimecmps [mtimecmp0 = (crate :: interrupt :: Hart :: H0 , "[0](crate::interrupt::Hart::H0)")] , msips [msip0 = (crate :: interrupt :: Hart :: H0 , "[0](crate::interrupt::Hart::H0)")] ,);
riscv_peripheral :: plic_codegen ! (base 0xC000000 , ctxs [ctx0 = (crate :: interrupt :: Hart :: H0 , "[0](crate::interrupt::Hart::H0)")] ,);

To do list

• Configuration parameter to select whether to use the standard macros or the old-school way.
• A mechanism to specify the CLINT's clock frequency to benefit from its embedded-hal implementation.
• Configuration parameter to activate the use of async_delay flag for CLINT.

Regarding the second point: what do you think about providing the CLINT clock frequency via a configuration parameter?

[romancardenas]

I started with the configuration parameters... and decided to explore using configuration parameters only, leaving the SVD file untouched.

For the E310x chip, the configuration file would look like this.
What do you think about this alternative? I personally like it more.

[burrbull]

I started with the configuration parameters... and decided to explore using configuration parameters only, leaving the SVD file untouched.

For the E310x chip, the configuration file would look like this.
What do you think about this alternative? I personally like it more.

Makes sense. But why a TOML? YAML should looks much cleaner for such things.

Also what should we do with svd-rs changes and released crates?

[romancardenas]

Makes sense. But why a TOML? YAML should looks much cleaner for such things.

I converted the TOML file to YAML and the following command fails:

svd2rust --target riscv -c svd2rust.yaml -g -i e310x.svd
[ERROR svd2rust] Failed to parse value for parser #2
    
    Caused by:
        0: Failed parse TOML
        1: TOML parse error at line 1, column 16
             |
           1 | core_interrupts:
             |                ^
           expected `.`, `=`

From here, it looks like svd2rust only supports TOML configuration files

Also what should we do with svd-rs changes and released crates?

If we prefer this isolated configuration file approach (which I do), then all the stuff under the unstable-riscv feature will no longer be necessary, as all the RISC-V magic will happen in svd2rust only.

[burrbull]

I think this should not be in svd2rust config file. It's better to use another --riscv-config file.yaml option as you may want to use different configs for different input SVDs but with the same svd2rust.toml.

[romancardenas]

I addressed your suggestions. I'm not sure if my independent YAML file implementation is the best approach, let me know what you think.

You can see how I use it for E310x chips here

[romancardenas]

• PAC using this PR: e310x
• HAL using the result PAC: e310x-hal
• BSP using the resulting HAL: hifive1
  • It contains an example using the PLIC and CLINT peripherals. You can emulate the CLINT example with QEMU
• Software Interrupt handler SLIC: riscv-slic