Computer system

Abstract

The present disclosure relates to a computer system, including a simulation virtual machine, which includes a translator and an instruction executor for translating simulation virtual machine instructions into instructions executable by a test platform. The simulation virtual machine uses shared memory to send instructions to the test platform; the instruction translator includes a CPU simulator, which receives and sends instructions to and from the BIOS and the OS, and the instruction translator also includes multiple instruction grabbers for grabbing corresponding instructions from the simulator; the instruction executor includes: a request filtering module for filtering and distributing various instructions received from the instruction translator, and sending the filtered instructions required for the test platform to execute the test; the request control module sends the filtered instructions to a transmission module, and receives the test execution results from the test platform from the transmission module; the transmission module uses shared memory to send the instructions required by the test platform to the test platform.

Description

Technical Field

[0001] The present disclosure relates to the field of computers, and in particular to emulation of software and hardware instructions by computer systems. Background Art

[0002] As the demand for processor computing power in fields such as cloud computing, big data, and personal computers continues to grow, processor complexity is increasing, and product iterations are required to be faster and faster. Processor product verification, especially chip verification, often accounts for over 70% of the entire chip development process. Traditional verification methods perform hardware and software verification separately in the early and late stages of verification. Software system verification relies on hardware emulators, which require expensive board resources, resulting in low verification efficiency and quality. Summary of the Invention

[0003] Despite the tight timelines and heavy workloads associated with the development of both computer system software and hardware, the field has been lacking full-cycle hardware-software collaborative verification. Improving chip verification efficiency and quality, and thereby shortening processor development time, has become a key concern.

[0004] In view of this, the present disclosure proposes a computer system, which includes a simulation virtual machine unit, which is configured to use the simulation virtual machine unit to run a basic input and output system, an operating system and application software, the simulation virtual machine unit includes an instruction translator and an instruction executor configured to translate the simulation virtual machine instructions into instructions that can be executed by a test platform, the simulation virtual machine unit uses shared memory to send instructions to the test platform for execution, and receives test execution results from the test platform; the instruction translator includes a CPU simulator, the CPU simulator receives and sends the instructions with the basic input and output system and the operating system, the instruction translator also includes a plurality of instruction grabbers for grabbing corresponding instructions from the CPU simulator; and the instruction executor includes: a request filtering module, a memory simulator, a peripheral simulator, a request filter ... A request control module and a transmission module, wherein the request filtering module is configured to filter and distribute various types of instructions received from the instruction translator, and send the filtered instructions required for the test platform to perform the test to the request control module, wherein the filtered instructions include interrupt instructions; the memory simulator and the peripheral simulator are configured to receive the filtered instructions from the request filtering module, and return the respective processing results of the memory simulator and the peripheral simulator to the request filtering module; the request control module is configured to send the filtered instructions to the transmission module, and receive the test execution results from the test platform from the transmission module; and the transmission module is configured to use shared memory to send the instructions required for the test platform to perform the test to the test platform, and receive the test execution results of the test platform.

[0005] By utilizing the above-mentioned full instruction grabber and request filter, at least one of the following effects can be achieved according to various aspects of the present disclosure: the versatility of the simulation system is greatly improved, and the hardware resources such as simulator boards that the simulation relies on can be reduced; through the interaction between the simulation virtual machine and the test platform, collaborative testing of software and hardware can be achieved, thereby shortening the time consumed by chip verification; by adjusting the instruction filtering rules of the request filtering module, the test of different designs to be tested can be adapted, thereby achieving flexible testing.

[0006] Further features and aspects of the present disclosure will become apparent from the following detailed description of exemplary embodiments with reference to the attached drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate exemplary embodiments, features, and aspects of the disclosure and, together with the description, serve to explain the principles of the disclosure.

[0008] Figure 1A schematic block diagram illustrating an emulation virtual machine unit included in a computer system according to an embodiment of the present disclosure is shown.

[0009] Figure 2 A schematic diagram illustrating the relationship between shared memory and physical memory according to an embodiment of the present disclosure.

[0010] Figure 3 A schematic block diagram illustrating communication between a simulation virtual machine unit and a test platform using a shared memory queue according to an embodiment of the present disclosure is shown.

[0011] Figure 4 A schematic diagram showing a comparison of the time taken by non-concurrent simulation and concurrent simulation according to an embodiment of the present disclosure is shown.

[0012] Figure 5 A schematic block diagram of a structure in which a simulation virtual machine unit is tested using a test platform according to an embodiment of the present disclosure is shown.

[0013] Figure 6 An exemplary diagram illustrating a test platform structure used in a test according to an embodiment of the present disclosure is shown.

[0014] Figure 7 A schematic flow chart showing how to quickly build a hybrid simulation solution based on the original test environment.

[0015] Figure 8 A schematic block diagram showing various applicable designs to be tested according to an embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0016] Various exemplary embodiments, features, and aspects of the present disclosure will be described in detail below with reference to the accompanying drawings. The same reference numerals in the accompanying drawings represent elements with the same or similar functions. Although various aspects of the embodiments are shown in the accompanying drawings, the drawings are not necessarily drawn to scale unless otherwise indicated.

[0017] The word “exemplary” is used exclusively herein to mean “serving as an example, example, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.

