Electrical computers and digital processing systems: processing – Processing control – Branching
Reexamination Certificate
1998-04-22
2001-11-20
Niebling, John F. (Department: 2812)
Electrical computers and digital processing systems: processing
Processing control
Branching
Reexamination Certificate
active
06321331
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The invention relates to systems and methods for debugging software in real time. More particularly, the invention relates to systems and methods for the real time debugging of firmware in embedded systems, e.g. ASIC chips having one or more processors on a single chip.
2. State of the Art
Software debugging may be accomplished in a number of ways, some of which are not performed in real time. A traditional debugging technique is to step through program instructions at a rate much slower than the rate at which the program is designed to run in real time. By stepping through the program instructions one-by-one, errors can be observed as they happen and the program code lines executed immediately prior to the error can be analyzed to find the cause of the error. This technique is not helpful, however, if the error in program execution is the result of timing errors or other types of errors which only occur when the program is running at real time speed. As used herein, the term “real time” means the rate at which a program must execute in order to process the incoming data rate which may be quite high.
A widely used technique for debugging a program which is running in real time is called “tracing”. Tracing involves recording the transactions performed by the computer as it executes the program code. The trace of activities performed by the computer during the time of a failure can be a useful guide in isolating possible causes of the failure.
Another useful debugging tool is to set breakpoints at selected places in the program. The breakpoints trap the flow of the software and provide insight into whether, when, and how certain portions of the software are entered and exited. An analysis of the flow of the software can provide information which is useful in isolating bugs.
Many state-of-the-art tracing and trapping methods are accomplished by a debug support circuit which is connected to the system bus, i.e. the bus which couples the CPU to memory. See, for example, U.S. Pat. No. 5,491,793 to Somasundaram et al. entitled “Debug Support in a Processor Chip.” Connecting a debug circuit to the system bus is convenient because addresses, instructions, and data can be accessed via the system bus. However, coupling the debug support circuit to the system bus increases the electrical load on the bus and interferes with the operation of the bus. Moreover, operation of the system bus may interfere with operation of the debug support circuit. In addition, the system bus may not provide all the information necessary for debugging a program running on a CPU which uses internal cache. These CPUs will not access the system bus if the information they need is available in cache. If an error occurs while the CPU is accessing internal cache, the debug support circuit will not be able to access the information it needs.
Another tracing and trapping method is disclosed in U.S. Pat. No. 5,833,310 to Whistel et al. entitled “On-Chip In-Circuit-Emulator Memory Mapping and Breakpoint Register Modules.” According to this method, an internal bus controller is coupled to the memory address bus and a match register. When a memory address written to the address bus matches an address in the match register, a memory mapping module maps a memory cycle to an external debug memory. The user can set specific bus event conditions for which memory is mapped by writing to a set of breakpoint registers. A disadvantage of this method is that it requires an additional set of I/O pins for the chip so that the external debug memory can be coupled to the chip. This may require a significant number of pins since the addresses to be mapped may be 32 or 64 bits wide.
Still another tracing and trapping method is disclosed in U.S. Pat. No. 5,513,346 to Satagopan et al. entitled “Error Condition Detector for Handling Interrupt in Integrated Circuits Having Multiple Processors.” According to this method, an interrupt processor controller intercepts all interrupts and routes them to the appropriate processor in a multiprocessor chip. The interrupt processor controller includes logic which determines when an interrupt will cause an error because a previously instigated interrupt has not been cleared. When such an error is detected, a bit is set in an error detect register, the bit corresponding to an interprocessor interrupt channel. The bits in the register are ORed and a single bit output indicates the occurrence of an error. The register may then be examined to determine the location of the interrupt error in the executing code. This method does not interfere with the system bus and does not require very many additional pins on the chip. However, the debugging information that it provides is limited.
The Motorola MPC-860 PowerQuicc™ includes a program development system interface port which provides a three bit output indicative of the state of the program execution as the program is being executed. The MPC-860 is a 40 mHz communications controller but the development system interface port is only operable at a rate of 4 mHz. Thus, the port can not be used for real time debugging. The specifications for the MPC-860 are found in the “MPC-860 POWERQUICC USER'S MANUAL”, Copyright 1996 Motorola, Inc., Schaumberg, Ill., the complete disclosure of which is incorporated herein by reference.
ASIC design using one or more embedded processors poses additional debugging challenges. The prior art methods of trapping instructions at a given point in time implies that the system must be stopped to allow debugging of firmware. Once the system is stopped, however, real time events and their timing relationships are lost. If there is a firmware bug which is only identifiable in the presence of live traffic (during real time operations) it is necessary to obtain contextual information about the error before the firmware is changed.
SUMMARY OF THE INVENTION
It is therefore an object of the invention to provide a debugging interface for tracing instructions without loss of real time context and event interaction.
It is also an object of the invention to provide a debugging interface which does not interfere with the operation of a processor or system bus.
It is another object of the invention to provide a debugging interface which does not require many additional pins on a processor chip.
It is a further object of the invention to provide a debugging interface which provides access to a substantial amount of information about the executed instructions.
In accord with these objects which will be discussed in detail below, the debugging interface of the present invention includes a first decoder coupled to the sequencer of a processor and to the Instruction RAM (IRAM) of the processor. The first decoder, according to the invention, provides a real time three bit output on a cycle by cycle basis which is indicative of the processor activity during the last clock cycle. According to a presently preferred embodiment, the three bit output indicates seven different conditions regarding processor activity. In particular, the three bit output indicates whether or not a new instruction has been executed since the last clock cycle, and if a new instruction has been executed, whether the last instruction executed by the processor was an immediate jump, a jump to register, or a branch taken. In addition, the three bit output will indicate whether execution of the instruction resulted in an exception. By recording this three bit output over time, and comparing it to the actual instructions listed in the program code, important debugging information is obtained about a program which was running in real time.
According to a preferred embodiment of the invention, a second decoder and an event history buffer are coupled to the cause register of the sequencer of the processor. In particular, the second decoder is coupled to the enable input of the history buffer and the cause register is coupled to the data input of the history buffer. The second decoder decodes the contents of the cause register and ena
Hembrook Paul
Mariano Richard
Parrella Eugene L.
Roy Subhash C.
Gallagher Thomas A
Gordon David P
Jacobson David S
Niebling John F.
TranSwitch Corporation
LandOfFree
Real time debugger interface for embedded systems does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Real time debugger interface for embedded systems, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Real time debugger interface for embedded systems will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2574307