Overview of VHDL

Modeling Space

Behavioral, dataflow, structural   

Simple types and objects

integer, character, bit, boolean, reals

 signals and variables

User defined types and objects are developed based upon these primitive types and classes of objects.

Designs are built using Entities and Architectures. 

Hierarchical design structure is supported with entities and architectures.

Packages and package bodies provide encapsulation of data structures and information abstraction.

Libraries and USE statements are needed to use packages. Entities and architectures are typically organized into libraries.

Primitive Data Types: Their meaning and uses

type integer is range -(2**31-1) to 2**31-1 (at least)  

Objects of type integer have to be converted into bit_vectors or std_logic_vectors of sufficient width to handle the range of values declared. An object of type integer will by default be converted into a 32 bit vector unless it has been constrained to a smaller range of values. 

         type bit is ('0','1');

However, because bit does not give a representation for X and Z, multiple valued logics are generally preferred for modeling and simulation. IEEE Standard 1164 has been defined for this purpose, and is discussed in more detail below.

 

         type boolean is (false, true);

 

Objects of type boolean, bit, std_logic usually translate into outputs of gates, latches, or flipflops.
 

to provide textual information to designer-users through design tool windows to the model


 

to create models which work with textual data and communication / control symbols


 
Although signal of type character translate naturally into 8-bit vectors, in most cases no physical implementation is called for (the second case above.)

         type character is the set of ASCII symbols

Although in concept it is possible to predefine the signals needed to implement the IEEE standard for floating point, and to create a library of implementations for floating point arithmetic operators, the size and complexity of these operators suggests that we insert them directly into a design at a high level without running them through a synthesis tool. Their speed demands more optimization than synthesis will be able to provide, and their design will have a major impact on floorplanning.

The VHDL language designers almost did include reals because it was felt they represented an inappropriate level of modeling for digital design.

They were included to support expression evaluation of physical, measured values and the intent to allow inclusion of attributes from the "physical" axis of design modeling.

Physical types have units associated with them, and values of physical objects must always be expressed in terms of those units.

constant Tenio_lz : TIME  := Tenio_plz + (Tio_clh * (io_cap));

Timing is important for simulation purposes, but is frequently ignored during synthesis. Instead the synthesis tool seeks to minimize delays and once the implementation is generated, a back annotator supplies predicted timing values for the model. Consequently, good VHDL models should use named constants everywhere so that the back annotator can generate a table of values in a configuration body or package rather than requiring text substitution through an entire collection of source modules.

Primitive Objects in VHDL

 Signals are used to establish connectivity and pass values between concurrently active design elements. A value for a signal is computed and added to a waveform for future application.

Examples of Object Declarations

        constant  Reg_size:  integer := 16;
        constant  Tprop:  time  := 15 ns;
        signal  preset, clear:  bit;
        signal  CS1:  bit;
        variable  i_slice:  integer range 0 to Reg_size-1;

-- All text on a line to the right of the double hyphen is a comment. 
-- In the cases above a constant object named Reg_size 
-- is declared to be of type integer and set to a value of 16
-- Signal objects named preset, clear,  and CS1 all are
-- declared to be of type bit.   Variable object i_slice will be
-- allowed only to take on values between 0 and 15.

User Defined Types

type identifier is type_definition

Example

 type ctl_states is (halt, wait, ack, int, exec ) ;

Type declarations do not occur frequently in architecture bodies. They usually should appear in a package declaration used by the architecture and invoked in a USE statement.

 An important example of a user defined type is std_ulogic which is more frequently used for modeling bits than type bit

