WO2024001251A1

WO2024001251A1 - Chip test system and method, and device and medium

Info

Publication number: WO2024001251A1
Application number: PCT/CN2023/078372
Authority: WO
Inventors: 郑俊飞; 任明刚
Original assignee: 苏州元脑智能科技有限公司
Priority date: 2022-06-30
Filing date: 2023-02-27
Publication date: 2024-01-04
Also published as: CN114816894B; CN114816894A

Abstract

A chip test system and method, and a device and a medium. The system comprises: an application layer (10), a communication layer (20), a virtualization layer (30), a hardware device layer (40), and an engine layer (50), wherein the application layer (10) is configured to convert a user operation into a use-case execution request, and send the use-case execution request to a use-case service scheduling module (31) on the basis of a communication protocol (21) of the communication layer; the use-case service scheduling module (31) is configured to call a use-case service (35) on a virtual host (34) on the basis of the use-case execution request; the use-case service (35) is configured to acquire a test parameter from the use-case execution request, and configure the test parameter to a hardware device (41); and the hardware device (41) is configured to invoke a corresponding algorithm acceleration engine (51) on the basis of the test parameter, so as to execute a test, and return a test result to the application layer (10) by means of the use-case service scheduling module (31). The system improves the portability, security and reliability of a test system, reduces the coupling between system modules, and enhances the expandability of the system.

Description

A chip testing system, method, equipment and medium

Cross-references to related applications

This application claims priority to the Chinese patent application filed with the China Patent Office on June 30, 2022, with application number 202210760710.9 and the application title "A chip testing system, method, equipment and medium", the entire content of which is incorporated by reference in in this application.

Technical field

The present application relates to the field of testing technology, and in particular, to a chip testing system, method, equipment and medium.

Background technique

Web (World Wide Web, Global Wide Area Network) service is a distributed application software design method that can realize cross-platform, cross-programming language, low-coupling, self-contained distributed application software, regardless of different software running on different network hosts. Regardless of the programming language, operating platform, and communication protocol used, as long as they are designed in accordance with Web services, data can be exchanged arbitrarily without relying on third-party software and hardware.

As the demand for chip localization replacement becomes increasingly urgent, many chip design companies have emerged on the market. However, chip R&D is characterized by a long cycle, including multiple stages such as architecture, design, testing, tape-out, and post- tape-out testing. In order to reduce R&D costs, During the cycle, researchers designed many chip simulation test systems so that chip design, verification and other work can be executed in parallel.

The currently commonly used chip simulation test platform design method is: divide the entire system into two parts: the front end and the front end. The front end displays the user interface and sends user operations to the back end. The back end uses virtualization technology to add hardware that simulates chip behavior, and then based on The test command submitted by the front end executes the corresponding test flow and returns the test results to the front end for display.

Although the above chip simulation test system can test the chip, it has the following problems:

1) System portability is poor. Since the test system is implemented based on a specific hypervisor (management program), when the hypervisor is replaced, all environment deployment operations such as image creation, system installation, startup, and shutdown of virtual machines, etc., need to be replaced with the new hypervisor interface, and it is not convenient for virtual hosts. dynamic migration between.

2) System security and reliability are poor. Because the system lacks mechanisms such as image backup, dynamic migration, data and network security, and status monitoring, and has not been fully tested by internal and external users, the system is prone to incomplete development. For example, damage to the host storage media is not considered, or exceptions that are difficult to recover from internal and external attacks such as network denial of service attacks are not considered.

3) The system is highly coupled and difficult to expand. Since there is no unified planning, newly added hardware, drivers and test codes may not only be duplicated, but may also affect the operation of the original modules. It requires a lot of effort to locate module conflicts. Many R&D personnel use methods such as repeated installation of virtual machines to resolve conflicts, and further Increased resource consumption and environment deployment work.

Contents of the invention

In view of this, this application proposes a chip testing system, method, equipment and medium to solve the problem of existing testing systems. Problems such as poor portability, poor reliability, and difficulty in expansion. Through the design of the application layer, communication layer, virtualization layer, device layer, and engine layer, the differences in the underlying hypervisor are shielded and the additional environment deployment work caused by replacing the hypervisor is reduced. ; And combined with cloud platform software and hardware services such as identity authentication, mirror service, dynamic migration, etc., the portability and reliability of the system are improved; and the plug-in use case service development mechanism based on Web services supports adding any chip test items to the test System, the new service is not coupled with other original services of the system and will not affect the operation of the original modules, making the system more scalable.

Based on the above purpose, one aspect of the embodiments of the present application provides a chip testing system. The system specifically includes:

Application layer, communication layer, virtualization layer, hardware device layer and engine layer. The communication layer includes communication protocols; the virtualization layer includes use case service scheduling module, cloud platform, virtual services and virtual hosts deployed on the cloud platform, and deployment For use case services on virtual hosts, the hardware device layer includes hardware devices, and the engine layer includes algorithm acceleration engines for hardware devices;

