Chip verification method and device, computer equipment, computer readable storage medium and computer program product

Abstract

The invention relates to a chip verification method and device, computer equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: establishing a verification environment of a UVM test platform; calling a test case; in the verification environment, verifying the chip according to the test case to obtain a verification result; wherein the test case is generated by using a TCL script according to a test requirement. According to the method, the test case written by the TCL is introduced, various different scenes can be infinitely tested only by loading and one-time compiling in the simulation stage, a test platform does not need to be repeatedly modified, and a large amount of test time is saved.

Description

Technical Field

[0001] The present application relates to the technical field of computer graphics, and in particular to a chip verification method, apparatus, computer equipment, computer-readable storage medium, and computer program product. Background Art

[0002] The traditional UVM (Universal Verification Methodology) verification method based on SystemVerilog language has the characteristics of object-oriented language encapsulation, inheritance and polymorphism. It also has unique advantages in the field of verification due to its random constraints, coverage and other characteristics.

[0003] However, in large-scale SoC verification, in order to test whether the DUT (Design Under Test) has achieved all the functional characteristics listed in its data sheet, the response to abnormal conditions and robustness, it is generally possible to iteratively add test cases or modify and expand the range of random constraints to ensure that the test covers all functional characteristics. No matter which method is used to change the test platform, it must be recompiled. For large SoC systems, the compilation time is very long. This testing method is clumsy and lacks flexibility. Summary of the invention

[0004] Based on this, it is necessary to provide a chip verification method, apparatus, computer equipment, computer-readable storage medium and computer program product that can save testing time in response to the above technical problems.

[0005] In a first aspect, the present application proposes a chip verification method, the method comprising:

[0006] Build the verification environment of UVM test platform;

[0007] Call the test case;

[0008] In the verification environment, verifying the chip according to the test case to obtain a verification result;

[0009] The test cases are generated using TCL scripts based on test requirements.

[0010] In one of the embodiments, in the verification environment, verifying the chip according to the test case to obtain a verification result includes:

[0011] Parsing the test case through the verification environment to obtain a stimulus signal;

[0012] According to the excitation signal, the chip is verified to obtain an output signal;

[0013] The output signal is compared with an expected value, and a verification result is generated according to the comparison result.

[0014] In one embodiment, the stimulus signal includes an operation type and a test parameter, the operation type includes a read operation and a write operation, and the test parameter includes a register address and a front door access path;

[0015] The verifying the chip according to the excitation signal includes:

[0016] A register model is determined according to the register address; wherein the register model is used to perform read and write access to a target register corresponding to the register address in the chip through the front door access path according to the operation type.

[0017] In one of the embodiments, the test parameters also include write data;

[0018] The register model performs read and write access to a target register in the chip according to the operation type, including:

[0019] When the operation type is a read operation, the register model reads data from a target register corresponding to the register address;

[0020] When the operation type is a write operation, the register model writes the write data into a target register corresponding to the register address.

[0021] In one of the embodiments, when the chip includes multiple hosts and multiple slaves, the test case encapsulates the bus interface timing and the transmission path of the stimulus signal;

[0022] The verifying the chip according to the excitation signal includes:

[0023] According to the transmission path of the excitation signal, the excitation signal is connected to the corresponding interconnection layer, so that the corresponding interconnection layer accesses the target slave according to the bus interface timing.

[0024] In one of the embodiments, the stimulus signal includes test parameters, expected return values ​​and breakpoints;

[0025] The method further comprises:

[0026] When the chip is verified using the test parameters, the actual return value at the breakpoint is compared with the expected return value to generate a verification result;

[0027] The printer of the UVM test platform is used to print and output the verification result.

[0028] In a second aspect, the present application proposes a chip verification device, the device comprising:

[0029] Build a module to build the verification environment of the UVM test platform;

[0030] The verification module is used to call the test case; in the verification environment, the chip is verified according to the test case to obtain the verification result; wherein the test case is generated according to the test requirements using the TCL script.

[0031] In a third aspect, the present application proposes a computer device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of the above method when executing the computer program.