[0018] In addition, numerous specific details are provided in the following detailed description to better illustrate the present disclosure. Those skilled in the art will appreciate that the present disclosure can be practiced without certain specific details. In some instances, methods, means, components, and circuits well known to those skilled in the art are not described in detail in order to highlight the main points of the present disclosure.

[0019] Figure 1 A schematic block diagram of a simulation virtual machine unit 100 included in a computer system according to an embodiment of the present disclosure is shown.

[0020] The computer system includes a simulation virtual machine unit 100 and is configured to run a basic input and output system (BIOS), an operating system, and application software using the simulation virtual machine unit 100. Figure 1 As shown, the simulation virtual machine unit 100 includes an instruction translator 102 and an instruction executor 104 configured to translate the simulation virtual machine instructions into instructions that can be executed by the test platform. The simulation virtual machine unit 100 uses shared memory to send instructions to the test platform for execution and receives test execution results from the test platform. The instruction translator 102 includes a CPU simulator 1021, which receives and sends the instructions to the basic input and output system and the operating system. The instruction translator 102 also includes multiple instruction grabbers. In a specific implementation, for example, it may include: a memory instruction grabber 1022 for grabbing corresponding instructions from the CPU simulator 1021, an input and output (IO) instruction grabber 1023, a model special register (MSR) instruction grabber 1024, a special instruction grabber 1025, and an interrupt instruction grabber 1026. The instruction executor 104 includes a request filtering module 1042 , a memory simulator 1047 , a peripheral simulator 1048 , a request control module 1044 and a transmission module 104 . Among them, the request filtering module 1042 is configured to filter and distribute various types of instructions received from the instruction translator 102 (for example, in a specific implementation, it may include memory instructions, input and output instructions, model-specific register instructions, special instructions and interrupt instructions), and send the filtered remaining instructions required for the test platform to perform the test to the request control module 1044, wherein the filtered remaining instructions include interrupt instructions; the memory simulator 1047 and the peripheral simulator 1048 are configured to receive the filtered instructions from the request filtering module 1042, and return the respective processing results of the memory simulator 1047 and the peripheral simulator 1048 to the request filtering module 1042; the request control module 1044 is configured to send the filtered remaining instructions to the transmission module 1046, and receive the test execution results from the test platform from the transmission module 1046; and the transmission module 1046 is configured to use shared memory to send the instructions required for the test platform to perform the test to the test platform, and receive the test execution results of the test platform.

[0021] The inventor first realized that the design to be tested on the test platform used can be a single module or a subsystem, etc. Since the function of the design to be tested is single, not all instructions may be executed, and the instruction sets that can be executed by different designs to be tested may also be different. The instructions that can be executed by the design to be tested can be intercepted in the simulation virtual machine and sent to the design to be tested for processing, and the results returned by the design to be tested can be received, while the instructions that cannot be executed by the design to be tested (i.e., the filtered instructions) are executed by the virtual device on the simulation virtual machine, thereby realizing the versatility of the present disclosure. The virtual device on the simulation virtual machine can be a default existing on an open source virtual machine such as a simulation virtual machine, or it can be developed using a simulation virtual machine framework.

[0022] The inventors conducted research and secondary development on traditional virtual machines, extracting all instructions generated during software execution. They then filtered out instructions that the design under test could execute and then simulated them in a hybrid environment. Furthermore, they modified or added relevant virtual devices within the virtual machine to execute the filtered instructions that the design under test could not. This allows system software or application software to execute unmodified within the simulated virtual machine of the computer system disclosed herein, reducing the workload during verification and facilitating comparisons across different platforms.

[0023] Within the emulated virtual machine unit 100, the CPU simulator 1021 parses software-generated instructions and can access I / O, MSR (model-specific register), and custom instructions through embedded source code. The memory simulator 1047 implements the MMU (Memory Management Unit) and accesses memory and MMIO instructions through embedded source code. The peripheral simulator 1048 simulates the behavior of various peripheral devices and can access device-specific instructions through embedded source code.

[0024] In a possible implementation, the instruction grabbers 1022 - 1026 may grab instruction codes corresponding to various types of instructions from the source code according to the characteristics of different emulated virtual machine instructions.

[0025] In one possible implementation, the request filtering module 1042 can filter the instructions obtained from the instruction translator 102 based on the instruction requirements of the design under test (DUT) on the test platform, wherein the filtered instructions are executed on the memory simulator 1047 and the peripheral simulator 1048 within the simulation virtual machine unit 100, and the design under test executes the remaining filtered instructions.

[0026] In one possible implementation, the request filtering module 1042 filters instructions based on any one of the following: based on the type of the design to be tested on the test platform; or based on the address range accessed by the instruction; or based on the requirement of the design to be tested on the test platform for instructions, to filter the instructions obtained from the instruction translator.

[0027] In a possible implementation, the request filtering module 1042 may determine whether the instruction is an instruction required by the design under test according to whether the address range corresponds to a memory, a peripheral device, or a design under test.

[0028] In one possible implementation, the request control module 1044 can encode, track and flow control the remaining filtered instructions, and backfill the data returned from the design under test to the shared memory to the simulation virtual machine unit 100, which is then returned by the simulation virtual machine unit 100 to the basic input and output system or operating system that issued the instruction.

