MityDSP-PRO Interrupt Routing¶

This section outlines interrupt routing between the FPGA and the DSP on the MityDSP-6455 (the MityDSP-PRO). The text below is a summary, additional details can be found in the first portion of the MityDSP Training, Day 2 [pdf] presentation.

There are 2 lines connected between the FPGA and the DSP intended for interrupt use. On the DSP, 2 GPIO pins are used for interrupt handling (GP [4] and GP [5]). On the FPGA, for example in the MityDSP-Pro.vhd boot image top level, the corresponding pins are called "o_dsp_int4 and o_dsp_int5".

FPGA interrupt routing¶

In a typical MityDSP application, the base_module.vhd core is responsible for raising each of the interrupt lines.

On the PRO (MityDSP-6455), the base_module accepts 16 inputs for each interrupt line and combines them with a local register mask in order to assert an interrupt line. When the line is raised, the DSP must read the state of the interrupt inputs (via a register) and determine, for each interrupt line, which of the 16 interrupts are pending and service them appropriately to clear the interrupt condition. It's a basic 16-to-1 vectoring scheme as shown in the figure below (representing the base module interrupt logic):

In the FPGA, core modules are allocated 1 interrupt line and hooked to the base module. The cores include, as part of their version register (at offset zero in each core), the interrupt line and vector that they are hooked to. This allows the software to essentially probe a core and determine how it's interrupt is routed without having intimate knowledge of the FPGA design.

Software interrupt handling¶

The MityDSP core library provides a C++ class (tcDspInterruptDispatch) that handles both of the GPIO interrupts (GP [4] and GP [5]) from the FPGA. The C++ class API provides a mechanism to register for a vector level callback (within an ISR context). All of the MDK core driver class APIs that interface with an FPGA core that uses interrupts use this API for initial interrupt handling. Some classes, like the tcDspGpio do provide hooks for application level interrupt handling.

Skipping the Framework¶

If you choose not to use the tcDspInterruptDispatch class for interrupt routing, you can plug your own ISR handler for GP [4] or GP [5] interrupts. Critical Link may not be able to support any troubleshooting activities if you choose this path.