Envisia HDL Modeling Reference
VHDL Modeling Style
Precedence Rules for Architecture Selection
When an entity has multiple architectures, the tool selects the architecture that will be used to synthesize the entity by evaluating the following rules in order:
1.The global variable hdl_vhdl_preferred_architecture overrides any VHDL entity-architecture binding rules.
For example, if the global is set
ac_shell[1]>set_global hdl_vhdl_preferred_architecture synth
If the entity, foo, has two architectures named sim and synth, the tool binds foo to entity synth. By default, hdl_vhdl_preferred_architecture is set to the null string ("").
2.If the entity is being synthesized in the context of an instantiation in a higher level entity, then any explicit architecture binding specified for that instantiation is used to determine the architecture that will be used to implement the current entity. Configuration specifications and component configurations (instances I2 and I8 respectively in
Component Instantiations and Bindings on page 83) can be used explicitly to specify the entity-architecture to which the instance is bound.
3.If the entity has a corresponding configuration declaration, the entity is bound to the architecture specified in the top-level block configuration of the configuration declaration. For example, the configuration BOTTOM_CONF in the example on Restrictions on Entities with Multiple Architectures on page 84 binds entity BOTTOM to architecture A1.
4.If none of the previous rules apply, the tool binds the entity to the most recently analyzed architecture (also known as the default architecture). For example, assume entity MRA has two architectures: A1 and A2. A1 is analyzed first followed by A2. The synthesis of entity MRA will use architecture A2.
It must be pointed out that once an entity has been synthesized, the only way to resynthesize it with a different architecture (perhaps by modifying a configuration declaration) is to reanalyze the entity and all its architectures. For the same reason, the global hdl_vhdl_preferred_architecture should only be set prior to any do_build_generic command.
VHDL-Related Commands and Globals
Table 3-5 provides the VHDL-related ac_shell commands. Table 3-6 provides the VHDLspecific ac_shell global variables used with the set_global command; the default values are shown in parentheses. Please see the Envisia and Ambit Command Reference for a complete list of commands and globals and their descriptions and examples.
September 2000 |
86 |
Product Version 4.0 |
Envisia HDL Modeling Reference
VHDL Modeling Style
Table 3-5 VHDL ac_shell Commands
Command |
Description |
|
|
read_vhdl |
Analyze VHDL source files. |
report_vhdl_library |
List mappings between all defined VHDL libraries and |
|
corresponding physical directories. |
reset_vhdl_library |
Delete all analyzed units from library. |
set_vhdl_library |
Define a new VHDL logical library and a directory to store |
|
the analyzed VHDL units. Also, associate WORK to another |
|
VHDL logical library. |
write_vhdl |
Write VHDL netlist. |
get_hdl_type |
For a given module, returns the file type, either verilog or |
|
VHDL. |
get_hdl_hierarchy |
Returns a hierarchical list of modules in the design and a list |
|
of their paramterized and non-parameterized instances. |
get_hdl_file |
Returns the file name corresponding to the module. |
get_hdl_top_level |
Returns a list of top level module names. |
|
|
Table 3-6 VHDL-Specific Global Variables
Command |
Description (Defaults) |
|
|
hdl_vhdl_case |
Case of VHDL symbols when files are analyzed using |
|
read_vhdl. (original) |
hdl_vhdl_environment |
Specifies the selection of the predefined arithmetic |
|
libraries. Choices are standard, synopsys, common, |
|
and synergy. (standard) |
hdl_vhdl_lrm_ |
When set to true, read_vhdl enforces a more strict |
compliance |
interpretation of the VHDL LRM. (fasle) |
hdl_vhdl_preferred_ |
Name of preferred architecture to use with an entity when |
architecture |
there are multiple architectures. (“ ”) |
hdl_vhdl_read_version |
VHDL version when files are analyzed using read_vhdl. |
|
(1993) |
September 2000 |
87 |
Product Version 4.0 |
Envisia HDL Modeling Reference
VHDL Modeling Style
Table 3-6 VHDL-Specific Global Variables, continued
Command |
Description (Defaults) |
|
|
hdl_vhdl_reuse_units |
Specify whether pre-analyzed units in VHDL libraries will |
|
be synthesized during do_build_generic (false). |
vdl_vhdl_write_ |
Specify whether to write VHDL architectures when |
architecture |
write_vhdl is called. (true) |
hdl_vhdl_write_ |
Name of the architecture for each entity in the netlist. |
architecture_name |
(netlist) |
hdl_vhdl_write_bit_ |
Define the bit type in which VHDL netlists will be written. |
type |
(std_logic) |
hdl_vhdl_write_ |
Specify whether component declarations for technology |
components |
cells are to be written in the VHDL netlists. (true) |
hdl_vhdl_write_entity |
Specify whether to write VHDL entities when |
|
write_vhdl is called. (true) |
hdl_vhdl_write_ |
Name for current entity to be used. If set to the empty |
entity_name |
string, “ “, then use current module name as the entity |
|
name. When writing out a hierarchical design, this |
|
variable only applies to the current module while all |
|
descendants use their own names. (“ “) |
hdl_vhdl_write_ |
Space separated list of package names for which |
packages |
library/ uses clauses must precede each entity |
|
during netlisting. For example: lib1.pack1 |
|
lib2.pack2. (ieee.std_logic_1164) |
hdl_vhdl_write_ |
VHDL version in which netlists will be written. (1993) |
version |
|
|
|
September 2000 |
88 |
Product Version 4.0 |
Envisia HDL Modeling Reference
4
Finite State Machine Structure and
Optimization
This chapter describes a Finite State Machine (FSM) and how it works with Ambit® BuildGates® synthesis. It also describes FSM optimization features, coding recommendations, and FSM verification.
This chapter contains the following information:
■Finite State Machine Overview on page 89
■BuildGates Synthesis and Finite State Machines on page 91
■FSM Optimization Features on page 92
■Verilog and VHDL FSM Directives on page 95
■Verification of Synthesized FSMs on page 104
Finite State Machine Overview
Figure 4-1 shows the general structure of a Finite State Machine (FSM). The current state of the machine is stored in the state memory, which is a set of flip-flops clocked by a single clock signal. The current state of the FSM is the value currently stored by the state memory. The next state of the machine, defined by the next state logic, is a function of the current state.
The Mealy outputs are a function of the state vector and the inputs, while Moore outputs are a function of the state vector only.
September 2000 |
89 |
Product Version 4.0 |
Envisia HDL Modeling Reference
Finite State Machine Structure and Optimization
Figure 4-1 State Machine Structure—Two Case Statements
inputs
NEXT |
|
STATE |
|
OUTPUT |
outputs |
|
STATE |
|
|
||||
LOGIC |
|
MEMORY |
|
LOGIC |
|
|
|
|
|
|
|||
|
|
|
|
|||
clock |
current state |
Figure 4-2 shows another way of organizing a state machine using only one logic block.
The logic in a state machine is described using a case statement or the equivalent (if-else). All possible combinations of current state and inputs are enumerated, and the appropriate values are specified for next state and the outputs.
A state machine may be coded as in Figure 4-1 using two separate case statements (for the next state and the output logic), or as in Figure 4-2, using only one. A single case statement may be preferred for Mealy machines where the outputs depend on the state transition rather than just the current state. Separate case statements are more suited for Moore machines where the outputs depend only on the current state.
Figure 4-2 State Machine Structure—One Case Statement
inputs |
outputs |
|
LOGIC |
|
STATE |
|
MEMORY |
|
clock |
|
current state |
September 2000 |
90 |
Product Version 4.0 |