CN117539764A

CN117539764A - Verification method and device of system on chip, storage medium and electronic equipment

Info

Publication number: CN117539764A
Application number: CN202311525114.3A
Authority: CN
Inventors: 李正玉
Original assignee: Beijing Horizon Information Technology Co Ltd
Current assignee: Beijing Horizon Information Technology Co Ltd
Priority date: 2023-11-15
Filing date: 2023-11-15
Publication date: 2024-02-09

Abstract

The invention discloses a verification method and device of a system on chip, a storage medium and electronic equipment, wherein the verification method of the system on chip comprises the following steps: determining a design to be tested, a verification requirement and a test case for verifying the design to be tested of the system on chip; determining to-be-processed tasks and description information of each to-be-processed task respectively corresponding to a plurality of test subsystems in the to-be-tested design according to the to-be-tested design and the verification requirement; scheduling a corresponding test subsystem to process each task to be processed based on the test case and the description information of each task to be processed to obtain a processing result of each task to be processed; and determining the verification result of the system on chip according to the test case and the processing result of each task to be processed. The scheduling and verification of each subsystem of the design to be tested are realized. The scheduling mode makes the execution process of each task to be processed modularized, and can improve the readability and maintainability of the verification code on the basis of realizing verification of the SoC.

Description

Verification method and device of system on chip, storage medium and electronic equipment

Technical Field

The disclosure relates to the technical field of chip design, and in particular relates to a verification method and device of a system on chip, a computer readable storage medium and electronic equipment.

Background

A System on Chip (SoC) is an integrated circuit with a dedicated target that contains the complete System and has the entire contents of embedded software. In the whole SoC chip development, before the chip enters production, the design of the SoC chip needs to be ensured to completely meet the requirement specification, all potential risks are solved, all defects are corrected, so that the problem that hardware faults which cannot be corrected are found after the chip is flowed can be avoided, and the later problem risk is reduced. As the complexity of SoC chip size and functionality increases, the difficulty of verification increases. The large number of modules on the SoC to be verified and the complex scheduling flow among the modules bring great challenges to the verification of the whole SoC.

Disclosure of Invention

In order to solve the technical problems, the present disclosure provides a method, an apparatus, a storage medium, and an electronic device for verifying a system on a chip, so as to implement modularized verification of the system on a chip.

In a first aspect of the present disclosure, there is provided a method for verifying a system-on-chip, including:

determining a design to be tested, a verification requirement and a test case for verifying the design to be tested of the system on chip;

determining tasks to be processed and description information of each task to be processed, which correspond to a plurality of test subsystems in the design to be tested, according to the design to be tested and the verification requirement;

Scheduling a corresponding test subsystem to process each task to be processed based on the test case and the description information of each task to be processed to obtain a processing result of each task to be processed;

and determining the verification result of the system on chip according to the test case and the processing result of each task to be processed.

In a second aspect of the present disclosure, there is provided a verification apparatus of a system on a chip, including:

the first determining module is used for determining a design to be tested, a verification requirement and a test case for verifying the design to be tested of the system on chip;

the second determining module is used for determining tasks to be processed and description information of the tasks to be processed, which correspond to the plurality of test subsystems in the design to be tested, respectively according to the design to be tested and the verification requirement;

the scheduling module is used for scheduling the corresponding testing subsystem to process each task to be processed based on the testing case and the description information of each task to be processed to obtain the processing result of each task to be processed;

and the third determining module is used for determining the verification result of the system-on-chip according to the test case and the processing result of each task to be processed.

In a third aspect of the present disclosure, there is provided a computer-readable storage medium storing a computer program for executing the verification method of the system-on-chip provided by the embodiment of the first aspect of the present disclosure.

In a fourth aspect of the present disclosure, there is provided an electronic device, including:

a processor;

a memory for storing the processor-executable instructions;

the processor is configured to read the instruction from the memory and execute the instruction to implement the verification method of the system on chip provided by the embodiment of the first aspect of the present disclosure.

In a fifth aspect of the present disclosure, a computer program product is presented, which, when executed by an instruction processor in the computer program product, performs the method of verifying a system on a chip proposed by the embodiment of the first aspect of the present disclosure.

When the verification of the system-on-chip is performed, the design to be tested, the verification requirement and the test case for verifying the design to be tested corresponding to the system-on-chip are determined first; and determining the tasks to be processed and the description information of the tasks to be processed, which correspond to the multiple test subsystems in the design to be tested, according to the design to be tested and the verification requirement, wherein the tasks to be processed and the description information thereof can be determined according to the execution sequence of the tasks to be processed, the transmission of data streams and the dependency relationship among the components in the system, which are described by the directed acyclic graph. Scheduling a corresponding test subsystem to process each task to be processed based on the test case and the description information of each task to be processed to obtain a processing result of each task to be processed; and finally, determining the verification result of the system on chip according to the test case and the processing result of each task to be processed. According to the method, the corresponding test subsystem is scheduled according to the test case and the description information of each task to be processed, so that the scheduling and verification of each subsystem to be tested is realized, the execution process of each task to be processed is modularized in a scheduling mode, and the readability and maintainability of verification codes can be improved on the basis of verifying the system on chip.

Drawings

Fig. 1 is a schematic diagram of a component architecture of a verification system of a system-on-chip provided in an exemplary embodiment of the present disclosure.

Fig. 2 is a schematic diagram of a composition structure of an SoC chip according to an exemplary embodiment of the present disclosure.

Fig. 3 is a schematic diagram of a framework of a verification environment built for the SoC chip shown in fig. 2 based on a TestBench platform according to an exemplary embodiment of the disclosure.

Fig. 4 is a schematic diagram of a processing flow of a service to be processed according to an embodiment of the disclosure.

Fig. 5 is a schematic diagram of a processing flow of a service to be processed based on a directed acyclic graph according to an embodiment of the disclosure.

Fig. 6 is a flow chart illustrating a verification method of a system on a chip according to an exemplary embodiment of the present disclosure.

