This is the sixth in the series of newsletters that present seven principles to help guide your own processes and best practices in hardware/firmware interface design. This month’s principle focuses on preparing for problems that will occur in the design.
Why do you carry insurance on your car (beside the fact that in many places the law requires it)? Why pay the insurance premium? Do you want to collect on it? Are you going to purposefully get into an accident so you can collect? No. But when you do get into an accident, you will be glad you have it. You are prepared for that contingency.
On September 21, 2005, JetBlue flight 292 with 139 passengers took off from Burbank, California. Unfortunately, the plane’s nose gear got stuck sideward. After circling Los Angeles for 3 hours to burn off fuel, the flight crew came in for a successful landing. The following are links to articles, videos, and pictures:
www.nbcnews.com/id/9430871#.U1b7j_ldWuk
commons.wikimedia.org/wiki/File:JetBlue292Landing.jpg
www.maniacworld.com/JetBlue-Emergency-Landing.htm
www.aerospaceweb.org/question/planes/q0245a.shtml
It was amazing that the nose gear did not collapse. It was rugged. It was designed for contingencies, although no one anticipated what the gear would be called upon to do.
Designing for contingencies means that you do what you can to prepare for problems that may appear.
One manager of a young hardware design team told me how his team had informed him that they had completed their design. The manager then said, “Six months from now, you are going to get the chip back and it won’t turn on. What are you going to need to debug that chip?” The team went off, thought about it, and added some test and debug hooks.
When you are trying to get a chip to work, you will need to know what is going on inside. If you are using a software simulator, you have a clear view of every internal signal and flip-flop. Similarly, if you are working with an in-circuit emulator or JTAG, you have a good view as to what is going on inside your design. But when you are trying to get firmware working on a physical chip mounted inside the product, visibility inside the device is very limited.
Visibility inside the chip can be provided to firmware by adding test and debug hooks in the device. Adding additional read/write access to internal flip-flops and signals gives firmware “peek-and-poke” capabilities. It is like having a basic logic analyzer built into the chip. These added capabilities cost little in terms of space on the silicon and time required designing and verifying them, but this is similar to paying insurance. You hope you don’t have to collect, but if there are problems, you will be very happy that your premiums have been paid.
Furthermore, test and debug hooks in the chip are not solely for diagnosing and working around defects in the hardware. They are also very useful for locating and identifying defects in the firmware.
- Principle 6: Design for Contingencies.
Until my next contingent newsletter…
Gary Stringham
Jakob brings up a good point. In security applications, you don’t want to be shipping a chip that could reveal important secrets to rogue firmware or debugging tools. And, as someone else commented to me, security applications might be the rare context that justifies using write-only registers instead of read-write registers — although I generally advocate just the opposite — so that rogue firmware or debuggers can’t read what the legitimate firmware wrote.
If you are designing for a security application, you may need a two-step approach:
1. During development, use chips (such as FPGAs) with debugging hooks installed until you get the whole system functional and tested.
2. Before shipping products to customers, remove the hooks from the chips and conduct a full regression test to ensure the product operates properly without the hooks.
Jakob Engblom
I have a friend who sees a big issue with this: if the goal is to keep the code secret and the functions of the chip confidential and safe from security threats, you might NOT want to have debug support in the shipping devices. Rather on the contrary. But it is a tough call.
Comments are closed.