PCI configuration space
From Wikipedia, the free encyclopedia
PCI configuration space is the underlying way that the Conventional PCI, PCI-X and PCI Express perform auto configuration of the cards inserted into their bus. The useful feature was marketed by Intel with the name Plug and Play.
Contents |
[edit] Technical Information
One of the major improvements the PCI Local Bus had over other I/O architectures was its configuration mechanism. In addition to the normal memory-mapped and port spaces, each device on the bus has a configuration space. This is 256 bytes that are addressable by knowing the 8-bit PCI bus, 5-bit device, and 3-bit function numbers for the device (commonly referred to as the BDF). This allows up to 256 buses, each with up to 32 devices, each supporting 8 functions. A single PCI expansion card can respond as a device and must implement at least function number zero. The first 64 bytes of configuration space are standardized; the remainder are available for vendor-defined purposes.
In order to allow more parts of configuration space to be standardized without conflicting with existing uses, there is a list of capabilities. Each capability has one byte that describes which capability it is, and one byte to point to the next capability. The number of additional bytes depends on the capability ID.
PCI-X 2.0 introduced an extended configuration space, up to 4096 bytes. The only standardized part of extended configuration space is the first 4 bytes at 0x100 which are the start of an extended capability list. Extended capabilities are very much like normal capabilities except that they can refer to any byte in the extended configuration space (by using 12 bits instead of 8), have a 4-bit version number and a 16-bit capability ID. Extended capability IDs overlap with normal capability IDs, but there is no chance of confusion as they are in separate lists.
[edit] Standardized registers
The Vendor ID and Device ID registers identify the device, and are commonly called the PCI ID. The 16-bit vendor ID is allocated by the PCI SIG. The 16-bit device ID is then assigned by the vendor. There is an ongoing project to collect all known Vendor and Device IDs. (See external links (below).)
The Subsystem Vendor ID and the Subsystem Device ID further identify the device. The Vendor ID is that of the chip manufacturer, and the Subsystem Vendor ID is that of the card manufacturer. The Subsystem Device ID is assigned by the subsystem vendor, but is assigned from the same number space as the Device ID.
The Command register contains a bitmask of features that can be individually enabled and disabled.
The Status register is used to report which features are supported and whether certain kinds of error have occurred.
The Cache Line Size register must be programmed before the device is told it can use the memory-write-and-invalidate transaction. This should normally match the CPU's cache line size, but the correct setting is system dependent.
[edit] Bus enumeration
In order to address a device through port space or memory space, system firmware or the OS will program the Base Address Registers (commonly called BARs) by writing configuration commands to the PCI controller. Since all PCI devices are in an inactive state upon system boot, they do not have any addresses assigned to them by which the operating system or device drivers can communicate with them. Either the BIOS or the operating system itself geographically addresses the PCI slots (e.g. the first PCI slot, or the second PCI slot or the third PCI slot on the motherboard etc.) through the PCI controller. Since there is no direct method for the BIOS or OS to determine which PCI slots have devices and which functions they implement, the PCI bus(es) must be enumerated. Bus enumeration is performed by attempting to read the Vendor- or Device ID for each combination of bus, device, and function. If there is no device that implements the specified function, the bus master performs an abort and returns all 1's in binary (F's in hexadecimal). This is an invalid VID/DID so the BIOS or OS knows the specified device does not exist. If a read to function zero of a specified bus/device master aborts, then it is assumed that no such device exists on the bus since devices are required to implement function number zero. In this case reads to the remaining functions are not necessary.
When a read to a specified BDF succeeds, the BIOS or OS programs the memory and port addresses into the PCI devices' on-chip memory. These addresses stay valid as long as the system remains turned on. On power off, all these settings are lost and on the next system boot, the configuration procedure is repeated all over again. Since this entire process is fully automated, the computer user is spared the task of configuring any newly added hardware manually by modifying settings of dip switches on the cards themselves. This is how plug and play is implemented.
If a bridge is found, the system must assign the bus behind the bridge a bus number then enumerate the devices behind the bridge.
Each non-bridge device can implement up to 6 BARs, each of which can respond to certain areas of port or memory space. A device can have a ROM.
[edit] Hardware implementation
When performing a configuration space access, a PCI device does not decode the address to determine if it should respond, but instead looks at a special IDSEL input pin which is different for each slot. Further, it is required to decode only the low 11 bits of the address, and ignore the high 21 bits completely.
The intended, and typical, implementation has each slot's IDSEL pin connected to a different address/data line AD[11] through AD[31]. To configure the card in slot n, the PCI bus bridge performs a configuration space access with the PCI register address on lines AD[7:2] (AD[1:0] are always 0), the PCI function number on bits AD[10:8], and all higher-order bits zero except for AD[n+11].
To reduce loading on the critical AD[] bus, typically the IDSEL line is connected to AD[n+11] through a resistor. This causes the IDSEL signal to appear more slowly than other PCI bus signals (due to the RC time constant of the resistor and the IDSEL pin's input capacitance), so configuration space accesses are performed more slowly to allow time for the IDSEL signal to reach a valid level.
[edit] See also
[edit] External links
- PCI Vendor and Device Lists
- The Linux PCI ID Repository, a project to collect all known IDs
- PCI and PCI32 utilities, Craig Hart's freeware PCI Software suites and ID Database