Fig. 7 is a flow chart illustrating a verification method of a system on chip according to another exemplary embodiment of the present disclosure.

Fig. 8 is a flow chart illustrating a verification method of a system on a chip according to still another exemplary embodiment of the present disclosure.

Fig. 9 is a flow chart illustrating a verification method of a system on chip according to still another exemplary embodiment of the present disclosure.

Fig. 10 is a flow chart illustrating a verification method of a system on a chip according to still another exemplary embodiment of the present disclosure.

Fig. 11 is a flow chart illustrating a verification method of a system on chip according to still another exemplary embodiment of the present disclosure.

Fig. 12 is a schematic diagram of the composition structure of a verification device of a system-on-chip provided in an exemplary embodiment of the present disclosure.

Fig. 13 is a schematic diagram of a composition structure of a verification device of a system-on-chip provided in another exemplary embodiment of the present disclosure.

Fig. 14 is a schematic diagram of a composition structure of an electronic device provided in an exemplary embodiment of the present disclosure.

Detailed Description

For the purpose of illustrating the present disclosure, exemplary embodiments of the present disclosure will be described in detail below with reference to the drawings, it being apparent that the described embodiments are only some, but not all embodiments of the present disclosure, and it is to be understood that the present disclosure is not limited by the exemplary embodiments.

It should be noted that: the relative arrangement of the components and steps, numerical expressions and numerical values set forth in these embodiments do not limit the scope of the present disclosure unless it is specifically stated otherwise.

Summary of the application

A SoC chip is a system-on-a-chip that integrates a plurality of functional components, for example, a plurality of functional modules such as a processor, a memory, and a peripheral may be integrated on the SoC chip. In order to ensure that the SoC chip can operate normally, the SoC chip may be verified. When the SoC chip is verified, the SoC system verification environment needs to simulate a real chip system scheduling flow, and each subsystem of the SoC is correctly scheduled to test whether the SoC chip meets the design specification, can realize the expected function and can work normally under various conditions.

A test platform (TestBench) is a virtual platform that simulates the input stimulus and output verification of a real environment, which is commonly used in SoC verification. Because the number of subsystems involved in the SoC system scheduling is generally relatively large, and complex data and flow dependency relationships exist among the subsystems, the SoC system scheduling flow is generally very complex.

In general, system scheduling software development generally adopts a multithreading mode, scheduling of each subsystem is realized by using an independent thread, and flow control among the subsystems is realized by using multithreading communication, so that system scheduling of the whole SoC is realized. In this way, the SoC system dispatcher has a large number of threads, thread communication, branch statements, and complex function calls, and has poor code readability and difficult maintenance.

In order to solve the above-mentioned problems, an embodiment of the present disclosure provides a verification method for a system on chip, where tasks to be processed and description information thereof are determined according to an execution sequence of each task to be processed described by a directed acyclic graph, a data stream transfer, and a dependency relationship between each component in the system, and corresponding test subsystems are scheduled according to test cases and description information of each task to be processed, so as to implement scheduling and verification of each subsystem of an SoC.

Exemplary System

Fig. 1 is a schematic diagram of a component architecture of a verification system of a system-on-chip provided in an exemplary embodiment of the present disclosure. As shown in fig. 1, the verification system 10 of the system-on-chip includes a verification platform 11 and a verification object 12. Wherein the verification object 12 is a design under test (Design Under Test, DUT) of a system on chip to be verified, and the verification platform 11 is a verification environment built for verifying the DUT.

Fig. 2 is a schematic diagram of a composition structure of an SoC chip according to an exemplary embodiment of the present disclosure. As shown in fig. 2, the SoC chip is provided with a plurality of subsystems, the subsystems are interconnected through a bus, a central processing unit (Central Processing Unit, CPU) is responsible for configuration and scheduling of the subsystems, and a memory is used for storing the output of each subsystem. The off-chip device 0 and the off-chip device 1 provide inputs to the SoC chip.

Fig. 3 is a schematic diagram of a framework of a verification environment built for the SoC chip shown in fig. 2 based on a TestBench platform according to an exemplary embodiment of the disclosure. As shown in fig. 3, the test platform (testtest) includes test cases (TestCase) and Environment components (Env). Wherein Env comprises a plurality of verifying intellectual property (Verify Intellectual Property, VIP) cores, such as VIP0, VIP1 and VIP2 shown in fig. 3. In this verification platform, VIP0 replaces off-chip device 0 in fig. 2, binding at the interface of off-chip device 0 and DUT. VIP1 replaces off-chip device 1 in fig. 2, binding at the interface of off-chip device 1 and DUT. VIP2 replaces the on-chip CPU in fig. 2, is bound at the interface of the CPU and bus, and TestCase calls VIP2 to complete the system dispatch of the DUT.

To more clearly illustrate the verification system provided by the embodiments of the present disclosure, an exemplary service to be processed is provided, and a process flow for processing the service to be processed by using a subsystem in a DUT is described as follows:

1) The subsystem A obtains the original input data from the VIP0, processes the data to obtain a_out, stores the a_out into a memory address a_out_addr, and transmits the a_out_addr through a bus.

2) The subsystem B obtains the original input data from the VIP1, processes the data to obtain b_out, stores the b_out into a memory address b_out_addr, and transmits the b_out_addr through a bus.

3) After the processing of both subsystem a and subsystem B is completed, VIP2 schedules subsystem C. The subsystem C acquires a_out_addr and b_out_addr transmitted by the bus; reading a_out from a_out_addr, reading b_out from b_out_addr, and processing to obtain c_out; the c_out is stored to the memory address c_out_addr and transmitted through the bus.

4) After the processing of the subsystem C is completed, the VIP2 dispatches the subsystem D. The subsystem D acquires the c_out_addr transmitted by the bus, reads the c_out from the address, and calculates d_out; the d_out is stored to the memory address d_out_addr and transmitted through the bus.

