EC-13.4 Digital and Programmable Hardware on the Bench

What this is and why it exists

Digital work has a laboratory failure mode of its own. The circuit is either right or completely wrong, with none of the graded misbehaviour that makes an analog fault readable.

That makes the instruments and the method more important rather than less. You cannot infer the fault from how wrong the answer is, because the answer is wrong and nothing more.

This stage is therefore about seeing what is actually happening, rather than about designing anything new.

The vocabulary

• Bring-up order — the sequence in which a board's basic functions are verified.
• Logic analyser — an instrument recording many lines at once as high or low.
• Testbench — a simulation that drives a design and checks its outputs.
• Timing constraint — a statement to the tools of the clock rate a design must meet.
• Setup and hold — the intervals around a clock edge during which an input must be stable.
• Metastability — the undefined state of a flip-flop clocked while its input was changing.
• Synchroniser — two flip-flops in series used to bring an external signal into a clock domain.

The mental model

Bring a digital board up in a defined order: supply, then clock, then reset, then everything else.

Check each on an oscilloscope before moving to the next. A supply that is a volt low, a clock that is not running and a reset stuck active all look like a broken design. All three are found in two minutes by looking.

The logic analyser is the instrument this stage exists to teach. Digital faults are relationships between signals rather than properties of one, so an instrument that shows eight or sixteen lines together is the right tool.

Capturing a state machine's control lines and reading their order shows you what the hardware actually did. Watching one line at a time on an oscilloscope shows you almost nothing about a relationship.

Simulation comes before programming, always. A simulation that fails costs seconds. A hardware fault costs a session to find, because the hardware has no way to tell you what it was thinking.

Running a testbench before programming is the single largest saving of time available in digital work. It is also the step most often skipped under deadline pressure, which is when it saves the most.

But a design that simulates can still fail, and the reason is timing. Simulation assumes signals arrive when they should. Real hardware has propagation delays, and a signal that arrives too close to a clock edge is not captured reliably.

The tools produce a timing report saying whether the design meets its clock. Reading that report is what tells you whether the hardware will work, and constraints are how you tell the tools what to check against. A design with no constraints has been checked against nothing.

Metastability is the failure that looks like magic and is not. A flip-flop clocked while its input is changing may settle to either value, and may take an unbounded time to settle to anything.

The remedy is a synchroniser: two flip-flops in series, so that the first absorbs the uncertainty and the second sees a settled value. Every signal entering from outside the clock domain needs one. Forgetting causes a class of faults that appear once an hour and never during a demonstration.

Finally, the temptation this stage exists to resist. With programmable hardware, changing something and trying again is fast, so it becomes the default.

It is also the slowest way to find a fault, because it teaches you nothing about the design. Capture the failing behaviour first, form a hypothesis about which signal is wrong, and test that hypothesis. Three deliberate cycles beat thirty random ones and leave you understanding the design.

What you should now be able to explain or do

• Bring up a digital board in an order that isolates the basic faults.
• Use a logic analyser to observe a relationship between several signals.
• Run a testbench before programming hardware, and say why it saves time.
• Read a timing report and explain what a constraint tells the tools.
• Explain metastability and place a synchroniser where one is needed.
• Diagnose a digital fault by hypothesis rather than by repeated reprogramming.

Check yourself