CN119201357A

CN119201357A - Computer Systems

Info

Publication number: CN119201357A
Application number: CN202411485103.1A
Authority: CN
Inventors: 李用维; 宋永峰; 丁迎来; 石鑫
Original assignee: Shanghai Zhaoxin Semiconductor Co Ltd
Current assignee: Shanghai Zhaoxin Semiconductor Co Ltd
Priority date: 2024-10-23
Filing date: 2024-10-23
Publication date: 2024-12-27
Anticipated expiration: 2044-10-23
Also published as: CN119201357B

Abstract

The present disclosure relates to a computer system, comprising an emulation virtual machine, which comprises a translator and an instruction executor, wherein the translator translates instructions of the emulation virtual machine into instructions which can be executed by a test platform, the emulation virtual machine transmits the instructions to the test platform by using a shared memory, the instruction translator comprises a CPU simulator, a BIOS and an OS, the simulator receives and transmits the instructions, the instruction translator further comprises a plurality of instruction grabbers which grab corresponding instructions from the simulator, the instruction executor comprises a request filtering module for filtering and distributing various instructions received from the instruction translator, the instructions required by the filtered residual test platform for executing the test are transmitted to a request control module, the request control module transmits the filtered residual instructions to a transmission module, and receives test execution results from the test platform by using the shared memory, and the transmission module transmits the instructions required by the test platform to the test platform.

Description

Computer system

Technical Field

The present disclosure relates to the field of computers, and more particularly to emulation of software and hardware instructions by a computer system.

Background

As the computational power growth demands of the fields of cloud computing, big data, personal computers, etc. on processors are higher and higher, the complexity of the processors becomes higher and higher, and the iteration speed of the required products is higher and higher. Whereas the time to verify a processor product, especially a chip, often takes up more than 70% of the overall chip development time. The traditional verification method performs hardware and software verification respectively in the early and later stages of verification, and the software system verification depends on a hardware simulation system (emulator) which needs expensive board card resources, so that the verification efficiency and quality are low.

Disclosure of Invention

Although the development time of the software and hardware of the computer system is heavy, the field is always lack of full-period cooperative verification of the software and the hardware. How to improve the verification efficiency and quality of the chip, and further shorten the development time of the processor becomes a concern.

In view of this, the present disclosure proposes a computer system comprising a simulation virtual machine unit configured to run a basic input output system, an operating system and application software with the simulation virtual machine unit, the simulation virtual machine unit comprising 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 utilizing a shared memory to send instructions to the test platform for execution and receive test execution results from the test platform, the instruction translator comprising a CPU simulator, the CPU simulator and the basic input output system and receiving and sending the instructions with the operating system, the instruction translator further comprising a plurality of instruction grabbers for grabbing corresponding instructions from the CPU simulator, and the instruction executor comprising a request filtering module, a memory simulator, a request control module and a transmission module, wherein the request filtering module is configured to filter and distribute instructions received from the various types of instruction translators to the test platform and receive test execution results from the test platform, the filtered instructions are configured to filter and interrupt the requested execution instructions from the peripheral control module and the peripheral control module are configured to filter and to the remaining filtered instructions, the request execution module is configured to filter and the requested execution instructions from the peripheral control module is configured to filter and the peripheral, and the transmission module is configured to send the instruction required by the test platform to the test platform by utilizing the shared memory and receive the test execution result of the test platform.

The full instruction grabber and the request filter can achieve at least one of the following effects according to aspects of the present disclosure, namely, universality of a simulation system is greatly improved, hardware resources such as a simulator board on which simulation depends can be reduced, a software and hardware cooperative test can be achieved through interaction of a simulation virtual machine and a test platform, time consumed for chip verification is shortened, and flexible test can be achieved by adjusting instruction filtering rules of a request filtering module and adapting tests of different designs to be tested.

Other features and aspects of the present disclosure will become apparent from the following detailed description of exemplary embodiments, which proceeds with reference to the accompanying drawings.

Drawings

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

FIG. 1 illustrates a schematic block diagram of an emulated virtual machine unit included in a computer system in accordance with an embodiment of the present disclosure.

FIG. 2 is a diagram illustrating a relationship between shared memory and physical memory according to one embodiment of the disclosure.

FIG. 3 illustrates a schematic block diagram of communication between an emulated virtual machine unit and a test platform using a shared memory queue in accordance with an embodiment of the present disclosure.

FIG. 4 illustrates a comparative schematic of non-concurrent simulation versus time taken for concurrent simulation in accordance with an embodiment of the present disclosure.

FIG. 5 illustrates a block diagram of a simulation virtual machine unit tested using a test platform in accordance with an embodiment of the present disclosure.

Fig. 6 shows an illustrative diagram of a test platform structure used in testing in accordance with an embodiment of the present disclosure.

Fig. 7 shows a schematic flow diagram of a test-based native environment quick build hybrid simulation scheme.

