Lesson five: entities, architectures and processes

VHDL entities, architectures and processes

prepared by P. Bakowski

Introduction

A complete VHDL description needs to contain at least one module called entity. An entity represents the interfaces of a model with the external environment possibly integrating more entities. The entities are inter-connected and communicate through signals. To each entity is associated one or more architectures. The architectures describe the internal behavior of the entity. This behavior may be expressed in terms of processes; each process describing independent sequential activities; or in terms of other entities considered as structural blocks. The architecture built only from processes and simple signal assignments is called behavioral architecture. The architectures composed from other entities referred to as components is called structural architecture.
In the following chapter we are going to present and to discuss the elements of entities and behavioral architectures.

Contents: entity declaration, architecture declaration, processes, sequential control, processes and assertions, processes and signal attributes, chaining delays in processes, concurrent procedures, exercises

**VHDL entity declaration [syntax]**

The basic descriptional element of VHDL is entity; each description must be composed from at least one entity. Each entity has a set of ports which constitute its interface to the outside world. In VHDL, an entity may be the top level module of the design or may be used as a component in a design.

entity horloge is
end horloge;
entity ones_counter is
end ones_counter;

In general, the entity modules consist of two parts:

entity header

The header may include specification of generic constants. Generics allow to determine some quantitative aspects of the structure (e.g. size of the bus) and behavior (e.g. number of counting steps) of the entity.

entity ones_counter is
end ones_counter;

The generics are actualized when the entity is instantiated as a component in a design.
The declarative part may be used to declare items (e.g. types, functions,..) to be used in the implementation of the entity. Optional statements in the entity declaration may be inserted to define some special behavior for monitoring operation of the entity (e.g. checks on the input signals).

ports and signals

An entity port contains the list of items that must all be of class signal. Consequently, we are not required to write the keyword signal, it is assumed by default.

port(signal a:in bit_vector(0 to 2); signal c:out bit_vector(0 to 1));
port(a:in bit_vector(0 to 2); c:out bit_vector(0 to 1));
-- both expressions are equivalent

The ports may specify the input (in), the output (out) and the input-output signals (inout).

port(reset:in bit;abus:out address; dbus:inout word);

The word bufferis a kind of inout signal. It should be applied if the port is to be connected to an output -input signals used as a component in a design.

port(counter:buffer word);

A buffer port may have at most one signal assignment within the architecture.

elements of entity declaration

The declarative part of an entity may contain several kinds of items including:

type declarations

e.g. type MVL is ('0','1','Z');

procedure or function definitions

e.g.

