Virtual machine for developing and testing target code for hardware designs

Abstract

To provide a virtual machine for developing and testing a target code for hardware designs.SOLUTION: A host computer 400 includes a memory storing a proxy VM, and a host CPU. The proxy VM emulates target hardware having an incomplete design. The proxy VM includes a virtual processor for emulating a target processor, and an emulated memory connected to the virtual processor via a virtual memory bus. The emulated memory includes at least one portion storing the target code. The host CPU emulates the target hardware having an incomplete design by executing the proxy VM to emulate the target hardware. The proxy VM, upon execution by the host CPU, executes, by the virtual processor, the target code.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present disclosure relates to a virtual machine for developing and testing target code for hardware designs. [Background technology]

[0002] When designing a new embedded system, the details of the final target hardware design and the embedded software that will run on that hardware are often not fully defined in the early stages. Typically, as the hardware design matures, software development progresses in parallel, with multiple iterations of development and testing. Development and testing is typically performed on hardware separate from the final target hardware, such as an integrated development environment (IDE) on a personal computer (PC) running a commercial operating system (OS). Therefore, there may be a "gap" in test fidelity for at least some of the tests that are performed while the hardware design is still incomplete. Furthermore, with application software rehosting, the rehosted application software can run on a PC, but other elements of the target hardware software stack, such as a real-time OS, cannot. This can also result in a fidelity gap. Such gaps can delay full-fidelity testing of the target software and target hardware, resulting in delayed discovery of problems and the need for multiple iterations of development and testing when the embedded system is nearing completion.

[0003] This section is intended to introduce the reader to various aspects of the prior art that may be relevant to various aspects of the present disclosure that may be described below and / or claimed. The statements in this section are believed to be helpful in providing the reader with background information to aid in understanding the various aspects of the present disclosure. As such, they should be read in this light, and not construed as admissions of prior art. Summary of the Invention

[0004] One embodiment relates to a host computer for developing, testing, and executing target code. The host computer includes a memory for storing a proxy virtual machine and a host central processing unit. The proxy virtual machine emulates target hardware for which a design is not yet complete. The proxy virtual machine includes a virtual processor for emulating a target processor. The proxy virtual machine includes an emulated memory connected to the virtual processor via a virtual memory bus. The emulated memory has at least one portion for storing target code. The host central processing unit is configured to emulate the target hardware by executing the proxy virtual machine. The proxy virtual machine, when executed by the host central processing unit, is configured to execute the target code via the virtual processor.

[0005] The features described in connection with the above-described aspects may be modified in various ways. Additionally, additional features may be incorporated into the above-described aspects. Such modifications and additional features may exist individually or in any combination. For example, the various features described in connection with the exemplary embodiments below may be incorporated into any of the above-described aspects, either alone or in combination. [Brief explanation of the drawings]

[0006] [Figure 1]FIG. 1 is a block diagram illustrating an exemplary avionics device. [Figure 2] FIG. 2 is a block diagram illustrating an exemplary host computer for emulating the avionics equipment shown in FIG. 1. [Figure 3] FIG. 2 is a block diagram illustrating an example virtual machine for emulating the avionics equipment shown in FIG. 1. [Figure 4] FIG. 1 is a block diagram illustrating an exemplary host computer. [Figure 5] 2 is a flow diagram illustrating an exemplary method for executing graphics function calls in target code running on a virtual machine emulating the avionics equipment shown in FIG. 1. DETAILED DESCRIPTION OF THE INVENTION

[0007] In the accompanying drawings, like parts are designated by like reference numerals throughout the several views. Although particular features of various embodiments may be shown in some drawings and not in others, this is for convenience only. Any feature in any drawing may be referenced and / or claimed in combination with features shown in other drawings.

[0008] The embodiments described herein utilize virtualized hardware on a virtual machine (VM) to provide at least some testing early in the development cycle. Virtualization refers to the mimicking or emulation of a given piece of hardware by a software program, such as a VM, running on a local or host computer via a hypervisor. Virtualization enables testing of target software without the need for rehosting software modifications or a full hardware test bench, which can be costly and demanding in the development of large or complex systems. For example, when virtualizing target hardware such as a single-board computer (SBC) or a communications bus controller, detailed information about the specific target hardware and firmware is typically required to build a VM that mimics or emulates hardware with equivalent functionality to the real target hardware. As used herein, target hardware refers to the real hardware part of an embedded or data processing system that is virtualized by a VM.

[0009] The embodiments described herein provide a VM that closely resembles the target hardware and can be used for early development and testing of the target hardware or target software, thereby enabling the use of virtualization during the development phase of hardware design.

