The Designer's Guide to VHDL / Edition 1

The Designer's Guide to VHDL / Edition 1

by Peter J. Ashenden, Ashenden
Pub. Date:
Elsevier Science & Technology Books


Current price is , Original price is $56.0. You
Select a Purchase Option (Older Edition)
  • purchase options


The Designer's Guide to VHDL / Edition 1

The Designer's Guide to VHDL is both a comprehensive manual for the language and an authoritative reference on its use in hardware design at all levels, from system level down to gate level. Using the IEEE standard for VHDL, the author presents the entire description language and builds a modeling methodology based on successful software engineering techniques. Requiring only a minimal background in programming, this is an excellent tutorial for anyone in computer architecture, digital systems engineering, or CAD.

The book is organized so that it can either be read cover to cover for a comprehensive tutorial or be kept deskside as a reference to the language. Each chapter introduces a number of related concepts or language facilities and illustrates each one with examples. Scattered throughout the book are four case studies, which bring together preceding material in the form of extended worked examples. In addition, each chapter is followed by a set of rated exercises.

Product Details

ISBN-13: 9781558602700
Publisher: Elsevier Science & Technology Books
Publication date: 06/28/1996
Edition description: Older Edition
Pages: 688
Product dimensions: 7.42(w) x 9.32(h) x 1.28(d)

About the Author

Peter J. Ashenden received his B.Sc.(Hons) and Ph.D. from the University of Adelaide, Australia. He was previously a senior lecturer in computer science and is now a Visiting Research Fellow at the University of Adelaide. His research interests are computer organization and electronic design automation. Dr. Ashenden is also an independent consultant specializing in electronic design automation (EDA). He is actively involved in IEEE working groups developing VHDL standards, is the author of The Designer's Guide to VHDL and The Student's Guide to VHDL and co-editor of the Morgan Kaufmann series, Systems on Silicon. He is a senior member of the IEEE and a member of the ACM.

Read an Excerpt

Chapter 1: Fundamental Concepts

Modeling Digital Systems

if we are to discuss the topic of modeling digital systems, we first need to agree on what a digital system is. Different engineers would come up with different definitions, depending on their background and the field in which they were working. Some may consider a single VLSI circuit to be a self-contained digital system. Others might take a larger view and think of a complete computer, packaged in a cabinet with peripheral controllers and other interfaces.

For the purposes of this book, we include any digital circuit that processes or stores information as a digital system. We thus consider both the system as a whole and the various parts from which it is constructed. Thus our discussions cover a range of systems from the low-level gates that make up the components to the top-level functional units.

If we are to encompass this range of views of digital systems, we must recognize the complexity with which we are dealing. It is not humanly possible to comprehend such complex systems in their entirety. We need to find methods of dealing with the complexity, so that we can, with some degree of confidence, design components and systems that meet their requirements.

The most important way of meeting this challenge is to adopt a systematic methodology of design. If we start with a requirements document for the system, we can design an abstract structure that meets the requirements. We can then decompose this structure into a collection of components that interact to perform the same function. Each of these components can in turn be decomposed until we get to a level where we have some ready-made, primitive components that perform a required function. The result of this process is a hierarchically composed system, built from the primitive elements.

The advantage of this methodology is that each subsystem can be designed independently of others. When we use a subsystem, we can think of it as an abstraction rather than having to consider its detailed composition. So at any particular stage in the design process, we only need to pay attention to the small amount of information relevant to the current focus of design. We are saved from being overwhelmed by masses of detail.

We use the term model to mean our understanding of a system. The model represents that information which is relevant and abstracts away from irrelevant detail. The implication of this is that there may be several models of the same system, since different information is relevant in different contexts. One kind of model might concentrate on representing the function of the system, whereas another kind might represent the way in which the system is composed of subsystems. We will come back to this idea in more detail in the next section.

There are a number of important motivations for formalizing this idea of a model. First, when a digital system is needed, the requirements of the system must be specified. The job of the engineers is to design a system that meets these requirements. To do that, they must be given an understanding of the requirements, hopefully in a way that leaves them free to explore alternative implementations and to choose the best according to some criteria. One of the problems that often arises is that requirements are incompletely and ambiguously spelled out, and the customer and the design engineers disagree on what is meant by the requirements document. This problem can be avoided by using a formal model to communicate requirements.

A second reason for using formal models is to communicate understanding of the function of a system to a user. The designer cannot always predict every possible way in which a system may be used, and so is not able to enumerate all possible behaviors. If the designer provides a model, the user can check it against any given set of inputs and determine how the system behaves in that context. Thus a formal model is an invaluable tool for documenting a system.

