1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> |
---|
2 | |
---|
3 | <!--Converted with LaTeX2HTML 2K.1beta (1.47) |
---|
4 | original version by: Nikos Drakos, CBLU, University of Leeds |
---|
5 | * revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan |
---|
6 | * with significant contributions from: |
---|
7 | Jens Lippmann, Marek Rouchal, Martin Wilck and others --> |
---|
8 | <HTML> |
---|
9 | <HEAD> |
---|
10 | <TITLE>User's Manual</TITLE> |
---|
11 | <META NAME="description" CONTENT="User's Manual"> |
---|
12 | <META NAME="keywords" CONTENT="cuddIntro"> |
---|
13 | <META NAME="resource-type" CONTENT="document"> |
---|
14 | <META NAME="distribution" CONTENT="global"> |
---|
15 | |
---|
16 | <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> |
---|
17 | <META NAME="Generator" CONTENT="LaTeX2HTML v2K.1beta"> |
---|
18 | <META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css"> |
---|
19 | |
---|
20 | <LINK REL="STYLESHEET" HREF="cuddIntro.css"> |
---|
21 | |
---|
22 | <LINK REL="next" HREF="node4.html"> |
---|
23 | <LINK REL="previous" HREF="node2.html"> |
---|
24 | <LINK REL="up" HREF="cuddIntro.html"> |
---|
25 | <LINK REL="next" HREF="node4.html"> |
---|
26 | </HEAD> |
---|
27 | |
---|
28 | <BODY > |
---|
29 | <!--Navigation Panel--> |
---|
30 | <A NAME="tex2html272" |
---|
31 | HREF="node4.html"> |
---|
32 | <IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" |
---|
33 | SRC="icons/next.png"></A> |
---|
34 | <A NAME="tex2html268" |
---|
35 | HREF="cuddIntro.html"> |
---|
36 | <IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" |
---|
37 | SRC="icons/up.png"></A> |
---|
38 | <A NAME="tex2html262" |
---|
39 | HREF="node2.html"> |
---|
40 | <IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" |
---|
41 | SRC="icons/prev.png"></A> |
---|
42 | <A NAME="tex2html270" |
---|
43 | HREF="node8.html"> |
---|
44 | <IMG WIDTH="43" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="index" |
---|
45 | SRC="icons/index.png"></A> |
---|
46 | <BR> |
---|
47 | <B> Next:</B> <A NAME="tex2html273" |
---|
48 | HREF="node4.html">Programmer's Manual</A> |
---|
49 | <B> Up:</B> <A NAME="tex2html269" |
---|
50 | HREF="cuddIntro.html">CUDD: CU Decision Diagram</A> |
---|
51 | <B> Previous:</B> <A NAME="tex2html263" |
---|
52 | HREF="node2.html">How to Get CUDD</A> |
---|
53 |   <B> <A NAME="tex2html271" |
---|
54 | HREF="node8.html">Index</A></B> |
---|
55 | <BR> |
---|
56 | <BR> |
---|
57 | <!--End of Navigation Panel--> |
---|
58 | <!--Table of Child-Links--> |
---|
59 | <A NAME="CHILD_LINKS"><STRONG>Subsections</STRONG></A> |
---|
60 | |
---|
61 | <UL> |
---|
62 | <LI><A NAME="tex2html274" |
---|
63 | HREF="#SECTION00031000000000000000">Compiling and Linking</A> |
---|
64 | <LI><A NAME="tex2html275" |
---|
65 | HREF="#SECTION00032000000000000000">Basic Data Structures</A> |
---|
66 | <UL> |
---|
67 | <LI><A NAME="tex2html276" |
---|
68 | HREF="#SECTION00032100000000000000">Nodes</A> |
---|
69 | <LI><A NAME="tex2html277" |
---|
70 | HREF="#SECTION00032200000000000000">The Manager</A> |
---|
71 | <LI><A NAME="tex2html278" |
---|
72 | HREF="#SECTION00032300000000000000">Cache</A> |
---|
73 | </UL> |
---|
74 | <BR> |
---|
75 | <LI><A NAME="tex2html279" |
---|
76 | HREF="#SECTION00033000000000000000">Initializing and Shutting Down a DdManager</A> |
---|
77 | <LI><A NAME="tex2html280" |
---|
78 | HREF="#SECTION00034000000000000000">Setting Parameters</A> |
---|
79 | <LI><A NAME="tex2html281" |
---|
80 | HREF="#SECTION00035000000000000000">Constant Functions</A> |
---|
81 | <UL> |
---|
82 | <LI><A NAME="tex2html282" |
---|
83 | HREF="#SECTION00035100000000000000">One, Logic Zero, and Arithmetic Zero</A> |
---|
84 | <LI><A NAME="tex2html283" |
---|
85 | HREF="#SECTION00035200000000000000">Predefined Constants</A> |
---|
86 | <LI><A NAME="tex2html284" |
---|
87 | HREF="#SECTION00035300000000000000">Background</A> |
---|
88 | <LI><A NAME="tex2html285" |
---|
89 | HREF="#SECTION00035400000000000000">New Constants</A> |
---|
90 | </UL> |
---|
91 | <BR> |
---|
92 | <LI><A NAME="tex2html286" |
---|
93 | HREF="#SECTION00036000000000000000">Creating Variables</A> |
---|
94 | <UL> |
---|
95 | <LI><A NAME="tex2html287" |
---|
96 | HREF="#SECTION00036100000000000000">New BDD and ADD Variables</A> |
---|
97 | <LI><A NAME="tex2html288" |
---|
98 | HREF="#SECTION00036200000000000000">New ZDD Variables</A> |
---|
99 | </UL> |
---|
100 | <BR> |
---|
101 | <LI><A NAME="tex2html289" |
---|
102 | HREF="#SECTION00037000000000000000">Basic BDD Manipulation</A> |
---|
103 | <LI><A NAME="tex2html290" |
---|
104 | HREF="#SECTION00038000000000000000">Basic ADD Manipulation</A> |
---|
105 | <LI><A NAME="tex2html291" |
---|
106 | HREF="#SECTION00039000000000000000">Basic ZDD Manipulation</A> |
---|
107 | <LI><A NAME="tex2html292" |
---|
108 | HREF="#SECTION000310000000000000000">Converting ADDs to BDDs and Vice Versa</A> |
---|
109 | <LI><A NAME="tex2html293" |
---|
110 | HREF="#SECTION000311000000000000000">Converting BDDs to ZDDs and Vice Versa</A> |
---|
111 | <LI><A NAME="tex2html294" |
---|
112 | HREF="#SECTION000312000000000000000">Variable Reordering for BDDs and ADDs</A> |
---|
113 | <LI><A NAME="tex2html295" |
---|
114 | HREF="#SECTION000313000000000000000">Grouping Variables</A> |
---|
115 | <LI><A NAME="tex2html296" |
---|
116 | HREF="#SECTION000314000000000000000">Variable Reordering for ZDDs</A> |
---|
117 | <LI><A NAME="tex2html297" |
---|
118 | HREF="#SECTION000315000000000000000">Keeping Consistent Variable Orders for BDDs and ZDDs</A> |
---|
119 | <LI><A NAME="tex2html298" |
---|
120 | HREF="#SECTION000316000000000000000">Hooks</A> |
---|
121 | <LI><A NAME="tex2html299" |
---|
122 | HREF="#SECTION000317000000000000000">The SIS/VIS Interface</A> |
---|
123 | <UL> |
---|
124 | <LI><A NAME="tex2html300" |
---|
125 | HREF="#SECTION000317100000000000000">Using the CUDD Package in SIS</A> |
---|
126 | </UL> |
---|
127 | <BR> |
---|
128 | <LI><A NAME="tex2html301" |
---|
129 | HREF="#SECTION000318000000000000000">Writing Decision Diagrams to a File</A> |
---|
130 | <LI><A NAME="tex2html302" |
---|
131 | HREF="#SECTION000319000000000000000">Saving and Restoring BDDs</A> |
---|
132 | </UL> |
---|
133 | <!--End of Table of Child-Links--> |
---|
134 | <HR> |
---|
135 | |
---|
136 | <H1><A NAME="SECTION00030000000000000000"></A> |
---|
137 | <A NAME="sec:user"></A> |
---|
138 | <BR> |
---|
139 | User's Manual |
---|
140 | </H1> |
---|
141 | |
---|
142 | <P> |
---|
143 | This section describes the use of the CUDD package as a black box. |
---|
144 | |
---|
145 | <P> |
---|
146 | |
---|
147 | <H2><A NAME="SECTION00031000000000000000"></A> |
---|
148 | <A NAME="sec:compileExt"></A><A NAME="78"></A> |
---|
149 | <BR> |
---|
150 | Compiling and Linking |
---|
151 | </H2> |
---|
152 | |
---|
153 | <P> |
---|
154 | To build an application that uses the CUDD package, you should add |
---|
155 | <PRE> |
---|
156 | #include "util.h" |
---|
157 | #include "cudd.h" |
---|
158 | </PRE> |
---|
159 | <A NAME="81"></A> |
---|
160 | to your source files, and should link |
---|
161 | <code>libcudd.a</code><A NAME="82"></A>, |
---|
162 | <code>libmtr.a</code><A NAME="83"></A>, |
---|
163 | <code>libst.a</code><A NAME="84"></A>, and |
---|
164 | <code>libutil.a</code><A NAME="85"></A> to your executable. (All these |
---|
165 | libraries are part of the distribution.) Some |
---|
166 | platforms require specific compiler and linker flags. Refer to the |
---|
167 | <TT>Makefile<A NAME="86"></A></TT> in the top level directory of the |
---|
168 | distribution. |
---|
169 | |
---|
170 | <P> |
---|
171 | Keep in mind that whatever flags affect the size of data |
---|
172 | structures--for instance the flags used to use 64-bit pointers where |
---|
173 | available--must be specified when compiling both CUDD and the files |
---|
174 | that include its header files. |
---|
175 | |
---|
176 | <P> |
---|
177 | |
---|
178 | <H2><A NAME="SECTION00032000000000000000"></A> |
---|
179 | <A NAME="sec:struct"></A> |
---|
180 | <BR> |
---|
181 | Basic Data Structures |
---|
182 | </H2> |
---|
183 | |
---|
184 | <P> |
---|
185 | |
---|
186 | <H3><A NAME="SECTION00032100000000000000"></A> |
---|
187 | <A NAME="sec:nodes"></A> |
---|
188 | <BR> |
---|
189 | Nodes |
---|
190 | </H3> |
---|
191 | |
---|
192 | <P> |
---|
193 | BDDs, ADDs, and ZDDs are made of DdNode's. A DdNode<A NAME="91"></A> |
---|
194 | (node<A NAME="92"></A> for short) is a structure with several fields. Those |
---|
195 | that are of interest to the application that uses the CUDD package as |
---|
196 | a black box are the variable index<A NAME="93"></A>, the |
---|
197 | reference<A NAME="94"></A> count, and the value. The |
---|
198 | remaining fields are pointers that connect nodes among themselves and |
---|
199 | that are used to implement the unique<A NAME="95"></A> table. (See |
---|
200 | Section <A HREF="node3.html#sec:manager">3.2.2</A>.) |
---|
201 | |
---|
202 | <P> |
---|
203 | The <EM>index</EM> field holds the name of the variable that labels the |
---|
204 | node. The index of a variable is a permanent attribute that reflects |
---|
205 | the order<A NAME="98"></A> of creation. Index 0 corresponds to |
---|
206 | the variable created first. On a machine with 32-bit pointers, the |
---|
207 | maximum number of variables is the largest value that can be stored in |
---|
208 | an unsigned short integer minus 1. The largest index is reserved for |
---|
209 | the constant<A NAME="99"></A> nodes. When 64-bit pointers are |
---|
210 | used, the maximum number of variables is the largest value that can be |
---|
211 | stored in an unsigned integer minus 1. |
---|
212 | |
---|
213 | <P> |
---|
214 | When variables are reordered to reduce the size of the decision |
---|
215 | diagrams, the variables may shift in the order, but they retain their |
---|
216 | indices. The package keeps track of the variable |
---|
217 | permutation<A NAME="100"></A> (and its inverse). The |
---|
218 | application is not affected by variable reordering<A NAME="101"></A>, |
---|
219 | except in the following cases. |
---|
220 | |
---|
221 | <UL> |
---|
222 | <LI>If the application uses |
---|
223 | generators<A NAME="103"></A> (<A NAME="tex2html3" |
---|
224 | HREF="cuddExtDet.html#Cudd_ForeachCube"><EM>Cudd_ForeachCube</EM></A> |
---|
225 | <A NAME="1423"></A> and <A NAME="tex2html4" |
---|
226 | HREF="cuddExtDet.html#Cudd_ForeachNode"><EM>Cudd_ForeachNode</EM></A> |
---|
227 | <A NAME="1425"></A>) and reordering is enabled, then it |
---|
228 | must take care not to call any operation that may create new nodes |
---|
229 | (and hence possibly trigger reordering). This is because the cubes |
---|
230 | (i.e., paths) and nodes of a diagram change as a result of reordering. |
---|
231 | </LI> |
---|
232 | <LI>If the application uses <A NAME="tex2html5" |
---|
233 | HREF="cuddExtDet.html#Cudd_bddConstrain"><EM> Cudd_bddConstrain</EM></A><A NAME="1427"></A> and reordering |
---|
234 | |
---|
235 | takes place, then the property of <A NAME="tex2html6" |
---|
236 | HREF="cuddExtDet.html#Cudd_bddConstrain"><EM>Cudd_bddConstrain</EM></A> |
---|
237 | of being an |
---|
238 | image restrictor is lost. |
---|
239 | </LI> |
---|
240 | </UL> |
---|
241 | |
---|
242 | <P> |
---|
243 | The CUDD package relies on garbage<A NAME="116"></A> |
---|
244 | collection to reclaim the memory used by diagrams that are no longer |
---|
245 | in use. The scheme employed for garbage collection is based on keeping |
---|
246 | a reference<A NAME="117"></A> count for each node. The |
---|
247 | references that are counted are both the internal references |
---|
248 | (references from other nodes) and external references (typically |
---|
249 | references from the calling environment). When an application creates |
---|
250 | a new BDD<A NAME="118"></A>, ADD<A NAME="119"></A>, or ZDD<A NAME="120"></A>, |
---|
251 | it must increase its reference count explicitly, through |
---|
252 | a call to <A NAME="tex2html7" |
---|
253 | HREF="cuddExtDet.html#Cudd_Ref"><EM>Cudd_Ref</EM></A><A NAME="1429"></A>. Similarly, when a |
---|
254 | diagram is no longer needed, the application must call <A NAME="tex2html8" |
---|
255 | HREF="cuddExtDet.html#Cudd_RecursiveDeref"><EM> Cudd_RecursiveDeref</EM></A><A NAME="1431"></A> (for BDDs |
---|
256 | and ADDs) or <A NAME="tex2html9" |
---|
257 | HREF="cuddExtDet.html#Cudd_RecursiveDerefZdd"><EM> Cudd_RecursiveDerefZdd</EM></A><A NAME="1433"></A> |
---|
258 | (for ZDDs) to ``recycle<A NAME="130"></A>" the nodes of the |
---|
259 | diagram. |
---|
260 | |
---|
261 | <P> |
---|
262 | Terminal<A NAME="131"></A> nodes carry a value. This is especially |
---|
263 | important for ADDs. By default, the value is a double<A NAME="132"></A>. |
---|
264 | To change to something different (e.g., an integer), the |
---|
265 | package must be modified and recompiled. Support for this process is |
---|
266 | currently very rudimentary. |
---|
267 | |
---|
268 | <P> |
---|
269 | |
---|
270 | <H3><A NAME="SECTION00032200000000000000"></A> |
---|
271 | <A NAME="134"></A><A NAME="sec:manager"></A> |
---|
272 | <BR> |
---|
273 | The Manager |
---|
274 | </H3> |
---|
275 | |
---|
276 | <P> |
---|
277 | All nodes used in BDDs, ADDs, and ZDDs are kept in special |
---|
278 | hash<A NAME="136"></A> tables called the <EM> unique<A NAME="137"></A> tables</EM>. Specifically, BDDs and ADDs |
---|
279 | share the same unique table, whereas ZDDs have their own table. As |
---|
280 | the name implies, the main purpose of the unique table is to guarantee |
---|
281 | that each node is unique; that is, there is no other node labeled by |
---|
282 | the same variable and with the same children. This uniqueness property |
---|
283 | makes decision diagrams canonical<A NAME="138"></A>. The |
---|
284 | unique<A NAME="139"></A> tables and some auxiliary data structures |
---|
285 | make up the DdManager<A NAME="140"></A> (manager<A NAME="141"></A> for |
---|
286 | short). Though the application that uses only the exported functions |
---|
287 | needs not be concerned with most details of the manager, it has to |
---|
288 | deal with the manager in the following sense. The application must |
---|
289 | initialize the manager by calling an appropriate function. (See |
---|
290 | Section <A HREF="node3.html#sec:init">3.3</A>.) Subsequently, it must pass a pointer to the |
---|
291 | manager to all the functions that operate on decision diagrams. |
---|
292 | |
---|
293 | <P> |
---|
294 | With the exception of a few statistical counters<A NAME="143"></A>, there are no global<A NAME="144"></A> variables in |
---|
295 | the CUDD package. Therefore, it is quite possible to have multiple |
---|
296 | managers simultaneously active in the same application.<A NAME="tex2html10" |
---|
297 | HREF="footnode.html#foot145"><SUP>1</SUP></A> It is the pointers to |
---|
298 | the managers that tell the functions on what data they should operate. |
---|
299 | |
---|
300 | <P> |
---|
301 | |
---|
302 | <H3><A NAME="SECTION00032300000000000000"></A> |
---|
303 | <A NAME="147"></A><A NAME="sec:memoize"></A> |
---|
304 | <BR> |
---|
305 | Cache |
---|
306 | </H3> |
---|
307 | |
---|
308 | <P> |
---|
309 | Efficient recursive manipulation of decision diagrams requires the use |
---|
310 | of a table to store computed results. This table<A NAME="149"></A> |
---|
311 | is called here the <EM>cache<A NAME="150"></A></EM> because it is |
---|
312 | effectively handled like a cache of variable but limited capacity. The |
---|
313 | CUDD package starts by default with a small cache, and increases its |
---|
314 | size until either no further benefit is achieved, or a limit size is |
---|
315 | reached. The user can influence this policy by choosing initial and |
---|
316 | limit values for the cache size. |
---|
317 | |
---|
318 | <P> |
---|
319 | Too small a cache will cause frequent overwriting of useful results. |
---|
320 | Too large a cache will cause overhead, because the whole cache is |
---|
321 | scanned every time garbage<A NAME="151"></A> collection takes |
---|
322 | place. The optimal parameters depend on the specific application. The |
---|
323 | default parameters work reasonably well for a large spectrum of |
---|
324 | applications. |
---|
325 | |
---|
326 | <P> |
---|
327 | The cache<A NAME="152"></A> of the CUDD package is used by most recursive |
---|
328 | functions of the package, and can be used by user-supplied functions |
---|
329 | as well. (See Section <A HREF="node4.html#sec:cache">4.4</A>.) |
---|
330 | |
---|
331 | <P> |
---|
332 | |
---|
333 | <H2><A NAME="SECTION00033000000000000000"></A> |
---|
334 | <A NAME="155"></A><A NAME="sec:init"></A> |
---|
335 | <BR> |
---|
336 | Initializing and Shutting Down a DdManager |
---|
337 | </H2> |
---|
338 | |
---|
339 | <P> |
---|
340 | To use the functions in the CUDD package, one has first to initialize |
---|
341 | the package itself by calling <A NAME="tex2html11" |
---|
342 | HREF="cuddExtDet.html#Cudd_Init"><EM> Cudd_Init</EM></A><A NAME="1435"></A>. This function takes four |
---|
343 | parameters: |
---|
344 | |
---|
345 | <UL> |
---|
346 | <LI>numVars<A NAME="161"></A>: It is the initial number of variables |
---|
347 | for BDDs and ADDs. If the total number of variables needed by the |
---|
348 | application is known, then it is slightly more efficient to create a |
---|
349 | manager with that number of variables. If the number is unknown, it |
---|
350 | can be set to 0, or to any other lower bound on the number of |
---|
351 | variables. Requesting more variables than are actually needed is |
---|
352 | not incorrect, but is not efficient. |
---|
353 | </LI> |
---|
354 | <LI>numVarsZ<A NAME="162"></A>: It is the initial number of variables |
---|
355 | for ZDDs. See Sections <A HREF="node3.html#sec:basicZDD">3.9</A> and <A HREF="node3.html#sec:convertZ">3.11</A> for |
---|
356 | a discussion of the value of this argument. |
---|
357 | </LI> |
---|
358 | <LI>numSlots<A NAME="165"></A>: Determines the initial size of each |
---|
359 | subtable<A NAME="166"></A> of the unique<A NAME="167"></A> table. |
---|
360 | There is a subtable for each variable. The size of each subtable is |
---|
361 | dynamically adjusted to reflect the number of nodes. It is normally |
---|
362 | O.K. to use the default value for this parameter, which is |
---|
363 | CUDD_UNIQUE_SLOTS<A NAME="168"></A>. |
---|
364 | </LI> |
---|
365 | <LI>cacheSize<A NAME="169"></A>: It is the initial size (number of |
---|
366 | entries) of the cache<A NAME="170"></A>. Its default value is |
---|
367 | CUDD_CACHE_SLOTS<A NAME="171"></A>. |
---|
368 | </LI> |
---|
369 | <LI>maxMemory<A NAME="172"></A>: It is the target value for the |
---|
370 | maximum memory occupation (in bytes). The package uses this value to |
---|
371 | decide two parameters. |
---|
372 | |
---|
373 | <UL> |
---|
374 | <LI>the maximum size to which the cache will grow, regardless of |
---|
375 | the hit rate or the size of the unique<A NAME="174"></A> table. |
---|
376 | </LI> |
---|
377 | <LI>the maximum size to which growth of the unique table will be |
---|
378 | preferred to garbage collection. |
---|
379 | |
---|
380 | </LI> |
---|
381 | </UL> |
---|
382 | If maxMemory is set to 0, CUDD tries to guess a good value based on |
---|
383 | the available memory. |
---|
384 | </LI> |
---|
385 | </UL> |
---|
386 | A typical call to <A NAME="tex2html12" |
---|
387 | HREF="cuddExtDet.html#Cudd_Init"><EM>Cudd_Init</EM></A><A NAME="1437"></A> may look |
---|
388 | like this: |
---|
389 | <PRE> |
---|
390 | manager = Cudd_Init(0,0,CUDD_UNIQUE_SLOTS,CUDD_CACHE_SLOTS,0); |
---|
391 | </PRE> |
---|
392 | To reclaim all the memory associated with a manager, an application |
---|
393 | must call <A NAME="tex2html13" |
---|
394 | HREF="cuddExtDet.html#Cudd_Quit"><EM>Cudd_Quit</EM></A><A NAME="1439"></A>. This is normally |
---|
395 | done before exiting. |
---|
396 | |
---|
397 | <P> |
---|
398 | |
---|
399 | <H2><A NAME="SECTION00034000000000000000"></A> |
---|
400 | <A NAME="sec:params"></A> |
---|
401 | <BR> |
---|
402 | Setting Parameters |
---|
403 | </H2> |
---|
404 | |
---|
405 | <P> |
---|
406 | The package provides several functions to set the parameters that |
---|
407 | control various functions. For instance, the package has an automatic |
---|
408 | way of determining whether a larger unique<A NAME="187"></A> table |
---|
409 | would make the application run faster. In that case, the package |
---|
410 | enters a ``fast growth<A NAME="188"></A>" mode in which resizing of |
---|
411 | the unique subtables is favored over garbage<A NAME="189"></A> |
---|
412 | collection. When the unique table reaches a given size, however, the |
---|
413 | package returns to the normal ``slow growth" mode, even though the |
---|
414 | conditions that caused the transition to fast growth still prevail. |
---|
415 | The limit size for fast growth<A NAME="190"></A> can be read by <A NAME="tex2html14" |
---|
416 | HREF="cuddExtDet.html#Cudd_ReadLooseUpTo"><EM> Cudd_ReadLooseUpTo</EM></A><A NAME="1441"></A> and changed |
---|
417 | by <A NAME="tex2html15" |
---|
418 | HREF="cuddExtDet.html#Cudd_SetLooseUpTo"><EM>Cudd_SetLooseUpTo</EM></A><A NAME="1443"></A>. Similar |
---|
419 | pairs of functions exist for several other parameters. See also |
---|
420 | Section <A HREF="node4.html#sec:stats">4.8</A>. |
---|
421 | |
---|
422 | <P> |
---|
423 | |
---|
424 | <H2><A NAME="SECTION00035000000000000000"></A> |
---|
425 | <A NAME="199"></A><A NAME="sec:const"></A> |
---|
426 | <BR> |
---|
427 | Constant Functions |
---|
428 | </H2> |
---|
429 | |
---|
430 | <P> |
---|
431 | The CUDD Package defines several constant functions. These functions |
---|
432 | are created when the manager<A NAME="201"></A> is initialized, and are accessible |
---|
433 | through the manager itself. |
---|
434 | |
---|
435 | <P> |
---|
436 | |
---|
437 | <H3><A NAME="SECTION00035100000000000000"></A> |
---|
438 | <A NAME="203"></A><A NAME="204"></A><A NAME="sec:zero"></A> |
---|
439 | <BR> |
---|
440 | One, Logic Zero, and Arithmetic Zero |
---|
441 | </H3> |
---|
442 | |
---|
443 | <P> |
---|
444 | The constant<A NAME="206"></A> 1 (returned by <A NAME="tex2html16" |
---|
445 | HREF="cuddExtDet.html#Cudd_ReadOne"><EM> Cudd_ReadOne</EM></A><A NAME="1445"></A>) is common to BDDs, |
---|
446 | ADDs, and ZDDs. However, its meaning is different for ADDs and BDDs, |
---|
447 | on the one hand, and ZDDs, on the other hand. The diagram consisting |
---|
448 | of the constant 1 node only represents the constant 1 function for |
---|
449 | ADDs and BDDs. For ZDDs, its meaning depends on the number of |
---|
450 | variables: It is the conjunction of the complements of all variables. |
---|
451 | Conversely, the representation of the constant 1 function depends on |
---|
452 | the number of variables. The constant 1 function of <IMG |
---|
453 | WIDTH="17" HEIGHT="19" ALIGN="BOTTOM" BORDER="0" |
---|
454 | SRC="img4.png" |
---|
455 | ALT="$n$"> variables is |
---|
456 | returned by <A NAME="tex2html17" |
---|
457 | HREF="cuddExtDet.html#Cudd_ReadZddOne"><EM>Cudd_ReadZddOne</EM></A><A NAME="1447"></A>. |
---|
458 | |
---|
459 | <P> |
---|
460 | The constant 0 is common to ADDs and ZDDs, but not to BDDs. The |
---|
461 | BDD<A NAME="213"></A> logic 0 is <B>not</B> associated |
---|
462 | with the constant 0 function: It is obtained by complementation (<A NAME="tex2html18" |
---|
463 | HREF="cuddExtDet.html#Cudd_Not"><EM> Cudd_Not</EM></A><A NAME="1449"></A>) of the constant 1. (It is also |
---|
464 | returned by <A NAME="tex2html19" |
---|
465 | HREF="cuddExtDet.html#Cudd_ReadLogicZero"><EM> Cudd_ReadLogicZero</EM></A><A NAME="1451"></A>.) All |
---|
466 | other constants are specific to ADDs. |
---|
467 | |
---|
468 | <P> |
---|
469 | |
---|
470 | <H3><A NAME="SECTION00035200000000000000"></A> |
---|
471 | <A NAME="sec:predef-const"></A> |
---|
472 | <BR> |
---|
473 | Predefined Constants |
---|
474 | </H3> |
---|
475 | |
---|
476 | <P> |
---|
477 | Besides 0 (returned by <A NAME="tex2html20" |
---|
478 | HREF="cuddExtDet.html#Cudd_ReadZero"><EM>Cudd_ReadZero</EM></A><A NAME="1453"></A>) |
---|
479 | and 1, the following constant<A NAME="226"></A> functions are |
---|
480 | created at initialization time. |
---|
481 | |
---|
482 | <OL> |
---|
483 | <LI>PlusInfinity<A NAME="228"></A> and |
---|
484 | MinusInfinity<A NAME="229"></A>: On computers implementing the |
---|
485 | IEEE<A NAME="230"></A> standard 754 for |
---|
486 | floating-point<A NAME="231"></A> arithmetic, these two constants |
---|
487 | are set to the signed infinities<A NAME="232"></A>. On the DEC |
---|
488 | Alphas<A NAME="233"></A>, the option <code>-ieee_with_no_inexact</code> or |
---|
489 | <code>-ieee_with_inexact</code> must be passed to the DEC compiler to get |
---|
490 | support of the IEEE standard. (The compiler still produces a |
---|
491 | warning, but it can be ignored.) Compiling<A NAME="234"></A> with |
---|
492 | those options may cause substantial performance degradation on the |
---|
493 | Evolution IV CPUs. (Especially if the application does use the |
---|
494 | infinities.) The problem is reportedly solved in the Evolution V |
---|
495 | CPUs. If <TT>gcc<A NAME="235"></A></TT> is used to compile CUDD on the |
---|
496 | Alphas, the symbol <TT>HAVE_IEEE_754<A NAME="236"></A></TT> must |
---|
497 | be undefined. (See the Makefile<A NAME="237"></A> for the details.) |
---|
498 | The values of these constants are returned by <A NAME="tex2html21" |
---|
499 | HREF="cuddExtDet.html#Cudd_ReadPlusInfinity"><EM> Cudd_ReadPlusInfinity</EM></A><A NAME="1455"></A> and <A NAME="tex2html22" |
---|
500 | HREF="cuddExtDet.html#Cudd_ReadMinusInfinity"><EM> Cudd_ReadMinusInfinity</EM></A><A NAME="1457"></A>. |
---|
501 | </LI> |
---|
502 | <LI>Epsilon<A NAME="244"></A>: This constant, initially set to |
---|
503 | |
---|
504 | <IMG |
---|
505 | WIDTH="49" HEIGHT="22" ALIGN="BOTTOM" BORDER="0" |
---|
506 | SRC="img5.png" |
---|
507 | ALT="$10^{-12}$">, is used in comparing floating point values for equality. |
---|
508 | Its value is returned by <A NAME="tex2html23" |
---|
509 | HREF="cuddExtDet.html#Cudd_ReadEpsilon"><EM> Cudd_ReadEpsilon</EM></A><A NAME="1459"></A>, and it can be |
---|
510 | |
---|
511 | modified by calling <A NAME="tex2html24" |
---|
512 | HREF="cuddExtDet.html#Cudd_SetEpsilon"><EM> Cudd_SetEpsilon</EM></A><A NAME="1461"></A>. Unlike the other |
---|
513 | |
---|
514 | constants, it does not correspond to a node. |
---|
515 | </LI> |
---|
516 | </OL> |
---|
517 | |
---|
518 | <P> |
---|
519 | |
---|
520 | <H3><A NAME="SECTION00035300000000000000"></A> |
---|
521 | <A NAME="254"></A><A NAME="sec:background"></A> |
---|
522 | <BR> |
---|
523 | Background |
---|
524 | </H3> |
---|
525 | |
---|
526 | <P> |
---|
527 | The background value is a constant<A NAME="256"></A> typically used |
---|
528 | to represent non-existing arcs in graphs. Consider a shortest path |
---|
529 | problem. Two nodes that are not connected by an arc can be regarded as |
---|
530 | being joined by an arc<A NAME="257"></A> of infinite length. In |
---|
531 | shortest path problems, it is therefore convenient to set the |
---|
532 | background value to PlusInfinity<A NAME="258"></A>. In network flow |
---|
533 | problems, on the other hand, two nodes not connected by an arc can be |
---|
534 | regarded as joined by an arc<A NAME="259"></A> of 0 capacity. |
---|
535 | For these problems, therefore, it is more convenient to set the |
---|
536 | background value to 0. In general, when representing |
---|
537 | sparse<A NAME="260"></A> matrices, the background value is the value that |
---|
538 | is assumed implicitly. |
---|
539 | |
---|
540 | <P> |
---|
541 | At initialization, the background value is set to 0. It can be read |
---|
542 | with <A NAME="tex2html25" |
---|
543 | HREF="cuddExtDet.html#Cudd_ReadBackground"><EM>Cudd_ReadBackground</EM></A><A NAME="1463"></A>, |
---|
544 | and modified with <A NAME="tex2html26" |
---|
545 | HREF="cuddExtDet.html#Cudd_SetBackground"><EM>Cudd_SetBackground</EM></A>. The background value |
---|
546 | affects procedures that read sparse matrices/graphs (<A NAME="tex2html27" |
---|
547 | HREF="cuddExtDet.html#Cudd_addRead"><EM> Cudd_addRead</EM></A><A NAME="1465"></A> and <A NAME="tex2html28" |
---|
548 | HREF="cuddExtDet.html#Cudd_addHarwell"><EM> Cudd_addHarwell</EM></A><A NAME="1467"></A>), procedures that |
---|
549 | print out sum-of-product<A NAME="272"></A> expressions |
---|
550 | for ADDs (<A NAME="tex2html29" |
---|
551 | HREF="cuddExtDet.html#Cudd_PrintMinterm"><EM> Cudd_PrintMinterm</EM></A><A NAME="1469"></A>), generators |
---|
552 | of cubes (<A NAME="tex2html30" |
---|
553 | HREF="cuddExtDet.html#Cudd_ForeachCube"><EM>Cudd_ForeachCube</EM></A><A NAME="1471"></A>), |
---|
554 | and procedures that count minterms<A NAME="279"></A> (<A NAME="tex2html31" |
---|
555 | HREF="cuddExtDet.html#Cudd_CountMinterm"><EM> Cudd_CountMinterm</EM></A><A NAME="1473"></A>). |
---|
556 | |
---|
557 | <P> |
---|
558 | |
---|
559 | <H3><A NAME="SECTION00035400000000000000"></A> |
---|
560 | <A NAME="sec:newconst"></A> |
---|
561 | <BR> |
---|
562 | New Constants |
---|
563 | </H3> |
---|
564 | |
---|
565 | <P> |
---|
566 | New constant<A NAME="285"></A> can be created by calling <A NAME="tex2html32" |
---|
567 | HREF="cuddExtDet.html#Cudd_addConst"><EM> Cudd_addConst</EM></A><A NAME="1475"></A>. This function will |
---|
568 | retrieve the ADD<A NAME="289"></A> for the desired |
---|
569 | constant, if it already exist, or it will create a new one. Obviously, |
---|
570 | new constants should only be used when manipulating ADDs. |
---|
571 | |
---|
572 | <P> |
---|
573 | |
---|
574 | <H2><A NAME="SECTION00036000000000000000"></A> |
---|
575 | <A NAME="sec:newvar"></A> |
---|
576 | <BR> |
---|
577 | Creating Variables |
---|
578 | </H2> |
---|
579 | |
---|
580 | <P> |
---|
581 | Decision diagrams are typically created by combining simpler decision |
---|
582 | diagrams. The simplest decision diagrams, of course, cannot be created |
---|
583 | in that way. Constant functions have been discussed in |
---|
584 | Section <A HREF="node3.html#sec:const">3.5</A>. In this section we discuss the simple |
---|
585 | variable functions, also known as <EM> projection<A NAME="293"></A> functions</EM>. |
---|
586 | |
---|
587 | <P> |
---|
588 | |
---|
589 | <H3><A NAME="SECTION00036100000000000000"></A> |
---|
590 | <A NAME="sec:BDDADDvar"></A> |
---|
591 | <BR> |
---|
592 | New BDD and ADD Variables |
---|
593 | </H3> |
---|
594 | |
---|
595 | <P> |
---|
596 | The projection<A NAME="296"></A> functions are distinct for |
---|
597 | BDDs and ADDs. A projection function for BDDs consists of an internal |
---|
598 | node with both outgoing arcs pointing to the constant 1. The <EM> else</EM> arc<A NAME="298"></A> is complemented. |
---|
599 | |
---|
600 | <P> |
---|
601 | An ADD projection function, on the other hand, has the <EM>else</EM> |
---|
602 | pointer directed to the arithmetic<A NAME="300"></A> zero |
---|
603 | function. One should never mix the two types of variables. BDD |
---|
604 | variables should be used when manipulating BDDs, and ADD variables |
---|
605 | should be used when manipulating ADDs. Three functions are provided |
---|
606 | to create BDD variables: |
---|
607 | |
---|
608 | <UL> |
---|
609 | <LI><A NAME="tex2html33" |
---|
610 | HREF="cuddExtDet.html#Cudd_bddIthVar"><EM>Cudd_bddIthVar</EM></A><A NAME="1477"></A>: Returns |
---|
611 | |
---|
612 | the projection<A NAME="305"></A> function with index <IMG |
---|
613 | WIDTH="12" HEIGHT="19" ALIGN="BOTTOM" BORDER="0" |
---|
614 | SRC="img6.png" |
---|
615 | ALT="$i$">. |
---|
616 | If the function does not exist, it is created. |
---|
617 | </LI> |
---|
618 | <LI><A NAME="tex2html34" |
---|
619 | HREF="cuddExtDet.html#Cudd_bddNewVar"><EM>Cudd_bddNewVar</EM></A><A NAME="1479"></A>: Returns a |
---|
620 | |
---|
621 | new projection<A NAME="309"></A> function, whose index is |
---|
622 | the largest index in use at the time of the call, plus 1. |
---|
623 | </LI> |
---|
624 | <LI><A NAME="tex2html35" |
---|
625 | HREF="cuddExtDet.html#Cudd_bddNewVarAtLevel"><EM> Cudd_bddNewVarAtLevel</EM></A><A NAME="1481"></A>: |
---|
626 | |
---|
627 | Similar to <A NAME="tex2html36" |
---|
628 | HREF="cuddExtDet.html#Cudd_bddNewVar"><EM>Cudd_bddNewVar</EM></A><A NAME="1483"></A>. In |
---|
629 | |
---|
630 | addition it allows to specify the position in the variable |
---|
631 | order<A NAME="316"></A> at which the new variable should be |
---|
632 | inserted. By contrast, <A NAME="tex2html37" |
---|
633 | HREF="cuddExtDet.html#Cudd_bddNewVar"><EM> Cudd_bddNewVar</EM></A><A NAME="1485"></A> adds the new |
---|
634 | |
---|
635 | variable at the end of the order. |
---|
636 | </LI> |
---|
637 | </UL> |
---|
638 | The analogous functions for ADDs are <A NAME="tex2html38" |
---|
639 | HREF="cuddExtDet.html#Cudd_addIthVar"><EM> Cudd_addIthVar</EM></A><A NAME="1487"></A>, <A NAME="tex2html39" |
---|
640 | HREF="cuddExtDet.html#Cudd_addNewVar"><EM> Cudd_addNewVar</EM></A><A NAME="1489"></A>, and <A NAME="tex2html40" |
---|
641 | HREF="cuddExtDet.html#Cudd_addNewVarAtLevel"><EM> Cudd_addNewVarAtLevel</EM></A><A NAME="1491"></A>. |
---|
642 | |
---|
643 | <P> |
---|
644 | |
---|
645 | <H3><A NAME="SECTION00036200000000000000"></A> |
---|
646 | <A NAME="331"></A><A NAME="sec:ZDDvars"></A> |
---|
647 | <BR> |
---|
648 | New ZDD Variables |
---|
649 | </H3> |
---|
650 | |
---|
651 | <P> |
---|
652 | Unlike the projection functions of BDDs and ADDs, the |
---|
653 | projection<A NAME="333"></A> functions of ZDDs have diagrams |
---|
654 | with <IMG |
---|
655 | WIDTH="47" HEIGHT="34" ALIGN="MIDDLE" BORDER="0" |
---|
656 | SRC="img7.png" |
---|
657 | ALT="$n+1$"> nodes, where <IMG |
---|
658 | WIDTH="17" HEIGHT="19" ALIGN="BOTTOM" BORDER="0" |
---|
659 | SRC="img4.png" |
---|
660 | ALT="$n$"> is the number of variables. Therefore the |
---|
661 | ZDDs of the projection functions change when new variables are added. |
---|
662 | This will be discussed in Section <A HREF="node3.html#sec:basicZDD">3.9</A>. Here we assume |
---|
663 | that the number of variables is fixed. The ZDD of the <IMG |
---|
664 | WIDTH="12" HEIGHT="19" ALIGN="BOTTOM" BORDER="0" |
---|
665 | SRC="img6.png" |
---|
666 | ALT="$i$">-th |
---|
667 | projection function is returned by <A NAME="tex2html41" |
---|
668 | HREF="cuddExtDet.html#Cudd_zddIthVar"><EM> Cudd_zddIthVar</EM></A><A NAME="1493"></A>. |
---|
669 | |
---|
670 | <P> |
---|
671 | |
---|
672 | <H2><A NAME="SECTION00037000000000000000"></A> |
---|
673 | <A NAME="339"></A><A NAME="sec:basicBDD"></A> |
---|
674 | <BR> |
---|
675 | Basic BDD Manipulation |
---|
676 | </H2> |
---|
677 | |
---|
678 | <P> |
---|
679 | Common manipulations of BDDs can be accomplished by calling <A NAME="tex2html42" |
---|
680 | HREF="cuddExtDet.html#Cudd_bddIte"><EM> Cudd_bddIte</EM></A>. This function takes three BDDs, <IMG |
---|
681 | WIDTH="17" HEIGHT="35" ALIGN="MIDDLE" BORDER="0" |
---|
682 | SRC="img8.png" |
---|
683 | ALT="$f$">, <IMG |
---|
684 | WIDTH="15" HEIGHT="34" ALIGN="MIDDLE" BORDER="0" |
---|
685 | SRC="img9.png" |
---|
686 | ALT="$g$">, and <IMG |
---|
687 | WIDTH="17" HEIGHT="19" ALIGN="BOTTOM" BORDER="0" |
---|
688 | SRC="img10.png" |
---|
689 | ALT="$h$">, |
---|
690 | as arguments and computes <!-- MATH |
---|
691 | $f\cdot g + f'\cdot h$ |
---|
692 | --> |
---|
693 | <IMG |
---|
694 | WIDTH="97" HEIGHT="37" ALIGN="MIDDLE" BORDER="0" |
---|
695 | SRC="img11.png" |
---|
696 | ALT="$f\cdot g + f'\cdot h$">. Like all the |
---|
697 | functions that create new BDDs or ADDs, <A NAME="tex2html43" |
---|
698 | HREF="cuddExtDet.html#Cudd_bddIte"><EM> Cudd_bddIte</EM></A><A NAME="1495"></A> returns a result that must |
---|
699 | be explicitly referenced by the caller. <A NAME="tex2html44" |
---|
700 | HREF="cuddExtDet.html#Cudd_bddIte"><EM>Cudd_bddIte</EM></A> |
---|
701 | can be |
---|
702 | used to implement all two-argument boolean functions. However, the |
---|
703 | package also provides <A NAME="tex2html45" |
---|
704 | HREF="cuddExtDet.html#Cudd_bddAnd"><EM>Cudd_bddAnd</EM></A><A NAME="1497"></A> |
---|
705 | as well as the other two-operand boolean functions, which are slightly |
---|
706 | more efficient when a two-operand function is called for. The |
---|
707 | following fragment of code illustrates how to build the BDD for the |
---|
708 | function <!-- MATH |
---|
709 | $f = x_0'x_1'x_2'x_3'$ |
---|
710 | --> |
---|
711 | <IMG |
---|
712 | WIDTH="110" HEIGHT="37" ALIGN="MIDDLE" BORDER="0" |
---|
713 | SRC="img12.png" |
---|
714 | ALT="$f = x_0'x_1'x_2'x_3'$">. |
---|
715 | <PRE> |
---|
716 | DdManager *manager; |
---|
717 | DdNode *f, *var, *tmp; |
---|
718 | int i; |
---|
719 | |
---|
720 | ... |
---|
721 | |
---|
722 | f = Cudd_ReadOne(manager); |
---|
723 | Cudd_Ref(f); |
---|
724 | for (i = 3; i >= 0; i--) { |
---|
725 | var = Cudd_bddIthVar(manager,i); |
---|
726 | tmp = Cudd_bddAnd(manager,Cudd_Not(var),f); |
---|
727 | Cudd_Ref(tmp); |
---|
728 | Cudd_RecursiveDeref(manager,f); |
---|
729 | f = tmp; |
---|
730 | } |
---|
731 | </PRE> |
---|
732 | This example illustrates the following points: |
---|
733 | |
---|
734 | <UL> |
---|
735 | <LI>Intermediate results must be ``referenced" and ``dereferenced." |
---|
736 | However, <TT>var</TT> is a projection<A NAME="355"></A> |
---|
737 | function, and its reference<A NAME="356"></A> count is always |
---|
738 | greater than 0. Therefore, there is no call to <A NAME="tex2html46" |
---|
739 | HREF="cuddExtDet.html#Cudd_Ref"><EM> Cudd_Ref</EM></A><A NAME="1499"></A>. |
---|
740 | </LI> |
---|
741 | <LI>The new <TT>f</TT> must be assigned to a temporary variable (<TT> tmp</TT> in this example). If the result of <A NAME="tex2html47" |
---|
742 | HREF="cuddExtDet.html#Cudd_bddAnd"><EM> Cudd_bddAnd</EM></A><A NAME="1501"></A> were assigned directly |
---|
743 | |
---|
744 | to <TT>f</TT>, the old <TT>f</TT> would be lost, and there would be no way |
---|
745 | to free its nodes. |
---|
746 | </LI> |
---|
747 | <LI>The statement <TT>f = tmp</TT> has the same effect as: |
---|
748 | <PRE> |
---|
749 | f = tmp; |
---|
750 | Cudd_Ref(f); |
---|
751 | Cudd_RecursiveDeref(manager,tmp); |
---|
752 | </PRE> |
---|
753 | but is more efficient. The reference<A NAME="370"></A> is |
---|
754 | ``passed" from <TT>tmp</TT> to <TT>f</TT>, and <TT>tmp</TT> is now ready to |
---|
755 | be reutilized. |
---|
756 | </LI> |
---|
757 | <LI>It is normally more efficient to build BDDs ``bottom-up." This |
---|
758 | is why the loop goes from 3 to 0. Notice, however, that after |
---|
759 | variable reordering, higher index does not necessarily mean ``closer |
---|
760 | to the bottom." Of course, in this simple example, efficiency is not |
---|
761 | a concern. |
---|
762 | </LI> |
---|
763 | <LI>Had we wanted to conjoin the variables in a bottom-up fashion |
---|
764 | even after reordering, we should have used <A NAME="tex2html48" |
---|
765 | HREF="cuddExtDet.html#Cudd_ReadInvPerm"><EM> Cudd_ReadInvPerm</EM></A><A NAME="1503"></A>. One has to be |
---|
766 | |
---|
767 | careful, though, to fix the order of conjunction before entering the |
---|
768 | loop. Otherwise, if reordering takes place, it is possible to use |
---|
769 | one variable twice and skip another variable. |
---|
770 | </LI> |
---|
771 | </UL> |
---|
772 | |
---|
773 | <P> |
---|
774 | |
---|
775 | <H2><A NAME="SECTION00038000000000000000"></A> |
---|
776 | <A NAME="379"></A><A NAME="sec:basicADD"></A> |
---|
777 | <BR> |
---|
778 | Basic ADD Manipulation |
---|
779 | </H2> |
---|
780 | |
---|
781 | <P> |
---|
782 | The most common way to manipulate ADDs is via <A NAME="tex2html49" |
---|
783 | HREF="cuddExtDet.html#Cudd_addApply"><EM> Cudd_addApply</EM></A><A NAME="1505"></A>. This function can |
---|
784 | apply a wide variety of operators to a pair of ADDs. Among the |
---|
785 | available operators are addition, multiplication, division, minimum, |
---|
786 | maximum, and boolean operators that work on ADDs whose leaves are |
---|
787 | restricted to 0 and 1 (0-1 ADDs). |
---|
788 | |
---|
789 | <P> |
---|
790 | The following fragment of code illustrates how to build the ADD for |
---|
791 | the function <!-- MATH |
---|
792 | $f = 5x_0x_1x_2x_3$ |
---|
793 | --> |
---|
794 | <IMG |
---|
795 | WIDTH="119" HEIGHT="35" ALIGN="MIDDLE" BORDER="0" |
---|
796 | SRC="img13.png" |
---|
797 | ALT="$f = 5x_0x_1x_2x_3$">. |
---|
798 | <PRE> |
---|
799 | DdManager *manager; |
---|
800 | DdNode *f, *var, *tmp; |
---|
801 | int i; |
---|
802 | |
---|
803 | ... |
---|
804 | |
---|
805 | f = Cudd_addConst(manager,5); |
---|
806 | Cudd_Ref(f); |
---|
807 | for (i = 3; i >= 0; i--) { |
---|
808 | var = Cudd_addIthVar(manager,i); |
---|
809 | Cudd_Ref(var); |
---|
810 | tmp = Cudd_addApply(manager,Cudd_addTimes,var,f); |
---|
811 | Cudd_Ref(tmp); |
---|
812 | Cudd_RecursiveDeref(manager,f); |
---|
813 | Cudd_RecursiveDeref(manager,var); |
---|
814 | f = tmp; |
---|
815 | } |
---|
816 | </PRE> |
---|
817 | This example, contrasted to the example of BDD manipulation, |
---|
818 | illustrates the following points: |
---|
819 | |
---|
820 | <UL> |
---|
821 | <LI>The ADD projection<A NAME="387"></A> function are not |
---|
822 | maintained by the manager. It is therefore necessary to |
---|
823 | reference<A NAME="388"></A> and |
---|
824 | dereference<A NAME="389"></A> them. |
---|
825 | </LI> |
---|
826 | <LI>The product of two ADDs is computed by calling <A NAME="tex2html50" |
---|
827 | HREF="cuddExtDet.html#Cudd_addApply"><EM> Cudd_addApply</EM></A><A NAME="1507"></A> with <A NAME="tex2html51" |
---|
828 | HREF="cuddExtDet.html#Cudd_addTimes"><EM> Cudd_addTimes</EM></A><A NAME="1509"></A> as parameter. There |
---|
829 | |
---|
830 | is no ``apply'' function for BDDs, because <A NAME="tex2html52" |
---|
831 | HREF="cuddExtDet.html#Cudd_bddAnd"><EM> Cudd_bddAnd</EM></A><A NAME="1511"></A> and <A NAME="tex2html53" |
---|
832 | HREF="cuddExtDet.html#Cudd_bddXor"><EM> Cudd_bddXor</EM></A><A NAME="1513"></A> plus complementation are |
---|
833 | |
---|
834 | sufficient to implement all two-argument boolean functions. |
---|
835 | </LI> |
---|
836 | </UL> |
---|
837 | |
---|
838 | <P> |
---|
839 | |
---|
840 | <H2><A NAME="SECTION00039000000000000000"></A> |
---|
841 | <A NAME="404"></A><A NAME="sec:basicZDD"></A> |
---|
842 | <BR> |
---|
843 | Basic ZDD Manipulation |
---|
844 | </H2> |
---|
845 | |
---|
846 | <P> |
---|
847 | ZDDs are often generated by converting<A NAME="406"></A> |
---|
848 | existing BDDs. (See Section <A HREF="node3.html#sec:convertZ">3.11</A>.) However, it is also |
---|
849 | possible to build ZDDs by applying boolean operators to other ZDDs, |
---|
850 | starting from constants and projection<A NAME="408"></A> |
---|
851 | functions. The following fragment of code illustrates how to build |
---|
852 | the ZDD for the function <!-- MATH |
---|
853 | $f = x_0'+x_1'+x_2'+x_3'$ |
---|
854 | --> |
---|
855 | <IMG |
---|
856 | WIDTH="174" HEIGHT="37" ALIGN="MIDDLE" BORDER="0" |
---|
857 | SRC="img14.png" |
---|
858 | ALT="$f = x_0'+x_1'+x_2'+x_3'$">. We assume that the |
---|
859 | four variables already exist in the manager when the ZDD for <IMG |
---|
860 | WIDTH="17" HEIGHT="35" ALIGN="MIDDLE" BORDER="0" |
---|
861 | SRC="img8.png" |
---|
862 | ALT="$f$"> is |
---|
863 | built. Note the use of De Morgan's law. |
---|
864 | <PRE> |
---|
865 | DdManager *manager; |
---|
866 | DdNode *f, *var, *tmp; |
---|
867 | int i; |
---|
868 | |
---|
869 | manager = Cudd_Init(0,4,CUDD_UNIQUE_SLOTS, |
---|
870 | CUDD_CACHE_SLOTS,0); |
---|
871 | ... |
---|
872 | |
---|
873 | tmp = Cudd_ReadZddOne(manager,0); |
---|
874 | Cudd_Ref(tmp); |
---|
875 | for (i = 3; i >= 0; i--) { |
---|
876 | var = Cudd_zddIthVar(manager,i); |
---|
877 | Cudd_Ref(var); |
---|
878 | f = Cudd_zddIntersect(manager,var,tmp); |
---|
879 | Cudd_Ref(f); |
---|
880 | Cudd_RecursiveDerefZdd(manager,tmp); |
---|
881 | Cudd_RecursiveDerefZdd(manager,var); |
---|
882 | tmp = f; |
---|
883 | } |
---|
884 | f = Cudd_zddDiff(manager,Cudd_ReadZddOne(manager,0),tmp); |
---|
885 | Cudd_Ref(f); |
---|
886 | Cudd_RecursiveDerefZdd(manager,tmp); |
---|
887 | </PRE> |
---|
888 | This example illustrates the following points: |
---|
889 | |
---|
890 | <UL> |
---|
891 | <LI>The projection<A NAME="412"></A> functions are |
---|
892 | referenced, because they are not maintained by the manager. |
---|
893 | </LI> |
---|
894 | <LI>Complementation is obtained by subtracting from the constant 1 |
---|
895 | function. |
---|
896 | </LI> |
---|
897 | <LI>The result of <A NAME="tex2html54" |
---|
898 | HREF="cuddExtDet.html#Cudd_ReadZddOne"><EM> Cudd_ReadZddOne</EM></A><A NAME="1515"></A> does not |
---|
899 | |
---|
900 | require referencing. |
---|
901 | </LI> |
---|
902 | </UL> |
---|
903 | CUDD provides functions for the manipulation of |
---|
904 | covers<A NAME="417"></A> represented by ZDDs. For instance, <A NAME="tex2html55" |
---|
905 | HREF="cuddExtDet.html#Cudd_zddIsop"><EM> Cudd_zddIsop</EM></A><A NAME="1517"></A> builds a ZDD |
---|
906 | representing an irredundant<A NAME="421"></A> sum of |
---|
907 | products for the incompletely specified function defined by the two |
---|
908 | BDDs <IMG |
---|
909 | WIDTH="18" HEIGHT="19" ALIGN="BOTTOM" BORDER="0" |
---|
910 | SRC="img15.png" |
---|
911 | ALT="$L$"> and <IMG |
---|
912 | WIDTH="20" HEIGHT="19" ALIGN="BOTTOM" BORDER="0" |
---|
913 | SRC="img16.png" |
---|
914 | ALT="$U$">. <A NAME="tex2html56" |
---|
915 | HREF="cuddExtDet.html#Cudd_zddWeakDiv"><EM> Cudd_zddWeakDiv</EM></A><A NAME="1519"></A> performs the weak |
---|
916 | division of two covers given as ZDDs. These functions expect the two |
---|
917 | ZDD variables corresponding to the two literals of the function variable |
---|
918 | to be adjacent. One has to create variable groups (see |
---|
919 | Section <A HREF="node3.html#sec:reordZ">3.14</A>) for reordering<A NAME="426"></A> of |
---|
920 | the ZDD variables to work. BDD automatic reordering is safe even |
---|
921 | without groups: If realignment of ZDD and ADD/BDD variables is requested |
---|
922 | (see Section <A HREF="node3.html#sec:consist">3.15</A>) groups will be kept adjacent. |
---|
923 | |
---|
924 | <P> |
---|
925 | |
---|
926 | <H2><A NAME="SECTION000310000000000000000"></A> |
---|
927 | <A NAME="429"></A> |
---|
928 | <A NAME="430"></A><A NAME="sec:convert"></A> |
---|
929 | <BR> |
---|
930 | Converting ADDs to BDDs and Vice Versa |
---|
931 | </H2> |
---|
932 | |
---|
933 | <P> |
---|
934 | Several procedures are provided to convert ADDs to BDDs, according to |
---|
935 | different criteria. (<A NAME="tex2html57" |
---|
936 | HREF="cuddExtDet.html#Cudd_addBddPattern"><EM> Cudd_addBddPattern</EM></A><A NAME="1521"></A>, <A NAME="tex2html58" |
---|
937 | HREF="cuddExtDet.html#Cudd_addBddInterval"><EM> Cudd_addBddInterval</EM></A><A NAME="1523"></A>, and <A NAME="tex2html59" |
---|
938 | HREF="cuddExtDet.html#Cudd_addBddThreshold"><EM> Cudd_addBddThreshold</EM></A><A NAME="1525"></A>.) The |
---|
939 | conversion from BDDs to ADDs (<A NAME="tex2html60" |
---|
940 | HREF="cuddExtDet.html#Cudd_BddToAdd"><EM> Cudd_BddToAdd</EM></A><A NAME="1527"></A>) is based on the |
---|
941 | simple principle of mapping the logical 0<A NAME="444"></A> and 1 on |
---|
942 | the arithmetic<A NAME="445"></A> 0 and 1. It is also possible to |
---|
943 | convert an ADD with integer values (more precisely, floating point |
---|
944 | numbers with 0 fractional part) to an array of BDDs by repeatedly |
---|
945 | calling <A NAME="tex2html61" |
---|
946 | HREF="cuddExtDet.html#Cudd_addIthBit"><EM>Cudd_addIthBit</EM></A><A NAME="1529"></A>. |
---|
947 | |
---|
948 | <P> |
---|
949 | |
---|
950 | <H2><A NAME="SECTION000311000000000000000"></A> |
---|
951 | <A NAME="450"></A> |
---|
952 | <A NAME="451"></A><A NAME="sec:convertZ"></A> |
---|
953 | <BR> |
---|
954 | Converting BDDs to ZDDs and Vice Versa |
---|
955 | </H2> |
---|
956 | |
---|
957 | <P> |
---|
958 | Many applications first build a set of BDDs and then derive ZDDs from |
---|
959 | the BDDs. These applications should create the manager with 0 |
---|
960 | ZDD<A NAME="453"></A> variables and |
---|
961 | create the BDDs. Then they should call <A NAME="tex2html62" |
---|
962 | HREF="cuddExtDet.html#Cudd_zddVarsFromBddVars"><EM> Cudd_zddVarsFromBddVars</EM></A><A NAME="1531"></A> to |
---|
963 | create the necessary ZDD variables--whose number is likely to be |
---|
964 | known once the BDDs are available. This approach eliminates the |
---|
965 | difficulties that arise when the number of ZDD variables changes while |
---|
966 | ZDDs are being built. |
---|
967 | |
---|
968 | <P> |
---|
969 | The simplest conversion from BDDs to ZDDs is a simple change of |
---|
970 | representation, which preserves the functions. Simply put, given a BDD |
---|
971 | for <IMG |
---|
972 | WIDTH="17" HEIGHT="35" ALIGN="MIDDLE" BORDER="0" |
---|
973 | SRC="img8.png" |
---|
974 | ALT="$f$">, a ZDD for <IMG |
---|
975 | WIDTH="17" HEIGHT="35" ALIGN="MIDDLE" BORDER="0" |
---|
976 | SRC="img8.png" |
---|
977 | ALT="$f$"> is requested. In this case the correspondence |
---|
978 | between the BDD variables and ZDD variables is one-to-one. Hence, <A NAME="tex2html63" |
---|
979 | HREF="cuddExtDet.html#Cudd_zddVarsFromBddVars"><EM> Cudd_zddVarsFromBddVars</EM></A> |
---|
980 | should be called with the <EM> multiplicity</EM> parameter equal to 1. The conversion proper can then |
---|
981 | be performed by calling <A NAME="tex2html64" |
---|
982 | HREF="cuddExtDet.html#Cudd_zddPortFromBdd"><EM> Cudd_zddPortFromBdd</EM></A><A NAME="1533"></A>. The |
---|
983 | inverse transformation is performed by <A NAME="tex2html65" |
---|
984 | HREF="cuddExtDet.html#Cudd_zddPortToBdd"><EM> Cudd_zddPortToBdd</EM></A><A NAME="1535"></A>. |
---|
985 | |
---|
986 | <P> |
---|
987 | ZDDs are quite often used for the representation of <EM> covers</EM><A NAME="467"></A>. This is normally done by associating |
---|
988 | two ZDD variables to each variable of the function. (And hence, |
---|
989 | typically, to each BDD variable.) One ZDD variable is associated with |
---|
990 | the positive literal of the BDD variable, while the other ZDD variable |
---|
991 | is associated with the negative literal. A call to <A NAME="tex2html66" |
---|
992 | HREF="cuddExtDet.html#Cudd_zddVarsFromBddVars"><EM> Cudd_zddVarsFromBddVars</EM></A><A NAME="1537"></A> |
---|
993 | with <EM>multiplicity</EM> equal to 2 will associate to BDD variable |
---|
994 | <IMG |
---|
995 | WIDTH="12" HEIGHT="19" ALIGN="BOTTOM" BORDER="0" |
---|
996 | SRC="img6.png" |
---|
997 | ALT="$i$"> the two ZDD variables <IMG |
---|
998 | WIDTH="21" HEIGHT="19" ALIGN="BOTTOM" BORDER="0" |
---|
999 | SRC="img17.png" |
---|
1000 | ALT="$2i$"> and <IMG |
---|
1001 | WIDTH="51" HEIGHT="34" ALIGN="MIDDLE" BORDER="0" |
---|
1002 | SRC="img18.png" |
---|
1003 | ALT="$2i+1$">. |
---|
1004 | |
---|
1005 | <P> |
---|
1006 | If a BDD variable group tree exists when <A NAME="tex2html67" |
---|
1007 | HREF="cuddExtDet.html#Cudd_zddVarsFromBddVars"><EM> Cudd_zddVarsFromBddVars</EM></A> |
---|
1008 | is called (see Section <A HREF="node3.html#sec:group">3.13</A>) |
---|
1009 | the function generates a ZDD variable group tree consistent to it. In |
---|
1010 | any case, all the ZDD variables derived from the same BDD variable are |
---|
1011 | clustered into a group. |
---|
1012 | |
---|
1013 | <P> |
---|
1014 | If the ZDD for <IMG |
---|
1015 | WIDTH="17" HEIGHT="35" ALIGN="MIDDLE" BORDER="0" |
---|
1016 | SRC="img8.png" |
---|
1017 | ALT="$f$"> is created and later a new ZDD variable is added to |
---|
1018 | the manager, the function represented by the existing ZDD changes. |
---|
1019 | Suppose, for instance, that two variables are initially created, and |
---|
1020 | that the ZDD for <IMG |
---|
1021 | WIDTH="97" HEIGHT="35" ALIGN="MIDDLE" BORDER="0" |
---|
1022 | SRC="img19.png" |
---|
1023 | ALT="$f = x_0 + x_1$"> is built. If a third variable is |
---|
1024 | added, say <IMG |
---|
1025 | WIDTH="24" HEIGHT="34" ALIGN="MIDDLE" BORDER="0" |
---|
1026 | SRC="img20.png" |
---|
1027 | ALT="$x_2$">, then the ZDD represents <!-- MATH |
---|
1028 | $g = (x_0 + x_1) x_2'$ |
---|
1029 | --> |
---|
1030 | <IMG |
---|
1031 | WIDTH="126" HEIGHT="37" ALIGN="MIDDLE" BORDER="0" |
---|
1032 | SRC="img21.png" |
---|
1033 | ALT="$g = (x_0 + x_1) x_2'$"> |
---|
1034 | instead. This change in function obviously applies regardless of what |
---|
1035 | use is made of the ZDD. However, if the ZDD is used to represent a |
---|
1036 | cover<A NAME="475"></A>, the cover itself is not changed by the |
---|
1037 | addition of new variable. (What changes is the |
---|
1038 | characteristic<A NAME="476"></A> function of the cover.) |
---|
1039 | |
---|
1040 | <P> |
---|
1041 | |
---|
1042 | <H2><A NAME="SECTION000312000000000000000"></A> |
---|
1043 | <A NAME="478"></A><A NAME="sec:reorder"></A> |
---|
1044 | <BR> |
---|
1045 | Variable Reordering for BDDs and ADDs |
---|
1046 | </H2> |
---|
1047 | |
---|
1048 | <P> |
---|
1049 | The CUDD package provides a rich set of |
---|
1050 | dynamic<A NAME="480"></A> reordering algorithms. Some of them |
---|
1051 | are slight variations of existing techniques |
---|
1052 | [<A |
---|
1053 | HREF="node7.html#Rudell93">16</A>,<A |
---|
1054 | HREF="node7.html#Drechs95">6</A>,<A |
---|
1055 | HREF="node7.html#Bollig95">2</A>,<A |
---|
1056 | HREF="node7.html#Ishiur91">10</A>,<A |
---|
1057 | HREF="node7.html#Plessi93">15</A>,<A |
---|
1058 | HREF="node7.html#Jeong93">11</A>]; some |
---|
1059 | others have been developed specifically for this package |
---|
1060 | [<A |
---|
1061 | HREF="node7.html#Panda94">14</A>,<A |
---|
1062 | HREF="node7.html#Panda95b">13</A>]. |
---|
1063 | |
---|
1064 | <P> |
---|
1065 | Reordering affects a unique<A NAME="483"></A> table. This means that |
---|
1066 | BDDs and ADDs, which share the same unique table are simultaneously |
---|
1067 | reordered. ZDDs, on the other hand, are reordered separately. In the |
---|
1068 | following we discuss the reordering of BDDs and ADDs. Reordering for |
---|
1069 | ZDDs is the subject of Section <A HREF="node3.html#sec:reordZ">3.14</A>. |
---|
1070 | |
---|
1071 | <P> |
---|
1072 | Reordering of the variables can be invoked directly by the application |
---|
1073 | by calling <A NAME="tex2html68" |
---|
1074 | HREF="cuddExtDet.html#Cudd_ReduceHeap"><EM>Cudd_ReduceHeap</EM></A><A NAME="1539"></A>. Or it |
---|
1075 | can be automatically triggered by the package when the number of nodes |
---|
1076 | has reached a given threshold<A NAME="488"></A>. (The |
---|
1077 | threshold is initialized and automatically adjusted after each |
---|
1078 | reordering by the package.) To enable automatic dynamic reordering |
---|
1079 | (also called <EM>asynchronous<A NAME="489"></A></EM> |
---|
1080 | dynamic reordering in this document) the application must call <A NAME="tex2html69" |
---|
1081 | HREF="cuddExtDet.html#Cudd_AutodynEnable"><EM> Cudd_AutodynEnable</EM></A><A NAME="1541"></A>. Automatic |
---|
1082 | dynamic reordering can subsequently be disabled by calling <A NAME="tex2html70" |
---|
1083 | HREF="cuddExtDet.html#Cudd_AutodynDisable"><EM> Cudd_AutodynDisable</EM></A><A NAME="1543"></A>. |
---|
1084 | |
---|
1085 | <P> |
---|
1086 | All reordering methods are available in both the case of direct call |
---|
1087 | to <A NAME="tex2html71" |
---|
1088 | HREF="cuddExtDet.html#Cudd_ReduceHeap"><EM>Cudd_ReduceHeap</EM></A><A NAME="1545"></A> and the case of |
---|
1089 | automatic invocation. For many methods, the reordering procedure is |
---|
1090 | iterated until no further improvement is obtained. We call these |
---|
1091 | methods the <EM>converging<A NAME="499"></A></EM> methods. |
---|
1092 | When constraints are imposed on the relative position of variables |
---|
1093 | (see Section <A HREF="node3.html#sec:group">3.13</A>) the reordering methods apply inside the |
---|
1094 | groups. The groups<A NAME="501"></A> themselves are reordered by |
---|
1095 | sifting<A NAME="502"></A>. Each method is identified by a |
---|
1096 | constant of the enumerated type <EM> Cudd_ReorderingType<A NAME="503"></A></EM> |
---|
1097 | defined in <EM>cudd.h<A NAME="504"></A></EM> (the external |
---|
1098 | header<A NAME="505"></A> file of the CUDD package): |
---|
1099 | |
---|
1100 | <P> |
---|
1101 | <DL> |
---|
1102 | <DT><STRONG>CUDD_REORDER_NONE<A NAME="507"></A>:</STRONG></DT> |
---|
1103 | <DD>This method |
---|
1104 | causes no reordering. |
---|
1105 | </DD> |
---|
1106 | <DT><STRONG>CUDD_REORDER_SAME<A NAME="508"></A>:</STRONG></DT> |
---|
1107 | <DD>If passed to |
---|
1108 | <A NAME="tex2html72" |
---|
1109 | HREF="cuddExtDet.html#Cudd_AutodynEnable"><EM>Cudd_AutodynEnable</EM></A><A NAME="1547"></A>, this |
---|
1110 | |
---|
1111 | method leaves the current method for automatic reordering unchanged. |
---|
1112 | If passed to <A NAME="tex2html73" |
---|
1113 | HREF="cuddExtDet.html#Cudd_ReduceHeap"><EM>Cudd_ReduceHeap</EM></A><A NAME="1549"></A>, |
---|
1114 | |
---|
1115 | this method causes the current method for automatic reordering to be |
---|
1116 | used. |
---|
1117 | </DD> |
---|
1118 | <DT><STRONG>CUDD_REORDER_RANDOM<A NAME="515"></A>:</STRONG></DT> |
---|
1119 | <DD>Pairs of |
---|
1120 | variables are randomly chosen, and swapped in the order. The swap is |
---|
1121 | performed by a series of swaps of adjacent variables. The best order |
---|
1122 | among those obtained by the series of swaps is retained. The number |
---|
1123 | of pairs chosen for swapping<A NAME="516"></A> equals the |
---|
1124 | number of variables in the diagram. |
---|
1125 | </DD> |
---|
1126 | <DT><STRONG>CUDD_REORDER_RANDOM_PIVOT<A NAME="517"></A>:</STRONG></DT> |
---|
1127 | <DD>Same as CUDD_REORDER_RANDOM, but the two variables are chosen so |
---|
1128 | that the first is above the variable with the largest number of |
---|
1129 | nodes, and the second is below that variable. In case there are |
---|
1130 | several variables tied for the maximum number of nodes, the one |
---|
1131 | closest to the root is used. |
---|
1132 | </DD> |
---|
1133 | <DT><STRONG>CUDD_REORDER_SIFT<A NAME="518"></A>:</STRONG></DT> |
---|
1134 | <DD>This method is |
---|
1135 | an implementation of Rudell's sifting<A NAME="519"></A> |
---|
1136 | algorithm [<A |
---|
1137 | HREF="node7.html#Rudell93">16</A>]. A simplified description of sifting is as |
---|
1138 | follows: Each variable is considered in turn. A variable is moved up |
---|
1139 | and down in the order so that it takes all possible positions. The |
---|
1140 | best position is identified and the variable is returned to that |
---|
1141 | position. |
---|
1142 | |
---|
1143 | <P> |
---|
1144 | In reality, things are a bit more complicated. For instance, there |
---|
1145 | is a limit on the number of variables that will be sifted. This |
---|
1146 | limit can be read with <A NAME="tex2html74" |
---|
1147 | HREF="cuddExtDet.html#Cudd_ReadSiftMaxVar"><EM> Cudd_ReadSiftMaxVar</EM></A><A NAME="1551"></A> and set |
---|
1148 | |
---|
1149 | with <A NAME="tex2html75" |
---|
1150 | HREF="cuddExtDet.html#Cudd_SetSiftMaxVar"><EM>Cudd_SetSiftMaxVar</EM></A><A NAME="1553"></A>. In |
---|
1151 | |
---|
1152 | addition, if the diagram grows too much while moving a variable up |
---|
1153 | or down, that movement is terminated before the variable has reached |
---|
1154 | one end of the order. The maximum ratio by which the diagram is |
---|
1155 | allowed to grow while a variable is being sifted can be read with |
---|
1156 | <A NAME="tex2html76" |
---|
1157 | HREF="cuddExtDet.html#Cudd_ReadMaxGrowth"><EM>Cudd_ReadMaxGrowth</EM></A><A NAME="1555"></A> and |
---|
1158 | |
---|
1159 | set with <A NAME="tex2html77" |
---|
1160 | HREF="cuddExtDet.html#Cudd_SetMaxGrowth"><EM>Cudd_SetMaxGrowth</EM></A><A NAME="1557"></A>. |
---|
1161 | </DD> |
---|
1162 | <DT><STRONG>CUDD_REORDER_SIFT_CONVERGE<A NAME="533"></A>:</STRONG></DT> |
---|
1163 | <DD>This is the converging<A NAME="534"></A> variant of |
---|
1164 | |
---|
1165 | CUDD_REORDER_SIFT. |
---|
1166 | </DD> |
---|
1167 | <DT><STRONG>CUDD_REORDER_SYMM_SIFT<A NAME="535"></A>:</STRONG></DT> |
---|
1168 | <DD>This method is an implementation of |
---|
1169 | symmetric<A NAME="536"></A> sifting [<A |
---|
1170 | HREF="node7.html#Panda94">14</A>]. It is |
---|
1171 | similar to sifting, with one addition: Variables that become |
---|
1172 | adjacent during sifting are tested for symmetry<A NAME="538"></A>. If |
---|
1173 | they are symmetric, they are linked in a group. Sifting then |
---|
1174 | continues with a group being moved, instead of a single variable. |
---|
1175 | After symmetric sifting has been run, <A NAME="tex2html78" |
---|
1176 | HREF="cuddExtDet.html#Cudd_SymmProfile"><EM> Cudd_SymmProfile</EM></A><A NAME="1559"></A> can be called |
---|
1177 | |
---|
1178 | to report on the symmetry groups found. (Both positive and negative |
---|
1179 | symmetries are reported.) |
---|
1180 | </DD> |
---|
1181 | <DT><STRONG>CUDD_REORDER_SYMM_SIFT_CONV<A NAME="542"></A>:</STRONG></DT> |
---|
1182 | <DD>This is the converging<A NAME="543"></A> variant of |
---|
1183 | CUDD_REORDER_SYMM_SIFT. |
---|
1184 | </DD> |
---|
1185 | <DT><STRONG>CUDD_REORDER_GROUP_SIFT<A NAME="544"></A>:</STRONG></DT> |
---|
1186 | <DD>This method is an implementation of group<A NAME="545"></A> |
---|
1187 | sifting [<A |
---|
1188 | HREF="node7.html#Panda95b">13</A>]. It is similar to symmetric sifting, but |
---|
1189 | aggregation<A NAME="547"></A> is not restricted to symmetric |
---|
1190 | variables. |
---|
1191 | </DD> |
---|
1192 | <DT><STRONG>CUDD_REORDER_GROUP_SIFT_CONV<A NAME="548"></A>:</STRONG></DT> |
---|
1193 | <DD>This method repeats until convergence the combination of |
---|
1194 | CUDD_REORDER_GROUP_SIFT and CUDD_REORDER_WINDOW4. |
---|
1195 | </DD> |
---|
1196 | <DT><STRONG>CUDD_REORDER_WINDOW2<A NAME="549"></A>:</STRONG></DT> |
---|
1197 | <DD>This |
---|
1198 | method implements the window<A NAME="550"></A> permutation |
---|
1199 | approach of Fujita [<A |
---|
1200 | HREF="node7.html#Fujita91b">8</A>] and Ishiura [<A |
---|
1201 | HREF="node7.html#Ishiur91">10</A>]. |
---|
1202 | The size of the window is 2. |
---|
1203 | </DD> |
---|
1204 | <DT><STRONG>CUDD_REORDER_WINDOW3<A NAME="553"></A>:</STRONG></DT> |
---|
1205 | <DD>Similar |
---|
1206 | to CUDD_REORDER_WINDOW2, but with a window of size 3. |
---|
1207 | </DD> |
---|
1208 | <DT><STRONG>CUDD_REORDER_WINDOW4<A NAME="554"></A>:</STRONG></DT> |
---|
1209 | <DD>Similar |
---|
1210 | to CUDD_REORDER_WINDOW2, but with a window of size 4. |
---|
1211 | </DD> |
---|
1212 | <DT><STRONG>CUDD_REORDER_WINDOW2_CONV<A NAME="555"></A>:</STRONG></DT> |
---|
1213 | <DD>This is the converging<A NAME="556"></A> variant of |
---|
1214 | CUDD_REORDER_WINDOW2. |
---|
1215 | </DD> |
---|
1216 | <DT><STRONG>CUDD_REORDER_WINDOW3_CONV<A NAME="557"></A>:</STRONG></DT> |
---|
1217 | <DD>This is the converging variant of CUDD_REORDER_WINDOW3. |
---|
1218 | </DD> |
---|
1219 | <DT><STRONG>CUDD_REORDER_WINDOW4_CONV<A NAME="558"></A>:</STRONG></DT> |
---|
1220 | <DD>This is the converging variant of CUDD_REORDER_WINDOW4. |
---|
1221 | </DD> |
---|
1222 | <DT><STRONG>CUDD_REORDER_ANNEALING<A NAME="559"></A>:</STRONG></DT> |
---|
1223 | <DD>This |
---|
1224 | method is an implementation of simulated |
---|
1225 | annealing<A NAME="560"></A> for variable |
---|
1226 | ordering, vaguely resemblant of the algorithm of [<A |
---|
1227 | HREF="node7.html#Bollig95">2</A>]. |
---|
1228 | This method is potentially very slow. |
---|
1229 | </DD> |
---|
1230 | <DT><STRONG>CUDD_REORDER_GENETIC:<A NAME="562"></A></STRONG></DT> |
---|
1231 | <DD>This |
---|
1232 | method is an implementation of a genetic<A NAME="563"></A> |
---|
1233 | algorithm for variable ordering, inspired by the work of Drechsler |
---|
1234 | [<A |
---|
1235 | HREF="node7.html#Drechs95">6</A>]. This method is potentially very slow. |
---|
1236 | </DD> |
---|
1237 | <DT><STRONG>CUDD_REORDER_EXACT<A NAME="565"></A>:</STRONG></DT> |
---|
1238 | <DD>This method |
---|
1239 | implements a dynamic programming approach to |
---|
1240 | exact<A NAME="566"></A> reordering |
---|
1241 | [<A |
---|
1242 | HREF="node7.html#Held62">9</A>,<A |
---|
1243 | HREF="node7.html#Friedman90">7</A>,<A |
---|
1244 | HREF="node7.html#Ishiur91">10</A>], with improvements described in |
---|
1245 | [<A |
---|
1246 | HREF="node7.html#Jeong93">11</A>]. It only stores one BDD at the time. Therefore, it is |
---|
1247 | relatively efficient in terms of memory. Compared to other |
---|
1248 | reordering strategies, it is very slow, and is not recommended for |
---|
1249 | more than 16 variables. |
---|
1250 | </DD> |
---|
1251 | </DL> |
---|
1252 | So far we have described methods whereby the package selects an order |
---|
1253 | automatically. A given order of the variables can also be imposed by |
---|
1254 | calling <A NAME="tex2html79" |
---|
1255 | HREF="cuddExtDet.html#Cudd_ShuffleHeap"><EM>Cudd_ShuffleHeap</EM></A><A NAME="1561"></A>. |
---|
1256 | |
---|
1257 | <P> |
---|
1258 | |
---|
1259 | <H2><A NAME="SECTION000313000000000000000"></A> |
---|
1260 | <A NAME="574"></A><A NAME="sec:group"></A> |
---|
1261 | <BR> |
---|
1262 | Grouping Variables |
---|
1263 | </H2> |
---|
1264 | |
---|
1265 | <P> |
---|
1266 | CUDD allows the application to specify constraints on the positions of |
---|
1267 | group of variables. It is possible to request that a group of |
---|
1268 | contiguous variables be kept contiguous by the reordering procedures. |
---|
1269 | It is also possible to request that the relative order of some groups |
---|
1270 | of variables be left unchanged. The constraints on the order are |
---|
1271 | specified by means of a tree<A NAME="576"></A>, which is created in |
---|
1272 | one of two ways: |
---|
1273 | |
---|
1274 | <UL> |
---|
1275 | <LI>By calling <A NAME="tex2html81" |
---|
1276 | HREF="cuddExtDet.html#Cudd_MakeTreeNode"><EM>Cudd_MakeTreeNode</EM></A><A NAME="1563"></A>. |
---|
1277 | </LI> |
---|
1278 | <LI>By calling the functions of the MTR<A NAME="581"></A> library |
---|
1279 | |
---|
1280 | (part of the distribution), and by registering the result with the |
---|
1281 | manager using <A NAME="tex2html82" |
---|
1282 | HREF="cuddExtDet.html#Cudd_SetTree"><EM>Cudd_SetTree</EM></A><A NAME="1565"></A>. The |
---|
1283 | |
---|
1284 | current tree registered with the manager can be read with <A NAME="tex2html83" |
---|
1285 | HREF="cuddExtDet.html#Cudd_ReadTree"><EM> Cudd_ReadTree</EM></A><A NAME="1567"></A>. |
---|
1286 | </LI> |
---|
1287 | </UL> |
---|
1288 | |
---|
1289 | <P> |
---|
1290 | Each node in the tree represents a range of variables. The lower bound |
---|
1291 | of the range is given by the <EM>low</EM> field of the node, and the |
---|
1292 | size of the group is given by the <EM>size</EM> field of the |
---|
1293 | node.<A NAME="tex2html80" |
---|
1294 | HREF="footnode.html#foot1315"><SUP>2</SUP></A> The variables in |
---|
1295 | each range are kept contiguous. Furthermore, if a node is marked with |
---|
1296 | the MTR_FIXED<A NAME="593"></A> flag, then the relative order of the |
---|
1297 | variable ranges associated to its children is not changed. As an |
---|
1298 | example, suppose the initial variable order is: |
---|
1299 | <PRE> |
---|
1300 | x0, y0, z0, x1, y1, z1, ... , x9, y9, z9. |
---|
1301 | </PRE> |
---|
1302 | Suppose we want to keep each group of three variables with the same |
---|
1303 | index (e.g., <code>x3, y3, z3</code>) contiguous, while allowing the package |
---|
1304 | to change the order of the groups. We can accomplish this with the |
---|
1305 | following code: |
---|
1306 | <PRE> |
---|
1307 | for (i = 0; i < 10; i++) { |
---|
1308 | (void) Cudd_MakeTreeNode(manager,i*3,3,MTR_DEFAULT); |
---|
1309 | } |
---|
1310 | </PRE> |
---|
1311 | If we want to keep the order within each group of variables |
---|
1312 | fixed (i.e., <code>x</code> before <code>y</code> before <code>z</code>) we need to |
---|
1313 | change MTR_DEFAULT<A NAME="598"></A> into MTR_FIXED. |
---|
1314 | |
---|
1315 | <P> |
---|
1316 | The <EM>low</EM> parameter passed to <A NAME="tex2html84" |
---|
1317 | HREF="cuddExtDet.html#Cudd_MakeTreeNode"><EM> Cudd_MakeTreeNode</EM></A><A NAME="1569"></A> is the index |
---|
1318 | of a variable (as opposed to its level or position in the order). The |
---|
1319 | group tree<A NAME="603"></A> can be created at any time. The result |
---|
1320 | obviously depends on the variable order in effect at creation time. |
---|
1321 | |
---|
1322 | <P> |
---|
1323 | It is possible to create a variable group tree also before the |
---|
1324 | variables themselves are created. The package assumes in this case |
---|
1325 | that the index of the variables not yet in existence will equal their |
---|
1326 | position in the order when they are created. Therefore, applications |
---|
1327 | that rely on <A NAME="tex2html85" |
---|
1328 | HREF="cuddExtDet.html#Cudd_bddNewVarAtLevel"><EM> Cudd_bddNewVarAtLevel</EM></A><A NAME="1571"></A> or |
---|
1329 | <A NAME="tex2html86" |
---|
1330 | HREF="cuddExtDet.html#Cudd_addNewVarAtLevel"><EM>Cudd_addNewVarAtLevel</EM></A><A NAME="1573"></A> to |
---|
1331 | create new variables have to create the variables before they group |
---|
1332 | them. |
---|
1333 | |
---|
1334 | <P> |
---|
1335 | The reordering procedure will skip all groups whose variables are not |
---|
1336 | yet in existence. For groups that are only partially in existence, the |
---|
1337 | reordering procedure will try to reorder the variables already |
---|
1338 | instantiated, without violating the adjacency constraints. |
---|
1339 | |
---|
1340 | <P> |
---|
1341 | |
---|
1342 | <H2><A NAME="SECTION000314000000000000000"></A> |
---|
1343 | <A NAME="611"></A><A NAME="sec:reordZ"></A> |
---|
1344 | <BR> |
---|
1345 | Variable Reordering for ZDDs |
---|
1346 | </H2> |
---|
1347 | |
---|
1348 | <P> |
---|
1349 | Reordering of ZDDs is done in much the same way as the reordering of |
---|
1350 | BDDs and ADDs. The functions corresponding to <A NAME="tex2html87" |
---|
1351 | HREF="cuddExtDet.html#Cudd_ReduceHeap"><EM>Cudd_ReduceHeap</EM></A> |
---|
1352 | and <A NAME="tex2html88" |
---|
1353 | HREF="cuddExtDet.html#Cudd_ShuffleHeap"><EM>Cudd_ShuffleHeap</EM></A> |
---|
1354 | are <A NAME="tex2html89" |
---|
1355 | HREF="cuddExtDet.html#Cudd_zddReduceHeap"><EM> Cudd_zddReduceHeap</EM></A><A NAME="1575"></A> and <A NAME="tex2html90" |
---|
1356 | HREF="cuddExtDet.html#Cudd_zddShuffleHeap"><EM> Cudd_zddShuffleHeap</EM></A><A NAME="1577"></A>. To enable |
---|
1357 | dynamic<A NAME="623"></A> reordering, the application must |
---|
1358 | call <A NAME="tex2html91" |
---|
1359 | HREF="cuddExtDet.html#Cudd_AutodynEnableZdd"><EM>Cudd_AutodynEnableZdd</EM></A><A NAME="1579"></A>, |
---|
1360 | and to disable dynamic reordering, it must call <A NAME="tex2html92" |
---|
1361 | HREF="cuddExtDet.html#Cudd_AutodynDisableZdd"><EM> Cudd_AutodynDisableZdd</EM></A><A NAME="1581"></A>. In |
---|
1362 | the current implementation, however, the choice of reordering methods |
---|
1363 | for ZDDs is more limited. Specifically, these methods are available: |
---|
1364 | |
---|
1365 | <P> |
---|
1366 | <DL> |
---|
1367 | <DT><STRONG>CUDD_REORDER_NONE<A NAME="631"></A>;</STRONG></DT> |
---|
1368 | <DD> |
---|
1369 | </DD> |
---|
1370 | <DT><STRONG>CUDD_REORDER_SAME<A NAME="632"></A>;</STRONG></DT> |
---|
1371 | <DD> |
---|
1372 | </DD> |
---|
1373 | <DT><STRONG>CUDD_REORDER_RANDOM<A NAME="633"></A>;</STRONG></DT> |
---|
1374 | <DD> |
---|
1375 | </DD> |
---|
1376 | <DT><STRONG>CUDD_REORDER_RANDOM_PIVOT<A NAME="634"></A>;</STRONG></DT> |
---|
1377 | <DD> |
---|
1378 | </DD> |
---|
1379 | <DT><STRONG>CUDD_REORDER_SIFT<A NAME="635"></A>;</STRONG></DT> |
---|
1380 | <DD> |
---|
1381 | </DD> |
---|
1382 | <DT><STRONG>CUDD_REORDER_SIFT_CONVERGE<A NAME="636"></A>;</STRONG></DT> |
---|
1383 | <DD> |
---|
1384 | </DD> |
---|
1385 | <DT><STRONG>CUDD_REORDER_SYMM_SIFT<A NAME="637"></A>;</STRONG></DT> |
---|
1386 | <DD> |
---|
1387 | </DD> |
---|
1388 | <DT><STRONG>CUDD_REORDER_SYMM_SIFT_CONV<A NAME="638"></A>.</STRONG></DT> |
---|
1389 | <DD> |
---|
1390 | </DD> |
---|
1391 | </DL> |
---|
1392 | |
---|
1393 | <P> |
---|
1394 | To create ZDD variable groups, the application calls <A NAME="tex2html93" |
---|
1395 | HREF="cuddExtDet.html#Cudd_MakeZddTreeNode"><EM> Cudd_MakeZddTreeNode</EM></A><A NAME="1583"></A>. |
---|
1396 | |
---|
1397 | <P> |
---|
1398 | |
---|
1399 | <H2><A NAME="SECTION000315000000000000000"></A> |
---|
1400 | <A NAME="sec:consist"></A> |
---|
1401 | <BR> |
---|
1402 | Keeping Consistent Variable Orders for BDDs and ZDDs |
---|
1403 | </H2> |
---|
1404 | |
---|
1405 | <P> |
---|
1406 | Several applications that manipulate both BDDs and ZDDs benefit from |
---|
1407 | keeping a fixed correspondence between the order of the BDD variables |
---|
1408 | and the order of the ZDD variables. If each BDD variable corresponds |
---|
1409 | to a group of ZDD variables, then it is often desirable that the |
---|
1410 | groups of ZDD variables be in the same order as the corresponding BDD |
---|
1411 | variables. CUDD allows the ZDD order to |
---|
1412 | track the BDD order and vice versa. To have the ZDD order track |
---|
1413 | the BDD order, the application calls <A NAME="tex2html94" |
---|
1414 | HREF="cuddExtDet.html#Cudd_zddRealignEnable"><EM> Cudd_zddRealignEnable</EM></A><A NAME="1585"></A>. The |
---|
1415 | effect of this call can be reversed by calling <A NAME="tex2html95" |
---|
1416 | HREF="cuddExtDet.html#Cudd_zddRealignDisable"><EM> Cudd_zddRealignDisable</EM></A><A NAME="1587"></A>. When |
---|
1417 | ZDD realignment is in effect, automatic reordering of ZDDs should be |
---|
1418 | disabled. |
---|
1419 | |
---|
1420 | <P> |
---|
1421 | |
---|
1422 | <H2><A NAME="SECTION000316000000000000000"></A> |
---|
1423 | <A NAME="652"></A><A NAME="sec:hooks"></A> |
---|
1424 | <BR> |
---|
1425 | Hooks |
---|
1426 | </H2> |
---|
1427 | |
---|
1428 | <P> |
---|
1429 | Hooks in CUDD are lists of application-specified functions to be run on |
---|
1430 | certain occasions. Each hook is identified by a constant of the |
---|
1431 | enumerated type <A NAME="tex2html96" |
---|
1432 | HREF="cuddExtDet.html#Cudd_HookType"><EM>Cudd_HookType</EM></A><A NAME="1589"></A>. In Version |
---|
1433 | 2.4.1 hooks are defined for these occasions: |
---|
1434 | |
---|
1435 | <UL> |
---|
1436 | <LI>before garbage collection (CUDD_PRE_GC_HOOK); |
---|
1437 | </LI> |
---|
1438 | <LI>after garbage collection (CUDD_POST_GC_HOOK); |
---|
1439 | </LI> |
---|
1440 | <LI>before variable reordering (CUDD_PRE_REORDERING_HOOK); |
---|
1441 | </LI> |
---|
1442 | <LI>after variable reordering (CUDD_POST_REORDERING_HOOK). |
---|
1443 | </LI> |
---|
1444 | </UL> |
---|
1445 | The current implementation of hooks is experimental. A function added |
---|
1446 | to a hook receives a pointer to the manager, a pointer to a constant |
---|
1447 | string, and a pointer to void as arguments; it must return 1 if |
---|
1448 | successful; 0 otherwise. The second argument is one of ``DD,'' |
---|
1449 | ``BDD,'' and ``ZDD.'' This allows the hook functions to tell the type |
---|
1450 | of diagram for which reordering or garbage collection takes place. The |
---|
1451 | third argument varies depending on the hook. The hook functions called |
---|
1452 | before or after garbage collection<A NAME="659"></A> do |
---|
1453 | not use it. The hook functions called before |
---|
1454 | reordering<A NAME="660"></A> are passed, in addition to the |
---|
1455 | pointer to the manager, also the method used for reordering. The hook |
---|
1456 | functions called after reordering are passed the start time. To add a |
---|
1457 | function to a hook, one uses <A NAME="tex2html97" |
---|
1458 | HREF="cuddExtDet.html#Cudd_AddHook"><EM> Cudd_AddHook</EM></A><A NAME="1591"></A>. The function of a given hook |
---|
1459 | are called in the order in which they were added to the hook. For |
---|
1460 | sample hook functions, one may look at |
---|
1461 | <I>Cudd_StdPreReordHook</I><A NAME="1593"></A> and |
---|
1462 | <I>Cudd_StdPostReordHook</I><A NAME="1595"></A>. |
---|
1463 | |
---|
1464 | <P> |
---|
1465 | |
---|
1466 | <H2><A NAME="SECTION000317000000000000000"></A> |
---|
1467 | <A NAME="669"></A><A NAME="670"></A><A NAME="sec:sis-vis"></A> |
---|
1468 | <BR> |
---|
1469 | The SIS/VIS Interface |
---|
1470 | </H2> |
---|
1471 | |
---|
1472 | <P> |
---|
1473 | The CUDD package contains interface functions that emulate the |
---|
1474 | behavior of the original BDD package used in SIS [<A |
---|
1475 | HREF="node7.html#Sentov92">17</A>] and |
---|
1476 | in the newer |
---|
1477 | <A NAME="tex2html98" |
---|
1478 | HREF="http://vlsi.Colorado.EDU/~vis/">VIS</A> |
---|
1479 | [<A |
---|
1480 | HREF="node7.html#VIS">4</A>]. How to build VIS with CUDD is described |
---|
1481 | in the installation documents of VIS. (Version 1.1 and later.) |
---|
1482 | |
---|
1483 | <P> |
---|
1484 | |
---|
1485 | <H3><A NAME="SECTION000317100000000000000"></A> |
---|
1486 | <A NAME="677"></A><A NAME="sec:sis"></A> |
---|
1487 | <BR> |
---|
1488 | Using the CUDD Package in SIS |
---|
1489 | </H3> |
---|
1490 | |
---|
1491 | <P> |
---|
1492 | This section describes how to build SIS with the CUDD package. Let |
---|
1493 | <TT>SISDIR<A NAME="679"></A></TT> designate the root of the directory |
---|
1494 | hierarchy where the sources for SIS reside. Let <TT> CUDDDIR<A NAME="680"></A></TT> be the root of the directory hierarchy where |
---|
1495 | the distribution of the CUDD package resides. To build SIS with the |
---|
1496 | CUDD package, follow these steps. |
---|
1497 | |
---|
1498 | <OL> |
---|
1499 | <LI>Create directories <TT>SISDIR/sis/cudd</TT> and <TT> SISDIR/sis/mtr</TT>. |
---|
1500 | </LI> |
---|
1501 | <LI>Copy all files from <TT>CUDDDIR/cudd</TT> and <TT>CUDDDIR/sis</TT> to |
---|
1502 | <TT>SISDIR/sis/cudd</TT> and all files from <TT>CUDDDIR/mtr</TT> to <TT> SISDIR/sis/mtr</TT>. |
---|
1503 | </LI> |
---|
1504 | <LI>Copy <TT>CUDDDIR/cudd/doc/cudd.doc</TT> to <TT>SISDIR/sis/cudd</TT>; |
---|
1505 | also copy <TT>CUDDDIR/mtr/doc/mtr.doc</TT> to <TT>SISDIR/sis/mtr</TT>. |
---|
1506 | </LI> |
---|
1507 | <LI>In <TT>SISDIR/sis/cudd</TT> make <TT>bdd.h</TT> a symbolic link to |
---|
1508 | <TT>cuddBdd.h</TT>. (That is: <TT>ln -s cuddBdd.h bdd.h</TT>.) |
---|
1509 | </LI> |
---|
1510 | <LI>In <TT>SISDIR/sis/cudd</TT> delete <TT>Makefile</TT> and rename <TT> Makefile.sis</TT> as <TT>Makefile</TT>. Do the same in <TT> SISDIR/sis/mtr</TT>. |
---|
1511 | </LI> |
---|
1512 | <LI>Copy <TT>CUDDDIR/sis/st.[ch]</TT> and <TT>CUDDDIR/st/doc/st.doc</TT> |
---|
1513 | to <TT>SISDIR/sis/st</TT>. (This will overwrite the original files: You |
---|
1514 | may want to save them beforehand.) |
---|
1515 | </LI> |
---|
1516 | <LI>From <TT>CUDDDIR/util</TT> copy <TT>datalimit.c</TT> |
---|
1517 | to <TT>SISDIR/sis/util</TT>. Update <TT>util.h</TT> and <TT>Makefile</TT> |
---|
1518 | in <TT>SISDIR/sis/util</TT>. Specifically, add the declaration |
---|
1519 | <TT>EXTERN long getSoftDataLimit();</TT> to <TT>util.h</TT> and add |
---|
1520 | <TT>datalimit.c</TT> to the list of source files (PSRC) in <TT>Makefile</TT>. |
---|
1521 | </LI> |
---|
1522 | <LI>In <TT>SISDIR/sis</TT> remove the link from <TT>bdd</TT> to <TT> bdd_cmu</TT> or <TT>bdd_ucb</TT> (that is, <TT>rm bdd</TT>) and make <TT> bdd</TT> a symbolic link to <TT>cudd</TT>. (That is: <TT>ln -s cudd |
---|
1523 | bdd</TT>.) |
---|
1524 | </LI> |
---|
1525 | <LI>Still in <TT>SISDIR/sis</TT>, edit <TT>Makefile</TT>, <TT> Makefile.oct</TT>, and <TT>Makefile.nooct</TT>. In all three files add |
---|
1526 | mtr to the list of directories to be made (DIRS). |
---|
1527 | </LI> |
---|
1528 | <LI>In <TT>SISDIR/sis/include</TT> make <TT>mtr.h</TT> a symbolic link to |
---|
1529 | <TT>../mtr/mtr.h</TT>. |
---|
1530 | </LI> |
---|
1531 | <LI>In <TT>SISDIR/sis/doc</TT> make <TT>cudd.doc</TT> a symbolic link to |
---|
1532 | <TT>../cudd/cudd.doc</TT> and <TT>mtr.doc</TT> a symbolic link to <TT> ../mtr/mtr.doc</TT>. (That is: <TT>ln -s ../cudd/cudd.doc .; ln -s |
---|
1533 | ../mtr/mtr.doc .</TT>.) |
---|
1534 | </LI> |
---|
1535 | <LI>From <TT>SISDIR</TT> do <TT>make clean</TT> followed by <TT>make -i</TT>. |
---|
1536 | This should create a working copy of SIS that uses the CUDD package. |
---|
1537 | </LI> |
---|
1538 | </OL> |
---|
1539 | |
---|
1540 | <P> |
---|
1541 | The replacement for the <TT>st</TT> library is because the version |
---|
1542 | shipped with the CUDD package tests for out-of-memory conditions. |
---|
1543 | Notice that the version of the <TT>st</TT> library to be used for |
---|
1544 | replacement is not the one used for the normal build, because the |
---|
1545 | latter has been modified for C++ compatibility. The above installation |
---|
1546 | procedure has been tested on SIS 1.3. SIS can be obtained via |
---|
1547 | anonymous FTP<A NAME="742"></A> from <A NAME="tex2html99" |
---|
1548 | HREF="ftp://ic.eecs.berkeley.edu"><TT> ic.eecs.berkeley.edu</TT></A>. To build SIS |
---|
1549 | 1.3, you need <TT>sis-1.2.tar.Z</TT> and <TT>sis-1.2.patch1.Z</TT>. When |
---|
1550 | compiling on a DEC Alpha<A NAME="747"></A>, you should add the <TT> -ieee_with_no_inexact</TT> flag. (See |
---|
1551 | Section <A HREF="node3.html#sec:predef-const">3.5.2</A>.) Refer to the <TT>Makefile</TT> in the |
---|
1552 | top level directory of the distribution for how to compile with 32-bit |
---|
1553 | pointers. |
---|
1554 | |
---|
1555 | <P> |
---|
1556 | |
---|
1557 | <H2><A NAME="SECTION000318000000000000000"></A> |
---|
1558 | <A NAME="sec:dump"></A> |
---|
1559 | <BR> |
---|
1560 | Writing Decision Diagrams to a File |
---|
1561 | </H2> |
---|
1562 | |
---|
1563 | <P> |
---|
1564 | The CUDD package provides several functions to write decision diagrams |
---|
1565 | to a file. <A NAME="tex2html101" |
---|
1566 | HREF="cuddExtDet.html#Cudd_DumpBlif"><EM>Cudd_DumpBlif</EM></A><A NAME="1597"></A> writes a |
---|
1567 | file in <EM>blif</EM> format. It is restricted to BDDs. The diagrams |
---|
1568 | are written as a network of multiplexers, one multiplexer for each |
---|
1569 | internal node of the BDD. |
---|
1570 | |
---|
1571 | <P> |
---|
1572 | <A NAME="tex2html102" |
---|
1573 | HREF="cuddExtDet.html#Cudd_DumpDot"><EM>Cudd_DumpDot</EM></A><A NAME="1599"></A> produces input suitable to |
---|
1574 | the graph-drawing<A NAME="760"></A> program |
---|
1575 | <A NAME="tex2html103" |
---|
1576 | HREF="http://www.research.att.com/sw/tools/graphviz"><EM>dot</EM></A> |
---|
1577 | written by |
---|
1578 | Eleftherios Koutsofios and Stephen C. North. An example of drawing |
---|
1579 | produced by dot from the output of <A NAME="tex2html104" |
---|
1580 | HREF="cuddExtDet.html#Cudd_DumpDot"><EM>Cudd_DumpDot</EM></A> |
---|
1581 | is shown in |
---|
1582 | Figure <A HREF="node3.html#fi:phase">1</A>. It is restricted to BDDs and ADDs. |
---|
1583 | |
---|
1584 | <P></P> |
---|
1585 | <DIV ALIGN="CENTER"><A NAME="fi:phase"></A><A NAME="1339"></A> |
---|
1586 | <TABLE> |
---|
1587 | <CAPTION ALIGN="BOTTOM"><STRONG>Figure 1:</STRONG> |
---|
1588 | A BDD representing a phase constraint for the optimization of |
---|
1589 | fixed-polarity Reed-Muller forms. The label of each node is the |
---|
1590 | unique part of the node address. All nodes on the same level |
---|
1591 | correspond to the same variable, whose name is shown at the left of |
---|
1592 | the diagram. Dotted lines indicate complement<A NAME="768"></A> |
---|
1593 | arcs. Dashed lines indicate regular<A NAME="769"></A> ``else" |
---|
1594 | arcs.</CAPTION> |
---|
1595 | <TR><TD><IMG |
---|
1596 | WIDTH="429" HEIGHT="701" BORDER="0" |
---|
1597 | SRC="img22.png" |
---|
1598 | ALT="\begin{figure}\centerline{\epsfig{file=phase.ps,height=15.5cm}}\end{figure}"></TD></TR> |
---|
1599 | </TABLE> |
---|
1600 | </DIV><P></P> |
---|
1601 | |
---|
1602 | <A NAME="tex2html105" |
---|
1603 | HREF="cuddExtDet.html#Cudd_zddDumpDot"><EM>Cudd_zddDumpDot</EM></A><A NAME="1601"></A> is the analog of <A NAME="tex2html106" |
---|
1604 | HREF="cuddExtDet.html#Cudd_DumpDot"><EM> Cudd_DumpDot</EM></A> |
---|
1605 | for ZDDs. |
---|
1606 | |
---|
1607 | <P> |
---|
1608 | <A NAME="tex2html107" |
---|
1609 | HREF="cuddExtDet.html#Cudd_DumpDaVinci"><EM>Cudd_DumpDaVinci</EM></A><A NAME="1603"></A> produces input suitable to |
---|
1610 | the graph-drawing<A NAME="780"></A> program |
---|
1611 | <A NAME="tex2html108" |
---|
1612 | HREF="ftp://ftp.uni-bremen.de/pub/graphics/daVinci"><EM> daVinci</EM></A> |
---|
1613 | developed |
---|
1614 | at the University of Bremen. It is restricted to BDDs and ADDs. |
---|
1615 | |
---|
1616 | <P> |
---|
1617 | Functions are also available to produce the input format of <EM> DDcal</EM> (see Section <A HREF="node2.html#sec:getFriends">2.2</A>) and factored forms. |
---|
1618 | |
---|
1619 | <P> |
---|
1620 | |
---|
1621 | <H2><A NAME="SECTION000319000000000000000"></A> |
---|
1622 | <A NAME="sec:save-restore"></A> |
---|
1623 | <BR> |
---|
1624 | Saving and Restoring BDDs |
---|
1625 | </H2> |
---|
1626 | |
---|
1627 | <P> |
---|
1628 | The <A NAME="tex2html109" |
---|
1629 | HREF="ftp://ftp.polito.it/pub/research/dddmp/"><EM>dddmp</EM></A> |
---|
1630 | library<A NAME="789"></A> by Gianpiero Cabodi and |
---|
1631 | Stefano Quer allows a CUDD application to save BDDs to disk in compact |
---|
1632 | form for later retrieval. See the library's own documentation for the |
---|
1633 | details. |
---|
1634 | |
---|
1635 | <P> |
---|
1636 | <HR> |
---|
1637 | <!--Navigation Panel--> |
---|
1638 | <A NAME="tex2html272" |
---|
1639 | HREF="node4.html"> |
---|
1640 | <IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" |
---|
1641 | SRC="icons/next.png"></A> |
---|
1642 | <A NAME="tex2html268" |
---|
1643 | HREF="cuddIntro.html"> |
---|
1644 | <IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" |
---|
1645 | SRC="icons/up.png"></A> |
---|
1646 | <A NAME="tex2html262" |
---|
1647 | HREF="node2.html"> |
---|
1648 | <IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" |
---|
1649 | SRC="icons/prev.png"></A> |
---|
1650 | <A NAME="tex2html270" |
---|
1651 | HREF="node8.html"> |
---|
1652 | <IMG WIDTH="43" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="index" |
---|
1653 | SRC="icons/index.png"></A> |
---|
1654 | <BR> |
---|
1655 | <B> Next:</B> <A NAME="tex2html273" |
---|
1656 | HREF="node4.html">Programmer's Manual</A> |
---|
1657 | <B> Up:</B> <A NAME="tex2html269" |
---|
1658 | HREF="cuddIntro.html">CUDD: CU Decision Diagram</A> |
---|
1659 | <B> Previous:</B> <A NAME="tex2html263" |
---|
1660 | HREF="node2.html">How to Get CUDD</A> |
---|
1661 |   <B> <A NAME="tex2html271" |
---|
1662 | HREF="node8.html">Index</A></B> |
---|
1663 | <!--End of Navigation Panel--> |
---|
1664 | <ADDRESS> |
---|
1665 | Fabio Somenzi |
---|
1666 | 2005-05-17 |
---|
1667 | </ADDRESS> |
---|
1668 | </BODY> |
---|
1669 | </HTML> |
---|