[0010] For the purposes of this disclosure, the terms "virtualization" and "emulation" are used interchangeably to refer to a VM that emulates any aspect of target hardware, although one or more other aspects of the target hardware may be built into the host computer.

[0011] The host computer disclosed herein provides a proxy VM for developing and testing target software or target code for an incomplete hardware design for an embedded system. More specifically, the proxy VM includes only core hardware design specifications that are defined early in the design process. For example, the processor type and operating system are typically determined early in the design process, when the hardware design is still incomplete. Other specifications, such as firmware for field programmable gate arrays (FPGAs) and application-specific integrated circuits (ASICs) and input / output (I / O) device designs, are typically not determined until much later in the hardware design process, sometimes months or even years after the core hardware design specifications are determined. As a result, many specifications, such as the requirements, design, interface, and input / output data definitions of the target hardware for the embedded system, are subject to change during the development process.

[0012] The proxy VM includes an emulation of at least the target processor and target OS, allowing initial development and testing of application software using IDEs, compilers, and other development tools for the target OS or another existing OS that is the same or very similar. For the purposes of this disclosure, the term "development tools" refers to any software modules, programs, libraries, or other applications that can be used to develop, test, or run the software under development or to develop or test the target hardware. For example, the OS for the proxy VM uses the same or very similar stack as the target OS. In alternative embodiments, the OS for the proxy VM need not be similar to the target OS. However, a similar OS can have the advantage of efficiently developing and testing the same set of development tools for the target OS, for example. In other alternative embodiments, the proxy VM may be "bare metal" and not include the target OS. In such embodiments, development and testing can be performed using IDEs, compilers, debuggers, or other development tools for a bare metal implementation. Early-stage application software often includes atomic-level functionality, application programming interfaces (APIs), and (after the target I / O devices have been designed) device drivers. These early software components undergo "white-box" testing, so they typically do not need to directly interact with the hardware elements of the embedded system. Additionally, early iterations of target hardware and device drivers can be emulated to test and evaluate hardware design choices. Leveraging virtualization in this early stage eliminates the rework and rehosting that often occurs later in development due to differences in the operating systems and IDEs running on typical developer PCs.Differences between the development environment, which is the "rehosted" environment, and the target environment are often resolved later in development, after the hardware design is finalized.

[0013] 1 is a block diagram illustrating an example of target hardware for an embedded system 100. The embedded system 100 is, for example, an avionics system such as a Flight Management Computer (FMC) or a Flight Control Computer (FCC). Although the systems and methods of the present disclosure are described using avionics terminology, the systems and methods of the present disclosure can be used in any other computer system, such as for land vehicles, ships, or spacecraft, where a shorter development cycle would be beneficial.

[0014] The design of embedded system 100 shown in FIG. 1 is an example of a complete design. Embedded system 100 includes a processor 102 directly connected to a memory cache 104, such as a level 1 cache or a level 2 cache. Embedded system 100 further includes a host bridge 106 directly connected to processor 102, for example, via a front-side bus. Host bridge 106 controls communication with processor 102 via a memory bus 108, such as an X bus, or an I / O or peripheral bus 110. Peripheral buses include, for example, Peripheral Component Interconnect (PCI) bus, PCI Express, PCI-X, Integrated Drive Electronics (IDE) bus, Serial Advanced Technology Attachment (SATA) bus, or any other suitable communication medium for connecting I / O devices 112 to processor 102. Host bridge 106 can be implemented on a processing chip, such as an ASIC or FPGA, and may include additional functionality, such as an interrupt controller. The I / O devices 112 may include, for example, sensors, communication interfaces, peripheral interfaces, or other peripheral hardware devices, which may be implemented on a PCI Mezzanine Card (PMC) 114. The embedded system 100 may include an additional bus bridge, such as a Versa Module Eurocard (VME) bus controller 116. The embedded system 100 may include at least two communication interfaces, an Ethernet controller 118 and a serial controller 128, for transmitting and receiving data over a communication bus. In certain embodiments, the I / O devices may include peripheral interfaces, such as audio or video interconnects.

[0015] Memory bus 108 connects various memory devices to processor 102 through host bridge 106. The memory devices may include, for example, random access memory (RAM), such as synchronous dynamic RAM (SDRAM) 120, which is typically available only to processor 102. Embedded system 100 includes direct memory access (DMA) buffers 122 on memory bus 108 between host bridge 106 and additional memory devices accessible by processor 102 and other devices. For example, embedded system 100 includes memory 124 for large-capacity nonvolatile RAM (NVRAM) 126 and a serial bus controller 128 connected to a high-speed bus 130, such as a PCI-X bus. DMA buffer 122 allows access to memory 124 and NVRAM 126 without using processor 102 processing cycles.

