System and method for developing firmware using collaborative simulation based on system virtualization

Abstract

Embodiments of the present disclosure include techniques for simulating a circuit, such as a system on a chip (SoC). In various embodiments, the simulated circuit may include one or more processors. However, using a hardware description language (HDL) to emulate circuitry may execute firmware instructions using a virtualized processor, rather than using an HDL to emulate the processor. Certain instructions from the virtualized processor may be sent to the HDL simulation for execution during the simulation.

Description

Background Technology

[0001] This disclosure generally relates to firmware development, and more specifically to systems and methods for developing firmware using co-simulation based on system virtualization.

[0002] Analog circuits are typically executed using hardware description language code that runs on a simulator, such as those provided by Synopsys® or Cadence®. For very large circuits comprising many functional blocks, such simulations can take a very long time to execute. This is especially true when the circuit includes a central processing unit (CPU). Simulating the CPU over a series of instructions can take hours or even days because the instructions are simulated on a clock cycle basis across the entire circuit. Additionally, simulations sometimes generate large amounts of data, which can complicate and limit insights into faults.

[0003] This disclosure relates to the simulation of improved circuits. Attached Figure Description

[0004] Figure 1 The illustration shows a system for analog circuits according to an embodiment.

[0005] Figure 2 The illustration shows a method for simulating a circuit according to an embodiment.

[0006] Figure 3 An example system for an analog circuit according to an embodiment is illustrated.

[0007] Figure 4 An example method for an analog circuit according to an embodiment is illustrated.

[0008] Figure 5 The illustration shows the hardware of a dedicated computing system configured according to the above disclosure. Detailed Implementation

[0009] This document describes techniques for firmware development and / or verification. In the following description, numerous examples and specific details are set forth for illustrative purposes to provide a thorough understanding of some embodiments. Various embodiments as defined by the claims may individually include some or all of the features of these examples, or combine these features with other features described below, and may also include modifications and equivalents of the features and concepts described herein.

[0010] Figure 1The illustration depicts a system for simulating a circuit according to an embodiment. Features and advantages of this disclosure include running certain instructions on the developed circuit using a virtualized processor during simulation. The circuit can be implemented as Hardware Description Language (HDL) code executed in a design automation environment. In some embodiments, for example, the HDL code can be Verilog or Register Transfer Logic (RTL) code. For example, the circuit may include a processor, but some processor functions are not simulated using HDL. Instead, some processor functions (such as firmware instructions) can be executed on the virtualized processor, which can provide faster results compared to the HDL version of the processor.

[0011] exist Figure 1 In one embodiment, a design automation environment 102 operable on at least one computer is configured with HDL code to simulate circuit 120. For example, the circuit may be a digital circuit and may include one or more processors coupled to one or more functional blocks (e.g., peripheral devices 131) via one or more buses 130. Loading the circuit HDL 120 into the design automation environment 102 allows for simulation of the circuit 120 to verify that the circuit operates and performs as needed. Verification of one or more circuits within the design automation environment is sometimes referred to as a “test bench.” The design automation environment 102 also includes multiple bus interfaces 121. Bus interfaces 121 can allow communication between the bus 130 and the peripheral devices 131 from other resources within the design automation environment (e.g., signal generators or data collection components outside the circuit HDL 120 for interacting with peripheral devices 131).

