Method and Apparatus for Nonintrusive Passive Processor Monitor

1. Field of the Invention

The invention relates to an apparatus and method for software monitoring.

2. Related Art

A computer controlled system runs in accordance with software stored in program memory. In order to maintain the integrity of the system, the execution of software by the computer must be effective and efficient. Ordinarily, as the computer executes the software, the original software language in which the program is composed, or source code, is converted by a compiler into a lower level, i.e. less abstract, mnemonic language, machine language or object code. The source code is converted into mnemonic language (object code) because the processors in a computer controlled system cannot act immediately on the source code. Rather the processor can only act on the object code. After the computer converts the source code to object code, the processor initiates and takes action on its three principal buses, the address bus, data bus, and control bus, to perform the functions required by the source code. The address bus is an internal electronic channel interconnecting the processor to a random access memory (RAM) along which the addresses of memory storage locations are transmitted to identify which code stored in memory will come into play during execution. Data is sent back and forth between the memory and the processor. The control bus carries the output signals used to control the apparatus being controlled by the processor.

Sometimes, the output at the processor does not match the function for which the source code coded. This can occur when so-called "wild-write errors", "execution leg errors", "logical flow errors", or other "bugs" occur in the control software. Errors are not always apparent from the output. Even when a problem is shown in the final output, the output does not reveal where in the source code the error occurred or if there is a compiling error. System faults or system behavior errors adversely affect the quality of the entire system; therefore, it is important to monitor execution of software to ascertain software efficiency and to identify and diagnose software bugs or other errors in the code so they may be removed from the program.

Existing software monitoring is achieved by sections of diagnostic code in the software program itself monitoring its execution. However, underlying software malfunctions can cause the diagnostic software to also malfunction. Other software diagnostic programs, referred to as code coverage, or code profiling, programs, such as diagnostic programs known in the market as CASE, QFD, SEI, and VFSM, perform diagnostics. Disadvantageously, because code coverage programs "instrument" the target object code by inserting diagnostic code or instructions into the source code being monitored, execution time is increased. As the computer software object code is read in sequential linear fashion, the diagnostic instructions inserted into the programs must also be read. For every line of code that the processor reads, the time needed to execute coded function adds to the total time of execution. While this increased execution time may be acceptable for off-line, or nonreal-time systems, this increased execution time is intolerable in many real-time systems.

Another problem with known code coverage programs is that they cannot be used in control systems in which the program is fully embedded in the processor memory such as is done with the processors used in many real-time control applications. Accordingly, no diagnostic code can be added into the embedded system and any attempt to exceed the capacity of the embedded program memory can cause the system to crash or cause a panic condition.

Circuit emulators are known which do not require insertions of diagnostic code into the code being monitored, but the output results are expressed only in object code and are therefore cumbersome to use. Also, in order for the circuit emulators to work, the processor being monitored, i.e. the target processor, has to be fully functional and operating.

Disadvantageously, in known monitors, monitoring is restricted to monitoring only one of a supervisor code and a user code so that problems arising from transfers between user code activity and supervisor code management activities are not readily detected.

Other disadvantages with known code coverage or monitors exst. Failure to precisely measure the elapsed time and time duration of functions being executed in real-time makes certain timing errors difficult to detect. The inability in known code monitors to maintain the actual waveform generated by the processor in order to detect hardware related problems is also lacking. Lack of sufficient memory to store large numbers of signals both before and after occurrence of trigger events also makes detection of programming errors more difficult.

The present invention is directed to overcoming or at least reducing the effects of one or more of the problems set forth above.

The source code monitor and monitor method of the present invention overcomes the problems and disadvantages of the prior art through provision of a monitor which is nonintrusive and thus well adapted for use in monitoring processors with fully embedded programs and which is capable of determining and displaying real-time actions taken by a processor and the corresponding part of the source code associated with these actions.