[0016] Memory 124 stores, for example, OS 132 and board support package (BSP) 134 for embedded system 100. Memory 124 may also store other application software and data for embedded system 100. The capacity of NVRAM 126 is typically significantly smaller than the amount of memory reserved for lower-level configuration data such as basic input / output system (BIOS) 136 or a "boot loader."

[0017] FIG. 2 is a block diagram illustrating an example of an incomplete hardware design for an embedded system 100. In the early stages of development, when the hardware design is “incomplete,” only core specifications of the hardware design are known, such as the processor 102 and the OS 132. The incomplete hardware design includes various specifications dictated by requirements, but the hardware devices corresponding to these specifications are yet to be designed or selected or are subject to change. In contrast, in a completed hardware design, all hardware devices have been selected and all hardware design specifications are complete. As the hardware design progresses, the incomplete hardware design may become more complete and include specific I / O devices 112, such as a communications interface 138. The communications interface 138 may include, for example, an ARINC 429 or MIL-STD-1553 PCI mezzanine card. The communications interface 138 may also be an Ethernet controller that is the same as or similar to the Ethernet controller 118. In some embodiments, the Ethernet controller included in communication interface 138 may not be similar to the final target Ethernet controller 118, as long as it fully supports standard Ethernet protocols. The incomplete hardware design generally does not include other I / O devices, fully implemented memory or peripheral buses, or fully implemented firmware for ASICs or FPGAs.

[0018] FIG. 3 is a block diagram illustrating an example of a high-fidelity software testing architecture 300 for a desktop testing environment. The architecture 300 is implemented on a desktop computer, i.e., a “host computer,” such as a PC, rather than a hardware test bench containing actual target hardware. The architecture 300 can also be implemented on a cloud computing platform using a PC virtual machine or server. In particular embodiments, the architecture 300 is implemented on a mobile computer, such as a tablet computer or smartphone. The architecture 300 includes a proxy VM 302 that emulates core specifications of the unfinished hardware design for the embedded system 100 shown in FIG. 2. The proxy VM 302 executes or operates within a hardware abstraction layer with the OS 304 for the host computer. For purposes of this disclosure, the hardware abstraction layer generally refers to the API 306, which includes interfaces, such as inter-process communication mechanisms (e.g., shared memory or sockets), for interacting with the OS 304. In particular embodiments, the API 306 may further include a hypervisor that coordinates the operation of the proxy VM 302. A host computer typically includes a host central processing unit (CPU) 308 and various host I / O devices 310. The host I / O devices 310 include, for example, a graphics interface. Examples of graphics interfaces include a graphics processing unit (GPU), audio peripherals, a network interface controller (NIC), a keyboard, a mouse, and other peripherals. In certain embodiments, the architecture 300 may include target hardware in the host I / O devices 310. The architecture 300 includes a device driver 312 that handles interactions between the host I / O devices 310, an OS 304, an API 306, and any application software that, when executed, interacts with the host I / O devices 310. For example, the proxy VM 302 interacts with the host I / O devices 310 via the API 306, the OS 304, and the device driver 312.

[0019] If the processor 102 does not match the processor for the host computer, the proxy VM 302 includes a virtual processor 314 that emulates the processor 102 of the embedded system 100. On the other hand, if the target processor 102 matches the processor of the host computer, the proxy VM 302 may not include the virtual processor 314. The proxy VM 302 also includes an OS 316 and a BSP 318 that correspond to the combination of the emulated hardware and the OS 316. The OS 316 and the BSP 318 are stored in one or more sections of emulated memory, which is connected to the virtual processor 314 via a virtual memory bus. In certain embodiments, such a virtual memory bus is a conceptual memory bus or memory structure implemented in the virtualization layer that enables the construction of a memory map and the transfer of data between the VM and the host hardware. The OS 316 is the same as or very similar to the OS 132 of the embedded system 100. BSP 318 includes configuration information for virtual processor 314 to execute OS 316, including, for example, memory mapping and interrupt mapping. Note that in the early stages of development of embedded system 100, when the hardware design is incomplete, proxy VM 302 typically does not include fully emulated I / O devices 320 or fully emulated peripheral buses that correspond to the target hardware I / O devices 112 of embedded system 100. Thus, the target code typically does not include device drivers 322 that correspond to the emulated I / O devices 320 or emulated peripheral buses. However, in later iterations, as the design of these virtualized components becomes more mature, these virtualized components are eventually incorporated into proxy VM 302.

