Clock generation in VHDL

In almost any testbench, a clock signal is usually required in order to

synchronise stimulus signals within the testbench. A free-running clock can be
created thus:

architecture declarative part

signal clock : std_ulogic := '1’;
-- architecture statement part
clock <= not clock after 5 ns;
◼

Note the use of declaration initialization for the clock signal. We need this
because the default initialization value of a std_ulogic signal is 'U'. The first time
the signal assignment executes, not 'U' is 'X' and the remaining executions
(every 5 ns) of this statement yield not 'X' is 'X' - no clock sequence at all. The
disadvantage of this approach is that the clock runs forever - and so will the
simulation!
 Rather than continuous generation, what we would like to do is implement
the clock generator inside a process so that a known number of clock cycles
can be generated, courtesy of a for loop.
-- architecture declarative part
Note that a VHDL constant is used to constant num_cycles : integer := 320;
allow easy maintenance of the signal clock : std_ulogic := '1';
simulation duration. However, this piece -- architecture statement part
of code doesn't really do the trick. After process
320 cycles, the loop exits and the begin
process is re-invoked, generating sets of for i in 1 to num_cycles loop
clock <= not clock;
320 cycles continuously. In order to stop
wait for 5 ns;
the simulation from running forever due clock <= not clock;
to continuous clock cycle generation, we wait for 5 ns;
can append a wait statement to this -- clock period = 10 ns
process to suspend the process end loop;
indefinitely after one pass of 320 cycles. end process;
process
begin
for i in 1 to num_cycles loop
clock <= not clock;
wait for 5 ns;
clock <= not clock;
wait for 5 ns;
-- clock period = 10 ns
end loop;
wait; -- simulation stops here
end process;
Wait Statement
Definition:
The wait statement is a statement that causes suspension of a process or a
procedure.

Simplified Syntax
wait;

• wait on signal_list;

• wait until condition;

• wait for time;

• The wait statement suspends the execution of the process or procedure in which
it is specified. Resuming the process or procedure depends on meting the
condition(s) specified in the wait statement. There are three types of conditions
supported with wait statements: sensitivity clause, condition clause, and timeout
clause.
• The most often used is the sensitivity clause. A sensitivity list defines a set of signals
to which the process is sensitive and causes the process to resume (example 1).
Example 1
After executing all signal S1, S2 : Std_Logic;
statements, the process ...
will be suspended on the process
wait statement and will be begin
resumed when one of the ...
S1 or S2 signals changes wait on S1, S2;
its value. end process;
If a wait statement does not contain a sensitivity list, then an implicit sensitivity list is
assumed, one which contains all the signals that are present in that condition. If a
process is resumed but no condition is met, then the process will not execute any other
statements (example 2). The second type of a condition supported with
the wait statement is the condition clause. A process is resumed when the logical
condition turns true due to a change of any signal listed in the condition (example
2).
In this example, the wait statement will resume
Example 2 the process when the Enable signal changes its
wait until Enable = '1'; value to '1'. This is equivalent to the loop
-- this is equivalent to described in the comment below the first line.
-- loop Please note that the process is resumed on any
-- wait on Enable; change of the Enable signal. However, it will
-- exit when Enable = '1'; awake the rest of the process only when the
new value is '1'.
-- end loop;
The timeout clause defines the maximum Example 3
time interval during which the process is wait for 50 ns;
not active. When the time elapses, the A process containing this statement
process is automatically resumed will be suspended for 50 ns.
(example 3)
A single wait statement can have Example 4
several different conditions. In such a BIN_COMP : process
case the process will be resumed when begin
all the conditions are met (example 4). wait on A, B until CLK = '1';
The process BIN_COMP is resumed after a ...
change on either A or B signal, but only when end process;
the value of the signal CLK is equal to '1'.
If a wait on sensitivity_list is the only wait in the process and the last
statement of the process, then it can be substituted by a sensitivity list of a
process. See sensitivity list for details.
The syntax of the wait statement allows to use it without any conditions. Such a statement
is equivalent to wait until true, which suspends a process forever and will never resume.
While in simulation of normal models this is a disadvantage, this particular feature of
a wait statement is widely used in testbenches. Example 5 shows an example of a
testbench section.
Example 5 In this process the values of signals G1 and G0 are
G: process set to '11', '10', '01', and '00' at the time intervals 5,
begin 10, 15 and 20 ns, respectively. When the wait
G0 <= '1' after 5 ns, statement is encountered, the process is suspended
'0' after 10 ns, forever.
'1' after 15 ns,
'0' after 20 ns;
G1 <= '1' after 5 ns, •The wait statement can be located anywhere
'0' after 15 ns; between begin and end process.
wait; •A process with a sensitivity list may not
end process G; contain any wait statements.
 Assert Statement