5) After the processing of the subsystem C and the subsystem D is completed, the VIP2 dispatches the subsystem E. The subsystem E acquires c_out_addr and d_out_addr transmitted by a bus; c_out is read from c_out_addr, d_out is read from d_out_addr, and e_out is obtained through calculation; e_out is stored to the memory address e_out_addr and e_out_addr is transferred through the bus. And finishing the whole processing flow.

Fig. 4 is a schematic diagram of a processing flow of a service to be processed provided in an embodiment of the present disclosure, and as shown in fig. 4, the flow chart can only show a start-up flow and a sequence of each subsystem, and cannot well characterize the dependency of data. For example, fig. 4 only characterizes subsystem E as being able to be started up after it has been completed, and does not characterize that the input to subsystem E is dependent on the output of subsystem C and subsystem D. In the prior art, the traditional flow shown in fig. 4 is expressed and developed, and the SoC system dispatcher has a large number of threads, thread communication, branch sentences and complex function calls, so that the verification code has poor readability and difficult maintenance.

Fig. 5 is a schematic diagram of a processing flow of a service to be processed according to a directed acyclic graph, where each circle (vertex) in fig. 5 represents a processing task executed by a subsystem, and an input port and an output port have unique numbers, and an arrow (directed edge) represents a jump relationship of the task and also represents transmission of commands and data.

As shown in fig. 5, a ring may have multiple input ports with strong binding relationships between the input ports. Taking the processing task executed by the subsystem C as an example, the subsystem C has two input ports, the two input ports have a strong binding relationship, and the processing task executed by the subsystem C is started only after the two input ports have both received the correct command and data. One ring may have multiple output ports with no binding relationship between the output ports. After each processing task is completed, each corresponding output port outputs the result of executing the processing task to carry out the subsequent flow.

The adoption of the directed acyclic graph can solve the characterization problems of processes such as the jump of tasks, the transmission of data and commands, the check of dependent conditions and the like. The directed acyclic graph shown in FIG. 5 is a clearer characterization of the order of execution and dependency of tasks than the conventional flow diagram shown in FIG. 4.

In the verification system provided by the embodiment of the disclosure, when the SoC is verified, firstly, a DUT corresponding to the SoC, a verification requirement and a test case for verifying the DUT are determined; and then determining the tasks to be processed and the description information of the tasks to be processed, which correspond to the test subsystems in the DUT, respectively according to the DUT and the verification requirements, wherein the tasks to be processed and the description information thereof can be determined according to the execution sequence of the tasks to be processed, the transmission of data streams and the dependency relationship among the components in the system, which are described by the directed acyclic graph. Scheduling a corresponding test subsystem to process each task to be processed based on the test case and the description information of each task to be processed to obtain a processing result of each task to be processed; and finally, determining the verification result of the SoC according to the test case and the processing result of each task to be processed. According to the verification system, the corresponding test subsystem is scheduled according to the test cases and the description information of each task to be processed, so that the scheduling and verification of each subsystem to be tested is realized, the execution process of each task to be processed is modularized in a scheduling mode, and the readability and maintainability of verification codes can be improved on the basis of verifying the SoC.

Exemplary method

Fig. 6 is a flow chart illustrating a verification method of a system on a chip according to an exemplary embodiment of the present disclosure. The method can be applied to electronic equipment, and as shown in fig. 6, the verification method of the system on chip provided by the embodiment of the disclosure includes the following steps:

in step S601, a design to be tested, a verification requirement, and a test case for verifying the design to be tested of the system on chip are determined.

The method provided by the embodiment of the disclosure may be performed by an electronic device in which an authentication system of a system-on-chip is deployed, and in particular may be performed by an authentication apparatus (hereinafter referred to as an authentication apparatus) of the system-on-chip in the electronic device.

When it is required to verify that each subsystem of a system-on-chip is properly scheduled and that each subsystem is capable of performing the intended function, the verification device needs to determine the Design Under Test (DUT) of the system-on-chip to be verified, the verification requirements, and the test case (TestCase) for verifying the DUT.

In the whole chip development, before the SoC chip enters production, the design of the SoC chip needs to be ensured to completely meet the requirement specification, all potential risks are solved, all defects are corrected, the problem that hardware faults which cannot be corrected are found after the chip is flowed is avoided, and the problem risk of later stages is reduced. The design to be tested is the register transfer level (Register Ttransfer Level, RTL) code designed to validate the SoC. The code can be divided into subsystem modules by a verifier according to the requirement, further refined into functional modules and then written into hardware description language files of RTL level. A test bench (TestBench) is built based on the DUT to simulate and control inputs and environments of the DUT, including generating functional models, input stimuli, or on-line data interactions, etc. The verification flow is to confirm the function and scheduling correctness of the DUT and ensure that the SoC product meets the design requirements.

In the embodiment of the disclosure, the verification requirement is a verification requirement determined according to a verification plan formulated by a verification target. Test cases (TestCase) are test cases encoded according to a verification plan formulated by a verification target. From the test cases, test data input to the DUT and expected reference results may be determined.

Step S602, determining to-be-processed tasks and description information of each to-be-processed task corresponding to a plurality of test subsystems in the to-be-tested design according to the to-be-tested design and the verification requirement.

First, the verification device may determine from the DUT all the subsystems that the DUT includes. According to the verification requirement, it can be determined which subsystems are required to be used for executing the current verification task in all the subsystems included in the DUT, namely, which subsystems in the DUT are the subsystems to be verified currently, and the subsystems are used as test subsystems. In general, the test subsystems corresponding to different verification tasks are different, or the scheduling sequences of the test subsystems are different.

And then, the verification device determines the task to be processed corresponding to each test subsystem according to the DUT and the verification requirement, and determines the description information of each task to be processed.

In the embodiment of the disclosure, the currently-to-be-verified test subsystem in the DUT at least comprises one subsystem, and the description information of the to-be-processed task is used for describing the scheduling and executing information of the to-be-processed task. The description information of the tasks to be processed can be determined according to the execution sequence of each task to be processed, the transmission of data streams and the dependency relationship among each component in the system, which are described by the directed acyclic graph as shown in fig. 5.

