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!

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

by Xilinx Employee ‎10-26-2015 09:55 AM - edited ‎01-06-2016 11:11 AM (39,173 Views)


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.



by Visitor se31berg
on ‎05-25-2017 10:47 AM

Is this why in issue 32, XADC Alarms and Interrupts, it takes a few minutes for the interrupt to appear in the terminal after running? Or is this something completely different?



by Visitor se31berg
on ‎05-26-2017 06:29 AM

I've been finding myself spending a ton of time trying to decipher this block diagram pictures because I'm not 100% fluent in Vivado yet. specifically, I am having difficulty recustomizing the processing system IP. Is there somewhere I can look for guidance? I tried an internet search but it was unsuccessful.


This is where I am at with recustomizing the PS IP


Any guidance or pointers?


I cant seem to figure out the rest.


Please help.


by Observer taylo_ap
on ‎05-27-2017 02:48 AM



I think you mean issue 43 XADC alarsm and interrupts, no this is not the reason if the interrupt took a few minutes to service our embedded system would not be very responsive. The reason in that blog it takes a few minutes is we have set an high temperature alarm on the device temperature. To ensure the demo works it needs to be set a little above the what the temperature would be when it is just turned on so you need to wait a few minutes for the device temperature to heat up before the alarm is triggered. Of course if your using a fan or heat sink this might be an even longer wait 



by Observer taylo_ap
on ‎05-27-2017 02:55 AM



What are you trying to do rebuild the diagram shown above, most of it should be available to you using the block automation fucntion which appears at the top of the diagram when you place a Zynq IP block on a block diagram. This should apply any board presets (very important). Following that is if you insert the two AXI timers ther should be a connection wizard appear in the same place which will connect them to the Zynq PS block for you. All you need to do then is add in the slices from the GPIO which you create under the MIO tab within the Zynq customisatgion menu. 





by Visitor se31berg
on ‎05-30-2017 05:01 AM

Hi Adam


I ended up figuring it out. I just had some difficulty figuring out how to include the interrupts and the GPIO ports on the processing system but it all worked out.




About the Author
  • Be sure to join the Xilinx LinkedIn group to get an update for every new Xcell Daily post! ******************** Steve Leibson is the Director of Strategic Marketing and Business Planning at Xilinx. He started as a system design engineer at HP in the early days of desktop computing, then switched to EDA at Cadnetix, and subsequently became a technical editor for EDN Magazine. He's served as Editor in Chief of EDN Magazine, Embedded Developers Journal, and Microprocessor Report. He has extensive experience in computing, microprocessors, microcontrollers, embedded systems design, design IP, EDA, and programmable logic.