A third motivation for modeling is to allow testing and verification of a design using simulation. If we start with a requirements model that defines the behavior of a system, we can simulate the behavior using test inputs and note the resultant outputs of the system. According to our design methodology, we can then design a circuit from subsystems, each with its own model of behavior. We can simulate this- composite system with the same test inputs and compare the outputs with those of the previous simulation. If they are the same, we know that the composite system meets the requirements for the cases tested. Otherwise we know that some revision of the design is needed. We can continue this process until we reach the bottom level in our design hierarchy, where the components are real devices whose behavior we know. Subsequently, when the design is manufactured, the test inputs and outputs from simulation can be used to verify that the physical circuit functions correctly. This approach to testing and verification of course assumes that the test inputs cover all of the circumstances in which the final circuit will be used. The issue of test coverage is a complex problem in itself and is an active area of research.

A fourth motivation for modeling is to allow formal verification of the correctness of a design. Formal verification requires a mathematical statement of the required function of a system. This statement may be expressed in the notation of a formal logic system, such as temporal logic. Formal verification also requires a mathematical definition of the meaning of the modeling language or notation used to describe a design. The process of verification involves application of the rules of inference of the logic system to prove that the design implies the required function. While formal verification is not yet in everyday use, it is an active area of research. There have already been significant demonstrations of formal verification techniques in real design projects, and the promise for the future is bright.

One final, but equally important, motivation for modeling is to allow automatic synthesis of circuits. If we can formally specify the function required of a system, it is in theory possible to translate that specification into a circuit that performs the function. The advantage of this approach is that the human cost of design is reduced, and engineers are free to explore alternatives rather than being bogged down in design detail. Also, there is less scope for errors being introduced into a design and not being detected. If we automate the translation from specification to implementation, we can be more confident that the resulting circuit is correct.

The unifying factor behind all of these arguments is that we want to achieve maximum reliability in the design process for minimum cost and design time. We need to ensure that requirements are clearly specified and understood, that subsystems are used correctly and that designs meet the requirements. A major contributor to excessive cost is having to revise a design after manufacture to correct errors. By avoiding errors, and by providing better tools for the design process, costs and delays can be contained.

1.2 Domains and Levels of Modeling

In the previous section, we mentioned that there may be different models of a system, each focussing on different aspects. We can classify these models into three domains: function, structure and geometry. The functional domain is concerned with the operations performed by the system. In a sense, this is the most abstract domain of description, since it does not indicate how the function is implemented. The structural domain deals with how the system is composed of interconnected subsystems. The geometric domain deals with how the system is laid out in physical space.

