VHDL: Programming By Example

VHDL: Programming by Example Douglas L. Perry Fourth Edition

McGraw-Hill New York • Chicago • San Francisco • Lisbon • London Madrid • Mexico City • Milan • New Delhi • San Juan Seoul • Singapore • Sydney • Toronto

abc

McGraw-Hill

Copyright © 2002 by The McGraw-Hill Companies, Inc. All rights reserved. Manufactured in the United States of America. Except as permitted under the United States Copyright Act of 1976, no part of this publication may be reproduced or distributed in any form or by any means, or stored in a database or retrieval system, without the prior written permission of the publisher. 0-07-140070-2

All trademarks are trademarks of their respective owners. Rather than put a trademark symbol after every occurrence of a trademarked name, we use names in an editorial fashion only, and to the benefit of the trademark owner, with no intention of infringement of the trademark. Where such designations appear in this book, they have been printed with initial caps. McGraw-Hill eBooks are available at special quantity discounts to use as premiums and sales promotions, or for use in corporate training programs. For more information, please contact George Hoare, Special Sales, at [email protected] or (212) 904-4069.

TERMS OF USE This is a copyrighted work and The McGraw-Hill Companies, Inc. (“McGraw-Hill”) and its licensors reserve all rights in and to the work. Use of this work is subject to these terms. Except as permitted under the Copyright Act of 1976 and the right to store and retrieve one copy of the work, you may not decompile, disassemble, reverse engineer, reproduce, modify, create derivative works based upon, transmit, distribute, disseminate, sell, publish or sublicense the work or any part of it without McGraw-Hill’s prior consent. You may use the work for your own noncommercial and personal use; any other use of the work is strictly prohibited. Your right to use the work may be terminated if you fail to comply with these terms. THE WORK IS PROVIDED “AS IS”. McGRAW-HILL AND ITS LICENSORS MAKE NO GUARANTEES OR WARRANTIES AS TO THE ACCURACY, ADEQUACY OR COMPLETENESS OF OR RESULTS TO BE OBTAINED FROM USING THE WORK, INCLUDING ANY INFORMATION THAT CAN BE ACCESSED THROUGH THE WORK VIA HYPERLINK OR OTHERWISE, AND EXPRESSLY DISCLAIM ANY WARRANTY, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. McGraw-Hill and its licensors do not warrant or guarantee that the functions contained in the work will meet your requirements or that its operation will be uninterrupted or error free. Neither McGraw-Hill nor its licensors shall be liable to you or anyone else for any inaccuracy, error or omission, regardless of cause, in the work or for any damages resulting therefrom. McGraw-Hill has no responsibility for the content of any information accessed through the work. Under no circumstances shall McGraw-Hill and/or its licensors be liable for any indirect, incidental, special, punitive, consequential or similar damages that result from the use of or inability to use the work, even if any of them has been advised of the possibility of such damages. This limitation of liability shall apply to any claim or cause whatsoever whether such claim or cause arises in contract, tort or otherwise. DOI: 10.1036/0071409548

This Book is Dedicated to my wife Debbie and my son Brennan Thank you for your patience and support

This page intentionally left blank.

CONTENTS Foreword xiii Preface xv Acknowledgments Chapter 1

Chapter 2

xviii

Introduction to VHDL

1

VHDL Terms Describing Hardware in VHDL Entity Architectures Concurrent Signal Assignment Event Scheduling Statement Concurrency Structural Designs Sequential Behavior Process Statements Process Declarative Region Process Statement Part Process Execution Sequential Statements Architecture Selection Configuration Statements Power of Configurations

2 3 3 4 5 6 6 7 8 9 9 9 10 10 11 11 12

Behavioral Modeling

15

Introduction to Behavioral Modeling Transport Versus Inertial Delay Inertial Delay Transport Delay Inertial Delay Model Transport Delay Model Simulation Deltas Drivers Driver Creation Bad Multiple Driver Model Generics Block Statements Guarded Blocks

16 20 20 21 22 23 23 27 27 28 29 31 35

vi

Contents Chapter 3

Chapter 4

Chapter 5

Sequential Processing

39

Process Statement Sensitivity List Process Example Signal Assignment Versus Variable Assignment Incorrect Mux Example Correct Mux Example Sequential Statements IF Statements CASE Statements LOOP Statements NEXT Statement EXIT Statement ASSERT Statement Assertion BNF WAIT Statements WAIT ON Signal WAIT UNTIL Expression WAIT FOR time_expression Multiple WAIT Conditions WAIT Time-Out Sensitivity List Versus WAIT Statement Concurrent Assignment Problem Passive Processes

