Co-Design for System Acceleration: A Quantitative Approach

Co-design for System Acceleration A Quantitative Approach

CO-DESIGN FOR SYSTEM ACCELERATION A Quantitative Approach

NADIA NEDJAH Department of Electronics Engineering and Telecommunications, State University of Rio de Janeiro, Brazil

LUIZA DE MACEDO MOURELLE Department of Systems Engineering and Computation, State University of Rio de Janeiro, Brazil

A C.I.P. Catalogue record for this book is available from the Library of Congress.

ISBN-13 978-1-4020-5545-4 (HB) ISBN-13 978-1-4020-5546-1 (e-book)

Published by Springer, P.O. Box 17, 3300 AA Dordrecht, The Netherlands. www.springer.com

Printed on acid-free paper

All Rights Reserved c 2007 Springer
No part of this work may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, microfilming, recording or otherwise, without written permission from the Publisher, with the exception of any material supplied specifically for the purpose of being entered and executed on a computer system, for exclusive use by the purchaser of the work.

To my mother and sisters, Nadia

To my father (in memory) and mother, Luiza

Contents

Dedication List of Figures List of Tables Preface Acknowledgments

v xi xv xvii xix

1. INTRODUCTION

1

1.1

Synthesis

2

1.2

Design Approaches

3

1.3

Co-Design 1.3.1 Methodology 1.3.2 Simulation 1.3.3 Architecture 1.3.4 Communication

4 5 6 6 6

1.4

Structure and Objective

7

2. THE CO-DESIGN METHODOLOGY

9

2.1

The Co-Design Approach

10

2.2

System Specification

11

2.3

Hardware/Software Partitioning

12

2.4

Hardware Synthesis 2.4.1 High-Level Synthesis 2.4.2 Implementation Technologies 2.4.3 Synthesis Systems

15 16 17 20

2.5

Software Compilation

21

2.6

Interface Synthesis

22 vii

viii

Contents

2.7 2.8

System Integration Summary

23 27

3. THE CO-DESIGN SYSTEM 3.1 Development Route 3.1.1 Hardware/Software Profiling 3.1.2 Hardware/Software Partitioning 3.1.3 Hardware Synthesis 3.1.4 Software Compilation 3.1.5 Run-Time System 3.2 Target Architecture 3.2.1 Microcontroller 3.2.2 Global Memory 3.2.3 Controllers 3.2.4 Bus Interface 3.2.5 The Coprocessor 3.2.6 The Timer 3.3 Performance Results 3.3.1 First Benchmark: PLUM Program 3.3.2 Second Benchmark: EGCHECK Program 3.3.3 Results Analysis 3.4 Summary

29 30 31 33 33 36 36 37 38 40 41 42 45 45 45 46 47 48 50

4. VHDL MODEL OF THE CO-DESIGN SYSTEM 4.1 Modelling with VHDL 4.1.1 Design Units and Libraries 4.1.2 Entities and Architectures 4.1.3 Hierarchy 4.2 The Main System 4.3 The Microcontroller 4.3.1 Clock and Reset Generator 4.3.2 Sequencer 4.3.3 Bus Arbiter 4.3.4 Memory Read and Write 4.4 The Dynamic Memory: DRAM 4.5 The Coprocessor 4.5.1 Clock Generator 4.5.2 Coprocessor Data Buffers 4.6 Summary

53 54 55 55 57 58 60 61 61 65 68 72 74 75 76 77

Contents

ix

5. SHARED MEMORY CONFIGURATION 5.1 Case Study 5.2 Timing Characteristics 5.2.1 Parameter Passing 5.2.2 Bus Arbitration 5.2.3 Busy-Wait Mechanism 5.2.4 Interrupt Mechanism 5.3 Relating Memory Accesses and Interface Mechanisms 5.3.1 Varying Internal Operations and Memory Accesses 5.3.2 Varying the Coprocessor Memory Access Rate 5.3.3 Varying the Number of Coprocessor Memory Accesses 5.4 Summary

81 82 85 87 87 88 90 92 94 96 98 105

6. DUAL-PORT MEMORY CONFIGURATION 6.1 General Description 6.1.1 Contention Arbitration 6.1.2 Read/Write Operations 6.2 The System Architecture 6.2.1 Dual-Port Memory Model 6.2.2 The Coprocessor 6.2.3 Bus Interface Controller 6.2.4 Coprocessor Memory Controller 6.2.5 The Main Controller 6.3 Timing Characteristics 6.3.1 Interface Mechanisms 6.4 Performance Results 6.4.1 Varying Internal Operations and Memory Accesses 6.4.2 Varying the Memory Access Rate 6.4.3 Varying the Number of Memory Accesses 6.4.4 Speedup Achieved 6.5 Summary

107 108 108 110 111 111 113 113 114 117 118 120 121

7. CACHE MEMORY CONFIGURATION 7.1 Memory Hierarchy Design 7.1.1 General Principles 7.1.2 Cache Memory

133 134 134 135

121 126 127 129 130

x

Contents

7.2

7.3 7.4

7.5

System Organization 7.2.1 Cache Memory Model 7.2.2 The Coprocessor 7.2.3 Coprocessor Memory Controller 7.2.4 The Bus Interface Controller Timing Characteristics 7.3.1 Block Transfer During Handshake Completion Performance Results 7.4.1 Varying the Number of Addressed Locations 7.4.2 Varying the Block Size 7.4.3 Varying the Number of Memory Accesses 7.4.4 Speedup Achieved 7.4.5 Miss Rate with Random Address Locations Summary

138 138 139 140 145 150 155 158 159 162 164 166 167 169

8. ADVANCED TOPICS AND FURTHER RESEARCH 8.1 Conclusions and Achievements 8.2 Advanced Topics and Further Research 8.2.1 Complete VHDL Model 8.2.2 Cost Evaluation 8.2.3 New Configurations 8.2.4 Interface Synthesis 8.2.5 Architecture Synthesis 8.2.6 Framework for co-design 8.2.7 General Formalization

173 173 176 176 177 177 177 177 177 178

Appendices A Benchmark Programs B Top-Level VHDL Model of the Co-design System C Translating PALASMT M into VHDL D VHDL Version of the Case Study

185 185 191 199 205

References

219

Index

225

List of Figures

2.1 2.2 2.3 2.4 2.5 2.6 3.1 3.2 3.3 3.4 3.5 3.6 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10

The co-design flow Typical CLB connections to adjacent lines Intel FLEXlogic iFX780 configuration Target architecture with parameter memory in the coprocessor Target architecture with memory-mapped parameter registers Target architecture using a general-purpose processor and ASICs Development route Hardware synthesis process Run-time system Run-time system and interfaces Target architecture Bus interface control register Main system configuration Coprocessor board components Logic symbol for the microcontroller VHDL model for the clock and reset generator Writing into the coprocessor control register The busy-wait model The interrupt routine model Completing the handshake, by negating N copro st Algorithmic state machine for the bus arbiter Algorithmic state machine for memory read/write xi

11 19 21 24 25 26 31 34 37 38 39 43 59 60 60 62 63 64 65 66 67 70

xii

List of Figures

4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 6.12

Logic symbol for the DRAM 16 Algorithmic state machine for the DRAM Logic symbol of the coprocessor Logic symbol of the coprocessor clock generator Flowchart for the coprocessor clock generator Logic symbol of the coprocessor data buffers Flowchart for the coprocessor input buffer control Flowchart for the coprocessor output buffer control C program of example Modified C program Passing parameter table to the coprocessor Sampling of the bus request input signal (N br) Bus arbitration without contention Bus arbitration when using busy-wait Handshake completion when using busy-wait End of coprocessor operation with interrupt Handshake completion when using interrupt Graphical representation for Tbw and Tint , in terms of iterations Graphical representation for Tb and Ti , in terms of accesses Relation between N memf in and mem f in, for busy-wait Logic symbol of the dual-port memory Arbitration logic Main system architecture Coprocessor board for the dual-port configuration Logic symbol of DRAM16 State machine for the dual-port memory model Logic symbol of the coprocessor for the dual-port configuration Logic symbol of the bus interface controller Logic symbol of the coprocessor memory controller State machine of the coprocessor memory accesses controller State machine of the DRAM controller Logic symbol of the main controller

72 73 74 75 75 76 77 78 83 84 86 88 89 90 91 92 93 97 99 103 108 110 111 112 112 114 115 115 116 117 118 119

List of Figures

6.13 6.14 6.15 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10 7.11 7.12 7.13 7.14 7.15 7.16 7.17 7.18 7.19 7.20 7.21

Chart for Tb and Ti , in terms of iterations Coprocessor memory access Synchronization between memory controller and accelerator Addressing different memory levels Block placement policies, with 8 cache blocks and 32 main memory blocks Coprocessor board for the cache memory configuration Logic symbol of the cache memory model Flowchart for the cache memory model Logic symbol of the coprocessor for the cache configuration Logic symbol for the coprocessor memory controller Virtual address for the cache memory configuration Cache directory Algorithmic state machine for the coprocessor memory controller Logic symbol of the bus interface controller for the cache configuration Algorithmic state machine for the block transfer Algorithmic state machine for the block updating Coprocessor cache memory write Bus arbitration when there is a cache miss Transferring a word from the cache to the main memory End of the block transfer during a cache miss End of coprocessor operation and beginning of block update End of transfer of block 0 Handshake completion after block updating C program example, with random address locations

xiii 123 124 125 135 136 138 139 140 140 141 141 142 143 146 147 149 151 152 153 155 157 158 159 168

List of Tables

2.1 3.1 3.2 5.1 5.2 5.3 5.4 5.5 5.6 5.7 6.1 6.2 6.3 6.4 6.5

Some characteristics of the XC4000 family of FPGAs Performance results for PLUM Performance results for EGCHECK Performing 10 internal operations and a single memory access per iteration Performing 100 internal operations and one memory access per iteration Performing 10 iterations and a single memory access per iteration Performing 10 iterations and 10 internal operations Performing 10 internal operations and no memory accesses Performing 10 internal operations and 2 memory accesses per iteration Performing 10 internal operations and 3 memory accesses per iteration Performing 10 internal operations and a single memory access per iteration Performing 10 internal operations and a single memory access per iteration Performing 10 iterations and a single memory access per iteration Performing 10 iterations and 10 internal operations Performing 10 internal operations and 2 memory accesses per iteration

xv

18 47 48 94 96 96 98 100 101 101 121 126 127 128 129

xvi

List of Tables

7.1 7.2 7.3 7.4 7.5

7.6

Performing 10 operations and 1 memory access per iteration with BS = 512 bytes Performing 10 operations and 1 memory access per iteration, with BS = 256 bytes Performing 10 operations and 1 memory access per iteration, with BS = 128 bytes Performing 10 iterations and 10 internal operations, with BS = 512 bytes Performing 10 internal operations and 1 memory access per iteration, with BS = 512 bytes and random address locations Performing 10 operations and 1 memory access per iteration, with BS = 128 bytes and random address locations

160 163 164 165

167

169

Preface

In this Book, we are concerned with studying the co-design methodology, in general, and how to determine the more suitable interface mechanism in a co-design system, in particular. This will be based on the characteristics of the application and those of the target architecture of the system. We provide guidelines to support the designer’s choice of the interface mechanism. The content of this book is divided into 8 chapters, which will be described in the following: In Chapter 2, we present co-design as a methodology for the integrated design of systems implemented using both hardware and software components. This includes high-level synthesis and the new technologies available for its implementation. Recent work in the co-design area is introduced. In Chapter 3, the physical co-design system developed at UMIST is then presented. The development route adopted is discussed and the target architecture described. Performance results are then presented based on experimental results obtained. The relation between the execution times and the interface mechanisms is analysed. In order to investigate the performance of the co-design system for different characteristics of the application and of the architecture, we developed, in Chapter 4, a VHDL model of our co-design system. In Chapter 5, a case study example is presented, on which all the subsequent analysis will be carried out. The timing characteristics of the system are introduced, that is times for parameter passing and bus arbitration for each interface mechanism, together with their handshake completion times. The relation between the coprocessor memory accesses and the interface mechanisms is then studied. In Chapter 6, a dual-port shared memory configuration is introduced, in substitution to the single-port shared memory of the original configuration. This new configuration aims to reduce the occurrence of bus contention, naturally present in a shared bus architecture. Our objective is to identify performance xvii

xviii

Preface

improvements due to the substitution of the single-port shared memory by the dual-port shared memory. In Chapter 7, A cache memory for the coprocessor is later on introduced into the original single-port shared memory configuration. This is an alternative to the dual-port memory, allowing us to reduce bus contention, while keeping the original shared memory configuration. The identification of performance improvements, due to the inclusion of a cache memory for the coprocessor in the original implementation, is then carried out. In Chapter 8, we describe new trends in co-design and software acceleration. N. Nedjah and L. M. Mourelle

Acknowledgments

