In many models, the behavior depends on a set of conditions that may or may not hold true during the course of simulation. We can use an if statement to express this behavior. The syntax rule for an if statement is

   if_statement ⇐
      [ if_label : ]
      if condition then
          { sequential_statement }
      { elsif condition then
          { sequential_statement } }
      [ else
          { sequential_statement } ]
      end if [ if_label ] ;

At first sight, this may appear somewhat complicated, so we start with some simple examples and work up to examples showing the general case. The label may be used to identify the if statement. We will discuss labeled statements in Chapter 20. A simple example of an if statement is

   if en then
    stored_value := data_in;
   end if;

The condition after the keyword if is used to control whether or not the statement after the keyword then is executed. If the condition is true, the statement is executed. In this example, if the value of the object en is ‘1’, the assignment is made; otherwise it is skipped. We can also specify actions to be performed if the condition is false. For example:

   if sel = 0 then
    result <= input_0;  -- executed if sel = 0
   else
    result <= input_1;  -- executed if sel /= 0
   end if;

Here, as the comments indicate, the first signal assignment statement is executed if the condition is true, and the second signal assignment statement is executed if the condition is false.

In many models, we may need to check a number of different conditions and execute a different sequence of statements for each case. We can construct a more elaborate form of if statement to do this, for example:

   if mode = immediate then
    operand := immed_operand;
   elsif opcode = load or opcode = add or opcode = subtract then
    operand := memory_operand;
   else
    operand := address_operand;
   end if;

In this example, the first condition is evaluated, and if true, the statement after the first then keyword is executed. If the first condition is false, the second condition is evaluated, and if it evaluates to true, the statement after the second then keyword is executed. If the second condition is false, the statement after the else keyword is executed.

In general, we can construct an if statement with any number of elsif clauses (including none), and we may include or omit the else clause. Execution of the if statement starts by evaluating the first condition. If it is false, successive conditions are evaluated, in order, until one is found to be true, in which case the corresponding statements are executed. If none of the conditions is true, and we have included an else clause, the statements after the else keyword are executed.

We are not restricted to just one statement in each part of the if statement. This is illustrated by the following if statement:

   if opcode = halt_opcode then
    PC := effective_address;
    executing := false;
    halt_indicator <= true;
   end if;

If the condition is true, all three statements are executed, one after another. On the other hand, if the condition is false, none of the statements are executed. Furthermore, each statement contained in an if statement can be any sequential statement. This means we can nest if statements, for example:

   if phase = wash then
    if cycle_select = delicate_cycle then
      agitator_speed <= slow;
    else
      agitator_speed <= fast;
    end if;
    agitator_on <= true;
   end if;

In this example, the condition phase = wash is first evaluated, and if true, the nested if statement and the following signal assignment statement are executed. Thus the assignment agitator_speed <= slow is executed only if both conditions evaluate to true, and the assignment agitator_speed <= fast is executed only if the first condition is true and the second condition is false.

   entity thermostat is
    port ( desired_temp, actual_temp : in integer;
           heater_on : out boolean );
   end entity thermostat;
   --------------------------------------------------
   architecture example of thermostat is
   begin
    controller : process (desired_temp, actual_temp) is
    begin
      if actual_temp < desired_temp - 2 then
        heater_on <= true;
      elsif actual_temp > desired_temp + 2 then
        heater_on <= false;
      end if;
    end process controller;

   end architecture example;

   if en = '1' then
    ...
   end if;

   conditional_variable_assignment ⇐
      [ label : ]
      name := expression when condition
              { else expression when condition }
              [ else expression ] ;

   result := a - b when mode = subtract else a + b;

   if mode = subtract then
    result := a - b;
   else
    result := a + b;
   end if;

If we have a model in which the behavior is to depend on the value of a single expression, we can use a case statement. The syntax rules are as follows:

   case_statement ⇐
      [ case_label : ]
      case expression is
          ( when choices => { sequential_statement } )
          { ... }
      end case [ case_label ] ;
   choices ⇐ ( simple_expression | discrete_range | others ) { | ... }

