Assertions may be used to verify the behavior of a design. They use a concise description to describe the complex behavior or the specification of a hardware system. Assertions can be checked dynamically by a simulator or statically by a property checking tool. These tools can check whether the design meets the specification or the properties described in the assertion rules.
In SystemVerilog, there are two kinds of assertions: immediate (assert) and concurrent (assert property). The immediate assertions are procedural statements and are mainly used in simulation. A conditional expression is evaluated immediately in the assertion. If the evaluated value is X, Z, or 0, then the assertion fails and the simulator outputs an error message. The concurrent assertion rules are the statements that assert the specified properties. The conditional expression is evaluated throughout simulation. They can be checked at every point in the simulation. They can also be checked on a rising or falling edge of a clock signal.
In this problem, a finite state machine and some concurrent assertion rules are given. Please write a program to generate an input sequence for the finite state machine, such that the input sequence makes the assertions failed during simulation. The finite state machine and assertion rules are implemented by SystemVerilog. The module name of the finite state machine is fsm. A test bench is given to verify the input sequence. Please note that the input sequence may not exist to make some assertions failed. Several benchmarks will be given to evaluate your program.
The goal is to develop an input sequence generator program to find an input sequence that makes the given assertions failed. Try to make the input sequence as short as possible and make the number of failed assertions as large as possible. An evaluation set consisting of several benchmarks is provided for evaluating your program. For each benchmark, your program must generate the input sequence and make the maximum number of assertions failed. An assertion failing many times is counted only once. Runtime spent for each benchmark will be also used for grading your work. You will have a better grade if the runtime is less.
The assertions can be implemented by SystemVerilog using the following example statement:
assertion_rule1: assert property
(@(posedge clk) $rose(req)|->##[1:3] $rose(ack))
else $display(“assertion rule1 failed”);
As shown in Figure 1, this assertion rule can be used to check whether the acknowledge signal comes within 1 to 3 cycles delay after the request signal req is asserted. The assertion will fail and show the error message if the acknowledge signal ack comes after more than 3 cycles .
Fig.1 Timing diagram of the req and ack signals.
The input file is a SystemVerilog netlist. In this file, the behavior of the finite state machine is described in a module named fsm, and the assertions are also given in the fsm module. There is also a module named test used for reading the input sequence for verifying the assertions during simulation.
The Verilog model is used to describe the behavior of the given finite state machine. Note that there is more than one assertion in the Verilog model. An example is shown as follows:
Fig.2 An example of finite state machine Verilog model.
The assertion rules are all concurrent assertion rules and checked at positive edge of clk. The signal is 1-bit input or output signal and can be evaluated by $rose or $fell function. For example, $rose(in[1]) is true if in[1] is changed to 1. The $fell(in[1]) function is true if in[1] is changed to 0. The symbol of “##” is the delay operator. The range after the delay operation may be changed in each rule.
TThe output of your program is a file containing the sequence of input patterns for the finite state machine. The output format is described as follows: Each line shows an input pattern. In each line, the first digit is the value of the rst signal and the remaining digits are the values of the inputs from the msb (most significant bit) to the lsb (less significant bit). The following is an output example for the finite state machine in Figure 2. The order of signal names is rst, in[1], and in[0].
000
100
010
011
…
The output file is used to verify the assertions. The input patterns will be read one by one into the test bench for simulation. In order to make this contest fair, the rst signal must be enabled (from logic 0 to logic 1) for entering the start state at the beginning of input sequence. However, you can also re-enable the rst signal to force the finite state machine to enter the start state in the any part of the input sequence.
We use a small finite state machine in Figure 3 as an example to illustrate the assertion failed. The following is an example of the assertion rule. The output signal must be active after 1 to 3 cylces when the input signal in[1] is active.
assertion_rule1: assert property
(@(posedge clk) $rose(in[1])|->##[1:3] $rose(out))
else $display(“assertion rule1 failed”);
If the example of input sequences as shown in Figure 4 and Figure 5 are used for simulation, the above assertion will failed and show the failed message.
Fig.3 State diagram of an example finite state machine.
Fig.4 The example input sequence #1.
Fig.5 The example input sequence #2.
The input sequence can be verified by SystemVerilog. The first command is compile the designs:
vcs –sverilog fsm.v test.v
The second command is used to run the simulation:
./simv
The output message of simulator will show the assertion is failed if you active the assertion and failed.
"fsm.sv", 33: test.f1.assertion_rule1: started at 70s failed at 130s
Offending '$rose(out)'
You have to guarantee the correctness of program compiling and running. The compiled executable should be stored in the root directory of your deliverables. Under the command prompt, key in “time your_program_name –i fsm.v –o input_sequence” and press enter. Your program should create an output file named input_sequence that contains the generated input sequence. Then, the file can be simulated by SystemVerilog to check the number of failed assertions.
The performance metric is the total number of failed assertions found for all benchmarks/cases including the public and hidden benchmarks. A team that finds more failed assertions will get a higher score. However, if two teams find the same number of failed assertions, the team that generates a shorter input sequence will get a higher score. If the lengths of the input sequences are also the same, the team that spends less runtime will gets a higher score. Basically we will terminate the test if a program runs over 2 hours. Your program does not need to follow the order of the given assertions. You can change the order for the optimization of the input sequence length.
Input Width | Output Width | State Number | Assertion Rule Number | ||
Public Benchmarks | case1 | 7 | 7 | 36 | 10 |
case2 | 7 | 19 | 96 | 20 | |
case3 | 8 | 19 | 116 | 20 | |
Private Benchmarks | case4 | 7 | 19 | 96 | 20 |
case5 | 8 | 19 | 146 | 20 |