Provided by: alliance_5.0-20110203-4_i386
VHDL behavioural subset.
This document describes the ALLIANCE VHDL subset for behavioural data
In a data flow architecture only concurrent statements (except process)
are supported. All sequential statements including loops, signal
assignment, etc .. are to be banished.
Allowed concurrent statements are:
simple signal assignment
conditional signal assignment
selected signal assignment
concurrent assert statement
When using concurrent statements, an ordinary signal can be assigned
only once. The value of the signal must be explicitly defined by the
signal assignment (for example, in a selected signal assignment the
value of the target signal is to be defined for every value that the
select expression can take).
The above constraint may be felt as a hard restriction when designing
distributed controled hardware (precharged line, distributed
multiplexer, etc ...). To hurdle this, VHDL uses a special feature:
A resolved signal is a signal declared with a resolved subtype (see
vhdl(5)). A resolved subtype is a type combined with a resolution
function. A resolved signal can be assigned by multiple signal
assignments. Depending on the value of each driver, the resolution
function determines the effective value of the signal.
A guarded signal is a resolved signal with drivers that can be
disconected. A guarded signal must be assigned inside a block
statement through a guarded signal assignment.
A distributed multiplexer may be described as :
signal Distributed_Mux : mux_bit bus;
first_driver_of_mux : block (Sel1 = '1')
Distributed_Mux <= guarded Data1;
second_driver_of_mux : block (Sel2 = '1')
Distributed_Mux <= guarded Data2;
LATCHES and REGISTERS
Sequential elements must be explicitly declared using the type reg_bit
or reg_vector (and must be of kind register). A sequential element must
be assigned inside a block statement by a guarded signal assignment.
Rising edge triggered D flip flop :
signal Reg : reg_bit register;
flip_flop : block (ck = '1' and not ck'STABLE)
Reg <= guarded Din;
Level sensitive latch:
signal Reg : reg_bit register;
latch : block (ck = '1')
Lat <= guarded Din;
In both cases, the guard expression must depend only on one signal if
the description is to be processed by the logic synthetizer (boom +
The following operators are only supported: not, and, or, xor, nor,
nand, &, =, /=
They can be applied on all types supported by the subset. Other
standard VHDL operators (+, -, >, <, ...) have not been implemented in
the present release.
Timing information can be specified in behavioural descriptions using
after clauses. However, those delays are currently only used for
simulation. After clauses are supported but not used for synthesis and
After clauses in block statements (for guarded signal assignments) are
not supported for sequential elements (signals of kind register), but
supported for bus elements (signals of kind bus). This is because the
VHDL default disconnection time is null and this can generate
unexpected behavior for sequential elements.
In selected signal assignment, only uniform delays are supported (the
same After clause in all assignments).
Transport option is not supported. All delays are inertial delays.
Only two severity levels are supported in concurrent assert statements:
warning print a warning message if the assert condition is not
error print an error message if the assert condition is not
satisfied. Then, stop the simulation.
Assert statements are ignored by the logic synthesis tool.
A special feature has been introduced in order to allow "don't care"
specification when the logic synthtizer is targeted ( Beware : this
feature is incompatible with the IEEE VHDL standard !!).
An output can be assigned to the value 'D' (don't care). This is taken
into account by the logic synthesis tool in the optimization process.
When the value of an output is 'D' the logic synthesis tool may turn it
into a '1' or a '0'.
A 'D' value is understood as a '0' by the logic simulator (asimut).
Arraies other than bit_vector, reg_vector, mux_vector and wor_vector
are not supported.
Here is the description of an adder with an accumulator register.
entity add_accu is
clk : in bit;
command : in bit;
data_in : in bit_vector (31 downto 0);
data_out : out bit_vector (31 downto 0);
cry_out : out bit;
vdd : in bit;
vss : in bit
architecture data_flow of add_accu is
signal eff_data : bit_vector (31 downto 0); -- effective operande
signal adder_out : bit_vector (31 downto 0); -- adder's result
signal adder_cry : bit_vector (32 downto 0); -- adder's carry
signal accum_reg : reg_vector (31 downto 0) register; -- accumulator
constant initialize : bit := '0';
constant accumulate : bit := '1';
-- select the effective operand
with command select
eff_data <= X"0000_0000" when initialize,
accum_reg when accumulate;
-- compute the result out of the adder
adder_out <= eff_data xor data_in xor adder_cry;
adder_cry (0) <= '0';
adder_cry (32 downto 1) <= (eff_data and adder_cry (31 downto 0)) or
(data_in and adder_cry (31 downto 0)) or
(aff_data and data_in ) ;
-- write the result into the register on the rising edge of clk
write : block (clk = '1' and not clk'STABLE)
accum_reg <= guarded adder_out;
-- assign outputs
cry_out <= adder_cry (32);
data_out <= accum_reg ;
-- check power supply
assert (vdd = '1' and vss = '0')
report "power sypply is missing"
vhdl(5), vst(5), boom(1), loon(1), boog(1), asimut(1), proof(1)