[0029] In a specific implementation, the request control module 1044 can record instructions for which data is expected to be returned according to an identification code (ID), and in response to receiving data returned by the design to be tested from the transmission module 1046, obtain instruction information from the record according to the ID, and send the returned data to the CPU simulator 1021 in the simulation virtual machine unit 100 based on the obtained instruction information.

[0030] In one possible implementation, the transmission module 1046 can package at least one of the received input and output instructions, model-specific register instructions, and special instructions, so as to transmit at least one of the input and output instructions, model-specific register instructions, and special instructions in a data packet in a format corresponding to each instruction (for example, 3 formats).

[0031] In one possible implementation, the transmission module 1046 may monitor a communication channel of a shared memory, which may include an interrupt transmission channel and a read data channel for memory instructions, input / output instructions, and model-specific register instructions.

[0032] For example, in response to monitoring data on the read data channel, the transmission module 1046 obtains the data and sends the obtained data to the CPU simulator 1021, the memory simulator 1047, or a cache module connected between the request filtering module 1042 and the request control module 1044;

[0033] For another example, in response to monitoring an interrupt on the interrupt transmission channel, the transmission module 1046 reports the interrupt to the interrupt instruction grabber 1026 in the instruction translator 102 .

[0034] One of the features of an embodiment of the present disclosure is that it implements full instruction simulation. It should be noted that according to different simulation requirements, the peripherals simulated by the peripheral simulator 1048 may be different, which is only schematically illustrated here. In the peripheral simulator 1048, you can use the existing common peripherals of the simulation virtual machine, such as USB radio data recorder (USDR), or you can develop other peripheral devices yourself. In a specific implementation, the corresponding instructions can be processed in the CPU simulator 1021, memory simulator 1047, and peripheral simulator 1048 in the simulation virtual machine.

[0035] A typical computer system may include several instructions as shown in the following table.

[0036]

[0037] Compared to the prior art, the inventors have further developed at least the following components / functions: a module for capturing various instruction types within the full instruction set, a request filtering module, an interrupt handler, a request control module, a transmission module, and a corresponding shared memory communication protocol. According to one embodiment of the present disclosure, the functions of each of these components / modules are detailed below.

[0038] 1) Virtual machine part

[0039] In a specific implementation of the embodiment of the present disclosure, a basic input / output system, an operating system, and application software are run on a simulated virtual machine. These software run in the virtual machine to generate various virtual machine instructions, including the various instructions in the above table.

[0040] 2) Instruction translator for emulated virtual machines

[0041] The instruction translator can translate various types of virtual machine instructions into instructions that can be executed by the host machine. In this process, a hooker can be used for each type of instruction to capture the various instructions in the above table, as shown in the following table:

[0042]

[0043] In a specific implementation, each instruction grabber grabs corresponding instructions based on, for example, the characteristics of the virtual machine instructions. For example, for a memory instruction grabber, it can accurately intercept and forward from the code to grab memory instructions based on the memory management in the memory simulator. It should be noted that the concept of grabbing various types of instructions in a simulated virtual machine has never been proposed in the art, and at the implementation level, it is not obvious to those skilled in the art. Instead, it requires a very deep understanding of the simulated virtual machine architecture and the virtual machine code implementation level.

[0044] 3) Command executor

[0045] After QEMU completes the instruction translation, it can execute the instruction. When executing the instructions required by the captured test platform, you can process various instructions according to the following table:

[0046]

[0047] In a specific embodiment, when sending the input and output instructions, model-specific register instructions, and special instructions required by the test platform to the request control module, formats corresponding to the three types of instructions can be defined, and the instructions can be packaged using the transmission module of the instruction executor to transmit the three types of instructions in three formats in, for example, one data packet.

[0048] In addition, as shown in the figure, the instruction translator of one embodiment of the present disclosure may include an interrupt instruction catcher. The interrupt instruction catcher can monitor in real time whether the request control module has an interrupt, and if so, report the interrupt to the interrupt module of the emulated virtual machine, and then notify the CPU to execute the interrupt.

[0049] 4) Request filtering module

[0050] The request filtering module is used to filter and distribute the instructions captured and sent by the instruction grabber. Specifically, the request filtering module can filter out instructions to be executed by the design under test and send them to the request control module. It also filters out instructions to be executed within the simulation virtual machine and distributes them to either the memory simulator or the peripheral simulator based on the instruction type.

[0051] Specifically, memory instructions can be divided into two types: one is memory instructions for accessing memory. This type of instruction is filtered by the request filtering module and then sent to the memory simulator; the other type is memory management input and output (MMIO) for accessing peripherals. This type of instruction is filtered by the request filtering module and then sent to the peripheral simulator. During actual testing, when certain memory instructions for accessing memory need to pass the test of the design under test, these instructions need to be filtered by the request filtering module and then sent to the design under test through the request control module and the transmission module. For other memory instructions for accessing memory that do not need to pass the test of the design under test, they need to be filtered by the request filtering module and then sent to the memory simulator. Similarly, when certain MMIO instructions need to pass the test of the design under test, these instructions need to be filtered by the request filtering module and then sent to the design under test through the request control module and the transmission module. For other MMIO instructions that do not need to pass the test of the design under test, they need to be filtered by the request filtering module and then sent to the peripheral simulator for execution. The above only specifically explains the screening simulation of memory instructions. The same screening principles apply to IO instructions, MSR instructions, Special instructions, and custom instructions. When one or more specific instructions of these types need to be tested by the design to be tested, they are filtered by the request filtering module and then sent to the design to be tested through the request control module and the transmission module. Specific instructions that do not need to be tested by the design to be tested are sent to the peripheral simulator.

