Are Hardware Developers From Mars And Software Developers From Jupiter?

By Frank Schirrmeister
In a recent discussion fellow Blogger Kurt Shuler, when talking about hardware and software designers, said something along the lines “Given languages like Verilog, both hardware and software developers really do software, for hardware designers the software is just getting fixed much sooner.” I intuitively agreed with him, but his comment inspired this post in which I am looking at similarities and differences between hardware and software tool markets.

The graphic for this post overlays the hardware/software flow graph I used in a previous post with the areas of similarity for hardware and software development:

• Both hardware and software development utilize a fair amount of reuse. For hardware a healthy third party IP market exists for processor models, interconnect fabrics and peripherals. The same is true for software, for which real time operating systems and middleware components can be licensed or are at least re-used internally.
• Compilation is a known process in both domains. In hardware logic synthesis translates designs described using register transfer languages like SystemVerilog into gates from which the actual silicon can be implemented.  The software world uses compilation from C and C++ into the actual assembler and object code. Compilers in both domains are very dependent on the actual implementation. For hardware, layout affects the logic synthesis in such a significant way that parts of the actual layout have to be done to make synthesis decisions. For software compilation, the architecture of the target processor and its environment have to be reflected in the compiler to create optimized code.
• High-level synthesis for hardware has been a topic of much debate for the better part of two decades, and it has reached a fair amount of maturity for the class of designs it is applicable to. A similar process exists in software development as well, for which automated implementations can be automatically created from higher level descriptions like SysML, UML and proprietary languages as used by The Mathworks. This is especially adopted in application domains like Mil/Aero and Automotive, for which repeatable, automatically checkable processes are desired.
• “Verification” for hardware development is mirrored by “testing” in the world of software development. Both areas are using formal and dynamic techniques to verify functionality, and automation of the verification/test process is becoming a significant issue due to the increased complexity of hardware and software. This is one of the areas for which the increasing dependencies between hardware and software lead to both camps having to interact more frequently.
• Debug is an issue which happens for both hardware and software independently, but as indicated in the graph’s center across virtual prototyping, RTL simulation, Emulation/Acceleration and FPGA based prototyping, the issue of hardware/software debug is another touch point where both camps meet and are forced to interact.
• Finally, system modeling, independent from hardware and software, is a domain to which both the hardware and software world are growing towards. Eventually, automatic implementations of hardware and software from higher-level descriptions will be the only way to deal with the ever growing complexities and design costs, but today this domain is largely disconnected, especially for hardware (for software see my comment in the high-level synthesis section.

There is one fundamental difference though, and it is hidden in the second part of Kurt’s statement. This “fix” in hardware development, known as tape-out, has much more significant implications than in the software world. According to IBS market data I have seen recently, at 28nm the cost of design are between $50M and $90M, mask sets cost between $2M and $3M. For future, even smaller technology nodes we may be looking at design cost between $120M and $500M, with mask sets being in the range of $5M to $8M. The pressure to get that piece of silicon right is huge. Taping the chip out, which essentially means signing off on creating a mask set at the cost mentioned above, can be a pivotal point in the career of a project manager, especially if there are bugs. This is why selling solutions for verification is a little bit like selling insurance. Verification is inherently an unbound problem, so while it is never done, getting the confidence level of design teams to a level that they are willing to tape out, is something they are willing to pay really money for!

In contrast the software side looks comparatively easy. There is always a service pack two, or another type of software upgrade which cannot be done in hardware. As a result of this fundamental difference, the design attitude of software and hardware developers is very different, one focused on completely clean hardware and the other knowing that there will be more bugs, for sure.

Bottom line, while the brief analysis of development processes above shows that both hardware and software camps look like they could be of same descent – and I am hoping that I avoided any immediate gender comments on the title by locating software developers on a planet different from Venus – their training and attitude towards design are completely different by definition of what they have to deliver.

Are these differences irreconcilable? Probably not, but watching the camps to work them out will be interesting!

–Frank Schirrmeister is group director for product marketing of the system development suite at Cadence.