In any design that has to switch worlds to handle an interrupt, the monitor becomes part of the critical path which defines the system’s worst case interrupt latency. Unlike ARM R-profile and M-profile processors, which are typically deployed into deeply embedded systems, software deployed to an ARM A-profile applications processor typically does not need low interrupt latency. However, designs should take any additional latency introduced by the monitor software into account to ensure that the worst case behavior does not cause violation of any timing constraints.
The interrupt overheads added by the monitor may be higher than just the cost of a single world switch. For example, if the processor has just entered the monitor when an interrupt occurs it will transition through the monitor before handling it, if the processor then needs to switch back to the other world to handle the interrupt it will need to perform a second monitor transition.
In designs that want to minimize the interrupt latency impact, the code and data used by the monitor should be placed in fast memory close to the core. In systems using the ARM1176JZ(F)-S processor, the monitor can be placed in TCM. In systems which do not provide TCM, the monitor can be placed in locked-down L2 cache lines or fast on-SoC SRAM.
A simple monitor which stacks the general purpose registers, and performs the SCR setting reconfiguration required for the interrupt model described previously in this section, may incur the following overheads:
Monitor code and data located in TCM.
Upper bound is 200 cycles per switch, or 400 cycles total.
400 cycles at 300MHz is 1.3us.
Monitor code and data located in locked L2 cache.
Approximate overhead is 1200 cycles per switch, or 2400 cycles total.
2400 cycles at 600MHz is 4us.
Total interrupt latency will include overheads due to the Normal world software, the Secure world software, and aspects of the system design such as external memory performance. These overheads are not indicated in the figures in this list.
For comparison, the interrupt latency seen by a Linux driver running on an ARM1176JZ(F)-S with two levels of cache, and without any Secure world software, is approximately 5000 cycles. This is caused by overheads in the operating system itself.