source: vis_dev/vis-2.3/share/help/res_verifyCmd.txt

Last change on this file was 14, checked in by cecile, 15 years ago

vis2.3

File size: 12.4 KB
RevLine 
[14]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
Note: See TracBrowser for help on using the repository browser.