[0020] The architecture 300 includes target code 324, which is typically developed in an IDE 326 running the OS 316. As previously mentioned, in the early stages of development, the target code 324 typically includes only application software for a minimal level of functionality. As development progresses, as target I / O devices are designed and emulated I / O devices 320 become available, the target code 324 is developed to include a hardware abstraction layer, i.e., API 328 and device drivers 322. The target code 324 is typically developed and tested in the IDE 326 or other test environment using underlying test data 330. The test data 330 is typically stored in host memory, but may also be stored in the proxy VM 302 along with the target code 324 for "white-box testing" purposes.

[0021] Generally, low-level functions in target code 324 do not interact, at least not directly, with emulated I / O devices 320. Target code 324 generally interacts with emulated I / O devices 320 through APIs 328. As both the hardware design and the embedded software become more mature, target code 324 can use APIs 328, which in turn can use device drivers 322 and emulated I / O devices 320.

[0022] The emulated I / O device 320 may include virtual hardware that differs from the target hardware of the embedded system 100 or that will not be included in the completed target hardware. For example, the proxy VM 302 may include an emulated Ethernet controller to control communications during test and development until the target hardware for the embedded system is designed and selected. For example, avionics systems often use standardized communication buses, such as the ARINC 429 or MIL-STD-1553 bus, and can communicate through an emulated Ethernet controller until a target hardware PCI mezzanine card for the ARINC 429 or MIL-STD-1553 bus is designed or selected. Additionally, the emulated Ethernet controller or emulated I / O device 320 may be removed from the proxy VM 302 in later stages of the design of the embedded system 100. In certain embodiments, the proxy VM 302 may include other virtual peripheral buses that connect or couple the proxy VM 302 to host hardware, such as physical host I / O devices. This allows the VM to communicate with devices external to the physical host via a virtual peripheral bus that is connected at the virtualization layer to the physical peripheral bus.

[0023] Target code 324 can be developed and tested on proxy VM 302. Virtual processor 314 executes OS 316. Host OS 304 also executes IDE 326 or other target code development tools on OS 316. Virtual processor 314 loads target code 324 and test data 330, specifically test input data, through emulated I / O devices 320, such as a virtual communication interface, e.g., an emulated Ethernet controller. In certain embodiments, if I / O devices 320 are not available in proxy VM 302, for example, because embedded system 100 is not yet fully developed, target code 324 and test data 330 are loaded directly into emulated memory in proxy VM 302. The loaded code and data are available once target code 324 is launched in proxy VM 302. Virtual processor 314 then executes target code 324 to process the test input data and writes test output data through the virtual communication interface in response to the execution of target code 324. For example, if a communication interface is not available in proxy VM 302, the test output data is written to emulated memory within proxy VM 302, after which processing is performed for verification and validation.

[0024] As the hardware design progresses and new target hardware becomes available, the target hardware is incorporated into the host I / O device 310 in the host computer. In response, API 328 and device driver 322 corresponding to the target hardware are incorporated into proxy VM 302. These components are mapped to API 306 and device driver 312 for the target hardware incorporated into the host computer, so that target code 324 can interact through these components.

[0025] 4 is a block diagram illustrating an example host computer 400 for emulating target hardware for the embedded system 100 shown in FIG. 1. Examples of the host computer 400 may include a desktop PC, a server PC, a cloud computing platform (e.g., a VM), a mobile computing device (e.g., a tablet computer or a smartphone), a training system, or other suitable computing system. The host computer 400 includes a host CPU 308 connected to a RAM 402 and a host memory 404 via a physical bus 406, which may include one or more memory buses, communication buses, or peripheral buses. The host memory 404 is computer-readable memory that includes a section for storing the proxy VM 302, a section for storing the OS 304, a section for storing the API 306, a section for storing the device driver 312, and a section for storing the target code 324. In alternative embodiments, one or more sections of the host memory 404 may be omitted, in which case the corresponding data may be stored remotely. For example, in particular embodiments, target code 324 may be stored remotely on a server or mass storage device and provided to host CPU 308 and proxy VM 302 over a network.

[0026] The host computer 400 further includes host I / O devices 310, examples of which may include a communication interface such as an Ethernet controller 408 or a peripheral interface for communicating with host peripheral devices 410 via a peripheral link 412. The host I / O devices 310 may include, for example, a GPU for operating a display device via a display link.

[0027] In particular embodiments, host computer 400 may include target I / O devices 414 for target hardware for embedded system 100 whose design and selection has been completed or nearly completed. For example, in one embodiment, host computer 400, and more specifically, target I / O devices 414, may include ARINC 429 mezzanine cards or MIL-STD-1553 PCI mezzanine cards that are the same as or substantially similar to the target hardware for embedded system 100. In such an embodiment, host computer 400 also includes device drivers 312 corresponding to these target I / O devices 414. Host computer 400 may include mapping information in a virtualization layer (e.g., included in an API or hypervisor) that associates the emulated target I / O devices 414 with the physical target I / O devices 414 included in host computer 400.