The label may be used to identify the case statement. We will discuss labeled statements in Chapter 20. We start with some simple examples of case statements and build up from them. First, suppose we are modeling an arithmetic/logic unit, with a control input, func, declared to be of the enumeration type:

   type alu_func is (pass1, pass2, add, subtract);

We could describe the behavior using a case statement:

   case func is
    when pass1 =>
      result := operand1;
    when pass2 =>
      result := operand2;
    when add =>
      result := operand1 + operand2;
    when subtract =>
      result := operand1 - operand2;
   end case;

At the head of this case statement is the selector expression, between the keywords case and is. In this example it is a simple expression consisting of just a primary value. The value of this expression is used to select which statements to execute. The body of the case statement consists of a series of alternatives. Each alternative starts with the keyword when and is followed by one or more choices and a sequence of statements. The choices are values that are compared with the value of the selector expression. There must be exactly one choice for each possible value. The case statement finds the alternative whose choice value is equal to the value of the selector expression and executes the statements in that alternative. In this example, the choices are all simple expressions of type alu_func. If the value of func is pass1, the statement result := operand1 is executed; if the value is pass2, the statement result := operand2 is executed; and so on.

A case statement bears some similarity to an if statement in that they both select among alternative groups of sequential statements. The difference lies in how the statements to be executed are chosen. We saw in the previous section that an if statement evaluates successive Boolean expressions in turn until one is found to be true. The group of statements corresponding to that condition is then executed. A case statement, on the other hand, evaluates a single selector expression to derive a selector value. This value is then compared with the choice values in the case statement alternatives to determine which statement to execute. An if statement provides a more general mechanism for selecting between alternatives, since the conditions can be arbitrarily complex Boolean expressions. However, case statements are an important and useful modeling mechanism, as the examples in this section show.

The selector expression of a case statement must result in a value of a discrete type, or a one-dimensional array of character elements, such as a character string or bit string (see Chapter 4). Thus, we can have a case statement that selects an alternative based on an integer value. If we assume index_mode and instruction_register are declared as

   subtype index_mode is integer range 0 to 3;
   variable instruction_register : integer range 0 to 2**16 - 1;

then we can write a case statement that uses a value of this type:

   case index_mode'((instruction_register / 2**12) rem 2**2) is
    when 0 =>
      index_value := 0;
    when 1 =>
      index_value := accumulator_A;
    when 2 =>
      index_value := accumulator_B;
    when 3 =>
      index_value := index_register;
   end case;

Notice that in this example, we use a qualified expression in the selector expression. If we had omitted this, the result of the expression would have been integer, and we would have had to include alternatives to cover all possible integer values. The type qualification avoids this need by limiting the possible values of the expression.

Another rule to remember is that the type of each choice must be the same as the type resulting from the selector expression. Thus in the above example, it is illegal to include an alternative such as

   when 'a' => ...   -- illegal!

since the choice listed cannot be an integer. Such a choice does not make sense, since it can never match a value of type integer.

We can include more than one choice in each alternative by writing the choices separated by the “|” symbol. For example, if the type opcodes is declared as

   type opcodes is
    (nop, add, subtract, load, store, jump, jumpsub, branch, halt);

we could write an alternative including three of these values as choices:

   when load | add | subtract =>
    operand := memory_operand;

If we have a number of alternatives in a case statement and we want to include an alternative to handle all possible values of the selector expression not mentioned in previous alternatives, we can use the special choice others. For example, if the variable opcode is a variable of type opcodes, declared above, we can write

   case opcode is
    when load | add | subtract =>
      operand := memory_operand;
    when store | jump | jumpsub | branch =>
      operand := address_operand;
    when others =>
      operand := 0;
   end case;