[0012] As mentioned above, virtual environment 101 includes a virtualization processor 110 for executing certain instructions that would otherwise be executed by one or more processors on the circuit HDL 120 being verified. For example, as part of the verification process, it may be desirable to execute and test instructions in firmware 150. Firmware 150 may include instructions that interact with (or cause interaction with) peripheral device 131 (referred to herein as peripheral device firmware instructions). Virtualization processor 110 may execute firmware instructions that include peripheral device firmware instructions. Advantageously, at least a portion of the peripheral device firmware instructions is transmitted via a network connection for emulation by circuit HDL code 120. For example, design automation environment 102 may include a network interface 122 coupled to bus interface 121 and configured to translate messages between bus interface 121 and network connection 151. Similarly, virtual environment 101 may include a network interface 111 coupled to virtualization processor 110 to encapsulate and decapsulate messages between virtualization processor 110 and network connection 151. Therefore, peripheral device firmware instructions can be executed by the virtualization processor 110, which generates a message that is then sent to network interface 111. Network interface 111 can encapsulate the message (e.g., in a network packet) and send it to network interface 122 via connection 151. For example, network interface 122 can receive the message and translate it into instructions on a specific bus interface 121. The message is coupled to a bus on circuit HDL 120 via bus interface 121, and the execution of the message simulates the execution of peripheral device firmware instructions in circuit HDL 120. Advantageously, a portion of the firmware instructions can be executed on the virtualization processor 110, while other portions can be simulated in circuit HDL 120. For example, some firmware instructions may not involve peripheral devices, or may only execute processor steps and return information to the user. Advantageously, some firmware instructions are processed by the virtualization processor, which is faster than executing such firmware instructions in an HDL simulator. Other firmware instructions (such as peripheral device firmware instructions) can be advantageously simulated in the circuit HDL 120 without the burden of simulating all firmware instructions in the HDL simulator. For example, executing processor functions on the virtualized processor during simulation can reduce verification time and accelerate the circuit development process.

[0013] Figure 2The illustration depicts a method for simulating a circuit according to an embodiment. At 201, a design automation environment is executed on at least one computer, such as a server (e.g., an "EDA computer"). The design automation environment may be configured with: HDL code for simulating the circuit, multiple bus interfaces, and a network interface. The circuit includes multiple buses communicating with multiple peripheral devices. The multiple bus interfaces are coupled to the multiple buses. The network interface is coupled to the multiple bus interfaces and configured to translate messages between the bus interfaces and the network connection. At 202, a virtual environment is executed on at least one computer. The virtual environment may be operable on a host computer (such as a server), for example, it may be coupled to the EDA computer via a network (e.g., Ethernet). The virtual environment may be configured with: a virtualization processor; and another network interface coupled to the virtualization processor for encapsulating and decapsulating messages between the virtualization processor and the network connection. At 203, the virtualization processor executes firmware instructions including peripheral device firmware instructions. At 204, at least a portion of the peripheral device firmware instructions is transmitted via the network connection for simulating by the HDL code.

[0014] Figure 3 The illustration depicts an example system for simulating a circuit according to an embodiment. In this example, a design automation environment 302 runs on a verification platform 360, such as Synopsys VCS®, a functional verification solution that provides simulation and constraint solver engines. Here, the circuit being verified is a System-on-Chip (SoC) RTL 320, which may include one or more processors 332, peripherals 331 for performing various functions, and one or more buses 330. Peripherals may include various functional blocks on the SoC, including but not limited to SRAM, UART, DMA control, I2C, etc. Buses 330 can be simulated using a generic verification method, which is a verification method that runs simulations and performs system IP verification. Buses may include AXI bus protocol 325, APB bus protocol 326, CHI bus protocol 327, etc., which provide interfaces to the SoC RTL 320. For example, these components may issue traffic from an external virtual CPU to the buses in the RTL. As mentioned above, since CPU332 is disabled (or excluded from SoC RTL code 320), bus interface 321 provides access to the RTL bus and peripheral devices.

[0015] In digital circuit design, register-transfer-level (RTL) code models synchronous digital circuits based on the digital signal (data) flow between hardware registers and the logical operations performed on those signals. The register-transfer-level (RTL) defines the digital portion of the design to be modeled during the design and verification process.

