PIO IRQs - how are SET/CLEAR operations for the same IRQ on the same cycle handled?

[piersfinlayson]

I couldn't find the answer to this question in the RP2350 datasheet, but apologies if I missed it.

with respect to RP2350's PIOs, if two state machines execute IRQ SET and IRQ CLEAR targeting the same PIO block's IRQ on the same cycle, is the result defined?

Does the high SM's operation take priority (like with GPIO output directions/levels) or does the clear/set take priority over the other operation?

[Wren6991]

If a set and clear take place on the same cycle, the result is that the IRQ is set. This applies to any source of IRQ set/clear, including writes to the IRQ or IRQ_FORCE bus register: any set takes precedence over any clear.

Notionally you can think of the clear taking place first, and the set taking place later in the cycle. The logic here is that the clear is acknowledging a past event and the set is causing a future event.

Can I ask why your program relies on this behaviour? Generally this means your SM is setting an IRQ that may already be set. That can be indicative of a latent race condition since, depending on the timing of the clear, either one or two IRQs might be posted.

I couldn't find a citation for this in the datasheet (I had to double-check the hardware before I answered) so I will make sure that is added.

[piersfinlayson]

Thanks @Wren6991. That makes sense as behaviour.

I have written what is intended to be a cycle exact RP2350 PIO emulator here: https://github.com/piersfinlayson/epio.

While I don't intend to write a program that relies on this behaviour, it's nice for the emulator to replicate the hardware PIO behaviour as closely as possible. Right now the emulator asserts this condition, but I can now relax that and implement the correct "apply clear then apply sets" at the end of each cycle.

I am considering some kind of warning from the emulator when unusual PIO programming is detected - for example this case, and also cases like when multiple SMs write to the same GPIOs, as the resultant behaviour, while specified, may not be what the programmer expected.

I have been noodling on some programs that might be able to make use of this, by having 2 x SMs perfectly cycle aligned, one clearing the IRQ and one potentially setting on the same cycle, with the set taking priority causing different behaviour downstream. I don't know for sure this will be useful, but it's nice to have in the kitbag.

Incidentally, there's another piece of SM IRQ behaviour I couldn't find documented, but tested to verify - and that's that more than one SM can wait and get "triggered" by the same IRQ being set, if they are both waiting on the cycle when the IRQ triggers. I.e. that the "first" SM getting triggered, and then the auto-clear at the end of the cycle, doesn't prevent the "second" SM from getting triggered. I rely on this in a (legacy) SRAM emulator, to trigger two SMs to simultaneously trigger two DMA channels, that themselves are chained (so the second DMA channel in the chain has the required data ready when the first one writes to it). Strictly I have the cycles to use two IRQs here, but it's nicer to use one.

[lurch]

I have written what is intended to be a cycle exact RP2350 PIO emulator here: https://github.com/piersfinlayson/epio.

Neat. There's a few other projects doing similar things too https://www.google.com/search?q=pio+emulator

[piersfinlayson]

I have written what is intended to be a cycle exact RP2350 PIO emulator here: https://github.com/piersfinlayson/epio.

Neat. There's a few other projects doing similar things too https://www.google.com/search?q=pio+emulator

Yeah, I found quite a few RP2040 PIO emulators but nothing that seemed to be a complete RP2350 implementation (the new instructions, more SMs), parallel SM execution, ability to chain to DMA, etc.