| Student's Guide to VHDL 목차
|Table of Contents
1 Fundamental Concepts 1
2 Scalar Data Types and Operations 31
3 Sequential Statements 65
4 Composite Data Types and Operations 95
5 Basic Modeling Constructs 135
6 Subprograms 201
7 Packages and Use Clauses 239
8 Resolved Signals 261
9 Predefined and Standard Packages 287
10 Aliases 315
11 Generic Constants 325
12 Components and Configurations 335
13 Generate Statements 359
14 Design for Synthesis 375
15 Case Study: System Design Using the Gumnut Core 413
A Standard Packages 437
B VHDL Syntax 461
C Answers to Exercises 479
Read an Excerpt
From Chapter 7: Packages and Use Clauses
...Subprograms in Package Declarations
Another kind of declaration that may be included in a package declaration is a subprogram declaration—either a procedure or a function declaration. This ability allows us to write subprograms that implement useful operations and to call them from a number of different modules. An important use of this feature is to declare subprograms that operate on values of a type declared by the package. This gives us a way of conceptually extending VHDL with new types and operations, so-called abstract data types.
An important aspect of declaring a subprogram in a package declaration is that we only write the header of the subprogram, that is, the part that includes the name and the interface list defining the parameters (and result type for functions). We leave out the body of the subprogram. The reason for this is that the package declaration, as we mentioned earlier, provides only the external view of the items it declares, leaving the implementation of the items to the package body. For items such as types and signals, the complete definition is needed in the external view. However, for subprogram. As users of a subprogram, we need not be concerned with how it achieves its effect or calculates its result. This is an example of a general principle called information hiding: making an interface visible but hiding the details of implementation. To illustrate this idea, suppose we have a package declaration that defines a bit-vector subtype:
subtype word32 is bit_vector(31 downto 0);
We can include in the package a procedure to do addition onWord32 values that represent signed integers. The procedure declaration in the package declaration is:
procedure add ( a, b : in word32; result : out word32; overflow : out boolean );
Note that we do not include the keyword is or any of the local declarations or statements needed to perform the addition. These are deferred to the package body. All we include is the description of the formal parameters of the procedure. Similarly, we might include a function to perform an arithmetic comparison of two word32 values:
function "<" ( a, b : in word 32 ) return boolean;
Again, we omit the local declarations and statements, simply specifying the formal parameters and the result type of the function.
Constants in Package Declarations
Just as we can apply the principle of information hiding to subprograms declared in a package, we can also apply it to constants declared in a package. The external view of a constant is just its name and type. We need to know these in order to use it, but we do not actually need to know its value. This may seem strange at first, but if we recall that the idea of introducing constant declarations in the first place was to avoid scattering literal values throughout a model, it makes more sense. We defer specifying the value of a constant declared in a package by omitting the initialization expression, for example:
constant max_buffer_size : positive;
This defines the constant to be a positive integer value. However, since we cannot see the actual value, we are not tempted to write the value as an integer literal in a model that uses the package. The specification of the actual value is deferred to the package body; where it is not visible to a model that uses the package. Given the above deferred constant in a package declaration, the corresponding package body must include the full constant declaration, for example:
constant max_buffer_size : positive := 4096;
Note that we do not have to defer the value in a constant declaration—it is optional...
| 도서 상세설명
|From the Publisher
The Student's Guide to VHDL is a condensed edition of The Designer's Guide to VHDL, the most widely used textbook on VHDL for digital system modeling. The Student's Guide is targeted as a supplemental reference book for computer organization and digital design courses.
Since publication of the first edition of The Student's Guide, the IEEE VHDL and related standards have been revised. The Designer's Guide has been revised to reflect the changes, so it is appropriate that The Student's Guide also be revised.
In The Student's Guide to VHDL, 2nd Edition, we have included a design case study illustrating an FPGA-based design flow. The aim is to show how VHDL modeling fits into a design flow, starting from high-level design and proceeding through detailed design and verification, synthesis, FPGA place and route, and final timing verification. Inclusion of the case study helps to better serve the educational market. Currently, most college courses do not formally address the details of design flow. Students may be given informal guidance on how to proceed with lab projects. In many cases, it is left to students to work it out for themselves. The case study in The Student's Guide provides a reference design flow that can be adapted to a variety of lab projects.
Written for engineering students, this introduction to VHDL (a language for describing digital electronic systems for the pre- manufacturing design of hardware systems) covers such topics as scalar data types, sequential statements, composite data types, modeling constructs, subprograms, packages and use clauses, resolved signals, generic constants, and components and configurations. Annotation c. by Book News, Inc., Portland, Or.
| 교육용 보조자료