[0052] 5) Request control module

[0053] The request control module controls the transmission module to forward instructions so that the instructions can be executed in the design under test on the test platform. In one specific implementation, the execution result data can be read from the design under test on the test platform. The request control module waits for the transmission module to obtain the actual execution result data from the design under test and then backfills the execution result data to the instruction executor of the simulation virtual machine, just as if the instruction was processed and executed by the instruction executor of the simulation virtual machine itself.

[0054] In a specific implementation, the request control module may perform at least one of the following operations:

[0055] ◆Call the transmission module to send the data packet to the test platform.

[0056] For instructions that expect data to be returned, such as memory reads, these instructions are recorded. After receiving the data returned by the transmission module, the instruction information is retrieved from the record based on the ID. The instruction data is then returned to the CPU simulator, which then returns it to the corresponding instruction issuer (BIOS or operating system).

[0057] ◆It can monitor in real time whether there is an interrupt from the transmission module. If there is an interrupt, it will report the interrupt to the interrupt hooker in the instruction translator, and then notify the CPU simulator to execute the interrupt.

[0058] 6) Transmission module

[0059] ◆Used to pack instructions and send them to different transmission channels of the shared memory queue according to their types.

[0060] ◆Used to monitor several channels (shared memory queues) used by the test platform to send data to the simulated virtual machine, including: monitoring the memory / IO / MSR read data channel. If there is memory / IO / MSR read data, it will be sent to the request control module first. The request control module will send the data to different objects according to the source of the read request: if the read request source is the memory read data of the cache, it will be sent to the cache; if the read request source is the memory read, IO read, or MSR read data of the CPU, it will be sent to the CPU; the transmission module also monitors the interrupt transmission channel. If there is an interrupt (including the Advanced Programmable Interrupt Controller (APIC), System Management Interrupt (SMI), Non-maskable Interrupt (NMI), etc.), it will be reported to the interrupt instruction grabber in the instruction translator.

[0061] 7) Shared Memory

[0062] The shared memory space in the physical memory is used to carry and implement the shared memory queue. The shared memory is the specific carrier of the transmission channel between the simulation virtual machine and the test platform.

[0063] Figure 2 Schematic diagram showing the relationship between the shared memory and the physical memory 200 according to an embodiment of the present disclosure. Figure 2 As shown, a shared memory space is set between the memory space occupied by the simulated virtual machine process and the test platform process in the physical memory 200. Through shared memory, the simulated virtual machine process and the test platform process can share and use the same physical memory. All communications can be completed by reading and writing to the shared memory. This direct access to memory has the characteristics of high speed, high reliability, and strong real-time performance. The request and data of the simulated virtual machine unit 100 can be quickly transferred to the test platform. The data of the design to be tested in the test platform can also be quickly transferred to the simulated virtual machine unit 100.

[0064] Figure 3 A schematic block diagram illustrating communication between a simulation virtual machine unit and a test platform using a shared memory queue according to an embodiment of the present disclosure is shown. In a specific implementation, Figure 3The green part in the figure can run the fast emulation virtual machine process (QEMU process).

[0065] like Figure 3 As shown, based on shared memory process communication technology, independent queues can be implemented in shared memory to independently and concurrently transmit different types of instructions and data in the simulation. In one specific implementation, instructions or data sent from the simulation virtual machine to the test platform are transmitted through the downlink queue, and instructions or data sent from the test platform to the simulation virtual machine are transmitted through the uplink queue.

[0066] In one specific implementation, shared memory can be allocated by the operating system in physical memory, and this physical memory space is shared by the emulated virtual machine process and the test platform process. Therefore, the test platform can directly access instructions sent by the emulated virtual machine from the shared memory, just as if the test platform were accessing its own queue. Similarly, the emulated virtual machine can access different types of instructions or data sent by the test platform to the emulated virtual machine as if it were directly accessing its own queue. The advantages of this approach include at least one of the following: 1) Fast simulation speed, as shared memory speed is the fastest among all process communication speeds; 2) Reliable communication, as information is directly transferred in memory under control, typically avoiding packet loss and data errors; 3) Low coupling between the emulated virtual machine and the test platform, as the emulated virtual machine and the test platform only need to operate on the queues without having to worry about each other's implementation mechanisms; 4) Reduced data conversion, as data packets from the emulated virtual machine and the test platform can be used directly without protocol conversion; 5) Simple to use and highly scalable, it can be encapsulated into an application programming interface (API); and 6) High concurrency, as detailed below.

[0067] In one possible implementation of an embodiment of the present disclosure, the emulated virtual machine process and the test platform process share the computer system's physical memory via a shared memory queue communication protocol. The transmission module 1046 places different types of instructions or data into separate shared memory queues, allowing the test platform to concurrently retrieve instructions or data from the queues.

[0068] In a specific implementation of an embodiment of the present disclosure, the message format of the shared memory queue communication protocol may include a shared memory header, which includes sideband information for exchanging information between the simulation virtual machine unit 100 and the test platform. The sideband information is set by the simulation virtual machine unit 100 during initialization and can be used when transmitting the interrupt instruction.