Step S603, based on the test cases and the description information of the tasks to be processed, scheduling the corresponding test subsystems to process the tasks to be processed, and obtaining processing results of the tasks to be processed.

The test case comprises test data input to the DUT, and the scheduling sequence of the test subsystem for executing each task to be processed can be determined according to the description information of each task to be processed. And scheduling the corresponding test subsystem to process each task to be processed based on the test data and the scheduling sequence of the test subsystem of each task to be processed, so as to obtain the processing result of each task to be processed.

Step S604, determining the verification result of the system on chip according to the test case and the processing result of each task to be processed.

The test cases include expected processing results of each task set by the verifier in addition to the test data input to the DUT. And determining the verification result of each test subsystem corresponding to each task to be processed according to the expected processing result of each task to be processed and the processing result obtained by the actual test, and further determining the verification result of the on-chip system.

According to the verification method of the system on chip, the corresponding test subsystem is scheduled through the test cases and the description information of each task to be processed, so that scheduling and verification of each subsystem of the design to be tested are achieved, the execution process of each task to be processed is modularized through the scheduling mode, and on the basis of verifying the SoC, the readability and maintainability of verification codes can be improved.

In some embodiments, the step S604 "determining the verification result of the on-chip system according to the test case and the processing result of each task to be processed" may be implemented by steps S6041 to S6043 shown in fig. 7 on the basis of the embodiment shown in fig. 6.

Step S6041, determining the reference result of each task to be processed according to the test case.

The test case includes a reference result of each task to be processed, which is an expected processing result of each task set by the verifier.

Step S6042, determining the consistency check result of each task to be processed according to the reference result and the processing result of each task to be processed.

And comparing the reference result of each task to be processed with the processing result obtained by the actual test to determine whether the reference result is consistent with the processing result obtained by the actual test. If the processing result obtained by the actual test is consistent with the reference result, determining that the consistency check result of the task to be processed is consistent. If the processing result obtained by the actual test is inconsistent with the reference result, determining that the consistency check result of the task to be processed is inconsistent.

In the embodiment of the disclosure, the processing result obtained by the actual test is consistent with the reference result, which may mean that the processing result is identical to the reference result, or may mean that the error between the processing result and the reference result is within a preset error range. Correspondingly, the processing result obtained by the actual test is inconsistent with the reference result, which may mean that the processing result is different from the reference result, or that the error between the processing result and the reference result exceeds a preset error range.

Step S6043, determining the verification result of the on-chip system according to the consistency verification result of each task to be processed.

After determining the consistency check results of all the tasks to be processed according to the step S6042, if the consistency check results of all the tasks to be processed are consistent, determining that the verification result of the on-chip system is verification passing. Otherwise, when the consistency check result of at least one task to be processed is inconsistent, determining that the verification result of the system on chip is verification failure. Thus, the system-on-chip is modularized and automatically verified.

In some embodiments, when the verification result of the system-on-chip is determined to be that the verification fails, the verification device may output a prompt that the verification fails, and the verification personnel modifies the DUT according to the prompt. And (5) carrying out verification again after modification until the consistency verification results of all the tasks to be processed are consistent.

In some embodiments, when the verification result of the on-chip system is determined to be that the verification fails, the prompt information output by the verification device that the verification fails may include a subsystem to be modified, where the subsystem to be modified is a test subsystem that the consistency verification result of the corresponding task to be processed is inconsistent. So that a verifier can quickly determine the subsystem to be modified in the DUT and the verification efficiency is improved.

In some embodiments, step S602 "determining, according to the design to be tested and the verification requirement, the task to be processed and the description information of each task to be processed corresponding to the plurality of test subsystems in the design to be tested" in the above embodiment may include the following steps S6021 to S6023 shown in fig. 8:

in step S6021, a plurality of subsystems included in the design to be tested is determined.

To more clearly illustrate the implementation of the disclosed embodiments, the verification method provided by the disclosed embodiments will be described in detail below with respect to the design under test DUT shown in fig. 3 and with respect to the verification task shown in fig. 5.

The verification means determines a plurality of subsystems comprised by the design under test DUT, for example subsystem a, subsystem B, subsystem C, subsystem D, subsystem E, subsystem F and subsystem G (subsystem F and subsystem G not shown in fig. 3).

In step S6022, a plurality of test subsystems are determined from the plurality of subsystems according to the verification requirement.

The verification device determines all subsystems (subsystems A to G) included in the DUT according to the verification requirement, wherein the subsystems are the subsystems which need to be used for executing the current verification task, namely, the subsystems in the DUT are the subsystems to be verified currently, and the subsystems are used as test subsystems. For example, the verification device determines that the subsystem required for executing the current verification task includes a subsystem a, a subsystem B, a subsystem C, a subsystem D and a subsystem E according to the verification requirement, and determines the subsystem a, the subsystem B, the subsystem C, the subsystem D and the subsystem E as the test subsystem.

Step S6023, determining the tasks to be processed and the description information of the tasks to be processed, which correspond to the test subsystems respectively, according to the test subsystems and the verification requirements.

The validation task may be comprised of a plurality of tasks to be processed, each task to be processed being performed by a corresponding one of the test subsystems. And determining the task to be processed corresponding to each test subsystem according to the test subsystems and the verification requirements. For example, test subsystem a performs task a, test subsystem B performs tasks B, …, and test subsystem E performs task E.

The description information of each task to be processed may include task description information and message description information. The task description information is used to describe information of the tasks themselves (circles as shown in fig. 5), and the message description information is used to describe information of transmission messages (arrows as shown in fig. 5) between the tasks.

In the embodiment of the disclosure, according to the verification requirement, a testing subsystem is determined among a plurality of subsystems included in the DUT, and then based on the testing subsystem and the verification requirement, a task to be processed and description information thereof corresponding to each testing subsystem are determined, so that a foundation is provided for realizing modular scheduling.