[0028] FIG. 5 is a flow diagram illustrating an embodiment of a method 500 for testing target code for incomplete target hardware. An example of the target hardware is the target hardware for the embedded system 100 shown in FIG. 1. The method 500 may be performed, for example, by the host computer 400 shown in FIG. 4. The host computer 400 executes the proxy VM 302 to emulate the target hardware at 502. As shown in FIG. 3, the proxy VM 302 includes a virtual processor 314, emulated memory, and I / O devices 320. In certain embodiments, the I / O devices often include a virtual communication interface, such as a virtual Ethernet controller. The host computer 400 executes the OS 304 stored in the emulated memory on the proxy VM 302 at 504. The host computer 400, or more specifically, the proxy VM 302, loads the target code 324 and test input data 330 via the virtual communication interface at 506. The target code 324 is then executed on the proxy VM 302 at 508 to process the test input data 330. In response to the execution of the target code 324 at 508, the test output data is written out via the virtual communication interface at 510. In an alternative embodiment, the test input data 330 may be stored in the proxy VM 302 along with the target code 324 and may be available without reading out 506. Similarly, in certain embodiments, the test output data may be written out to emulated memory instead of being written out via the virtual communication interface at 510.

[0029] Proxy VM 302 may further include a BIOS or boot loader connected to virtual processor 314. The boot loader loads OS 316 and BSP 318 from the appropriate portion of emulated memory upon startup of proxy VM 302. Host computer 400 includes one or more development tools, such as IDE 326, that run on host OS 304. In particular embodiments, OS 316 is omitted, and BSP 318 and target code 324 run on emulated bare metal. In such embodiments, one or more development tools, such as IDE 326, run without intervention of OS 316.

[0030] In particular embodiments, executing 508 the target code 324 includes executing at least one functional application on the proxy VM 302 that interacts with at least one peripheral hardware abstraction layer, such as the API 328, but does not directly interact with peripheral hardware, such as the I / O device 320. Such I / O devices are typically not included in the preliminary hardware design of the target hardware of the embedded system 100. For the purposes of this disclosure, the term "functional application" refers to any portion of program code that does not directly interact with peripheral hardware. Peripheral hardware generally includes any hardware portion that communicates with the processor 102 via a data bus (e.g., a memory bus, a communication bus, a peripheral bus), but is not integrated into the processor 102 or communicates with the processor 102 via a front-side bus. For example, with reference to the embedded system 100 of FIG. 1, peripheral hardware devices communicate with the processor 102 via the memory bus 108 and peripheral bus 110 and through the host bridge 106. Proxy VM 302 also runs additional code beyond the target code to test proxy VM 302 itself.

[0031] The technical effects of the disclosed method, system, and apparatus include, for example, at least one of the following: (a) A proxy VM targeting the hardware of an embedded system can be provided early in the development of the embedded system, typically before the target hardware is complete; (b) Development and testing can be performed on a proxy VM running the same or a very similar OS and BSP as the target hardware, and can run on the same emulated processor as the target hardware; (c) Testing and development of the target hardware and target code can be performed earlier without requiring rehosting or full virtualization of the target hardware; (d) High-fidelity development testing can be performed earlier on the proxy VM, reducing defects later in the development of the embedded system; and (e) A user trainer (e.g., a maintenance or operator training system) can be implemented on a proxy VM running the same or a very similar OS and BSP as the target hardware, and can run on the same emulated processor as the target hardware.

[0032] In some embodiments, one or more electronic processor devices or computer devices are used. As used herein, the terms "processor" and "computer," and related terms such as "processor device," "computer device," and "controller," are not limited to what is commonly referred to in the art as an integrated circuit. These terms are broad terms that include processors, processor devices, controllers, general-purpose central processing units (CPUs), graphics processing units (GPUs), microcontrollers, microcomputers, programmable logic controllers (PLCs), reduced instruction set computer (RISC) processors, field programmable gate arrays (FPGAs), digital signal processor (DSP) devices, application-specific integrated circuits (ASICs), and other programmable circuits or processor devices capable of performing the functions described herein, and these terms are used interchangeably. These processor devices are generally configured to perform certain functions by being programmed or being programmed, or by providing instructions for execution. The above examples are not intended to limit in any way the definition or meaning of processor, processor device, and related terms.

