PCI Bus Requirements
This section summarizes requirements for the PCI bus.
16 System supports a 32‑bit bus architecture
For example, for PCI, the server system must support the 32‑bit physical address space, and PCI adapters must be capable of addressing any location in that address space.
17 PCI bus and devices meet Hardware Design Guide guidelines and PCI 2.1 requirements
Recommended: Two PCI controllers implemented as peer bridges to provide more effective bus bandwidth. Also, servers with more than 4 GB of memory should support the PCI dual address cycle (DAC) for the 64‑bit physical address space. DAC support does not preclude hardware from using 32‑bit addressing for better performance.
If PCI is present in the system, the PCI bus must meet the requirements defined in PCI Local Bus Specification, Revision 2.1 or higher (PCI 2.1), plus any additional PCI requirements in this guide. The system must also support the addition of PCI bridge cards, and all PCI connectors on the system board must be able to allow any PCI expansion card to have bus master privileges.
All server systems also must meet the PCI requirements defined in this section, which include requirements to ensure effective Plug and Play support. In particular, see the required implementation and exemptions for PCI 2.1 Subsystem Vendor IDs in the “Device IDs include PCI 2.1 Subsystem IDs” requirement later in this section.
18 Each PCI slot and device type has access to a non-shared interrupt line
Each PCI slot and PCI device type provided on a server system must have access to a non-shared interrupt line. Also, dedicated PCI interrupts must not use vectors from ISA bus interrupts.
This requirement does not prohibit sharing of an interrupt line by PCI slots or devices. In expansion card designs that implement multiple PCI functions behind a PCI-to-PCI bridge, PCI devices can share an interrupt line behind the bridge on that expansion card. Likewise, a similar design can be implemented on a system board.
The intent of this requirement is to ensure that all PCI slots and PCI device types can, when needed, obtain exclusive use of an interrupt line in cases where it is required for performance reasons.
19 System does not contain ghost cards
A computer must not include any ghost cards, which are cards that do not correctly decode the type 1/type 0 indicator. Such a card will appear on bus 0 and all the buses behind it that use the same IDSEL. As defined in PCI 2.1, a single-function card can decode the IDSEL and AD[1:0] pins and not decode AD[10::8] if the card does not have bit 7 set in the header type. This requirement also excludes, for example, devices that ignore some type 0 transaction bits and therefore appear at multiple device/function addresses.
A PCI card should be visible through hardware configuration access at only one bus/device/function coordinate.
20 System uses standard method to close BAR windows on nonsubtractive decode PCI bridges
PCI-to-PCI bridges must comply with the PCI to PCI Bridge Specification, Revision 1.0. Setting the base address register (BAR) to its maximum value and the limit register to zeroes must effectively close the I/O or memory window references in that bridge BAR.
21 PCI devices do not use the <1 MB BAR type
Devices must take any 32‑bit BAR address.
22 PCI devices decode only their own cycles
PCI devices must not decode cycles that are not their own to avoid contention on the PCI bus. Notice that this requirement does not in any way prohibit the standard interfaces provided for by the PCI cache support option discussed in PCI 2.1, which allows the use of a snooping cache coherency mechanism.
23 VGA-compatible devices do not use non-video I/O ports
Recommended: Device includes a mode that does not require ISA VGA ports to function.
A VGA-compatible device must not use any I/O ports that are not set aside for video in the PCI 2.1 specification.
24 PCI chip sets support Ultra DMA/33
For servers that implement PCI IDE connectivity, PCI chip sets must implement DMA as defined in SFF 8020i, and implement Ultra DMA/33 (also known as Ultra‑ATA) as defined in the specification submitted by Quantum Corporation for inclusion in the ATA 4 specification.
Ultra DMA/33 is required to avoid the bottleneck created by the current 16.6 Mb/s limit on IDE disk transfer. Ultra DMA/33 also provides error checking for improved robustness over previous IDE implementations.
An exemption exists for PCI IDE-connected CD‑ROM devices used solely for the purpose of software installation on a server system. Such devices cannot be used for any other purpose, including access to data by client systems. This exemption will not be allowed in the next version of these guidelines.
25 ISA Write Data Port address is propagated to ISA bus at power up
The requirement applies if the system uses an ISA bus in conjunction with a PCI bridge. At the time of power up and system reset, the Plug and Play ISA Write Data Port address must be propagated through the bridge to all ISA buses that might contain external ISA Plug and Play cards. This requirement ensures that the system can identify, isolate, and configure external Plug and Play ISA cards plugged into the ISA bus during the boot process.
26 Functions in a multifunction PCI device do not share writable PCI Configuration Space bits
The operating system treats each function of a multifunction PCI device as an independent device. As such, there can be no sharing between functions of writable PCI Configuration Space bits (such as the Command register).
27 Devices use the PCI 2.1 Configuration Space register for their Plug and Play device identifiers
The PCI 2.1 specification describes the Configuration Space register used by the system to identify and configure each device attached to the bus. The Configuration Space register is made up of a 256‑byte field for each device and contains sufficient information for the system to identify the capabilities of the device. Configuration of the device is also controlled from this register.
The Configuration Space register is made up of a header region and a device-dependent region. Each Configuration Space register must have a 64‑byte header at offset 0. All the device registers that the device circuit uses for initialization, configuration, and catastrophic error handling must fit within the space between byte 64 and byte 255.
All other registers that the device uses during normal operation must be located in normal I/O or memory space. Unimplemented registers or reads to reserved registers must complete normally and return zero. Writes to reserved registers must complete normally, and the data must be discarded.
All registers required by the device at interrupt time must be in I/O or memory space.
28 Device IDs include PCI 2.1 Subsystem IDs
All components must provide PCI 2.1 Subsystem IDs and Subsystem Vendor IDs with the exception of the following: PCI-to-PCI bridges, PCI core chips sets, and OEM-unique system board devices for system management that are not visible to the operating system. See the note at the end of this requirement for information about alternative solutions provided for Version 1.0 of this guide.
The following diagram shows the two registers added to the Configuration Space header for PCI 2.1. Although these registers are only recommended in the PCI 2.1 specification, they are mandatory in these guidelines. Support for these registers requires non-zero values to be populated for both the Subsystem ID and Subsystem Vendor ID.
New registers in Configuration Space header for PCI 2.1
31
|
16
|
15
|
0
|
|
Subsystem ID
|
Subsystem Vendor ID
|
2Ch
|
These fields are important for the correct enumeration of a device. When the Subsystem ID fields are populated correctly for your adapter, Windows NT can differentiate between adapters based on the same PCI chip.
The Subsystem ID also allows Windows NT to load system miniports for system board devices. Thus, Subsystem IDs are also a requirement on system board devices, but not for core chip sets or PCI-to-PCI bridges.
Two methods can be used to implement a Subsystem Vendor ID:
Load the value by hardware methods—for example, pin strappings at RST, an attached parallel or serial ROM, and so on.
Program the Subsystem Vendor ID using BIOS. Two designs using the BIOS method meet the requirements in these guidelines:
Make a copy of the Subsystem Vendor ID in PCI user-defined space. Any writes to this location will change both the copy and the Subsystem Vendor ID field. Any writes to the Subsystem Vendor ID are discarded.
Make a write-enable bit in the PCI user-defined space. The BIOS can turn this bit on, change the Subsystem Vendor ID, and then turn it off.
For more information, see the article titled “IDs and Serial Numbers for Plug and Play” at http://www.microsoft.com/hwdev/busbios/.
Note: Multiple-monitor support allows display class devices to be initialized independent of the system initialization process. For this reason, system‑board and add-on display devices cannot use the VGA BIOS POST routine to populate the Subsystem Vendor ID because the device’s POST code might not be executed until later in the process, after device enumeration occurs. For system-board devices, the system BIOS should populate the Subsystem Vendor ID at power on. Add-on display adapters should provide a method for populating the Subsystem Vendor ID at the point when power is applied and the device is initialized to the state that it is ready for POST.
Important: It is recognized that Hardware Design Guide Version 1.0 for Windows NT Server will be in effect during a transitional period for many vendors who are implementing PCI 2.1 Subsystem Vendor IDs. Therefore, an alternative solution is defined that will be allowed only under Version 1.0 of these guidelines. Under this solution, when a system is submitted for compliance testing, the system’s supplier must prove to Microsoft that all PCI devices recognized by the operating system will always be properly identified by the operating system so that the correct driver is loaded. This group includes all PCI devices that are not specifically exempted and that do not supply PCI 2.1 Subsystem Vendor IDs. This provision encompasses the following cases:
In cases where a PCI device that does not provide PCI 2.1 Subsystem Vendor IDs is used by multiple IHVs and OEMs, the system supplier must show that the proper driver will load in two configurations: (1) when the device is the sole instance in the system, and (2) when it is used simultaneously with another vendor’s implementation. In the latter case, both instances of the device must load the proper driver as determined by the vendor implementing the device. This correct loading must be shown by testing both with the
OEM-provided version of Windows NT and the retail release.
In cases where a PCI device that does not provide PCI 2.1 Subsystem Vendor IDs is proprietary to a single vendor and is enumerated by the operating system, the system supplier must show that the proper driver will load under both the OEM-provided version of Windows NT and the retail release.
In either of these cases, the appropriate driver or drivers must be loaded in compliance with all relevant guidelines in this document, including support for unattended installation. Vendors cannot meet these alternative requirements by invoking a manual installation solution to work around the operating system’s inability to determine the difference between devices that do not implement PCI 2.1 Subsystem Vendor IDs.
29 Configuration Space is correctly populated
Windows NT places extra constraints on a few configuration registers. Microsoft provides a program named Pci.exe to help debug the use of the Configuration Space. This program is available at http://www.microsoft.com/hwdev/busbios/.
The following items are specific requirements for the Configuration Space:
The class code register (09h) must be populated for all devices.
Follow the base class, sub-class, and programming interface values outlined in PCI 2.1.
Devices must not fill the BARs with random values.
See PCI 2.1 for the correct usage of these registers. Notice that BARs (10, 14, 18, 1C, 20, and 24h) should return zero if they are not used, indicating that no memory or I/O space is needed.
Run-time registers for PCI devices must not be placed in the configuration space.
30 Interrupt routing is supported using ACPI
The system must provide interrupt routing information using a _PRT object, as defined in Section 6.2.3 of Advanced Configuration and Power Interface Specification, Version 1.0 or higher.
31 BIOS does not configure I/O systems to share PCI interrupts
This applies to boot devices configured by the BIOS on systems that use Intel Architecture processors. The operating system should configure all other devices.
32 BIOS configures boot device IRQ and writes to the interrupt line register
This requirement does not apply for RISC-based servers. This requirement applies only to boot devices configured by the BIOS. All other devices should be configured by Windows NT because, after an interrupt request (IRQ) is assigned by the system BIOS, Windows cannot change the IRQ, even if necessary. If the BIOS assigns the IRQ and Windows needs it for another device, a sharing problem occurs.
The BIOS must configure the boot device IRQ to a PCI-based IRQ and write the IRQ into the interrupt line register 3Ch, even if the BIOS does not enable the device. This way, the operating system can still enable the device with the known IRQ at configuration time, if possible.
33 Hot swapping for any PCI device uses ACPI-based methods
Windows NT 5.0 supports dynamic enumeration, installation, and removal of PCI devices only if there is a supported hardware insert/remove notification mechanism.
The hardware insert/remove notification mechanism must be implemented as defined in Section 5.6.3 of the ACPI 1.0 specification. To properly function with the native support in the operating system, developing industry standards such as those referred to as PCI Hot Plug and Compact PCI must use ACPI-based methods for supporting hardware insertion and removal as defined in the ACPI 1.0 specification.
34 System supports a 64‑bit bus architecture
For example, the server system with a 64‑bit PCI bus should support the 64‑bit physical address space, and 64‑bit PCI adapters must be able to address any location in that address space.
35 All 66‑MHz and 64‑bit PCI buses present in a server system meet Hardware Design Guide and PCI 2.1 requirements
If PCI buses that are 66 MHz, 64 bit, or both are present in a server system, all devices connected to these buses must meet the requirements defined in PCI 2.1.
It is recommended that 33‑MHz/32‑bit PCI devices and 66‑MHz/64‑bit PCI devices be placed on separate PCI buses to allow the best use of I/O bandwidth in a server system.
| 