In some embodiments, step S6023 "determining the task to be processed and the description information of the task to be processed corresponding to each test subsystem according to the multiple test subsystems and the verification requirement" in the above embodiments may include step S60231 and step S60232 shown in fig. 9.

Step S60231, determining the task to be processed and the starting condition of each task to be processed respectively corresponding to each test subsystem according to the test subsystems and the verification requirements.

The verification device determines the to-be-processed tasks corresponding to the test subsystems according to the test subsystems and the verification requirements, and when determining the description information of the to-be-processed tasks, the verification device determines the starting conditions of the to-be-processed tasks. The starting condition of the task to be processed is used for determining whether to trigger the task.

In the embodiment of the disclosure, the starting condition of each task to be processed can be determined according to the test subsystem executing each task to be processed and the dependency relationship of each task to be processed. For example, in the directed acyclic graph shown in fig. 5, a task a executed by a test subsystem a depends on an environment component VIP0, a task B executed by a test subsystem B depends on an environment component VIP1, that is, executing the task a requires test data output by the environment component VIP0, executing the task B requires test data output by the environment component VIP1, based on this, it is determined that a start condition of the task a is that the test subsystem a receives test data output by VIP0, and a start condition of the task B is that the test subsystem B receives test data output by VIP 1. The task C executed by the test subsystem C depends on the task A and the task B, namely the execution results of the task A and the task B are needed when the task C is executed, and the starting condition of the task C is determined to be that the test subsystem C receives the execution results of the task A and the task B. And similarly, determining that the starting condition of the task D is the execution result of the task C received by the test subsystem D, and the starting condition of the task E is the execution result of the task C and the task D received by the test subsystem E.

Step S60232, determining task description information and message description information of each task to be processed according to the starting condition of each task to be processed.

In the embodiment of the present disclosure, the task description information is used to describe the information of the task itself, and may be represented by using a data structure shown in the following table 1:

TABLE 1 data structure of task description information

All fields shown in table 1 may be divided into a Task attribute field and a Task dependency check field, wherein the Task attribute field may include task_id, entry_port_num, entry_port_id, cfg_id, cfg_len, entry_port_num, entry_port_id, entry_msg_priority, and Consumer_task_id; the task dependency check fields may include a producer_task_id and a producer_task_check_port_id.

Based on the configuration entry ID of the task to be processed in Table 1, the configuration table may be consulted to determine the configuration values that need to be sent to the DUT. The configuration table entry data structure is shown in table 2:

table 2 configuration table entry data structure

Fields	Description of the invention
		Cfg_id	Configuration ID
Cfg_len	Configuration length
		Cfg_addr[]	Configuring an address array, wherein the array size is equal to Cfg_len
Cfg_value[]	Configuring an array of values, the array size being equal to cfg_len

The message description information is information describing the transmission of messages between tasks, and may be represented by the following data structure shown in table 3:

table 3 data structure of message description information

Fields	Description of the invention
		msg_id	Message ID
priority	Priority level
		Ingress_port_id	Input port ID of a subsequent task
Egress_port_id	Output port ID of a pre-stage task
		Producer_task_id	Front-end task ID
Consumer_task_id	Post-stage task ID
		Payload_len	Message payload length
Payload[]	Message load array, array size equal to payload_len

And determining task description information and message description information of each task to be processed according to the starting conditions of each task to be processed and the information of the task.

For example, the task description information of the determined task a may be as follows:

for example, the message description information of task a may be determined as follows:

in the embodiment of the disclosure, the inspection device determines each task to be processed and description information thereof through each test subsystem and verification requirement, wherein the description information comprises task description information and message description information. When the test subsystem executes the task to be processed, the test subsystem determines to trigger the execution of the task of the current level according to the received message description information, and executes the task according to the task description information to obtain an execution result of the task. And then determining a lower-level task according to the task description information, generating and sending message description information to a later-level test subsystem. Therefore, the modularization of the execution process of each task to be processed is realized, and the modularization development of the verification code is facilitated.

In some embodiments, step S603 "in the foregoing embodiments, based on the test case and the description information of each task to be processed, schedules the corresponding test subsystem to process each task to be processed, to obtain the processing result of each task to be processed", may be implemented by the following steps shown in fig. 10:

step S6031, determining test data according to the test cases.

The test data is data determined by a verifier according to a verification requirement. In an actual test process, the test data may be multiple sets, and the number of each set of test data may be determined by the number of interfaces input to the DUT. As shown in fig. 3 for a DUT, each set of test data may include 2 test data.

Step S6032, storing the test data.

Because the test data can be of various types, in order to adopt unified verification codes and realize modularized scheduling, the test data is stored after being acquired, and the storage address of the test data is obtained. In the embodiment of the disclosure, the storage address of the test data corresponding to the task a is denoted as a_addr, and the storage address of the test data corresponding to the task B is denoted as b_addr.

Step S6033, based on the storage address of the test data, the task description information and the message description information in the description information of each task to be processed, scheduling the corresponding test subsystem to process each task to be processed, and obtaining the processing result of each task to be processed.

The verification device uses VIP2 to schedule each test subsystem in the DUT to execute the corresponding task to be processed based on the storage address of the test data, the task description information and the message description information in the description information of each task to be processed, and obtains the processing result of each task to be processed.

In the embodiment of the disclosure, the storage address of the test data is carried in the transmitted message, but not the test data itself, so that when the scheduling sequence is changed or the information such as the type of the test data is changed, the verification code is not required to be modified, and only the transmitted message is required to be modified. Moreover, the storage address is adopted for transmission, and the character length occupied by the storage address is fixed, so that the length of the message is fixed, and the unified verification code is conveniently written.

In some embodiments, step S6033 "in the foregoing embodiments, based on the storage address of the test data, the task description information and the message description information in the description information of each task to be processed, schedules the corresponding test subsystem to process each task to be processed, to obtain the processing result of each task to be processed", may include steps S60331 to S60333 as shown in fig. 11:

