What's So Hard About Agile Hardware Development?

by John J. Smith on Saturday January 10th, 2015 07:34 PM

Agile hardware development is a tough nut to crack. Oh sure... lots of companies claim to do agile hardware development, but if you look closely, the claims tend to be suspect. The tools necessary for Agile development are available to the software industry, but just don't exist in the land of hardware. Not yet.

As I've said before, there are some hardware related projects that can legitimately claim agile processes. The first is plug n' chug board integration. This is called integration for a reason... it doesn't require the long delays associated with board manufacture. The second is FPGA/ASIC development, which is more accurately referred to as firmware. While ASIC design has it's own manufacturing delays, these are usually discounted from the process. The real problem is custom electronic device development, which can get very bogged down in manufacturing delays associated with each iteration.

So what is the problem? Why don't software methods translate to hardware? They are both engineering disciplines, right?The answer to these questions is that hardware design tools just haven't kept up with the changing face of engineering.

First of all, there is very little design re-use. I noticed this when I was designing yet another buck regulator circuit. It's true that I can cut-and-paste in an old schematic, or create a schematic sub-sheet that can be re-used. I could probably even cut and paste some of the circuit board traces into the new layout. However, this is a fairly labor intensive process, and it is just as subject to errors as designing the circuit from scratch. There is really no simple way to design, layout, and test a circuit, then just include it in a new design as-is.

The result of this re-use problem is that the addition of a simple module to a hardware design introduces a significant risk of human error, which invalidates a significant amount of work for each iteration. Goodbye Agile.

To solve this problem, hardware EDA tools will need to take a good hard look at software libraries and the way that the software industry uses them. Yes, hardware has it's concept of libraries (schematic, footprint), but these libraries only exist at the component level. What about something at a higher level like circuit modules? Current EDA tools have a few features that get part of the way there, but they all seem to fall very short of the example set by the software industry.

I've been toying with the concept of circuit libraries and I've found that the software for them isn't that difficult. There is no great technological barrier to scale. All of the information is available in currently generated output files. All that remains is some way of re-combining component numbers and re-locating nets. If you have any experience with software, this concept should be very familiar. Essentially, hardware EDA needs to add circuit libraries to their linking step.

The second major problem is a complete lack of a universal standard file format. Open standards exist, but are only given lip service by the tool vendors. EDA tool manufacturers claim that their proprietary format is industry standard, and some even promise to allow free and unencumbered use, but they stop short of releasing them as open. So... the popular standards aren't really open, and the open standards aren't really popular.

In addition, the different file formats for schematic, PCB, and netlist make it difficult to keep track of associations between the schematic concepts and the PCB implementation. If you consider that all of these are relatively simple graphics files with similar forms and requirements, the lack of a unified design format is just silly.

So, to sum up my rant: Agile hardware development is hampered by the lack of tools available for re-use and modular design. The time is ripe for a new approach.

There is 1 comment

Sunday September 27th, 2015 09:47 AM by Tran

We’re All In the Same Boat Please see my StickyMinds Blog for a new post inspired by Jeff Patton's rencet presentation to our Agile Denver user group. The Whole Team Approach isn't just for developing the software! We need to really think Whole Company. Comments welcome!

Add Your Comment

Note: This is an anonymous comment page, so we've taken drastic measures to eliminate spamments. Any comment that looks like it contains a link (href=[anything]) or a URL ([anything]://[anything]) will be shunted to a secondary page, where you will have the opportunity to remove the unallowed text.

General references to web sites or pages that would not result in an SEO-friendly link (i.e. www.example.com/index) are allowable. All tags will be automatically stripped

Name (optional) :

Email (optional, not publicly displayed, but available to post author for offline discussion):