Target design model behavior explorer

Details Target design model behavior explorer Target design model behavior explorer

1999-07-29

2004-02-10

Broda, Esq., Samuel (Department: 2123)

Data processing: structural design, modeling, simulation, and em

Simulating electronic device or electrical system

Circuit simulation

C703S015000, C716S030000

Reexamination Certificate

active

06691078

ABSTRACT:

FIELD OF THE INVENTION
The present invention is in the general field of exploring the behavior of a design and in particular hardware design of a semiconductor chip.
BACKGROUND OF THE INVENTION
REFERENCES
[1] “Formal Methods in System Design—An International Journal” Edmund Clarke (Ed.) Kluwer Academic Publishing 1985-present.
[2] Sequential Logic Testing and Verification”, A Ghosh, S. Devadas and R. Newton, Kluwer Academic Publishing, 1992.
[3] “RuleBase: An Industry-Oriented Formal Verification Tool”, I. Beer, S. Ben-David, C. Eisner and A. Landver, Design Automation Conference 1996.
[4] “Model Checking the IBM Gigahertz Processor. An Abstraction Algorithm for High-Performance Netlists” by Jason Baymgartner, Tamir Heyman, Adnan Aziz and Vigyan Singhal, Proceedings of the 11
th
International Conference on Computer-Aided Verification (CAV99), N. Halbwachs and D. Peled (Eds.) Lecture Notes in Computer Science 1633, Springer Verlag, 1999.
[5] “Alliance Formal Verification Effort”, S. Mittlemeyar, presentation in the IBM Internal Verification Conference (VAT), September 1998.
[6] “Symbolic Model Checking”, K. McMillan, Kluwer Academic Publishing, 1993.
[7] “The Specification of Process Sychronization by Path Expression”, R. H. Campbel and A. N. Habermann, in Lecture Notes in Computer Science (G. Goos and J. Heartiness (ed.), Springer, N.Y., 1974, pp. 89-102).
[8] “Path expressions for complex queries and automatic database program conversion”. In Proceedings, Very Large Data Bases: 6
th
international conference, pp. 33-34, IEEE Computer Society, October 1980.
[9] Generalized Path Expression: A High-Level Debugging Mechanism”, B. Bruegge and P. Hibbard, J. of Systems and Software 3, 1983, pp. 265-276.
[10] “Switching and Finite Automata Theory” by Zvi Kohavi et al. McGraw Hill College Div.
[11] “On-The-Fly Model Checking of RCTL Formulas” by I. Beer, S. Ben-David and A. Landver, presented in the 1998 Conference on Computer-Aided Verification (CAV98)
The improvements in the silicon, computer and electronic related technologies gave rise to the design of very complicated integrated circuits (IC—referred to also as chips). This trend poses a real challenge to all those automatic and manual verification and inspection procedures which aim at filtering out bugs and faults during the design phase of the specified chips, and thereby to assure with high degree of certainty that faulty chip designs will not be forwarded to manufacture.
Accordingly, the industry is seeking improved technologies, tools and methodologies, to withstand these shortcomings. Thus, it has been suggested to use better techniques for static analysis, e.g. Formal Methods [1]. Such methods have been indeed successfully used in the verification of Finite State Machines (FSMs) in a variety of domains, notably hardware verification [2]. A second, methodological trend, is to ensure that verification starts as early as possible, and is not deferred to later design stages in which detection and correction of flaws is longer and costlier. In fact, an increasing number of design teams are introducing block-level debugging, or exploration, as an integral part of the product development cycle, before integrating the individual units into the target systems [3,4].
The debugging activity is the process in which the implementor explores and experiments with the FSM model by typically testing it against a subset of its feasible inputs. In doing so, the implementor gains insight into the behavior of the FSM model, detects design flaws and corrects them. The related activity of verification (which may or may not be done by the implementor) assures that the implemented FSM meets its functional requirements as thoroughly as possible. In this connection it should be noted that the difference between exploration and verification then, is that inter alia exploration is associated with the implementation process while verification is essentially a post-implementation process. Contemporary exploration methods are limited, as they are generally based on simulation, and require tedious specification of simulation scenarios, which are tested one at a time. That is, all inputs for the model (normally specifying explicitly input vectors) must be specified on a cycle-by-cycle basis to elicit each individual scenario of interest. In practice, given the limitations of contemporary exploration means, and further considering the labor-intensive tedious trial-and-error process, designers tend to carry out exploration of relatively low quality before delivering their FSM models to system verification.
1
1
System verification is the activity in which the individual components designed by separate designers are integrated and tested as a system.
Furthermore, the specified cycle-by-cycle process typically requires speculation of what input may drive the design towards the behavior of interest. The inherent parallelism of hardware, together with the inadequacy of the simulation platform for this purpose, render hardware exploration low-productivity activity.
The result is that detection of logic errors in the model are deferred to later verification stages where they are costlier to detect and fix, or even overlooked which is obviously undesired.
There is, accordingly, a need in the art to provide for exploration technique. There is a further need in the art to provide for a technique which obviates the specified cycle-by-cycle tedious trial-and-error procedures.
GLOSSARY OF TERMS
There follows now a glossary of terms, some being conventional and others have been coined herein. The definitions are provided for convenience of explanation only and should by no means be regarded as binding:
Term
Explanation
Finite State
For a definition of this term refer to
Machine (FSM);
standard texts, e.g. [10] [2], where,
Model
specifically, the concepts of states,
transitions and state variables,
inputs, signals and executions are
defined in detail.
Herein, any signals, state variables
and/or possibly inputs, are
collectively referred to as resources.
In this invention, the term FSM is used
also for referencing infinite-state
machines of which a finite-state subset
is subjected to examination.
Throughout the description of the
invention, reference is made to two
specific types of FSMs. One is the
design - which is the FSM being
subjected to analysis. The second
type is referred to as an auxiliary
FSM, which is an FSM representation of
a path specification (defined below).
The translation of path specifications
to FSMs is known in the literature
[11].
Model Checking
A formal analysis method used for
(MC)
static analysis of FSM. By one
application, it accepts as an input two
elements - an FSM and a temporal logic
formula and returns “true” if the
formula is true in the model, or
“false” and a counter example
otherwise.
Path scenario
A sequence of states through which the
design passes in one execution.
Path
A set ot constraints on the resources
specification
(see above) of the system, specifying
their values and/or interdependencies
over time. Path specification is
illustrated by the following
non-limiting examples:
(a)
in the first cycle a = 1, and in
the second cycle a = 0.
(b)
In the first cycle a = 1, then
in the second cycle a = 0 and
then in the third cycle either
b = 7 or c = 9.
(c)
a write command followed by a
read command. The read command
will receive a retry answer
and will consequently be
reissued.
NOTE:
In each of these examples, the path
specification in fact represents
multiple paths that meet the
specification, since no constraints
have been posed on the values of the
unspecified resources, and/or the
timing relationships between the points
in time at which specified resources
take specified values.
It should be noted that in example (c)
the terms write command, rd command are
shorthand for more elaborate
combinations of resource value whic

Affiliated with

Also associated with

Rating

Target design model behavior explorer does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Target design model behavior explorer, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Target design model behavior explorer will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3330443