PCI Local Bus Signals
The PCI local bus, or PCI "Legacy" bus as it is called in common parlance, is a 32 or 64 bit bus capable of speeds from 33MHz to 533MHz, and it supports peripheral voltages of 3.3 andv 5v, though the bus itself specifies a 3.3v signaling environment. PCI peripherals may support 32 or 64 bit addressing transparently. Peripherals must support a minimum pinout of 47 pins for non-masters and 49 pins (+REQ and GNT for arbitration) for masters; but additional pins are specified which add support for features like JTAG, 64-bit addressing and data transfer, SMB I2C Management, IRQ pins and locked bus transactions.
The name "Local Bus" comes from the origins of the PCI bus, which are the IBM-PC ISA bus days, when the growing requirement for a high bandwidth connection to graphics cards caused vendors to experiment with the AGP bus, which was a wire connection that placed the graphics card close to the CPU, as opposed to being positioned behind the north or south bridge controller. From here, the PCI Local Bus's elder wizards (The PCI-SIG - PCI Special Interest Group) have carefully monitored its growth and expanded the specification, and enhanced its feature set. PCI found itself well positioned to then provide the locality of design required to support the bandwidth hungry consumer requirements imposed on new IBM-PC peripherals such as SCISI and Gigabit Ethernet IPs. Its Plug and Play software interface along with the care taken by PCI-SIG enabled it to present a single interface to software, even as the devices being added to its repertoire expanded rapidly.
This Wiki page is current with revision 3.0 of the PCI specification. This wiki page does not take the PCI Express bus into account. This page is not meant to serve as an exhaustive reference for the PCI Local Bus specification, but it is meant to function as a condensed refresher for an individual who has already read the PCI Local Bus specification.
The signals on this page are written up from the perspective of a peripheral card, since this page is describing the the card pinout for PCI peripherals. PCI Signals are active low unless stated otherwise here. PCI signals are latched on the rising edge of CLK. Some signals are only latched when they qualify for latching. I.e, when they have a meaning for the current ongoing transaction type.
|Type||Shortname (used throughout the docs)||Description|
|Input||in||Input signals are flows from a bridge or other agent to the card|
|Output||out||Output signals are flows from the card to another agent.|
|Tristate||t/s||Tristate signals are bidirectional flows to and from the card, which must be driven only by one agent at a time (obviously). Tristate signals may be in high, low or floating (High-Z/High impedance) state.|
|Sustained Tristate||s/t/s||Sustained tristate signals are active low signals which must be driven high for at least one clock cycle after they are driven active. I.e, after an agent drives a s/t/s signal active (low), when it wishes to relinquish control of the pin, it must drive it high for one signal before letting it float.|
|Open Drain||o/d||Open Drain signals are pulled up into the floating state unless explicitly driven by an agent.|
Signals with the type "core" are part of the minimum card pinout which is required of all devices. Signals without the "core" keyword are optional card pinouts.
|Name||Type||Relationship to CLK||Description|
|CLK||in, core||N/A||CLK is an input to every PCI device. All signal parameters including timing are defined relative to this signal. Valid clock speeds are those defined by the PCI and PCI-X specifications.|
|RST#||in, core||async||Reset brings all PCI-specific registers, sequencers and signals to a consistent state. The effect of RST# on a device beyond sequencers and PCI configuration regs is implementation defined. Devices which can wake the system have additional RST# requirements. On the assertion of RST#, all pci output signals must be driven to their benign state. REQ# and GNT# must be tristated. The central resource may drive AD, C/BE and PAR low to prevent floating, but not high. AD[63:32], C/BE[7:4] and PAR64 have special requirements when not connected (i.e, 64-bit card connected to a 32-bit host). Only devices which are required to boot the system will respond while in RST#, with the exception of configuration accesses.|
|AD[31:0]||t/s, core||sync||Address and Data lines 0-32. After the assertion of FRAME#, the first latch of clock will treat these as address signals. This first latch is called the Address phase, and during this latch, the C/BE[3:0] lines are latched and interpreted as an accompanying 4-bit command value. From the second latch of clock onward within a FRAME# active period, these pins when latched are interpreted as data bits. These subsequent latches are called Data phase latches, and during this latch, the C/BE[3:0] lines are latched and interpreted as byte-enables which state which of the 32 Data lines contain valid data -- each byte-enable pertains to one group of 8 lines of data.|
|C/BE#||t/s, core||sync||C/BE is a multiplexed signal - it can at any given moment either be in use as either a Command which accompanies the address phase or a Byte-Enable which accompanies the data phase.|
|PAR#||t/s, core||sync||Parity is invalid during the address phase, and becomes valid during the first data phase clock cycle and for all subsequent data phase cycles until FRAME# is deasserted, as long as TRDY# or IRDY# are also asserted.|
|FRAME#||s/t/s, core||sync||Cycle Frame is asserted at the start of a transaction and is held active for the duration of it.|
|IRDY#||s/t/s, core||sync||Initiator ready is used as a flow control mechanism. When the master is reading, it asserts IRDY# to state that it is ready to receive more data. When the master is writing, it asserts #IRDY to indicate to the slave that there is more data available for it to read.|
|TRDY#||s/t/s, core||sync||Target ready is used as a flow control mechanism. When the slave is being written to, if it has not yet asserted TRDY#, the master interprets the current cycle as a WAIT cycle and the master will relatch the same data on the next cycle.|
|STOP#||s/t/s, core||sync||This indicates that the slave is requesting that the master stop the current transaction.|
|LOCK#||s/t/s, core||sync||This guarantees a logically atomic transaction comprised of multiple transactions each with their own address and data phases. Lock is meant to be used by bridges. Non-bridge devices which assert LOCK# are not conformant with the PCI spec. The PCI-SIG is actively attempting to phase out and eliminate the LOCK# signal.|
|IDSEL||in, core||sync||"Initialization Device Select": This is used as a chipselect during configuration read and write transactions.|
|DEVSEL#||s/t/s, core||sync||When actively driven, this signal indicates that the asserting device recognizes itself as being the target of the current address phase.|
|REQ#||t/s, core, MASTERS ONLY||sync||Request is a signal to the central resource which forms part of the arbitration protocol. All devices have logically separate REQ# lines to the arbiter.|
|GNT#||t/s, core, MASTERS ONLY||sync||Grant is an indicator to the device from the central resource that is has control over the bus. All devices have logically separate GNT# lines from the arbiter.|
|PERR#||s/t/s||sync||Parity error: This is used to signal parity errors in data during any PCI transaction other than a "Special Cycle".|
|SERR#||o/d||sync||System Error: this is for reporting address and data parity errors on the "Special Cycle" command, or any other system error with a "catastrophic result".|
|INTA#, INTB#, INTC#, INTD#||o/d||async|| The interrupt lines must be used in order, from A to D. A device with only one IRQ must assert INTA#, and it may not assert INTB#/C#/D#, and so on. A single PCI function (bus/slot/function) may not generate IRQs on more than one line (i.e, only one IRQ per function). A device with multiple IRQs may wire each function to whichever INT# signal it wishes so long as that INT# signal meets the constraints outlined in the first sentence of this cell. PCI requires that the motherboard designer must connect every INT# line that is implemented to the IRQ subsystem on the motherboard. PCI devices must assume that they will be sharing an IRQ line on the motherboard's IRQ controller, and all PCI devices must be ready to play nicely with IRQ sharing, including with other functions within their own device package.
As you can see, PCI interrupt signals are active low, level triggered (open drain driven state is maintained by the device until the IRQ is acked).
Devices must ignore their GNT# lines while RST# input is asserted. The arbiter must ignore all REQ# lines while RST# is asserted.
These signals are extensions and they are not required of cards.
|Name||Type||Relationship to CLK||Description|
|PRSNT[1:2]#||in||Unknown||The present signals are meant only for add-in cards and are not required for all devices. It indicates when a card has been connected and what its voltage/power requirements are.|
|CLKRUN#||in, o/d, s/t/s||Unknown|
|M66EN#||in||unknown||This input to the device states whether the bus is being driven at 33 or 66 MHz.|
|PME#||o/d||async||This is used by devices to request a change in its own, or in the system's power state. Devices may not assert this signal without software permitting/enabling them first. Once asserted by the device, the signal is sticky until software clears it.|
|3.3Vaux||in||unknown||this is an additional 3.3V power input for add-in cards which enables them to participate in power management events when software has turned off main power to the device.|
|AD[63:32]||t/s||sync||These pins are the top 32 bits of a 64-bit transaction. They work the same as AD[32:0] except that their FRAME# signal is the REQ64# signal instead.|
|C/BE[7:4]||t/s||sync||These only act as command signals during the address phase when using the Dual Address generation feature. During the data phase they act as byte enables on the high 32 bits of the latched data for a 64 bit transaction.|
|REQ64#||s/t/s||sync||This, like FRAME# is asserted by the currently GNT#-ed bus master and it indicates that a frame is in progress.|
|ACK64#||s/t/s||sync||When this signal is driven by the device which has decoded the address of the address phase as its own, it indicates to the master that the device is willing to transfer data using 64-bits. It has the same timing and implicatins as DEVSEL#.|
|PAR64||t/s||sync||This is the upper DWORD parity signal which has the same function as the PAR signal, but for the AD[63:32] pins.|
|TCK, TDI, TDO, TMS, TRST||in, in, out, in in||unknown||These are JTAG pins for interacting with the card.|
|SMBCLK, SMBDAT||o/d||unknown||These are I2C pins for the SMBUS standard.|