Sign up to receive free email alerts when patent applications with chosen keywords are publishedSIGN UP

Abstract:

An equivalency testing system, for formally comparing an RTLM and HLM, is
presented. RTLM and HLM are first converted into DFGs RTLMDFG and
HLMDFG. RTLMDFG and HLMDFG are then put into timestep form
and are called RTLMts and HLMts. A test bench CSts is
selected that couples RTLMts and HLMts. The combination of
RTLMts[t], HLMts[t] and CSts[t] can have parts designated
as datapath. Parts designated as datapath can be subject to a form of
equivalence checking that seeks to prove equivalence by a form of
inductive theorem proving that propagates symbolic values indicative of
whether a node carries the same data content as another node. The theorem
proving starts from initial conditions for HLMts[t] determined by
partial execution of the HLM. Propagation to a combinational function
output can be determined from equivalence relationships between it and
another combinational function. Propagation through a multiplexer can
produce a conditional symbolic value.

Claims:

1. A method of propagating values in a data-flow graph, comprising:marking
each node, of an initial set of nodes, with a symbolic value indicative
of whether a node carries the same data content as another
node;determining a first and a second combinational function, of the
data-flow graph, are equivalent;determining a first condition under which
the first and second combinational functions should produce a symbolic
value in common; andforming a first symbolic value, at a first output of
the first combinational function, that evaluates to a symbolic value in
common with a second output of the second combinational function when the
first condition is satisfied.

2. The method of claim 1, wherein the symbolic values, for the initial set
of nodes, represent integers.

3. The method of claim 2, wherein the symbolic values, for the initial set
of nodes, are represented by binary decision diagrams.

4. The method of claim 1, wherein the first symbolic value is represented
by a multi-terminal binary decision diagram.

6. The method of claim 1, wherein the first condition is represented as a
binary decision diagram.

7. The method of claim 1, wherein the step of determining a first
condition further comprises:solving a second symbolic value, received by
the first combinational function, and a corresponding third symbolic
value, received by the second combinational function, for a second
condition under which the second and third symbolic values evaluate to a
common symbolic value.

8. The method of claim 1, further comprising the following
steps:determining the first and a third combinational function, of the
data-flow graph, are equivalent;determining a second condition under
which the first and third combinational functions should produce a
symbolic value in common;forming a second symbolic value, at the first
output of the first combinational function, that evaluates to a symbolic
value in common with a third output of the third combinational function
when the second condition is satisfied, and that evaluates to a symbolic
value in common with the second output of the second combinational
function when the first condition is satisfied.

9. The method of claim 1, wherein the step of forming a first symbolic
value further comprises:identifying a first equivalence class of which
the first output is a member;identifying a second equivalence class of
which the second output is a member;producing a third equivalence class
that combines the first and second equivalence classes.

10. The method of claim 9, wherein the step of identifying a first
equivalence class further comprises:determining the transitive closure of
which a second symbolic value, at the first output, is a member by
determining whether a symbolic value component, of the second symbolic
value, is assigned to any other nodes of the data-flow graph.

11. The method of claim 9, wherein the step of identifying a first
equivalence class further comprises:determining the transitive closure of
which a second symbolic value, at the first output, is a member by
determining whether the second symbolic value is a component of a
symbolic value assigned to any other nodes of the data-flow graph.

12. The method of claim 9, wherein the step of producing a third
equivalence class further comprises:producing symbolic values for nodes,
of the third equivalence class, in a predetermined order.

13. The method of claim 12, wherein the predetermined order is guided by
unique identifiers assigned to the nodes of the third equivalence class.

14. The method of claim 12, wherein symbolic values for nodes of the third
equivalence class are produced from pre-existing symbolic values for
nodes of the first and second equivalence classes.

15. The method of claim 1, further comprising:organizing the data-flow
graph into timesteps.

16. The method of claim 1, further comprising:determining whether, from a
first timestep to a second timestep, each timestep is fully populated
with symbolic values.

17. The method of claim 1, further comprising:determining whether, from a
first timestep to a second timestep, each timestep is fully populated
with symbolic values.

18. The method of claim 1, further comprising:initializing a section of an
initial timestep of the data-flow graph by partial execution of a
high-level model corresponding to the section.

19. The method of claim 15, further comprising:organizing each timestep
into a first section representative of a first model, a second section
representative of a second model and a third section representative of a
test bench between the first and second models.

20. The method of claim 19, further comprising:organizing the third
section, when the first and third sections are equivalent, to produce an
equivalency indicator.

21. The method of claim 20, further comprising:determining whether, from a
first timestep to a second timestep, each timestep is sufficiently
populated with symbolic values such that an equivalency indicator, for
each of the first timestep to the second timestep, can be tested.

22. The method of claim 21, further comprising:reencoding, a set of
symbolic values for a third timestep, one timestep later than the second
timestep, if each equivalency indicator, for each of the first timestep
to the second timestep, indicates equivalence between the first section
and the second section.

23. The method of claim 21, further comprising:adding a third timestep,
one timestep later than the second timestep, if at least one equivalency
indicator, for each of the first timestep to the second timestep, does
not indicate equivalence between the first section and the second
section.

24. The method of claim 21, further comprising:producing a
counter-example, if at least a first equivalency indicator, for each of
the first timestep to the second timestep, does not indicate equivalence
between the first section and the second section.

25. The method of claim 24, wherein the step of producing a
counter-example further comprises:determining a conditional equivalence
relation for which the first equivalency indicator indicates equivalence.

26. The method of claim 7, wherein the second condition is represented as
a binary decision diagram.

27. The method of claim 7, wherein the second symbolic value is
represented by a multi-terminal binary decision diagram.

29. A data-processing system for propagating values in a data-flow graph,
comprising the following sub-systems:a sub-system configured to mark each
node, of an initial set of nodes, with a symbolic value indicative of
whether a node carries the same data content as another node;a sub-system
configured to determine a first and a second combinational function, of
the data-flow graph, are equivalent;a sub-system configured to determine
a first condition under which the first and second combinational
functions should produce a symbolic value in common; anda sub-system
configured to form a first symbolic value, at a first output of the first
combinational function, that evaluates to a symbolic value in common with
a second output of the second combinational function when the first
condition is satisfied.

30. A computer program on a computer readable medium, having
computer-readable code devices embodied therein, for propagating values
in a data-flow graph, the computer program comprising:computer readable
program code devices configured to mark each node, of an initial set of
nodes, with a symbolic value indicative of whether a node carries the
same data content as another node;computer readable program code devices
configured to determine a first and a second combinational function, of
the data-flow graph, are equivalent;computer readable program code
devices configured to determine a first condition under which the first
and second combinational functions should produce a symbolic value in
common; andcomputer readable program code devices configured to form a
first symbolic value, at a first output of the first combinational
function, that evaluates to a symbolic value in common with a second
output of the second combinational function when the first condition is
satisfied.

Description:

[0001]This application is a divisional application of and claims benefit
under 35 U.S.C. §121 to U.S. Patent Application "Method and
Apparatus for Formally Checking Equivalence Using Equivalence
Relationships" by inventors Alfred Koelbl and Carl Preston Pixley, filed
Jun. 10, 2005, with Ser. No. 11/149,751, which claims benefit under 35
U.S.C. §119(e) to U.S. Provisional Application "Method and Apparatus
For Production Of Data-Flow-Graphs By Symbolic Simulation," Application
No. 60/635,152, filed Dec. 10, 2004. Application No. 60/635,152 is herein
incorporated by reference.

CROSS REFERENCE TO RELATED APPLICATIONS

[0002]This application is related to the following four U.S. patent
applications, all of which are herein incorporated by reference in their
entirety:

[0007]The present invention relates generally to the comparison of models
prepared at differing levels of abstraction, and more particularly to the
comparison of a high-level model to a register transfer level model.

BACKGROUND OF THE INVENTION

[0008]To cope with the high complexity of modern hardware design,
designers can adopt a methodology that starts with a very high-level
design specification. Such high-level specification can also be referred
to as a high-level model (HLM). An HLM captures basic functionality of
the design, but can leave out implementation details. The focus can
therefore be on algorithm design and design exploration, since even
extensive changes in the HLM's architecture can be easily made.
Furthermore, a methodology using HLMs enables validation of the
architecture during the early stages of design. HLMs can be written in a
high-level programming language, such as C or C++.

[0009]Once the HLM has been validated, and sufficient decisions have been
made regarding implementation of the design, the HLM can be refined to an
RTL model (RTLM), that can then be processed by more "back-end" tools
that perform synthesis and placement. The process of producing the RTLM
from the HLM, however, is often performed in a mainly manual fashion that
is error prone. A need therefore exists for EDA tools to assist the
designer in verifying that the RTLM adheres to (or is equivalent to) the
HLM.

[0010]A known approach for determining equivalence between an RTLM and HLM
is the running of extensive simulations on both models. The results of
such simulations are compared. Such simulations can be very time
consuming and can miss subtle discrepancies between the two models.

[0011]Therefore, there exists a need for better methods of determining
equivalence between RTLMs and HLMs. A formal approach to determining such
equivalency is desirable since such approaches have the possibility of
actually proving that, according to some standard of equivalency, the two
models are equivalent.

[0012]However, conventional approaches to formal analysis are often too
inefficient when applied to anything but small scale designs. What is
needed, therefore, are more efficient approaches to formal analysis that
have a good expectation of proving equivalency between large-scale
designs.

[0013]In addition to the formal analysis itself, issues that can also be
addressed, for improving the efficiency of formal approaches to
equivalence determination, include the following: producing an
appropriate common representation of the RTLM and HLM; producing an
appropriate test bench for combining the RTLM and HLM; and determining
appropriate initial conditions from which to start a formal analysis.

SUMMARY OF THE INVENTION

[0014]Please refer to the Glossary of Selected Terms, included at the end
of the Detailed Description, for the definition of selected terms used in
the below Summary. Section numbers in the below Summary correspond to
section numbers in the Detailed Description.

1. Summary of an Equivalency Testing System

[0015]A novel equivalency testing system is presented. As a framework for
discussing the various components of the equivalency testing system, a
pseudo-coded procedure called "test_for_equivalency" is also presented.

[0016]Both an RTLM and HLM to be compared for equivalence are converted
into DFGs, called RTLMDFG and HLMDFG. The HLM can be specified
as a function written in a high-level programming language, such as C++.
HLMDFG can be determined by a new technique, of symbolic simulation
of the HLM, presented herein.

[0017]RTLMDFG and HLMDFG are put into a timestep form, referred
to as RTLMts and HLMts. An arbitrary timestep "t," of
RTLMts and HLMts, can be referred to as RTLMts[t] and
HLMts[t].

[0018]A combining structure CSts can be selected that couples
RTLMts and HLMts. A combining structure can also be referred to
as a "test bench." The combining structure has the following property:
if, for a timestep t, RTLMts[t] and HLMts[t] are equivalent
according to a given (or automatically determined) notion of equivalence,
then CSts[t] will detect this. Different types of combining
structures can be selected depending upon the type of circuit represented
by RTLMts and HLMts. Novel techniques, for classifying each of
RTLMts and HLMts, and for selecting a suitable CSts, are
presented. In addition, novel forms of combining structure, suitable in
general for formal verification, are presented. For example, a novel
combining structure, for showing that RTLMts and HLMts are
stream-equivalent, is presented.

[0019]The complete system, comprised of RTLMts[t], HLMts[t] and
CSts[t], is referred to as a "miter." The miter can have certain
parts designated as representing control logic and other parts designated
as representing datapath logic. Parts of the miter designated as control
can be subject to a known form of bit-level equivalence checking. Parts
of the miter designated as datapath are subject to a new form of
equivalence checking that works above the bit level, using a node value
indicator referred to herein as a "symbolic data value" or SDV, and that
seeks to prove equivalence by a form of inductive theorem proving.

[0020]In the datapath portions of the miter, equivalence checking can be
conducted at a higher level of abstraction if one is not interested in
actual data values, but only in whether RTLMts and HLMts
produce the same data (given that they receive the same input data). In
this case, integers can be used as an abstraction for datapath data
values: if two signals have the same integer number, this signifies that
their actual data values are the same; if two signals have the different
integer numbers, this signifies their actual data values are different.
To refer to such integer values, the term "integer SDV" can be used.

[0021]If it can be proven that RTLMts and HLMts both produce the
same SDVs on all of their primary outputs, and for all times, it is
proven that both designs are equivalent. In order to determine the SDVs
of the primary outputs of RTLMts and HLMts, input SDVs must be
propagated through the miter.

[0022]A novel form of inductive theorem proving starts from initial
conditions for the first timestep for the miter (i.e., for timestep
RTLMts[0], HLMts[0] and CSts[0]). The initial state for
RTLMts[0] can be determined by any suitable known means, but the
initial state for HLMts[0] can be determined by a new technique, of
partial execution of the HLM, presented herein.

[0023]A first "phase" of SDV propagation is performed. In SDV propagation,
SDVs of the first timestep are sought to be propagated forward to the
outputs of the first timestep. If a path of propagation cannot be fully
pursued to the outputs of a timestep, additional timesteps can be added.
The first phase of SDV propagation ends when the miter is completely
"populated" with SDVs up to a timestep called t_ready-1. The full
population of SDVs means that if RTLM and HLM can be equivalent during
those timesteps (i.e., the timesteps from the first timestep up to
t_ready-1), this equivalence will be detected by the combining structure
of each of those timesteps.

[0024]In propagating SDVs through a timestep, a complication arises with
multiplexers. Consider the case of a two-input multiplexer where an
integer SDV is present at each of the multiplexer's inputs. If the two
SDVs are to be propagated through the multiplexer, the resulting SDV on
the multiplexer output cannot be represented as an integer, since the
multiplexer's selector input determines which SDV is routed to the
output. To model the conditional dependency of the multiplexer output, on
the selector condition, a second type of SDV, referred to herein as an
ITE (If-Then-Else) SDV, is introduced.

[0025]The SDVs chosen and formed, as part of the first phase of SDV
propagation, are guided by labels that are assigned to the nodes of the
miter in a particular order as timesteps are added.

[0026]The timestep at t_ready is reencoded and the symbolic values of its
datapath signals, relative to their timestep-invariant node names, are
recorded as a potential first "fixed-point" of the SDV propagation
process.

[0027]As part of the reencode, the order of label assignment, that guided
the selection and formation of SDVs during the first phase of SDV
propagation, is repeated from the beginning.

[0028]Starting with the potential first fixed-point as the initial
condition, a second phase of SDV propagation is performed. Like the first
phase, the ending of the second phase of SDV propagation is marked by the
miter being completely "populated" with SDVs up to a later timestep, also
called t_ready-1.

[0029]Because the second phase of SDV propagation is guided by a
repetition of the same labeling process that guided the first phase of
SDV propagation, if the potential first fixed-point is a real
fixed-point, the exact same form of SDV propagation will occur during the
second phase as occurred during the first phase.

[0030]This repetition of propagation phases can be detected as follows.
The timestep of the later t_ready is reencoded. The symbolic values of
the next-state and primary inputs of the later t_ready, relative to their
timestep-invariant node names, are recorded as a potential second
"fixed-point."

[0031]If the first and second, potential fixed-points, are identical, then
it has been inductively proven that the process of SDV propagation can be
repeated, indefinitely, for all timesteps. If each timestep "t," from the
initial timestep of the first phase up to the timestep t_ready-1 of the
second phase, indicates HLMts[t] and RTLMts[t] are equivalent
(as indicated by CSts[t]), then it is known that HLM and RTLM are
equivalent for all timesteps.

[0032]The proving of equivalence between HLM and RTLM can produce an
"equivalence indicator" for a user of the system. If equivalence
determination process cannot prove equivalence, a "counter example" can
be produced to aid the user in locating where behavior of the HLM
diverges from that of the RTLM.

1.1 Summary of Conversion of HLM and RTLM to DFGs

[0033]Within test_for_equivalency, a procedure "RTLM_2_DFG" can be invoked
for conversion of an RTLM into an RTLMDFG. RTLMDFG is referred
to in the pseudo-code as "RTLM_dfg." Also within test_for_equivalency,
procedure "HLM_2_DFG" can be invoked for conversion of an HLM into an
HLMDFG.

1.2 Summary of Conversion Into Timestep Form

[0034]Within test_for_equivalency, a procedure "generate_timestep" can be
invoked twice: once for for generation of RTLMts from RTLMDFG
and a second time for generation of HLMts from HLMDFG.
RTLMts is referred to in the pseudo-code as "RTLM_ts." HLMts is
referred to in the pseudo-code as "HLM-ts."

1.3 Summary of Combining Structure Generation

[0035]A process for producing a CSts can be summarized as follows.
RTLMts and HLMts can each be classified. Based upon the
classification of each DFG, a CSts can be selected.

[0036]A CSts can be designed to produce an output "q" that has the
following property: "q" for a timestep t, is TRUE if and only if
RTLMts[t] and HLMts[t] are equivalent according to a given
notion of equivalence.

[0037]One of the combining structures presented is for the comparison of
stream-based designs. This stream-based combining structure, on its own
and without a prior step of classification of the designs to be coupled,
is novel. Other applications, of this stream-based combining structure,
are discussed.

[0038]Production of the miter can include identification of control and
datapath nodes. Each datapath node can be assigned a value referred to
herein as an "SDV." Each control node can be assigned a value referred to
herein as a "symbolic Boolean expression."

[0039]An SDV is not intended to represent a particular piece of data, or a
particular value. Rather, an SDV is intended to represent whether one
node of the datapath has been assigned the same value (or data structure)
as another node of the datapath. An SDV can be of two types: integer and
ITE.

[0040]An integer SDV is just an integer value. The actual data represented
by the integer SDV can be arbitrarily complex.

[0041]An ITE SDV takes three arguments: a symbolic Boolean expression, a
first SDV and a second SDV. If the symbolic Boolean expression is
satisfied, then the value of the first SDV is returned by the ITE SDV,
else the value of the second SDV is returned by the ITE SDV. The first
and second SDVs can either be an integer SDV, or a nested ITE SDV.

[0042]An ITE SDV can be used to indicate whether or not datapath nodes are
outputting the same data, at a particular time, depending upon which
conditions of the control nodes are met.

[0043]A symbolic Boolean expression is the same as an ordinary Boolean
expression, except that rather than being comprised of Boolean variables
(e.g., "x" or "-x") and/or Boolean values (e.g., "1" or "0"), it is
comprised of, respectively, symbolic Boolean variables and/or symbolic
Boolean values. A symbolic Boolean expression can be a single symbolic
Boolean variable or a single symbolic Boolean value. A symbolic Boolean
expression can also be comprised of symbolic Boolean variables and/or
symbolic Boolean values connected by Boolean operators.

[0044]A symbolic Boolean variable can differ from an ordinary Boolean
variable as follows: it can indicate the timestep from which it arose. A
symbolic Boolean value can differ from an ordinary Boolean value as
follows: it can indicate the timestep from which it arose.

[0045]A CER is a symbolic Boolean expression that describes the conditions
under which a node "n1" at a timestep "t1" has the same integer SDV as a
node "n2" at a timestep "t2."

[0046]If "n1" and "n2" are both assigned integer SDVs, the CER between
them can be as follows. The CER can be a logic 1 if both "n1" and "n2"
have the same integer SDV. The CER can be a logic 0 if "n1" and "n2" have
different integer SDVs.

[0047]If "n1" is assigned an integer SDV and "n2" is assigned an ITE SDV,
then the CER between them can be as follows. The CER can be logic 0 if
there is no setting of the variables of the ITE SDV for which it
evaluates to the same integer SDV assigned to "n1." The CER can be a
symbolic Boolean expression that specifies a setting of the variables of
the ITE SDV for which it evaluates to the same integer SDV assigned to
"n."

[0048]If "n1" is assigned an ITE SDV "iteSDV1" and "n2" is assigned an ITE
SDV "iteSDV2," then the CER between them can be as follows. Let us call
the collection of all variables of iteSDV1 and iteSDV2 the "support" for
any CER between them. The CER can be logic 0 if there is no setting of
the support variables that causes iteSDV1 and iteSDV2 to evaluate to the
same integer SDV. The CER can be a symbolic Boolean expression that
specifies a setting of the variables of the support that causes iteSDV1
and iteSDV2 to evaluate to the same integer SDV.

[0049]Any appropriate heuristic or procedure can be used to identify a
node of a miter as part of control or part of the datapath. Also, the
division between control and datapath nodes can be guided by user input.

[0050]Within test_for_equivalency, a procedure "generate_test_bench" can
be invoked for generation of CSts from RTLMts and HLMts.
CSts is referred to in the pseudo-code as "CS_ts."

1.4 Summary of Initializations

[0051]An "Active Timestep Range" (ATR) is the range of timesteps, of a
miter, currently being processed with the objective of further
propagating SDVs. An ATR begins at a timestep t=ATR_begin and continues
to a timestep at t=ATR_end.

[0052]Prior to starting an equivalence-determining process, the following
initializations can be done.

[0053]The ATR of the miter can be defined by setting values for ATR_begin
and ATR_end. The miter can be initialized to begin as a single timestep
at t=0. In this case, for example, ATR_begin and ATR_end can both be
initialized to zero.

[0054]For each timestep of the ATR, each datapath node can be assigned a
"label identifier." A label identifier is a globally unique identifier
for each datapath node of a miter. Label identifiers can be used, as
described below, for insuring that equivalence classes of nodes, that
have been determined by an equivalence-determining process, are combined
according to a predictable ordering.

[0055]In order to "prime" an SDV propagation process, whereby equivalences
between nodes can be determined, the following initializations can be
accomplished.

[0056]Initial SDVs, for the present-state nodes of the ATR, can be
assigned. In order to determine such initial SDVs, initial states for
RTLM and for HLM can be determined. A novel technique is described herein
for determining an initial state of an HLM by partial execution of it.

[0057]SDVs can be assigned to datapath primary inputs of the ATR. Symbolic
Boolean expressions can be assigned to control primary inputs of the ATR.

[0058]Propagation of SDVs through TFs can be assisted by the determination
of CERs. Specifically, propagation of SDVs through a TF "TF1" and a TF
"TF2" can be assisted by the determination of CERs between the inputs of
TF1 and TF2. Such CERs, combined with a CEC of TF1 and TF2, can allow for
CERs between the outputs of TF1 and TF2 to be determined.

[0059]Within test_for_equivalency, the present-state inputs of the initial
timestep of the initial ATR (e.g., RTLMts[0] and HLMts[0]), can
be set by a procedure called "initialize_initial_timestep."
initialize_initial_timestep can work by first finding initial states for
RTLM and HLM. The initial state for HLM can be found by a novel technique
that utilizes partial execution of the HLM. Results of the partial
execution can be saved, using further novel techniques, such that
initialization of the initial timestep can be accomplished.

1.5 Summary of Equivalence Checking with CERs

[0060]A flowchart, with an overview of a core equivalence-determining
process, is presented.

[0061]The first step of the process is to produce and initialize a miter.

[0062]An SDV propagation process is applied to the ATR.

[0063]The ATR is tested for whether it has a timestep at t=t_ready that is
ready for reencoding.

[0064]If there is a timestep t_ready, the following actions can be taken:
t_ready is reencoded; a first fixed-point target (FPT) is extracted from
t_ready and recorded in an array element FPT[0]; and the ATR is updated
to begin at t_ready (i.e., ATR_begin=t_ready). In preparation for trying
to find a second FPT, timesteps are also added to the ATR and they are
initialized (or "primed") for more SDV propagation.

[0065]If a timestep ready for reencoding has not yet been found, the miter
is tested for whether a maximum number of timesteps have already been
tried. If a maximum number of timesteps have already been tried, the
equivalence-determining process fails and a counter-example can be
generated for the user. If a maximum number of timesteps have not been
tried, a timestep (or timesteps) are added to the ATR. Once timesteps
have been added to the ATR, the process repeats from the above step of
applying an SDV propagation process to the ATR.

[0066]Assuming the search for a first FPT is successful, the
above-described process is repeated in order to find a second FPT at a
later timestep of the miter.

[0067]If a second FPT is found, the two FPTs can be compared. If the two
FPTs are identical, then it is proven that HLMts is equivalent to
RTLMts for all timesteps.

[0068]The equivalence-determining process presented herein is described
mostly with respect to the analysis of a DFG that has been derived from
an RTLM and HLM. However, the equivalence-determining process presented
can be used for comparing two RTLMs to each other, or for comparing two
HLMs to each other. Furthermore, the DFG, to which the
equivalence-determining process presented herein is applied, can be
derived from any type of initial source description.

[0069]Within test_for_equivalency, the procedure
"equivalence_checking_with_CERs" can be called that performs the core
equivalence determining process.

2. Summary of HLM to DFG Conversion by Symbolic Simulation

[0070]The term "symbolic simulation," as utilized herein, refers to a
simulated execution of an input representation such that all possible
scenarios, for flow-of-control, are considered. The result is a
non-canonical data structure that explicitly represents the
flows-of-control considered.

[0071]As an example, the input representation, to be symbolically
simulated, can be a CFG. The CFG can be produced from an HLM, where the
HLM is expressed in a high-level programming language, such as C or C++.
The particular form of non-canonical data structure, produced by symbolic
simulation of the CFG, can be a DFG.

[0072]Each possible flow-of-control through the CFG can be represented by
a marker referred to herein as an "execution path." An execution path can
serve as a bridge, between the CFG and the DFG being produced, as
follows. In addition to marking a location with the CFG, an execution
path can include an expression referred to herein as a "path condition."
A path condition of an execution path "x" can express, in terms of
variables set by nodes of the DFG being produced, the condition under
which the CFG location (indicated by execution path "x") can be reached.

[0073]The initial value, of each variable of the CFG, can be represented
as an input to the DFG to be produced. Once symbolic simulation is
completed, these initial values can "flow through" the DFG and be
transformed, by operators of the DFG, to produce output values for HLM
variables.

[0074]Each possible flow of control through the CFG is encompassed within
the DFG produced by symbolic simulation. Depending upon the initial
values input to the DFG, data can flow through particular paths of the
DFG in order to produce the correct result.

[0075]An example CFG, that can be symbolically simulated, is presented. An
example symbolic simulation of the example CFG, to produce a DFG, is
presented.

[0076]A key operation of any symbolic simulation is "splitting" an
existing execution path "x," into two execution paths "x_true" and
"x_false," when a conditional node "y" of a CFG is reached. Execution
path x_true handles the case where the conditional expression, of
conditional node "y," is satisfied. Execution path x_false handles the
case where the conditional expression, of conditional node "y," is not
satisfied. Symbolic execution fully explores both x_true and x_false so
that the resulting DFG can handle both cases. Another key operation of
symbolic simulation is "merging" two execution paths, "x_true" and
"x_false," into a re-combined execution path "x."

[0077]The symbolic simulation techniques presented herein are discussed
primarily with respect to their application to the
equivalence-determining process presented herein. However, the symbolic
simulation techniques presented herein can be used in conjunction with
any application utilizing a non-canonical representation of an HLM. By
way of example only, and without limiting the range of potential
applications, non-canonical representations of an HLM can be useful with
other types of design analysis tools and with synthesis tools.

[0078]Techniques for handling loops with efficient "decision procedures,"
during symbolic simulation, are presented.

[0079]The order in which execution paths are pushed-on or popped-off the
queue of execution paths, during symbolic simulation, can have a
significant impact on the efficiency of symbolic simulation and on the
quality of the constructed DFG. In general, execution paths which are
split should be merged again as soon as possible. This goal can be
achieved by appropriately sorting the queue of execution paths.