Fig. 8 shows a schematic block diagram of a variety of designs under test that may be suitable in accordance with an embodiment of the present disclosure.

Detailed Description

Various exemplary embodiments, features and aspects of the disclosure will be described in detail below with reference to the drawings. In the drawings, like reference numbers indicate identical or functionally similar elements. Although various aspects of the embodiments are illustrated in the accompanying drawings, the drawings are not necessarily drawn to scale unless specifically indicated.

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

In addition, numerous specific details are set forth in the following detailed description in order to provide a better understanding of the present disclosure. It will be understood by those skilled in the art that the present disclosure may be practiced without some of these specific details. In some instances, methods, means, elements, and circuits well known to those skilled in the art have not been described in detail in order not to obscure the present disclosure.

FIG. 1 illustrates a schematic block diagram of an emulated virtual machine unit 100 included in a computer system in accordance with an embodiment of the present disclosure.

The computer system includes an emulated virtual machine unit 100 configured to run a Basic Input Output System (BIOS), an operating system, and application software using the emulated virtual machine unit 100. As shown in fig. 1, the emulation virtual machine unit 100 includes an instruction translator 102 and an instruction executor 104 configured to translate an emulation virtual machine instruction into an instruction that can be executed by a test platform, and the emulation virtual machine unit 100 sends the instruction to the test platform for execution by using a shared memory, and receives a test execution result from the test platform. The instruction translator 102 includes a CPU simulator 1021, the CPU simulator 1021 receiving and transmitting the instructions with a basic input output system and with an operating system, and the instruction translator 102 further includes a plurality of instruction grippers. In one particular implementation, for example, memory instruction fetcher 1022, input Output (IO) instruction fetcher 1023, model Specific Register (MSR) instruction fetcher 1024, special (specialty) instruction fetcher 1025, and interrupt instruction fetcher 1026 may be included for fetching corresponding instructions from 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. Wherein the request filtering module 1042 is configured to filter and distribute various types of instructions (for example, in one specific implementation, may include a memory instruction, an input/output instruction, a model-specific register instruction, a special instruction, and an interrupt instruction), send filtered remaining instructions required for the test platform to execute a 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 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 test execution results from the test platform from the transmission module 1046, and the transmission module 1046 is configured to send the instructions required for the test platform to execute a test to the test platform using a shared memory and receive the test execution results of the test platform.

The inventors first realized that the design under test on the test platform used may be a single module, a subsystem, etc. Because the design under test functions are unitary, not all instructions may be executed, and the instruction sets that different designs under test can execute may also be different. The instruction which 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 result returned by the design to be tested is received, while the instruction which can not be executed by the design to be tested (i.e. the filtered instruction) is executed by the virtual equipment on the simulation virtual machine, so that the universality of the present disclosure is realized, and the virtual equipment on the simulation virtual machine can be default existing on an open source virtual machine such as the simulation virtual machine or the like, and can also be developed by utilizing a simulation virtual machine framework.

The inventor obtains all instructions generated in the software executing process from the traditional virtual machine through research and secondary development, screens out instructions which can be executed by the design to be tested and carries out mixed simulation with the design to be tested. Meanwhile, related virtual equipment is modified or added in the virtual machine, so that filtered instructions which cannot be executed by the design to be tested are executed. Therefore, the system software or the application software can be executed in the simulation virtual machine of the computer system without modification, so that the extra workload in the verification process is reduced, and meanwhile, conditions are created for comparison on different platforms.

Inside the emulation virtual machine unit 100, the CPU simulator 1021 parses the software-generated instructions, and obtains the IO, MSR (model SPECIFIC REGISTER ), and custom instructions by way of embedded source code, and the memory simulator 1047 implements MMU (Memory Management Unit), and obtains memory and MMIO instructions by way of embedded source code. The peripheral simulator 1048 is responsible for simulating the behavior of the respective peripheral devices. The device-related instructions may be obtained by way of embedded source code.

In one possible implementation, the instruction grabbers 1022-1026 may grab instruction codes corresponding to the various types of instructions from the source code according to respective characteristics of different emulation virtual machine instructions.

In one possible implementation, the request filtering module 1042 may filter the instructions obtained from the instruction translator 102 according to the requirements of the Design Under Test (DUT) on the test platform executing the instructions remaining filtered on the memory simulator 1047 and the peripheral simulator 1048 within the emulated virtual machine unit 100.

In one possible implementation, the request filtering module 1042 filters the instructions according to any one of the type of design under test on the test platform, or according to an address range accessed by the instructions, or according to the requirements of the design under test on the test platform for the instructions, and filters the instructions obtained from the instruction translator.

In one possible implementation, the request filtering module 1042 may determine whether the instruction is an instruction required by the design to be tested according to whether the address space corresponds to a memory, a peripheral, or the design to be tested.

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