[0032] In a fourth aspect, the present application proposes a computer-readable storage medium having a computer program stored thereon, wherein the computer program implements the steps of the above method when executed by a processor.

[0033] In a fifth aspect, the present application proposes a computer program product, comprising a computer program, which implements the steps of the above method when executed by a processor.

[0034] The above chip verification method, device, computer equipment, computer readable storage medium and computer program product build a verification environment of the UVM test platform according to the test requirements, and use TCL scripts to generate test cases. During the test, the test case is called, and the chip is verified according to the test case in the verification environment to obtain the verification result. This application introduces the test case written by TCL, which only needs to be loaded in the simulation stage. One compilation can test a variety of different scenarios infinitely, without repeatedly modifying the test platform, saving a lot of testing time. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the drawings required for use in the embodiments of the present application or related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0036] Figure 1 A structural block diagram of a chip verification system in one embodiment;

[0037] Figure 2 A schematic diagram of a flow chart of a traditional UVM test in one embodiment;

[0038] Figure 3 A schematic diagram of a chip verification method according to an embodiment;

[0039] Figure 4 A block diagram of a SoC architecture in one embodiment;

[0040] Figure 5 A schematic diagram of a chip verification method according to another embodiment;

[0041] Figure 6 is a structural block diagram of a chip verification device in one embodiment;

[0042] Figure 7 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0043] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0044] See also Figure 1 An embodiment of the present application provides a chip verification system 10, including a UVM test platform 101, a simulator 102 and a test case generation module 103.

[0045] UVM test platform 101 (Testbench) is used to provide a verification environment, which includes a stimulus sequence module (sequence), a driver (Driver), a monitor (Monitor), and a scoreboard (Scoreboard). Among them, the stimulus sequence module reads the test case to generate a stimulus signal; the driver converts these stimulus signals into input signals that can be received by the DUT (Design Under Test); the monitor monitors the output signal generated by the DUT according to the input signal; the scoreboard compares the output signal with the expected value to determine whether the function is correct. Furthermore, DUT refers to the logic module that actually needs to be verified, which is usually described in RTL (Verilog / VHDL).

[0046] The simulator 102 is used to simulate the operation of the chip in a real hardware environment, and gradually execute the RTL code to implement the function, timing behavior and register transfer logic of the DUT. In addition, the simulator 102 can also provide functions such as waveform viewing, log recording and code tracking. Specifically in this embodiment, the simulator 102 receives and processes the stimulus signal, and generates an output signal according to the input signal and internal logic.

[0047] The test case generation module 103 is used to generate test cases using TCL scripts. TCL (Tool Command Language) is a powerful, concise and easy-to-learn scripting language that is widely used in electronic design automation (EDA), automated testing, embedded system development and other fields. The test case generation module 103 extracts functional points, performance requirements and constraints from the design specification according to the test requirements, and generates test cases using TCL scripts, wherein the test cases define the verification objectives, test conditions, execution steps and expected results, so as to verify whether the DUT meets the functional requirements or specific behavioral characteristics.

[0048] See also Figure 2 , Figure 2 Path L1 in the figure shows the traditional UVM test process based on SystemVerilog. After analyzing the test requirements, formulating the test plan and setting up the test environment, the verification engineer starts to write test cases according to the functional regulations listed in the functional feature list. Every change to the test case requires recompiling the test platform. After iterative modification and passing the compilation, it enters the simulation. When a test phenomenon that does not match the functional description specification appears during the simulation process, the verification engineer needs to track the bug, locate the cause of the problem, and feedback to the designer to modify the code and recompile the test platform. After the simulation passes the basic test cases mentioned in the functional feature list, regression is performed to collect coverage data, analyze whether there are omissions in the test, add new test cases based on the analysis results, or modify and expand the random constraint range, and re-enter the compilation process. The cycle is repeated until all possible situations are covered. The time consumption caused by the compilation of the entire process accounts for a very high proportion.

[0049] Figure 2 Path L2 in the figure shows the test process of introducing Tcl to write test cases. Since the test cases written in Tcl only need to be loaded in the simulation stage, one compilation can test multiple different scenarios. For newly added test cases, simulation testing can be directly entered without re-compilation. Compared with the conventional process, it saves the time consumption caused by compilation and saves the time consumption of simulation data on the path to a certain extent, allowing verification engineers to focus more on the functional verification of the target slave, which has obvious advantages.

