U.S. patent application number 11/285565 was filed with the patent office on 2006-04-06 for recognizing signals in design simulation.
This patent application is currently assigned to Intel Corporation. Invention is credited to David J. Harriman, Arthur D. JR. Hunter, Arvind B. Iyer.
Application Number | 20060074619 11/285565 |
Document ID | / |
Family ID | 25017032 |
Filed Date | 2006-04-06 |
United States Patent
Application |
20060074619 |
Kind Code |
A1 |
Harriman; David J. ; et
al. |
April 6, 2006 |
Recognizing signals in design simulation
Abstract
A transaction rule is used to recognize a set of simulation
signals obtained from a design simulation as a transaction. An
action associated with the transaction rule is executed to produce
an output identifying the transaction.
Inventors: |
Harriman; David J.;
(Portland, OR) ; Hunter; Arthur D. JR.; (Cameron
Park, CA) ; Iyer; Arvind B.; (San Jose, CA) |
Correspondence
Address: |
KACVINSKY LLC
4500 BROOKTREE ROAD
SUITE 102
WEXFORD
PA
15090
US
|
Assignee: |
Intel Corporation
|
Family ID: |
25017032 |
Appl. No.: |
11/285565 |
Filed: |
November 21, 2005 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
09750233 |
Dec 27, 2000 |
6993468 |
|
|
11285565 |
Nov 21, 2005 |
|
|
|
Current U.S.
Class: |
703/13 |
Current CPC
Class: |
G06F 30/33 20200101 |
Class at
Publication: |
703/013 |
International
Class: |
G06F 17/50 20060101
G06F017/50 |
Claims
1-27. (canceled)
28. A method comprising: receiving simulation signals from a design
simulation; applying a transaction rule to recognize a first set of
the simulation signals as a transaction; and applying an atomic
rule to recognize a second set of the simulation signals.
29. The method according to claim 28 further comprising:
successively defining the transaction rule using other rules so
that the transaction rule is defined by the simulation signals.
30. The method according to claim 28 further comprising: applying a
non-atomic rule to recognize a first set of atomic rules; and
applying the transaction rule to recognize a second set of atomic
rules and a set of non-atomic rules as the transaction
corresponding to the transaction rule.
31. The method according to claim 28 further comprising: placing in
a data structure one or more symbols corresponding to an atomic
rule associated with the simulation signals; replacing in the data
structure the one or more symbols corresponding to atomic rules
with one or more symbols corresponding to a non-atomic rule; and
replacing the one or more symbols corresponding to non-atomic rules
and the one or more symbols corresponding to atomic rules with one
or more symbols corresponding to the transaction rule.
32. A method comprising: defining a first transaction rule by
non-atomic rules; defining one or more atomic rules in terms of one
or more simulation signals.
33. The method according to claim 32 further comprising: placing in
a data structure a symbol corresponding to an atomic rule
associated with the simulation signals; replacing in the data
structure one or more symbols corresponding to atomic rules with a
symbol corresponding to a non-atomic rule; and replacing one or
more symbols corresponding to non-atomic rules and one or more
symbols corresponding to atomic rules with a symbol corresponding
to the first transaction rule.
34. The method according to claim 32 further comprising: defining a
second transaction rule to recognize a permutation of the atomic
rules as the transaction.
35. An article comprising a computer-readable medium that stores
computer-executable instructions for causing a computer system to:
receive simulation signals from a design simulation; apply a
transaction rule to recognize a first set of the simulation signals
as a transaction; and apply an atomic rule to recognize a second
set of the simulation signals.
36. The article according to claim 35 further including instruction
for causing the computer system to: successively define the
transaction rule with other rules so that the transaction rule is
defined by the simulation signals.
37. The article according to claim 35 further including instruction
for causing the computer system to: apply a non-atomic rule to
recognize a first set of atomic rules; and apply the transaction
rule to recognize a second set of atomic rules and a set of
non-atomic rules as the transaction corresponding to the
transaction rule.
38. The article according to claim 35 further including instruction
for causing the computer system to: place in a data structure one
or more symbol corresponding to an atomic rule associated with the
simulation signals; replace in the data structure the one or more
symbols corresponding to atomic rules with one or more
corresponding to a non-atomic rule; and replace the one or more
symbols corresponding to non-atomic rules and the one or more
symbols corresponding to atomic rules with one or more symbols
corresponding to the transaction rule.
39. An article comprising a computer-readable medium that stores
computer-executable instructions for causing a computer system to:
define a first transaction rule by non-atomic rules; and define one
or more atomic rules in terms of one or more simulation
signals.
40. The article according to claim 39 further including instruction
for causing the computer system to: place in a data structure a
symbol corresponding to an atomic rule associated with the
simulation signals; replace in the data structure one or more
symbols corresponding to atomic rules with a symbol corresponding
to a non-atomic rule; and replace one or more symbols corresponding
to non-atomic rules and one or more symbols corresponding to atomic
rules with a symbol corresponding to the transaction rule.
41. The article according to claim 39 further including instruction
for causing the computer system to: define a second transaction
rule to recognize a permutation of the atomic rules as the
transaction.
42. An apparatus comprising: a processor to: receive simulation
signals; apply a transaction rule to recognize a first set of the
simulation signals as a transaction; and apply an atomic rule to
recognize a second set of the simulation signals.
43. The apparatus according to claim 42 wherein the processor is
further configured to: successively define the transaction rule
with other rules so that the transaction rule is defined by the
simulation signals.
44. The apparatus according to claim 42 wherein the processor is
to: apply a non-atomic rule to recognize a first set of atomic
rules; and apply the transaction rule to recognize a second set of
atomic rules and a set of non-atomic rules as the transaction
corresponding to the transaction rule.
45. The apparatus according to claim 42 wherein the processor is
to: place in a data structure one or more symbols corresponding to
an atomic rule associated with the simulation signals; replace in
the data structure the one or more symbols corresponding to atomic
rules with one or more corresponding to a non-atomic rule; and
replace the one or more symbols corresponding to non-atomic rules
and the one or more symbols corresponding to atomic rules with one
or more symbols corresponding to the transaction rule.
46. An apparatus comprising: a processor to: receive simulation
signals; define a first transaction rule by non-atomic rules; and
define one or more atomic rules in terms of one or more simulation
signals.
47. The apparatus according to claim 46 wherein the processor is
to: place in a data structure a symbol corresponding to an atomic
rule associated with the simulation signals; replace in the data
structure one or more symbols corresponding to atomic rules with a
symbol corresponding to a non-atomic rule; and replace one or more
symbols corresponding to non-atomic rules and one or more symbols
corresponding to atomic rules with a symbol corresponding to the
transaction rule.
48. The apparatus according to claim 46 wherein the processor is
further configured to: define a second transaction rule to
recognize a permutation of the atomic rules as the transaction.
49. A method comprising: determining whether an atomic rule applies
to a simulation signal; placing in a data structure a first symbol
corresponding to the atomic rule; and applying a non-atomic rule to
the first symbol.
50. The method of claim 49, comprising: comparing the first symbol
to the second symbol.
51. The method of claim 50, comprising: replacing in the data
structure the first symbol with the second symbol.
52. The method of claim 49, comprising: recognizing a transaction
when a third symbol is placed in the data structure.
53. The method of claim 52, comprising: emptying the data structure
when the transaction is recognized.
Description
BACKGROUND
[0001] The invention relates to recognizing signals in design
simulation.
[0002] To determine whether a hardware or a system design will
perform as intended, the design is often simulated to produce
simulated signals. Specific sets of the simulated signals make up
transactions or protocols. A transaction is a set of signals that
indicate a unit of interactions such as a read or write operation.
A protocol refers to signals that define rules of data
transmission.
[0003] Simulated transactions or protocols conventionally are
verified either by producing specific signal events and data during
the simulation, which is time-consuming, or using an unstructured
ad-hoc post-processing program on the simulation output.
Simulations of lower-level designs are not easily extendible to
higher-level designs, such as full-chip or system-level
designs.
BRIEF DESCRIPTION OF THE DRAWINGS
[0004] FIG. 1 shows a flow of tracking and checking
transactions.
[0005] FIG. 2 shows a table of rules and actions.
[0006] FIG. 3 shows a table of a partial signal event list.
[0007] FIG. 4 shows a time-evolving stack.
[0008] FIG. 5 illustrates how the stack is manipulated.
[0009] FIG. 6 illustrates a design simulation. boundary of a design
under test. The event list file 20 can be generated for every test
by the simulator 10. The file 20 can be stored as character strings
that are read from left to right.
[0010] A front-end reader called a unit tracker and checker (UTC)
30 reads the signal events and keeps track of the state of the
events at each rising edge of a clock signal. Because signals are
relevant at the clock rising edge for many logic circuit designs,
the UTC 30 is configured to filter out signal events between clock
cycles and to present the state of signal events at each clock
rising edge as signal values 40. For example, assuming that the
clock cycle is 10 nanoseconds (ns), if the signal event list shows
that A=1 and B=1 at 121 ns and A=0 at 123 ns, the UTC 30 presents
A=0 and B=1 at the clock rising edge at 130 ns.
[0011] The signal values 40 are read by a recognition program 45
generated by a unit tracker and checker yet another compiler
compiler (UTCYACC) program 50. The UTCYACC program incorporates
production rules 60, each of which is coupled to a corresponding
action 70, into the program 45. The program 45 uses the production
rules and the actions 70 to recognize transactions or protocols in
the signal values 40.
[0012] The production rules 60 are formal languages comprising
atomic rules. An atomic rule interprets a set of atomic signal
events, each of which is an indivisible unit of interaction, for
example, between devices. Atomic signal events are found in the
event list file 20. The production rules 60 include "read
transaction" and "write transaction."
[0013] Additionally, each production rule 60 is accompanied by an
action 70, which is a set of tasks to be executed whenever the
production rule applies. One such action 70 involves printing out a
transaction output 90 which may contain such information as event
time, cycle identification, transaction and event identification.
The action 70 can further print out details of a transaction, such
as operation code (opcode), length, address, byte enable, and data,
and may indicate whether the transaction was completed successfully
or whether errors were incurred. Additionally, the action 70 can
perform coherency checks and compute user-defined values for later
use.
[0014] At a clock rising edge, the action 70 manipulates the atomic
rules extracted from the signal values 40 using a stack 80. Details
of how the stack 80 are used to recognize a transaction are
described below.
[0015] Context-independent formal languages are used to model a
transaction. The formal languages are a set of rules that define
the transaction successively until atomic signal events are
obtained. For example, FIG. 6 shows a unit (U) subject to testing.
One of the transactions that the unit (U) can perform is a read
operation from an output/input device controller (D) to a memory
controller (M). In the following discussion, such a read
transaction is designated symbolically as DMRead.
[0016] The device controller (D) presents a read command (DUcmd) to
the unit (U). After several clock cycles, the unit (U) presents a
command (UMcmd) to the memory controller (M). The memory controller
(M) responds to the unit (U) with data (MUdata) after several more
clock cycles. Then, the unit (U) responds to the device controller
(D) with the data (UDdata).
[0017] The read transaction rule can be written as follows:
[0018] DMRead :=DUcmd UMcmd MUdata UDdata.
[0019] The above rule includes a rule symbol (left-hand side) and
production symbols (right-hand side). The rule is an example of a
non-atomic rule that requires further definition. The
device-to-unit read command, DUcmd, can be defined, for example, in
terms of handshake signals, that is, atomic signal events,
designated DUcavail and UDcget:
[0020] DUcmd :=(DUcavail=1) AND (UDcget=1).
[0021] As shown in FIG. 6, the handshake signal DUcavail is
transmitted from the device controller (D) to the unit (U). The
unit (U) responds by sending the handshake signal UDcget to the
device controller (D). The device-to-unit command, DUcmd, including
signals such as device address and opcode, is then sent to the unit
(U). In other words, if the handshaking signals are detected, the
command signals (DUcmd) are sent from the device controller (D) to
the unit (U). No further breakdown of this rule is required because
atomic signal events have been obtained. Therefore, the
device-to-unit command, DUcmd, is an example of an atomic rule.
[0022] Similarly, the unit-to-memory command, UMcmd, can be defined
as follows:
[0023] UMcmd :=(UMcavail=) AND (MUcget=1).
[0024] For the purpose of illustration, it is assumed that
memory-to-unit data, MUdata, is transferred in two clock cycles and
unit-to-device data, UDdata, is transferred in one to four clock
cycles, depending on the data length. The memory-to-unit data,
MUdata, and the unit-to-device data, UDdata, can be defined as
follows: [0025] MUdata :=MUdxfer MUdxfer, [0026] UDdata UDdxfer,
and [0027] UDdata :=UDdata UDdxfer.
[0028] The MUdata rule specifies two data transfers. The two UDdata
rules constitute a recursive definition and can specify any number
of data transfers. The first UDdata is defined as one data
transfer, and the second UDdata is defined as UDdata followed by a
data transfer.
[0029] The non-atomic rules MUdxfer and UDdxfer can be defined as
atomic rules using handshake signals as follows: [0030] MUdxfer
:=(MUdavail=1) AND (UMdget=1), and [0031] UDdxfer :=(UDdavail=1)
AND (DUdget=1).
[0032] The foregoing rules, along with corresponding actions, are
summarized in FIG. 2.
[0033] The UTCYACC program 50 generates the recognition program 45,
which applies the read transaction rules to the event list 20
generated by the simulator 10 to recognize the read transaction.
The recognition program 45 is a stack-based engine that executes
the user-defined action 70 that manipulates the stack 80 whenever
the rule applies.
[0034] The manipulation of the stack 80 is shown in FIG. 5. The
program 45 checks (100) whether each atomic rule applies to the
signal events. If a particular rule applies, the program 45 places
(110) the applicable rule symbol on top of the stack. A stack is a
data structure for storing items that are to be accessed in
last-in, first-out order.
[0035] The program 45 then reduces (120) the stack by applying the
appropriate non-atomic rules. This involves comparing symbols on
top of the stack to production symbols of the non-atomic rules. If
the symbols on the stack match the production symbols (e.g. MUdxfer
MUdxfer), the program 45 removes (130) the appropriate number of
production symbols from the stack and pushes (140) the appropriate
rule symbol (MUdata) onto the stack in their place.
[0036] When the stack contains a top-level symbol (e.g. DMRead),
the transaction is recognized (150) and the stack is emptied.
[0037] If the end of the event list 20 is reached and the stack is
not empty, the program 45 reports (160) that an error occurred and
that the transaction was not completed.
[0038] FIG. 3 shows an example of a partial event list for a read
transaction. The event list as shown is not filtered by the UTC 30.
A clock period of 10 ns interval is assumed. FIG. 4 shows how the
contents of the stack are modified according to the application of
rules by the program 45 through this event list.
[0039] At time 40 ns, the program 45 recognizes the atomic events
DUcavail=1 and UDcget=1 corresponding to DUcmd, and the command
gets placed on top of the stack as shown in FIG. 4. At time 60 ns,
another command (UMcmd) is recognized and is placed on top of the
stack. At time 90 ns, a data transfer (MUdxfer) is recognized and
is placed on the stack. At time 100 ns, a clock cycle later,
another data transfer is recognized and is placed on top of the
stack. The program 45 applies a non-atomic rule (see FIG. 2),
removes MUdxfer MUdxfer from the stack and places MUdata on top of
the stack.
[0040] At time 120 ns, a data transfer (UDdxfer) is recognized and
placed on the stack. The non-atomic, first UDdata rule (see FIG. 2)
is used to replace UDdxfer with UDdata. At time 130 ns, another
UDdxfer is recognnized and is placed on the stack. The second
UDdata rule (see FIG. 2) is applied to remove UDdxfer UDdata and to
place UDdata on the stack. The program 45 then recognizes that the
stacked symbols, UDdata MUdata UMcmd DUcmd, correspond to the
transaction symbol DMRead and removes the symbols to place DMRead
on top of the stack. Subsequently, DMRead is recognized as a
top-level symbol, and the stack is emptied. The functions of
removing symbols from the stack and placing them on the stack are
executed by the actions 70.
[0041] In addition to manipulating the stack 80, the actions 70
specify user-defined tasks. This includes printing useful signal
values, performing coherency checks, and computing other values of
interest. For example, the action, DUcmd_act( ) can be coded to
check if the transaction is a read command transfer, to obtain
current stack/cycle identification for the transaction, to place
DUcmd on the stack, to print cycle identification and signal values
such as address, opcode and length, to compute the number of data
transfers, and to increment the cycle identification for the next
DUcmd event.
[0042] Similary, the action for UDdxfer can be coded to obtain
current stack/cycle identification for the transaction, to count
down the number of data transfers, to place UDdxfer on the stack,
to print cycle identification and signal values, to check the data
against what was obtained on the memory-to-unit data event, and to
move to the next cycle if all data transfers are done.
[0043] The foregoing examples represent actions for atomic rules.
Actions for a non-atomic rule, such as UDdata_act(n), can be coded
to obtain current stack/cycle identification for the transaction,
to remove n symbols from the stack and to place UDdata on the
stack. Similary, the action for the non-atomic rule DMRead_act( )
can be coded to obtain current stack/cycle identification for the
transaction, to check to see that all unit-to-device data transfers
are done, to remove four symbols from the stack and to print "Done"
if the stack is empty.
[0044] Any non-empty stack is reported as an incomplete transaction
and the contents of the stack are printed to indicate the events
completed at that time.
[0045] The ordering of atomic rules can be important in some
instances. For example, a DUcmd event occurs before a UMcmd event,
and the rules should reflect this order. Similarly, non-atomic
rules should be ordered to reduce the stack. For example, a DMRead
rule should be applied after a DUdata rule is applied.
[0046] Some tests may have more than one instance of a transaction
cycle. Each transaction can be tracked by using a separate stack
that is uniquely identified by the cycle-identification. The
cycle-identification is incremented when a new transaction begins.
For example, two DUcmd events would imply that the second DUcmd
should be assigned to the next stack.
[0047] If the design unit (U) also performs another transaction
such as a write transaction, there should be separate rules and
actions table for DMWrite. The UTCYACC program 50 can incorporte
write transaction rules into the recognition program 45. Thus, the
system would be reporting transaction events that they individually
recognize.
[0048] If different transactions such as read or write transactions
share the same signal events, such as DUcmd, then an opcode can be
used to uniquely identify which transaction applies. An additional
check on the opcode in the DUcmd rule can be implemented to address
this type of situation.
[0049] To illustrate, it is assumed that there are two instances of
read transaction with the event list below: [0050] DUcmd.sub.1
DUcmd.sub.2 UMcmd.sub.2 UMcmd.sub.1 . . . The UMcmd.sub.2 event for
the second cycle occurs before the first and the recognition
program 45 will incorrectly associate the UMcmd.sub.2 event with
the first stack. To address this situation, either an ordering
algorithm can be implemented or the address bits can be used to
identify the cycle uniquely. Alternatively, the internal signals in
the event list in addition to those at the boundary may be used in
the rules or actions to distinguish the events.
[0051] The unit (U) may retry an event based on a preferred
condition, such as a time-out. In that case, the retry condition
should be part of the rules 60. Alternatively, the program 45,
internal signals, or unique signal values can be used to detect
retry events.
[0052] A transaction rule may be represented by different
permutations of production symbols. For example, assume that a rule
for DMWrite can be expressed as follows:
[0053] DMWrite :=DUcmd DUdata UMcmd UMdata.
[0054] It may be valid for the unit-to-memory command transfer to
occur before any device-to-unit data transfer. Thus, the following
rule is valid also:
[0055] DMWrite :=DUcmd UMcmd DUdata UMdata.
[0056] As long as all permutations of the rule are specified, the
stack-based approach is able to handle the different
situations.
[0057] A set of rules and actions to detect an incorrect signal
assertion or de-assertion can be created. Garbage collection rules
can be used to detect invalid opcodes, invalid signal values during
reset and hanging signals. These rules can be useful in increasing
the coverage of the checks and can be extended to include all
signals.
[0058] The foregoing techniques can be implemented in a program
executable on a computer system. The program can be stored on a
storage medium readable by a general or special purpose
programmable computer system. The storage medium is read by the
computer system to perform the functions described above.
[0059] The invention can also be implemented using digital logic
hardware.
[0060] Other implementations are within the scope of the following
claims.
* * * * *