The assertion statement has three
Formal Definition optional fields and usually all three are
A statement that checks that a used.
The condition specified in an assertion
specified condition is true and
statement must evaluate to a boolean
reports an error if it is not. value (true or false). If it is false, it is
said that an assertion violation
Simplified Syntax occurred.
assert condition The expression specified in
report string the report clause must be of
severity severity_level; predefined type STRING and is a
message to be reported when assertion
violation occurred.
• If the severity clause is present, it must specify an expression of
predefined type SEVERITY_LEVEL, which determines the
severity level of the assertion violation.

• The SEVERITY_LEVEL type is specified in the STANDARD

package and contains following values: NOTE, WARNING,
ERROR, and FAILURE. If the severity clause is omitted it is
implicitly assumed to be ERROR.

• When an assertion violation occurs, the report is issued and

displayed on the screen. The supported severity level supplies an
information to the simulator. The severity level defines the degree
to which the violation of the assertion affects operation of the
process:
•NOTE can be used to pass information messages from simulation ;
•WARNING can be used in unusual situation in which the simulation can be continued,
but the results may be unpredictable (example 2);

Example 2 Example 3
assert Status = OPEN_OK assert not (S= '1' and R= '1')
report "The call to FILE_OPEN was not report "Both values of signals S
successful" and R are equal to '1'"
severity WARNING; severity ERROR;
When the values of the signals S
Having called the procedure FILE_OPEN, if
and R are equal to '1', the message
the status is different from OPEN_OK, it is
is displayed and the simulation is
indicated by the warning message.
stopped because the severity is set
to ERROR.
•ERROR can be used when assertion violation makes continuation of
the simulation not feasible (example 3);
•FAILURE can be used when the assertion violation is a fatal error and
the simulation must be stopped at once (example 4).
Event like illegal operation code are
Example 4
severe errors and should cause
assert Operation_Code = "0000" immediate termination of the
report "Illegal Code of Operation" simulation, which is forced by the
severity FAILURE; severity level FAILURE.
•The message is displayed when the condition is NOT met, therefore the message should be
an opposite to the condition.
•Concurrent assertion statement is a passive process and as such can be specified in an
entity.
•Concurrent assertion statement monitors specified condition continuously.
•Synthesis tools generally ignore assertion statements.
 TestBench
Test bench is not defined by the VHDL Language Reference
Manual and has no formal definition.

Simplified Syntax
entity testbench_ent is
end entity testbench_ent;
architecture testbench_arch of testbench_ent is
signal declarations
component declarations
begin
component instantiations
stimuli (test vectors)
end architecture testbench_arch;
• The testbench is a specification in VHDL that plays the role of a
complete simulation environment for the analyzed system (unit
under test, UUT). A testbench contains both the UUT as well as
stimuli for the simulation.
• The UUT is instantiated as a component of the testbench and
the architecture of the testbench specifies stimuli for the UUT's
ports, usually as waveforms assigned to all output and
bidirectional ports of the UUT.
• The entity of a testbench does not have any ports as this serves
as an environment for the UUT. All the simulation results are
reported using the assert and report statements.
Example
entity Test_Decoder_bcd is begin
end entity Test_Decoder_bcd; U1:
architecture Struct_1 of Test_Decoder_bcd is Decoder_bcd port map (Enable,led,bcd);
bcd <= "00" after 5 ns,
component Decoder_bcd is "01" after 15 ns,
port ( "10" after 25 ns,
enable : in BIT; "11" after 35 ns;
led : in std_ulogic_vector(3 downto 0); assert bcd = "00" and led = "0001"
or bcd = "01" and led = "0010"
bcd : out BIT_VECTOR(1 downto 0)); or bcd = "10" and led = "0100"
end component Decoder_bcd; or bcd = "11" and led = "1000"
signal bcd: BIT_VECTOR(1 downto 0) := "11"; report "There is an incorrect value
signal Enable: BIT := '1'; on the output led"
severity error;
signal led: std_ulogic_vector (3 downto 0); end architecture Struct_1;
The design entity Test_Decoder_BCD is designed to verify correctness of the
Decoder_BCD. This test bench applies stimuli to the bcd inputs and when the
value of the sled signal is other than asingle '1' on the position corresponding
to the binary value of the bcd signal, with all other bits equal to zero, the
listed error is reported.

•Testbenches should allow automated verification of the UUT, with reports

on success or failure of each sub-test.
•In case of sequential units under test, a clock signal should be supported in
the testbench. Typically, it is realized as a separate process in the testbench
architecture.
•In order to stop the simulation with a testbench, stimuli are often specified
inside a process which contains a non-conditional wait statement at the end;
such statement suspends the execution of the testbench forever.