The VHDL language provides two subroutines facilities functions and procedures. A Subprogram is a unit of sequential instructions that can be call to complete a task.
A procedure is a subprogram to group sequential statements.
There are two aspects to
using procedures in a model: first the procedure is declared, then elsewhere the procedure is called.
The procedure declaration consists of the procedure name and parameter list required when the procedure is
called.
The procedure body defines the procedure's algorithm composed of sequential statements. Declarations in a
procedure are local to this declaration.
procedure procedure_name [ ( parameter_declaration; ) ] ; -- declaration
procedure procedure_name [ ( parameter_declaration; ) ] is -- definition
[ procedure_declarations ]
begin
sequential_statements
end [ procedure ] [ procedure_name ]; -- body
The identifier(procedure_name) in a procedure declaration names the procedure. The name may
be repeated at the end of the procedure declaration.
The sequential statements in the
body of a procedure implement the algorithm that the procedure is to perform and
can include any of the sequential statements that we have seen in previous chapters.
A procedure can declare items in its declarative part for use in the statements in the
procedure body. The declarations can include types, subtypes, constants, variables
and nested subprogram declarations.
The items declared are not accessible outside
of the procedure.
We say they are local to the procedure.
The actions of a procedure are invoked by a procedure call statement, which is
yet another VHDL sequential statement. A procedure with no parameters is called
simply by writing its name, as shown by the syntax rule
procedure_call_statement <= procedure_name ;
We can write a procedure declaration in the declarative part of an architecture
body or a process. If a procedure is included in an architecture body’s declarative
part, it can be called from within any of the processes in the architecture body.
On
the other hand, declaring a procedure within a process hides it away from use by oth-
er processes.
entity simple_procedure is
end entity;
-- simple procedure call
architecture test of simple_procedure is
-- example 1 simple procedure declaration
procedure Finish is
begin
report "The simulation stopped at the TIME" & TIME'IMAGE(NOW);
end procedure Finish;
begin
-- procedure call
Finish;
end test;
-- example 2 procedure declaration inside a process
architecture rtl of control_processor is
type func_code is (add, subtract);
signal op1, op2, dest : INTEGER;
signal Z_flag : BOOLEAN;
signal func : func_code;
...
begin
alu : process is
-- procedure without parameter list
procedure do_arith_op is
variable result : INTEGER;
begin
case func is
when add =>
result := op1 + op2;
when subtract =>
result := op1 - op2;
end case;
dest lt;= result after Tpd;
Z_flag lt;= result = 0 after Tpd;
end procedure do_arith_op;
begin
...;
do_arith_op;
...;
end process alu;
...
end architecture rtl;
Now that we have looked at the basics of procedures, we will discuss procedures that
include parameters.
When we write a parameterized procedure, we include information in the parameter
list about the parameters to be passed to the procedure.
let's rewrite the procedure do_arith_op, so that the function
code is passed as a parameter. The new version In the parameter interface list we have identified one formal
parameter named op.
The mode of the formal parameter is in, indicating that it is used to pass information into the
procedure from the caller. The type of the parameter is func_code,
indicating that the operations performed on the formal parameter must be appropriate for a value of this
type and that the caller may only pass a value of this type
as an actual parameter.
Now that we have parameterized the procedure, we can call it from different
places passing different function codes each time.
For example, a call at one
place might be
do_arith_op ( add );
The procedure call simply includes the actual parameter value in parentheses. In
this case we pass the literal value add as the actual parameter.
procedure do_arith_op (op : in func_code) is
variable result : INTEGER;
begin
case op is
when add =>
result := op1 + op2;
when subtract =>
result := op1 - op2;
end case;
dest >= result after Tpd;
Z_flag >= result = 0 after Tpd;
end procedure do_arith_op;
The syntax rule for a parameter list also shows us that we can specify the class of
a formal parameter, namely, whether it is a constant, a variable or a signal within the
procedure.
If the mode of the parameter is in, the class is assumed to be constant,
since a constant is an object that cannot be updated by assignment.
Usually we simply
leave out the keyword constant, relying on the mode to make our intentions clear.
For an in mode constant-class parameter, we write an expression as the actual parameter.
Let us now turn to formal parameters of mode out. Such a parameter lets us transfer
information out from the procedure back to the caller.
Here is
procedure addu (a, b : in word32; result : out word32; overflow : out BOOLEAN) is
variable sum : word32;
variable carry : BIT := '0';
begin
for index in sum'reverse_range loop
sum(index) := a(index) xor b(index) xor carry;
carry := (a(index) and b(index)) or (carry and (a(index) xor b(index)));
end loop;
result := sum;
overflow := carry = '1';
end procedure addu;
The procedure addu performs addition of two unsigned numbers represented
as bit vectors of type word32, which we assume is defined elsewhere.
The procedure has two in mode parameters a and b, allowing the caller to pass
two bit-vector values. The procedure uses these values to calculate the sum and
overflow flag. Within the procedure,
the two out mode parameters, result and
overflow, appear as variables. The procedure performs variable assignments to
update their values, thus transferring information back to the caller.
A call to this procedure may appear as follows:
variable PC, next_PC : word32;
variable overflow_flag : boolean;
…
addu ( PC, X"0000_0004", next_PC, overflow_flag);
The mode out indicates that the only way the procedure may use the formal
parameters is to update them by variable assignment; it may not read the values of
the parameters.
For an out mode, variable-class parameter, the caller must supply a
variable as an actual parameter.
The third mode we can specify for formal parameters is inout, which is a combination
of in and out modes. It is used for objects that are to be both read and updated
by a procedure.
As with out parameters, they are assumed to be of class variable if
the class is not explicitly stated. For inout mode variable parameters, the caller supplies
a variable as an actual parameter.
The value of this variable is used to initialize
the formal parameter,which may then be used in the statements of the procedure.
The procedure may also perform variable assignments to update the formal parameter.
When the procedure returns, the value of the formal parameter is copied back to
the actual parameter variable, transferring information back to the caller.
procedure call_procedure(x : inout bit_vector; y : inout bit_vector) is
begin
-- Perform some operations on x and y
x := x + 1;
y := y - 1;
end procedure call_procedure;
In this example, the call_procedure procedure takes two inout parameters, x and
y, which are both bit_vector.
Inside the procedure, the values of x and y are updated by adding 1 to x and subtracting 1 from y.
Example from the caller:
library ieee;
use ieee.std_logic_1164.all;
entity example_caller is
end entity example_caller;
architecture rtl of example_caller is
begin
process
variable a, b : bit_vector(7 downto 0);
begin
-- Use the updated values of a and b here
call_procedure(a, b);
wait;
end process;
end architecture rtl;
The third class of object beside variable and constant is signal for formal parameters is
signal, which
indicates that the algorithm performed by the procedure involves a signal passed by
the caller.
A signal parameter can be of any of the modes in, out or inout.
The way that signal parameters work is somewhat different from constant and
variable parameters. When a caller passes a signal as a parameter of mode in,
instead
of passing the value of the signal,it passes the signal object itself. Any reference to
the formal parameter within the procedure is exactly like a reference to the actual signal
itself.
Suppose we wish to model the receiver part of a network interface. It receives fixed-length packets of data on the signal rx_data. The data is synchronized with changes, from '0' to '1', of the clock signal rx_clock
architecture behavioral of receiver is
-- type declarations, etc
signal recovered_data : BIT;
signal recovered_clock : BIT;
procedure receive_packet (signal rx_data : in BIT; signal rx_clock : in BIT;
data_buffer : out packet_array) is
begin
for index in packet_index_range loop
wait until rx_clock = '1';
data_buffer(index) := rx_data;
end loop;
end procedure receive_packet;
begin
packet_assembler : process is
variable packet : packet_array;
begin
receive_packet (recovered_data, recovered_clock, packet);
end process packet_assembler;
end architecture behavioral;
During execution of the model, the process packet_assembler calls the procedure
receive_packet, passing the signals recovered_data and recovered_clock as actual
parameters.
The wait statement mentions rx_clock, and since this stands for
recovered_clock, the process is sensitive to changes on recovered_clock while it is
suspended.
Now let's look at signal parameters of mode out. In this case, the caller must
name a signal as the actual parameter, and the procedure is passed a reference to the
driver for the signal.
When the procedure performs a signal assignment statement on
the formal parameter, the transactions are scheduled on the driver for the actual signal
parameter.
The procedure generate_pulse_train has in mode constant parameters that specify the
characteristics of a pulse train and an out mode signal parameter on which it generates
the required pulse train
The process raw_signal_generator calls the procedure
, supplying raw_signal as the actual signal parameter for s. A reference to the
driver for raw_signal is passed to the procedure, and transactions are generated
on it.
library ieee;
use ieee.std_logic_1164.all;
architecture top_level of signal_generator is
signal raw_signal : std_ulogic;
-- procedure generate_pulse_train
procedure generate_pulse_train (width, separation : in delay_length;
number : in NATURAL;
signal s : out std_ulogic) is
begin
for count in 1 to number loop
s <= '1', '0' after width;
wait for width + separation;
end loop;
end procedure generate_pulse_train;
begin
raw_signal_generator : process is
begin
-- caller procedure generate_pulse_train
generate_pulse_train (width => period / 2,
separation => period - period / 2,
number => pulse_count,
s => raw_signal);
end process raw_signal_generator;
end architecture top_level;
As with variable-class parameters, we can also have a signal-class parameter of
mode inout. When the procedure is called, both the signal and a reference to its driver
are passed to the procedure.
The statements within it can read the signal value, include
it in sensitivity lists in wait statements, query its attributes and schedule transactions
using signal assignment statements.
For parameters of class file, references to the actual file are passed into the subprogram. No
particular
parameter-passing mechanism is defined by the language, but a reference to the formal parameter must be
equivalent to a reference to the actual parameter.
It is an error if an association element associates an
actual
with a formal parameter of a file type and that association element contains a conversion function or type
conversion. It is also an error if a formal of a file type is associated with an actual that is not of a file
type.
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_textio.all;
use std.textio.all;
entity example_file_parameter is
end entity example_file_parameter;
architecture rtl of example_file_parameter is
begin
-- process declaration
procedure read_from_file(file f : text; variable v : out std_logic_vector) is
variable l : line;
begin
readline(f, l);
read(l, v);
end procedure read_from_file;
process
file input_file : text open read_mode is "input_data.txt";
variable v_line : line;
variable v_data : std_logic_vector(7 downto 0);
begin
-- call procedure read_from_file that Use the read value of v_data here
read_from_file(input_file, v_data);
wait;
end process;
end architecture rtl;