Computer system

Abstract

The present disclosure relates to a computer system comprising a simulation virtual machine comprising a translator to translate simulation virtual machine instructions into instructions executable by a test platform and an instruction executor, the simulation virtual machine sending the instructions to the test platform using a shared memory; the instruction translator comprises a CPU (Central Processing Unit) simulator, the simulator, a BIOS (Basic Input Output System) and an OS (Operating System) for receiving and sending instructions, and the instruction translator further comprises a plurality of instruction grabber for grabbing corresponding instructions from the simulator; the instruction executor comprises a request filtering module which filters and distributes various instructions received from the instruction translator, and sends filtered residual instructions required by test execution of the test platform to a request control module; the request control module sends the filtered residual instruction to the transmission module, and receives a test execution result from the test platform from the transmission module; and the transmission module sends an instruction required by the test platform to the test platform by using the shared memory.

Description

Technical Field

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

[0002] As the demand for processor computing power in cloud computing, big data, personal computers and other fields increases, processor complexity becomes greater and greater, and product iteration speed is required to be faster and faster. The time for processor product verification, especially chip verification, often accounts for more than 70% of the entire chip development time. Traditional verification methods perform hardware and software verification separately in the early and late stages of verification, and software system verification relies on hardware simulation systems (emulators) that require expensive board resources, resulting in low verification efficiency and quality. Summary of the invention

[0003] Although the development time of computer system software and hardware is tight and the task is heavy, there has been a lack of full-cycle software and hardware collaborative verification in this field. How to improve the verification efficiency and quality of chips and thus shorten the processor development time has become a 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 simulation virtual machine instructions into instructions executable 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 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 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 remaining 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, according to various aspects of the present disclosure, at least one of the following effects can be achieved: 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, software and hardware collaborative testing can be achieved, thereby shortening the time consumed by chip verification; by adjusting the instruction filtering rules of the request filtering module, the testing 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 showing a simulation virtual machine unit included in a computer system according to an embodiment of the present disclosure.

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

[0010] Figure 3 A schematic block diagram showing 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 for a non-concurrent simulation and a concurrent simulation according to an embodiment of the present disclosure is shown.

[0012] Figure 5 A structural schematic block diagram showing a simulation virtual machine unit performing a test using a test platform according to an embodiment of the present disclosure.

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

[0014] Figure 7 A schematic flow chart showing a method for quickly building 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. 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 specified.

