Patent Publication Number: US-8972944-B2

Title: Coordinating and controlling debuggers in a simulation environment

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation of U.S. application Ser. No. 11/637,376, filed Dec. 11, 2006, now issued as U.S. Pat. No. 8,423,959, which is incorporated by reference in its entirety. 
    
    
     BACKGROUND 
     Computing devices have made significant contributions toward the advancement of modern society and are utilized in a number of applications to achieve advantageous results. Numerous devices, such as personal computers, laptop computers, servers, minicomputers, mainframe computers, workstations, computer aided design (CAD) system, simulators, emulators, automatic test equipment (ATE) systems, and distributed computer systems, have facilitated increased productivity and reduced costs in analyzing and communicating data in most areas of business, science, engineering, education and entertainment. As computing devices continue to progress, techniques such as multi-threading, virtualization and the like are being utilized to achieve increased performance. 
     For example, the virtualization of a physical computing device creates a uniform hardware image, implemented in software, on which operating systems and applications run. Each virtual machine is a software representation of a physical machine that can run or host a guest operating system and one or more applications. A typical virtualized computing platform includes a physical machine and one or more virtual machines for executing a host operating system and one or more applications. 
     To simulate virtualized computing platforms during development, multiple simulator components and debuggers are utilized to simulate the platform. The debuggers are applications attached to the simulator components for analyzing, displaying and modifying the state of the simulation. The conventional debuggers are assumed to be the master of the run mode of their corresponding simulation. However, the conventional debugger server is attached to the simulation in such a way that the run mode of the simulation is shared between all debuggers. Furthermore, the conventional debugger server forces a debugger to always abort its current operation. When the simulation stops, it is not always useful to abort the current operation of the debugger (e.g., to return from the current function). Furthermore, when the simulation continues, the debugger has to automatically choose one of the possible ways to continue the simulation. There is a substantial risk that it may choose an operation that does not fit to the current intention of the user. Therefore, there is a continuing need for improved multi-debugger techniques. 
     SUMMARY 
     Embodiments of the present invention are directed toward techniques for coordinating and controlling debuggers in a simulation environment. In one embodiment, the simulation environment includes a debugger server to coordinate run modes of one or more debugger adapters. Each debugger adapter couples a corresponding debugger client to the debugger server. The debugger adapters are utilized to control the run mode of their corresponding debugger clients. 
     In another embodiment, a method of coordinating debuggers in a simulation environment includes coupling one or more debuggers to the simulation. A debugger adapter couples a corresponding debugger to a debugger server to thereby couple the debugger to the simulation. Thereafter, the debugger server may drive the run mode of one or more other debugger adapters utilizing the debugger server. 
     In yet another embodiment, a method of controlling debuggers in a simulation environment includes coupling a debugger to a debugger server through a debugger adapter. Thereafter, the state of the simulation may be modified by the debugger adapter. In one instance, a debugger adapter may make requests to the debugger server to change the run mode of one or more other debugger adapters currently coupling a corresponding debugger to the debugger server. In another instance, the debugger adapter may accept or reject a request from the debugger server to change the run mode of the debugger adapter&#39;s corresponding debugger. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Embodiments of the present invention are illustrated by way of example and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements. 
         FIG. 1  shows a block diagram of an exemplary simulation environment, in accordance with one embodiment of the present invention. 
         FIG. 2  shows a flow diagram of a method of coordinating and controlling debuggers in a simulation environment, in accordance with one embodiment of the present invention. 
         FIG. 3  shows a block diagram of an exemplary computing device for implementing embodiments of the present invention. 
     
    
    
     DETAILED DESCRIPTION 
     Reference will now be made in detail to the embodiments of the invention, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with these embodiments, it will be understood that they are not intended to limit the invention to these embodiments. On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the scope of the invention as defined by the appended claims. Furthermore, in the following detailed description of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it is understood that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the present invention. 
     Referring to  FIG. 1 , an exemplary simulation environment, in accordance with one embodiment of the present invention, is shown. The simulation environment  100  includes a debugger server  105 , one or more debugger clients  110 - 120  and one or more debugger adapters  125 - 135 . A debugger adapter  125 - 135  is communicatively coupled between the debugger server  105  and each debugger client  110 - 120  that is currently coupled to the debugger server  105 . One debugger client may also use multiple debugger adapters, for example when it is debugging different components of the hardware simulation model at the same time (e.g., two instruction set simulators). Multiple debugger clients may also share the same debugger adapter. The debugger clients are also referred to herein as debuggers. The simulation environment  100  is also referred to here as the simulation. 
     The debuggers  110 - 120  are generally not part of the simulation, but are instead stand-alone applications that run on the same computing device as the simulation or another computing device in such a way that they communicate with the simulation via a network connection. The debug target of a debugger may be the whole hardware model of the simulation or one or multiple components within the hardware mode (e.g., the target of a debugger may be an instruction set simulator). 
     The debugger server  105  is adapted to coordinate the run modes of the debugger adapter  125 - 135 . The debugger server  105  controls the run mode of the simulation after the start of the simulation but before a debugger couples to the simulation  100 . The debugger server  105  may also enable the coupling of debugger clients  110 - 120  to the simulation environment  100 . The debugger server  105  also maintains run state information about debuggers  110 - 120  that are currently coupled to the simulation environment  100 . The debugger server  105  may also drive the simulation  100  into a given run mode. The debugger server  105  may also enable the un-coupling of debugger clients  110 - 120  from the simulation environment  100 . In addition, the debugger server  105  also controls the run mode of the simulation  100  after the last debugger un-couples from the simulation environment  100 . 
     Each debugger adapter  125 - 135  is utilized to control the run mode of its respective debugger  110 - 120 . The debugger adapter  125 - 135  responds to requests from the debugger server on behalf its corresponding debugger  110 - 120 . The debugger adapter  125 - 135  also makes requests to the debugger server  105  on behalf of its debugger  110 - 120 . For instance, each debugger adapter  125 - 135  is adapted to couple its corresponding debugger  110 - 120  to the simulation environment  100 . Each debugger adapter  125 - 135  may retrieve information about the run mode of any other debugger currently coupled to the simulation environment  100 . Each debugger adapter  125 - 135  may request that the other debugger adapters currently coupled to the simulation environment  100  change their run mode to a given state. Each debugger adapter  125 - 135  may also accept or reject a request to change the run mode of its corresponding debugger  110 - 120  to a given state. In addition, each debugger  110 - 120  may un-couple from its corresponding debugger adapter  125 - 135 , thereby un-coupling from the simulation environment  100 . Thus, each debugger adapter  125 - 135  is a proxy for its respective debugger client  110 - 120 . 
     The debugger adapters  125 - 135  may be implemented as an application programming interface (API). The debugger adapters  125 - 135  may be a standardized debugger adapter that operates with a number of debugger clients, a custom debugger adapter provided by the debugger server  105 , and/or a custom debugger adapter provided by its corresponding debugger client. The communication between each debugger adapter  125 - 135  and the debugger server  105  may be in accordance with a single protocol. The communication between a given debugger adapter  125 - 135  and its corresponding debugger  110 - 120  may be in accordance with any number of protocols. Thus, the communication between the debugger adapter  125 - 135  and its debugger  110 - 120  may be transparent to the debugger server  105 . 
     In another embodiment, the simulation could be split into multiple components and each component could be simulated by a different simulation environment as co-simulation. Single components can be executed by real hardware. The debugger server of the master component acts as a central coordinating instance of all debuggers attached to any component of the co-simulation. 
     Referring now to  FIG. 2 , a method of coordinating and controlling debuggers in a simulation, in accordance with one embodiment of the present invention is shown. The method will be described with reference to the exemplary simulation shown in  FIG. 1 . The method includes processes performed by a debugger server  105  and processes performed by each debugger adapter  125 - 135  on behalf of a corresponding debugger  110 - 1120 . 
     The method begins with starting a simulation  100  utilizing the debugger server  105 . The debugger server  105  controls the run mode of the simulation after the start of the simulation but before any debugger client couples to the simulation  100 , at  205 . Possible run mode states may include: run, stop, step, stalled, and finished. In the ‘run’ state the simulation begins executing behavioral code. In the ‘stop’ state, the simulation stops without executing any behavioral code. In the ‘step’ state, a single step (e.g., one instruction) in the behavioral code is executed. After execution of the step the run mode automatically changes to the stop state. In the ‘stalled’ state, the simulation runs by does not execute any behavioral code. This is comparable to the execution of no-operation-instructions. In the ‘finish’ state, the simulation terminates by executing a finish procedure. 
     In one implementation, the debugger server  105  includes a Boolean configuration parameter that determines if the run mode of the simulation is stopped when the simulation started. The value of the configuration parameter may be set based on start arguments of the simulation or user configurations. Stopping the simulation  100  at the time of initiation is realized by an instance of the simulation stopper mechanism of the debugger server that stops the whole simulation. 
     Control of the run mode by the debugger server  105  enables starting the simulation  100  in the stopped run mode before any behavioral code is executed. Thereafter, any debugger  110 - 120  that subsequently attaches may begin executing the behavior code of the simulation  100 . 
     For each debugger  110 - 120  to be coupled to the simulation  100 , the corresponding debugger adapter  125 - 135  couples the given debugger to the debugger server  105 , at  210 . The debugger server  105  assists the debugger adapters  125 - 135  in coupling their respective debuggers  110 - 120  to the simulation  100 , at  215 . In one implementation, when a given debugger  110  couples to the simulation, a debugger adapter  125  corresponding to the given debugger  110  registers with the debugger server  105 . The registration may include choosing a unique name for each debugger  110 - 120 . In one implementation, the debugger server  105  chooses the unique name for the particular debugger  110 . The unique name will be used to maintain information about each debugger and communicating with the particular debugger  110  through its corresponding debugger adapter  125 . 
     When a given debugger  110  couples to the simulation  100  its debugger adapter  125  may request an initial run state. The initial run state is used if no other debugger adapters  130 ,  135  are registered. The possible value of the requested initial run state may include retain, run, stop, and finish. In the retain mode, the former run state of the simulation is kept. Therefore, the given debugger becomes a stopper of the simulation if the simulation was stopped when the given debugger couples to the simulation. In the run mode, the given debugger becomes a no-stopper of the simulation. In the stop mode, the debugger adapter becomes a stopper of the simulation. In the finish mode, the given debugger becomes the requester for finishing the simulation. 
     The debugger server  105  maintains information about the run mode of debuggers that are coupled to the simulation, at  220 . The debugger server  105  keeps track of the run mode of all its registered debugger adapters  125 - 135 . Each time a debugger  110  changes its run mode, its debugger adapter  125  notifies the debugger server  105  about its new mode. A given debugger adapter  125  may cause its corresponding debugger  110  to change its run mode, for instance, because it reacts to a breakpoint hit. In the case of a user command, the debugger  110  instructs its debugger adapter  125  to change its run mode. The information maintained by the debugger server  105  about the current run mode of all coupled debugger adapters  125 - 135  is accessible to all currently coupled debugger adapters  125 - 135  or to any other interested entity. Therefore, a given debugger adapter  125  may retrieve information about the other debuggers  115 ,  120  coupled to the simulation  100 , at  225 . The information may include the unique names of all attached debuggers, the run mode of each attached debugger, all debuggers that are currently stopping the simulation, and/or the like. Each debugger adapter  125 - 135 , for example, can query the information maintained by the debugger server  105  to collect a list of all debugger adapters  125 - 135  that are currently stopping the simulation. 
     Each debugger adapter may request one or more other debugger adapters to change their run mode, at  230 . Possible requested run mode values include run, stop, step, and stall. In response thereto, the debugger server may coordinate between the debugger adapters  125 - 135  to drive the simulation into the requested run mode, at  235 . For example, the debugger server  105  may request that all attached debugger adapters  125 - 135  enter a given run mode in response to a request from a given debugger adapter  125 . The debugger server  105  forwards the requests to one or more applicable debugger adapters  125 - 135 . 
     Each debugger adapter  125 - 135  may accept or reject a request to enter a given run mode, at  240 . The debugger adapter may decide how to react to the change request or communicate the request to its corresponding debugger. The debugger may involve its user to decide how to react to the change request. The change to a given run mode only succeeds if all debugger adapters, current coupled to the simulation, confirm the request to change to the given run mode. The debugger server may optionally inform the given debugger adapter that initiated the procedure about the success of the procedure. The success or failure of the procedure may be indicated by a Boolean return value. 
     Accordingly, if one debugger adapter stops the simulation due to a breakpoint hit, watchpoint hit or the like in its simulation, the other debugger adapters can be driven to recognize that the simulation stopped. In response thereto, the other debugger adapters can change to a stop state and enable a user to evaluate the state of one or more simulation components utilizing one or more of the debuggers. Likewise, the procedure for driving the simulation into a given run mode enables the case where a user wants to continue the simulation from one debugger even if the simulation was stopped by another debugger. 
     Each debugger may un-couple from its respective debugger adapter and hence from the simulation, at  245 . The debugger server  105  may delete the respective debuggers adapter during the un-coupling process, at  250 . 
     If all debuggers  110 - 120  un-couple from the simulation  100 , the debugger server  105  controls the run mode of the simulation after the last debugger uncouples, at  255 . When a debugger un-couples and it is the last debugger adapter that was coupled to the debugger server  105 , a requested follow-up run state parameter of the un-register procedure is evaluated to determine the follow-up run state of the simulation. Possible values of the parameter may include retain, run, stop and/or finish. The retain value is actual no-state at all but a request to keep the current state. If the simulation was stopped and the follow-up run state parameter has the value retain or stop, the responsibility of the stop state of the simulation is handled over from the last debugger adapter to the simulation stopper of the debugger server  105 . If the parameter has the value finish, the simulation is finished. In all other cases the simulation is only stopped with the help of the simulation stopper of the debugger server  105  if the parameter has the value stop. 
     Control of the run state of the simulation after the last debugger uncouples by the debugger server, enables the simulation to be stopped or continued when the last debugger uncouples. Furthermore, if the simulation is stopped when the last server uncouples, the simulation can be continued by any debugger that subsequently attaches to the simulation. 
     Thus, the simulation  100  is always in a run state (e.g., it is running, stopped, finished or the like). A debugger adapter is operating in a run mode (e.g., stop, continue, step, stalled). Changing the mode of a debugger adapter may result in an adaptation of the run state of the simulation. The simulation will adapt its state accordingly to the run mode of all debuggers, but this is a transient procedure. For example, when a debugger switches from mode stop to mode run, the simulation may still be stopped by another debugger and not adapt its state immediately to running. When a debugger for example switches from run to stop the simulation may continue running for a short while until it finishes the current instruction of the simulation component that the debugger is attached to. 
     Referring now to  FIG. 3 , an exemplary computing device for implementing embodiments of the present invention is shown. The computing device  300  may be a local or remote device, such as an emulator, simulator, debugger, CAD system, ATE system, personal computer, server computer, client computer, laptop computer, hand-held device, minicomputer, mainframe computer, distributed computer system or the like. The computing device  300  includes one or more processors (e.g., CPU)  310 , one or more computing device readable media  320 ,  330  and one or more input/output (I/O) devices  340 ,  350 ,  360 ,  370 . The computing device readable media  320 ,  330 , and I/O devices  340 ,  350 ,  360 ,  370  may be communicatively coupled to the processor  310  by a chip set  380  and one or more busses. The chipset  380  acts as a simple input/output hub for communicating data and instructions between the processor  310  and the computing device-readable media  320 ,  330 , and I/O devices  340 ,  350 ,  360 ,  370 . 
     The I/O devices  340 ,  350 ,  360 ,  370  may include one or more network interface cards  340 , and peripherals such as a keyboard, a pointing device, a monitor, a speaker, a printer, and/or the like. The network interface card  340  provides for access to one or more other computing devices, networks and/or storage devices remote to the computing device  300 . 
     Generally, local storage, such as a magnetic disk and/or optical disk, provides for non-volatile storage of computing device readable instructions and data for use by the computing device  300 . For instance, the disk drive  330  may store an operating system (OS), applications and data. The system memory (e.g., RAM)  320  provides for volatile storage of computing device readable instructions and data for use by the computing device  300 . For instance, the system memory  320  may temporarily store executing portions of the operating systems, one or more applications and associated data that are currently used by the CPU  310 . 
     The above described method of coordinating multiple debuggers in a simulation environment may be embodied in computing device executable instructions stored on one or more computing device readable media  320 ,  330  coupled to one or more computing devices  300 , and/or communicated to one or more computing devices  300  through one or more network interfaces  340 . The instruction may be executed by one or more processor  310  on one or more computing devices  300  to implement that the method of coordinating multiple debuggers. In addition, the exemplary simulation environment described above may be implemented on one or more computing devices  300 . 
     Embodiments of the present invention provide techniques for coordinating multiple debuggers in a simulation environment. A debugger server advantageously coordinates the run mode of the debugger clients through corresponding debugger adapters. Each debugger adapter advantageously controls the run mode of its respective debugger client by acting as a proxy for communicating with the debugger server. The debuggers advantageously have the freedom through their corresponding debugger adapters to accept or reject a request to change their run mode. This enables the implementation of convenient algorithms for deciding inside each of the debugger how to react on a request to change the run mode. It also makes it possible to involve a user in the process to determine the user&#39;s current intention. 
     The foregoing descriptions of specific embodiments of the present invention have been presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed, and obviously many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the Claims appended hereto and their equivalents.