Bus Arbitration: Daisy Chain Bus
September 24, 2015
Contents
1
Buses
1
2
Bus Arbitration
4
3
Daisy Chains
5
4
Hidden Arbitration
6
5
Decentralized Arbitration
7
6
Conclusion
beamer
8
Homework and announcements
• Reading: Chapter 9
• Homework: On-line
• Slides online
• Reminder: Prelim 1 on October 7!
1
1.1
Buses
The problem
• Need to get information from one component to another
• Components to connect include:
– functional units of CPU
– CPU and memory
– CPU and I/O
1
– I/O and memory
• Point-to-point communication- Too many wires!
• Instead, use a bus – shared communication pathway
1.2
Buses
• Consists of wires + control circuitry
• Wires ≡ lines
• Lines carry binary information, sent in parallel
• Multiple devices share bus
– Can all send and receive
– No privacy
– Potential for collisions of data
1.3
CPU ⇔ memory
• Overall:
– CPU puts address of memory location on some bus lines
– CPU signals via another line if it’s a read or write
– If read: Memory puts data on bus lines
– If write: CPU puts data on bus lines
• Some buses: separate address, data lines
• Others: use two phases, address and data, on same lines
1.4
CPU ⇔ I/O
• Address, data lines
• Control lines
• Select line(s): which device to use
• Interrupt line
2
1.5
I/O ⇔ memory
• DMA: Direct memory access
• Frees up CPU – doesn’t have to monitor I/O
– tell I/O device what to do (read, write), and where (source, target of data in
memory)
– I/O and memory then coordinate, and CPU goes on to other tasks
• I/O, memory: use bus to communicate
• I/O device lets CPU know when done via interrupt
1.6
Interrupts
• Way of telling CPU something important has happened
• Keeps CPU from having to poll other hardware
• Examples:
– Normal interrupts: Disk is done with DMA, I/O devices done, key pressed,
etc.
– Abnormal: Temperature of CPU is too high, power failure, memory fault,
etc.
– Software interrupts – program wants OS to do something for it
1.7
Interrupts
• Mechanism:
– CPU checks for interrupts during fetch–execute–interrupt cycle
– Device puts 1 on interrupt line (“raises” an interrupt)
– CPU notices, suspends what it is doing – saving some state
– CPU executes preset interrupt-handling routine
– When done, restores state, continues what it was doing
1.8
Bus terminology
• System bus: connects memory, CPU, I/O (maybe via the “Northbridge” chip)
• Bus width: # of data/address lines
• Assert: put 1 on line (“raise” the line)
• Negate: put 0 on line (“lower” the line)
3
2
2.1
Bus Arbitration
Bus arbitration
• No physical reason multiple devices can’t simultaneously use bus
• However, would ⇒ collision – garbled information
• Bus arbitration controls which device gets bus
• Many different schemes, but for any:
– All devices must follow same rules (“protocol”)
– Do not send information unless allowed by arbitration
2.2
Centralized arbitration
• An arbiter decides which device gets bus
• Pros:
– Arbitration scheme can be simple
– Devices don’t need to include arbitration circuitry
• Cons:
– Cost of arbiter
– Arbiter → single point of failure
2.3
Decentralized arbitration
• All devices participate in arbitration – no arbiter
• Pros:
– Less costly
– No single point of failure
• Cons:
– More complicated for devices
– Arbitration scheme can be more complex
4
3
Daisy Chains
3.1
Daisy chain buses
• Devices hooked together in a chain – either control lines or bus itself
• Examples: SCSI, Thunderbolt, Firewire, MIDI – even USB, with specialized
connectors
Request Line
Arbiter
Grant Line
Device 1
Device 2
Device 3
Release Line
3.2
Centralized daisy chain arbitration
Request Line
Arbiter
Request Line
Arbiter
Grant Line
Device 1
Device 2
Device 3
Device 1
Release Line
Arbiter
Device 2
Device 1
Release Line
Device 1
Arbiter
Device 2
Device 1
Device 1
Device 2
Device 3
Device 2
Device 3
Release Line
Request Line
Arbiter
Device 2
Grant Line
Device 3
Release Line
Device 1
Release Line
Questions
Request Line
Arbiter
Device 3
Grant Line
Device 3
Grant Line
Device 3
Release Line
3.3
Device 2
Request Line
Grant Line
Device 2
Request Line
Arbiter
Release Line
Request Line
Arbiter
Device 1
Release Line
Grant Line
Device 3
Grant Line
Device 3
Request Line
Grant Line
Device 1
Device 2
Release Line
Request Line
Arbiter
Request Line
Arbiter
Grant Line
Grant Line
Device 1
Device 2
Release Line
5
Device 3
• How do devices know the bus is busy?
• If two devices request the bus at the same time, which gets it?
• Which device has highest (implicit) priority? Is this fair?
• Can a device starve – i.e., never get the bus? Under what conditions?
3.4
Adding priorities
• Can add priority levels to daisy chain arbitration
• Multiple grant and request lines, 1 per level
• Arbiter will assert grant line for highest level with request
• Ensures that high-priority device will not starve due to low-priority device
• Starvation still possible?
• Assigning priorities?
4
Hidden Arbitration
4.1
Hidden arbitration
• So far: arbitration occurs only when bus available
– No data sent while arbitration occurring
– Wastes time when data could be sent over bus
• Hidden arbitration – arbitration occurs while bus is in use ⇒ increased bus use
4.2
Daisy chain hidden arbitration
Request Line
Arbiter
Request Line
Arbiter
Grant Line
ACK
Device 1
Device 2
Device 3
Bus
Grant Line
ACK
Device 1
Device 2
Request Line
Arbiter
Grant Line
ACK
Device 1
Device 2
6
Device 3
Bus
Device 3
Bus
5
Decentralized Arbitration
5.1
One possibility
• n devices ⇒ n request lines
• Device i wants bus:
– checks to see if higher-priority device has request line raised
– if so, waits, if not, uses bus
• Needs additional circuitry/lines to determine if bus in use
• Used in some older computer systems (e.g., DEC’s VAX SBI bus)
• Could we use dlog2 ne lines? At what cost?
5.2
Another possibility for daisy chains
• Just replace the arbiter with an asserted grant line!
• ACK is now a “busy” line
• Device takes control of bus in usual way, but has to check busy line
5.3
Decentralized daisy chain
Busy Line
1
Busy Line
Grant Line
Device 1
1
Device 2
Device 3
Bus
Device 1
Busy Line
1
1
Device 2
Device 3
1.
2.
3.
4.
5.
6.
Bus
Device 1
Device 2
Device 3
Bus
Device 2
Device 3
Bus
Busy Line
Grant Line
Device 1
Device 3
Grant Line
Bus
Busy Line
1
Device 2
Busy Line
Grant Line
Device 1
Grant Line
1
Device 2
Device 3
Grant Line
Bus
Device 1
Initially, grant line passed throughout chain
When device wants bus and busy negated, negate grant line, assert busy
If another wants bus, senses busy, waits
When finished, negate busy, pass asserted grant
Device wanting bus now notices busy negated, asserts it and negates grant downstream
Device begins using bus
7
6
6.1
Conclusion
Why study daisy chains?
• Simple introduction to important topic – bus arbitration
• Used in some real systems
• Good to think about the idea of trade-offs
8