Re: Zero latency interrupt extension for ARMv6-M

Glaropoulos, Ioannis

Hi Fabio,

Thanks for your email. To the best of my knowledge, none is working on ZLI on Baseline Cortex-M. If you would like to move with this forward, the best way is to an RFC issue in the Zephyr main tree Github, to get feedback from the architecture maintainers/collaborators. Remember to copy the content in this email thread.

Some comments to your suggestion:

ZLI works OK on Mainline Cortex-M, essentially because we can guarantee the following priority level order:
       ZLI > Kernel > HW IRQs (+misc) > PendSV (Faults are always given highest configurable priority)
So ZLIs can preempt all HW IRQs, and can also preempt the Kernel (i.e. SVCs).

Now on Baseline (If I understand the proposal):
- PRIMASK won't be used at all for IRQ locking, if the ZLI feature is enabled.
- For ZLIs to preempt the kernel (thus, for ZLI to have the same functionality as in Mainline), SVCs need to be given a priority level lower than the ZLIs. That means, 1 out of 4 priority levels need to be reserved, which is something we were trying to avoid for some time.

There's also the performance of irq_lock and _unlock functions: the beauty of the current solution is that no memory-mapped register access is performed. This speeds up the execution, and requires only an ISB barrier. With NVIC, read-modify-write and ram-variable-storing we will need memory-mapped accesses in addition to data synchronization barriers, which might increase the overhead of locking and unlocking the IRQs. The problem will be harder on Armv8-m Baseline, which has support for much more than 32 IRQ lines.

Guess these are reasons why the software emulation of irq locking "up-to-a-priority-level" has not attracted much attention so far, but I'd be happy to see an actual discussion going on here, ideally in an RFC Github issue.


Join to automatically receive all group messages.