Out in Left Field
Posted by Chris Schalick on Mon, Nov 05, 2007 @ 09:40 PM
An FPGA by any other name wouldn't smell as sweet. The FPGA acronym itself advertises that you can program devices in the field. This is very powerful for upgrades, but I don't want my DVR to hiccup and require a field upgrade to get it working. As a customer, the last thing I want to hear is that there is a "hardware patch" that needs to be applied.
Unfortunately, the FPGA development community is all too familiar with "coding in the lab". This makes hardware development more exciting, but when that excitement colors a customer's opinion the excitement turns to danger. Embracing the "field" in FPGAs too much can be costly in terms of customer perception.
I visited a customer recently that had a market, a product developed around FPGAs, and customers who wanted (and paid for it). The product was developed with a "blow and go" approach through trial and error in the lab, with no simulation environment. The hardware group got it working well enough to put it in the field. Natural business cycles caused turnover in the engineering group, and the original engineers all left. The customer found problems with the product, and the people in development were left asking, "I know what it doesn't do, but what should it do?"
This scenario is a recipe for developing a robust simulation environment. That gives developers a repeatable, reliable baseline of functionality that can be depended on during field analysis. It is hard enough to get all the bugs out when you follow best practices (engineering is a human endeaver after all). When you don't put in the work and diligence up front to get it right the first time, you are doomed to do it twice, or three times at the expense of customer friction or even losing customers.
Following best practices, working hard and making use of the latest analysis tools is a good recipe for staying in the game and out of left field (apologies to Manny Ramirez who we all want to stay in left field).