In the preferred embodiment the source code monitor has an interface for a monitoring the execution of an object coded computer program by a processor. The monitor provides for nonintrusively (i.e. passively) detecting the actions taken by the processor while executing the object coded program, and determining during execution of the source program by the processor if there is a match between the actions as detected and an associated part of the object code. A display is provided for an indication of the actions performed and, if there is a match, an indication of the associated part of the source code. If there is not a match, an indication that there is not a match is provided. The interface circuit monitors signals on the target processor address bus, data bus and control bus. A code coverage analyzer box connects these signals to a code representing the process or action taken during each transition cycle and a local, or remote network connected, code coverage analysis server compares the action to a set of possible actions which can be taken by the processor with the associated set of symbols representative of the different parts of the user code.

In addition to displaying an encoded form of the actions taken along with identification of the associated user code, the elapsed time since commencement of a transaction cycle and the time duration of each transition cycle monitored is determined and displayed.

Advantageously, the actual waveforms of the signals on the target processor busses are stored and made available for display in order to facilitate detection of hardware related problems. In addition, recirculating memories are sufficiently large to enable restriction of memory transition cycles both after and before the occurrence of triggering events to facilitate analysis.

Any of the processor actions associated with the source code and detection of actions which are not connected with the source code are selectable as trigger events. Because the triggering events are not placed in the object code, no concern need be given to the effect on timing in real-time applications and triggering events can occur at any time during execution of the object code even when the processor is not functioning in a fully "pumped" operational mode.

These and other features of this invention will become apparent from the following detailed description, the accompanying drawings and the appended claims.

The advantages of this invention will become apparent upon reading the following detailed description and upon reference to the drawings in which:

FIG. 1 is a functional block diagram of a preferred embodiment of the basic form of the source code monitor of the present invention as used to monitor an on-site target processor;

FIG. 2A is a functional block diagram of the code coverage analysis box interface of the monitor of FIG. 1;

FIG. 2B is a schematic side view illustration of the code coverage analysis box interface mounted on a printed circuit board and interconnected with another printed circuit board upon which the target processor is mounted;

FIG. 3 is a functional block diagram of the code coverage analysis box of the monitor of FIG. 1;

FIG. 4 is a functional block diagram of the code coverage analysis server of the monitor of FIG. 1;

FIG. 5 is a flow chart of the preferred embodiment of the basic source code monitor computer program stored in the source code monitor program memory of FIG. 5 and used to control the monitoring operation and produce the monitor output;

FIG. 6A is a functional block diagram of a preferred embodiment of a networked form of the source code monitor of the present invention;

FIG. 6B is a functional block diagram illustrating use of the networked source code monitor of FIG. 6A to monitor source code of a plurality of remote target processors;

FIG. 7A is a flow chart of the preferred embodiment of the networked source code monitor computer program stored and executed by the code coverage analysis server of FIG. 6A;

FIG. 7B is a flowchart of the preferred embodiment of the networked source code monitor computer program stored and executed by the code coverage analysis server of FIG. 6B;

FIG. 8A is an example of the preferred form of the output results produced by the source code monitors of FIGS. 1 and 6A;

FIG. 8B is an encoder/decoder chart of a code used to express processor activity in the output results of FIG. 8A;

FIG. 9 is another example of the preferred form of the output results produced by the source code monitor; and

FIG. 10 is a functional block diagram of a multimodule programming application in which the monitor is capable of being used.

Referring to FIG. 1, a preferred embodiment of a relatively basic, or "stand alone", form of the source code monitor 10 of the present invention is connected with a target processor 12 of a target computer 14 being used to control a computer controlled apparatus 16 in accordance with a computer program, or software, stored in a program memory 18. For example, target computer 14 and the computer controlled apparatus 16 form part of a telephonic switching module, such as a 5ESS.TM. Switching Module 2000 made by LUCENT TECHNOLOGIES.RTM. and shown in at http:.backslash..backslash.www.lucent.com.backslash.netsys.backslash.5ESS. backslash.5esswtch.html in which the software is embedded in memory. In such case, the target processor is an MC68040.RTM. microprocessor made by MOTOROLA, INC..RTM..

