A verification platform and verification method for system-level chip

Abstract

The present application discloses a verification platform and verification method for a system-level chip, the method comprising: a general verification methodology test instance generates constrained random parameters and random controls and stores them in a storage area of ​​a bus function model; a software test instance reads the random parameters and random controls from the storage area to configure the test of the system-level chip through a central processing unit; the execution status information of the software test instance is stored in the storage area; the general verification methodology test instance reads the execution status information, adjusts the constraints for generating random parameters and random controls according to the execution status information to exclude tested scenarios, and converts the execution status information into coverage data for coverage analysis.

Description

Technical Field

[0001] The present invention generally relates to the technical field of simulation verification, and in particular to a verification platform and a verification method of a system-level chip. Background Art

[0002] SoC (System on Chip) technology refers to the integration of the central processing unit (CPU) and input and output (I / O) peripherals, memory and other functional peripherals into a single chip. SoC technology can effectively reduce product area, improve product performance, reduce product power consumption and improve product reliability, so it has been widely used. However, due to the high cost of chips, in order to ensure the function and performance of SoC chips, a large amount of sufficient verification is required before the chip is taped out.

[0003] One way of verifying SoC chips in the prior art is to execute the test mode through the CPU, which requires running a software program on the CPU, and the software program configures the object under test, controls the generation of stimuli, and coordinates the simulation, but these cannot be done randomly at the software level. Therefore, only direct testing can be performed, that is, a fixed configuration is given to the object under test, a fixed stimulus is given to the object under test, and a fixed process test is performed on the object under test. In order to achieve test coverage, a lot of time is needed to build a large number of direct tests, which affects the simulation progress. At the same time, direct tests for some scenarios are extremely difficult or even impossible to build manually, which affects the improvement of test coverage. Moreover, since the software program cannot dynamically control the verification platform, each time a simulation of a verification platform configuration is started, it needs to be recompiled, which affects the efficiency of the simulation. Summary of the invention

[0004] The purpose of the present invention is to provide a verification platform and verification method of a system-on-chip to realize constrained random simulation at the software level and improve the execution coverage of software codes.

[0005] In one embodiment of the present application, a verification platform for a system-on-chip is disclosed, comprising: a bus function model unit connected to a bus, a storage area is provided in the bus function model unit, a central processing unit accesses the storage area through the bus, and a general verification methodology test instance directly accesses the storage area. The general verification methodology test instance generates constrained random parameters and random controls and stores them in the storage area, the software test instance reads the random parameters and random controls through the central processing unit and configures the test of the system-on-chip, and the execution status information of the software test instance is stored in the storage area through the central processing unit and read by the verification methodology test instance.

[0006] In a preferred example, the execution status information includes one or any combination of the following: whether the software test case runs successfully, whether there are errors during the running process and the error content, feedback from the system-level chip under test during the running process, and the execution coverage of the software code.

[0007] In a preferred example, the system-on-chip includes a central processing unit, a plurality of IP core modules and a bus, each of the IP core modules is respectively connected to the bus, and the central processing unit is connected to the bus.

[0008] In a preferred example, the bus function model unit and an IP core module are connected to the bus via a selection switch, and the interface protocol of the bus function model unit is the same as that of the IP core module and complies with the interface protocol of the bus.

[0009] In a preferred example, the bus function model unit has an interface that complies with the bus protocol and is directly connected to the bus.

[0010] In a preferred example, the general verification methodology test case reads the execution status information, adjusts the constraints of generating random parameters and random control according to the execution status information to exclude tested scenarios, and converts the execution status information into coverage data for coverage analysis.

[0011] In another embodiment of the present application, a system-on-chip verification method is also disclosed, including:

[0012] Generic Verification Methodology Test Cases generate constrained random parameters and random controls and store them in a storage area of ​​a bus functional model;

[0013] The software test instance reads the random parameters and random controls from the storage area and configures the system-on-chip test through a central processing unit;

[0014] Storing the execution status information of the software test instance in the storage area;

[0015] The general verification methodology test instance reads the execution status information, and adjusts the constraints of generating random parameters and random control according to the execution status information to exclude the tested scenarios.

[0016] In a preferred example, the method may further include converting the execution status information into coverage data for coverage analysis.

[0017] The present invention realizes constrained random testing at the software level through the storage area of ​​the bus function model unit, and can collect execution status information of software test cases to realize coverage analysis, thereby ensuring that test coverage requirements are met. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Non-limiting and non-exhaustive embodiments of the present application are described with reference to the following figures, wherein like reference numerals refer to like parts throughout the various figures unless otherwise specified.

[0019] Figure 1 A schematic diagram of a system-on-chip verification platform in an embodiment of the present application is shown.

