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