The application layer is configured to convert user operations into use case execution requests, and send the use case execution requests to the use case service scheduling module based on the communication protocol;

The use case service scheduling module is configured to call the use case service on the virtual host based on the use case execution request;

The use case service is configured to obtain test parameters from the use case execution request and configure the test parameters to the hardware device;

The hardware device is configured to call the corresponding algorithm acceleration engine based on the test parameters to execute the test, and return the test results to the application layer through the use case service scheduling module.

In some embodiments, the application layer includes a user operation interface;

The algorithm acceleration engine is configured to return the test results to the use case service of the virtual host after the test is completed;

The virtual host is configured to return test results to the use case service scheduling module based on the use case service;

The use case service scheduling module is configured to further return the test results to the application layer and display them to the user operation interface.

In some implementations, the use case service scheduling module includes a service interface configuration module, and the service interface configuration module is configured as:

Obtain the virtual services deployed to the cloud platform, and write the corresponding service interfaces into the service interface configuration file hierarchically based on the virtual services. Each level includes at least one service interface, and each service interface includes a passive service interface and an active service interface. and lower-level service interfaces.

In some implementations, the use case service scheduling module includes a service interface detection module and a service interface parsing module. The service interface detection module is configured as:

Regularly detect whether the service interface configuration file has changed;

In response to changes in the service interface configuration file, the service interface parsing module is triggered, and the service interface configuration file is updated through the service interface parsing module;

The service interface parsing module is configured to read from the service interface configuration file and parse the service interface line by line.

In some implementations, the use case service scheduling module includes a service interface parsing module, and the service interface parsing module is configured as:

Get the next service interface among the service interfaces at this level;

Determine whether the next service interface is the last service interface among the service interfaces at this level;

In response to the next service interface not being the last service interface among the service interfaces at this level, determine whether the passive service interface of the next service interface is empty;

Based on the judgment result of whether the passive service interface of the next service interface is empty, judge whether the active service interface of the next service interface is empty;

Based on the judgment result of whether the active service interface of the next service interface is empty, judge whether the subordinate service interface of the next service interface is empty;

In response to the lower-level service interface of the next service interface being empty or not empty, return to the step of obtaining the next service interface of this level to continue parsing the next service interface of the next service interface of this level until all the services of this level are parsed. Service interface.

In some implementations, based on the determination result of whether the passive service interface of the next service interface is empty, determining whether the active service interface of the next service interface is empty includes:

In response to the passive service interface of the next service interface being not empty, register the passive service interface in the service interface hash table, and determine whether the active service interface of the next service interface is empty, where the passive service interface is used when receiving Called when testing a request;

In response to the passive service interface of the next service interface being empty, it is directly determined whether the active service interface of the next service interface is empty.

In some implementations, based on the judgment result of whether the active service interface of the next service interface is empty, judging whether the subordinate service interface of the next service interface is empty includes:

In response to the active service interface of the next service interface not being empty, start thread polling to determine whether the subordinate service interface of the next service interface is empty. Thread polling is used to call the active service interface of this level service interface;

In response to the active service interface of the next service interface being empty, it is directly determined whether the subordinate service interface of the next service interface is empty.

In some implementations, in response to the lower-level service interface of the next service interface being not empty, return to the step of obtaining the next service interface of this level to continue parsing the next service interface of the next service interface of this level until the current level is parsed. All service interfaces at the level, including:

In response to the lower-level service interface of the next service interface not being empty, obtain the service interface of the next level based on the lower-level service interface, and recursively parse the service interface of the next level until all service interfaces of all lower levels are parsed;

Return to the step of obtaining the next service interface of this level to continue parsing the next service interface of the next service interface of this level until all service interfaces of this level are parsed.

In some implementations, the service interface resolution module is also configured as:

In response to the next service interface being the last service interface among the service interfaces of this level, the service interface resolution of this level is ended.

In some implementations, the use case service scheduling module includes a service interface triggering module, and the service interface triggering module is configured as:

In response to receiving the use case execution request, the corresponding service interface is found from the service interface hash table based on the message type field in the use case execution request.

In some implementations, the use case service scheduling module includes a service interface calling module, and the service interface calling module is configured as:

Call the corresponding service interface to send the use case execution request to the Web server to forward the use case execution request to the use case service based on the Web server.

In some implementations, the use case service is configured to call the hardware testing tool, and based on the hardware testing tool, call the corresponding hardware peripheral driver to drive the corresponding hardware device to perform the corresponding hardware test.

Another aspect of the embodiment of the present application also provides a chip testing method, which is applied to a test system. The test system includes: an application layer, a communication layer, a virtualization layer, a hardware device layer and an engine layer, where the communication layer includes communication Protocol; the virtualization layer includes the use case service scheduling module, the cloud platform, virtual services and virtual hosts deployed on the cloud platform, and use case services deployed on the virtual hosts. The hardware device layer includes hardware devices, and the engine layer includes hardware devices. Algorithm acceleration engine; methods include:

The application layer converts user operations into use case execution requests, and sends the use case execution requests to the use case service scheduling module based on the communication protocol;

The use case service scheduling module calls the use case service on the virtual host based on the use case execution request;

The use case service obtains test parameters from the use case execution request and configures the test parameters to the hardware device;

The hardware device calls the corresponding algorithm acceleration engine based on the test parameters to execute the test, and returns the test results to the application layer through the use case service scheduling module.

Another aspect of the embodiments of the present application also provides a computer device, including: at least one processor; and a memory. The memory stores a computer program that can be run on the processor. When the computer program is executed by the processor, the above method is implemented. A step of.

In another aspect of the embodiments of the present application, a non-volatile readable storage medium is also provided. The non-volatile readable storage medium stores a computer program that implements the above method steps when executed by a processor.

This application has at least the following beneficial technical effects: 1) Improves the portability of the system. Replacing the hypervisor at the bottom of the system does not require modification of the environment deployment process, such as virtual machine image creation, operating system installation, startup, shutdown, suspension, recovery of virtual machines, etc., and the image of the specific use case service interface can be deployed on bare metal, virtual machines, containers Any migration between them; 2) Improves the security and reliability of the system. Based on the cloud platform's mature user identity authentication, image backup, dynamic migration, data and network security, status monitoring and other mechanisms, and because the cloud platform has been fully tested by large-scale users, the system failure rate is low and the fault self-recovery capability is also strong. And it can effectively filter malicious network attacks from internal and external users; 3) Reduces the coupling between system modules and enhances system scalability. The unified use case service scheduling module reduces repeated test code writing work. The use case service plug-in development framework based on the Web service interface makes the test modules developed by each test developer not dependent on each other. The coupling degree of each service interface is low, reducing In order to solve the problem of difficulty in locating system faults caused by module coupling, the newly added software and hardware test modules will not interfere with the operation of the original modules.

Description of drawings

In order to explain the embodiments of the present application or the technical solutions in the prior art more clearly, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings in the following description are only These are some embodiments of the present application. For those of ordinary skill in the art, other embodiments can be obtained based on these drawings without exerting creative efforts.

Figure 1 is a schematic structural diagram of an embodiment of the chip testing system provided by this application;

Figure 2 is a schematic structural diagram of another embodiment of the chip testing system provided by this application;

Figure 3 is a schematic diagram of an embodiment of the service interface configuration file provided by this application;

Figure 4 is a matching flow chart of the service interface hash table provided by this application;

Figure 5 is a block diagram of an embodiment of the chip testing method provided by this application;

Figure 6 is a schematic structural diagram of an embodiment of the computer equipment provided by the present application;

Figure 7 is a schematic structural diagram of an embodiment of a non-volatile readable storage medium provided by this application.

Detailed ways

In order to make the purpose, technical solutions and advantages of the present application more clear, the embodiments of the present application will be further described in detail below with reference to specific embodiments and the accompanying drawings.

It should be noted that all expressions using “first” and “second” in the embodiments of this application are intended to distinguish two entities or parameters with the same name but not the same. It can be seen that “first” and “second” It is only for the convenience of description and should not be understood as a limitation on the embodiments of the present application, and subsequent embodiments will not describe this one by one.

Based on the above purpose, a first aspect of the embodiments of this application provides an embodiment of a chip testing system. As shown in Figure 1, the system includes:

The application layer 10, the communication layer 20, the virtualization layer 30, the hardware device layer 40 and the engine layer 50, where the communication layer 20 includes communication communication protocol 21; the virtualization layer 30 includes a use case service scheduling module 31, a cloud platform 32, a virtual service 33 and a virtual host 34 deployed on the cloud platform 32, a use case service 35 deployed on the virtual host 34, and the hardware device layer 40 includes The hardware device 41 and the engine layer 50 include an algorithm acceleration engine 51 for the hardware device.

The testing process based on the above test system is as follows:

S1. The application layer converts user operations into use case execution requests, and sends the use case execution requests to the use case service scheduling module based on the communication protocol;

S2. The use case service scheduling module calls the use case service on the virtual host based on the use case execution request;

S3. The use case service obtains the test parameters from the use case execution request and configures the test parameters to the hardware device;

S4. The hardware device calls the corresponding algorithm acceleration engine based on the test parameters to execute the test, and returns the test results to the application layer through the use case service scheduling module.

The application layer provides a user operation interface, and converts user operations obtained through the user operation interface into use case execution requests and sends them to the use case service scheduling module of the virtualization layer. The use case service scheduling module calls different virtualization environments (i.e. virtual hosts) based on test parameters. , such as bare metal servers, virtual machines, containers, etc.), the use case service calls the underlying hardware (such as FPGA (Field Programmable Gate Array, field programmable logic gate array) prototype verification platform, post-strip hardware, simulation hardware, Test stubs, etc.) execute the test and return the results to the use case service scheduling module through the use case service, and further return to the user operation interface through the use case service scheduling module.

