Processor support devices Part 1: Interrupts and shared memory

1. Processor support devicesPart1: Interrupts and shared memory dr.ir. A.C. VerschuerenEindhoven University of TechnologySection of Digital Information Systems

2. What are 'processor support devices'? • Processor support devices extend the functionality of the processor core • This includes almost everything in a computerexcept the input/output control logic • Can add exactly the needed amount of functionality • But ends up with a lot of separate hardware parts • Which must be interconnected, slowing down the system

3. Integrate processor support with CPU • Good example: • Intel 80486: 32 bits CPU,memory management (segmenting & paging),floating point co-processor, 'caches' • Not so good example: • Philips 68070: 32 bits CPU,DMA and interrupt controllers,timers, standard and I2C serial input/output I/O is NOT‘processor support’

4. ‘interrupt request register’: requested but not started yet ‘in service register’: routine started but not finished yet vector interruptrequestreceiver maskregister& logic priority &selectionlogic interruptrequests vectorgenerator request& vectortransfer CPU interface 'interrupt handled’ enable/disable modesettings vectorsettings (I/O ports) Interrupt handling • The number of interrupts varies a lot (0.. >200) • Use separate interrupt controller devices to accomodate

5. 1 1 2 2 priority 8 3 8 3 lowestpriority! interrupt4handled 7 4 4 7 6 5 6 5 Equally important interrupts • Giving these fixed priorities leads to 'starvation' • The lowest priority never gets handled (or very slow) • Solution: use 'rotating priority' within such a group

6. interrupt slavecontroller1 vector interrupt mastercontroller request interrupt inputs vector handshake slavecontrollerN slave selectionfor vector generation ‘Cascading’ to get more interrupt inputs • Master should not disable slave input during interrupt • Limited capabilities for rotating prioritiesonly within slaves !

7. 'false' in controller1 interrupt vector out vector interrupt inputs handshake in interrupt controllerN request out ‘Daisy chaining’ to get more interrupts No request:outin • Very slow: signals must pass through all controllers • Inflexible: priority determined by placement in chain Active request:out‘true’ Give vector if:out AND (NOT in)

8. The end of an interrupt routine • Controllers need to know when a routine ends • To allow the next interrupt on the same input • To restore interrupt masks to their original status • To modify priorities in a rotating priority group • This event is completely determined by software! • Use special RET instruction, 'visible' to controllers • Inform the interrupt controllers with I/O operations

9. read read write (2-ported) write CPU I/O device addr addr memory data data Shared memory • Direct Memory Access allows both the CPU and I/O devices access to the same main memory • The fastest solution: multi-ported shared memory • CPU and I/O memory accesses do not interfere • Real 2-port memory is very expensive,3 ports and up is not available!

10. read read write write CPU I/O device addr addr memory wait data data wait arbiter fast(er) memory Shared memory with an arbiter • Multi ported memory may be simulated with an ‘arbiter’ and a higher speed (normal) memory True simultaneous access is impossible! May haveto wait ! Fast memory is expensive !

11. read read write write sharedmemory sharedmemory I/O device I/O device addr addr data data read select select write CPU addressdecoder addr data select privatememory Combine shared and private memory • Communication confined to a small memory area • CPU works mostly in private memory:using an arbiter does not degrade performance! Simple to have more devices

12. input/outputmodule I/O proc.+ memory+ I/O ports globalmemorymodule main proc.+ memory ? ! arbiter arbiter ? ! system bus Modular systems • Access to the system bus and shared memories requires arbitration ( = ‘data traffic control’)

13. I/O proc.+ memory+ I/O ports globalmemorymodule main proc.+ memory 2 1 2 3 Localmemory Localmemory 1 arbiter Sharedlocalmemory Sharedlocalmemory arbiter 2 2 3 3 Globalmemory Globalmemory Mainprocessor I/Oprocessor Memory mapping • Mapping done by address decoding hardware • Which can place memories at different addresses ! • Shared local memories require complex arbiters

14. ‘Standard’ system buses • Standardisation needed for ‘plug and play’ • A lot of them exist (Multibus, VME, EISA....) • Multibus designed by Intel for 80x86 series • VME busdesigned by Motorola for 680x0 series • They compete for the most complex protocols • Bus signals optimised for one processor (series) • Using an Intel processor on a VME bus is not simple

15. DMArequest DMArequest DMAgrant DMAgrant request readwritedataaddress readwritedataaddress CPU I/O HW grant CPU has bus CPU releases I/O HW has bus Memory CPU takes bus back Shared bus Direct Memory Access • A protocol must be used to transfer bus mastership • Slower than shared memory solutions • I/O hardware must create all processor bus lines !

16. DMArequest inoutreadwritedataaddress inoutdata DMAgrant I/O CPU IOrequest Simple interface ! DMArequest inoutreadwriteaddress DMAgrant readwritedataaddress DMAcontrol Memory IOreq Using a separate DMA controller • DMA controller can handle multiple I/O requests • Requires the same functionality as multiple interrupts (masking, priorities...)

17. Types of DMA controllers (1) • Direct processor controlled DMA (generation 1) • Transfers one data block at a time • Requires main processor support for each data block • Instruction list controlled DMA (generation 2) • Transfers multiple data blocks autonomously • Controlled by command (linked) list in memory

18. mainprocessor DMAco-processor I/O hardware mainmemory DMAmemory Types of DMA controllers (2) • DMA co-processors (generation 3) • Handle I/O tasks including transfer of data blocks • Run their own programs (stored in DMA memory), controlled by 'messages' in main memory