[0016] In this example, the virtual environment 301 includes a virtualized processor 310, I / O 312, a network interface 311, and virtualized peripherals 313. For example, the virtual environment 301 can be implemented using QEMU, a general-purpose open-source machine emulator and virtualizer. QEMU emulates a computer's processor through dynamic binary translation and provides the machine with different sets of hardware and device models, enabling it to run various guest operating systems. It can interoperate with kernel-based virtual machines (KVM) to run virtual machines at near-native speeds. QEMU can also emulate user-level processes, allowing applications compiled for one architecture to run on another. When used as a virtualizer, QEMU achieves near-native performance by executing guest code directly on the host CPU. QEMU supports virtualization when running under the Xen hypervisor or using the KVM kernel module in Linux. When using KVM, QEMU can virtualize x86, server and embedded PowerPCs, 64-bit POWER, S390, 32-bit and 64-bit ARM, and MIPS guests. It is important to understand that QEMU is merely an example virtual environment used to illustrate this technology. Other virtual environments can be used, such as virtual machines from VMware or any virtualization environment. Although the virtualization processor 310 runs on a physical host CPU (such as x86), the processor 310 can virtualize, for example, ARM, RISC, or any other CPU type.

[0017] Verification may include executing firmware 350 against the SoC RTL 320. However, as indicated above, the RTL against the SoC CPU 332 may be inactive (or removed) during verification. Therefore, SoC emulation is performed without using the RTL code against the SoC processor. Instead, the SoC processor functions are executed by the virtualized processor 310 during emulation. Firmware 350 may include microcode or programs embedded in the memory of the hardware device to assist in the operation of the hardware device. Firmware can be used to enable hardware such as cameras, smartphones, network cards, optical drives, printers, routers, scanners, and TV remotes to operate smoothly. Firmware is sometimes considered the foundation of the software stack used by computer hardware for basic operations and running applications. Hardware manufacturers can use embedded firmware to control the functionality of various hardware devices and systems, just as a computer's operating system (OS) controls the functionality of software applications. An example of firmware in computing is the BIOS (Basic Input / Output System, also known as System BIOS, ROM BIOS, BIOS ROM, or PC BIOS). BIOS is firmware used to provide runtime services for the operating system and programs, and to perform hardware initialization during the booting process.

[0018] Some firmware functions can be fully implemented in the virtual processor 310. For example, the simple addition operation required by the firmware (A+B=C) does not need to be transmitted to the RTL. Implementing some firmware functions on the virtual processor 310 saves clock cycles. On the other hand, other firmware functions may require the CPU to interact with peripherals on the SoC. Therefore, some firmware functions are coupled to the SoC RTL 320 and the RTL peripheral 331. In some cases, some firmware functions for peripherals can be emulated. For example, when the firmware function on the peripheral does not affect the behavior of the system (e.g., it generates status messages for manual interaction during debugging), such a peripheral can also be virtualized. Therefore, the virtual environment 301 includes locally virtualized peripherals 313 to execute certain peripheral firmware instructions.

[0019] The virtual environment 301 also includes an input / output controller (I / O) 312 coupled to the virtualization processor 310. I / O 312 is configured to receive messages from the virtualization processor and send messages to a network interface 311 (for emulation by RTL code) or a local virtualized peripheral device 313 (for execution on the local virtualized peripheral device 313). I / O 312 can act as a filter between the virtual processor 310 and peripheral devices implemented as RTL or emulated peripheral devices. For example, I / O 312 can determine whether a peripheral message from the virtualization processor 310 can be sent to the virtual peripheral device or whether it needs to be sent to the RTL peripheral device. For example, the virtualization processor 310 can read or write (R / W) traffic from other functional blocks (e.g., peripheral devices). I / O 312 can determine whether to send traffic to the local virtualized peripheral device 313 or the RTL peripheral device 313 based on the R / W address from the virtualization processor 310. In various embodiments, I / O 312 is custom code (e.g., it may be implemented in C, Python) that determines the path to / from traffic on processor 310. In this example, virtual environment 301 receives device tree 351. Device tree 351 may specify multiple host peripherals used to emulate local virtualization peripherals 313. In some embodiments, device tree 351 may describe, for example, what kinds of peripherals are on the host computer system running virtualization environment 301.

