- Shopping Bag ( 0 items )
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.
VDHL is the standard language for describing the structure and function of digital systems. This authoritative guide illustrates the importance of the VDHL-93 standard in designing high-speed digital systems. Requiring only a minimal background of Pascal or FORTRAN programming, this is an excellent tutorial for anyone in computer architecture, computer systems engineering and CAD.
...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...