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:

• The compliant block will work, without changes, with compliant off-the-shelf components (e.g. blocks, chips, device drivers, test suites, debuggers, analyzers, development platforms).
• Well-defined specifications already exist for verifying and testing compliant blocks.
• Expertise in standards exists and is available.

• Best Practice: Design the chip or block exactly to the specifications of the standard, even down to the details of the characteristics of the registers.

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.

• Best Practice: When implementing a subset of a standard, implement a standard subset, not a custom-designed standard.

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…