[0069] For example, the shared memory header may include the number and description information of the communication channels between the simulation virtual machine unit 100 and the test platform set during initialization, so that the test platform can bind the communication channels created by the simulation virtual machine unit 100 according to the number and the description information.

[0070] The message format of the communication protocol is described in detail below.

[0071] 1) Shared memory header

[0072] The shared memory header can store some status information for communication status, the number and description of transmission channels, and information exchange with some sidebands between the simulated virtual machine and the simulator or emulator test platform. The shared memory header can be set by the simulated virtual machine during initialization. In a specific implementation, the setting may include: creating shared memory, filling in the number and description of transmission channels, and sideband information. After the shared memory header information is set, the set information is known to both the simulated virtual machine and the test platform process. The sideband information is used, for example, when a user transmits an interrupt signal.

[0073] In one specific implementation, when the emulated virtual machine creates a transmission channel, it increments the number of transmission channels in the message header by 1 and adds the description of the newly created transmission channel to the header. Before communicating with the emulated virtual machine, the test platform process obtains the number and description of the transmission channels from the message header and binds the transmission channels created by the emulated virtual machine based on this information. This allows the emulated virtual machine and the test platform to communicate via transmission signals.

[0074] The sample code for the shared memory header is as follows.

[0075]

[0076] The meaning of each field is as follows:

[0077]

[0078]

[0079] 2) Shared memory queue elements

[0080] The communication channel is a shared memory queue. C / C++ structures are used as the basic elements of the shared memory queue. Because the elements in the structure are customizable, the type of information transmitted by the channel can be customized. For example, the following is a structure definition used for transmitting a memory read or write request:

[0081]

[0082] In a specific implementation, the shared memory queue can be implemented in three structures, for example: multi-thread sending and multi-thread receiving, multi-thread sending and single-thread receiving, and single-thread sending and single-thread receiving.

[0083] According to an embodiment of the present disclosure, a shared memory queue communication protocol is developed to achieve concurrent transmission and high-speed simulation of instructions and data between the simulation virtual machine unit 100 and the test platform.

[0084] Figure 4 A schematic diagram showing a comparison of the time taken by non-concurrent simulation and concurrent simulation according to an embodiment of the present disclosure is shown.

[0085] High concurrency principle such as Figure 4 As shown, Figure 4 (a) shows the traditional non-concurrent simulation method, where different types of requests are in the same queue. Therefore, before the request at the front of the queue is processed, the request at the back will be blocked and cannot be processed. The example in (a) takes a total of 6 clock cycles to complete the simulation, which is a serial method. Figure 4 (b) illustrates the concurrent simulation method of the present disclosure, placing different types of requests in separate queues. Simulation can be performed concurrently from these queues without blocking each other. In the specific example of (b), the simulation is completed in just three clock cycles. Thus, using shared memory can meet the timing requirements of the DUT, allowing different types of requests to be processed synchronously on the DUT side.

[0086] Figure 5 A schematic block diagram of a structure in which a simulation virtual machine unit according to an embodiment of the present disclosure is tested using a test platform is shown. Figure 5 As shown, the top layer is the Top layer, in which the sub-modules (DUT, COSIM adapter, and DPI interface configuration information, etc.) of the DUT running on the test platform 504 are instantiated, as well as the connection relationship information between the sub-modules. Figure 5 The illustrated example is a top-down hybrid simulation solution. The simulated virtual machine unit 502 can be an open-source virtual machine. In one specific implementation, the Quick Emulator (QEMU) can be used. The simulated virtual machine unit 502 can run the same basic input and output system (BIOS), operating system, and application software as a real machine.

[0087] The simulation virtual machine unit 502 can provide a platform on which software can be directly executed, obtain various instructions generated during software operation to interact with the design under test on the testbench, and simulate the required peripheral devices so that the software can be executed smoothly with almost no additional adaptation.

[0088] The computer system according to an embodiment of the present disclosure can be applied to both a co-simulation system and a co-emulation system, because, for example, the simulation virtual machine, shared memory, direct programming interface, and collaborative adapter are common to both systems. In a co-simulation system, the simulation virtual machine, shared memory, and test platform can all run on a simulation server. In a co-simulation system, the simulation virtual machine, shared memory, and direct programming interface (e.g., C language) of the software part can run on the simulation server, and the collaborative adapter and hardware interface of the direct programming interface of the hardware part can run on the simulation device (i.e., emulator).

[0089] The direct programming interface (DPI) on the testbench allows for direct interaction with shared memory queues. In one implementation, the testbench can perform verification primarily based on collaborative simulation (COSIM), using the direct programming interface to convert instructions or data through a co-simulation adapter into interface timing signals that connect to the DUT. At the top level of the testbench, the submodules that enable the DUT (e.g., the DUT, COSIM adapter, and direct programming interface configuration information) can be instantiated, along with information about the connections between the submodules.

[0090] The software verified by the test platform can be application software, basic input and output systems, or at least parts of an operating system running on a virtual machine. The hardware verified can be, for example, a design under test generated through simulation using a Verilog file compiled using a hardware programming language. The design under test is tested in conjunction with the software.

[0091] Figure 6 An exemplary diagram illustrating a test platform structure used in a test according to an embodiment of the present disclosure is shown.