40 40 40 42 43 45 46 47 48 50 53 54 56 57 59 62 62 62 63 64 66 67 70

Data Types

73

Object Types Signal Variables Constants Data Types Scalar Types Composite Types Incomplete Types File Types File Type Caveats Subtypes

74 74 76 77 78 79 86 98 102 105 105

Subprograms and Packages

109

Subprograms Function

110 110

Contents

vii

Chapter 6

Chapter 7

Conversion Functions Resolution Functions Procedures Packages Package Declaration Deferred Constants Subprogram Declaration Package Body

113 119 133 135 136 136 137 138

Predefined Attributes

143

Value Kind Attributes Value Type Attributes Value Array Attributes Value Block Attributes Function Kind Attributes Function Type Attributes Function Array Attributes Function Signal Attributes Attributes ’EVENT and ’LAST_VALUE Attribute ’LAST_EVENT Attribute ’ACTIVE and ’LAST_ACTIVE Signal Kind Attributes Attribute ’DELAYED Attribute ’STABLE Attribute ’QUIET Attribute ’TRANSACTION Type Kind Attributes Range Kind Attributes

144 144 147 149 151 151 154 156 157 158 160 160 161 164 166 168 169 170

Configurations

173

Default Configurations Component Configurations Lower-Level Configurations Entity-Architecture Pair Configuration Port Maps Mapping Library Entities Generics in Configurations Generic Value Specification in Architecture Generic Specifications in Configurations Board-Socket-Chip Analogy Block Configurations Architecture Configurations

174 176 179 180 181 183 185 188 190 195 199 201

viii

Contents Chapter 8

Chapter 9

Chapter 10

Advanced Topics

205

Overloading Subprogram Overloading Overloading Operators Aliases Qualified Expressions User-Defined Attributes Generate Statements Irregular Generate Statement TextIO

206 206 210 215 215 218 220 222 224

Synthesis

231

Register Transfer Level Description Constraints Timing Constraints Clock Constraints Attributes Load Drive Arrival Time Technology Libraries Synthesis Translation Boolean Optimization Flattening Factoring Mapping to Gates

232 237 238 238 239 240 240 240 241 243 243 244 245 246 247

VHDL Synthesis

251

Simple Gate — Concurrent Assignment IF Control Flow Statements Case Control Flow Statements Simple Sequential Statements Asynchronous Reset Asynchronous Preset and Clear More Complex Sequential Statements Four-Bit Shifter State Machine Example

252 253 256 257 259 261 262 264 266

Contents

ix Chapter 11

Chapter 12

Chapter 13

High Level Design Flow

273

RTL Simulation VHDL Synthesis Functional Gate-Level Verification Place and Route Post Layout Timing Simulation Static Timing

275 277 283 284 286 287

Top-Level System Design

289

CPU Design Top-Level System Operation Instructions Sample Instruction Representation CPU Top-Level Design Block Copy Operation

290 290 291 292 293 299

CPU: Synthesis Description

303

ALU Comp Control Reg Regarray Shift Trireg

Chapter 14

Chapter 15

306 309 311 321 322 324 326

CPU: RTL Simulation

329

Testbenches Kinds of Testbenches Stimulus Only Full Testbench Simulator Specific Hybrid Testbenches Fast Testbench CPU Simulation

330 331 333 337 340 342 345 349

CPU Design: Synthesis Results

357

x

Contents Chapter 16

Chapter 17

Chapter 18

Place and Route

369

Place and Route Process Placing and Routing the Device Setting up a project

370 373 373

CPU: VITAL Simulation

379

VITAL Library VITAL Simulation Process Overview VITAL Implementation Simple VITAL Model VITAL Architecture Wire Delay Section Flip-Flop Example SDF File VITAL Simulation Back-Annotated Simulation

381 382 382 383 386 386 388 392 394 397

At Speed Debugging Techniques

399

Instrumentor Debugger Debug CPU Design Create Project Specify Top-Level Parameters Specify Project Parameters Instrument Signals Write Instrumented Design Implement New Design Start Debug Enable Breakpoint Trigger Position Waveform Display Set Watchpoint Complex Triggers

401 401 401 402 403 403 404 405 405 406 406 408 408 409 410

Appendix A Standard Logic Package

413