[0080]As a preprocessing step, to applying symbolic simulation to a CFG,
the nodes of the CFG can each be given a priority that determines when
they are traversed during symbolic simulation. Execution paths that point
to nodes with a higher priority can be traversed before execution paths
pointing to lower priority nodes.

[0081]An example CFG, and an example application of a prioritization
process to such CFG, is presented. The prioritization process, used for
the example, is presented in pseudo-code form.

3. Summary of the Timestep Form

[0082]As discussed above, prior to applying an SDV-propagation process,
the miter can be converted into timestep form.

[0083]An example DFG, for conversion into the timestep form, is presented.

[0084]An example conversion into timestep form, of the example DFG, is
presented.

[0085]Production of the timestep form used herein is well-known in the
art, and any suitable technique for production of the timestep form can
be used in conjunction with the inventive techniques described herein.

4. Summary of Test Bench Generation

[0086]As discussed above, test bench generation relates to producing a DFG
in timestep form, referred to herein as a "combining structure" (or
CSts), for combining RTLMts and HLMts in a way that
permits the resulting timestep, referred to herein as a "miter" timestep,
to be tested for equivalence. A timestep "t" of a miter (MTts[t])
can be comprised of the following DFGs: RTLMts[t], HLMts[t] and
CSts[t].

[0087]A process for accomplishing the combination of DFGs can be
summarized as follows. Each RTLMts and HLMts can each be
classified, individually, based on structural criteria. The
classification assigned is referred to herein as a "DFG class." Based
upon the DFG class of RTLMts and HLMts, a structure CSts
for combining the two DFGs can be selected. Such selection of a combining
structure can be viewed as applying the DFG class of RTLMts and the
DFG class of HLMts to a two-dimensional decision matrix. The
selected combining structure can be constructed by drawing upon a library
of DFG building blocks.

[0088]As discussed above, the CSts produced can be designed to have a
"q" output with the following property: "q," for a timestep t, is TRUE if
and only if RTLMts[t] and HLMts[t] are equivalent. Once the
CSts has been produced, the miter timestep can be processed, for
identification of control and datapath nodes, prior to application of an
equivalence-determining procedure.

[0089]While the above-described process, for the selection of CSts,
assumes RTLMts and HLMts each belong to only one DFG class,
this is not necessarily the case. To address this situation, for each
pair of corresponding primary outputs, from RTLMts and HLMts,
each primary output can be put into a DFG class to form a DFG class pair.
This can be accomplished by applying the below-described classification
techniques, to RTLMts and HLMts, on a
primary-output-by-primary-output basis. If all such pairs, of a DFG class
for an output of RTLMts with a DFG class for a corresponding output
of HLMts, are the same, one type of miter can be generated for which
equivalence determination is applied once.

[0090]However, if more than one type of pairing of DFG classes is
identified, an appropriate miter can be generated for each different type
of DFG class pair found. An equivalence-determining procedure can be
applied to each miter. RTLMts and HLMts have been proven to be
equivalent only if all such equivalence-determining tests are successful.

4.1 Summary of Classifying RTLMts and HLMts

[0091]Each DFG can be classified based upon a structural analysis. The
types of DFG classes can include: combinational, pipelined, handshaking
and unknown. Methods for testing a DFG, as to whether it belongs to each
of the DFG classes, are presented. The classification methods share the
common goal of trying to determine how many prior cycles of input data
can affect the result of a computation.

4.2 Summary of Combining Structure Selection

[0092]Based on the DFG class for RTLMts and the DFG class for
HLMts, an appropriate structure, for combining the two DFGs to
produce MTts, can be selected. A decision matrix can be used. An
example decision matrix is presented. The output of the example decision
matrix is one of five categories of combining structure: combinational,
cycle-accurate, pipelined, stream-based and error.

[0093]Each of the five categories of combining structure is presented.

4.2.1 Summary of Combinational

[0094]The combinational combining structure can be applied when both DFGs
are classified as combinational.

4.2.2 Summary of Cycle-Accurate

[0095]The cycle-accurate combining structure can be applied when either
DFG is classified as unknown. The cycle-accurate combining structure can
be preferred under these circumstances since it produces a "strong" form
of equivalence testing that will not produce a false positive. On the
other hand, because the cycle-accurate combining structure produces a
MTts that is so restrictive as to the conditions under which
equivalence between HLMts and RTLMts can be found, it can
produce a false negative where a "weaker" equivalence test might be able
to show the DFGs are equivalent. Therefore, while the cycle-accurate
combining structure is a suitable default, it can also be desirable to
allow the user to select another combining structure that produces a
weaker test for equivalence.

[0096]The cycle-accurate combining structure produces an equivalence test
where both DFGs must produce exactly the same output on every clock cycle
in order for equivalence to be found.

4.2.3 Summary of Pipelined

[0097]The pipelined combining structure can be applied under the following
circumstances: both DFGs are classified as pipelined, one DFG is
classified as combinational and the other is classified as pipelined. If
one of the DFGs is classified as combinational, it can be converted into
a one-stage pipeline.

[0098]The approach of a pipelined combining structure is to effectively
modify one or both of the DFGs such that a cycle-accurate equivalence
test can be performed.

[0099]Techniques are presented for using a pipelined combining structure
to couple DFGs that use memories. The technique employs determination of
a memory mapping between the memories of both designs.

4.2.4 Summary of Stream-Based

[0100]The stream-based combining structure is applicable when both
RTLMts and HLMts have been put into the DFG class
"handshaking."

[0101]Stream-based equivalence, if proven, can be characterized as
follows. First, both RTLMts and HLMts receive the same stream
of input data, but not necessarily at the same time. Second, both
RTLMts and HLMts generate the same output data, but not
necessarily at the same time. Phrased another way, stream-based
equivalence means there are no constraints on the relative timing of the
inputs or outputs of RTLMts and HLMts, however, data packets
produced by the two DFGs should be produced in the same order.

[0102]An overall method, by which a stream-based combining structure can
be used, is as follows. First, create two sub-miters. Each sub-miter is
comprised of an instance of RTLMts, HLMts and the stream-based
combining structure CS_STREAMts. Second, if both sub-miters find
equivalency, on a cycle-accurate basis, then RTLMts and HLMts
are equivalent on a stream-accurate basis.

[0103]Each sub-miter is constructed as follows.

[0104]For a first sub-miter, RTLMts is tested for equivalence with
HLMts under conditions that correspond to RTLMts operating at
"full speed." Put differently, every time RTLMts can accept a set of
data inputs, it is able to do so. HLMts is tested for equivalence
with RTLMts under conditions that constrain its inputs to be the
same as whatever RTLMts indicates it is able to accept. Thus the
first sub-miter determines equivalence between a fully exercised
RTLMts and a HLMts limited to those inputs that exercise
RTLMts.

[0105]If the result of comparing RTLMts to HLMts is successful,
then it is known that for any inputs acceptable by RTLMts,
HLMts will produce stream-equivalent output. However, it is still
not known whether, for the "full" range of inputs acceptable to
HLMts, if RTLMts can produce stream-equivalent outputs. This is
accomplished by reversing the roles of RTLMts and HLMts in the
second sub-miter.

[0106]Put more symbolically, it is first shown by the first sub-miter that
the set of outputs (or SOO) of RTLMts (or SOO(RTLMts)) is a
subset of the SOO of HLMts (or SOO(HLMts)). Put in mathematical
relation form:

SOO(RTLMts).OR right.SOO(HLMts)

[0107]By reversing the roles of RTLMts and HLMts, the second
sub-miter can show that:

SOO(HLMts).OR right.SOO(RTLMts)

[0108]The only way both relations can be true is if the following is true:

SOO(HLMts)=SOO(RTLMts)

[0109]An example stream-based combining structure, suitable for
constructing the first and second sub-miters, is presented.

[0110]Since the first and second sub-miters can be constructed in an
identical way, except for the roles of RTLMDFG and HLMDFG being
reversed, just the construction of the first sub-miter is addressed.

[0111]The first sub-miter is constructed to allow DFG 2623 to process data
as soon as it is able to, while not guaranteeing the same for DFG 2624.

[0112]DFGs 2623 and 2624, of a sub-miter, can produce their output packets
at different times. A FIFO can be used to store outputs such that they
can be compared. An example operation for such FIFO is presented.

[0113]The stream-based combining structure, presented herein, can be used
in conjunction with any formal analysis tool. The stream-based combining
structure, presented herein, can be used without the step of classifying
the first and second designs that it couples.

[0114]When the stream-based combining structure is used without the step
of classification, any appropriate representation can be used for the
stream-based combining structure and for the first and second designs to
be coupled. For the first and second designs to be coupled, each can be
treated as a "black box," with just information on its inputs and outputs
provided.

4.2.5 Summary of Error

[0115]The error combining structure can be applied if it is not known, for
the classifications of the two DFGs, what combining structure, if any,
should be applied.

4.3 Summary of Generating the Test Bench

[0116]Once a combining structure has been selected, MTts can be
generated.

4.4 Summary of Other Applications

[0117]The techniques of test bench generation presented herein are
discussed primarily with respect to combining DFGs of an RTLM and HLM,
for purposes of applying the equivalence determination process described
herein. However, the test bench generation techniques presented herein
can be used for combining any first DFG and second DFG, regardless of the
source from which the first and second DFGs are derived. The resulting
combination, of first DFG, second DFG and combining structure, can be
used in conjunction with any formal analysis technique.

[0118]Furthermore, the test bench generation techniques presented herein
can be used for combining a first and second design, where the first and
second designs are not specified as DFGs. The step of classifying each of
the first and second designs, in order to determine the applicable
combining structure, only requires that the first and second designs be
expressed in a representation that provides the necessary structural
information. By way of example, a netlist representation could be used
instead of a DFG representation.

5. Summary of Initialization of the Miter Timestep

[0119]As discussed above, in order to compare RTLMts and HLMts
for potential equivalency, they may need to be set to equivalent initial
states.

[0120]Suitable initial states of RTLM and HLM, for initializing
RTLMts and HLMts, can be determined.

[0121]Whenever both RTLM and HLM are ready, the initial states for RTLM
and HLM can be translated into appropriate initial values for RTLMts
and HLMts.

[0122]For an HLM that is compiled, its initial state can be determined by
the following process.

[0123]Before partially executing the HLM, the user can provide information
on the location within the HLM where the initialization phase is
finished, and a breakpoint can be set at the location.

[0124]An HLM written in a compiled language (such as C or C++) can be
compiled such that debugging information is available. Debugging
information, in a compiled executable, can be used to extract the values
of program variables of the HLM when it stopped at the breakpoint.

[0125]An operating system process, under which the HLM runs, can be
created.

[0126]For an HLM that is run with a dynamic (or run-time) linker,
operating system libraries used by the HLM can be linked-to at run-time.
At the time of such library linking, rather than linking the HLM's
typical run-time library, a special "Interceptor Library" can be linked
to.

[0127]An Interceptor Library is so-called because it can intercept
operating system calls the HLM might make, such as those related to
memory allocation, memory reallocation or memory deallocation.

[0128]The Interceptor Library functions can call the actual functions of
the applicable operating system. Before returning, the Interceptor
Library functions can record, for post run-time use, information about
the currently allocated memory blocks.

[0129]The HLM can be run until the breakpoint is reached, at which point
it is in an appropriate initial state to be used for setting the initial
states of RTLMts and HLMts. Because the HLM was executed with
debugging information enabled, and with the Interceptor Library
substituted for certain operating system procedures, the necessary
information is available for the process of setting RTLMts and
HLMts to initial states.

[0130]Once initial states for RTLM and HLM are available, a process is
presented for translating their values into appropriate initial values
for the initial timesteps of RTLMts and HLMts.

[0131]An example initialization, for the control and datapath
present-state inputs of an initial timestep, is presented.

[0132]The techniques of partial HLM execution, and of accessing the values
of the partially executed HLM, are presented herein primarily with
respect to initializing a DFG representation of the HLM. Furthermore, the
discussion presented herein focuses primarily on applying the initialized
DFGs to the equivalence determining process presented herein.

[0133]However, the techniques of partial HLM execution, and of accessing
the values of the partially executed HLM, can be used in conjunction with
initializing any formal analysis tool (including those that do not use
DFGs), where the representation subject to formal analysis is derived
from an HLM.

6. Summary of Verification with CERs

[0134]Pseudo-code, for a core equivalence-determining process, is
presented. Before presenting the pseudo-code, an example application of a
core equivalence-determining process is presented in overview form.

[0135]A core equivalence-determining process can be performed by invoking
a pseudo-code procedure called equivalence_checking_with_CERs." The
hierarchical manner, in which procedures are invoked by
equivalence_checking_with_CERs, is diagrammed.

7. Summary of Example

[0136]To illustrate the operation of the pseudo-code an example simulation
is presented.

BRIEF DESCRIPTION OF THE DRAWINGS

[0137]The accompanying drawings, that are incorporated in and constitute a
part of this specification, illustrate several embodiments of the
invention and, together with the description, serve to explain the
principles of the invention:

[0138]FIG. 1 presents a high-level overview of an equivalency testing
system, where novel sub-systems are drawn with dashed lines.

[0139]FIG. 2A defines certain global variables and symbolic constants that
are used throughout the pseudo-code of FIGS. 24 to 30.

[0140]FIG. 2B depicts a pseudo-coded procedure called
"test_for_equivalency" that represents an example equivalency testing
system that operates in accordance with teachings of the present
inventions.

[0141]FIG. 3A presents an example of C or C++ code from which a CFG can be
produced.

[0142]FIG. 3B presents an example CFG that can be symbolically simulated
to produce a DFG.

[0143]FIGS. 4A-4G depict steps in the creation of a DFG by symbolic
simulation.

[0144]FIGS. 5A-5F depict intermediate data structures, that can be used
during DFG production by symbolic simulation, referred to herein as
"output-lists."

[0145]FIGS. 6A-6H depict different states of a queue, referred to herein
as an "execution path queue," that can be used to perform a breadth-first
traversal of an HLMCFG.

[0146]FIGS. 7A-7F depict pseudo-code for symbolic simulation.

[0147]FIGS. 8A-8N and 8P-8Q (there is no FIG. 80) depict an example of how
the prioritization procedure, of FIGS. 9A-9B, can be applied.

[0148]FIGS. 9A-9B show pseudo-code for assigning priorities as part of a
preprocessing step to symbolic simulation.

[0149]FIG. 10A depicts an example DFG for conversion into the timestep
form.

[0150]FIG. 10B shows a conversion of the DFG of FIG. 10A into the timestep
form.

[0151]FIG. 11 shows a pseudo-code implementation for use in determining
whether a DFG primary output is of DFG class "combinational."

[0152]FIG. 12 shows a pseudo-code implementation for use in determining
whether a DFG primary output is of DFG class "pipelined."

[0153]FIG. 13 depicts a combinational combining structure.

[0154]FIG. 14 depicts a cycle-accurate combining structure.

[0155]FIG. 15 depicts a pipelined combining structure.

[0156]FIG. 16A depicts a stream-based combining structure.

[0157]FIG. 16B depicts a process to allow DFG 2623 to process data as soon
as it is able to, while not guaranteeing the same for DFG 2624.

[0158]FIG. 16C depicts a more detailed view of an example operation of a
FIFO controller.

[0175]FIG. 31 depicts a data processing system for executing the
equivalence determining architecture of the present invention, or for
executing each of its component sub-systems individually.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0176]Reference will now be made in detail to preferred embodiments of the
invention, examples of which are illustrated in the accompanying
drawings. Wherever possible, the same reference numbers will be used
throughout the drawings to refer to the same or like parts.

[0211]2.5. Loop For Breadth-First Traversal Of CFG [0212]2.5.1. Two EPs
Point To Same CFG Node [0213]2.5.2. Top EP Points To Conditional CFG Node
[0214]2.5.3. Top EP Points To Assignment CFG Node [0215]2.5.4. Top EP
Points To END CFG Node

[0306]This section begins by presenting a high-level overview of an
equivalency testing system (see FIG. 1, where novel sub-systems are drawn
with dashed lines). Then, each of sub-sections 1.1 to 1.5 addresses, in
further detail, a major component of such a system. To provide an example
overall framework for presenting sub-sections 1.1 to 1.5, each of these
sub-sections relates the component it discusses to a pseudo-coded
procedure called "test_for_equivalency" (shown in FIG. 2B).
test_for_equivalency presents an example equivalency testing system that
operates in accordance with teachings of the present inventions. Each of
sections 2-6, that follow this section 1, addresses a major component, of
an equivalency testing system, in much greater detail. FIG. 2A defines
certain global variables and symbolic constants that are used throughout
the pseudo-code of FIGS. 24 to 30.

[0307]Both the RTLM and HLM, that are to be compared for equivalence, are
converted into DFGs, called RTLMDFG and HLMDFG. RTLMDFG
can be determined by any suitable known means, but HLMDFG can be
determined by a new technique, of symbolic simulation of the HLM,
presented herein. FIG. 1 presents an input RTLM 1020 and HLM 1010. A
novel HLM to DFG conversion process 1011 is used to produce HLMDFG
1012. An RTLM to DFG conversion process 1021 is used to produce
RTLMDFG 1022.

[0308]RTLMDFG and HLMDFG are put into a timestep form, referred
to as RTLMts and HLMts. An arbitrary timestep "t," of
RTLMts and HLMts, can be referred to as RTLMts[t] and
HLMts[t]. FIG. 1 presents an HLMDFG to timestep conversion
process 1013 that produces HLMts 1014. FIG. 1 presents an
RTLMDFG to timestep conversion process 1023 that produces
RTLMts 1024.

[0309]A combining structure CSts can be selected, that couples to
RTLMts and HLMts. The combining structure has the following
property: if, for a timestep t, RTLMts[t] and HLMts[t] are
equivalent according to a given (or automatically determined) notion of
equivalence, then CSts[t] will detect this. Different types of
combining structures can be selected depending upon the type of circuit
represented by RTLMts and HLMts. Novel techniques, for
classifying each of RTLMts and HLMts, and for selecting a
suitable CSts, are presented. In addition, novel forms of combining
structure, suitable in general for formal verification, are presented.
For example, a novel combining structure, for showing that RTLMts
and HLMts are stream-equivalent, is presented.

[0311]The complete system, comprised of RTLMts[t], HLMts[t] and
CSts[t], will be referred to herein as "miter." The miter can have
certain parts designated as representing control logic and other parts
designated as representing datapath logic. Parts of the miter designated
as control can be subject to a known form of bit-level equivalence
checking. Parts of the miter designated as datapath are subject to a new
form of equivalence checking that works above the bit level, using a node
value indicator referred to herein as a "symbolic data value" or SDV, and
that seeks to prove equivalence by a form of inductive theorem proving.
Formation of the miter, and its processing for equivalence checking, is
represented in FIG. 1 by HLMts 1014, CSts 1032 and RTLMts
1024 feeding into equivalence determination process 1033.

[0312]In the datapath portions of the miter, equivalence checking can be
conducted at a higher level of abstraction if one is not interested in
actual data values, but only in whether RTLMts and HLMts
produce the same data (given that they receive the same input data). In
this case, integers can be used as an abstraction for datapath data
values: if two signals have the same integer number, this signifies that
their actual data values are the same; if two signals have the different
integer numbers, this signifies their actual data values are different.
To refer to such integer values, the term "integer SDV" can be used.

[0313]If it can be proven that RTLMts and HLMts both produce the
same SDVs on all of their primary outputs, and for all times, it is
proven that both designs are equivalent. In order to determine the SDVs
of the primary outputs of RTLMts and HLMts, input SDVs must be
propagated through the miter.

[0314]A novel form of inductive theorem proving starts from initial
conditions for the first timestep for the miter (i.e., for timestep
RTLMts[0], HLMts[0] and CSts[0]). The initial state for
RTLMts[0] can be determined by any suitable known means, but the
initial state for HLMts[0] can be determined by a new technique, of
partial execution of the HLM, presented herein. FIG. 1 represents the
initialization of HLMts 1014 and RTLMts 1024 as follows. HLM
1010, RTLM 1020, HLMts 1014 and RTLMts 1024 all serve as inputs
to an initial state determination process 1030. Initial state
determination process 1030 sets HLMts 1014 and RTLMts 1024 to
an initial state prior to their utilization by equivalence determination
process 1033.

[0315]A first "phase" of SDV propagation is performed. In SDV propagation,
SDVs of the first timestep are sought to be propagated forward to the
outputs of the first timestep. If a path of propagation cannot be fully
pursued to the outputs of a timestep, additional timesteps can be added.
The first phase of SDV propagation ends when the miter is completely
"populated" with SDVs up to a timestep called t_ready-1. The full
population of SDVs means that if RTLM and HLM can be equivalent during
those timesteps (i.e., the timesteps from the first timestep up to
t_ready-1), this equivalence will be detected by the combining structure
of each of those timesteps.

[0316]In propagating SDVs through a timestep, a complication arises with
multiplexers. Consider the case of a two-input multiplexer where an
integer SDV is present at each of the multiplexer's inputs. If the two
SDVs are to be propagated through the multiplexer, the resulting SDV on
the multiplexer output cannot be represented as an integer, since the
multiplexer's selector input determines which SDV is routed to the
output. To model the conditional dependency of the multiplexer output, on
the selector condition, a second type of SDV, referred to herein as an
ITE (If-Then-Else) SDV, is introduced.

[0317]The SDVs chosen and formed, as part of the first phase of SDV
propagation, are guided by labels that are assigned to the nodes of the
miter in a particular order as timesteps are added.

[0318]The timestep at t_ready is reencoded and the symbolic values of its
datapath signals, relative to their timestep-invariant node names, are
recorded as a potential first "fixed-point" of the SDV propagation
process.

[0319]As part of the reencode, the order of label assignment, that guided
the selection and formation of SDVs during the first phase of SDV
propagation, is repeated from the beginning.

[0320]Starting with the potential first fixed-point as the initial
condition, a second phase of SDV propagation is performed. Like the first
phase, the ending of the second phase of SDV propagation is marked by the
miter being completely "populated" with SDVs up to a later timestep, also
called t_ready-1.

[0321]Because the second phase of SDV propagation is guided by a
repetition of the same labeling process that guided the first phase of
SDV propagation, if the potential first fixed-point is a real
fixed-point, the exact same form of SDV propagation will occur during the
second phase as occurred during the first phase.

[0322]This repetition of propagation phases can be detected as follows.
The timestep of the later t_ready is reencoded. The symbolic values of
the datapath signals of the later t_ready, relative to their
timestep-invariant node names, are recorded as a potential second
"fixed-point."

[0323]If the first and second, potential fixed-points, are identical, then
it has been inductively proven that the process of SDV propagation can be
repeated, indefinitely, for all timesteps. If each timestep "t," from the
initial timestep of the first phase up to the timestep t_ready-1 of the
second phase, indicates HLMts[t] and RTLMts[t] are equivalent
(as indicated by CSts[t]), then it is known that HLM and RTLM are
equivalent for all timesteps.

[0324]In FIG. 1, the proving of equivalence between HLM and RTLM
corresponds to equivalence determination process 1033 producing an
"equivalence indicator" for the user of the system. If equivalence
determination process 1033 cannot prove equivalence, a "counter example"
can be produced to aid the user in locating where behavior of the HLM
diverges from that of the RTLM.

[0325]1.1. Conversion of HLM and RTLM to DFGs

[0326]1.1.1. Overview

[0327]Before an HLM and RTLM are compared, for purposes of determining
equivalence, both can be translated into the common representation of a
DFG (Data-Flow-Graph).

