| 1 | |
|---|
| 2 | res_verify - Verifies a combinational circuit using residue arithmetic. |
|---|
| 3 | _________________________________________________________________ |
|---|
| 4 | |
|---|
| 5 | res_verify [-b] [-d <n>] [-h] -i <filename> [-m <filename>] [-n |
|---|
| 6 | <filename>] {-o <filename> | -O} [-s <filename>] [-t <timeOut>] |
|---|
| 7 | |
|---|
| 8 | This command performs residue verification between two networks. The |
|---|
| 9 | method used is based on residue arithmetic and the Chinese Remainder |
|---|
| 10 | theorem; it is described in [1] |
|---|
| 11 | ftp://vlsi.colorado.edu/pub/fmcad96.ps. Verification is performed by |
|---|
| 12 | interpreting the outputs of the circuits as integers and verifying the |
|---|
| 13 | residues of the outputs with respect to a set of moduli. The choice of |
|---|
| 14 | moduli is directed by the Chinese Remainder Theorem in order to prove |
|---|
| 15 | equivalence of the two circuits. This method works well with |
|---|
| 16 | multipliers and possibly other arithmetic circuits (due to its |
|---|
| 17 | dependence on residue arithmetic). For the same reason, it is |
|---|
| 18 | necessary to specify an output order which determines how the outputs |
|---|
| 19 | are interpreted as integers. Discretion should be exercised in |
|---|
| 20 | applying this method to general combinational circuits. |
|---|
| 21 | |
|---|
| 22 | Residue verification is available only if vis is linked with the cu |
|---|
| 23 | BDD package. (This is the default.) It reads both blif and blif-mv |
|---|
| 24 | files. However, it does NOT support multi-valued variables. Residue |
|---|
| 25 | verification is primarily for combinational verification, but may be |
|---|
| 26 | applied to sequential circuits with the same state encoding. The latch |
|---|
| 27 | outputs are then considered to be combinational inputs of the circuits |
|---|
| 28 | and the latch inputs and reset are considered to be combinational |
|---|
| 29 | outputs of the circuits. |
|---|
| 30 | |
|---|
| 31 | There are two ways to perform residue verification in this package. As |
|---|
| 32 | a first option, two files describing two networks, the specification |
|---|
| 33 | and the implementation, (in the same format, blif or blif-mv, see |
|---|
| 34 | option -b) are given in the command line; the procedure tries to |
|---|
| 35 | verify the equivalence of the combinational outputs as functions of |
|---|
| 36 | the combinational inputs. |
|---|
| 37 | |
|---|
| 38 | vis> res_verify -o network.order -i network1.blif -s network2.blif |
|---|
| 39 | |
|---|
| 40 | In this case both networks are read in, flattened and the verification |
|---|
| 41 | is performed between the combinational outputs of both networks. The |
|---|
| 42 | -i option denotes the implementation file and the -s option denotes |
|---|
| 43 | the specification file. The -o option specifies the order of outputs |
|---|
| 44 | for the circuits (See Command Options below for detailed explanation). |
|---|
| 45 | |
|---|
| 46 | A second way to perform the verification is as follows. The |
|---|
| 47 | specification network is taken from a hierarchy already read into VIS. |
|---|
| 48 | Then the res_verify command compares that specification against an |
|---|
| 49 | implementation network obtained from the file in the command line. Any |
|---|
| 50 | previous verification, performed with the specification, can be used |
|---|
| 51 | towards the next verification task only if the same implementation |
|---|
| 52 | circuit is being verified against and the same number of outputs have |
|---|
| 53 | been directly verified with sucess in the previous attempt. The |
|---|
| 54 | typical sequence of commands given to perform such task would be: |
|---|
| 55 | |
|---|
| 56 | vis> read_blifmv network1.mv |
|---|
| 57 | vis> flatten_hierarchy |
|---|
| 58 | vis> res_verify -o network.order -i network2.mv |
|---|
| 59 | |
|---|
| 60 | If the hierarchy has been read but no flattened network exists at the |
|---|
| 61 | current node, the command will return without doing anything. If one |
|---|
| 62 | of the networks used is the one in the current node in the hierarchy, |
|---|
| 63 | then the information regarding the verification process will be stored |
|---|
| 64 | in that network. |
|---|
| 65 | |
|---|
| 66 | Note: It is important to keep the specification distinct from the |
|---|
| 67 | implementation because most parameters specified for the res_verify |
|---|
| 68 | command are with respect to the specification. For example, the output |
|---|
| 69 | order is specified with respect to the specification. The file that is |
|---|
| 70 | read in first in the second format, is considered to be the |
|---|
| 71 | specification. |
|---|
| 72 | |
|---|
| 73 | There is an option to directly verify some outputs by building the |
|---|
| 74 | BDDs for the corresponding outputs of the 2 circuits. In that case, if |
|---|
| 75 | the user wants to use an initial ordering, the only way to do it is |
|---|
| 76 | the second method and reading in the network, one may specify the |
|---|
| 77 | initial order using static order. |
|---|
| 78 | |
|---|
| 79 | The command does not repeat residue verification if the same |
|---|
| 80 | specification-implementation pair have been verified with success and |
|---|
| 81 | the same number of directly verified outputs have been verified in the |
|---|
| 82 | previous attempt. |
|---|
| 83 | |
|---|
| 84 | Relevant flags to be set using the set command: |
|---|
| 85 | |
|---|
| 86 | residue_verbosity |
|---|
| 87 | Default is 0, turns on verbosity to the desired level between 0 |
|---|
| 88 | and 5. |
|---|
| 89 | |
|---|
| 90 | residue_ignore_direct_verified_outputs |
|---|
| 91 | Default 0 (FALSE). If 1, then ignores directly verified outputs |
|---|
| 92 | during residue verification. |
|---|
| 93 | |
|---|
| 94 | residue_top_var |
|---|
| 95 | Default "msb". The 2 possible values are "msb" and lsb"; this |
|---|
| 96 | puts the most/least significant bit near the top or bottom of |
|---|
| 97 | the residue decision diagram. |
|---|
| 98 | |
|---|
| 99 | residue_autodyn_residue_verif |
|---|
| 100 | Default 0 (FALSE). If 1, turns on dynamic reordering during |
|---|
| 101 | residue verification. |
|---|
| 102 | |
|---|
| 103 | residue_residue_dyn_method |
|---|
| 104 | Default "groupsift". Specifies the method for dynamic |
|---|
| 105 | reordering during residue verification. Other methods supported |
|---|
| 106 | are "same" (same as before), "none", "random", "randompivot", |
|---|
| 107 | "sift", "siftconverge", "symmsiftconverge", "symmsift", |
|---|
| 108 | "window2", "window3", "window4", "window2converge", |
|---|
| 109 | "window3converge", "window4converge", "groupsift", |
|---|
| 110 | "groupsiftconverge", "anneal", "genetic", "linear", |
|---|
| 111 | "linearconverge", "exact". |
|---|
| 112 | |
|---|
| 113 | residue_autodyn_direct_verif |
|---|
| 114 | Default 0 (FALSE). If 1, turns on dynamic reordering during |
|---|
| 115 | direct verification. |
|---|
| 116 | |
|---|
| 117 | residue_direct_dyn_method |
|---|
| 118 | Default "groupsift". Specifies the method for dynamic |
|---|
| 119 | reordering during direct verification. Other methods supported |
|---|
| 120 | are "same" (same as before), "none", "random", "randompivot", |
|---|
| 121 | "sift", "siftconverge", "symmsiftconverge", "symmsift", |
|---|
| 122 | "window2", "window3", "window4", "window2converge", |
|---|
| 123 | "window3converge", "window4converge", "groupsift", |
|---|
| 124 | "groupsiftconverge", "anneal", "genetic", "linear", |
|---|
| 125 | "linearconverge", "exact". |
|---|
| 126 | |
|---|
| 127 | residue_layer_schedule |
|---|
| 128 | Default "alap". This is a flag to specify the layering strategy |
|---|
| 129 | of the networks. The 2 options are "asap" (as soon as possible) |
|---|
| 130 | and "alap" (as late as possible). |
|---|
| 131 | |
|---|
| 132 | residue_layer_size |
|---|
| 133 | Default largest layer size in network. Specifies the maximum |
|---|
| 134 | layer size that can be composed in (relevant for vector |
|---|
| 135 | composition only). |
|---|
| 136 | |
|---|
| 137 | residue_composition_method |
|---|
| 138 | Default "vector". Specifies the composition method to be used |
|---|
| 139 | in composing the network into the residue ADD. The options are |
|---|
| 140 | "vector", "onegate", "preimage" and "superG". |
|---|
| 141 | |
|---|
| 142 | Command Options: |
|---|
| 143 | |
|---|
| 144 | -b |
|---|
| 145 | If this option is specified, the specification and the |
|---|
| 146 | implementation files read are considered to be in blif-mv |
|---|
| 147 | format. Default is blif format. |
|---|
| 148 | |
|---|
| 149 | -d n |
|---|
| 150 | This option specifies the number of outputs to be directly |
|---|
| 151 | verified. That is, for n least significant outputs of the |
|---|
| 152 | circuit, this command performs like comb_verify. The actual |
|---|
| 153 | outputs are read off the output order array. Since the output |
|---|
| 154 | order array is specified starting with the MSB, the number of |
|---|
| 155 | directly verified outputs will be a chunk of the bottom part of |
|---|
| 156 | the output order array. The option "-d all" sets the number of |
|---|
| 157 | directly verified outputs to the number of combinational |
|---|
| 158 | outputs in the circuit i.e., all outputs are directly verified. |
|---|
| 159 | The direct verification for small BDD sizes is faster and |
|---|
| 160 | overall reduces the number of primes to be used in residue |
|---|
| 161 | verification. In general, one output is checked at a time |
|---|
| 162 | against the corresponding output of the other network and |
|---|
| 163 | consequently , this method may be fast and use less memory |
|---|
| 164 | resources. |
|---|
| 165 | IMPORTANT: It is possible to specify an initial order for the |
|---|
| 166 | direct verification. This is done by reading in the |
|---|
| 167 | specification file and using static_order to specify the |
|---|
| 168 | initial order. The implementation will get the same order as |
|---|
| 169 | the specification. When specifying the initial order, one must |
|---|
| 170 | be careful not to specify the -s option in the res_verify |
|---|
| 171 | command. The -s option reads in the specification file again |
|---|
| 172 | and the initial order is lost. |
|---|
| 173 | |
|---|
| 174 | -h |
|---|
| 175 | Print the command usage. |
|---|
| 176 | |
|---|
| 177 | -i <filename> |
|---|
| 178 | Implementation network to perform verification against. The |
|---|
| 179 | file must be in blif format unless -b is specified, in which |
|---|
| 180 | case the file is taken to be in blif-mv format. The blif format |
|---|
| 181 | is the default. |
|---|
| 182 | |
|---|
| 183 | -m <filename> |
|---|
| 184 | Optional file name specifying the matching pair of output names |
|---|
| 185 | between the two networks. If not specified, it is assumed that |
|---|
| 186 | all outputs have identical names. This option is useful when |
|---|
| 187 | verifying two circuits whose output names do not match. The |
|---|
| 188 | file will give pairs of the form name1 name2 to be considered |
|---|
| 189 | as corresponding outputs in the verification process. In each |
|---|
| 190 | pair, name1 may belong to the specification and name2 to the |
|---|
| 191 | implementation or vice-versa. The matching procedure is not |
|---|
| 192 | capable of dealing with some special situations. For example, |
|---|
| 193 | when two outputs, one of each network have the same name, they |
|---|
| 194 | must correspond to the same output. Partial orders may not be |
|---|
| 195 | specified. |
|---|
| 196 | |
|---|
| 197 | -n <filename> |
|---|
| 198 | Optional file name specifying the matching pair of input names |
|---|
| 199 | between the two networks. If not specified, it is assumed that |
|---|
| 200 | all inputs have identical names. This option is useful when |
|---|
| 201 | verifying two circuits whose input names do not match. The file |
|---|
| 202 | will give pairs of the form name1 name2 to be considered as |
|---|
| 203 | corresponding inputs in the verification process. In each pair, |
|---|
| 204 | name1 may belong to the specification and name2 to the |
|---|
| 205 | implementation or vice-versa. The matching procedure is not |
|---|
| 206 | capable of dealing with some special situations. For example, |
|---|
| 207 | when two inputs, one of each network have the same name, they |
|---|
| 208 | must correspond to the same input. Partial orders may not be |
|---|
| 209 | specified. |
|---|
| 210 | |
|---|
| 211 | -o <filename> |
|---|
| 212 | Required file specifying output order, starting with the MSB. |
|---|
| 213 | The file must be a list of output names separated by spaces. |
|---|
| 214 | The list must belong to the specification network and must |
|---|
| 215 | contain a full order i.e., must contain all the combinational |
|---|
| 216 | output names. It is advisable to use the -o option as far as |
|---|
| 217 | possible to specify the order of the outputs.See also -O |
|---|
| 218 | option. |
|---|
| 219 | |
|---|
| 220 | -O |
|---|
| 221 | This option specifies whether the res_verify command should |
|---|
| 222 | generate a default order for the outputs. If the -o option is |
|---|
| 223 | not used, this option must be specified. The default order |
|---|
| 224 | generated is random and is NOT the same as the input files. The |
|---|
| 225 | set of outputs for the output order may be generated by using |
|---|
| 226 | the print_network command to write the network into a file and |
|---|
| 227 | extract the node name from the lines containing the word |
|---|
| 228 | "comb-output". The set of outputs can then be ordered as |
|---|
| 229 | required. |
|---|
| 230 | It is advisable to use the -o option as far as possible to |
|---|
| 231 | specify the order of the outputs. The -o option overrides the |
|---|
| 232 | -O option. See also -o option. |
|---|
| 233 | |
|---|
| 234 | -s <filename> |
|---|
| 235 | Specification network. This network will be taken as the |
|---|
| 236 | specification of the circuit. The result of the computation |
|---|
| 237 | will be stored in this network. If this network is not |
|---|
| 238 | provided, the current node of the hierarchy will be taken. The |
|---|
| 239 | file must contain a blif description of a circuit unless the |
|---|
| 240 | option -b is specified, in which case the file is considered in |
|---|
| 241 | blif-mv format. If two networks are specified in the command |
|---|
| 242 | line, both of them must have the same format, either blif or |
|---|
| 243 | blif-mv. The blif format is the default. |
|---|
| 244 | |
|---|
| 245 | -t <timeOut > |
|---|
| 246 | Execution time in seconds allowed for verification before |
|---|
| 247 | aborting. The default is no limit. |
|---|
| 248 | _________________________________________________________________ |
|---|
| 249 | |
|---|
| 250 | Last updated on 20050519 10h16 |
|---|