This document discusses test-driven development (TDD) for hardware creation from a software perspective. It provides 3 key differences between testing hardware vs software: 1) Hardware tests must check output signals over time in response to input signals, 2) Hardware development relies heavily on static simulation due to long synthesis times, and 3) Determining a hardware device's current state is more complex. It then explains using FPGAs with a hardware description language like Verilog. The document outlines the usual development process vs the TDD process, and provides an example of developing a hardware sound player from an SD card using TDD.
Building Real-Time Data Pipelines: Stream & Batch Processing workshop Slide
An Application of Test-Driven Development Methodology into the Process of Hardware Creation (a View from a Software Perspective)
1. TDHD: Staroletov, Fedorov
An Application of Test-Driven Development
Methodology into the Process of
Hardware Creation
(a View from a Software Perspective)
Sergey Staroletov (PhD), Vladimir Fedorov (student)
Polzunov Altai State Technical University,
Lenin avenue 46, Barnaul, 656038, Russia
Email: serg soft@mail.ru ** vladimir.fodorow@gmail.com 1 / 8
2. TDHD: Staroletov, Fedorov
Some notable differences of device testing
The testing process of the code running on a device is quite
different from the testing used in Software Engineering. We
identified the following main differences:
1 The time parameter is added, the tests should check not
just the correspondence of the output value according to a
given input, but the correspondence of the output signals
over time according to specified input signals
2 A rather long synthesis time, project deployment, a large
number of signals, a short device response time lead to the
fact that static testing methods (simulation) become very
important during the development
3 The complexity of determining a current state of the
working code on the device.
4 Dynamic testing is carried out by connecting external logic
analyzers
2 / 8
3. TDHD: Staroletov, Fedorov
FPGA
FPGA (field-programmable gate array) is a device (a special
processor) that contains developer-reconfigurable blocks with
inputs and outputs, and their configuration code is written in a
special language for describing integrated circuit hardware
(HDL, hardware description language).
The advantage of using FPGAs while working with external
equipment to the microcontrollers (such as, for example,
Arduino or STM32 and especially to devices with an operating
system like Raspberry Pi) is that the processor here does not
run some compiled machine code, and its logic is programmed
especially to solve a given task.
3 / 8
4. TDHD: Staroletov, Fedorov
Verilog
Verilog language is a high-level C- and Pascal-like at the
level of operations, conditions, and cycles, which is then
synthesized into logical elements of the FPGA.
Verilog program describes modules connected by inputs
and outputs, and one can declare memory registers in the
form of bitwise data and their arrays, connections, and
control structures.
The programs are written according to the event-oriented
pattern, usually at a positive or negative front of a change
of frequency clock or some other signal. The code
always@(posedge clock 50M )
begin
dacclk a <=dacclk ;
end
is performed at a f = 50 MHz. And NO delay loops in code. 4 / 8
6. TDHD: Staroletov, Fedorov
A TDD Process in HD (TDHD)
1 Create a project for the target hardware. Create a
git-repository and commit. Use git commit at each step
2 Define the external interface according using MDD in a
graphical editor, then generate a test containing a link to
the main program block with these signals and the code of
this block. Start adding low-level blocks.
3 Next, it’s time to implement the code only to pass the test
4 Using the component development model, integrate an IP
(IP or Intellectual Property, similar to the components) and
integrate at the block layer when needs, write trivial tests.
5 Manually determine the signals by drawing them on a
timing diagram, or use a logic analyzer and record the real
signals and generate tests
6 Refactor and create more tests for blocks. Add more blocks
6 / 8