[0092] According to one specific implementation of the present disclosure, when building a test platform for a computer system, the top-level test environment can be built from scratch for the design under test, instantiated and initialized, and finally connected to a simulation virtual machine unit to complete, for example, a collaborative simulation (COSIM) environment. This from-scratch approach has the advantage of removing unused modules, making the test environment more concise and reducing the consumption or occupation of simulator or emulator resources.

[0093] According to one embodiment of the present disclosure, a hybrid simulation solution based on the present disclosure can be quickly established based on the existing simulation test environment. This existing environment can refer to the existing verification environment of the test platform previously built by the verification team. When subsequently building a collaborative simulation (COSIM) platform, for example, the portion of the existing environment that initializes the design under test can be inherited, shortening the COSIM test environment development time.

[0094] Figure 6 The following shows a solution for quickly building a hybrid simulation based on the original environment. Figure 1 The left side remains the same, while the right side adds a signal switch to the existing environment. From the start of simulation to the end of environment initialization, the configuration complete (cfg done) signal is 0, and the signal switch connects to the existing peripheral environment to initialize the DUT. After environment initialization is complete, the cfg done signal is 1, and the signal switch connects to the COSIM adapter for subsequent hybrid simulation. This signal switching approach leverages the complex initialization logic of the existing environment, focusing on hybrid simulation and reducing additional debugging work. This shortens COSIM environment setup time while ensuring stability. It is suitable for rapidly setting up a COSIM environment and is a methodology that can be widely applied to various systems.

[0095] Figure 7 A schematic flow chart for quickly building a hybrid simulation solution based on the original test environment is shown, illustrating the process of this method.

[0096] In a specific implementation of the embodiment of the present disclosure, the test platform can provide a simulation verification environment including the design to be tested. According to the present disclosure, any operating system such as Windows, Linux, etc. can be run, and any open source or closed source application software can be executed, without modifying the software of the simulation virtual machine. Because the embodiment of the present disclosure has at least the following two characteristics: 1) versatility, it can be used to simulate virtual machines and simulators to build a co-simulation (co-simulation) system, and can also be used to simulate virtual machines and simulators to build a co-simulation (co-emulation) system; 2) full system simulation, the software can be switched and run on the following various test platforms without modification, so it has the advantage of comparative verification in methodology, can increase debugging (debugging) means and flexibility, and thus improve the efficiency of simulation verification.

[0097] Figure 8 The following table summarizes the above-mentioned systems:

[0098]

[0099] The following describes how to perform comparative verification:

[0100] ●When the software system (including application software, BIOS, OS, Figure 1 Also shown in Figure 8 In the lower right figure, the system is running in the post-silicon verification or production system, and a fault (bug) occurs in the system. This bug may be a software bug or a hardware bug. Since it is generally difficult to debug the system after silicon, the same software system can be directly used across platforms. Figure 8 Run the system shown in the lower left and upper right figures to reproduce the bug. Figure 8 After the system has reproduced the problem in the lower left figure, you can use the various debugging methods mentioned above, including waveforms, logs, debugging tools, etc., to first determine whether it is a software bug or a hardware bug. If it is determined to be a software bug, then work with the software development team to use Figure 8 The system in the lower left figure is further debugged, such as adding logs, using gdb tools to debug, etc. to determine the problem, and finally the software development team will solve the problem. If it is determined to be a hardware bug, the hardware development team will be coordinated to use Figure 8 The system in the lower left image is further debugged, such as adding logs and waveforms to identify the problem, and finally the hardware development team solves the problem. Figure 8 The lower left picture shows the various debugging methods mentioned above, which are very helpful in locating and solving problems.

[0101] ●When Figure 8 If you encounter a problem in the upper right picture, you can also use the same software system across platforms. Figure 8 Reproduce and solve the problem in the system shown in the lower left figure. Figure 8 The advantages of the lower left picture are: 1) it takes up less emulator resources; 2) it has better debugging methods. Figure 8 The upper right picture is rich.

[0102] In a specific implementation of comparative verification, if a problem is determined or suspected to be caused by a specific module or small-scale subsystem, a collaborative simulation (COSIM) system can be constructed, as shown in the upper left figure. By using a simulator and emulator to construct a collaborative simulation system for modules or small-scale subsystems, the same software system as the one experiencing the problem can be run cross-platform within the COSIM system without using the emulator's expensive board resources. This allows for the use of a variety of troubleshooting methods to locate and resolve the problem during debugging.

[0103] Debugging across multiple platforms simultaneously, without being limited by platform-specific interference, provides more possibilities. For example, you can compare waveforms, logs, and other information, use QEMU's virtual devices to replace modules in the DUT for comparative runs, and then analyze waveforms and logs to help identify issues.

[0104] Once the problem is identified, feedback is given to the software and hardware teams to modify the problem and ensure smooth product development.

[0105] In one possible implementation, the test platform can communicate with the simulation virtual machine unit 100 via shared memory, run the same software system as the software system to be debugged that has a fault on the test platform to reproduce the fault, and use debugging means to determine the type of the fault in response to the test platform reproducing the fault. For example, the fault type may include software fault, hardware fault, etc.

[0106] In one specific implementation, the design to be tested on the test platform may be a full chip or a subsystem-level device. In response to a failure occurring in the chip or subsystem-level device when running the software system to be debugged on the test platform, the design to be tested is changed to a smaller-scale subsystem-level device or module-level device, and a software system identical to the failed software system to be debugged is run in the smaller-scale subsystem-level device or module-level device to perform fault reproduction debugging.

