Chapter 9: The Firmware Development Process

Now that we have a functioning circuit board, it is time to flesh out some key portions of the Field Programmable Gate Array (FPGA) algorithm, including communication with the analog-to-digital converter (ADC), and continue the development of the MicroBlaze processor firmware. When developing firmware, it is important to make use of appropriate tools to ensure that the source code is subjected to static analysis where possible, which can head off many errors that are otherwise difficult to debug. It is also important to implement a version control system to track the evolution of the code over the project life cycle. We will discuss the importance of developing a comprehensive, at least partially automated test suite to maintain code quality as changes are made. This chapter includes several recommendations for free and commercial tools that perform each of these functions.

After completing this chapter, you will have learned how to design...

Technical requirements

The files for this chapter are available at https://github.com/PacktPublishing/Architecting-High-Performance-Embedded-Systems.

Designing and implementing the FPGA algorithm

Up to this point, we have discussed only the details of the digital circuitry needed to receive an analog signal and perform the analog-to-digital conversion. We haven't really looked at what happens to an ADC sample after it has been captured. The next section will provide an overview of all of the functional elements of the digital oscilloscope system.

Digital oscilloscope system overview

Much of our work in the previous chapters has been focused on designing and constructing the hardware aspects of the digital oscilloscope add-on board that will plug into the Arty board. We will now examine the complete system at a high level.

The following figure provides a top-level view of the functional elements of the digital oscilloscope system:

Figure 9.1 – Digital oscilloscope system diagram

Figure 9.1 shows the portions of the system that reside on the oscilloscope board, those on the Arty A7 board...

Coding style

The C and C++ programming languages have many powerful features but also present many opportunities for developers to insert unintended behaviors that can manifest later as severe bugs. By following a set of code styling rules, you can substantially increase the likelihood that your code will perform as intend and, perhaps even more importantly, the code will be easier to read and understand for future maintainers.

Of course, simply following a set of style guidelines does not guarantee your code will be bug-free. The consistent application of coding style rules is just one part of an effective firmware development process that includes thorough testing and rigorous version control.

The following sections list some fundamental coding style guidelines applicable to C and C++. Similar rules can be applied to other programming languages we use, such as VHDL and C#. When multiple developers are working on a project, all of them should follow the same style guidelines...

Statically analyzing source code

As the name implies, static source code analysis examines the source code for a computer program and provides a report on issues it identifies in the code.

What is static code analysis?

A static source code analyzer is similar in some ways to a compiler for the same programming language. Both tools ingest source code for a program and process it under the rules of the associated programming language, which is C or C++ in the current discussion.

The difference between the two types of tools is that the compiler intends to generate executable code that implements the logic defined in legal source code. A source code analyzer, on the other hand, performs an extensive assessment of the code, generally far beyond that performed by a compiler, and analyzes the code for compliance with a lengthy list of rules.

The output of the source code analyzer is a set of messages indicating potential problems it discovered in the code. It is then up to the...

Source code version control

For any software project larger than a single-file program, it is critical to maintain a rigorously managed history of file versions. Several new and old software tools are available for performing version control, some of which are free and some offered commercially.

Rather than list the options available for these tools, we will focus on the popular version control system named Git. Git is the version control system used for the Linux operating system source code. Many online Git repositories such as GitHub (https://github.com) are available. Git is free and is available at https://git-scm.com/downloads.

Version control with Git

Vitis contains integrated capabilities for working with Git to version control your application source code. It also has the ability to work with remote repositories such as on GitHub or on an organization-provided Git server.

Git allows multiple developers to work on the same code base and enables each developer to...

Test-driven development

Test-driven development (TDD) is a philosophy and process for integrating comprehensive testing into the software development process at the earliest stage possible. The idea behind this approach is to begin with a set of fully tested individual components and continue testing as these components are integrated into a functional system. By using this methodology, the likelihood of significant bugs remaining in the code is drastically reduced.

To make the development process test-driven, you first write a test for a piece of functionality that does not yet exist in the system and then run the test. The test should fail, perhaps by not even compiling successfully if a function being called does not yet exist. You then implement the function the test is attempting to execute, which should allow the test to pass. The set of tests should verify as fully as possible that the implemented system code is performing correctly.

While fairly simple in concept, there...

Summary

This chapter covered the implementation of a few of the significant remaining portions of the FPGA design, including the deserializer, the FIFO buffer, and the interface to the AXI bus. We covered the application of appropriate code style guidelines and discussed the use of static source code analysis as a powerful means of preventing many errors that are otherwise difficult to debug.

The chapter discussed the use of Git as a software project version control system. The benefits of TDD were discussed and the Ceedling TDD tool for C language projects was introduced.

Having completed this chapter, you understand the basics of designing FPGA algorithms and how to develop embedded C code in a maintainable and well-tested style. You are familiar with the basics of Git version control and understand the fundamental steps of TDD.

The next and final chapter will discuss best practices for performing thorough testing of the entire embedded device and will offer some effective...