In this example, if the value of opcode is anything other than the choices listed in the first and second alternatives, the last alternative is selected. There may only be one alternative that uses the others choice, and if it is included, it must be the last alternative in the case statement. An alternative that includes the others choice may not include any other choices. Note that, if all of the possible values of the selector expression are covered by previous choices, we may still include the others choice, but it can never be matched.

The remaining form of choice that we have not yet mentioned is a discrete range, specified by these simplified syntax rules:

   discrete_range ⇐
      discrete_subtype_indication
      | simple_expression ( to | downto ) simple_expression
   subtype_indication ⇐
      type_mark
          [ range simple_expression ( to | downto ) simple_expression ]

These forms allow us to specify a range of values in a case statement alternative. If the value of the selector expression matches any of the values in the range, the statements in the alternative are executed. The simplest way to specify a discrete range is just to write the left and right bounds of the range, separated by a direction keyword. For example, the case statement above could be rewritten as

   case opcode is
    when add to load =>
      operand := memory_operand;
    when branch downto store =>
      operand := address_operand;
    when others =>
      operand := 0;
   end case;

Another way of specifying a discrete range is to use the name of a discrete type, and possibly a range constraint to narrow down the values to a subset of the type. For example, if we declare a subtype of opcodes as

   subtype control_transfer_opcodes is opcodes range jump to branch;

we can rewrite the second alternative as

   when control_transfer_opcodes | store =>
    operand := address_operand;

Note that we may only use a discrete range as a choice if the selector expression is of a discrete type. We may not use a discrete range if the selector expression is of an array type, such as a bit-vector type. If we specify a range by writing the bounds and a direction, the direction has no significance except to identify the contents of the range.

An important point to note about the choices in a case statement is that they must all be written using locally static values. This means that the values of the choices must be determined during the analysis phase of design processing. All of the above examples satisfy this requirement. To give an example of a case statement that fails this requirement, suppose we have an integer variable N, declared as

   variable N : integer := 1;

If we wrote the case statement

   case expression is         -- example of an illegal case statement
    when N | N+1 => ...
    when N+2 to N+5 => ...
    when others => ...
   end case;

the values of the choices depend on the value of the variable N. Since this might change during the course of execution, these choices are not locally static. Hence the case statement as written is illegal. On the other hand, if we had declared C to be a constant integer, for example with the declaration

   constant C : integer := 1;

then we could legally write the case statement

   case expression is
    when C | C+1 => ...
    when C+2 to C+5 => ...
    when others => ...
   end case;

This is legal, since we can determine, by analyzing the model, that the first alternative includes choices 1 and 2, the second includes numbers between 3 and 6 and the third covers all other possible values of the expression.

The previous examples all show only one statement in each alternative. As with the if statement, we can write an arbitrary number of sequential statements of any kind in each alternative. This includes writing nested case statements, if statements or any other form of sequential statements in the alternatives.

Although the preceding rules governing case statements may seem complex, in practice there are just a few things to remember, namely:

   type sel_range is range 0 to 3;

   library ieee;  use ieee.std_logic_1164.all;

   entity mux4 is
    port ( sel : in sel_range;
           d0, d1, d2, d3 : in std_ulogic;
           z : out std_ulogic );
   end entity mux4;
   --------------------------------------------------
   architecture demo of mux4 is
   begin
    out_select : process (sel, d0, d1, d2, d3) is
    begin
      case sel is
        when 0 =>
          z <= d0;
        when 1 =>
          z <= d1;
        when 2 =>
          z <= d2;
        when 3 =>
          z <= d3;
      end case;
    end process out_select;
   end architecture demo;

   selected_variable_assignment ⇐
      [ label : ]
      with expression select
          name := { expression when choices , }
                  expression when choices ;

   with func select
    result := operand1            when pass1,
              operand2            when pass2,
              operand1 + operand2 when add,
              operand1 - operand2 when subtract;

Sometimes when writing models we need to state that when some condition arises, no action is to be performed. This need often arises when we use case statements, since we must include an alternative for every possible value of the selector expression. Rather than just leaving the statement part of an alternative blank, we can use a null statement to state explicitly that nothing is to be done. The syntax rule for the null statement is simply

   null_statement ⇐ [ label : ] null ;