Appendix B VHDL Reference Tables

435

Appendix C Reading VHDL BNF

445

Contents

xi Appendix D VHDL93 Updates Alias Attribute Changes Bit String Literal DELAY_LENGTH Subtype Direct Instantiation Extended Identifiers File Operations Foreign Interface Generate Statement Changes Globally Static Assignment Groups Incremental Binding Postponed Process Pure and Impure Functions Pulse Reject Report Statement Shared Variables Shift Operators SLL — shift left logical SRL — shift right logical SLA — shift left arithmetic SRA — shift right arithmetic ROL — rotate left ROR — rotate right Syntax Consistency Unaffected XNOR Operator

Index 469 About the Author

477

449 449 450 452 452 452 453 454 455 456 456 457 458 459 460 460 461 461 463 463 463 463 463 464 464 464 466 466

This page intentionally left blank.

FOREWORD

VHDL has been at the heart of electronic design productivity since initial ratification by the IEEE in 1987. For almost 15 years the electronic design automation industry has expanded the use of VHDL from initial concept of design documentation, to design implementation and functional verification. It can be said that VHDL fueled modern synthesis technology and enabled the development of ASIC semiconductor companies. The editions of Doug Perry’s books have served as the authoritative source of practical information on the use of VHDL for users of the language around the world. The use of VHDL has evolved and its importance increased as semiconductor devices dimensions have shrunk. Not more than 10 years ago it was common to mix designs described with schematics and VHDL. But as design complexity grew, the industry abandoned schematics in favor of the hardware description language only. The successive revisions of this book have always kept pace with the industry’s evolving use of VHDL. The fact that VHDL is adaptable is a tribute to its architecture. The industry has seen the use of VHDL’s package structure to allow designers, electronic design automation companies and the semiconductor industry to experiment with new language concepts to ensure good design tool and data interoperability. When the associated data types found in the IEEE 1164 standard were ratified, it meant that design data interoperability was possible. All of this was facilitated by industry backing in a consortium of systems, electronic design automation and semiconductor companies now known as Accellera. And when the ASIC industry needed a standard way to convey gatelevel design data and timing information in VHDL, one of Accellera’s progenitors (VHDL International) sponsored the IEEE VHDL team to build a companion standard. The IEEE 1076.4 VITAL (VHDL Initiative Towards ASIC Libraries) was created and ratified as offers designers a single language flow from concept to gate-level signoff. In the late ’90s, the Verilog HDL and VHDL industry standards teams collaborated on the use of a common timing data such as IEEE 1497 SDF, set register transfer level (RTL) standards and more to improve design

xiv

Foreword methodologies and the external connections provided to the hardware description languages. But from the beginning, the leadership of the VHDL community has assured open and internationally accredited standards for the electronic design engineering community. The legacy of this team’s work continues to benefit the design community today as the benchmark by which one measures openness. The design community continues to see benefits as the electronic design automation community continues to find new algorithms to work from VHDL design descriptions and related standards to again push designer productivity. And, as a new generation of designers of programmable logic devices move to the use of hardware description languages as the basis of their design methodology, there will be substantial growth in the number of VHDL users. This new generation of electronic designers, along with the current designers of complex systems and ASICs, will find this book as invaluable as the first generation of VHDL users did with the first addition. Updated with current use of the standard, all will benefit from the years of use that have made the VHDL language the underpinning of successful electronic design. Dennis B. Brophy Chair, Accellera

PREFACE

This is the fourth version of the book and this version now not only provides VHDL language coverage but design methodology information as well. This version will guide the reader through the process of creating a VHDL design, simulating the design, synthesizing the design, placing and routing the design, using VITAL simulation to verify the final result, and a new technique called At-Speed debugging that provides extremely fast design verification. The design example in this version has been updated to reflect the new focus on the design methodology. This book was written to help hardware design engineers learn how to write good VHDL design descriptions. The goal is to provide enough VHDL and design methodology information to enable a designer to quickly write good VHDL designs and be able to verify the results. It will also attempt to bring the designer with little or no knowledge of VHDL, to the level of writing complex VHDL descriptions. It is not intended to show every possible construct of VHDL in every possible use, but rather to show the designer how to write concise, efficient, and correct VHDL descriptions of hardware designs. This book is organized into three logical sections. The first section of the book will introduce the VHDL language, the second section walks through a VHDL based design process including simulation, synthesis, place and route, and VITAL simulation; and the third section walks through a design example of a small CPU design from VHDL capture to final gate-level implementation, and At-Speed debugging. At the back of the book are included a number of appendices that contain useful information about the language and examples used throughout the book. In the first section VHDL features are introduced one or more at a time. As each feature is introduced, one or more real examples are given to show how the feature would be used. The first section consists of Chapters 1 through 8, and each chapter introduces a basic description capability of VHDL. Chapter 1 discusses how VHDL design relates to schematic based design, and introduces the basic terms of the language. Chapter 2 describes some of the basic concepts of VHDL, including the different delay mechanisms available, how to use instance specific data, and defines VHDL drivers. Chapter 2 discusses concurrent statements while Chapter 3 introduces the reader to VHDL sequential statements. Chapter 4 talks about the wide