The above-mentioned test system can be applied to testing at various stages of chip development, such as system architecture stage, design stage, tape-out stage, post- tape-out stage and other stages of testing.

Through the above test system, the chip is tested, and through the design of the application layer, communication layer, virtualization layer, device layer and engine layer, the differences in the underlying hypervisor are shielded and the additional environment deployment work caused by replacing the hypervisor is reduced. ; And combined with cloud platform software and hardware services such as identity authentication, mirroring services, dynamic migration, etc., the portability and reliability of the system are improved; and the use case service scheduling module supports adding any chip test items to the test system, making new services compatible with Other original services of the system are not coupled and will not affect the operation of the original modules, thus enhancing the scalability of the system.

The application layer, communication layer, virtualization layer, device layer and engine layer of the above test system will be described in more detail below through some specific embodiments.

As shown in Figure 2, it is a schematic structural diagram of another chip testing system.

The functions of each module in Figure 2 are introduced below.

The S001 application layer is used to display the user operation interface to the user. The user operation interface includes any one of S001, S002, and S003;

S002 browser interface, a graphical user operation interface based on a web browser;

S003 graphical user interface, a graphical user operation interface based on desktop application graphics library;

S004 command line interface, a user operation interface based on the terminal command line and without graphical elements;

S005 communication layer, used for communication between the use case service scheduling module of the application layer and virtualization layer, including any one of S006, S007, and S008;

S006 Hyper Text Transfer Protocol (HTTP), an application layer data transfer protocol located above the network transport layer;

S007 network transport layer protocol, a data transmission protocol based on the network transport layer, can provide a socket form interface;

S008 Advanced Message Queuing Protocol, an application layer message publish-subscribe protocol based on the network transport layer;

S009 virtualization layer, used to provide test equipment, test environment, and various carriers for test case execution;

S010 use case service scheduling is used to receive various test commands from the application layer;

S011 bare metal is a physical server that can provide virtual software and hardware resources on the cloud platform. It is a type of virtual host. Only one virtual host can be selected for each test and deployed on the cloud platform based on the application scenario;

S012 bare metal use case service, a use case service module running on a bare metal server, is a type of virtual host. Only one virtual host can be selected for each test and deployed on the cloud platform based on the application scenario;

S013 virtual machine, a virtual host that can provide software and hardware resources on the cloud platform, is created through the hypervisor software of the physical server. Due to the hypervisor software overhead, its performance is lower than that of bare metal with the same configuration;

S014 virtual machine use case service, a use case service module running on a virtual machine;

S015 containers, containers that use lightweight virtualization technology on cloud platforms, can usually only run a single process;

S016 container use case service, a use case service module running on the container;

S017 cloud platform, a cloud computing platform that provides computing, network, storage, application software and other virtual services;

S018 authentication service provides services for managing user identity authentication, service rules, service tokens and other information;

S019 image service provides services for registering, downloading, and creating operating system images of different types and versions;

S020 computing service provides life cycle management services such as creation, deletion, suspension and recovery of virtual machines;

S021 storage service provides block storage as a virtual hard disk and object storage service for storing object data;

S022 network service provides virtual switch/bridge, virtual router, DHCP (Dynamic Host Configuration Protocol), namespace and other services;

The S023 device layer provides various hardware devices that can be used to simulate chip behavior. Each test can only select one hardware device according to the application scenario to perform the corresponding test;

S024 physical hardware, FPGA prototype verification hardware before tape-out, hardware after tape-out, etc.;

S025 simulation hardware, a simulation hardware device that simulates chip behavior through software;

S026 test pile is a hardware test interface simulated by software and does not have any hardware functions;

The S027 engine layer includes various algorithm acceleration engines within the hardware;

S028 compression, a hardware acceleration engine for compression algorithms;

S029 erasure, hardware acceleration engine for erasure algorithm;

S030 encryption and decryption, hardware acceleration engine for encryption and decryption algorithms;

S031 RAID (Redundant Array of Independent Disk, independent disk redundancy system), the hardware acceleration engine of the disk redundant array algorithm;

S032 network offload (offload, a network fragmentation technology), network protocols such as TCP (Transmission Control Protocol, Transmission Control Protocol)/UDP (User Datagram Protocol, User Datagram Protocol)/IP (Internet Protocol, Internet Protocol), etc. Algorithm hardware acceleration engine;

S033 audio and video codec, a hardware acceleration engine for audio and video codec algorithms.

The following describes the chip testing process of the test system in conjunction with Figure 2.

S11. After the application layer receives the user's execution of the test case on the user operation interface, the application layer converts the user operation into a use case execution request, and based on a certain communication protocol of the communication layer (including but not limited to hypertext transfer protocol, network transmission layer protocol, advanced message queue protocol, etc.) forward the use case execution request to the use case service scheduling module of the virtualization layer;

