U.S. patent application number 10/630891 was filed with the patent office on 2004-08-05 for defining breakpoints and viewpoints in the software development environment for programmable stream computers.
Invention is credited to Woodall, Thomas R..
Application Number | 20040153818 10/630891 |
Document ID | / |
Family ID | 21975343 |
Filed Date | 2004-08-05 |
United States Patent
Application |
20040153818 |
Kind Code |
A1 |
Woodall, Thomas R. |
August 5, 2004 |
Defining breakpoints and viewpoints in the software development
environment for programmable stream computers
Abstract
A stream computer has a first plurality of interconnected
functional units. The functional units are responsive to a data
stream containing data and tokens. The data is to be operated on by
one or more of the first plurality of interconnected functional
units. A second plurality of said interconnected functional units,
also part of said stream computer units, are allocated for
comparing the data stream with a debug stream to generate debug
signals. Reporting logic is responsive to the debug signals for
reporting the occurrence of matches between the data stream and the
debug stream in a format compatible for human perception. The
second plurality of interconnected functional units generate
viewpoints and breakpoints in response to similarities between the
data streams present within the stream computer and the debug
stream. The breakpoint can either interrupt the data stream or let
it pass through. Viewpoints do not change the streams they examine.
The reporting logic is compatible with a graphical user interface,
where the graphical user interface identifies the functional units,
input and output streams of each of the functional units.
Inventors: |
Woodall, Thomas R.;
(Valencia, CA) |
Correspondence
Address: |
Leonard A. Alkov, Esq.
Raytheon Company
P.O. Box 902 (E4/N119)
El Segundo
CA
90245-0902
US
|
Family ID: |
21975343 |
Appl. No.: |
10/630891 |
Filed: |
July 30, 2003 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10630891 |
Jul 30, 2003 |
|
|
|
10052082 |
Jan 17, 2002 |
|
|
|
Current U.S.
Class: |
714/37 ;
712/E9.071 |
Current CPC
Class: |
G06F 9/3891 20130101;
G06F 15/7867 20130101; G06F 9/3897 20130101 |
Class at
Publication: |
714/037 |
International
Class: |
G06F 011/30 |
Claims
I claim:
1. A stream computer, said stream computer comprising: a plurality
of interconnected functional units, each of said functional units
responsive to a data stream containing data to be operated on by
one or more of said functional units; digital logic cooperatively
associated with one of said functional units for comparing said
data stream presented to said one of said functional units with a
debug stream; reporting logic associated with said digital logic
for reporting the occurrence of matches between said data stream
and said debug stream.
2. A stream computer as described in claim 1 wherein said digital
logic extracts similarities between said data stream and said debug
stream to generate a viewpoint.
3. A stream computer as described in claim 2 wherein said digital
logic generates said viewpoint without interrupting said data
stream.
4. A stream computer as described in claim 1 wherein said digital
logic extracts similarities between said data stream and said debug
stream to induce a breakpoint.
5. A stream computer as described in claim 4 wherein said digital
logic extracts similarities between said data stream and said debug
stream to induce said breakpoint in response to a breakpoint number
arriving at said digital logic.
6. A stream computer as described in claim 4 wherein said digital
logic generates said breakpoint and interrupts said data stream
passing through said digital logic.
7. A stream computer as described in claim 4 wherein said digital
logic generates said breakpoint and allows said data stream to pass
through.
8. A stream computer as described in claim 1 wherein said at least
one of said plurality of interconnected functional units, said
digital logic, and said reporting logic are integrated on a single
substrate.
9. A stream computer as described in claim 1 wherein said reporting
logic are compatible with a graphical user interface, said
graphical user interface identifying said functional units, and
inputs and outputs of said functional units.
10. A stream computer as described in claim 1 wherein one or more
of said functional units are reconfigured to become part of said
digital logic.
11. A stream computer as described in claim 1 wherein said digital
logic further comprises arithmetic logic units (ALU) and memory
functions, said functions obtained by allocating some functional
units to perform said ALU and memory functions.
12. A stream computer, said stream computer comprising: a first
plurality of interconnected functional units, said functional units
responsive to a data stream containing data and tokens to be
operated on by one or more of said first plurality of
interconnected functional units; a second plurality of said
interconnected functional units allocated for comparing said data
stream, and internal streams within said stream computer, with a
debug stream to generate debug signals; reporting logic responsive
to said debug signals for reporting the occurrence of matches
between said data stream and said debug stream compatible with
human perception.
13. A stream computer as described in claim 12 wherein said second
plurality of interconnected functional units extracts similarities
between said data stream and said debug stream to generate a
viewpoint.
14. A stream computer as described in claim 13 wherein said second
plurality of interconnected functional units generates said
viewpoint without interrupting said data stream.
15. A stream computer as described in claim 12 wherein said second
plurality of interconnected functional units extracts similarities
between said data stream and said debug stream to induce a
breakpoint.
16. A stream computer as described in claim 15 wherein said second
plurality of interconnected functional units extracts similarities
between said data stream and said debug stream to induce said
breakpoint in response to a breakpoint number.
17. A stream computer as described in claim 15 wherein said second
plurality of interconnected functional units generates said
breakpoint and interrupts said data stream.
18. A stream computer as described in claim 15 wherein said second
plurality of interconnected functional units generates said
breakpoint and allows said data stream to pass through.
19. A stream computer as described in claim 12 wherein at least one
of said plurality of interconnected functional units, and said
reporting logic are integrated on a single substrate.
20. A stream computer as described in claim 12 wherein said
reporting logic is compatible with a graphical user interface, said
graphical user interface identifying said functional units, and
inputs and outputs of said functional units.
21. A method for operating a stream computer, said method
comprising the steps of: programming a first plurality of
interconnected functional units forming said stream computer to
compute in accordance with data and token contained in a data
stream; programming a second plurality of said interconnected
functional units forming said stream computer to compare said data
stream, and internal streams within said stream computer, with a
debug stream; reporting the occurrence of matches between said data
stream and said debug stream using symbols compatible with human
perception.
22. A method as described in claim 21 further including the step of
extracting similarities between said data stream and said debug
stream to generate a viewpoint, using said second plurality of
interconnected functional units.
23. A method as described in claim 22 wherein said step of
extracting similarities by said second plurality of interconnected
functional units generates said viewpoint without interrupting said
data stream.
24. A method as described in claim 21 wherein said step of
extracting similarities by said second plurality of interconnected
functional units between said data stream and said debug stream
induces a breakpoint.
25. A method as described in claim 24 wherein said step of
extracting similarities by said second plurality of interconnected
functional units also induces said breakpoint in response to a
breakpoint number.
26. A method as described in claim 24 wherein inducing said
breakpoint interrupts said data stream.
27. A method as described in claim 24 wherein inducing said
breakpoint allows said data stream to pass through.
28. A method as described in claim 21 computer wherein said
reporting step generates information compatible with a graphical
user interface, said graphical user interface identifying said
functional units, and inputs and outputs of said functional units.
Description
[0001] This application is a continuation in part of U.S. Patent
and Trademark Office application Ser. No. 10,052,082 titled
"Reconfigurable Processor Architectures".
BACKGROUND OF THE INVENTION
[0002] 1. Field of Invention
[0003] This invention is in the field of software development using
breakpoints and viewpoints for use in stream computers.
[0004] 2. Description of the Related Art
[0005] Software, the instructions for a computer to follow, are
necessary to perform a particular function and render the computer
useful. Developing a properly executing software package, possibly
comprising thousands of computer instructions, or steps, is an
arduous task. Ideally, in a quality software package, all computer
instructions are correct and in the proper sequence, errors have
been identified and corrected, and desired functions completely
implemented.
[0006] In arriving at a quality software package, generally an
iteration method is used wherein executable instructions, or code,
are written into registers or memory locations and then presented
for execution on the target computer. After examining results of
code execution, its effects on the registers and memory locations,
the code is modified to correct any errors that may have been
found. Thus, during the software development process, code
compatible tools are needed that allow the examination of various
machine states at certain points in the execution of a program to
insure that the software is performing the desired function and
specified results are reached. Like the oscilloscope is a tool
allowing the builder of electronic circuits to "see" circuits in
operation, a similar tool is developed for the software engineer.
This tool allows the examination of registers and memory locations
following the particular execution of one or more instructions thus
tracing the changes brought on by executing the computer
instructions.
[0007] In prior art, Von Newman type, central control computers,
progress of execution of computer instructions is typically
performed by examining register contents at certain time intervals
corresponding to events chosen by the programmer. These events are
defined with the aid of a a compiler or other software tool having
the capability of stopping execution and presenting the specific
contents of registers and memory locations for inspection and
evaluation.
[0008] Prior art software tools allowing the step by step
examination of registers and memory location in Von Newman
architecture computers are well known. However, with the advent of
distributed, stream computers described in the parent application,
the software tools relevant in single central processing unit (CPU)
Von Newman architectures are no longer applicable, in fact,
impossible to use. The prior art tools depend on a central entity,
the central processing unit to transfer and process information
between various parts of a computer. Thus, this one central entity,
is responsible for program progress and is the area to be
monitored. In this invention, in contrast, there are pluralities of
independent processing entities, having no relationship to the Von
Newman structure, function or concept.
SUMMARY OF THE INVENTION
[0009] Above limitations are solved by the present invention by a
stream computer, said stream computer comprising a first plurality
of interconnected functional units. The functional units are
responsive to a data stream containing data and tokens. The data is
to be operated on by one or more of said first plurality of
interconnected functional units.
[0010] A second plurality of said interconnected functional units,
also part of said stream computer, are allocated for comparing said
data stream with a debug stream to generate debug signals.
Reporting logic is responsive to the debug signals for reporting
the occurrence of matches between said data stream and said debug
stream in a format compatible for human perception.
[0011] The second plurality of interconnected functional units
generate viewpoints and breakpoints in response to similarities
between the data streams present within said stream computer and
the debug stream(s). The breakpoint can either interrupt the data
stream or pass it through. Viewpoints do not change the streams
they examine, but only extract information therefrom matching said
debug stream.
[0012] The reporting logic is compatible with a graphical user
interface, where the graphical user interface identifies the
functional units, inputs and outputs (streams) to or from the
functional units, as well as streams between the functional
units.
BRIEF DESCRIPTION OF THE DRAWING
[0013] In the Drawing:
[0014] FIG. 1 is an exemplary configuration of prior art Von
Newman, single control computer architecture.
[0015] FIG. 2 is an exemplary graphic representation of a problem
to be solved using stream computers;
[0016] FIG. 3 is an exemplary user defined function of the problem
in FIG. 2 via a graphical interface;
[0017] FIG. 4 is the user defined function of FIG. 3, further
refined and ready to run on a target computer or compatible
simulator;
[0018] FIG. 5 shows a typical breakpoints and viewpoints depiction
for the Graphical Programming Environment of this invention for the
problem of FIG. 4;
[0019] FIG. 6 shows details of breakpoint and viewpoints applied to
the exemplary stream computer described herein;
[0020] FIG. 7 shows an example of digital logic implementing a
breakpoint applicable to this invention;
[0021] FIG. 8 shows an example of digital logic implementing a
viewpoint applicable to this invention;
[0022] FIG. 9 shows an example of allocating part of a stream
computer to implement the digital logic required to generate
breakpoints and viewpoints.
DETAILED DESCRIPTION
[0023] The present invention describes an apparatus and method of
inducing breakpoints and initiating viewpoints during the
programming of a stream computer.
[0024] The stream computer comprises a first plurality of
interconnected functional units. The functional units are
responsive to a data stream containing data and tokens. The data is
to be operated on by one or more of said first plurality of
interconnected functional units.
[0025] A second plurality of said interconnected functional units,
also part of said stream computer, are allocated for comparing said
data stream, as well as other streams internal to the computer,
with a debug stream to generate debug signals. Reporting logic is
responsive to the debug signals for reporting the occurrence of
matches between said data stream and said debug stream in a format
compatible for human perception.
[0026] The second plurality of interconnected functional units
generate viewpoints and breakpoints in response to similarities
between the data streams present within said stream computer and
the debug stream(s). The breakpoint can either interrupts the data
stream or pass it through. Viewpoints do not change the streams
they examine.
[0027] The reporting logic is compatible with a graphical user
interface, where the graphical user interface has symbols
identifying in human compatible format the functional units, and
inputs and outputs (streams) to or from the functional units.
[0028] Stream computers are collections of functional units (nodes)
operationally interconnected via software streams in addition to
hardware links. More specifically, stream computers comprise a
plurality of similar functional units where the specification of
the computer (and the programming thereof) is defined by the
operations performed by the functional units and the streams (also
known as data flows) that connect, or traverse the functional
units. Thus, the specification of a computer program for stream
computers is defined by the operations performed by the functional
units and the streams (also known as data flows) that connect the
functional units.
[0029] The functional units perform prescribed operations on the
input(s) and create output(s) when all inputs are valid and the
output flow can accept the output. The software streams flowing
between functional units contain data, for example, integer data.
Some stream computers also have control/token information as part
of the data, generally at most a few bits, or a small percentage of
the data bits. This control/token information also flows along with
the data between functional units. The token information is not
operated on (e.g. added, multiplied) but rather is used to
determine what operation the functional units perform.
[0030] In contrast to stream computers, FIG. 1 is an exemplary Von
Newman computer structure of the prior art. A control unit 107
monitors the transfer of digital information between memory 101,
Arithmetic and Logic Unit (ALU) 103, and Input/Output unit 105.
Typically, control unit 107 will instruct ALU 103 to fetch contents
of a particular location within memory 101, perform a mathematical
or logical operation on the retrieved data, then write the results
at another location within memory 101. Control unit 107 can
interpret an instruction retrieved from memory 101 and select
alternative courses of action based on the results of previous
operations. Memory 101 contains both data and instructions to be
followed by control unit 107 and/or ALU 103. The instructions can
be followed in any order. Similarly, control unit 107 will instruct
Input/Output (I/O) unit 105 to make ready data for ALU 103 to read.
Thus, for software development purposes, monitoring control unit
107, contents of memory 101 and I/O 105 will suffice to ascertain
the state of the computer on a step by step basis and monitor
progress of program execution. Compilers of the prior art provide
break points within a sequence of executed steps by control unit
107. The break points typically halt the execution of program steps
within control unit 107 and list contents of certain locations
within memory 101 for inspection and reconciliation with expected
values. In Von Newman architectures, there is no flow of data to a
plurality of functional units, each capable of computing the
required results. Von Newman architectures can be viewed as having
centralized control, while stream computers represent a distributed
structure with much duplication of individual functional units
where each functional unit reacts independently of the others and
computes results under control of flowing data and tokens.
[0031] To accommodate the distributed nature of stream computers,
and facilitate software development for them, this invention
inserts breakpoint and viewpoint logic into the definition (or
program) of a programmable stream computer. This functionality is
best implemented in a graphical programming environment and the
examples illustrating the best mode of the invention use such an
environment.
[0032] The examples in this invention are illustrated by the use of
a simple polynomial equation to illustrate the characteristics of
this invention. Typically a large number, perhaps hundreds, of
functional units exemplified below are interconnected to compute
Fast Fourier Transforms, or matched filter functions.
[0033] A simple, general illustrative equation is used:
Y=PX.sup.2+QX+R
[0034] where P, Q, R and X are inputs and Y is the output. For
simplicity, X and Y are the only dynamic data streams and P, Q, and
R are constants (i.e. registers preloaded with constant values)
whereas a new value of X is potentially available on the input
stream for every clock pulse.
[0035] As shown in FIG. 2, in this example, the fundamental
(primitive) functional unit in the sample computer is a functional
unit 202 capable of performing a multiplication in multiplier 206
and an addition in adder 208. The results from multiplier 206 are
combined with an addition in adder 208. While this example shows a
multiplier 206 and adder 208, any other functions can be
substituted, depending on computational needs.
[0036] Functional unit 202 is shown by the dashed line and in later
figures will be identified as a MUL. Functional unit 204 is
structurally similar to functional unit 202, having a multiplier
212 and adder 214 to generate an output Y.
[0037] Delay 210 applied to X matches the delay experienced in
functional unit 202. Without delay 210, X would be presented to
functional unit 204 before the result from functional unit 202,
PX+Q, was ready. This facilitates keeping the pipeline full.
[0038] From the diagram in FIG. 2, the output Y is the result of
PX.sup.2+QX+R, as computed by functional units 202 and 204.
[0039] Breakpoints and Viewpoints
[0040] In a graphical programming environment to be used with this
invention, the user graphically represents the function being
performed. In this example, as shown in FIG. 3, a user defined
function for the same equation as in FIG. 2 Y=PX.sup.2+QX+R is
being defined. In the graphical interface, MUL 301 is the hardware
functional unit 202, while MUL 303 is the hardware functional unit
303. The delay 305 for X is also provided to facilitate the
operation of the pipeline.
[0041] In the graphical interface, for this example, the user
selects each data flow and selects the data types. The user also
selects the function and specifies the function to be performed by
MUL 301 and MUL 303. In this case, the function of MUL 301 and MUL
303 is a multiply with an add.
[0042] Typically, having completed the specification of the
functional units, the specification will be executed on a simulator
or directly in hardware. The graphical representation shown in FIG.
4, is an example of the structure of FIG. 3. The graphical
representation is compiled to generate an executable program. The
executable to compute Y=2X.sup.2+3X+4 is then run on a target
computer or simulator. The details of compilation of a
specification, and running the compilation on a target (whether
real hardware or a simulation) are well known, and therefore not
detailed further.
[0043] The development environment of this invention inserts the
breakpoint and viewpoint specifications into the executable program
generated from FIG. 4. The breakpoint and viewpoint specifications
are loaded as part of the program image in FIG. 5. The capabilities
are fully programmable. The graphical programming environment
incorporates the details. The programmer sees the view as shown in
FIG. 5. The other mechanistic, underlying details are conveniently
shielded from the user to facilitate the development process.
[0044] Once a breakpoint and/or viewpoint is defined, the graphical
interface saves the definition but allows the user to determine
whether or not specific breakpoints and viewpoints are incorporated
into the specific program image being created.
[0045] The graphical programming environment is tied to the target
as shown in FIG. 4. FIG. 4 shows the combination of functions MUL
reading the X values from a file, source of X values 402, and
deposits the Y outputs into another file, or storage means, store
results Y 404. The specification defines the values of P, Q, and R
to be 2, 3, and 4 respectively, so that the sample equation now
becomes
Y=2X.sup.2+3X+4
[0046] When the user runs this program the input file in 402 is
read and the output file in 404 is written. If the programmer has
incorrectly specified the function to be performed by one or both
functional units (identified as MUL in the graphic interface) 301
and 303 units then the output Y may not be as expected. That is,
there may be an error in the program. With an error present, the
programmer inserts a breakpoint in an attempt to locate the error.
This invention allows a breakpoint to be inserted on any data
stream. Therefore, the user can select the input stream X, the
stream flowing between MUL units 301 and 303, or the output stream
Y. Since each stream has two components, namely data and token, the
user is able to select a combination of the two. For example, a
condition for generating a breakpoint is defined by:
[0047] a) when the data is greater than zero and
[0048] b) the token equals zero.
[0049] The capabilities of the stream computer functional units
will define the set of available breakpoint conditions. However,
the breakpoint function can use one or more functional units. The
number of breakpoint functions is only limited by the number of
programmable functional units and connectivity defined by the
programmable stream computer.
[0050] In the example of FIG. 5, the programmer introduces a
breakpoint triggered by the data stream between MUL 301 and MUL 303
having a value of 1. The programmer also wants to view the X input
stream to the second MUL 303 after delay 305. For the example
shown, the corresponding value of X is -1. FIG. 5 shows how the
user specifies this breakpoint graphically using the graphic
interface. Breakpoint 501 specifies the data condition and token
condition. Data condition for breakpoint 501 is D: 1 while token
condition is T: ANY. The AND function indicates that both
conditions must be met for a breakpoint to be triggered.
[0051] Viewpoint 503 indicates the condition necessary to generate
a viewpoint. For example, the data value 0 is shown, followed by a
semicolon, and then the token value 0.
[0052] Viewpoint 505 monitors the stream of X, after delay 305,
before entering MUL 303. The viewpoint is triggered when the data
value is 0 and token value is also 0.
[0053] The display of the graphic interface shields the programmer
from the underlying details and facilitates the programming
process. FIG. 6 shows an exemplary implementation for the
breakpoints shown in FIG. 5 using a similar level of abstraction.
In FIG. 6, viewpoints 604, and 606 and breakpoint 602 are
interposed to examine the data streams from MUL 301 and into MUL
303.
[0054] FIG. 7 shows an example of a breakpoint implementation
applicable to this invention. The breakpoint uses digital logic and
uses an independent stream (the debug stream) to perform
comparisons and identify the occurrence of a condition for
triggering the breakpoint. In this digital logic, ALU 701 compares
a debug stream and breakpoint number and stores results in a memory
703. The quantities stored in memory 703 are compared by ALU 705
with the data stream to identify a breakpoint.
[0055] The structure the digital logic made of ALU 701, memory 703
and ALU 705 used to identify the breakpoint is the same as that
used within the functional units. An ALU is the same functionally,
and can be the same as a MUL functional unit without the multiply
capability, as shown in FIGS. 6 and 7. The debug stream carries
information to the digital logic and enables output of the
results.
[0056] Because the functional units have the same structure
required for breakpoint generation, a programmer has the option to
allocate part of the stream computer resources for breakpoint
generation, on a case by case basis. If breakpoints are specified
in the program, they require valuable resources within the stream
computer, namely streams and functional units.
[0057] In the example shown in FIG. 7, the input to initiate a
breakpoint is a debug stream that will indicate whether the
breakpoint is enabled. A combination of data and token can be used.
For example, the data may be a unique identifier for each
breakpoint so that more than one can be used. The output stream
will indicate if the breakpoint has been triggered or else it will
pass along the input. The viewpoints then take this information
(also passing it along for downstream viewpoints) and act
accordingly. If the breakpoint has been triggered, then on the
first available clock it may forward breakpoint trigger
information.
[0058] On the next clock cycle, the digital logic of FIG. 7 may
output the identifier of the viewpoint and then finally the value
of the viewpoint to a reporting logic. The token values that are
input to and output by the viewpoints are:
[0059] null (data is invalid);
[0060] breakpoint (data is the address of the breakpoint and
enable/disable/trigger data);
[0061] viewpoint identifier (data is the viewpoint identifier);
[0062] viewpoint value (the data is the value of the
viewpoint).
[0063] The Breakpoint in FIG. 7 is implemented by having ALU 701
and 705 compare the debug stream input. If the token indicates
breakpoint, ALU 701 will detect if the breakpoint number (a
constant) is a match, if so it will output a breakpoint hit. This
detection by ALU 701 controls digital logic that will generate
output that is the same as this input until a breakpoint is hit. If
a breakpoint has been hit then the digital logic will neither
consume the input (causing upstream functions to stop), nor produce
output causing downstream functions to stop. This information also
continues down the debug stream to viewpoints so they will output
their data.
[0064] The viewpoint in FIG. 8 is implemented by splitting the data
stream and always forwarding it unchanged. The digital logic on the
debug stream, viewpoint ALU 802, looks to see if any breakpoint has
been detected. If so, the digital logic will insert its viewpoint
identifier and data stream values into the debug stream at the
first available opportunity and will continue to do so until no
data stream information is available or the breakpoint is released.
Memory 804 provides the incoming data stream to viewpoint ALU 802
for viewpoint detection in accordance with the debug stream, as
well as passing the data stream unchanged to the next stage or
functional unit.
[0065] These implementations are examples indicative of the concept
of the invention. The exact implementation will be a function of
the capabilities of the functional units and available stream
connectivity in the system. Breakpoints and viewpoints are
implemented using the same programmable functional capabilities as
the typical, normal function units available within a stream
computer. These functions are inserted into the program of the
stream computer the same as any other functionality. Because of
this and the fact that no special debug capabilities are required
and that generally differ in hardware versus a simulation, there
will be a consistent implementation in the simulation and the
target thereby easing program development.
[0066] This invention does not preclude special debug capabilities,
but rather frees the software development engineer from relying on
them. This differs from the prior art because most processors
require and implement special functions to support debugging. Using
this paradigm no special capabilities are required, although the
system does require some functional units to be available for
debug. However, having spare units would be normal during unit
testing where small fragments of the overall program are being
tested.
[0067] The concept is further summarized using the concepts from
FIG. 2 to FIG. 8 in a simple example shown in FIG. 9. Here,
functional units 901, 903, 905, 907, 909, 911, 913, 915 and 917
form a stream computer and have access to the data and token
stream. Of these, functional units 905 and 911 are allocated to
process breakpoint/viewpoint generation. Functional units 905 and
911 form digital logic 919 required to interpret a debug stream.
Functional units 905 and 911 are cooperatively associated with, for
example, functional units 903 and 909 respectively, in that the
data stream through 903 and 909 are monitored by 905 and 911
respectively.
[0068] The results from digital logic 919 are transferred to
reporting logic 921 for conversion to a format compatible with the
display of breakpoints, viewpoints and associated data stream
content 923. In effect, functional units 905 and 911, part of the
stream computer are programmed to respond to the debug stream and
the data/token stream for debugging purposes. It is envisioned that
the functional units making up the stream computer as well as
reporting logic 921 are integrated on a single semiconductor or
hybrid substrate to minimize size and cost.
[0069] The structure of the stream computer applicable herein is
discussed in the parent application, and is incorporated herein in
its entirety.
[0070] Although presented in exemplary fashion employing specific
embodiments, the disclosed structures are not intended to be so
limited. For example, although a multiply and add function is shown
as a building block example, any other combination of mathematical
or Boolean logic operation could benefit from the concepts
described by the invention herein.
[0071] Those skilled in the art will also appreciate that numerous
changes and modifications could be made to the embodiment described
herein without departing in any way from the invention. These
changes and modifications and all obvious variations of the
disclosed embodiment are intended to be embraced by the claims to
the limits set by law.
* * * * *