Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Embedded

Building interrupt responses into embedded SoC

Posted: 05 Sep 2013 ?? ?Print Version ?Bookmark and Share

Keywords:interrupt service routines? SoC? IP blocks? ADC? formal verification?

During normal operations, executing interrupt service routines (ISRs) through conventional approaches calls for 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 analogue-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 behavioural model to mimic actual analogue behaviour 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:

???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.
???Connectivity of interrupt bus from peripherals to the interrupt controller through static checks using formal verification techniques (IFV).
???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.

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 world design let's look at the following case study comparing the conventional approach to the one we propose: a defect resides in RTL logic for a scenario where the core sees the interrupt information when an FSM (finite state machine) within the core is at a particular state, in this case, 0x4 only. As a result the system hangs and a design fix is required in platform logic.

Figure 2: Proposed methodology for interrupt verification.

1???2?Next Page?Last Page

Article Comments - Building interrupt responses into em...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top