Interrupts in Detail

A hardware and software look at interrupts

Blackfin MASKS and LatchesSame hardware in concept as previous slides

INSTR PHASE 1FETCH AN INSTRUCTION FROM PROGRAM MEMORY

INSTR PHASE 2 DECODE THE INSTRUCTION AND FETCH ANY VALUES NEEDED FROM REGISTER OR MEMORY

INSTR PHASE 3 EXECUTE THE INSTRUCTION

INSTR PHASE 4 WRITE BACK THE RESULT

The “standard” instruction cycleRESETTHE PROCESSOR

RESET*(ACTIVE low)

EXECUTING‘YOUR PROGRAM’

UNTIL POWER IS REMOVED

The “standard” instruction cyclewith external device having important data

RESETTHE PROCESSOR

RESET*(ACTIVE low)

EXTERNAL HARDWARE

Control signal – I have data for you

16-bits This is the data

Control signal – ThanksProcessor has received data

Checkif

ready

INSTR PHASE 1FETCH AN INSTRUCTION FROM PROGRAM MEMORY

INSTR PHASE 2 DECODE THE INSTRUCTION AND FETCH ANY VALUES NEEDED FROM REGISTER OR MEMORY

INSTR PHASE 3 EXECUTE THE INSTRUCTION

INSTR PHASE 4 WRITE BACK THE RESULT

The “wait till ready” approach of reading data from external device

In decode phase – read control register valueIn execute phase – check if 1-- keep waiting (fetch-decode-execute-writeback instruction cycle) until

the control value changes from 0 (device not ready) to 1 (device ready)

When 1 – go to a different part of your program code to read the datae.g. call ReadData( )

Then your program must send an acknowledge back to device that the data has been read. e.g. call AcknowledgeReadData( ).

The device can then go and get more values for you.

PROBLEM: You have no time to do anything else other than waitNot a problem if waiting for this device is the only thing you want to do

with the processor

The “Poll approach” of getting dataNot much waiting – but a lot of “doing”

read control register value of device 1-- if 1

go to a different part of the code to “read the data” (ReadData1( ) ) – after reading the data send an acknowledge signal back to device 1 (AcknowledgeReadData1( ) )

-- if 0go and read the control value of device 2 – don’t worry about device 1 for some time

read control register value of device 2-- if 1

go to a different part of the code to “read the data” (ReadData2() ) – after reading the data send an acknowledge signal back to device 2 (AcknowledgeReadData2( ) )

-- if 0go and read the control value of device 3 – don’t worry about device 2 and 3 for

some time

ETC

PROBLEM: What happens if, while you are handling device 2, device 1 has “time sensitive information” that will disappear if device 1 is not serviced immediately

Interrupt Approach – basic ideaExtra “phase” in instruction cycle

RESETTHE PROCESSOR

RESET*(ACTIVE low)

PHASE 1FETCH AN INSTRUCTION FROM “NORMAL” (NOT ISR)PROGRAM MEMORY

PHASE 2DECODE THE INSTRUCTION AND FETCH ANY VALUES NEEDED FROM REGISTER OR MEMORY

PHASE 3EXECUTE THE INSTRUCTION

PHASE 4WRITE BACK THE ANSWER

EXTERNAL HARDWARE

16-bits data

PHASE ANY-TIME

CHECK IF ANINTERRUPT

REQUEST HAS OCCURRED

CONTROL SIGNALDATA READY SIGNAL

BECOMES INTERRUPTREQUEST

NO

yesDOISR

CONTINUEAS BEFORE

Acknowledge Request done

Simple model of interruptsFetch

DecodeExecute

WritebackFetch

DecodeExecute

Writeback

FetchDecodeExecute

Writeback

ISR Instr1ISR Instr2ISR Instr3

RTI

Every instruction has four phasesthat execute in turn

Next instruction’s Fetch phase is stopped

ISR executed

Blocked Instruction is restartedafter ISR RTI instructionFetch INT

Real Life -- Processor has pipelined instructions

FetchDecode

Execute

Writeback

Fetch

DecodeExecute

Writeback

FetchDecode

ExecuteWriteback

FetchDecode

Execut

Fetch

DecodDecodeExecute

Writeback

FetchDecode

ExecuteWritebac

Pipelining still means that each instruction takes 4 cycles to complete

However a new instruction only takes an extra 1 cycle to complet

So overall the processor is running 4 times faster

