Mi-V Embedded RISC-V - OPSRV Interrupt Register and TCM ECC Management example?

[patricevenant]

Hi,

I'm using a MiV32I core in RTG4.
Do you you have any advice or example of how to manage the TCM RAM ECC interrupt within OPSRV registers ?

At the boot stage, the TCM RAM is considered as an unknown state, the ECC errors (correctable and uncorrectable) are already raised which is correct. But, when we enable the OPSRV interrupts, in trap is raised. This is a false ECC error as the TCM RAM isn't initialized yet.

Probably, you have already a recipe of how to manage the OPSRV/ECC interrupt in assembler ?

Thanks for your help,
Patrice

[hughbreslin]

Hi @patricevenant

there is an explanation of the ECC configuration for GPRs and TCM in section 4.14 of the core handbook which will probably be useful here.

4.14 ECC
Error Correcting Codes (ECC) can be enabled for the core through the configurator. They encode parity with data in
RAM and can correct single bit errors and detect double bit errors, Single Error Correct Double Error Detect
(SECDED).

If RAM based GPRs are used (default) and ECC is enabled, a fabric encoder and decoder is instantiated for the
RAM. If the TCM is used, an encoder and decoder isl also instantiated for the memory when ECC is enabled.
When ECC is enabled for the GPRs, the core are held in soft reset for several cycles on start-up, while the GPRs are
initialized to 0. This prevents erroneous SECDED errors on uninitialized RAM.

If a double bit error is detected from a GPR, the core automatically initiates a soft reset and the GPRs are reinitialized
before start-up. This prevents bad data from the GPR being used. In the event of a DED, soft reset bit[2] of the
OPSRV Soft register sets to indicate that the core has recovered from a double bit error and this bit can be cleared
by writing to it. The individual machine ECC interrupts have to be enabled for an ECC error to be handled, but the
soft reset occurs on a DED regardless of the interrupts being enabled.

When ECC is enabled for the TCM, ECC bit is not initialized. This process must be undertaken in software before
enabling the TCM ECC interrupts in the OPSRV register.

Sample code to initialize the TCM to 0:
C:

volatile uint32_t *tcm_addr;
tcm_addr = 0x40000000; // Memory mapped start address of TCM
uint32_t tcm_end_addr = 0x40002000; // Memory mapped end address of TCM
while (tcm_addr != tcm_end_addr){ // loop until end is reached
    *tcm_addr = 0x0; // write 0 to memory location tcm_addr = tcm_addr + 0x1; // increment pointer
}

Sample code to scrub the TCM and generate parity for initialized memory: C:

volatile uint32_t *tcm_addr;
tcm_addr = 0x40000000; // Memory mapped start address of TCM
uint32_t tcm_end_addr = 0x40002000; // Memory mapped end address of TCM
while (tcm_addr != tcm_end_addr){
    *tcm_addr = *tcm_addr; 
    tcm_addr = tcm_addr + 0x1;
}

Programming the TCM through the TAS also generates parity if ECC is enabled.

I hope this helps 🙂 In terms of assembly, something like the following should work to initialize to 0:

    la  a4, __tcm_start
    la  a5, __tcm_end
    .init_tcm
    sw x0, 0(a4)
    add a4, a4, 4
    blt a4, a5, .init_tcm

or to generate parity for existing data:

    la  a4, __tcm_start
    la  a5, __tcm_end
    .init_tcm
    lw t0, 0(a4)
    sw t0, 0(a4)
    add a4, a4, 4
    blt a4, a5, .init_tcm

[patricevenant]

Thanks a lot for your answer, this is helpful. I have some confusion about the parity. In the handbook document chapter 4.11, the parity seems not supported ? Or which parity have you mentioned in your answers ?
Thanks,
Patrice

4.11 OPSRV Register
Setting the opsrv_parity_en bit enables parity checking on TCM and interface transactions. Data in the TCM must
be written with parity when this feature is enabled, and bus parity must be generated by peripherals connected to the
core. In this release of the core, the parity enable register has been tied to 0, as parity is not being supported.

[hughbreslin]

Ahhh yes I can see why that would be confusing - I’m talking about parity bits for data in ram whereas the parity being discussed in section 4.11 is on the internal busses themselves (i.e if a bit flip occurred while data was on the bus).

[patricevenant]

I understand, great thanks. The parity bits for data in ram is calculated with ECC. I suppose then, we have two separate algorithms :

• an ECC which can correct a single bit error only, an OPSRV interrupt is generated in case of single or multiple error
• a parity error, no correction of the data, a "Data load parity error" interrupt is generated.

Just to be sure, is that supposition accurate ?
Thanks

[hughbreslin]

We do have two separate algorithms yes but the bus parity, or parity error as you called it above, isn't enabled or really supported. This could be implemented by TMR (Triple Mode Redundancy) if its something you feel you need.

[patricevenant]

Thanks, I made a link between the differences. 👍