In one implementation, the request control module 1044 may record an instruction for which data return is desired in terms of an identification code (ID), and in response to receiving the 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 emulated virtual machine unit 100 according to the obtained instruction information.

In one possible implementation, the transmission module 1046 may package at least one of the received input-output instructions, model-specific register instructions, and special instructions to transmit at least one of the input-output instructions, model-specific register instructions, and special instructions in a format (e.g., 3 formats) corresponding to each instruction in one data packet.

In one possible implementation, the transmission module 1046 may snoop the communication channel of the shared memory. The communication channels may include interrupt transfer channels, memory instructions, input output instructions, and read data channels of model specific register instructions.

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

For another example, the transmission module 1046 also reports interrupts to an interrupt instruction fetcher 1026 in the instruction translator 102 in response to listening for interrupts on the interrupt transmission channel.

One of the features of an embodiment of the present disclosure is that full instruction emulation is achieved. It should be noted that the peripheral simulated by the peripheral simulator 1048 may be different according to different simulation requirements, and only schematic description is given here. In the peripheral simulator 1048, the existing common peripherals emulating a virtual machine, such as a USB radio data recorder (USDR), may be utilized, and other peripheral devices may also be developed by themselves. In one specific implementation, the processing of the corresponding instructions may be performed in the CPU simulator 1021, the memory simulator 1047, and the peripheral simulator 1048 in the emulated virtual machine.

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

The inventors have further developed, relative to the prior art, at least the following components/functions, fetch, request filter module, interrupt handling, request control module, transfer module, and corresponding shared memory communication protocol for each type of instruction in the full instruction set. The functions of the above-described components/modules are described in detail below, for example, according to an embodiment of the present disclosure.

1) Virtual machine part

In one specific implementation of an embodiment of the present disclosure, a basic input output system, an operating system, and application software are run on a emulated virtual machine. These software runs in virtual machines to generate a wide variety of virtual machine instructions, including the various instructions in the table above.

2) Instruction translator for emulating virtual machine

The instruction translator may translate various types of virtual machine instructions into instructions that the host may execute. In this process, each class of instruction may be respectively fetched by a fetcher (gripper) into the above table, specifically the following table:

In one particular implementation, each instruction fetcher fetches corresponding instructions according to, for example, respective characteristics of virtual machine instructions. For example, for a memory instruction fetcher, it may precisely intercept forwarding from code to fetch memory instructions based on memory management in a memory simulator. It should be noted that the concept of grabbing various types of instructions in an emulated virtual machine has never been proposed in the art, and is not readily apparent to those skilled in the art at the implementation level, but rather requires a very thorough understanding of the emulated virtual machine architecture and virtual machine code implementation level.

3) Instruction executor

After the QEMU has completed instruction translation, the instruction can be executed. When executing the instructions required by the grabbed test platform, various instructions can be processed in the following table manner:

In one embodiment, when the input/output instruction, the model-specific register instruction, and the special instruction required by the test platform are sent to the request control module, formats corresponding to the three instructions may be defined, and the instructions may be packaged by the transmission module of the instruction executor, so that the three instructions may be transmitted in three formats in, for example, one data packet.

Additionally, as shown, the instruction translator of one embodiment of the present disclosure may include an interrupt instruction fetcher. The interrupt instruction grabber can monitor whether the request control module has an interrupt or not in real time, if so, the interrupt instruction grabber reports the interrupt to the interrupt module of the simulation virtual machine, and then informs the CPU to execute the interrupt.

4) Request filtering module

The request filtering module is used for filtering and distributing each instruction which is captured and sent by the instruction capture device. Specifically, the request filtering module may filter out the instruction to be executed by the design to be tested, send the instruction to the request control module, filter out the instruction executed by the inside of the emulation virtual machine, and distribute the instruction to one of the memory simulator and the peripheral simulator according to the type of the instruction.

Specifically, the memory instruction can be divided into two types, namely a memory instruction for accessing the memory, wherein the type of the memory instruction is filtered by the request filtering module and then sent to the memory simulator, and the other type of the memory instruction is used for accessing the peripheral equipment and is subjected to Memory Management Input Output (MMIO) and then sent to the peripheral equipment simulator. In actual test, when some memory instructions accessing the memory need to pass through the design to be tested, the instructions need to be filtered by the request filtering module and then sent to the design to be tested through the request control module and the transmission module, while other memory instructions accessing the memory which do not need to pass through the design to be tested are filtered by the request filtering module and then sent to the memory simulator. Similarly, when some MMIO needs to pass through the design test to be tested, the part of instructions need to be filtered by the request filtering module and then sent to the design to be tested through the request control module and the transmission module, and other MMIO which does not need to pass through the design test to be tested are filtered by the request filtering module and then sent to the peripheral simulator for execution. The above only specifically illustrates the screening simulation of the memory instruction, and the screening principle is the same for the IO instruction, the MSR instruction, the specific instruction, and the custom instruction, and when one or more specific instructions in these types need to pass the design test to be tested, the specific instructions 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, and the specific instructions that do not need to pass the design test to be tested are sent to the peripheral simulator.