[0050] In the above chip verification system, after the verification engineer analyzes the test requirements, formulates the test plan and builds the test environment, he uses TCL scripts to write test cases according to the functional regulations listed in the functional characteristics list. During the test, the UVM test platform calls the test cases. In the test environment, the chip is verified according to the test cases to obtain the verification results. This application introduces test cases written in TCL, which only need to be loaded in the simulation stage. One compilation can test a variety of different scenarios infinitely, without repeatedly modifying the test platform, saving a lot of testing time.

[0051] See also Figure 3 In one embodiment, the present application provides a chip verification method, the chip verification method comprising:

[0052] Step 302: Build a verification environment for the UVM test platform.

[0053] Specifically, in the UVM testbench, the verification environment is built based on the UVM methodology, which is a complex test framework used to simulate, drive and monitor the behavior of the DUT and collect verification results and coverage.

[0054] The verification environment is built by analyzing the test requirements. For example, after the verification engineer understands the functional characteristics of the test, determines the target to be verified, the verification scope, the stimulus mode and the coverage target, the basic framework of the verification environment is built according to the above information. The basic framework includes a stimulus sequence module, a driver, a monitor, and a scoreboard. Furthermore, the verification engineer also selects a suitable simulator, determines the simulation environment, and defines the interface method between the UVM test platform and the simulator.

[0055] Step 304: call the test case, verify the chip in the verification environment according to the test case, and obtain the verification result. The test case is generated according to the test requirements using the TCL script.

[0056] Specifically, test cases are generated based on test requirements. Verification engineers list the test scenarios that need to be verified based on the functional requirements of the test plan, and define specific test cases for each test scenario, including stimulus signals, input constraints, and output expectations. Then, test cases are written using TCL scripts, and during testing, they are integrated into the verification environment by calling the test cases.

[0057] Optionally, in a verification environment, the chip is verified according to a test case to obtain a verification result, including:

[0058] The test cases are parsed through the verification environment to obtain the stimulus signal.

[0059] According to the excitation signal, the chip is verified to obtain the output signal.

[0060] The output signal is compared with the expected value, and a verification result is generated based on the comparison result.

[0061] Specifically, the verification environment includes a stimulus sequence module, a driver, a monitor, and a scoreboard. Among them, the stimulus sequence module of the verification environment reads and parses the test cases to generate stimulus signals; the driver converts these stimulus signals into input signals that can be received by the chip; the chip generates an output signal in response to the received input signal; the monitor monitors the output signal and transmits it to the scoreboard; the scoreboard compares the output signal with the expected value. If the output signal matches the expected value, it is considered that the function is normal; otherwise, it is considered that the function is abnormal. It should be understood that the above chip is the hardware behavior simulated by the simulator, and the output signal of the chip is the response signal of the simulator.

[0062] The above chip verification method builds a test environment according to the test requirements and uses TCL scripts to write test cases. During the test, the test case is called to verify the chip and obtain the verification result. This application introduces test cases written in TCL, which only need to be loaded in the simulation stage. One compilation can test multiple different scenarios infinitely without repeatedly modifying the test platform, saving a lot of testing time.

[0063] Optionally, the stimulus signal includes an operation type and a test parameter, the operation type includes a read operation and a write operation, and the test parameter includes a register address and a front door access path.

[0064] The above steps verify the chip according to the stimulus signal, including:

[0065] According to the register address, the register model is determined, wherein the register model is used to read and write access to the target register in the chip through the front door access path according to the operation type.

[0066] Specifically, the register model is the core component of the register abstraction layer (RAL) of the UVM test platform. It is an abstract representation of chip registers in the verification environment, which is used to generate stimulus signals and model the behavior of each register of the chip. Therefore, the definition of the register model must be consistent with the register parameters of the chip. When defining the register model, the verification engineer must fully consider all the parameters of the chip register, including address, data width, field, access rights, reset value, bus protocol, and special behavior. These parameters directly determine the accuracy of the register model and the functional coverage capability of the verification environment. With an accurate register model, the verification engineer can efficiently generate stimulus signals, call the register read and write interfaces (such as reg.write and reg.read) of UVM, and interact with the chip to verify whether the functions and behaviors of the chip registers meet the design specifications.