Each of these domains can also be divided into levels of abstraction. At the top level, we consider an overview of function, structure or geometry, and at lower levels we introduce successively finer detail. Figure 1-1 (devised by Gajski and Kuhn, see reference [61) represents the domains on three independent axes, and represents the levels of abstraction by the concentric circles crossing each of the axes....

Table of Contents

The DesignerÆs Guide to VHDL
by Peter J. Ashenden
    1 Fundamental Concepts
      1.1 Modeling Digital Systems
      1.2 Domains and Levels of Modeling
      1.3 Modeling Languages
      1.4 VHDL Modeling Concepts
        Elements of Behavior
        Elements of Structure
        Mixed Structural and Behavioral Models
        Test Benches
        Analysis, Elaboration and Execution
      1.5 Learning a New Language: Lexical Elements and Syntax
        Lexical Elements
        Syntax Descriptions

    2 Scalar Data Types and Operations
      2.1 Constants and Variables
        Constant and Variable Declarations
        Variable Assignment
      2.2 Scalar Types
        Type Declarations
        Integer Types
        Floating-Point Types
        Physical Types
        Enumeration Types
      2.3 Type Classification
        Type Qualification
        Type Conversion
      2.4 Attributes of Scalar Types
      2.5 Expressions and Operators

    3 Sequential Statements
      3.1 If Statements
      3.2 Case Statements
      3.3 Null Statements
      3.4 Loop Statements
        Exit Statements
        Next Statements
        While Loops
        For Loops
        Summary of Loop Statements
      3.5 Assertion and Report Statements

    4 Composite Data Types and Operations
      4.1 Arrays
      Multidimensional Arrays
      Array Aggregates
      Array Attributes
    4.2 Unconstrained Array Types
      Bit Vectors
      Standard-Logic Arrays
      String and Bit-String Literals
      Unconstrained Array Ports
    4.3 Array Operations and Referencing
      Array Slices
      Array Type Conversions
    4.4 Records
      Record Aggregates

5 Basic Modeling Constructs
    5.1 Entity Declarations
    5.2 Architecture Bodies
      Concurrent Statements
      Signal Declarations
    5.3 Behavioral Descriptions
      Signal Assignment
      Signal Attributes
      Wait Statements
      Delta Delays
      Transport and Inertial Delay Mechanisms
      Process Statements
      Concurrent Signal Assignment Statements
      Concurrent Assertion Statements
      Entities and Passive Processes
    5.4 Structural Descriptions
      Component Instantiation and Port Maps
    5.5 Design Processing
      Design Libraries, Library Clauses and Use Clauses

6 Case Study: A Pipelined Multiplier Accumulator
    6.1 Algorithm Outline
      MAC Entity Declaration
    6.2 A Behavioral Model
      Testing the Behavioral Model
    6.3 A Register-Transfer-Level Model
      Modules in the Register-Transfer-Level Model
      The Register-Transfer-Level Architecture Body
      Testing the Register-Transfer-Level Model

7 Subprograms
    7.1 Procedures
      Return Statement in a Procedure
    7.2 Procedure Parameters
      Signal Parameters
      Default Values
      Unconstrained Array Parameters
      Summary of Procedure Parameters
    7.3 Concurrent Procedure Call Statements
      Functional Modeling
      Pure and Impure Functions
      The Function Now
    7.5 Overloading
      Overloading Operator Symbols
    7.6 Visibility of Declarations

8 Packages and Use Clauses
    8.1 Package Declarations
      Subprograms in Package Declarations
      Constants in Package Declarations
    8.2 Package Bodies
    8.3 Use Clauses
    8.4 The Predefined Package Standard

9 Aliases
    9.1 Aliases for Data Objects
    9.2 Aliases for Non-Data Items

10 Case Study: A Bit-Vector Arithmetic Package
    10.1 The Package Interface
    10.2 The Package Body
    10.3 An ALU Using the Arithmetic Package

11 Resolved Signals
    11.1 Basic Resolved Signals
      Composite Resolved Subtypes
      Summary of Resolved Subtypes
    11.2 IEEE Std_Logic_1164 Resolved Subtypes
    11.3 Resolved Signals and Ports
      Resolved Ports
      Driving Value Attribute
    11.4 Resolved Signal Parameters

12 Generic Constants
    12.1 Parameterizing Behavior
    12.2 Parameterizing Structure

13 Components and Configurations
    13.1 Components
      Component Declarations
      Component Instantiation
      Packaging Components
    13.2 Configuring Component Instances
      Basic Configutration Declarations
      Configuring Multiple Levels of Hierarchy
      Direct Instantiation of Configured Entities
      Generic and Port Maps in Configurations
      Deferred Component Binding
    13.3 Configuration Specifications
      Incremental Binding

14 Generate Statements
    14.1 Generating Iterative Structures
    14.2 Conditionally Generating Structures
      Recursive Structures
    14.3 Configuration of Generate Statements

15 Case Study: The DLX Computer System
    15.1 Overview of the DLX CPU
      DLX Registers
      DLX Instruction Set
      DLX External Interface
    15.2 A Behavioral Model
      The DLX Types Package
      The DLX Entity Declaration
      The DLX Instruction Set Package
      The DLX Behavioral Architecture Body
    15.3 Testing the Behavioral Model
      The Test-Bench Clock Generator
      The Test-Bench Memory
      The Test-Bench Architecture Body and Configuration
    15.4 A Register-Transfer-Level Model
      The Arithmetic and Logic Unit
      The Registers
      The Register File
      The Multiplexer
      The Extenders
      The Architecture Body
      The Controller
      The Configuration Declaration
    15.5 Testing the Register-Transfer-Level Model

16 Guards and Blocks
    16.1 Guarded Signals and Disconnection
      The Driving Attribute
      Guarded Ports
      Guarded Signal Parameters
    16.2 Blocks and Guarded Signal Assignment
      Explicit Guard Signals
      Disconnection Specifications
    16.3 Using Blocks for Structural Modularity
      Generics and Ports in Blocks
      Configuring Designs with Blocks

17 Access Types and Abstract Data Types
    17.1 Access Types
      Access Type Declarations and Allocators
      Assignment and Equality of Access Values
      Access Types for Records and Arrays
    17.2 Linked Data Structures
      Deallocation and Storage Management
    17.3 Abstract Data Types Using Packages
      Container ADTs

18 Files and Input/Output
    18.1 Files
      File Declarations
      Reading from Files
      Writing to Files
      Files Declared in Subprograms
      Explicit Open and Close Operations
      File Parameters in Subprograms
      Portability of Files
    18.2 The Package Textio
      Textio Read Operations
      Textio Write Operations
      Reading and Writing User-Defined Types

19 Case Study: Queuing Networks
    19.1 Queuing Network Concepts
    19.2 Queuing Network Modules
      Random Number Generator
      A Package for Token and Arc Types
      The Token Source Module
      The Token Sink Module
      The Queue Module
      The Token Server Module
      The Fork Module
      The Join Module
    19.3 A Queuing Network for a Disk System

20 Attributes and Groups
    20.1 Predefined Attributes
      Attributes of Scalar Types
      Attributes of Array Types and Objects
      Attributes of Signals
      Attributes of Named Items
    20.2 User-Defined Attributes
      Attribute Declarations
      Attribute Specifications
      The Attribute Foreign
    20.3 Groups

21Miscellaneous Topics
    21.1 Buffer and Linkage Ports
    21.2 Conversion Functions in Association Lists
    21.3 Postponed Processes
    21.4 Shared Variables

A Synthesis by DAVID W. BISHOP
    A.1 Synthesis Tools
    A.2 A Synthesis Subset of VHDL
      EVSWG Synthesis Subsets
    A.3 Tricks and Hints
      Using IEEE Standard 1164 Logic Types
      Design Partitioning
    A.4 The Draft P1076.3 Standard Synthesis Package
    A.5 Examples-"Doing It Right"
      Finite-State Machines
    A.6 Examples-"Doing It Wrong"
    A.7 Hand Instantiation-"Doing it the hard way"

B The Predefined Package Standard
C IEEE Standard 1164
D Related Standards
    D.1 IEEE Std. 1029.1: WAVES
    D.2 IEEE P1076a: Shared Variables
    D.3 IEEE P1076.1: VHDL-A-Analog Extensions to VHDL
    D.4 IEEE P1076.2: Standard VHDL Language Mathematical Package
    D.5 IEEE P1076.3: Standard VHDL Language Synthesis Package
    D.6 IEEE P1076.4: Timing Methodology (VITAL)
    D.7 IEEE P1076.5: VHDL Utility Library
    D.8 IEEE P1165: EDIF Interoperability
    D.9 EIA-567A: Component Modeling and Interface Standard

E VHDL Syntax
    Index to Syntax Rules
    E.1 Design File
    E.2 Library Unit Declarations
    E.3 Declarations and Specifications
    E.4 Type Definitions
    E.5 Concurrent Statements
    E.6 Sequential Statements
    E.7 Interfaces and Associations
    E.8 Expressions

F Differences Between VHDL-87 and VHDL-93
    Lexical Differences
    Syntactic Differences
    Semantic Differences
    Differences in the Standard Environment
    VHDL-93 Facilities Not in VHDL-87

G Answers to Exercises


by Paul Mencbini
Research Triangle Park, North Carolina

Digital electronic systems are increasing exponentially in their complexity over time. This fact, coupled with decreasing product lifetimes and increasing reliability requirements, has forced designers to dramatically increase their productivity and the quality of their designs.

VHDL was developed in response to these trends. Borrowing complexity management and error detection techniques from the software engineering world, VHDL was developed to eliminate irrelevant detail, allow technology-independent description, catch errors earlier, and promote portable and interoperable models from the gate to the system level.

In response, EDA tools have been designed to take an ever-greater share of the burden from designers. A single representation medium can now drive design processes from specification down to detailed digital design.

Originally developed as the United States Department of Defense's standard hardware description language (HDL), VHDL has evolved through two additional rounds of IEEE standardization into one of the two preeminent HDLs in use throughout the world. Continued development in the areas of detailed timing models, synthesis directives, analog capabilities, and so forth mean the VHDL will continue to provide the expressive facilities needed by state-of-the-art designs well into the next century. New tools leveraging on VHDL's precise definition continue to be introduced and offer increased simulation performance, increased synthesis capabilities, and entirely new capabilities such as the formal verification of the functional equivalence of models.

Because VHDL usesconcepts not commonly found in hardware description, designers approaching VHDL for the first time need a sure guide to the features using these concepts. One of the few books on VHDL that does not rely heavily on experience with programming languages, A Designer's Guide to VHDL is ideal for the nonprogrammer wishing to learn VHDL.

This book explores in detail the latest version of VHDL, VHDL-93 (IEEE Std. 1076-1993). Assuming no prior knowledge of VHDL, Professor Ashenden walks the reader through VHDL, first addressing simple modeling issues, then moving on to the more complex. As VHDL contains many features, the reader is greatly aided by the inclusion of four fully worked case studies. These case studies put VHDL's features in context and show how they work in concert to model digital systems of varying levels of complexity and varying levels of detail.

Appendices cover the use of VHDL in synthesis, as well as other standards built upon the VHDL framework. As an aid to the experienced user of VHDL, other appendices contain syntax summaries and a list of differences from the initial IEEE standard, IEEE Std. 1076-1987.

Welcome to VHDL!

Customer Reviews

Most Helpful Customer Reviews

See All Customer Reviews