The simplest kind of assertion is to check whether a signal’s value is within an expected range. This is done by comparing the signal’s value with a minimum bound and a maximum bound. If the value lies outside the bound, an error has occurred. Sample code that checks whether signal S is out of bound [LOWER, UPPER] is

if ( 'LOWER > S || S > 'UPPER )
   $display ("signal S = %b is out of bound");

An assertion may not need to be active all the time. For instance, during the power-on period, S may not have been initialized and the assertion should be turned off. To activate the assertion only when S is ready, a triggering expression is added:

always @(posedge clock)
begin
if ( (ready_to_check == 1'b1) && ('LOWER > S || S > 'UPPER ))
   $display ("signal S = %b is out of bound");
end

Many assertions used in practice fall into this type of assertion, sometimes with a minor change. Table 5.3 lists some variants of signal range assertion.

Checking whether signal A is equal to an unknown value cannot be done by simply comparing A with x, because A can have multiple bits. The assertion is to ensure that no bit of A has an unknown value. This assertion is needed in situations when data patterns are expected on A (for instance, data bus to memory during a write cycle). A brute-force check is to go through each bit of A and compare it with 1’bx. A more clever method is to use a reduction XOR operator, ^. A reduction XOR performs XOR on all the bits of A, one by one. By definition of XOR, if at any time an operand has an unknown value X, the result will be X regardless of other operand values. Thus, the reduction XOR will produce an X result if and only if at least 1 bit of A is X. The Verilog code to check for an unknown value on signal A is

if ( ^A == 1'bx) $display ("ERROR: unknown value in signal A");

A signal is of even parity if the number of 1s is even, such as ^A gives 0. Similarly, A is odd parity if ^A is 1. To check a signal’s parity, reduction XOR can be used, which XORs all bits of the signal together. If the result is 1, the parity is odd; otherwise, it is even. The code for checking even and odd parity is as follows:

if ( ^A == 1'b0) $display ("info: signal A is even parity");
if ( ^A == 1'b1) $display ("info: signal A is odd parity");

This type of assertion ensures that a set of signals is equal to expected values or differs from unwanted values. The expected values can be valid opcodes and the unwanted values can be unknown values. As an example, consider checking an instruction variable, instr, against a list of legal opcodes: BEQ, JMP, NOOP, SHIFT, and CLEAR. The comparison can be done by using either the comparison operator == or a case statement, as shown here. The macros (for example, BEQ and JMP) are defined to be the corresponding opcode binaries:

'define BEQ 1010
'define JMP 1100
'define NOOP 0000
'define SHIFT 0110
'define CLEAR 1000

if( (instr != 'BEQ)   && 
    (instr != 'JMP)   && 
    (instr != 'NOOP)  && 
    (instr != 'SHIFT) && 
    (instr != 'CLEAR))
$display ("ERROR: illegal instruction instr = %b", instr);

Or, embed a case statement within the body of an instruction execution unit:

case (instr):
   'BEQ: execute_beq();
   'JMP: execute_jmp();
   'NOOP: execute_noop();
   'SHIFT: execute_shift();
   'CLEAR: execute_clear();
   default:
   $display ("ERROR: illegal instruction instr = %b", instr);
endcase

Several signals can be concatenated and compared against a set of legal values. Grouping signals gives a more concise description and opens the opportunity for using don’t-cares in the expressions, as illustrated next. For example, we restrict single-bit signals reset, load, cs, hold, and flush to the values {10001, 11001, 00110, 01110}, which can be simplified using don’t-care notation to {1?001, 0?110}. To take advantage of don’t-cares, use the casez statement for comparison:

sigSet = {reset, load, cs, hold, flush}
casez (sigSet) :
   1?001: // do something
   0?110: // do other thing
   default:
      $display ("illegal control signals ...);
endcase

A signal is one-hot if exactly 1 bit of the signal is 1 at any time. To assert the one-hot property, instead of comparing the bits of the signal with 1, 1 bit at a time, the following simple code accomplishes the goal:

if ( |(B & (B - 'WIDTH'b1)) != 1'b0 )
   $display ("Bus B is not one hot, B = %b", B);

The macro WIDTH is the width of signal B. To see why this expression detects the one-hot property, try sample value B equals 8'b00010000.

                B : 8'b00010000
         B - 8'b1 : 8'b00001111     // subtract 1
   B & (B - 8'b1) : 8'b00000000     // bitwise AND
| (B & B - 8'b1 ) : 1'b0            // reduction OR

If B is not one-hot, say, B equals 8'01001000, then

              B : 8'b01001000
         B-8'b1 : 8'b01000111
   B & (B-8'b1) : 8'b01000000
| (B & B-8'b1 ) : 1'b1

Sometimes, a one-hot signal has a 0 value when it’s not active. A 0 value is not one-hot, but the previous algorithm does not distinguish 0 from one-hot. To eliminate 0 from being one-hot, a comparison with 0 is added to the previous one-hot-checking code, as follows:

if ((B != 'WIDTH'b0) &&                    
    ( | (B & (B - 'WIDTH'b1)) != 1'b0 ))

In addition, some bits of a one-hot signal can have unknown values when inactive. To accommodate this situation, a check for value X is added to the one-hot assertion, as follows:

if ((^B != 1'bx) &&                       
    (B != 'WIDTH'b0) &&                   
    (|(B & (B - 'WIDTH'b1)) != 1'b0 ))

OR

if ((^B != 1'bx) &&                          
    (|B != 1'b0) &&                          
    (|(B & (B - 'WIDTH'b1)) != 1'b0 ))

A one-cold signal, on the other hand, has exactly 1 bit equal to 0. To assert on one-cold, invert the signal bit by bit and use the previous one-hot assertion:

B = 'WIDTH{1'b1} ^ C;

where C is a one-cold signal. ’WIDTH{1’b1} creates a mask of 1s with a width of ’WIDTH (for example, 8{1’b1} is 8’b11111111).

Sequential assertions involve past and future values of variables. The key is to create a signal archive that saves the past values of the variables. A simple archiving mechanism is a shift register file for each variable such that at each clock transition, the current value of the signal is shifted in. The length is the register file equal to the history required for the assertion. The shift register file is clocked by the variable’s reference clock. To evaluate an assertion, the past values of the variables are retrieved from the shift register files. For example, consider writing an assertion to ensure that a Gray-coded signal changes exactly 1 bit at a time. The assertion first determines the bits that change by bitwise XORing the current value with that of the previous cycle (A = S-1 ^ S). If a bit changes, the corresponding bit position in A is 1. Then we determine how many bits have changed by checking whether A is one-hot. If A is one-hot or 0, the signal did not violate the Gray coding requirement. The code is as follows:

A = prev_S ^ S; // prev_S = S-1
if (~((A == 0) || | (A & (A-1) ) ) // one-hot assertion
   $display ("ERROR: Gray code violation");

where S-1 or prev_S can be obtained as follows:

initial
   curr_S = 1'bx;
   // assume S (curr_S) is one-bit; or use ('WIDTH-1) {1'bx}

always @(posedge clock)
begin
   prev_S = curr_S;
   curr_S = S;
end

In general, to save the previous N values of a signal S, a circular queue of length N + 1 is used, N slots for the N past values plus one slot for the current value. Figure 5.11A illustrates the movement of the queue over time. The queue rotates clockwise one slot every time the clock clicks, but the external labels (S, S-1, ..., S-N) remain stationary. At every clock tick, the current value of the signal is stored in the slot facing label S. Thus, after N clock ticks, the queue is fully filled, and now all N past values are available. A piece of Verilog code implementing the circular queue is as follows:

reg ['WIDTH-1:0] CQ [N:0]; // WIDTH is width of S
integer i; // index of the current cycle
integer j; // index of the jth past value

initial i = N;

always @(posedge clock)
begin
   i = i + 1 ;
   i = i % (N+1); // circular index
   CQ[i] = S; // present value
   // retrieving kth past value
   j = (i-k>=0) ? i-k : i-k+N+1 ; // calculate circular index
   prev_k_S = CQ[j];
end

Figure 5.11. Circular queue for archiving past signal values. (A) A circular queue before a clock tick. (B) A circular queue rotates after a clock tick.

Signal S-k, 1 ≤ k ≤ N, is CQ[j], where j = i - k, if i - k is nonnegative; otherwise, j = i - k + N + 1.

Once past values of signals are computed, assertions over the history of signals can be written. An example assertion over signal history is as follows: If Req is 1, then Ack should turn 1 three cycles later, which causes Req to return to 0 seven cycles later. Whether this assertion fails will not be known until ten cycles after Req becomes 1. After Req has become 1, values of Ack and Req are archived for the next ten cycles. By then, passage of the assertion can be determined. Let prev_k_Req and prev_k_Ack denote the past k^th value of Req and Ack respectively:

if (prev_10_Req == 1'b1)
   if ( !(prev_7_Ack == 1'b1 && Req == 1'b0) )
      $display ("ERROR: assertion failed");

If we use circular queues CQ_Ack and CQ_Req for Ack and Req respectively, and choose N to be ten, then the assertion takes the form

always @(posedge clock) begin
   i = i + 1;
   i = i % 11;
   j1 = (i−7>=0) ? i−7 : i + 4; // index for Ack
   j2 = (i−10>=0) ? i−10 : i + 1 ; // index for Req
   if (CQ_Req[j2] == 1'b1)
      if (!(CQ_Ack[j1] ==1'b1 && Req == 1'b0) )
         $display ("ERROR: assertion failed");
end

Note that this code should be activated after at least ten cycles have passed.

Once the history of signals is available, and together with combinational assertions, we can obtain assertions on many common signal properties. Table 5.4 lists some common assertions that can be implemented by applying combinational assertions to the signals’ history.

These assertions determine whether a signal does or does not change over a period of time or within a period specified by a pair of events. In the case when the time period is delimited by a number of cycles, a repeat statement can be used to perform the check. For instance, assume that a signal must remain unchanged for N cycles, checking is done by embedding S⁻¹ == S in a repeat loop of N iterations. In the code, signal S is sampled at every positive transition of the clock, and thus it is assumed that signal S changes only at the clock’s transitions:

repeat (N)
   @(posedge clock)
      if (prev_S != S) $display ("ERROR...");

In the other case, when the interval is specified by a pair of events, signal S must be monitored for changes all the time, not just at some clock transitions. This situation is related to an asynchronous timing specification and it is discussed in “Unclocked Timing Assertions” on page 243.

The previous discussion assumes that the cycle numbers of the past values are specified, such as signal value seven cycles ago. On the other hand, if a range, instead of the exact cycle number, is specified (such as, S will rise some time between cycle 1 and cycle 10 after signal Ready is set), then the assertion can be implemented by embedding the check inside a loop with an iteration count equal to the range. The following code asserts that S will rise some time from cycle 1 to cycle 10 after signal Ready is set. When S rises, it immediately disables the block. If S does not rise after ten cycles, an error will be displayed:

always @(posedge clock)
begin: check // named block
   if ( Ready == 1'b1 ) begin
      repeat (10) @(posedge clock)
         if ( (prev_S != S) && (S == 1'b1) ) disable check;
          // assertion passes, exit
   end
   $display ("ERROR: assertion failed");
end // end of named block, check

Similar code can be written for assertions about an event that should not occur throughout an interval. If the event occurs within the interval, an error message is issued and the block is disabled. If not, it silently passes. For example, the following code asserts that address [31:0] remain steady for ten cycles after WR becomes one:

always @(posedge clock)
begin: check
   if (WR == 1'b1)
      repeat (10) @(posedge clock)
         if ( prev_Address != Address ) begin
            $display ("ERROR: Address changed");
            disable check;
         end
end // end of named block, check

Thus far, all timing constraints use a clock cycle as a reference. Hence, this way of constraining is not applicable for assertions that do not have explicit clocks. Situations with no reference clocks occur in high-level specifications that constrain the order of event occurrences without specific delays. For instance, signal R must toggle after signal S becomes high, with no requirement on how soon or how late R must toggle. Here we need to study two cases. The first case concerns an expression that should remain steady within an interval. The second case involves an expression that should attain a certain value within an interval. The interval is defined by two transitions—one signaling the beginning and the other signaling the end. An example of the first case is that the WR line must not change during a read or write cycle. An example of the second case is that signal Grant must attain a value and remain steady until signal Req is lowered. Unlike the situations with reference clocks, the expressions must be constantly monitored throughout the interval, as opposed to monitoring just at clock transitions.

To construct an assertion for the first case, the delimiting events and the expressions or signals are monitored using the event control operator @. The following example code ensures that S remains steady throughout the interval marked by events E1 and E2. The assertion is active only when guarding signal Start becomes 1. Two named blocks are created: one block waiting on E1 and the other, E2. If the assertion fails before E2 arrives, an error is displayed and the E2 block is disabled. If E2 arrives before any failure, the E1 block is disabled:

always @(posedge Start) // guarding statement
begin: check
   @ (E1);
   @ (S) $display ("ERROR: signal S changes");
      disable stop;
end

always @(posedge Start) // guarding statement
begin: stop
   @ (E2) disable check;
end

To prevent a hanging situation, when E2 never arrives, another block can be created to impose an upper time limit on the interval:

always @(E1)
begin: time_limit
   @(posedge clock) begin
      count = count + 1;
      if (count > LIMIT) begin
         $display ("ERROR: interval too long");
         disable check
         disable stop; // disable the ending block
      end
   end
end

When E2 arrives, block stop has to disable block time_limit because the stopping event has already arrived, and thus checking for its arrival time becomes irrelevant. A modified block stop is as follows:

always @(posedge Start) // guarding statement
begin: stop
   @ (E2) begin
      disable check;
      disable time_limit;
   end
end

For the second case that asserts an expression to attain a certain value during an interval, the expression is first monitored for changes. When a change occurs, the value of the expression is checked. The interval is instrumented with two named blocks: one block waiting on the first event and the second block waiting on the second event. We can illustrate this with the assertion that signal Grant cannot change until signal Req lowers, and this sequence of transitions must happen within an interval:

always @(posedge Start) // guarding statement
begin: check
   @ (E1); // beginning event
   @ (posedge Grant)
   if (Req != 0) $display ("ERROR: Grant changed at Req = 1");
   disable stop;
end

always @(posedge Start) // guarding statement
begin: stop
   @ (E2) $display ("ERROR: Grant never changed");
   disable check;
end

If signal Grant changes within the interval, the value of Req is checked. If it’s not 0, an error will be issued. In either case, block stop will be disabled when Grant arrives. Therefore, if block stop has not been disabled when event E2 arrives, it means that signal Grant never changed in the interval and an error will be issued.

Assertions can also check the integrity of the data without knowing the exact data values. These assertions ensure that design entities remain intact after they have gone through processing. An example is that the content of a cache block remains the same from the time it is filled to the time it is first accessed. Another example is that a packet received is the same packet sent, even though the packet has undergone encoding, transmission, and decoding. This type of assertion contains local variables or containers that save the data before processing, and use the saved data to compare with the data after processing. Let’s illustrate container assertion with following packet transmission example.

In this example, packets are encoded, transmitted through a network, decoded, and received. We want to write a container assertion to check for data integrity of the packets—namely, the received packets were not corrupted during the process. We assume each packet is identified by an ID and packets arrive in the same order they are sent. When a packet is sent, signal SEND toggles. The container assertion has two FIFOs: one for the packet ID and the other for the packet data. When SEND toggles, the packet’s ID is pushed into id_FIFO, and the packet data are saved in packet_FIFO. The packet also carries its ID. On the receiving end, when a packet arrives, signal RECEIVE toggles, and the ID is extracted from the packet. At the same time, an ID is also retrieved from id_FIFO for comparison. If there is no match, an error is issued. If there is a match, the saved data are retrieved from packet_FIFO and are compared with those of the received packet. If there is a difference, an error has occurred. The transmission process and its interactions with the assertion are shown in Figure 5.12.

Figure 5.12. Assertion to check for packet integrity

The following abridged code implements the container assertion:

always @(SENT) begin
   push_idFIFO(ID);
   push_packetFIFO( packet);
end

always @(RECEIVE) begin
   ID1 = get_FIFO();
   ID2 = get_ID_from_packet (packet);
   if (ID1 != ID2) $display ("ERROR: packet out of order");
   else begin
      org_packet = get_original_packet (packet_FIFO);
      ok = compare_packet (packet, org_packet);
      if (!ok) $display ("ERROR: packet corrupted");
   end
end

If we relax the requirement that the arrival order has to be the same as the sending order, id_FIFO would have to be replaced by another data structure that is more amicable to matching, such as a hash table. Then, when a packet arrives, its ID is extracted and is sent to the hash table for matching. If it is found, the packet content is then compared; otherwise, an error has occurred.

The key to construct a sequence is to specify time. The first constructor is cycle delay specifier ##. ## N means N cycles of delay, and N can be any nonnegative integer. As an example, x₁ ##3 x₂ is equivalent to (x₁, t₁), (x₂, t₁ + 3). In other words, x₂ is delayed by three cycles relative to the previous time. The argument of ## can be a range (##[n,m]), which means the delay is any number between n and m. For example, x₁##[1,3] x₂ is equivalent to the following:

     x1 ##1 x2
     or
     x1 ##2 x2
     or
     x1 ##3 x2

Therefore, for x₁##[1,3]x₂ to be true, at least one of the previous sequences must be true. Consider the waveforms in Figure 5.14. x₁ ##1 x₂ is satisfied at time 7 if it starts at time 6, because at time 6, x₁ is true and one cycle later x₂ becomes true. However, x₁ ##2 x₂ and x₁ ##3 x₂ are not satisfied with the waveforms. Therefore, sequence x₁ ##[1,3] x₂ is satisfied by the waveforms. To specify an unbound upper limit, $ denotes infinity (for example, ##[1,$] means any number of cycles greater than or equal to one).

Figure 5.14. Example waveforms for a sequence

As an example of constructing a sequence, consider the order of events that signal req is high, followed by ack going high three cycles later, and ending with req going low seven cycles later. The sequence is req ## 3 ack ## 7 !req. This sequence is true if and only if the previously described pattern occurs.

Just like a module, a sequence can be defined, with or without arguments, and can be instantiated elsewhere. For example, to define sequence mySeq, enclose the sequence within keywords sequence and endsequence:

     sequence mySeq ;
   ##1 x1 (x2) [*2,8] ##3 x1
     endsequence

To instantiate, just call mySeq,

     ##3 y mySeq #1 x

which is equivalent to

     ##3 y ##1 x1 (x2) [*2,8] ##3 x1 #1 x

To define a sequence with parameters, enclose the parameters inside a pair of parentheses. The following is an example of defining sequence seqParam with parameters a and b:

     sequence seqParam (a,b);
   ##1 a x1 ##3 (x1 == b)
endsequence

To instantiate the sequence, just call it by name and substitute values for the parameters. For example, the following instantiation

     seqParam (y,z)

is equivalent to

        ##1 y x1 ##3 (x1 == z)

Larger sequences can be formed from sequences using connective operators, so that complex assertions can be built from simple ones. To duplicate a sequence over time, use the repeat operator [*N], which duplicates the preceding expression N times with one cycle delay inserted between duplicates. For example, (x₁+x₂) [*3] is equivalent to the following:

     (x1 + x2) ##1 (x1 + x2) ##1 (x1 + x2) // duplicate 3 times

Note the one cycle delay was inserted between the duplicates. The argument of the repeat operator, N, can be a range (for example, [*n,m]) in which case it repeats for a number of times j, where n≤j≤m. For example, (x₁+x₂) [*1,3] is equivalent to the following:

     (x1 + x2)
     or
     (x1 + x2) ##1 (x1 + x2) // duplicate 2 times
     or
     (x1 + x2) ##1 (x1 + x2) ##1 (x1 + x2) // duplicate 3 times

Instead of separating duplicates by exactly one clock cycle, as in repeat operator [*n,m], two variants of the repeat operation allow arbitrary intervals between duplicates. To create patterns with arbitrary intervals between duplicates, use nonconsecutive repeat operators [*->n,m] or [*=n,m]. Nonconsecutive repeat operators allow other patterns to be inserted between duplicates. For example, x₁##1x₂ [*->1,3] ##1x₃ is equivalent to

     x1 ##1 (y ##1 x2) [*1,3] ##1 x3

where y is any sequence, including an empty sequence, that does not have x2 as a subsequence. Therefore, x₁ ##1 (x₄ ##1 x₂) (x₅ ##1 x₂) ##1 x₃ is an instance described by the previous construct. Formally, x₁ ##1 x₂ [*->1,3] ##1 x₃ is equivalent to

     x1 ##1 (!x2 [*0,$] ##1 x2) [*1,3] ##1 x3

Repeat operator [*=n,m] is a slight variation of [*->n,m] in that a ##1 is appended to the end of the result from the operator. That is, x₁ ##1 x₂[*=n,m] ##1 x₃ is equivalent to

     x1 ##1 (!x2 [*0,$] ##1 x2) [*n,m] ##1 !x2 [*0,$] ##1 x3

Sequence connectives build new sequences from existing ones. To build new sequences, some connectives place constraints on the operand sequences, such as start times and lengths, to make the resulting sequences meaningful. The idea behind sequence connectives is twofold. First, it makes creating complex sequences easy; second, it extends operations on variables to sequences so that temporal reasoning can be carried out in a manner similar to Boolean reasoning.

Sequences can be logically ANDed if the operand sequences start at the same time. Operation (sequence1 AND sequence2) is true at time t if and only if both sequences are true at time t, or one sequence is true at time t and the other has already become true at time t. Let’s use Figure 5.15 to determine whether S1 AND S2 is true on the given signal waveforms of x₁ and x₂, where S₁ = x₁ ##2 and S₂ = ##1 x₂ ##2 ##1 (x₁ + ). The horizontal double–arrowhead lines denote the time interval a sequence is evaluating, from the start time to the end time. Assume the current time is cycle 1. Sequence S1 starts at time 1 and ends at time 3. In cycle 1, the expression is x₁, and in cycle 3, the expression is . From the waveforms, we see x₁ is 1 at cycle 1, and at cycle 3, x₁ is 0 and x₂ is 1. Therefore, S1 becomes true at cycle 3. The same goes for sequence S2, which becomes true at cycle 5. Hence, S1 AND S2 is true at cycle 5.

Figure 5.15. Signal traces satisfy S1 AND S2

For intersection operation, sequence1 intersect sequence2 is true at time t if and only if both sequences are true at time t. This operator requires that both operand sequences start and end at the same time. Therefore, we cannot perform intersection on the sequences in Figure 5.15, because S1 and S2 do not end at the same time. If we change S1 to S₁ = x₁ ##2 ##2 (x₁x₂), then S1 intersect S2 becomes true at cycle 5, because both sequences become true at cycle 5, as shown in Figure 5.16. If either or both sequences have multiple matches, only the pairs with the same start time and end time are considered.

Figure 5.16. Signal waveforms satisfy S1 intersect S2

sequence1 OR sequence2 is true at time t if and only if at least one sequence is true at time t. Both operand sequences start at the same time. For the sequences in Figure 5.15, S1 OR S2 is true at cycles 3, 4, and 5, because S1 is true at these times.

Operator first_match takes in a sequence and returns true when the sequence first becomes true. If the sequence expands to multiple sequences, such as ##[2,5](x₁x₂) expanding to four sequences, then first_match returns true when any of the expanded sequences first becomes true. The end time of first_match is the time it turns true. Figure 5.17 shows the operation of first_match. ##[2,5] (x₁x₂) expands to ##2 (x₁x₂) or ##3 (x₁x₂) or ##4 (x₁x₂) or ##5 (x₁x₂). Of these, ##2 (x₁x₂) and ##4 (x₁x₂) are true for the given waveforms. Operator first_match detects the first time the sequence becomes true (at cycle 3, ##2 (x₁x₂)). Thus, it returns true and ends at cycle 3.

Figure 5.17. Example of first_match operation

This operation is the same as the Boolean implication operator, A → B, which is Ā + A · B, except that it applies to sequences (for example, sequence₁| → sequence₂). If sequence₁ is true at time t, then sequence₂ starts at time t and its valuation determines that of the implication. If sequence₁ is false, then the implication is true. A variation is sequence₁|⇒ sequence₂ for which sequence₂ starts one cycle after sequence₁ becomes true. An example use of sequence implications is when an interrupt signal arrives, the processor will wait up to three cycles. If all in-flight tasks are finished by then, the control is transferred to an interrupt handler in the next cycle. Once control is in the interrupt handler, it should finish within 20 cycles. Let INT, TASK, HDLR, and DONE denote the interrupt signal, in-flight task done signal, signal to start the interrupt handler, and handler finish signal respectively. This behavior can be described as (INT ## [0,3] TASK) |=> HDLR ## [1,20] DONE. This assertion is true at cycle 7 for the waveforms shown in Figure 5.18.

Figure 5.18. Implication assertion for interrupt and interrupt handler

This operator, E throughout S, where E is an expression and S is a sequence, imposes expression E on sequence S. Recall that a sequence is {(Bi,Ti),i ε V}. Then E throughout S is {(E . Bi,Ti),i ε V}. An example is (x₁ + x₂) throughout (##1 x₃ ##2 x₄), which is equivalent to (##1 (x₁ + x₂)x₃ ##2 (x₁ + x₂)x₄). An applicable situation is that S is an assertion packaged with an IP module and the expression E is a condition describing the environment in which the IP is instantiated (for example, the peripheral signals to the IP must be within the correct ranges required by the IP). For the IP instance to work properly, the environment expression E must be true throughout the interval that the IP assertion holds. In other words, E is a predicate guarding the application of S.

This operator, sequence₁ within sequence₂, tests whether sequence₁ lies within sequence₂ and whether both sequences succeed. This operation requires that sequence₁ start and end after sequence₂ starts and before sequence₂ ends. The operation becomes true if sequence₁ has become true and is true when sequence₂ is true. S₁ within S₂ is equivalent to

(1 ##1) [*0,$] S1 (##1 1) [*0,$] intersect S2

An applicable scenario is that throughout an exclusive critical-section access, the ID of the accessing process should not change. Let S1 = (ID == $past (ID)) [*6], S2 = (ACCESS ##5 !ACCESS), where $past is a system function that returns the previous cycle value of the operand and thus (ID == $past (ID)) is true if ID has not changed since the last cycle. Sequence S₁ asserts that the ID remain the same for six cycles, whereas sequence S₂ asserts that access be done within five cycles. If variable ID does not change while the critical section is being accessed, (S2 within S1) is true. Figure 5.19 shows signal waveforms satisfying (S2 within S1).

Figure 5.19. Asserting critical-section access using the within operator

A sequence can have local variables to hold data that are to be used in the future. An application checks whether the data that popped out of a stack are the same as the data pushed. The assertion uses a local variable to save the data when it is pushed into the stack. When the data are popped out, they are compared with the saved version. The following assertion does this check, saving data when push is high and comparing the popped data seven cycles later when it is popped. The container operator is the comma that separates push and the assignment in the antecedent:

int orig;
(push, orig = data |-> ##7 data = orig)

This operator, sequence.ended, returns true at the time when the sequence becomes true—that is, the time the sequence ends. An example application is to assert that signal grant lowers two cycles after sequence transaction finishes:

( transaction.ended ##2 !grant )

Built-in system functions in SystemVerilog simplify code writing. Some system functions are $onehot, $onehot0, $inset, $insetz, $isunknown, $past, and $countones. A system function takes in expressions as arguments, such as $onehot (bus) and returns the advertised value. The following list explains some common system functions.

So far, the number of clock cycles has referred to an inferred clock, which is the clock of the domain in which the assertion is embedded. SystemVerilog provides a way to write assertions driven by multiple clocks and references the cycle delays to their respective clocks. For instance, consider the sequence

@(posedge clk1) x1 ## (posedge clk2) x2

In this sequence, at every posedge of clk1, x1 is checked. If x1 is true, then on the next posedge of clk2, x2 is checked. Thus, ## serves as a synchronizer between the two clocks. If clk1 and clk2 are identical, the previous sequence reduces to

@(posedge clk1) x1 ##1 x2

Sequences can be defined and instantiated, making sequences reusable. The following code defines a sequence, called testSequence, to be ##1 A ##2 B ##3 (x == y):

sequence testSequence (x,y);
   ##1 A ##2 B ##3 (x == y)
endsequence

To instantiate testSequence, just invoke it by name, as shown here in another sequence definition:

sequence callSequence;
   @(posedge clock) testSequence (p,q)
endsequence

This sequence, callSequence, is equivalent to

@(posedge clock) ##1 A ##2 B ##3 (p == q)

The purpose of defining sequences is to facilitate assertion construction on temporal behavior. Expressions and sequences form properties that are asserted by assertions. SystemVerilog provides a way to define properties and instantiate them in different assertions. To define a property:

property SteadyID (x)
   @(posedge clock) (x == $past (x)) [*6]
endproperty

To assert property SteadyID:

assert property SteadyID (procID)

Statement coverage collects statistics about statements that are executed in a simulation. For example, consider the code in Figure 5.20. Excluding the begin, end, and else lines, there are ten statements. If a simulation run is such that a > x at line 5 and x == y at line 12 are true, then all statements except those on lines 10, 11, 14, and 15 are executed in this run, as indicated by the arrows in Figure 5.20. Again excluding the begin, end, and else lines, eight lines are executed, giving 80% statement coverage.

Figure 5.20. Sample code for statement coverage

Note that in Figure 5.20, once line 3 is reached, line 4 will be executed; that is, coverage of some statements automatically implies coverage of other statements. Therefore, the statements can be grouped into blocks such that a statement in a block is executed if and only if all other statements are executed. The dividing lines for blocks are flow control statements such as if–then–else, case, wait, @, #, and loop statements. The code in Figure 5.20 can be grouped as shown in Figure 5.21. During the simulation run, four of six blocks are executed, giving 66.67% block coverage. Because of the similar nature of statement coverage and block coverage, and the fact that blocks better reflect the code structure, block coverage is often used in lieu of statement coverage. Near 100% statement and block coverage are easy to achieve and should be the goal for all designs. There are types of code that prevent 100% statement or block coverage. The first type is dead code, which cannot be reached at all and is a design error. The other type of statement is executed only under particular environment settings or should not be executed under correct operation of the design. Examples of this type are gate-level model statements that are not activated in a behavioral simulation, or error detection statements or assertions that do not fire if there are no errors. Thus, these types of statements should be excluded from statement and block coverage computation.

Figure 5.21. Sample code for block coverage

Coverage tools should have a pragma to delimit statements that are to be excluded. For example, when a coverage tool encounters the pragmas coverage_tool off and coverage_tool on, it skips the statements between them and excludes the statements from coverage calculation. The exact pragma name and syntax depend on specific coverage tools:

// coverage_tool off
if( state == 'BAD )
   $display ("ERROR: reach bad state");
// coverage_tool on

Conditional statements create different paths of execution. Each conditional statement is a forking point. Path coverage metrics measure the percentage of paths exercised. For the code in Figure 5.20, a graph of paths of statement execution is shown in Figure 5.22. There are four possible paths (in other words, four combinations of if-else branches). Two paths are shown in Figure 5.22. Path P1 is where both if statements are true, whereas path P2 is where both if statements are false. For the simulation run under discussion, P1 is executed, giving 25% path coverage. The number of paths grows exponentially with the number of conditional statements. Therefore, it is difficult to achieve 100% path coverage in practice.

Figure 5.22. Sample code for path coverage

How a statement is executed can be further analyzed. For example, when the statement containing several variables or expressions is executed, a detailed analysis is: which of the variables or expressions did get exercised. For example, that the expression (x1x2 + x3x4) evaluates to 1 can be broken down into whether x1x2 or x3x4 or both evaluate to 1. Such detailed information, revealing the parts of the expression executed, can be used to guide test generation to exercise as many parts of the expression as possible.

To compute expression coverage, operators in an expression are layered. For instance, E = (x1x2 + x3x4) is considered to have two layers:

layer 1: E = y1 + y2
layer 2: y1 = x1x2, y2 = x3x4

The second layer consists of two subexpressions: y1 and y2. Each expression or subexpression is a simple operator (such as AND or OR) and its expression coverage can be calculated from the minimum input tables shown in Tables 5.5 through 5.7. A minimum input determining an expression is the fewest number of input variables that must be assigned a value in order for the expression to have a Boolean value. For simple operators, all minimum inputs determining the value of the expression can be tabulated. The number of entries in the table consists of all cases for the expression to be exercised completely. Expression coverage is the ratio of the cases exercised to the total number of cases.

As examples, Tables 5.5 through 5.7 show the minimum inputs for f = x1 & x2, f = ( y ? x1 : x2), and f = (x > y).

This table indicates three cases for the AND function. For AND to evaluate to 0, only one input needs to be assigned 0. Because there are two inputs, two minimum inputs exist for the AND expression to be 0. For AND to evaluate to 1, both inputs must be 1. Therefore, there are a total of three minimum input entries. A line in the table represents a don’t-care for the variable. If, during a simulation run, x₁ and x₂ take on values x₁ = 1 and x₂ = 0 at one time and x₁ = 1 and x₂ = 1 at another time, then two cases are exercised, giving two-thirds or 66.67% expression coverage for this operator.

For the quest operator y ? x₁ : x₂, if y evaluates to true, the expression’s value is then determined by that of x₁. If y evaluates to false, x₂ then determines the expression’s value. There are four cases, as shown in Table 5.6.

For the comparison operator, there are two cases: true or false.

For composite operators, expression coverage can be computed for either the top layer of the operator or for all layers. Deciding on the top or all layers is a matter of how precisely one wants to test an expression. As an example, consider f = ((x > y) || (a & b)). Input (x, y, a, b) takes on values (3, 4, 1, 1) and (2, 5, 1, 0) during a simulation. The top layer operator is OR (||). In this simulation, the operands of OR evaluate to (x > y) = false, (a & b) = 1, and (x > y) = false, (a & b) = 0, for (3, 4, 1, 1) and (2, 5, 1, 0) respectively.

Because the OR operator has three cases, this simulation has a top-layer expression coverage of two-thirds, or 66.67%. For the next layer, (x > y) evaluates to false, giving 50% expression coverage; (a & b) has two-thirds, or 66.67%, coverage.

State coverage calculates the number of states visited over the total number of states in a finite-state machine. The states are extracted from RTL code, and visited states are marked in simulation. Consider the following three-state finite-state machine (depicted by the state diagram shown in Figure 5.23), where state S1 is the initial state and S4 is not defined in the RTL code.

Figure 5.23. State diagram extracted from RTL for state coverage

initial present_state = 'S1;
always @(posedge clock)
   case ({present_state, in})
      {'S1,a} : next_state = 'S3;
      {'S2,a} : next_state = 'S1;
      {'S3,a} : next_state = 'S2;
      {'S1,b} : next_state = 'S2;
      {'S3,b} : next_state = 'S3;
   endcase

If a simulation causes input in to be b, a, b, a, b, a, ..., then the state machine will only transit between S1 and S2, giving two-thirds, or 66.67%, state coverage. Because at least 2 bits are required to encode the three states, S4 is an implicit state and the state machine may end up at S4 for some error combinations on state bits. A more reliable design should consider how to handle S4. Therefore, for state coverage purposes, S4 should be counted and the previous input sequence would give only 50% state coverage. Because S4 can never be reached under normal operation, state coverage can be, at best, 75%. This should alert the designer that some states cannot be reached.

Transition or arc coverage records the percentage of transitions traversed, and, in some cases, the frequency they are traversed. For the state machine in Figure 5.23 and the input sequence b, a, b, a, ...,, only two of five transitions are traversed, giving 40% transition coverage. Note that the transition from S2 under input b is not defined. Including this undefined transition in the coverage calculation lowers the coverage to 33.33% and alerts us to potential problems. Therefore, the total number of transitions can be the actual number of transitions in the design or all possible transitions, which is equal to the number of states multiplied by the number of all possible inputs.

Sequence coverage calculates the percentage of user-defined state sequences that are traversed. A state sequence is a sequence of states that a finite-state machine traverses under an input sequence. For example, under input sequence a, b, a, a, a, b, b, the previous state machine traverses state sequence S1, S3, S3, S2, S1, S3, S3, S3. A user may specify that certain state sequences be traversed in a simulation run or not be traversed (in other words, illegal sequences). These state sequences could represent crucial functions or corner cases of the design. Sequence coverage provides information about which legal sequences are traversed and which illegal sequences are encountered.

Toggle coverage measures whether and how many times nets, nodes, signals, variables, ports, and buses toggle. Toggle coverage could be as simple as the ratio of nodes toggled to the total number of nodes. For buses, bits are measured individually. For instance, a change from 0000 to 1101 for a 4-bit bus gives three-fourths, or 75%, toggle coverage, instead of 100%, as if the entire bus were considered as a whole.

To compute code coverage, the RTL code must first be instrumented to have a mechanism installed to detect statement execution and to collect coverage data. There are two parts in instrumenting RTL code. The first part adds user-defined PLI tasks to the RTL code so that whenever a statement is executed, a PLI task is called to record the activity. Using the example in Figure 5.20, the code can be instrumented as shown in Figure 5.24. The user PLI task $C1 (), ... , $C5 () is added to the RTL code. When the statements in block 1 are executed, $C1 is called. If $C2 and $C4 are called at the same simulation time, then path P₁ of Figure 5.22 is traversed. The C/C++ code of PLI tasks $C1, $C2, and so on, record the simulation times when they are called and write out the results to a file for postprocessing. A fragment of code is shown here:

void C1 ()
{
   ...
   time = $tf_gettime(); // get simulation time
   C1_call_frequency[time].frequency++;
   // C1_call_frequency is a look-up table taking in
   // simulation time T and returns the number of times C1 is
   // called at time T.
...
}

Figure 5.24. Instrumented RTL code to collect coverage data

At the end of the simulation, table C1_call_frequency is dumped out to a file. The file’s contents may look like

routine:    time called:    frequency:
C1          1002             1
C1          1201             2
...
C2          1002             2
C2          1201             1
...
C3          1002             1
C3          2001             1
...

The second part of instrumenting creates a map that correlates the dumped output file to the filenames and line numbers of the RTL code. In Verilog, there are no means to get the filename and line number at which a user-defined PLI task is invoked; thus, a map is created to accomplish this goal. During the first part of instrumentation, when the PLI tasks are inserted, the filename and the line number of the insertion point are recorded in the map. Thus, a map contains data similar to

routine:    file name:    line number:
C1           cpu.v          3
C2           cpu.v          7
...

With this map, the calling frequencies of statements can be computed, from which block, path, state, transition, and other coverage metrics are derived. To evaluate expression coverage, the expression is passed to a PLI task and it is evaluated in C, through which the expression’s coverage is computed. For example, the expression on line 9, y = (b & a) is replaced by PLI task $C_exp (y, b, a), which takes on the values of variables a and b, computes the expression coverage, and returns the value of y. A postprocessor combines the dumped output and the map to create a coverage report.

After RTL code is instrumented, the instrumented code, instead of the original code, is simulated. Because PLI calls are involved in measuring code coverage, simulation performance is significantly decreased. It is not uncommon to see a 100% decrease in simulation speed once coverage measurement is turned on. Let’s look at several techniques to mitigate this problem.

For the code that the user does not want to measure coverage, or code that has been measured already, or error detection code that normal operations should not invoke, turn off the code with a pragma. Although the syntax of the pragma varies from tool to tool, a general form is shown here. The pragma is in the form of a stylized comment and it has no effect on other tools. Some coverage tools automatically ignore code marked by pragmas of synthesis tools, such as synthesize_off.

// coverage_tool off
// the following code is to be ignored
always @(posedge clock)
   begin
      ...
   end
// coverage_tool on

Ordering tests according to the parts of the circuit they cover improves performance. Coverage areas by each test can be represented using a Vann diagram. Tests with coverage that is subsumed by other tests should be eliminated. One way of ordering tests is to start with the test having the largest coverage area, followed by the test that has the most incremental change to coverage. When running a set of tests, the covered portions of circuit can be turned off progressively using pragmas so that a new test only measures the code that has not been covered by previous tests. When the code of a design is changed incrementally, we would identify the part of the design that is affected and update the coverage only for that part of the design.

A well-designed coverage tool should exhibit progressive performance improvements over a simulation run. During a simulation run, once a statement is covered, it does not need to be measured later in the simulation. For example, the PLI calls responsible for the statement can be disabled. Therefore, as coverage gradually reaches a plateau, simulation performance should gradually improve. At the coverage plateau, simulation speed should approach that without coverage measurement.

Finally, performance can be improved by simulating several tests in parallel and by combining the results. This technique is particularly useful in profiling tests on their coverage scope and using the profiling data to trim redundant tests and order tests.

This method of identifying functionality and creating monitors to detect their stimulation can be generalized and cast in the light of object-oriented programming (OOP). A functional verification object is associated with a functionality to be verified. Within such an object is a generalized state variable, which is a set of signals, variables, states, or a combination thereof. Associated with the object is a coverage method, which can be a function or task, that detects execution of the functionality by constantly monitoring the values or sequence of values the state variable takes. A functionality is defined in terms of a particular value or sequence of values of the state variable. Thus, when the state variable attains the value or sequence of values, the functionality is invoked. Sometimes an assertion for the functionality is also associated with the object to determine whether it passed or failed.

Using the previous MP cache protocol as an example, the generalized state variable consists of command, cache_A, and cache_B. State functionl is reached when the opcode portion of command is READ, and neither cache_A nor cache_B has a tag equal to the address portion of command. When state functionl is reached, functionl is invoked. The task monitor_functionl is the associated coverage method. The following module is code for a functional verification object for the MP cache protocol with a coverage method that detects the invocation of functiona1. Note that because memory cannot be passed to a module, hierarchical references to memory, cache_A, and cache_B are used:

     module verification_object (command);
     input [31:0] command;
     reg invoked;

     // generalized object consists of
     // reg [31:0] command and memory cache_A and cache_B
     // Because memory cannot be passed to module,
     // hierarchical references are used.

     monitor_function1(invoked); // monitor function1 invocation
     if (invoked == 1'b1) $display ("function1 has been called");
          // coverage method
     task monitor_function1;
     output invoked;
     ...
     reg ['ADDR:0] address;
     begin
        ...
        if (command['OPCODE] == 'READ) begin
           address = command['OPERAND];
           for (i=0; i<='CACHE_DEPTH; i=i+1) begin
              if (top.cpu.cache_A[i][valid] == 1'b1) // valid data
                 if (top.cpu.cache_A['TAG] == address['TAG])
                    hit_A = 1'b1;
           end // end of for loop

           ...

           if ( hit_A == 1'b0 && hit_B == 1'b0)
              invoked = 1'b1;
           else
              invoked = 1'b0;
         end // end of if (command =...
      end
      endtask

      endmodule

To use the functional verification object, just instantiate the module:

     verification_object m1 (command);

Unfortunately, Verilog does not allow creation of objects and calling of methods in the standard OOP way. Therefore, Verilog can only simulate the OOP effect with a module. An alternative is to use a language other than Verilog, such as Vera, to create the objects.

Organizing functional coverage using verification objects materializes functionality enumeration and encapsulates coverage and assertion methods with objects. It therefore makes functional verification more manageable and reusable.