Why is this book of interest to the hardware folks?

Why is this book of interest to the hardware folks?

As "I R A Hardware Engineer" (maybe you figured that out already), let's start by considering things from this side of the fence. Electronic design automation (EDA) refers to the software tools used to design electronic components and systems. In the early days of digital logic design, we captured our circuits as gate-level schematics.

This approach began to run out of steam in the mid- to late-1980s, but we were saved by the introduction of sophisticated hardware description languages (HDLs). These allowed us to describe the functionality of a design at a reasonably high level of abstraction called the register transfer level (RTL). In turn , these descriptions allowed alternative design scenarios to be more quickly and easily represented and simulated. And, of course, the real boost to productivity came in the form of logic synthesis technology, which could automatically compile these high-level descriptions into equivalent gate-level netlists.

Another consideration is the way in which a design is physically realized. Initially, the only options were to use lots of off-the-shelf " jelly -bean" devices and simple programmable logic devices, or to create your own application-specific device. Then, in 1984, a new component appeared on the scene: the field-programmable gate array (FPGA). The first incarnations of these devices were relatively simple and contained only a few thousand equivalent gates, but my, how things have changed. Today's offerings can boast tens of millions of equivalent gates coupled with large numbers of embedded functions like RAM blocks and multipliers.

And now we are running into a design productivity crunch again. Although languages like Verilog and VHDL are great for precisely describing a design's functional intent, they are somewhat cumbersome when it comes to representing today's multimillion-gate systems. Actually capturing and verifying (via simulation and/or formal verification) such a design in HDL is very time-consuming .

A bigger problem, however, is that describing a design using a traditional HDL requires us to make a lot of implementation-level (microarchitecture) decisions. In turn, this makes make exploring alternative design scenarios and architectures time-consuming and complex. For example, if you already have a design captured in HDL and someone says, "Let's try doubling the number of pipeline stages to see what happens," you know that you can cancel your plans for the coming weekend .

The solution is, once again, to move to a higher level of abstraction. The most natural level for hardware design engineers is the standard ANSI C programming language (don't talk to me about C++, because trying to wrap my brain around that makes my eyes water). This book shows you how to express designs using standard ANSI C extended with a small number of C-compatible library functions. Once the design has been captured and verified (and alternative solutions and architectures explored), the book also discusses the tools used to automatically convert the untimed C description into its synthesizable HDL equivalent.

The end result is that this methodology allows hardware design engineers to achieve a working prototype much faster than using an HDL-only approach. "But what of the software folks?" you cry...