PACKAGE std_logic_INC IS
------------------------------------------------------------------    
-- logic state system  (unresolved)
    TYPE std_ulogic IS ( 'U',  -- Uninitialized
                         'X',  -- Forcing  Unknown
                         '0',  -- Forcing  0
                         '1',  -- Forcing  1
                         'Z',  -- High Impedance   
                         'W',  -- Weak     Unknown
                         'L',  -- Weak     0       
                         'H',  -- Weak     1       
                         '-'     -- Don't care   );

User Defined Objects

signal ident : subtype_definition := constant_expression ;
 
The most common subtype_definition here is a simple type or subtype identifier . An initial value is defined by := constant_expression, and is optional.

 Example

signal  ready, request, MRQ :  std_logic ;
-- where std_logic is a multiple valued logic bit.

constant identifier : type_id := constant_expression ;
 
Constant expressions may consist of logical and arithmetic operations on other constant identifiers and values passed in through generics.

 Example  

constant  Tio_clh : TIME  :=  0.1 ns;

Time is a standard, pre-defined physical type. Physical types have units associated with them, and values of physical objects must always be expressed in terms of those units. 

constant Tenio_lz : TIME  := Tenio_plz + (Tio_clh * (io_cap));

This example used previously defined constants Tenio_plz and Tio_clh, and a generic parameter io_cap.

Entities and Architectures

Entities describe the interface (the black box view)

Architectures describe the implementation inside.

Entity Declaration Example:

entity  acia    is
        generic
(       slot_id  :  in  bit_vector ( 0 to 2 ));
        port
        (       -- System side
                data :  inout bit_vector (7 downto 0);
                addrs :  out bit_vector (7 downto 0);
                irq  :          out bit;
                bus_busy:       inout bit;
                bus_req:        out bit;
                data_valid:     inout bit;

                -- Asynchronous side
                xmit :          out bit;
                recv :          in bit;
                r_strobe:       in bit;
                async_clk:      in bit;
        );
end acia  ;

Ports and Generics

Generics 

Pass information from its environment into the design unit which is NOT time-varying.


 

Very useful for creating and using generalized designs.

 

 Examples:

modulus for a mod-N counter

desired width of an N-bit ALU

T_high for a one-shot

Ports

Pass information through the interface which is time-varying.


 

Ports are signal objects (connected together by signals) which are used to pass values between concurrently active units.

Interface Modes -- represent direction of value flow

In entities, components, and blocks the modes may be:

IN

within the design unit (both entity and body) the value may be read, but not written.

OUT

within the design unit (both entity and body) the value may be written, but not read.

INOUT

within the design unit (both entity and body) the value may be both read and written.

BUFFER

is identical to INOUT, except that it may be driven by only one source -- either externally or internally.


 

LINKAGE

used primarily to specify connections which are not being used in the current model.

Architectures

The body of a design lies within an architecture. An architecture may present one of several alternative views of a design, or present one of several possible implementations of a design specification.

architecture identifier of entity_identifier is

-- local declarations, typically signals
begin

 

-- concurrent statements
end identifier ;

 

Simple Architecture Example



entity  XOR  
port  ( a,  b :  in bit;  z : out bit );
end;

architecture  nand_gates  of  XOR  is
        signal  s0, s1, s2:     bit;
begin
        s0 <= a nand b;
        s1 <= a nand s0;
        s2 <= b nand s0;
        z <=  s1 nand s2;
end  nand_gates;

Different ARCHITECTURES of the same design ENTITY may present


 

• different design views (e.g. behavior, structure)

 
• different designs used to realize same function

 
• different technologies / performance characteristics

 



Hierarchical Design

Top Down, Bottom Up, and Middle Out Strategies For Structural and Dataflow Design Are All Supported.
 
• Bottom Up Strategy 
• create low level and auxiliary models first, entity and architecture 
• -- once low level entities are present, they can be used as components in the next higher level architectural body.
• Top Down Strategy:
• -- create highest level entity and architecture first, creating only the interface definitions (entity declarations) for lower level architectures

 Note: To compile a VHDL architectural body, the entity declaration indicated in the configuration specification must be available in the work library, but this is not required for the architectural bodies.
 

• Middle Out Strategy
• The VHDL features required to work from the middle UP are the same as those provided to support bottom up design . 
• The VHDL features required to work from the middle DOWN are the same as those provided to support top down design .

 

    (Top down, bottom up, and middle out strategies for Procedural design are also supported by allowing subprogram declarations to be separated from the subprogram bodies.)

Example of a series of entity declarations

library asic;
use asic.c_measure, asic.strength_logic;

entity nand2 is generic (ycap : capacitance)
        port (a0,a1 : in iSig; y : out iSig )
        end nand2;

entity nand4 is generic (ycap : capacitance)
        port (a0,a1,a2,a3 : in iSig; y : out iSig)
        end nand6;

entity nor2  is generic (ycap : capacitance)
        port (a0,a1 : in iSig; y : out iSig )
        end nor2;

entity nor4 is  generic (ycap : capacitance)
        port (a0,a1,a2,a3 : in iSig; y : out iSig)
        end nor6;

entity buf is   generic (ycap : capacitance)
        port (a0 : in iSig; y : out iSig )
        end buf;

entity ipad is  generic (ycap : capacitance)
        port (a0 : in iSig; y : out iSig )
        end ipad;

entity opad is  generic (ycap : capacitance)
        port (a0 : in iSig; y : out iSig )
        end opad;

entity invert is        generic (ycap : capacitance)
        port (a0 : in iSig; y : out iSig )
        end invert;

entity aoi2x2 is        generic (ycap: capacitance)
        port  (a0,a1,b0,b1 : in iSig; y : out iSig)
        end aoi2x2;

Packages

• Support modular design by encapsulating Data Abstractions:

• type and subtype declarations

 for example:  

• multi-valued logic to handle X, Z 
• arrays of multi-valued logic to serve as memory words or buses 
• records collecting several types for high level design to represent such things as instruction sets

 
• operators on types of data objects

 for example:  

• AND, OR, NOT for multivalued logic 
• WIRED-AND or WIRED-OR behavior of buses 
• type conversion functions like Bit_to_Integer

 
• -- holding collections of functions and procedures

 

• Consist of two parts: Declaration and Body

 

Package Declarations (the interface)

contain the information required by design units (e.g. entities and architectures which use the data abstractions and subprograms contained in the package


 

Package Bodies

contain the executable parts of the functions and procedures. This part can be compiled separately and hides unnecessary detail from the users view, including internal, local data types and structures.

• Are provided by

• Standards bodies (like IEEE)  - Implementation of standards
• Vendors  -  Sometimes tool specific
• Corporate CAD groups  -  Supporting corporate standards
• Design groups
• Project specific, shared functions, data
 

Example of a package implementing a standard

PACKAGE std_logic_INC IS
------------------------------------------------------------------    
-- logic state system  (unresolved)
    TYPE std_ulogic IS ( 'U',  -- Uninitialized
                         'X',  -- Forcing  Unknown
                         '0',  -- Forcing  0
                         '1',  -- Forcing  1
                         'Z',  -- High Impedance   
                         'W',  -- Weak     Unknown
                         'L',  -- Weak     0       
                         'H',  -- Weak     1       
                         '-'     -- Don't care   );
------------------------------------------------------------------    
-- unconstrained array of std_ulogic for use with resolution function
    TYPE std_ulogic_vector IS ARRAY ( NATURAL RANGE <> ) OF std_ulogic;
-------------------------------------------------------------------
-- common subtypes
    SUBTYPE X01     IS resolved std_ulogic RANGE 'X' TO '1'; 
    SUBTYPE X01Z    IS resolved std_ulogic RANGE 'X' TO 'Z'; 
    SUBTYPE UX01    IS resolved std_ulogic RANGE 'U' TO '1';
-------------------------------------------------------------------    
-- overloaded logical operators
    FUNCTION "and"  ( l : std_ulogic; r : std_ulogic ) RETURN UX01;
    FUNCTION "nand" ( l : std_ulogic; r : std_ulogic ) RETURN UX01;
    FUNCTION "or"   ( l : std_ulogic; r : std_ulogic ) RETURN UX01;
    FUNCTION "nor"  ( l : std_ulogic; r : std_ulogic ) RETURN UX01;
    FUNCTION "xor"  ( l : std_ulogic; r : std_ulogic ) RETURN UX01;
    FUNCTION "not"  ( l : std_ulogic                 ) RETURN UX01;
    
-------------------------------------------------------------------
-- vectorized overloaded logical operators
    FUNCTION "and"  ( l, r : std_ulogic_vector ) RETURN std_ulogic_vector;
    FUNCTION "nand" ( l, r : std_ulogic_vector ) RETURN std_ulogic_vector;
    FUNCTION "or"   ( l, r : std_ulogic_vector ) RETURN std_ulogic_vector;
    FUNCTION "nor"  ( l, r : std_ulogic_vector ) RETURN std_ulogic_vector;
    FUNCTION "xor"  ( l, r : std_ulogic_vector ) RETURN std_ulogic_vector;
    FUNCTION "not"  ( l : std_ulogic_vector ) RETURN std_ulogic_vector;
-------------------------------------------------------------------
-- conversion functions
    FUNCTION To_bit    ( s : std_ulogic; xmap : BIT := '0') RETURN BIT;
    FUNCTION To_bitvector ( s : std_ulogic_vector; xmap : BIT := '0') 
                                                           RETURN BIT_VECTOR;
    FUNCTION To_StdULogic       ( b : BIT ) RETURN std_ulogic;
    FUNCTION To_StdULogicVector ( b : BIT_VECTOR ) 
                                                        RETURN std_ulogic_vector;
-------------------------------------------------------------------
-- strength strippers and type convertors
    FUNCTION To_X01  ( s : std_ulogic_vector ) RETURN  std_ulogic_vector;
    FUNCTION To_X01  ( s : std_ulogic        ) RETURN  X01;
                        .
                        .
                        .
    FUNCTION To_UX01  ( b : BIT_VECTOR  ) RETURN  std_ulogic_vector;
    FUNCTION To_UX01  ( b : BIT ) RETURN  UX01;       
-------------------------------------------------------------------
-- edge detection
    FUNCTION rising_edge  (SIGNAL s : std_ulogic)  RETURN BOOLEAN;
    FUNCTION falling_edge (SIGNAL s : std_ulogic)  RETURN BOOLEAN;
-------------------------------------------------------------------
-- object contains an unknown
    FUNCTION Is_X ( s : std_ulogic_vector ) RETURN  BOOLEAN;
    FUNCTION Is_X ( s : std_ulogic        ) RETURN  BOOLEAN;

END std_logic_1164;

PACKAGE BODY std_logic_1164 IS
    -------------------------------------------------------------------
    -- local types
    -------------------------------------------------------------------
    TYPE stdlogic_1d IS ARRAY (std_ulogic) OF std_ulogic;
    TYPE stdlogic_table IS ARRAY(std_ulogic, std_ulogic) OF std_ulogic;

    -------------------------------------------------------------------
    -- resolution function
    -------------------------------------------------------------------
    CONSTANT resolution_table : stdlogic_table := (
    -----------------------------------------------------------
    --      |  U    X    0    1    Z    W    L    H    -        |   |
    -----------------------------------------------------------
            ( 'U', 'U', 'U', 'U', 'U', 'U', 'U', 'U', 'U' ), -- | U |
            ( 'U', 'X', 'X', 'X', 'X', 'X', 'X', 'X', 'X' ), -- | X |
            ( 'U', 'X', '0', 'X', '0', '0', '0', '0', 'X' ), -- | 0 |
            ( 'U', 'X', 'X', '1', '1', '1', '1', '1', 'X' ), -- | 1 |
            ( 'U', 'X', '0', '1', 'Z', 'W', 'L', 'H', 'X' ), -- | Z |
            ( 'U', 'X', '0', '1', 'W', 'W', 'W', 'W', 'X' ), -- | W |
            ( 'U', 'X', '0', '1', 'L', 'W', 'L', 'W', 'X' ), -- | L |
            ( 'U', 'X', '0', '1', 'H', 'W', 'W', 'H', 'X' ), -- | H |
            ( 'U', 'X', 'X', 'X', 'X', 'X', 'X', 'X', 'X' )  -- | - |
        );
        
    FUNCTION resolved ( s : std_ulogic_vector ) RETURN std_ulogic IS
        VARIABLE result : std_ulogic := 'Z';  -- weakest state default
    BEGIN
        -- the test for a single driver is essential otherwise the
        -- loop would return 'X' for a single driver of '-' and that
        -- would conflict with the value of a single driver unresolved
        -- signal.
        IF    (s'LENGTH = 1) THEN    RETURN s(s'LOW);
        ELSE
            FOR i IN s'RANGE LOOP
                result := resolution_table(result, s(i));
            END LOOP;
        END IF;
        RETURN result;
    END resolved;

    -------------------------------------------------------------------
    -- tables for logical operations
    -------------------------------------------------------------------

    -- truth table for "and" function
    CONSTANT and_table : stdlogic_table := (
    ------------------------------------------------------
    --      |  U    X    0    1    Z    W    L    H    -         |   |
    ------------------------------------------------------
            ( 'U', 'U', '0', 'U', 'U', 'U', '0', 'U', 'U' ),  -- | U |
            ( 'U', 'X', '0', 'X', 'X', 'X', '0', 'X', 'X' ),  -- | X |
            ( '0', '0', '0', '0', '0', '0', '0', '0', '0' ),  -- | 0 |
            ( 'U', 'X', '0', '1', 'X', 'X', '0', '1', 'X' ),  -- | 1 |

LIBRARY and USE Statements

There are two special libraries explicitly prescribed by VHDL:

STD    -  whose contents are predefined by the VHDL language. It contains


 

package STANDARD

with type declarations for bit, bit_vector, boolean, character, string, severity_leveel, integer, real, natural, positive, time, and the function NOW.

package TEXTIO

with subprograms and types to support file input and output.


 

The contents of STANDARD and TEXTIO are available for use within all designs without explicit USE statements.

WORK

which denotes the current working library during VHDL model analysis.


 

It is typically selected either by a command to the VHDL analyzer, or a directory selection at the system level. Therefore, it can be a private library, or shared between several users.

Since the members of the WORK library are whatever people have put into it, references to those packages, entities, and architectures must be named by a USE statement before the analyzer will be able to recognize them.

 

LIBRARY Statements

library logical_name(s) ;

While VHDL does not prescribe how to create libraries, it does assume that libraries of designs will be created, and that a means is needed to explicitly describe where designs are to be found -- either to import declarations, or to select between collections of entities and architectures. 

Examples:

 



Within a VHDL description one may specify LOGICAL library names, which then can be used as part of an extended naming scheme.

The logical name can then be associated with a file name at the system level when the tool is invoked.

 

USE Statements

explicitly provides a naming "scope," somewhat like the "WITH" statement in Pascal.

Forms:
 

library_name.package_name.ALL     -  even if the library_name is WORK
 package_name.object         - requires that the package be defined in the same file
 library_name.package_name.object
 
Examples:

library ASIC;
use ASIC.gate_array.all;

makes visible all the declarations in the package gate_array in my private library named ASIC. Note that the library must be named before it can appear in a USE statement.

library WORK, STD;
use STD.STANDARD.all;

explicitly do what already happens automatically.

use work.my_pkg.all;

If a package has been placed in the WORK library, it must still be explicitly declared in a USE statement to be known by the VHDL compiler.

Rev. 1/29/98 B. Huey