We are grateful to FAPERJ (Fundac¸˜ao de Amparo `a Pesquisa do Estado do Rio de janeiro, http://www.faperj.br) and CNPq (Conselho Nacional de Desenvolvimento Cient´ıfico e Tecnol´ogico, http://www.cnpq.br) for their continuous financial support.

xix

Chapter 1 INTRODUCTION

In a digital system, hardware is usually considered to be those parts of the system implemented using electronic components, such as processors, registers, logic gates, memories and drivers. Software is thought of as the sub-systems implemented as programs stored in memory as a sequence of bits, which are read and executed by a processor. In a traditional design strategy, the hardware and software partitioning decisions are fixed at an early stage in the development cycle and both designs evolve separately (Kalavade and Lee, 1992; Kalavade and Lee, 1993; N. S. Woo and Wolf, 1994). Certain operations are clearly implemented by hardware, such as high-speed data packet manipulation; others by software, such as recursive search of a tree data structure; and there are usually a collection of further operations that can be implemented either by hardware or by software. The decision to implement an operation in hardware or software is based on the available technology, cost, size, maintainability, flexibility and, probably most importantly, performance. Advances in microelectronics have offered us large systems containing a variety of interacting components, such as general-purpose processors, communicationsub-systems, special-purpose processors (e.g., Digital Signal Processors – DSP), micro-programmed special-purpose architectures, off–the-shelf electronic components, logic-array structures (e.g., Field Programmable GateArrays – FPGAs) and custom logic devices (e.g., Application Specific Integrated circuits – ASICs) (Subrahmanyam, 1992; Subrahmanyam, 1993; Wolf, 2004). Today’s products contain embedded systems implemented with hardware controlled by a large amount of software (G. Borriello, 1993). These systems have processors dedicated to specific functions and different degrees of 1

2

Introduction

programmability (Micheli, 1993) (e.g., microcontrollers), namely the application, instruction or hardware levels. In the application level, the system is running dedicated software programs that allows the user to specify the desired functionality using a specialized language. At the instruction level, programming is achieved by executing on the hardware, the instructions supported by the architecture. hardware-level programming means configuring the hardware, after manufacturing, in the desired way. There have also been advances in some of the technologies related to design system, such as logic synthesis, and system level simulation environments, together with formal methods for design specification, design and verification (Subrahmanyam, 1992; Subrahmanyam, 1993). In this chapter, we discuss the concept of synthesis and design approaches. Later on, the co-design concept is introduced, together with a methodology for its application. Finally, the objective of this book is then presented, together with its structure.

1.1

Synthesis

Synthesis is the automatic translation of a design description from one level of abstraction to a more detailed, lower level of abstraction. A behavioral description defines the mapping of a system’s inputs to its outputs and a structural description indicates the set of interconnected components that realize the required system behavior. The synthesis process offers reduction in the overall design time and cost of a product, together with a guarantee of the circuit correctness. However, the synthesized design may not be as good as one produced manually by an experienced designer. Architectural synthesis allows the search for the optimal architectural solution relative to the specified constraints (E. Martin and Philippe, 1993). High-level synthesis is the process of deriving hardware implementations for circuit s from high-level programming languages or other high-level specifications (Amon and Borriello, 1991). In order to have a behavioral description of the system, we use a hardware Description Language (HDL), which offers the syntax and semantics needed. As examples of suitable HDLs, we have the Specification and Description Language (SDL) (Rossel and Kruse, 1993; A.A. Jerraya and Ismail, 1993), the Very high speed integrated circuit s hardware Description Language (VHDL) (Ecker, 1993a; Ecker, 1993b; Navabi, 1998), the high-level description language HardwareC (Gupta, 1993; R. K. Gupta and Micheli, 1992a; R. K. Gupta and Micheli, 1992b; R. K. Gupta and Micheli, 1994; Gupta and Micheli, 1992; Gupta and Micheli, 1993; Ku and Micheli, 1990). Instead of a hardware description language, it is possible to use a highlevel programming language, such as C or C++, to describe the system behavior, making the translation to a hardware description language at a later stage of the design process (M. D. Edwards, 1993; Edwards and Forrest, 1994; Edwards

Design Approaches

3

and Forrest, 1995; Edwards and Forrest, 1996a; Edwards and Forrest, 1996b; P. Pochmuller and Longsen, 1993). Using high-level synthesis techniques, we can synthesize digital circuits from a high-level specification (Thomas, 1990; D. E. Thomas and Schmit, 1993) which have the performance advantages offered by customizing the architecture to the algorithm (Srivastava and Brodersen, 1991; M. B. Srivastava and Brodersen, 1992). Nevertheless, as the number of gates increases, the cost and turnaround time, i.e., the time taken from the design specification until its physical implementation, also increase, and for large system designs, synthesized hardware solutions tend to be expensive (Gupta, 1993; Gupta and Micheli, 1993). Despite the increase in power and flexibility achieved by new processors, users are always asking for something more. In order to satisfy this demand, it would be necessary to add special-purpose modules to a processor system. However, this would constrain the system and the usually small market generated for a specialized function discourages companies from developing hardware to satisfy such needs. A solution to this problem would be the use of a reconfigurable system, based on, say, Field-Programmable Gate Arrays (FPGAs), which could be attached to a standard computer, for performing functions normally implemented by special-purpose cards (D. E. Van den Bout, 1992). This kind of implementation offers faster execution, low cost and low power, since the necessary logic is embedded in the ASIC component.

1.2

Design Approaches

For a behavioral description of a system implemented as a program, running on a processor, we have a low cost and flexible solution. Typically, the pure software implementations of a system are often too slow to meet all of the performance constraints, which can be defined for the overall time (latency) to perform a given task or to achieve predetermined input/output rates (R. K. Gupta and Micheli, 1992b). Depending on these constraints, it may be better to have all or part of the behavioral description of the system implemented as a hardware circuit. In this kind of implementation, hardware modifications cannot be performed as dynamically as in a software implementation and the relative cost is higher, since the solution is customized. System designers are faced with a major decision: what kind of implementation is the best, given a behavioral description of a system and a set of performance constraints – a software or a hardware solution? Cost-effective designs use a mixture of hardware and software to accomplish their overall goals (Gupta, 1993; Gupta and Micheli, 1993). Dedicated systems, with hardware and software tailored for the application, normally provide performance improvements over systems based on general-purpose hardware (Srivastava and Brodersen, 1991; M. B. Srivastava and Brodersen, 1992). Mixed system

4

Introduction

designs, using ASICs, memory, processors and other special-purpose modules reduce the size of the synthesis task by minimizing the number of applicationspecific chips required, while, at the same time, achieving the flexibility of software reprogramming to alter system behavior. However, the problem is usually more complex, since the software on the processor implements system functionality in an instruction-driven manner with a statically allocated memory space, whereas ASICs operate as data-driven, ıreactive elements (Chiodo and Sangiovanni-Vincentelli, 1992; Gupta and Micheli, 1992). Nevertheless, additional problems must also be solved (R. K. Gupta and Micheli, 1992a; Gupta and Micheli, 1992), such as: modeling system functionality and constraints; determining the boundaries between hardware and software components in the system model; specifying and synthesizing the hardware-software interface; implementing hardware and software components.

1.3

Co-Design

Co-design refers to the integrated design of systems implemented using both hardware and software components (Subrahmanyam, 1992; Subrahmanyam, 1993), given a set of performance goals and an implementation technology. In this way, it is not a new approach to designing systems. What is new is the requirement for systematic, scientific co-design methods (Wolf, 1993). The co-design problem entails characterizing hardware and software performance, identifying a hardware-software partition, transforming the functional description of a system into such a partition and synthesizing the resulting hardware and software (D. E. Thomas and Schmit, 1993). From a behavioral description of the system, that is an implementation independent one, a partitioning could be performed into hardware and software components based on imposed performance constraints. hardware solutions may provide higher performance by supporting the parallel execution of operations, but there is the inherent cost of fabricating one or more ASICs. On the other hand, software solutions will run on high-performance processors, which are available at lower cost due to high-volume production. However, the serialization of operations and the lack of specific support for some tasks can decrease performance (Micheli, 1993). Designers might start with an all-software implementation, in which case it is said to be a software-oriented approach (M. D. Edwards, 1993; Edwards and Forrest, 1994; Edwards and Forrest, 1995; Edwards and Forrest, 1996a; Edwards and Forrest, 1996b; Ernst and Henkel, 1992; R. Ernst and Benner,

5

Co-Design

1993) and check the implementation’s functionality. Later on, they might refine the design over time to get a mixed hardware-software design (M. D. Edwards, 1993; Edwards and Forrest, 1994; Edwards and Forrest, 1995; Edwards and Forrest, 1996a; Edwards and Forrest, 1996b; N. S. Woo and Wolf, 1994; N. S. Woo and Dunlop, 1992), in which ASIC components are chosen to complement performance or add functionality not achievable by pure program implementations alone (Gupta and Micheli, 1992), such as floating-point operations. On the other hand, it is possible to start with a hardware implementation, called a hardware-oriented approach (R. K. Gupta and Micheli, 1992b), and try, gradually, to move hardware functions to software, taking into account timing constraints and synchronization requirements. A good design trade-off is to improve the event that happens more frequently. The impact of making some occurrence faster is higher if the occurrence is frequent. Therefore, the point now is to decide what the frequent case is and how much performance can be improved by making that case faster. We will return to this subject in Chapter 3, when the co-design system developed at UMIST is discussed.

1.3.1

Methodology

In recent years, several integrated CAD environments for the automatic generation of ASICs have been developed, that have resulted in a reduction in the overall design time of a system (Srivastava and Brodersen, 1991). On the other hand, computer aids are available in order to assist with the structured design of software systems. In practice, we may want to (Chiodo and SangiovanniVincentelli, 1992): formally verify a design in order to check whether the system satisfies a number of properties that specify its correctness; simulate to check whether the system responds correctly to the stimuli that the environment is supposed to produce; automatically synthesize an implementation consistent with user-defined criteria, such as speed and area. The chosen synthesis methodology may be for general-purpose applications (M. D. Edwards, 1993; Edwards and Forrest, 1994; Edwards and Forrest, 1995; Edwards and Forrest, 1996a; Edwards and Forrest, 1996b) or for domainspecific applications, such as DSPs (Kalavade and Lee, 1992; Kalavade and Lee, 1993) or ASIPs (A. Alomary, 1993). Some tools are available using high-level synthesis techniques to generate a purely hardware implementation of a system, such as CATHEDRAL II (J. Rabaey, 1988), OLYMPUS (G. De Micheli and Truong, 1990), System Architecture’s Workbench (Thomas, 1990) and CONES (Stroud, 1992).

6

Introduction

A framework for co-design means a methodology along with a complementary set of tools for specification, development, simulation/prototyping and testing (Subrahmanyam, 1992; Subrahmanyam, 1993). It must provide estimates of the performance metrics, such as size, power, cost, maintainability, flexibility and modifiability. In (Kalavade and Lee, 1992; Kalavade and Lee, 1993), a framework called PTOLEMY is used for simulating and prototyping heterogeneous systems, while in (Buchenrieder and Veith, 1992; Buchenrieder, 1993; Buchenrieder and Veith, 1994) another framework called CODES is used as a environment for concurrent system design.

1.3.2

Simulation

Another interesting problem is related to the simulation of hardware, taking into account the existence of the associated software. This is known as co-simulation (D. Becker and Tell, 1992; D. E. Thomas and Schmit, 1993). In this case, both software and hardware are expected to be developed in parallel and their interaction is analyzed, using the simulation of the hardware components. POSEIDON (R. K. Gupta and Micheli, 1992a; Gupta and Micheli, 1992) is a tool that allows for the simulation of multiple functional modules implemented either as a program or as behavioral or structural hardware models.

1.3.3

Architecture

In a co-design system, the target system architecture usually consists of a software component, as a program running on a re-programmable processor, assisted by application-specific hardware components (M. D. Edwards, 1993; Edwards and Forrest, 1994; Edwards and Forrest, 1995; Edwards and Forrest, 1996a; Edwards and Forrest, 1996b; Gupta, 1993; R. K. Gupta and Micheli, 1992a; R. K. Gupta and Micheli, 1992b; R. K. Gupta and Micheli, 1994; Gupta and Micheli, 1992; Gupta and Micheli, 1993). Some aspects that lead to this kind of implementation are (Srivastava and Brodersen, 1991; Subrahmanyam, 1993): the increasing diversity and complexity of applications employing embedded systems (D. D. Gajski and Gong, 1994); the need for decreasing the cost of designing and testing such systems; advances in some of the key enabling technologies, such as logic synthesis and formal methods.

1.3.4

Communication

From the hardware/software co-design point of view, it is important to ensure the proper communication between the hardware and software sub-systems. If we take a closer look at software running on a processor, we recognize

Structure and Objective

7

that hardware/software communication is nothing else but hardware/hardware communication (Monjau and Bunchenrieder, 1993) at the lower levels. Thus, if we are able to map the abstract communication to distinct protocols for the hardware parts, we can also do this for the communication between the hardware and software parts. From a software perspective, communication with the hardware processes of the system has to be performed via some special device driver software and associated system calls provided by the processor’s operating system (Rossel and Kruse, 1993). Due to the parallelism associated with embedded systems, they can be expressed as a set of concurrent sequential processes communicating via message queues (Monjau and Bunchenrieder, 1993; M. B. Srivastava and Brodersen, 1992). Amon (Amon and Borriello, 1991) discusses the problem of sizing synchronization queues, in order to implement constructs such as send and receive.

1.4

Structure and Objective

In the rest of the book, we present co-design as a methodology for the integrated design of systems implemented using both hardware and software components. The initial system specification is partitioned into hardware and software sub-systems that will have to communicate during the execution of the application. The objective of this research is to analyze the behavior of the co-design system, based on different interface mechanisms between the hardware and software sub-systems. As a result of this analysis, we provide some guidelines to support the designer in the choice of the most suitable interface, according to the of the application and of the co-design system under consideration. In Chapter 2, the co-design methodology is discussed in more detail. Highlevel synthesis is also presented, together with the new technologies available for its implementation. Along with the discussion, recent work in the co-design area is introduced as examples. In Chapter 3, the physical co-design system developed at UMIST is discussed. The development route is outlined and the target architecture is described. performance results are then presented based on experimental results obtained. The relation between the execution times and the interface mechanisms employed is then discussed. In Chapter 4, we present the VHDL model of our co-design system. Since we have already a physical implementation of the system, the procedure adopted for modeling it is explained. Most of the components will be manually translated from their previous description into VHDL, in a quite straightforward process. Others, such as the global memory, will have to be modeled based on their behavior and how they interface with the rest of the system. In Chapter 5, the simulation of the VHDL model of the co-design system is described. A case study example is presented, on which all the subsequent

8

Introduction

analysis will be carried out. The timing of the system are introduced, that is times for parameter passing and bus arbitration for each interface mechanism, together with their handshake completion times. The relation between the coprocessor memory accesses and the interface mechanisms is then analyzed. In Chapter 6, we continue the simulation process, based on a dual-port shared memory configuration. The new system’s architecture is presented, together with the necessary modifications to the original VHDL models and the derivation of new models. Once again, the timing of the new system are introduced. performance results are obtained based on the same case study used in the previous chapter. Our aim is to identify any performance improvement due to the substitution of the single-port shared memory, in the original implementation, by the dual-port shared memory. In Chapter 7, a cache memory for the coprocessor is introduced into the original single-port shared memory configuration. The concept of memory hierarchy design is discussed, in order to provide the necessary background for the subsequent analysis. So far, the new organization of the system is presented, together with the necessary modifications to the existing VHDL models and the derivation of new modules. Continuing our study of the system’s performance, timing are then presented. performance results are obtained based on the same case study used in the two previous chapters. The identification of performance improvements, due to the inclusion of a cache memory for the coprocessor in the original implementation, is carried out. In Chapter 8, we present some conclusions based on this research and some ideas for future work are also outlined. A comparison between the single shared memory configuration, the dual-port shared memory configuration and the coprocessor cache configuration is undertaken, based on the simulation results obtained.

Chapter 2 THE CO-DESIGN METHODOLOGY

Computing systems are becoming increasingly complex and often contain large amounts of both hardware and software. The need for methodological support in managing the development process of such systems, therefore, becomes more urgent. The user’s requirements are partitioned into functional and nonfunctional subsets, from which a functional view and an architectural view, i.e., the environment the system has to function in, can be derived. The subject of computing is then split between hardware and software at an early stage. The hardware development will be based on cost and performance, whilst the software development will be guided by the functional requirements of the system. Each development process will have its own models in its own environment. Problems discovered during integration and test, but after hardware fabrication, cause projects to run over budget, behind schedule and result in systems that may not fully satisfy user needs (Kuttner, 1996). Hence, it is important to produce systems that are “right first time”. The design of heterogeneous hardware/software systems is driven by a desire to maximize performance and minimize cost. Therefore, it is necessary to use an integrated design environment, which is capable of investigating and modeling the performance and process functionality of the hardware/software system (Cooling, 1995). The design process can be defined as a sequence of transformations that begins with a system specification and leads to an implementation of the system. The steps in the sequence are defined by system models in decreasing levels of abstraction and, at every step in the sequence, an input model is transformed into an output model (Monjau and Bunchenrieder, 1993). This chapter presents the co-design methodology and recent developments in this area. High-level synthesis is also discussed as it is central to the 9

10

The Co-design Methodology

implementation of mixed hardware/software systems. New implementation technologies are presented followed by a review of the available synthesis tools.

2.1

The Co-Design Approach

Co-design refers to a methodology for the integrated design of systems implemented using both hardware and software components (Subrahmanyam, 1993), given a set of performance goals and an implementation technology. In this way, it is not a new approach. What is new is the requirement for systematic, scientific co-design methods (Wolf, 1993). The co-design problem entails (D. E. Thomas and Schmit, 1993): characterizing hardware and software performance; identifying a hardware/software partition; transforming the functional description into such a partition; synthesizing the resulting hardware and software. From a behavioral description of the system, that is implementation independent, a partitioning could be done into hardware and software components, based on imposed performance constraints (R. K. Gupta and Micheli, 1992a; R. K. Gupta and Micheli, 1992b; Gupta and Micheli, 1992), cost, maintainability, flexibility and area, in terms of logic and space requirements (N. S. Woo and Wolf, 1994). hardware solutions may provide higher performance by supporting the parallel execution of operations, but there is the cost of fabricating one or more ASICs1 . On the other hand, software solutions will run on high-performance processors available at low cost due to high-volume production. However, the serialization of operations and the lack of specific support for some tasks can decrease performance (Micheli, 1993). A framework for co-design means a methodology along with a complementary set of tools for the specification, development, simulation/prototyping and testing of systems. It may be suitable for general-purpose applications (M. D. Edwards, 1993; Edwards and Forrest, 1994; Edwards and Forrest, 1995; Edwards and Forrest, 1996a; Edwards and Forrest, 1996b) or for a specific domain (Kalavade and Lee, 1992; Kalavade and Lee, 1993), but, in general, the co-design methodology consists of the steps presented in Figure 2.1. The following sections introduce each step. An example of a framework for co-design is PTOLEMY (J. Buck and Messerschmitt, 1990; University of California and Science, 1992), a software environment for the simulation and prototyping of heterogeneous systems. It uses object-oriented software technology to model sub-systems using different techniques and has mechanisms to integrate these sub-systems into a complete model.

11

System Specification

Figure 2.1. The co-design flow

Another example of framework for co-design is POLIS (F. Balarin, 1997), which makes use of a methodology for specification, automatic synthesis and validation of embedded systems (D. D. Gajski and Gong, 1994). Design is done in a unified framework, with unified hardware/software representation, so as to prejudice neither hardware nor software implementation (Wolf, 2002). This model is maintained throughout the design process, in order to preserve the formal properties of the design. POLIS uses the PTOLEMY environment to perform co-simulation. Partitioning is done using this co-simulation, thus allowing a tight interaction between architectural choices and performance/cost analysis. The COSYMA system (Ernst and Henkel, 1992; R. Ernst and Benner, 1993) is a platform for co-synthesis of embedded architectures. It follows a softwareoriented co-synthesis approach, in which as many operations as possible are implemented in software. External hardware is generated only when timing constraints are violated. COSYMA uses the OLYMPUS (G. De Micheli and Truong, 1990) high-level synthesis tool for hardware synthesis and simulation.

2.2

System Specification

For system specification, we can use a hardware description language, such as VHDL (Ecker, 1993a; Ecker, 1993b; Wendling and Rosenstiel, 1994). The development of VHDL as a general design tool was to overcome the problem of a design becoming target dependent. In this way, a design may be created in VHDL and the target technology chosen after the fact. The design may then be synthesized into a target technology by the application of synthesis tools. Once the technology changes, it will be necessary to re-synthesize the design only, instead of a complete logic redesign. The resulting benefit to the user

12

The Co-design Methodology

is a dramatic reduction in time-to-market by saving on learning curve time, redesign time and design entry time. Another possibility is of using a high-level description language, such as HardwareC (Gupta, 1993; R. K. Gupta and Micheli, 1992a; R. K. Gupta and Micheli, 1992b; R. K. Gupta and Micheli, 1994; Gupta and Micheli, 1992; Gupta and Micheli, 1993) for the system specification. The HardwareC language (Ku and Micheli, 1990) has a C-like syntax and supports timing and resource constraints. This language supports specification of unbounded and unknown delay operations that can arise from data dependent decisions and external synchronization operations. A high-level programming language, such as C or C++, can also be used for system specification (M. D. Edwards, 1993; Edwards and Forrest, 1994; Edwards and Forrest, 1995; Edwards and Forrest, 1996a; Edwards and Forrest, 1996b). In this case, we can say that the design follows a software-oriented approach, in contrast to the hardware-oriented approach provided by VHDL and HardwareC. The translation to a hardware description language is made at a later stage in the design process. There are some languages used for specific applications, such as the Specification and Description Language (SDL ) (Rossel and Kruse, 1993), for communication systems, and PROMELA(A. S. Wenban and Brown, 1992), a high-level concurrent programming language used for communication protocol specifications. In (N. S. Woo and Wolf, 1994; N. S. Woo and Dunlop, 1992), an ObjectOriented Functional Specification language (OOFS) is used, in order to avoid biasing the initial specification to hardware or software. When using PTOLEMY (Kalavade and Lee, 1992; Kalavade and Lee, 1993), the specification of the system is described in domains, which provides a different computational model, such as the Synchronous Data Flow (SDF ) domain, for filters and signal generators, and the digital-hardware modeling (Thor) domain, for digital hardware.

2.3

Hardware/Software Partitioning

Given some basis for evaluating system performance, it is possible to decide which tasks should be implemented as hardware and which as software. If a task interacts closely with the operating system, software may be the only feasible implementation. Likewise, if a task interacts closely with external signals, implementing it in hardware may be the only practical solution. We can determine which to pursue according to the following criteria: dynamic properties of the system: a characterization of how the execution time of a task impacts system performance; static properties of the task: the difference in execution times between hardware and software implementations of the task;

Hardware/Software Partitioning

13

hardware costs: the amount of custom hardware required to realize a hardware implementation of the task. The first consideration takes into account how the system performance depends on the execution time of each task, which in turn depends on the criterion by which system performance is measured. In the second case, some tasks are inherently much better suited for hardware implementation than others. To quantify these differences, we must identify properties of a task behavior that indicate how software and hardware implementations of the task will perform. In considering the amount of custom hardware necessary to reduce a task execution time, we must see that, for some tasks, custom hardware implementations might perform well, but be impractical due to high gate counts or memory requirements. For others, there may be a range of achievable performance gains, depending on how much of the custom hardware is devoted to the task. In the case of embedded systems (D. D. Gajski and Gong, 1994; Wolf, 2002), a hardware/software partition represents a physical partition of the system functionality into application-specific hardware (coprocessor) and software executing on one or more processors. The hardware/software interface strongly affects partitioning. The aim in this kind of architecture is to improve the system performance. In this sense, partitioning seeks to maximize the overall speedup for a given application. The speedup estimation can be done by a profiling analysis that takes into account typical data sets over which the application behavior is estimated. Due to this data dependence, in some application areas the speedup may not be a well-defined metric or it may not be a useful metric either, particularly in those with real-time response requirements. In such cases, the size of the implementation and timing constraint satisfaction are used to drive the partitioning decision. Some partitioning strategies are discussed in (Micheli and Gupta, 1997). In (M. D. Edwards, 1993; Edwards and Forrest, 1994; Edwards and Forrest, 1995; Edwards and Forrest, 1996a; Edwards and Forrest, 1996b), from a system specification written in C, partitioning is based on the identification of performance critical regions, using an interactive profiling tool. The partitioning tool (Wright, 1997) then translates the C code for the body of a critical region to a hardware description language representation, in order to enable high-level hardware synthesis. The identified C source code for a critical region is adapted to implement a “hardware” call/return mechanism, which invokes the associated operations in the hardware component (see Section 3.1.2). Another method implements partitioning based on the fact that some operations are best performed by hardware, others by software and some either by hardware or by software (N. S. Woo and Wolf, 1994; N. S. Woo and Dunlop,

14

The Co-design Methodology

1992). This yields three groups of operations: hardware (H), software (S) and co-design (C). Each object and operation in the S group is defined in the C++ language. Each object and operation in the H group is defined in C++ in order to emulate the object and its operation. These C++ programs will be used for a simulation of the whole system. Each object and operation in the C group is defined in OOFS (Object-Oriented Functional Specification). The system designers indicate whether each specification in the last group will be implemented by software or by hardware, which will define the translation from the co-specification language to C++ or BESTMAP-C (Laboratories, 1992), a hardware description language, respectively. The HardwareC description used in (Gupta, 1993; R. K. Gupta and Micheli, 1992a; R. K. Gupta and Micheli, 1992b; R. K. Gupta and Micheli, 1994; Gupta and Micheli, 1992; Gupta and Micheli, 1993) is compiled into a system graph model based on data-flow graphs. This graph consists of vertices representing operations and edges which represent serialization among operations. Overall, the system graph model is composed of concurrent data flow sections, which are ordered by the system control flow. Considering an initial solution in hardware, some operations are selected for moving into software, based on a cost criterion of communication overheads. With the serialization of the operations and analysis of the corresponding assembly code, delays through the software component can be derived. The movement of operations to software is then constrained by the satisfaction of timing constraints. As a second approach to system partitioning, the effect of non-determinism is taken into account, which is caused either by external synchronization operations (send, receive) or by internal data-dependent delay operations (loops, conditionals). System partitioning is performed by decoupling the external and internal points of non-determinism in the system model. The external non-deterministic points are implemented using application-specific hardware and the internal non-deterministic points are implemented in software. If the initial partition is feasible, then it is refined by migrating operations from hardware to software, in search for a lower cost feasible partition. The partition is indicated by “tagging” the system graph’s vertices to be either hardware or software. In (Ernst and Henkel, 1992; R. Ernst and Benner, 1993), as many operations as possible are implemented in software, using a subset of the C language, called C. External hardware is only generated when timing constraints are violated or in the case of I/O functions. The C-system description is parsed into a syntax graph CGL including all constraints, on which partitioning is performed. Those statements, which shall be implemented in software, are then translated to regular C. The original program structure is kept throughout the partitioning process.

Hardware Synthesis

15

In PTOLEMY (Kalavade and Lee, 1992; Kalavade and Lee, 1993), partitioning is performed manually, based on speed, complexity and flexibility requirements. The specification to be implemented in custom hardware and written in SDF2 is translated to SILAGE (Hilfinger, 1985), a functional language. This provides a link to high-level synthesis systems, that use SILAGE as specification of their inputs (Goosens, 1993; Rabaey, 1991). POLIS (F. Balarin, 1997) provides the designer with an environment to evaluate design decisions through feedback mechanisms, such as formal verification and system co-simulation. As a result of partitioning, we find finite state machine sub-networks chosen for hardware implementation and those chosen for software implementation. COSYMA (R. Ernst and Benner, 1993) executes hardware/software partitioning on a graph representation of the system by marking nodes to be moved to hardware. It follows an iterative approach, including hardware synthesis, compilation and timing analysis of the resulting hardware/software system. Simulation and profiling identify computation-time-intensive system parts. An estimation of the speedup is obtained through hardware synthesis and the communication penalty for nodes moved to hardware. The communication between the processor and the application-specific hardware implies additional delays and costs related to the interface circuit and protocol implemented. Once the integration phase has finished, simulation results should be returned to the partitioning stage, so that these additional parameters may be used to obtain a better hardware/software partition, i.e., one that will provide a better performance/cost trade-off.

2.4

Hardware Synthesis

Hardware synthesis is employed to generate the logic network for the hardware component. Synthesis is concerned with a reduction in design time and project cost, together with a guarantee of correctness for the circuit. The strategy for the synthesis process, given the behavioral specification of the system and a set of constraints, consists of finding a structure that implements the behavior and, at the same time, satisfies the constraints. A fundamental concept in the design of synthesis tools is that, from an implementation independent system specification, and based on the target technology libraries and user constraints, a number of possible implementations can be obtained (Jay, 1993). With the complexity found in new technologies, it is crucial to employ automatic synthesis tools (G. De Micheli and Truong, 1990), as part of the design process. Automatic synthesis presents some facilities, such as:

shorter design cycle, which means that a product can be completed faster, decreasing the cost in design and the time-to-market;

16

The Co-design Methodology

fewer errors, since the synthesis process can be verified, increasing the chance that the final design will correspond to the initial specification; the ability to search the design space, since the synthesis system can offer a variety of solutions from the same specification, i.e., a particular solution can be chosen by the designer in order to satisfy tradeoffs between cost, speed or power; documenting the design process, which means keeping track of the decisions taken and their effects; availability of integrated circuit technology to more people, as more design expertise is moved into the synthesis system, allowing non-expert people to produce a design.

2.4.1

High-Level Synthesis

High-level synthesis (M. C. McFarland and Camposano, 1990) obtains an optimized register-transfer description from an algorithmic one, which can be written in a high-level programming language or a hardware description language. The register-transfer description consists of an interconnected set of functional components (data path) together with the order in which these components are activated (control path). An example of high-level synthesis tool is the System Architect’s Workbench (Thomas, 1990). From the algorithmic description, a Control and Data Flow Graph (CDFG) can be derived, which specifies a set of data manipulation operations, their data dependencies and the order of execution of these operations. This graph can be optimized through the use of transformations similar to those found in a software compiler. Later on, scheduling and allocation are undertaken. The scheduling process means assigning data operations for execution in particular clock cycles. This allows the minimization of the number of clock cycles needed for the completion of the algorithm, given a set of hardware resources, which involves maximizing the number of operations that can be done in parallel, in each cycle. Some scheduling algorithms are considered in (Micheli and Gupta, 1997). The allocation task (M. C. McFarland and Camposano, 1990) assigns data operations to hardware resources, minimizing the amount of hardware required, in order to meet cost, area and performance constraints. A sub-task is module binding, where known components are taken from a hardware library. If there are not adequate components, then it might be necessary to generate a specialpurpose hardware, through the use of a logic synthesis tool. For the control path, an implementation must be found using finite state machines with hardwired or micro-programmed control.

Hardware Synthesis

2.4.2

17

Implementation Technologies

We can identify three types of logic devices (Coli, 1993): standard logic; programmable ASICs; masked ASICs. Standard logic devices are not specific to any particular application, being connected together to build an application. Programmable Application Specific Integrated Circuits (ASICs) include simple Programmable Logic Devices (PLDs), complex PLDs and Field Programmable Gate Arrays (FPGAs) (Wolf, 2004). Programmable ASICs are purchased in their un-programmed state and, then, programmed by the user for a specific application. Masked ASICs include gate-arrays and standard cells, being designed by the user for a specific application, tooled by the chosen supplier and, finally, purchased as a custom product. Circuit density and input/output count generally increase as one moves from standard logic to programmable ASICs and, then, to masked ASICs. Standard logic has the appeal of being purchased as a standard product, but compromises system integration by restricting the designer to interconnect many “catalogue” circuits. Masked ASICs are the opposite situation, in which they can be easily customized for the user’s specific application, but must be custom tooled and, therefore, purchased as a custom product. Programmable ASICs are a good compromise, because they are purchased as a standard product, but may be used as a custom product. The configuration of Field Programmable Logic Devices (FPLDs) (York, 1993) is achieved by either EPROM technology, anti-fuse or embedded register. EPROM and embedded registers are erasable, while the anti-fuse approach is one-time programmable. The embedded register configuration technique is commonly referred to as embedded RAM. All of the devices that are based on an embedded register produce the configuration data using shift registers, which, by its nature, is a serial process. The time-consuming delays, which arise due to the complexity of silicon processing, are avoided and this helps to facilitate a shorter time-to-market. It is now possible to implement systems of appreciable complexity on a single field programmable chip. A logic description of the circuit to be implemented in a Field Programmable Gate Array (FPGA) is created and, then, synthesized into a netlist. Synthesis is a critical step in the FPGA design process. For this purpose, there is a variety of input/output formats and tools available. The common goal of all these tools is to simplify the design process, maximize the chance of

18

The Co-design Methodology

Table 2.1. Some characteristics of the XC4000 family of FPGAs Device

XC4002A XC4008 XC4020

Approximate gate count CLB matrix Number of CLBs Number of flip-flops Max decode inputs (per side) Max RAM bits Number of IOBs

2,000 8×8 64 256 24 2,048 64

8,000 18 × 18 324 936 54 10,368 144

20,000 30 × 30 900 2280 90 28,800 240

first-time-success and accelerate time-to-market. Unlike masked ASIC tools, which are workstation based, a wide variety of FPGA tools are available on PCs as well as workstations. This can lower the design cost of an FPGA. The high quality and variety of FPGA CAE/CAD tools enhance FPGA design productivity. The availability of these tools on PCs and with open frameworks lowers barriers to use and promotes user-friendly design (Coli, 1993). FPGAs took advantage of the concept of multiple AND/OR arrays and local connectivity, introduced by complex PLDs (Coli, 1993; Wolf, 2004). An FPGA die offers many small arrays, called logic cells, dispersed around the chip. These logic cells are connected like a gate array using programmable interconnections. An example of FPGA is the XC4000 logic cell array family, produced by Xilinx (Xilinx, 1992; Xilinx, 1993), using CMOSSRAM technology. It provides a regular, flexible, programmable architecture of Configurable Logic Blocks (CLBs), interconnected by a powerful hierarchy of versatile routing resources and surrounded by a perimeter of programmable Input/Output Blocks (IOBs). Figure 2.2 shows a CLB and programmable switch matrixes, which allow for the connectivity between other CLBS and IOBs. The devices are customized by loading configuration data into the internal memory cells. The FPGA can either actively read its configuration data out of an external serial or byte-parallel PROM (master mode) or the configuration data can be written directly into the FPGA (slave and peripheral modes). Table 2.1 shows the characteristics of some FPGAs from the XC4000 family. The XC4000 family is the first programmable logic device to include on-chip static memory resources. An optional mode for each CLB makes the memory look-up tables usable as either a (16 × 2) or (32 × 1) bit array of read/write memory cells. The RAMs are very fast: read access is the same as a logic delay, about 5ns; write time is about 6ns; both are several times faster than any off-chip solution. This feature creates new possibilities for the system

Hardware Synthesis

19

Figure 2.2. Typical CLB connections to adjacent lines

designer: registered arrays of multiple accumulators, status registers, index registers, DMA counters, distributed shift registers, LIFO stacks and FIFO buffers are all readily and easily implemented. The Xilinx FPGAs are configured by the XACT design tools (Xilinx, 1994), the Xilinx development system, running on PCs or popular workstations. After schematic – or equation-based entry, the design is automatically converted to a Xilinx Netlist Format (XNF). XACT interfaces to popular design environments like Viewlogic, Mentor Graphics and OrCAD. The XC4000 series devices are used within our co-design environment and the basic steps for their configuration is presented in Section 3.1.3. Another example of a commonly used FPGA is the Intel FLEXlogic iFX780 family (Intel, 1994), which is fabricated using 0.8µ CHMOS EPROM technology. These devices are widely used in the target architecture of our co-design system. It consists of 8 Configurable Function Blocks (CFBs) linked by a global interconnect matrix. Each CFB can be defined either as a 24V10 logic block (i.e., 24 input/output lines between the block and the global interconnect matrix, and 10 input/output lines between the block and the external pins) or as a block

20

The Co-design Methodology

of 128 × 10 SRAM, as described in Figure 2.3. Any combination of signals in the matrix can be routed into any CFB, up to the maximum fan-in of the block (24). This combination will provide approximately 5,000 gates of logic. The SRAM has a minimum read/write cycle of 15ns, comparable to off-chip commercial ones. The combination of features available in the iFX780 makes it ideal for a wide variety of applications, such as bus control, custom cache control and DRAM control. The combination of SRAM and logic in a single device becomes a big advantage when designing communication controllers or bus interface controllers, where memory is required for buffering data in addition to the logic for the controller itself. The Intel FLEXlogic FPGA family is supported by industry standard design entry/programming environments, including Intel PLDshell PlusT M software (Intel, 1993), which runs on PCs. Third party tools support will be provided by vendors like Cadence, Data I/O, Logical Devices, Mentor Graphics, Minc, OrCAD, Viewlogic.

2.4.3

Synthesis Systems

The purpose of a synthesis system is to provide the designer with automatic synthesis tools, which lead to an implementation configuration from an implementation independent specification of the system and is based on the target technology. Besides synthesis itself, it usually provides the designer facilities for validation and simulation of the system specification, before the final configuration is obtained in the form of a gate netlist. COSMOS (A. A. Jerraya and Ismail, 1993) is an example of synthesis environment that allows the translation of a system specification written in SDL into VHDL, at the behavioral and register-transfer levels. Another example is AMICAL (I. Park and Jerraya, 1992), an interactive architectural synthesis system based on VHDL, which starts with a behavioral specification in VHDL and generates a structural description that may feed existing silicon compilers acting at the logic and register-transfer levels. The Princeton University Behavioral Synthesis System (PUBSS) (W. Wolf and Manno, 1992) and the Siemens High-Level Synthesis System (CALLAS) (J. Biesenack, 1993; Stoll and Duzy, 1992) are also examples of synthesis systems that use VHDL for the initial specification of a system. The OLYMPUS synthesis system (G. De Micheli and Truong, 1990) was developed at Stanford University for digital design. It is a vertically integrated set of tools for multilevel synthesis, technology mapping and simulation. The system supports the synthesis of ASICs from behavioral descriptions, written in HardwareC. Internal models represent hardware at different levels of abstraction and provide a way to pass design information among different tools. The OLYMPUS system includes behavioral, structural and logic synthesis tools. Since it is targeted for semi-custom implementations, its output is in terms of

Software Compilation

21

Figure 2.3. Intel FLEXlogic iFX780 configuration

gate netlists. Instead of supporting placement and routing tools, OLYMPUS provides an interface to standard physical design tools, such as MISII (Brayton, 1987) for multiple-level logic optimization. Examples of co-design systems using OLYMPUS for hardware synthesis can be found in (M. D. Edwards, 1993; Edwards and Forrest, 1994; Edwards and Forrest, 1995; Edwards and Forrest, 1996a; Edwards and Forrest, 1996b). Another example of synthesis system is ASYL+/Programmable Logic Synthesizer (ASYL+/PLS) (Technologies, 1995), which is dedicated to the FPGA/ CPLD3 user. It maps directly to physical cells in an optimized way. Xilinx designs, for instance, are mapped to CLBs or F-map and H-map primitives. Automatic migration is also implemented, so a design captured using the primitives associated with one FPGA or PLD family and even an ASIC library can be targeted to another. ASYL+/PLS comprises the ASYL+/VHDL tool, which accepts all classical constructs of synthesizable VHDL in one of the broadest VHDL support sets available.

2.5

Software Compilation

In PTOLEMY (Kalavade and Lee, 1992; Kalavade and Lee, 1993), the parts of the SDF specification to be implemented as software are sent to a code generation domain, that will generate the code for the target processor. Hence,

22

The Co-design Methodology

we can find an SDF domain synthesizing C code and a domain synthesizing assembly code for DSP. For communication protocols written in PROMELA (A. S. Wenban and Brown, 1992), a software compiler translates the PROMELA program into C++, suitable for embedded controllers. The user may need to supply additional C++ code, in order to support any external hardware interfaces. In (M. D. Edwards, 1993; Edwards and Forrest, 1994; Edwards and Forrest, 1995; Edwards and Forrest, 1996a; Edwards and Forrest, 1996b), from a system specification written in C, performance-critical regions are selected for hardware implementation, using an interactive profiling tool. The identified C source code for a critical region is then adapted to implement a “hardware” call/return mechanism, which invokes the associated operations in the hardware component. A more detailed description will be presented in Section 3.1.2. In POLIS (F. Balarin, 1997), the finite state machine-like sub-network chosen for software implementation is mapped into a software structure that includes a procedure for each machine. The first step consists of implementing and optimizing the desired behavior in a high-level, processor-independent representation of the decision process similar to a control/data flow graph. Subsequently, the control/data flow graph is translated into portable C code to be used by any available compiler, to implement and optimize it in a specific, microcontrollerdependent instruction set.

2.6

Interface Synthesis

Interface synthesis involves adding latches, FIFOs or address decoders in hardware and inserting code for I/O operations and semaphore synchronization in software. The hardware interface circuitry can be described in a separate behavioral model. PTOLEMY offers some options, such as inter-processor communication (IPC) or communication between custom hardware and processors. In modeling software, we represent an I/O system call, such as read or write to the hardware device, by an appropriate inter-process communication primitive. In the case of a process described in a hardware description language, where data transfer and synchronization are often represented as explicit port operations, a single inter-process communication primitive represents the set of port operations that perform the data transfer and associated synchronization. In (M. D. Edwards, 1993; Edwards and Forrest, 1994; Edwards and Forrest, 1995; Edwards and Forrest, 1996a; Edwards and Forrest, 1996b), after partitioning, the resulting hardware description of the critical region, selected for hardware implementation, includes the specification for parameter and control passing. Hence, during hardware synthesis, the hardware function is synthesized together with the data transfer and synchronization controls.

System Integration

23

In POLIS (F. Balarin, 1997), interface between different implementation domains (hardware and software) is automatically synthesized. These interfaces come in the form of cooperating circuits and software procedures (I/O drivers) embedded in the synthesized implementation. Communication can be through I/O ports available on the microcontroller or general memorymapped I/O.

2.7

System Integration

Once the hardware synthesis and software compilation phases are complete, the next step is to integrate both hardware and software components. One possibility is to use a prototyping system consisting of general-purpose processor assisted by application-specific hardware (Ernst and Henkel, 1992; R. Ernst and Benner, 1993; Gupta, 1993; R. K. Gupta and Micheli, 1992a; R. K. Gupta and Micheli, 1992b; R. K. Gupta and Micheli, 1994; Gupta and Micheli, 1992; Gupta and Micheli, 1993). Another possibility is to use a reconfigurable system, for the hardware component, and a computer system, for the software component. It is also possible to use a framework, such as PTOLEMY (Kalavade and Lee, 1992; Kalavade and Lee, 1993), in order to implement co-simulation and verify the performance of the co-design system. In each of these approaches, the performance results obtained during the system integration phase may be used to change the system partitioning, if the initial constraints, such as speed, cost and logic size, are not satisfied. In PTOLEMY, the SDF domain supports simulation of algorithms and also allows functional modeling of components, such as filters. The Thor domain implements the Thor simulator, which is a functional simulator for digital hardware and supports the simulation of circuits from the gate level to the behavioral level. Thor, hence, provides PTOLEMY with the ability to simulate digital components ranging in complexity from simple logic gates to programmable DSP devices. The mixed-domain simulation is executed, using the components synthesized so far. POLIS (F. Balarin, 1997) uses PTOLEMY as a simulation engine. Another example of simulator is POSEIDON, used by (R. K. Gupta and Micheli, 1992a; R. K. Gupta and Micheli, 1992b; R. K. Gupta and Micheli, 1994) which performs concurrent execution of multiple functional models implemented either as a program or as application-specific hardware. Input to POSEIDON consists of gate-level descriptions of the ASIC hardware, assembly code of the software and a description of their interface. The system specification is written using model declarations, model interconnections, communication protocols and system outputs. The interface protocol for data-transfer between models is specified via guarded commands. The gate-level description

24

The Co-design Methodology

Figure 2.4. Target architecture with parameter memory in the coprocessor

of the hardware component is generated using structural synthesis techniques provided by the OLYMPUS synthesis system (G. De Micheli and Truong, 1990). The first version of the development board presented in (M. D. Edwards, 1993; Edwards and Forrest, 1994; Edwards and Forrest, 1995; Edwards and Forrest, 1996a; Edwards and Forrest, 1996b) comprised of a processor, system memory, input/output section, custom hardware and AT bus interface. The custom hardware consisted of a parameter memory, a dual-port controller and the coprocessor, which implemented the synthesized hardware function, as shown in Figure 2.4. The dual-port controller was responsible for the communication between the coprocessor internal bus and the system bus, during parameter passing. Parameters were transferred between the coprocessor parameter memory and the system memory as either 16-bit integers, pointers or data arrays, using Direct Memory Access (DMA). In the present version (Edwards and Forrest, 1995; Edwards and Forrest, 1996a), described in Chapter 3 with more details, parameters are transferred directly to the coprocessor as either 16-bit integers or pointers, as can be seen

System Integration

25

Figure 2.5. Target architecture with memory-mapped parameter registers

from Figure 2.5. Data arrays are kept in the system memory and only their pointers are passed to the coprocessor. The coprocessor bus interface contains memory-mapped registers for configuring and controlling operation of the coprocessor. Another example of a development board is the HARP reconfigurable computer (Hoare and Page, 1994a; Hoare and Page, 1994b; de M. Mourelle, 1998; Page, 1994; Page, 1995; Page and Luk, 1993), a computing platform developed at Oxford university. It consists of a 32-bit RISC microprocessor, with 4MB DRAM, closely coupled with a Xilinx FPGA processing system with its own local memory. The microprocessor can download the hardware configuration into the FPGA via the shared bus. The target architecture used in (Ernst and Henkel, 1992; R. Ernst and Benner, 1993; Gupta, 1993; R. K. Gupta and Micheli, 1992a; R. K. Gupta and Micheli, 1992b; R. K. Gupta and Micheli, 1994; Gupta and Micheli, 1992; Gupta and Micheli, 1993) consists of a general-purpose processor assisted by applicationspecific hardware components (ASICs), as shown in Figure 2.6. The hardware modules are connected to the system address and data busses. Thus, all communication between the processor and the other hardware modules takes place over a shared medium. The re-programmable component is always the bus master. Inclusion of such functionality in the application-specific component would greatly increase the total hardware cost. All the communication between the re-programmable component and the ASIC components is achieved over named channels, whose width is the same as the corresponding port widths used by read and write instructions in the software component. The re-programmable component contains a sufficient number of maskable interrupt input signals. These interrupts are un-vectored and there exists a predefined unique destination address associated with each interrupt signal.

26

The Co-design Methodology

Figure 2.6. Target architecture using a general-purpose processor and ASICs

Computer designers can connect the gates of FPGAs into an arbitrary system merely by loading the chip’s internal RAM with configuration data. By combining FPGAs with external RAMs, microprocessors and digital signal processors, designers can create a Reconfigurable System (RS). Plugged into a standard PC, the reconfigurable system would perform functions normally performed by special-purpose cards. Such an arrangement has the following advantages: faster execution – since FPGAs operate at circuit speeds, they can compute much faster than pure software functions; however, their wiring and logic delays make them slower than equivalent mask-programmed gate array s or ASICs; low cost – an RS is much cheaper for each new application than an ASIC; configuring an RS for a new task requires that the PC user reprograms the connections of the logic gates in each FPGA; low power, small volume – one RS can take over the non-concurrent functions of several dedicated, special-purpose cards, reducing the size and power consumption of the PC system; increased innovation – because reconfiguring an RS is similar to loading a new software program, the costs of creating a new system will be much lower. These reconfigurable systems can be used as testbeds for co-design, providing a board for implementing the hardware component, along with the means for communicating with the software component. Examples of testbed

Summary

27

implementations are SPLASH (M. Gokhale, 1991), ANYBOARD (D. E. Van den Bout, 1992), Rasa Board (D. E. Thomas and Schmit, 1993) and the multiple-FPGA-based board presented in (Wendling and Rosenstiel, 1994).

2.8

Summary

In this chapter, we introduced the co-design approach. Then, the co-design methodology was outlined by describing each of the steps involved, together with recent work in this area. In the next chapter, we will discuss the co-design system developed at UMIST, along with experimental results obtained.

28

Notes 1 Application Specific Integrated Circuits. 2 SDF stands for Synchronous Data Flow. 3 CPLD stands for Complex PLDs.

The Co-design Methodology

Chapter 3 THE CO-DESIGN SYSTEM

The purpose of hardware/software co-design is to engineer systems containing an optimum balance of hardware and software components, which work together to achieve a specified behavior and fulfill various design criteria, including meeting performance targets (Wolf, 1994). A general-purpose co-design methodology should allow the designer to progress from an abstract specification of a system to an implementation of the hardware and software sub-systems, whilst exploring tradeoffs between hardware and software in order to meet the design constraints. A co-design environment provides software tool support for some, or all, of the co-design operations and may include an integrated development system consisting of a microcomputer or microcontroller and programmable hardware for system prototyping purposes. The co-design in this book concentrates on the realization of hardware/ software systems where the primary objective is to enhance the performance of critical regions of a software application, characterized as a software approach (Edwards and Forrest, 1994; Edwards and Forrest, 1995; Edwards and Forrest, 1996b). In our case, a critical region is part of an application where either a software solution cannot meet the required performance constraints, and a hardware solution must be found, or the overall performance can be usefully accelerated by implementing that region in hardware. In order to produce viable hardware/software systems, we have created a development environment, which supports the co-synthesis and performance evaluation of such systems. An application is firstly implemented as a C program and identified critical regions are synthesized automatically for implementation in a field programmable gate array (FPGA).

29

30

3.1

The Co-design System

Development Route

The development route consists of a sequence of stages for the translation of a C source program into machine code for a microcontroller and FPGA configuration data, as shown in Figure 3.1, following the co-design methodology presented in Section 2.4. Profiling consists of identifying performance critical regions in the C source program. The Amdahl’s law (Amdahl, 1967) can be employed to determine the performance gain that can be obtained by implementing these critical regions in hardware. It states that “the performance improvement to be gained from using some faster mode of execution is limited by the fraction of the time the faster mode can be used” (Amdahl, 1967). The speedup that can be gained corresponds to the ratio in (3.1).

speedup =

execution time of software-only implementation execution time of software/hardware implementation

(3.1)

As presented in (Edwards and Forrest, 1996b), the overall speedup of an application Shs can be defined as in (3.2)

Shs =

Ssc 1 + µ(Scs − 1)

(3.2)

wherein Scs corresponds to the speedup obtained by executing the critical region in hardware and µ to the fraction of the computation time in the software implementation that is not enhanced by the hardware implementation. As Scs tends to infinity, the overall speedup Shs obtainable becomes inversely proportional to µ. Therefore, the overall speedup increases as the frequency of use of the software implementation that is enhanced by the hardware implementation increases. This provides a good design trade-off in selecting potential critical regions for hardware implementation. Hardware/software partitioning consists of translating performance critical regions in the C source program into a hardware description for input to a hardware synthesis system. The identified C source code for a region is adapted to implement a “hardware” call/return mechanism, which invokes the associated

31

Development Route

Figure 3.1. Development route

operations in the FPGA. The modified C source program is, then, prepared for compilation. During hardware synthesis, the hardware description of a critical region is synthesized, through a series of synthesis tools, into a netlist for the specific FPGA. The configuration data is, then, translated into an initialized C array. Software compilation stage accepts the modified C source program and translates it into machine code to be executed by the co-design system. The run-time system consists of the necessary hardware to download the modified C code into the development hardware, execute it and return performance statistics.

3.1.1

Hardware/Software Profiling

Hardware/software profiling permits the identification of performance critical regions in the C source program. Deterministic, accurate timing analysis has been used to estimate program execution time against bounds in real time systems (Park and Shaw, 1991; Shaw, 1989). Knowledge about the dynamic behavior of the programs have also been used to estimate their performance (J. Gong and Narayan, 1993; Narayan and Gajski, 1992).

32

The Co-design System

In a first approach (Edwards and Forrest, 1994; Edwards and Forrest, 1995; Edwards and Forrest, 1996a; Edwards and Forrest, 1996b), the profiling software is PC-based and critical regions are identified interactively and can be either single functions or sequences of statements within a function. Performance statistics for a program and selected regions can be readily obtained by compiling and executing the code. Critical regions are identified by running the program with representative data. The performance information is acquired by the run-time system using timers of the development system hardware. The current values of a timer are read when the profiled region is both entered and exited. The profiling system temporarily modifies the original code, so that “time stamps” can be used to indicate entry and exit times from the regions selected by the user. The time stamps are generated by the hardware timers of the system hardware. Figures of the minimum, maximum and average execution times for a selected region, together with the number of times the region is executed, are computed and stored in the system memory of the development hardware. From this information, it is possible to ascertain where a program spends most of its time and, hence, which regions could benefit from software acceleration. At this stage, we naively assume that the execution time of a program is determined and does not depend on any asynchronous activities. We are, however, experimenting with a “statistical” form of profiling, where the value of the program counter of the microprocessor is sampled at random intervals. This allows us to determine the dynamic execution characteristics of a program and is useful for profiling interrupt-driven applications. In another approach (Nikkhah, 1997; B. Nikkhah and Forrest, 1996), the selection of candidate functions is performed automatically, based on profiling data. Functions are the unit of translation, but designers can readily rewrite other regions as functions. A hybrid static/dynamic policy for timing assessment is adopted, where the duration of each “basic block” in a program is estimated statistically for a particular processor. Program regions are compared by their relative timing characteristics. The program is run in a workstation environment and the estimated times of the executed basic blocks are summed up to give an estimated time for the program on the target environment. In a C program, basic blocks are identified by noting the occurrences of “for”, “while”, “do”, “if” and switch constructs. Constructs such as “break”, “continue” and “return” may denote the end of these blocks. The basic block execution time is estimated using the source code on an instruction-by-instruction basis. The estimation is independent of the processor on which the source program is executed. The processor dependent timing data, extracted from the manuals in clock cycles,

Development Route

33

is held for each basic operation of a C instruction. profiling and software timing estimation is done without executing the source program on the target architecture. In (Nikkhah, 1997; B. Nikkhah and Forrest, 1996), after the selection of candidate functions based on the software timing estimation, the area size estimation is performed. This allows the designer to eliminate those candidates that do not satisfy the area constraint.

3.1.2

Hardware/Software Partitioning

Partitioning (Edwards and Forrest, 1994; Edwards and Forrest, 1995; Edwards and Forrest, 1996a; Edwards and Forrest, 1996b) consists of translating the C code of a critical region into VHDL, in order to enable highlevel hardware synthesis of the identified region. The C source code of the critical region is adapted to implement the parameter passing and a “hardware” call/return mechanism, which invokes the associated operations in the FPGA. The implemented protocol consists of: parameter passing from the processor to the hardware sub-system; instigating the function in the FPGA; waiting until the hardware sub-system completes the operation, which depends on the interface mechanism adopted; accessing parameters returned by the hardware sub-system. The partitioning tool (Wright, 1997) generates a VHDL behavioral description of the critical region, as well as the adapted C source program. Specialpurpose hardware/software interface logic is generated automatically to implement the transfer of parameters and control between the two sub-systems, which is embedded in the VHDL description. An example of the application of this tool is provided in Appendix A.

3.1.3

Hardware Synthesis

The hardware synthesis tool is UNIX-based. It accepts the VHDL code for a critical region, generated by the partitioning tool, and produces the logic network for a Xilinx FPGA XC40xx . During this phase, different tools are used according to the type of output required, as described in Figure 3.2. Optimization. The VHDL behavioral description of a critical region may follow a structured programming style, i.e., include procedures and functions. This may yield a very large synthesis space. In order to be able to handle such a large space, high-level synthesis tools impose some constraints on the type of hardware description that can be handled, i.e., the synthesis tool may not support record types, some kind of “loop” statements (“loop . . . end loop”),

34

The Co-design System

Figure 3.2. Hardware synthesis process

some kind of “wait” statements (“wait for time expression”), “next” statements, “exit” statement, some kind of signal mode declarations (inout, buffer). The optimization is presently done by VOTAN (Siemens, 1994) (high-level VHDL Optimization, Transformation and Analysis), which is an easily extendible system of tools, that was designed to allow the use of high-level synthesis techniques with an established VHDL design flow. The two main aims of VOTAN are to pre-compile descriptions written for a dedicated RT-synthesis tool and raise the abstraction level of descriptions that can be synthesized. This tool fully enables a structured programming style by allowing procedures (with “wait” statements), functions and arbitrary nested loops and branches. Therefore, hierarchical descriptions that are easier to write and maintain, can

Development Route

35

be transformed into VHDL code, that is synthesizable by commercial RT-level synthesis tools. VOTAN offers a flexible scheduling technique intended to optimize the control flow in a selected VHDL process. In our case, the VHDL behavioral description of a critical region is presented as one process consisting of nested loops, controlled by “wait” statements, and several procedures. VOTAN accepts this input and produces a finite state machine, eliminating the nested loops and the procedure calls. Synthesis. The next step in the hardware synthesis process is to synthesize the optimized version of the VHDL description of a critical region, generated by VOTAN. We use ASYL+/PLS (Technologies, 1995) to obtain a netlist description for a Xilinx FPGA XC40xx . This tool does not support any “wait” statements, multiple “wait” descriptions, “loop” statements, “next” statements, “exit” statements. These restrictions are avoided by transforming the original VHDL description using VOTAN. Amapper transforms a technology-independent description into a technologydependent network of cells for the target technology. The initial specification may be a textual language description, such as VHDL, or a schematic or virtual library netlist, such as Electronic Design Interchange Format (EDIF) (Association, 1989). The mappers are technology specific, since they utilize the unique architectural features of the target technology. A netlist optimizer starts from a mapped netlist and optimizes the netlist to improve the performance of the circuit. In this case, the source and the target technology are identical, which allows the identification and optimization of critical paths according to special constraints. For instance, the most common option minimizes the longest path between two flip-flops or latches throughout the design, thus maximizing the clock frequency. ASYL+ performs a specific mapping on Xilinx 3000, 4000 and 5200 families of FPGAs. For FPGAs, the output is either a single or set of XNF1 files ready for processing by the Xilinx place and route tools. The netlist optimizer is available only for the X4000 series. Partitioning, placement and routing. Once the Xilinx netlist (XNF) is obtained from the synthesis tool, the next step consists of partitioning the design into logic blocks, then finding a near-optimal placement for each block and finally selecting the interconnect routing. These tasks are performed by the Xilinx development system XACT (Xilinx, 1993), which generates a Logic Cell Array (LCA2 ) file, from which a bit stream file can be generated. Linking. The necessary serial bit stream description, to configure the Xilinx FPGA, is obtained from the LCA file generated by the previous partitioning, placement and routing phase. This task is performed by the FROMLCA script,

36

The Co-design System

which generates an initialized C array (ximage.c) to be linked to the adapted C source program during software compilation process. The configuration itself is part of the program execution and so is performed by the software sub-system, once the adapted C code is loaded into the co-design system.

3.1.4

Software Compilation

The software compiler takes the adapted C source program, with the inserted “hardware” call/return and the parameter passing mechanism, and produces the processor machine code. During this phase, the configuration data, in the form of an initialized C array generated during the last phase of the hardware synthesis process, is linked with the adapted C code. The compilation phase generates an object code in the Motorola S-records format (src) to be loaded into the target processor memory.

3.1.5

Run-Time System

The run-time system (Edwards and Forrest, 1996a) executes the adapted C code and consists of the processor and coprocessor boards, shown in Figure 3.3. The processor board comprises a microcontroller MC68332 (MOTOROLA, 1990b), 2MB DRAM, 64KB SRAM and 2 FLEXlogic FPGAs iFX780 (Intel, 1994), which implement the necessary glue logic. The coprocessor board comprises a Xilinx FPGA X4010 (Xilinx, 1992), which implements the hardware function, and a FLEXlogic FPGA iFX780, which implements the bus interface. The adapted C code, together with the initialized C array containing the Xilinx configuration data, is downloaded into the run-time system memory via the Background Debug Mode (BDM3 ) port. The JTAG4 (Intel, 1993; Intel, 1994) port is used to configure the FLEXlogic FPGAs iFX780. The serial peripheral interface (SPI), time processing unit (TPU) and serial ports support low-level input-output facilities (MOTOROLA, 1990b). The development process, corresponding to the profiling, partitioning, software compilation and hardware synthesis, is UNIX-based. On the other hand, the FLEXlogic FPGAs iFX780 have to be configured as well. A system interface (A. Ali, 1995) was built to link the run-time system to the development host, as shown in Figure 3.4. There is a single RS232 serial connection, using a packet based protocol. Under the control of the workstation, the interface can configure the system FLEXlogic devices and operate the BDM port on the coprocessor board. The serial port from the processor, which is principally used to provide program diagnostics during execution, is routed to the workstation via the interface system.

37

Target Architecture

Figure 3.3. Run-time system

3.2

Target Architecture

The target architecture (Edwards and Forrest, 1995) for our co-design system has the configuration shown in Figure 3.5. The microcontroller, global memory and controllers are located in the processor board also called the software subsystem, since it is responsible for the execution of the adapted C code. The bus interface and coprocessor are located in the coprocessor board, also called the hardware sub-system, since it is responsible for the execution of the critical region (hardware function). Both sub-systems communicate through the main system bus. This type of shared bus architecture is commonly used in co-design systems (R. Ernst and Benner, 1993; D. E. Thomas and Schmit, 1993; N. S. Woo and Wolf, 1994). Integer and pointer parameters are passed to and from the coprocessor via memory-mapped registers, while data arrays are stored in the shared memory.

38

The Co-design System

Figure 3.4. Run-time system and interfaces

3.2.1

Microcontroller

The MOTOROLA MC68332 (MOTOROLA, 1990a; MOTOROLA, 1990b) consists of a 32-bit microcontroller unit (MCU), combining high-performance data manipulation capabilities with powerful peripheral sub-systems. It contains intelligent peripheral modules such as the time processor unit (TPU), which provides 16 micro-coded channels for performing time-related activities. Highspeed serial communications are provided by the queued serial module (QSM) with synchronous and asynchronous protocols available. The modules are connected on-chip via the inter-module bus (IMB). The system clock is generated by an on-chip circuit to run the device up to 16.78MHz, from a 32.768KHz crystal. The MCU architecture supports byte, word and long-word (32-bit) operands, allowing access to 8-bit and 16-bit data ports through the use of asynchronous

39

Target Architecture

Figure 3.5. Target architecture

cycles controlled by the data transfer (size
1 : 0) and the data size acknowledge (dsak
1 : 0) signals. The MCU requires word and long-word operands to be located in memory on word or long-word boundaries. The only type of transfer that can be misaligned is a single-byte transfer to an odd address. For an 8-bit port, multiple bus cycles may be required for an operand transfer due to either misalignment or a port width smaller than the operand size. The MCU contains an address bus (a
23 : 0), that specifies the address for the transfer, and a data bus (d
15 : 0), that transfers the data. Control signals indicate the beginning of the cycle, address space, size of the transfer and the type of the cycle. The selected device then controls the length of the cycle with the signals used to terminate the cycle. Strobe signals, one for the address bus (as) and another for the data bus (ds), indicate the validity of the address and provide timing information for the data. The bus and control input signals are internally synchronized to the MCU clock, introducing a delay, i.e., the MCU reads an input signal only on the falling edge of the clock and not as soon as the input signal is asserted. The function codes (f c
2 : 0) select user or supervisor, program or data spaces. The area selected by f c
2 : 0 = 111, for example, is classified as the CPU space, which allows the CPU to acquire specific control information not normally associated with real or write bus cycles, such as during an interrupt acknowledge cycle. There are seven prioritized interrupt request lines available (irk
7 : 1), where irk(7) is the highest priority. The irk
6 : 1 are internally maskable interrupts and irk(7) is non-maskable. When a peripheral device signals the MCU that the device requires service and the internally synchronized value on these signals indicates a higher priority than the interrupt mask in the status register (or that a transition has occurred in the case of a level 7 interrupt), the

40

The Co-design System

MCU makes the interrupt a pending interrupt. It takes an interrupt exception for a pending interrupt within one instruction boundary (after processing any other pending exception with a higher priority). When the MCU processes an interrupt exception, it performs an interrupt acknowledge cycle to obtain the number of the vector that contains the starting location of the interrupt service routine. Some interrupting devices have programmable vector registers that contain the interrupt vectors for the routines they call. Other interrupting conditions or devices cannot supply a vector number and use the auto-vector cycle, in which the supplied vector number is derived from the interrupt level of the current interrupt. The bus design of the MCU provides for a single bus master at a time: either the MCU or an external device. One or more of the external devices on the bus has the capability to become the bus master. Bus arbitration is the protocol by which an external device becomes the master. The bus controller in the MCU manages the bus arbitration signals so that the MCU has the lowest priority. Systems including several devices that can become bus master require external circuitry to assign priorities to the devices, so that, when two or more external devices attempt to become the bus master at the same time, the one having the highest priority becomes bus master first. The sequence of the protocol steps is: an external device asserts the bus request signal (br); the MCU asserts the bus grant signal to indicate that the bus is available (bg); the external device asserts the bus grant acknowledge signal to indicate that it has assumed bus mastership (bgack).

3.2.2

Global Memory

The global memory consists of 64KB SRAM and 2MB DRAM, the latter being directly accessible by both the microcontroller and the coprocessor. The DRAM is implemented by two 1M×8 bits DRAMs, allowing for byte and word access. The DRAM 10 address lines on the module are time multiplexed at the beginning of a memory cycle by two clocks: row address strobe (ras) and column address strobe (cas), into two separate 10-bit address fields. A cas active transition is followed by a ras active transition for all read or write cycles. The normal read cycle begins with both ras and cas active transitions latching the desired byte location. The write input (w) must be high before the cas active transition, in order to enable the read mode. The ras and cas clocks must remain active for a minimum time to complete the read cycle. Data out is valid as long

Target Architecture

41

as the cas clock is active. When the cas clock becomes inactive, the output will switch to high impedance. The write mode is enabled by the transition of w to low, before cas active transition. The data input is referenced to cas. The ras and cas clocks must stay active for some time after the start of the write operation in order to complete the cycle. Page mode allows for fast successive data operations at all column locations on a selected row. A page mode cycle is initiated by a normal read or write. Once the timing requirements for the first cycle are met, cas becomes inactive, while ras remains low. The second cas active transition, while ras is low, initiates the first page mode cycle. The dynamic RAM design is based on capacitor charge storage for each bit in the array. Thus each bit must be periodically refreshed to maintain the correct bit state. The refresh is accomplished by cycling through the 512 row addresses in sequence within the specified refresh time. All the bits on a row are refreshed simultaneously when the row is addressed. A normal read or write operation to the RAM will refresh all the bytes associated with the particular decoded row. One method for DRAM refresh is by asserting cas active before ras, which activates an internal refresh counter that generates the row address to be refreshed. External address lines are ignored during the automatic refresh cycle.

3.2.3

Controllers

The controllers consist of 2 FLEXlogic FPGAs iFX780, as shown in Figure 3.5. They implement the necessary “glue” functions for bus arbitration, bus monitoring, address multiplexing, DRAM accessing and refresh control. Bus arbitration is required in order to determine the bus master. Each coprocessor (notice that two coprocessor ports are available) is provided with a bus request signal. The bus arbitration control accepts these signals, plus the refresh request generated by the TPU, and asserts the bus request signal (br = 0) to the microcontroller. It, then, waits until the bus is granted (bg = 0) by the microcontroller. Subsequently, the requesting device is selected, according to the priority scheme adopted. The controller signals to the selected device that the bus is granted and asserts the bus grant acknowledge (bgack) to the microcontroller. The bus monitor control signals bus error (berr) to the MCU when no device responds by asserting dsack
1:0 or within an appropriate period of time after the MCU asserts signal as. This allows the cycle to terminate and the MCU to enter the exception processing mode for the processing of error conditions. DRAM control is used to signal ras and cas in the appropriate sequence, according to the desired operation. Notice that the DRAM consists of a pair of 1M×8 bits. During a byte operation, if the address is “even” the higherorder byte of the data bus is used, otherwise, the lower-order byte of the data

42

The Co-design System

bus is used instead. This means that each 1M×8 bits DRAM must be selected individually, which is achieved by controlling their cas signals separately. Since we are using a 16-bit port, the DRAM control asserts dsack(1) when the transfer is complete, while keeping dsack(0) negated. It also detects a refresh request and signals the necessary control signals to implement cas before ras refresh operation. The second controller is responsible for the address multiplexing operation. First, the row address is sent. As soon as the DRAM control indicates that the row address was latched, the address multiplexer sends the column address to the same 10-bit address output lines of the DRAM. During a long-word operation, this controller prepares the address of the next location. It also signals to the DRAM control if the present address is in the same page as the previous one, thus allowing for page mode operation.

3.2.4

Bus Interface

The purpose of this interface is to allow data parameters and control to be passed correctly between the two sub-systems. In our case, a C program is executed in the software except for a performance critical region, which is executed in the hardware sub-system. Assuming a single thread of control and the C program is being executed on a conventional processor, the sequence of events taken in executing the critical region in the hardware sub-system is as follows: parameters are passed from the software to the hardware sub-system; the thread of control is passed from the processor executing the C program to the hardware sub-system; the hardware sub-system executes the specified function; the thread of control is passed back to the processor from the hardware sub-system; the function results, if applicable, are read back by the software sub-system. Recall that the critical region, in the original program, has been replaced by a “hardware” call/return mechanism (see Section 3.1.2). There are two commonly used implementations of this mechanism: busy-wait and interrupt. In the busy-wait mechanism, the processor will start the hardware execution of the function and loop, reading a status flag, which indicates when the function has been completed. In the interrupt mechanism, the processor will again start the hardware-based function, but this time it will wait for an interrupt, which indicates completion of the function. The choice of interface mechanism can have a significant effect on the performance speedups obtained and is the subject of detailed analysis in next chapters.

43

Target Architecture

Figure 3.6. Bus interface control register

The bus interface has an 8-bit memory-mapped control register, shown in Figure 3.6, through which the processor directs the operation of the coprocessor. Signals Nprogram, rdy, done and Ninit are related to the Xilinx FPGA configuration (Xilinx, 1993). Signals copro-st, copro-dn and iack-di are related to the Xilinx FPGA operation, when executing the hardware function: copro-st: starts the hardware-based function execution; copro-dn: indicates that the hardware-based function has finished; iack-di: during interrupt, corresponds to the interrupt acknowledge; during busy-wait, disables interrupts from the coprocessor. Busy-wait. the microcontroller implements the following protocol, expressed in C: start (); {set copro-st = 1} while (!is_finished ()) {loop until copro_dn = 1} ack_stop (); {set copro-st = 0} This is a straightforward implementation of the busy-wait protocol. It is assumed that the parameters are transferred before the hardware function is started and the results after it has finished. Interrupt. the coprocessor uses interrupt line level 3 (irq3) from the microcontroller (see Section 3.2.1) to generate an interrupt once the hardware function has been executed. Automatic vectoring is used, whereby the microcontroller generates the appropriate interrupt vector internally. In the current set up, the microcontroller stops after starting the coprocessor and will resume operation only after an interrupt. Note that other interrupts can also be present in the

44

The Co-design System

system and any of these can restart the processor. The coprocessor completion is identified in the same way as it was for the busy-wait mechanism. Nevertheless the control register is read only after an interrupt, thus significantly reducing bus contention. In order to withdraw the interrupt request, the coprocessor needs an interrupt acknowledge signal. The MCU does not provide interrupt acknowledge lines. Since a hardware solution for the interrupt acknowledge signal could not be implemented in our current system, due to an area constraint, a software solution was adopted using the iack-di flag in the control register. The interrupt service routine sets this flag, which causes the coprocessor to unassert the interrupt request. This generates a small performance overhead when using interrupts. The microcontroller now implements the following protocol, which includes resetting the iack di at the same time as unasserting copro st:

start (); {sets copro_st = 1} wait_for_int (); {stops the CPU} ack_stop (); {sets copro_st = 0 and iack_di = 0}

Parameter passing is achieved via memory-mapped registers located in the coprocessor. The bus interface identifies the beginning of the transfer and signals to the microcontroller when the coprocessor has finished, by asserting the data size acknowledge signal (dsack1 = 0), following the bus transfer protocol (see Section 3.2.1). Moreover, the bus interface controls the coprocessor memory accesses. Once a memory request is detected, it signals to the bus arbiter (see Section 3.2.3) requesting the bus. As soon as the bus is granted, the necessary signals for a bus transfer are driven (see Section 3.2.1). The interrupt controller is implemented by the bus interface too, which detects the end of the coprocessor operation and asserts the corresponding interrupt request signal. It, then, waits for the interrupt acknowledge signal, as part of the handshake protocol. Notice that the coprocessor has a direct access to the data and address buses for parameter passing only. All the necessary control for this operation to take place and for the coprocessor memory accesses are generated by the bus interface itself.

Performance Results

3.2.5

45

The Coprocessor

Basically, the coprocessor consists of a Xilinx FPGA XC4010, implementing the critical region of the C source program. The coprocessor runs at half the speed of the microcontroller, due to the Xilinx internal delays. We can divide the FPGA into three components, interconnected by internal signals: the clock divider, data buffers and accelerator. These components were merged into a single configuration file (.lca) by the Xilinx tool XACT, during the partitioning, placement and routing stage of the hardware synthesis (see Section 3.1.3). The data buffers permit the interface between the 16-bit main system bus and the coprocessor 32-bit internal data bus. The bus interface provides the necessary control signals to select the appropriate part of the data buffers, according to the size of the data transfer (8-bit, 16-bit or 32-bit), and to control the data flow, according to the type of the operation. Due to the FPGA internal delays, it might be impossible to run an application at the same speed as the microcontroller (16.78MHz). In this case, the coprocessor will require its own clock. The clock divider provides the coprocessor internal clock, based on the main system clock. It is possible to generate a clock frequency of 8.39MHz or 4.19MHz. The accelerator implements the hardware function, selected during the partitioning stage (see Section 3.1.2), whose configuration is obtained during hardware synthesis (see Section 3.1.3). It contains the memory-mapped registers for parameter passing and the body of the hardware function to be executed.

3.2.6

The Timer

The timer is implemented by an INTEL FLEXlogic FPGA iFX780, located in the second coprocessor board (coprocessor port 2). It consists of a memorymapped counter, controlled by the software through a memory-mapped control register. When a specific part of the code needs to be timed, the counter is started just before entering the code. At the end of the timed region, the counter is then halted and read. The examples provided in the next section are timed by this external timer and its use in the source code can be seen in Appendix A.

3.3

Performance Results

The execution times of two programs PLUM and EGCHECK were measured using the busy-wait and interrupt mechanisms (L. de M. Mourelle and Forrest, 1996). This was done in order to determine if any noticeable differences in their performances could be detected. In order to provide an application environment of realistic embedded systems, a periodic interrupt timer (PIT) was implemented to generate “timing” interrupts at different rates (the internal timer for the MC68332 was used for this purpose). A special-purpose external counter, residing on the system bus,

46

The Co-design System

was used to provide execution time information for the two programs. The counter is based on the 16.78MHz microcontroller clock. The basic system timing parameters for both programs are given below: shared memory access time from the microcontroller: 300ns (5 clock cycles); control register access time from the microcontroller: 240ns (4 clock cycles); shared memory access time from the coprocessor: 1200ns (20 clock cycles); interrupt acknowledge cycle: 10020ns (167 clock cycles).

3.3.1

First Benchmark: PLUM Program

InAppendixA, we present the PLUM program and the corresponding adapted C program, generated by the synthesis tool Synth during partitioning. The function inner is synthesized in hardware, performing 800,000 shared memory accesses. With the PIT turned off, the time to execute the program in software is 6836ms. When executing the called function in the coprocessor, the execution time for the program reduces to 2234ms, when using the busy-wait mechanism, and 2319ms, when using the interrupt mechanism. This gives speedups of 3.1 and 2.9, respectively. Intuitively, this program has more coprocessor internal operations than memory accesses and it, therefore, seems more natural to use the busy-wait mechanism. In this case, there is little bus contention due to the non-frequent memory accesses (one memory access every 3µs). The system performance degrades when the PIT is turned on, as shown in Table 3.1. The times provided are in milliseconds (ms). The first column gives the period of the interrupt timer and the second the execution time of the pure software version of the program. The software overhead, in the third column, is the increase in the execution time caused by the interrupt timer, since the MCU has now to execute the corresponding interrupt routine too. The subsequent columns are related to the hardware/software implementation of the program. The fourth column provides the execution time when using the busy-wait mechanism. The column Error/bw indicates the error introduced into the program execution time by the busy-wait mechanism, which decreases as the time spent by the MCU in executing the interrupt routine decreases. The column Speedup/bw shows the speedup obtained for the same mechanism. The highest speedup obtained is when the MCU is heavily busy with the interrupt timer. This indicates that the move of some functionality to hardware helped reducing the overall execution time. Similarly, the last three columns provide the results obtained using the interrupt mechanism.

47

Performance Results Table 3.1. Performance results for PLUM PIT

Tsw

0.122 10901 0.244 8402 0.488 7539 0.977 7170 1.95 6999 3.91 6916 7.81 6876 15.62 6856 31.13 6846 ∞ 6836

overhead(%)

Ths bw

Err (%) bw

Speedup bw

Ths /int

Err (%) int

Speedup int

59.5 22.9 10.3 4.9 2.4 1.2 0.6 0.3 0.1 0.0

2441 2441 2441 2278 2250 2242 2235 2235 2236 2234

9.3 9.3 9.3 2.0 0.7 0.4 0.0 0.0 0.0 0.0

4.5 3.4 3.1 3.2 3.1 3.1 3.1 3.1 3.1 3.1

2848 2441 2441 2417 2345 2332 2374 2454 2323 2319

22.8 5.3 5.3 4.2 1.1 0.6 2.4 5.8 0.0 0.0

3.8 3.4 3.1 3.0 3.0 3.0 2.9 2.8 2.9 2.9

We can draw some conclusions now. As the frequency of the interrupts generated by the PIT increases, so does the amount of code executed by the MCU, corresponding to the interrupt routine. This leads to an increase in the bus contention. But, since PLUM has non-frequent memory accesses, bus contention is non-frequent as well. The slow interface between the coprocessor and the shared memory does not affect the execution time as much as the interrupt acknowledge cycle does, during the handshake completion, when the coprocessor finishes executing the function. The error introduced with the busywait mechanism is smaller than that introduced with the interrupt mechanism, due more to the handshake completion than to the memory accesses performed during the function execution.

3.3.2

Second Benchmark: EGCHECK Program

The EGCHECK program is presented in Appendix A, together with the corresponding adapted C program. The decode function, implemented in hardware, performs 6.4 million shared memory accesses. With the PIT turned off, the execution time of the program in software is 10917ms. When executing decode in the coprocessor, the execution time for the program reduces to 6193ms, when using the busy-wait mechanism, and 5518ms, when using the interrupt mechanism. This gives speedups of 1.8 and 2.0, respectively. Intuitively, the EGCHECK program has more shared memory accesses than coprocessor internal operations. Therefore, it seems more natural to use the interrupt mechanism. In this case, there is significant bus contention, due to the frequent memory accesses (more than one memory access every 1µs). The system performance degrades when the PIT is turned on, as shown in Table 3.2. Again, these results indicate that the interrupt timer has little effect, when its interrupt period is greater than 1ms. Faster interrupts indicate

48

The Co-design System

Table 3.2. Performance results for EGCHECK PIT

Tsw

overhead(%)

Ths bw

Err (%) bw

Speedup bw

Ths /int

Err (%) int

Speedup int

0.122 0.244 0.488 0.977 1.95 3.91 7.81 15.62 31.13 ∞

17385 13411 12037 11450 11177 11046 10981 10949 10933 10917

59.2 22.8 10.3 4.9 2.4 1.2 0.6 0.3 0.1 0.0

6300 6242 6217 6204 6199 6196 6194 6194 6193 6193

1.7 0.8 0.4 0.2 0.1 0.0 0.0 0.0 0.0 0.0

2.8 2.2 1.9 1.9 1.8 1.8 1.8 1.8 1.8 1.8

6303 5966 5733 5627 5571 5544 5531 5528 5521 5518

14.2 8.1 3.9 2.0 1.0 0.5 0.2 0.2 0.1 0.0

2.8 2.3 2.1 2.0 2.0 2.0 2.0 2.0 2.0 2.0

that the software overhead has become unacceptable. The columns in the table below are as those in Table 3.1. We can draw some conclusions here too. Since EGCHECK performs shared memory accesses frequently, as the frequency of interrupts generated by the PIT increases, so does the frequency of bus contention. Bus arbitration with the interrupt mechanism is faster than with the busy-wait mechanism. Therefore, the interrupt mechanism provides a better performance, according to the characteristics of this application in terms of number of memory accesses. On the other hand, the error introduced into the program execution time by the busy-wait is still smaller than that introduced by the interrupt. This indicates that, as the PIT increases, the corresponding increase in the code performed by the MCU interferes more in the execution times with interrupt than with busy-wait. This is because the handshake completion with interrupt introduces a considerable overhead due to the interrupt acknowledge cycle.

3.3.3

Results Analysis

Two different communication mechanisms were investigated: busy-wait and interrupt. In the first one, the microcontroller reads a memory-mapped control register continuously, leading to the problem of bus contention. In the second one, the microcontroller waits for an interrupt request of the coprocessor, indicating completion of operation, thus reducing bus contention, but introducing an additional time overhead corresponding to the interrupt acknowledge cycle. It was shown that the busy-wait mechanism is better than the interrupt mechanism when the coprocessor performs more internal operations than memory accesses. On the other hand, the interrupt mechanism is more suitable when there are more coprocessor memory accesses than internal operations.

49

Performance Results

Considering (3.2) in Section 3.1, we can introduce other factors that contribute for the performance of the system. The speedup obtained by executing the critical region in hardware is defined as in (3.3). Scs =

Tsw Thw

(3.3)

wherein Tsw is the software execution time of the critical region and Thw is its hardware execution time. The latter can be subdivided into five other components: Tpo , which is the time spent transfering the required parameters from the software to the hardware sub-system; Tco , which is the time spent transfering control from the software to the hardware sub-system; Tex , which is the execution time of the critical region in hardware sub-system; Tci , which is the time spent transfering control from the hardware sub-system to the software; Tpi , which is the time spent transfering the required parameters from the hardware sub-system to the software. The times Tpo and Tpi are related to the requirements of the critical region and the interface between the software and the hardware sub-systems. Tco and Tci are related to the handshake protocol and the interface between the two sub-systems. Time Tex can, in turn, be subdivided into two elements: Tiops , which is the time the hardware sub-system requires to execute the internal operations; Tios , which is the time the hardware sub-system requires to execute the input/output operations. The examples considered perform only memory accesses as input/output operations. From the results obtained, we can see that the time associated with the coprocessor memory accesses is a key factor in the performance of the co-design system. The characteristics of the hardware function (memory accesses) and those of the target architecture (bus interface, handshake protocol, bus arbitration) play a strong role in the performance of the co-design system. In order to determine the most suitable mechanism that will provide the best system performance, the number of coprocessor memory accesses and the memory access rate need to be analyzed. This is the subject of subsequent chapters.

50

3.4

The Co-design System

Summary

In this chapter, we have presented the co-design system developed at UMIST, including the adopted development route and the implemented target architecture. In the development route, we described the different stages a co-design implementation should pass through, from the system specification until its execution on the run-time system. This includes system profiling, partitioning, hardware synthesis and software compilation. The target architecture microcontroller is based on a shared bus configuration, using the MOTOROLA MC68332. Performance results were obtained for two benchmark programs, using the busy-wait and the interrupt interface mechanisms. One program performs more coprocessor internal operations than memory accesses, whilst the other performs more coprocessor memory accesses than internal operations. The performance results indicated that the speedup depends on the coprocessor memory accesses, together with the chosen interface mechanism. The remainder of this book will include a more systematically generated set of results, which will allow us to choose the most suitable interface mechanism for the application. In order to achieve this aim, we will proceed with our study using simulation method, which will allow us to examine the system in a variety of ways and in a much shorter time. In the next chapter, we present the VHDL model of the co-design system.

Summary

51

Notes 1 XNF stands for Xilinx Netlist Format. 2 LCA is a Xilinx trademark and a reference to the Xilinx FPGA architecture. 3 The BDM is an alternate CPU32 operating mode, during which normal instruction is suspended and special microcode performs debugging functions under external control. 4 JTAG/IEEE 1149.1 is an industry standard interface to support in-circuit reconfiguration and programming.

Chapter 4 VHDL MODEL OF THE CO-DESIGN SYSTEM

From the analysis undertaken in the previous chapter, we concluded that there is a relation between the number of coprocessor memory accesses and the interface mechanism, which determines the performance of the co-design system in terms of program execution times. The mechanism yields shorter execution times than the interrupt mechanism when the number of coprocessor memory accesses is small. On the other hand, as the number of coprocessor memory accesses increases, the interrupt mechanism becomes the better option, yielding shorter execution times compared to the busy-wait. Therefore, we decided to concentrate our attention on how to determine the best interface mechanism, based on the memory accesses of an application implemented by the coprocessor. This means analyzing the behavior of the execution times for different numbers and rates of memory accesses. From this point of view, we opted for a simulation procedure, instead of a physical experiment, because it allows us to analyze the system in a variety of ways and in a much shorter time. Besides this, through simulation we are able to inspect several levels of the design, which can help us in studying the behavior of the whole system and identifying potential bottlenecks. This chapter presents a simplified VHDL model of our physical co-design system, which was described and used in the previous chapter to implement our applications. Simulation results are presented and analyzed in the next chapter.

53

54

4.1

VHDL Model of the Co-design System

Modelling with VHDL

The VHSIC Hardware Description Language (VHDL) is an industry standard language used to describe hardware from the abstract to concrete level. In 1986, VHDL was proposed as an IEEE standard. It went through a number of revisions and changes until it was adopted as the IEEE 1076 standard, in December 1987 (IEEE, 1987). The use of Hardware Description Languages (HDL) in system design has a strong influence onto the design process and the used Computer Aided Design (CAD) tools. An HDL like VHDL enables the designer to describe a system at different levels of abstraction and to describe the different aspects of a design using a single, standardized language. Thus, the starting point of an automated design process has become closer to the level of reasoning of a system designer. The system can be described either in terms of states and actions triggered by external or internal events, sequential computations within a single process, communication between processes or structurally introduced existing hardware blocks. Extensive simulation of such a multi-level specification is used to validate, that the design does what is wanted. In the design process, we can identify three VHDL-based phases in use: system modeling (specification phase), register-transfer level (RTL) modeling (design phase) and netlist (implementation phase). Typically, the system model will be a VHDL model which represents the algorithm to be performed without any hardware implementation in mind. The purpose is to create a simulation model that can be used as a formal specification of the design and which can be run in a simulator to check its functionality. The system model is then transformed into a register-transfer level design in preparation for synthesis. The transformation is aimed at a particular hardware implementation but, at this stage, at a coarse-grain level. In particular, at this stage of the design process, the timing is specified at the clock cycle level. Also, the hardware resources to be used in the implementation are specified at the block level. The final stage of the design cycle is to synthesize the RTL design to produce a netlist, which should meet the area constraints and timing requirements of the implementation. We will model our co-design system using the RTL description, since we start from a physically implemented design. All the components are already defined as well as their interfaces. Therefore, the system model is not required at this level of the design.

Modelling with VHDL

4.1.1

55

Design Units and Libraries

Design units are the basic building blocks of VHDL (Perry, 1991; Rushton, 1995). A design unit is indivisible in that it must be completely contained in a single file (design file). A file may contain any number of design units. When a file is analyzed using a VHDL simulator or synthesizer, the file is, in effect, broken up into its individual design units and each design unit is analyzed separately as if it was provided in a separate file. The resulting analysis is another file (library unit), that is inserted into a design library. There are five kinds of design units in VHDL: entity, architecture, package and configuration. The design units are further classified as primary or secondary units. A primary design unit can exist on its own. A secondary design unit cannot exit without its corresponding primary unit. The entity is a primary design unit that defines the interface to a circuit. Its corresponding secondary unit is the architecture that defines the contents of the circuit. There can be many architectures associated with a particular entity. The package is also a primary design unit. A package declares types, subprograms, operations, components and other objects which can then be used in the description of a circuit. The package body is the corresponding secondary design unit that contains the implementations of subprograms and operations declared in this package. The configuration declaration is a primary design unit with no corresponding secondary. It is used to define the way in which a hierarchical design is to be built from a range of subcomponents. In a structural description, we declare components and create instances of components. The binding of each component to its corresponding entity is done through a configuration declaration. There are two special libraries which are implicitly available to all design units and, so, do not need to be named in a library clause. The first of these is called WORK and refers to the working design library into which the current design units will be placed by the analyzer. The second special library is called STD and contains the packages standard and textio (Rushton, 1995). The package standard contains all of the predefined types and functions and the package textio contains the built-in procedures for performing text I/O, providing enough functionality to read data files, for example.

4.1.2

Entities and Architectures

An entity defines the interface to a circuit and the name of the circuit. It specifies the number, the direction and the type of the ports. An architecture defines the contents of the circuit itself. Entities and architectures therefore exist in pairs. It is possible to have an entity without an architecture, but it is not possible to have an architecture without an entity. An example of an entity is given below for a reset-set flip-flop:

56

VHDL Model of the Co-design System

ENTITY rsff IS PORT (set, reset: IN q,qb: BUFFER END rsff;

bit; bit);

The circuit rsff has four ports: 2 input ports set and reset, and 2 output ports q and qb. Notice that the output ports are declared as BUFFER, instead of OUT, because in this case they need to be read as well as modified. A description for the corresponding architecture, using concurrent statements, is as follows: ARCHITECTURE behavior OF rsff IS BEGIN q -=> => => => => => => => => => => => => => =>

addr, data, siz, Ndsack, c1_ctrl

-- slot one control codes);

{using slot two} clk, -- main system clock Nreset, Nas, Nds, rNw, Nhalt, Nberr, Navec, fc, addr, data, siz, Ndsack, Nirq, c2_ctrl -- slot two control codes);

microcontroller PORT MAP( clk => clk, -- main system clock Nreset => Nreset, rNw => rNw, Nds => Nds, Nas => Nas, Nrmc => Nrmc, Navec => Navec, Nhalt => Nhalt, Nberr => Nberr, Ncsboot => Ncsboot, Nbr => Nbr, Nbg => Nbg, Nbgack => Nbgack, refresh => refresh, addr => addr, data => data, fc => fc, siz => siz, Nirq => Nirq, Ndsack => Ndsack); U5: main_ctrl PORT MAP( clk => clk, -- main system clock Nreset => Nreset, -- reset signal (not used) cpu_space => cpu_space, refresh => refresh, addr_inc => addr_inc,

195

196

Appendix B: Top-Level VHDL Model of the Co-design System Nbr Nbgack Nbg Nrmc Ncsboot same_page Nras Ncas0 Ncas1 uNl Nwr Noe rNw Nds Nas Nhalt Nberr fc siz Ndsack c1_ctrl c2_ctrl addr addr0

=> => => => => => => => => => => => => => => => => => => => => => => =>

Nbr, Nbgack, Nbg, Nrmc, Ncsboot, same_page, Nras, Ncas0, Ncas1, uNl, Nwr, Noe, rNw, Nds, Nas, Nhalt, Nberr, fc, siz, Ndsack, c1_ctrl, c2_ctrl, addr(23 DOWNTO 21), addr(0));

U8: addr_mux PORT MAP( clk Nreset uNl same_page addr_inc cpu_space addr addr_mux

=> => => => => => => =>

clk, Nreset, uNl, same_page, addr_inc, cpu_space, addr(22 DOWNTO 1), addr_mux);

U6: dram16 PORT MAP( rNw Nras data Ncas0 Ncas1 addr_mux END structure;

=> => => => => =>

rNw, Nras, -- combined ras1 ras2 sig data(15 DOWNTO 0), Ncas0, -- column address strobe 0 Ncas1, addr_mux); -- multiplexed bus

-- Main system components configuration details. CONFIGURATION main_system_config OF main_system IS FOR structure FOR U6: dram16 USE CONFIGURATION work.dram16_config;

Appendix B: Top-Level VHDL Model of the Co-design System END FOR; FOR U8: addr_mux USE ENTITY work.addr_mux(rtl); END FOR; FOR U5: main_ctrl USE ENTITY work.main_ctrl(behaviour); END FOR; FOR U1: microcontroller USE CONFIGURATION work.microcontroller_config; END FOR; FOR C2: copro_board --{slot two} USE CONFIGURATION work.copro_board_config; END FOR; FOR C1: timer --{slot one} USE ENTITY work.timer(behaviour); END FOR; END FOR; END main_system_config;

197

Appendix C Translating PALASMT M into VHDL

r 2 [48] into a VHDL description The translation of a circuit specification written in PALASM is quite straightforward. Combinatorial circuits are implemented in PALASM using Boolean equations. The output from the equation is a pin name or a node name. For example, we can have the following statement in PALASM: a = b ∗ c ∗ /d

(C.1)

a