[0020] For peripheral device firmware instructions executed in the RTL for peripheral device 331, virtualization processor 310 generates peripheral messages, which are routed to network interface 311 by I / O 312. For example, a message may include the address used by I / O 312 to route the message to network interface 311. Network interface 311 encapsulates messages from virtualization processor 310 in TCP / IP packets for transmission over network connection 352 (e.g., Ethernet connection, intranet connection, Internet connection, or cloud network connection). TCP / IP stands for Transmission Control Protocol / Internet Protocol. TCP / IP is a standardized set of rules that allows computers to communicate over networks such as the Internet. The TCP / IP protocol supports two types of ports: TCP ports and UDP ports. TCP is typically used for connection-oriented applications, has built-in error checking, and retransmits lost packets. UDP is typically used for connectionless applications.

[0021] Network interface 322 forwards messages in TCP / IP packets to one of the multiple buses via one of the multiple buses, and to a corresponding peripheral device in one of the multiple peripheral devices 331, for emulation by SoC RTL code 320. For example, network interface 322 receives and unpacks TCP / IP packets via connection 352. Network interface 322 can map messages to a bus interface 321 based on addresses in the messages. For example, a message with a first address can be mapped to AXI bus interface 325 and the corresponding peripheral device for emulation by RTL code. Another message with a second address can be mapped to an APB bus interface and another corresponding peripheral device for emulation by RTL code. As a more specific example, a write message writing the value "1234" to address 1000 can be forwarded to the APB bus. While this example illustrates message mapping to specific buses and peripheral devices on the design automation environment network interface 322 side of connection 352, it is to be understood that such mapping can be performed on the virtual environment network interface 311 side of connection 352. However, in some example embodiments, it may be advantageous for network interface 322 to perform mappings, for example, because design automation environment 302 can more efficiently access the mapping between addresses and bus interfaces and peripheral devices. Network interface 322 can be implemented using the SystemVerilog Direct Programming Interface (DPI), which is the interface between System Verilog and external programming languages. An example implementation of the network interface can be accomplished using the C programming language as the interface with Verilog code. The C code can process incoming TCP / IP packets and translate these packets into a Verilog environment, which, for example, can transfer traffic to or from bus interface 321. For example, DPI can allow designers to call C functions from SystemVerilog and export SystemVerilog functions for C to call.

[0022] Figure 4The illustration depicts an example method for simulating a circuit according to an embodiment. At 401, the circuit RTL is loaded into the design automation environment. At 402, the bus interface (UVM) is loaded into the design automation environment. At 403, a virtualization processor is started in the virtual environment. At 404, local virtualized peripherals are started. At 405, firmware and device trees are loaded into the virtual environment. At 406, circuit RTL simulation is started. At 407, firmware instructions are processed in the virtualization processor. At 408, peripheral firmware instruction messages are generated in the virtualization processor. At 409, the I / O controller determines whether the peripheral for the message can be executed by local virtualized peripherals or remote RTL peripherals. If it can be executed by local virtualized peripherals, the message is sent to the local virtualized peripherals that execute the peripheral firmware instructions. If it cannot be executed by local virtualized peripherals, the message is sent to the network interface. At 410, the message is encapsulated in a TCP / IP packet and transmitted to the design automation environment running the circuit RTL simulation. At 411, the TCP / IP packet is received by the network interface and the message is unpacked. At 412, the network interface determines which bus interface to send the message to based on the message address. At 413, the message is sent to the bus interface and corresponding peripheral device in the SoC RTL, and peripheral device firmware instructions are executed for the peripheral device RTL.