xvi

Preface range of types available for use in VHDL. Examples are given for each of the types showing how they would be used in a real example. In Chapter 5 the concepts of subprograms and packages are introduced. The different uses for functions are given, as well as the features available in VHDL packages. Chapter 6 introduces the five kinds of VHDL attributes. Each attribute kind has examples describing how to use the specific attribute to the designer’s best advantage. Examples are given which describe the purpose of each of the attributes. Chapters 7 and 8 will introduce some of the more advanced VHDL features to the reader. Chapter 7 discusses how VHDL configurations can be used to construct and manage complex VHDL designs. Each of the different configuration styles are discussed along with examples showing usage. Chapter 8 introduces more of the VHDL advanced topics with discussions of overloading, user defined attributes, generate statements, and TextIO. The second section of the book consists of Chapters 9 through 11. Chapters 9 and 10 discuss the synthesis process and how to write synthesizable designs. These two chapters describe the basics of the synthesis process including how to write synthesizeable VHDL, what is a technology library, what does the synthesis process look like, what are constraints and attributes, and what does the the optimization process look like. Chapter 11 discusses the complete high level design flow from VHDL capture through VITAL simulation. The third section of the book walks through a description of a small CPU design from the VHDL capture through simulation, synthesis, place and route, and VITAL simulation. Chapter 12 describes the top level of the CPU design from a functional point of view. In Chapter 13 the RTL description of the CPU is presented and discussed from a synthesis point of view. Chapter 14 begins with a discussion of VHDL testbenches and how they are used to verify functionality. Chapter 14 finishes the discussion by describing the simulation of the CPU design. In Chapter 15 the verified design is synthesized to a target technology. Chapter 16 takes the synthesized design and places and routes the design to a target device. Chapter 17 begins with a discussion of VITAL and ends with the VITAL simulation of the placed and routed CPU design. Chapter 18 is a new chapter that discusses the new technique of At-Speed debugging. This chapter provides the reader with an in-depth look at how a hardware implementation of the CPU design can help speed verification. Finally there are three appendices at the end of the book to provide reference information. Appendix A is a listing of the IEEE 1164 STD_LOGIC

Preface

xvii package used throughout the book. Appendix B is a set of useful tables that condense some of the information in the rest of the book into quick reference tables. Finally, Appendix C describes how to read the BachusNaur format(BNF) descriptions found in the VHDL Language Reference Manual. I can only hope that you the reader will have as much fun reading this book and working with VHDL as I did in writing it.

ACKNOWLEDGMENTS

This book would not have been possible without the help of a number of people, and I would like to express my gratitude to all of them. Rod Farrow, Cary Ussery, Alec Stanculescu, and Ken Scott answered a multitude of questions about some of the vagaries of VHDL. Mark Beardslee and Derek Palmer for their review of parts of the third edition. Their comments were both helpful and insightful. Paul Krol developed the chart in Chapter 7 that describes generics. Keith Irwin helped define the style of some of the chapters. Hoa Dinh and David Emrich for answering a lot of questions about FPGA synthesis. Thanks to John Ott and Dennis Brophy for making the ModelSim and Leonardo Spectrum software available during the writing and for the software on the CD. Thanks to Derek Palmer and Robert Blake of Altera for making the MaxPlus II software available and answering questions. Finally thanks to Endric Schubert, Mark Beardslee, Gernot Koch, Olaf Poeppe, Matt Hall, Michael Eitelwein, Ewald Detjens, and William Vancleemput for all of their hard work with Bridges2Silicon.

CHAPTER

1