[0033] In the embodiments described herein, memory includes, but is not limited to, computer-readable non-transitory media, such as, but not limited to, flash memory, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable read-only memory (EEPROM), non-volatile RAM (NVRAM), etc. As used herein, the term "computer-readable non-transitory media" is intended to represent any tangible computer-readable medium, including, but not limited to, computer-readable non-transitory storage devices, including, but not limited to, volatile and non-volatile media, removable or fixed media, including, but not limited to, firmware, physical and virtual storage media, CD-ROMs, DVDs, and other suitable digital sources such as a network or the Internet, as well as digital means developed in the future, excluding only transitory carrier signals. Alternatively, a floppy disk, compact disk, e.g., a read-only memory (CD-ROM), a magneto-optical disk (MOD), a digital versatile disk (DVD), or any other computer-based device implemented with any method or technology for short-term or long-term storage of information, such as computer-readable instructions, data structures, program modules and sub-modules, or any other data, may also be used. Accordingly, the methods described herein may be coded as executable instructions and implemented, for example, as "software" and "firmware" on a non-transitory computer-readable medium. Furthermore, the terms "software" and "firmware" are used interchangeably herein and include any computer program stored in memory and executed by personal computers, workstations, client devices, and server devices. These instructions, when executed by a processor, cause the processor to perform at least a portion of the methods described herein.

[0034] Additionally, in the embodiments described herein, additional input channels may include computer peripherals associated with the operator interface, such as, but not limited to, a mouse and keyboard, or other computer peripherals, such as, but not limited to, a scanner. Additionally, in some embodiments, additional output channels may include, but not limited to, an operator interface monitor.

[0035] The systems and methods described herein are not limited to the specific examples described above, and elements of the systems and / or steps of the methods may be used independently and separately from other elements and / or steps described herein.

[0036] It should be noted that although particular features of various embodiments of the present disclosure may be shown in some drawings and not in others, this is for reasons of convenience only, and in accordance with the principles of the present disclosure, any feature shown in any drawing may be referenced and / or claimed in combination with any feature shown in any other drawing.

[0037] In this specification, the use of an element or step in the singular does not necessarily exclude a plurality of elements or steps unless specifically stated otherwise. In addition, references to "one embodiment" or "an exemplary embodiment" of the present invention do not exclude the existence of other embodiments that incorporate features recited in the embodiment.

[0038] This written description uses examples to disclose various embodiments, including the best mode, and to enable those skilled in the art to practice various examples, including making and using any devices or systems, and performing the incorporated methods. The patentable scope of this disclosure is defined by the claims, and may include other examples that occur to those skilled in the art. Such other examples should be considered within the scope of the claims if they contain elements that do not differ from the literal language of the claims, or if they contain equivalent elements that have only insubstantial differences from the literal language of the claims.

[0039] Exemplary embodiments of the present disclosure further include, but are not limited to, those set forth in the following appendices:

[0040] According to one embodiment of the present disclosure, a host computer includes a memory storing a proxy virtual machine (VM) that emulates undesigned target hardware, and a host central processing unit (CPU) configured to emulate the target hardware by executing the proxy virtual machine. The proxy virtual machine includes a virtual processor for emulating the target processor, and emulated memory communicating with the virtual processor via a virtual memory bus and having at least one portion that stores target code. The proxy virtual machine, when executed by the host central processing unit, is configured to execute the target code via the virtual processor.

[0041] In an optional configuration of the host computer according to the above appendix, the proxy virtual machine, when executed by the host central processing unit, is further configured to execute at least one target code development tool.

[0042] In an optional configuration of the host computer according to any of the above appendices, the target code includes at least one functional application that interacts with at least one peripheral hardware abstraction layer but does not interact with peripheral hardware omitted in the incomplete design.

[0043] In an optional configuration, the host computer according to any of the above appendices further includes a peripheral hardware device included in the target hardware, and the proxy virtual machine further includes a hardware abstraction layer corresponding to the peripheral hardware device, the hardware abstraction layer configured to use a host driver for the peripheral hardware device when the target code is executed by the proxy virtual machine.

[0044] In an optional configuration of the host computer according to any of the above clauses, the proxy virtual machine includes virtualized peripheral hardware devices that correspond to peripheral hardware that is not included in the completed design of the target hardware.

[0045] In an alternative configuration of the host computer according to any of the above clauses, the proxy virtual machine further includes a virtual peripheral bus connecting emulated I / O devices of the proxy virtual machine and physical host I / O devices.

[0046] In an alternative configuration of the host computer according to any of the above clauses, the emulated memory further comprises a portion storing an operating system (OS) and a board support package (BSP).

[0047] In an optional configuration, the host computer according to any of the above appendices further includes a virtual communication interface connected to an emulated peripheral bus, the emulated memory further having a portion for storing test input data, and the proxy virtual machine, when executed by the host central processing unit, is further configured to execute the target code by the virtual processor to process the test input data, and to write test output data via the virtual communication interface in response to execution of the target code.