step S60331, determining the current task to be processed based on the task description information of each task to be processed.

When the verification device schedules each test subsystem in the DUT, the current task to be processed is determined according to the task description information of each task to be processed. Taking each task to be processed as shown in fig. 5 as an example, the current task to be processed is determined to be a task a or a task B according to the tasks a-E to be processed.

Step S60332, generating a first route message based on the message description information of the current task to be processed and the storage address of the test data.

And if the current task to be processed is the task A, generating a first routing message corresponding to the task A according to the message description information of the task A and the storage address a_addr of the test data.

And if the current task to be processed is the task B, generating a first routing message corresponding to the task B according to the message description information of the task B and the storage address b_addr of the test data.

Step S60333, based on the first route information, scheduling a test subsystem corresponding to the current task to be processed to process the current task to be processed, and obtaining a processing result of the current task to be processed.

And the verification device dispatches the test subsystem corresponding to the current task to be processed through the VIP2 according to the first routing message. For example, the verification device schedules the test subsystem a through VIP2 according to the first routing message corresponding to the task a, so that the test subsystem a executes the task a to obtain a processing result of the task a, which is denoted as a_out. For example, the verification device schedules the test subsystem B through VIP2 according to the first routing message corresponding to the task B, so that the test subsystem B executes the task B to obtain a processing result of the task B, and the processing result is denoted as b_out.

In the embodiment of the disclosure, the verification device determines a current task to be processed based on task description information, and schedules the test subsystem to execute the corresponding task to be processed based on the generated first routing information, so as to determine the task to be processed, and automatically schedules the corresponding test subsystem to execute the task to be processed based on the realization.

In some embodiments, step S60333 "based on the first routing message, the scheduling the test subsystem corresponding to the current task to process the current task to obtain the processing result of the current task to be processed" in the above embodiments may include the following steps S3331 to S3333:

step S3331, determining that the current task to be processed meets the task execution condition based on the first routing message and the task description information of the current task to be processed.

In the embodiment of the present disclosure, whether the current task to be processed meets the task execution condition may be determined according to the following steps: first, based on Task identifications (including a former-stage Task identification producer_task_id and a latter-stage Task identification consumer_task_id) in a first routing message and Task identifications (including a former-stage Task identification producer_task_id and a current-stage Task identification task_id) in Task description information of a currently-to-be-processed Task, whether the first routing message meets legal requirements is determined. When the first routing message meets the legal requirement, determining that the current task to be processed meets the task execution condition based on the task identification in the first routing message and the dependency relationship in the task description information of the current task to be processed.

In the embodiment of the disclosure, whether the first routing message meets the legal requirement is determined and whether the first routing message is sent to the user or not is determined, if the former Task identifier producer_task_id in the first routing message is matched with the former Task identifier producer_task_id in the Task description information of the current Task to be processed, and the latter Task identifier consumer_task_id in the first routing message is matched with the current Task identifier task_id in the Task description information of the current Task to be processed, whether the first routing message meets the legal requirement is determined, and then whether the current Task to be processed meets the Task execution condition is continuously determined.

If the former Task identifier producer_task_id in the first routing message is not matched with the former Task identifier producer_task_id in the Task description information of the current Task to be processed, or the latter Task identifier consumer_task_id in the first routing message is not matched with the current Task identifier task_id in the Task description information of the current Task to be processed, determining that the first routing message does not meet the legal requirement, and no operation is required to be executed at this time.

In the embodiment of the disclosure, the verification device may determine whether the current task to be processed meets the task execution condition based on the task identifier in the first routing message and the dependency relationship in the task description information of the current task to be processed. When the method is implemented, the number of the previous-stage task identifications Producer_task_id in the task identifications in the first routing message and the number of the previous-stage task identifications Producer_task_id in the dependency relationship in the task description information of the current task to be processed can be compared to determine. Because a routing message is sent by a pre-stage testing subsystem, comparing whether the number of task identifiers is equal is equivalent to comparing whether the number of received first routing messages is equal to the number of tasks on which the current task to be processed depends. If the tasks are equal, determining that the current task to be processed meets the task execution conditions. If the tasks are not equal, the other testing subsystems are not executed, and the waiting is continued.

Step S3332, determining configuration parameters required for executing the current task to be processed based on the first routing message and the task description information of the current task to be processed.

The configuration parameters required by the current task to be processed can be obtained by inquiring the configuration list item ID (Cfg_id) of the current task to be processed. The configuration parameters may include parameters of a model previously deployed for the test subsystem and processing results from performing the pre-stage tasks.

And step S3333, based on the configuration parameters, scheduling a test subsystem corresponding to the current task to execute the current task to be processed to obtain a processing result of the current task to be processed.

And dispatching a test subsystem corresponding to the current task to be processed according to the configuration parameters, and processing the current task to be processed to obtain a processing result.

In some embodiments, after the processing result of the current task to be processed is obtained, the processing result may be stored, to obtain the storage address of the processing result. And generating a new routing message based on the storage address and the description information of the currently pending task. And (3) until all tasks are executed, and thus, processing results of all tasks to be processed are obtained. The specific process is as follows:

Step S6033 "based on the storage address of the test data, the task description information and the message description information in the description information of each task to be processed, schedules the corresponding test subsystem to process each task to be processed to obtain the processing result of each task to be processed" in the above embodiment may further include the following steps S60334 to S60336 as shown in fig. 11:

step S60334, determining the next task to be processed of the current task to be processed based on the task description information of the current task to be processed.

For example, the current task to be processed is task a, and after task a is executed, determining that the next task to be processed of task a is task C according to a next task ID (consumer_task_id) in task description information of task a.

Step S60335 generates a second routing message based on the message description information of the next task to be processed, and the memory address of the test data and/or the processing result of the current task to be processed.

And determining the input port ID of the next task to be processed, the output port ID of the previous task, the previous task ID, the next task ID and the message load length (namely the length of a storage address of test data and/or a storage address of a processing result of the current task to be processed) according to the message description information of the next task to be processed, and generating a new routing message.

