The Designer's Guide to VHDL

Peter J. Ashenden

• Publisher: Morgan Kaufmann
• Year: 2001
• Print ISBN: 9781558606746
• eBook ISBN: 9780080477152
• Edition: 2
• Topic: Computer Science
• Subtopic: Systems Architecture
• Index: Computer Science

Since the publication of the first edition of The Designer's Guide to VHDL in 1996, digital electronic systems have increased exponentially in their complexity, product lifetimes have dramatically shrunk, and reliability requirements have shot through the roof. As a result more and more designers have turned to VHDL to help them dramatically improve productivity as well as the quality of their designs. VHDL, the IEEE standard hardware description language for describing digital electronic systems, allows engineers to describe the structure and specify the function of a digital system as well as simulate and test it before manufacturing. In addition, designers use VHDL to synthesize a more detailed structure of the design, freeing them to concentrate on more strategic design decisions and reduce time to market. Adopted by designers around the world, the VHDL family of standards have recently been revised to address a range of issues, including portability across synthesis tools. This best-selling comprehensive tutorial for the language and authoritative reference on its use in hardware design at all levels--from system to gates--has been revised to reflect the new IEEE standard, VHDL-2001. Peter Ashenden, a member of the IEEE VHDL standards committee, presents the entire description language and builds a modeling methodology based on successful software engineering techniques. Reviewers on Amazon.com have consistently rated the first edition with five stars. This second edition updates the first, retaining the authors unique ability to teach this complex subject to a broad audience of students and practicing professionals.* Details how the new standard allows for increased portability across tools.* Covers related standards, including the Numeric Synthesis Package and the Synthesis Operability Package, demonstrating how they can be used for digital systems design.* Presents four extensive case studies to demonstrate and combine features of the language taught across multiple chapters.* Requires only a minimal background in programming, making it an excellent tutorial for anyone in computer architecture, digital systems engineering, or CAD.

1 Fundamental Concepts

In this introductory chapter, we describe what we mean by digital system modeling and see why modeling and simulation are an important part of the design process. We see how the hardware description language VHDL can be used to model digital systems and introduce some of the basic concepts underlying the language. We complete this chapter with a description of the basic lexical and syntactic elements of the language, to form a basis for the detailed descriptions of language features that follow in later chapters.

1.1 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. Therefore, 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...

Table of contents

• Cover
• Title Page
• Copyright
• Dedication
• Foreword
• Foreword to the First Edition
• Preface
• Table of Contents
• Chapter 1: Fundamental Concepts
• Chapter 2: Scalar Data Types and Operations
• Chapter 3: Sequential Statements
• Chapter 4: Composite Data Types and Operations
• Chapter 5: Basic Modeling Constructs
• Chapter 6: Case Study: A Pipelined Multiplier Accumulator
• Chapter 7: Subprograms
• Chapter 8: Packages and Use Clauses
• Chapter 9: Aliases
• Chapter 10: Case Study: A Bit-Vector Arithmetic Package
• Chapter 11: Resolved Signals
• Chapter 12: Generic Constants
• Chapter 13: Components and Configurations
• Chapter 14: Generate Statements
• Chapter 15: Case Study: The DLX Computer System
• Chapter 16: Guards and Blocks
• Chapter 17: Access Types and Abstract Data Types
• Chapter 18: Files and Input/Output
• Chapter 19: Case Study: Queuing Networks
• Chapter 20: Attributes and Groups
• Chapter 21: Miscellaneous Topics
• A: Synthesis
• B: The Predefined Package Standard
• C: IEEE Standard Packages
• D: Related Standards
• E: VHDL Syntax
• F: Differences among VHDL-87, VHDL-93 and VHDL-2001
• G: Answers to Exercises
• References
• Index