The optional label serves to identify the statement. We discuss labeled statements in Chapter 20. A simple, unlabeled null statement is

   null;

An example of its use in a case statement is

   case opcode is
    when add =>
      Acc := Acc + operand;
    when subtract =>
      Acc := Acc - operand;
    when nop =>
      null;
   end case;

We can use a null statement in any place where a sequential statement is required, not just in a case statement alternative. A null statement may be used during the development phase of model writing. If we know, for example, that we will need an entity as part of a system, but we are not yet in a position to write a detailed model for it, we can write a behavioral model that does nothing. Such a model just includes a process with a null statement in its body:

   control_section : process ( sensitivity_list ) is
   begin
    null;
   end process control_section;

Note that the process must include the sensitivity list, for reasons that are explained in Chapter 5.

Often we need to write a sequence of statements that is to be repeatedly executed. We use a loop statement to express this behavior. There are several different forms of loop statements in VHDL; the simplest is a loop that repeats a sequence of statements indefinitely, often called an infinite loop. The syntax rule for this kind of loop is

   loop_statement ⇐
      [ loop_label : ]
      loop
          { sequential_statement }
      end loop [ loop_label ] ;

In most computer programming languages, an infinite loop is not desirable, since it means that the program never terminates. However, when we are modeling digital systems, an infinite loop can be useful, since many hardware devices repeatedly perform the same function until we turn off the power. Typically a model for such a system includes a loop statement in a process body; the loop, in turn, contains a wait statement.

   entity counter is
    port ( clk : in bit;  count : out natural );
   end entity counter;
   --------------------------------------------------
   architecture behavior of counter is
   begin
    incrementer : process is
      variable count_value : natural := 0;
    begin
      count <= count_value;
      loop
        wait until clk;
        count_value := (count_value + 1) mod 16;
        count <= count_value;
      end loop;
    end process incrementer;
   end architecture behavior;

   exit_statement ⇐
      [ label : ] exit [ loop_label ] [ when condition ] ;

   exit;

   if condition then
    exit;
   end if;

   loop
    ...
    exit when condition;
    ...
   end loop;
   ...          -- control transferred to here
            -- when condition becomes true within the loop

   entity counter is
    port ( clk, reset : in bit;  count : out natural );
   end entity counter;
   --------------------------------------------------
   architecture behavior of counter is
   begin
    incrementer : process is
      variable count_value : natural := 0;
    begin
      count <= count_value;
      loop
        loop
          wait until clk or reset;
          exit when reset;
          count_value := (count_value + 1) mod 16;
          count <= count_value;
        end loop;
        -- at this point, reset = '1'
        count_value := 0;
        count <= count_value;
        wait until not reset;
      end loop;
    end process incrementer;
   end architecture behavior;

   loop_name : loop
    ...
    exit loop_name;
    ...
   end loop loop_name;

   outer : loop
    ...
    inner : loop
      ...
      exit outer when condition_1;  -- exit 1
      ...
      exit when condition_2;        -- exit 2
      ...
    end loop inner;
    ...                             -- target A
    exit outer when condition_3;    -- exit 3
     ...
   end loop outer;
   ...                              -- target B

   exit when reset = '1';

   next_statement ⇐
      [ label : ] next [ loop_label ] [ when condition ] ;

   next;

   next when condition;

   next loop-label;

   next loop-label when condition;

   loop                            loop
    statement-1;                    statement-1;
    next when condition;            if not condition then
    statement-2;                      statement-2;
   end loop;                        end if;
                                 end loop;

While Loops

We can augment the basic loop statement introduced previously to form a while loop, which tests a condition before each iteration. If the condition is true, iteration proceeds. If it is false, the loop is terminated. The syntax rule for a while loop is

   loop_statement ⇐
      [ loop_label : ]
      while condition loop
          { sequential_statement }
      end loop [ loop_label ] ;