And step 60336, based on the second routing message, scheduling the test subsystem corresponding to the next task to be processed to process the next task to be processed, and obtaining a processing result of the next task to be processed.

And the verification device dispatches a test subsystem corresponding to the next task to be processed through the VIP2 according to the second routing message. For example, the verification device schedules the test subsystem C through VIP2 according to the second routing message corresponding to the task C, so that the test subsystem C executes the task C to obtain a processing result of the task C, which is denoted as c_out.

Here, since the task C depends on the task a and the task B, before the test subsystem C executes the task C, the test subsystem C needs to be scheduled to process the task C on the premise that the task C is judged to satisfy the task execution condition according to the procedure shown in the steps S3331 to S3333. And obtaining a processing result of the task C.

In the embodiment of the disclosure, after the current task to be processed is executed, the verification device continues to determine the next task to be processed based on the task description information, and the test subsystem is scheduled to execute the corresponding next task to be processed based on the generated second routing information, so that the next task to be processed is determined, the steps are repeated, and the corresponding test subsystem is automatically scheduled to execute all the tasks to be processed, so that the processing result of each task to be processed is obtained.

Exemplary apparatus

Based on the foregoing embodiments, the embodiments of the present disclosure provide a verification apparatus for a system on a chip, where each module included in the apparatus and each unit included in each module may be implemented by a processor in a computer device; of course, the method can also be realized by a specific logic circuit; in practice, the processor may be a central processing unit (Central Processing Unit, CPU), microprocessor (Microprocessor Unit, MPU), digital signal processor (Digital Signal Processing, DSP), or field programmable gate array (Field Programmable Gate Array, FPGA), or the like.

Fig. 12 is a schematic diagram of a composition structure of a verification device of a system-on-chip according to an exemplary embodiment of the present disclosure, and as shown in fig. 12, a verification device 1200 of a system-on-chip includes:

a first determining module 1201, configured to determine a design to be tested, a verification requirement, and a test case for verifying the design to be tested of the system on chip;

a second determining module 1202, configured to determine, according to the design to be tested and the verification requirement, tasks to be processed and description information of the tasks to be processed, where the tasks to be processed correspond to a plurality of test subsystems in the design to be tested respectively;

The scheduling module 1203 is configured to schedule, based on the test case and the description information of each task to be processed, a corresponding test subsystem to process each task to be processed, so as to obtain a processing result of each task to be processed;

and a third determining module 1204, configured to determine a verification result of the system on chip according to the test case and the processing result of each task to be processed.

On the basis of the embodiment shown in fig. 12, the embodiment of the disclosure further provides a verification apparatus of the system on chip shown in fig. 13, as shown in fig. 13, the third determining module 1204 includes:

a first determining unit 12041, configured to determine, according to the test case, a reference result of each task to be processed;

a second determining unit 12042, configured to determine a consistency check result of each task to be processed according to the reference result and the processing result of each task to be processed;

a third determining unit 12043, configured to determine a verification result of the system-on-chip according to the consistency verification result of each task to be processed.

In some embodiments, as shown in fig. 13, the second determining module 1202 includes:

a fourth determining unit 12021, configured to determine a plurality of subsystems included in the design to be tested;

A fifth determining unit 12022, configured to determine a plurality of test subsystems from the plurality of subsystems according to the verification requirement;

a sixth determining unit 12023, configured to determine, according to the multiple test subsystems and the verification requirement, a task to be processed and description information of the task to be processed, where the task to be processed corresponds to each test subsystem.

In some embodiments, the sixth determining unit 12023 is further configured to:

determining a task to be processed and starting conditions of the tasks to be processed, which correspond to the test subsystems respectively, according to the test subsystems and the verification requirements;

and determining task description information and message description information of each task to be processed according to the starting conditions of each task to be processed.

In some embodiments, as shown in fig. 13, the scheduling module 1203 includes:

a seventh determining unit 12031, configured to determine test data according to the test case;

a storage unit 12032 for storing the test data;

the scheduling unit 12033 is configured to schedule the corresponding test subsystem to process each task to be processed based on the storage address of the test data, the task description information and the message description information in the description information of each task to be processed, so as to obtain a processing result of each task to be processed.

In some embodiments, the scheduling unit 12033 is further configured to:

determining a current task to be processed based on the task description information of each task to be processed;

generating a first routing message based on the message description information of the current task to be processed and the storage address of the test data;

and based on the first routing message, scheduling a test subsystem corresponding to the current task to be processed to process the current task to be processed, so as to obtain a processing result of the current task to be processed.

In some embodiments, the scheduling unit 12033 is further configured to:

determining a next task to be processed of the current task to be processed based on task description information of the current task to be processed;

generating a second routing message based on the message description information of the next task to be processed and the storage address of the test data and/or the processing result of the current task to be processed;

and based on the second routing message, scheduling a test subsystem corresponding to the next task to be processed to process the next task to be processed, so as to obtain a processing result of the next task to be processed.

In some embodiments, the scheduling unit 12033 is further configured to:

Determining that the current task to be processed meets a task execution condition based on the first routing message and task description information of the current task to be processed;

determining configuration parameters required for executing the current task to be processed based on the first routing message and the task description information of the current task to be processed;

and based on the configuration parameters, scheduling a test subsystem corresponding to the current task to execute the current task to be processed to obtain a processing result of the current task to be processed.

In some embodiments, the scheduling unit 12033 is further configured to:

determining that the first routing message meets legal requirements based on a task identifier in the first routing message and a task identifier in task description information of the current task to be processed;

and determining that the current task to be processed meets a task execution condition based on the task identification in the first routing message and the dependency relationship in the task description information of the current task to be processed.

It should be noted that: the description of the verification device embodiment items of the system-on-chip above, which is similar to the method description above, has the same advantageous effects as the method embodiment. For technical details not disclosed in the embodiments of the verification device of the system-on-chip provided in the present disclosure, those skilled in the art will understand with reference to the description of the embodiments of the method of the present application, which are not described herein again.