[0020] Figure 2 A schematic diagram of a system-on-chip verification platform in another embodiment of the present application is shown.

[0021] Figure 3 A flow chart of a system-on-chip verification method in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0022] Various aspects and examples of the present application will now be described. The following description provides specific details for a thorough understanding and implementation of the description of these examples. However, those skilled in the art will appreciate that the present application can be practiced without many of these details.

[0023] Additionally, some well-known structures or functions may not be shown or described in detail to maintain clarity and to avoid unnecessarily obscuring the relevant description.

[0024] Description of some concepts:

[0025] IP core module: An IP (Intellectual Property) core module is a pre-designed or even verified component with a certain function for chip designers to integrate and select. Generally, multiple IP core modules are integrated in a SoC.

[0026] Coverage: Coverage is a measure of test completeness and effectiveness. Coverage is equal to the number of items executed at least once / the total number of items.

[0027] UVM: Universal Verification Methodology

[0028] BFM: Bus Function Model, bus function model.

[0029] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below in conjunction with the accompanying drawings.

[0030] In the first embodiment of the present application, a system-on-chip verification platform is disclosed. Figure 1FIG. 1 is a schematic diagram of a verification platform 100 in this embodiment. The verification platform 100 includes: a design to be tested 110 and a simulation environment 120. The design to be tested 110 includes a system-level chip that needs to be verified, and the function of the system-level chip 110 is tested through the simulation environment 120. The system-level chip to be verified includes a central processing unit (CPU), a plurality of IP core modules (e.g., IP1 to IP n ) and bus (BUS), each of the IP core modules IP1 to IP n Each IP core module IP1 to IP n It is a component with a certain specific function, for example, IP1 is a universal serial bus (USB) controller, IP2 is a video decoder, IP3 is an audio decoder, etc. It should be understood that each of the IP core modules is not limited to the components of the above examples, and can also be components of other specific functions, which are well known to those skilled in the art and will not be described in detail herein. The simulation environment 120 includes software test cases, universal verification methodology (UVM) test cases and bus function model unit (BFM), the software test instance is a software code (C program) written in C language, and the universal verification methodology test case is a test code written in universal verification methodology.

[0031] In one embodiment, the bus function model unit has a protocol that complies with the bus and is directly connected to the bus, for example, Advanced Microcontroller Bus Architecture (AMBA) protocol, Open Core Protocol (OCP), etc. In one embodiment, the general verification methodology test instance directly accesses the storage area in the bus function model unit. In one embodiment, a storage area 121 is provided in the bus function model unit, and it should be understood that the storage area is implemented by registers or associative arrays. The central processing unit can access the storage area 121 through the bus, and the general verification methodology test instance directly accesses the storage area 121 to write or read data into the storage area 121. By adding a bus function model unit in the simulation environment as a bridge for information interaction between the software program and the verification platform, constrained random simulation at the software level is achieved.

[0032] In this embodiment, the general verification methodology test case generates constrained random parameters and random controls, and stores the random parameters and random controls in the storage area 121. The software test case reads the random parameters and random controls through the central processing unit and configures the test of the system-level chip. Specifically, the system-level chip under test is configured with the random parameters, and the system-level chip under test is tested according to the random control process. The constrained random parameters and constrained random controls generated by the general methodology test case are dynamically transferred to the storage area of ​​the BFM. After being read by the software program running on the CPU, the software program can dynamically configure the object under test and dynamically coordinate the entire simulation, thereby realizing the constrained random test of the SoC, improving the verification coverage of the SoC, and accelerating the verification convergence of the SoC.

[0033] Furthermore, the execution status information of the software test instance is stored in the storage area by the central processing unit and read by the verification methodology test instance. In one embodiment, the execution status information of the software test case includes one of the following or any combination thereof: whether the software test case runs successfully, whether there are errors and their error contents during the running process, feedback from the system-level chip under test during the running process, and the execution coverage of the software code (for example, the line number of the software code executed, etc.). The general methodology test case can understand the running status of the software program in real time, and can make corresponding adjustments to the verification platform, so that the software program can dynamically control the verification platform.

[0034] In one embodiment, the general verification methodology test case reads the execution status information and converts the execution status information into coverage data, which is finally displayed in the form of a chart in a coverage analysis tool, so that the execution coverage of the software program can be intuitively understood, so as to increase direct test cases to directly test uncovered points, thereby achieving the coverage target.

