Posts Tagged ‘plan ahead’

Designing a Chip for Unplanned Products

Wednesday, December 29th, 2010 Gary Stringham

One of the rules of the Extreme Programming design philosophy for software is Never Add Functionality Early. This means that when coding for one product, do not add features or functionality needed for a future product. While this rule does have some merit for software development, it should be applied more judiciously to hardware development.

One of the reasons programmers can get away with that type of thinking is because they can and are able to change software rapidly by simply recompiling and re-executing. Hardware engineers do not have that luxury. It takes months and millions of dollars to produce a different version of the chip. Future costs can be reduced if the chip is designed with the future in mind, with the possibility that it might be used in future products that are currently unplanned.

There is also an aspect of planning for the future where you prepare by building a framework but not putting in the features. That makes it easier to implement the new features in the future but still requires putting out a new version of the chip. But that will be the subject for another issue. For this issue, I am talking about what can be done to make this version of the chip more likely to be used in the future.

Not all known future functionality should be put into the design; time, effort, space and cost will not permit it. But some of it has little risk in terms of complexity, implementation and verification. If a three-bit number might need four bits in the future, making it a four-bit number now has little risk to the program. Adding a couple of extra GPIO lines is also low-risk (assuming there are pins for it.) Adding a block that is new, big and complex could add a lot of risk to the program and needs to be weighed against the potential gain if it were needed.

Extreme Programming says that “only 10% of that extra stuff will ever get used.” But if you put 10 “extra” features in the chip and only one gets used, you could save your company months and millions of dollars.

Best Practice: Include low-risk features in the design of the chip that might be used in future products.

Aside from features that might be needed in the future, faster speed is characteristic of future products. Chips are designed with a performance and speed budget. Planning for the future would mean that you also look at the speed of the chip. I have seen cases where existing chips were limited in their usefulness because they were not fast enough and we had to spend lots of time and money to produce a new version just to get the speeds we needed.

Best Practice: Increase the performance margins in the design to allow the chip to be used in faster products in the future.

Always looking toward the future…

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…