The target processor 12 has three primary busses upon which are performed or substantially all processor activity. These three busses, an address bus 20, a data bus 22, and a control bus 24 are coupled to a code coverage analysis box 26 through a code coverage analysis box interface, or interface circuit, 28. The code coverage analysis box 26, in turn, is connected with a code coverage analysis server computer 30 at which the monitor output information is produced and displayed, examples of which are shown in FIGS. 8A and 9.

Referring to FIG. 2A, the interface circuit 28 includes target processor releasable bus connectors 32, as symbolically represented by bus lines 20, 22 and 24, for releasable connection with mating connectors of the target processor 12 to interconnect signals from target processor 12 with a tristate buffer circuit 34. The tristate buffer circuit 34 functions to reduce inductive and capacitive loading before the signals from the target processor 12 are applied to an output signal conditioning circuit 36 and a timing signal generation circuit 38. The output signal conditioning circuit 36 conditions the tristate buffered target processor signals and the timing signal generation circuit 38 generates timing signals to facilitate recognition of the states, or actions, of the processor. The output signals from the output signal conditioning circuit 38 and the timing signal generation circuit 38 are coupled to the code coverage analysis box 26 via interface output cable 40, as also shown in FIG. 1. All of the components of the interface circuit 28 are preferably mounted on and interconnected by pin connectors on a circuit board 42 schematically illustrated by broken line.

Referring to FIG. 2B, in the case of the target processor 12 being mounted on a printed circuit board 44 connected to other circuitry (not shown) via a back plane connector 46 and having extension pin receptors 50, the interface circuit board 42 makes appropriate connection via a plurality of connector pin extenders 48 inserted into mating receptors 50 located in a preselected pattern across a lower face 52 of the printed circuit board 44 defining a connector "footprint". The plurality of pin extenders 48 define the target processor releasable bus connectors 32 shown in functional block form in FIG. 2A as being connected with busses 20, 22 and 24. Each bus requires multiple connections via a plurality of the pin connectors 48. The interface output cable 40 of FIG. 2A is preferably a ribbon cable as shown in FIG. 2B which couples the interface circuit 28 to the code coverage analysis box 26.

The code coverage analysis box 26 is preferably implemented with a logic analyzer, preferably a TEKTRONIX.RTM. TLA 510 logic analyzer. The TLA 510 logic analyzer is described in detail at http:.backslash..backslash.www.Tek.com. Briefly, referring to FIG. 3, it acquires information at high speed with a real time data acquisition circuit 53 which enables monitoring the interfaced target processor signals on cable 40 in real time. The acquired information is preferably stored in the form of "hardware traces" in a recirculating memory 54 having a memory capacity sufficient to store 32 k, 128 k, 512 k, or 2 MB. All or a portion of the recirculating memory is selectively transferred to the code coverage analysis server 30 via an output 56 upon the occurrence of preselected trigger events.

Referring now to FIG. 4, the code coverage analysis server 30 is preferably a code monitor server computer 58 with a conventional display screen 60 for displaying the monitor output results, a keyboard 62, a printer 64 for printing the display of output results and source code monitor program memory 68. A model SPARC 5.TM. computer made by SUN MICROSYSTEMS.RTM. has sufficient capability to function as the code coverage analysis server. In addition, the server has a large capacity target processor symbolic data base 66, such as a source code symbol memory, for storage of symbol table monitoring information associated with the target processor 12 along with an associated support program. The large symbol code memory 66 is preferably contained on a removable storage medium such as a compact laser disc or the like with a storage capacity on the order of 16 B. A preferred embodiment of source code monitor software program of the present invention is stored in a source code monitor program memory 68. The hardware trace signals on the output 56 from the recirculating memory 54, FIG. 3, are selectively stored in the input data memory buffer 70.