[0067] The front-door access path refers to directly communicating with the chip through standard hardware interfaces, such as AXI, APB, I2C, etc., to perform register read and write operations. It should be understood that in conventional technology, a back-door access path is also included, and back-door access (Backdoor Access) operates by directly accessing the internal register storage of the DUT (usually a memory-mapped address) without relying on the bus protocol. The front-door access is used in the embodiment of the present application because the front-door access simulates the normal operating process of the hardware, including handshake protocols, signal timing, etc., and more realistically simulates the data flow.

[0068] Different registers in the chip have unique physical addresses, and the register model and the front-door access path are implemented based on these physical addresses. Therefore, different registers correspond to different register models and front-door access paths.

[0069] Exemplarily, by encapsulating the write task reg_write and the read task reg_read, the address of the register to be accessed, the front door access path, the operation type, the write data wr_data and other information are passed to the predefined TCL as test parameters to generate a test case through the TCL script; wherein, in the test case, the operation type is generated by the corresponding operation type code (for example, 0 for write, 1 for read). In the process of calling the test case, the parsed operation type code and the above test parameters are passed to the predefined task access_ral_reg in the GTB_TCL_CMD module in SystemVerilog, and then the operation type code and the above test parameters are passed to the register model, and the register model finally calls UVM's own reg.write and reg.read to achieve read and write access to the target register through the front door access path.

[0070] The above chip verification method can be applied to a variety of application scenarios. Two modules that communicate with each other, such as the CPU configuring the registers of a slave, directly or indirectly map the output signal to the input signal of another slave according to a certain rule. Due to specific functional limitations, conventional test cases cannot randomly configure these registers. To verify this mapping relationship, configuring a large number of registers and capturing a large number of signals will lead to a complex and redundant test environment with poor reusability. Changes in the signal path will also cause the environment to be recompiled. By writing the stimulus sequence for register reading and writing through Tcl, the target register can be read and written directly, which plays an irreplaceable role in environmental maintenance and improving verification efficiency.

[0071] Optionally, the register model performs read and write access to a target register in the chip through a front-door access path according to the operation type, including:

[0072] When the operation type is a read operation, the register model reads data from the target register corresponding to the register address.

[0073] When the operation type is a write operation, the register model writes the write data into the target register corresponding to the register address.

[0074] Specifically, the register model transmits the stimulus signal to the hardware interface of the simulator through the bus to perform read and write operations on the target register. Furthermore, for write operations, whether the write operation is successful should be recorded; for read operations, the read-back data should be extracted from the register model and returned to the UVM test platform. In the verification environment, it is compared with the expected data to verify whether the register operation meets the design requirements of the chip.

[0075] The chip verification method passes the test parameters to the predefined TCL by encapsulating the register access method so that the register model performs read and write operations on the target register. This application utilizes the flexibility of the register model and Tcl script of UVM to ensure the efficiency and scalability of register verification.

[0076] Optionally, when the chip includes multiple hosts and multiple slaves, the test case encapsulates the bus interface timing and the transmission path of the stimulus signal.

[0077] According to the stimulus signal, the chip is verified, including:

[0078] According to the transmission path of the excitation signal, the excitation signal is connected to the corresponding interconnection layer, so that the corresponding interconnection layer accesses the target slave according to the bus interface timing.

[0079] See also Figure 4 , Figure 4 The typical SoC architecture block diagram is shown, which consists of multiple host (master) and multiple slave (slave) devices. Data transmission is achieved between each master and interconnect layer (interconnect), slave and interconnect, and master and slave through bus interfaces such as AXI, AHB, APB, etc.

[0080] Traditional test cases based on system verilog and UVM combined to build a test platform to simulate the DUT require verification engineers to write stimuli, then drive the stimuli to the top layer of the DUT at the output interface of the host Master, and then pass through layers of interconnects to finally reach the slave. For large-scale SoC verification, due to data path and bandwidth limitations, the simulation time is very long, which invisibly reduces the verification efficiency. For more complex topology architectures, additional routing configuration may be required. Verification engineers have to pay attention to configurations other than the target slave function, resulting in additional investment of time and energy.

