Skip to main content

Über dieses Buch

This is a practical book for computer engineers who want to understand or implement hardware/software systems. It focuses on problems that require one to combine hardware design with software design – such problems can be solved with hardware/software codesign. When used properly, hardware/software co- sign works better than hardware design or software design alone: it can improve the overall performance of digital systems, and it can shorten their design time. Hardware/software codesign can help a designer to make trade-offs between the ?exibility and the performanceof a digital system. To achieve this, a designer needs to combine two radically different ways of design: the sequential way of dec- position in time, using software, with the parallel way of decomposition in space, using hardware. Intended Audience This book assumes that you have a basic understandingof hardware that you are - miliar with standard digital hardware componentssuch as registers, logic gates, and components such as multiplexers and arithmetic operators. The book also assumes that you know how to write a program in C. These topics are usually covered in an introductory course on computer engineering or in a combination of courses on digital design and software engineering.



Basic Concepts


Chapter 1. The Nature of Hardware and Software

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.
Patrick R. Schaumont

Chapter 2. Data Flow Modeling and Implementation

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.
Patrick R. Schaumont

Chapter 3. Analysis of Control Flow and Data Flow

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.
Patrick R. Schaumont

The Design Space of Custom Architectures


Chapter 4. Finite State Machine with Datapath

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.
Patrick R. Schaumont

Chapter 5. Microprogrammed Architectures

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.
Patrick R. Schaumont

Chapter 6. General-Purpose Embedded Cores

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.
Patrick R. Schaumont

Chapter 7. System On Chip

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.
Patrick R. Schaumont

Hardware/Software Interfaces


Chapter 8. On-Chip Busses

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.
Patrick R. Schaumont

Chapter 9. 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.
Patrick R. Schaumont

Chapter 10. Coprocessor Control Shell Design

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).
Patrick R. Schaumont



Chapter 11. Trivium Crypto-Coprocessor

Stream ciphers are complex state machines that generate an infinite stream of pseudo-random bits starting from a single key. These bits can be used as a keystream in encryption and decryption operations. In this chapter we’ll discuss the implementation of such a stream cipher algorithm, called Trivium, as a co-processor. The co-processor is attached to a host processor. The software on that host processor initializes the Trivium coprocessor, and retrieves a very long (infinite) keystream. We consider different types of host processors, including an 8-bit 8051 microcontroller, a 32-bit StrongARM RISC, and a 32-bit Microblaze processor. We will consider the impact of different types of hardware–software interfaces on the performance of the overall design. We will also investigate the path to implementation on an FPGA.
Patrick R. Schaumont

Chapter 12. CORDIC Coprocessor

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.
Patrick R. Schaumont


Weitere Informationen

BranchenIndex Online

Die B2B-Firmensuche für Industrie und Wirtschaft: Kostenfrei in Firmenprofilen nach Lieferanten, Herstellern, Dienstleistern und Händlern recherchieren.



Globales Erdungssystem in urbanen Kabelnetzen

Bedingt durch die Altersstruktur vieler Kabelverteilnetze mit der damit verbundenen verminderten Isolationsfestigkeit oder durch fortschreitenden Kabelausbau ist es immer häufiger erforderlich, anstelle der Resonanz-Sternpunktserdung alternative Konzepte für die Sternpunktsbehandlung umzusetzen. Die damit verbundenen Fehlerortungskonzepte bzw. die Erhöhung der Restströme im Erdschlussfall führen jedoch aufgrund der hohen Fehlerströme zu neuen Anforderungen an die Erdungs- und Fehlerstromrückleitungs-Systeme. Lesen Sie hier über die Auswirkung von leitfähigen Strukturen auf die Stromaufteilung sowie die Potentialverhältnisse in urbanen Kabelnetzen bei stromstarken Erdschlüssen. Jetzt gratis downloaden!