The only difference between this form and the basic loop statement is that we have added the keyword while and the condition before the loop keyword. All of the things we said about the basic loop statement also apply to a while loop. We can write any sequential statements in the body of the loop, including exit and next statements, and we can label the loop by writing the label before the while keyword.

There are three important points to note about while loops. The first point is that the condition is tested before each iteration of the loop, including the first iteration. This means that if the condition is false before we start the loop, it is terminated immediately, with no iterations being executed. For example, given the while loop

   while index > 0 loop
    ...      -- statement A: do something with index
   end loop;
   ...        -- statement B

if we can demonstrate that index is not greater than zero before the loop is started, then we know that the statements inside the loop will not be executed, and control will be transferred straight to statement B.

The second point is that in the absence of exit statements within a while loop, the loop terminates only when the condition becomes false. Thus, we know that the negation of the condition must hold when control reaches the statement after the loop. Similarly, in the absence of next statements within a while loop, the loop performs an iteration only when the condition is true. Thus, we know that the condition holds when we start the statements in the loop body. In the above example, we know that index must be greater then zero when we execute the statement tagged statement A, and also that index must be less than or equal to zero when we reach statement B. This knowledge can help us reason about the correctness of the model we are writing.

The third point is that when we write the statements inside the body of a while loop, we must make sure that the condition will eventually become false, or that an exit statement will eventually exit the loop. Otherwise the while loop will never terminate. Presumably, if we had intended to write an infinite loop, we would have used a simple loop statement.

Example 3.5. A cosine module

We can develop a model for an entity cos that might be used as part of a specialized signal processing system. The entity has one input, theta, which is a real number representing an angle in radians, and one output, result, representing the cosine function of the value of theta. We can use the relation

by adding successive terms of the series until the terms become smaller than one millionth of the result. The entity and architecture body declarations are:

   entity cos is
    port ( theta : in real;  result : out real );
   end entity cos;
   --------------------------------------------------
   architecture series of cos is
   begin
    summation : process (theta) is
      variable sum, term : real;
      variable n : natural;
    begin
      sum := 1.0;
      term := 1.0;
      n := 0;
      while abs term > abs (sum / 1.0E6) loop
        n := n + 2;
        term := (-term) * theta**2 / real(((n-1) * n));
        sum := sum + term;
      end loop;
      result <= sum;
    end process summation;
   end architecture series;

The architecture body consists of a process that is sensitive to changes in the input signal theta. Initially, the variables sum and term are set to 1.0, representing the first term in the series. The variable n starts at 0 for the first term. The cosine function is computed using a while loop that increments n by two and uses it to calculate the next term based on the previous term. Iteration proceeds as long as the last term computed is larger in magnitude than one millionth of the sum. When the last term falls below this threshold, the while loop is terminated. We can determine that the loop will terminate, since the values of successive terms in the series get progressively smaller. This is because the factorial function grows at a greater rate than the exponential function.

VHDL-87, -93, and -2002

