characterizing the interrupt latency of your...
TRANSCRIPT
Slide 2
Agenda
• Why do we miss interrupts ?
– How do we currently manage them
• Why is latency characterization a problem.
• Characterizing Interrupt Latency using simulators
Slide 4
Necessary Conditions for Interrupt
Service
• Common across all DSPs
– GIE is enabled.
– NMI is enabled.
– Individual Interrupts are enabled.
– No higher priority interrupt is blocking the lower priority interrupt.
• C6000
– Should not be in branch delay slot
• C64+
– Interruptible but with a delay, which is variable and can be roughly upto 150
cycles.
– Branch delay slots still not interruptible.
• C54xx
– RPT
Slide 5
Why do we miss interrupts
• Possible Causes
• Programmatic error
– missed enabling all relevant bits (GIE, NMI)
• In a non interruptible loop for a long time.
– did not use –min compiler option..
– Hand assembled code in branch delay slot.
• Lot of code between HWI_Disable and HWI_Restore
– Used to lock scratch mem, rather than operating on local
variables for reentrancy.
Slide 6
Joule Interruptability
• Compiler won’t generate the sploop when
– -ms3 compiler switch is used
– Iteration interval > 14
– Dynamic length > 48
– Things that disqualify normal software pipelining (call in
loop, complex control code in loop, etc)
– Optimizer completely unrolls the loop
• would be interruptible.
Slide 7
When is the problem caught
– May not be caught.
– Caught mostly at the system integration stage.
– Cost of Correction is high
a) Full System Debug.
b) Identify Component.
c) Component Debug.
Slide 9
1. Wasteful Jump to ISR, Slows down the execution. Program behaves differently.
2. Can at best measure down to timer period (threshold (least count)).
3. Falsely, may report very small latency
Interuptible
Non Interuptible
Program Counter
Interrupts
Main Code ISR
Finding Interruptability
Slide 10
Problems with this approach
1. Intrusive
• The act of measuring changes the application behavior.
2. Measurement Time α
(1 / Threshold) code keeps jumping to the ISR and the code could become
unnecessarily slower while measuring
3. Needs a lot of automation support to be built. Not
Trivial
Slide 12
Approach in Simulation
• Observe the Cause, not the symptom
– Monitor GIE disables, branch delay slots, NMI disables.
– Get the worst case latency for a test vector.
– Characterize the interrupt latency of the algorithm.
Slide 13
Inputs to the system
• Inputs
– Test Vector (Program File)
– Measurement Parameters
• Interrupt latency threshold
• Non Inputs– Interrupts (Need not give interrupts to measure the latency)
Slide 16
Output
• Summary Output– Maximum interrupt latency of the code
• Start and end PC
• Start and end cycle
• Trace Output– Instances when the interrupt latency exceeds the given threshold
• A trace of all instances of threshold access, with start and end pc and start and end cycle
• Debug Mode– Break the execution when the interrupt latency exceeds the specified threshold.
Slide 17
Interval 0, multiple such start and
stop are possible
Maximum Latency Data
Interrupt State at the start and end of the
measurement
Trace of All Instances when the
latency exceeds specified threshold
Slide 18
Summary of the tool
• Specify the initial settings in
– Simulator Configuration file.
• Load the Application.
• Load the int_lat_measure.gel file
• Identify your profile points and put breakpoints
• Run to BP. Start the profile of interrupt latency through gel command.
• Run to next BP and stop.
• Check the data obtained in the interrupt_trace.csv
Slide 20
Problem
• Customer reports Interrupt latency >125� sec
(sampling rate of 8KHz).
• The algorithm supplier quotes <10� sec based on
information from developers
Slide 21
Criticality
• Resulted in loss of interrupts – customer’s
application cannot work in real time
Slide 22
Previous ways to solve it
• First assume that the problem is due to GIE being disabled in one of the 100 scheduled assembly functions.
– (However, if GIE is properly restored, then profile all functions where interrupts are disabled – this might take 2-3 hours)
• Automate the test harness to detect the frame in which status of GIE is not restored
• Manually step through the code for that frame to detect the problem causing function (this might take an hour or so)
Slide 23
Using the tool
• Use the tool to get the Trace Output for instances
where Interrupt Latency exceeds 10� sec (6000
cycles)
• Able to directly get to the problem causing
function within 10 minutes irrespective of the
nature of the cause
Slide 24
Advantages
• Although in this case the assumption about GIE was true,
it may not necessarily be the case. Using the tool, no
such assumption is required
• No dependency on developer to know the Interrupt
Latency – such problems can be detected before release
• Interrupt latency can be quoted confidently