Blackfin – 10 stage Pipeline

Real Life -- Processor has pipelined instructions

DecodeExecute

Writeback

Fetch

DecodeExecute

Writeback

FetchDecode

ExecuteWriteback

FetchDecode

ExecuteWritebac

Fetch

DecodeExecute

FetchDecode

ExecuteWriteback

ExecuteWriteback

INT

Real Life -- Processor has pipelined instructions

e

Writeback

eExecute

Writeback

DecodeExecute

FetchFetchDecode

k

ISR F1

ISR D1ISR E1

ISR W1

ISR F2

ISR D2ISR E2

ISR W

RTI F

RTI ISR …

ISR …

ISR

INT

Real Life -- Processor has pipelined instructions

ckte

hde

ISR F1

ISR D1ISR E1

ISR W1

ISR F2

ISR D2ISR E2

ISR W2

RTI F

RTI DRTI E

RT

ISR …

ISR …

ISR …

FetchDec

Fe

INT

After RTI Decode phase(RETI register

has been recovered)

The processor know enough to be ableto restart the pipeline

Real Life -- Processor has pipelined instructions

ISR W1ISR E2

ISR W2

RTI F

RTI DRTI E

RTI W

ISR …

ISR …

FetchDecode

ExecuteW

FetchFetchDecode

E

After RTI Execute phaseRETI register has been recovered

It can be REGISTER FORWARDED TO THE PCWithout waiting to actually be stored somewhere

The processor know enough to be ableto restart the pipeline

Blackfin interrupt pipeline looks like this (see reference sheet)

Real Life -- What happens ifInterrupt occurs between

DecodeExecute

Writeback

F CC =

D CC = E CC =

W CC =

F IF CCD IF CC

E IF CC

FetchFetchDecode

ExecuteWriteback

INTRTI E

RTI W

FetchDecode

ExecuteWri

FetchD

FetchDecode

E

F IF CCD IF CC

E IF CCW

AFTER ISRWe must be able to

complete IF CC operation

Condition code bitCC is therefore a

‘non-volatile register’

Part of the Blackfin STAT register

CC = R1 <= R2

IF CC JUMP

Your Assignment 2Watchdog time ISR DEFECT – written as subroutine by mistake

WATCHDOG

EXAMPLE NOT CORE-

TIMER NEEDED FOR ASSIGNMENT

2

CLI – stop interrupts (CLear IMASK a

Makes sense as SSYNC means ‘finisSTI -- restart interrupts (STore R

This is not ending in RTI but RTS

If you put this into EVT(Event Vector Table)

It will fit

BUT CRASH THE SYSTEM WHEN USED

Your Assignment 2Watchdog time ISR -- Correctly written

Save CC (ASTAT)and then any register used (P0

Compare uses R7 but does not chaAlways jump

So R7 is never actually loaded usinRecover P0And then CC

This code is simply to fix the “ANpipeline code

Compiler “knows” that going to

Call a subroutine during ISR

So saves “every register” that might get changed as

“all registers are non-volatile during ISR

SUB code ISR code body

ISR – Must be fastStep 1 – turn on C++ Optimizer

Turn on optimizer for ISRNo optimizations possible

Look at new version of ISR code without

“UpdateSimulation” call

Writing an ASM ISRfor Post Lab 3 Quiz

Step 1 – Write the subroutine version of the code to be used inside the ISR

Step 2 – Identify all registers being usedAll volatile AND non-volatile

Step 3 – Start ASM code as follows

.section program

.global _ISR_ISR:

Special code to handle silicon race issues (State – don’t include

.section program.global _ISR

_ISR:Special code to handle silicon race issues (State – don’t include

code)

Link 0x0 (Saves RETS and FP)[--SP] = ASTAT Show the volatile AND nonvolatile registers being saved to stack

(eg. [--SP] = R0; [--SP] = P0; [--SP] = R1; [--SP] = P2 etc.)Essentially the subroutine code (optimized as much as possible)

REMOVE RTSShow the registers being recovered from the stack (reverse order)

(eg. Etc. P2 = [SP++]; R1 = [SP++]; P0 [SP++]; R0 = [SP++])

ASTAT = [SP++];UNLINK

RTI -- and the most important differenceREMEMBER – FAST ISR means only save registers used – no more

NMI interrupt

Looks the same

But different hardware causes interrupt

Means use RETN register not RETI