Building high performance interrupt responses into an embedded SoC design - Embedded.com

Building high performance interrupt responses into an embedded SoC design

During normal operations, executing interrupt service routines (ISRs) using conventional approaches requires tight coordination between the system’s interrupt controller (INTC) and the core processor. In such cases the peripheral function’s interrupt requests are handled through the INTC, which collects all of the interrupts and passes them to the core processor, which then stores the ISRs in a status register on stack, after which it finally services the ISR.

During the design of a system-on-chip (SoC), however, verification of both hardware and software functionality can be problematic. Because additional IP blocks have been added for silicon testing purposes, more system clock cycles than normal are required, limiting the ability to exhaustively test the device. (See Figure 1 for this scheme of interrupt handling.)

To understand why this occurs, let’s consider a scenario in which an analog-to-digital convertor (ADC) is doing data conversion serially on its 16 channels with the aim of switching to another mode of operation (e.g., injected mode) in the middle of on-going conversion once we receive an interrupt from another IP, say a periodic interrupt timer.

In such a scenario, due to cumulative software delays latency in interrupt servicing as well as inability of the behavioral model to mimic actual analog behavior causes interruptions. By the time the core reaches actual execution of the ISR code, the first conversion is already over and the switch to new mode occurs in the middle of an ongoing conversion and cannot be made. As a result, even though it is a valid use-case in the SoC it is non-targetable through RTL simulation.

Such situations can be avoided with a methodology that provides a way to target and verify all specified and needed functionality. As shown in Figure 2 , the method needs to incorporate the following capabilities:

  1. generation of interrupts from peripherals, handshaking with IP interrupt (IPI) monitors and finally executing needed tasks and routines and clearing the interrupt bit in main code.
  2. connectivity of interrupt bus from peripherals to the interrupt controller through static checks using formal verification techniques (IFV).
  3. at most, one test case needs to be generated to check the design logic from peripheral-generated interrupt to interrupt controller to core servicing. This checks the “sanity” of the interrupt servicing through core which was is not done in Step 1.

The two-forked approach taken in Steps 1 and 2 is highly efficient and exhaustive in nature and is highly productive if used in a complimentary way. This is accomplished by doing away with the full path of the interrupt service routine execution flow from INTC to the core.

The static technique (Step 2) is an IFV-based formal verification and can be used to comprehensively verify the connectivity of each interrupt line from peripherals to INTC through the use of a test bench-independent formal verification setup which has zero probability of error. The verification is reliable (golden) with respect to source of interrupts from peripherals and their corresponding vector mapping into the INTC, and is derived from the design’s SoC Guide /Architecture definition document and then used as input to a formal check engine.

A fully automated script derives the formal assertions from the SoC guide to formally establish that the value at the peripheral interrupt port is the same as the corresponding interrupt vector at INTC.

We have tried this methodology in a number of different SoCs, and due to its completely formal nature, it can be used in the initial as well as subsequent phases of an SoC architectural design in a highly automated way. When used in conjunction with the scheme in Step 1 we can be sure of full interrupt verification.

Figure 1: Conventional approach to interrupt verification

Figure 2: Proposed methodology for interrupt verification

The elimination of the delay through the route of interrupt–>interrupt controller block–>core servicing, checking each source of interrupt using an ipi monitor plus IFV-based connectivity checking, shows a significant save in regression time as well saving tool and resource efforts, 100% coverage, and without missing out any source or being unable to reach a scenario due to the latency in the logic.

Testing the methodology
To see out this works in a real worlddesign let’s look at the following case study comparing the conventionalapproach to the one we propose: a defect resides in RTL logic for ascenario where the core sees the interrupt information when an FSM(finite state machine) within the core is at a particular state, in thiscase, 0x4 only. As a result the system hangs and a design fix isrequired in platform logic.

In the conventional approach (shownin Figure 3), there is an extra and unexpected transition (0x4->0xAon current_mode[3:0] ) in the state machine by the time the delayedinterrupt information reaches the core through the latency-prone logicin INTC.

As a consequence we miss out on hitting the valid cornercase scenario, which is achievable only if the interrupt reaches thecore on the previous state (current_mode[3:0] == 0x4 ) rather than thenext state (current_mode[3:0] == 0xA).

If the core saw theinterrupt information while it was in state 0x4, it was supposed tofurther trigger some functionality, which would have been consideredfaulty by RTL logic because it was getting masked, and as a consequencewas not caught in simulations, since core sees a state 0xA instead.

Figure 3: Simulations with conventional approach

  Function isr_routine();

  if (current_mode[3:0] == 0x4)
  …..
  core does functionality 1
  ……
  else if (current_mode[3:0] == 0xA)
  …..
  core does functionality 2
  ……
  else
  core does functionality 3
  …..
  …..

  endfunction

TheCorner case has a fault in the RTL logic, and is encountered only whenthe Core executes functionality 1 in the interrupt service routine(ISR).

Proposed approach
In our approach (Figure 4 ),we don’t wait for the information to reach through INTC to the core.Instead we use an interrupt monitor to keep snooping on the interruptbus. As soon as the monitor sees the interrupt, it will send a flag tothe core to execute the same routine but with bypassed latency, allowingus to achieve functionality 1 (shown in the figure). This makes thecorner case visible in the simulation, allowing us to see the fault inplatform logic because it is now unmasked and analyzable in RTLsimulations.

Figure 4: Simulations with proposed approach

Conclusion
Theelimination of the delay in route in Figure 1 by using the scheme inFigure 2 allows us to achieve results that were not possible earlier dueto the extra latency introduced by the additional test logic. Theseresults show a significant saving in iterative coding, analysis, anddebugging time for individual interrupt cases. Regression time was alsoreduced, thus saving tool and resource efforts as well as makingpossible 100% coverage because we can now depend on formal checking.

Neha Srivastava is a lead design engineer at Freescale Semiconductors (Noida, IndiaDesign Centre), working in the Automotive and Industrial Solution Group(AISG) for over 5 years. She has a Bachelor of Engineering (B.E.) degreefrom Birla Institute of Technology and has worked on multiple SoCs infront-end verification and Verification for Testing domain, with areasof interest being low power designs, safety architectures, and highperformance systems. She can be reached at

Aashish Mittal is a principle design engineer at Freescale Semiconductors (Noida,India Design Centre), working in the Automotive and Industrial SolutionGroup(AISG) for over 12 years. He has a Master of Technology fromBanaras Hindu University and has worked on multiple SoCs in front-endverification, Testbench Integration and Verification for Testing domain,with areas of interest being dual core, security, debug, and low powerarchitecture. He can be reached at

Nitin Goel issenior design engineer at Freescale Semiconductor India Pvt. Ltd ,working in the Automotive Microcontroller Group (AMCG) for over 6 years .He graduated from Netaji Subhash Institute Of Technology, Delhi in2006. Since then he has been working in frontend verification domain.Along with an experience in IP Level , SoC Level, and Core verification ,he has been working in Tester pattern development and debugging.

Amitav Halder is a principle design engineer at Freescale Semiconductor India Pvt.Ltd , working in the Automotive Microcontroller Group (AMCG) for overseven years . He graduated from MITS Gwalior and has worked extensivelyon SoC verification, testbench-integration formal verification, and lowpower verification. He can be reached at

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.