fc_event_data_o of APB Event Generator not connected to anything

[MikeOpenHWGroup]

Is there an existing core-v-mcu bug for this?

• I have searched the existing bug issues

Bug Description

This issue was discovered during the effort to update the User Manual by @cst-jayesht. See this discussion in pull-request #344:

Hi Mike, the fc_event_o pin directly forwards the input events 7 and 8 i.e. uDMA UART 1's err_event_o and uDMA Core's rx_lin_events_o. However, the pin is not connected to anything in the RTL implementation. The same is mentioned in the documentation. Hence, it is not covered in the block diagram.

It seems to me that at the very least, the uDMA rx_lin_events_o should be connected to fc_event as an interrupt for the CV32E40P core.

[shivamtiwari020505]

Hi Mike, I would like to look into this issue.

I traced the path on the current master branch. It appears that soc_event_generator.fc_events_o[1:0] is driven from per_events_i[8:7] and connected to s_fc_hp_events[1:0] in soc_peripherals.sv, but s_fc_hp_events is not connected to the 32 bit fc_events_o bus sent to the FC subsystem.

I also noticed that fc_event_data_o, mentioned in the issue title, is already used internally to feed the event FIFO for IRQ 11.

Before proposing a change, could you confirm which CPU interrupt IDs should receive the two high priority events? The currently documented fast interrupt IDs 16 through 31 appear to already be allocated, and I want to make sure the implementation remains backward compatible with existing software.

[MikeOpenHWGroup]

Before proposing a change, could you confirm which CPU interrupt IDs should receive the two high priority events?

@cst-aditya, can you comment?

[shivamtiwari020505]

While checking the RTL history, I found that s_fc_hp_events[0] and s_fc_hp_events[1] were previously connected to CPU interrupt IDs 30 and 31 respectively. In the current interrupt map, IRQ 30 is used by eFPGA event 5 and IRQ 31 by the event-controller error. Interrupt IDs 12 through 15 are reserved by CV32E40P.

This suggests that IRQs 30 and 31 were the original intended IDs. @MikeOpenHWGroup, could you advise how you would like the conflict with the current IRQ 30 and 31 assignments to be handled?

[MikeOpenHWGroup]

I like your recommendation @shivamtiwari020505, but we should try to get comments from other users of the MCU as changing the interrupt hierarchy directly impacts software.

@cst-aditya, @ChrisElash, @yusefkarim

[cst-aditya]

Hi @MikeOpenHWGroup,
cc: @shivamtiwari020505

Please expect a response today.

[cst-aditya]

Hi @MikeOpenHWGroup
cc: @shivamtiwari020505

soc_event_generator.fc_events_o[1:0] is driven from per_events_i[8:7]
Since the original sources of these events are platform-specific (second level) interrupts—specifically, uDMA UART 1's err_event_o and the uDMA core's rx_lin_events_o—could we map these events to interrupt ID 11 instead?

from https://docs.openhwgroup.org/projects/core-v-mcu/doc-src/interrupts.html

Regarding the proposal to map these events to interrupt IDs 30 and 31, it is difficult to determine from the version history why they were originally unmapped from CPU interrupt IDs 30 and 31.

From the SW perspective, we are currently not using interrupt ID 30. However, interrupt ID 31 is used as the SoC queue overflow indicator, so changing or reusing it may be important for us. The implications of this mapping are currently unclear.

[shivamtiwari020505]

Using IRQ 11 is consistent with the two-level interrupt scheme. From the current RTL, per_events_i[7] and per_events_i[8] already enter the FC arbitration and FIFO path like the other platform-specific events. When their FC mask bits are cleared, their event IDs are written to the FIFO, and event_fifo_valid_o drives CPU IRQ 11.

The unused soc_event_generator.fc_events_o[1:0] output appears to be a separate direct high-priority path. I do not think it should be connected directly to IRQ 11, because that could assert the interrupt without placing a corresponding event ID in the FIFO.

I propose first adding a focused simulation that unmasks events 7 and 8, triggers them individually, checks IRQ 11, verifies that REG_FIFO reports the correct event ID, and checks the interrupt acknowledgment behavior. If this path already works as expected, should issue #355 be treated as cleanup or documentation of the unused direct output rather than assigning new CPU interrupt IDs?

[cst-aditya]

It makes sense to me. Could you please validate and share your findings? Accordingly, we can take a call.
@MikeOpenHWGroup: Please share your input.

[shivamtiwari020505]

Understood. I will validate the IRQ 11 FIFO path for events 7 and 8, including masking, FIFO event IDs, and interrupt acknowledgment, and then share the results here before proposing any RTL changes.

[shivamtiwari020505]

I validated this on commit d51a278 using the production event-generator parameters.

Events 7 and 8 are already handled by the normal FC arbitration and FIFO path. With the reset masks, neither event raises the FIFO interrupt. After clearing bit 7 or bit 8 in FC_MASK_0, the corresponding event is queued, event_fifo_valid_o asserts CPU IRQ 11, and an IRQ 11 acknowledgement pops the entry and updates REG_FIFO with event ID 7 or 8. Acknowledgements for IRQ 30 or IRQ 31 do not pop this FIFO.

I also tested events 7 and 8 arriving together. Both event IDs are retained, and IRQ 11 remains asserted until both entries have been acknowledged.

The separate fc_events_o[1:0] path still mirrors per_events_i[8:7], but the connected s_fc_hp_events signal has no downstream consumer. fc_event_data_o itself is not unconnected; it feeds the FC FIFO. IRQs 30 and 31 remain driven by eFPGA event 5 and the event-controller error respectively.

The focused self-checking test passes with Icarus and Verilator, and the repository lint target passes.

My conclusion is that no new IRQ 11 mapping or reassignment of IRQs 30 and 31 is needed. Connecting the direct output to IRQ 11 would bypass the mask and FIFO semantics. Would you prefer a follow-up PR that adds this regression test and clarifies the documentation around the unused direct output?

[MikeOpenHWGroup]

Thanks for your detailed investigation of this issue @shivamtiwari020505

Would you prefer a follow-up PR that adds this regression test and clarifies the documentation around the unused direct output?

Yes, that would be a valuable contribution.