S12. The use case service scheduling module submits the use case execution request to the Web server, and forwards the use case execution request to the use case service on the corresponding virtual host (including but not limited to bare metal, virtual machines, containers, etc.) through the Web server;

S13. The use case service on the virtual host obtains the test parameters from the use case execution request and configures the test parameters into the corresponding hardware devices (including but not limited to physical hardware, simulated hardware, test stubs, etc.). The hardware devices call different hardware The engine executes corresponding test cases, including but not limited to compression, erasure, encryption and decryption, RAID, network offload, audio and video codec, etc.;

S14. After the hardware engine executes the test case, it returns the test results to the use case service of the virtual host;

S15. The use case service of the virtual host further returns the test results to the use case service scheduling module;

S16. The use case service scheduling module further returns the test results to the application layer software and displays them on the operation interface.

The above solution has the following benefits:

1) Improved the portability of the system. Replacing the hypervisor at the bottom of the system does not require modification of the environment deployment process, such as virtual machine image creation, operating system installation, startup, shutdown, suspension, recovery of virtual machines, etc., and the image of the specific use case service interface can be deployed on bare metal, virtual machines, containers Any migration between them;

2) Improve the safety and reliability of the system. Based on the cloud platform's mature user identity authentication, image backup, dynamic migration, data and network security, status monitoring and other mechanisms, and because the cloud platform has been fully tested by large-scale users, the system failure rate is low and the fault self-recovery capability is also strong. And it can effectively filter malicious network attacks from internal and external users.

3) Reduces the coupling between system modules and enhances system scalability. Unified use case service scheduling module to reduce The use case service plug-in development framework based on the Web service interface eliminates repetitive test code writing work, so that the test modules developed by each test developer will not depend on each other, and the coupling degree of each service interface is low, reducing system failures caused by module coupling. It is difficult to locate the problem. The newly added software and hardware test module will not interfere with the operation of the original module.

In some embodiments, the application layer includes a user operation interface;

As shown in Figure 3, it is a schematic diagram of the service interface configuration file.

The specific process of configuring the service interface configuration file based on Figure 3 is as follows:

Suppose that the service developer is developing a specific service, for example, the specific service is a testing service for a certain chip. After the virtual service is deployed to the virtual machine image template of the cloud platform, the deployed virtual service writes the service interface required for testing into a certain level of the configuration file as a use case service interface at that level. Each use case service interface includes Passive service interface, active service interface, lower-level service interface (if the service contains more sub-services, such as use case execution service may include compression, erasure, redundant array and other algorithm acceleration chip sub-test services, it will be reflected in the lower-level service interface) .

More specifically, the passive service interface is used to execute command processing after receiving the command, such as device control, use case execution services, etc.; the active service interface is used to proactively report service status, such as hardware interrupt processing, etc.; the subordinate service interface is used to associate sub-services. , if the current service contains more sub-services, for example, the use case execution service may include compression, erasure, redundant array and other algorithm acceleration chip sub-test services, it will be reflected in the lower-level service interface.

Regularly detect whether the service interface configuration file has changed;

The detection process of the service interface detection module will be described below with reference to Figure 3.

S21. Regularly detect whether there are any changes in the service interface configuration file;

S22. If the service interface configuration file changes, stop all services;

S23. Trigger the service interface parsing module, and implement online updating of the service interface configuration file through the service interface parsing module.

The following is the parsing process of the service interface parsing module:

Parse the service interface line by line from the service interface configuration file;

If it is determined that the passive service interface is not empty, configure the passive service interface into the service interface hash table. When the use case service scheduling module receives the use case execution message, it searches for the matching passive service interface execution in the hash table according to the message type field. Corresponding test cases;

If it is determined that the active service interface is not empty, a thread will be started to poll and call the service interface. Through this service interface, the running status of the service can be reported to the application layer software when necessary, such as reporting hardware interrupt notifications, hardware exception status information, or Other service abnormal status information, etc.

As shown in Figure 4, it is the matching flow chart of the service interface hash table.

The message type of each level of test parameters submitted by the user can trigger the service interface of the corresponding level. Then parameter 1 of this level is used as the identification field of the next-level test parameter, and the same processing process is performed on the lower-level test parameters. Different developers can Configure different service interfaces for different cloud platform hosts to achieve a customized testing environment.

Get the next service interface among the service interfaces at this level;

In response to the passive service interface of the next service interface not being empty, register the passive service interface in the service interface hash table. interface, and determine whether the active service interface of the next service interface is empty, where the passive service interface is used to call when receiving a test request;

The following explains the parsing process of the service interface parsing module in conjunction with Figure 3.

S30. Obtain the next service interface among the service interfaces at this level;

S31. Determine whether the next service interface is the last service interface among the service interfaces at this level;

S32. In response to the next service interface being the last service interface among the service interfaces at this level, end the service interface parsing at this level;

