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

Last change on this file since 19 was 14, checked in by cecile, 13 years ago

vis2.3

File size: 12.4 KB
Line 
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.