Introduction to VHDL The VHSIC Hardware Description Language is an industry standard language used to describe hardware from the abstract to the concrete level. VHDL resulted from work done in the ’70s and early ’80s by the U.S. Department of Defense. Its roots are in the ADA language, as will be seen by the overall structure of VHDL as well as other VHDL statements. VHDL usage has risen rapidly since its inception and is used by literally tens of thousands of engineers around the globe to create sophisticated electronic products. This chapter will start the process of easing the reader into the complexities of VHDL. VHDL is a powerful language with numerous language constructs that are capable of describing very complex behavior. Learning all the features of VHDL is not a simple task. Complex features will be introduced in a simple form and then more complex usage will be described.

2

Chapter One 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. The IEEE 1076-1987 standard VHDL is the VHDL used in this book. (Appendix D contains a brief description of VHDL 1076-1993.) All the examples have been described in IEEE 1076 VHDL, and compiled and simulated with the VHDL simulation environment from Model Technology Inc. The synthesis examples were synthesized with the Exemplar Logic Inc. synthesis tools.

VHDL Terms Before we go any further, let’s define some of the terms that we use throughout the book. These are the basic VHDL building blocks that are used in almost every description, along with some terms that are redefined in VHDL to mean something different to the average designer. ■ Entity. All designs are expressed in terms of entities. An entity is the most basic building block in a design. The uppermost level of the design is the top-level entity. If the design is hierarchical, then the top-level description will have lower-level descriptions contained in it. These lower-level descriptions will be lower-level entities contained in the top-level entity description. ■ Architecture. All entities that can be simulated have an architecture description. The architecture describes the behavior of the entity. A single entity can have multiple architectures. One architecture might be behavioral while another might be a structural description of the design. ■ Configuration. A configuration statement is used to bind a component instance to an entity-architecture pair. A configuration can be considered like a parts list for a design. It describes which behavior to use for each entity, much like a parts list describes which part to use for each part in the design. ■ Package. A package is a collection of commonly used data types and subprograms used in a design. Think of a package as a toolbox that contains tools used to build designs. ■ Driver. This is a source on a signal. If a signal is driven by two sources, then when both sources are active, the signal will have two drivers.

Introduction to VHDL

3

■ Bus. The term “bus” usually brings to mind a group of signals or a particular method of communication used in the design of hardware. In VHDL, a bus is a special kind of signal that may have its drivers turned off. ■ Attribute. An attribute is data that are attached to VHDL objects or predefined data about VHDL objects. Examples are the current drive capability of a buffer or the maximum operating temperature of the device. ■ Generic. A generic is VHDL’s term for a parameter that passes information to an entity. For instance, if an entity is a gate level model with a rise and a fall delay, values for the rise and fall delays could be passed into the entity with generics. ■ Process. A process is the basic unit of execution in VHDL. All operations that are performed in a simulation of a VHDL description are broken into single or multiple processes.

Describing Hardware in VHDL VHDL Descriptions consist of primary design units and secondary design units. The primary design units are the Entity and the Package. The secondary design units are the Architecture and the Package Body. Secondary design units are always related to a primary design unit. Libraries are collections of primary and secondary design units. A typical design usually contains one or more libraries of design units.

Entity A VHDL entity specifies the name of the entity, the ports of the entity, and entity-related information. All designs are created using one or more entities. Let’s take a look at a simple entity example: ENTITY mux IS PORT ( a, b, c, d : IN BIT; s0, s1 : IN BIT; x, : OUT BIT); END mux;

4

Chapter One The keyword ENTITY signifies that this is the start of an entity statement. In the descriptions shown throughout the book, keywords of the language and types provided with the STANDARD package are shown in ALL CAPITAL letters. For instance, in the preceding example, the keywords are ENTITY, IS, PORT, IN, INOUT, and so on. The standard type provided is BIT. Names of user-created objects such as mux, in the example above, will be shown in lower case. The name of the entity is mux. The entity has seven ports in the PORT clause. Six ports are of mode IN and one port is of mode OUT. The four data input ports (a, b, c, d) are of type BIT. The two multiplexer select inputs, s0 and s1, are also of type BIT. The output port is of type BIT. The entity describes the interface to the outside world. It specifies the number of ports, the direction of the ports, and the type of the ports. A lot more information can be put into the entity than is shown here, but this gives us a foundation upon which we can build more complex examples.