The flow chart for the preferred embodiment of source code monitor software program of the present invention is shown in FIG. 5.

In step 72, prior to using the source code coverage monitor, the operator will decide what function of the computer controlled apparatus needs to be monitored. For example, in the telephonic industry, this apparatus may be in the 5ESS.RTM. switch indicated by a telephone off the hook.

In step 74, the operator will then determine the vectors of the function to be monitored, such as address, data, control, read, write, etc. This information is used to fill the trace request form on the CCAS 30.

In step 76, the source code coverage monitor then sends this trace request command to the CCAB 28 from the CCAS 30.

In step 78, the CCAB 28 then decodes the request and obtains a series of target processor 12 hardware traces such as those shown in FIG. 8A, via the CCAB 28 interface and stores them in the CCAB's 28 circular memory buffers 54.

In step 80, after the desired amount of traces, such as those shown in FIG. 8A, are obtained by the CCAB 28 and stored in circular memory buffer 54, the traces are then sent to the CCAS 30 for post-processing to obtain the source code information trace 150. An output such as the chart of FIG. 8A is therefore readily attained.

Referring now to FIG. 6A, the preferred embodiment of the networked source code monitor 10' of the present invention is seen to include the interface circuit 28, the code coverage analysis box 26 and the code coverage analysis server 30 which are substantially identical in structure and function as described above with reference to FIGS. 1-4. However, unlike the basic source code monitor of FIG. 1, the code coverage analysis server 30 is coupled to the code coverage analysis box 26 via a local area network 120.

As in the source code monitor 10 of FIG. 1, the code coverage analysis server 30 functions as the control point for the user to perform the various functions shown in FIG. 5 such as "start trace", "stop trace", "display results", "print results", etc. and executes the source code monitor program necessary to match the hardware traces representing the actions taken by the target processor 12 with the software symbols indicating the various parts of the source code.

However, unlike the case in the basic monitor 10, in the networked monitor 10', the source code symbols are not necessarily stored in the target processor symbolic data base 66 exclusive to the source code monitor server computer 58 of FIG. 4. Instead, preferably, the source code symbols and associated actions are stored in a memory associated with a source code program data base support processor 122 which provide the appropriate source code symbol data and associated actions to the source code monitor server computer 58, FIG. 4, via the local area network 120. This source code program data base support processor 122 is specifically a model SPARC 2000.TM. computer made by SUN MICROSYSTEMS .RTM. and has a memory capacity of 240 MB.

Another difference relative to the basic monitor 10, is that the networked monitor 10' preferably has a programmer's support system 124 coupled to the code coverage analysis server 30 via the local area network 120, such as AHMDAL.RTM. Model 5995 running VTS SYSTEM V.TM., version 2.12 operating system. As shown in FIG. 6B, importantly, with the networked source code monitor 10', the source code monitor server computer 58 is capable of off-site monitoring through the local area network 120 with a plurality of different target processors 12-1 through 12-N through associated on-site interface circuits 28-1 through 28-N and code coverage analysis boxes 26-1 through 26-N, respectively. The larger quantity of source code symbols which must be stored for comparison with a plurality of target processors 12-1 through 12-N instead of only one target processor 12 is handled via the off-site source code program data base support processor 122.

The matching function performed by the code coverage analysis server 30 in the networked monitor 10' is substantially performed in the same way as in the basic monitor 10 but additional software steps for communicating with multiple target processors 12-1 through 12-N, with the source code program data base support processor 122 and the program support system 124 are added as shown in the flow chart of FIG. 7.

Referring to FIG. 7A and FIG. 6A, one of the most powerful features of the source code software coverage monitor 10' is that it can decipher which functions the target processor 12 executes without interfering or modifying the underlying source code. This is accomplished by correlating the hardware trace information, such as those in columns, 152, 154, 156, 158, with the symbols from the source code database. In step 130, the operator accesses the CCAS 30 and activates a command that accesses the source code program database located on the support processor 122 via a LAN 120.