S33. In response to the next service interface not being the last service interface among the service interfaces at this level, determine whether the passive service interface of the next service interface is empty;

S34. In response to the passive service interface of the next service interface being empty, step S36 is directly executed;

S35. In response to the passive service interface of the next service interface being not empty, register the passive service interface (ie callback interface) in the service interface hash table, where the passive service interface is used to call when a test request is received;

S36. Determine whether the active service interface of the next service interface is empty;

S37. In response to the active service interface of the next service interface being empty, step S39 is directly executed;

S38. In response to the active service interface of the next service interface not being empty, start thread polling. Thread polling is used to call the active service interface of this level service interface;

S39. Determine whether the subordinate service interface of the next service interface is empty;

S40. In response to the lower-level service interface of the next service interface being empty, return to the step of obtaining the next service interface of this level to continue parsing the next service interface of the next service interface of this level until all service interfaces of this level are parsed. .

S41. In response to the lower-level service interface of the next service interface not being empty, obtain the service interface of the next level based on the lower-level service interface, and recursively parse the service interface of the next level until all service interfaces of all lower levels are parsed;

S42. Return to the step of obtaining the next service interface of this level to continue parsing the next service interface of the next service interface of this level until all service interfaces of this level are parsed.

This embodiment uses a unified use case service scheduling module to reduce repeated test code writing work, reduces the coupling degree of each service interface through the detection and analysis of service interface configuration files, and reduces the difficulty in locating system faults caused by module coupling. , the newly added software and hardware test modules will not interfere with the operation of the original modules, thereby reducing the coupling between system modules and enhancing system scalability.

The triggering process of the service interface trigger module will be described below with reference to Figure 3.

S51. The user executes the use case on the application layer software operation interface;

S52. The application layer software converts the user operation into a use case execution request, sends the use case execution request to the use case service scheduling module, and triggers the use case service scheduling module to find the service interface corresponding to the hash table execution.

This embodiment uses a unified use case service scheduling module to reduce repeated test code writing work, reduces the coupling degree of each service interface through the configuration of service interface files, and reduces the difficulty in locating system faults caused by module coupling. Newly added software The hardware test module will not interfere with the operation of the original modules, thus reducing the coupling between system modules and enhancing system scalability.

The following describes the calling process of the service interface calling module in conjunction with Figure 3.

S61. When the service interface calling module calls the corresponding service interface (callback interface), it will automatically submit the use case execution request to the Web server;

S62. The web server forwards the use case execution request to the corresponding use case service;

S63. The use case service calls hardware testing tools written in various programming languages, such as auduino (an open source electronic prototyping platform) control tool written in python (a computer programming language), or using C language (a computer programming language) Written PCIe (Peripheral Component Interconnect Express, a high-speed serial computer expansion bus standard) reset tool, etc.;

S64. Various hardware testing tools call hardware device (peripheral) drivers to perform hardware testing operations;

S65. The hardware device driver controls the physical/simulated hardware device to perform corresponding hardware test operations.

This embodiment reduces repetitive test code writing work through a unified use case service scheduling module. The use case service plug-in development framework based on the Web service interface makes the test modules developed by each test developer not dependent on each other, and the coupling degree of each service interface is improved. It is lower, which reduces the difficulty in locating system faults caused by module coupling. The newly added software and hardware test modules will not interfere with the operation of the original modules, thus reducing the coupling between system modules and enhancing system scalability.

Based on the same inventive concept, according to another aspect of the present application, as shown in Figure 5, an embodiment of the present application also provides a chip testing method, which is applied to the test system. The method includes:

S100. The application layer converts user operations into use case execution requests, and sends the use case execution requests to the use case service scheduling module based on the communication protocol;

S200. The use case service scheduling module calls the use case service on the virtual host based on the use case execution request;

S300. The use case service obtains test parameters from the use case execution request and configures the test parameters to the hardware device;

S400. The hardware device calls the corresponding algorithm acceleration engine to execute the test based on the test parameters, and returns the test results to the application layer through the use case service scheduling module.

Based on the same inventive concept, according to another aspect of the present application, as shown in FIG. 6, an embodiment of the present application also provides a computer device 30. The computer device 30 includes a processor 310 and a memory 320. The memory 320 stores There is a computer program 321 that can be run on the processor. When the processor 310 executes the program, it performs the steps of the above method.

Among them, the memory, as a non-volatile readable storage medium, can be used to store non-volatile software programs, non-volatile computer executable programs and modules, such as program instructions corresponding to the chip testing method in the embodiment of the present application. /module. The processor executes various functions of the device by running non-volatile software programs, instructions and modules stored in the memory. Functional application and data processing are the chip testing methods that implement the above method embodiments.

The memory may include a program storage area and a data storage area, where the program storage area may store an operating system and an application program required for at least one function; the storage data area may store data created according to use of the device, etc. In addition, the memory may include high-speed random access memory and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory optionally includes memory located remotely from the processor, and these remote memories may be connected to the local module through a network. Examples of the above-mentioned networks include but are not limited to the Internet, intranets, local area networks, mobile communication networks and combinations thereof.