[0107] In one possible implementation, the test platform includes a signal switch connected to the design to be tested. From the start of the test until the environment initialization of the test platform is completed, the signal switch connects the design to be tested to the original environment of the test platform to initialize the design to be tested.

[0108] According to one embodiment of the present disclosure, mixed simulation can be performed on various designs to be tested, such as: dynamic random access memory controller (DRAMC) modules, peripheral component interconnect express (PCIE) modules, chip interconnect subsystems, or input and output die (IO Die) systems as larger units, etc.

[0109] As a specific application example, the following will take a software verification and a hardware verification of a processor chip as an example to illustrate the entire verification process.

[0110] Taking DRAMC (DRAM controller) verification as an example, the process may include the following steps:

[0111] S1: The hardware design team develops DRAMC design and releases a basic version.

[0112] S2: The hardware verification team builds a verification environment based on the version released by the design team and releases a runnable basic version

[0113] S3: Based on the verification environment released by the hardware verification team, the COSIM team builds a simulation virtual machine (DRAMC co-simulation or co-emulation environment) and performs software verification and hardware-software interaction verification.

[0114] S4: Once a problem is discovered, it needs to be located. On the DUT side, waveforms can be captured (dumped) or logs can be output. In one specific implementation, the test platform can run within the EDA vendor's tools. Common EDA vendors all provide these capture tools. On the emulator side, logs can be output (including information printed by the software itself, as well as requests and data exchanged between the software and the emulator) to view executed requests and acquired data. Problems can also be located by dynamically obtaining the current program execution status or viewing variable values ​​using the GDBgnu open-source debugger / debugging tool. Because the emulator can run a variety of software, other software tools can also be used to locate the problem. Logs are also printed on the communication channel between the emulator and the DUT, namely in shared memory implementation functions and DPI interface functions. The debug information generated by the DUT, emulator, and communication channel can be combined to locate the problem. For example, if waveforms reveal that DRAMC registers are incorrectly configured, causing malfunction, the transmission channel log can be used to determine whether the software correctly issued the configuration request. If so, the problem is likely in the DUT, requiring the design team to review the waveforms and design. If the software is not delivered correctly, the problem may be located on the software side. The software development team needs to debug by simulating the log output by the virtual machine or using tools such as gdb, and repeat this process until the problem is finally solved.

[0115] S5: The hardware verification team discovers a design bug and reports it to the hardware design team to update the design and the verification environment simultaneously. The COSIM team then updates the COSIM environment for regression verification.

[0116] S6: The COSIM team discovers a design bug and reports it to the hardware verification team and the hardware design team for confirmation. The hardware design team then fixes the bug and submits it to the COSIM team and the hardware verification team for regression verification.

[0117] S7: The COSIM team discovers a software bug and submits it to the software development team for problem identification and debugging, and then the COSIM team performs regression verification.

[0118] S8: Steps S5-S7 are performed simultaneously and continuously until the software and design meet the verification requirements.

[0119] Generally speaking, the application scenarios of the present disclosure may include at least one of the following:

[0120] √Software development and verification in advance.

[0121] √ Perform software verification or system-level verification in advance of hardware.

[0122] √ Conduct joint debugging of software and hardware in advance, including bringing up system software.

[0123] √ Software and hardware performance analysis and tuning.

[0124] √ Compare and verify to debug internal chip problems.

[0125] In actual testing, when using the traditional testing method, an 8-core device needs to consume 12 emulator boards, and a 1-core device needs to consume 5 emulator boards. In contrast, according to the testing method of an embodiment of the present disclosure, the testing of both 8-core and 1-core devices only needs to consume 2 emulator boards, which significantly reduces resource consumption and improves verification efficiency. Due to the versatility of the computer system provided by various aspects of the present disclosure for simulation, it is possible to perform software hybrid simulation and co-simulation (co-simulation), hardware hybrid simulation and co-emulation (co-emulation) of different modules, subsystems, and system levels at various stages of chip verification, especially in the early stages, and allow the software to be compared and verified with full chip simulation (full chip emulation) and silicon simulation without any modification, thereby improving verification efficiency and quality and helping to shorten product time to market.

[0126] The universal full-instruction hardware and software hybrid method proposed in the present disclosure is universal in that it can perform software-level / system-level verification on any module, subsystem, or system at each stage of the chip development cycle using operating systems such as Windows and Linux, BIOS, and application software that do not require modification. Full instructions are mainly reflected in the acquisition of any instruction generated by the software in the system and passing it to the design under test for verification through the protocol. The shared memory queue communication protocol has the characteristics of strong concurrency, fast simulation speed, low coupling, reliable communication, reduced data conversion, simple use, and strong scalability. The present disclosure can be widely used in the collaborative and parallel verification of hardware and software at different levels and stages of various projects, especially in advance verification and software system verification. It is an extension of verification methodology and can improve verification efficiency and quality.