Next, at step 132, a symbol extract program is run which creates a symbolic database 66, which contains the names of the symbols along with the addresses in case of the functions; and values in case of the data structures. Steps 130 and 132 are only performed when a new software load is running. Step 134 performs the hardware trace acquisition described in FIG. 5 and in its accompanying text.

After the traces are acquired, at step 136 a resolve program is run which combines the traces from the CCAB 28 with the symbolic database 66 on the CCAS 30. The result of the combination produces the source code indication trace 150. The output of the source code software coverage monitor 10' is then viewed on the CCAS 30 console and in step 138 sent to archival storage or additional analysis to the programmers support system 124 via the LAN 120.

With reference to FIGS. 7B and 6B, the source code software coverage monitor 10' is capable of tracking several target processors 12-N utilizing a common CCAS 30 via a LAN 120. In step 140 of FIG. 7B, the symbolic database 66 is created for each target processor 12-N. This is done by using the CCAS 30 as a base to access the source code program database on the support processor 122 via a LAN 120 for the target processor 12-N. In step 142, the steps of FIG. 5 and described in its accompanying text are performed to compare the symbols and generate the source code information trace 150 by running the resolve program. The resolve program combines the hardware traces from the CCAB 28 with the symbolic database 66 on the CCAS 30 to produce the indication traces 150. The results are then sent to the programmers support system 124 via the LAN 120 for further off-line analysis.

The result of using either the basic source code monitor 10 of FIG. 1 or the networking source monitor 10' of FIGS. 6A is production of source code monitoring data, such as shown in FIG. 8A, by the source code monitor server computer 58, FIG. 4, and display of that data selectively on the printer 64 and conventional display screen 60, such as shown in FIG. 8A. Referring to FIG. 8A, column 152 labelled "elapsed Time" shows the cumulative lapsed time since the occurring of the trigger action by the target processor 12 which initiated a monitoring cycle by the source code monitor 10 or 10'. Referring to FIG. 8A, each successive row of column 152 represents the elapsed time at the end of each successive transaction cycle of the target processor 12. Column 154, labelled transaction time, on the other hand, shows the length of time taken by the target processor 12 to perform each of the server transactions. Each entry is equal to the difference between the elapsed time entry on the same row in column 152 less the elapsed time entry on the immediately previous row.

The entries on each row of column 156 is a code word which indicates many aspects of the actions, or activity, taken by the target processor 12. This code word has the one-character fields f1, f2, and f3 and a two-character field f4 shown in FIG. 8A The field, the type of action, and the corresponding code letters and number are shown in FIG. 8B. Briefly, as seen in FIG. 8B, the phase of the bus is encoded in field f1; the read, write, etc. processor action is encoded in field f2; the size of the data moved across the bus is encoded in field f3 and the processor action on the bus including whether a user text or data or supervisor text or data or command function is being moved on the bus, is encoded in the two characters of field f4.

With reference again to FIG. 8A, column 158 represents the data value, if data is on the bus, and the address of other code on the bus.

The fifth column 160 is an indication of the object code being performed or executed during the associated transition cycle and selectively includes the matching line of source code indicated in brackets and is expressed in symbols, functions, and other high level abstract language and code representation of which part of the source code is being performed during the associated transaction cycle of the target processor 12 if there is, in fact, a match between the source code indication stored in input processor 122 or symbolic database 66. The actions of the target processor 12 are indicated in the columns, particularly columns 156 and 158, FIG. 8A are also displayed in conjunction with the associated part of the source code.