Exemplary electronic device

Fig. 14 is a schematic diagram of the composition structure of an electronic device provided in an exemplary embodiment of the present disclosure, and as shown in fig. 14, the electronic device 1400 includes at least one processor 1401 and a memory 1402.

The processor 1401 may be a Central Processing Unit (CPU) or other form of processing unit having data processing and/or instruction execution capabilities and may control other components in the electronic device 1400 to perform the desired functions.

Memory 1402 may include one or more computer program products that may include various forms of computer-readable storage media, such as volatile memory and/or non-volatile memory. Volatile memory can include, for example, random Access Memory (RAM) and/or cache memory (cache) and the like. The non-volatile memory may include, for example, read Only Memory (ROM), hard disk, flash memory, and the like. The processor 1401 may execute one or more computer program instructions to implement the verification method of the system-on-chip and/or other desired functions of the various embodiments of the disclosure above.

In one example, the electronic device 1400 may further include: an input device 1403 and an output device 1404, which are interconnected by a bus system and/or other forms of connection mechanisms (not shown).

The input device 1403 may also include, for example, a keyboard, a mouse, and the like.

The output device 1404 may output various information to the outside, which may include, for example, a display, a speaker, a printer, and a communication network and a remote output apparatus connected thereto, etc.

Of course, only some of the components of the electronic device 1400 that are relevant to the present disclosure are shown in fig. 14 for simplicity, components such as buses, input/output interfaces, etc. are omitted. In addition, electronic device 1400 may include any other suitable components depending on the particular application.

Exemplary computer program product and computer readable storage Medium

In addition to the methods and apparatus described above, embodiments of the present disclosure may also provide a computer program product comprising computer program instructions which, when executed by a processor, cause the processor to perform steps in a method of verifying a system-on-chip of the various embodiments of the present disclosure described in the "exemplary methods" section above.

The computer program product may write program code for performing the operations of embodiments of the present disclosure in any combination of one or more programming languages, including an object oriented programming language such as Java, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computing device, partly on the user's device, as a stand-alone software package, partly on the user's computing device, partly on a remote computing device, or entirely on the remote computing device or server.

Furthermore, embodiments of the present disclosure may also be a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, cause the processor to perform steps in a method of verifying a system-on-chip of the various embodiments of the present disclosure described in the above section "exemplary method".

A computer readable storage medium may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example but not limited to, a system, apparatus, or device including electronic, magnetic, optical, electromagnetic, infrared, or semiconductor, or a combination of any of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium would include the following: an electrical connection having one or more wires, a portable disk, a hard disk, random Access Memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

The basic principles of the present disclosure have been described above in connection with specific embodiments, but the advantages, benefits, effects, etc. mentioned in this disclosure are merely examples and are not to be considered as necessarily possessed by the various embodiments of the present disclosure. Furthermore, the specific details disclosed herein are for purposes of illustration and understanding only, and are not intended to be limiting, since the disclosure is not necessarily limited to practice with the specific details described.

Various modifications and alterations to this disclosure may be made by those skilled in the art without departing from the spirit and scope of this application. Thus, the present disclosure is intended to include such modifications and alterations insofar as they come within the scope of the appended claims or the equivalents thereof.

Claims

1. A method of verification of a system-on-chip, comprising:

2. The method of claim 1, wherein the determining the verification result of the system-on-chip according to the test case and the processing result of each task to be processed comprises:

determining a reference result of each task to be processed according to the test case;

determining a consistency check result of each task to be processed according to the reference result and the processing result of each task to be processed;

and determining the verification result of the system-on-chip according to the consistency verification result of each task to be processed.

3. The method of claim 1, wherein the determining, according to the design to be tested and the verification requirement, the task to be processed and the description information of each task to be processed respectively corresponding to the plurality of test subsystems in the design to be tested includes:

determining a plurality of subsystems included in the design to be tested;

determining a plurality of test subsystems from the plurality of subsystems according to the verification requirement;

and determining the tasks to be processed and the description information of the tasks to be processed, which correspond to the test subsystems respectively, according to the test subsystems and the verification requirements.

4. A method according to claim 3, wherein the determining, according to the plurality of test subsystems and the verification requirement, the task to be processed and the description information of the task to be processed respectively corresponding to each test subsystem includes:

5. The method according to any one of claims 1-4, wherein the scheduling the corresponding test subsystem to process the tasks to be processed based on the test case and the description information of the tasks to be processed to obtain the processing result of the tasks to be processed includes:

determining test data according to the test cases;

storing the test data;

and scheduling a corresponding test subsystem to process each task to be processed based on the storage address of the test data, task description information and message description information in the description information of each task to be processed, and obtaining a processing result of each task to be processed.

6. The method of claim 5, wherein the scheduling the corresponding test subsystem to process the tasks to be processed based on the storage address of the test data, the task description information and the message description information in the description information of the tasks to be processed, to obtain the processing result of the tasks to be processed, includes:

7. The method of claim 6, wherein the scheduling the corresponding test subsystem to process the tasks to be processed based on the storage address of the test data, the task description information and the message description information in the description information of the tasks to be processed, to obtain the processing result of the tasks to be processed, further comprises:

8. The method of claim 6, wherein the scheduling, based on the first routing message, the test subsystem corresponding to the current task to be processed to process the current task to be processed, to obtain a processing result of the current task to be processed, includes:

9. The method of claim 8, wherein the determining that the current task to be processed satisfies a task execution condition based on the first routing message and task description information of the current task to be processed comprises:

10. A verification apparatus of a system-on-chip, comprising:

11. A computer readable storage medium storing a computer program for executing the method of verification of a system on chip as claimed in any one of the preceding claims 1-9.

12. An electronic device, the electronic device comprising:

a processor;

a memory for storing the processor-executable instructions;

the processor being configured to read the instructions from the memory and execute the instructions to implement the method of verifying a system on a chip as claimed in any one of the preceding claims 1-9.