Since these versions of VHDL do not perform implicit conversion of conditions to boolean, conditions in while loops must yield boolean results without conversion.

   loop_statement ⇐
      [ loop_label : ]
      for identifier in discrete_range loop
          { sequential_statement }
      end loop [ loop_label ] ;

   simple_expression ( to | downto | simple_expression

   for count_value in 0 to 127 loop
    count_out <= count_value;
    wait for 5 ns;
   end loop;

   type controller_state is (initial, idle, active, error);

   for state in controller_state loop
    ...
   end loop;

   erroneous : process is
    variable i, j : integer;
   begin
    i := loop_param;                -- error!
    for loop_param in 1 to 10 loop
      loop_param := 5;              -- error!
    end loop;
    j := loop_param;                -- error!
   end process erroneous;

   hiding_example : process is
    variable a, b : integer;
   begin
    a := 10;
    for a in 0 to 7 loop
      b := a;
    end loop;
    -- a = 10, and b = 7
    ...
   end process hiding_example;

   for i in 10 to 1 loop
    ...
   end loop;

   for i in 10 downto 1 loop
    ...
   end loop;

   architecture fixed_length_series of cos is
   begin
    summation : process (theta) is
      variable sum, term : real;
    begin
      sum := 1.0;
      term := 1.0;
      for n in 1 to 9 loop
        term := (-term) * theta**2 / real(((2*n-1) * 2*n));
        sum := sum + term;
      end loop;
      result <= sum;
    end process summation;
   end architecture fixed_length_series;

   loop_statement ⇐
      [ loop_label : ]
      [ while condition | for identifier in discrete_range ] loop
          { sequential_statement }
      end loop [ loop_label ] ;

One of the reasons for writing models of computer systems is to verify that a design functions correctly. We can partially test a model by applying sample inputs and checking that the outputs meet our expectations. If they do not, we are then faced with the task of determining what went wrong inside the design. This task can be made easier using assertion statements that check that expected conditions are met within the model. An assertion statement is a sequential statement, so it can be included anywhere in a process body. The full syntax rule for an assertion statement is

   assertion_statement ⇐
      [ label : ] assert condition
              [ report expression ] [ severity expression ] ;

The optional label allows us to identify the assertion statement. We will discuss labeled statements in Chapter 20. The simplest form of assertion statement just includes the keyword assert followed by a condition that we expect to be true when the assertion statement is executed. If the condition is not met, we say that an assertion violation has occurred. If an assertion violation arises during simulation of a model, the simulator reports the fact. During synthesis, the condition in an assertion statement may be interpreted as a condition that the synthesizer may assume to be true. During formal verification, the condition may be interpreted as a condition to be proven by the verifier. For example, if we write

   assert initial_value <= max_value;

and initial_value is larger than max_value when the statement is executed during simulation, the simulator will let us know. During synthesis, the synthesizer may assume that initial_value <= max_value and optimize the circuit based on that information. During formal verification, the verifier may attempt to prove initial_value <= max_value for all possible input stimuli and execution paths leading to the assertion statement.

If we have a number of assertion statements throughout a model, it is useful to know which assertion is violated. We can get the simulator to provide extra information by including a report clause in an assertion statement, for example:

   assert initial_value <= max_value
    report "initial value too large";

The string that we provide is used to form part of the assertion violation message. We can write any expression in the report clause provided it yields a string value, for example:

   assert current_character >= '0' and current_character <= '9'
    report "Input number " & input_string & " contains a non-digit";

Here the message is derived by concatenating three string values together. We can use the to_string operation to get a string representation of a value to include in a message, for example:

   assert initial_value <= max_value
    report "initial value " & to_string(initial_value)
           & " too large";

In Section 2.2, we mentioned a predefined enumeration type severity_level, defined as

   type severity_level is (note, warning, error, failure);

We can include a value of this type in a severity clause of an assertion statement. This value indicates the degree to which the violation of the assertion affects operation of the model. The value note can be used to pass informative messages out from a simulation, for example:

   assert free_memory >= low_water_limit
    report "low on memory, about to start garbage collect"
    severity note;

The severity level warning can be used if an unusual situation arises in which the model can continue to execute, but may produce unusual results, for example:

   assert packet_length /= 0
    report "empty network packet received"
    severity warning;

We can use the severity level error to indicate that something has definitely gone wrong and that corrective action should be taken, for example:

   assert clock_pulse_width >= min_clock_width
    severity error;

Finally, the value failure can be used if we detect an inconsistency that should never arise, for example:

   assert (last_position - first_position + 1) = number_of_entries
    report "inconsistency in buffer model"
    severity failure;

We have seen that we can write an assertion statement with either a report clause or a severity clause, or both. If both are present, the syntax rule shows us that the report clause must come first. If we omit the report clause, the default string in the error message is “Assertion violation.” If we omit the severity clause, the default value is error. The severity value is usually used by a simulator to determine whether or not to continue execution after an assertion violation. Most simulators allow the user to specify a severity threshold, beyond which execution is stopped. The VHDL standard recommends that, in the absence of such a specification, simulation continue for assertion violations with severity error or less.

Usually, failure of an assertion means either that the entity is being used incorrectly as part of a larger design or that the model for the entity has been incorrectly written. We illustrate both cases.

   entity SR_flipflop is
    port ( S, R : in bit;  Q : out bit );
   end entity SR_flipflop;
   --------------------------------------------------
   architecture checking of SR_flipflop is
   begin
      set_reset : process (S, R) is
      begin
        assert S nand R;
        if S then
          Q <= '1';
        end if;
        if R then
          Q <= '0';
        end if;
      end process set_reset;
   end architecture checking;

   entity max3 is
    port ( a, b, c : in integer;  z : out integer );
   end entity max3;
   --------------------------------------------------
   architecture check_error of max3 is
   begin
      maximizer : process (a, b, c)
        variable result : integer;
      begin
        if a > b then
          if a > c then
            result := a;
          else
            result := a;  -- Oops!  Should be: result := c;
          end if;
        elsif  b > c then
          result := b;
        else
          result := c;
        end if;
        assert result >= a and result >= b and result >= c
          report "inconsistent result for maximum:"
                 & to_string(result)
          severity failure;
        z <= result;
      end process maximizer;
   end architecture check_error;

Another important use for assertion statements is in checking timing constraints that apply to a model. For example, most clocked devices require that the clock pulse be longer than some minimum duration. We can use the predefined primary now in an expression to calculate durations. We return to now in a later chapter. Suffice it to say that it yields the current simulation time when it is evaluated.

   entity edge_triggered_register is
    port ( clock : in bit;
           d_in : in real;  d_out : out real );
   end entity edge_triggered_register;
   --------------------------------------------------
   architecture check_timing of edge_triggered_register is
   begin
    store_and_check : process (clock) is
      variable stored_value : real;
      variable pulse_start : time;
    begin
      if rising_edge(clock) then
        pulse_start := now;
        stored_value := d_in;
        d_out <= stored_value;
      else
        assert now = 0 ns or (now - pulse_start) >= 5 ns
          report "clock pulse too short:"
                 & to_string(now - pulse_start);
      end if;
    end process store_and_check;
   end architecture check_timing;

VHDL also provides us with a report statement, which is similar to an assertion statement. The syntax rule for the report statement shows this similarity:

   report_statement ⇐
      [ label : ] report expression [ severity expression ] ;

The differences are that there is no condition, and if the severity level is not specified, the default is note. Indeed, the report statement can be thought of as an assertion statement in which the condition is the value false and the severity is note, hence it always produces the message. One way in which the report statement is useful is as a means of including “trace writes” in a model as an aid to debugging.

   transmit_element : process (transmit_data) is
   ...       -- variable declarations
   begin
    report "transmit_element: data = "
           & to_string(transmit_data);
    ...
   end process transmit_element;

Both assertion statements and report statements allow inclusion of a message string to provide useful information. In some cases, the information we wish to provide may be extensive and not fit entirely on a single line when displayed. We can include the line-feed character in the message string to break the message over multiple lines. A line-feed is represented by the identifier LF of type character. For example:

   assert data = expected_data
    report "%%%ERROR data value miscompare." & LF &
            " Actual value = " & to_string(data) & LF &
            " Expected value = " & to_string(expdata) & LF &
            " at time: " & to_string(now) );

The message produced when this assertion is violated consists of four lines of text. A VHDL tool interprets the line feed characters using the appropriate convention for the host operating system. For example, if a Unix-based system were to write the message to a file, it would just include the line-feed characters. A Windows-based system, on the other hand, would write a carriage-return/line-feed pair for every line-feed in the message.

   report "Initialization complete";

   assert false
    report "Initialization complete" severity note;