Based on the same inventive concept, according to another aspect of the present application, as shown in Figure 7, an embodiment of the present application also provides a non-volatile readable storage medium 40. The non-volatile readable storage medium 40 stores A computer program 410 that performs the above method when executed by a processor.

Finally, it should be noted that those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing relevant hardware through a computer program. The program can be stored in a computer-readable storage medium. When the program is executed, it may include the processes of the above method embodiments. Among them, the storage medium of the program can be a magnetic disk, an optical disk, a read-only memory (Read-Only Memory, ROM) or a random access memory (Random Access Memory, RAM), etc. The foregoing computer program embodiments can achieve the same or similar effects as any of the corresponding foregoing method embodiments.

Those of skill would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the disclosure herein may 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 generally in terms of their functionality. Whether this functionality is implemented as software or hardware depends on the specific application and the design constraints imposed on the overall system. Those skilled in the art can implement the functions in various ways for each specific application, but such implementation decisions should not be interpreted as causing a departure from the scope of the embodiments disclosed in the present application.

The above are exemplary embodiments disclosed in the present application, but it should be noted that various changes and modifications can be made without departing from the scope of the embodiments disclosed in the present application as defined in the claims. The functions, steps and/or actions of the method claims in accordance with the disclosed embodiments described herein need not be performed in any particular order. The embodiment numbers disclosed in the above embodiments of the present application are only for description and do not represent the advantages or disadvantages of the embodiments. In addition, although the elements disclosed in the embodiments of the present application may be described or claimed in individual form, they may also be understood as plural unless explicitly limited to the singular.

It will be understood that, as used herein, the singular form "a" and "an" are intended to include the plural form as well, unless the context clearly supports an exception. It will also be understood that as used herein, "and/or" is meant to include any and all possible combinations of one or more of the associated listed items.

Those of ordinary skill in the art should understand that the above discussion of any embodiments is illustrative only and is not intended to imply It is indicated that the disclosed scope of the embodiments of the present application (including the claims) is limited to these examples; under the idea of the embodiments of the present application, the technical features in the above embodiments or different embodiments can also be combined, and there are the above present inventions. There are many other variations on different aspects of the application embodiments and are therefore not provided in detail for the sake of brevity. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the embodiments of the present application shall be included in the protection scope of the embodiments of the present application.

Claims

A chip testing system is characterized by including:

Application layer, communication layer, virtualization layer, hardware device layer and engine layer, wherein the communication layer includes a communication protocol; the virtualization layer includes a use case service scheduling module, a cloud platform, and a virtual machine deployed on the cloud platform. Services, virtual hosts, and use case services deployed on the virtual host, the hardware device layer includes hardware devices, and the engine layer includes an algorithm acceleration engine for hardware devices;

The application layer is configured to convert user operations into use case execution requests, and send the use case execution requests to the use case service scheduling module based on the communication protocol;

The use case service scheduling module is configured to call the use case service on the virtual host based on the use case execution request;

The use case service is configured to obtain test parameters from the use case execution request and configure the test parameters to the hardware device;

The hardware device is configured to call a corresponding algorithm acceleration engine to execute the test based on the test parameters, and return the test results to the application layer through the use case service scheduling module.
The system according to claim 1, wherein the application layer includes a user operation interface;

The algorithm acceleration engine is configured to return test results to the use case service of the virtual host after the test is completed;

The virtual host is configured to return the test results to the use case service scheduling module based on the use case service;

The use case service scheduling module is configured to further return the test results to the application layer and display them to the user operation interface.
The system according to claim 1, characterized in that the use case service scheduling module includes a service interface configuration module, and the service interface configuration module is configured as:

Obtain the virtual service deployed to the cloud platform, and write the corresponding service interface into the service interface configuration file hierarchically based on the virtual service, where each level includes at least one service interface, and each service interface includes a passive service interface , active service interface and subordinate service interface.
The system according to claim 3, characterized in that the passive service interface is used to execute command processing after receiving a command, the active service interface is used to actively report the running status of the service, and the lower-level service interface is used to associate subservice.
The system according to claim 4, wherein the running status of the service includes hardware interrupt notification, hardware abnormal status information, and other service abnormal status information.
The system according to claim 3, characterized in that the use case service scheduling module includes a service interface Detection module and service interface analysis module, the service interface detection module is configured as:

Regularly detect whether the service interface configuration file has changed;

In response to changes in the service interface configuration file, the service interface parsing module is triggered, and the service interface configuration file is updated through the service interface parsing module;

The service interface parsing module is configured to read the service interface configuration file and parse the service interface line by line.
The system according to claim 3, characterized in that the use case service scheduling module includes a service interface parsing module, and the service interface parsing module is configured as:

Get the next service interface among the service interfaces at this level;

Determine whether the next service interface is the last service interface among the service interfaces at this level;