Architectures The entity describes the interface to the VHDL model. The architecture describes the underlying functionality of the entity and contains the statements that model the behavior of the entity. An architecture is always related to an entity and describes the behavior of that entity. An architecture for the counter device described earlier would look like this: ARCHITECTURE dataflow OF mux IS SIGNAL select : INTEGER; BEGIN select b, x1 => a, x4 => d, x3 => c, x => x);

This statement uses named association to match the ports and signals to each other. For instance port x2 of the orgate is connected to port b of the entity with the first association clause. The last instantiation clause connects port x of the orgate component to port x of the entity. The order of the clauses is not important. Named and ordered association can be mixed, but it is not recommended.

Sequential Behavior There is yet another way to describe the functionality of a mux device in VHDL. The fact that VHDL has so many possible representations for similar functionality is what makes learning the entire language a big task. The third way to describe the functionality of the mux is to use a process statement to describe the functionality in an algorithmic representation. This is shown in architecture sequential, as shown in the following: ARCHITECTURE sequential OF mux IS (a, b, c, d, s0, s1 ) VARIABLE sel : INTEGER; BEGIN IF s0 = ‘0’ and s1 = ‘0’ THEN sel := 0; ELSIF s0 = ‘1’ and s1 = ‘0’ THEN sel := 1; ELSIF s0 = ‘0’ and s1 = ‘0’ THEN sel := 2; ELSE sel := 3; END IF; CASE sel IS

Introduction to VHDL

9

WHEN 0 => x x x x qdelay, => qbdelay) clk, int1, reset, ground, data_out, nc);

The entity and architecture shown are a simple 2-bit shift register made from two D flip-flop (DFF) component instantiations. This example, though relatively simple, shows how ports and generics are mapped at different levels. The component instance for component DFF in the architecture statement part acts like a socket in the architecture for the board. When a component instance is placed in the architecture, signals are used to connect the component to the board, which is the architecture. The actual chip is not connected to the socket until a configuration is specified for the board entity. If all of the names of the socket ports and generics match the names of the actual entity being used, then no mapping is needed. The default mapping connects the chip to the socket. If the names are different, or the number of ports are not the same, for the component instanti-

198

