Difference between revisions of "Bus grant line"
m (+see also) |
(Mention the race between a new request and an old grant; add clarification about basic operation) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | '''Bus grant lines''' are used in a number of bus architectures (for example, the [[UNIBUS]] and [[QBUS]]) for the [[Central Processing Unit|CPU]] (or whatever circuitry is controlling the bus) to communicate to [[device controller]] | + | '''Bus grant lines''' are used in a number of bus architectures (for example, the [[UNIBUS]] and [[QBUS]]) for the [[Central Processing Unit|CPU]] (or whatever circuitry is controlling the bus) to communicate to a [[device controller]] that its request for an [[interrupt]] or [[Direct Memory Access|DMA]] has been [[bus grant|granted]] (hence the name). The CPU does this by sending a [[pulse]] down the grant line, to the device controller, to notify it. |
| − | + | Such lines are usually wired in series, so that one device's 'grant out' line is connected to the next device's 'grant in' line, starting the CPU's 'grant out' line. When a device sees a 'granted' pulse on one of its grant in lines, '''if''' the device had requested an interrupt/DMA, it 'consumes' the grant pulse, and goes on to do the type of operation it requested; if it was '''not''' requesting that type of operation, it 'passes' the grant by generating a 'granted' pulse on its grant out line. | |
| − | In | + | (A perceptive reader may have noticed that there is a potential [[race]] here, between an incoming grant, previously sent by the CPU in response to some ''other'' device's request, and a ''new'' request just raised by the device. For a more detailed discussion of this topic, see [[Bus Arbitration on the Unibus and QBUS|here]].) |
| + | |||
| + | In such series-wired systems, when there are conflicting requests for the bus, the requests are prioritized based on the devices' location on the bus; the ones closest to the CPU have the highest priority. | ||
On systems which have [[backplane]]s into which devices can be plugged, it is usually necessary to provide some means for a grant to 'jump over' an empty backplane slot; for the UNIBUS, this is done with either a [[G727 grant continuity card|G727]] or a [[G7273 grant continuity card]]. | On systems which have [[backplane]]s into which devices can be plugged, it is usually necessary to provide some means for a grant to 'jump over' an empty backplane slot; for the UNIBUS, this is done with either a [[G727 grant continuity card|G727]] or a [[G7273 grant continuity card]]. | ||
| Line 9: | Line 11: | ||
==See also== | ==See also== | ||
| − | * [[ | + | * [[Non-Processor Request and Grant]] - UNIBUS DMA request and grant lines |
| + | * [[DMA Request and Grant]] - QBUS DMA request and grant lines | ||
| + | * [[M8264 No-SACK Timeout Module]] - in particular, the [[M8264 No-SACK Timeout Module#Functionality discussion|Discussion]] section | ||
[[Category: Hardware Basics]] | [[Category: Hardware Basics]] | ||
Latest revision as of 19:03, 27 July 2025
Bus grant lines are used in a number of bus architectures (for example, the UNIBUS and QBUS) for the CPU (or whatever circuitry is controlling the bus) to communicate to a device controller that its request for an interrupt or DMA has been granted (hence the name). The CPU does this by sending a pulse down the grant line, to the device controller, to notify it.
Such lines are usually wired in series, so that one device's 'grant out' line is connected to the next device's 'grant in' line, starting the CPU's 'grant out' line. When a device sees a 'granted' pulse on one of its grant in lines, if the device had requested an interrupt/DMA, it 'consumes' the grant pulse, and goes on to do the type of operation it requested; if it was not requesting that type of operation, it 'passes' the grant by generating a 'granted' pulse on its grant out line.
(A perceptive reader may have noticed that there is a potential race here, between an incoming grant, previously sent by the CPU in response to some other device's request, and a new request just raised by the device. For a more detailed discussion of this topic, see here.)
In such series-wired systems, when there are conflicting requests for the bus, the requests are prioritized based on the devices' location on the bus; the ones closest to the CPU have the highest priority.
On systems which have backplanes into which devices can be plugged, it is usually necessary to provide some means for a grant to 'jump over' an empty backplane slot; for the UNIBUS, this is done with either a G727 or a G7273 grant continuity card.
See also
- Non-Processor Request and Grant - UNIBUS DMA request and grant lines
- DMA Request and Grant - QBUS DMA request and grant lines
- M8264 No-SACK Timeout Module - in particular, the Discussion section
