Monitoring computer systems.

0001The present invention generally relates to data processing system analyzers and more particularly to a method of attaching a software analyzer to a data processing system having the central processing unit (CPU) connected to the memory and other peripheral devices by a common input/output bus. This invention relates to the detection of use of the common bus by the CPU; and more specifically to detecting such use by monitoring the priority level of the devices that are requesting access to the common bus.

0002Current methods for analyzing the operation for data processing systems include various methods for extracting data or monitoring the performances of the data processing system in operation. These data processing systems analyzers may be broken down into two categories; hardware analyzers and software analyzers.

0003The purpose of a hardware analyzer is to monitor and analyze the various aspects of the operation of the data processing system hardware. For example, a hardware analyzer may monitor various timings within the CPU or transfer of information between units connected to a bus. For example, the hardware analyzer may monitor the time that it takes for the memory to respond to a CPU request for reading a word from memory with this time being the average time reflecting those cases in which the memory is immediately available for reading and .those cases which the reading is deferred because the memory is busy performing a data transfer to a peripheral device. Hardware analyzers are also used to determine utilization factors, for example, the percentage of time that the CPU is being utilized, as compared to the percentage of time the CPU is idle, waiting for either data from memory or the completion of an input/output operation. The hardware analyzer may also be used to determine utilization facts and response times for various components within the system, such as peripheral devices, and memory subsystems. The data provided by the hardware analyzer may be used in various ways. For example, the diagnosis of system design problems or the optimization of system configurations as a data processing system is either contracted or expanded by the addition or removal of equipment in response to optimizing system for an existing data processing workload or to accommodate a changing data processing workload.

0004Current methods of performing hardware analysis of a data processing operation require a detailed knowledge of the hardware of the data processing system to be analyzed so that the hardware analyzer may be connected to points within the data processing system such that' various hardware signals can be monitored to provide the data required for a hardware analysis. The ease with which the hardware analyzer may be connected to a data processing system will vary from system to,system and will also depend upon whether monitoring or probe points have been designed into the system. Current hardware analyzers often require connecting monitoring signal wires to various pins of components mounted on printed circuit boards so that the signals may be monitored in order to collect the required data.

0005The purpose of a software analyzer is to analyze the operation of the software programs as they execute in the data processing system. The software analyzer may be used to monitor accesses to a specified memory location, monitor access to a specified peripheral device, monitor the setting of a specified bit within a memory word, monitor the execution of the program at a specified hardware priority level, or perform a trace of the execution of a software program. The software analyzer functions may be performed during the debugging of the software systems, for example, in attempting to determine who is inadvertently destroying data in a specified location, or for optimizing the software program by determining where in an operating system the largest bulk of time is being spent such that that particular section of code may be recoded to execute faster.

0006These software analyzer functions may be performed ei-ther; by modifying the software which is to be analyzed to include various analysis routines, by use of various hardware features built into the data processing system on which the software to be analyzed is to be executed, or by a software analyzer which is attached to the data processing system, or by a combination of these methods. For example, if the software analyzer is to analyze the amount of time in which the CPU is idle waiting for the completion of a input/output operation, the idle loop within the operating system may be modified to include a counter within the idle loop such that the counter is incremented each time the idle loop is executed. This count can then be used in determining the amount of time in which the operating system is spent in the idle loop out of the total elapsed time. A further example is that the routine within the operating system which changes the priority level in which the software is executing can be modified to collect data each time the priority level is changed. Modifications of this kind which require the insertion of data collection or probe points within the software which is to be analyzed, require detailed knowledge of the software in order to insert these probe points and data collection of points. This technique also has the disadvantage that, in many cases, the operation of the system being analyzed is changed due to the increased execution time required to perform the data collection for software analysis.

0007Hardware features built into the central processor system may also be used to perform the software analysis function. For example, if it is desired to determine who is changing a specified memory location, the memory location or the block in which it is contained may be write protected, if the system has that capability, and a routine written such that every time a memory write violation is detected, an analysis is to be made as to whether the memory location is the specific location which is to be monitored. The routine would then collect the data as to the location of the instruction attempting to write into the specified location. Also, if the particular CPU has the ability to trap or interrupt upon the execution of each jump or branch software instruction, a routine may be written to monitor the jump/branch trap/interrupt. This routine can then be used to analyze which program location was attempting to perform the jump/branch instruction to the specified location.

0008Alternatively, equipment may be attached to the data processing system to monitor and analyze the execution of software within the system. In this case, the equipment would be attached to the data processing system at various probe points similar to that used for a hardware monitor and the system operation monitored and analyzed by use of the signals collected at these probe points. This method, in which the equipment is attached to the data processing system, has the advantage that the analysis of the software system can usually be done without the observation interfering or changing the execution of the software within the system. This use of .additional equipment to monitor the software also has the additional advantage that it is generally independent of the particular operating system software which is to monitored. This method generally requires detailed knowledge of the data processing system hardware, but the detailed knowledge required if various software probe points are to be inserted within the operating system software is not required.

0009A problem in attaching any kind of a monitor/analyzer to a data processing system, be it for analyzing the software execution or the hardware operation, is to attach the analyzer to the system as conveniently as possible. In the past, in which discrete components were used within data processing systems and in which electronics packaging was not as .dense as it is using modern integrated circuits, probe points could be attached to the data processing system be means of clipping onto the leads of various components mounted on the printed circuit boards. In the past, these printed circuit boards were spaced within the system such that the analyzer probes could be connected to the system while the printed circuit boards were enclosed within the data processing system cabinets. However, with the advent of integrated circuits and current packaging densities, it is often difficult, if not impossible, to have probes connected to points on a printed circuit board while the printed circuit.board is in its normal operating position. In many cases, because of signal propagation time constraint, the system cannot operate at normal speeds while the printed circuit boards are connected by an extender card which would allow the probes to be connected.

0010Therefore, what is needed is a method by which a monitor/analyzer can be connected to a data processing system with ease without affecting the operation of the function being monitored or analyzed.