[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, in order to better illustrate the present disclosure, numerous specific details are given in the following specific embodiments. It should be understood by those skilled in the art that the present disclosure can also be implemented without certain specific details. In some examples, methods, means, components and circuits well known to those skilled in the art are not described in detail in order to highlight the subject matter 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 the test execution results from the test platform. The instruction translator 102 includes a CPU simulator 1021, and the CPU simulator 1021 receives and sends the instructions with 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 can include: a memory instruction grabber 1022, an input and output (IO) instruction grabber 1023, a model special register (MSR) instruction grabber 1024, a special (Special) instruction grabber 1025, and an interrupt instruction grabber 1026 for grabbing corresponding instructions from the CPU simulator 1021. 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. 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 studied and redeveloped traditional virtual machines, obtained all instructions generated during the software execution process, screened out instructions that can be executed by the design to be tested, and performed mixed simulation with the design to be tested. At the same time, relevant virtual devices are modified or added to the virtual machine to execute the filtered instructions that cannot be executed by the design to be tested. As a result, system software or application software can be executed in the simulated virtual machine of the computer system of the present invention without modification, reducing the extra workload in the verification process, and also creating conditions for comparison on different platforms.

[0023] Inside the simulation virtual machine unit 100: the CPU simulator 1021 parses the instructions generated by the software and can obtain IO, MSR (model specific register), and customized instructions through embedded source code; the memory simulator 1047 implements the MMU (Memory Management Unit) and obtains memory and MMIO instructions through embedded source code. The peripheral simulator 1048 is responsible for simulating the behavior of each peripheral device. Device-related instructions can be obtained 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 according to the requirements of the design under test (DUT) on the test platform for instructions, wherein the filtered instructions are executed on the memory simulator 1047 and the peripheral simulator 1048 in 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 under test on the test platform; or based on the address range accessed by the instructions; or based on the requirement of the design under test on the test platform for instructions, the instructions obtained from the instruction translator are filtered.

[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 interval 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 control the flow of 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 may 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 under test 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-output instructions, model-specific register instructions, and special instructions, so as to transmit at least one of the input-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 the communication channel of the shared memory. The communication channel may include an interrupt transmission channel and a read data channel of a memory instruction, an input / output instruction, and a model-specific register instruction.

[0032] For example, in response to monitoring the data on the read data channel, the transmission module 1046 acquires the data and sends the acquired 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 full instruction simulation is implemented. It should be noted that according to different simulation requirements, the peripherals simulated by the peripheral simulator 1048 may be different, and only a schematic illustration is given here. In the peripheral simulator 1048, the existing common peripherals of the simulation virtual machine, such as a USB radio data recorder (USDR), can be used, or other peripheral devices can be developed independently. In a specific implementation, the corresponding instructions can be processed in the CPU simulator 1021, the memory simulator 1047, and the 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 with the prior art, the inventors have further developed at least the following components / functions: capture of various types of instructions in the full instruction set, request filtering module, interrupt processing, request control module, transmission module, and corresponding shared memory communication protocol. According to an embodiment of the present disclosure, the functions of the above components / modules are described in detail as follows.

[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 are run in the virtual machine to generate various virtual machine instructions, including 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 to grab various instructions in the above table for each type of instruction, as shown in the following table:

[0042]

[0043] In a specific implementation, each instruction grabber grabs corresponding instructions according to, for example, the characteristics of each virtual machine instruction. 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 idea of ​​grabbing various types of instructions in a simulated virtual machine has never been proposed in the art, and it is not obvious and easy for a person skilled in the art to think of it at the implementation level, but 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, various instructions can be processed 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, the formats corresponding to the three instructions can be defined, and the instructions can be packaged using the transmission module of the instruction executor so as to transmit the three instructions in three formats in, for example, one data packet.

[0048] In addition, as shown in the figure, the instruction translator of an 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 emulation 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 capturer. Specifically, the request filtering module can filter out the instructions to be executed by the design under test and send them to the request control module, and filter out the instructions to be executed inside the simulation virtual machine, and distribute them to one of the memory simulator and the peripheral simulator according to the type of the instruction.

[0051] Specifically, memory instructions can be divided into two types: one is memory instructions for accessing memory, which are sent to the memory simulator after being filtered by the request filter module; the other is memory management input and output (MMIO) for accessing peripherals, which are sent to the peripheral simulator after being filtered by the request filter module. In actual testing, when some memory instructions for accessing memory need to pass the test of the design under test, these instructions need to be filtered by the request filter module and sent to the design under test through the request control module and the transmission module, while other memory instructions for accessing memory that do not need to pass the test of the design under test are sent to the memory simulator after being filtered by the request filter module. Similarly, when some MMIOs need to pass the test of the design under test, these instructions need to be filtered by the request filter module and sent to the design under test through the request control module and the transmission module, while other MMIOs that do not need to pass the test of the design under test are sent to the peripheral simulator for execution after being filtered by the request filter module. 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 the instruction so that the instruction is executed in the design under test on the test platform. In a 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 real execution result data from the design under test, and fills the execution result data back to the instruction executor of the simulation virtual machine, just as the instruction is 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 read, such instructions will be recorded. After receiving the data returned by the transmission module, the instruction information is obtained from the record according to the ID, and then the instruction data is returned to the CPU simulator, and the CPU 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, the interrupt will be reported to the interrupt hooker in the instruction translator, and then the CPU simulator will be notified 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 memory / IO / MSR read data channels. If there is memory / IO / MSR read data, it will be sent to the request control module first. The request control module sends 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 is sent to the cache; if the read request source is the memory read, IO read, MSR read data of the CPU, it is 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) and other interrupts, 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 A 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 simulation virtual machine process and the test platform process in the physical memory 200. Through the shared memory, the simulation virtual machine process and the test platform process can share the same physical memory. All communications can be completed by reading and writing to the shared memory. This direct access to the memory has the characteristics of high speed, high reliability and strong real-time performance. The request and data of the simulation 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 simulation virtual machine unit 100.

[0064] Figure 3 A schematic block diagram showing 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 the shared memory process communication technology, independent queues can be implemented in the shared memory to independently and parallelly transmit different types of instructions and data in the simulation. In a specific implementation, the instructions or data sent by the simulation virtual machine to the test platform are transmitted through the downlink queue, and the instructions or data sent by the test platform to the simulation virtual machine are transmitted through the uplink queue.

[0066] In a specific implementation, the shared memory can be allocated space on the physical memory by the operating system, and the simulated virtual machine process and the test platform process share this part of the physical memory space. Therefore, the test platform can directly obtain the instructions sent by the simulated virtual machine from the shared memory, just like the test platform is accessing its own queue. Similarly, the simulated virtual machine obtains different types of instructions or data sent by the test platform to the simulated virtual machine just like directly obtaining them from its own queue. The advantages of this method include at least one of the following: 1) Fast simulation speed, because the shared memory speed is the fastest communication speed of all processes; 2) Reliable communication, because the information is directly controlled and transmitted in the memory, and usually there will be no problems such as packet loss and data errors; 3) Low coupling between the simulated virtual machine and the test platform, the simulated virtual machine and the test platform only need to operate the queue, and do not need to care about the implementation mechanism of the other party; 4) Reduced data conversion, the data packets of the simulated virtual machine and the test platform can be used directly without protocol conversion; 5) Simple to use and highly scalable, can be encapsulated into an application program interface (API); 6) It has the characteristics of high concurrency, as described below.

