Pre-Grant Publication Number: 20070162496
Please help the USPTO examine the application by evaluating the relevance of the publicly submitted prior art to the patent application.
Peer-to-Patent forwards the Top 10 most relevant prior art submissions and their annotations to the United States Patent and Trademark Office.
Review this prior art and click on the thumbs up (or down) to indicate whether this submission should be forwarded to the USPTO.
If you login then you can add an annotation by typing in the box at the bottom of the screen to comment on the relevance of the prior art to the claims of the patent application.
Review this prior art and click on the thumbs up (or down) to indicate whether this submission should be forwarded to the USPTO.
If you login then you can add an annotation by typing in the box at the bottom of the screen to comment on the relevance of the prior art to the claims of the patent application.
Prior Art Detail
Summary / Description
| Summary / Description | Paper providing an overview of comparing different types of models, and their attributes. |
Basic Information
| Type of Prior Art | Print Publication |
| Publication Title * | Transaction Level Modeling: An Overview |
| Author | Lukai Cai and Daniel Gajski |
| ISBN | |
| Page Range | |
| Medium | Journal article |
| Publication Date * | October 1, 2003 |
| URL | |
Notes / To Do
| Notes | |
Excerpt
Excerpt Modeling domain. It deals with languages and styles
of writing models. In other words, it deals with seman-
tics of different models used for different design tasks,
such as verification, refinement, and synthesis. System
modeling task can be simplified if the part of model
has been predefined as IP and saved in IP library. An
example of modeling is that designers can specify the
Model A using system level design languages such as
SpecC and SystemC.
The modeling styles of TLMs have been briefly discussed
in section 3. Especially, because communication
is completed separated from computation in
TLM, designers can specify different components of
one model at different abstraction levels. Such a model
is called multi-level model. Both SpecC and SystemC
support TLM modeling. The difference of modeling
TLMs using SpecC and SystemC is discussed in [8]. |
Relevance
Claims
1
A method for comparison of computer-based and data-processing models of a complex system, wherein a first model and a second model of the system are present, the models in each case model a system behaviour by way of predefined objects which represent activities and units within the system, and the method comprises the following steps:
comparing both models and determining predefined objects of the first and the second model, which objects are associated with one another in each case,
determining differences in attributes of predefined objects associated with one another, and
issuing the determined associations and differences to a user.
Relevance
This is exactly the idea behind Transaction Level Modeling in EDA. Here the designer is trying to verify the correctness of a system. To do this, typically they have several models of differing complexity/detail, and the simulation and/or formal verification reports differences for the important attributes (for example, the data read and written is normally crucial, but the exact time may not be). Also many of these are pre-defined as IP (PCI bus model, USB model, etc.)
This is exactly the idea behind Transaction Level Modeling in EDA. Here the designer is trying to verify the correctness of a system. To do this, typically they have several models of differing complexity/detail, and the simulation and/or formal verification reports differences for the important attributes (for example, the data read and written is normally crucial, but the exact time may not be). Also many of these are pre-defined as IP (PCI bus model, USB model, etc.)
Claim Chart
All
5
The method according to Claim 1, wherein the first and the second model in each case comprise
at least one first and a second modelling level on which the system in each case with different degrees of abstraction is represented by definition of objects and of links between the objects,
and associations or relations between objects of the first and of the second modelling level.
Relevance
This is normal for transaction level verification. Differences in levels of abstraction is the most common reason for having, and comparing, multiple models.
This is normal for transaction level verification. Differences in levels of abstraction is the most common reason for having, and comparing, multiple models.
Claim Chart
All
7
The method according to Claim 5, wherein the associations between the objects of the first and second modelling level represent a partial support of the objects of the first modelling level by the objects of the second modelling level.
Relevance
This is normal in transaction level modeling. The first conceptual model may be supported in whole or in part by the second physical model.
This is normal in transaction level modeling. The first conceptual model may be supported in whole or in part by the second physical model.
Claim Chart
All
9
The method according to Claim 5, wherein at least some objects on the first modelling level represent elements, wherein an element represents a real physical or logical unit, and wherein at least some objects on the second modelling level represent information and function units, wherein the information- and function units are data, programs or rules, and wherein the support of an element by an information and function unit expresses the fact that the element requires the information and function unit in order to be able to function.
Relevance
This is normal in transaction based verification. The designer starts with information and function representation, then verifies later that the equivalent model with real physical parts matches up in the important attributes.
This is normal in transaction based verification. The designer starts with information and function representation, then verifies later that the equivalent model with real physical parts matches up in the important attributes.
Claim Chart
All
10
The method according to Claim 1, wherein at least two models of the same system exist, a first model represents the system in a first condition and a second model the system in a second condition, and comprising the step of automatically determining actions for conveying the system from the first into the second condition is carried out.
Relevance
This is normal in transaction level design. The first model is a conceptual model, the second an actual implemtation in terms of hardware, and the transformation between them is carried out be a 'synthesis' step. See the article for details.
This is normal in transaction level design. The first model is a conceptual model, the second an actual implemtation in terms of hardware, and the transformation between them is carried out be a 'synthesis' step. See the article for details.
Claim Chart
All
15
A data processing system for modelling a system, wherein the data processing system comprises means for carrying out the method according to Claim 1.
Relevance
Transaction Level Modeling in EDA is normally implemented on a data processing system.
Transaction Level Modeling in EDA is normally implemented on a data processing system.
Claim Chart
All
16
A computer program for modelling a system, which may be loaded and implemented on a data processing unit, and which on implementation carries out the method according to Claim 1.
Relevance
Transaction level modeling is often implemented as a computer program.
Transaction level modeling is often implemented as a computer program.
Claim Chart
All
20
A method for comparison of computer-based and data-processing models of a complex system, wherein a first model represents the system in a first condition and a second model represents the system in a second condition, wherein the first and the second model in each case model a system behaviour by way of predefined objects which represent activities and units within the system, and the first and the second model in each case comprise
at least one first and a second modelling level on which the system in each case with different degrees of abstraction is represented by definition of objects and of links between the objects, wherein the links re resent an exchange or a transfer of working means, wherein a working means represents a physical unit or an information unit,
and associations or relations between objects of the first and of the second modelling level, representing a support of the objects of the first modelling level by the objects of the second modelling level,
and the method comprises the following steps:
comparing both models and determining predefined objects of the first and the second model, which objects are associated with one another in each case,
determining differences in attributes of predefined objects associated with one another,
automatically determining change actions from the associations and differences determined between the two models, which change actions convey, the system from the first condition into the second condition,
using the change actions for planning, and/or controlling changes of the system, the system being a technical installation or a production process.
Relevance
This is exactly the point of most transaction level verification in EDA - comparing two models, one conceptual and one physical, to make sure the relevant attributes are preserved.
This is exactly the point of most transaction level verification in EDA - comparing two models, one conceptual and one physical, to make sure the relevant attributes are preserved.
Claim Chart
All