5) Request control module

The request control module controls the transmission module to forward the instruction so as to execute the instruction in the design to be tested on the test platform. In one particular implementation, execution result data may be read from a design under test on a test platform. The request control module waits for the transmission module to acquire real execution result data from the design to be tested, and backfills the execution result data to the instruction executor of the simulation virtual machine, as if the instruction is processed and executed by the instruction executor of the simulation virtual machine.

In one particular implementation, the request control module may perform at least one of the following:

The transmission module is invoked to send the data packets to the test platform.

For instructions where data return is desired, such as memory reads, such instructions are recorded. After receiving the data returned by the transmission module, the instruction information is acquired from the record according to the ID, the data of the instruction is returned to the CPU simulator, and the CPU returns to the corresponding instruction sender (BIOS or operating system).

The method can monitor whether the transmission module has an interrupt or not in real time, if so, report the interrupt to an interrupt handler in the instruction translator, and then inform the CPU simulator to execute the interrupt.

6) Transmission module

And the different transmission channels are used for packaging the instructions and sending the instructions to the shared memory queues according to the types.

Several channels (shared memory queues) for monitoring the test platform to send data to the emulated virtual machine include monitoring memory/IO/MSR read data channels, if memory/IO/MSR read data are first uniformly sent to the request control module, the request control module sends the data to different objects according to different sources of read requests, if the source of the read request is the cached memory read data, the request is sent to the cache, if the source of the read request is the cached memory read data, the request is sent to the CPU, if the source of the read request is the memory read, IO read and MSR read data of the CPU, the transmission module also monitors interrupt transmission channels, and if interrupts (including interrupts such as Advanced Programmable Interrupt Controller (APIC), system Management Interrupt (SMI), non-mask interrupt (NMI) and the like) are sent to an interrupt instruction grabber in the instruction translator.

7) Shared memory

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

FIG. 2 is a diagram illustrating a relationship between shared memory and physical memory 200 according to one embodiment of the disclosure. As shown in fig. 2, a shared memory space is provided between the memory space occupied by the emulated virtual machine process and the test platform process in the physical memory 200. By sharing the memory, the simulation virtual machine process and the test platform process can share and use the same section of physical memory. All communication may be accomplished by reading from and writing to shared memory. The method for directly accessing the memory has the characteristics of high speed, high reliability and strong real-time performance. Requests and data for the emulated virtual machine unit 100 can be quickly passed into the test platform. The data of the design to be tested in the test platform can also be quickly transferred to the emulation virtual machine unit 100.

FIG. 3 illustrates a schematic block diagram of communication between an emulated virtual machine unit and a test platform using a shared memory queue in accordance with an embodiment of the present disclosure. In one particular implementation, the green portion of FIG. 3 may run a fast emulation virtual machine process (QEMU process).

As shown in fig. 3, the independent queue can be implemented in the shared memory to independently and parallelly transmit different types of instructions and data in the simulation based on the shared memory process communication technology. In one specific implementation, the instructions or data sent by the simulation virtual machine to the test platform are transferred through the downlink queue, and the instructions or data sent by the test platform to the simulation virtual machine are transferred through the uplink queue.

In one implementation, the shared memory may be allocated space on physical memory by the operating system, and this portion of the physical memory space is shared by the emulated virtual machine process and the test platform process. Therefore, the test platform can directly acquire the instruction sent by the simulation virtual machine from the shared memory, just like the test platform accesses the queue of the test platform. Similarly, the emulation virtual machine obtains different types of instructions or data sent by the test platform to the emulation virtual machine just like directly obtaining the instructions or data from the queue of the emulation virtual machine. The method has the advantages that at least one of 1) the simulation speed is high, because the shared memory speed is the fastest in all process communication speed, 2) the communication is reliable, because the information is directly controlled and transmitted in the memory, the problems of packet loss, data errors and the like do not occur generally, 3) the simulation virtual machine and the test platform are low in coupling, the simulation virtual machine and the test platform only need to operate queues and do not care about the implementation mechanism of the other party, 4) the data conversion is reduced, the data packets of the simulation virtual machine and the test platform can be directly used without protocol conversion, 5) the method is simple to use and high in expandability and can be packaged into an Application Program Interface (API), and 6) the method has the characteristic of high concurrency, and is specifically described below.

In one possible implementation of an embodiment of the present disclosure, an emulated virtual machine process and a test platform process share a physical memory of a 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, respectively, so that the test platform can obtain the instructions or data from the queues concurrently.

In one 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 including sideband information for information exchange between the emulated virtual machine unit 100 and the test platform, the sideband information being set by the emulated virtual machine unit 100 at initialization and being usable when transmitting the interrupt instruction.

