Reading device identity from configuration space

A PCI Express function reports its identity through a small set of read-only registers in configuration space: Vendor ID, Device ID, Revision ID, Class Code, Subsystem Vendor ID and Subsystem ID. These fields are written by the silicon vendor and the board integrator, not by the driver, and they are the first thing enumeration software reads before any BAR is assigned or any driver is bound. The nameplate on the package and the register contents usually agree, but they answer different questions, and the gap between them is where most identity bugs live.

What does a device identity register hold?

Configuration space begins with a 64-byte header. The first two words are fixed by specification: offset 0x00 holds the Vendor ID, a 16-bit value assigned by the PCI SIG to the company that sells the silicon, and offset 0x02 holds the Device ID, chosen by that same vendor. Offset 0x08 carries the Revision ID, an 8-bit field the vendor increments when the die or firmware changes. Offset 0x09 is the Programming Interface, offset 0x0A the Subclass, and offset 0x0B the Base Class, together forming the 24-bit Class Code that tells software what kind of function this is. Offsets 0x2C and 0x2E hold the Subsystem Vendor ID and Subsystem ID, which belong to whoever built the add-in card or soldered the part down.

A driver that binds on Vendor ID and Device ID alone is binding on the silicon. A driver that also matches Subsystem ID is binding on the board. That distinction decides whether one binary can serve several assemblies. The same reading discipline applies outside the bus: a diesel genset is identified from the data plate before any maintenance decision is taken, and the genset nameplate fields of rating, frequency and serial number play the role that Vendor ID and Device ID play here. In both cases the label is the contract and the register is the report.

Why can two identical boards report differently?

Two boards that look the same on the bench can enumerate with different Device IDs or different Subsystem IDs. The common causes are mundane. A die revision may carry a new Device ID because the vendor chose to distinguish it rather than rely on Revision ID alone. A second-source build may use a different silicon vendor entirely, so the Vendor ID changes while the board outline does not. A board variant with a different connector, a different power stage or a different EEPROM load may be given its own Subsystem ID so that one driver package can select the right configuration.

There is also the case of the same silicon on two cards. The Vendor ID and Device ID are identical, and only the Subsystem Vendor ID and Subsystem ID separate them. Software that ignores the subsystem pair will treat both cards as one product and may load a driver tuned for the wrong one. Conversely, software that matches on Subsystem ID too tightly will refuse to bind when a card is revised, even though the silicon is unchanged.

A third cause is configuration itself. Some functions load identity values from an external serial memory or from straps sampled at reset. If that memory is blank, corrupted or programmed for a different SKU, the register reports what the memory says, not what the die is. This is why a board can pass on one assembly line and fail on another with no silicon difference at all.

What does the nameplate not tell a driver?

The nameplate is a human-readable summary: manufacturer, model, rating, serial number, sometimes a date code and a compliance mark. It does not carry the Vendor ID, it does not carry the Class Code, and it does not tell software which register offsets are implemented. A driver cannot parse a label. It reads the header, checks the Class Code to decide whether this is a storage, network or display function, then looks at the Vendor and Device pair to pick a code path.

The nameplate also omits capability. Two units with the same model number may differ in lane width, in supported link speeds, in whether they implement the Power Management Capability or the Advanced Error Reporting Capability. Those are read from the capability list in configuration space, not from the label. A driver that assumes a capability because the model number suggests it will fault on the unit that lacks it.

Finally, the nameplate does not record the firmware revision. The Revision ID in configuration space does, at least to the granularity the vendor chose. When a field failure is traced to a firmware change, the register is the evidence and the label is not.

Where the two readings meet

The register and the nameplate are two views of one object. The register is what software can act on; the nameplate is what a person can act on. Neither is complete. A qualification record that holds both, taken at the same moment from the same unit, is the only version that settles an argument later. Read the header first, read the label second, and write down both before the unit leaves the bench.