function bin2int(a;bit_vector(range <>) return int;

begin ... end bin2int;

assertions concerning the input signals

An example:

**VHDL architecture declaration [syntax]**

The architecture is a module used to define how entity behaves or what it is composed of. The architecture description may be abstract implying the use of abstract objects; RTL (register transfer level) oriented implying the use of hardware related object types like registers or buses or structural implying the use of smaller hardware modules referred to as components. Depending on the character of the design or description, the components may be embraced at block or core level or be may be much more detailed and imply the creation of logic level structures (logic netlists). Each architecture body can describe a different implementation of the entity.

The potential composition of architecture module comprises:

declarative part

signals,
shared variables (local variables are not allowed)
component declarations
subprogram declarations

architecture body

component instantiation
autonomous signal assignments
processes

architecture declarative part

The declarative part of the architecture may contain:

signal declarations :

the signals are used to interconnect the internal components used in the same architecture

constant declarations :

the constants used internally in the given architecture

component declarations :

the components used in the architecture must be declared conformingly to the corresponding entities

subprogram declarations :

the functions/procedures used in the architecture

Example:

architecture exemple of entite_une is
begin
-- architecture body starts here

**VHDL processes [syntax]**

Behavioral architecture descriptions use extensively the algorithmic programming of the circuit/system functionalities. The behavioral architectures are mainly built from processes. All operations described in a process are executed sequentially (procedurally). Processes are activated through the events on signals generated outside or within the process (VHDL'93 provides an attribute called 'driving which can indicate if the signal is driven from within a process). The processes active at the same time execute concurrently.

basic process structure

A process is built from two parts: the declaration part and the statements part

label: process
-- signals are not allowed
begin
statements
end process label;

The statements section of the process is the sequential program. The behavior of the process is a function of the signals read by the process. The results of behavior are applied to the signals which may activate other processes.

`wait`statements

A simple wait statement stops the execution of a process.

wait;

A wait statement with signal list stops the execution of a process until one of the listed signals is activated.

Any event on any signal listed frees the process.

wait on signal_list;
e.g.wait on a,b,cin;

A wait statement with until condition stops the execution of a process until the condition becomes TRUE.

wait until condition;
e.g. wait until reset='1';

A wait statement with for time_expression stops the process for the time specified by the expression.

wait for time_expression;
e.g. wait for 100 ns;

A wait statement may combine several kinds of evaluations:

and_process:
process
begin
wait on a,b until enable='1';
end process;

Remark: The process above (and_process) will reactivate whenever there is an event on a or bor enable but only if enable is equal to `1', otherwise the process remain suspended.

sensitivity list versus `wait` statement

The sensitivity list is a kind of wait operation specified in the header of process statement. In the table below we illustrate the alternative use of sensitivity list and wait statement.

sensitivity list (..)	`wait` statement
`or_process_1:` `process(in1,in2)` `begin` `output<= in1 or in2;` `end process;`	`process` `begin` `output<= in1 or in2;` `wait on in1,in2;` `end process;`

Attention: The use of sensitivity list excludes the wait statements in the process

Sequential control in process

The body of a VHDL process comprises one or more sequential statements and/or signal assignments. The conditional control of their execution depends on the evaluation of control statements and assertions. This in turn may involve the evaluation of signal attributes. Note that multiple signal assignments executed "sequentially" in a process follow the specific rules. These rules are explained in chaining delays in processes.

Some examples of conditional control in processes:

if then end if

dff_process:

process

begin

if enable='1' then

q<= d after 5 ns;

end if;

wait on d;

end process;

if then else end if

buffer_process:

process

begin

if enable='0' then

output<= `z' after 5 ns;

else

output<= input after 5 ns;

end if;

wait on input;

end process;

if then elsif else end if

and_process:

process

begin

if in1='0' or in2='0' then
elsif in1='x' or in2='x' then
else
end if;
wait on in1,in2;

end process;

case is when when when others end case;

select_process:
process
begin

case sel is

when 1 => output<= 0;

when 2|3 => output<= 1;

when others => output<= 2;

end case;

end process;

loop end loop

process_exit_AB:

process

variable a: integer:=0;

variable b: integer:=1;

begin

loop_A: loop

a:=a+1;

b:=20;

loop_l2: loop

if b<(a*a) then

exit loop_B;

end if;

b:=b-a;

end loop loop_B;

exit loop_A when a>10;

end loop loop_A;

wait;

end process;

Multi-process architecture - an example

The following model describes latch architecture decomposed into three processes.

the process strobe_procoperates on strobe signal and loads the latch (input process)
the processenbld_procoperates on the output validation signals and generates an internal signal called enbld_sig
the process output_procis activated independently by new latch content and output validation signal.

architecture multi_path of registre is
begin
strobe_proc:
process(strb)
begin
end process strobe_proc;
enbld_proc:
process(ds1,nds2)
begin
end process enbld_proc;
output_proc:
process(reg,enbld_sig) -- both signals may activate the process in a short time and produce a spike
begin
end process output_proc;
end multi_path;

Processes and assertion statements

The assertions are efficient means to control process execution. For example specific input conditions may be checked before the execution of the related statements. The general syntax of assertion is as follows. Remind that different severity levels yield different simulator response.

assert condition

report message

severity level; -- level : note , warning or error

When the condition is FALSE the message is sent to the system output; if no message is given "assertion violation" is reported.
Example:
The following is a well known model of RS flip-flop. The assertion is used to detect the forbidden state (s=1 and r=1) at the flip-flop inputs.

entity srff is

port(s,r: in bit; q: out bit);

end srff;

architecture constrained of srff is

begin

process

variable int1,int2: bit:='0';

variable last_state: bit:='0';

begin

assert not (s='1' and r='1') -- s='1' and r='1' is not allowed

report "both s and r set to 1"

severity error;

if s='0' and r='0' then

last_state:=last_state;

elsif s='0' and r='1' then

last_state:='0';

elsif s='1' and r='0' then

last_state:='1';

end if;

q<= last_state after 2 ns;
wait on r,s;
end process;
end constrained;

Remark: Note that the same assertion may be specified in entity declaration. This makes constraints on the device independent from the internal architecture and visible at the interface level.

entity srff is
end srff;
architecture constrained of srff is
begin - see the architecture above

Processes and signal related attributes

As we have seen in the previous chapter concerning signals, VHDL provides a number of predefined signal related attributes. They allow to express different time related conditions and constraints.

Some attributes which define signals themselves :

`delayed, `quiet, `transaction

are signals

Other are functions that provide the information about signals :

`active, `event, `last_value, `last_event, `last_active- are functions

`'delayed`attribute (signal):

signal s: integer;

s<= 1 after 1 ns, 2 after 2 ns;

s'delayed(10 ns) ;

Question:

What is the resulting waveform of the output (s) signal?

Another example:

entity clock is
end clock;
architecture use_attributes of clock is
signal con: bit:='0';
begin
process(con)
end process;
end use_attributes;

`'stable`attribute (function - boolean result)

The `stable attribute is a boolean signal whose value is TRUE when an event has not occurred on the signal for the given time; otherwise is FALSE.
Detection of spikes:

entity dff is

port(d: in bit; q : out bit);

end dff;

architecture spike_protected of dff is

begin

process

begin

wait until d'stable(5 ns);

q<= d after 7 ns;

end process;

end spike_protected;

`'transaction`attribute (signal- event result)

The `transaction attribute is a bit signal which toggles every time when a transaction has occurred on the signal. Note that the `transactionattribute produces events even if the value of the signal has not changed.

entity nand_comp is

port(in1,in2: in bit; output: out bit);

end nand_comp;

architecture accounting of nand_comp is

component nand_gate

port(a,b: in bit; f: out bit);

end component;

signal result: bit;

begin
inst1:nand_gate port map(in1,in2,result);
output<=result;
account_process: -- counts the number of transactions on result signal

process

variable counter: integer:=0;

begin

wait on result'transaction;

counter:=counter+1;

end process;

end accounting;

`'active, 'event` attributes (function - boolean result)

The `active attribute is a boolean signal which is TRUE when a transaction has occurred on the signal during the current simulation cycle. The `event attribute is a boolean signal which is TRUE when an event has occurred on the signal during the current simulation cycle.

The following excl_process is sensitive to two input signals but its behavior depends on whether or not each of the inputs has changed.

entity buffer is
end buffer;
architecture exclusive of buffer is
begin excl_process:
process
begin
end process;
end exclusive;

`'last_active, 'last_event, 'last_value`attributes (function - boolean result)

The `last_active attribute returns the amount of time that has elapsed since there was a transaction on the signal. The `last_event attribute returns the amount of time that has elapsed since there was an event on the signal. The `last_value attribute returns the value of the signal before the last event.
Examples:
The first example shows how `last_value attribute can be applied to detect the signal falling edge. The second example presents the use of 'event and 'last_event attributes to test the setup time.

entity sh_reg is

port(inbit,clk: in bit; outbit: out bit);

end sh_reg;

architecture pfalling of sh_reg is
begin
shift_process:
process
variable reg: bit_vector(7 downto 0);
begin

if clk'last_value='1' and clk='0' then -- test of falling edge

outbit<=reg(0);

for i in 0 to 6 loop

reg(i):=reg(i+1); -- in VHDL'93 shr operator

end loop;

reg(7):=inbit;

end if;

wait on clk;

end process;

end pfalling;

Setup time check:

entity dff is
end dff;
architecture hold_time of dff is
begin
process
begin
end process;
end hold_time;

Chaining delays in processes

Several consecutive signal assignments may produce different effects depending on the value of signal and type of delays used in the process. When inertial signal assignment is made, all driver values in the queue past the current time are deleted. This is not the case of transport delays which maintains the previously (in time) assigned values.

More precise rule is given in the table below:

	inertial delay	transport delay
new transaction is scheduled before already existing	overwrites existing transactions	overwrites existing transactions
new transaction is scheduled after already existing	overwrites existing transactions having different values, otherwise keeps the existing transactions	appends the new transaction to existing ones

Examples:

Concurrent procedures

The VHDL architectures modules may contain concurrent procedure calls. A concurrent procedure is instantiated as a concurrent statement (e.g. signal assignment). Concurrent procedure is equivalent to a process with a sensitivity list extracted from all the actual signals whose mode in the formal parameter list is of in or inout. All elements associated to the formal parameters during the procedure instantiation must be visible in the architecture. There can be multiple occurrences of a concurrent procedure with different formal=>actual parameters association lists. This allows the reuse of the same procedure in different contexts.
The concurrent procedure may be declared in a package, in the entity declarative part, or in the architecture declarative part. All classes of objects (signals, variables, constants and files) may be used as concurrent procedure parameters.

adder_proc(a,b,cin: in std_logic; s,cout: out std_logic);
-- a,b,cin,s,cout : are formal parameters

architecture con_proc of adder is

begin

adder_proc(in1,in2,in3,out1,out2); -- seen as concurrent procedure instantiation

end con_proc;

architecture seq_proc1 of adder is

begin

process

begin

adder_proc(in1,in2,in3,out1,out2); -- seen as normal procedure

wait on in1,in2,in3;

end process;

end seq_proc1;

architecture seq_proc2 of adder is

begin

process(in1,in2,in3)

begin

adder_proc(in1,in2,in3,out1,out2); -- seen as normal procedure

end process;

end seq_proc2;

Introduction

VHDL entity declaration [syntax]

ports and signals

elements of entity declaration

VHDL architecture declaration [syntax]

architecture declarative part

VHDL processes [syntax]

basic process structure

wait statements

sensitivity list versus wait statement

Sequential control in process

Multi-process architecture - an example

Processes and assertion statements

Processes and signal related attributes

'delayed attribute (signal):

'stable attribute (function - boolean result)

'transaction attribute (signal- event result)

'active, 'event attributes (function - boolean result)

'last_active, 'last_event, 'last_value attributes (function - boolean result)

Concurrent procedures

Exercises

**VHDL entity declaration [syntax]**

**VHDL architecture declaration [syntax]**

**VHDL processes [syntax]**

`wait`statements

sensitivity list versus `wait` statement

`'delayed`attribute (signal):

`'stable`attribute (function - boolean result)

`'transaction`attribute (signal- event result)

`'active, 'event` attributes (function - boolean result)

`'last_active, 'last_event, 'last_value`attributes (function - boolean result)