In response to the next service interface not being the last service interface among the service interfaces at this level, determining whether the passive service interface of the next service interface is empty;

Based on the determination result of whether the passive service interface of the next service interface is empty, determine whether the active service interface of the next service interface is empty;

Based on the determination result of whether the active service interface of the next service interface is empty, determine whether the subordinate service interface of the next service interface is empty;

In response to the lower-level service interface of the next service interface being empty or not empty, return to the step of obtaining the next service interface of this level to continue parsing the next service interface of the next service interface of this level until the current level is parsed. All service interfaces.
The system according to claim 7, characterized in that, based on the judgment result of whether the passive service interface of the next service interface is empty, judging whether the active service interface of the next service interface is empty includes:

In response to the passive service interface of the next service interface being not empty, register the passive service interface in the service interface hash table, and determine whether the active service interface of the next service interface is empty, wherein the passive service The interface is used to call when receiving a test request;

In response to the passive service interface of the next service interface being empty, it is directly determined whether the active service interface of the next service interface is empty.
The system according to claim 7, characterized in that, based on the judgment result of whether the active service interface of the next service interface is empty, judging whether the subordinate service interface of the next service interface is empty includes:

In response to the active service interface of the next service interface being not empty, thread polling is started to determine whether the lower-level service interface of the next service interface is empty, where the thread polling is used to call the service interface of this level. Active service interface;

In response to the active service interface of the next service interface being empty, it is directly determined whether the subordinate service interface of the next service interface is empty.
The system according to claim 7, characterized in that, in response to the lower-level service interface of the next service interface being not empty, the step of obtaining the next service interface of this level is returned to continue to obtain the next service interface of this level. A service interface is parsed until all service interfaces at this level are parsed, including:

In response to the lower-level service interface of the next service interface not being empty, obtain the service interface of the next level based on the lower-level service interface, and recursively parse the service interface of the next level until all service interfaces of all lower levels are parsed;

Return to the step of obtaining the next service interface of this level to continue parsing the next service interface of the next service interface of this level until all service interfaces of this level are parsed.
The system according to claim 7, characterized in that the service interface parsing module is further configured to:

In response to the next service interface being the last service interface among the service interfaces at this level, the service interface parsing at this level is ended.
The system according to claim 1, characterized in that the use case service scheduling module includes a service interface trigger module, and the service interface trigger module is configured as:

In response to receiving the use case execution request, the corresponding service interface is found from the service interface hash table based on the message type field in the use case execution request.
The system according to claim 12, characterized in that the use case service scheduling module includes a service interface calling module, and the service interface calling module is configured as:

The corresponding service interface is called to send a use case execution request to the Web server, so as to forward the use case execution request to the use case service based on the Web server.
The system of claim 13, wherein the use case service is configured to call a hardware testing tool, and based on the hardware testing tool, calls a corresponding hardware peripheral driver to drive the corresponding hardware device to perform the corresponding hardware test. .
The system according to claim 14, characterized in that, based on the hardware testing tool, the corresponding hardware peripheral driver is called to drive the corresponding hardware device to perform the corresponding hardware test, including:

Based on the hardware testing tool, the corresponding hardware peripheral driver is called, and the hardware peripheral driver is used to drive the hardware device corresponding to the hardware testing tool to perform the corresponding hardware test, wherein the hardware device includes a physical hardware device, a simulation hardware equipment.
The system according to claim 15, wherein the hardware device is configured to call a corresponding hardware engine to execute corresponding test cases, and the test cases include compression, erasure, encryption and decryption, and audio and video encoding and decoding.
The system according to claim 1, characterized in that the virtualization layer is configured to provide test equipment, test environments, and various carriers for test case execution.
A chip testing method, characterized in that it is applied to a test system, the test system includes: an application layer, a communication layer, a virtualization layer, a hardware device layer and an engine layer, wherein the communication layer includes a communication protocol; The virtualization layer includes a use case service scheduling module, a cloud platform, virtual services and virtual hosts deployed on the cloud platform, and use case services deployed on the virtual host. The hardware device layer includes hardware devices, and the engine layer An algorithm acceleration engine is included for a hardware device; the method includes:

The application layer converts user operations into use case execution requests, and sends the use case execution requests to the use case service scheduling module based on the communication protocol;

The use case service scheduling module calls the use case service on the virtual host based on the use case execution request;

The use case service obtains test parameters from the use case execution request and configures the test parameters to the hardware device;

The hardware device calls the corresponding algorithm acceleration engine to execute the test based on the test parameters, and returns the test results to the application layer through the use case service scheduling module.
A computer device consisting of:

at least one processor; and

A memory storing a computer program executable on the processor, characterized in that when the processor executes the program, the steps of the method of claim 18 are performed.
A non-volatile readable storage medium, the non-volatile readable storage medium stores a computer program, characterized in that when the computer program is executed by a processor, the steps of the method as claimed in claim 18 are performed. .