For example, the shared memory header may include the number and description information of the communication channels with the test platform set by the emulated virtual machine unit 100 at the time of initialization, so that the test platform can bind the communication channels created by the emulated virtual machine unit 100 according to the number and the description information.

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

1) Shared memory header (header)

The shared memory header may store some state information for use in emulating the communication state between the virtual machine and the emulator or the test platform of the emulator, the number of transport channels and description information, and for exchanging information with some of the sidebands. The shared memory header may be completed by the emulated virtual machine settings at initialization. In one embodiment, the setting may include creating a shared memory, filling out the number of transmission channels, description information, and side information. After the shared memory header information is set, the set information is known to the simulation virtual machine and the test platform process. Wherein the side information is used, for example, when the user transmits an interrupt signal.

In one embodiment, the emulation virtual machine, when creating a transport channel, adds 1 to the number of transport channels in the header and adds description information of the newly created transport channel to the header every time a transport channel is created. Before the test platform process communicates with the simulation virtual machine, the number and description information of the transmission channels are acquired through header information, and the transmission channels created by the simulation virtual machine are bound according to the information. Thus, communication between the emulation virtual machine and the test platform can be performed through transmission signals.

Example code for the shared memory header is as follows.

The meaning of each field is as follows:

2) Shared memory queue element

Through the shared memory queue as a communication channel. The C/C++ structure is used as the basic element of the shared memory queue transfer, and the information type of the channel transfer is customized because the elements in the structure can be customized. For example, the following is a structure definition used for memory read or write request delivery:

in one particular implementation, the shared memory queue may be implemented in, for example, three structures, multi-threaded send multi-threaded receive, multi-threaded send single-threaded receive, single-threaded send single-threaded receive.

In accordance with an embodiment of the present disclosure, a shared memory queue communication protocol was developed to enable concurrent transmission and high-speed emulation of instructions and data between the emulated virtual machine unit 100 and a test platform.

The high concurrency principle is shown in fig. 4, where fig. 4 (a) shows a conventional non-concurrency simulation mode, and different types of requests are in the same queue. Thus, the requests at the front of the queue may be blocked from processing until the requests at the back are processed, and the example in (a) takes a total of 6 clock cycles to emulate the end, which is a serial fashion. While fig. 4 (b) shows a concurrent simulation manner of the present disclosure, where different types of requests are respectively placed in separate queues, instructions may be concurrently fetched from the queues for simulation without blocking each other. In the specific example of (b), it eventually takes only 3 clock cycles to process to completion. Therefore, the shared memory can meet the time sequence requirement of the design to be tested, so that different types of requests can be synchronously processed at the design to be tested side.

FIG. 5 illustrates a block diagram of a simulation virtual machine unit tested using a test platform in accordance with an embodiment of the present disclosure. As shown in fig. 5, the Top layer, or Top layer, is instantiated in order to run the sub-modules of the DUT (DUT, cosi adapter, DPI interface configuration information, etc.) and connection relationship information between the sub-modules on the test platform 504. Fig. 5 shows a top-down built hybrid simulation scheme. The emulated virtual machine unit 502 may be an open-source virtual machine. In one particular implementation, a Quick emulators virtual machine (QEMU) may be employed. The emulated virtual machine unit 502 is capable of running the same Basic Input Output System (BIOS), operating system, and application software as a real machine.

The emulation virtual machine unit 502 can provide a platform on which software can directly execute, obtain various instructions generated during the running of the software to interact with the design to be tested on the test platform (testbench), and simulate the required peripheral equipment so that the software can be smoothly executed with little additional adaptation.

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

A Direct Programming Interface (DPI) on the test platform may interact directly with the shared memory queue. In one embodiment, the test platform may perform a collaborative simulation (COSIM) based verification, using a direct programming interface to convert instructions or data into interface timing signals through a collaborative simulation adapter to connect to a design under test. At the top layer of the test platform, various sub-modules (such as design to be tested, COSIM adapter, direct programming interface configuration information, etc.) and connection relationship information among the sub-modules can be instantiated for running the design to be tested.

The software verified by the test platform can be at least part of application software, a basic input and output system and an operating system running on the virtual machine, and the verified hardware can be a design to be tested generated after simulation, such as a verilog file compiled by a hardware programming language. And the design to be tested is tested in cooperation with the software.

According to one specific implementation of the present disclosure, when a test platform of a computer system is built, the top layer of the test environment can be built from scratch for the design under test, the design under test is instantiated and initialized, and finally connected to a simulation virtual machine unit to complete, for example, a collaborative simulation COSIM environment. The method for constructing the head has the advantages that some unused modules can be removed, so that the test environment is more concise, and consumption or occupation of simulator or simulator resources is reduced.

According to one embodiment of the present disclosure, a hybrid simulation scheme based on the present disclosure may be quickly built based on the original environment of the simulation test. The native environment may refer to a native verification environment of a test platform previously built by a verification team. When a collaborative simulation COSIM platform is built in the follow-up process, for example, the part for initializing the to-be-tested design in the original environment can be inherited, so that the development time of the COSIM test environment is shortened.

