embedded software boot camp

Abiding by Industry Standards

Friday, June 3rd, 2011 by Gary Stringham

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…

 

Tags: , ,

One Response to “Abiding by Industry Standards”

  1. Lundin says:

    How many who work with RS-232 have actually read the EIA RS-232 document? I haven’t, even though I have had far more than the recommended daily intake of this horrible, ancient little bus. Even though I tend to regularly end up with various boring technical standards. Can you even order the document from somewhere? EIA is hardly a widely recognized standard institute, and from what I recently heard, they are no more. It is hard to follow a standard when you don’t know what the standard says.

    But at least RS-232 was adopted by a minor standard institute. Other serial buses like SPI and I2C aren’t as fortunate, and they tend to be implemented (and named) in new creative ways for every chip manufacturer using them. These are truly “customized standards”, you have to RTFM in extreme detail before even considering using the specific SPI/I2C chip, to see which creative non-standard ideas they decided to implement this time. Compare these with CAN which is a formal ISO/IEC standard, I have never had any protocol/timing-related problems when setting up two CAN controllers to speak with each other, while such problems are mandatory when using SPI and I2C.

Leave a Reply