A Practical Introduction to Hardware/Software Codesign

Hardware/software codesign is the activity of partitioning an application into a flexible part (software) and a fixed part (hardware). The flexible part includes C programs, configuration data, parameter settings, bitstreams, and so forth. The fixed part consists of programmable components such as microprocessors and coprocessors. There are several technological and economical reasons for implementing electronic systems in this fashion, and we will discuss them upfront in this chapter. Next, we consider the design space of programmable components: what distinguishes one component from the other, and how do we select one in a given hardware–software codesign. A key observation is that there is a trade-off between flexibility and efficiency. A third part in this chapter will define the abstraction levels for hardware and software for the purpose of this book. And finally, we will also define three terms that play a vital role in this book, namely the terms concurrent, parallel, and sequential.

In this chapter, we will learn how to create data flow models, and how to implement those models in hardware and software. Unlike C programs, data flow models are concurrent: they can express activities that happen simultaneously. This property makes data flow well suited for a parallel hardware implementation as well as a sequential software implementation.

In this chapter, we analyze the control flow and dataflow of a C program. Understanding these properties helps a designer to understand the relationship between a C program and an equivalent hardware implementation of that C program. Control edges and data edges reflect relationships between the operations of the C program, and we distinguish control edges from data edges. A control edge specifies the execution order of these operations. A data edge specifies that data produced by one operation is consumed by the second. By representing the operations of the C program as nodes of a graph, control edges and data edges define a structure called a Control Flow Graph (CFG) and a Data Flow Graph (DFG), respectively. For a hardware–software codesigner, the distinction between control edges and data edges is of great importance. Data edges will appear in any implementation target – hardware or software – of the algorithm. Control edges, on the other hand, may be removed when the algorithm executes on an architecture with sufficient implementation parallelism.

In this chapter, we introduce an important building block for efficient custom hardware design: the Finite State Machine with Datapath (FSMD). An FSMD combines a controller, modeled as a finite state machine (FSM) and a datapath. The datapath receives commands from the controller and performs operations as a result of executing those commands. The controller uses the results of datapath operations to make decisions and to steer control flow. The FSMD model will be used throughout the remainder of the book as the reference model for the ‘hardware’ part of hardware/software codesign. We will introduce a syntax for FSMD by means of the GEZEL language. The cosimulation tools used in conjunction with this book rely on the GEZEL language. We will discuss several alternate language mappings for the FSMD language in GEZEL, including VHDL, Verilog, and SystemC. Thus, GEZEL is used as a generic shorthand modeling mechanism for FSMD. Finally, we will also describe a few formal properties of the FSMD model, and we define a proper FSMD as one which leads to a race-free and deterministic hardware implementation.

The Finite State Machine controller in an FSMD is nonprogrammable. By substituting this FSM for a programmable controller, you obtain a microprogrammed architecture. The advantage of a programmable architecture is obviously the flexibility to implement multiple functionalities. This chapter discusses the design of microprogrammed controllers and datapaths, and it explains the advantages and limitations of microprogramming. In particular, you will see that complex, pipelined datapaths are not easy to handle because of the bare-bones approach to control.

The most successful programmable component on silicon is the microprocessor. Fueled by a well-balanced mix of efficient implementations, flexibility, and tool support, microprocessors have grown into a key component for electronic design. This chapter reviews the major features of microprocessor architectures, and in particular of RISC (Reduced Instruction Set Computer) processors. The topic of microprocessors is a very broad one; entire books are devoted to its discussion. The objectives of this chapter are more modest. Our objective is to get insight into the relation between a C program and the execution of that C program on a microprocessor. This will help us to understand the cost of the C program in terms of memory footprint and execution time. Later chapters build on this insight to discuss the detailed interaction of C programs with custom-hardware modules. The chapter covers four different aspects of C program execution on RISC processors. First, we will discuss the major architecture elements of a RISC processor and their role in C program execution. Second, we will discuss the path from C programs to assembly programs to machine instructions. Third, we will discuss the runtime organization of a C program at the level of the machine. And finally, we will discuss techniques to evaluate the quality of generated assembly code, and thus evaluate the quality of the C compiler. Much more can be said on microprocessors besides these points; the reader can find additional suggestions in the Further Reading section at the end of this chapter.

There is no generally accepted, universally-available machine abstraction above that of a RISC processor. However, the RISC is a key component in a very successful heterogeneous architecture: the System-on-Chip. A system-on-chip architecture combines one or more microprocessors, an on-chip bus system, several dedicated coprocessors, and on-chip memory, all on a single chip. An SoC architecture provides general-purpose computing capabilities along with a few highly specialized functions, adapted to a particular design domain. This chapter reviews the cast of players in the system-on-chip concept, and it describes its key characteristics. The chapter also documents how GEZEL SoC models can be constructed as a combination of custom FSMD hardware modules and simulation primitives to capture the RISC cores.

The on-chip bus is the backbone of any SoC, and it is a means to efficiently connect various components including processors, memory, and peripherals. The challenges for an on-chip bus are not minor: it has to accommodate a wide range of communication needs with a single, unified architecture. In this chapter we review the key characteristics of the on-chip bus, using several existing on-chip bus standards as examples: ARM/AMBA, IBM/Coreconnect, and Wishbone. We also look at some of the long-term challenges for on-chip interconnect, and how this will affect the design of hardware–software interfaces.

The objective of a hardware/software interface is to enable communication between software and custom hardware. The software runs on a microprocessor, while the custom hardware is attached to that microprocessor. We will consider how to implement stable data transfers by synchronizing software and hardware. Next, we will discuss the various implementations of hardware/software interfaces, including memory-mapped interfaces, coprocessor interfaces, and custom-instruction interfaces.

This chapter discusses the design practice of attaching a custom hardware module to a hardware/software interface, an activity referred to as control shell design. It involves the encapsulation of a custom hardware module on a standard hardware/software interface, and the development of a software driver to control the custom hardware module through this hardware/software interface. There are two orthogonal aspects to control shell design. The first, data design, defines how to transfer data from software to custom hardware and back. The second, control design, defines how to implement a software control strategy for the custom hardware. The outcome of data design and control design define the programmer’s model, the abstract software view of the hardware module. This chapter will address each of these aspects, and discuss an example based on a control shell for an encryption coprocessor for the Advanced Encryption Standard (AES).

The Coordinate Rotation Digital Computer Algorithm (CORDIC for short) is a well known algorithm to perform rotations using simple, integer arithmetic. The algorithm implements a conversion between rectangular (X, Y ) coordinates and polar (r, θ) coordinates. In this chapter, we discuss the design of a coprocessor that implements the CORDIC algorithm. We will use a Fast-Simplex-Link (FSL) interface. We also discuss a prototype implementation of the design on a Spartan 3E Starter Kit, and show how to resolve the communication bottleneck occuring from an inefficient hardware/software interface.