Fig. 6 shows a scheme for quickly constructing a hybrid simulation based on an original environment. The left side is the same as the left side part of fig. 1, a signal switcher is added on the right side on the basis of the original environment, and a configuration completion (cfg done) signal is 0 in the period from the start of simulation to the end of environment initialization, and the signal switcher is communicated with the original peripheral environment to initialize the DUT. After the environment initialization is finished, the cfg done signal is 1, and the signal switcher is communicated COSIM with the adapter to perform subsequent mixed simulation. The method for switching the signals fully utilizes the original complex initialization logic of the environment, places key work on the hybrid simulation body, reduces extra debug work, shortens the time for constructing the COSIM environment and simultaneously ensures the stability of the environment. The method is suitable for quickly constructing COSIM environments, is a methodology, and can be widely applied to various systems.

Fig. 7 shows a schematic flow chart of a quick set up hybrid simulation scheme based on the original environment of the test, illustrating the flow of this method.

In one particular implementation of embodiments of the present disclosure, a test platform may provide a simulated verification environment that includes a design under test. According to the present disclosure, any operating system such as Windows, linux may be run, any open-source or closed-source application software may be executed, and no modification to the software emulating the virtual machine is required. The embodiment of the invention has at least two characteristics of 1) universality, namely, the method can be used for constructing a co-simulation (co-simulation) system by simulating a virtual machine and a simulator, and can also be used for constructing a co-simulation (co-simulation) system by simulating the virtual machine and the simulator, and 2) full-system simulation, and software can be switched to run on various test platforms without modification, so that the method has the advantages of comparison verification in methodology, and can increase debugging means and flexibility, and further improve simulation verification efficiency.

Fig. 8 shows a schematic block diagram of a variety of designs under test that may be suitable in accordance with an embodiment of the present disclosure. The following table summarizes the several systems described above:

how the comparative verification is performed is described below:

● When a software system (including application software, BIOS, OS, also shown in FIG. 1) is run in the post-silicon verification or production system of the lower right hand diagram of FIG. 8, the system fails (bug), which may be either a software bug or a hardware bug. Since system debug is generally difficult after silicon, the same software system can be run directly across the platform for bug reproduction in the system shown in the bottom left and top right of FIG. 8. When the system in the lower left diagram of fig. 8 is in a recurring problem, various debugging (debug) means including waveforms, logs, debug tools, etc. as described above can be utilized to determine whether the software bug or the hardware bug is first, if the software bug is determined to be a software bug, then in coordination with a software development team, the system in the lower left diagram of fig. 8 is utilized to further debug the problem, such as adding logs (logs), utilizing gdb tool debugging, etc. to determine the problem, and finally the software development team solves the problem. If the determination is a hardware bug, the system in the lower left diagram of FIG. 8 is utilized to further debug the problem, such as by adding log, waveform and the like, in cooperation with the hardware development team, and finally the problem is solved by the hardware development team. Because of the various rich debug approaches described above in the lower left diagram of FIG. 8, there is a great help to help locate and solve the problem.

● When the problem is encountered in the upper right diagram of fig. 8, the same software system can be reproduced and solved in the system shown in the lower left diagram of fig. 8 in a cross-platform manner, and the lower left diagram of fig. 8 has the advantages that 1) emulator resources are occupied less, and 2) the debug means are richer than those of the upper right diagram of fig. 8.

● In one particular implementation of contrast verification, when a problem is determined or suspected to be caused by a particular module or small-scale subsystem, then a collaborative simulation COSIM system as shown in the upper left-hand diagram may be constructed. The collaborative simulation system of the simulation simulator and the simulator building module or the small-scale subsystem is utilized, so that the software system which is the same as the software system to be debugged and has problems can be operated in the COSIM system in a cross-platform manner under the condition of not occupying the expensive board card resource of the simulator emulator, and the problems are positioned and solved by using abundant positioning means in the debugging process.

● The multiple platforms perform debug together, are not limited by the interference of specific factors on one platform, and provide more possibility for debug. For example, waveform, log, etc. information comparison can be performed, virtual equipment of the QEMU is utilized to replace a module in the DUT for comparison operation, waveform and log are analyzed, and problems are helped to be determined.

After the problems are clear, the problems are fed back to a software team and a hardware team to carry out the modification of the problems, and the smooth progress of product research and development is ensured.

In one possible implementation, a test platform may communicate with the emulated virtual machine unit 100 through a shared memory, run the same software system in the test platform as the software system to be debugged that failed to perform a failure recovery, and determine the type of the failure using a debug tool in response to the test platform recovering from the failure. For example, the fault types may include software faults, hardware faults, and the like.

In one specific implementation, the design under test on the test platform may be a chip (full chip) or a subsystem-level device, and in response to a failure of the chip or subsystem-level device when running the software system under test on the test platform, the design under test is changed to a smaller-scale subsystem-level device or module-level device, and the same software system as the failed software system under test is run in the smaller-scale subsystem-level device or module-level device for failure-recurrence debugging.

In one possible implementation, a test platform includes a signal switcher connected to a design under test that connects the design under test to an original environment of the test platform to initialize the design under test from a start of testing until an environment initialization of the test platform is completed.

Hybrid simulations may be performed on various designs under test, such as a Dynamic Random Access Memory Controller (DRAMC) module, a Peripheral Component Interconnect Express (PCIE) module, a chip interconnect subsystem, or an input-output Die (IO Die) system as a larger unit, etc., according to an embodiment of the present disclosure.

As a specific application example, the whole verification process will be described below by taking one software verification and one hardware verification of the processor chip as examples.

Taking DRAMC (DRAM controller) verification as an example, the flow may include the following steps:

S1, developing DRAMC DESIGN a basic version of release by a hardware design team.

S2, the hardware verification team builds a verification environment based on the version of the design team release, and the release is an operable basic version

And S3, COSIM, building a simulation virtual machine-DRAMC co-simulation or co-simulation environment based on a verification environment of a hardware verification team release, and performing software verification and software and hardware interaction verification.

S4, when the problem is found, the problem needs to be located. The (dump) waveform or output log may be grasped at the DUT side. In one particular implementation, the test platform may run in an EDA vendor's tool, which is commonly provided by EDA vendors. The simulation virtual machine side can check the executed request and the acquired data through outputting log (comprising the information printed by the software and the request and the data interacted by the software and the simulation virtual machine), and can also perform problem positioning through a GDBgnu open source debugger/debugging tool dynamic acquisition mode, a current program execution state viewing variable value mode and the like. The debug information generated by the DUT, the emulation virtual machine and the communication channel can be combined to locate the problem. For example, if the correct configuration of the register, which is the DRAMC, is found by waveform inspection, the correct configuration request is sent by the software through log of the transmission channel, and if the software is sent correctly, the positioning problem may be in the DUT, and the design team is required to check the waveform and design. If the software is not issued correctly, the positioning problem may occur at one side of the software, and a software development team is required to debug by simulating log output by the virtual machine or using gdb and other tools, so that the problem is solved finally.

And S5, the hardware verification team discovers design bug, reports the design bug to the hardware design team, synchronously updates the verification environment, and carries out regression verification on the COSIM team update COSIM environment.

And S6, the COSIM team discovers the design bug, reports the design bug to a hardware verification team and a hardware design team for confirmation, and then the hardware design team modifies the bug and gives COSIM team and the hardware verification team regression verification.

And S7, the COSIM team discovers the software bug, submits the software bug to a software development team to determine and debug the problem, and then the COSIM team performs regression verification.

S8, S5-S7 are carried out simultaneously, and the steps are carried out continuously until the software and design meet the verification requirement.

In general, the application scenario of the present disclosure may include at least one of:

And v software is developed and verified in advance.

The hardware performs software verification or system level verification in advance.

And performing software and hardware joint debugging in advance, including system software bring up and the like.

And performing software and hardware performance analysis and tuning.

And (3) comparing and verifying to debug the internal problems of the chip.

In actual testing, using the conventional test mode, the 8 core devices need to consume 12 emulator boards, and the 1 core device needs to consume 5 emulator boards. In contrast, according to the test mode of the embodiment of the disclosure, only 2 simulator boards are consumed for the 8-core and 1-core device test, so that the resource consumption is obviously reduced, and the verification efficiency is improved. Because the computer system provided by the aspects of the disclosure is used for the universality of simulation, the software mixed simulation and collaborative simulation (co-simulation), hardware mixed simulation and collaborative simulation (co-simulation) of different modules, subsystems and system levels can be performed at each stage of chip verification, especially at an early stage, and the software can be allowed to be compared and verified with full chip simulation (full chip emulation) and silicon chip (silicon) simulation without any modification, so that the verification efficiency and quality are improved, and the product marketing time is facilitated to be shortened.

The general full instruction software and hardware mixing method provided by the disclosure has the universality that software level/system level verification can be carried out on any module, subsystem and system by utilizing an operating system such as Windows, linux and the like, BIOS and application software without modification in each stage of a chip research and development period. The full instruction is mainly characterized in that any instruction generated by software in the system is acquired and transmitted to the design to be tested through a protocol for verification. The shared memory queue communication protocol has the characteristics of strong concurrency capability, high simulation speed, low coupling, reliable communication, reduced data conversion, simple use and strong expandability. The method can be widely applied to software and hardware collaborative parallel verification of different levels and different stages of each project, particularly advanced verification and software system verification, is an extension of verification methodology, and can improve verification efficiency and quality.

