copyright 1997 rassp e&f 1 vhdl synthesis module 60 rassp education & facilitation program...

123
Copyright 1997 RASSP E&F 1 VHDL Synthesis Module 60 RASSP Education & Facilitation Program M60_01_00 February 1998 Copyright 1998 RASSP E&F All rights reserved. This information is copyrighted by the RASSP E&F Program and may only be used for non-commercial educational purposes. Any other use of this information without the express written permission of the RASSP E&F Program is prohibited. All information contained herein may be duplicated for non-commercial educational use provided this copyright notice is included. No warranty of any kind is provided or implied, nor is any liability accepted regardless of use. FEEDBACK: The RASSP E&F Program welcomes and encourages any feedback that you may have including any changes that you may make to improve or update the material. You can contact us at [email protected] or http://rassp.scra.org/module-request/FEEDBACK/feedback-on-modules.html

Upload: chester-johnson

Post on 01-Jan-2016

218 views

Category:

Documents


0 download

TRANSCRIPT

Test Technology Overview Module*
Copyright ã 1998 RASSP E&F
All rights reserved. This information is copyrighted by the RASSP E&F Program and may only be used for non-commercial educational purposes. Any other use of this information without the express written permission of the RASSP E&F Program is prohibited. All information contained herein may be duplicated for non-commercial educational use provided this copyright notice is included. No warranty of any kind is provided or implied, nor is any liability accepted regardless of use.
FEEDBACK:
The RASSP E&F Program welcomes and encourages any feedback that you may have including any changes that you may make to improve or update the material. You can contact us at [email protected] or
http://rassp.scra.org/module-request/FEEDBACK/feedback-on-modules.html
*
Primarily
software
Primarily
hardware
CO-DESIGN
Obviously, VHDL synthesis is used mainly in the hardware design process. However, if synthesis is planned to be used in the hardware design process, then models that are developed in the functional design and hardware/software codesign process should be generated with the later use of synthesis in mind. Also, synthesis techniques and tools are being developed to support the automation of the upper levels in the design process.
Copyright ã 1997 RASSP E&F
*
Algorithmic
RTL
Logic
Combinational logic synthesis
Sequential logic synthesis
RTL level synthesis
The goal of this module is to teach VHDL synthesis to the digital designer. The major emphasis of this module will be on VHDL syntax for the lower levels of synthesis, namely, logic and RTl level synthesis. In order to put this in context, background on the synthesis process and levels of synthesis will be presented.
Copyright ã 1997 RASSP E&F
*
Types
Attributes
After clauses
Inferring latches
*
Level sensitive sequential logic
Edge sensitive sequential logic
Structural VHDL
*
Structural VHDL
*
Hardware Synthesis
Hardware Synthesis is the process of mapping an input specification for a hardware design into a hardware implementation
The input specification contains the behavioral information - what functions the final implementations is to perform,
The input specification DOES NOT specify how the functions are to be performed
[Parker84]
This is the traditional definition of hardware synthesis. This definition and the accompanying slides are from a tutorial paper in IEEE Design and Tes of Computer by Alice Parker, a noted researcher in hardware synthesis. Although the paper is from 1984, the definitions are still in line with what is commonly used.
Copyright ã 1997 RASSP E&F
*
Abstract behavior
The operation of a digital hardware module in terms of reads and writes of variables to and from the outside world, the conditions on the reads and writes, the values of the output variables, and their partial orderings
Control-flow behavior
The operation of a digital hardware module in terms of the loops, conditional branches, and ordering of functions performed by the module
Data paths
[Parker84]
Copyright ã 1997 RASSP E&F
*
Definitions (Cont.)
Gate level
The stage of hardware design at which the operations and storage elements can be described in terms of their constructions from logic gates such as NAND and OR
Logic level
Sometimes synonymous with gate level; often used when the hardware is described in terms of Boolean equations
Register-transfer level
The hardware implementation stage at which the hardware is described in terms of transfers of data between registers and operations on the data, which are usually expressed as bit vectors rather than as single-bit values; includes register-transfer behavior and register-transfer structure
[Parker84]
*
The operation of hardware at the register-transfer level; only abstract or visible transfers and registers are described; interconnections between registers and functional units are usually implicit; control signals and overall control flow are usually implicit and/or expressed at a high level
Register-transfer structure
Hardware implementation at the register-transfer level; register, functional operators, and their interconnections are specified; the control signals and overall control flow may be embedded in the hardware as part of the overall specification or may be specified separately; sometimes referred to as the functional structure
[Parker84]
*
Maximum speed
Minimum area
[Parker84]
Synthesis attempts to produce designes that meet a set of constraints and the maximize a set of goals. The difference between goals and constraints is primarily one of degree. Goals are things that are “nice,” like high speed, small area, low power, etc. Constraints are things that are required, like a maximum size that will fit on a given FPGA, a maximum number of I/O pins available in a given package, etc.
This is a list of typical synthesis goals. Note that the synthesis tool attempts minimize (maximize) these metrics during optimization, but that the VHDL description that it starts with can have a SIGNIFICANT impact on the outcome. It is up to the designer to “think in terms of hardware” and write the VHDL behavioral description in such a way as to drive the synthesis tools toward the intended solution.
Copyright ã 1997 RASSP E&F
*
Limitations of a given implementation technology (i.e., no tri-state devices available, no built-in memory cells)
Specified time delays between significant events
Area upper bounds
Lower bound on reliability
[Parker84]
Here is a list of typical constraints that a synthesis tool must deal with. Again, the designer must help the tool meet these by writing the behavioral VHDL in the proper way. For example, if the behavioral VHDL includes the syntax for internal tri-state buffers, there is no way that the synthesis tool will be able to map this VHDL to an FPGA or PLD family that does not support internal tri-state drivers.
Copyright ã 1997 RASSP E&F
*
Resource allocation - selection of structures to implement functions
Design transformation - changing a design to meet a goal of constraint without adding additional detail (optimization)
(De)composition - partitioning or combining functions so that they directly map to structures available in the target technology (technology mapping)
Event scheduling - assigning operations to clock phases or slots on a time axis
[Parker84]
These are the high level processes that a synthesis tool must go through. An example of resource allocated would be the selection of a multiplier from a “library” within the synthesis tool to implement a “*” operation in the behavioral code. An example of design transformation would be the general minimization of boolean functions that a synthesis tool goes through during area optimization. An example of composition/decomposition would be the selection of an and-or-invert primitive from a specific tecnology library to replace a separate and gate, or gate, and invert gate connected in the and-or-invert gate topology (see the slides on structural VHDL where the Autologic tool did this during optimization). Finally, event scheduling helps determine the order of events. Performing this operation in terms of clock cycles is really the domain of behavioral synthesis tools which will be explained in the subsequent slides.
Copyright ã 1997 RASSP E&F
*
Involves high-level scheduling and assignment
Register-Transfer Synthesis - synthesis of register-transfer structure from abstract, control-flow, or register-transfer behavior
Logic Synthesis - synthesis of gate-level logic (an implementation) from register-transfer structure or Boolean equations
[Parker84]
Behavioral synthesis involves taking a high level algorithm description, ususally described in a dataflow fashion, and developing a datapath tht can implement it in an efficient fashion. Behavioral synthesis involves the processes of scheduling, i.e., determining the order of operations relative to each other and some clock, and assignment, i.e., specifying which resources are going to compute each operation.
Register-transfer synthesis involves synthesizing an RTL level structure (datapath and control) from what is basically the output of the behavioral synthesis process.
Finally, logic synthesis is the process of developing a logic level (gate level) structure from an RTL level structure or a set of boolean equations.
Copyright ã 1997 RASSP E&F
*
+
*
+
*
+
*
+
*
This slide shows graphically the first step in the behavioral synthesi process, that of scheduling tasks to individual clock cycles. The schedule shown allows resource sharing in that the additions and multiplications occur on different clock cycles and thus can use the same hardware resource (a single adder and a single multiplier).
Note that you could in fact, take the VHDL signal assignment statements that represent the algorithm shown above and wrap them in an entity and architecture, and submit them to a logic level synthesis tool. What you would get however, would be a big block of combinational logic comprised ot two 8 bit adders and two 8 bit multipliers. There would be no synchronous nature, and no resource sharing.
Copyright ã 1997 RASSP E&F
*
Register
R3
Register
R4
E(7:0)
A(7:0)
B(7:0)
D(7:0)
C(7:0)
G(15:0)
F(15:0)
The next step in behavioral synthesis is developing a data path behavior that corresponds to the algorithm and the corresponding schedule. That process is shown here. In addition to the datapath, the control structure that animates the datapath to perform the algorithm is also developed. It is generally considered that synthesis from the data path behavior and control downward is RTL level synthesis, i.e., this is where behavioral synthesis stops and RTL level synthesis begins.
Tools to perform behavioral synthesis, such as Monet from Mentor Graphics, and Behavioral Compiler from Synopsis, are becoming available, but they are somewhat lacking in maturity and require that the problem be able to be specified in a dataflow manner. They are not appropriate for design of complex, control flow dominated systems such as microprocessors or micro controllers.
Copyright ã 1997 RASSP E&F
*
Load R4;
RTL level synthesis is the process of mapping the (abstract) datapath behavior and control to an actual datapath the consists of actual library elements such as ALUs, registers, and multiplexors. In RTL level synthesis, additional registers may be added, but the assignment of which operations happen on which resources during which clock cycle has already been determined.
Most synthesis tools can handle basic RTL level synthesis, although they may differ in the quality of the designs they produce (how well they meet their goals).
Copyright ã 1997 RASSP E&F
*
Load R4;
Logic synthesis is the process of generating a gate level representation of the design from the RTL level structure (by inserting library elements for things such as ALUs and multipliers) or from Boolean equations.
Copyright ã 1997 RASSP E&F
*
Structural VHDL
*
Typically IEEE 1164 Std. types are used
std_ulogic type
Values ‘U’, ‘X’, ‘W’, and ‘-’ are called metalogical values for synthesis
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
USE IEEE.std_logic_1164.ALL;
This section of the module presents the standard packages used in developing synthesizable VHDL descriptions. Obviously, VHDL standard BIT types may be used. However, in describing real hardware, it is convenient to have a type that also can represent a high impedance state (Z) and an unknown state (X or -).
The IEEE Std. 1164 package defines an enumerated type that has the values of ‘U’, ‘X’, ‘W’, ‘-’, ‘L’, ‘H’ as well as ‘0’ and ‘1’. This package is supported by most, if not all, synthesis tools. The 1164 package also defines vectors of the std_ulogic type and a resolved subtype of std_ulogic, called std_logic. It is most common to simply use std_logic for all single bit signals, and std_logic_vector for all multibit signals in a synthesizable VHDL description.
Another relevant standard is the IEEE draft Standard 1076.6 Draft Standard for VHDL Register Transfer Level Synthesis. This standard describes the VHDL syntax that is allowed for RTL level synthesis and below. All of the examples contained in this module conform to this standard as much possible. One important definition it contains is that of “metalogical values” - values of ‘U’, ‘X’, ‘W’, and ‘-’ - that have special use in synthesis, as will be pointed out in the coming slides.
Copyright ã 1997 RASSP E&F
*
Subtypes of std_logic - X01, X01Z, UX01, UX10Z
Logic functions with various arguments - std_ulogic, std_logic, std_logic_vector
FUNCTION “and” (l,r : std_ulogic;) RETURN UX01;
FUNCTION “nand” (l,r : std_ulogic;) RETURN UX01;
FUNCTION “or” (l,r : std_ulogic;) RETURN UX01;
FUNCTION “nor” (l,r : std_ulogic;) RETURN UX01;
FUNCTION “xor” (l,r : std_ulogic;) RETURN UX01;
FUNCTION “xnor” (l,r : std_ulogic;) return ux01;
FUNCTION "not" (l,r : std_ulogic) RETURN UX01;
Conversion functions
FUNCTION To_bit(s:std_ulogic) RETURN bit;
FUNCTION To_bitvector(s:std_ulogic_vector) RETURN bit_vector;
FUNCTION To_StdULogic(b:bit) RETURN std_ulogic;
The 1164 package also includes many useful functions. In fact, it is commonly used in modeling digital systems in general, not just for synthesis.
Copyright ã 1997 RASSP E&F
*
Clock edge functions
FUNCTION Is_X (s:std_ulogic_vector) RETURN boolean;
FUNCTION Is_X (s:std_logic_vector) RETURN boolean;
FUNCTION Is_X (s:std_ulogic) RETURN boolean;
More 1164 functions. The clock edge functions are useful for synthesis of sequential logic as will be shown.
Copyright ã 1997 RASSP E&F
*
Synopsis developed packages based on std_logic_1164 package - supported by many other synthesis tools
std_logic_arith
std_logic_signed
std_logic_unsigned
asyl.arith
IEEE has developed standard packages for synthesis IEEE Std. 1076.3
Numeric_Bit
Numeric_Std
All synthesis tools support some type of arithmetic package - that is, a package that contains operators like addition, subtraction, multiplication, etc.
When synthesis tools began to appear, each tool vendor created their own arithmetic package. Synopsis created packages for general arithmetic, and signed and unsigned arithmetic called std_logic_arith, std_logic_unsigned, and std_logic_signed. These became “de facto” standards and other tool vendors began to support them. In 1997, the IEEE came out with a standard set of packages for synthesis. These are defined in IEEE std. 1076.3-1997 IEEE Standard VHDL Synthesis Packages.
These packages are called numeric_bit, for arithmetic operations on stnadard VHDL BIT types, and numeric_std for arithmetic operations on std_logic types.
Copyright ã 1997 RASSP E&F
*
TYPE unsigned IS ARRAY (natural RANGE <> ) OF bit;
TYPE signed IS ARRAY (natural RANGE <> ) OF bit;
Arithmetic operators - various combinations of signed and unsigned arguments
FUNCTION “abs” (arg:unsigned) RETURN unsigned;
FUNCTION “-” (arg:unsigned) RETURN unsigned;
FUNCTION “+” (l,r:unsigned) RETURN unsigned;
FUNCTION “-” (l,r:unsigned) RETURN unsigned;
FUNCTION “*” (l,r:unsigned) RETURN unsigned;
FUNCTION “/” (l,r:unsigned) RETURN unsigned;
USE IEEE.numeric_bit.ALL;
*
FUNCTION “>” (l,r:unsigned) RETURN boolean;
FUNCTION “<” (l,r:unsigned) RETURN boolean;
FUNCTION “<=” (l,r:unsigned) RETURN boolean;
FUNCTION “>=” (l,r:unsigned) RETURN boolean;
FUNCTION “=” (l,r:unsigned) RETURN boolean;
FUNCTION “/=” (l,r:unsigned) RETURN boolean;
Shift and rotate functions
*
Conversion functions
Logical operators
Edge detection functions
Copyright ã 1997 RASSP E&F
*
Signed and unsigned type declarations
Aritmetic operators
Comparison operators
Translation functions
USE IEEE.numeric_std.ALL;
- both values are well defined and have the same values
- one value is ‘0’ and the other is ‘L’
- one value is ‘1’ and the other is ‘H’
- at least one of the values is ‘-’
For vectors, they must be of the same length and each element returns true from a STD_MATCH call on it.
Translation functions translate ‘H’ to ‘1’ and ‘L’ to ‘0’. If a value other than ‘0’, ‘L’, ‘1’, or ‘H’ is found, a warning is issued.
Copyright ã 1997 RASSP E&F
*
Types
Attributes
After clauses
Inferring latches
Structural VHDL
*
Bit, Boolean, and Std_Ulogic map to single bits
Mapping of other types will be made by the tool unless the ENUM_ENCODING attribute is used
Character type is suppored
Severity_level type is ignored
Integer type, Natural, and Positive are supported
A subtype with a descrete range should be used or the default 32 bit length will be synthesized
Physical types (e.g., time) are ignored
Floating point type is ignored - references to floating point objects can occur only within ignored constructs, e.g., After clauses, etc.
Copyright ã 1997 RASSP E&F
*
Array types are supported
Bounds must be specified directly or indirectly as static values of an integer type
Element subtype must denote a scalar type or a one dimensional vector of an enumerated type that denotes single bits
TYPE integer_array IS ARRAY(natural RANGE 7 DOWNTO 0) OF integer;
TYPE boolean_array IS ARRAY(integer RANGE <>) OF boolean;
...
Record types are supported
Access types are ignored
File types are ignored
Copyright ã 1997 RASSP E&F
*
t’BASE
t’LEFT
t’RIGHT
t’HIGH
t’LOW
a’LEFT
a’RIGHT
a’HIGH
a’LOW
a’RANGE
a’REVERSE_RANGE
a’LENGTH
s’STABLE
s’EVENT
Copyright ã 1997 RASSP E&F
*
Multiple waveform elements are not allowed
library IEEE;
use IEEE.std_logic_1164.all;
BEGIN
SIGNAL sig1,sig2 : std_logic;
*
Concurrent conditional signal assignment statements are supported - must end in else clause
library IEEE;
use IEEE.std_logic_1164.all;
BEGIN
b WHEN (sel = '1') ELSE
'X';
*
library IEEE;
use IEEE.std_logic_1164.all;
y : OUT std_logic);
BEGIN
*
Generally, if the numeric_bit and numeric_std packages are supported, the operators within them are supported
Arithmetic operators - “abs”, “+”, “-”, “*”, “/”, “rem”, “mod”
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
END divider;
BEGIN
*
aleb : OUT boolean);
BEGIN
*
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
END shift_4;
BEGIN
*
Postponed processes (or postponed concurrent signal assignment statements) are NOT supported
Process statement can have either a sensitivity list or a WAIT statement
Sensitivity list is ignored for synthesis (by most tools) - thus, to avoid simulation mismatches, all signals which appear on the RHS should be in the sensitivity list
Only one WAIT statement per process is allowed and it must be the first statement in the process after BEGIN
Only the WAIT UNTIL syntax of the WAIT statement is supported
WAIT UNTIL input1 = ‘1’;
Copyright ã 1997 RASSP E&F
*
SIGNAL sig1 : std_logic;
*
SIGNAL sig1 : std_logic;
b
c
sig1
0
U
An incomplete sensitivity list can cause mismatches between simulation and synthesis as seen here. The synthesis tool, because it ignores the sensitivity list, creates the same solution as with the complete sensitivity list, but it does not simulate like an and/or/invert gate as the waveforms show (this is a copy of the simulation results from QuickHDL).
Autologic II flags an incomplete sensitivity list as an error, but Exemplar’s Galileo only issues a warning. The IEEE synthesis standard says sensitivity lists are ignored.
The waveform for the example on the previous page with the complete sensitivity list is shown below.
Note: This example was from Exemplar’s Galileo tool targeted towards Actel primitives - hence the “unusual” configuration of the result.
a
y
b
c
sig1
0
*
Various types of signal assignment statements inside a process statement (sequential signal assignment statements) are supported
IF statements
Case statements
Loop statement
Only For loops supported
Bounds must be specified as static values of an integer type
Exit and Next statements supported (without lables)
Copyright ã 1997 RASSP E&F
*
BEGIN
y <= '1';
*
library IEEE;
use IEEE.std_logic_1164.all;
y : OUT std_logic);
BEGIN
*
library IEEE;
use IEEE.std_logic_1164.all;
shift_out : OUT std_logic);
BEGIN
IF(mode = '0') THEN
*
Procedures and Functions are supported - with limitations to allowed statement types
Procedures and functions may be in a package or in the declarative part of the architecture
LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.numeric_std.all;
SIGNAL output : OUT std_logic_vector(3 DOWNTO 0));
END logic_package;
*
VARIABLE result : std_logic;
BEGIN
IF((in1 = '1' and in2 = '1') or (in2 = '1' and in3 = '1') or
(in1 = '1' and in3 = '1')) THEN
result := '1';
ELSIF((in1 = '0' and in2 = '0') or (in2 = '0' and in3 = '0') or
(in1 = '0' and in3 = '0')) THEN
result := '0';
*
BEGIN
*
BEGIN
*
LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.numeric_std.all;
USE work.logic_package.all;
END decoder;
BEGIN
*
Tri-State Logic
Tri-state logic is infered when an object is assigned an IEEE Std. 1164 value ‘Z’
library IEEE;
use IEEE.std_logic_1164.all;
END tri_state4;
BEGIN
"ZZZZ";
*
Use of Don’t Cares (‘X’s)
IEEE Std. 1164 values of ‘X’ or ‘-’ can be used to specify “don’t care” conditions
library IEEE;
use IEEE.std_logic_1164.all;
BEGIN
y <= '1';
END IF;
*…