- •About This Manual
- •Additional Resources
- •Manual Contents
- •Conventions
- •Typographical
- •Online Document
- •Using Foundation Express with VHDL
- •Hardware Description Languages
- •Typical Uses for HDLs
- •Advantages of HDLs
- •About VHDL
- •Foundation Express Design Process
- •Using Foundation Express to Compile a VHDL Design
- •Design Methodology
- •Design Descriptions
- •Entities
- •Entity Generic Specifications
- •Entity Port Specifications
- •Architecture
- •Declarations
- •Components
- •Concurrent Statements
- •Constant Declarations
- •Processes
- •Signal Declarations
- •Subprograms
- •Type Declarations
- •Examples of Architectures for NAND2 Entity
- •Configurations
- •Packages
- •Using a Package
- •Package Structure
- •Package Declarations
- •Package Body
- •Resolution Functions
- •Data Types
- •Type Overview
- •Enumeration Types
- •Enumeration Overloading
- •Enumeration Encoding
- •Enumeration Encoding Values
- •Integer Types
- •Array Types
- •Constrained Array
- •Unconstrained Array
- •Array Attributes
- •Record Types
- •Record Aggregates
- •Predefined VHDL Data Types
- •Data Type BOOLEAN
- •Data Type BIT
- •Data Type CHARACTER
- •Data Type INTEGER
- •Data Type NATURAL
- •Data Type POSITIVE
- •Data Type STRING
- •Data Type BIT_VECTOR
- •Unsupported Data Types
- •Physical Types
- •Floating-Point Types
- •Access Types
- •File Types
- •Express Data Types
- •Subtypes
- •Expressions
- •Overview
- •Operators
- •Logical Operators
- •Relational Operators
- •Adding Operators
- •Unary (Signed) Operators
- •Multiplying Operators
- •Miscellaneous Arithmetic Operators
- •Operands
- •Operand Bit-Width
- •Computable Operands
- •Aggregates
- •Attributes
- •Expressions
- •Function Calls
- •Identifiers
- •Indexed Names
- •Literals
- •Numeric Literals
- •Character Literals
- •Enumeration Literals
- •String Literals
- •Qualified Expressions
- •Records and Fields
- •Slice Names
- •Limitations on Null Slices
- •Limitations on Noncomputable Slices
- •Type Conversions
- •Sequential Statements
- •Assignment Statements and Targets
- •Simple Name Targets
- •Indexed Name Targets
- •Slice Targets
- •Field Targets
- •Aggregate Targets
- •Variable Assignment Statements
- •Signal Assignment Statements
- •Variable Assignment
- •Signal Assignment
- •if Statements
- •Evaluating Conditions
- •Using the if Statement to Infer Registers and Latches
- •case Statements
- •Using Different Expression Types
- •Invalid case Statements
- •loop Statements
- •Basic loop Statement
- •while...loop Statements
- •for...loop Statements
- •Steps in the Execution of a for...loop Statement
- •for...loop Statements and Arrays
- •next Statements
- •exit Statements
- •Subprograms
- •Subprogram Always a Combinatorial Circuit
- •Subprogram Declaration and Body
- •Subprogram Calls
- •Procedure Calls
- •Function Calls
- •return Statements
- •Procedures and Functions as Design Components
- •Example with Component Implication Directives
- •Example without Component Implication Directives
- •wait Statements
- •Inferring Synchronous Logic
- •Combinatorial Versus Sequential Processes
- •null Statements
- •Concurrent Statements
- •Overview
- •process Statements
- •Combinatorial Process Example
- •Sequential Process Example
- •Driving Signals
- •block Statements
- •Nested Blocks
- •Guarded Blocks
- •Concurrent Versions of Sequential Statements
- •Concurrent Procedure Calls
- •Concurrent Signal Assignments
- •Simple Concurrent Signal Assignments
- •Conditional Signal Assignments
- •Selected Signal Assignments
- •Component Instantiation Statements
- •Direct Instantiation
- •generate Statements
- •for...generate Statements
- •Steps in the Execution of a for...generate Statement
- •Common Usage of a for...generate Statement
- •if...generate Statements
- •Register and Three-State Inference
- •Register Inference
- •The Inference Report
- •Latch Inference Warnings
- •Controlling Register Inference
- •Inferring Latches
- •Inferring Set/Reset (SR) Latches
- •Inferring D Latches
- •Inferring Master-Slave Latches
- •Inferring Flip-Flops
- •Inferring D Flip-Flops
- •Inferring JK Flip-Flops
- •Inferring Toggle Flip-Flops
- •Getting the Best Results
- •Understanding Limitations of Register Inference
- •Three-State Inference
- •Reporting Three-State Inference
- •Controlling Three-State Inference
- •Inferring Three-State Drivers
- •Inferring a Simple Three-State Driver
- •Three-State Driver with Registered Enable
- •Three-State Driver Without Registered Enable
- •Writing Circuit Descriptions
- •How Statements Are Mapped to Logic
- •Design Structure
- •Adding Structure
- •Using Variables and Signals
- •Using Parentheses
- •Using Design Knowledge
- •Optimizing Arithmetic Expressions
- •Arranging Expression Trees for Minimum Delay
- •Sharing Common Subexpressions
- •Changing an Operator Bit-Width
- •Using State Information
- •Propagating Constants
- •Sharing Complex Operators
- •Asynchronous Designs
- •Don’t Care Inference
- •Using Don’t Care Default Values
- •Differences Between Simulation and Synthesis
- •Synthesis Issues
- •Feedback Paths and Latches
- •Fully Specified Variables
- •Asynchronous Behavior
- •Understanding Superset Issues and Error Checking
- •Foundation Express Directives
- •Notation for Foundation Express Directives
- •Foundation Express Directives
- •Translation Stop and Start Pragma Directives
- •synthesis_off and synthesis_on Directives
- •Resolution Function Directives
- •Component Implication Directives
- •Foundation Express Packages
- •std_logic_1164 Package
- •std_logic_arith Package
- •Using the Package
- •Modifying the Package
- •Data Types
- •UNSIGNED
- •SIGNED
- •Conversion Functions
- •Arithmetic Functions
- •Example 10-1: Binary Arithmetic Functions
- •Example 10-2: Unary Arithmetic Functions
- •Comparison Functions
- •Example 10-3: Ordering Functions
- •Example 10-4: Equality Functions
- •Shift Functions
- •ENUM_ENCODING Attribute
- •pragma built_in
- •Type Conversion
- •numeric_std Package
- •Understanding the Limitations of numeric_std package
- •Using the Package
- •Data Types
- •Conversion Functions
- •Resize Function
- •Arithmetic Functions
- •Comparison Functions
- •Defining Logical Operators Functions
- •Shift Functions
- •Rotate Functions
- •Shift and Rotate Operators
- •std_logic_misc Package
- •ATTRIBUTES Package
- •VHDL Constructs
- •VHDL Construct Support
- •Design Units
- •Data Types
- •Declarations
- •Specifications
- •Names
- •Identifiers and Extended Identifiers
- •Specifics of Identifiers
- •Specifics of Extended Identifiers
- •Operators
- •Shift and Rotate Operators
- •xnor Operator
- •Operands and Expressions
- •Sequential Statements
- •Concurrent Statements
- •Predefined Language Environment
- •VHDL Reserved Words
- •Examples
- •Moore Machine
- •Mealy Machine
- •Read-Only Memory
- •Waveform Generator
- •Smart Waveform Generator
- •Definable-Width Adder-Subtracter
- •Count Zeros—Combinatorial Version
- •Count Zeros—Sequential Version
- •Soft Drink Machine—State Machine Version
- •Soft Drink Machine—Count Nickels Version
- •Carry-Lookahead Adder
- •Carry Value Computations
- •Implementation
- •Serial-to-Parallel Converter—Counting Bits
- •Input Format
- •Implementation Details
- •Serial-to-Parallel Converter—Shifting Bits
- •Programmable Logic Arrays
VHDL Reference Guide
Type Overview
The advantage of strong typing is that VHDL tools can detect many common design errors, such as assigning an 8-bit value to a 4-bit-wide signal or incrementing an array index out of its range.
The following example code shows the definition of a new type, BYTE, as an array of 8 bits, and a variable declaration, ADDEND, that uses this type.
type BYTE is array(7 downto 0) of BIT; variable ADDEND: BYTE;
The predefined VHDL data types are built from the basic VHDL data types. Some VHDL types are not supported for synthesis, such as REAL and FILE.
The examples in this chapter show type definitions and associated object declarations. Although each constant, signal, variable, function, and parameter is declared with a type, only variable and signal declarations are shown in this chapter’s examples. Constant, function, and parameter declarations are shown in the “Declarations” section of the “Design Descriptions” chapter.
VHDL also provides subtypes, which are defined as subsets of other types. Anywhere a type definition can appear, a subtype definition can also appear. The difference between a type and a subtype is that a subtype is a subset of a previously defined parent (or base) type or subtype. Overlapping subtypes of a given base type can be compared against and assigned to each other. All integer types, for example, are technically subtypes of the built-in integer base type (see the “Integer Types” section and “Subtypes” section of this chapter).
Enumeration Types
You define an enumeration type by listing (enumerating) all possible values of that type.
The syntax of an enumeration type definition follows.
type type_name is ( enumeration_literal {, enumeration_literal} );
•type_name is an identifier
•Each enumeration_literal is either an identifier (enum_6) or a character literal (’A’).
3-2 |
Xilinx Development System |
Data Types
•An identifier is a sequence of letters, underscores, and numbers. An identifier must start with a letter and cannot be a VHDL reserved word, such as TYPE. All VHDL reserved words are listed in the “VHDL Construct Support” section of the “VHDL Constructs” chapter.
A character literal is any value of type CHARACTER, in single quotes.
The following example shows two enumeration type definitions and the corresponding variable and signal declarations.
type COLOR is (BLUE, GREEN, YELLOW, RED); type MY_LOGIC is (’0’, ’1’, ’U’, ’Z’); variable HUE: COLOR;
signal SIG: MY_LOGIC;
. . .
HUE := BLUE;
SIG <= ’Z’;
Enumeration Overloading
You can overload an enumeration literal by including it in the definition of two or more enumeration types. When you use such an overloaded enumeration literal, Foundation Express can usually determine the literal’s type. However, under certain circumstances, determination may be impossible. In these cases, you must qualify the literal by explicitly stating its type. (See the “Enumeration Literals” section of the “Expressions” chapter.) The following example shows how you can qualify an overloaded enumeration literal.
type COLOR is (RED, GREEN, YELLOW, BLUE, VIOLET); type PRIMARY_COLOR is (RED, YELLOW, BLUE);
...
A <= COLOR’(RED);
Enumeration Encoding
Enumeration types are ordered by enumeration value. By default, the first enumeration literal is assigned the value 0, the next enumeration literal is assigned the value 1, and so forth.
Foundation Express automatically encodes enumeration values into bit vectors that are based on each value’s position. The length of the
VHDL Reference Guide |
3-3 |
VHDL Reference Guide
encoding bit vector is the minimum number of bits required to encode the number of enumerated values. For example, an enumeration type with five values has a 3-bit encoding vector.
The following example shows the default encoding of an enumeration type with five values.
type COLOR is (RED, GREEN, YELLOW, BLUE, VIOLET);
The enumeration values are encoded as follows.
RED |
= “000” |
|
GREEN |
= “001” |
|
YELLOW |
= |
“010” |
BLUE |
= |
“011” |
VIOLET = “100”
The result is RED < GREEN < YELLOW < BLUE < VIOLET.
You can override the automatic enumeration encodings and specify your own enumeration encodings with the ENUM_ENCODING attribute. The interpretation of the ENUM_ENCODING attribute is specific to Foundation Express.
Several VHDL synthesis-related attributes are declared in the ATTRIBUTES package supplied with Foundation Express. For more information about this package, see the “ATTRIBUTES Package” section of the “Foundation Express Packages” chapter.
A VHDL attribute is defined by its name and type and is then declared with a value for the attributed type, as shown in the example below.
The ENUM_ENCODING attribute must be a STRING containing a series of vectors, one for each enumeration literal in the associated type. The encoding vector is specified by 0s, 1s, Ds, Us, and Zs separated by blank spaces. The meaning of these encoding vectors is described in the “Enumeration Encoding Values” section of this chapter.
The first vector in the attribute string specifies the encoding for the first enumeration literal. The second vector specifies the encoding for the second enumeration literal, and so on. The ENUM_ENCODING attribute must immediately follow the type declaration.
The following example illustrates how the default encodings from the previous example can be changed with the ENUM_ENCODING attribute.
3-4 |
Xilinx Development System |
Data Types
attribute ENUM_ENCODING: STRING; -- Attribute definition
type COLOR is (RED, GREEN, YELLOW, BLUE, VIOLET); attribute ENUM_ENCODING of
COLOR: type is "010 000 011 100 001"; -- Attribute declaration
The enumeration values are encoded as follows.
RED |
= "010" |
|
GREEN |
= "000" |
|
YELLOW |
= |
"011" |
BLUE |
= |
"100" |
VIOLET = "001"
The result is GREEN<VIOLET<RED<YELLOW<BLUE.
Note: The interpretation of the ENUM_ENCODING attribute is specific to Foundation Express. Other VHDL tools, such as simulators, use the standard encoding (ordering).
Enumeration Encoding Values
The possible encoding values for the ENUM_ENCODING attribute follow.
•‘0’—bit value ‘0’
•‘1’—bit value ‘1’
•‘D’—don’t-care (can be either ‘0’ or ‘1’)
To use don’t care information, see the “Don’t Care Inference” section of the “Writing Circuit Descriptions” chapter
•‘U’—unknown
If ‘U’ appears in the encoding vector for an enumeration, you cannot use that enumeration literal except as an operand to the = and /= operators. You can read an enumeration literal encoded with a ‘U’ from a variable or signal, but you cannot assign it.
For synthesis, the = operator returns FALSE and the /= operator returns TRUE when either of the operands is an enumeration literal whose encoding contains ‘U.’
•‘Z’—high impedance
VHDL Reference Guide |
3-5 |
