Archive for September, 2010

Accommodating Product Changes

Tuesday, September 7th, 2010 Gary Stringham

Late in the development of a new printer, a third-party print engine that interfaced with a block on the ASIC changed its interface behavior. The print engine would quit sending pulses before the block was done with its job, causing the block to hang waiting for more pulses. This behavior existed in other printer models; their associated blocks had support to detect early pulse termination. Because this new printer’s block did not have that support, I had to create a firmware workaround for it.

I tried three different algorithms over a three-week period and finally settled on one, even though under rare circumstances, it had a severe performance penalty. Unfortunately, one particular customer bought several of these printers for a specific application and experienced this rare circumstance that cut print speed in half for every page. Obviously the customer was dissatisfied and threatened to return the printers and cancel the large order, which included other printer models. I spent another two weeks to come up with a fourth algorithm that avoided the penalty. We upgraded the customer’s printers and they were happy.

Had this particular block had the early termination support (at a low cost of a few hundred gates), we could have accommodated this late product change with a one-hour firmware change. Instead, beyond nearly costing us a major contract, it also cost five weeks of engineering effort, thousands of warranty dollars and some damage to our reputation.

In contrast, we had an ASIC that was designed for portrait-format printers that was being investigated for use in landscape-format printers. The ASIC was based off previous ASICs that did support landscape-format printers. The engineers did not remove the landscape-format support even though the ASIC was not targeted for landscape-format printers. ASICs for landscape-format printers require more onboard memory in several places in the pipeline to accommodate longer scan lines. Reducing the memory requirement would have reduced their gate count, but they decided not to do that when they made this ASIC.

After verifying that landscape-format support was still in the ASIC, we used them in landscape-format printers. This saved us millions of dollars and several months from having to develop and produce a new ASIC.

Ideally, every ASIC will support any product, whether old or new, high-end or low-end. Since that is not realistic, choices have to be made. Old functionality can be removed once you are sure that it will never be needed again, even for mid-life kicker products. Functionality with large gate-count requirements that is only needed for specific family lines of products could be removed. But where possible, leave as much functionality in an ASIC, even if not all of it is needed for the targeted products.

Best Practice: Implement and retain all known low-overhead functionality in a block, even if the current requirements do not call for it.

Until the next shipment…