Test-Driven Hardware Development: True or False?

Ron Wilson, Intel FPGA
Feb.22, 2018

Few generalizations about hardware design are more widely accepted than this: it is better to find errors early. And yet the traditional design-then-verify flow gives errors ample time to embed themselves in the design before even starting to look for them. It need not be so.

A technique borrowed from the software world—Test-Driven Development (TDD)—seeks to eliminate the problem by, in effect, reversing a portion of the design flow. In TDD, you develop the test harness for each unit of code before you write the code. It may sound like a rather pointless change in scheduling. But increasing numbers of design teams are finding that TDD makes a big difference: shortening design time, improving quality, and preparing design teams for emerging issues such as security and functional safety.

TDD Defined

So what is TDD? It is an iterative design methodology based on the concepts of unit testing. In unit test, rather than attempting to test an entire functional block of code at once, you partition the block into units and test each unit in isolation before integrating it into the block. So what is a unit? The partitioning process is more art than algorithm. You want a unit to have a small number of inputs and outputs, a clear function that is independent of the inputs—and especially independent of the state of other units—and minimal internal state. In other words, you define your units so they are easy to test, without letting the number of units get out of hand.

The innovation of TDD is that you define the units from the requirements, before the code exists. Then, before you write the code for a unit, you write the test harness for it—again, working directly from the requirements and the software architecture. You check the test by applying it to the existing code for the overall block, if there already is any. The block should of course fail the new test, since you haven’t written the new code yet.

Click here to read more ...