| 1 | |
|---|
| 2 | incremental_ctl_verification - Verify a set of CTL formulas by means of an |
|---|
| 3 | incremental model checking algorithm. |
|---|
| 4 | _________________________________________________________________ |
|---|
| 5 | |
|---|
| 6 | incremental_ctl_verification [-D <number>] [-e] [-h] [-n] \ [-s] [-t |
|---|
| 7 | <seconds>] [-v <number>] [-V <number>] [-x] <ctlfile> |
|---|
| 8 | |
|---|
| 9 | Like model_check, incremental_ctl_verification verifies a set of CTL |
|---|
| 10 | formulas. It uses a system of abstraction and incremental refinement |
|---|
| 11 | that works for all of (fair)CTL, using over and underapproximations as |
|---|
| 12 | appropriate. See [1,2] for details. |
|---|
| 13 | |
|---|
| 14 | Incremental_ctl_verification (also known as Abs or Trasgo) works |
|---|
| 15 | especially well on large systems on which mc is too slow or runs out |
|---|
| 16 | of memory. Unlike amc, it can handle full CTL, not just the universal |
|---|
| 17 | or existential subsets of it. Also, fairness is supported with this |
|---|
| 18 | command, although it tends to be inefficient. Support for the |
|---|
| 19 | mu-calculus is not yet implemented. |
|---|
| 20 | |
|---|
| 21 | Before using incremental_ctl_verification, a flattened hierarchy |
|---|
| 22 | should be present. See `help init`. Using dynamic variable reordering |
|---|
| 23 | may be beneficial on large systems. See `help dynamic_var_ordering`. |
|---|
| 24 | |
|---|
| 25 | Fairness constraints can be applied using `read_fairness', as with mc. |
|---|
| 26 | When using incremental verification with fairness, there is no check |
|---|
| 27 | for unfair initial states. Please be aware that if there are no fair |
|---|
| 28 | initial states, all formulas starting with "A" will be trivially true. |
|---|
| 29 | Mc will tell you whether you have fair initial states. |
|---|
| 30 | |
|---|
| 31 | A typical use would be |
|---|
| 32 | incremental_ctl_verification -D2 <ctl_file> |
|---|
| 33 | |
|---|
| 34 | For every formula, incremental verification will report whether it is |
|---|
| 35 | valid or invalid, or it returns an inconclusive result. A formula is |
|---|
| 36 | valid iff it holds for all initial states. An error trace is not |
|---|
| 37 | provided. For the people who are used to mc: The -r option is not |
|---|
| 38 | supported, incremental verification always reduces the fsm with |
|---|
| 39 | respect to individual formulas. The -c option is not supported either. |
|---|
| 40 | There is no sharing of subformulas between different formulas. |
|---|
| 41 | |
|---|
| 42 | Command options: |
|---|
| 43 | |
|---|
| 44 | -D <number> |
|---|
| 45 | Specify extent to which don't cares are used to simplify the |
|---|
| 46 | MDDs. |
|---|
| 47 | |
|---|
| 48 | + 0: No Don't Cares used. |
|---|
| 49 | + 1: Use reachability information to compute the don't-care |
|---|
| 50 | set. Reachability is performed by formula. This is different |
|---|
| 51 | from mc, where reachability is performed only once. |
|---|
| 52 | + 2: Use reachability information, and minimize the transition |
|---|
| 53 | relation with respect to the `frontier set' (aggresive |
|---|
| 54 | minimization). |
|---|
| 55 | |
|---|
| 56 | The equivalent of mc -D3 is not implemented. |
|---|
| 57 | |
|---|
| 58 | -e |
|---|
| 59 | Compute the set of fair states (those satisfying the formula |
|---|
| 60 | EGfair TRUE) before the verification process and use the result |
|---|
| 61 | as care set. In certain cases this will speed up computation |
|---|
| 62 | when fairness constraints are present. In other cases it will |
|---|
| 63 | slow it down. |
|---|
| 64 | |
|---|
| 65 | -h |
|---|
| 66 | Print the command usage. |
|---|
| 67 | |
|---|
| 68 | -n |
|---|
| 69 | Try to prove the negation of every formula. In some cases it |
|---|
| 70 | may be easier to prove the negation of a formula than the |
|---|
| 71 | formula itself. For systems with only one initial state, a |
|---|
| 72 | formula is true iff its negation is false. Note that for |
|---|
| 73 | systems with multiple initial states a formula and its negation |
|---|
| 74 | can both be false. |
|---|
| 75 | |
|---|
| 76 | -s |
|---|
| 77 | Print a summary of statistics after the verification. |
|---|
| 78 | |
|---|
| 79 | -t <secs> |
|---|
| 80 | Time in seconds allowed to spend in the verification. The |
|---|
| 81 | default is infinity. |
|---|
| 82 | |
|---|
| 83 | -v <number> |
|---|
| 84 | Specify verbosity level. Use 0 for no feedback (default), 1 for |
|---|
| 85 | more and 2 for maximum feedback. This option can not be used in |
|---|
| 86 | conjunction with -V. |
|---|
| 87 | |
|---|
| 88 | -V <number> |
|---|
| 89 | Mask specifying type of information to be printed out while |
|---|
| 90 | verifying the formulas. This allows for a finer control than |
|---|
| 91 | -v. -V and -v cannot be used simultaneously. The mask is given |
|---|
| 92 | as a binary number, by taking the logical or of the following |
|---|
| 93 | binary values. One does not have to convert these numbers to |
|---|
| 94 | decimal. |
|---|
| 95 | |
|---|
| 96 | 1 number of primary inputs and flip-flops |
|---|
| 97 | |
|---|
| 98 | 10 labeled operational graph of the formulas |
|---|
| 99 | |
|---|
| 100 | 100 cpu-time for the computation in each vertex |
|---|
| 101 | |
|---|
| 102 | 1000 cubes of the function sat for each vertex |
|---|
| 103 | |
|---|
| 104 | 10000 cubes of the function goalSet for each vertex |
|---|
| 105 | |
|---|
| 106 | 100000 vertex data structure contents after evaluation |
|---|
| 107 | |
|---|
| 108 | 1000000 cubes in the care set for every evaluation |
|---|
| 109 | |
|---|
| 110 | 10000000 size of care set for every evaluation |
|---|
| 111 | |
|---|
| 112 | 100000000 number of states that satisfy every sub-formula |
|---|
| 113 | |
|---|
| 114 | 1000000000 number of overall reachable states |
|---|
| 115 | |
|---|
| 116 | 10000000000 cubes for every iteration of a fixed point |
|---|
| 117 | |
|---|
| 118 | 100000000000 size of the BDD in each iteration in a fix-point |
|---|
| 119 | |
|---|
| 120 | 1000000000000 labeled operational graph in dot format |
|---|
| 121 | |
|---|
| 122 | 10000000000000 number of envelope states |
|---|
| 123 | |
|---|
| 124 | 100000000000000 number of states to be refined |
|---|
| 125 | |
|---|
| 126 | 1000000000000000 size of the refinement operands |
|---|
| 127 | |
|---|
| 128 | 10000000000000000 cubes of the refinement operands |
|---|
| 129 | |
|---|
| 130 | 100000000000000000 Number of latches before and after |
|---|
| 131 | simplification |
|---|
| 132 | |
|---|
| 133 | 1000000000000000000 report partial progress (i.e. reach, |
|---|
| 134 | EG(true),...) |
|---|
| 135 | |
|---|
| 136 | 10000000000000000000 Begin/End refinement process |
|---|
| 137 | |
|---|
| 138 | 100000000000000000000 Size of goal set |
|---|
| 139 | |
|---|
| 140 | 1000000000000000000000 cubes of the goal set |
|---|
| 141 | |
|---|
| 142 | 10000000000000000000000 Contents of vertex after refinement |
|---|
| 143 | |
|---|
| 144 | -x |
|---|
| 145 | Perform the verification exactly. No approximation is done. |
|---|
| 146 | |
|---|
| 147 | <ctlfile> |
|---|
| 148 | File containing the CTL formulas to be verified. |
|---|
| 149 | |
|---|
| 150 | Related "set" options: |
|---|
| 151 | |
|---|
| 152 | ctl_change_bracket <yes/no> |
|---|
| 153 | Vl2mv automatically converts "[]" to "<>" in node names, |
|---|
| 154 | therefore CTL parser does the same thing. However, in some |
|---|
| 155 | cases a user does not want to change node names in CTL parsing. |
|---|
| 156 | Then, use this set option by giving "no". Default is "yes". |
|---|
| 157 | |
|---|
| 158 | See also commands : model_check, incremental_ctl_verification |
|---|
| 159 | |
|---|
| 160 | 1. A. Pardo and G. Hachtel. Automatic abstraction techniques for |
|---|
| 161 | propositional mu-calculus model checking. In 9th Conference on |
|---|
| 162 | Computer Aided Verification (CAV'97). Springer-Verlag. Pages 12-23, |
|---|
| 163 | 1997. |
|---|
| 164 | |
|---|
| 165 | 2. A. Pardo and G. Hachtel. Incremental CTL model checking using BDD |
|---|
| 166 | subsetting. In 35th Design Automation Conference (DAC'98). pages |
|---|
| 167 | 457-462, 1998. |
|---|
| 168 | _________________________________________________________________ |
|---|
| 169 | |
|---|
| 170 | Last updated on 20050519 10h16 |
|---|