source: vis_dev/vis-2.1/share/vis/help/res_verifyCmd.txt @ 14

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

Add vis

File size: 13.3 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
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
Note: See TracBrowser for help on using the repository browser.