With reference to FIGS. 8A and 8B, one manner in which the source code monitor 10 operates is on the basis that any given software program has a finite universe of object code symbols associated with it that corresponds to all the instructions the processor can process. For example, a PENTIUM.TM. processor chip made by INTEL CORPORATION.TM.. of Santa Clara, Calif., described in PENTIUM.TM. Processor User's Manual, Vol. 3, Architecture & Programming Manual, has a finite universe of about five hundred (500) instruction codes in its latest software issue. In the telephonic industry, a switch such as a 5ESS.RTM. switch has a universe of about five hundred thousand (500,000) symbols. The 5ESS.RTM. switch is manufactured by LUCENT TECHNOLOGIES.RTM. and described in "The 5ESS Switching System Architectural Overview", AT&T Technical Journal, vol. 64, No. 6 July/August 1985, pp. 1303-1564. For every action taken by the target processor 12 on its bus lines as indicated in columns 156 and 158, there should be an associated part of the object code. Accordingly, a universe of source code symbols representative of all the source codes and the associated actions are either preloaded into the source code symbol memory in the basic monitor unit 10 or are stored in the source code program data base support processor 127 and accessed by the server 30 of the network source code monitor 10'. In both monitors 10 and 10' instruction codes in the magnitude of thousands and even tens of thousands and the associated processor actions are stored. Preferably, the code coverage analysis server 30 employs a state machine to determine what action is occurring across a particular bus 20, 22, or 24 of the target processor 12. While the source code monitors 10 and 10' will have some, but not necessarily all, of the instruction codes possible to perform whatever function it is to perform, the universe of all the source code instruction codes possible are compared to the actions performed by the target processor 12. It is this universe of codes, against which the source code monitors 10 and 10', compares the actual action being taken by the target processor 12.

By way of example with particular reference to the first, or top, row, column 158 of FIG. 8A, the source code monitor 10 is programmed, in conjunction with the state machine mechanism, to understand that if the target processor 12 is currently operating at location 0170b640 to perform a read quad word user text function, then the object code being executed must be performing the Auptlchk function appearing on source code line 128 of the source code listing. On the other hand, if the target processor 12 is operating at location 0170b640 but is performing a write byte of supervisory mode text, then there will be a mismatch and there will be no correlation to the Auptlchk function and source code line 128. In such event of no match, no indication of a corresponding part of the source code is printed or displayed in column 160. This absence, of course, provides a clear indication that something has gone awry in the target processor 12.

As noted, users of the source mode monitor program can program onset and termination of a monitoring cycle in response to preselected triggering events. These triggering events can include any events of the type reported at columns 156, 158 and 159, in addition to passage of preselected time periods and transitional cycles to both start and stop acquisition of stored data in the recirculating memory.

Using the decoding table of FIG. 8B, the first entry of column 158 of FIG. 8A is read as "Address read of quad word of user text".

If the triggering event is detection of execution of a particular part of the object code, the triggering instruction is capable of being strategically placed anywhere within the object code to enable diagnosis of selected source code software activity only to eliminate other possible error-causing candidates in the system. For example, the source code monitor 10 is programmable to store X samples of data before occurrence of the triggering event and Y samples after the occurrence of triggering event. In this manner, when the target processor 12 malfunctions as evidenced, for example, by failure of the end function, parts of the object code are available for diagnosis. In microprocessors with embedded software, the microprocessor often does not show signs of malfunction until long after the problem originated. Therefore, it is critical to debugging wild-write errors to enable the program to look far back into the object code to find the error and for this reason the recirculating memory has such large capacity.

As should be appreciated, the source code monitor 10 facilitates tracking software and hardware at any state of the target processor 12. For example, many 32-bit processors used with embedded software programs operate in both user and supervisory modes. Often times, the system will crash as the operating system, or OS, transitions the target processor 12 from user to supervisory modes and vice versa. This will occur at times when the OS is running off a target processor 12 that is of a higher speed than for which it was originally designed. Advantageously, the source code monitor 10 facilitates diagnosing such a problem because the output of column 156, field f4 tracks whether the source code is supervisory code or user code. This enables analyzing the event occurring between transitions of user to supervisory codes and vice versa.

