[BUG] Update interrupt vector table description

[DanieleParravicini-Synthara]

Bug Description

The CVE2 documentation read online at ReadTheDocs at cve2-user-manual/en/latest/internal says that CVE2 should start at [boot_addr_i + 0x80] (https://docs.openhwgroup.org/projects/cve2-user-manual/en/latest/02_user/integration.html#interfaces) but I do not find any information on the interrupt vector table.

We tried to use a vector table that was compatible with this other version of Ibex and used its documentation on ReadTheDocs.
But it does not work,

As you can see boot_addr_i is set to 0x80000, and the crush_dump_o.current_pc and crush_dump_o.next_pc goes to 0x80000, then to 0x80004, and then 0x800a6 and not to 0x80000+0x80 as indicated in (https://docs.openhwgroup.org/projects/cve2-user-manual/en/latest/02_user/integration.html#interfaces).

Where can I find more information on the interrupt vector table description?

If you are ok we could submit a PR to fix the simple-system firmware to reflect the change.

[DanieleParravicini-Synthara]

MAYBE: comparing cve2_if_stage.sv with ibex_if_stage.sv it seems that the CVE2 starts boot_addr_i and not at boot_addr_i+0x80.

looking further it seems that the old ibex has 32 irq, or 32 addresses in the IRQ vector table whereas the CVE2 seems to have 64 "IRQS": 32 dedicated to actual IRQ and other 32 for exc, right?

so we can say that IRQ[0] is actually the boot address. correct?

[DanieleParravicini-Synthara]

If you are ok with that I could create a PR that updates the documentation

[davideschiavone]

yes that would be very welcome :)

[DanieleParravicini-Synthara]

Noice, but do you think that the intuition is correct?

MAYBE: comparing cve2_if_stage.sv with ibex_if_stage.sv it seems that the CVE2 starts boot_addr_i and not at boot_addr_i+0x80.

looking further it seems that the old ibex has 32 irq, or 32 addresses in the IRQ vector table whereas the CVE2 seems to have 64 "IRQS": 32 dedicated to actual IRQ and other 32 for exc, right?

so we can say that IRQ[0] is actually the boot address. correct?

[davideschiavone]

yes it has been done here: be70b26

[DanieleParravicini-Synthara]

so combining page 43 of Volume 2, Privileged Specification version 20240411 and [cve2 repo e.g. cve2_pkg, cve2_controller]:(

cve2/rtl/cve2_pkg.sv

Line 299 in 42f76f4

typedef enum logic [6:0] {

):

• IRQ0 is reserved
• IRQ3 is software IRQ
• IRQ7 is for timer
• IRQ11 is for machine external interrupts
• IRQ>16 and above are considered customs and in the case of CVE2:
• IRQ16-IRQ31 are used for 16 irq_fast
• IRQ32 is non maskable IRQ

so the vector interrupt table is as follows ( the addresses are indicated as word offset from the mtvec or boot_addr):

offset	description
0	boot
1-2	reserved
3	IRQ
4-6	reserved
7	irq timer
8 - 10	reserved
11	irq external
12-15	reserved
16-31	16 fast local interrupt
32	non maskable interrupt

so the vector table starts at boot_addr and arrives till 0x7C (included)

[DanieleParravicini-Synthara]

can you please confirm?

[DanieleParravicini-Synthara]

a wait, the exception are also "multiplexed" on this vector table, right?

[DanieleParravicini-Synthara]

I am not so sure because I can see some overlapping in the exc_cause_e:

• EXC_CAUSE_BREAKPOINT = {1'b0, 6'd03} and EXC_CAUSE_IRQ_SOFTWARE_M = {1'b1, 6'd03},
• EXC_CAUSE_STORE_ACCESS_FAULT = {1'b0, 6'd07} and EXC_CAUSE_IRQ_TIMER_M = {1'b1, 6'd07},
• EXC_CAUSE_ECALL_MMODE = {1'b0, 6'd11} and EXC_CAUSE_IRQ_EXTERNAL_M = {1'b1, 6'd11},

[davideschiavone]

interrupts are not related to the boot address, when an interrupt occurs you jump to the address pointed by the mtvec CSR

https://github.com/openhwgroup/cve2/blob/main/rtl/cve2_if_stage.sv#L124C23-L124C29

[DanieleParravicini-Synthara]

but mtvec is set to boot_addr at boot right, no?

cve2/rtl/cve2_cs_registers.sv

Line 502 in 42f76f4

mtvec_d = csr_mtvec_init_i ? {boot_addr_i[31:8], 6'b0, 2'b01} :