WO2001069390A2 - Method and apparatus for debugging programs in a distributed environment - Google Patents

Method and apparatus for debugging programs in a distributed environment Download PDF

Info

Publication number
WO2001069390A2
WO2001069390A2 PCT/US2001/040292 US0140292W WO0169390A2 WO 2001069390 A2 WO2001069390 A2 WO 2001069390A2 US 0140292 W US0140292 W US 0140292W WO 0169390 A2 WO0169390 A2 WO 0169390A2
Authority
WO
WIPO (PCT)
Prior art keywords
processes
hardware
processor
processors
debug
Prior art date
Application number
PCT/US2001/040292
Other languages
French (fr)
Other versions
WO2001069390A3 (en
Inventor
Thomas J. Pennello
Henry A. Davis
Original Assignee
Arc Cores, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Arc Cores, Inc. filed Critical Arc Cores, Inc.
Priority to AU2001255808A priority Critical patent/AU2001255808A1/en
Publication of WO2001069390A2 publication Critical patent/WO2001069390A2/en
Publication of WO2001069390A3 publication Critical patent/WO2001069390A3/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/362Software debugging
    • G06F11/3636Software debugging by tracing the execution of the program

Definitions

  • the present invention relates to the field of debugging programs in a distributed environment, such as a set of heterogeneous hardware processors (integrated circuits or In- Circuit Emulators), and/or software-based simulators.
  • a distributed environment such as a set of heterogeneous hardware processors (integrated circuits or In- Circuit Emulators), and/or software-based simulators.
  • the process of debugging software intended for operation in embedded applications is a task that employs many different tools depending on the stage of software readiness. Programs are often organized in a hierarchical fashion, but need not include such structure. While structured programs are easier to debug because there is a reduced span of control within the software, both structured and unstructured programs commonly employ similar programming techniques including functions, subroutines, co-routines, and the like.
  • Software-based simulators are used to provide design engineers and programmers (hereinafter "engineers") with absolute control over the execution of the software to be debugged. This process permits control at varying degrees of granularity ranging from a single line of code to larger blocks such as procedures, functions, and subroutines. Control includes among other facilities, the ability to start and stop execution, report results and change memory contents.
  • Multiprocessor systems complicate the debugging process significantly as compared to a unitary processor hardware environment.
  • the most complex debugging environment is one in which the processors used in the multi-processor hardware employ different instructions sets. This condition is known to those skilled in the art as a heterogeneous multiprocessor system.
  • heterogeneous development environments potentially introduces more error, due largely to the fact that the development environment associated with one of the heterogeneous processors utilizes one function for a given keystroke or other user input, while a different environment may utilize an all together different function for that same keystroke or input. Accordingly, the engineer must in effect maintain a "correlation table" for the various functions and associated inputs depending on which development environment is being used.
  • an improved method for debugging programs in a distributed environment comprises heterogeneous hardware digital processors (integrated circuits or In-Circuit Emulators), and/or software-based simulators, and the method comprises: identifying a plurality of processes; initializing each of the processes; executing with a single thread of control among the processes; and continuously cycling among the processes to obtain status information. Each "running" simulation process simulates the execution of a single instruction for each status request.
  • the method further comprises initializing profile information, and incrementing the profile history after simulation (simulator) or execution (hardware) of one instruction.
  • an improved computer program useful for debugging such distributed programs comprises a C ⁇ source code listing reduced to an object code representation and stored on the magnetic storage device readable by a microcomputer, and adapted to run on the central processing unit thereof.
  • the computer program further comprises an interactive, menu-driven graphical user interface (GUI), thereby facilitating ease of use.
  • GUI graphical user interface
  • the basic design of the computer program takes an object-oriented approach, with an abstract class defined to provide the interface to an individual process within the target system.
  • an improved debug architecture comprises a digital processor with a debug process running thereon, at least one simulation process associated and in data communication therewith, and at least one hardware process in data communication with the processor, wherein the simulation and hardware processes are executed with a single thread of control via the debig process.
  • an improved apparatus for running the aforementioned debug computer program comprises a stand-alone microcomputer system (e.g., IBM PC) having a display, central processing unit, data storage device(s), and input device.
  • the apparatus is adapted to run one or more of the aforementioned simulators and the debug program, and interface with one or more hardware processes external to the apparatus via respective data interfaces.
  • the engineer may then debug the multiple hardware processes using the debug program and simulation process(es), advantageously avoiding the need for multiple hardware/software environments for the debug and simulation processes.
  • Fig. 1 is a logical flow diagram illustrating one exemplary embodiment of the general debugging methodology employed the present invention.
  • Fig. la is logical flow diagram illustrating an alternate embodiment of determining the sleep interval based on poll delay according to the invention.
  • Fig. 2 is a logical flow diagram illustrating a second embodiment of the debugging methodology employed in the present invention, incorporating profile histories.
  • Fig. 2a is a logical flow diagram illustrating the use of the method of Fig. 2 to optimize the systems performance of a multi-processor based system.
  • Fig. 3 is a block diagram of an exemplary multi-processor debugging architecture for which the methodology of Fig. 1 may be applied.
  • Fig. 4 is a functional block diagram of one exemplary embodiment of a computer system useful for running a computer program embodying the method of Fig. 1.
  • processor is meant to include any integrated circuit or other electronic device capable of performing an operation on at least one instruction word including, without limitation, reduced instruction set core (RISC) processors such as the ARCTM user- configurable core manufactured by the Assignee hereof, central processing units (CPUs), and digital signal processors (DSPs).
  • RISC reduced instruction set core
  • CPUs central processing units
  • DSPs digital signal processors
  • the hardware of such devices may be integrated onto a single piece of silicon (“die”), or distributed among two or more dies.
  • various functional aspects of the processor may be implemented solely as software or firmware associated with the processor.
  • process refers to executable software that runs within a processor environment. This means that the process is typically scheduled to run based on a time schedule or system event. It will generally have its own Process Control Block (PCB) that describes it.
  • PCB Process Control Block
  • the PCB may include items such as the call stack location, code location, scheduling priority, etc.
  • task and “process” are often interchangeable with regard to computer programs.
  • a "task” as used herein generally refers to a process-like entity whose PCB is referred to as a Task Control Block (TCB).
  • a "thread” refers to a process having the same properties as a task except that it runs within a task context and uses the task's TCB. Multiple threads can run within the context of a single task. Threads are often more efficient than tasks because they don't require as much time to be switched into CPU context when the task they are associated with is already running.
  • the present invention provides a flexible system for debugging programs in a distributed environment.
  • a distributed environment comprises a set of heterogeneous hardware processors (integrated circuits or In-Circuit Emulators), and/or software-based simulators; see the discussion with respect to Fig. 3 below.
  • the basic design takes an object-oriented approach with an abstract class defined to provide the basic interface to an individual process within the target system.
  • object-oriented approach allows language-independence at the design level.
  • Object-oriented programming is well understood in the computer programming arts, and accordingly will not be described further herein.
  • the methods and instance variables of this abstract class fall into two categories: (i) those relating to direct control of the target processor and examination of its state; and (ii) those relating to synchronization and control of the individual processes by the debugging system.
  • Instance variables relating to direct control of the target processor include, inter alia, setting and examining register values and the contents of memory; starting, stopping, and "single-stepping" the processor; setting hardware-controlled breakpoints; and similar operations.
  • Registers are often employed by engineers (or the output of compilers) to hold working variables; i.e., those that are being operated upon. These registers frequently contain values of substantial interest to the design engineer/programmer. Consequently, it is important for the debug environment to provide access to such register values. Many programming errors may be temporarily corrected by a skilled engineer through affording the ability to modify the contents of these registers. Such is often the case with programmatic loop constructs that either terminate prematurely or fail to terminate at the intended time.
  • the engineer performing the debugging task may be able to permit the program to proceed further in the program sequence while producing correct results. This ability significantly reduces development time by permitting the engineer to make changes that are local in scope, yet have a global impact on the functioning of the software.
  • So-called single stepping of a processor permits engineers to follow the execution of the software to determine where implementation or design errors exist.
  • Generally accepted debugging practice is defined, rnter alia, in IEEE 1008-1987 IEEE Standard for Software Unit Testing and terms in IEEE Std
  • Synchronization and control variables include, mter alia, time of last status check; the current delay between status checks; whether the process is running in a simulator or in hardware; the processor type and options; and similar parameters.
  • individual subclasses are defined for each supported processor, In-Circuit Emulator (ICE), or simulator with each subclass being implemented generally as a dynamically loadable library.
  • ICE In-Circuit Emulator
  • simulator By creating individual subclasses for each processor, it is possible to dynamically link processors into the system without the need to recompile or otherwise reconfigure the static structure of the debug environment.
  • the use of a dynamically loadable library permits changes to be made while the debugger is in operation without necessarily halting the execution of other processors. Further, this permits the engineer performing debug activities to simulate the failure of one or more procesors by selectively switching them out of the debug environment.
  • Some digital processor families reserve a section of the processor instruction set for so- called “extended operations” or “extensions” which are typically implemented in customized sections of the hardware to perform application-specific functions such as Viterbi decode, FFT, and the like.
  • the processor instance class for those processor types defines a further interface to dynamically loadable libraries which embody one or more of the possible extended operations.
  • the libraries provide the functions for displaying the extension instruction in machine code listings.
  • the extension library must also provide the implementation of the instruction itself. It will be appreciated that software simulators operate by implementing the logical operation of hardware in software. Hardware functions are performed by sequences of software isntructions in the simulator.
  • the hardware extension library contains the HDL model for the hardware used during the compilation phase. Since the extension may also be implemented during the debug phase by a software simulator, it is necessary to also provide this software in the extension library.
  • each process When debugging, each process will normally be in one of two states. It may be stopped, with execution suspended while the user examines and possibly modifies the process state before continuing. Alternatively, the process may be running, in which case it executes instructions until it reaches a breakpoint, error condition, a certain amount of time has passed, or the user manually requests the operation be suspended. It will be recognized that the foregoing list of conditions under which a running process is terminated is not all inclusive; other situations where the process terminates may exist.
  • the debugger of the present invention executes with a single thread of control which, when in "run” mode, continuously cycles among the various processes obtaining status information.
  • Each "running" simulation process will simulate the execution of a single instruction for each status request.
  • Associated with each running hardware process is an indication of when the status was last checked, and a variable delay interval indicating when it should next be checked.
  • This association occurs as a consequence of employing an object oriented language such as C++, but may also be implemented by use of explicit parameters passed via function or subrountine calls. Alternatively, the association may be made completely explicit by use of a common data structure such as mailboxes, message buffers and simlar communications protocols commonly used by operating systems to manage such data.
  • each iteration through the status loop further includes an idle period designed to delay the debugger until at least one process is ready to be checked.
  • FIG. 1 the generalized method of debugging distributed programs according to the present invention is described.
  • the exemplary embodiment of Fig. 1 is described in terms of a computer program, although it will be recognized that such program is only one means for implementing the method of the invention.
  • certain portions of the functionality described herein could be implemented in hardware if desired.
  • the method 100 generally comprises the steps necessary to repeatedly obtain the status of each running processor in sequence, subject to the aforementioned conditions. If any of the running processors are being simulated, the simulation of the illustrated embodiment will be advanced by one instruction before its status is checked. To allow processes running on hardware to run as efficiently as possible, they will only be checked when a specified per-process time interval has elapsed since the previous check. This time interval may be varied (either statically, such as by merely changing the duration of the interval, or dynamically, such as based on the output of an associated algorithm which calculates a time interval based on other parameters), and is set according to the attributes of the paticular process and hardware.
  • a predetermined delay may be invoked to prevent unnecessary passes through the check loop. Similar to the per-process interval period, the predetermined delay may be varied (statically or dynamically) as well.
  • step 102 the poll delay associated with each process is initialized.
  • the term “poll delay” refers to the minimum time period between retrievals of processor status information for display to the user.
  • the poll delay is initialized to the minimum value, and its next poll time set to "now".
  • the term “now” is used to indicate the current point in time at which "now” is referenced.
  • step 104 the "ran simulator” value is set to “false”, and the “need sleep” value also set “false”. The "ran simulator” and “need sleep” values determine the desirability of introducing a delay before the next cycle of processor status checks.
  • the debugger state is determined; if in "run", the program proceeds to step
  • step 108 the run status of that process is determined. If the debugger is in a state other than run (e.g., stop) , then the process returns as shwon in Fig. 1. For each process, if the process is running, the process type is next determined in step 1 10.
  • process type refers to whether the processor is running in the simulation or hardware environment.
  • step 1 12 the program proceeds to step 1 12, where the simulated processor is advanced through one instruction cycle. The simulated processor's status is subsequently checked. The "ran simulator” value is then set to "true”, and the program returns to step 108 again for the next process.
  • step 1 10 the value of the "next poll” is determined per step 1 14; if it represents a time in the future relative to the present time, the "need sleep” value is set to "true” per step 1 16, and the program returns to step 108 again. This in effect delays the program for a predetermined time until the next polling opportunity is available, as previously described.
  • step 120 If the value of the next poll is the current time or a time in the past, the polling opportunity is immediately available, and the status of the process is checked per step 120.
  • the value of "next poll” is set to the current time plus the processor's poll delay per step 120 as well.
  • the "check time” value is also set to the minimum of the current "check time” or the “next poll” value in this step 120 as well. Note that the status check of step 120 may change the poll delay value to better balance the need to display processor status with the desire to minimize the use of system resources. This need is determined by monitoring the current systems resource availability and comparing that to the amount that may be required to perform both the display function and other functions that mnay be operating concurrently.
  • the program checks the value of the "ran simulator" variable per step 122 to determine whether any of the running processes are executing in simulators. If so, the program advantagously returns immediately to step 104 so that the simulation(s) will run as quickly as possible, as is desired in order to most closely replicate the actual operating conditions of the simulated device. If no running processes are executing in simulators, then the program proceeds to step 124 to determine if any of the hardware processes were not yet ready to be checked, as indicated by the "need sleep" value set to "true”. If all hardware processes have been checked, the program returns to step 104. If at least one hardware process was not ready to be checked, the program sleeps until the next "check time" per step 126. At the next check time, the program awakes and returns to step 104.
  • the value associated with the "need sleep” interval is algorithmically determined based on analysis of the value of the "next poll” determination in step 1 14. Specifically, as illustrated in Fig. la, the current time (referenced to the time when step 1 14 is executed) is subtracted from the value of the "next poll” determined in step 114 to arrive at a minimum delay value before the polling of that device is available. In this fashion, the "need sleep" interval is dynamically adjusted based on the next available polling opportunity, thereby reducing an "extra” delay introduced by a fixed sleep interval.
  • the required sleep interval is determined based on statistical analysis of historical data obtained either from past debug operations for the hardware environment under analysis, from operating history generated immediately prior to the poll delay determination in step 1 14 (such as using a moving "window” technique of the type well known in the art), or some combination thereof. Numerous types of statistical/historical analyses and associated algorithms are known to those of ordinary skill in the programming arts, and accordingly are not described further herein.
  • Fig. 2 an alternate embodiment of the method of Figs. 1-1 a is described.
  • Optimizing systems performance in a single processor system is a relatively simple matter of moving applications code to better utilize the CPU, modifying the code to better reflect the systems capabilities, and/or developing a new algorithm for the specific circumstances under which the system is operating. For multiple processor systems, however, this process becomes much more complicated. Each individual processor can be optimized for locally optimum performance but the systems may still have suboptimal performance.
  • the methodology 200 of Fig. 2 advantageously permits engineers to perform both local and global optimizations across multiple processors based on the execution history of the system when data representative of "real world" inputs is supplied. Alternatively, real world data may be supplied to the system for the purpose of collecting execution history profiles.
  • profiles may identify: (i) individual instructions of a program running on a specific processor; (ii) sequential blocks of code running on a specific processor, and (iii) functions, subroutines or other information determined by the engineer to be valuable during the optimization process. Such information may include, for example, patterns of register references, number of memory references, patterns of memory reference, and the like.
  • the aforementioned profile history is initialized during the beginning of the run loop (step 203), and profile history collected (steps 213, 215) after both the simulations step and hardware execution step.
  • profile history data collection functions simply record execution information specified by the engineer for later presentation.
  • the modified run loop of Fig. 2 operates in the same manner as that of Figs. 1-1 a in all other respects.
  • Fig. 2a the method 200 of Fig. 2 is employed as a step in the method
  • the run loop function of Fig. 2 is performed to gather execution history as may be determined by the user's selection of information to be gathered (step 252). These results are then examined (step 254) to determine which if any processors are relatively overloaded, and which if any are relatively underloaded.
  • Portions of executable code may be rearranged within the scope of a single processor's program space, restructured so as to consume fewer resources, or partitioned across processors so as to more economically computer the desired result (step 256).
  • the aforementioned improvements to the performance of the multi-processor based system are well known to one of ordinary skill in the art of programming multi-processor systems and is not further discussed here.
  • the run loop function is again executed (step 258) to gather execution history data that will prove or disprove the performance. The process continues iterating until the performance goals determined by the user have been met, or the user has determined that the goals can not be met.
  • the architecture 300 generally comprises a debugger/simulator process 302, and a plurality of hardware processes 304 each operatively coupled via respective data paths 306 and control paths 308 to the debugger/simulator 302. Note that the control paths 308 are unidirectional, whereas data may flow both to and from the hardware processes 304 via the data paths 306. It will be recognized that, depending on the type of hardware platform employed to implement the debugger/simulator 302 (see Fig.
  • various types of data and control pathway hardware may be employed, such as RS-232, IEEE-1394 "Firewire", or even fiber or wireless links, so long as any required timing relationships are preserved.
  • the debugger/simulator 302, including data and control paths may be physically integrated with the hardware processes, such as by being disposed entirely within a single silicon substrate.
  • the debugger/simulator may be employed as an algorithm running on a RISC processor, CISC microprocessor, digital signal processor (DSP), or other digital processor associated with the individual hardware processes.
  • the debugger/simulator 302 of Fig. 3 comprises a plurality of individual simulator processes 310, operatively coupled to a debugger process 312 via additional respective data paths 314 and control paths 316.
  • the debugger and simulator processes 310, 312 in one embodiment comprise software implementing the foregoing methodology, although it can be appreciated that at least portions of the methods of Figs. 1 and 2 may be embodied in firmware or even hardware if desired.
  • Each simulator process 310 (1 through N) of Fig. 3 is representative of a single instance of a simulator that functions as the target central processing unit (CPU) of the complete system.
  • Each simulator process 310 may implement any instruction set architecture as is needed by the actual designed heterogeneous multiprocessor system. Simulation processes may be used for a number of reasons including unavailability of hardware, a desire to control systems debug such that hardware transient behaviors are not present, and for reasons of cost.
  • each hardware process 304 represents a single instruction set architecture within the heterogeneous multiprocessor system. These processes may be actual physical semiconductor devices, or an in-circuit emulator (ICE) of the type well known in the art. Hardware processes may be used when fast execution is desired, debugging of hardware interfaces is taking place, or the actual operation of the hardware is in some way different that that exhibited by the simulation model.
  • ICE in-circuit emulator
  • Each of these processes may implement any desired instruction set architecture or a fixed function operation.
  • Examples of an instruction set architecture include but is not limited to: Intel 8080, 8086, 8036, Pentium, Motorola 68000, 68030, PowerPC, Texas Instruments TMX320C6100 and the like.
  • Fixed function operations may include, but it not limited to: special purpose hardware such as Viterbi decode, digital filters, noise shapers, FFT, and the like.
  • the present invention is advantageously compatible with systems represented by only simulator processes or hardware processes, as well as those that are represented by a combination of simulation and hardware processes. These processes may be homogeneous or heterogeneous in nature, thereby providing the engineer with additional flexibility not present in prior art techniques.
  • FIG. 4 one embodiment of a computing device capable of implementing the debugging methods (in the form of a computer program) discussed previously herein with respect to Figs. l-2a is described. It is noted that the foregoing methods are readily reduced to source code listings in any useful higher level programming language, such as for example C ⁇ , and subsequently compiled, by one of ordinary skill in the computer programming arts. Appendix I hereto provides one such exemplary source code listing.
  • the computing device 400 comprises a motherboard 401 having a central processing unit (CPU) 402, random access memory (RAM) 404, and memory controller 405.
  • a storage device 406 (such as a hard disk drive or CD-ROM), input device 407 (such as a keyboard or mouse), and display device 408 (such as a CRT, plasma, or TFT display), as well as buses necessary to support the operation of the host and peripheral components, are also provided.
  • the method of Fig. 1 are embodied in the form of an object code representation of a computer program and stored in the RAM 404 and/or storage device 406 for use by the CPU 402 during analysis, the latter being well known in the computing arts.
  • the computer program may reside on a removable storage device (not shown) such as a floppy disk or magnetic data cartridge of the type also well known in the art.
  • the user analyzes the data input from the various sources (such as heterogeneous processors) by inputting initiating operation of the computer program via the program displays and the input device 407 during system operation.
  • the system may be configured to automatically accept (and store if desired) the various data inputs and run the computer program when sufficient data exist, or on a periodic or ongoing basis. Many such alternative are possible, each being well within the skill of the ordinary practitioner.
  • Analyses and/or formatted data generated by the program are stored in the storage device 406 for later retrieval, displayed on the graphic display device 408 for viewing by the user, or output to an external device such as a printer, data storage unit, other peripheral component via a serial or parallel port 412 if desired. It may be appreciated that any number of types of infromation may be displayed on the graphic display device. The following is illustrative and not prescriptive for such data infromation.
  • the actual proram code executed by the process may be displayed in source code format, assembly languag format, or a numerical radix based format where the radix corresponds to a word size or other informnative division of data..
  • Execution traces of addresses, address ranges, data values, subroutine entry/exit and the ike may also be displayed.
  • interprocessor commnnications and internal program or processor state information may be displayed.
  • the forgoing infromation may be displayed in a vairety of forms convenient to the user such as bar garphs, histograms, "eye charts", flowcharts, or textual forms.
  • One preferred embodiment of the hardware used in conjunction with the debugger program previously described herein is based on the industry standard IBM Personal Computer architecture operating on an Intel microprocessor.
  • Such a computer generally comprises a display mechanism such as a CRT display, input devices such as a keyboard and mouse, storage media such as a hard disk drive, communications ports to communicate with any external hardware such as target hardware boards or in-circuit emulators (ICEs).
  • ICEs in-circuit emulators
  • Other alternatives include workstations manufactured by Sun Microsystems of Mountain View California based on the Sun SPARC microprocessor. These workstations employ peripherals such as those listed above for the IBM Personal Computer but operate internally on a different microprocessor, systems bus, and UNIX-based operating system. However, these examples are merely illustrative, and not prescriptive of the type of hardware on which the invention can operate.
  • R_system. check_status_always) ⁇ // Warning: each time you do a status check, process // could have terminated, so verify that process is non-zero, f (R system. is simulator!)) ⁇ check_status ( ) ; ran_a_s ⁇ mulator was_executmg
  • Process *process R.get_process ( ) ; dbg && process && printf! 'pic %d cd %d ⁇ n", process . ⁇ s_executmg ( ) , R . complet ⁇ on_delayed) ; // The process may have died as a result of checking status, if (process && 'process . ⁇ s_executmg () ) ⁇ if (R.complet ⁇ on_delayed) ⁇

Abstract

A method and apparatus for debugging programs in a distributed environment, such as a set of heterogeneous hardware processors (integrated circuits or In-Circuit Emulators), and/or software-based simulators. In one embodiment, the method comprises identifying a plurality of processes; initializing each of the processes; executing with a single thread of control among the processes; and continuously cycling among the processes to obtain status information. A computer program and apparatus for implementing the aforementioned methodology are also disclosed.

Description

METHOD AND APPARATUS FOR DEBUGGING PROGRAMS IN A DISTRIBUTED ENVIRONMENT
Priority This application claims priority to U.S. provisional patent application Serial No.
60/189,521 filed March 15, 2000 and entitled "Method and Apparatus for Debugging Heterogeneous Processors .*
Copyright
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and
Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.
Background of the Invention 1. Field of the Invention
The present invention relates to the field of debugging programs in a distributed environment, such as a set of heterogeneous hardware processors (integrated circuits or In- Circuit Emulators), and/or software-based simulators.
2. Description of Related Technology
The process of debugging software intended for operation in embedded applications is a task that employs many different tools depending on the stage of software readiness. Programs are often organized in a hierarchical fashion, but need not include such structure. While structured programs are easier to debug because there is a reduced span of control within the software, both structured and unstructured programs commonly employ similar programming techniques including functions, subroutines, co-routines, and the like. Software-based simulators are used to provide design engineers and programmers (hereinafter "engineers") with absolute control over the execution of the software to be debugged. This process permits control at varying degrees of granularity ranging from a single line of code to larger blocks such as procedures, functions, and subroutines. Control includes among other facilities, the ability to start and stop execution, report results and change memory contents.
Multiprocessor systems complicate the debugging process significantly as compared to a unitary processor hardware environment. The most complex debugging environment is one in which the processors used in the multi-processor hardware employ different instructions sets. This condition is known to those skilled in the art as a heterogeneous multiprocessor system.
Heretofore, engineers have relied on diverse development environments, often provided by many different vendors, to debug such heterogeneous systems. These diverse development environments often provide different user interfaces, different commands, different capabilities, and sometimes employ different underlying computer operating systems which makes information transference between the systems challenging at best.
These conditions force engineers involved with debug to be less productive than would otherwise be possible were the interfaces common between all of the different processors. Further, each different system requires engineers to become conversant with its unique capabilities and disabilities, which requires more learning time and results in reduced productivity.
Additionally, the use of such heterogeneous development environments potentially introduces more error, due largely to the fact that the development environment associated with one of the heterogeneous processors utilizes one function for a given keystroke or other user input, while a different environment may utilize an all together different function for that same keystroke or input. Accordingly, the engineer must in effect maintain a "correlation table" for the various functions and associated inputs depending on which development environment is being used.
Based on the foregoing, what is needed is an improved method and apparatus for debugging devices such as heterogeneous processors. Such method and apparatus would ideally be readily adaptable to a number of different hardware/software environments, would allow for ready transfer of information associated with one processor to the development/debug environment of another, thereby facilitating side-by-side comparison of the operation of the different processors. Such improved debug method and apparatus would also be readily adapted to run on conventional microprocessor-based platforms, and accommodate inputs from both the aforementioned hardware processes and simulation processes. Summary of the Invention The present invention satisfies the aforementioned needs by an improved method and apparatus for debugging devices such as heterogeneous processors. In a first aspect of the invention, an improved method for debugging programs in a distributed environment is disclosed. In one exemplary embodiment the environment comprises heterogeneous hardware digital processors (integrated circuits or In-Circuit Emulators), and/or software-based simulators, and the method comprises: identifying a plurality of processes; initializing each of the processes; executing with a single thread of control among the processes; and continuously cycling among the processes to obtain status information. Each "running" simulation process simulates the execution of a single instruction for each status request. In a second exemplary embodiment, the method further comprises initializing profile information, and incrementing the profile history after simulation (simulator) or execution (hardware) of one instruction. In a second aspect of the invention, an improved computer program useful for debugging such distributed programs is disclosed. In one exemplary embodiment, the computer program comprises a C^ source code listing reduced to an object code representation and stored on the magnetic storage device readable by a microcomputer, and adapted to run on the central processing unit thereof. The computer program further comprises an interactive, menu-driven graphical user interface (GUI), thereby facilitating ease of use. The basic design of the computer program takes an object-oriented approach, with an abstract class defined to provide the interface to an individual process within the target system.
In a third aspect of the invention, an improved debug architecture is disclosed. In one exemplary embodiment, the improved debug architecture comprises a digital processor with a debug process running thereon, at least one simulation process associated and in data communication therewith, and at least one hardware process in data communication with the processor, wherein the simulation and hardware processes are executed with a single thread of control via the debig process.
In a fourth aspect of the invention, an improved apparatus for running the aforementioned debug computer program is disclosed. In one exemplary embodiment, the system comprises a stand-alone microcomputer system (e.g., IBM PC) having a display, central processing unit, data storage device(s), and input device. The apparatus is adapted to run one or more of the aforementioned simulators and the debug program, and interface with one or more hardware processes external to the apparatus via respective data interfaces. The engineer may then debug the multiple hardware processes using the debug program and simulation process(es), advantageously avoiding the need for multiple hardware/software environments for the debug and simulation processes.
Brief Description of the Drawings
Fig. 1 is a logical flow diagram illustrating one exemplary embodiment of the general debugging methodology employed the present invention.
Fig. la is logical flow diagram illustrating an alternate embodiment of determining the sleep interval based on poll delay according to the invention.
Fig. 2 is a logical flow diagram illustrating a second embodiment of the debugging methodology employed in the present invention, incorporating profile histories.
Fig. 2a is a logical flow diagram illustrating the use of the method of Fig. 2 to optimize the systems performance of a multi-processor based system.
Fig. 3 is a block diagram of an exemplary multi-processor debugging architecture for which the methodology of Fig. 1 may be applied. Fig. 4 is a functional block diagram of one exemplary embodiment of a computer system useful for running a computer program embodying the method of Fig. 1.
Detailed Description Reference is now made to the drawings wherein like numerals refer to like parts throughout.
As used herein, the term "processor" is meant to include any integrated circuit or other electronic device capable of performing an operation on at least one instruction word including, without limitation, reduced instruction set core (RISC) processors such as the ARC™ user- configurable core manufactured by the Assignee hereof, central processing units (CPUs), and digital signal processors (DSPs). The hardware of such devices may be integrated onto a single piece of silicon ("die"), or distributed among two or more dies. Furthermore, various functional aspects of the processor may be implemented solely as software or firmware associated with the processor.
As used herein, the term "process" refers to executable software that runs within a processor environment. This means that the process is typically scheduled to run based on a time schedule or system event. It will generally have its own Process Control Block (PCB) that describes it. The PCB may include items such as the call stack location, code location, scheduling priority, etc. The terms "task" and "process" are often interchangeable with regard to computer programs.
Similarly, a "task" as used herein generally refers to a process-like entity whose PCB is referred to as a Task Control Block (TCB). A "thread" refers to a process having the same properties as a task except that it runs within a task context and uses the task's TCB. Multiple threads can run within the context of a single task. Threads are often more efficient than tasks because they don't require as much time to be switched into CPU context when the task they are associated with is already running.
Overview
In general, the present invention provides a flexible system for debugging programs in a distributed environment. In one embodiment, such a distributed environment comprises a set of heterogeneous hardware processors (integrated circuits or In-Circuit Emulators), and/or software-based simulators; see the discussion with respect to Fig. 3 below.
The basic design takes an object-oriented approach with an abstract class defined to provide the basic interface to an individual process within the target system. Among other benefits, the use of an object-oriented approach allows language-independence at the design level. Object-oriented programming is well understood in the computer programming arts, and accordingly will not be described further herein.
The methods and instance variables of this abstract class fall into two categories: (i) those relating to direct control of the target processor and examination of its state; and (ii) those relating to synchronization and control of the individual processes by the debugging system.
Instance variables relating to direct control of the target processor include, inter alia, setting and examining register values and the contents of memory; starting, stopping, and "single-stepping" the processor; setting hardware-controlled breakpoints; and similar operations. Registers are often employed by engineers (or the output of compilers) to hold working variables; i.e., those that are being operated upon. These registers frequently contain values of substantial interest to the design engineer/programmer. Consequently, it is important for the debug environment to provide access to such register values. Many programming errors may be temporarily corrected by a skilled engineer through affording the ability to modify the contents of these registers. Such is often the case with programmatic loop constructs that either terminate prematurely or fail to terminate at the intended time. By modifying a register value, the engineer performing the debugging task may be able to permit the program to proceed further in the program sequence while producing correct results. This ability significantly reduces development time by permitting the engineer to make changes that are local in scope, yet have a global impact on the functioning of the software.
So-called "single stepping" of a processor, whether as a simulation process or a hardware process, permits engineers to follow the execution of the software to determine where implementation or design errors exist. Generally accepted debugging practice is defined, rnter alia, in IEEE 1008-1987 IEEE Standard for Software Unit Testing and terms in IEEE Std
610.12-1990, Standard Glossary of Software Engineering Terminology (ANSI).
Synchronization and control variables include, mter alia, time of last status check; the current delay between status checks; whether the process is running in a simulator or in hardware; the processor type and options; and similar parameters.
In the present embodiment of the invention, individual subclasses are defined for each supported processor, In-Circuit Emulator (ICE), or simulator with each subclass being implemented generally as a dynamically loadable library. By creating individual subclasses for each processor, it is possible to dynamically link processors into the system without the need to recompile or otherwise reconfigure the static structure of the debug environment. The use of a dynamically loadable library permits changes to be made while the debugger is in operation without necessarily halting the execution of other processors. Further, this permits the engineer performing debug activities to simulate the failure of one or more procesors by selectively switching them out of the debug environment. In addition, it is possible to substitute the operation of actual hardware in place of a simulator or in-circuit emulator to permit continuous debugging as more information is gathered.
Some digital processor families reserve a section of the processor instruction set for so- called "extended operations" or "extensions" which are typically implemented in customized sections of the hardware to perform application-specific functions such as Viterbi decode, FFT, and the like. To handle these extended operations in the debugger, the processor instance class for those processor types defines a further interface to dynamically loadable libraries which embody one or more of the possible extended operations. When the instance is an interface to a hardware processor, the libraries provide the functions for displaying the extension instruction in machine code listings. When the instance is a software simulator, the extension library must also provide the implementation of the instruction itself. It will be appreciated that software simulators operate by implementing the logical operation of hardware in software. Hardware functions are performed by sequences of software isntructions in the simulator. State information and registers are assigned specific memory locations in the simulation software memory space. Within the ARC design environment, the hardware extension library contains the HDL model for the hardware used during the compilation phase. Since the extension may also be implemented during the debug phase by a software simulator, it is necessary to also provide this software in the extension library.
When debugging, each process will normally be in one of two states. It may be stopped, with execution suspended while the user examines and possibly modifies the process state before continuing. Alternatively, the process may be running, in which case it executes instructions until it reaches a breakpoint, error condition, a certain amount of time has passed, or the user manually requests the operation be suspended. It will be recognized that the foregoing list of conditions under which a running process is terminated is not all inclusive; other situations where the process terminates may exist.
When running, it is desirable for the process to execute, as nearly as possible, at the speed with which execution would occur if it were not running under the control of a debugger. In this way, the actual operation of the process on the device is most closely simulated. However, it is also desirable to rapidly and continuously update the status displays for the user. In practice, obtaining status information from hardware processors often takes a large amount of time as compared to the execution of a single instruction; so the use of continuous status requests would significantly impair performance. Conversely, when running in a simulator, obtaining the status has relatively little impact; some care must be taken, however, to keep multiple simulations synchronized as though they were running on parallel hardware processors. Furthermore, it is desirable that the debugger itself run as efficiently as possible to reduce the impact on any other programs which may be concurrently executing.
To address the foregoing issues, the debugger of the present invention executes with a single thread of control which, when in "run" mode, continuously cycles among the various processes obtaining status information. Each "running" simulation process will simulate the execution of a single instruction for each status request. Associated with each running hardware process is an indication of when the status was last checked, and a variable delay interval indicating when it should next be checked. This association occurs as a consequence of employing an object oriented language such as C++, but may also be implemented by use of explicit parameters passed via function or subrountine calls. Alternatively, the association may be made completely explicit by use of a common data structure such as mailboxes, message buffers and simlar communications protocols commonly used by operating systems to manage such data. In the instance where all such running processes are executing on hardware processors, then each iteration through the status loop further includes an idle period designed to delay the debugger until at least one process is ready to be checked.
Methodology
Referring now to Fig. 1, the generalized method of debugging distributed programs according to the present invention is described. The exemplary embodiment of Fig. 1 is described in terms of a computer program, although it will be recognized that such program is only one means for implementing the method of the invention. For example, certain portions of the functionality described herein could be implemented in hardware if desired.
As illustrated in Fig. 1 , the method 100 generally comprises the steps necessary to repeatedly obtain the status of each running processor in sequence, subject to the aforementioned conditions. If any of the running processors are being simulated, the simulation of the illustrated embodiment will be advanced by one instruction before its status is checked. To allow processes running on hardware to run as efficiently as possible, they will only be checked when a specified per-process time interval has elapsed since the previous check. This time interval may be varied (either statically, such as by merely changing the duration of the interval, or dynamically, such as based on the output of an associated algorithm which calculates a time interval based on other parameters), and is set according to the attributes of the paticular process and hardware. At the end of each check cycle, if it is determined that all running processes are executing on hardware, and none of the running processes are ready to be checked, a predetermined delay may be invoked to prevent unnecessary passes through the check loop. Similar to the per-process interval period, the predetermined delay may be varied (statically or dynamically) as well.
In step 102, the poll delay associated with each process is initialized. As used herein, the term "poll delay" refers to the minimum time period between retrievals of processor status information for display to the user. In the present embodiment, the poll delay is initialized to the minimum value, and its next poll time set to "now". As used herein, the term "now" is used to indicate the current point in time at which "now" is referenced. Next, in step 104, the "ran simulator" value is set to "false", and the "need sleep" value also set "false". The "ran simulator" and "need sleep" values determine the desirability of introducing a delay before the next cycle of processor status checks. In step 104, the debugger state is determined; if in "run", the program proceeds to step
106, where for each process, the run status of that process is determined (step 108). If the debugger is in a state other than run (e.g., stop) , then the process returns as shwon in Fig. 1. For each process, if the process is running, the process type is next determined in step 1 10. The term "process type" as used herein refers to whether the processor is running in the simulation or hardware environment.
If the process type is the simulation environment, the program proceeds to step 1 12, where the simulated processor is advanced through one instruction cycle. The simulated processor's status is subsequently checked. The "ran simulator" value is then set to "true", and the program returns to step 108 again for the next process. In the hardware environment (step 1 10), the value of the "next poll" is determined per step 1 14; if it represents a time in the future relative to the present time, the "need sleep" value is set to "true" per step 1 16, and the program returns to step 108 again. This in effect delays the program for a predetermined time until the next polling opportunity is available, as previously described. If the value of the next poll is the current time or a time in the past, the polling opportunity is immediately available, and the status of the process is checked per step 120. The value of "next poll" is set to the current time plus the processor's poll delay per step 120 as well. The "check time" value is also set to the minimum of the current "check time" or the "next poll" value in this step 120 as well. Note that the status check of step 120 may change the poll delay value to better balance the need to display processor status with the desire to minimize the use of system resources. This need is determined by monitoring the curent systems resource availability and comparing that to the amount that may be required to perform both the display function and other functions that mnay be operating concurrently. This monitoring is well known to those skilled in the art of operating systems design as part of "load balancing," Proper load balance may be determined by a number of techniques known to those of ordinary skilled in the art of operating systems design, the specific techniques of which ar not relevant to the present invention. For example, such techniques are taught in "Operating Systems Principles" by Per Brinch Hansen, Prentice Hall 1973. After these operations have been completed, the program returns to step 108.
After the foregoing steps 1 10 through 120 have been completed for each process, the program checks the value of the "ran simulator" variable per step 122 to determine whether any of the running processes are executing in simulators. If so, the program advantagously returns immediately to step 104 so that the simulation(s) will run as quickly as possible, as is desired in order to most closely replicate the actual operating conditions of the simulated device. If no running processes are executing in simulators, then the program proceeds to step 124 to determine if any of the hardware processes were not yet ready to be checked, as indicated by the "need sleep" value set to "true". If all hardware processes have been checked, the program returns to step 104. If at least one hardware process was not ready to be checked, the program sleeps until the next "check time" per step 126. At the next check time, the program awakes and returns to step 104.
It will be recognized that while the aforementioned poll delay and "need sleep" intervals are described in terms of predetermined, fixed time periods, these intervals may alternatively be variable in nature, depending on the value of other parameters or the existence of other circumstances within the hardware/simulation environments. For example, in one alternate embodiment, the value associated with the "need sleep" interval is algorithmically determined based on analysis of the value of the "next poll" determination in step 1 14. Specifically, as illustrated in Fig. la, the current time (referenced to the time when step 1 14 is executed) is subtracted from the value of the "next poll" determined in step 114 to arrive at a minimum delay value before the polling of that device is available. In this fashion, the "need sleep" interval is dynamically adjusted based on the next available polling opportunity, thereby reducing an "extra" delay introduced by a fixed sleep interval.
In another embodiment, the required sleep interval is determined based on statistical analysis of historical data obtained either from past debug operations for the hardware environment under analysis, from operating history generated immediately prior to the poll delay determination in step 1 14 (such as using a moving "window" technique of the type well known in the art), or some combination thereof. Numerous types of statistical/historical analyses and associated algorithms are known to those of ordinary skill in the programming arts, and accordingly are not described further herein.
Referring now to Fig. 2, an alternate embodiment of the method of Figs. 1-1 a is described. Optimizing systems performance in a single processor system is a relatively simple matter of moving applications code to better utilize the CPU, modifying the code to better reflect the systems capabilities, and/or developing a new algorithm for the specific circumstances under which the system is operating. For multiple processor systems, however, this process becomes much more complicated. Each individual processor can be optimized for locally optimum performance but the systems may still have suboptimal performance. The methodology 200 of Fig. 2 advantageously permits engineers to perform both local and global optimizations across multiple processors based on the execution history of the system when data representative of "real world" inputs is supplied. Alternatively, real world data may be supplied to the system for the purpose of collecting execution history profiles. These profiles may identify: (i) individual instructions of a program running on a specific processor; (ii) sequential blocks of code running on a specific processor, and (iii) functions, subroutines or other information determined by the engineer to be valuable during the optimization process. Such information may include, for example, patterns of register references, number of memory references, patterns of memory reference, and the like. In the modified run loop of Fig. 2, the aforementioned profile history is initialized during the beginning of the run loop (step 203), and profile history collected (steps 213, 215) after both the simulations step and hardware execution step. These two profile history data collection functions simply record execution information specified by the engineer for later presentation. The modified run loop of Fig. 2 operates in the same manner as that of Figs. 1-1 a in all other respects.
Referring now to Fig. 2a, the method 200 of Fig. 2 is employed as a step in the method
250 of optimizing the performance of a mutliprocessor system. The run loop function of Fig. 2 is performed to gather execution history as may be determined by the user's selection of information to be gathered (step 252). These results are then examined (step 254) to determine which if any processors are relatively overloaded, and which if any are relatively underloaded.
Portions of executable code may be rearranged within the scope of a single processor's program space, restructured so as to consume fewer resources, or partitioned across processors so as to more economically computer the desired result (step 256). The aforementioned improvements to the performance of the multi-processor based system are well known to one of ordinary skill in the art of programming multi-processor systems and is not further discussed here. Once the improvements are made, the run loop function is again executed (step 258) to gather execution history data that will prove or disprove the performance. The process continues iterating until the performance goals determined by the user have been met, or the user has determined that the goals can not be met.
It will be recognized that while the foregoing example and description with respect to Figs. 1, la, 2, and 2a herein is cast in terms of a specific series of steps for accomplishing the desired result (i.e., debugging in a distributed environment), various permutations of this series of steps, including substitution and/or addition of other steps, may be used consistent with the invention disclosed herein. Accordingly, the scope of the disclosed invention should be determined by the claims appended hereto, without respect to specific embodiments or limitations presented within the foregoing discussion.
Referring now to Fig. 3, one exemplary multiprocessor debugging architecture 300 for which the foregoing method may be used is described. The architecture 300 generally comprises a debugger/simulator process 302, and a plurality of hardware processes 304 each operatively coupled via respective data paths 306 and control paths 308 to the debugger/simulator 302. Note that the control paths 308 are unidirectional, whereas data may flow both to and from the hardware processes 304 via the data paths 306. It will be recognized that, depending on the type of hardware platform employed to implement the debugger/simulator 302 (see Fig. 4 below for one exemplary embodiment), various types of data and control pathway hardware may be employed, such as RS-232, IEEE-1394 "Firewire", or even fiber or wireless links, so long as any required timing relationships are preserved. Alternatively, the debugger/simulator 302, including data and control paths, may be physically integrated with the hardware processes, such as by being disposed entirely within a single silicon substrate. For example, the debugger/simulator may be employed as an algorithm running on a RISC processor, CISC microprocessor, digital signal processor (DSP), or other digital processor associated with the individual hardware processes.
The debugger/simulator 302 of Fig. 3 comprises a plurality of individual simulator processes 310, operatively coupled to a debugger process 312 via additional respective data paths 314 and control paths 316. The debugger and simulator processes 310, 312 in one embodiment comprise software implementing the foregoing methodology, although it can be appreciated that at least portions of the methods of Figs. 1 and 2 may be embodied in firmware or even hardware if desired.
Each simulator process 310 (1 through N) of Fig. 3 is representative of a single instance of a simulator that functions as the target central processing unit (CPU) of the complete system. Each simulator process 310 may implement any instruction set architecture as is needed by the actual designed heterogeneous multiprocessor system. Simulation processes may be used for a number of reasons including unavailability of hardware, a desire to control systems debug such that hardware transient behaviors are not present, and for reasons of cost. Likewise, each hardware process 304 represents a single instruction set architecture within the heterogeneous multiprocessor system. These processes may be actual physical semiconductor devices, or an in-circuit emulator (ICE) of the type well known in the art. Hardware processes may be used when fast execution is desired, debugging of hardware interfaces is taking place, or the actual operation of the hardware is in some way different that that exhibited by the simulation model.
Each of these processes, either hardware or software, may implement any desired instruction set architecture or a fixed function operation. Examples of an instruction set architecture include but is not limited to: Intel 8080, 8086, 8036, Pentium, Motorola 68000, 68030, PowerPC, Texas Instruments TMX320C6100 and the like. Fixed function operations may include, but it not limited to: special purpose hardware such as Viterbi decode, digital filters, noise shapers, FFT, and the like.
Accordingly, the present invention is advantageously compatible with systems represented by only simulator processes or hardware processes, as well as those that are represented by a combination of simulation and hardware processes. These processes may be homogeneous or heterogeneous in nature, thereby providing the engineer with additional flexibility not present in prior art techniques.
Apparatus for Implementing Methodology
Referring now to Fig. 4, one embodiment of a computing device capable of implementing the debugging methods (in the form of a computer program) discussed previously herein with respect to Figs. l-2a is described. It is noted that the foregoing methods are readily reduced to source code listings in any useful higher level programming language, such as for example C, and subsequently compiled, by one of ordinary skill in the computer programming arts. Appendix I hereto provides one such exemplary source code listing.
The computing device 400 comprises a motherboard 401 having a central processing unit (CPU) 402, random access memory (RAM) 404, and memory controller 405. A storage device 406 (such as a hard disk drive or CD-ROM), input device 407 (such as a keyboard or mouse), and display device 408 (such as a CRT, plasma, or TFT display), as well as buses necessary to support the operation of the host and peripheral components, are also provided. The method of Fig. 1 are embodied in the form of an object code representation of a computer program and stored in the RAM 404 and/or storage device 406 for use by the CPU 402 during analysis, the latter being well known in the computing arts. Alternatively, the computer program may reside on a removable storage device (not shown) such as a floppy disk or magnetic data cartridge of the type also well known in the art. The user (not shown) analyzes the data input from the various sources (such as heterogeneous processors) by inputting initiating operation of the computer program via the program displays and the input device 407 during system operation. Alternatively, the system may be configured to automatically accept (and store if desired) the various data inputs and run the computer program when sufficient data exist, or on a periodic or ongoing basis. Many such alternative are possible, each being well within the skill of the ordinary practitioner. Analyses and/or formatted data generated by the program are stored in the storage device 406 for later retrieval, displayed on the graphic display device 408 for viewing by the user, or output to an external device such as a printer, data storage unit, other peripheral component via a serial or parallel port 412 if desired. It may be appreciated that any number of types of infromation may be displayed on the graphic display device. The following is illustrative and not prescriptive for such data infromation. The actual proram code executed by the process may be displayed in source code format, assembly languag format, or a numerical radix based format where the radix corresponds to a word size or other informnative division of data.. Execution traces of addresses, address ranges, data values, subroutine entry/exit and the ike may also be displayed. For some debug envirnoments interprocessor commnnications and internal program or processor state information may be displayed. The forgoing infromation may be displayed in a vairety of forms convenient to the user such as bar garphs, histograms, "eye charts", flowcharts, or textual forms. One preferred embodiment of the hardware used in conjunction with the debugger program previously described herein is based on the industry standard IBM Personal Computer architecture operating on an Intel microprocessor. Such a computer generally comprises a display mechanism such as a CRT display, input devices such as a keyboard and mouse, storage media such as a hard disk drive, communications ports to communicate with any external hardware such as target hardware boards or in-circuit emulators (ICEs). Other alternatives include workstations manufactured by Sun Microsystems of Mountain View California based on the Sun SPARC microprocessor. These workstations employ peripherals such as those listed above for the IBM Personal Computer but operate internally on a different microprocessor, systems bus, and UNIX-based operating system. However, these examples are merely illustrative, and not prescriptive of the type of hardware on which the invention can operate. In addition to the so-called "clone" machines of the above named companies, there are many other alternative personal computers and workstations upon which the invention can operate. These include those manufactured by Hewlett-Packard, Intergraph, Data General, Apple Computer, and others. While the above detailed description has shown, described, and pointed out novel features of the invention as applied to various embodiments, it will be understood that various omissions, substitutions, and changes in the form and details of the device or process illustrated may be made by those skilled in the art without departing from the invention. The foregoing description is of the best mode presently contemplated of carrying out the invention. This description is in no way meant to be limiting, but rather should be taken as illustrative of the general principles of the invention. The scope of the invention should be determined with reference to the claims.
APPENDIX I
Copyright © 2000-2001 Metaware Software, Inc. All rights reserved.
NOINLINE void check_for_completιon ( void each ( ) -> (common_RCE*) ' , // Set of command processors. common_RCE *only_thιs_one, bool Srunmng, bool &repeat_check_ιmmedιately, unsigned *sleep_tιmep=0) { if (sleep_tιmep) *sleep_tιmep = 0; // Polling. If all the running processes are non-simulators, should
// sleep m-between polling. Otherwise, can run the simulators
// and check the real machine in between, as long as wait long enough
// so as not to burden the real machine. i.e., the loop is:
// repeat ... // for each running R do
// if R is a simulator, check its status.
// else if R is hardware, if we've waited
// long enough since last check, check it
// else early = mm (early, R' s last check time + mm wait) // end for
// if there were no simulators, sleep (current_tιme-early)
// end repeat //
// With the GUI this process will be different. The GUI will issue // status checks periodically. running = FALSE; repeat_check_ιmmedιately = FALSE; bool ran a simulator = FALSE, need sleep = FALSE; unsigned earlιest_we_can__check_hardware = (unsigned) -1; unsigned now() { return get_system( ) .get_llιo ( ) . alltιme_mιllιseconds ( ) ; ) bool changed_status = FALSE, somebody_wants_checkmg_always = FALSE; changed_status = FALSE; somebody_wants_checkιng_always = FALSE; for R <- each() do { if (only_thιs_one '= 0 && only_thιs_one '= R) continue; dbg && pπntf ( "check for completion on %s\n", R . get_system ( ) . get_name ( ) ) ; if (R. get_process ( ) == 0) continue; dbg && printf ( "checking process [ %d] : \n" , R. rce_number) ; dbg && (R.dιsplay_processes ( ) , 0) ; bool was_executιng = R. get_process ( ) . ιs_executmg ( ) ; void check_status ( ) { i ( ' R.get_system( ) . ιs_sιmulator ( ) ) dbg && printf (" M status check on H [ d] %s\n", R. rce_number, R . get_system ( ) . name ( ) ) ; R. status (0, FALSE, 'was executing) ; }
System *R_system = R. get_system( ) ;
0 && printf ("system %s wase %d csa %d\n",
R_system.name ( ) , was_executιng, R_system. check_status_always) ; if (R_system. check_status_always ) somebody_wants_checkmg_always = TRUE; if (was_executmg || R_system. check_status_always) { // Warning: each time you do a status check, process // could have terminated, so verify that process is non-zero, f (R system. is simulator!)) { check_status ( ) ; ran_a_sιmulator = was_executmg
// Either was executing or is now executing. II R.get process)) && R.get process!). is executing!); } - _ else { unsigned Now = now ( ) ; unsigned POLL_WAIT = R. get_process (). et_key (). delay . get_poll_delay ( ) ; if (FALSE && globals.trace_sleep) { printf ("[%d] POLL WAIT comes back as %d ",
R.get_rce_number, POLL_WAIT) ; printf ("delta is %d ",Now - R. tιme_sιnce_last_poll) ; printf ( "earliest %d\n", earliest we can check hardware); > _ _ _ _ if (Now - R . tιme_smce_last_poll >= P0LL_WAIT ) { / / printf ( "polling [ %d] \n" , R . get_rce_number ( ) ) ; check_status ( ) ; Now = no ( ) ; / / Status might have taken a while . R. tιme_sιnce_last_poll = Now;
// Now get the next value of delay, which may have // gone down (e.g., hostlmk) or up. This has // the necessary side effect of changing the delay, if (R.get process!))
POLL_WAIT = R.get_process ( ) . get_key ( ) . delay. current_poll_delay( ) ; } else need_sleep = TRUE; unsigned earliest = R.tιme_sιnce_last_poll + POLL_WAIT; earlιest_we_can_check_hardware = _mm ( earlιest_we_can_check_hardware, earliest) ;
} bool ιs_executmg = // The process may have died as a result of checking status.
R. get_process ( ) && R. get_process ( ) . ιs_executmg ( ) ; running = running | | ιs_executιng; changed_status |= was_executιng ' = ιs_executmg;
} Process *process = R.get_process ( ) ; dbg && process && printf!" 'pic %d cd %d\n", process . ιs_executmg ( ) , R . completιon_delayed) ; // The process may have died as a result of checking status, if (process && 'process . ιs_executmg () ) { if (R.completιon_delayed) {
// Announce status. dbg && printf ("Call step completion\n") ; R. step_completιon (R. completmg_stmt_step, TRUE) ; } process . get_key ( ) . delay .mmιmιze_poll_delay ( ) ; } // repeat check immediately = TRUE; } i ran_a_sιmulator && need_sleep && running) { unsigned Now = now ( ) ; if (Now > earlιest_we_can_check_hardware) ; else { unsigned sleep_tιme = earlιest_we_can_check_hardware-Now; if (sleep_tιmep) { // printf ("!not sleeping for %d; let GUI do it. \n" , sleep_time) ;
*sleep_timep = sleep_time; } else { get_system( ) .get_llio ( ) .sleep (sleep_time) ; // printf ("! sleep for %d\n", sleep_time) ; } } }

Claims

WE CLAIM:
1. A method of debugging a plurality of distributed programs, comprising: identifying a plurality of processes; initializing each of said processes; executing with a single thread of control among said processes; and continuously switching between said processes to obtain status information relating thereto.
2. The method of Claim 1, wherein the act of identifying a plurality of processes comprises identifying at least one simulation process and at least one hardware process.
3. The method of Claim 2, further comprising analyzing said status information to identify at least one or more occurrences or errors within at least one of said distributed programs.
4. The method of Claim 2, further comprising: defining at least one object class, defining at least one first object subclass for said at least one hardware process; and defining at least one second object subclass for said at least one simulation process.
5. The method of Claim 1 , wherein the act of executing comprises providing at least one first instance variable adapted for control of at least one of said plurality of processes.
6. The method of Claim 5, further comprising dynamically changing polling times associated with said at least one of said plurality of processes based on the status thereof.
7. The method of Claim 5, further comprising defining an interface to a first library for said at least one hardware process.
8. The method of Claim 7, further comprising accessing said first library via said interface in order to provide functions relating to at least one extension instruction.
9. The method of Claim 8, further comprising defining an interface to a first library for said at least one simulation process.
10. The method of Claim 8, further comprising accessing said first library via said interface in order to provide functions relating to at least one extension instruction, including the implemention of said at least one extension instruction.
1 1. The method of Claim 2, wherein the act of continuously switching comprises cycling between said processes in repeated succession.
12. The method of Claim 2, wherein the act of initializing comprises: initializing a first process resident on a first hardware processor; and initializing a second process on a simulator.
13. The method of Claim 1, further comprising: defining a plurality of individual subclasses for each of said plurality of processes; and implementing at least a portion of said subclasses as a dynamically loadable library.
14. A system for debugging heterogenous processors, comprising: a processor having at least one debug process running thereon, and at least one simulation process associated and in data communication with said at least one debug process; and at least one hardware process in data communication with said at least on debug process; wherein said at least one simulation and hardware processes are controlled via a single thread.
15. The system of Claim 14, wherein said processor comprises a digital processor embodied as an integrated circuit, and said at least one debug process comprises a computer program adapted to run on said integrated circuit.
16. The system of Claim 15, further comprising at least one external port adapted for said data communication with respective ones of said at least one hardware processes.
17. The system of Claim 16, wherein said at least one simulation process comprises a computer program running on said digital processor.
18. The system of Claim 17, further comprising a plurality of dynamically loadable libraries, at least a portion of said libraries being adapted for communication with said at least one debug process.
19. The system of Claim 14, further comprising a first storage device adapted for se therewith, said storage device comprising: a storage medium configured to store a plurality of data thereon; and a plurality of data stored thereon, said data comprising a computer program adapted to run on said processor, and configured to debug one or more other computer programs using the method comprising: identifying a plurality of software processes including said at least one simulation process and said at least one hardware process; initializing each of said plurality of processes; executing with a single thread of control among said processes; and continuously switching between said processes to obtain status information relating thereto; and a second storage device adapted to at least temporarily store said status information for use by said at least one debug process.
20. A method of optimizing the operation a multi-processor system comprising a plurality of software processes, comprising: initializing each of said processes; executing with a single thread of control among said processes; iteratively obtaining execution profiling information from at least a portion of said processors; and optimizing the operation of said system based at least in part on said execution profiling information.
21. A method of debugging a plurality of processors using a debug process, said debug process being in data communication with said processors, comprising: initializing each of said processors; executing with a single thread of control among said processors using said debug process; establishing a minimum polling time for each of said processors; and obtaining status information from each of said processors based at least in part on said polling interval.
PCT/US2001/040292 2000-03-15 2001-03-14 Method and apparatus for debugging programs in a distributed environment WO2001069390A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001255808A AU2001255808A1 (en) 2000-03-15 2001-03-14 Method and apparatus for debugging programs in a distributed environment

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US18952100P 2000-03-15 2000-03-15
US60/189,521 2000-03-15

Publications (2)

Publication Number Publication Date
WO2001069390A2 true WO2001069390A2 (en) 2001-09-20
WO2001069390A3 WO2001069390A3 (en) 2002-06-06

Family

ID=22697673

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/040292 WO2001069390A2 (en) 2000-03-15 2001-03-14 Method and apparatus for debugging programs in a distributed environment

Country Status (3)

Country Link
US (1) US7133820B2 (en)
AU (1) AU2001255808A1 (en)
WO (1) WO2001069390A2 (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007028227A1 (en) * 2005-09-09 2007-03-15 Ibm Canada Limited - Ibm Canada Limitee Integrating different programming language debug tools for observing thread execution
CN100336033C (en) * 2005-02-25 2007-09-05 清华大学 Single-chip analog system with multi-processor structure
CN112270408A (en) * 2020-09-30 2021-01-26 北京清微智能科技有限公司 Heterogeneous system simulator framework and generation, access and main cycle operation method thereof

Families Citing this family (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6931636B2 (en) * 2000-08-08 2005-08-16 Texas Instruments Incorporated Multiprocessor emulation support using dynamic linking
DE10161140A1 (en) * 2001-12-12 2003-07-03 Siemens Ag System and method for tracking and / or evaluating the exchange of information
US20040083089A1 (en) * 2002-10-24 2004-04-29 International Business Machines Corporation System and method for coordinated operation or a plurality of computers
US20040158443A1 (en) * 2003-02-11 2004-08-12 Texas Instruments Incorporated Functional verification using heterogeneous simulators
TW588238B (en) * 2003-02-13 2004-05-21 Micro Star Int Co Ltd Program debugging method
US20050071824A1 (en) * 2003-08-22 2005-03-31 K. N. Keerthi Bhushan Method and system for executing software on non-native platforms
US7383539B2 (en) * 2003-09-18 2008-06-03 International Business Machines Corporation Managing breakpoints in a multi-threaded environment
US8090564B1 (en) 2003-11-03 2012-01-03 Synopsys, Inc. Automatic generation of transaction level bus simulation instructions from bus protocol
US7328429B2 (en) * 2003-11-13 2008-02-05 Intel Corporation Instruction operand tracing for software debug
US7684970B2 (en) * 2004-06-25 2010-03-23 Intel Corporation Graphical user interface for use during processor simulation
US7742905B2 (en) * 2005-02-25 2010-06-22 Coware, Inc. Method and system for dynamically adjusting speed versus accuracy of computer platform simulation
US7716031B2 (en) * 2005-02-25 2010-05-11 Coware, Inc. Interface converter for unified view of multiple computer system simulations
US7650273B2 (en) * 2005-09-21 2010-01-19 Intel Corporation Performance simulation of multiprocessor systems
US8769495B1 (en) * 2005-09-30 2014-07-01 Sony Computer Entertainment Inc. Systems and methods for debugging in a multiprocessor environment
CN100435111C (en) * 2005-10-13 2008-11-19 同济大学 Parallel adjusting and performance analyzing method of supporting multi-language multi-platform under isomerized environment
US7747426B2 (en) * 2005-12-02 2010-06-29 International Business Machines Corporation System simulation using multi-tasking computer code
US8543367B1 (en) 2006-02-16 2013-09-24 Synopsys, Inc. Simulation with dynamic run-time accuracy adjustment
US7899661B2 (en) 2006-02-16 2011-03-01 Synopsys, Inc. Run-time switching for simulation with dynamic run-time accuracy adjustment
US7983742B2 (en) * 2006-02-27 2011-07-19 Vito Starc Multi-channel system for beat to beat QT interval variability
US7792792B2 (en) * 2006-05-22 2010-09-07 Microsoft Corporation Synchronizing structured web site contents
US20080126862A1 (en) * 2006-08-25 2008-05-29 Microchip Technology Incorporated System and Method for Testing Software Code for Use on a Target Processor
US7925487B2 (en) * 2007-06-29 2011-04-12 Microsoft Corporation Replaying distributed systems
US8739133B2 (en) * 2007-12-21 2014-05-27 International Business Machines Corporation Multi-threaded debugger support
US7933759B2 (en) * 2008-03-28 2011-04-26 Microsoft Corporation Predicate checking for distributed systems
US10169199B2 (en) * 2008-06-10 2019-01-01 Microsoft Technology Licensing, Llc Automatic model-specific debugger extensions
US7747742B2 (en) * 2008-06-27 2010-06-29 Microsoft Corporation Online predicate checking for distributed systems
US7984332B2 (en) * 2008-11-17 2011-07-19 Microsoft Corporation Distributed system checker
US8397218B2 (en) * 2010-10-19 2013-03-12 International Business Machines Corporation Step granularity selection in a software debugger
US8423343B2 (en) * 2011-01-24 2013-04-16 National Tsing Hua University High-parallelism synchronization approach for multi-core instruction-set simulation
US20130227520A1 (en) * 2011-09-01 2013-08-29 Eric Hosick Rapid process integration through visual integration and simple interface programming
US9195457B1 (en) * 2014-06-11 2015-11-24 Amazon Technologies, Inc. Interactive application programming interface documentation
US9852048B2 (en) * 2016-01-18 2017-12-26 International Business Machines Corporation Simulating process variable changes during process runtime
US10162731B2 (en) * 2017-01-23 2018-12-25 International Business Machines Corporation Conditional breakpoint on call stack during debugging at runtime
US10169197B2 (en) * 2017-01-24 2019-01-01 International Business Machines Corporation Temporary breakpoints during debug process
US10593010B2 (en) * 2017-12-13 2020-03-17 Microsoft Technology Licensing, Llc Techniques for capturing and executing graphics processing operations
US10606338B2 (en) 2017-12-29 2020-03-31 Intel Corporation Energy-aware power sharing control
CN111092767B (en) * 2019-12-20 2022-10-18 北京百度网讯科技有限公司 Method and device for debugging equipment
US11200150B2 (en) * 2020-01-13 2021-12-14 EMC IP Holding Company LLC Multi-tenanted build system with visualization of dynamic build progress

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5787245A (en) * 1995-11-13 1998-07-28 Object Technology Licensing Corporation Portable debugging service utilizing a client debugger object and a server debugger object

Family Cites Families (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4063080A (en) * 1976-06-30 1977-12-13 International Business Machines Corporation Method of propagation delay testing a level sensitive array logic system
SE467229B (en) * 1983-08-19 1992-06-15 Kurt Katzeff DEVICE FOR CREATING AN INFORMATION AND / OR INSTRUCTION INTENDED TO BE INPUT INTO A COMPUTER'S SOFTWARE
US4674089A (en) 1985-04-16 1987-06-16 Intel Corporation In-circuit emulator
US5274797A (en) * 1986-05-30 1993-12-28 Bull Hn Information Systems Inc. Multiprocessor system with centralized initialization, testing and monitoring of the system and providing centralized timing
JPH0833615B2 (en) * 1987-11-06 1996-03-29 富士写真フイルム株式会社 Photosensitive strip container
JPH01297764A (en) * 1988-05-25 1989-11-30 Nec Corp Processor
US5179702A (en) * 1989-12-29 1993-01-12 Supercomputer Systems Limited Partnership System and method for controlling a highly parallel multiprocessor using an anarchy based scheduler for parallel execution thread scheduling
US5193187A (en) * 1989-12-29 1993-03-09 Supercomputer Systems Limited Partnership Fast interrupt mechanism for interrupting processors in parallel in a multiprocessor system wherein processors are assigned process ID numbers
US5175856A (en) * 1990-06-11 1992-12-29 Supercomputer Systems Limited Partnership Computer with integrated hierarchical representation (ihr) of program wherein ihr file is available for debugging and optimizing during target execution
US5410685A (en) * 1990-06-12 1995-04-25 Regents Of The University Of Michigan Non-intrinsive method and system for recovering the state of a computer system and non-intrusive debugging method and system utilizing same
US5495615A (en) * 1990-12-21 1996-02-27 Intel Corp Multiprocessor interrupt controller with remote reading of interrupt control registers
JPH07113912B2 (en) * 1991-05-31 1995-12-06 富士ゼロックス株式会社 Debug method for distributed information processing system
US5452437A (en) * 1991-11-18 1995-09-19 Motorola, Inc. Methods of debugging multiprocessor system
US5642478A (en) * 1994-12-29 1997-06-24 International Business Machines Corporation Distributed trace data acquisition system
US5980096A (en) * 1995-01-17 1999-11-09 Intertech Ventures, Ltd. Computer-based system, methods and graphical interface for information storage, modeling and stimulation of complex systems
US5819093A (en) * 1995-03-03 1998-10-06 Sun Microsystems, Inc. System and method for a distributed debugger for debugging distributed application programs
US5828863A (en) * 1995-06-09 1998-10-27 Canon Information Systems, Inc. Interface device connected between a LAN and a printer for outputting formatted debug information about the printer to the printer
US5815653A (en) * 1995-11-13 1998-09-29 You; Lawrence L. Debugging system with portable debug environment-independent client and non-portable platform-specific server
US6158045A (en) * 1995-11-13 2000-12-05 Object Technology Licensing Corporation Portable debugging services utilizing a client debugger object and a server debugger object with flexible addressing support
US5778230A (en) * 1995-11-13 1998-07-07 Object Technology Licensing Corp. Goal directed object-oriented debugging system
US6117181A (en) * 1996-03-22 2000-09-12 Sun Microsystems, Inc. Synchronization mechanism for distributed hardware simulation
JP3175757B2 (en) * 1996-08-13 2001-06-11 日本電気株式会社 Debug system
US6567837B1 (en) * 1997-01-29 2003-05-20 Iq Systems Object oriented processor arrays
US6061517A (en) * 1997-03-31 2000-05-09 International Business Machines Corporation Multi-tier debugging
US5892941A (en) * 1997-04-29 1999-04-06 Microsoft Corporation Multiple user software debugging system
US6282701B1 (en) * 1997-07-31 2001-08-28 Mutek Solutions, Ltd. System and method for monitoring and analyzing the execution of computer programs
US6083281A (en) * 1997-11-14 2000-07-04 Nortel Networks Corporation Process and apparatus for tracing software entities in a distributed system
US6230307B1 (en) * 1998-01-26 2001-05-08 Xilinx, Inc. System and method for programming the hardware of field programmable gate arrays (FPGAs) and related reconfiguration resources as if they were software by creating hardware objects
US6061709A (en) * 1998-07-31 2000-05-09 Integrated Systems Design Center, Inc. Integrated hardware and software task control executive
KR20010072477A (en) * 1998-08-13 2001-07-31 썬 마이크로시스템즈, 인코포레이티드 Method and apparatus of translating and executing native code in a virtual machine environment
CA2246270C (en) * 1998-09-01 2003-09-23 Ibm Canada Limited - Ibm Canada Limitee Debugging multiple related processes simultaneously
US7162713B2 (en) * 2000-03-14 2007-01-09 Arc International Difference engine method and apparatus
US6718294B1 (en) * 2000-05-16 2004-04-06 Mindspeed Technologies, Inc. System and method for synchronized control of system simulators with multiple processor cores
US20030005407A1 (en) * 2000-06-23 2003-01-02 Hines Kenneth J. System and method for coordination-centric design of software systems

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5787245A (en) * 1995-11-13 1998-07-28 Object Technology Licensing Corporation Portable debugging service utilizing a client debugger object and a server debugger object

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "A Java-based Debug Model" RESEARCH DISCLOSURE, vol. 41, no. 415, 1 November 1998 (1998-11-01), XP002180478 Havant, UK, article No. 41577 *
ANONYMOUS: "Enea OSE Systems and Green Hills Software Team To Make Run-mode Debugging a Reality" GREEN HILLS SOFTWARE INC. , [Online] 5 August 1999 (1999-08-05), XP002180477 News & Press Retrieved from the Internet: <URL:http://www.ghs.com/news/archive/99080 5ene.html> [retrieved on 2001-10-18] *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100336033C (en) * 2005-02-25 2007-09-05 清华大学 Single-chip analog system with multi-processor structure
WO2007028227A1 (en) * 2005-09-09 2007-03-15 Ibm Canada Limited - Ibm Canada Limitee Integrating different programming language debug tools for observing thread execution
US8196109B2 (en) 2005-09-09 2012-06-05 International Business Machines Corporation Common debug adaptor in a multiple computer programming language environment
CN112270408A (en) * 2020-09-30 2021-01-26 北京清微智能科技有限公司 Heterogeneous system simulator framework and generation, access and main cycle operation method thereof

Also Published As

Publication number Publication date
AU2001255808A1 (en) 2001-09-24
US7133820B2 (en) 2006-11-07
US20010056341A1 (en) 2001-12-27
WO2001069390A3 (en) 2002-06-06

Similar Documents

Publication Publication Date Title
US7133820B2 (en) Method and apparatus for debugging programs in a distributed environment
Romer et al. Instrumentation and optimization of Win32/Intel executables using Etch
US6374369B1 (en) Stochastic performance analysis method and apparatus therefor
US8903703B2 (en) Dynamically adjusting speed versus accuracy of computer platform simulation
Tsai et al. A noninterference monitoring and replay mechanism for real-time software testing and debugging
Healy et al. Bounding pipeline and instruction cache performance
US6493868B1 (en) Integrated development tool
US8091075B2 (en) Method and apparatus for breakpoint analysis of computer programming code using unexpected code path conditions
US7716031B2 (en) Interface converter for unified view of multiple computer system simulations
US5960198A (en) Software profiler with runtime control to enable and disable instrumented executable
US8336032B2 (en) Implementing enhanced template debug
JP3480973B2 (en) Behavior analysis device for parallel processing system
US20040006760A1 (en) Generating and using profile information automatically in an integrated development environment
Reilly et al. Performance simulation of an Alpha microprocessor
Diep et al. VMW: A visualization-based microarchitecture workbench
Scheidler et al. Trapper: A graphical programming environment for industrial high-performance applications
US20050066312A1 (en) Inter-job breakpoint apparatus and method
US20060101418A1 (en) Apparatus and method for automatic generation of event profiles in an integrated development environment
Cláudio et al. Monitoring and debugging message passing applications with MPVisualizer
Hollingsworth et al. Techniques for performance measurement of parallel programs
Grabner et al. Debugging of concurrent processes
Griffin et al. A debugger for parallel processes
Chapman Program timing analysis
WO2006091785A1 (en) Interface converter for unified view of multiple computer system simulations
DeRose et al. Performance issues in parallel processing systems

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: A3

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP