Task processing method and device based on chip monitoring system, medium and equipment

Abstract

The application provides a task processing method and device based on a chip monitoring system, a medium and equipment. The method comprises the following steps: deploying a back-end device and a corresponding front-end driver conforming to a Virtio standard in the chip monitoring system; in an initialization stage, configuring corresponding functional characteristics for the back-end device according to an application scenario by the firmware of the back-end device, and performing a characteristic negotiation process based on the functional characteristics by the front-end driver, so that front-end drivers and back-end devices of different versions are compatible with each other; in response to completing the characteristic negotiation and the front-end driver receiving a task request sent by a protocol adaptation layer in the chip monitoring system, writing the task request into a request queue; reading the task request from the request queue by the back-end device, and executing a corresponding task, and writing a task execution result into a response queue; reading the task execution result from the response queue by the front-end driver, and forwarding the task execution result to the protocol adaptation layer for processing. The application improves the portability and data transmission performance of the chip monitoring system.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of chips, and in particular to a task processing method and device based on a chip monitoring system, a medium and equipment. BACKGROUND

[0002] Virtio is a standard for implementing a simulated device supporting semi-virtualization technology. Compared with a simulated device implemented based on full-virtualization technology, the number of context switches between a virtual machine and a host hypervisor (a management tool software for a virtual machine, also known as a virtual machine monitor), the length of an input / output instruction path, memory copying and the like are reduced, so that the simulated device based on the Virtio standard has higher performance and stronger portability / expandability.

[0003] With the increasing demand for chip localization replacement, a large number of chip design companies have emerged in the market. However, chip research and development is difficult and has a long cycle. In order to improve the efficiency of chip research and development, researchers have designed many chip software and hardware monitoring systems, so that problems encountered in the chip development process can be quickly discovered and effectively solved. The current common chip monitoring system design method is as follows: the system is divided into two parts of monitoring chip hardware / firmware state, and the device driver monitors the chip hardware state by reading the chip state register interface. The device firmware is notified by configuring the chip register, and then the execution state thereof is sent to the driver by the firmware through a DMA (Direct Memory Access) or the like, so as to monitor the chip firmware state.

[0004] This approach can effectively design a chip monitoring system, but still has the following problems:

[0005] 1) Poor portability. Since the device driver software depends on the device hardware register interface to obtain the hardware or firmware running state, the device driver software and the hardware register interface are coupled with each other, and any change in the hardware register interface needs to be correspondingly modified in the device driver software, resulting in poor portability of the device driver software between different hardware versions.

[0006] 2) Poor expandability. Since the device driver software and the hardware register interface are coupled with each other, when a new hardware register interface is added, the device driver software interface needs to be correspondingly increased, resulting in that the software and hardware interfaces cannot be independently upgraded and expanded with new functions.

[0007] 3) More version maintenance work. Different versions of device drivers and different versions of device hardware cannot coexist, and the developer needs to maintain the correspondence between the device driver version and the device hardware version, which will cause a huge version maintenance workload when there are many device driver versions and device hardware versions.

[0008] 4) Physical hardware performance is low. When the system hardware is a chip design prototype verification platform before tape-out or a real hardware device with chip packaging after tape-out, the device driver can only read the hardware state register in a synchronous manner or notify the firmware and wait for the firmware to return its return state information. The synchronous transmission mechanism makes the system data transmission performance low.

[0009] 5) Analog hardware performance is also low. When the system hardware is a virtualization platform simulating chip behavior before tape-out, the analog hardware performance is low due to the full virtualization technology of the analog hardware, that is, executing a device input / output instruction causes too many hypervisor context switches, too long instruction path length, too much memory copying, and other problems.

[0010] 6) High cost. When the system hardware is a physical hardware device, the performance can only be improved by increasing the hardware register interface, which increases the chip hardware cost. Even if a virtualization platform simulates the device, the development cost of the simulated device is also increased.

[0011] The above problems hinder the task processing in the chip monitoring system. SUMMARY

[0012] Therefore, the purpose of the present application is to provide a chip monitoring system-based task processing method, device, medium, and equipment to solve the problems of poor portability, poor scalability, more maintenance work, low physical hardware performance, low analog hardware performance, and high cost in the prior art chip monitoring system when processing tasks.

[0013] To achieve the above purpose, the present application provides a chip monitoring system-based task processing method, which comprises the following steps:

[0014] Deploying a back-end device conforming to the Virtio standard and a corresponding front-end driver in the chip monitoring system;

[0015] In the initialization stage, the firmware of the back-end device configures the corresponding functional characteristics for the back-end device according to the application scenario, and the front-end driver performs a characteristic negotiation process based on the functional characteristics to make different versions of the front-end driver and the back-end device compatible with each other;

[0016] In response to completing the characteristic negotiation and the front-end driver receiving a task request sent by a protocol adaptation layer in the chip monitoring system, the task request is written into a request queue;

[0017] The back-end device reads the task request from the request queue and executes the corresponding task, and writes the task execution result into a response queue;

[0018] The task execution result is read from the response queue by the front-end driver, and the task execution result is forwarded to the protocol adaptation layer for processing.

[0019] In some embodiments, the method further comprises:

[0020] In response to the task request being a monitoring command input by the user, the task execution result is an execution result of the monitoring command;

[0021] In response to the task request being idle buffer information, the task execution result is hardware state or firmware log information of the back-end device;

[0022] In response to the task request being a queue configuration request, the task execution result is a queue configuration request processing result.

[0023] In some embodiments, the method further comprises:

[0024] In the initialization phase, the request queue and the corresponding response queue are created by the front-end driver, and the write request queue thread and the read response queue thread are created, and the read request queue thread and the write response queue thread are created by the back-end device.

[0025] In some embodiments, the chip monitoring system further comprises a display layer and a cloud platform layer;

[0026] The display layer comprises a user operation interface of the chip monitoring system and monitoring tools of various interface protocols, and is configured to transmit the task request to the protocol adaptation layer and receive the task execution result from the protocol adaptation layer;

[0027] The cloud platform layer provides virtual services for testing computing resources and storage resources of the back-end device.

[0028] In some embodiments, the protocol adaptation layer comprises an adaptation module of various interface protocols, and is configured to strip the task request after the protocol message header and tail, and forward it to the front-end driver, and add the task execution result returned by the front-end driver to the protocol message header and tail, and forward it to the monitoring tools of the display layer.

[0029] In some embodiments, the task execution result is read from the response queue by the front-end driver, and the task execution result is forwarded to the protocol adaptation layer for processing.

[0030] The task execution result is read from the response queue by the front-end driver based on the interrupt vector configured in the initialization phase.

[0031] In some embodiments, the back-end device comprises a hardware device simulating chip behavior, a chip design prototype verification platform for running chip hardware code, and a hardware device with a chip package after being taped out.

[0032] Another aspect of the present application also provides a task processing device based on a chip monitoring system, comprising:

[0033] a deployment module configured to deploy a backend device conforming to a Virtio standard and a corresponding frontend driver in a chip monitoring system;

[0034] a function feature module configured to, in an initialization stage, configure a corresponding function feature for the backend device according to an application scenario by firmware of the backend device, and perform a feature negotiation process based on the function feature by the frontend driver, so as to make different versions of the frontend driver and the backend device compatible with each other;

[0035] a write module configured to, in response to completion of the feature negotiation and reception of a task request sent by a protocol adaptation layer in the chip monitoring system by the frontend driver, write the task request into a request queue;

[0036] a read-write module configured to, after reading the task request from the request queue by the backend device, execute a corresponding task, and write a task execution result into a response queue; and

[0037] a read module configured to, read the task execution result from the response queue by the frontend driver, and forward the task execution result to the protocol adaptation layer for processing.

[0038] Still another aspect of the present application provides a computer readable storage medium storing computer program instructions, which, when executed by a processor, implement the above method.

[0039] Still another aspect of the present application provides a computer device comprising a memory and a processor, the memory storing a computer program, which, when executed by the processor, implements the above method.

[0040] The present application has at least the following beneficial technical effects:

[0041] The present application designs a chip monitoring system based on a Virtio standard, and designs the system to comprise a frontend driver layer and a backend device layer, thereby reducing interface coupling between the frontend driver and the backend device by using the Virtio standard, so that the two can be independently upgraded and perform feature negotiation, improving portability, expandability and data transmission performance of the chip monitoring system, and reducing version maintenance work and cost; by designing a protocol adaptation layer in the chip monitoring system, a user can input a task request using a conventional standardized debugging tool, improving interactive effect. BRIEF DESCRIPTION OF DRAWINGS

[0042] In order to make the technical solutions of the embodiments of the present application or the prior art clearer, the accompanying drawings needed in the embodiments or prior art description will be briefly introduced. Obviously, the accompanying drawings in the following description only constitute some embodiments of the present application, and for those skilled in the art, other embodiments can be obtained from the accompanying drawings without creative effort.

[0043] Figure 1 A schematic diagram of a task processing method based on a chip monitoring system according to an embodiment of the present application is provided.

[0044] Figure 2 A structural schematic diagram of a chip monitoring system based on a Virtio standard according to an embodiment of the present application is provided.

[0045] Figure 3 A structural schematic diagram of task processing of a Virtio front-end driver and a Virtio back-end device according to an embodiment of the present application is provided.

[0046] Figure 4 A schematic diagram of a task processing device based on a chip monitoring system according to an embodiment of the present application is provided.

[0047] Figure 5 A schematic diagram of a computer readable storage medium for implementing a task processing method based on a chip monitoring system according to an embodiment of the present application is provided.

[0048] Figure 6 A hardware structural schematic diagram of a computer device for executing a task processing method based on a chip monitoring system according to an embodiment of the present application is provided. DETAILED DESCRIPTION

[0049] In order to make the technical solutions of the embodiments of the present application or the prior art clearer, the accompanying drawings needed in the embodiments or prior art description will be briefly introduced. Obviously, the accompanying drawings in the following description only constitute some embodiments of the present application, and for those skilled in the art, other embodiments can be obtained from the accompanying drawings without creative effort.

[0050] It should be noted that all the expressions of "first" and "second" in the embodiments of the present application are used to distinguish two same name non-same entities or non-same parameters, and it can be seen that "first" and "second" are only used for the convenience of description, and should not be understood as the limitation of the embodiments of the present application. In addition, the terms "include" and "have" and any variants thereof are intended to cover non-exclusive inclusion, for example, the process, method, system, product or device inherently has other steps or units.

[0051] Based on the above purpose, a first aspect of the embodiments of the present application provides an embodiment of a task processing method based on a chip monitoring system. Figure 1Fig. 1 shows a schematic diagram of an embodiment of the task processing method provided by the chip monitoring system according to the present application. Figure 1 As shown in Fig. 1, the embodiment of the present application comprises the following steps:

[0052] Step S10, deploying a backend device conforming to the Virtio standard and a corresponding frontend driver in the chip monitoring system;

[0053] Step S20, in the initialization stage, the firmware of the backend device configures the corresponding functional characteristics for the backend device according to the application scenario, and the frontend driver performs a characteristic negotiation process based on the functional characteristics, so as to make the frontend driver and the backend device of different versions compatible with each other;

[0054] Step S30, in response to completing the characteristic negotiation and the frontend driver receiving the task request sent by the protocol adaptation layer in the chip monitoring system, writing the task request into the request queue;

[0055] Step S40, reading the task request from the request queue by the backend device and executing the corresponding task, and writing the task execution result into the response queue;

[0056] Step S50, reading the task execution result from the response queue by the frontend driver, and forwarding the task execution result to the protocol adaptation layer for processing.

[0057] The Virtio standard is a simulation device implementation standard supporting the semi-virtualization technology, and the simulation device based on the Virtio standard has higher performance and stronger portability / expandability.

[0058] The embodiment of the present application reduces the interface coupling between the frontend driver and the backend device by designing the chip monitoring system based on the Virtio standard and designing the system to comprise the frontend driver layer and the backend device layer, so that the Virtio standard is used to make the frontend driver and the backend device independent of each other in upgrading and performing the functional characteristic negotiation, improve the portability, expandability and data transmission performance of the chip monitoring system, and reduce the version maintenance work and cost; by designing the protocol adaptation layer in the chip monitoring system, the user can input the task request using the conventional standardized debugging tool, and the interaction effect is improved.

[0059] In some embodiments, the method further comprises: in response to the task request being a monitoring command input by the user, the task execution result being an execution result of the monitoring command; in response to the task request being idle buffer information, the task execution result being hardware status or firmware log information of the backend device; and in response to the task request being a queue configuration request, the task execution result being a queue configuration request processing result.

[0060] In some embodiments, the method further comprises, in the initialization stage, creating, by the front-end driver, a request queue and a corresponding response queue, and creating a write request queue thread and a read response queue thread, and creating, by the back-end device, a read request queue thread and a write response queue thread.

[0061] In some embodiments, the chip monitoring system further comprises a presentation layer and a cloud platform layer; the presentation layer comprises a user operation interface of the chip monitoring system and monitoring tools of various interface protocols, and is configured to transmit a task request to the protocol adaptation layer and receive a task execution result from the protocol adaptation layer; the cloud platform layer provides virtual services of computing resources and storage resources for testing the back-end device.

[0062] In some embodiments, the protocol adaptation layer comprises adaptation modules of various interface protocols, and is configured to forward the task request after stripping protocol message headers and tails, to the front-end driver, and forward the task execution result returned by the front-end driver after adding protocol message headers and tails, to the monitoring tools of the presentation layer.

[0063] In some embodiments, reading, by the front-end driver, the task execution result from the response queue comprises reading, by the front-end driver, the task execution result from the response queue based on an interrupt vector configured in the initialization stage.

[0064] In some embodiments, the back-end device comprises a hardware device simulating chip behavior, a chip design prototype verification platform for running chip hardware code, and a hardware device with a chip package after tape-out.

[0065] Figure 2 A structural schematic diagram of a chip monitoring system based on a Virtio standard according to an embodiment of the present application is provided. As shown in Figure 2 , the chip monitoring system comprises:

[0066] A presentation layer S01 is configured to provide a user operation interface of the monitoring system, including but not limited to monitoring tools of various analog serial ports / network ports / USB (Universal Serial Bus, Universal Serial Bus) port communication protocols, and transmit a command input by a user to a protocol adaptation layer S02 and receive a back-end response therefrom.

[0067] The protocol adaptation layer S02 comprises but is not limited to serial port / network / USB protocol adaptation modules, and is configured to forward command data transmitted by the presentation layer after stripping protocol message headers and tails to a Virtio driver layer S03, and forward command response data returned by the Virtio driver layer S03 or actively reported state data after adding protocol message headers and tails to the monitoring tools of the presentation layer S01.

[0068] Virtio driver layer S03, driving Virtio device, including but not limited to analog device (hardware device simulating chip behavior) driver, pre-tapeout device (chip design prototype verification platform running chip hardware code) driver, post-tapeout device (hardware device with chip package after tapeout) driver, processing the commands transmitted by the protocol adaptation layer S02 and returning response data, or actively reporting device exception state information when the device appears an exception;

[0069] Cloud platform layer S04, cloud computing platform, providing virtual services of computing, storage and other resources for deploying and testing Virtio device, including but not limited to high-performance bare metal servers, general-purpose virtual machines, lightweight containers and other resource forms;

[0070] Virtio device layer S05, used for providing various hardware devices conforming to Virtio standard on the cloud platform, including but not limited to analog devices, pre-tapeout devices and post-tapeout devices conforming to Virtio standard.

[0071] Figure 3 The structure diagram of the task processing of the Virtio front-end driver and the Virtio back-end device provided according to the embodiment of the application is shown in FIG. 1. Figure 3 As shown in the figure, the functions of each module are as follows:

[0072] Virtio front-end driver S001, used for providing Virtio device driver;

[0073] Driver initialization S002, initializing the Virtio front-end driver, including feature negotiation (negotiating software and hardware feature with the Virtio back-end device to make different versions of software and hardware compatible with each other), queue / thread creation (creating queues and processing threads for saving user commands, hardware states and firmware logs, and configuring queue information such as actual queue number, queue base address and interrupt vector for notifying that the response queue has been written with data through the queue configuration register of the Virtio back-end device) and the like;

[0074] Command queue processing S003, processing the monitoring commands input by the user, such as viewing / modifying device hardware state, viewing / modifying device firmware state and the like, including command writing (writing the user command data transmitted by the protocol adaptation layer into the command request queue), response reading module (reading the command response data returned by the Virtio back-end device from the command response queue);

[0075] State queue processing S004, processing the hardware state / firmware log information reported by the Virtio back-end device, including buffer writing (writing the idle buffer storing the device hardware state / firmware log information into the state request queue), state reading (reading the device hardware state / firmware log information from the buffer included in the state response queue) module;

[0076] Configuration queue processing S005, processing user input command / status queue configuration information, such as the number of command / status queues used by the device hardware / firmware respectively, queue processing priority, etc., including configuration write (writing queue configuration information into the configuration request queue), response read (reading the queue configuration result of the backend device from the configuration response queue) module;

[0077] Memory S006, used to store the storage device of the above various request / response queues;

[0078] Command request / response queue S007, storing command request / response data;

[0079] Status request / response queue S008, storing status request / response data;

[0080] Configuration request / response queue S009, storing queue configuration request / response data;

[0081] Virtio backend device S010, a hardware device implemented in accordance with the Virtio standard;

[0082] Device-specific module S011, a device-specific module other than the bus standard module implemented in accordance with the Virtio standard;

[0083] DMA (Direct Memory Access) channel S012, used by the device hardware / firmware to read / write various request / response data from the above queues;

[0084] Firmware initialization S013, initializing Virtio backend device firmware, including feature configuration (configuring hardware to enable different functional features according to specific use scenarios), thread creation module (creating specific threads to process the above various queues);

[0085] Command queue processing S014, processing command request / response queue, including command read (reading user command data from command request queue), response write (writing command processing result to command response queue) module;

[0086] Status queue processing S015, processing status request / response queue, including buffer read (reading idle buffer information from status request queue), status write module (writing hardware status / firmware log information to status response queue);

[0087] Configuration queue processing S016, processing configuration request / response queue, including configuration read (reading queue configuration information from configuration request queue), response write module (writing queue configuration result such as whether the execution is successful or not to the configuration response queue);

[0088] The bus standard module S017, which is implemented according to the Virtio standard, has the same hardware register interface based on Virtio devices of the same bus such as PCI (Peripheral Component Interconnect) and MMIO (Memory-Mapped Device Directly Connected to Processor), including feature indication (indicating the functional features supported by the device, such as whether to support configuration of the number of software and hardware queues, the maximum number of queues, the maximum number of queue elements, and configuration of queue priority), device state (indicating the current running state of the device), driver notification (used for driver notification of the hardware queue write pointer position, whether the queue is wrapped, etc.), and queue configuration (used for driver configuration of the actual number of queues created by hardware / base address, notification of the interrupt vector of the response queue after data is written, etc.)

[0089] The task processing workflow is as follows:

[0090] 1) In the device power-on initialization stage, the firmware configures the functional features related to the application scenario to enable the hardware, and then creates a queue processing thread for reading and writing the above-mentioned various request / response queues according to the specific application scenario.

[0091] 2) In the initialization stage after the Virtio front-end driver is loaded into the system, the feature negotiation process is performed according to the functional feature information of the driver itself and the hardware functional feature information read from the Virtio back-end device feature register, so that different versions of the driver and the device are compatible with each other, and then the above-mentioned various request / response queues and queue processing threads are created.

[0092] 3) After the Virtio front-end driver receives the user monitoring command sent by the protocol adaptation layer, the command is written into the command request queue and the driver notification register of the device hardware is configured to notify the device hardware or firmware to process the monitoring command.

[0093] 4) After the Virtio back-end device hardware or firmware reads the monitoring command from the command request queue, the command processing is performed.

[0094] 5) The Virtio back-end device writes the command processing result into the command response queue, and then notifies the Virtio front-end driver that there is pending response information to be processed according to the queue interrupt vector configured in the initialization stage, through an interrupt signal.

[0095] 6) After the Virtio front-end driver receives the hardware interrupt signal indicating that there is pending response information to be processed, the command response information is read from the command response queue, and then the command response information is further forwarded to the protocol adaptation layer for processing.

[0096] The processing procedures of subsequent steps 7) to 10) are similar to steps 3) to 6), and the difference is that the Virtio front-end driver writes the idle buffer information into the request queue and reads the hardware state or firmware log information returned by the back-end device from the response queue;

[0097] The processing procedures of subsequent steps 11) to 14) are similar to steps 3) to 6), and the difference is that the Virtio front-end driver writes the queue configuration information into the request queue and reads the queue configuration request processing result information returned by the back-end device from the response queue.

[0098] The chip monitoring system based on the Virtio standard in this embodiment can bring the following advantages:

[0099] a. Improved system portability. Since the device driver software does not rely on the device hardware register interface to obtain the hardware or firmware state, the system device driver software and the hardware register interface are decoupled, and any change in the hardware register interface does not require modification of the device driver software. The device driver software is well portable between different hardware versions.

[0100] b. Improved system scalability. Since the device driver software and the hardware register interface are not coupled, adding a new hardware register interface does not require adding a device driver software interface, and the software and hardware interfaces can be independently upgraded to add new functions.

[0101] c. Reduced system version maintenance work. Since the Virtio standard function feature negotiation mechanism is provided, different versions of the device driver and different versions of the device hardware can coexist, and the developer does not need to maintain the version correspondence between the device driver and the device hardware. When there are many versions of the device driver and the device hardware, the version maintenance workload will be greatly reduced.

[0102] d. Enhanced system physical hardware performance. When the system hardware is a chip design prototype verification platform before tape-out or a real hardware device with a chip package after tape-out, the device driver can asynchronously send multiple monitoring commands in batches, without blocking and waiting for the command to complete. After the hardware or firmware returns its return state information, the front-end driver can asynchronously call the callback processing function registered by the front-end driver. The asynchronous transmission mechanism makes the system data transmission performance higher.

[0103] e. Enhanced system simulation hardware performance. When the system hardware is a virtualization platform simulation hardware that simulates the behavior of a chip before tape-out, the semi-virtualization technology is adopted, i.e., the device can execute multiple input / output instructions simultaneously, avoiding the performance problems of full virtualization technology, such as excessive context switching, excessive instruction path length, and excessive memory copying.

[0104] f. Reduce the cost of the system. Because of the Virtio standard multi-queue mechanism, when the system hardware is physical hardware, the performance can be improved by increasing the number of queues, reducing the hardware cost caused by increasing the register interface, and even using the virtualization platform to simulate the device, which will reduce the development cost of the virtualization platform to simulate the device register interface.

[0105] The second aspect of the embodiment of the application also provides a task processing device based on a chip monitoring system. Figure 4 The embodiment of the task processing device based on the chip monitoring system provided by the application is shown. As shown in Figure 4 The task processing device based on the chip monitoring system includes a deployment module 10 configured to deploy a back-end device conforming to the Virtio standard and a corresponding front-end driver in the chip monitoring system; a function characteristic module 20 configured to, in the initialization stage, configure the back-end device with corresponding function characteristics according to the application scenario by the firmware of the back-end device, and perform a characteristic negotiation process based on the function characteristics by the front-end driver to make different versions of the front-end driver and the back-end device compatible with each other; a write module 30 configured to, in response to completing the characteristic negotiation and the front-end driver receiving a task request sent by a protocol adaptation layer in the chip monitoring system, write the task request into a request queue; a read-write module 40 configured to, after the back-end device reads the task request from the request queue, execute a corresponding task, and write a task execution result into a response queue; and a read module 50 configured to, by the front-end driver, read the task execution result from the response queue, and forward the task execution result to the protocol adaptation layer for processing.

[0106] The third aspect of the embodiment of the application also provides a computer readable storage medium, Figure 5 The embodiment of the computer readable storage medium for implementing the task processing method based on the chip monitoring system provided by the application is shown. As shown in Figure 5 The computer readable storage medium 3 stores computer program instructions 31. The computer program instructions 31 are executed by the processor to implement the method of any one of the above embodiments.

[0107] It should be understood that all the embodiments, features and advantages described above for the task processing method based on the chip monitoring system according to the application are equally applicable to the task processing device and the storage medium based on the chip monitoring system according to the application without conflicting with each other.

[0108] The fourth aspect of the embodiment of the application also provides a computer device, including Figure 6The memory 402 shown stores a computer program which, when executed by the processor 401, implements the method of any of the embodiments described above.

[0109] As shown in Figure 6 Fig. 1 is a schematic diagram of the hardware structure of an embodiment of the computer device for performing the task processing method based on the chip monitoring system provided by the present application. As shown in Figure 6 Fig. 1, the computer device includes a processor 401 and a memory 402, and can further include an input device 403 and an output device 404. The processor 401, the memory 402, the input device 403 and the output device 404 can be connected by a bus or other means, Figure 6 for example, by a bus. The input device 403 can receive input digital or character information, and generate key signal input related to user settings and function control of the task processing device based on the chip monitoring system. The output device 404 can include a display device such as a display screen.

[0110] The memory 402, as a non-volatile computer readable storage medium, can be used to store non-volatile software programs, non-volatile computer executable programs and modules, such as program instructions / modules corresponding to the task processing method based on the chip monitoring system in the embodiments of the present application. The memory 402 can include a program storage area and a data storage area, wherein the program storage area can store an operating system and application programs required by at least one function; the data storage area can store data created by use of the task processing method based on the chip monitoring system, etc. In addition, the memory 402 can include a high-speed random access memory, and can further include a non-volatile memory, such as at least one magnetic disk storage device, a flash memory device, or other non-volatile solid-state memory device. In some embodiments, the memory 402 can optionally include a memory disposed remotely with respect to the processor 401, and these remote memories can be connected to the local modules through a network. Examples of the above network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0111] The processor 401 executes various function applications and data processing of the server by running the non-volatile software programs, instructions and modules stored in the memory 402, i.e. implements the task processing method based on the chip monitoring system of the above method embodiments.

[0112] Finally, it is noted that the computer-readable storage media of the present application, for example, the memory, can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory. By way of example, and not limitation, nonvolatile memory can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM), which can act as external cache memory. By way of example, and not limitation, RAM is available in many forms such as Static RAM (DRAM), Dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and direct Rambus RAM (DRRAM). The memory of the disclosed aspects is intended to include, without being limited to including, these and any other suitable types of memory.

[0113] Those skilled in the art will further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the disclosure herein can be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans can implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application embodiments disclosure.

[0114] The foregoing is a summary of the exemplary embodiments disclosed herein, but it should be noted that various changes and modifications could be made therein without departing from the scope of the present application embodiments disclosure as defined by the appended claims. The functional, step, and / or action elements of the method claims, as described herein, need not be performed in any particular order. Furthermore, although elements of the present application embodiments disclosure can be described or claimed in individual forms, other embodiments can include a combination of described or claimed elements, unless specifically stated otherwise.

[0115] It should be understood that, as used herein, "a" or "an" can mean one or more things unless the context clearly dictates otherwise. It will also be understood that the terms "and", "or", "both" and "and / or" as used herein, refer to a function of the conjunctive inclusion (an inclusive "OR"), unless expressly indicated otherwise. The above-described application embodiments disclosure sequence numbers are merely for description, not representing the advantages or disadvantages of the embodiments.

[0116] Those skilled in the art should understand that the above discussion of any embodiment is only exemplary, and is not intended to mean that the scope of the embodiments disclosed by the present application (including claims) is limited to these examples; under the idea of the embodiments of the present application, the above embodiments or technical features in different embodiments can also be combined, and there are many other changes of different aspects of the embodiments of the present application as above. In order to be brief, they are not provided in details. Therefore, any omission, modification, equivalent replacement, improvement, etc. made in the spirit and principle of the embodiments of the present application shall be included in the protection scope of the embodiments of the present application.

Claims

1. A task processing method based on a chip monitoring system, characterized in that, Includes the following steps: The chip monitoring system deploys a presentation layer, a protocol adaptation layer, a cloud platform layer, a bus standard module, and backend devices conforming to the Virtio standard, along with corresponding frontend drivers. The presentation layer includes the user interface of the chip monitoring system and monitoring tools for various interface protocols, configured to transmit task requests to the protocol adaptation layer and receive task execution results from the protocol adaptation layer. The protocol adaptation layer includes adaptation modules for various interface protocols, configured to strip the protocol message headers and footers from the task requests before forwarding them to the frontend drivers, and to add the protocol message headers and footers to the task execution results returned by the frontend drivers before forwarding them to the monitoring tools in the presentation layer. The cloud platform layer provides virtual services for testing the computing and storage resources of the backend devices. The bus standard module is a bus standard module implemented according to the Virtio standard; Virtio devices based on the same bus have the same hardware register interfaces, including feature indicators, device status, driver notifications, and queue configurations. During the initialization phase, the firmware of the backend device configures corresponding functional features for the backend device according to the application scenario, and the frontend driver performs a feature negotiation process based on the functional features to make different versions of the frontend driver and the backend device compatible with each other. In response to the completion of feature negotiation and the front-end driver receiving the task request sent by the protocol adaptation layer, the task request is written into the request queue. The backend device reads the task request from the request queue, executes the corresponding task, and writes the task execution result into the response queue; The front-end driver reads the task execution result from the response queue and forwards the task execution result to the protocol adaptation layer for processing.

2. The method according to claim 1, characterized in that, Also includes: In response to the task request being a monitoring command input by the user, the task execution result is the execution result of the monitoring command; In response to the task request being an idle buffer, the task execution result is the hardware status or firmware log information of the backend device. In response to the task request being a queue configuration request, the task execution result is the queue configuration request processing result.

3. The method according to claim 1, characterized in that, Also includes: During the initialization phase, the front-end driver creates the request queue and the corresponding response queue, and creates a write request queue thread and a read response queue thread, while the back-end device creates a read request queue thread and a write response queue thread.

4. The method according to claim 1, characterized in that, The front-end driver reads the task execution result from the response queue, including: The front-end driver reads the task execution result from the response queue based on the interrupt vector configured in the initialization phase.

5. The method according to claim 1, characterized in that, The backend equipment includes hardware devices for simulating chip behavior, a chip design prototype verification platform for running chip hardware code, and hardware devices for chip packaging after tape-out.

6. A task processing device based on a chip monitoring system, characterized in that, include: Presentation layer, protocol adaptation layer, cloud platform layer, bus standard module, deployment module, feature module, write module, read-write module, read module, and backend devices conforming to the Virtio standard and corresponding frontend drivers; The presentation layer includes the user interface of the chip monitoring system and monitoring tools with various interface protocols, configured to transmit task requests to the protocol adaptation layer and receive task execution results from the protocol adaptation layer. The protocol adaptation layer includes adaptation modules for various interface protocols, and is configured to strip the protocol message header and footer from the task request and forward it to the front-end driver, and to add the protocol message header and footer to the task execution result returned by the front-end driver and forward it to the monitoring tool in the presentation layer. The cloud platform layer provides virtual services for testing the computing and storage resources of the backend devices; The bus standard module is a bus standard module implemented according to the Virtio standard. Virtio devices based on the same bus have the same hardware register interface, including feature indication, device status, driver notification, and queue configuration. The deployment module configuration is used to deploy Virtio-compliant backend devices and corresponding frontend drivers in the chip monitoring system; The feature module configuration is used during the initialization phase, whereby the firmware of the backend device configures corresponding features for the backend device according to the application scenario, and the frontend driver performs a feature negotiation process based on the feature to make different versions of the frontend driver and the backend device compatible with each other. The write module configuration is used to write the task request into the request queue in response to the completion of feature negotiation and the front-end driver receiving the task request sent by the protocol adaptation layer of the chip monitoring system. The read / write module is configured to allow the backend device to read the task request from the request queue, execute the corresponding task, and write the task execution result to the response queue. as well as The read module is configured to read the task execution result from the response queue by the front-end driver and forward the task execution result to the protocol adaptation layer for processing.

7. A computer-readable storage medium, characterized in that, The system stores computer program instructions that, when executed by a processor, implement the method as described in any one of claims 1-5.

8. A computer device, comprising a memory and a processor, characterized in that, The memory stores a computer program, which, when executed by the processor, performs the method as described in any one of claims 1-5.

Images