[0023] Figure 5 The illustration shows the hardware of a dedicated computing system 500 configured according to the above disclosure. The following hardware description is merely an example. It is to be understood that various computer topologies can be used to implement the techniques described above. Figure 5The diagram illustrates an example computer system 510. Computer system 510 includes a bus 505 or other communication mechanism for transmitting information and one or more processors 501 coupled to the bus 505 for processing information. Computer system 510 also includes a memory 502 coupled to the bus 505 for storing information and instructions to be executed by the processors 501, such as information and instructions for performing some of the techniques described above. Memory 502 may also be used to store programs executed by the processors 501(c). Possible implementations of memory 502 may be (but are not limited to) random access memory (RAM), read-only memory (ROM), or both. Storage device 503 is also provided for storing information and instructions. Common forms of storage devices include, for example, hard disks, magnetic disks, optical disks, CD-ROMs, DVDs, solid-state drives, flash memory or other non-volatile memory, USB memory cards, or any other electronic storage medium that a computer can read. For example, storage device 503 may include source code, binary code, or software files for performing the above techniques. Storage device 503 and memory 502 are examples of non-transient computer-readable storage media (also known as storage media).

[0024] In some systems, computer system 510 may be coupled to display 512 via bus 505 for displaying information to the computer user. Input devices 511, such as a keyboard, touchscreen, and / or mouse, are coupled to bus 505 for transmitting information and command selections from the user to processor 501. This combination of components allows the user to communicate with the system. For example, in some systems, bus 505 represents multiple dedicated buses used to couple various components of the computer together.

[0025] Computer system 510 also includes a network interface 504 coupled to bus 505. Network interface 504 can provide bidirectional data communication between computer system 510 and local network 520. For example, network 520 can represent one or more network technologies, such as Ethernet, local wireless network (e.g., WiFi), or cellular network. For example, network interface 504 can be a wireless or wired connection. For example, computer system 510 can send and receive information across wired or wireless LANs, intranets, or cellular networks and the Internet 530 via network interface 504. In some embodiments, for example, a front-end (e.g., a browser) can access data and features on back-end software systems that can be deployed on-prem 531 on multiple different hardware servers, or can be deployed across network 530 (e.g., extranet or Internet) on servers 532 to 534. For example, one or more of servers 532 to 534 can also be deployed in a cloud computing environment. Other examples

[0026] Each of the non-limiting features in the following examples may be independent or may be combined with one or more other features in various permutations or combinations. In various embodiments, this disclosure may be implemented as a processor or method.

[0027] In one embodiment, this disclosure includes a computer system for simulating circuits, comprising: a design automation environment operable on at least one computer, the design automation environment being configured with: hardware description language code for simulating circuits, the circuits including multiple buses communicating with multiple peripheral devices; multiple bus interfaces coupled to the multiple buses; and a first network interface coupled to the multiple bus interfaces and configured to translate messages between the bus interfaces and the network connection; and a virtual environment operable on at least one computer, the virtual environment being configured with: a virtualization processor; and a second network interface coupled to the virtualization processor to encapsulate and decapsulate messages between the virtualization processor and the network connection, wherein the virtualization processor executes firmware instructions including peripheral device firmware instructions, and wherein at least a portion of the peripheral device firmware instructions is transmitted via the network connection for simulating by the hardware description language code.

[0028] In another embodiment, this disclosure includes a method of simulating a circuit, comprising: executing a design automation environment on at least one computer, the design automation environment being configured with: hardware description language code for simulating a circuit including multiple buses communicating with multiple peripheral devices; multiple bus interfaces coupled to the multiple buses; and a first network interface coupled to the multiple bus interfaces and configured to translate messages between the bus interfaces and the network connection; and executing a virtual environment on at least one computer, the virtual environment being configured with: a virtualization processor; and a second network interface coupled to the virtualization processor to encapsulate and decapsulate messages between the virtualization processor and the network connection, wherein the virtualization processor executes firmware instructions including peripheral device firmware instructions, and wherein at least a portion of the peripheral device firmware instructions is transmitted via the network connection for simulating by the hardware description language code.

