A printer ASIC was designed to be just a PCI Express endpoint so some of the configuration registers were hard-coded as such and it was used in a printer model. Sometime later, for a new printer model, the engineers wanted to use the ASIC as a root complex to bridge to other PCI Express devices on a different bus. However, since the PCI Express configuration registers in the ASIC were hard-coded as an endpoint, the standard discovery process would not search for another bus connected to that ASIC. Fixing the ASIC to make it configurable as a root complex would have required a respin.
Because the ASIC had not been implemented per the standard, other components had to deviate from the standard to interface with it. In this case, the engineers had to hack up the firmware discovery process to say, “If the device being queried is an endpoint and the vendor and device id matches this particular chip, then treat it as a root complex and search for another bus and its devices.”
Designing a block in strict compliance to a standard has several benefits:
Some standards have standard subsets. For example, the RS-232 serial interface has transmit and receive lines and hardware handshaking lines. The hardware handshaking lines are optional. Hardware and drivers should be designed such that, if they are fully implemented, they will work with other components that do not have the optional part implemented.
A non-standard subset of a standard will create problems. Implementing a transmit-only RS-232 interface can cause compatibility problems with associated compliant components, such as RS-232 drivers, other RS-232 interfaces connected to it, and test suites trying to verify functionality. These interfacing components would all have to be customized, increasing the time and cost of development, and the risk of introducing bugs.
Remember, there is no such thing as a customized standard. Either it is customized or it is a standard – not both.
Until the next standard issue…