[0067] In a possible implementation of an embodiment of the present disclosure, 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 1046 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.

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

[0073] In a specific implementation, when the simulation virtual machine creates a transmission channel, each time a transmission channel is created, the number of transmission channels in the header is increased by 1, and the description information of the newly created transmission channel is added to the header. Before the test platform process communicates with the simulation virtual machine, it obtains the number and description information of the transmission channels through the header information, and binds the transmission channel created by the simulation virtual machine based on this information. In this way, the simulation virtual machine and the test platform can communicate through the transmission signal.

[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] Use the shared memory queue as the communication channel. Use C / C++ structures as the basic elements of the shared memory queue. Because the elements in the structure are customizable, the information type transmitted by the channel supports customization. For example, the following is a structure definition used for memory read or write request transmission:

[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 for a non-concurrent simulation and a concurrent simulation according to an embodiment of the present disclosure is shown.

[0085] High concurrency principle 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) shows the concurrent simulation method of the present disclosure, which places different types of requests in independent queues, and can concurrently take out instructions from the queues for simulation without blocking each other. In the specific example of (b), it only takes 3 clock cycles to complete the processing. Therefore, the timing requirements of the design under test can be met by using shared memory, so that different types of requests can be processed synchronously on the design under test side.

[0086] Figure 5 A schematic block diagram of a structure showing a test performed by a simulation virtual machine unit using a test platform according to an embodiment of the present disclosure 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 What is shown is a hybrid simulation solution built from top to bottom. The simulation virtual machine unit 502 can be an open source virtual machine. In a specific implementation, a quick simulation virtual machine (Quick EMUlator, QEMU) can be used. The simulation virtual machine unit 502 can run the same basic input and output system (BIOS), operating system and application software as the 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 the 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 the co-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-emulation system, the simulation virtual machine, shared memory, and direct programming interface of the software part, such as the C language part, can run on the simulation server, and the co-adapter and the hardware interface of the direct programming interface of the hardware part can run on a simulation device (i.e., an emulator).

[0089] The direct programming interface (DPI) on the test platform can directly interact with the shared memory queue. In a specific implementation, the test platform can perform verification based on collaborative simulation (COSIM), using the direct programming interface to convert instructions or data through the collaborative simulation adapter to interface timing signals connected to the design under test. At the top level of the test platform, the sub-modules that enable the design under test to run (such as the design under test, COSIM adapter, and direct programming interface configuration information, etc.) and the connection relationship information between the sub-modules can be instantiated.