[0048] One embodiment of the present disclosure relates to a method for executing target code for undesigned target hardware, the method including: executing a proxy virtual machine (VM) for emulating the undesigned target hardware, the proxy virtual machine including a virtual processor, an emulated memory, and a virtual communication interface; executing the target code stored in the emulated memory on the proxy virtual machine; accessing input data on the proxy virtual machine; processing the input data by the target code; and writing output data via the virtual communication interface in response to execution of the target code.

[0049] The method according to the above clause, in an optional configuration, further includes accessing output data by a host processor via a virtual bus on the proxy virtual machine.

[0050] The method according to the above clause, in an optional configuration, further includes executing an operating system (OS) stored in the emulated memory on the proxy virtual machine.

[0051] In an optional configuration of the method according to the above appendix, the proxy virtual machine further includes a boot loader connected to the virtual processor, the boot loader configured to load the operating system and board support package (BSP) from a portion of the emulated memory when the proxy virtual machine is started.

[0052] The method according to any of the above appendices, in an optional configuration, further includes executing at least one target code development tool connected to the proxy virtual machine via the virtual communication interface.

[0053] In an optional configuration of the method according to any of the above notes, executing the target code includes executing at least one functional application on the proxy virtual machine that interacts with at least one peripheral hardware abstraction layer but does not interact with peripheral hardware omitted in the unfinished design.

[0054] One embodiment of the present disclosure relates to a computer-readable memory storing a proxy virtual machine (VM) that emulates target hardware, the proxy virtual machine including: a virtual processor for emulating a target processor; emulated memory connected to the virtual processor via a virtual memory bus, the emulated memory having at least one portion storing a board support package (BSP) and target code; and a virtual communication interface connected to the virtual processor via an emulated peripheral bus. The proxy virtual machine, when executed by a host central processing unit (CPU), is configured to execute the target code stored in the emulated memory, access input data on the proxy virtual machine, process the input data with the target code, and write output data via the virtual communication interface in response to execution of the target code.

[0055] In an optional configuration of the computer-readable memory according to the above appendix, the emulated memory of the proxy virtual machine includes a virtual random access memory (RAM) connected to the virtual processor via the virtual memory bus, and a virtual non-volatile memory connected to the virtual memory bus and storing the board support package and the target code.

[0056] In a selective configuration of the computer-readable memory according to the above appendix, the proxy virtual machine includes a boot loader connected to the virtual processor and configured to load an operating system (OS) and the board support package from the virtual non-volatile memory upon startup.

[0057] In an optional configuration of the computer-readable memory according to any of the preceding clauses, the target hardware and the proxy virtual machine each do not include a device driver for a peripheral device.

[0058] In an optional configuration of the computer-readable memory according to any of the above clauses, the target hardware and the proxy virtual machine are from an incomplete design.

[0059] In an optional configuration of the computer-readable memory according to any of the above notes, the proxy virtual machine includes virtualized peripheral hardware devices corresponding to peripheral hardware not included in the completed design of the target hardware.

[0060] One embodiment of the present disclosure relates to a host computer including a memory storing a proxy virtual machine (VM) that emulates target hardware, and a host central processing unit (CPU) configured to emulate the target hardware by executing the proxy virtual machine. The proxy virtual machine includes a virtual processor for emulating the target processor, and an emulated memory connected to the virtual processor via a virtual memory bus, the emulated memory having at least one portion that stores target code. The proxy virtual machine, when executed by the host central processing unit, is configured to execute the target code via the virtual processor.

[0061] One embodiment of the present disclosure relates to a trainer system for a target hardware device. The trainer system includes a user interface configured to receive input data from a user, a host computer connected to the user interface, and a host central processing unit (CPU). The host computer includes a memory for storing a proxy virtual machine (VM) that emulates the target hardware device, the proxy virtual machine including a virtual processor for emulating a target processor, and an emulated memory connected to the virtual processor via a virtual memory bus, the emulated memory having at least one portion for storing target code. The host central processing unit is configured to emulate the target hardware by executing the proxy virtual machine. The proxy virtual machine, when executed by the host central processing unit, is configured to execute the target code via the virtual processor.

[0062] One embodiment of the present disclosure is a test bench for an embedded system, comprising a host computer. The host computer includes a host communication interface for receiving input test data, a memory for storing a proxy virtual machine (VM) emulating a target hardware device whose design is not yet complete, and a host central processing unit configured to emulate the target hardware by executing the proxy virtual machine. The proxy virtual machine includes a virtual processor for emulating the target processor, and emulated memory connected to the virtual processor via a virtual memory bus, the emulated memory having at least one portion for storing target code. The proxy virtual machine, when executed by the host central processing unit, is configured to execute the target code via the virtual processor and the input test data.