[0328]An HLM can be specified as a function written in a high-level
programming language, such as C++. The DFG produced from the HLM can be
referred to as an HLMDFG. The DFG produced from the RTLM can be
referred to as RTLMDFG. Conversion of an RTLM into an RTLMDFG
is well known and need not be described herein. A novel technique is
described herein, in section 2 ("HLM to DFG Conversion By Symbolic
Simulation"), for converting an HLM into an HLMDFG using symbolic
simulation.

[0329]1.1.2. Within Test_for_Equivalency

[0330]In FIG. 2B, a procedure "RTLM--2_DFG" is invoked (see line 5)
for conversion of an RTLM into an RTLMDFG. RTLMDFG is referred
to in the pseudo-code as "RTLM_dfg." FIG. 2B also shows the invocation
(see line 8) of a procedure "HLM--2_DFG" for conversion of an HLM
into an HLMDFG. HLMDFG is referred to in the pseudo-code as
"HLM_dfg." Procedure "HLM--2_DFG corresponds to HLM to DFG
conversion process 1011 of FIG. 1. Procedure "RTLM--2_DFG
corresponds to RTLM to DFG conversion process 1021 of FIG. 1.

[0331]1.2. Conversion Into Timestep Form

[0332]1.2.1. Overview

[0333]RTLMDFG and HLMDFG can be converted into the timestep (or
time stage) form for further equivalence-determination processing.
Conversion of a DFG into timestep form is described below in section 3
("The Timestep Form"). The timestep form of RTLMDFG can be referred
to as RTLMts. The timestep form of HLMDFG can be referred to as
HLMts.

[0334]A timestep of time "t," of an arbitrary DFG "X" in timestep form
(e.g., Xts or X_ts), can be referred to as an array element "t" of
"X" (e.g., Xts[t] or X_ts[t]).

[0335]Prior to the conversion of RTLMDFG and HLMDFG into
timestep form, each of their nodes can have a name, referred to herein as
a "timestep-independent" name, that can be kept in the timestep form (see
Glossary for definition of timestep-independent name).

[0336]1.2.2. Within Test_for_Equivalency

[0337]RTLMts is referred to in the pseudo-code as "RTLM_ts."
HLMts is referred to in the pseudo-code as "HLM_ts."

[0338]FIG. 2B shows the invocation (see line 14) of a procedure
"generate_timestep" for generation of RTLMts from RTLMDFG
(which corresponds to RTLMDFG to RTLMts conversion process 1023
of FIG. 1). FIG. 2B also shows the invocation (see line 15) of the
procedure "generate_timestep" for generation of HLMts from
HLMDFG (which corresponds to HLMDFG to HLMts conversion
process 1013 of FIG. 1).

[0339]1.3. Combining Structure Generation

[0340]1.3.1. Overview

[0341]Test bench generation relates to producing a DFG in timestep form,
referred to herein as a "combining structure" (or CSts), for
combining RTLMts and HLMts in a way that permits the resulting
timestep, referred to herein as a "miter" timestep, to be tested for
equivalence. A timestep "t" of a miter can be comprised of the following
DFGs: RTLMts[t], HLMts[t] and CSts[t].

[0342]A process for producing a CSts can be summarized as follows.
RTLMts and HLMts can each be classified. Based upon the
classification of each DFG, a CSts can be selected. A detailed
description of this process is presented below in section 4 ("Test Bench
Generation").

[0343]A CSts can be designed to produce an output "q" that has the
following property: "q" for a timestep t, is TRUE if and only if
RTLMts[t] and HLMts[t] are equivalent according to a given
notion of equivalence.

[0344]One of the combining structures presented is for the comparison of
stream-based designs. This stream-based combining structure, on its own
and without a prior step of classification of the designs to be coupled,
is novel. Other applications, of this stream-based combining structure,
are discussed.

[0345]Production of the miter can include identification of control and
datapath nodes. Each datapath node can be assigned a value referred to
herein as an "SDV." Each control node can be assigned a value referred to
herein as a "symbolic Boolean expression." The below section 1.3.2
("Symbolic Data Values (SDVs) and Conditional Equivalence Relations
(CERs)") presents definitions for SDV and symbolic Boolean expression.
The below section 1.3.3, "Identification Of Nodes As Control or
Datapath," discusses considerations and techniques for identifying nodes
as control or datapath.

[0347]Each node of the miter, identified as part of the datapath, can be
assigned a value referred to herein as a "symbolic data value" or SDV. An
SDV is not intended to represent a particular piece of data, or a
particular value. Rather, an SDV is intended to represent whether one
node of the datapath has been assigned the same value (or data structure)
as another node of the datapath. An SDV can be of two types: integer and
ITE.

[0348]1.3.2.1. Integer SDV

[0349]An integer SDV is just an integer value. If node "n1" at a timestep
"t1" is assigned the same integer SDV as a node "n2" at a timestep "t2,"
this means that node "n1," for at least timestep "t1," and node "n2," for
at least timestep "t2," have the same value. The actual data represented
by the integer SDV, and is therefore the same at nodes "n1" and "n2," can
be arbitrarily complex.

[0350]1.3.2.2. ITE SDV

[0351]An ITE SDV expression can be defined by the following context-free
grammar:

[0352]An ITE SDV takes three arguments: a symbolic Boolean expression, a
first SDV and a second SDV. Whether the symbolic Boolean expression is
satisfied depends upon control nodes to which it relates. If the symbolic
Boolean expression is satisfied, then the value of the first SDV is
returned by the ITE SDV, else the value of the second SDV is returned by
the ITE SDV. The first and second SDVs can either be an integer SDV, or a
nested ITE SDV.

[0353]An ITE SDV can be used to indicate whether or not datapath nodes are
outputting the same data, at a particular time, depending upon which
conditions of the control nodes are met.

[0354]1.3.2.3. Symbolic Boolean Expression

[0355]A symbolic Boolean expression is the same as an ordinary Boolean
expression, except that rather than being comprised of Boolean variables
(e.g., "x" or "-x") and/or Boolean values (e.g., "1" or "0"), it is
comprised of, respectively, symbolic Boolean variables and/or symbolic
Boolean values. A symbolic Boolean expression can be a single symbolic
Boolean variable or a single symbolic Boolean value. A symbolic Boolean
expression can also be comprised of symbolic Boolean variables and/or
symbolic Boolean values connected by Boolean operators.

[0356]A symbolic Boolean variable can differ from an ordinary Boolean
variable as follows. A symbolic Boolean variable can include an
indication of the timestep for which it was initially created. For
example, a symbolic Boolean variable can include the integer "0" to
indicate that it was initially created for the timestep zero. For the
timestep zero, an example symbolic Boolean variable can be "X[0]"
(corresponding to the Boolean variable "X").

[0357]A symbolic Boolean value can differ from an ordinary Boolean value
as follows. A symbolic Boolean value can include an indication of the
timestep for which it was initially created. For example, a symbolic
Boolean value can include the integer "0" to indicate that it was
initially created for the timestep zero. For the timestep zero, the
symbolic Boolean values can be "1[0]" (corresponding to a Boolean "1")
and "0[0]" (corresponding to a Boolean "0").

[0358]1.3.2.4. CERs

[0359]A CER is a symbolic Boolean expression that describes the conditions
under which a node "n1" at a timestep "t1" has the same integer SDV as a
node "n2" at a timestep "t2."

[0360]If "n1" and "n2" are both assigned integer SDVs, the CER between
them can be as follows. The CER can be a logic 1 if both "n1" and "n2"
have the same integer SDV. The CER can be a logic 0 if "n1" and "n2" have
different integer SDVs.

[0361]If "n1" is assigned an integer SDV and "n2" is assigned an ITE SDV,
then the CER between them can be as follows. The CER can be logic 0 if
there is no setting of the variables of the ITE SDV for which it
evaluates to the same integer SDV assigned to "n1." The CER can be a
symbolic Boolean expression that specifies a setting of the variables of
the ITE SDV for which it evaluates to the same integer SDV assigned to
"n1."

[0362]If "n1" is assigned an ITE SDV "iteSDV1" and "n2" is assigned an ITE
SDV "iteSDV2," then the CER between them can be as follows. Let us call
the collection of all variables of iteSDV1 and iteSDV2 the "support" for
any CER between them. The CER can be logic 0 if there is no setting of
the support variables that causes iteSDV1 and iteSDV2 to evaluate to the
same integer SDV. The CER can be a symbolic Boolean expression that
specifies a setting of the variables of the support that causes iteSDV1
and iteSDV2 to evaluate to the same integer SDV.

[0363]1.3.2.5. MTBDDs

[0364]ITE SDVs (as well as integer SDVs) can be represented as MTBDDs.
This permits a CER to be found, between two SDVs, by applying the two
SDVs to any standard MTBDD solving package that seeks for the conditions
under which the two SDVs produce the same value. The CER, resulting from
the two MTBDDs, can be expressed as a BDD.

[0365]1.3.3. Identification of Nodes as Control or Datapath

[0366]Any appropriate heuristic or procedure can be used to identify a
node of a miter as part of control or part of the datapath. Also, the
division between control and datapath nodes can be guided by user input.

[0367]Identification of all nodes in a miter as being control results in
the performance of a known type of equivalence checking at the bit level.
This type of equivalence checking has the advantage that if the search is
not intractable, an exact answer, as to whether the two designs are
equivalent, will be found.

[0368]As one proceeds to indicate more of a miter as being datapath, the
search for equivalence can become more tractable, but the probability of
finding a "false negative" (i.e., an indication that the two designs are
not equivalent when, in fact, the are equivalent) increases.

[0369]The following heuristic has been found to provide a suitable
tradeoff between increased tractability, while keeping the probability of
false negatives low: indicate all nodes as datapath, except for those in
the transitive fanin of each multiplexer selector input.

[0370]1.3.4. Within Test_for_Equivalency

[0371]CSts is referred to in the pseudo-code as "CS_ts." FIG. 2B
shows the invocation (see line 21) of a procedure "generate_test_bench"
for generation of CSts from RTLMts and HLMts. Procedure
"generate_test_bench" corresponds to combining structure generation
process 1031 of FIG. 1.

[0372]1.4. Initializations

[0373]1.4.1. Overview

[0374]Prior to starting an equivalence-determining process, the following
initializations can be done.

[0375]The ATR of the miter can be defined (see below section 1.4.2,
"Active Timestep Range," for definition of ATR) by setting values for
ATR_begin and ATR_end. The miter can be initialized to begin as a single
timestep at t=0. In this case, for example, ATR_begin and ATR_end can
both be initialized to zero.

[0376]For each timestep of the ATR, each datapath node can be assigned a
"label identifier." A label identifier is a globally unique identifier
for each datapath node of a miter. Label identifiers can be used, as
described below, for insuring that equivalence classes of nodes, that
have been determined by an equivalence-determining process, are combined
according to a predictable ordering.

[0377]In order to "prime" an SDV propagation process, whereby equivalences
between nodes can be determined, the following initializations can be
accomplished (see below section 1.4.3, "SDV Propagation Processes," for a
definition of SDV propagation processes).

[0378]Initial SDVs, for the present-state nodes of the ATR, can be
assigned. In order to determine such initial SDVs, initial states for
RTLM and for HLM can be determined. An initial state for RTLM can be
determined in a well known manner that need not be described herein. A
novel technique is described herein for determining an initial state of
an HLM by partial execution of it.

[0379]SDVs can be assigned to datapath primary inputs of the ATR. Symbolic
Boolean expressions can be assigned to control primary inputs of the ATR.

[0380]1.4.2. Active Timestep Range

[0381]An "Active Timestep Range" (ATR) is the range of timesteps, of a
miter, currently being processed with the objective of further
propagating SDVs (see below section 1.4.3 "SDV Propagation Processes").
An ATR begins at a timestep t=ATR_begin and continues to a timestep at
t=ATR_end.

[0382]1.4.3. SDV Propagation Processes

[0383]An SDV Propagation process seeks to propagate SDVs through a miter's
ATR as far as possible.

[0384]Propagation of an SDV means the following. For a component (e.g., a
multiplexer or transformation function) within a timestep, it is the
determination of an SDV for the component's output based upon the SDVs at
its inputs. When propagating an SDV from a timestep at t=n to a timestep
at t=n+1, it is the determination of an SDV for a present state input of
t=n+1 based upon next state outputs of t=n.

[0385]Propagation of SDVs through TFs (see Glossary for definition of
"TF") can be assisted by the determination of CERs. Specifically,
propagation of SDVs through a TF "TF1" and a TF "TF2" can be assisted by
the determination of CERs between the inputs of TF1 and TF2. Such CERs,
combined with a CEC of TF1 and TF2, can allow for CERs between the
outputs of TF1 and TF2 to be determined.

[0386]1.4.4. Within Test_for_Equivalency

[0387]The active timestep range can be defined to begin at the value set
for "ATR_begin" (which also indicates the last timestep to be reencoded)
and to end at the value set for "ATR_end." These can both be initialized
to zero. FIG. 2B, lines 23-24.

[0388]The initial active timestep range (e.g., RTLMts[0],
HLMts[0] and CSts[0]) can have its nodes labeled in levelized
order by label_datapath_nodes. FIG. 2B, line 27.

[0389]The present-state inputs of the initial timestep of the initial ATR
(e.g., RTLMts[0] and HLMts[0]), can be set by a procedure
called "initialize_initial_timestep." FIG. 2B, lines 32-33.
initialize_initial_timestep can work by first finding initial states for
RTLM and HLM. The initial state for RTLM can be found by any appropriate
conventional technique. The initial state for HLM can be found by a novel
technique that utilizes partial execution of the HLM. Results of the
partial execution can be saved, using further novel techniques, such that
initialization of the initial timestep can be accomplished.
initialize_initial_timestep is discussed in detail in below section 5
("Initialization Of The Miter Timestep"). In FIG. 1, procedure
initialize_initial_timstep corresponds to initial state determination
process 1030.

[0390]The datapath primary inputs and the control logic primary inputs of
the initial timestep of the initial ATR can be initialized by calling a
procedure called "initialize_timestep_inputs." FIG. 2B, line 40.
initialize_timestep_inputs is discussed in detail in below sections 5.3
("Translation To Initial Timestep") and 6.1.5
("initialize_timestep_inputs").

[0391]1.5. Equivalence Checking with CERs

[0392]1.5.1. Overview

[0393]An overview of an equivalence-determining process is shown in FIG.
19.

[0394]The process begins at step 4000. The first step of the process is to
produce and initialize a miter, as discussed above. Step 4001.

[0396]The ATR is tested for whether it has a timestep at t=t_ready that is
ready for reencoding. Step 4003. The conditions, for a timestep being
ready for reencoding, are discussed in the below section 1.5.3 ("Ready
For Reencoding"). If there is a timestep t_ready, the following actions
can be taken (see step 4006): t_ready is reencoded; a fixed-point target
(FPT) is extracted from t_ready and recorded in an array element FPT[0];
and the ATR is updated to begin at t_ready (i.e., ATR_begin=t_ready). A
definition of "FPT" is presented in the below section 1.5.4 ("Fixed-Point
Target (FPT)"). In preparation for trying to find another FPT, timesteps
are also added to the ATR and they are initialized (or "primed") for more
SDV propagation. FIG. 19, step 4008.

[0397]If a timestep ready for reencoding has not yet been found, the "no"
branch of step 4003 is taken and the miter is tested (by step 4004) for
whether a maximum number of timesteps have already been tried. If a
maximum number of timesteps have already been tried, the "yes" branch of
step 4004 is taken and the equivalence-determining process fails (in step
4007). If a maximum number of timesteps have not been tried, the "no"
branch of step 4004 is taken and a timestep (or timesteps) are added to
the ATR (by step 4005). Once timesteps have been added to the ATR, the
SDV propagation process is repeated (at step 4002).

[0398]Continuing the above description, at the point where step 4008 has
been accomplished, the collective function of steps of 4002 to 4007, in
finding a first FPT, is essentially repeated by steps 4010 to 4015. Steps
4010 to 4015 seek to find a second FPT at a later timestep of the miter.

[0400]The ATR is tested for whether it has a timestep at t=t_ready that is
ready for reencoding. Step 4012. The timestep t_ready, if found, is at a
later timestep than the t_ready found by step 4003. The conditions, for a
timestep to be ready for reencoding, are the same as those discussed
above for step 4003.

[0401]If a timestep t_ready is found by step 4012, the following actions
can be taken (by step 4014): the timestep at t_ready is reencoded; a
second fixed-point target (FPT) is extracted from the timestep at t_ready
and recorded in an array element FPT[1]; and the ATR is updated to begin
at t_ready (i.e., ATR_begin=t_ready).

[0402]Continuing from the point where step 4014 is completed, the two FPTs
can be compared. Step 4016. If the two FPTs are identical, then it is
proven that HLMts is equivalent to RTLMts for all timesteps.
Such success is indicated by taking the "yes" branch from step 4016 to
step 4018 that causes a "succeed" to be indicated. If the two FPTs are
not identical, then it is known that the equivalence-determining process
cannot prove equivalence, for all timesteps, between HLMts and
RTLMts.

[0403]If a timestep at a time t_ready is not found by step 4012, the
following actions can be taken. The miter is tested (by step 4013) for
whether a maximum number of timesteps have already been tried. If a
maximum number of timesteps have already been tried, the "yes" branch of
step 4013 is followed and the equivalence-determining process fails (in
step 4015). If a maximum number of timesteps have not been tried, the
"no" branch of step 4013 is taken and a timestep (or timesteps) are added
to the ATR (by step 4010). Once timesteps have been added to the ATR, the
SDV propagation process is repeated (at step 401 1).

[0404]1.5.2. Other Applications

[0405]The equivalence-determining process presented herein is described
mostly with respect to the analysis of a DFG that has been derived from
an RTLM and HLM. However, the equivalence-determining process presented
can be used for comparing two RTLMs to each other, or for comparing two
HLMs to each other. Furthermore, the DFG, to which the
equivalence-determining process presented herein is applied, can be
derived from any type of initial source description.

[0406]1.5.3. Ready for Reencoding

[0407]An ATR of a miter is ready for reencoding, at a timestep t_ready, if
the following conditions are satisfied by each timestep from t=ATR_begin
to t=t_ready-1: [0408]All primary outputs have SDVs.; [0409]All
next-state outputs have SDVs.; [0410]The combining structure indicates
that HLM and RTLM are equivalent.

[0411]1.5.4. Fixed-Point Target (FPT)

[0412]The Fixed-Point Target (FPT) is a pattern of SDV assignment that, if
found at a timestep t=x1, where "x1" is any permissible timestep, and is
also found at a timestep t=x2, where "x2" is any permissible timestep
after "x1," it is known that a "steady-state" of SDV propagation has been
reached.

[0413]A suitable pattern of SDV assignment that can be recorded, as an FPT
of a timestep "t_ready," is as follows: [0414]For each signal of
RTLM_ts[tiready] and HLM_ts[t_ready], the correspondence between the
timestep-independent name of the signal and its SDV value.

[0415]1.5.5. Counter-Example Generation

[0416]Whenever the equivalence-determining process fails, counter-example
generation can be performed. With regard to FIG. 19, counter-example
generation can be performed at steps 4007 or 4015. For either of these
steps, a test can be performed to determine whether the failure to be
ready for a reencode is due to a combining structure, for one of the
timesteps from ATR_begin to ATR_end, indicating conditional equivalence
between the HLM and RTLM.

[0417]A CSts, of some timestep "t," indicates equivalence
conditionally if it has a CER "CS_CERs" which, if satisfied, would cause
CSts[t] to indicate equivalence between RTLMts[t] and
HLMts[t]. CS-CER should be a symbolic Boolean expression other than
logic "1."

[0418]The set of all symbolic Boolean variables, comprising CS_CER, can be
referred to as its "basis." Each setting, of the basis of CS_CER, for
which CSts[t] will not indicate equivalence, is a potential
counter-example. The basis can be set by assignment of Boolean values to
the primary inputs of both designs. Any such assignment of Boolean
values, that causes CS_CER to evaluate to "0," is a potential
counter-example.

[0419]A designer can use a potential counter-example in conjunction with,
for example, conventional simulation. The objective of the simulation is
to determine whether the potential counter-example is a real
counter-example that actually prevents a finding of equivalency between
the HLM and RTLM.

[0420]If simulation cannot show that a potential counter-example is a real
counter-example, the designer's conclusions can include the following:
the equivalence-determining system may have produced a "false negative"
(i.e., it may be that the HLM and RTLM are actually equivalent but the
equivalence-determining system was not able to prove this). The
possibility that a formal equivalence-determining system, in accordance
with the present invention, may produce a false negative is balanced by
the fact that, compared with conventional formal equivalence-determining
systems, much larger designs are tractable.

[0421]For the case of step 4017 of FIG. 19, all the combining structures
indicated equivalence, but the induction proof did not succeed. Thus, it
can only be concluded that the designs are equivalent up to the latest
timestep for which the combining structures indicated equivalence, but
equivalence for all times has not been proven.

[0424]Given the miter, comprised of RTLM_ts, HLM_ts and CS_ts,
equivalence_checking_with_CERs returns a TRUE if RTLM_ts is equivalent to
HLM_ts. In FIG. 1, procedure equivalence_checking_with_CERs corresponds
to equivalence determination process 1033.

[0425]2. HLM to DFG Conversion by Symbolic Simulation

[0426]2.1. Overview

[0427]The term "symbolic simulation," as utilized herein, refers to a
simulated execution of an input representation such that all possible
scenarios, for flow-of-control, are considered. The result is a
non-canonical data structure that explicitly represents the
flows-of-control considered.

[0428]As an example, the input representation, to be symbolically
simulated, can be a CFG. The CFG can be produced from an HLM, where the
HLM is expressed in a high-level programming language, such as C or C++.
The particular form of non-canonical data structure, produced by symbolic
simulation of the CFG, can be a DFG.

[0429]Each possible flow-of-control through the CFG can be represented by
a marker referred to herein as an "execution path." An execution path can
serve as a bridge, between the CFG and the DFG being produced, as
follows. In addition to marking a location with the CFG, an execution
path can include an expression referred to herein as a "path condition."
A path condition of an execution path "x" can express, in terms of
variables set by nodes of the DFG being produced, the condition under
which the CFG location (indicated by execution path "x") can be reached.

[0430]The initial value, of each variable of the CFG, can be represented
as an input to the DFG to be produced. Once symbolic simulation is
completed, these initial values can "flow through" the DFG and be
transformed, by operators of the DFG, to produce output values for HLM
variables.

[0431]Each possible flow of control through the CFG is encompassed within
the DFG produced by symbolic simulation. Depending upon the initial
values input to the DFG, data can flow through particular paths of the
DFG in order to produce the correct result.

[0432]An example CFG, that can be symbolically simulated, is shown in FIG.
3B. FIG. 3B can be produced from the example C or C++ code of FIG. 3A.

[0433]The symbolic simulation of FIG. 3B can begin with a DFG as shown in
FIG. 4A. FIG. 4A represents each initial value of the CFG as an input
node of the DFG to be produced. A non-canonical result, of symbolically
simulating FIG. 3B, is the DFG shown in FIG. 4G. The initial values ("a,"
"b" and "c") flow through FIG. 4G and result in producing the final
values (a', b' and c').

[0434]As can be seen, FIG. 4G encompasses each potential execution path of
FIG. 3B. For example, in FIG. 3B, if the initial value of "a" is not
zero, then none of initial values are changed. This execution scenario is
encompassed, in the DFG of FIG. 4G, by the initial value nodes simply
flowing, unchanged, to the final value nodes.

[0435]Under the scenario where "a" is equal to zero, two sub-scenarios are
possible: "b" is less than one or "b" is not less than one. If "b" is
less than one, than "c" is set to "5." If "b" is not less than one, than
"c" is set to "3." These two sub-scenarios are encompassed, within FIG.
4G, by the multiplexer that selects between "5" or "3" depending upon the
result of comparing "b" to "1." Regardless of the initial value of "b,"
"a" is set to the same value to which "c" is set. This is encompassed,
within FIG. 4G, by the multiplexer that drives final value "a" selecting
for the output of the multiplexer that selects between "5" or "3."

[0437]A key operation of any symbolic simulation is "splitting" an
existing execution path "x," into two execution paths "x_true" and
"x_false," when a conditional node "y" of a CFG is reached. Execution
path x_true handles the case where the conditional expression, of
conditional node "y," is satisfied. Execution path x_false handles the
case where the conditional expression, of conditional node "y," is not
satisfied. Symbolic execution fully explores both x_true and x_false so
that the resulting DFG can handle both cases. Another key operation of
symbolic simulation is "merging" two execution paths, "x_true" and
"x_false," into a re-combined execution path "x." Examples of splitting
and merging are discussed below with regard to the example production of
FIG. 4G.

[0438]2.2. Other Applications

[0439]The symbolic simulation techniques presented herein are discussed
primarily with respect to their application to the
equivalence-determining process presented herein. However, the symbolic
simulation techniques presented herein can be used in conjunction with
any application utilizing a non-canonical representation of an HLM. By
way of example only, and without limiting the range of potential
applications, non-canonical representations of an HLM can be useful with
other types of design analysis tools and with synthesis tools.

[0440]2.3. For HLM and RTLM Comparison

[0441]As discussed above, before an HLM and RTLM are compared, for
purposes of determining equivalence, both can be translated into the
common representation of a DFG.

[0442]This section describes a novel technique for converting an HLM into
an HLMDFG using symbolic simulation. In terms of the example overall
equivalence-determining system of FIG. 2B, this section addresses
techniques for implementing RTLM_2_DFG (line 5) and HLM_2_DFG (line 8).
However, an equivalence-determining system is just an example application
of the symbolic-simulation based conversion technique presented.

[0443]In the HLMDFG produced, a node can represent any of the
following: a primary input, a primary output, a combinational function
(including a multiplexer) or a register.

[0444]As discussed above, symbolic simulation can be applied to an HLM
described in any type of representation. For example, if the HLM is
described in a high-level programming language, such as C++, compilation
of the HLM can produce parse trees to which symbolic simulation can be
applied. The particular representation discussed in detail herein, for
application of symbolic simulation, is a control-flow graph (or CFG). A
CFG representing the HLM is referred to herein as HLMCFG. Conversion
of an HLM into a HLMCFG is well known and need not be described
herein.

[0445]A procedure for symbolic simulation, of an HLMCFG, is depicted
in the pseudo code of FIGS. 7A to 7F. FIGS. 7A to 7F are discussed below
in conjunction with the example HLMCFG of FIG. 3B.

[0446]The HLMCFG of FIG. 3B was produced from the example code of
FIG. 3A, where FIG. 3A is written in the C or C++ programming language.

[0447]Advantages of using a CFG representation of an HLM, upon which to
apply symbolic simulation, include the following. A CFG provides a common
representation to which HLMs, written in a variety of programming
languages, can be converted. A CFG can provide a simpler representation,
compared with the source HLM, upon which to apply symbolic simulation.
For example, the various types of control structures, present in the C or
C++ programming languages, can all be converted, in the CFG, to
appropriate conditional nodes.

[0448]An example HLMDFG, produced by application of the procedure of
FIG. 7A to the HLMCFG of FIG. 3B, is shown in FIG. 4G.

[0449]FIGS. 4A-4F depict earlier steps in the creation of the HLMDFG
of FIG. 4G. FIGS. 5A-5F depict intermediate data structures, used during
the DFG production process, referred to herein as "output-lists." During
the DFG generation process, each variable of the HLM has a corresponding
output-list. FIGS. 6A-6H depict different states of a queue, referred to
herein as an "execution path queue" or EP_queue, that can be used to
perform a breadth-first traversal of HLMCFG.

[0450]2.4. Initialization for CFG Traversal

[0451]Symbolic simulation can begin by producing a DFG representation for
initial values of the HLM variables (see FIG. 7A, line 1). Each initial
value can be represented by a node designated as representing a
particular variable of the HLM. Once the DFG is completed, these initial
values "flow through" the DFG and are transformed, by the operators of
the DFG, to produce output values for HLM variables.

[0453]Next, symbolic simulation can produce an intermediate
representation, for each HLM variable, that comprises elements of the CFG
and DFG. This intermediate representation is referred to herein as an
output-list representation for each HLM variable (see FIG. 7A, line 3).
The output-list can be comprised of elements, each referred to herein as
an "OL_element." OL_elements, of an output-list, are connected by an
implicit multiplexer that could implement, in a DFG, the function mapped
by the OL_elements. Each OL_element can be comprised of two parts, one of
which refers to the DFG and the other to the CFG. These two parts are
referred to herein, respectively, as a "DFG-pointer" and a "path
condition." A DFG-pointer can point to a particular node of HLMDFG.
A path condition can specify the conditions under which a particular
thread of control is executed in an HLMCFG. When the path condition
of an OL_element is satisfied, its HLM variable should have the value
produced by the HLMDFG node indicated by its DFG-pointer.

[0454]For the HLMCFG of FIG. 3B, FIG. 5A shows example, initial,
output-lists for variables "a," "b" and "c." To distinguish the initial
state of variables "a," "b" and "c," from their values as output by the
HLMDFG, the output-lists of FIG. 5A represent "a," "b" and "c" as
"primed" variables.

[0455]An output-list's support set can be defined as the union of the
support set for each path condition in each of its OL_elements.

[0456]Operations on an output-list can be structured to enforce that the
following conditions are true. For each combination of values, assigned
to an output-list's support set, only one path condition, of one
OL_element, is satisfied. For each combination of values, assigned to an
output-list's support set, at least one path condition, in one
OL_element, is satisfied.

[0457]A path condition can be represented in the following hybrid format
that uses both DFG and BDD representations. Each conditional expression,
of a CFG conditional node, can be converted into a DFG, referred to
herein as conditional_expressionDFG, that can be added to
HLMDFG. The output of conditional_expressionDFG can be
represented, in a path condition, by a variable. A path condition can be
a Boolean expression on such variables, where the expression can be
represented as a BDD.

[0458]The next step, in a symbolic simulation, can be to initialize a
queue of execution paths. (FIG. 7A, lines 5-7) An execution path can be
referred to herein as an "EP" and a queue of such EPs can be referred to
as an "EP_queue." Each EP can be comprised of a path condition and a
pointer to a node of HLMCFG to which such path condition applies.
The initial EP, on EP_queue, can be a path condition comprised of a logic
TRUE (since no conditions of the HLM need be evaluated to any particular
value for the path to be executed) and a pointer to the first node of
HLMCFG.

[0459]For the example of FIG. 3B, an initial EP_queue is shown in FIG. 6A.
In the EP_queues of FIGS. 6A-6H, EPs are inserted (or pushed) onto the
bottom of the queue and removed (or popped) from the top.

[0460]Using EP_queue to keep track, symbolic simulation can explore the
possible execution paths of HLMCFG in a breadth-first manner. Such
breadth-first traversal can be driven by a loop (FIG. 7A, lines 9-23)
that repeats until EP_queue is empty (tested for at FIG. 7A, line 9).

[0461]2.5. Loop for Breadth-First Traversal of CFG

[0462]For each iteration of the breadth-first search loop, four types of
conditions can be tested for. The four conditions are discussed below.

[0463]2.5.1. Two EPs Point to Same CFG Node

[0464]A first condition, that can be tested-for during a CFG traversal, is
whether two EPs, of EP_queue, point to the same node of HLMCFG (FIG.
7A, line 11). An example EP_queue, satisfying this first condition, is
shown in FIG. 6F, where both EPs point to node 114 of FIG. 3B. If the
first condition is satisfied, the following steps can be performed (see
FIG. 7B for the function "merge_EPs").

[0465]The two EPs pointing to the same CFG node, referred to herein as EP1
and EP2, can be removed from EP_queue (FIG. 7B, line 4). The contents of
EP_queue can be appropriately shifted to remove the "gaps" created by the
removal of EP1 and EP2.

[0466]An EP3 can be created (FIG. 7B, line 6) to replace EP1 and EP2. An
example EP3, created to replace the example EP1 and EP2 of FIG. 6F, is
shown in FIG. 6G. EP3 can point to the same node of HLMCFG as was
pointed to by EP1 and EP2. The path condition of EP3 can be the
simplified disjunction (FIG. 7B, lines 8-9) of the path conditions for
EP1 (referred to herein as "pc1") and EP2 (referred to herein as "pc2").
With pc1 and pc2 represented as BDDs, standard techniques can be used for
producing a simplified disjunction (referred to herein as "pc3"). For the
EP1 and EP2 of FIG. 6F, the disjunction is:

v1*v2+v1*-v2

which simplifies to:

[0467]v1

[0468]EP3 can be pushed onto EP queue (FIG. 7B, line 11).

[0469]If the support of pc3 is a proper subset of the union of the
supports of pc1 and pc2 (FIG. 7B, line 13) then, for certain HLM
variables, it may be possible to simplify their output-list by shifting
some of their path condition logic to HLMDFG. This can be determined
by calling (FIG. 7B, line 15) "construct_DFG." For the example EP3 of
FIG. 6G, the support of its pc3 is {v1}, while the union of the supports
of the pc1 and pc2, of FIG. 6F, is {v1, v2}.

[0470]construct_DFG can operate as follows (see FIG. 7B, lines 19-47). A
set, referred to herein as "IS_pc3," can be identified. IS_pc3 can
contain all OL_elements, of an HLM variable's output-list, whose path
conditions intersect pc3 (see FIG. 7B, lines 22-23). If IS_pc3 contains
more than one element (see FIG. 7B, line 25), it may be possible to merge
the path conditions of its OL_elements, while shifting their logic to
HLMDFG. Such operation can be invoked by calling a function
"merge_OL_elements" (FIG. 7B, line 29). For example, when EP_queue is in
the state shown in FIG. 6F, a corresponding state of the output-lists is
shown in FIG. 5C. Of HLM variables a', b' and c', only c' has OL_elements
(labeled 350 and 351 in FIG. 5C) that intersect with pc3 (i.e., intersect
with v1).

[0471]merge_OL_elements can operate as follows (see FIG. 7C). A nested ITE
expression can be constructed from the elements of IS_pc3 (see FIG. 7C,
line 6). The nested ITE can be any particular serialization of the
multiplexer implied between OL_elements. The ITE can be converted into an
MTBDD (FIG. 7C, line 8) which is then simplified (FIG. 7C, line 10). The
simplified MTBDD can be converted back into a simplified ITE expression
(FIG. 7C, line 12). The simplified ITE expression can be converted into a
group of multiplexers, "mpg_simp_ITE_IS_pc3," that are added to
HLMDFG. (FIG. 7C, lines 14-15). A pointer to the multiplexer group
can be returned (FIG. 7C, line 17).

[0472]Returning to construct_DFG, a new OL_element "OLE_new" can be
appended to the HLM variable's output-list. The path condition of OLE_new
is pc3 and its DFG-pointer points to the multiplexer group for IS_pc3.
FIG. 7B, lines 31-33. All OL_elements on the output-list, that are
members of IS_pc3, have their path conditions changed such that they do
not intersect with pc3 anymore. FIG. 7B, lines 35-36. Any OL_element on
the output-list that was completely contained in pc3, will get a path
condition of zero and should be removed from the output-list. Any
OL_element on the output-list that was only partially contained in pc3,
will get a non-zero path condition and should not be removed from the
output-list. FIG. 7B, lines 38-41.

[0473]In the example, an IS_pc3, for the output-list of HLM variable c' as
shown in FIG. 5C, comprises OL_elements 350 and 351. An ITE expression
for this IS_pc3 is as follows:

ITE(v1*v2, ptr1, ITE(v1*-v2, ptr2, DC))

Where "DC" is a "don't care." The resulting simplified ITE expression can
be:

[0475]FIG. 5D comprises an arrow 360. On the left side of arrow 360, the
following is shown. An OLE new is indicated by a numeral 352, that has
been appended to the list of FIG. 5C. OL_element 352 has a path condition
of pc3 (i.e., v1) and a pointer to mpg_simp_ITE_IS_pc3 (i.e., ptr3).
Changing the path condition of OL_element 350 such that it does not
intersect with pc3 (i.e., v1) can be achieved by computing
(v1*v2)*-pc3=v1*v2*-v1=0. Since the resulting path condition is zero,
OL_element 350 can be removed. Same applies to OL_element 351, leaving
only OL_elements 352 and 353. The removal of 350 and 351 is shown on the
right side of arrow 360.

[0476]2.5.2. Top EP Points to Conditional CFG Node

[0477]A second condition to be tested for, is whether the top EP points to
a conditional node (FIG. 7A, line 14). This condition is met by EP_queue
as shown in FIG. 6A (where EP 410 points to conditional statement 110 of
FIG. 3B) and FIG. 6B (where top EP 411 points to conditional statement
111 of FIG. 3B). If this condition is met, the following steps can be
performed (see FIG. 7D for the function split_EP").

[0478]A DFG can be produced, for HLMDFG, to perform the conditional
expression of the conditional node pointed to by the top EP (FIG. 7D,
line 4). For the EP 410 of FIG. 6A, the DFG produced for HLMDFG is
shown in FIG. 4B as comprising comparator node 210 and constant node 211.
For the EP 411 of FIG. 6B, the DFG produced for HLMDFG is shown in
FIG. 4C as comprising comparator node 212 and constant node 213.

[0479]A BDD variable, referred to herein as "vnew," can be created to
represent the value of the conditional expression (FIG. 7D, line 6). For
FIG. 4B, vnew is v1 while for FIG. 4C vnew is v2.

[0480]Two EPs, referred to herein as EP_if and EP_else, can be created.
EP_if's path condition can be pc*vnew and EP_else's path condition can be
pc*-vnew, where the path condition of the top EP is referred to herein as
"pc" (FIG. 7D, lines 8-9).

[0481]The top EP can be popped from EP_queue (FIG. 7D, line 10).

[0482]EP_if and EP_else can be pushed on EP_queue (FIG. 7D, line 12). The
EP_if and EP_else, created from the EP 410 of FIG. 6A, are shown in FIG.
6B as EPs 411 and 412. The EP_if and EP_else, created from the EP 411 of
FIG. 6B, are shown in FIG. 6C as EPs 413 and 414.

[0483]2.5.3. Top EP Points to Assignment CFG Node

[0484]A third condition to be tested for, is whether the top EP, referred
to herein as an "EP_top," points to an assignment node (tested for by
line 17 of FIG. 7A). This condition is met by EP_queue as shown in FIG.
6D (where EP 413 points to assignment statement 113 of FIG. 3B), FIG. 6E
(where top EP 414 points to assignment statement 112 of FIG. 3B) and FIG.
6G (where top EP 417 points to assignment statement 114 of FIG. 3B).
While FIG. 6F also has a top EP 415 that points to assignment statement
114, the first condition (that EP 415 and 416 point to the same CFG node)
can have a higher priority and application of the steps of the first
condition produce the EP_queue as shown in FIG. 6G. If the third
condition is met, the following steps can be performed (see FIG. 7E for
the function "process_and_advance_EP").

[0485]A function "merge_rhs" can be called (FIG. 7E, line 4) that adds an
output to HLMDFG that produces the value of the assignment
statement's right-hand side (rhs) and returns a pointer to such DFG
output. merge_rhs can operate as follows (see FIG. 7F).

[0486]A set, referred to herein as "rhs_HLM_vars," can be identified (FIG.
7F, line 4). rhs_HLM_vars is the set of HLM variables of the rhs of the
assignment pointed to by an EP_top. For assignment statements 113, 112
and 114, respectively, their rhs_HLM_vars can be: { }, { } and {c}.

[0487]For each variable "vcurr" of rhs_HLM_vars, the following can be done
(see FIG. 7F, lines 6-13. Construct a DFG from OL_elements of the
output-list for vcurr. The OL_elements used to construct the DFG are
those whose path condition intersect with the path condition of the top
EP (see call to "construct_DFG at line 10 of FIG. 7F). The DFG
constructed is added to the list "rhs_HLM_DFGs." FIG. 7F, line 12.

[0488]Produce a set referred to herein as "rhs_HLM_cons" (FIG. 7F, lines
15). rhs_HLM_cons is the set of HLM constants of the rhs of the
assignment. For assignment statements 113,112 and 114, respectively,
their rhs_HLM_cons can be: {5}, {3} and { }.

[0489]For each constant "ccurr" of rhs_HLM_cons, the following can be done
(see FIG. 7F, lines 17-23. Construct a node for HLMDFG to represent
the constant (FIG. 7F, lines 19-20). The DFG node constructed is added to
the list "rhs_HLM_DFGs." FIG. 7F, line 22.

[0490]When assignment statement 113 is the top EP, as shown in FIG. 6D,
HLMDFG is in the state shown in FIG. 4C and the output-lists are in
the state shown in FIG. 5A. A node 220, to represent the constant 5, can
be added as shown in FIG. 4D. This node can be added to rhs_HLM_DFGs.

[0491]When assignment statement 112 is the top EP, as shown in FIG. 6E,
HLMDFG is in the state shown in FIG. 4D and the output-lists are in
the state shown in FIG. 5B. A node 221, to represent the constant 3, can
be added as shown in FIG. 4E. This node can be added to rhs_HLM_DFGs.

[0492]When assignment statement 114 is the top EP, as shown in FIG. 6G,
HLMDFG is in the state shown in FIG. 4F and the output-lists are in
the state shown in FIG. 5D. Since this assignment statement has no
constant on its rhs, no constant-representing node is added.

[0493]From rhs_HLM_DFGs, as applied through any operators of rhs, produce
a DFG for HLMDFG referred to herein as rhs_DFG (FIG. 7F, lines
25-27).

[0494]For assignment statement 113, since it has no rhs operators, rhs_DFG
is just node 220 (as shown, for example, in FIG. 4D), pointed to by ptrl,
that represents a constant "5."

[0495]For assignment statement 112, since it has no rhs operators, rhs_DFG
is just node 221 (as shown, for example, in FIG. 4E), pointed to by ptr2,
that represents a constant "3."

[0496]For assignment statement 114, since it has no rhs operators, rhs_DFG
is just multiplexer 250 (as shown, for example, in FIG. 4F), pointed to
by ptr3.

[0497]Return a pointer to rhs_DFG (FIG. 7F, line 29).

[0498]For assignment statements 113, 112 and 114, respectively, the
pointer returned is ptr1, ptr2 and ptr3.

[0499]Returning to process_and_advance_EP, write to the output-list, for
the variable of the Ihs of assignment, an OL_element, LE1, comprised of
the path condition of EP_top and a DFG-pointer whose value is that of
ptr2_rhs_DFG (FIG. 7E, lines 6-8). Insure that elements of output-list of
Ihs variable, other than LE1, cover, and only cover, complementary path
conditions to those covered by LE1's path condition (FIG. 7E, lines
10-11).

[0500]For assignment statement 113, LE1 is shown as OL_element 350 of FIG.
5B. OL_element 310, of FIG. 5A, is not complementary to OL_element 350.
In FIG. 5B, it is replaced by OL_element 311, which covers, and only
covers, the complementary path conditions to those covered by OL_element
350. The complementary relationship of 350 and 311 is illustrated in FIG.
5B by truth table 361.

[0501]For assignment statement 112, LE1 is shown as OL_element 351 of FIG.
5C. OL_element 311, of FIG. 5B, is not complementary to OL_element 351.
In FIG. 5C, it is altered to be complementary to 351, as well as to 350.
The complementary relationship of 350, 311 and 351 is illustrated in FIG.
5C by truth table 362.

[0502]For assignment statement 114, LE1 is shown as OL_element 354 of FIG.
5E. OL_element 313, however, is not complementary to OL_element 354. In
FIG. 5F, it is replaced by OL_element 355.

[0503]Advance EP_top to next node of HLMCFG (FIG. 7E, lines 13). Pop
EP_top from top of EP_queue (FIG. 7E, line 15) and push EP_top back on
EP_queue (FIG. 7E, lines 17).

[0504]For assignment statement 113, EP 413 (the EP_top at that time), of
FIG. 6D, is advanced to node 114 and pushed back onto EP_queue in FIG. 6E
as EP 415.

[0505]For assignment statement 112, EP 414 (the EP_top at that time), of
FIG. 6E, is advanced to node 114 and pushed back onto EP_queue in FIG. 6F
as EP 416.

[0506]For assignment statement 114, EP 417 (the EP_top at that time), of
FIG. 6G, is advanced to the END node and pushed back onto EP_queue in
FIG. 6H as EP 418.

[0507]2.5.4. Top EP Points to END CFG Node

[0508]A fourth condition to be tested for is whether the top EP points to
an END node (tested for by line 20 of FIG. 7A). If this condition is met,
the top EP is popped from EP_queue (FIG. 7A, line 21). When all EP's have
been thus popped from EP_queue, traversal of HLMDFG has been
completed.

[0509]The "else" condition of conditional statement 110 points to the END
node, as indicated by EP 412 that is added in FIG. 6B. In FIG. 6C, EP 412
is the top EP and is therefore popped from EP_queue.

[0510]After assignment statement 114 has been processed, the current EP
(EP 418) points to the END node, as indicated in FIG. 6H. EP 418 is
popped from EP_queue, emptying it, and thereby ending the loop.

[0511]2.6. Post-CFG-Traversal Processing

[0512]Once the CFG-traversal loop has completed, an HLMDFG, that
produces a value for each HLM variable, is created as follows.

[0513]For each HLM variable, convert the remaining elements, of its
output-list representation, into a DFG that is added to HLMDFG (see
FIG. 7A, lines 25-27). This can be accomplished by the following steps. A
nested ITE expression can be constructed from the OL_elements of the
output-list. The nested ITE can be any particular serialization of the
multiplexer implied between OL_elements. The ITE can be converted into a
MTBDD which is then simplified. The simplified MTBDD can be converted
back into a simplified ITE expression. The simplified ITE expression can
be converted into a group of multiplexers that are added to HLMDFG.

[0514]For the example, FIG. 5F shows the output-lists once the
CFG-traversal loop has completed.

[0515]An ITE expression for the output-list of HLM variable "a," shown in
FIG. 5F as comprising OL-elements 355 and 354, is as follows:

ITE(-v1, a, ITE(v1, ptr3, DC))

Where "DC" is a "don't care." The resulting simplified ITE expression can
be:

ITE(v1, ptr3, a)

[0516]The simplified ITE can be converted into multiplexer 260 of FIG. 4G.

[0518]An ITE expression for the output-list of HLM variable "c," shown in
FIG. 5F as comprising OL_elements 352 and 353, is as follows:

ITE(-v1, c, ITE(v1, ptr3, DC))

Where "DC" is a "don't care." The resulting simplified ITE expression can
be:

ITE(v1, ptr3, c)

[0519]The simplified ITE can be converted into multiplexer 261 of FIG. 4G.

[0520]2.7. Handling Loops During Symbolic Simulation

[0521]Loops are implicitly unrolled during symbolic simulation. If
symbolic simulation is being done with a CFG, all loop types in the CFG
(e.g., "for" loops, "while" loops, "do-while" loops) are reduced to
if-nodes (or conditional-nodes) and nodes with backward edges (i.e.,
nodes from which a traversal can be made to a node closer to the starting
point of the CFG).

[0522]The conditional-node that checks the loop condition generates two
execution paths in symbolic simulation: one execution path that does a
next loop iteration and another execution path that exits the loop.
Without additional measures, this generation of two execution paths means
there will be an execution path that executes the loop forever. In
general, however, a meaningful loop eventually terminates. Thus, in many
cases, it is possible to determine the maximum number of times a loop can
be executed.

[0523]An approach to accomplishing this is to call a "decision procedure"
every time the loop condition is evaluated. The decision procedure can
try to determine if the last iteration of the loop has been reached or if
the loop can be executed at least once more. Since the exact symbolic
expression for the loop condition is stored in the DFG, any existing
proof technique (e.g., any theorem prover, based on BDDs or SAT) can be
utilized for this purpose. If it can be proven that the loop will not be
executed again, under any circumstances, the execution path, for
repeating the loop, can be destroyed.

[0524]Although an advantage of symbolic simulation is that it allows proof
procedures to be embedded, while the DFG is being constructed, it can
also be computationally costly to perform a proof every loop cycle. As a
solution, symbolic simulation can be restricted to application of
efficient decision procedures for such embedded proofs.

[0525]For example, a type of decision procedure, referred to herein as
"constant propagation decision procedure," can be used. With a constant
propagation decision procedure, nodes in the DFG whose operands are all
constants can be replaced, on-the-fly, by their constant result. While a
constant propagation decision procedure can only handle relatively simple
loop types, these types can be sufficient for analysis of a broad range
of hardware designs.

[0526]Example loop types that can be handled by a constant propagation
decision procedure include the following: a loop with constant bounds, a
set of nested loops where the number of iterations of the inner loop is
bounded by the outer loop) and a loop that starts at a symbolic offset
but has a fixed number of iterations. An example, of each of these loops
types, follows.

[0529]The following is an example of a suitable loop that starts at a
symbolic offset:

for (int i=start; i<start+7; i++){ . . . }

[0530]For the above example loop, with a symbolic starting offset, an
approach to determining a constant propagation decision procedure can be
as follows.

[0531]In the first iteration, the loop condition checked is:
"start<start+7." In the second iteration, the loop condition checked
is: start+1<start+7." In the third iteration, the loop condition
checked is: start+2<start+7." Generalizing from these three instances,
it can be readily determined that a decision rule that can be applied to
determine if these loop conditions are true is as follows:

(start+c1)<(start+c2) is true if c1<c2

[0532]where c1 and c2 are constants

[0533]From the above decision rule, it can be seen that the value of
"start" is unnecessary for determining whether the loop condition is
satisfied. To decide the loop condition, knowing just the constants c1
and c2 is sufficient. This decision rule is valid for unbounded-width
integers. For fixed width integers there is a possibility of overflow: if
one side of the comparison does overflow but the other side does not, the
above decision rule is no longer true.

[0534]An approach, to handling fixed width integers, is to assume that no
overflow occurs on either side and to generate special constraint nodes
in the DFG which assert that no overflow happens. A proof that the
special constraint nodes are never violated can then be deferred until
later in the overall process in which the production of the DFG is being
used. For example, if DFG production by symbolic simulation is being used
as part of an equivalence-determining system, a proof that the special
constraint nodes are never violated can be deferred until an
equivalence-determining procedure is applied.

[0535]2.8. Optimization: Global Priority Scheduling

[0536]2.8.1. Overview

[0537]The order in which execution paths are pushed-on or popped-off the
EP_queue can have a significant impact on the efficiency of symbolic
simulation and on the quality of the constructed DFG. In general,
execution paths which are split in (e.g., by FIG. 7A, line 15) should be
merged again as soon as possible (e.g., by FIG. 7A, line 12). This goal
can be achieved by sorting the execution paths in the queue of EPs used
for symbolic simulation, appropriately.

[0538]As a preprocessing step, to applying symbolic simulation to a CFG,
the nodes of the CFG can each be given a priority that determines when
they are traversed during symbolic simulation. EPs that point to nodes
with a higher priority can be traversed before EPs pointing to lower
priority nodes.

[0539]The priorities can be computed, for example, before invoking the
algorithm of FIG. 7A. Then, during symbolic simulation (such as that
shown by FIG. 7A), EPs on the queue of EPs can be sorted according to
their priority. For example, EPs can be sorted in descending order, with
the highest priority EP at the queue's output position and the lowest
priority EP at the queue's input position. A higher priority can be
represented by a numerically higher value. The priority of an EP is
equivalent to the priority of the CFG node it points to. EPs with higher
priority (pointing to higher priority CFG nodes) are popped before EPs
with lower priority.

[0540]With global priority scheduling enabled, pushing an execution path
on EP_queue does not always result in inserting an EP at the input
position of the queue, but can, for example, result in inserting the EP
at the middle of the queue at a location where its priority fits the
descending ordering.

[0541]Two major goals of prioritization are as follows: [0542](i) a node
with more than one incoming edge should receive a lower priority than its
predecessors (where the set of predecessors to a node "x" is comprised of
each node "y" that has a directed edge to "x"); and [0543](ii) a node
within a cycle "x" should receive a higher priority than an exit node of
the cycle (where an exit node is a node outside the cycle that can be
traversed-to from a node of cycle "x").

[0544]Goal (i) ensures that an EP arriving at a CFG node with more than
one incoming edge will wait at that node until EPs arrive from the other
incoming edges. Goal (ii) ensures that any EP exiting a cycle wait at the
cycle's exit node for EPs still in the cycle. Then, where there are
multiple EPs waiting at the same node, the EPs can be automatically
merged (e.g., see merge_EPs( ) at line 12 of FIG. 7A). Occasionally,
goals (i) and (ii) cannot be achieved for all nodes at the same time. In
that case, the presented heuristic tries to achieve them for as many
nodes as possible.

[0545]FIG. 8A shows an example CFG to which prioritization can be applied.
Nodes of FIG. 8A with more than one exiting edge (nodes 611, 613, 614,
616) are conditional nodes. Conditional nodes can be used to form loops.
For example, node 611 can perpetuate a loop between itself and node 612,
or node 611 can branch to node 613. Node 613 can either branch to node
614, thereby starting the loop body comprised of 613, 614 and 616, or
node 613 can branch to node 616, thereby performing the loop body
comprised of 613 and 616.

[0546]FIG. 8Q shows priorities, assigned to the CFG of FIG. 8A, in
accordance with the above two major goals (an example process, for
getting from FIG. 8A to FIG. 8Q is discussed below in connection with the
pseudo-code of FIGS. 9A-9B). The two major goals of prioritization are
satisfied in FIG. 8Q as follows.

[0547]Nodes with more than one incoming edge are: 611 (with predecessor
610), 613 (with predecessor 611) and 616 (with predecessors 613 and 614).
As can be seen, the node with more than one incoming edge has a lower
priority than its predecessors. A first cycle is comprised of nodes 611
and 612, having an exit node of 613 (node 613 is the exit node since it
is the first node led to, by a node in the first cycle, that is not
inside the cycle). A second cycle is comprised of nodes 613 and 616,
having an exit node of 614 (node 614 is the exit node since it is the
first node led to, by a node in the second cycle, that is not inside the
cycle). A third cycle is comprised of nodes 613, 614 and 616, having an
exit node of 615. As can be seen, the exit node of the third cycle (613,
614, 616) as well as the exit node of the first cycle (611, 612) have
lower priorities than the nodes in the respective cycles. For the second
cycle (613, 616), exit node 614 cannot have a lower priority than any
node in the cycle without violating goal (i) for node 616.

[0548]2.8.2. Prioritization Pseudo-Code

[0549]FIGS. 9A-9B show pseudo-code for assigning priorities as part of a
preprocessing step to symbolic simulation. The main function is
"computePriorities" (see FIG. 9A) which calls "adjustPredecessors" (see
FIG. 9B). A summary, of the operation of computePriorities and
adjustPredecessors, follows. The END node, of the CFG to be prioritized,
is assigned a lowest priority of "1". The heuristic search then works its
way backward through the CFG. First, an attempt is made to assign
priorities to all nodes whose successors already have a valid priority
(FIG. 9A, line 12). If that is not possible (because there is at least
one successor that has not been processed yet), all nodes on
CFG_traversal_queue must be on a cycle in the CFG (FIG. 9A, line 30). In
order to fulfill goal (ii), the first node on the queue is assigned a
higher priority than that of any other node in the CFG (FIG. 9A, line
42). This automatically ensures that nodes within the cycle get higher
priorities than any of the cycle-exit nodes. These steps are iterated
until all nodes have been processed.

[0550]To achieve goal (i), the priorities of predecessor nodes are
adjusted (FIG. 9B, line 13). To avoid cycles in the computation, those
nodes are additionally marked as done. Nodes with a single incoming edge
are not marked (FIG. 9B, line 5). This has the effect that priority
changes on these nodes don't stop there but are allowed to propagate
further.

[0551]A step-by-step discussion, of the pseudo-code of FIGS. 9A-9B, is as
follows.

[0552]2.8.2.1. computePriorities

[0553]computePriorities can begin by assigning a priority of "1" to the
END node of the CFG to which it is applied (FIG. 9A, line 3).

[0554]Next, computePriorities can push the predecessors of the END node on
a queue (FIG. 9A, line 4).

[0555]The loop of computePriorities can be started, and continued, so long
as the queue "CFG_traversal_queue" is not empty (FIG. 9A, line 6).

[0556]The loop begins each iteration by setting a current node "curr_node"
to the resulting of popping CFG_traversal_queue (FIG. 9A, line 8).

[0557]Up to three tests can then be performed. A first "if" (line 10) can
test whether the current node is marked "DONE." A second "if" (line 12)
can test whether all successors of the current node already have
priorities assigned. A third "if" (line 30) can test whether all nodes on
CFG_traversal queue are marked as "WAITING."

[0558]If the first "if" is satisfied if the current node has been fully
processed, and no action is taken in the current iteration.

[0559]If the second "if" is satisfied, the following steps can be taken
(FIG. 9A, lines 13-20). If the current node has not yet been assigned a
priority, then the current node is assigned a priority equal to the
maximum priority assigned to any of its successors. Next,
adjustPredecessors can be called. Third, the predecessors to the current
node can be pushed onto CFG_traversal_queue.

[0560]If the second "if" is not satisfied, the following steps can be
taken (FIG. 9A, lines 23-28). The current node can be marked as
"WAITING." The current node can be pushed onto CFG_traversal_queue.

[0561]If the third "if" is satisfied, the following steps can be taken
(FIG. 9A, lines 31-45). The current node can be set to the top node of
CFG_traversal_queue. All nodes marked WAITING can be unmarked. The
current node can be set to a priority one greater than the priority
assigned to any other node. adjustPredecessors can be called. The
predecessors to the current node can be pushed onto CFG_traversal_queue.

[0562]2.8.2.2. adjustPredecessors

[0563]adjustPredecessors can operate as follows.

[0564]The predecessors to the current node, referred to as
"preds_curr_node," can be found (FIG. 9B, line 3).

[0565]Up to two tests can then be done. A first "if" (FIG. 9B, lines 5-7)
can be satisfied if: current node has only one predecessor, the one
predecessor to current node already has a priority assigned and the one
predecessor to current node is not marked "DONE." A second "if" (FIG. 9B,
line 13) can be satisfied if the current node has more than one incoming
edge.

[0566]If the first "if" is satisfied, the following action can be taken
(FIG. 9B, lines 8-11): the one predecessor to the current node can be set
to a priority that is the maximum of the predecessor's priority and the
current node's priority.

[0567]If the second "if" is satisfied, the following steps can be taken
(FIG. 9B, lines 14-20). Each predecessor to the current node can be set
to a priority that is the maximum of the predecessor's priority and one
plus the current node's priority. The current node can be marked "DONE."

[0568]2.8.3. Example Prioritization

[0569]FIGS. 8B-8Q depict how the procedure of FIGS. 9A-9B can be applied,
step-by-step, to FIG. 8A.

[0570]computePriorities assigning a value of one to the END node (see FIG.
9A, line 3) is shown in FIG. 8B by node 615 being assigned a priority of
one.

[0571]computePriorities pushing the predecessors to the END node on
CFG_traversal_queue (FIG. 9A, line 4) is shown in FIG. 8C by predecessor
node 614 being on a CFG_traversal_queue that is in a state 650.

[0572]Each iteration, of the "while" loop of computePriorities, is
described as follows.

[0573]2.8.3.1. First Iteration

[0574]Current node is set to 614 (by line 8 of FIG. 9A). The "if" of line
12 of FIG. 9A is not satisfied by node 614. Node 614 is marked as
"WAITING" (see FIG. 8D) and is pushed back on CFG_traversal_queue. The
resulting state for the CFG_traversal_queue is shown as a state 651 in
FIG. 8D.

[0575]In state 651 all nodes on CFG_traversal_queue are waiting. Node 614
is unmarked as WAITING (see FIG. 8E). Node 614 is assigned a priority one
greater than the priority of node 615 (see FIG. 8E). adjustPredecessors
performs no operations, since neither of its "if" statements are
satisfied. The predecessor to node 614 is pushed onto CFG_traversal_queue
and the resulting state of CFG_traversal_queue shown in FIG. 8E as state
652.

[0576]2.8.3.2. Second Iteration

[0577]curr_node is 613. Since all successors to node 613 are not assigned
priorities, node 613 is marked as "WAITING" (see FIG. 8F). Also, node 613
is pushed back onto CFG_traversal_queue, resulting in a state for
CFG_traversal_queue shown in FIG. 8F as state 653.

[0578]In state 653 all nodes on CFG_traversal_queue are waiting. Node 613
is unmarked as WAITING (see FIG. 8G). Node 613 is assigned a priority one
greater than the priority of node 614 (see FIG. 8G). Since 613 has more
than one incoming edge, adjustPredecessors adjusts each predecessor to
node 613 to have a priority of 4 (see FIG. 8G). adjustPredecessors also
marks node 613 as "DONE" (see FIG. 8G). The predecessors to node 613
(nodes 616 and 611) are pushed onto CFG_traversal_queue and the resulting
state of CFG_traversal_queue is shown in FIG. 8G as state 654.

2.8.3.3. Third Iteration

[0579]curr_node is 616. Since all of node 616's successors have been
assigned priorities and 616 has a priority, adjustPredecessors (FIG. 9A,
line 18) is executed. Since node 616 has more than one incoming edge,
each predecessor to 616 (nodes 613 and 614) is set to one-plus the
priority of node 616 and node 616 is marked DONE (see FIG. 8H). When the
call to adjustPredecessors returns, the predecessors to node 616 are
pushed on CFG_traversal-queue (FIG. 9A, line 19). The resulting state for
CFG_traversal_queue is shown in FIG. 8H as state 655.

[0580]2.8.3.4. Fourth Iteration

[0581]curr_node is 611. Since all of 611's successors do not have
priorities, mark 611 as WAITING and push back on queue. The resulting
state for CFG_traversalqueue is shown in FIG. 8I as state 656.

[0582]2.8.3.5. Fifth Iteration

[0583]curr_node is 613. Since 613 is already DONE, just pop it (line 10 of
FIG. 9A is executed). The resulting state for CFG_traversal_queue is
shown in FIG. 8J as state 657.

[0584]2.8.3.6. Sixth Iteration

[0585]curr_node is 614. Since all of node 614's successors already have
priorities, and since 614 already has a priority, adjustPredecessors
(FIG. 9A, line 18) is executed. However, adjustPredecessors performs no
operation. When the call to adjustPredecessors returns, the predecessors
to node 614 are pushed on CFG_traversal_queue (FIG. 9A, line 19). The
resulting state for CFG_traversal_queue is shown in FIG. 8K as state 658.

[0586]2.8.3.7. Seventh Iteration

[0587]curr_node is 611. Since all of node 611's successors do not have
priorities, push node 611 back on CFG_traversal_queue. The resulting
state for CFG_traversal_queue is shown in FIG. 8L as state 659.

[0588]2.8.3.8. Eighth Iteration

[0589]curr_node is 613. Since 613 is already DONE, just pop it (line 10 of
FIG. 9A is executed). The resulting state for CFG_traversal_queue is
shown in FIG. 8M as state 660.

[0590]2.8.3.9. Ninth Iteration

[0591]curr_node is 611. Since all successors to node 611 do not already
have priorities, the "else" of FIG. 9A, lines 23-28 is executed but
achieves no net change to the state of FIG. 8M.

[0592]Since all nodes on queue are waiting, pop node 611 (see FIG. 9A,
line 40), unmark node 611 from its state of WAITING and set node 611's
priority to one-plus the maximum priority assigned to all nodes. The
resulting state for the CFG is shown in FIG. 8N.

[0593]adjustPredecessors is called (see FIG. 9A, line 43). It sets the
predecessors to node 611, nodes 610 and 612, to one-plus the priority of
611 and marks 611 as "DONE."

[0594]When the call to adjustPredecessors returns, nodes 610 and 612 are
pushed on CFG_traversal_queue.

[0595]The resulting state for CFG_traversal_queue is shown in FIG. 8P as
state 661.

[0596]2.8.3.10. Tenth Iteration

[0597]curr_node is 610. The net result of executing computePriorities is
to pop node 610. The resulting state for CFG_traversal_queue is shown in
FIG. 8Q as state 662.

[0598]2.8.3.11. Eleventh Iteration

[0599]curr_node is 612. The net result of executing computePriorities is
to pop node 612 and to push node 611. The resulting state for
CFG_traversal queue is not shown.

[0600]2.8.3.12. Twelfth Iteration

[0601]curr_node is 611. Since node 611 is DONE, it is simply popped and
CFG_traversal_queue is then empty.

[0602]2.9. Other Optimizations

[0603]In generating the representation of the DFG, identical subgraphs can
be shared. For example, nodes of the DFG can be stored in a hash-table.
Identical nodes with identical operands can be detected in the hash-table
and shared. With this optimization, determining the equality of two
structurally identical DFGs becomes simple.

[0604]When a new DFG node is created, the symbolic expression upon which
it is based can be checked against a collection of re-write rules. Three
example re-write rules are as follows:

aaa (1)

ite(a, ite(b, c, d), d)ite(a b, c, d) (2)

(vector>>5) & 0xfextract(vector, 5, 4) (3)

[0605]For re-write rules in the above format, a match of the left side of
the rule causes the rule to "fire." The portion of the symbolic
expression, that matches the left side of the rule, is replaced by the
right side of the rule.

[0606]Example (1) is an example of using a re-write rule to perform
simplification of Boolean expressions.

[0607]Example (2) is an example of using a re-write rule to perform
simplification of ITE expressions.

[0608]Example (3) is an example of using a re-write rule to perform
simplification of hardware-oriented programming language expressions. In
particular, the left side of example (3) is a programming technique of
C++ for extracting a range of bits from a bitvector. The particular
example shown extracts 4 bits from the vector starting at bit 5. The
re-write rule replaces the hardware-oriented programming language
expression with an explicit expression of the hardware functionality
desired. In the particular example, the left side of the re-write rule is
substituted with an explicit range extraction expression. The
substitution of a more explicit expression permits the resulting DFG to
be more explicit, which can not only simplify the DFG but aid subsequent
synthesis or verification.

[0609]3. The Timestep Form

[0610]As discussed above, prior to applying an SDV-propagation process,
the miter can be converted into timestep form.

[0611]An example DFG, for conversion into the timestep form, is shown in
FIG. 10A. The sequential DFG of FIG. 10A is comprised of three registers
R1, R2 and R3. It is also comprised of a primary input "i" and a primary
output "o." Registers R1, R2 and R3 each have an input R1IN,
R2IN and R3IN. Registers R1, R2 and R3 each have an output
R1OUT, R2OUT and R3OUT. When the DFG of FIG. 10A is
converted into timestep form, all of the following names can be used as
timestep-independent names: R1, R2, R3, "i," "o," R1IN, R2IN,
R3IN, R1OUT, R2OUT, and R3OUT.

[0612]FIG. 10B shows a conversion of the DFG of FIG. 10A into the timestep
form. FIG. 10B depicts two example timesteps: a timestep 4120 on the left
side of dividing line 4110 at some time t=x and a timestep 4130 on the
right side of dividing line 4110 at some time t=x+1. As can be seen,
timesteps 4120 and 4130 have the same timestep-independent names.

[0613]Each timestep of FIG. 10B is identical, except for its position
relative to other timesteps. In order to construct the timestep, each
register of FIG. 10A is divided into two parts: a part that drives the
present-state input to a timestep that comprises a register's output and
part that accepts the next-state output of a timestep that comprises a
register's input. An example present-state input 4121 is shown as driven
by a register output, of timestep 4120, that has timestep-independent
name "R1OUT." An example next-state output 4122 is shown as driving
a register input, of timestep 4120, that has timestep-independent name
"R1IN."

[0614]Further, the present-state inputs and the next-state outputs of each
timestep have been arranged such that successive timesteps can be coupled
by simply arranging them in a linear sequence.

[0615]Production of the timestep form used herein is well-known in the
art, and any suitable technique for production of the timestep form can
be used in conjunction with the inventive techniques described herein.

[0616]4. Test Bench Generation

[0617]As discussed above, test bench generation relates to producing a DFG
in timestep form, referred to herein as a "combining structure" (or
CSts), for combining RTLMts and HLMts in a way that
permits the resulting timestep, referred to herein as a "miter" timestep,
to be tested for equivalence. A timestep "t" of a miter (MTts[t])
can be comprised of the following DFGs: RTLMts[t], HLMts[t] and
CSts[t].

[0618]A process for accomplishing the combination of DFGs can be
summarized as follows. Each RTLMts and HLMts can each be
classified, individually, based on structural criteria. The
classification assigned is referred to herein as a "DFG class." Based
upon the DFG class of RTLMts and HLMts, a structure CSts
for combining the two DFGs can be selected. Such selection of a combining
structure can be viewed as applying the DFG class of RTLMts and the
DFG class of HLMts to a two-dimensional decision matrix. The
selected combining structure can be constructed by drawing upon a library
of DFG building blocks.

[0619]As discussed above, the CSts produced can be designed to have a
"q" output with the following property: "q," for a timestep t, is TRUE if
and only if RTLMts[t] and HLMts[t] are equivalent. Once the
CSts has been produced, the miter timestep can be processed, for
identification of control and datapath nodes, prior to application of an
equivalence-determining procedure.

[0620]While the above-described process, for the selection of CSts,
assumes RTLMts and HLMts each belong to only one DFG class,
this is not necessarily the case. To address this situation, for each
pair of corresponding primary outputs, from RTLMts and HLMts,
each primary output can be put into a DFG class to form a DFG class pair.
This can be accomplished by applying the below-described classification
techniques, to RTLMts and HLMts, on a
primary-output-by-primary-output basis. If all such pairs, of a DFG class
for an output of RTLMts with a DFG class for a corresponding output
of HLMts, are the same, one type of miter can be generated for which
equivalence determination is applied once.

[0621]However, if more than one type of pairing of DFG classes is
identified, an appropriate miter can be generated for each different type
of DFG class pair found. An equivalence-determining procedure can be
applied to each miter. RTLMts and HLMts have been proven to be
equivalent only if all such equivalence-determining tests are successful.

[0622]4.1. Classifying RTLMts and HLMts

[0623]Each DFG can be classified based upon a structural analysis. The
types of DFG classes can include: combinational, pipelined, handshaking
and unknown. Methods for testing a DFG, as to whether it belongs to each
of the DFG classes, are presented below. The below methods share the
common goal of trying to determine how many prior cycles of input data
can affect the result of a computation. For example, a property that can
be tested for, in the below methods, is whether a DFG has sequential
cycles. Another property that can be tested for is the number of
registers that need to be traced back through before reaching a primary
input.

[0624]4.1.1. Combinational

[0625]Whether a DFG is of DFG class "combinational" can be determined as
follows. For each primary output find its transitive fanin. If there are
no register-outputs in each such transitive fanin, the output can be
classified as combinational.

[0626]A pseudo-code implementation, of the test for combinationality, is
shown in FIG. 11.

[0627]FIG. 11, lines 1-5, presents a loop that iterates over each primary
output node, referring to each such node as "o" (line 1). For each node
"o," its transitive fanin list ("tfi_list") is initially set to empty
(line 2). Then, the procedure "traverseFanin" is called (line 3) to find
the transitive fanin of node "o."

[0628]FIG. 11, lines 8-19, presents the procedure traverseFanin.
traverseFanin is a recursive procedure, where each invocation of
traverseFanin begins at a node "n" (see parameter list of line 11).
traverseFanin iterates over each input "i" of node "n" (line 13),
recursively calling traverseFanin. If node "n" itself is a primary input
or the output of a register, it is added to the transitive fanin list.

[0629]Once the loop of FIG. 11, lines 1-5, is complete, another loop can
iterate over each primary output or register input node, examining the
transitive fanin list for each (that has been generated by the
pseudo-code of FIG. 11). If none of these transitive fanin lists contain
a register output node, the DFG can be classified as combinational.

[0630]4.1.2. Pipelined

[0631]A DFG primary output is of DFG class "pipelined" if that output is
only affected by input-data in a finite number of previous cycles.
Another way of stating this requirement is that the output must not
depend on a cycle of registers.

[0632]Within the pipelined classification, there are the following three
types of circuits. First, circuits where only a single input data affects
the result of each computation. Second, circuits where input data over
several cycles affects the result of each computation, as long as each
input data only effects the output for a finite number of cycles. Third,
circuits where input data can effect an output for an indefinite number
of cycles, but such data is written into a memory. In this case, the user
must specify where the memories in the DFG are located.

[0633]Detecting register cycles can be achieved by a depth-first traversal
of the DFG starting at the primary outputs. If a register is encountered
that has already been visited before, then a cycle has been detected.

[0634]Furthermore, for non-cyclic paths, it can be useful to count the
number of pipeline stages. This is the number of registers on a path
between a primary output and a primary input. If there are multiple
paths, from an output to its inputs, with different numbers of pipeline
stages, the lengths of all such paths can be stored.

[0635]An example pseudo-code implementation, for accomplishing the
just-above-described traversal of a DFG, is shown in FIG. 12.

[0636]FIG. 12, lines 2-10, presents a loop that iterates over each primary
output ("o") of the DFG (line 2). For each output "o," the procedure
"computeRegistersOnPath" is called (line 5). computeRegistersOnPath
returns a "false" if a cycle is found, and otherwise returns a list in
its parameter "path_list." Each item of path list" is comprised of two
values: the name of a primary input "i," and the number of registers
between "o" and "i."

[0637]FIG. 12, lines 16-39, present a pseudo-code implementation for
computeRegistersOnPath. computeRegistersOnPath begins by finding the
transitive fanin of the output "o" passed to it (where "o" is referred
to, within computeRegistersOnPath, as "n"). Specifically, at line 19 of
FIG. 12, a call is issued to "tfi_list(n)." For each element of the
transitive fanin that is a primary input or register-output (i.e., a
"present-state output" in timestep form terminology), it is iterated by
and assigned to "i." FIG. 12, line 19.

[0638]A test is performed to determine whether "i" is a primary input or
the output of a register that has been declared by the user to be a
memory. FIG. 12, line 20. As discussed below in section 4.2.3
("Pipelined") if there is a memory mapping between the memories of the
designs to be compared, the outputs of memories can be treated as primary
inputs. If the test is satisfied, an element is added to the result list,
returned by computeRegistersOnPath, comprised of the primary input "i"
and the number of registers between "i" and the primary output (node
"n"). FIG. 12, line 21.

[0639]If the test of line 20 is not satisfied, the "else" of lines 22 to
36 is performed. When performing the "else" it is known that "i" is a
register output of a register that has not been declared a memory. If "i"
has already been visited, a register cycle is detected and
computeRegistersOnPath returns a FALSE. FIG. 12, lines 26-29. Otherwise,
"i" is added to the list of visited registers. FIG. 12, line 30. The
corresponding register input "rin" for "i" is obtained. FIG. 12, line 31.
computeRegistersOnPath recursively calls itself, using "rin" as the
"primary output" from which it searches. FIG. 12, lines 32-33. If the
recursive call to computeRegistersOnPath returns FALSE, then the calling
instance of computeRegistersOnPath returns FALSE as well. FIG. 12, lines
32-35.

[0640]4.1.3. Handshaking

[0641]A primary output falls under the DFG classification "handshaking" if
a user specified a handshaking protocol for the output. Handshaking can
be identified on an output by providing the user with a pre-defined
library of handshaking protocols (e.g., request-busy or request-busy-next
protocols) in terms of which the DFG can be defined.

[0642]Once an output of an RTLMts or HLMts has been defined as
handshaking, it can generally be assumed that all its inputs are
handshaking.

[0643]DFGs that do not use handshaking, but do require a variable number
of cycles to perform their operation, can be handled by classifying them
as handshaking.

[0644]4.1.4. Unknown

[0645]A DFG output is classified as "unknown" if it does not meet any
other classifications.

[0646]4.2. Combining Structure Selection

[0647]Based on the DFG class for RTLMts and the DFG class for
HLMts, an appropriate structure, for combining the two DFGs to
produce MTts, can be selected. A decision matrix can be used. An
example decision matrix is shown in FIG. 17. As can be seen, the decision
matrix takes as input a pair of DFG classifications "1" and "2." The
output of the decision matrix is one of five categories of combining
structure: combinational, cycle-accurate, pipelined, stream-based and
error. The mapping of a pair of DFG classifications to a category is, for
the particular example decision matrix, independent of the ordering of
the two input DFG classes.

[0648]Each of the five categories of combining structure is discussed
below.

[0649]4.2.1. Combinational

[0650]The combinational combining structure can be applied when both DFGs
are classified as combinational.

[0651]A combinational combining structure can be created as follows (see
FIG. 13).

[0652]A DFG 2310 represents HLMts and a DFG 2311 represents
RTLMts. Corresponding inputs of 2310 and 2311 are connected
together. Corresponding outputs of 2310 and 2311 are input to a
comparator, such as comparator 2312.

[0653]During formal equivalence proving, a task can be proving that the
output of a comparator, such as output 2320 of comparator 2312, is
equivalent to a logic "1" (represented, in FIG. 13, as being provided at
an "output" 2321).

[0654]4.2.2. Cycle-Accurate

[0655]The cycle-accurate combining structure can be applied when either
DFG is classified as unknown. The cycle-accurate combining structure can
be preferred under these circumstances since it produces a "strong" form
of equivalence testing that will not produce a false positive. On the
other hand, because the cycle-accurate combining structure produces a
MTts that is so restrictive as to the conditions under which
equivalence between HLMts and RTLMts can be found, it can
produce a false negative where a "weaker" equivalence test might be able
to show the DFGs are equivalent. Therefore, while the cycle-accurate
combining structure is a suitable default, it can also be desirable to
allow the user to select another combining structure that produces a
weaker test for equivalence.

[0656]The cycle-accurate combining structure produces an equivalence test
where both DFGs must produce exactly the same output on every clock cycle
in order for equivalence to be found.

[0657]A cycle-accurate combining structure can be created as follows (see
FIG. 14).

[0658]A DFG 2410 represents HLMts and a DFG 2411 represents
RTLMts. Corresponding inputs of 2410 and 2411 are connected together
(and thus RTLMts and HLMts are applied the same input vector
each clock cycle). Corresponding outputs of 2410 and 2411 are input to a
comparator, such as comparator 2412. Additional clocking logic 2431 and
reset logic 2430 is added.

[0659]During formal equivalence proving, a task can be proving that the
output 2420 of comparator 2412 is equivalent to a logic "1" (represented
in FIG. 14 by an "output" 2421).

[0660]4.2.3. Pipelined

[0661]The pipelined combining structure can be applied under the following
circumstances: both DFGs are classified as pipelined, one DFG is
classified as combinational and the other is classified as pipelined. If
one of the DFGs is classified as combinational, it can be converted into
a one-stage pipeline.

[0662]The approach of a pipelined combining structure is to effectively
modify one or both of the DFGs such that a cycle-accurate equivalence
test can be performed.

[0663]A pipelined combining structure can be created as follows (see FIG.
15).

[0664]A DFG 2510 represents HLMts and a DFG 2511 represents
RTLMts. Corresponding inputs of 2510 and 2511 are connected together
(and thus RTLMts and HLMts are applied the same input vector
each clock cycle). Corresponding outputs of 2510 and 2511 are input to a
comparator, such as comparator 2512. Additional clocking logic 2531 and
reset logic 2530 is added.

[0665]In addition, if the number of pipeline stages are not the same in
both designs, pipeline-equalizing (or "dummy") registers (e.g., registers
2540 and 2541) are inserted at the outputs of the design with fewer
pipeline stages.

[0666]Counting the number of pipeline stages of each design can be
accomplished by utilizing the analysis performed (discussed above) by
which one or both DFGs were classified as DFG class "pipelined."

[0667]Such counting can be performed according to one of three different
methods, the three methods referred to as "a," "b" or "c."

[0668]Whether method "a," "b" or "c" is applicable can be expressed in
terms of whether certain conditions, referred to as conditions (i), (ii)
and (iii), are true or false.

[0669]Condition (i) is that there are no memories in the DFG.

[0670]Condition (ii) is that, for each pair (o, i) of a primary output and
primary input, all paths between them cross the same number of registers.

[0671]Condition (iii) is that, in addition to condition (ii) being true,
the number of registers according to condition (ii), between each pair
(o, i) of a primary output and primary input, are all equal to the same
value.

[0672]Counting method "a" determines the number of pipeline stages, to
represent a DFG, by counting the number of pipeline stages from any
primary output to any primary input. Counting method "a" can be used if
conditions (i), (ii) and (iii) are true.

[0673]Counting method "b" determines the number of pipeline stages, to
represent a DFG, by counting the (o, i) pair with the greatest register
count. Counting method "b" can be used if conditions (i) and (ii) are
true, but condition (iii) is false.

[0674]Counting method "c" determines the number of pipeline stages, to
represent a DFG, by counting the (o, i) pair with the greatest register
count that does not pass through a memory. Counting method "c" can be
used if condition (ii) is true, but conditions (i) and (iii) are false.

[0675]In order to prove equivalence between two DFGs that use memories,
there must exist a memory mapping between the memories of both designs.
That the memory mapping holds for all times can be shown by an up-front
check that, for both DFGs, shows the same data is always written to the
same location in each memory.

[0676]If such equality of memory mapping is found, then the memories can
be effectively eliminated from the versions of the DFGs, used to
construct MTts, as follows. In constructing the pipelined combining
structure, the output nodes of the memories in the DFGs are treated as
primary inputs. Just as with actual primary inputs, in the MTts, the
corresponding memory output nodes of each DFG are connected together.

[0677]If the same type of equality of memory mapping can be shown between
registers in the two DFGs, then such registers can also be effectively
eliminated, from the versions of the DFGs used to construct MTts, by
treating their output nodes as primary inputs.

[0678]4.2.4. Stream-Based

[0679]4.2.4.1. Overview

[0680]The stream-based combining structure is applicable when both
RTLMts and HLMts have been put into the DFG class
"handshaking."

[0681]Stream-based equivalence, if proven, can be characterized as
follows. First, both RTLMts and HLMts receive the same stream
of input data, but not necessarily at the same time. Second, both
RTLMts and HLMts generate the same output data, but not
necessarily at the same time. Phrased another way, stream-based
equivalence means there are no constraints on the relative timing of the
inputs or outputs of RTLMts and HLMts, however, data packets
produced by the two DFGs should be produced in the same order.

[0682]An overall method, by which a stream-based combining structure can
be used, is as follows. First, create two sub-miters. Each sub-miter is
comprised of an instance of RTLMts, HLMts and the stream-based
combining structure CS_STREAMts. Second, if both sub-miters find
equivalency, on a cycle-accurate basis, then RTLMts and HLMts
are equivalent on a stream-accurate basis.

[0683]Each sub-miter is constructed as follows.

[0684]For a first sub-miter, RTLMts is tested for equivalence with
HLMts under conditions that correspond to RTLMts operating at
"full speed." Put differently, every time RTLMts can accept a set of
data inputs, it is able to do so. HLMts is tested for equivalence
with RTLMts under conditions that constrain its inputs to be the
same as whatever RTLMts indicates it is able to accept. Thus the
first sub-miter determines equivalence between a fully exercised
RTLMts and a HLMts limited to those inputs that exercise
RTLMts.

[0685]If the result of comparing RTLMts to HLMts is successful,
then it is known that for any inputs acceptable by RTLMts,
HLMts will produce stream-equivalent output. However, it is still
not known whether, for the "full" range of inputs acceptable to
HLMts, if RTLMts can produce stream-equivalent outputs. This is
accomplished by reversing the roles of RTLMts and HLMts in the
second sub-miter.

[0686]Put more symbolically, it is first shown by the first sub-miter that
the set of outputs (or SOO) of RTLMts (or SOO(RTLMts)) is a
subset of the SOO of HLMts (or SOO(HLMts)). Put in mathematical
relation form:

SOO(RTLMts).OR right.SOO(HLMts)

[0687]By reversing the roles of RTLMts and HLMts, the second
sub-miter can show that:

SOO(HLMts).OR right.SOO(RTLMts)

[0688]The only way both relations can be true is if the following is true:

SOO(HLMts)=SOO(RTLMts)

[0689]An example stream-based combining structure, suitable for
constructing the first and second sub-miters, is depicted in FIG. 16A. In
discussing HLMDFG and RTLMDFG, with regard to the first and
second sub-miters, each is referred to as either DFG 2623 and DFG 2624.
To construct the first sub-miter, in accordance with FIG. 16A, DFG 2623
and DFG 2624 refer to, respectively, RTLMDFG and HLMDFG. To
construct the second sub-miter, in accordance with FIG. 16A, DFG 2623 and
DFG 2624 refer to, respectively, HLMDFG and RTLMDFG.

[0690]Since the first and second sub-miters can be constructed in an
identical way, except for the roles of RTLMDFG and HLMDFG being
reversed, the below will just address construction of the first
sub-miter.

[0691]4.2.4.2. Input of Data to RTLMts and HLMts DFGs

[0692]The first sub-miter is constructed to allow DFG 2623 to process data
as soon as it is able to, while not guaranteeing the same for DFG 2624.
This can be achieved by implementing the following process in the
sub-miter (which is depicted in FIG. 16B):

[0693](i) Until DFG 2623 is able to accept its next packet, DFG 2624 is
not asked to accept its next packet. In FIG. 16B, this is depicted by
step 2650 inhibiting requests to DFG 2624 and by decision point 2651
looping back to itself until DFG 2623 accepts its next packet.

[0694](ii) When DFG 2623 accepts its next packet (decision point 2651
follows the "yes" branch to step 2652 and decision point 2653), if DFG
2624 is not able to accept its next packet at that time (decision point
2653 follows the "no" branch), the clock to DFG 2623 is switched off (see
step 2654), "freezing" the state of DFG 2623. Once DFG 2624 accepts its
next packet (decision point 2653 follows the "yes" branch), the clock to
DFG 2623 is switched back on (see step 2655), and the process loops back
to step (i).

[0695]FIG. 16A depicts two example handshaking inputs for each of DFG 2623
and 2624: a first handshaking input comprised of connection ports labeled
"A" and "B," and a second handshaking input comprised of connection ports
labeled "C" and "D." The dashed box around ports "A" and "B," and the
other dashed box around ports "C" and "D," represent handshaking protocol
interfaces. The packets accepted by the first and second handshaking
inputs can be of any length, depending on the design of DFGs 2623 and
2624.

[0697]Counterpart handshaking protocol interfaces 2610, 2611, 2612 and
2613 can be controlled by synchronization logic 2635 through its
connection ports 2618, 2619, 2621 and 2620. Synchronization logic 2635
can also control whether clock 2629 is applied to DFG 2623 by controlling
AND gate 2626. AND gate 2626 is controlled by output 2622 of
synchronization logic 2635.

[0698]Reset logic 2628 can be responsible for putting DFGs 2623 and 2624
into an initial state. Clock unit 2629 can be responsible for providing
clock signals to DFGs 2623 and 2624.

[0699]Regarding the above-described process (for allowing DFG 2623 to
process data as soon as it is able to, while not guaranteeing the same
for DFG 2624), it can be described, in terms of the particular units of
FIG. 16A, as follows:

[0700](i) Until a handshaking input to DFG 2623 indicates its acceptance
of its next packet, the corresponding handshaking input to DFG 2624 is
not asked to accept its next packet. This can be accomplished by
synchronization logic 2635 as follows. For a particular handshaking
protocol interface of DFG 2623, synchronization logic 2635 can detect
whether it has accepted its next packet. If the handshaking protocol
interface of DFG 2623 has not accepted, then synchronization logic 2635
can cause the corresponding counterpart handshaking protocol interface,
for DFG 2624, to not request a packet acceptance of DFG 2624.

[0701](ii) When a handshaking input to DFG 2623 has accepted its next
packet, if the corresponding handshaking input to DFG 2624 is not able to
accept its next packet at that time, the clock to DFG 2623 is switched
off, "freezing" the state of DFG 2623. Once the handshaking input to DFG
2624 has accepted its next packet, the clock to DFG 2623 is switched back
on, and the same process loops back to step (i). This can be accomplished
by synchronization logic 2635 as follows. Once synchronization logic 2635
has detected that a handshaking input to DFG 2623 has accepted its next
packet, synchronization logic 2635 then tests whether the corresponding
handshaking input, to DFG 2624, has either accepted, or is able to
accept, the next packet. If synchronization logic 2635 determines that
the handshaking input to DFG 2624 has not accepted, or is not able to
accept, its next packet, synchronization logic 2635 can switch off the
clock input to DFG 2623 by lowering its output 2622. Synchronization
logic 2635 presents the packet to the handshaking input of DFG 2624 until
it has been accepted. No packets are presented to the other handshaking
inputs of DFG 2624 during this time. When synchronization logic 2635
subsequently determines that the handshaking input to DFG 2624 has
accepted its next packet, synchronization logic 2635 can switch on the
clock input to DFG 2623.

[0702]4.2.4.3. Output of Data from RTLM and HLM DFGs

[0703]DFGs 2623 and 2624 can produce their output packets at different
times. A FIFO can be used to store outputs such that they can be
compared. In the following discussion, data enters at the "tail" of a
FIFO and exits at the "head" of the FIFO.

[0704]A FIFO controller can have states called "DFG 2623 ahead," "DFG 2624
ahead" and "neither DFG ahead." Based upon the current FIFO controller
state, and whether the latest packet to be output is from DFG 2623 or DFG
2624, the FIFO controller can operate as follows.

[0705]This paragraph addresses the case where the state is "neither DFG
ahead." If a packet from DFG 2623 is produced, then it is pushed on the
FIFO and the state changes to "DFG 2623 ahead." If a packet from DFG 2624
is produced, then it is pushed on the FIFO and the state changes to "DFG
2624 ahead."

[0706]This paragraph addresses the case where the state is "DFG 2623
ahead." If a packet from DFG 2623 is produced, then it is pushed on the
FIFO and the state remains "DFG 2623 ahead." If a packet from DFG 2624 is
produced, then it is compared with the packet at the head of the FIFO and
the head of the FIFO is popped. If, as a result of the pop, the FIFO is
empty, the state becomes "neither DFG ahead."

[0707]This paragraph addresses the case where the state is "DFG 2624
ahead." If a packet from DFG 2624 is produced, then it is pushed on the
FIFO and the state remains "DFG 2624 ahead." If a packet from DFG 2623 is
produced, then it is compared with the packet at the head of the FIFO and
the head of the FIFO is popped. If, as a result of the pop, the FIFO is
empty, the state becomes "neither DFG ahead."

[0708]A handshaking output, of DFGs 2623 and 2624, is represented by two
connection ports labeled "E" and "F." The dashed box around ports "E" and
"F" represents a handshaking protocol interface. A counterpart
handshaking protocol interface, to model an appropriate environment for
DFG 2623, is labeled 2625. A counterpart handshaking protocol interface,
to model an appropriate environment for DFG 2624, is labeled 2627.

[0709]FIG. 16A represents the FIFO as a FIFO 2631. FIFO 2631 is controlled
by a FIFO controller unit 2630 that receives data packets via counterpart
handshaking protocol interfaces 2625 and 2627. Elements of FIFO 2631 are
compared with a latest output packet, from either DFG 2623 or 2624 as
appropriate, by a comparison unit 2632. Comparison unit 2632 can produce
a signal representative of a logical "1," at its output 2633, when the
comparison finds equality between the compared output packets.

[0710]A more detailed view, of an example operation of a FIFO controller,
is shown in FIG. 16C. When first beginning to compare the outputs of DFG
2623 and 2624, the result of the comparisons can be initialized to TRUE
(step 2660). Waiting for a next packet at step 2661 can correspond to the
state, discussed above, of "neither DFG ahead." Steps 2680-2685 can
correspond to being in the state "DFG 2624 ahead." Steps 2670-2675 can
correspond to being in the state "DFG 2623 ahead."

[0711]Starting from step 2661, when a next (or first) packet arrives, it
is tested by decision point 2662 for whether the packet is from DFG 2623
or 2624. If the packet is from DFG 2623, the "yes" branch of 2662 is
followed to steps 2670-2675. If the packet is not from DFG 2623, then it
is from DFG 2624 and the "no" branch of 2662 is followed to steps
2680-2685.

[0712]Steps 2670-2675 operate as follows. The packet from DFG 2623 is
pushed on the FIFO (step 2670). The FIFO controller waits for a next
packet (step 2671). When a next packet arrives, it is tested by decision
point 2672. If the next packet is from DFG 2623, it is simply pushed on
the FIFO (step 2670). If the next packet is from DFG 2624, it is tested
by decision point 2673. If the FIFO head is not equal to the latest
packet from DFG 2624, the result of the comparisons can be set to FALSE
(step 2663) and the FIFO controller process can end. If the FIFO head is
equal to the latest packet from DFG 2624, the FIFO head can be popped
(step 2674) and the state of the FIFO can be tested by decision point
2675. If the FIFO is empty, the "state" of "neither DFG ahead" can be
returned to by branching to step 2661. If the FIFO is not empty, the
"state" of "DFG 2623 ahead" can be remained in by branching to step 2671.

[0713]Steps 2680-2685 operate in the same fashion as steps 2670-2675,
except that steps 2680-2685 operate upon a FIFO containing packets from
DFG 2624 and compares those FIFO packets to packets from DFG 2623.

[0714]4.2.4.4. Other Applications

[0715]The stream-based combining structure, presented herein, can be used
in conjunction with any formal analysis tool. The stream-based combining
structure, presented herein, can be used without the step of classifying
the first and second designs that it couples.

[0716]When the stream-based combining structure is used without the step
of classification, any appropriate representation can be used for the
stream-based combining structure and for the first and second designs to
be coupled. For the first and second designs to be coupled, each can be
treated as a "black box," with just information on its inputs and outputs
provided.

[0717]4.2.5. Error

[0718]The error combining structure can be applied if it is not known, for
the classifications of the two DFGs, what combining structure, if any,
should be applied. This can occur when one DFG is classified as
handshaking and the other DFG is classified as other than handshaking.

[0719]Under such circumstances, the user can be allowed to specify a
suitable combining structure.

[0720]4.3. Generating the Test Bench

[0721]4.3.1. Overview

[0722]Once a combining structure has been selected, MTts can be
generated as follows.

[0723]The selected combining structure can first be generated in a
hardware description language (HDL) such as Verilog HDL. Within such HDL
description, HLMts and RTLMts can be coupled-to as "black
boxes." In this way, the two DFGs do not need to be converted into the
HDL. The resulting initial text bench, since it uses both HDL and DFG
representation, can be referred to as MTts/HDL.

[0724]Once the complete MTts/HDL has been produced, just the parts
expressed in an HDL can be converted into a DFG representation in order
to produce the MTts to which equivalence proving can be applied.

[0725]4.3.2. Reset Logic

[0726]Rather than extracting an initial state for RTLM or HLM, as
described below in section 5 ("Initialization Of The Miter Timestep"),
and transferring such initial state to MTts, reset logic can be
added to MTts.

[0727]To the extent such reset logic is "run," in order to determine
initial state, operation of MTts can be disabled during the first
few timesteps (or cycles) of MTts operation.

[0728]For the case where reset logic is used to determine an initial state
for both RTLMts and for HLMts, the portion of the combining
structure, that checks for whether the data produced by the two DFGs is
equivalent, can be disabled. For example, when comparing two DFGs
classified as pipelined, with unknown initial states, if the results of
the first few cycles of MTts are not ignored, it may not be possible
to prove equivalence.

[0729]For the case where reset logic is used to determine an initial state
for RTLMts, but partial execution of the HLM is used to determine
the initial state for HLMts (as in below section 5 "Initialization
Of The Miter Timestep"), clocking to HLMts can be disabled during
the first few cycles of MTts operation. By disabling the clock to
HLMts, the state assigned to HLMts can be maintained while
RTLMts proceeds through a reset sequence.

[0730]Conversely, for the case where reset logic is used to determine an
initial state for HLMts, but partial execution of the RTLM is used
to determine the initial state for RTLMts (as in below section 5
"Initialization Of The Miter Timestep"), clocking to RTLMts can be
disabled during the first few cycles of MTts operation. By disabling
the clock to RTLMts, the state assigned to RTLMts can be
maintained while HLMts proceeds through a reset sequence.

[0731]4.3.3. Clocking Logic

[0732]During formal equivalence verification of MTts, it can be
assumed there is only a single implicit clock.

[0733]If there are multiple clocks in HLMts and RTLMts, these
can be removed by preprocessing the DFG prior to formal equivalence
verification. The preprocessing can simplify the multiple clocks by
deriving a single, "common-denominator," clock rate. Each clock of the
DFG is then expressed as a multiple of such common-denominator clock
rate.

[0734]Such simplification can be done after MTts has been generated.

[0735]4.3.4. Use of Libraries

[0736]The combining structure can be constructed from a library of HDL
building blocks. Such a library can include building blocks that perform
the following functions: reset-sequence generation, different
clocking-schemes, different handshaking protocols or different kinds of
FIFOs.

[0737]The library approach can make it easier for the user to create
customized combining structures. For example, a user can add her or his
own building blocks to the library and then swap, for certain building
blocks of a pre-existing combining structure, newly added building
blocks.

[0738]The library approach can also make it easier for the user to create
entirely new combining structures, either from building blocks of an
existing library or from newly-added building blocks.

[0739]4.4. Other Applications

[0740]The techniques of test bench generation presented herein are
discussed primarily with respect to combining DFGs of an RTLM and HLM,
for purposes of applying the equivalence determination process described
herein. However, the test bench generation techniques presented herein
can be used for combining any first DFG and second DFG, regardless of the
source from which the first and second DFGs are derived. The resulting
combination, of first DFG, second DFG and combining structure, can be
used in conjunction with any formal analysis technique.

[0741]Furthermore, the test bench generation techniques presented herein
can be used for combining a first and second design, where the first and
second designs are not specified as DFGs. The step of classifying each of
the first and second designs, in order to determine the applicable
combining structure, only requires that the first and second designs be
expressed in a representation that provides the necessary structural
information. By way of example, a netlist representation could be used
instead of a DFG representation.

[0742]5. Initialization of the Miter Timestep

[0743]As discussed above, in order to compare RTLMts and HLMts
for potential equivalency, they may need to be set to equivalent initial
states. A pseudo-code procedure, for setting RTLMts and HLMts
to equivalent initial states, was introduced above as
"initialize_initial_timestep." A more detailed discussion, of techniques
for implementing initialize_initial_timestep, is presented in this
section and explained in conjunction with FIG. 18A.

[0744]First, suitable initial states of RTLM and HLM, for initializing
RTLMts and HLMts, can be determined. Determining a suitable
initial state for the RTLM is represented in FIG. 18A by steps 1110-1111.
Determining a suitable initial state for the HLM is represented in FIG.
18A by steps 1120-1122. This determination of suitable initial states is
addressed in the below sub-sections 5.1 ("Initializing RTLM") and 5.2
("Initializing HLM").

[0745]Second, whenever both RTLM and HLM are ready (indicated in FIG. 18A
by synchronization point 1125), the initial states for RTLM and HLM can
be translated into appropriate initial values for RTLMts and
HLMts. This translation into appropriate initial values is
represented in FIG. 18A by steps 1126-1129, and is addressed in the below
sub-section 5.3 ("Translation To Initial Timestep").

[0746]5.1. Initializing RTLM

[0747]An initial state for RTLM, suitable for use in setting the initial
states of RTLMts and HLMts, can be determined as follows. A
reset signal of the RTLM can be asserted (step 1110). The RTLM is
simulated, using any appropriate known simulator, until it reaches an
initial state as specified by the user (step 1111).

[0748]5.2. Initializing HLM

[0749]For an HLM that is compiled, its initial state can be determined by
the following process.

[0750]Before partially executing the HLM, the user can provide information
(step 1120) on the location within the HLM (e.g., a function or
line-number) where the initialization phase is finished, and a breakpoint
can be set at the location.

[0751]An HLM written in a compiled language (such as C or C++) can be
compiled such that debugging information is available (step 1121).
Debugging information, in a compiled executable, can be used to extract
the values of program variables of the HLM when it stopped at the
breakpoint. For example, debugging information can include a function,
referred to herein as "program variable mapping function," that maps a
program variable name to a location in memory where the program
variable's value is stored.

[0752]An operating system process, under which the HLM runs, can be
created.

[0753]For an HLM that is run with a dynamic (or run-time) linker,
operating system libraries used by the HLM can be linked-to at run-time.
At the time of such library linking, rather than linking the HLM's
typical run-time library, a special "Interceptor Library" can be linked
to.

[0754]An Interceptor Library is so-called because it can intercept
operating system calls the HLM might make, such as those related to
memory allocation, memory reallocation or memory deallocation. For the C
and C++ programming languages, such operating system calls include:
"malloc," "realloc" and "free." Malloc allocates a dynamic block of
memory. Free frees a dynamic block of memory. Realloc allocates a larger
dynamic block of memory for a dynamic block of memory that has already
been allocated. The already-allocated block is copied into the
newly-allocated block.

[0755]The Interceptor Library functions can call the actual functions of
the applicable operating system. Before returning, the Interceptor
Library functions can record, for post run-time use, information about
the currently allocated memory blocks. Information recorded can include a
pointer to an allocated memory block and the size of an allocated memory
block.

[0756]The HLM can be run until the breakpoint is reached (step 1122), at
which point it is in an appropriate initial state to be used for setting
the initial states of RTLMts and HLMts. Because the HLM was
executed with debugging information enabled, and with the Interceptor
Library substituted for certain operating system procedures, the
following information is available for the process of setting RTLMts
and HLMts to initial states.

[0757]To extract the state of program variables as of the time the
breakpoint occurred, the program variable mapping function can be used.
To extract the state of program variables that serve as pointers, as of
the time the breakpoint occurred, the following process can be used. The
program variable mapping function can be used to extract the pointer
address. Information stored by the Interceptor Library procedures can be
used to determine the allocated memory block corresponding to such
pointer address. For example, Interceptor Library procedures can store
the begin and end addresses of allocated memory blocks. If a pointer of
the HLM points to an address within the begin and end addresses of an
allocated memory block, then that memory block's values can be used for
initialization of RTLMts and HLMts.

[0758]For an HLM run on an interpreter, the following modifications, to
the above-described approach for compiled HLMs, can be employed. The
mechanism for setting a breakpoint can then be replaced by a procedure,
in the interpreter, that stops interpretation at a specified line number.
The functionality of the Interceptor Library can be integrated into the
procedures that implement the interpreter, which procedures can save
information on the allocation of memory blocks. Extraction of variable
values can be accomplished by accessing internal data-structures of the
interpreter and, where appropriate, using the saved memory block
allocation information.

[0759]5.3. Translation to Initial Timestep

[0760]Once initial states for RTLM and HLM are available (i.e.,
synchronization point 1125 has been reached), their values can be
translated into appropriate initial values, for the initial timesteps of
RTLMts and HLMts, as follows.

[0761]Datapath present-state nodes, of MTts, can be initialized as
follows (step 1126).

[0762]For each datapath present-state node of RTLMts,
"dp_ps_RTLM_ts," its corresponding value in the RTLM, "dp_ps_RTLM," can
be sought. For each datapath present-state node of HLMts,
"dp_ps_HLM_ts," its corresponding value in the HLM, "dp_ps_HLM," can be
sought.

[0763]dp_ps_RTLM can be determined from dp_ps_RTLM_ts by any suitable
known means. For example, the timestep-independent name of dp_ps_RTLM_ts
can be used to locate dp_ps_RTLM.

[0764]dp_ps_HLM can be determined from dp_ps_HLM_ts as follows. For
ordinary program variables, the timestep-independent name of dp_ps_HLM_ts
can be used with the program variable mapping function to map to a
location in memory where dp_ps_HLM is stored. For a pointer variables,
the location in memory, found with the program variable mapping function,
is a pointer to a location inside a block of memory. Using the pointer
value, in conjunction with information stored by the Interceptor Library,
the memory block pointed to can be identified. The contents of the memory
block identified can then be the dp_ps_HLM.

[0765]A set of datapath present-state nodes, "DP_PS_TS," can be defined to
contain all nodes of type dp_ps_RTLM_ts or dp_ps_HLM_ts that have a
corresponding model value, where corresponding model value is defined as
follows. For each member of DP_PS_TS, where the member is of type
dp_ps_RTLM_ts, its corresponding model value is dp_ps_RTLM, and where the
member is of type dp_ps_HLM_ts its corresponding model value is
dp_ps_HLM.

[0766]DP_PS_TS can be divided into subsets, where each subset has the
following property: all members have the same corresponding model value.
Each subset "x" of DP_PS_TS can be assigned a unique integer SDV "y."
Each member of a subset "x," in MTts, can have its SDV initialized
to "y." If a subset "x" of DP_PS_TS contains only one member, then that
member is initialized to a unique integer SDV, with respect to the SDV
initializations provided to all other datapath present-state nodes of
MTts.

[0767]Control present-state nodes, of MTts, can be initialized as
follows (step 1127).

[0768]For each control present-state node of RTLMts, "ct_ps_RTLM_ts,"
its corresponding value in the RTLM, "ct_ps_RTLM," can be sought. For
each control present-state node of HLMts, "ct_ps_HLM_ts," its
corresponding value in the HLM, "ct_ps_HLM," can be sought. Determining
ct_ps_RTLM from ct_ps_RTLM_ts can be found in the same manner, discussed
above, for finding dp_ps_RTLM from dp_ps_RTLM_ts. Determining ct_ps_HLM
from ct_ps_HLM_ts can be found in the same manner, discussed above, for
finding dp_ps_HLM from dp_ps_HLM_ts.

[0769]Each ct_ps_RTLM_ts can be initialized to a symbolic Boolean value
that directly represents its corresponding ct_ps_RTLM. For example, if
the ct_ps_RTLM for a ct_ps_RTLM_ts is a logic "1," then ct_ps_RTLM_ts can
be initialized to the symbolic Boolean value "1[0]." The index, of the
symbolic Boolean value "1[0]," is added to indicate that the logic "1"
was assigned to the node ct_ps_RTLM_ts in the initial timestep zero. As
another example, if the ct_ps_RTLM for a ct_ps_RTLM_ts is a logic "0,"
then ct_ps_RTLM_ts can be initialized to the symbolic Boolean value
"0[0]."

[0770]In the same manner, each ct_ps_HLM_ts can be initialized to a
symbolic Boolean value that directly represents its corresponding
ct_ps_HLM.

[0771]Datapath primary input nodes, of MTts, can be initialized as
follows (step 1128). Pairs of corresponding datapath primary input nodes,
from RTLMts and HLMts, can be found. The member of each pair
from RTLMts can be referred to as "dp_pi_RTLM_ts" and the member of
each pair from HLMts can be referred to as "dp_pi_HLM_ts."
dp_pi_RTLM_ts and dp_pi_HLM_ts can form a corresponding pair of nodes if
they share the same timestep-independent name. dp_pi_RTLM_ts and
dp_pi_HLM_ts can be assigned a common integer SDV.

[0772]Control primary input nodes, of MTts, can be initialized as
follows (step 1129). Pairs of corresponding control primary input nodes,
from RTLMts and HLMts, can be found. The member of each pair
from RTLMts can be referred to as "ct_pi_RTLM_ts" and the member of
each pair from HLMts can be referred to as "ct_pi_HLM_ts."
ct_pi_RTLM_ts and ct_pi_HLM_ts can form a corresponding pair of nodes if
they share the same timestep-independent name. ct_pi_RTLM_ts and
ct_pi_HLM_ts can be assigned a common symbolic Boolean variable.

[0773]With regard to initializing the primary input nodes, both control
and datapath, this can be accomplished in the pseudo-code by
"initialize_timestep_inputs" rather than being included with
"initialize_initial_timestep."

[0774]5.4. Example

[0775]FIG. 18B presents an example initialization of the control and
datapath present-state inputs for an initial timestep.

[0776]The initial timestep is comprised of the following: HLM_ts 1230,
CS_ts 1201 and RTLM_ts 1240. Together, these three components for an
initial miter. It is assumed that the initial time is zero.

[0777]Internal components of CS_ts 1201 are not shown.

[0778]HLM_ts 1230 is comprised of the following. There is a control
section, comprised of a present-state input with timestep-independent
name "Q1." Q1 is input to a block of control logic 1231, whose internal
components are not shown. Internal components of control logic 1231 can
include logic gates and TFs. Control logic 1231 produces a next-state
output with timestep-independent name "D1." Elements of the control
section are drawn in dashed form.

[0779]HLM_ts 1230 also has a datapath section comprised of present-state
inputs with timestep-independent names "Q2" and "Q3." Q2 and Q3 are input
to a block of datapath logic 1232, whose internal components are not
shown. Internal components of datapath logic 1232 can include TFs and
multiplexers. Datapath logic 1232 produces two next-state outputs with
timestep-independent names "D2" and "D3."

[0780]RTLM_ts 1240 is comprised of the following. There is a control
section, comprised of a present-state input with timestep-independent
name "Q4." Q4 is input to a block of control logic 1241, whose internal
components are not shown. Internal components of control logic 1241 can
include logic gates and TFs. Control logic 1241 produces a next-state
output with timestep-independent name "D4." Elements of the control
section are drawn in dashed form.

[0781]RTLM_ts 1240 also has a datapath section comprised of a
present-state input with timestep-independent name "Q5." Q5 is input to a
block of datapath logic 1242, whose internal components are not shown.
Internal components of datapath logic 1242 can include TFs and
multiplexers. Datapath logic 1242 produces a next-state output with
timestep-independent names "D5."

[0782]Corresponding to HLM_ts 1230 is an HLM 1210 that is shown in a
partially executed state. Similarly, corresponding to RTLM_ts 1240 is an
RTLM 1220 that is shown in a partially executed state.

[0783]The set of datapath present-state nodes, "DP_PS_TS," that contains
all nodes of type dp_ps_RTLM_ts or dp_ps_HLM_ts, along with the
corresponding model value for each, is as follows:

TABLE-US-00003
Q2 7
Q3 55, 100, 2
Q5 7

[0784]The corresponding model value for "Q2" of HLM_ts 1230 can be found
as follows. If "Q2" is an ordinary program variable, its
timestep-independent name can be applied to the program variable mapping
function to map to a location in memory, of HLM 1210, where the value "7"
is stored.

[0785]The corresponding model value for "Q3" of HLM_ts 1230 can be found
as follows. Its timestep-independent name can be applied to the program
variable mapping function to map to a location in memory, of HLM 1210,
where the address "addr1" is stored. Using the pointer value "addr1," in
conjunction with information stored by the Interceptor Library when HLM
1210 was executing, the memory block pointed to can be identified. In
this case, the memory block spans an address range from "addr0" to
"addr2." The contents of this memory block can then be the values for
"Q3."

[0786]The corresponding model value for "Q5" of RTLM_ts 1240, in RTLM
1220, can be found as follows. The timestep-independent name "Q5" can be
used to locate the corresponding register in RTLM 1220, which register
has the value "7."

[0787]DP_PS_TS can be divided into the following subsets: {Q2, Q5} and
{Q3}. The subset {Q2, Q5} can be assigned the integer SDV "1" and the
subset {Q3} can be assigned the integer SDV "2."

[0788]The corresponding value for "Q1" of HLM_ts 1230, in HLM 1210, can be
found in the same way that it was found for "Q2." The only difference is
that "Q1" is at the bit level. The value found for "Q1," in HLM 1210, is
a binary "1." This translates into the symbolic Boolean value "1[0]" for
"Q1" in HLM_ts 1230.

[0789]The corresponding value for "Q4" of RTLM_ts 1240, in RTLM 1220, can
be found in the same way that it was found for "Q5." The only difference
is that "Q4" is at the bit level. The value found for "Q4," in RTLM 1220,
is a binary "0." This translates into the symbolic Boolean value "0[0]"
for "Q4" in RTLM_ts 1240.

[0790]5.5. Other Applications

[0791]The techniques of partial HLM execution, and of accessing the values
of the partially executed HLM, are presented herein primarily with
respect to initializing a DFG representation of the HLM. Furthermore, the
discussion presented herein focuses primarily on applying the initialized
DFGs to the equivalence determining process presented herein.

[0792]However, the techniques of partial HLM execution, and of accessing
the values of the partially executed HLM, can be used in conjunction with
initializing any formal analysis tool (including those that do not use
DFGs), where the representation subject to formal analysis is derived
from an HLM.

[0793]6. Verification with CERs

[0794]This section presents, in pseudo-code, the core
equivalence-determining process presented above in FIG. 19. The core
equivalence-determining process, presented in FIG. 19, is comprised of
all steps of FIG. 19 with the exception of the initializations of step
4001. Correspondences between the pseudo-code and the steps of FIG. 19
are presented. Before presenting the pseudo-code, this section begins by
presenting, in overview, an example application of a core
equivalence-determining process.

[0795]6.1.1. Overview

[0796]FIGS. 21A-21N and 21P-21Q present an example application of a core
equivalence-determining process.

[0797]FIG. 21A depicts an initial miter MTts[0], comprised of an
RTLMts[0], HLMts[0] and CSts[0]. CSts[0] is indicated
in FIG. 21A as DFG 4310. DFG 4310 has one primary output "OUT" that is
true only if RTLMts[0], HLMts[0] are equivalent. The choices
for RTLMts[0] and HLMts[0], in FIG. 21A, are as follows.
RTLMts[0] can be DFG 4300 and HLMts[0] can be DFG 4301.
Alternatively, RTLMts[0] can be DFG 4301 and HLMts[0] can be
DFG 4300.

[0798]The control portion of FIG. 21A is indicated in dashed form, while
the rest of FIG. 21A is datapath. More specifically, the control portion
is comprised of two AND gates: one in DFG 4300 (referred to as AND 4300)
and the other in DFG 4301 (referred to as AND 4301). AND 4300 controls
the select inputs, in parallel, of two multiplexers. AND 4301 controls
the select input of one multiplexer.

[0799]When the select input to a multiplexer is at logic "1," the input to
the multiplexer labeled "1" is selected. Conversely, when the select
input to a multiplexer is at logic "0," the input to the multiplexer
labeled "0" is selected. For example, consider the multiplexer of DFG
4300 that produces a next-state output with timestep-independent name
"D1," referred to herein as "MUX_1_4300." When its select input is at
logic "1," MUX_1_4300 selects the primary input with timestep-independent
name "I1." When its select input is at logic "0," MUX_1_4300 selects the
present-state input with timestep-independent name "Q1."

[0800]FIG. 21B shows MTts[0] set to initial SDVs and symbolic Boolean
variables. To conserve graphical space, SDVs and symbolic Boolean
variables are indicated in FIGS. 21A-21N and 21P-21Q by being enclosed in
a pair of hyphens. Timestep-independent names are not enclosed within any
pair of symbols. The timestep-independent names for DFGs 4300 and 4301,
and the initial integer SDV for each, are as follows:

TABLE-US-00004
I1 4
I2 5
Q1 1
Q2 2
Q3 3
O1 3
O2 3

[0801]I1" and "I2" are primary inputs, "O1" and "O2" are primary outputs
and "Q1," "Q2" and "Q3" are present-state inputs. DFGs 4300 and 4301 also
include next-state outputs, indicated by the following
timestep-independent names: "D1," "D2" and "D3." "D1," "D2" and "D3,"
however, have not yet been assigned SDVs. A goal of SDV propagation is to
propagate SDVs to each of them.

[0802]For the particular example of FIG. 21B, the setting of "O1," "O2"
and "Q3" to the same SDV is not accomplished by the automatic
initialization procedures presented in above section 5 ("Initialization
Of The Miter Timestep"). This particular part of the initialization can
be accomplished, for example, under "manual" direction by the designer.
The designer may understand, having created the designs under test, that
"O1," "O2" and "Q3" need to be initialized to the same value in order for
equivalence to be found.

[0803]The timestep-independent names for DFGs 4300 and 4301, and the
initial integer symbolic Boolean variables for each, are as follows:

[0806]The equivalent of step 4002 is depicted, in the example, by FIGS.
21C to 21F. FIG. 21C shows the evaluation of the control logic
(specifically, the symbolic Boolean expression "P0*E0" is propagated to
the output of the AND gate in DFGs 4300 and 4301.

[0807]FIG. 21D shows the propagation of SDVs through the multiplexers of
DFG 4300. Specifically, the multiplexer that receives integer SDVs "4"
and "1" at its inputs is given the ITE SDV "ITE(P0*E0, 4, 1)" at its
output. Similarly, the multiplexer that receives integer SDVs "5" and "2"
at its inputs is given the ITE SDV "ITE(P0*E0, 5, 2)" at its output.
There is no propagation through the multiplexer of DFG 4301 since that
multiplexer only has an SDV at one of its inputs. The other input to the
multiplexer is driven by a TF block to whose output an SDV has not yet
been propagated.

[0808]FIG. 21E corresponds to the part of SDV propagation where
propagation through TF blocks is attempted. Propagation through TF blocks
can be performed when the following conditions, between a pair of TFs
called "TF1" and "TF2," are satisfied. First, conditions (called
conditional equivalence relations or CERs), under which TF1 and TF2
receive the same input data, are sought. Second, TF1 and TF2 are
compared, without consideration for the broader DFG in which they're
coupled, for whether they are functionally equivalent. When a non-null
CER can be found, and when the second condition is satisfied, TF1 and TF2
can be assigned SDVs that evaluate as follows. When the non-null CER
evaluates to true, the outputs of TF1 and TF2 should have the same
integer SDV. When the non-null CER evaluates to false, the outputs of TF1
and TF2 should have different integer SDVs. As can be seen from FIG. 21E,
there are no conditions under which the TF of DFG 4300 and the TF of DFG
4301 can receive the same input data. Therefore, there is nothing that
can be asserted about the output of the TF of DFG 4301.

[0809]If FIG. 21E did depict SDV propagation, FIG. 21F would show any
further SDV propagation that is possible as a result of propagation
through a TF or TFs.

[0810]Step 4003, of FIG. 19, can be applied to FIG. 21F. In FIG. 21F,
there is no miter timestep, prior to timestep MTts[0], that can
satisfy the conditions indicative of MTts[0] being ready for
reencode.

[0811]The actions of steps 4004-4005 are shown in FIG. 21G. Since a
maximum number of timesteps has not yet been added to the miter of FIG.
21F, an additional timestep MTts[1] is added and initialized in FIG.
21G. The timestep-independent names for DFGs 4302 and 4303, and the
initial integer SDV for each, are as follows:

TABLE-US-00006
I1 14
I2 15
Q1 ITE(P0*E0, 4, 1)
Q2 ITE(P0*E0, 5, 2)

[0812]The timestep-independent names for DFGs 4302 and 4303 that have not
yet been assigned SDVs are as follows: "O1," "O2," "Q3," "D1," "D2" and
"D3."

[0813]The timestep-independent names for DFGs 4302 and 4303, and the
initial integer symbolic Boolean variables for each, are as follows:

TABLE-US-00007
P P1
E E1

[0814]The equivalent of step 4002 is depicted, in the example, by FIGS.
21H to 21I.

[0815]FIG. 21H shows the evaluation of the control logic and the
propagation of SDVs through the multiplexers of DFG 4302.

[0816]FIG. 21I corresponds to the part of SDV propagation where
propagation through TF blocks is attempted. As can be seen from FIG. 21I,
there is a CER under which the TF of DFG 4300 and the TF of DFG 4302 can
receive the same input data: NOT(P0*E0). Furthermore, there is a CER
under which the TF of DFG 4302 and the TF of DFG 4301 can receive the
same input data: P0*E0. If it is assumed that these three TFs are
equivalent (see next paragraph for explanation of "equivalent"), an
integer SDV "8" can be propagated to the output of the TF of DFG 4301 and
an ITE SDV "ITE(NOT(P0*E0), 3, 8)" can be propagated to the output of the
TF of DFG 4302. As can be seen, with these newly propagated SDVs, the
outputs of the TFs of DFGs 4300 and 4302 are the same (i.e., integer SDV
"3") when "NOT(P0*E0)" is TRUE. Also, the outputs of the TFs of DFGs 4302
and 4301 are the same (i.e., integer SDV "8") when "NOT(P0*E0)" is FALSE.

[0817]Finding the three TFs equivalent can be accomplished as follows.
When any TF is considered in isolation, apart from any circuit to which
it may be coupled, it can be referred to as being "isolated." When all
three TFs have been isolated, they are equivalent if each of them
represents the same function as the other two.

[0818]As of FIG. 21I, the ATR is comprised of MTts[0] to
MTts[1]. Application of step 4003 of FIG. 19 to FIG. 21I results in
a determination that miter timestep MTts[0] satisfies the conditions
for MTts[1] to be reencoded.

[0819]FIG. 21J shows the result of step 4006 being performed. As of FIG.
21J, the ATR is set to begin and end at MTts[1]. This re-setting of
the ATR is more clearly indicated in FIG. 21K, where any values, prior to
the current reencode, are ignored. The FPT[0], that can be recorded from
MTts[1] of FIG. 21K is as follows:

[0820]FIG. 21K is identical to FIG. 21F, except that the timestep indices,
of the symbolic Boolean variables, are one greater in FIG. 21K.
Therefore, proceeding forward with SDV propagation from FIG. 21K is
identical (except for symbolic Boolean variable timestep indices) to what
has already been discussed in FIGS. 21G to 21K. The SDV propagation shown
in FIGS. 21G to 21K corresponds to the SDV propagation shown in FIGS.
21L-21N and 21 P-21Q. FIGS. 21L-21N and 21 P-21Q represent the action of
steps 4008 to 4014 of FIG. 19.

[0821]The FPT[1], that can be recorded from MTts[2] of FIG. 21Q is as
follows:

[0822]Since FPT[1] is identical to FPT[0] (such testing corresponding to
step 4016 of FIG. 19), except for symbolic Boolean variable timestep
indices, equivalence for all timesteps has been proven.

[0823]6.1.2. Equivalence_Checking_with_CERs

[0824]A core equivalence-determining process can be performed by invoking
equivalence_checking_with_CERs as shown in FIG. 24. The hierarchical
manner, in which procedures are invoked by
equivalence_checking_with_CERs, is diagrammed in FIG. 23. As can be seen
from FIG. 23, equivalence_checking_with_CERs directly invokes four
procedures. One of the four procedures invoked, "find_FPT," directly
invokes five additional procedures. One of the five procedures invoked by
find_FPT, "propagate_SDVs," directly invokes two more procedures. One of
the two procedures invoked by propagate_SDVs, "TF_prop," directly invokes
three more procedures. equivalence_checking_with _CERs calls find_FPT to
find a first FPT. FIG. 24, lines 6-7. With respect to FIG. 19, this first
call to find_FPT performs the equivalent of steps 4002 to 4007. The
equivalent of step 4008, that adds timesteps to the ATR and initializes
them in preparation for finding the second FPT, is performed by lines 9
to 23 of FIG. 24.

[0825]For the first call to find_FPT, the FPT found is stored in an array
element FPT[0]. If the first call to find_FPT is successful, find_FPT is
called again. If the first call to find_FPT is not successful, a counter
example is generated and equivalence_checking_with_CERs returns the value
FALSE. FIG. 24, lines 41-44.

[0826]Prior to the second call to find_FPT, the following steps (that
correspond to step 4008 of FIG. 19) can be accomplished. ATR_end can be
advanced. FIG. 24, line 9. The nodes of the additional timestep can be
labeled by calling "label_datapath_nodes." FIG. 24, line 10. The present
state of the just-added timestep can be set to the SDVs of the last
timestep's next-state outputs by calling "initialize_timestep_state."
FIG. 24, line 15. The primary inputs, of the just-added timestep, can be
set by calling "initialize_timestep_inputs." FIG. 24, line 23.

[0827]For the second call to find_FPT (FIG. 24, lines 25-26), the FPT
found can be stored in an array element FPT[1]. With respect to FIG. 19,
this second call to find_FPT performs the equivalent of steps 4010 to
4015.

[0828]If the second call to find_FPT is not successful, a counter example
can be generated and equivalence_checking_with_CERs can return FALSE.
FIG. 24, lines 34-38.

[0829]If the second call to find_FPT is successful, the two FPTs can be
compared. FIG. 24, line 27. This comparison corresponds to step 4016 of
FIG. 19. If the two FPTs are the same, equivalence_checking_with_CERs
returns the value TRUE. FIG. 24, line 28. If the two FPTs are not the
same equivalence_checking_with _CERs returns the value FALSE since
equivalence was only proven for some timesteps and not all. FIG. 24, line
32.

[0830]6.1.3. Label_Datapath_Nodes

[0831]As was introduced above, a label identifier is a globally unique
identifier for each datapath node of a miter. Label identifiers can be
used, as described in the below section 6.1.12 "Add_CER," for insuring
that equivalence classes of nodes, that have been determined by an
equivalence-determining process, are combined according to a predictable
ordering.

[0832]Labels can be generated, by label_datapath_nodes, as a sequence of
increasing integers and they can be assigned to the nodes of a timestep
in levelized order, starting from the primary inputs level and proceeding
to the primary outputs level. By assigning labels in this manner it can
be assured that an integer label for a node "x" will always be greater
than any integer label for a node in the transitive fanin of "x." An
example labeling procedure is shown in FIG. 30, 38-48.

[0833]Each call to label_datapath_nodes can act to label all nodes of just
the particular timestep specified and then label_datapath_nodes can
return to the calling procedure. If the highest integer assigned by
label_datapath_nodes on a particular invocation is "n," the next time
label_datapath_nodes is called, it can start assigning labels at "n+1."
This type of "memory," between calls to label_datapath_nodes, can be
accomplished by storing the value of the beginning label value, for the
next invocation of label_datapath_nodes, in a global variable
"beginning_label_value." The initial value for beginning_label_value,
prior to the first invocation of label_datapath_nodes, can be "1."

[0834]At a certain point during the SDV propagation process (i.e., when it
is desired to reencode a timestep), beginning_label_value can be set back
to "1."

[0835]6.1.4. Initialize_Timestep_State

[0836]Performs a simple form of SDV propagation when a new timestep is
added to an ATR: each present-state input of the just-added timestep is
set to the SDV of the corresponding next-state output of the last
timestep.

[0839]For the datapath primary inputs, initialization can be accomplished
as follows. For each pair of corresponding primary inputs, one from
RTLM_ts and one from HLM_ts, they can share the same integer SDV to
indicate they are always set to the same value. Correspondence, for
purposes of identifying a pair of corresponding primary inputs, can be
determined by the primary inputs sharing the same timestep-independent
names.

[0840]For the control primary inputs, initialization can be accomplished
as follows. For each pair of corresponding primary inputs, one from
RTLM_ts and one from HLM_ts, they can share the same symbolic Boolean
variable to indicate they are always set to the same Boolean value. The
symbolic Boolean variables created can include an indication of the
timestep for which they are created. Correspondence, for purposes of
identifying a pair of corresponding primary inputs, can be determined by
the primary inputs sharing the same timestep-independent names.

[0841]6.1.6. Find_FPT

[0842]6.1.6.1. Overview

[0843]Pseudo-code for find_FPT is depicted in FIGS. 25A-25B.

[0844]find_FPT's goal is as follows. Given a sequence of timesteps,
beginning at the last timestep "ATR_begin" to be encoded (or reencoded),
up to a latest timestep "ATR_end," propagate SDVs such that, from
timestep ATR_begin to a timestep "t_ready-1," the following conditions
for doing a reencode (tested for by "ready_to_reencode," FIG. 25A, line
29) are satisfied: [0845]All primary outputs, of RTLM_ts[ATR_begin] to
RTLM_ts[t_ready-1] and of HLM_ts[ATR_begin] to HLM_ts[t_ready-1], have
SDVs; [0846]All next state outputs, of RTLM_ts[ATR_begin] to
RTLM_ts[t_ready-1] and of HLM_ts[ATR_begin] to HLM_ts[t_ready-1], have
SDVs; and [0847]For CS_ts[ATR_begin] to CS_ts[t_ready-1], the "q" output
indicates RTLM_dfg=HLM_dfg.

[0848]If the conditions for a reencode are satisfied, then timestep
"t_ready-1" is the timestep just before the next timestep to be
reencoded. The timestep at t_ready is reencoded (by "reencode," FIG. 25A,
line 37) and the FPT of timestep t_ready is recorded (by "record_FPT,"
FIG. 25A, line 42) as the following: [0849]For each signal of
RTLM_ts[t_ready] and HLM_ts[t_ready], the correspondence between the
timestep-independent name of the signal and its SDV value.

[0850]It should be noted that within an FPT, as defined above, the indices
of control inputs, in any ITE-SDV expressions present, are expressed
relative to the last timestep to be reencoded (or, if a reencode has not
yet occurred, relative to the initial timestep of the miter).

[0851]The last timestep to be reencoded, as indicated by "ATR_begin," is
updated to the value of t_ready.

[0852]If the conditions for a reencode are not satisfied, find_FPT can try
adding another timestep to the range of timesteps within which it seeks
to find equivalences. This can be accomplished by incrementing
latest_timestep. If a maximum number of timesteps have been tried, and
the conditions for a reencode are still not satisfied, then find_FPT can
return value of FALSE.

[0853]6.1.6.2. Further Details

[0854]A more detailed discussion, of the pseudo-code for find_FPT, is as
follows.

[0855]Each iteration of the "while" loop of find_FPT (see FIG. 25A, line
10 to FIG. 25B, line 27), represents an attempt by find_FPT to satisfy
the conditions for reencoding. SDVs are propagated, within the range of
timesteps ATR_begin to ATR_end, by invoking the procedures
eval_control_exps" and "propagate_SDVs." With respect to FIG. 19, the
execution of "eval_control_exps" and "propagate_SDVs" corresponds to the
application of an SDV propagation process by step 4002 or 4011.

[0856]eval_control_exps (FIG. 25A, line 13) evaluates the control
expressions of RTLM_ts[ATR end] and HLM_ts[ATR_end].

[0857]propagate_SDVs (FIG. 25A, line 19) seeks to fully propagate SDVs
from RTLM_ts[ATR_begin] to RTLM_ts[ATR end] and from HLM_ts[ATR_begin] to
HLM_ts[ATR_end]. More detailed discussion of the operations of
propagate_SDVs is discussed in the below section 6.1.8 "propagate SDVs."

[0858]find_FPT then tests for whether the conditions for a reencode have
been satisfied with the procedure "ready_to_reencode." FIG. 25A, lines
29-30. With respect to FIG. 19, the execution of "ready_to_reencode"
corresponds to the testing performed by step 4003 or 4012.

[0859]If ready_to_reencode fails, find_FPT can test whether ATR_end has
been set to its maximum value. FIG. 25B, line 2. With respect to FIG. 19,
such testing corresponds to step 4004 or 4013. If ATR_end is set to its
maximum value, find_FPT can end and return a value of FALSE. FIG. 25B,
lines 3-6. With respect to FIG. 19, this corresponds to step 4007 or
4015. If ATR_end is not set to its maximum value, find_FPT can do the
following (which corresponds to step 4005 or step 4010 of FIG. 19):
[0860]increments ATR_end (FIG. 25B, line 9); [0861]levelized labeling of
the nodes of RTLM_ts[ATR_end] and HLM_ts[ATR_end] with the procedure
"label_datapath_nodes" (FIG. 25B, line 10), where the labels can proceed
incrementally from the last label used when label_datapath_nodes was last
called; [0862]initialize the present state of RTLM_ts[ATR_end] and
HLM_ts[ATR_end] with the next-state SDVs of RTLM_ts[ATR_end-1] and
HLM_ts[ATR_end-1] (See call to "initialize_timestep_state" at FIG. 25B,
line 15); [0863]initialize the datapath and control primary inputs of
RTLM_ts[ATR_end] and HLM_ts[ATR_end] (See call to
"initialize_timestep_inputs" at FIG. 25B, lines 22-23); and

[0864]continue the "while" loop by setting try_next_timestep to TRUE (FIG.
25B, line 24).

[0865]If ready_to_reencode succeeds, it can return a value of TRUE and set
one of its parameters (e.g., the variable "t_ready-1") to the location of
the timestep just before the timestep to be reencoded. The following
steps, that correspond to step 4006 or 4014 of FIG. 19, can also be done.
Reencoding, of the timestep at t_ready, can be accomplished by invoking
"reencode." FIG. 25A, line 37. The FPT, of the timestep at t_ready, can
be extracted by calling the procedure "record_FPT." FIG. 25A, line 42.
Further, a variable that indicates the last timestep to be reencoded
(e.g., "ATR_begin") can be updated to the value of t_ready. FIG. 25A,
line 45. find_FPT can then return by setting try_next_timestep to FALSE.
FIG. 25A, line 47.

[0866]6.1.7. Eval_Control_Exps

[0867]Each time a timestep is added by find_FPT, its control expressions
need to be evaluated. This is accomplished by invoking eval_control_exps.
FIG. 25A, line 13.

[0868]6.1.8. Propagate_SDVs

[0869]propagate_SDVs executes a "while" loop. FIG. 26, lines 12-24. The
"while" loop applies the procedures "mux_prop" (FIG. 26, line 19) and
"TF_prop" (FIG. 26, line 23). So long as mux_prop or TF_prop returns a
value of TRUE (and each of these procedures returns a value of TRUE when
it is able to cause a change to the DFG to which it is applied),
propagate_SDVs will continue to iterate its "while" loop.

[0870]6.1.9. Reencode

[0871]Reencoding, of a timestep at t=t_ready, can be accomplished as
follows.

[0872]The procedure "label_datapath_nodes" can be "reset" such that, upon
its next invocation, it will label the nodes of a specified timestep
starting from the lowest integer value it can assign.
label_datapath_nodes can then be applied to the timestep at t=t_ready
such that all of the labels of that timestep are overwritten.

[0873]For each present-state input "PSinput_x" to a timestep t_ready, its
current SDV value "curr_SDV_PSinput_x" can be replaced by its
newly-assigned label value "new_SDV_PSinput x." Then, wherever else, in
timestep t_ready (or in a later timestep), curr_SDV_PSinput_x appears, it
can be replaced by new_SDV_PSinput_x.

[0874]Similarly, for each primary input "Pinput_x" to a timestep t_ready,
its current SDV value "curr_SDV_Pinput_x" can be replaced by its
newly-assigned label value "new_SDV_Pinput_x." Then, wherever else, in
timestep t_ready (or in a later timestep), curr_SDV_Pinput_x appears, it
can be replaced by new_SDV_Pinput_x.

[0875]6.1.10. Mux_Prop

[0876]Without loss of generality, mux_prop is described herein as applied
to two-input multiplexers. Anyone of ordinary skill in the art will
readily appreciate how to adapt mux_prop to multiplexers with a greater
number of inputs.

[0877]mux_prop propagates SDVs through a multiplexer "X," provided that
the following conditions are met: each data input to "X" has an SDV and
the control input to "X" has a symbolic Boolean expression (referred to
herein as "SBV_X").

[0878]If we refer to the SDV at each input of "X" as SDV_1 and SDV_2,
where SDV_1 is selected if SBV_X is true while otherwise SDV_2 is
selected, the function of mux_prop is to produce the following ITE SDV
for the output of "X":

ITE(SBV_X, SDV--1, SDV--2)

[0879]6.1.11. TF_Prop

[0880]TF_prop operates as follows. Please see FIG. 27.

[0881]TF_prop contains an outer loop that iterates over each pair of TFs
(TF1 and TF2) in the miter DFG. FIG. 27, line 4. For each pair of TFs, an
inner loop iterates over each pair of inputs TF1_in and TF2_in, where
TF1_in is an input of TF1 and TF2_in is an input of TF2. FIG. 27, lines
6-7.

[0882]The CER between TF1_in and TF2_in, referred to herein as
"CER_TF1in_TF2in," is determined. FIG. 27, lines 9-10. CER_TF1in_TF2in
can be determined by obtaining the SDV for TF1_in and the SDV for TF2_in
(with the procedure "get_SDV--4node"). Another procedure, referred
to as "SDVs_to_CER," can determine whether there is any set of conditions
CER_TF1in_TF2in for which the SDV for TF1_in and the SDV for TF2_in
evaluate to the same value.

[0883]The CER CER_TF1in_TF2in produced by SDVs_to_CER can be tested (by
procedure "CER_can_be_true") for whether it is satisfiable. FIG. 27, line
12. For example, if there is no set of conditions for which the SDV for
TF1_in and the SDV for TF2_in produce the same value, then the CER
CER_TF1 in_TF2in produced by SDVs_to_CER will always be FALSE.

[0884]If CER_TF1in_TF2in is satisfiable, then it is possible for TF1 and
TF2, under certain conditions, to produce the same outputs. To determine
for certain whether this is the case, and under what conditions, the
following steps can be done. A combinational equivalence check can be
done between TF1 and TF2 by calling the procedure "Comb_Equiv_Check."
FIG. 27, line 13. Comb_Equiv_Check returns a value of TRUE if TF1 and TF2
compute the same combinational function. Comb_Equiv_Check determines
that, for each input "x1" to TF1 there is a corresponding input "x2" of
TF2 that performs the same function. If Comb_Equiv_Check returns a value
of TRUE, then a further determination can be done to see whether there is
a CER, called "CER_TF1out_TF2out," for which TF1 and TF2 do produce the
same outputs. FIG. 27, lines 19-20.

[0885]For example, if there is a CER_TF1out_TF2out that, if satisfied,
causes each pair of corresponding inputs, between TF1 and TF2, to receive
the same values, then it has been determined that the value produced by
TF1_out always equals the value of TF2_out.

[0886]If a non-null CER_TF1out_TF2out is found, "Add_CER" can be called.
FIG. 27, lines 22-24. Add_CER can adjust the SDVs, of TF1_out and
TF2_out, such that they evaluate to the same value when the conditions of
CER_TF1out_TF2out are satisfied.

[0887]6.1.12. Add_CER 6.1.12.1. Overview

[0888]The basic function of Add_CER is to couple two pre-existing
equivalence classes (the equivalence class of nodes in the CER transitive
closure of TF1_out and the equivalence class of nodes in the CER
transitive closure of TF2_out) to produce a new combined equivalence
class.

[0889]To accomplish this, a new SDV (also referred to as "SDVnew") is
determined for each node of the new combined equivalence class. Each
SDVnew is determined in terms of the pre-existing SDVs and in a
particular order. The order in which a node is selected, for a
determination of its SDVnew, is determined by the node's label
identifier. A label identifier is globally unique for each node of a
miter DFG. Having label identifiers assigned according to a predetermined
ordering procedure insures that pre-existing equivalence classes are
combined according to a predetermined ordering that produces the
following property: [0890]Assume a first application of find_FPT
produces two pre-existing equivalence classes "pre_EC1" and "pre_PEC2,"
with the combined equivalence class referred to as "com_EC1."
[0891]Assume a second application of find_FPT produces two pre-existing
equivalence classes "pre_EC3" and "pre_PEC4," with the combined
equivalence class referred to as "com_EC2." [0892]Assume that "pre_EC1"
is equivalent to "pre_EC3" and "pre_EC2" is equivalent to "pre_EC4."

[0893]Then, "com_EC1" will be equivalent to "com_EC2."

[0894]Suitable label identifiers can be, for example, positive integers.
With integer label identifiers, each SDVnew can be determined, in terms
of the pre-existing SDVs, according to the following order. Without loss
of generality, assume the label identifiers, of both pre-existing
equivalence classes, combine to form a set of integers "1" to "n." For
the node with label identifier "1," its SDVnew can be the same as its
current SDV. For the node with label identifier "2," its SDVnew can be
expressed in terms of the current SDV for the node with label identifier
"1." In general, for any node "k," where "1"<"k"≦"n," its
SDVnew can be expressed in terms of the SDVnew for each node with a label
identifier less than "k."

[0895]6.1.12.2. Pseudo-Code

[0896]Add_CER begins by determining the CER transitive closure of all
nodes of the miter that are connected to TF1_out or TF2_out. FIG. 28A,
lines 5-9. This transitive closure is referred to as "nodeset." An
example procedure, for determining the CER transitive closure, is shown
in FIG. 30, lines 6-28, as "determineConnectedNodeSet."

[0897]Each node of nodeset can be initialized as follows. FIG. 28A, lines
13-17. SDVnew can be set to the label identifier. If the node does not
already have an SDV, it is set to the label identifier.

[0898]An outer loop of Add_CER (FIG. 28B, lines 1-2) iterates over each
node "nlow" of nodeset, in order of decreasing label identifier value.

[0899]An inner loop of Add_CER (FIG. 28B, lines 4-5) can determine the set
of all nodes whose node labels are greater than nlow's and can iterate
over each node "nhigh" of that set, in order of decreasing label
identifier value.

[0901]For each pair, nlow, nhigh, an SDVnew for nhigh is constructed. FIG.
28B, line 25. The condition "c1|c2|c3" of the SDVnew is the CER between
nlow and nhigh, determined using the current SDVs. In general, either all
of "c1," "c2" and "c3" are FALSE, or only one of "c1," "c2" and "c3"
evaluates to a non-FALSE value.

[0902]The statement for evaluating ci seeks to find a CER between nlow and
nhigh in the following way. FIG. 28B, lines 9-12. It is assumed that nlow
is in the same pre-existing equivalence class with TF1_out and it is
assumed that nhigh is in the same pre-existing equivalence class with
TF2_out. If either of these assumptions is not true, c1 evaluates to a
FALSE value.

[0903]The statement for evaluating c2 seeks to find a CER between nlow and
nhigh in the following way. FIG. 28B, lines 15-18. It is assumed that
nlow is in the same pre-existing equivalence class with TF2_out and it is
assumed that nhigh is in the same pre-existing equivalence class with
TF1_out. If either of these assumptions is not true, c2 evaluates to a
FALSE value.

[0904]The statement for evaluating c3 seeks to find a CER between nlow and
nhigh in the following way. FIG. 28B, lines 21-22. It is assumed that
nlow is in the same pre-existing equivalence class with nhigh. If this
assumption is not true, c3 evaluates to a FALSE value.

[0905]7. Example

[0906]To illustrate the operation of the above-described pseudo-code, this
section presents an example simulation of the "test_for_equivalency"
procedure. Each pseudo-coded procedure invoked, directly or indirectly,
by test_for_equivalency is also part of the example simulation.

[0907]7.1. Test_for_Equivalency

[0908]This example simulation does not start with examples for source HLM
and RTLM.

[0909]The production of HLMDFG and RTLMDFG, from HLM and RTLM,
is also not shown. As described above, such production can be performed
by test_for_equivalency calling RTLM_2_DFG and HLM_2_DFG. FIG. 2B, line 5
and line 8.

[0910]The example simulation begins with HLMDFG and RTLMDFG
already produced. Such example DFGs are shown in FIG. 20A as DFGs 4200
and 4201. One of the DFGs can be HLMDFG and the other RTLMDFG.

[0911]FIG. 20B depicts DFGs 4200 and 4201 in timestep form, as can be
accomplished by test_for_equivalency calling generate_timestep. FIG. 2B,
line 14 and line 15. HLM_ts and RTLM_ts can be generated such that, for
each timestep used, the control and datapath sections identified. FIG.
20B shows the control sections are comprised of dashed lines while the
datapath is comprised of solid lines.

[0912]A suitable combining structure, for DFGs 4200 and 4201 of FIG. 20B,
can be selected by calling generate_test_bench. FIG. 2B, line 21.
generate_test_bench can operate as follows.

[0913]DFGs 4200 and 4201 of FIG. 20B can both be classified as being of
type "unknown."

[0914]According to the combining structure decision matrix (see FIG. 17),
a "cycle-accurate" CSts can be chosen. FIG. 21A shows a CSts[0]
4310, along with DFGs 4200 and 4201 renumbered as 4300 and 4301.

[0915]Since the search for equivalence is defined to begin at time "t=0,"
FIG. 2B, lines 23-24, show the variables "ATR_begin" and "ATR_end" set to
zero.

[0916]The resulting timestep, RTLMts[0], HLMts[0] and
CSts[0], can have its nodes labeled in levelized order by
label_datapath_nodes. FIG. 2B, line 27.

[0917]FIG. 21A shows the levelized labeling of nodes as follows: to
conserve graphical space in the drawing, a label is indicated in FIG. 21A
as a number placed in-between two periods. (It should be noted that the
levelized labeling of FIG. 21A is correct, so long as one assumes the
following two pairs of nodes each represents a single: node "I1" of DFG
4300 and node "I1" of DFG 4301 represent a singled node labeled "4;" and
node "I2" of DFG 4300 and node "I2" of DFG 4301 represent a singled node
labeled "5." The same assumption applies for nodes "I1" and "I2," in
FIGS. 21G and 21L.)

[0918]RTLM_ts[0] and HLM_ts[0] can be initialized by calling
"initialize_initial_timestep." FIG. 2B, lines 32-33. The datapath and
control primary inputs of RTLM_ts[0] and HLM_ts[0] can be set by calling
"initialize_timestep_inputs." FIG. 2B, line 40. A resulting state for the
first timestep is shown in FIG. 21B. As was noted above, in section 6.1.1
("Overview"), the setting of "O1," "O2" and "Q3" to the same SDV can be
accomplished under "manual" direction by the designer.

[0927]Since the two FPTs are the same (except for the indices of the
symbolic Boolean variables applied to control ITE SDVs),
equivalence_checking_with_CERs returns TRUE.

[0928]7.3. Find_FPT

[0929]The example applications of find_FPT are as follows.

[0930]7.3.1. Application of Find_FPT to FIG. 21B

[0931]The result of applying eval_control_exps to FIG. 21B is shown in
FIG. 21C.

[0932]The result of applying propagate_SDVs to FIG. 21C is shown in FIG.
21F. More detailed discussion of the operations of propagate_SDVs, that
produces the change from FIG. 21C to 21F, is discussed in the below
section 7.5 "propagate_SDVs."

[0933]ready_to_reencode fails when applied to FIG. 21F.

[0934]It is assumed the maximum value for latest timestep is not reached,
and another timestep is added as is shown in FIG. 21G.

[0935]The timestep added in FIG. 21G can be labeled by calling the
procedure "label_datapath_nodes" (FIG. 25B, line 10).

[0936]The timestep added can have its present state initialized by calling
the procedure "initialize_timestep_state" (FIG. 25B, line 15).

[0937]The timestep added and can have its datapath and control primary
inputs initialized by calling the procedure "initialize_timestep_inputs"
(FIG. 25B, line 22).

[0938]In the next iteration of the "while" loop, invocation of the
procedures eval_control_exps" and "propagate_SDVs" on FIG. 21G produces
the DFG of FIG. 21I.

[0939]When ready_to_reencode is applied to the DFG of FIG. 21I, the
conditions for a reencode are satisfied and ready_to_reencode sets
t_ready to one. Given that ATR_begin is set to zero, the conditions for a
reencode are satisfied by FIG. 21I as follows: [0940]All primary
outputs, of RTLM_ts[0] to RTLM_ts[0] and of HLM_ts[0] to HLM_ts[0], have
SDVs; [0941]All next state outputs, of RTLM_ts[0] to RTLM_ts[0] and of
HLM_ts[0] to HLM_ts[0], have SDVs; and [0942]For CS_ts[0] to CS_ts[0],
the "q" output indicates RTLM_dfg=HLM_dfg.

[0944]FIG. 21K is the same as FIG. 21J, except that non-reencoded values
are omitted to make it visually easier to see the values comprising the
FPT recorded by record_FPT (FIG. 25A, line 42). The FPT of FIG. 21K is as
follows:

[0955]Note that the indices of control inputs in ITE-SDVs (i.e., "P" and
"E") are expressed relative to timestep 1, which is the latest timestep
to be reencoded (in the Figures, the indices of "P" and "E" are expressed
without brackets).

[0956]7.3.2. Application of Find_FPT to FIG. 21L

[0957]In the first iteration of the "while" loop, for the second call to
find_FPT, invocation of the procedures "eval_control_exps" and
"propagate_SDVs" on FIG. 21L produces the DFG of FIG. 21N.

[0958]When ready_to_reencode is applied to the DFG of FIG. 21N, the
conditions for a reencode are satisfied and ready_to_reencode sets its
parameter t_ready to two. Given that ATR_begin is set to one, the
conditions for a reencode, that are satisfied by FIG. 21N, are as
follows: [0959]All primary outputs, of RTLM_ts[1] to RTLM_ts[1] and of
HLM_ts[1] to HLM_ts[1], have SDVs; [0960]All next state outputs, of
RTLM_ts[1] to RTLM_ts[1] and of HLM_ts[1] to HLM_ts[1], have SDVs; and
[0961]For CS_ts[1] to CS_ts[1], the "q" output indicates
RTLM_dfg=HLM_dfg.

[0963]FIG. 21Q is the same as FIG. 21P, except that non-reencoded values
are omitted to make it visually easier to see the values comprising the
FPT recorded by application of record_FPT. The FPT of FIG. 21Q is as
follows:

[0974]Note that the indices of control inputs in ITE-SDVs (i.e., "P" and
"E") are expressed relative to timestep 2, which is the latest timestep
to be reencoded.

[0975]7.4. Eval_Control_Exps

[0976]The example applications of eval_control_exps are as follows.

[0977]The transition from FIG. 21B to FIG. 21C is a result of an
application of eval_control_exps. As can be seen, the control circuitry
comprises an AND gate in DFG 4300 and an AND gate in DFG 4301. In FIG.
21C, the symbolic Boolean variables, at the inputs to these AND gates
have resulted in the symbolic Boolean expression at the output of each
AND gate.

[0978]FIG. 21G shows the addition of a timestep at time one and the
evaluation of symbolic Boolean variables at the inputs to the AND gates
of DFGs 4302 and DFG 4303 is shown in FIG. 21H.

[0979]FIG. 21L shows the addition of a timestep at time two and the
evaluation of symbolic Boolean variables at the inputs to the AND gates
of DFGs 4304 and DFG 4305 is shown in FIG. 21M.

[0980]7.5. Propagate_SDVs

[0981]The example applications of eval_control_exps are as follows.

[0982]7.5.1. Applied to FIG. 21C

[0983]propagate_SDVs can be applied to FIG. 21 C to produce the DFG of
FIG. 21F.

[0984]First, propagate_SDVs can apply mux_prop to the DFG of FIG. 21C to
produce FIG. 21D. As can be seen, an ITE SDV has been propagated to the
output of each multiplexer of DFG 4300. Since the DFG changed from FIG.
21C to FIG. 21D, mux_prop returns a value of TRUE.

[0985]Next, propagate_SDVs can apply TF_prop to the DFG of FIG. 21D to
produce FIG. 21F. Since the DFG did not change, from FIG. 21D to FIG.
21F. TF_prop returns a value of FALSE.

[0986]propagate_SDVs will execute its "while" loop a second time, since
mux_prop returned a value of TRUE on the first iteration. On the second
iteration of the "while" loop, both mux_prop and TF_prop return a value
of FALSE and so propagate_SDVs returns.

[0987]7.5.2. Applied to FIG. 21G

[0988]propagate_SDVs can be applied to FIG. 21G to produce the DFG of FIG.
21I.

[0989]On a first iteration of the "while" loop, mux_prop can be applied to
the DFG of FIG. 21G to produce FIG. 21H. As can be seen, an ITE SDV has
been propagated to the output of each multiplexer of DFG 4302. Since the
DFG changed from FIG. 21G to FIG. 21H, mux_prop returns a value of TRUE.

[0990]TF_prop can be applied to the DFG of FIG. 21H to produce FIG. 21I.
As can be seen, an ITE SDV has been propagated to the output of the TF of
DFG 4302. Also, an integer SDV has been propagated to the output of the
TF of DFG 4301. Since the DFG changed from FIG. 21H to FIG. 21I, TF_prop
returns a value of TRUE.

[0991]On a second iteration of the "while" loop, both mux_prop and TF_prop
return FALSE, and propagate_SDVs ends.

[0992]7.5.3. Applied to FIG. 21L

[0993]propagate_SDVs can be applied to FIG. 21L to produce the DFG of FIG.
21N.

[0994]On a first iteration of the "while" loop, mux_prop can be applied to
the DFG of FIG. 21L to produce FIG. 21 M. As can be seen, an ITE SDV has
been propagated to the output of each multiplexer of DFG 4304. Since the
DFG changed from FIG. 21L to FIG. 21 M, mux_prop returns a value of TRUE.

[0995]TF_prop can be applied to the DFG of FIG. 21M to produce FIG. 21N.
As can be seen, an ITE SDV has been propagated to the output of the TF of
DFG 4304. Also, an integer SDV has been propagated to the output of the
TF of DFG 4303. Since the DFG changed from FIG. 21M to FIG. 21N, TF_prop
returns a value of TRUE.

[0996]On a second iteration of the "while" loop, both mux_prop and TF_prop
return FALSE, and propagate_SDVs ends.

[0997]7.6. TF_Prop

[0998]The example applications of TF_prop are as follows.

[0999]7.6.1. Applied to FIG. 21D

[1000]Application of TF_prop to FIG. 21D produces FIG. 21F.

[1001]In FIG. 21D there are only two TFs: the TF of DFG 4300 (referred to
herein as TF 4300) and the TF of DFG 4301 (referred to herein as TF
4301). Therefore, there is only one pair of TFs that can be iterated over
by the outer loop of TF_prop. For each pair of inputs, between TF 4300
and TF 4301, the CER_TF1in_TF2in is null. This inability to find any CERs
CER_TF1in_TF2in is represented by FIG. 21E being the same as FIG. 21D.

[1002]Since no non-null values for CER_TF1in_TF2in are produced, no values
for CER_TF1out_TF2out are produced. This inability to find any CERs
CER_TF1out_TF2out is represented by FIG. 21F being the same as FIG. 21E.

[1003]7.6.2. Applied to FIG. 21H

[1004]Application of TF_prop to FIG. 21H produces FIG. 21I.

[1005]The net result for SDV propagation, in going from FIG. 21H to 431,
is as follows: the output of the TF of DFG 4302 (referred to herein as TF
4302) is assigned ITE SDV "ITE(NOT(P0*E0), 3, 8)" and the output of TF
4301 is assigned integer SDV "8." TF_prop achieves this propagation as
follows.

[1006]In FIG. 21H there are four TFs: TF 4300, TF 4301, the TF 4302 and
the TF of DFG 4303 (referred to herein as TF 4303). Between these four
TFs, the following six pairs can be iterated over by the outer loop of
TF_prop: (TF 4300, TF 4301), (TF 4302, TF 4303), (TF 4300, TF 4302), (TF
4301, TF 4303), (TF 4300, TF 4303) and (TF 4301, TF 4302).

[1007]From among these six pairs, only the following two produce a CER
CER_TF1out_TF2out: (TF 4300, TF 4302) and (TF 4301, TF 4302).

[1008]7.6.2.1. Pair (TF 4300, TF 4302)

[1009]For (TF 4300, TF 4302), the actions of TF_prop are as follows.

[1010]For (TF 4300, TF 4302) the two CERs of type CER_TF1in_TF2in are as
follows. The first is the CER "NOT(P0*E0)" between the following two
inputs: the input of TF 4300 with integer SDV "1" (which input is
indicated in FIG. 21I by an arrow labeled "CER 5") and the input of TF
4302 with ITE SDV "ITE(P0*E0, 4, 1)" (which input is indicated in FIG.
21I by an arrow labeled "CERs 3,5"). The second is the CER "NOT(P0*E0)"
between the following two inputs: the input of TF 4300 with integer SDV
"2" (which input is indicated in FIG. 21I by an arrow labeled "CER 6")
and the input of TF 4302 with ITE SDV "ITE(P0*E0, 5, 2)" (which input is
indicated in FIG. 21I by an arrow labeled "CERs 4,6"). The resulting
CER_TF1out_TF2out, between the output of TF 4300 and TF 4301, is
"NOT(P0*E0)."

[1011]Add_CER is called with its parameters set as follows:
[1012]CER_TF1out_TF2out=NOT(P0*E0) [1013]TF1_out=output of TF 4300
[1014]TF2_out=output of TF 4302

[1015]The detailed actions of Add_CER, with the above parameters, is
covered in the below section 7.7 "Add_CER." FIG. 22A shows a simplified
view of FIG. 21H. Operations of Add_CER can result in FIG. 22A being
transformed to FIG. 22E, where the output of TF 4302 is given ITE SDV
"ITE(NOT(P0*E0), 3, 19)."

[1016]7.6.2.2. Pair (TF 4301, TF 4302)

[1017]For (TF 4301, TF 4302), the actions of TF_prop are as follows.

[1018]For (TF 4301, TF 4302) the two CERs of type CER_TF1 in_TF2in are as
follows. The first is the CER "P0*E0" between the following two inputs:
the input of TF 4301 with integer SDV "4" (which input is indicated in
FIG. 21I by an arrow labeled "CER 3") and the input of TF 4302 with ITE
SDV "ITE(P0*E0, 4, 1)" (which input is indicated in FIG. 21I by an arrow
labeled "CERs 3,5"). The second is the CER "P0*E0" between the following
two inputs: the input of TF 4301 with integer SDV "5" (which input is
indicated in FIG. 21I by an arrow labeled "CER 4") and the input of TF
4302 with ITE SDV "ITE(P0*E0, 5, 2)" (which input is indicated in FIG.
21I by an arrow labeled "CERs 4,6"). The resulting CER_TF1out_TF2out,
between the output of TF 4301 and TF 4302, is "P0*E0."

[1019]Add_CER is called with its parameters set as follows:
[1020]CER_TF1out_TF2out=P0*E0

[1021]TF1_out=output of TF 4301

[1022]TF2_out=output of TF 4302

[1023]The detailed actions of Add_CER, with the above parameters, is
covered in the below section 7.7 "Add_CER." To summarize, however,
operations of Add_CER can result in FIG. 22E being transformed to FIG.
22K, where the output of TF 4302 is given ITE SDV "ITE(NOT(P0*E0), 3, 8)"
and the output of TF 4301 is given integer SDV "8." FIG. 22K has the
final result that is seen in FIG. 21I.

[1024]7.6.3. Applied to FIG. 21M

[1025]Application of TF_prop to FIG. 21M produces FIG. 21N. Production of
FIG. 21N from FIG. 21M is the same (except for the timestep numbers
involved) as production of FIG. 21I from FIG. 21H.

[1026]7.7. Add_CER

[1027]The example applications of Add_CER are as follows. The below
applications of Add_CER are only those invoked by TF_prop in the above
section 7.6.2 ("Applied to FIG. 21H"). Since action of Add_CER cannot be
seen in the transition from FIG. 21H to 43I, it is discussed with respect
to FIG. 22 (which presents a simplified view of FIG. 21H).

[1028]7.7.1. Applied to FIG. 22A

[1029]As discussed above in section 7.6.2.1 ("Pair (TF 4300, TF 4302)"),
when processing the miter state of FIG. 22A, Add_CER can be called with
its parameters set as follows: [1030]CER_TF1out_TF2out=NOT(P0*E0)
[1031]TF1_out=output of TF 4300 [1032]TF2_out=output of TF 4302

[1033]The detailed actions of Add_CER, with the above parameters, are
depicted in FIGS. 29A-29B. FIGS. 29A-29B identify nodes by their label
numbers. For example, line 5 of FIG. 29A refers to TF1_out as
node_labeled--9," rather than as the output of TF 4300.

[1034]The net result of Add_CER executing the actions of FIG. 29A is to
convert FIG. 22A to the state shown in FIG. 22B. The net result of
Add_CER executing the actions of FIG. 29B is to convert FIG. 22B to the
state shown in FIG. 22E. Step-by-step, the actions shown by FIGS. 29A-29B
are as follows.

[1035]Lines 3-6 of FIG. 29A show the parameter values with which Add_CER
is called.

[1036]FIG. 29A at lines 9-12 shows the determination of nodeset.

[1037]FIG. 29A, lines 15-18 show the initialization of SDV and SDVnew
values.

[1038]FIG. 29A, line 22 shows the nodes of nodeset in descending order.

[1039]FIG. 29A at lines 25-27 show the selection of the first (nlow,
nhigh) pair: (node_labeled_9, node_labeled_19).

[1040]For (node_labeled_9, node_labeled_19), only c1 evaluates to a
non-zero value (of "NOT(P0*E0)") and such evaluation is shown at lines
30-35 of FIG. 29A.

[1041]FIG. 29A, lines 38-40 show the determination of SDVnew for
node_labeled_19.

[1042]FIG. 29B at lines 1-24 show the actions performed for the (nlow,
nhigh) pair: (node_labeled_3, node_labeled_19). The net result of Add_CER
executing the actions of FIG. 29B, lines 1-24, is to convert FIG. 22B to
the state shown in FIG. 22C.

[1043]FIG. 29B at lines 27-41 show the actions performed for the (nlow,
nhigh) pair: (node_labeled_3, node_labeled_9). The net result of Add_CER
executing the actions of FIG. 29B, lines 27-41, is to convert FIG. 22C to
the state shown in FIG. 22D.

[1044]FIG. 29B at lines 44-49 show the actions performed after all (nlow,
nhigh) pairs have been iterated over. The net result of Add_CER executing
the actions of FIG. 29B, lines 44-49, is to convert FIG. 22D to the state
shown in FIG. 22E.

[1045]7.7.2. Applied to FIG. 22E

[1046]As discussed above in section 7.6.2.2 ("Pair (TF 4301, TF 4302)"),
when processing the miter state of FIG. 22E, Add_CER can be called with
its parameters set as follows: [1047]CER_TF1out_TF2out=P0*E0
[1048]TF1_out=output of TF 4301 [1049]TF2_out=output of TF 4302

[1050]The detailed actions of Add_CER, with the above parameters, are
depicted in FIGS. 29C-29E.

[1051]The net result of Add_CER executing the actions of FIG. 29C, lines
1-16 is to convert FIG. 22E to the state shown in FIG. 22F. The net
result of Add_CER executing the actions of FIG. 29C, lines 19-34 is to
convert FIG. 22F to the state shown in FIG. 22G. The net results of
Add_CER executing the actions of FIG. 29D, lines 1-18, are shown in FIG.
22H. The net results of Add_CER executing the actions of FIG. 29D, lines
21-49, are shown in FIG. 22I. The net results of Add_CER executing the
actions of FIG. 29E, lines 1-27, are shown in FIG. 22J. The net results
of Add_CER executing the actions of FIG. 29E, lines 30-44, are shown in
FIG. 22K. Step-by-step, the actions shown by FIGS. 29C-29E are as
follows.

[1052]Lines 4-6 of FIG. 29C show the parameter values with which Add_CER
is called.

[1053]FIG. 29C at lines 8-10 shows the determination of nodeset.

[1054]FIG. 29C, lines 12-16 show the initialization of SDV and SDVnew
values.

[1055]FIG. 29C, line 23 shows the nodes of nodeset in descending order.

[1056]FIG. 29C at lines 25-28 show the selection of the first (nlow,
nhigh) pair: (node_labeled_9, node_labeled_19).

[1057]For (node_labeled_9, node_labeled_19), all of c1, c2 and c3 evaluate
to a zero value.

[1058]FIG. 29C, lines 32-34 show the determination of SDVnew for
node_labeled--19.

[1059]FIG. 29D at lines 1-18 show the actions performed for the (nlow,
nhigh) pair: (node_labeled_8, node_labeled_19). The net result of Add_CER
executing the actions of FIG. 29D, lines 1-18, is to convert FIG. 22G to
the state shown in FIG. 22H.

[1060]FIG. 29D at lines 21-30 show the actions performed for the (nlow,
nhigh) pair: (node_labeled_8, node_labeled_9).

[1061]FIG. 29D at lines 33-49 show the actions performed for the (nlow,
nhigh) pair: (node_labeled_3, node_labeled_19).

[1062]FIG. 29E at lines 1-13 show the actions performed for the (nlow,
nhigh) pair: (node_labeled_3, node_labeled_9).

[1063]FIG. 29E at lines 16-27 show the actions performed for the (nlow,
nhigh) pair: (node_labeled_3, node_labeled_8).

[1064]FIG. 29E at lines 30-44 show the actions performed after all (nlow,
nhigh) pairs have been iterated over. The net result of Add_CER executing
the actions of FIG. 29E, lines 30-44, is to convert FIG. 22J to the state
shown in FIG. 22K.

[1065]8. Hardware Environment

[1066]The equivalence determining architecture of the present invention,
or each of its component sub-systems individually, can be executed within
a computing environment (or data processing system) such as that of FIG.
31. FIG. 31 depicts a workstation computer 6000 comprising a Central
Processing Unit (CPU) 6001 (or other appropriate processor or processors)
and a memory 6002. Memory 6002 has a region 6003 in which is stored the
software tools (or computer programs) and data of the present invention.
While 6003 is depicted as a single region, those of ordinary skill in the
art will appreciate that, in fact, such software may be distributed over
several memory regions or several computers. Furthermore, depending upon
the computer's memory organization (such as virtual memory), memory 6002
may comprise several types of memory (including cache, random access
memory, hard disk and networked file server). Computer 6000 can be
equipped with a display monitor 6005, a mouse pointing device 6004 and a
keyboard 6006 to provide interactivity between the software of the
present invention and a chip designer. Computer 6000 also includes a way
of reading computer readable instructions from a computer readable medium
6007, via a medium reader 6008, into the memory 6002. Computer 6000 also
includes a way of reading computer readable instructions via the Internet
(or other network) through network interface 6009.

[1067]In some embodiments, computer programs embodying the present
invention are stored in a computer readable medium, e.g. CD-ROM or DVD.
In other embodiments, the computer programs are embodied in an
electromagnetic carrier wave. For example, the electromagnetic carrier
wave may include the programs being accessed over a network.

[1068]9. Glossary of Selected Terms

[1069]CEC: Combinational Equivalence Check.

[1070]CFG: Control F1ow Graph

[1071]Conditional expression: The expression, of a CFG conditional node,
that evaluates to TRUE or FALSE. F1ow of control, from the conditional
node, proceeds in one of two directions depending upon the conditional
expression's value.

[1072]EP: Execution Path.

[1073]EP queue: A queue of EPs. EPs can enter an EP queue at the "bottom"
or input end of the queue. EPs can exit an EP queue at the "top" or
output end of the queue.

[1074]FPT: Fixed-Point Target.

[1075]HLM: High-Level Model

[1076]HDL: Hardware Description Language, such as Verilog HDL.

[1077]Intersect: Two functions are defined, herein, to "intersect" if
there is at least one input combination for which both are satisfied.

[1078]ITE: If-Then-Else.

[1079]lhs: left-hand-side

[1080]Miter: A term used herein to refer to the combination of
RTLMts[t], HLMts[t] and CSts[t].

[1081]MTBDD: Multi-Terminal Binary Decision Diagram. A type of BDD that
can represent functions that return values other than just logic one or
logic zero.

[1082]Non-canonical data structure: A data structure for representing
symbolic functions, e.g., ((a+b)<(c-d)). A data structure is
non-canonical if there exist several structurally different
representations for the same function. A DFG is one type of non-canonical
data structure. Example: The function `a+b` can be represented with
several different DFGs, e.g., (a+b+0) or ((a+c)+(b-c)).

[1083]Pseudo-code: The pseudo-code presented herein is loosely based on
the C programming language. The C programming language is described in
such texts as "A Book on C," by A. Kelley and I. Pohl, Benjamin Cummings
Pub. Co., Third Edition, 1995, ISBN 0-8053-1677-9, herein incorporated by
reference in its entirety. In pseudo-code procedure calls, a parameter is
prefixed with the "&" operator to indicate that the called procedure will
operate on the data object of the calling procedure. This use of the "&"
operator is a standard part of the C programming language.

[1084]rhs: right-hand-side

[1085]RTLM: RTL Model

[1086]SDV: Symbolic Data Value. Can be of two types: integer SDV or ITE
SDV.

[1087]Test bench: also referred to herein as a "combining structure" or
CS.

[1088]Timestep-independent name: Each timestep used as part of the same
miter repeats the same set of timestep-independent names. The
timestep-independent names are carried over from the DFG that is
converted into the timestep form. Timestep-independent names are
characterized by the following property: any node "n1" of a timestep at
time t=x1, where "x1" is any permissible timestep, and any node "n2" of a
timestep at time t=x2, where "x2" is any permissible timestep other than
"x1," that have the same timestep-independent name, serve the same
function within their respective timesteps.

[1089]TF: Transformation Function. Identified in the Figures as any block
labeled "TF." The contents of a TF is defined to be purely combinational
logic.

[1090]Verilog HDL: A hardware description language. It is maintained as a
standard by the Institute of Electrical and Electronic Engineers (IEEE).
An example Verilog HDL standard is IEEE 1364.

[1091]While the invention has been described in conjunction with specific
embodiments, it is evident that many alternatives, modifications and
variations will be apparent to those skilled in the art in light of the
foregoing description. Accordingly, it is intended to embrace all such
alternatives, modifications and variations as fall within the spirit and
scope of the appended claims and equivalents.

Patent applications by Alfred Koelbl, Dachau DE

Patent applications by Carl Preston Pixley, Beaverton, OR US

Patent applications by SYNOPSYS, INC.

Patent applications in class DATABASE SCHEMA OR DATA STRUCTURE

Patent applications in all subclasses DATABASE SCHEMA OR DATA STRUCTURE