The foregoing description of the embodiments of the present disclosure has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the various embodiments described. The terminology used herein was chosen in order to best explain the principles of the embodiments, the practical application, or the technical improvements in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A computer system comprising an emulated virtual machine unit configured to run a basic input output system, an operating system, and application software using the emulated virtual machine unit, characterized in that,

The simulation virtual machine unit comprises an instruction translator and an instruction executor, wherein the instruction translator and the instruction executor are configured to translate simulation virtual machine instructions into instructions which can be executed by the test platform, and the simulation virtual machine unit sends the instructions to the test platform to be executed by utilizing a shared memory and receives test execution results from the test platform;

The instruction translator includes a CPU simulator that receives and transmits the instructions with the basic input output system and with the operating system,

The instruction translator further includes a plurality of instruction grippers for gripping corresponding instructions from the CPU simulator, and

The instruction executor comprises 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 instructions required by the filtered residual test platform to execute a test to the request control module, wherein the filtered residual instructions comprise 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 test execution results from the test platform from the transmission module, and

The transmission module is configured to send instructions required by the test platform to the test platform by using the shared memory, and receive test execution results of the test platform.

2. The system of claim 1, wherein each of the instruction grippers comprises a memory instruction gripper, an input-output instruction gripper, a model-specific register instruction gripper, a special instruction gripper, and an interrupt instruction gripper;

The instructions of various types comprise a memory instruction, an input-output instruction, a model special register instruction, a special instruction and an interrupt instruction.

3. The system of claim 1, wherein each of the instruction grippers grips instruction code corresponding to each of the instruction grippers according to a respective characteristic of an emulated virtual machine instruction.

4. The system of claim 1, wherein the request filtering module filters instructions according to any one of:

filtering instructions according to the type of the design to be tested on the test platform, or

Filtering instructions according to address intervals accessed by the instructions, or

And filtering the instruction obtained from the instruction translator according to the requirements of the design to be tested on the test platform on the instruction.

5. The system of claim 4, wherein the request filtering module determines whether the instruction is a required instruction for the design under test based on whether the address space corresponds to a memory, a peripheral, or a design under test.

6. The system of claim 1, wherein the request control module encodes, tracks and flow controls the instructions that remain filtered, and backfills data returned to the shared memory from the design under test on the test platform to the emulated virtual machine unit, and from the emulated virtual machine unit back to the basic input output system or operating system that issued the instructions.

7. The system of claim 6, wherein the request control module records instructions for which data return is expected in an identification code, and in response to receiving the data returned by the design under test from the transmission module, obtains instruction information from the records according to the identification code, and sends the returned data to the CPU simulator in the emulated virtual machine unit according to the obtained instruction information.

8. The system of claim 2, wherein the transmission module packages the received at least one of the input-output instructions, the model-specific register instructions, and the special instructions such that the at least one of the input-output instructions, the model-specific register instructions, and the special instructions are transmitted in a data packet in a format corresponding to each instruction.

9. The system of claim 1, wherein the transport module listens to a communication channel of the shared memory, the communication channel comprising an interrupt transport channel and a read data channel of memory instructions, input output instructions, and model specific register instructions;

The transmission module is used for responding to the data on the read data channel, acquiring the data and sending 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 interrupts to an interrupt instruction fetcher in the instruction translator in response to monitoring interrupts on the interrupt transmission channel.

10. The system of claim 1, wherein the emulated virtual machine process and test platform process share physical memory of the computer system through a shared memory queue communication protocol,

And the transmission module respectively places different types of instructions or data into different shared memory queues, so that the test platform acquires the instructions or data from the queues concurrently.

11. The system of claim 10, wherein the message format of the shared memory queue communication protocol includes a shared memory header including sideband information for information exchange between the emulated virtual machine unit and the test platform, the sideband information being set by the emulated virtual machine unit upon initialization and used upon transmission of the interrupt instruction.

12. The system of claim 11, wherein the shared memory header includes a number and description information of communication channels with the test platform set by the emulated virtual machine unit at initialization, such that the test platform binds the communication channels created by the emulated virtual machine unit according to the number and the description information.

13. The system of claim 1, wherein the test platform communicates with the emulated virtual machine unit via a shared memory, runs the same software system in the test platform as the failed software system to be debugged for failure recovery, and determines a failure type of the failure using debug means in response to the test platform recovering from the failure, wherein the failure type comprises a software failure, a hardware failure.

14. The system of claim 13, wherein the design under test on the test platform is a chip or subsystem level device, the design under test is changed to a smaller scale subsystem level device or module level device in response to a failure of the chip or subsystem level device when the software system under debug is running on the test platform, and the same software system as the failed software system under debug is run in the smaller scale subsystem level device or module level device for failure-recurring debugging.

15. The system of claim 1, wherein the test platform includes a signal switcher connected to a design under test, the signal switcher connecting the design under test to an original environment of the test platform to initialize the design under test from a start of a test until an environment initialization of the test platform is completed.