Claims

1. a memory for storing a proxy virtual machine (VM) that emulates a target hardware for which a design is not yet complete, the proxy virtual machine comprising: emulated ethernet controller, a virtual processor for emulating the target processor; and a memory including an emulated memory in communication with the virtual processor via a virtual memory bus and having at least one portion storing target code; a host central processing unit (CPU) configured to emulate the target hardware by executing the proxy virtual machine; the proxy virtual machine, when executed by the host central processing unit, is configured to execute the target code with the virtual processor to interact with at least the emulated Ethernet controller; the host central processing unit updates the proxy virtual machine to remove the emulated Ethernet controller and to include target hardware I / O devices; The updated proxy virtual machine is reconfigured to execute the target code with the virtual processor and to interact with at least the I / O devices that are target hardware.

2. The host computer of claim 1 , wherein the proxy virtual machine, when executed by the host central processing unit, is further configured to execute at least one target code development tool.

3. 3. The host computer of claim 1, wherein the target code includes at least one functional application that interacts with at least one peripheral hardware abstraction layer but does not interact with peripheral hardware omitted in the incomplete design.

4. A host computer as described in any one of claims 1 to 3, further including peripheral hardware devices included in the target hardware, and the proxy virtual machine further including a hardware abstraction layer corresponding to the peripheral hardware devices, the hardware abstraction layer configured to use host drivers for the peripheral hardware devices when the target code is executed by the proxy virtual machine.

5. 5. The host computer of claim 1, wherein the proxy virtual machine includes virtualized peripheral hardware devices that correspond to peripheral hardware that is not included in the completed design of the target hardware.

6. 6. The host computer according to claim 1, wherein the proxy virtual machine further includes a virtual peripheral bus connecting emulated input / output devices of the proxy virtual machine and physical host input / output devices.

7. 7. The host computer of claim 1, wherein the emulated memory further comprises a portion for storing an operating system (OS) and a board support package (BSP).

8. and a virtual communication interface connected to an emulated peripheral bus, the emulated memory further having a portion for storing test input data, the proxy virtual machine, when executed by the host central processing unit, further comprising: executing the target code with the virtual processor to process the test input data; 8. The host computer of claim 1, configured to write test output data via the virtual communication interface in response to execution of the target code.

9. 1. A method of executing target code for undesigned target hardware, comprising: running a proxy virtual machine (VM) for emulating the undesigned target hardware, the proxy virtual machine having a virtual processor, emulated memory, and a virtual communication interface including an emulated Ethernet controller; executing the target code stored in the emulated memory on the proxy virtual machine to interact with at least the emulated Ethernet controller; accessing input data on the proxy virtual machine; processing the input data with the target code; writing output data via the virtual communication interface in response to execution of the target code; updating the proxy virtual machine to remove the emulated Ethernet controller and include target hardware I / O devices; executing, in the updated proxy virtual machine, the target code in the emulated memory to interact with at least the I / O devices that are target hardware.

10. 10. The method of claim 9, further comprising accessing output data by a host processor on the proxy virtual machine through a virtual bus.

11. The method of claim 9 or 10, further comprising running an operating system (OS) stored in the emulated memory on the proxy virtual machine.

12. 12. The method of claim 11, wherein the proxy virtual machine further includes a boot loader connected to the virtual processor, the boot loader configured to load the operating system and a board support package (BSP) from a portion of the emulated memory when the proxy virtual machine starts.

13. The method of any one of claims 9 to 12, further comprising executing at least one target code development tool connected to said proxy virtual machine via said virtual communication interface.

14. 14. The method of claim 9, wherein executing the target code comprises executing at least one functional application on the proxy virtual machine that interacts with at least one peripheral hardware abstraction layer but does not interact with peripheral hardware omitted in the unfinished design.

15. A memory for storing a proxy virtual machine (VM) that emulates unfinished target hardware design, the proxy virtual machine comprising: a virtual communications interface including an emulated Ethernet controller; a virtual processor for emulating the target processor; and a memory including an emulated memory connected to the virtual processor via a virtual memory bus and having at least one portion storing target code; a host central processing unit (CPU) configured to emulate the target hardware by executing the proxy virtual machine; the proxy virtual machine, when executed by the host central processing unit, is configured to execute the target code with the virtual processor to interact with at least the emulated Ethernet controller; the host central processing unit updates the proxy virtual machine to remove the emulated Ethernet controller and to include target hardware I / O devices; The updated proxy virtual machine is reconfigured to execute the target code with the virtual processor and to interact with at least the I / O devices that are target hardware.

Images