We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Showing results for 
Search instead for 
Did you mean: 

Adam Taylor’s MicroZed Chronicles, Part 105: Interrupt Latency

Xilinx Employee
Xilinx Employee
0 5 158K


By Adam Taylor


When we last looked at the Zynq SoC’s XADC, we explored ways to design the hardware so that we could get a real-world signal into the XADC and obtain maximum performance prior to quantization. However that is just half of the battle. Once we get the signal into the XADC and the Zynq SoC, we then need to ensure that we have designed our application architecture to meet its performance requirements. This is particularly important with respect to timing. Interrupt latency—the time between the interrupt being raised and the interrupt being serviced—plays a large role in performance. A number of issues impact interrupt latency.


Two of these issues are the presence of an operating system and the complexity of the ISR (Interrupt Service Routine). If we rely on interrupts to capture data from the XADC or to kick of XADC sampling and fail to consider interrupt latency, the application might fail depending upon the latency period, latency consistency, and the time taken for the ISR. Events could be missed if latency is too great or ISR execution time is too long. In such cases, the net result is an unreliable system with intermittent failures.


We will use the Zynq SoC’s XADC in our examples and we will communicate with the XADC over the AXI bus while using the Zynq SoC’s programmable fabric to process interrupts. Therefore, we are interested in the interrupt latency on the private peripheral interrupts nIQ and fIQ when using a bare-metal system.


Note: both nIQ and fIQ are level-triggered interrupts. The peripheral must assert these interrupts until they are acknowledged. Note also: these lines are active high.


But how do we go about determining our system’s interrupt latency? To find out, we need to accurately know when an interrupt is asserted and we also need to know when the ISR starts.


We can use the AXI Timer to obtain this information. The AXI Timer gives us the ability to load an initial value and then count up until a terminal value is reached. Once this value is reached we can configure the AXI timer to generate an interrupt at this point. We will use two very useful AXI Timer features to aid us in this task:


  • The ability to auto reload—the interrupt counter reloads and continues counting.
  • A freeze input that stops the AXI Timer from counting when asserted. The ISR can assert this signal to stop the counter.


Using the above AXI Timer features, we can accurately determine how long it takes to service an interrupt and then calculate the interrupt latency. We will use an EMIO GPIO signal from the Zynq SoC’s PS (Processing System) to assert the freeze input. Our interrupt latency time calculations will therefore include the small amount of time needed to assert the freeze signal over the EMIO GPIO.


As we wish to use both nIQ and fIQ interrupts in our examples, I used two AXI timers configured as shown below to determine the interrupt latency on both interrupts:






In next week’s blog, we will look at related software development and the results we obtain for the fabric-to-processor interrupt latencies.



Files, as always, are on my github repository.



If you want E book or hardback versions of previous MicroZed chronicle blogs, you can get them below.



MicroZed Chronicles hardcopy.jpg 



  • First Year E Book here
  • First Year Hardback here.



 MicroZed Chronicles Second Year.jpg



  • Second Year E Book here
  • Second Year Hardback here





You also can find links to all the previous MicroZed Chronicles blogs on my own Web site, here.



Tags (1)