[0081] Based on this, the introduction of Tcl combined with UVM for testing in the embodiment of the present application is a targeted solution to solve the above pain points.

[0082] To solve the slow simulation speed caused by long data paths, bandwidth limitations and other reasons, verification engineers can try to use Tcl to encapsulate the process (proc) that meets the timing of various bus interfaces. By predetermining the transmission path of the stimulus signal, any level from interconnect_0 to interconnect_n can be selected. Finally, by controlling the stimulus through parameter transmission, access to downstream devices can be quickly achieved.

[0083] Taking the AXI bus as an example, the AXI bus is divided into five channels: AW, W, B, AR, and R. Each channel has a corresponding valid and ready handshake mechanism and other control signals. Among them, valid means valid; ready means ready. Under the premise of meeting the timing, the verification engineer controls the relevant control signals in the AW, W, B, AR, and R channels, waits for the valid and ready handshakes of each channel to end, checks whether the response returned by the slave meets the expectations, releases the signal, and then executes the next operation. Because it is separated from the upper-level bus logic, any combination of signals such as AWLEN, AWSIZE, AWID, AWBURST, and AWCACHE can be realized to test circuit performance, channel ID and QOS randomization testing, etc. For example, control the delay of ready pulling high, the maximum outstanding number supported by the master device, and multiple masters accessing a bus at the same time, and the robustness of the circuit. As the data path is shortened and the low-bandwidth bus is avoided, the simulation efficiency is significantly improved.

[0084] In addition, Tcl testing can control the start and end of simulation at any time without waiting for all initialization processes to be completed step by step. It can also dynamically generate clocks to make up for the defects of bandwidth limitation. This method has wide applicability and can be used not only for AMBA bus, but also for any interface protocol. As long as the timing logic is mastered, it can be easily implemented. Therefore, the above method can save simulation time to a certain extent on the basis of saving compilation time.

[0085] The above chip verification method uses the existing UVM test environment to flexibly select the node level of the stimulus source, simulate the timing of bus protocols such as APB / AHB / AXI, and send customized stimulus to access slave devices, which significantly improves the simulation efficiency. At the same time, it dynamically generates a clock of a specified frequency, which saves simulation time while saving compilation time.

[0086] See also Figure 5 Optionally, the stimulus signal includes a test parameter, an expected return value, and a breakpoint. The chip verification method of the embodiment of the present application also includes:

[0087] Step 502: When verifying the chip using the test parameters, compare the actual return value at the breakpoint with the expected return value to generate a verification result.

[0088] Step 504: Use the printer of the UVM test platform to print and output the verification result.

[0089] Specifically, by writing TCL process (proc), simulation flow can be controlled, and specific signals or events in the simulation are supervised in conjunction with UVM printing mechanism. Further, UVM test platform provides macros such as uvm_info, uvm_warning, uvm_error and uvm_fatal to print information of different severity levels, and these macros allow parameters and message content to be passed to report server (uvm_report_server). Exemplarily, by reasonably setting breakpoints, data can be monitored by writing TCL code, if read data and write data do not match, bus returns err resp or any situation that does not match with expected value, print content can be passed to uvm_error by parameter, similarly other prompt message contents that need to be printed are passed to uvm_info, and finally uvm_report_server captures error (error) number, and displays final verification result.

[0090] Whether using Tcl to read and write registers in the slave, or using Tcl to simulate the AMBA bus to access the slave device, Tcl can detect errors and print reports. Using Tcl to implement the error detection and reporting mechanism is a perfection of Tcl to accelerate UVM simulation to achieve efficient chip testing, making it more practical.

[0091] The above chip verification method uses Tcl code combined with UVM printing mechanism, which can flexibly set the monitoring position and realize a good error detection and reporting mechanism.

[0092] In order to enable those skilled in the art to fully understand the present application, the steps of the chip verification method of the present application are described in detail below:

[0093] This application first builds a verification environment for the UVM test platform according to the test requirements, and uses TCL scripts to generate test cases.

[0094] During testing, the test case is parsed through the verification environment to obtain the stimulus signal; based on the stimulus signal, the chip is verified to obtain the output signal. The output signal is compared with the expected value, and the verification result is generated based on the comparison result.

[0095] Further, in the case where the stimulus signal includes an operation type and a test parameter, the operation type includes a read operation and a write operation, and the test parameter includes a register address and a front door access path, the present application determines the register model according to the register address. When the operation type is a read operation, the register model is used to read data from the target register corresponding to the register address through the front door access path; when the operation type is a write operation, the register model is used to write the write data to the target register corresponding to the register address through the front door access path.

[0096] Furthermore, when the chip includes multiple hosts and multiple slaves, and the test case encapsulates the bus interface timing and the transmission path of the excitation signal, the present application connects the excitation signal to the corresponding interconnection layer according to the transmission path of the excitation signal, so that the corresponding interconnection layer accesses the target slave according to the bus interface timing.

[0097] Furthermore, when the stimulus signal includes test parameters, expected return values ​​and breakpoints, the present application compares the actual return value at the breakpoint with the expected return value when verifying the chip using the test parameters to generate a verification result; and uses the printer of the UVM test platform to print and output the verification result.

[0098] The above chip verification method introduces test cases written in TCL. It only needs to be loaded in the simulation stage. One compilation can test multiple different scenarios infinitely without repeatedly modifying the test platform, saving a lot of test time. By writing the register reading and writing stimulus sequence in Tcl, the target register can be read and written directly, and the flexibility of the register model and Tcl script of UVM is utilized to ensure the efficiency and scalability of register verification. It plays an irreplaceable role in environmental maintenance and improving verification efficiency. Using the existing UVM test environment, the node level sent by the stimulus source can be flexibly selected, the timing of bus protocols such as APB / AHB / AXI can be simulated, and customized stimulus access to slave devices can be sent, which significantly improves the simulation efficiency. At the same time, the clock of the specified frequency is dynamically generated, which saves the simulation time on the basis of saving the compilation time. Using Tcl code in conjunction with the UVM printing mechanism, the monitoring position can be flexibly set, and a good error detection and reporting mechanism can be realized.

[0099] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0100] Based on the same inventive concept, the embodiment of the present application also provides a chip verification device for implementing the chip verification method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more chip verification device embodiments provided below can refer to the limitations on the chip verification method above, and will not be repeated here.

[0101] In an exemplary embodiment, Figure 6 As shown, a chip verification device 60 is provided, including: a building module 601, a verification module 602, wherein:

[0102] Building module 601 is used to build a verification environment for the UVM test platform.

[0103] The verification module 602 is used to call the test case; in the verification environment, the chip is verified according to the test case to obtain the verification result; wherein the test case is generated according to the test requirements using the TCL script.

[0104] Optionally, the verification module 602 verifies the chip according to the test case in the verification environment to obtain a verification result, including: parsing the test case through the verification environment to obtain a stimulus signal; verifying the chip according to the stimulus signal to obtain an output signal; comparing the output signal with the expected value, and generating a verification result based on the comparison result.

[0105] Optionally, the stimulus signal includes an operation type and a test parameter, the operation type includes a read operation and a write operation, and the test parameter includes a register address and a front door access path. Then the verification module 602 verifies the chip according to the stimulus signal, including: determining a register model according to the register address; wherein the register model is used to perform read and write access to a target register in the chip through a front door access path according to the operation type, when the operation type is a read operation, the register model reads data from the target register corresponding to the register address; when the operation type is a write operation, the register model writes the write data into the target register corresponding to the register address.

[0106] Optionally, when the chip includes multiple hosts and multiple slaves, the test case encapsulates the bus interface timing and the transmission path of the excitation signal. The verification module 602 verifies the chip according to the excitation signal, including: according to the transmission path of the excitation signal, connecting the excitation signal to the corresponding interconnection layer, so that the corresponding interconnection layer accesses the target slave according to the bus interface timing.