[0090] The software verified by the test platform can be at least part of the application software, basic input and output system, and operating system running on the virtual machine, and the hardware verified can be, for example, the design to be tested generated after simulation by a Verilog file compiled by a hardware programming language. The design to be tested is tested in coordination with the above software.

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

[0092] According to a specific implementation of the present disclosure, when building a test platform for a computer system, the top layer of the test environment can be built from scratch for the design to be tested, the design to be tested can be instantiated and initialized, and finally connected to the simulation virtual machine unit to complete, for example, a collaborative simulation COSIM environment. The advantage of this from-scratch construction method is that some unused modules can be removed, making the test environment more concise, thereby reducing the consumption or occupation of simulator or emulator resources.

[0093] According to an embodiment of the present disclosure, a hybrid simulation solution based on the present disclosure can be quickly built based on the original environment of the simulation test. The original environment can refer to the original verification environment of the test platform previously built by the verification team. When building a collaborative simulation COSIM platform in the future, for example, the part of the original environment that initializes the design to be tested can be inherited to shorten the development time of the COSIM test environment.

[0094] Figure 6 The following is a solution for quickly building a hybrid simulation based on the original environment. Figure 1 The left part is the same, and a signal switch is added to the right side based on the original environment. During the period from the start of simulation to the end of environment initialization, the configuration completion (cfg done) signal is 0, and the signal switch connects to the original peripheral environment to initialize the DUT. After the environment initialization is completed, the cfg done signal is 1, and the signal switch connects to the COSIM adapter for subsequent hybrid simulation. This signal switching method makes full use of the complex initialization logic of the original environment, focuses on hybrid simulation, reduces additional debugging work, shortens the time to build the COSIM environment, and ensures the stability of the environment. It is suitable for quickly building a COSIM environment and is a methodology that can be widely used in 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 embodiments 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, and there is no need to modify the software of the simulation virtual machine. Because the embodiments of the present disclosure have at least the following two characteristics: 1) Universality, it can be used to simulate virtual machines and simulators to build a co-simulation (co-simulation) system, and it 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 (debug) means and flexibility, and thus improve the efficiency of simulation verification.

[0097] Figure 8 A schematic block diagram of various designs to be tested that can be applied according to an embodiment of the present disclosure is shown. 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 fails (bugs) during post-silicon verification or production system operation. 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 installed across platforms. Figure 8 The bug is reproduced by running in the system shown in the lower left and upper right figures. Figure 8 After the system has reproduced the problem in the lower left figure, you can use various debugging methods as 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, collaborate 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 helping to locate and solve 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, when it is determined or suspected that the problem is caused by a specific module or small-scale subsystem, the collaborative simulation COSIM system shown in the upper left figure can be built. Using simulators and emulators to build a collaborative simulation system of modules or small-scale subsystems, without occupying the expensive board resources of the emulator, the same software system as the software system to be debugged with the problem can be run across platforms in the COSIM system, and a rich range of positioning methods can be used to locate and solve problems during debugging.

[0103] ●Multiple platforms can debug together, without being limited by the interference of specific factors on a certain platform, which provides more possibilities for debugging. For example, you can compare waveforms, logs and other information, use QEMU's virtual device to replace the modules in the DUT for comparative operation, and then analyze the waveforms and logs to help identify the problem.