Chapter Seven ation and the actual entity, then a mapping between the socket (component instantiation) and the chip (actual entity) is needed. The actual chip to be mapped is described by the entity and architecture shown here: LIBRARY IEEE; USE IEEE.std_logic_1164.ALL; ENTITY dff IS GENERIC( q_out, qb_out : time); PORT( preset, clear, din, PORT( clock : IN std_logic; PORT( q, qb : OUT std_logic); END dff; ARCHITECTURE behave OF dff IS BEGIN dff_proc : PROCESS(preset, clear, clock) VARIABLE int_q : std_logic; BEGIN IF preset = ‘0’ and clear = ‘0’ THEN IF (clock’EVENT) AND (clock = ‘1’) THEN int_q := din; END IF; ELSIF preset = ‘1’ AND clear = ‘0’ THEN int_q := ‘1’; ELSIF clear = ‘1’ AND preset = ‘0’ THEN int_q := ‘0’; ELSE int_q := ‘X’; END IF; q g2) PORT MAP( preset => ground, clear => p3, PORT MAP( din => p2, clock => p1, PORT MAP( q => p5, qb => p6); END FOR; END FOR; END board_con;

Block Configurations When an architecture contains block statements, the configuration must reflect this fact. (Block statements are discussed in Chapter 2, “Behavioral Modeling.”) Blocks act like another level of hierarchy between the containing architecture and any components being configured. The configuration must specify which block of a configuration is being configured when the architecture is being configured. Following shows an architecture fragment that contains three blocks: LIBRARY IEEE; USE IEEE.std_logic_1164.ALL; ENTITY cpu IS PORT( clock : IN std_logic; PORT( addr : OUT std_logic_vector(0 to 3); PORT( data : INOUT std_logic_vector(0 to 3); PORT( interrupt : IN std_logic; PORT( reset : IN std_logic); END cpu; ARCHITECTURE fragment OF cpu IS COMPONENT int_reg PORT( data : IN std_logic; PORT( regclock : IN std_logic; PORT( data_out : OUT std_logic); END COMPONENT; COMPONENT alu PORT( a, b : IN std_logic; PORT( c, carry : OUT std_logic); END COMPONENT; SIGNAL a, c, carry : std_logic_vector(0 TO 3); BEGIN reg_array : BLOCK BEGIN R1 : int_reg PORT MAP( data(0), clock, data(0));

200

Chapter Seven

R2 : int_reg PORT MAP( data(1), clock, data(1)); R3 : int_reg PORT MAP( data(2), clock, data(2)); R4 : int_reg PORT MAP( data(3), clock, data(3)); END BLOCK reg_array; shifter : BLOCK BEGIN A1 : alu PORT MAP( a(0), data(0), c(0), carry(0)); A2 : alu PORT MAP( a(1), data(1), c(1), carry(1)); A3 : alu PORT MAP( a(2), data(2), c(2), carry(2)); A4 : alu PORT MAP( a(3), data(3), c(3), carry(3)); shift_reg : BLOCK BEGIN R1 : int_reg PORT MAP( data, shft_clk, data_out); END BLOCK shift_reg; END BLOCK shifter; END fragment;

The architecture consists of three blocks, each containing component instantiations. The first block contains four int_reg components, and the second contains an alu component, plus another BLOCK statement. The last block contains a single int_reg component. The configuration for this architecture must take into account the fact that BLOCK statements exist in the architecture. Following is a simple configuration for the architecture: CONFIGURATION cpu_con OF cpu IS FOR fragment FOR reg_array FOR ALL: int_reg USE CONFIGURATION WORK.int_reg_con; END FOR; END FOR;

Configurations

201 FOR shifter FOR A1 : alu USE CONFIGURATION WORK.alu_con; END FOR; FOR shift_reg FOR R1 : int_reg USE CONFIGURATION WORK.int_reg_con; END FOR; END FOR; END FOR; END FOR; END cpu_con;

In the configuration cpu_con of entity cpu, architecture fragment is used for the entity. Inside of block reg_array, all (R1 through R4) of the int_reg components use configuration int_reg_con. In block shifter, the alu component (A1) uses configuration alu_con. For block shift_reg inside of block shifter, the int_reg component uses configuration int_reg_con.

Architecture Configurations The last type of configuration we discuss is the architecture configuration. This configuration exists in the architecture declarative region and specifies the configurations of parts used in the architecture. If this type of configuration is used, a separate configuration declaration is not needed to configure the components used in the architecture. The next example configuration is for a very high-level description of an autopilot. The autopilot block diagram is shown in Figure 7-5. Following is an example of this type of configuration: PACKAGE ap IS TYPE alt IS INTEGER RANGE 0 TO 50000; TYPE hdg IS INTEGER RANGE 0 TO 359; TYPE vdir IS INTEGER RANGE 0 TO 9; TYPE hdir IS INTEGER RANGE 0 TO 9; TYPE control IS INTEGER RANGE 0 TO 9; END ap; USE WORK.ap.ALL; ENTITY autopilot IS PORT( altitude : IN alt; altitude_set : IN alt; heading : IN hdg; heading_set : IN hdg; rudder : OUT control;

202 Figure 7-5 Block Diagram of Autopilot Example.

Chapter Seven Alt_Comp Indicated Altitude

Alt_Ctrl

Up/Down Elevator

Desired Altitude

Hdg_Comp Indicated Heading

Hdg_Ctrl

Left/Right

Desired Heading

Aileron Rudder

aileron : OUT control; elevator : OUT control); END autopilot; ARCHITECTURE block_level OF autopilot IS COMPONENT alt_compare PORT( alt_ref : IN alt; PORT( alt_ind : IN alt; PORT( up_down : OUT vdir); END COMPONENT; COMPONENT hdg_compare PORT( hdg_ref : IN hdg; PORT( hdg_ind : IN hdg; PORT( left_right : OUT hdir); END COMPONENT; COMPONENT hdg_ctrl PORT( left_right : IN hdir; PORT( rdr : OUT control; PORT( alrn : OUT control); END COMPONENT; COMPONENT alt_ctrl PORT( up_down : IN vdir; PORT( elevator : OUT control); END COMPONENT; SIGNAL up_down : vdir; SIGNAL left_right : hdir; FOR M1 : alt_compare USE CONFIGURATION WORK.alt_comp_con;

Configurations

203 FOR M2 : hdg_compare USE CONFIGURATION WORK.hdg_comp_con; FOR M3 : hdg_ctrl USE ENTITY WORK.hdg_ctrl(behave); FOR M4 : alt_ctrl USE ENTITY WORK.alt_ctrl(behave); BEGIN M1 : alt_compare PORT MAP( alt_ref => altitude, PORT MAP( alt_ind => alt_set, PORT MAP( up_down => up_down); M2 : hdg_compare PORT MAP( hdg_ref => heading, PORT MAP( hdg_ind => hdg_set, PORT MAP( left_right => left_right); M3 : hdg_ctrl PORT MAP( left_right => left_right, PORT MAP( rdr => rudder, PORT MAP( alrn => aileron); M4 : alt_ctrl PORT MAP( up_down => up_down, PORT MAP( elevator => elevator); END block_level;

This model is a top-level description of an autopilot. There are four instantiated components that provide the necessary functionality of the autopilot. This model demonstrates how component instantiations can be configured in the architecture declaration section of an architecture. Notice that after the component declarations in the architecture declaration section of architecture block_level, there are four statements similar to the following: FOR M1 : alt_compare USE CONFIGURATION WORK.alt_comp_con;

These statements allow the designer to specify either the configuration or the entity-architecture pair to use for a particular component type. This type of configuration does not provide the same flexibility to the designer as the separate configuration declaration, but it is useful for small designs. Configurations are a useful tool for managing large designs. With proper use of configurations, a top-down design approach can be implemented that allows all levels of description of the design to be used for the most efficient model needed at any point in the design process.

204

Chapter Seven

SUMMARY In this chapter, we discussed the following: ■ How default configurations can be used to bind architectures to entities. ■ How component configurations can be used to specify which entity to use for each component instantiation. ■ How port maps within configurations allow mapping entities with different names to component instances. ■ How generics can be specified in configurations to allow late binding of generic information. ■ How block configurations can be used to configure architectures with block statements in them. ■ How architecture configurations allow specification of configurations for component instantiations in the architecture declaration section. The basic features of VHDL have now been introduced. In the next chapter, we examine some of the more esoteric but useful features that exist in VHDL.

CHAPTER

8

Advanced Topics In this chapter, some of the more esoteric features of VHDL are discussed. Some of the features may be useful for certain types of designs, and not for others. Typical usage examples are presented to show how these features might be taken advantage of. Some of the features discussed include overloading, qualified expressions, user-defined attributes, generate statements, aliases, and TextIO. All of these features provide the user with an advanced environment with which to do modeling.

206

Chapter Eight

Overloading Overloading allows the designer to write much more readable code. An object is overloaded when the same object name exists for multiple subprograms or type values. The VHDL compiler selects the appropriate object to use in each instance. In VHDL, a number of types of overloading are possible. Subprograms can be overloaded, operators can be overloaded, and enumeration types can be overloaded. Overloading subprograms allows subprograms to operate on objects of different types. Overloading an operator allows the operator to perform the same operation on multiple types. Overloading frees the designer from the necessity of generating countless unique names for subprograms that do virtually the same operation. The result of using overloaded subprograms and operators is models that are easier to read and maintain.

Subprogram Overloading Subprogram overloading allows the designer to write multiple subprograms with the same name, but the number of arguments, the type of arguments, and return value (if any) can be different. The VHDL compiler, at compile time, selects the subprogram that matches the subprogram call. If no subprogram matches the call, an error is generated. The following example illustrates how a subprogram can be overloaded by the argument type: LIBRARY IEEE; USE IEEE.std_logic_1164.ALL; PACKAGE p_shift IS TYPE s_int IS RANGE 0 TO 255; TYPE s_array IS ARRAY(0 TO 7) OF std_logic; FUNCTION shiftr( a : s_array) return s_array; FUNCTION shiftr( a : s_int) return s_int; END p_shift; PACKAGE BODY p_shift IS FUNCTION shiftr( a : s_array) return s_array IS VARIABLE result : s_array; BEGIN FOR i IN a’RANGE LOOP IF i = a’HIGH THEN result(i) := ‘0’;

Advanced Topics

207 ELSE result(i) := a(i + 1); END IF; END LOOP; RETURN result; END shiftr; FUNCTION shiftr( a : s_int) return s_int IS BEGIN RETURN (a/2); END shiftr; END p_shift;

The package p_shift contains two functions both named shiftr. Both functions provide a right-shift capability, but each function operates on a specific type. One function works only with type s_int, and the other works only with type s_array. The compiler picks the appropriate function based on the calling argument(s) and return argument. In the following example, different types of function calls are shown, and the results obtained with each call: USE WORK.p_shift.ALL; ENTITY shift_example IS END shift_example; ARCHITECTURE test OF shift_example IS SIGNAL int_signal : s_int; SIGNAL array_signal : s_array; BEGIN -- picks function that works with s_int type int_signal