Referring to FIG. 9, this capability is illustrated. The example illustrates software coverage of embedded processor activity in a telephone switching system making transition form supervisor mode of operation, i.e. operating system, to user mode, i.e. program. At the time 0.639110 ms time the target processor 12 is in the supervisor mode (address read of quad word of supervisor text--ARQST), executing line 390 of operating system function Osdisp[390]. After a series of executed statements, at time 0.642200, the line 27 of user function Oslites[27] is being executed.

In keeping with another aspect of the invention, the integration of many operating modules into a central system is facilitating. For example, in one department of an office, the office may be wired only for regular telephone service. Later as the office upgrades, the office may need ISDN (integrated services digital network) lines, video lines, or trunk transfer capabilities. An ISDN network is a network that provides end-to-end connectivity to support a wide range of services, including voice and nonvoice services, to which users have access by a set of standard multipurpose customer interfaces. Because each addition may be written in a different kind of software code, integration is difficult.

Referring to FIG. 10, in some applications, a load building processor 91 is connected to a plurality of operating modules 91 at which are produced different modules, or sections, of program source code. The source code of the individual modules 90 are submitted to the load building processor 93 where they are linked together into composite software load to create a composite universe of possible instruction and object codes available for the target processor 12 with different lines of code associated with the different modules. The composite software load is installed into the main program memory of the target processor 12. In keeping with the invention, this composite software load is also loaded to the source code program data base support processor 122 and is used to build the entire universe of symbols including software function names, transfer vector names, data structure names and any other software construct that may be present in the totality of software modules 91. In this way, monitor 10' is able to show errors occurring in the source code of multiple operating modules 91 and can determine in which modules the errors occur.

Another aspect of the current invention relates to setting up pseudo break-points in the source code monitor 10. Unlike break-points, which interject into the source code an instruction digit or the like to mark where the object code may be interrupted by external intervention or by a monitoring routine during execution of the object code, monitors 10 and 10' are noninterrupted, or noninterfering, and do not require insertion of an instructions to mark break points in the source code. Instead, a pseudo break point defined by occurrence of detection of execution of a preselected part of the object code will trigger the monitor to take action normally associated with the instruction of a real break point. As with the disadvantages of other software diagnostic tools, the current invention is advantageous in generating pseudo break points in a noninterfering (i.e. passively) manner. In the past, the interference caused by break points inserted into the target processor software potentially caused intolerable delays in program execution and program degradation.

The time stamp capabilities of the monitor also provide a great advantage. Because the current invention monitors the timing of execution of object code, the intervals between certain events are calculated. Preferably, the timing signal generation circuit 38 of the interface circuit 28, FIG. 2A, and the code coverage analysis box 26, FIG. 3, used in the monitors 10 and 10' are sensitive to five hundred picoseconds, so the length of a function or the duration between functions can be ascertained precisely in real-time. The computation of time intervals are calculated from the elapsed time signals.

In addition to the information described above with reference to FIGS. 8A and 8B, source code monitor 10 is also programmable to add more columns to the chart of FIG. 8A to include the time between preselected events using the data from columns 152 and 154.

In addition, the monitors 10 and 10' can be used in diagnosing the target processor's 12 hardware. Once the monitor starts its diagnostic routine, the target processor 12 is selectively monitored, for example by displaying the waveform of the target processor 12, and thus by cross-referencing when the target processor 12 fails in relation to the object code executed, accurate diagnosis of the waveforms can be obtained and examined. This is advantageous in determining whether the fault occurs in the source code monitor 10 or the target processor 12 itself This capability is of great assistance when debugging software running on a new hardware platform.

Those skilled in the art who now have the benefit of the present disclosure will appreciate that the present invention may take many forms and embodiments. Some embodiments have been presented and described so as to give an understanding of the invention. It is intended that these embodiments should be illustrative, and not limiting of the present invention. Rather, it is intended that the invention cover all modifications, equivalents and alternatives falling within the spirit and scope of the invention as defined by the appended claims.