[0029] In one embodiment, the circuit is a SoC including a system-on-a-chip (SoC) processor, and the SoC simulation is performed without using hardware description language code for the SoC processor, and the SoC processor functions are performed by a virtualized processor during the simulation.

[0030] In one embodiment, the virtual environment further includes a plurality of locally virtualized peripheral devices, wherein at least a second portion of the peripheral device firmware instructions is executed on the plurality of locally virtualized peripheral devices.

[0031] In one embodiment, the virtual environment further includes an input / output controller coupled to the virtualization processor, the I / O controller being configured to receive messages from the virtualization processor and send messages to one of: a second network interface for emulation by hardware description language code; and a plurality of local virtualization peripherals for execution on the plurality of local virtualization peripherals.

[0032] In one embodiment, the system further includes a device tree specifying multiple host peripheral devices for emulating multiple locally virtualized peripheral devices.

[0033] In one embodiment, the network connection is a TCP / IP connection, and the second network interface encapsulates messages from the virtualization processor in TCP / IP packets for transmission, and the first network interface forwards messages in the TCP / IP packets to one of a plurality of bus interfaces and a corresponding peripheral device among a plurality of peripheral devices via one of a plurality of buses for emulation by hardware description language code.

[0034] In one embodiment, the message includes an address, and the first network interface maps the address to one of a plurality of bus interfaces.

[0035] In one embodiment, a first message having a first address is mapped to a first bus interface and a corresponding first peripheral device for simulation by hardware description language code, and a second message having a second address is mapped to a second bus interface and a corresponding second peripheral device for simulation by hardware description language code.

[0036] In one embodiment, multiple bus interfaces are simulated using a universal verification method (UVM).

[0037] In one embodiment, the hardware description language code is register transfer logic (RTL) code.

[0038] In one embodiment, the design automation environment is operable on a first computer, and the virtual environment is operable on a host computer.

[0039] The foregoing description illustrates various embodiments and examples of how some embodiments may be implemented. The foregoing examples and embodiments should not be considered as limited embodiments, but are presented to illustrate the flexibility and advantages of some embodiments as defined in the claims. Based on the foregoing disclosure and claims, other arrangements, embodiments, implementations, and equivalents may be employed without departing from the scope defined by the claims.

Claims

1. A computer system for analog circuits, comprising: Design automation environment (102), operable on at least one computer, said design automation environment (102) being configured with: Hardware description language code for simulating the circuit (120), the circuit including multiple buses for communicating with multiple peripheral devices; Multiple bus interfaces (121) are coupled to the multiple buses; as well as A first network interface (111) is coupled to the plurality of bus interfaces and configured to translate messages between the bus interface (121) and the network connection; and A virtual environment (101), operable on at least one computer, is configured to: Virtualization processor (110); and A second network interface is coupled to the virtualization processor to encapsulate and decapsulate messages between the virtualization processor and the network connection. The virtualization processor executes firmware instructions including peripheral device firmware instructions, and at least a portion of the peripheral device firmware instructions are transmitted via the network connection for emulation by the hardware description language code.

2. The system of claim 1, wherein the circuit is a SoC including a system-on-a-chip (SoC) processor, and wherein the emulation of the SoC is performed without using hardware description language code for the SoC processor, and wherein the SoC processor functions are performed by the virtualization processor during the emulation.

3. The system according to claim 1, wherein the virtual environment further includes a plurality of locally virtualized peripheral devices, wherein at least a second portion of the peripheral device firmware instructions is executed on the plurality of locally virtualized peripheral devices.

4. The system of claim 3, wherein the virtual environment further includes an input / output controller coupled to the virtualization processor, the I / O controller being configured to receive messages from the virtualization processor and send the messages to one of the following: The second network interface is for emulation by the hardware description language code; and The plurality of local virtualized peripheral devices are used for execution on the plurality of local virtualized peripheral devices.

