FIELD OF THE INVENTION  
         [0001]    The present invention relates generally to prototyping application software and, more particularly, to a technique for prototype software to be executed in conjunction with traditional embedded software in a microprocessor without modifications to the underlying software source code.  
         BACKGROUND OF THE INVENTION  
         [0002]    In modern automotive electronic control units, there exist a number of embedded control algorithms that control different aspects of the vehicle. For instance, there may be an algorithm that controls the amount of fuel injected into the cylinders and a different control algorithm that is responsible for shifting gears in the transmission. Traditionally, if changes needed to be made to an algorithm, a controls engineer would specify the modifications to the algorithm and then give the specification to a software engineer who would write prototype software in accordance with the specification. The control engineer would then test the new algorithm. This process may need to be repeated numerous times before the algorithm is finalized.  
           [0003]    More recently, rapid prototyping methods have been used to develop and/or modify control algorithms. Rapid prototyping is a technique of replacing a calculation or feature of a control algorithm that is embedded in the software with a modified calculation or feature that runs at a different location in the processor or on an external processor. A necessary condition of this approach was to write “hooks” into the base software residing in the electronic control unit. In other words, this approach requires at least some modifications to the underlying source code. Therefore, it is desirable to provide a technique for prototype software embedded in a microprocessor without modifications to the underlying source code.  
           [0004]    During the process of developing an embedded control system, it is often necessary to test and verify that the software running in the embedded system meets required specifications. This process of testing and verification traditionally takes several forms including testing the embedded system in the physical environment for which it is intended. Another common form of testing and verification is to connect the embedded controller to a hardware simulator. The hardware simulator stimulates the physical inputs of the controller and monitors the controller&#39;s output for correctness in accordance with the specification.  
           [0005]    Therefore, it is also desirable to provide a technique for simulating an embedded controller and the algorithms in the embedded controller without the need to provide physical stimulation to the embedded controller.  
         SUMMARY OF THE INVENTION  
         [0006]    In accordance with the present invention, a method is provided for prototyping software embedded in a microprocessor without modifications to the underlying source code. The method includes: presenting an software program having a plurality of machine instructions of a finite quantity of fixed lengths in an executable form; defining a replacement instruction for at least one of the machine instructions in the software program; and replacing identified machine instructions in the executable form of the software program with the replacement instruction. In one aspect of the present invention, the replacement instruction is further defined as a branch instruction that references an address outside an address space for the software program.  
           [0007]    For a more complete understanding of the invention, its objects and advantages, reference may be had to the following specification and to the accompanying drawings. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0008]    [0008]FIG. 1 is a diagram depicting an exemplary software prototyping environment;  
         [0009]    [0009]FIG. 2 is a flowchart illustrating a method for prototyping software embedded in a microprocessor without modifications to the underlying source code in accordance with the present invention;  
         [0010]    [0010]FIG. 3A is a diagram illustrating an unmodified program memory image for a target software program embedded in a microprocessor;  
         [0011]    [0011]FIG. 3B is a diagram illustrating a program memory image modified in accordance with the present invention;  
         [0012]    [0012]FIGS. 4A and 4B are flowcharts illustrating exemplary embodiments of relocation code in accordance with the present invention; and  
         [0013]    [0013]FIG. 5 is a diagram depicting an exemplary embodiment of a prototyping tool that is configured to support the present invention. 
     
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0014]    An exemplary software prototyping environment  10  is depicted in FIG. 1. The prototyping environment  10  is configured to design and test software-implemented control algorithms which may be embedded in an automotive electronic control unit. While the following description is provided with reference to control algorithms embedded in an automotive electronic control unit, it is readily understood that the broader aspects of the present invention are applicable to other types of software applications which are embedded in microprocessors.  
         [0015]    The prototyping environment  10  is generally comprised of a modeling tool  12 , a prototyping tool  14 , and, optionally, a memory emulator  16 . The modeling tool  12  is an interactive tool for modeling, simulating and analyzing dynamic systems. For instance, the modeling tool  12  allows users to generate models which represent control algorithms. In an exemplary embodiment, the modeling tool  12  may be implemented using the Simulink modeling tool which is commercially available from MathWorks, Inc.  
         [0016]    The prototyping tool  14  then enables users to connect simulation models to physical systems and execute them in real time on a microprocessor or other PC-compatible hardware. In particular, the prototyping tool  14  is operable to generate executable software based on the user-defined simulation models. An exemplary prototyping tool is the xPC Target system which is also commercially available from MathWorks, Inc. In order to access variables within a control algorithm embedded in a read-only memory space, it is envisioned that the prototyping environment  10  may also employ a memory emulator  16 . A suitable memory emulator is the M5 memory emulator which is commercially available from the Accurate Technologies, Inc.  
         [0017]    To prototype control algorithms without modifications to the underlying source code, the software prototyping environment  10  must support three principal requirements. First, bypass code must have access to input parameters that reside in a target software application, where bypass code is understood to be executable software that defines one or more substitute or additional functions for the target software. It is readily understood that the bypass code may be executed at a different location on the same processor that supports the target software or on a different processor.  
         [0018]    When the bypass code is to be executed on the same processor as the target software, the bypass code may access the input parameters (as global variables) in the same memory space as is accessed by the target software. Conversely, when the bypass code is to be executed on a different processor than the target software, the bypass code may gain access to the input parameters through the use of a memory emulator. For automotive electronic control units that support memory emulation, random access memory variables may be accessed through common shadow table mechanisms as is well known in the art. In either case, the bypass code has access to input parameters associated with the target software.  
         [0019]    Furthermore, the prototyping environment must provide a method for the bypass code to write its output parameters to the target software as well as provide a method for synchronizing execution of the bypass software with the target software. Modifying the program memory image at a machine code level is one approach to meeting these two remaining requirements.  
         [0020]    In many conventional microprocessors, machine instructions are limited to a finite quantity of fixed lengths. For example, machine instructions in a RISC-based processor are 32 bits in length; whereas Tri-Core and ST10 processors have machine instructions that are 16 bits and 32 bits in length. Thus, some machine instructions in the underlying software may be replaced with other machine instructions. Although this concept serves as the basis for the present invention, it is readily understood that the broader aspects of the present invention may be extended to microprocessors having machine-instructions of a varied length.  
         [0021]    In accordance with the present invention, a method is provided for prototyping software embedded in a microprocessor without modifications to the underlying source code. Referring to FIG. 2, the target software program is provided at step  30  in an executable form which is defined by a plurality of machine instructions of a finite quantity of fixed lengths. A replacement instruction is defined at step  34  for at least one of the machine instructions in the target software program.  
         [0022]    Next, one or more machine instructions of the target software program are replaced with replacement instructions. To do so, a memory address is determined for each machine instruction which is to be replaced in the software program at step  36 . The memory address for a given machine instruction may be determined from a set of object files from which the software program was built as is well known in the art. The replacement instruction is then inserted at step  38  into the program memory image of the software program at the identified address.  
         [0023]    A preferred embodiment of the present invention is further described below. FIG. 3A illustrates a unmodified program memory image  40  for a target software program embedded in a microprocessor. The memory space may be partitioned into an address space  42  for the target software program and an unused portion  44  of memory space. It is readily understood that the address space  42  for the target software program may be further partitioned into a data portion and a code portion.  
         [0024]    [0024]FIG. 3B illustrates a program memory image modified in accordance with the present invention. One or more machine instructions  46  (also referred to as “bypassed instructions”) may be replaced with replacement instructions. In the preferred embodiment, the bypassed instructions are preferably machine instructions that access or modify variables that correspond to the output parameters of the bypass code. For instance, since there are no machine instructions that directly modify the memory space of a RISC-based processor, the code must load the value of the variable into a register, modify the value (e.g., though a math operation), and then store the modified value back into its appropriate memory space. Thus, in a RISC-based processor, the bypassed instructions are specifically designated as load and/or store instructions for the applicable variables in the target software. However, it is readily understood that other types of machine instructions may also serve as bypass instructions.  
         [0025]    Furthermore, each replacement instruction is preferably defined as a branch instruction that references an address outside the address space for the target software program. In one exemplary embodiment, branch instructions pass processing control to a series of machine instructions that are defined in the unused portion of the memory space and are referred to herein as relocation code  48 . Relocation code  48  is responsible for variable relocation and task synchronization functions as will be further described below. Bypass code  49  may also be defined in the unused portion of the memory space.  
         [0026]    Alternatively, it is envisioned that replacement instructions may be defined as instructions that cause an interrupt or an exception to occur in the microprocessor. For example, RISC-based processors provide a “sc” command to perform this function; whereas ST10-based processors provide a “trap” instruction to perform this function. Although these types of instructions provide an alternative technique for branching to a different address space, this approach is generally not preferred because these types of instructions may interfere with the normal operation of the microprocessor.  
         [0027]    [0027]FIGS. 4A and 4B are flowcharts that illustrate exemplary embodiments of relocation code in accordance with the present invention. In general, the relocation code performs four primary functions. Referring to FIG. 4A, the relocation code initially determines if the bypass feature is enabled or disabled as shown at step  52 . When the bypass feature is disabled, the relocation code executes the bypassed instruction as shown at step  54 ; otherwise, and the branches processing to the machine instruction following the bypassed instruction in the target software program.  
         [0028]    On the other hand, when the bypass feature is enabled, the relocation code performs the remaining functions. First, the relocation code determines if conditions are met to trigger execution of the bypass code at step  56 . If so, the bypass code is executed as shown at step  58 . In one exemplary embodiment, the bypass code may be triggered each time a write (or store) instruction is performed for a given output parameter. Alternatively, the bypass code may be triggered upon a call to an externally linked (global) function. It is readily understood that other techniques for triggering the bypass code are within the scope of the present invention.  
         [0029]    Next, the relocation code synchronizes the values of the output parameters which may be modified by the bypass code. For each modifiable output parameter, the corresponding value as maintained by the bypass code is retrieved at step  62  and then stored at step  64  at its corresponding address within the address space of the target software program. In this way, the value of each output parameter in the target software program matches the value of the corresponding output parameter as established by the bypass code. It should be noted that this synchronization process occurs regardless of whether the bypass code is executed by the relocation code.  
         [0030]    Lastly, the relocation code branches processing at step  66  to the machine instruction following the bypassed instruction in the target software program. The relocation code described above assumes a direct addressing method of storing variable values. In other words, each machine instruction that manipulates the value of a variable contains the address information needed to access that variable in memory.  
         [0031]    In some instances, an indirect addressing method may be employed for storing variable values. Indirect addressing first loads the address of a variable into a machine register, and then uses the register to load or store the value of the variable. Thus, it is not possible to directly determine what store instructions are associated with a given variable. For these types of instructions, the present invention determines the machine register used as the pointer to the variable and then searches, starting from the specified instruction, for all store instruction using that register. The search includes all instructions in the current function (or routine) as well as all function that may be called by the function. In this way, all instructions that have the possibility of being store instructions to the given variable are modified. With this method, it is possible to modify a store instruction that is not associated with the given variable.  
         [0032]    Relocation code for an indirect addressing method of storing variable values is shown in FIG. 4B. In this case, it is necessary for the relocation code to determine that the value of the register is in fact pointing to the given variable as shown at step  55 ; otherwise the relocation code is in a manner as set forth in relation to FIG. 4A.  
         [0033]    Conventional prototyping tools may be configured to support the present invention. Referring to FIG. 5, a conventional prototyping tool  14  typically includes a user interface  72  and an execution component  74 . In accordance with the present invention, the prototyping tool  14  may be further configured to include an instruction locator  76  and an instruction replacement component  78 .  
         [0034]    A user configures the prototyping environment through the use of the user interface  72 . In general, the user interface may be used to specify the target software program and the applicable bypass code. Specifically, the user may further specify the machine instructions which are to be bypassed and the corresponding replacement instructions. Alternatively, it is envisioned that the user may merely specify inputs and outputs for the bypass code as well as trigger conditions for executing the bypass code. In this case, the prototyping tool will generate the required replacements instructions as well as the relocation code as discussed above. In either case, one skilled in the art will readily recognize that a suitable user interface may be designed to support these required functions of the present invention.  
         [0035]    In operation, the instruction locator  76  is adapted to receive a specified machine instruction within a target software program and operable to identify location information for the specified machine instruction within the executable form of the target software program. In one exemplary embodiment, the instruction locator searches through the application image (hex record) for the target software and parses each machine instruction therein. For Embedded Application Binary Interface (EABI) compliant compilers, load and store instructions can be identified in the application image. In RISC-based processors, running software that is EABI compliant, registers must be used in specific ways. For example, R13 must be used to point to the small data area for read/write memory. This register normally is used to index to the internal random access memory of the processor. Using this specific information, the instruction locator has the ability to reverse calculate an address for any load or store instruction in the small data area. It is readily understood that other techniques for identifying location information for a specific machine instruction are within the broader aspects of the present invention.  
         [0036]    The instruction replacement component  78  is then operable to replace the specified machine instruction with a replacement instruction. To do so, the instruction replace component  78  is adapted to receive the replacement instruction and then inserting the replacement instruction into a program memory image of the software program at the identified address. In one exemplary embodiment, the instruction replacement component  78  generates the applicable relocation code. When the bypass code is to be executed on the same processor as the target software, the instruction replacement component  78  also inserts the relocation code and bypass code into an unused portion of the memory space on the target microprocessor.  
         [0037]    Lastly, the execution component  74  is operable to execute the executable form of the software program that includes the replacement instructions. It is to be understood that only the relevant steps of the process are discussed herein, but that other software-implemented features may be needed to manage and control the overall prototyping environment.  
         [0038]    While the invention has been described in its presently preferred form, it will be understood that the invention is capable of modification without departing from the spirit of the invention as set forth in the appended claims.
A method is provided for prototyping, testing, stimulating and verifying software embedded in a microprocessor without modifications to the underlying source code. The method includes: presenting an software program having a plurality of machine instructions of a finite number of fixed lengths in an executable form; searching through the machine instructions of the executable and finding at least one appropriate instruction to replace; and defining a replacement instruction for identified machine instructions in the software program; and replacing identified machine instructions in the executable form of the software program with the replacement instruction. The replacement instruction may be further defined as a branch instruction that references an address outside an address space for the software program.