Interrupt latency in RTEMS (Zedboard)

[Chris Johns]

On 28/03/2018 01:28, Joel Sherrill wrote:
> On Tue, Mar 27, 2018 at 8:05 AM, BRIARD Sebastien
> <sebastien.briard at thalesaleniaspace.com
> <mailto:sebastien.briard at thalesaleniaspace.com>> wrote:
> 
>     Okay, I realized how I was confusing clock tick (for timekeeping) and
>     interrupt latency and why the result were not the ones I expected.
>     I still have one question, is there a macro to choose/impose the processor
>     frequency ?
> 
> If you mean the actual clock rate of the CPU, then it would be a BSP specific
> option and
> it would have to match the hardware. All the BSP options for this BSP are in
> c/src/lib/libbsp/arm/xilinx_zynq/configure.ac <http://configure.ac>.

The frequency for the Cortex-A9 is exported in the Xilinx headers created when
you export the design in Vivado. You need a way to import those defines into
your code.

A few of the clock related set ups in this BSP use weak symbols so you can
provide a version in your code that matches the frequency your designers have
set up in Vivado.

> For the clock tick length, you have to balance overloading the CPU with clock tick
> interrupts on one extreme and not advancing time on the other. Your 1 microsecond
> per tick is dangerously close to the no forward progress end. At some point, you
> have to consider that it takes a minimum number of instructions to process the
> interrupt and from that a minimum length of time. 
> 
> At near 1 Mhz, you can probably handle the 1 usec clock ticks alone but there won't
> be much time left to do real work. I experimented years ago on a 400 Mhz
> embedded PowerPC and you could go very low on the clock tick but it was
> clear from the test code I was running that you lost more and more non-interrupt
> processing time to do application processing. So as the interrupt rate went up,
> the overall application throughput went down.

Looking at one interrupt on a Zynq I have at hand I am seeing a minimum time of
1040 nsecs and a max of 3597 nsecs. This is the time from raising the request,
getting into the interrupt and acknowledging it in a PL register. These times
are measured in the PL so no software or related overheads involved.

Chris