5. The system of claim 3 further includes a device tree, the device tree specifying multiple host peripheral devices used to emulate the plurality of local virtualized peripheral devices.

6. The system of claim 1, wherein the network connection is a TCP / IP connection, and wherein the second network interface encapsulates messages from the virtualization processor in TCP / IP packets for transmission, and wherein the first network interface forwards the messages in the TCP / IP packets to one of the plurality of bus interfaces and a corresponding peripheral device of the plurality of peripheral devices for emulation by the hardware description language code via one of the plurality of buses.

7. The system of claim 6, wherein the message includes an address, and wherein the first network interface maps the address to one of the plurality of bus interfaces.

8. The system of claim 7, wherein a first message having a first address is mapped to a first bus interface and a corresponding first peripheral device for simulation by the hardware description language code, and wherein a second message having a second address is mapped to a second bus interface and a corresponding second peripheral device for simulation by the hardware description language code.

9. The system of claim 1, wherein the plurality of bus interfaces are simulated using a universal verification method (UVM).

10. The system of claim 1, wherein the hardware description language code is register transfer logic (RTL) code.

11. The system of claim 1, wherein the design automation environment is operable on a first computer and the virtual environment is operable on a host computer.

12. A method for simulating a circuit, comprising: A design automation environment is executed on at least one computer, the design automation environment being configured to: Hardware description language code for simulating the circuit, which includes multiple buses that communicate with multiple peripheral devices; Multiple bus interfaces are coupled to the multiple buses; as well as A first network interface is coupled to the plurality of bus interfaces and configured to translate messages between the bus interfaces and the network connection; as well as A virtual environment is executed on at least one computer, the virtual environment being configured to: Virtualized processor; as well as A second network interface is coupled to the virtualization processor to encapsulate and decapsulate messages between the virtualization processor and the network connection. The virtualization processor executes firmware instructions including peripheral device firmware instructions, and at least a portion of the peripheral device firmware instructions are transmitted via the network connection for emulation by the hardware description language code.

13. The method of claim 12, wherein the circuit is a SoC including a system-on-a-chip (SoC) processor, and wherein the simulation of the SoC is performed without using hardware description language code for the SoC processor, and wherein the SoC processor functions are performed by the virtualization processor during the simulation.

14. The method of claim 12, wherein the virtual environment further comprises a plurality of locally virtualized peripheral devices, wherein at least a second portion of the peripheral device firmware instructions is executed on the plurality of locally virtualized peripheral devices.

15. The method of claim 14, wherein the virtual environment further comprises an input / output controller coupled to the virtualization processor, the I / O controller being configured to receive messages from the virtualization processor and send the messages to one of the following: The second network interface is for emulation by the hardware description language code; and The plurality of local virtualized peripheral devices are used for execution on the plurality of local virtualized peripheral devices.

16. The method of claim 14, further comprising a device tree specifying a plurality of host peripherals used to emulate the plurality of local virtualized peripherals.

17. The method of claim 12, wherein the network connection is a TCP / IP connection, and wherein the second network interface encapsulates messages from the virtualization processor in TCP / IP packets for transmission, and wherein the first network interface forwards the messages in the TCP / IP packets to one of the plurality of bus interfaces and a corresponding peripheral device of the plurality of peripheral devices for emulation by the hardware description language code via one of the plurality of buses.

18. The method of claim 17, wherein the message includes an address, and wherein the first network interface maps the address to one of the plurality of bus interfaces.

19. The method of claim 18, wherein a first message having a first address is mapped to a first bus interface and a corresponding first peripheral device for emulation by the hardware description language code, and wherein a second message having a second address is mapped to a second bus interface and a corresponding second peripheral device for emulation by the hardware description language code.

20. The method of claim 12, wherein the hardware description language code is register transfer logic (RTL) code.

Images