0011Accordingly, it is an object of the present invention to provide a convenient technique to connect an analyzer..to a system without requiring detailed knowledge of the system and without affecting the operation of the system.

0012in Accordingly, the present invention providesla data processing system comprising a plurality of devices sharing a common resource wherein conflicts between competing requests to utilize the common resource by different devices are resolved on a priority basis, monitoring means for detecting activity of a particular device, characterized in that said means are connected to the common resource and include priority detection means for detecting the priority level of the particular device, and grant detection means for detecting when utilization of the common resource has been granted to a device, the outputs of the priority detection means and the grant detection means being combined.

0013A data processing system embodying the present invention will now be described, by way of example, with reference to the drawings, in which:- <ul id="ul0001" list-style="none"><li>Figure 1 is a general block diagram illustration of a software analyzer incorporating the common bus utilization detection logic.</li><li>Figure 2 is a logic diagram of the.common bus utilization detection logic.</li><li>Figure 3 is a general block diagram illustration of a data processing system having a common bus showing a software analyzer connected between the central processor and other units on the common bus.</li></ul>

0014The analyzer is a software analyzer which is capable of recording central processing unit (CPU) in real time. The software analyzer is primarily used for software debugging and checkout. The software analyzer attaches to the common bus of the data processing system on which the software that is to be analyzed is executed. The software analyzer attaches to the common bus just below the CPU in the same manner as other peripheral devices are attached to the common bus. The software analyzer has no connections to the data processing system other than that made through the common bus and a connection to the CPU firmware address line test connector.

0015The software analyzer has a recording memory which is a very high speed memory because of the need to keep up with the dialogue on the common bus. The software analyzer records in this memory enough information to produce a reverse assembly. From this information stored in the software analyzer memory, the software analyzer disassembles the information to produce a record of the execution of software that is understandable to a software person. This disassembly is produced in a format that is familiar to a software person.

0016The software analyzer can monitor three types of CPU activity. These three CPU activity types are: any kind of memory activity, any kind of input/output (I/O) activity, and interrupt activity. Within each CPU activity type, the user of the software analyzer can select what kind of activity he wants to monitor. For example, with respect to CPU memory references, the person using the analyzer can monitor memory writes, or memory reads. Memory reads can be broken down into a read for the purpose of fetching an instruction or a read for the purpose of fetching operand data to be manipulated by an instruction.

0017The software analyzer therefore is designed to monitor central processing unit activities on the common bus and to ignore all other devices, such as peripheral controllers which utilize the bus. It is this ability to differentiate between CPU utilization of the common bus and the utilization by other devices that allows the software analyzer to function properly. Therefore, the software analyzer has the ability to determine when the central processor is reading or writing into memory and to ignore other memory reads or writes which are taking place between the memory and another device, such as a disc controller on the common bus.