[0107] Optionally, the stimulus signal includes a test parameter, an expected return value and a breakpoint. The chip verification device 60 of the embodiment of the present application further includes: a printing module 603 .

[0108] The printing module 603 is used to compare the actual return value at the breakpoint with the expected return value when verifying the chip using the test parameters, and generate a verification result; use the printer of the UVM test platform to print and output the verification result.

[0109] The above chip verification device introduces test cases written in TCL. It only needs to be loaded in the simulation stage. One compilation can test multiple different scenarios infinitely without repeatedly modifying the test platform, saving a lot of test time. By writing the register reading and writing stimulus sequence in Tcl, the target register can be directly read and written. The flexibility of the register model and Tcl script of UVM is utilized to ensure the efficiency and scalability of register verification. It plays an irreplaceable role in environmental maintenance and improving verification efficiency. Using the existing UVM test environment, the node level sent by the stimulus source can be flexibly selected, the timing of bus protocols such as APB / AHB / AXI can be simulated, and customized stimulus access to slave devices can be sent, which significantly improves the simulation efficiency. At the same time, a clock of a specified frequency is dynamically generated, which saves simulation time on the basis of saving compilation time. Using Tcl code in conjunction with the UVM printing mechanism, the monitoring position can be flexibly set, and a good error detection and reporting mechanism can be realized.

[0110] Each module in the above chip verification device can be implemented in whole or in part by software, hardware or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute the operations corresponding to each module.

[0111] In an exemplary embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as shown in FIG. Figure 7 As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store texture data. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a chip verification method is implemented.

[0112] Those skilled in the art will understand that Figure 7The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0113] In an exemplary embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the method of the steps in any one of the above embodiments when executing the computer program.

[0114] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the method of implementing the steps in any one of the above embodiments is implemented.

[0115] In one embodiment, a computer program product is provided, including a computer program, and when the computer program is executed by a processor, the method of implementing the steps in any one of the above embodiments is implemented.

[0116] Those of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

[0117] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0118] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A chip verification method, characterized in that: The method comprises: Build the verification environment of UVM test platform; Call the test case; In the verification environment, verifying the chip according to the test case to obtain a verification result; The test cases are generated using TCL scripts based on test requirements.

2. The method according to claim 1, characterized in that: In the verification environment, verifying the chip according to the test case to obtain a verification result includes: Parsing the test case through the verification environment to obtain a stimulus signal; According to the excitation signal, the chip is verified to obtain an output signal; The output signal is compared with an expected value, and a verification result is generated according to the comparison result.

3. The method according to claim 2, characterized in that The stimulus signal includes an operation type and a test parameter, the operation type includes a read operation and a write operation, and the test parameter includes a register address and a front door access path; The verifying the chip according to the excitation signal includes: A register model is determined according to the register address; wherein the register model is used to perform read and write access to a target register corresponding to the register address in the chip through the front door access path according to the operation type.

4. The method according to claim 3, characterized in that The test parameters also include write data; The register model performs read and write access to a target register in the chip according to the operation type, including: When the operation type is a read operation, the register model reads data from a target register corresponding to the register address; When the operation type is a write operation, the register model writes the write data into a target register corresponding to the register address.

5. The method according to claim 3, characterized in that: In the case where the chip includes multiple hosts and multiple slaves, the test case encapsulates the bus interface timing and the transmission path of the stimulus signal; The verifying the chip according to the excitation signal includes: According to the transmission path of the excitation signal, the excitation signal is connected to the corresponding interconnection layer, so that the corresponding interconnection layer accesses the target slave according to the bus interface timing.

6. The method according to any one of claims 1 to 5, characterized in that The stimulus signal includes test parameters, expected return values ​​and breakpoints; The method further comprises: When the chip is verified using the test parameters, the actual return value at the breakpoint is compared with the expected return value to generate a verification result; The printer of the UVM test platform is used to print and output the verification result.

7. A chip verification device, characterized in that: The device comprises: Build a module to build the verification environment of the UVM test platform; The verification module is used to call the test case; in the verification environment, the chip is verified according to the test case to obtain the verification result; wherein the test case is generated according to the test requirements using the TCL script.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images