[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 a possible implementation, the test platform can communicate with the simulation virtual machine unit 100 through a shared memory, run the same software system as the software system to be debugged that has a fault in the test platform to reproduce the fault, and in response to the test platform reproducing the fault, use debugging means to determine the type of the fault. For example, the fault type may include software fault, hardware fault, etc.

[0106] In a 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 under test. From the start of the test until the environment initialization of the test platform is completed, the signal switch connects the design under test to the original environment of the test platform to initialize the design under test.

[0108] According to one embodiment of the present disclosure, mixed simulation can be performed on various designs to be tested, such as: a dynamic random access memory controller (DRAMC) module, a peripheral component interconnect express (PCIE) module, a chip interconnect subsystem, or an input and output die (IO Die) system as a larger unit, 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 basic version that can be run.

[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: When a problem is found, it is necessary to locate the problem. On the DUT side, waveforms can be captured (dumped) or logs can be output. In a specific implementation, the test platform can be run in the tools of EDA manufacturers. Common EDA manufacturers all provide the above-mentioned capture tools. On the emulation virtual machine side, the executed requests and acquired data can be viewed by outputting logs (including information printed by the software itself, and requests and data for interaction between the software and the emulation virtual machine). The problem can also be located by dynamically obtaining the current program execution status or viewing variable values ​​through the GDBgnu open source debugger / debugging tool. Because the emulation virtual machine can run a variety of software, other software tools can also be used to locate the problem; on the communication channel between the emulation virtual machine and the DUT, that is, in the shared memory implementation function and the DPI interface function, logs are also printed. The above-mentioned debug information generated by the three parts of the DUT, the emulation virtual machine, and the communication channel can be combined to locate the problem. For example, through the waveform, it can be seen that the DRAMC register is not configured correctly, resulting in abnormal operation. At this time, the log of the transmission channel can be used to determine whether the software correctly sends the configuration request. If the software is correctly sent, the location problem may be in the DUT, and the design team needs to check the waveform and design. If the software is not correctly released, the positioning problem may occur on the software side. The software development team needs to debug through the log output by the simulation virtual machine or use 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 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. After the hardware design team fixes the bug, it is handed over 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] In general, the application scenarios of the present disclosure may include at least one of the following:

[0120] √Software is developed and verified in advance.

[0121] √ Hardware performs software verification or system-level verification in advance.

[0122] √ Carry out software and hardware joint debugging in advance, including bringing up system software, etc.

[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, only 2 emulator boards are needed for both 8-core and 1-core device testing, 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, software hybrid simulation and co-simulation (co-simulation), hardware hybrid simulation and co-emulation (co-emulation) of different modules, subsystems, and system levels can be performed at various stages of chip verification, especially in the early stages, and the software can be compared and verified with full chip simulation (full chip emulation) and silicon simulation without any modification, which improves verification efficiency and quality and helps shorten product time to market.

[0126] The universal full-instruction software-hardware 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 Windows, Linux, and other operating systems and BIOS, and application software that do not require modification. Full instructions are mainly reflected in the acquisition of any instructions generated by the software in the system and passing them to the design under test through the protocol for verification. 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 parallel verification of software and hardware at different levels and stages of various projects, especially early verification and software system verification. It is an extension of verification methodology and can improve verification efficiency and quality.

[0127] The embodiments of the present disclosure have been described above, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and changes will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The selection of terms used herein is intended to best explain the principles of the embodiments, practical applications, or technical improvements in the market, or to enable other persons of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A computer system, comprising a simulated virtual machine unit, configured to use the simulated virtual machine unit to run a basic input and output system, an operating system and application software, characterized in that: The simulation virtual machine unit includes an instruction translator and an instruction executor configured to translate the simulation virtual machine instructions into instructions executable by the test platform, and the simulation virtual machine unit uses the shared memory to send the instructions to the test platform for execution, and receives the 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 also 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 the filtered instructions from the request filtering module, and return the 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 use the shared memory to send the instructions required by the test platform to execute the test to the test platform, and receive the 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 the instructions according to any one 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 Instructions obtained from the instruction translator are filtered according to the requirements of the design under test on the test platform for instructions.

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

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 under test 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 instructions for which data is expected to be returned according to an identification code, and in response to receiving data returned by the design under test 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 at least one of the received input / output instructions, model-specific register instructions and special instructions, so as to transmit at least one of the input / 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 channel of the shared memory, wherein the communication channel includes an interrupt transmission channel and a read data channel of a memory instruction, an input / output instruction, and a model-specific register instruction; The transmission module, in response to monitoring the data on the read data channel, acquires the data 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, respectively, so that the test platform concurrently obtains 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 used to exchange 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, hardware fault.

14. The system according to claim 13, wherein: The design to be tested on the test platform is a chip or a 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