0018The software analyzer's ability to differentiate between the common bus activity caused by use of the common bus by the CPU and common bus activity caused by use of the common bus by other devices allow the software analyzer to monitor only those activities associated with the CPU. The software analyzer uses the fact that priority for granting use of the common bus is determined by the would-be bus user's position along the common bus. By being connected between the CPU and all the devices on the common bus, the software analyzer uses this positional priority to determine when the CPU is using the common bus. Although as will be seen hereinbelow, when the CPU in the preferred embodiment makes the request on the common bus, the memory read request is tagged with an identifier (the CPU's channel number) which indicates that the CPU is making a request,, the same is not true for memory write requests which are untagged. Therefore, it is the positional priority along the common bus which is used to determine when bus activity is associated with the CPU.

0019. By designing the software analyzer to use che priority scheme of the common bus, the software analyzer can capture key information as it appears on the common bus at the right time. This ability to determine when a common bus activity is associated with the CPU becomes more complex in light of the split.bus cycle operation of the preferred embodiment. That is, in the preferred embodiment, a read or write request to memory is split into at least two bus cycles. During the first cycle (referred to as a first-half cycle), which is the request cycle, the requesting device places on the common bus the address of the location to be read or written. During the second cycle (referred.to as a second-half cycle), which is the response cycle, that occurs asynchronously with respect to the first-half bus cycle, the data to be written into memory or which has been read from memory is placed on the common bus. The software analyzer has the ability to capture the memory address during the first-half bus cycle and line it up with the memory data which it captures during the second-half bus cycle and to store the address and data in one location within the trace memory of the software analyzer.

0020The common bus utilization detection logic is used by the software analyzer to determine when the CPU is active on the common bus. As stated hereinbefore, priority along the common bus of the data processing system of the preferred embodiment is determined by position. By placing the software analyzer on the common bus between the CPU and all other devices, the common bus utilization detection logic can determine when the CPU has gained access to the common bus. In the preferred embodiment the CPU is the lowest priority device on the common bus and the memory is the highest priority device. By positioning the software analyzer next to the CPU, the software analyzer becomes the second lowest priority device on the common bus. Because of the priority network used to determine the granting of the common bus to a requesting device, there can be no open slots on the common bus and therefore all slots in which a device may be connected to the common bus must either be filled with a device, such as a peripheral controller or memory, or the slots must be jumpered in order to maintain the integrity of the priority network.

0021A key element in allowing the software analyzer to be connected directly to the common bus without requiring probe points connected to the CPU is the common bus utilization detection logic which permits the analyzer to differentiate between bus activity associated with the CPU and bus activity associated with other devices connected to the common bus. Without the common bus utilization detection logic, a much more complex method of attaching the software analyzer to the hardware system to be analyzed would be required. This ability to capture CPU related activity from the common bus allows the software analyzer to capture information which is associated with the execution of the software within the CPU and by analyzing this information, the software analyzer can produce a reverse assembly which produces assembly language level code. By monitoring the execution of the software in the CPU by analyzing the CPU related activity which occurs over the common bus, the software analyzer can be used to solve software problems which most other software debugging tools can not solve.

0022Other tools usually interact with the execution of the software itself and therefore somehow affect the execution of the software in one way or another. For example, if software analyzing is being done by the use of breakpoints, the breakpoint usually causes the C_PU to halt the software being executed and to display the CPU register and in the process changes the timing characteristics of the software being analyzed. The software analyzer of the preferred embodiment does not interfere with the timing of the software being executed within the CPU. Further, it is totally independent of any operating system software and can therefore be applied to the full range of software systems without requiring modification of the software analyzer itself. That is, the fact that the software analyzer is observing the execution of the software in the CPU does not change the activity within the CPU whereas most other software monitors change the activity because they either slow it down or they insert different software code than would actually otherwise be executed. The software analyzer of the preferred embodiment has the further advantage that it has the ability to do things that a software tool cannot do. For example, a software programmer may be concerned with how a particular bit within a particular word is being set or reset. The software analyzer has the ability to monitor a particular bit and determine where that bit is being modified without affecting the timing characteristics of the software as would be required if the particular word was write protected, and an interrupt or trap caused by every attempt to modify that particular word. The interrupt or trap routine could then be used to determine if the bit of interest within the word was being modified.

0023By use of the common bus utilization detection logic, the software analyzer is able to differentiate between common bus activity associated with the CPU and that associated with other devices thus allowing the software analyzer to ignore a modification of a particular bit in a particular word that is caused by a peripheral device writing data into that word. For example, the software analyzer will ignore the activity if a sector is read from a disc into a block of memory locations, one of which is the particular word of interest. This ability to filter out changes in the data processing system caused by other devices allows the software analyzer to concentrate on those changes caused by the execution of the software within the CPU. The fact that the software analyzer does not watch changes caused by peripheral devices within the system is not a problem because the software analyzer can be used to monitor the commands given to the peripheral devices and therefore the software analyzer can be used to determine indirectly whether a peripheral device was given a command which would result in the changing of a location of interest in the memory. This allows the software analyzer to be used to determine whether the changing of the location is associated with a software execution problem or a hardware problem.

0024The connection of the software analyzer to the data processing system by connecting the analyzer to the common bus has the advantage that the software analyzer is very easily connected to the data processing system. This method of connection eliminates the need for connecting probe points directly to the CPU logic through the use of alligator or other types of clips connected to leads on circuit. elements. This method of connecting to logic element leads within the CPU itself has the disadvantage that a higher level of knowledge is required to make such connections. Further, the point at which the leads are to be connected may vary from one revision to another

0025of the CPU logic boards. In addition, there is no single place within the CPU of the preferred embodiment which indicates when the CPU is utilizing the common bus and at which all data of interest to the analyzer appears. The connection of the software analyzer to the CPU by use of a series of probe points would probably not pass various underwriter laboratories testing requirements and thus prevent the software analyzer from being used other than in a system development environment.

0026The preferred embodiment is utilized in a software analyzer which attaches to the common bus which connects the central processing unit (CPU) with the memory and peripheral controllers of a data processing system. The software analyzer, a block diagram of which is shown in Figure 1, is used to analyze the execution of the software within the CPU. As shown in Figure 3, the software analyzer 207 is connected between central processor 206 and all other devices on common bus 200. As will be explained hereinafter, the placement of software analyzer 207 in this position is dictated by the bus priority scheme utilized in the data processing system whose software execution is to be analyzed.

0027Referring now to Figure 1, the major elements of the software analyzer will be briefly described. The software analyzer attaches to the data processing system whose software is to be analyzed by plugging into one slot on the common bus 200 by means of two 50-pin connectors. As will be described in more detail hereinafter, common bus 200 contains approximately 100 lines which are used to distribute power between various units and communicate data.

0028The software analyzer is capable of recording activities of the central processor of the data processing system in real time. The software analyzer occupies one slot on the common bus of the data processing system and has its own internal microprocessor which controls its operation. Communications with the person operating the analyzer is provided by interfacing the terminal to the software analyzer such that data may be input by the terminal and output displayed on it. The operation and use of the software analyzer is totally independent of the operation of the data processing systems whose central processor activity is to be analyzed.

0029The software analyzer, although attached to the data processing system on the common bus which carries all activity between memory peripheral devices and the central processor, responds only to activity associated with the central processing unit. This CPU activity is caused by the execution of software by the central processing system and thereby allows the software analyzer to analyze the execution of the software within the central processing unit. The purpose of the software analyzer is to record CPU software instructions and their related activity. The software analyzer performs this by monitoring the fetching of software instructions and operands by the central processing unit. The software analyzer is designed such that any central processor unit activity which occurs over the common bus can start or stop the recording of CPU activity information within the software analyzer.

0030The central processor activities which are monitored are defined as any type of memory access by the central processing unit, any input/ouput (I/O) operation associated with the CPU, or any interrupts to the CPU. For example, the software analyzer can be programmed to stop recording on the fifth occurrence of the data pattern "1234" being written into memory location 10,000. The software analyzer of the preferred embodiment has a memory capable of storing up to 8K (1K = 1024) worth of CPU activity. In the preferred embodiment, this corresponds to approximately 6K worth of software instructions being executed by the data processing system whose activity is being analyzed.

0031To facilitate user operation of the software analyzer, the software analyzer is.programmed by a series of menus from which the operator selects desired functions. The output of the software analyzer which is provided on the terminal connected to the software analyzer resembles the machine language of the data processing system and instruction mnemonics are extensively used. In addition to recording CPU activity, the software analyzer has performance monitoring capabilities. The software analyzer can provide the maximum/minimum or average time between specified CPU activities. The software analyzer can also count occurrences of a specified CPU activity.

0032Because the software analyzer is connected to the data processing system's common bus 200, the software analyzer can read or write into the data processing system's main memory. The ability to write into the data processing system's main memory allows the contents of trace RAM 319 to be written into the data processing system's main memory and from there displayed or otherwise manipulated by the data processing system itself. The ability to read from the data processing system's main memory allows the software analyzer to search the main memory for occurrences of specified data bit combinations. to In addition, the software analyzer has the ability/perform input/output operations with the peripheral devices of the data processing system.

0033As discussed hereinbefore, in attaching the software analyzer to the data processing system in this manner, the software analyzer may be very easily attached to the system without requiring any specific knowledge of where to connect probe points to the data processing system hardware. The software analyzer has the further advantage that by being a hardware device which connects to the data processing system, the software analyzer can be used independent of the operating software being executed in the data processing system.

0034Referring now to Figure 1; other features of the software analyzer will be described. The software analyzer has four condition registers 315 which allow the user to specify conditions A through D which will be used to control the recording of CPU activities within trace RAM 319. C_PU activity on the common bus 200 is compared with the conditions in condition registers 315 by address comparator 314, data comparator 313, and cycle comparator 312. The output of these three comparators is input to trace control 316, the output of which controls the recording of the CPU activities within trace RAM 319.

0035The software analyzer can be programmed by the operator to record a specified number of CPU activities before or after trigger points. For example, the software analyzer can be programmed to record 1K worth of CPU activity before a trigger point, and 7K of activity after the trigger point. As indicated above, the software analyzer can be programmed to record a specific CPU activity such as a read into a specified data processing system memory location or it can record groups of activities such as all input/output activity with a peripheral device having a specified channel number. The software analyzer is totally passive with respect to the data processing system whose CPU activity is being modified and therefore has no effect on the data processing system's performance or timing.

0036The programming and operation of the software analyzer is controlled by microprocessor 306, which communicates with the operator using terminal 340 via I/O control 307. The operating system of the software analyzer is loaded into the analyzer's 32K read/write memory (RAM) 309.from the data processing system whose CPU activity is to monitor via bus interface 305. This allows the software analyzer's operating system to be easily modified to provide new features and also eliminates the need to have a storage device connected directly to the software analyzer for loading the software analyzer's operating system. The boot strapping of the software analyzer is provided by PROM 308. In the preferred embodiment, RAM 309 consists of 32K bytes of programmable memory and PROM 308 consists of 8K bytes.

0037The recording (or tracing) of CPU activity within trace RAM 319 is controlled by two status bits stored in trace control 316. The four condition (A-D) registers 315 are used to modify these two status bits. The first status bit is the trace bit. When the trace bit is set, the software analyzer will record the CPU activity currently in progress. The second bit is the enable bit. This enable bit can be tested by condition registers 315 and if the enable bit is set, it can determine whether the current CPU activity should set or reset the trace bit.

0038Activity on the data processing system's common bus 200 that is associated with the CPU is detected by the software analyzer by CPU bus use detection logic 301 and CPU channel number detection logic 322.^.CPU bus use detection logic 301 detects when the C_PU has won control of the common bus 200 and has become a bus master. CPU channel number detection logic 322 detects those cases in which another device on the common bus has addressed the CPU by placing the CPU's channel number of the common bus When activity associated with the CPU is detected on the common bus, the address bits and conditions are latched into address register 302 and the data bits and conditions are latched into register 303. Auto address development logic 304 is used to automatically increment the address of a location in memory that appears on the common bus when the data processing system's CPU makes a memory request in which the CPU provides only the address of the first word of multiple words of software instructions to be fetched from memory. These multiple words of software instructions are retrieved from memory and transferred to the CPU over the common bus unaccompanied by their address and logic 304 provides the address of each word as the data appears on the common bus so that the address can be compared with the addresses specified in condition registers 315.

0039The operation of the software analyzer will be described with respect to the specific data processing system and its common bus operation described in U.S. Patent No. 4,236,203, to which reference may be made for details of the data processing system.

0040CPU bus use detection logic 301 basically determines when the CPU is getting onto common bus 200 as bus master. CPU bus use detection logic 301 does this by monitoring the nine lines associated with the priority network lines 341 and the control lines 342 associated with bus request, acknowledge (ACK), negative acknowledge (NAK), wait, bus master clear and data cycle new (signals BSREQT+, BSACKR+,. BSNAKR+, BSWAIT+, BSMCLR+, and BSDCNN+). The output of CPU bus use detection logic 301 on register clocking lines 339 is used to control the latching of various signals from the common bus 200 into address register 302, data register 303 and auto address development logic 304.

0041If the CPU is doing a memory read operation, during the first-half bus cycle when the CPU is the bus master and is providing the address of the word to be read from memory on the common bus 200, the address bits will be latched into address register 302 or into auto address development logic 304. If the CPU is in the process of doing a read of a word from memory to fetch a word of data to be used as an operand, the address bits on the common bus 200 on bus address lines 326 are latched into address register 302. These same address bits from common bus 200 are latched into auto address development logic 304 if the CPU is in the process of initiating a memory read for the purpose of fetching one or more words of memory to be used as software instructions to be executed within the CPU. This type of read is detected by logic 304 examining control information from the common bus on control lines 343.

0042The difference between the use of address register 302 and auto address development logic 304 is that 304 has the ability to automatically increment the address so that a correct address can be developed for each word of data that arrives back to the CPU from the memory during a multiple word procedure fetch. In the data processing system of the preferred embodiment a multiple fetch operation is performed only for reading words of memory to be used as procedure (software instructions) and not words of memory to used as operands. There is a further need to have two places, 302 and 304, for storing the address bits from the common bus 200 because the central processor of the preferred embodiment has the ability to have both an operand fetch and a procedure fetch simultaneously outstanding. Further, the words of data returned from the memory to the CPU when both types of requests are outstanding will not necessarily be returned to the CPU in the order in which the requests were made.

0043Data register 303 is used to capture the data bits . appearing on bus data bit lines 333 as 16-bit words of data are interchanged between the CPU and other devices on common bus 200. Data appears on these lines during a first-half bus cycle, when the CPU is transferring data to another device, and during a second-half bus cycle, when any device is transferring data to the CPU, such as occurs during a read from memory. Data register 303 is also used to capture and store 16 bits of data when a device on the common bus is interrupting the CPU. In this case, the 16 bits of information stored in the data register 303 indicate the channel number of the CPU and the level of the intertupt.

0044The address and the data bits captured from the common bus 200 in elements 302, 303 and 304 is then compared with the conditions of interest stored in condition registers 315 by use of comparators 312, 313 and 314. Address comparator 314 is used to determine whether the address stored in address register 302 which appears on operand address bus 325 is equal to or greater than the address specified by the operator of the software analyzer which is contained in condition registers A through D of condition register 315. Address comparator 314 compares the address bits from the condition registers 315 which appear on conditions bus 336 with the address bits appearing on address bus 338 which selectively receives input from operand address bus 325 or procedure address bus 337, which receives an address from auto address development logic 304 if a procedure fetch operation is involved. The equal to and greater than outputs of address comparator 314 are useful in that they allow the software analyzer user to monitor conditions occurring between a beginning, and an ending address, one of which is stored in one of condition registers 315 and the other of which is stored in another of condition registers 315.

0045Data comparator 313 is used to test whether the data bits specified in conditions A through-D in condition registers 315, which are selectively enabled onto conditions bus 336, are equal to the data bits stored in data register 303 which is available via data bus 332. Data comparator 313, although only having an equal output which is input to trace control 316, has the ability to test whether each bit of the 16-bit data word is a binary ONE, a binary ZERO or a don't care condition.

0046Cycle comparator 312 is used to determine whether or not the type of bus cycle that is occurring on common bus is of the type whose information is to be recorded in trace RAM 319. The type of bus cycles of interest for which it is desired to trace are specified in condition registers A through D in condition registers 315, each of which is selectively enabled onto conditions bus 336 and compared with the signals specified in the cycle type which appear on cycle type lines 327 via address condition lines 323 and bus cycle type lines 330 which receive the information from the address conditions stored in address register 302 and cycle conditions stored in data register 303. For example, cycle comparator 312 is used to determine whether the bus cycle occurring on common bus 200 is a input/output operation to a device, a memory operation, an interrupt operation, a memory write operation, a memory operand fetch (read) operation, a memory procedure fetch (read) operation, or a don't care (any kind) bus cycle involving the CPU.

0047The A input to comparators 312, 313 and 314 comes from condition registers 315 which contains the user supplied parameters specifying those conditions of interest to the operator of the software analyzer. Condition registers 315 containing conditions A through D are four 64-bit registers which contain bits specifying the address, the data, don't care bits for the data, and the type of bus cycles of interest_.to the operator of the software analyzer. This information can be specified for each of conditions A through D of condition registers 315.

0048Condition registers A through D can be used to specify four different conditions, the occurrence of any one of which will cause the data'and address bits from common bus 200 to be recorded into trace RAM 319 or or conditions A through D may be used in combination to detect one or more conditions of interest to the user. For example, condition register A could be used to specify a starting address by specifying that tracing is to occur if the address on the common bus is greater than or equal to the address in condition register A and condition register 3 could be used to specify an ending address by specifying that .the trace is not to occur if the address from the data bus is equal to or greater than that found in condition register B. This checking for four separate conditions or less than four combination conditions is made possible because each time that a bus cycle associated with the CPU occurs on common bus 200, (i.e., each time the CPU is either the bus master or slave) the information on the bus is compared against condition registers A through D in a pipeline fashion. The comparison is made first against the conditions in condition register A, then in B, then in C and then in D.

0049Each condition register A through D has the ability to set the two control bits (the trace bit and the enable bit) within trace control 316.

0050These two. status bits within trace control 316 operate as follows. The enable bit can be set (made equal to a binary ONE), reset (made equal to a binary ZERO), or tested by conditions A through D specified in condition registers 315. When the enable bit is set, (i.e., in the binary ONE state) the condition specified in conditions A through _D of condition registers 315 are enabled to change the status of the trace bit depending on how the conditions compare with the status of the information (i.e., address, data, or cycle type) from common bus 200. For example, the operator of the software analyzer can program the conditions within condition register 315 to: set the enable bit and the trace bit, reset the enable bit and the trace bit, set the enable bit, reset the enable bit, set the trace bit if the enable bit is set, or reset the trace bit if the trace bit is set. The trace bit is used to control whether the information associated with the current bus cycle is to be recorded in trace RAM 319.

0051At the appropriate time during a bus cycle, if the trace bit is set, a signal from trace control 316 on line 329 controls the incrementing of the trace address counter 317 which thereby provides for the retention of the information in trace RAM 319. If the trace bit is not set at the appropriate point in the bus cycle, the trace address counter is not augmented and the information associated with the next bus cycle will be written over the information associated with the previous bus cycle thereby destroying the information associated with the previous bus cycle.

0052This incrementing of the trace address counter 317 occurs after condition C has been compared with the information from common bus 200 and before condition D has been compared with the information from common bus 200. Therefore, if at the end of making the compare with the conditions in condition register C, the trace bit is a binary ONE, the trace address counter is incremented and the information from the current bus cycle which has been previously written into trace RAM 319 will be preserved because the next information associated with the next bus cycle will be written into a location whose address is one greater than that associated with the current bus cycle.

0053By examining the trace bit only after completion of comparing with the conditions in condition C, the software analyzer can be programmed such that conditions A, B and C can toggle the trace bit and nothing will be recorded into trace RAM 319 unless the trace bit is a binary ONE after condition C has been compared. For example, if it is desired to trace the execution of all software instructions occurring between memory addresses 100 and 500, condition registers A, B and C could be programmed such that: condition register A will turn on both the enable and trace bits if it is a procedure fetch bus cycle and the memory address is equal to or greater than 100, condition register B will to turn off the enable and trace bit if the memory address is greater than 500, condition register C will not change the enable and trace bit, and condition register D will be programmed to unconditionally reset the enable and trace bits. Following this example, if a word of a software instruction is fetched from location 200, condition register A will turn on the enable and trace bit condition register B will not reset the enable or trace bit because the address is less than 500, condition register C will make no change in either the enable or trace bit, and because the trace bit is set at the end of the condition register C compare, the data will be retained in trace RAM 319 because trace address counter 317 will be incremented and condition register D will unconditionally reset both the enable and trace bits so that the next bus cycle will be traced only if the enable and trace bits are set by the compare with conditions in condition register A.

0054The testing of the trace bit between the testing of conditions C and D permits the software analyzer to be programmed such that software execution can be traced up to and including the occurrence of a specified event. For example, if it is desired to find out what is causing a specified location to be destroyed, the software analyzer can be programmed to trace all bus cycles by control logic 310 and condition register D can be programmed to reset the trace bit upon the occurrence of a write into the specified location which was being destroyed. Therefore, each common bus cycle that is associated with a CPU will be traced. Registers A, B and C are not used and therefore will not modify the enable and trace bits. Condition register D will reset the enable and trace bits upon the occurrence of a write into the specified location. In this manner, not only will be procedure fetches which include the instructions which are being executed, but the operand data associated with those instructions will be traced right up to and including the instruction which does an operation which modifies the contents of the specified location. The data being written into the specified location will also be traced because the trace bit will still be set after condition C is tested during the bus cycle in which the data is stored into the specified location.

0055As indicated above, information from common bus 200 is written into trace RAM 319 during each bus cycle associated with a transfer to or from the CPU. The information from one such bus cycle is written into one 48-bit word in trace RAM 319. The information written into the 48-bit word consists of the address conditions from address condition lines 323 which indicate whether the address is associated with a read or write operation, a memory or I/O operation and whether it is a byte or a word address; the address bits from address bus 338; the data bits from data bus 332; the type of bus cycle which indicates whether the bus cycle is a second-half cycle or a double fetch operation from bus cycle type lines 330; and four bits which indicate which CPU firmware location was being accessed when the bus cycle occurred from CPU firmware indicator, lines 328.

0056As indicated, during each bus cycle associated with the CPU, this 48-bits of information is written into trace RAM 319 before the comparison occurs at the end of condition C. After condition register C has been compared, if the trace bit is set, the trace address counter 317 is incremented by one, thereby providing that the 48 bits of information associated with the next bus cycle will be written into the next location and not overlay and destroy the 48 bits worth of information associated with the current (previous) bus cycle.

0057Because in the data processing system of the preferred embodiment there are some transfers which occur over a common bus 200, which cannot be unambiguously interpreted by the software analyzer simply looking at the control lines on the common bus, the software analyzer also has a direct connection to the CPU of the data processing system. This connection is made to a test connector within the CPU which gives the software analyzer access to the CPU firmware address bus. CPU firmware address line .321 is connected to this test connector and makes available to CPU firmware address decoder 320 the CPU firmware address. CPU firmware address decoder 320 . contains a lookup table which has been precoded to provide at its output four bits on CPU firmware indicator line 328 which are used, along with the other information directly from the common bus which is also stored in the 48-bit words in trace RAM 319, to resolve these ambiguous bus cycles. This allowing the software analyzer to analyze the execution of the software in the CPU in an unambiguous manner. An example of one of these ambiguous conditions occurs when the CPU is executing a main memory move instruction. The CPU firmware utilizes logic which is normally associated only with fetching procedure words of software instructions from memory and not the logic normally used for fetching operands. Therefore, if the software analyzer relied only on the information available. from looking at the common bus, the software analyzer would believe that procedure was being read from memory instead of the main memory move instruction which was actually taking place. If these ambiguous conditions did not occur on the common bus, in the preferred embodiment the software analyzer would not require any direct connections to the CPU of the data processing system executing the software.

0058The analysis of the bus cycle information stored in trace RAM 319 is done under the control of microprocessor 306 which operates under the control of the analyzer program stored in PROM 308 and RAM 309. Microprocessor 306, 1/0 control 307, PROM 308, RAM 309 are each connected to microprocessor address bus 334 and microprocessor data bus 335 which provide for the interchange of address and data information between the various elements. Trace address counter 317 is also connected to microprocessor address bus 334. Control 310, status register 311, condition registers 315, and multiplexer 318 are also connected to the microprocessor data bus 335. Control 310 controls the initialization of the software analyzer.

0059Status register 311 holds the status of the software analyzer and indicates if: the tracing is enabled, tracing has been triggered, the trace memory (RAM) is full, the CPU is using the common bus, and other conditions. Multiplexer 318 is an 8 to 1 multiplexer which allows for the 48-bit words of bus cycle information . stored in trace RAM 319 to be multiplexed on to the microprocessor data bus 335 for analysis by microprocessor 306. Also connected as an input to multiplexer 318 is trace address counter 317. Microprocessor 306 is programmed such that it can analyze the information stored in trace RAM 319 and produce a reverse assembly of the software which was executing in the CPU which caused the various bus cycles to occur over common bus 200.

0060Figure 2 shows details of CPU bus use detection logic 301.

0061This logic is used to detect those cases in which the CPU has become the master of the common bus in order to transfer information to another unit on the common bus. As seen hereinbefore, in the data processing system of the preferred embodiment, all transfers over the common bus which require a responding unit to respond to a requesting unit during a second-half bus cycle are done in a manner which provides for the requesting unit to provide its channel number as the channel number of the source during the first-half bus cycle along with the channel number that is the destination of the request who is to provide a response during one or more second-half bus cycle. The exception to this is that during a memory read request, the channel number of the requesting unit is provided as the source channel number but instead of specifying the channel number of the destination, the memory address is provided. Therefore, if all transfers over the common bus resulted in a request cycle during a first-half bus cycle and one or more response cycles during one or more second-half bus cycles, the software analyzer could simply monitor the source and destination channel numbers to determine whether the CPU was either requesting or responding to a transfer over the common bus. This would allow the software analyzer to easily monitor all bus cycles associated with the CPU. However, in the data processing system of the preferred embodiment, there are some bus transfers which only require a single first-half bus cycle and in which only the channel number of the slave (destination) unit is specified and do not provide for the specification of the master (source) unit. An example of this type of bus transfer is when the CPU performs an I/O output command to a peripheral device. During this I/O output command transfer, the CPU places on the common bus only the channel number of the destination unit, the function code which is to be performed by that unit, and 16 bits of data. The CPU does not place on the common bus its channel number as the source channel number. Therefore, .,a software analyzer designed to monitor common bus transfers by only detection of ,a channel number associated with the CPU would not detect this bus cycle and thereby not be able to trace the. execution of this type of CPU software instruction. CPU bus use detection logic 301 is therefore designed to detect this type of bus transfer which is initiated by the CPU including those in which the CPU places its channel number on the common bus.

0062Basically, CPU bus detection logic 301 is designed to detect each occurrence of a bus cycle initiated by a unit of lower priority on the bus than the priority of the software analyzer. Due to the fact that in the preferred embodiment, the CPU of the data processing system is • the lowest priority device on the common bus, positioning the software analyzer on the common bus next to the CPU allows the CPU bus detection logic 301 to defect when the lower priority unit (i.e., the CPU) has been granted control of the bus; the software analyzer knows then that the cycle is associated with the CPU as bus master. Because the CPU must become the bus master in order to initiate a transfer with any other device on common bus 200, the CPU bus use detection logic 301 is used to detect all bus cycles initiated by the CPU and no monitoring of the common bus 200 need be done in order to detect whether the CPU channel number has been provided as the channel number of the source unit, thus simplifying the software analyzer 207. As indicated hereinbefore, CPU channel number detection logic 322 is used to detect those cases in which the CPU is the destination unit by the detecting of the C_PU channel number on the common bus 200.

0063CPU bus use detection logic 301 is used to determine when the CPU has become bus master and is using the common bus to transfer to another unit connected thereto. The CPU bus use detection logic 301 shown in Figure 2 is basically a simplified version of the priority network logic of the CPU. The simplification of the CPU bus use detection logic illustrated in Figure 2 is possible because the logic in Figure 2 does not contain the necessary elements to allow the software analyzer to request use of the common bus and become a bus master. Instead, the logic in Figure 2 simply allows the software analyzer to determine whether the asynchronous bus cycle that is in progress was initiated by another unit on the bus having higher priority than the position of the (slot) on the common bus on which the software analyzer is connected. Because the software analyzer is connected immediately above the CPU on the common bus, the logic in Figure 2 allows the software analyzer to deduce that, if an asynchronous bus cycle is in progress, and no higher priority device on the common bus has been granted the common bus, the common bus must have been granted to a lower priority unit than the software analyzer and therefore the bus cycle must be a bus cycle in which the CPU is the bus master.

0064The common bus utilization detection logic of Figure 2 basically monitors bus control network lines and the nine priority network lines of the common bus and sets CPU bus master flip-flop 402 when a lower priority device has become bus master and the information placed on the common bus by such lower priority device has become stable. CPU bus master flip-flop 402 is reset when the slave (responding) device on the common bus responds with an ACK (acknowledge), a NAK (negative acknowledge), or a WAIT response. The CPU bus master flip-flop 402 corresponds to the grant flip-flop in the CPU. The CPU DCN flip-flop 405 is used to hold the signal CPDCNS- (which indicates that a lower priority device has been granted the use of the common bus) until the lower priority device has placed information placed on the common bus by the lower priority device has stabilized, at which time CPU bus master flip-flop 402 is clocked.

0065The input signals to the bus utilization detection logic illustrated in Figure 2, signals BSREQT+ through BSDCNN+, are all derived from inverting their corresponding signal which appears on the common bus (for example, signal BSREQT+ is derived by inverting signal BSREQT- from common bus 200). Therefore, the input signals to Figure 2 will be discussed as if they come directly from the common bus 200 whereas in actuality they are the output of receivers which receive and invert the signals transmitted on the common bus. The inputs to NAND gate 401 are control signals BSREQT+ and BSDCNN+ and the nine priority network signals BSAUOK+ through BSIUOK+.

0066When a device on the common bus wants to become bus master and use a bus cycle, it makes a bus request by making bus request signal BSREQT+ a binary ONE thus indicating that at least one device on the common bus is requesting a bus cycle. When the priority is resolved and the bus is granted, bus cycle now signal BSDCNN+ becomes a binary ONE indicating that the tie-breaking function is completed and that one specific device is now master of the common bus

0067At the time the bus cycle now signal BSDCNN+ becomes a binary ONE, the master device supplies the information to be transferred on the common bus. Each device on the common bus develops an internal strobe from signal BSDCNN+. The strobe is delayed approximately 60 nanoseconds from when BSDCNN+ becomes a binary ONE in each unit to allow the information to stabilize on the bus. When the delay is completed, the bus skew will have been accounted for and each slave device on the common bus will be able to recognize its address (memory address or channel number). In Figure 2, this internal strobe which is used to clock CPU bus master flip-flop 402 is signal BSDCND+ which is the output of 60 nanosecond delay 404. Thus, this internal strobe signal BSDCN_D+, which is connected to the clock (C) input of CPU bus master flip-flop 402, is used to clock the flip-flop when the information placed on the bus by the master device will be valid. This allows the output of CPU bus master flip-flop 402, signal CPDCNN+ at the Q output thereof, and signal CPDCNN- at the Q-bar output thereof, to be used directly, or signals derive therefrom, to be used to capture information placed on the common bus when the CPU is the master device. For example, in Figure 1 it can be seen that the output of CPU bus use detection logic 301 on line 339 is used to clock address register 302, data register 303, and auto address development logic 304.

0068Returning now to Figure 2, the other input signals to NAND gate 401 are the nine priority signals BSAUOK+ through BSIUOK+. Signals BSAUOK+ through BSIUOK+ will all be a binary ONE if none of the previous (higher priority) devices on the common bus has made a bus request. Therefore, when signal BSDCNN+ becomes a binary ONE (see Figure 9) the output of NAND gate 401, signal CPDCNS-, will become a binary ZERO and set CPU DCN flip-flop 405 if no higher priority device on the common bus has made a bus request.

0069When CPU DCN flip-flop 405 is set, the output thereof, signals CPDCND+ becomes a binary ONE at the Q output and indicates that the bus data cycle now in progress has been requested by a device on the bus which is lower in priority than the software analyzer (i.e., the CPU is now bus master). Signal CPDCDN+ is connected to the data (D) input to CPU bus master flip-flop 402. Sixty nanoseconds after common bus data cycle now signal BSDCNN+ becomes a binary ONE, the output of 60 nanosecond delay 404, signal BSDCN_D+ becomes a binary ONE and clocks CPU bus master flip-flop 402. If signal CPDCND+ at the data input to CPU bus master flip-flop 402 is a binary ONE, indicating that no higher priority device on the common bus has been granted the bus, and therefore the CPU must be the current bus master, CPU bus master 402 will be set when clocked making the Q output, signal CPDCNN+ a binary ONE, and the Q-bar output, signal CPDCNN-, a binary ZERO.

0070CPU bus master flip-flop 402 remains set until the responding (slave) unit on the common bus responds to the bus cycle with an acknowledgement (signal BSACKR+ becomes a binary ONE), a negative acknowledgement (signal BSNAKR+ becomes a binary ONE), or a wait (signal BSwait+ becomes a binary ONE). When any of these three responses occurs, the output of NOR gate 403, signal MYDCNR- becomes a binary ZERO and resets CPU DNC flip-flop 405 and CPU bus master flip-flop 402. The other condition which can occur is a bus master clear which when initiated causes signal BSMCLR+ at NOR 403 to become a binary ONE which in turn causes the resetting of flip-flops 405 and 402.

0071As indicated above, the purpose of the 60 nanosecond delay 404 is to insure that the information presented on the common bus by the bus master has stabilized before the information is strobed from the common bus. This same philosophy is followed in the CPU bus use detection logic 301 in that CPU bus master flip-flop 402 is clocked by this delayed signal thereby assuring that all other clocking within the software analyzer of information from the common bus which is derived from signal CPDCNN+ and CPDCNN- is done when the information on the common bus is valid. The purpose of CPU DNC flip-flop 405 is to assure that the output of NAND gate 401, which is present when the data cycle now (DSDCNN+) signal becomes a binary ONE, is preserved until the expiration of the 60 nanosecond delay and does not disappear before the CPU bus master flip-flop 402 is clocked. As indicated hereinbefore, to handle the case of the CPU (or any other device) when bus master addressing a device which is not present within the system (i.e., an invalid memory address or an invalid channel number) there is time out logic within the CPU which will generate a negative acknowledgement signal (NAK) and thereby generate a signal BSNAKR+ in the binary ONE state which will clear flip-flops 405 and 402.

0072From the above discussion, it can be appreciated that the CPU bus use detection logic 301 can be used to determine when the CPU has become bus master because it determines that the common bus 200 is being utilized by a device that is lower in priority than itself. Because the only device that connects to the common bus of lower priority than the software analyzer is the CPU, the CPU must be the bus master. This allows the software analyzer to detect all cases in which the CPU has become bus master without having to examine the source destination channel number information placed on the common bus by the current bus master. It has been discussed hereinbefore that there are certain cases in which the CPU does not place its channel number on the common bus as a source device channel number.

0073From the above discussion it can be appreciated how the common bus utilization detection logic 301 can be utilized in a system employing a common bus having priority in accessing a bus determined by the position along the common bus. The above discussion has been in terms of utilizing the common bus utilization detection logic in a position which is next to the lowest priority device (the CPU in the data processing system in the preferred embodiment) on the common bus. The same logic can be used to determine when the highest priority device on the common bus has been granted access to the bus by positioning the common bus utilization logic in the next lower priority slot position along the common bus and inverting the meaning of CPU bus master flip-flop 402, such that when signal CP_DC_NN+ is a binary ONE, it would indicate that the highest priority device has not been granted the common bus and when signal CPDCNN+ is a binary ZERO, it would indicate that the highest priority device on the common bus has been granted the common bus.

0074Common bus utilization detection logic 402 can be utilized to determine when an intermediate priority device on a common bus has been granted the common bus by bracketing the intermediate priority device with two sets of common bus utilization detection logic, one on each adjacent side of the intermediate priority device. For example, if a common bus has 10 slots in which to connect devices and the device of interest is connected to the common bus in slot 5. By connecting a first set of common bus utilization detection logic in slot 6, which is the next highest priority slot, and connecting another set of common bus utilization detection logic in slot 4, and taking signal CPDCNN+ from the logic in slot 6 and ANDing it with the signal CPDCNN- from the logic in slot 4, the output of that AND gate will be a binary ONE when the device in slot 5 has become bus master. Signal CPDCNN+ from the logic in slot 6 will be a binary ONE when a device on the common bus which is lower in priority has become bus master and signal CPDCNN- from the logic in slot 4 will be a binary ONE when no lower priority device has become the bus master and therefore the output of ANDing those two signals will become a binary ONE when the device in the slot between the two detection logics has become the bus master.

0075Although the above discussion has been in terms of a preferred embodiment in which the granting of the common bus is determined by priority based upon the requesting device's position along the common bus, the present invention is equally applicable to non-positional priority schemes having a set of common priority lineswhich can be used by the bus utilization detection logic to determine whether the bus has been granted to a device having a higher or lower priority than the priority of the particular device of interest whose bus use as master is to be detected.

0076Although the above discussion has been in terms of a preferred embodiment in which the common resource to be allocated is a common bus, the present invention is equally applicable to any resource that is allocated on a priority basis.