[0035] Figure 2 A schematic diagram of a verification platform 200 in another embodiment is shown. The verification platform 200 is substantially the same as the verification platform 100, except that: the bus function model unit is connected to an IP core module IP select The bus is connected by selecting switch 211, and the bus function model unit is connected to the IP core module IP select The interface protocol of the bus is the same as that of the bus, and complies with the interface protocol of the bus. The selection switch 211 implements the bus model unit and the IP core module IP select Mutually exclusive gating with the bus. In this embodiment, if there is no redundant interface on the bus, an IP core module with the same bus interface as the bus function model unit is selected, and the bus function model unit is connected to the bus by controlling the gating.

[0036] In another embodiment of the present application, a system-on-chip verification method is also disclosed. Figure 3 The flowchart of the verification method in this embodiment is shown. The method includes:

[0037] Step S301 : The general verification methodology test instance generates constrained random parameters and random controls and stores them in a storage area of ​​a bus function model.

[0038] Step S303, the software test instance reads the random parameters and random control from the storage area through the central processing unit and configures the test of the system-level chip. Specifically, the system-level chip under test is configured with the random parameters, and the system-level chip under test is tested according to the random control process.

[0039] Step S305: storing the execution status information of the software test instance in the storage area.

[0040] Step S307 : the general verification methodology test instance reads the execution status information, and adjusts the constraints of generating random parameters and random control according to the execution status information to exclude the tested scenarios.

[0041] In one embodiment, the verification method may further include converting the execution status information into coverage data for coverage analysis. For uncovered test points, direct tests may be added to meet the test coverage requirement.

[0042] In this application, constrained random testing is implemented at the software level through the storage area of ​​the bus function model unit. At the same time, the execution status information of the software program can be collected to realize a dynamic control verification platform and accelerate coverage convergence.

[0043] It should be noted that in the application documents of this patent, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "including one" do not exclude the existence of other identical elements in the process, method, article or device including the elements. In the application documents of this patent, if it is mentioned that an action is performed according to an element, it means that the action is performed at least according to the element, which includes two situations: performing the action only according to the element, and performing the action according to the element and other elements. Expressions such as multiple, multiple, and multiple include 2, 2 times, 2 kinds, and more than 2, more than 2 times, and more than 2 kinds.

[0044] All documents mentioned in this specification are considered to be included in the disclosure of this application as a whole, so that they can be used as a basis for modification when necessary. In addition, it should be understood that the above is only a preferred embodiment of this specification and is not intended to limit the scope of protection of this specification. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of one or more embodiments of this specification should be included in the scope of protection of one or more embodiments of this specification.

[0045] In some cases, the actions or steps described in the claims may be performed in a different order than in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

Claims

1. A system-on-chip verification platform, characterized in that: include: A bus function model unit connected to the bus, wherein the bus function model unit is provided with a storage area, the central processing unit accesses the storage area through the bus, and the universal verification methodology test instance directly accesses the storage area; Among them, the general verification methodology test instance generates constrained random parameters and random controls and stores them in the storage area, the software test instance reads the random parameters and random controls through the central processing unit and configures the test of the system-level chip, and the execution status information of the software test instance is stored in the storage area through the central processing unit and read by the general verification methodology test instance.

2. The system-on-chip verification platform according to claim 1, characterized in that: The execution status information includes one or any combination of the following: whether the software test instance runs successfully, whether there are errors during the running process and the error content, feedback from the system-level chip under test during the running process, and execution coverage of the software code.

3. The system-on-chip verification platform according to claim 1, characterized in that: The system-level chip includes a central processing unit, a plurality of IP core modules and a bus, each of the IP core modules is respectively connected to the bus, and the central processing unit is connected to the bus.

4. The system-on-chip verification platform according to claim 3, characterized in that: The bus function model unit is connected to the bus via a selection switch with an IP core module. The interface protocol of the bus function model unit is the same as that of the IP core module and complies with the interface protocol of the bus.

5. The system-on-chip verification platform according to claim 1, characterized in that: The bus functional model unit has an interface conforming to the bus protocol and is directly connected to the bus.

6. The system-on-chip verification platform according to claim 1, characterized in that: The general verification methodology test instance reads the execution status information, adjusts the constraints of generating random parameters and random control according to the execution status information to exclude tested scenarios, and converts the execution status information into coverage data for coverage analysis.

7. A method for verifying a system-on-chip, characterized in that: include: Generic Verification Methodology Test Cases generate constrained random parameters and random controls and store them in a storage area of ​​a bus functional model; The software test instance reads the random parameters and random controls from the storage area and configures the system-on-chip test through a central processing unit; Storing the execution status information of the software test instance in the storage area; The general verification methodology test instance reads the execution status information and adjusts the constraints of generating random parameters and random control according to the execution status information to exclude the tested scenarios.

8. The verification method of the system-on-chip according to claim 7, characterized in that: Also includes: The execution status information is converted into coverage data for coverage analysis.

Images