[0127] While various embodiments of the present disclosure have been described above, the foregoing description is intended to be illustrative, non-exhaustive, and not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is selected to best explain the principles of the embodiments, their practical applications, or technological improvements in the marketplace, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A computer system comprising a simulated virtual machine unit, configured to run a basic input / output system, an operating system, and application software using the simulated virtual machine unit, wherein: The emulated virtual machine unit includes an instruction translator and an instruction executor configured to translate emulated virtual machine instructions into instructions executable by the test platform, the emulated virtual machine unit uses shared memory to send instructions to the test platform for execution, and receives test execution results from the test platform; The instruction translator includes a CPU simulator, and the CPU simulator receives and sends the instructions with the basic input and output system and the operating system. The instruction translator further includes a plurality of instruction grabbers for grabbing corresponding instructions from the CPU simulator; as well as The instruction executor includes: a request filtering module, a memory simulator, a peripheral simulator, a request control module and a transmission module, wherein: The request filtering module is configured to filter and distribute various types of instructions received from the instruction translator, and send the filtered remaining instructions required for the test platform to perform the test to the request control module, wherein the filtered remaining instructions include interrupt instructions; The memory simulator and the peripheral simulator are configured to receive filtered instructions from the request filtering module and return processing results of the memory simulator and the peripheral simulator to the request filtering module; The request control module is configured to send the filtered remaining instructions to the transmission module, and receive the test execution result from the test platform from the transmission module; and The transmission module is configured to send instructions required by the test platform to execute a test to the test platform using a shared memory, and receive a test execution result of the test platform.

2. The system according to claim 1, wherein: Each of the instruction grabbers includes: a memory instruction grabber, an input and output instruction grabber, a model-specific register instruction grabber, a special instruction grabber, and an interrupt instruction grabber; The various types of instructions include: memory instructions, input and output instructions, model-specific register instructions, special instructions and interrupt instructions.

3. The system according to claim 1, wherein: Each of the instruction grabbers grabs the instruction code corresponding to each of the instruction grabbers according to the characteristics of the emulated virtual machine instructions.

4. The system according to claim 1, wherein: The request filtering module filters instructions according to any of the following: Filtering instructions according to the type of the design to be tested on the test platform; or Filter instructions based on the address range they access; or The instructions obtained from the instruction translator are filtered according to the instruction requirements of the design to be tested on the test platform.

5. The system according to claim 4, wherein: The request filtering module determines whether the instruction is an instruction required by the design to be tested according to whether the address range corresponds to a memory, a peripheral device or a design to be tested.

6. The system according to claim 1, wherein: The request control module encodes, tracks and controls the flow of the remaining filtered instructions, and backfills the data returned from the design to be tested on the test platform to the shared memory into the simulation virtual machine unit, which is then returned by the simulation virtual machine unit to the basic input and output system or operating system that issued the instruction.

7. The system according to claim 6, wherein: The request control module records the instructions for which data is expected to be returned according to the identification code, and in response to receiving the data returned by the design to be tested from the transmission module, obtains instruction information from the record according to the identification code, and sends the returned data to the CPU simulator in the simulation virtual machine unit according to the obtained instruction information.

8. The system according to claim 2, wherein: The transmission module packages the received at least one of the input and output instructions, model specific register instructions and special instructions, so as to transmit the at least one of the input and output instructions, model specific register instructions and special instructions in a data packet in a format corresponding to each instruction.

9. The system according to claim 1, wherein: The transmission module monitors the communication channels of the shared memory, wherein the communication channels include an interrupt transmission channel and a read data channel for memory instructions, input and output instructions, and model-specific register instructions; The transmission module acquires the data in response to monitoring the data on the read data channel and sends the acquired data to the CPU simulator, the memory simulator, or a cache module connected between the request filtering module and the request control module; The transmission module also reports the interrupt to the interrupt instruction grabber in the instruction translator in response to monitoring the interrupt on the interrupt transmission channel.

10. The system according to claim 1, wherein: The simulation virtual machine process and the test platform process share the physical memory of the computer system through a shared memory queue communication protocol. The transmission module places different types of instructions or data into different shared memory queues, so that the test platform can concurrently obtain instructions or data from the queues.

11. The system according to claim 10, wherein: The message format of the shared memory queue communication protocol includes a shared memory header, which includes sideband information for exchanging information between the simulation virtual machine unit and the test platform. The sideband information is set by the simulation virtual machine unit during initialization and used when transmitting the interrupt instruction.

12. The system according to claim 11, wherein The shared memory header includes the number and description information of the communication channels between the simulation virtual machine unit and the test platform set during initialization, so that the test platform binds the communication channels created by the simulation virtual machine unit according to the number and the description information.

13. The system of claim 1, wherein: The test platform communicates with the simulation virtual machine unit through shared memory, runs a software system identical to the faulty software system to be debugged in the test platform to reproduce the fault, and in response to the test platform reproducing the fault, uses debugging means to determine the fault type of the fault, wherein the fault type includes: software fault and hardware fault.

14. The system according to claim 13, wherein: The design to be tested on the test platform is a chip or subsystem-level device. In response to a failure of the chip or subsystem-level device when running the software system to be debugged on the test platform, the design to be tested is changed to a smaller-scale subsystem-level device or module-level device, and a software system identical to the software system to be debugged that has failed is run in the smaller-scale subsystem-level device or module-level device to perform fault reproduction debugging.

15. The system of claim 1, wherein: The test platform includes a signal switch connected to the design to be tested. From the start of the test until the environment initialization of the test platform is completed, the signal switch connects the design to be tested to the original environment of the test platform to initialize the design to be tested.

Images