Automatic chip verification method, system, equipment and medium

Abstract

The embodiment of the invention relates to the field of chip verification, and discloses an automatic chip verification method, system and device and a medium. Generating a register model according to the custom register table; generating a register test case based on the register attribute; performing simulation operation on the register model and the register test case according to a simulation configuration file, and collecting coverage rate information in a simulation result; the simulation configuration file comprises simulation times, test case names and coverage rate collection targets. Compared with a traditional manual operation mode, the method has the advantages that the change of the register can be quickly responded, the test case is automatically updated, and the continuity and integrity of the verification process are ensured. According to the invention, high automation of the chip verification process is realized, manual intervention is reduced, verification comprehensiveness and resource utilization rate are improved, and more reliable verification guarantee is provided for chip design. The technical problem of low chip verification efficiency can be at least solved.

Description

Technical Field

[0001] The present application relates to the field of chip verification, and in particular to an automated chip verification method, system, device and medium. Background Art

[0002] In the prior art, the IC verification process is that the verification personnel build various components in the verification platform based on UVM, write components such as stimulus generators and stimulus constraint methods, and then send constrained random stimuli based on the platform built, test the DUT, collect coverage, manually check the coverage, and analyze it. In this process, for different projects, some components cannot be inherited, such as register models and register test cases, which vary with the business needs of different projects. There are many registers, manual writing is time-consuming, and the probability of manual errors is high, which greatly increases the time cost of platform construction.

[0003] In addition, in the process of large-scale random verification of DUT, the verification personnel need to manually check the coverage before knowing and deciding whether to continue collecting coverage to meet the target requirements. In this process, for test cases with errors, they also need to manually check and re-simulate the error waveform file for debugging. This also increases the time for verification personnel to complete the verification work. In short, in IC verification, there are a lot of manual processes in the register test area and coverage convergence process. Frequent changes are prone to errors and time-consuming and labor-intensive, affecting the verification progress. Summary of the invention

[0004] One object of the present application is to provide a chip verification method, system, device and medium, at least to solve the technical problem of low chip verification efficiency.

[0005] To achieve the above objectives, some embodiments of the present application provide the following aspects:

[0006] In the first aspect, some embodiments of the present application also provide a chip verification method, which includes generating a register model based on a custom register table; generating a register test case based on register attributes; simulating the register model and the register test case according to a simulation configuration file, and collecting coverage information in the simulation results; the simulation configuration file includes the number of simulations, the test case name and the coverage collection target.

[0007] On the second aspect, some embodiments of the present application also provide an automated chip verification system, the system comprising: a register model generation module, used to generate a register model based on a custom register table; a register test case generation module, used to generate a register test case based on register attributes; an automated verification module, used to simulate the register model and the register test case according to a simulation configuration file, and collect coverage information in the simulation results; the simulation configuration file includes the number of simulations, the test case name and the coverage collection target.

[0008] In a third aspect, some embodiments of the present application further provide an electronic device, comprising: one or more processors; and a memory storing computer program instructions, wherein the computer program instructions, when executed, cause the processor to perform the steps of the method described above.

[0009] In a fourth aspect, some embodiments of the present application further provide a computer-readable medium having computer program instructions stored thereon, wherein the computer program instructions can be executed by a processor to implement the method as described above.

[0010] Compared with the related art, the solution provided in the embodiment of the present application greatly improves the efficiency and accuracy of chip verification by automatically generating register models and register test cases, and realizing automatic collection and analysis of coverage during simulation verification. Compared with the traditional manual operation method, it can quickly respond to changes in registers, automatically update test cases, and ensure the continuity and integrity of the verification process. It achieves a high degree of automation of the chip verification process, which not only reduces manual intervention, but also improves the comprehensiveness of verification and resource utilization, providing a more reliable verification guarantee for chip design. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] One or more embodiments are exemplarily described by pictures in the corresponding drawings, and these exemplified descriptions do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, and unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0012] Figure 1 A schematic diagram of a flow chart of an automated chip verification method provided according to an embodiment of the present application;

[0013] Figure 2 A schematic diagram of a flow chart of another automated chip verification method provided according to an embodiment of the present application;

[0014] Figure 3 The present invention is a schematic diagram of the structure of an electronic device provided according to an embodiment of the present application. DETAILED DESCRIPTION

[0015] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0016] First embodiment

[0017] The first embodiment of the present application relates to an automated chip verification method. Figure 1 As shown, the method may include the following steps:

[0018] S101, generate a register model according to a custom register table. In a chip design project, registers are usually used to store various chip status information, so it is very important to verify the correctness of the registers. First, the verification engineer will define the register table according to the project requirements. The table usually includes detailed information of the register, such as register address, bit width, attributes (such as read-write attributes, read-only attributes, write-clear attributes, etc.), default values, and functional descriptions.

[0019] By parsing the custom register table, the register model is automatically generated. The generated register model can accurately reflect the structure and behavior characteristics of the register, and serve as the basis for subsequent verification tests. This process avoids the tediousness and possible human errors of manually creating a register model, allowing the register model to quickly adapt to changes in the project, improving the flexibility and efficiency of verification.

[0020] S102, generate register test cases based on register attributes. Register attributes usually include but are not limited to the following: read-write attribute (RW), read-only attribute (RO), write-clear attribute (WC). This type of register will automatically clear its content after writing a certain value. The test case needs to verify whether the content is correctly cleared after writing.

[0021] Based on these properties, corresponding read and write test cases are generated for each register to ensure the correctness of the register function. For example, the system generates test cases for registers with read and write properties to verify whether the writing and reading of the registers are as expected; for registers with read-only properties, test cases are generated to verify whether they refuse to change under write operations. In addition, the generated test cases will also verify the interaction between the register and the chip interface to ensure that the connection between the register model and the chip circuit interface is correct. This automated way of generating test cases greatly reduces the workload of manually writing test cases, while ensuring that the properties of each register are fully tested to prevent omissions.

[0022] S103, simulating the register model and the register test case according to the simulation configuration file, and collecting coverage information in the simulation results; the simulation configuration file includes the number of simulations, the name of the test case, and the coverage collection target. The simulation configuration file contains basic parameters for executing the simulation, such as the number of simulations, the name of the test case, and the coverage collection target. Specifically, the simulation configuration file defines the number of simulations that should be performed for each test case, the coverage requirements of the target module, and whether to ignore certain coverage types.

[0023] During the simulation execution, the register model is simulated and verified multiple times according to the parameters of the configuration file. In order to ensure the comprehensiveness of the verification, different random seeds are used to send different random stimuli to ensure that the simulation results can cover as many design scenarios as possible. As the simulation operation proceeds, the coverage information in each simulation result is collected and analyzed in real time.

[0024] Coverage information is an important indicator to measure the comprehensiveness of simulation verification, which usually includes the following types of coverage: line coverage, verifying whether each line in the code is executed; conditional coverage: verifying whether each conditional branch is triggered; state machine coverage, verifying whether each state and state transition in the state machine is traversed; functional coverage, verifying the implementation of specific functions. After collecting coverage data, determine whether to continue simulation based on the coverage collection target preset in the simulation configuration file. If the coverage has reached the set target, the simulation operation ends; if the target is not reached, the system will continue to perform new simulation operations, and may gradually improve the coverage by modifying random excitation or other simulation parameters until the coverage requirements are met or the convergence conditions are reached.

[0025] During this process, the results of each simulation are automatically recorded to help verification engineers quickly locate potential functional defects or uncovered scenarios. In addition, if some simulation operations fail, the relevant compilation files and stimulus information are saved to facilitate subsequent reproduction of the fault scenario, problem location and repair.

[0026] It is not difficult to find that compared with the related technology, in the solution provided in the embodiment of the present application, through this automated process, the verification personnel can complete the verification of the chip registers faster and more accurately, thereby greatly improving the efficiency of the overall chip design and verification.

[0027] Second embodiment

[0028] The second embodiment of the present application relates to an automated chip verification method. The second implementation is an improvement on the first embodiment, and the specific improvements are:

[0029] In chip design projects, registers are usually used to store various states and control signals of the chip. Each project defines a register table containing register information, which includes detailed information such as the register name, address, bit width, default value, and its properties. Based on this table, the system generates register models and corresponding test cases through automated scripts. Specifically:

[0030] Parse the field information in the register table and automatically generate a register model, which reflects the structure and function of the register and can be applied to the subsequent verification process. According to the different attributes of the register (such as RW, WC, RO, etc.), generate different test cases to verify the read and write functions of the register and the connectivity with the chip interface.

[0031] Tests are performed on different register attributes. Register attributes are important functional descriptions in chip design. Common register attributes include: RW (read-write) attributes. This type of register allows read and write operations. The generated test case writes test data to the register and verifies whether the data is correct when reading; WC (write-clear) attributes. This type of register automatically clears its content after writing a specific value. The test case detects the state of the register after the write operation and verifies whether the content has been correctly cleared; RO (read-only) attributes. Read-only registers cannot be written. The generated test case attempts to write to the register and verifies whether the write operation is rejected and whether the register content remains unchanged. By testing different register attributes, the basic read and write functions of the chip register can be fully verified.

[0032] When testing interfaces related to registers, in addition to testing the functions of the registers themselves, the connectivity between the registers and the internal interfaces of the chip also needs to be verified. Registers usually communicate with other modules inside the chip through interfaces, and ensuring the correctness of the interfaces is crucial to the overall function of the chip. The test cases generated by the system will not only verify the read and write functions of the registers, but also verify whether the interface connection between the registers and other chip modules is correct. The test cases will simulate the flow of internal chip signals to ensure that the registers can correctly transmit and receive signals through the interface, and ensure the correctness of the register-to-chip interface circuit.

[0033] Quickly update register models and test cases during project development. During chip development, as the project progresses, the contents of the register table may change. In order to cope with this situation, the automated chip verification method of this application can quickly generate updated register models and corresponding test cases after the register table changes. Automatically detect changes to the register table and regenerate an updated register model to ensure that the function of the register can be verified in a timely manner to avoid functional defects caused by register changes.

[0034] In addition, regression verification can be automatically performed to ensure that the register function still meets the design requirements after the change. In this way, verification personnel can quickly respond to register changes and improve the flexibility and efficiency of chip verification.

[0035] like Figure 2 As shown, the specific steps of simulating the register model and the register test case according to the simulation configuration file and collecting coverage information in the simulation result include:

[0036] Constructing test cases. During the chip design process, verification personnel start to construct simulation test cases based on the specific requirements of the design under test (DUT). Usually, the construction of test cases can be written manually or generated with the help of automated tools. The goal of the test cases is to verify the correctness and performance of each functional module in the chip design. In order to ensure the comprehensiveness of the verification, the test cases usually cover the key functional modules in the chip design to ensure that each functional point is fully verified.

[0037] Specifically, the writing of test cases will be carried out for different design scenarios, including: functional verification, testing whether the main functions of the chip meet the design specifications, for example, the read and write functions of the registers, whether the signal transmission path is correct, etc.; interface verification, verifying whether the interface connection between the chip and the external module or other internal modules is accurate and can work normally under various load and boundary conditions; boundary condition testing, verifying the behavior of the chip under extreme input conditions, ensuring that the chip function does not abnormally under maximum load, highest frequency or minimum voltage, etc.; exception handling, simulating errors or abnormal conditions that may occur in the design, and verifying the chip's fault handling capabilities and recovery mechanisms.

[0038] Write simulation configuration files. After completing the test case construction, the verification personnel need to write simulation configuration files for the simulation operation. The simulation configuration file is the core guidance file for the simulation operation, which defines the key parameters of the simulation execution, ensures that the simulation task can be effectively executed, and meets the coverage target.

[0039] Specifically, the simulation configuration file includes the following: number of simulations, which specifies the number of simulations that should be performed for each test case. The setting of the number of simulations depends on the complexity of the test case and the use of random excitations. It is usually used to improve verification coverage and ensure that the performance of the design under multiple input conditions is tested; test case name, which lists all test cases to be executed in this simulation. These test cases correspond to functional tests, interface tests, boundary tests, etc. in the constructed test cases. Each test case has a clear name to distinguish different verification scenarios; coverage collection targets, the verifier defines the coverage requirements of the target modules in the configuration file. These targets are usually related to the key functions and modules of the chip. The verifier can adjust the coverage targets according to the importance of the design. For example, for some core modules, higher coverage is required, while secondary modules may only need to meet the basic coverage standards; coverage type flag, the simulation configuration file allows the verifier to choose whether to collect different types of coverage data, and set flags to ignore certain coverage types according to actual needs.

[0040] Common coverage types include: line coverage, which measures whether each line in the code is executed to ensure that every part of the design has been run in the simulation; conditional coverage is used to detect the branching of conditional statements (such as ifelse structures) to ensure that each conditional branch is triggered by the simulation; flip coverage is used to measure the state change of the signal to ensure that the signal can undergo a sufficient flipping process in the simulation; state machine coverage, for the state machine module, verifies whether each state and state transition is triggered to ensure that the state machine works properly in the simulation; branch coverage, detects the execution of the branch structure to verify whether all branch paths have been executed; functional coverage ensures the integrity of specific functional modules and checks whether each function has been verified in place. These coverage marks help verification personnel clarify the scope and goals of coverage collection, ensure that the coverage of key modules and functions meets the standards, and reasonably allocate simulation resources. For example, some modules may not need to collect all types of coverage, and verification personnel can choose to ignore some coverage to save simulation time and computing resources.

[0041] Send different random stimuli for simulation. Perform simulation operations and record the results. After the simulation configuration file is written, the simulation operation will be performed on the design under test (DUT) according to the parameters in the configuration file. Using random stimuli, you can use systemver il og to use different random seeds to generate diverse test inputs to ensure that the simulation operation can cover every corner of the design. To increase the simulation speed, the waveform file is not saved by default to reduce the storage space occupied and speed up the simulation execution.

[0042] When a simulation operation fails, the relevant compilation files, simulation stimuli, and other necessary intermediate data are automatically saved for subsequent reproduction of the problem. Saving this information helps the verifier quickly locate the cause of the failure and avoid restarting the simulation from scratch. To further improve the efficiency of problem reproduction, the failed simulation operation is automatically re-executed and the waveform file is saved in the process. The waveform file contains detailed information about the changes of the internal signals of the design over time. The verifier can view the waveform diagram to deeply analyze the occurrence point and root cause of the problem, so as to efficiently locate and repair the defects in the design.

[0043] For successful simulations, coverage data is automatically collected. Coverage is an important indicator for measuring simulation results, ensuring that simulation operations cover different functions and scenarios of the design under test. The collected coverage is compared with the predetermined coverage target to determine whether the current simulation has achieved the expected results.

[0044] To avoid wasting storage space, unnecessary simulation artifacts, such as intermediate generated files, temporary data, etc., are deleted. This frees up disk space, prevents storage resources from being full, and avoids the failure of subsequent simulation tasks due to insufficient disk space. Through this automatic cleanup mechanism, it can run stably for a long time without affecting simulation efficiency due to storage issues. During the entire simulation operation, the results of each simulation are recorded in detail. Regardless of whether the simulation is successful or not, the simulation data can be effectively managed, allowing the verifier to quickly retrieve the results of a specific simulation.

[0045] When all simulation operations are completed, the coverage data is automatically counted and analyzed. The coverage collected from each simulation is compared with the coverage target in the simulation configuration file: if the coverage reaches the preset target in the configuration file, the simulation operation will be automatically exited; if the coverage does not reach the target, a different random stimulus seed will be automatically replaced, and multiple simulation operations will be repeated. This process will be repeated until the coverage meets the target or the coverage cannot be further improved.

[0046] When the collected coverage increases slightly compared to the previous time and does not reach the predetermined target, the simulation operation will be exited and a warning message will be output, prompting the verification personnel that the current test case may be incompletely written and further optimization is recommended. When the collected coverage increases significantly compared to the previous time and does not reach the predetermined target, different random stimuli will be resent for simulation and the verification operation will continue.

[0047] After the simulation operation is completed, detailed simulation statistical results will be automatically generated and output. This result provides the verification personnel with a comprehensive simulation operation report, which helps to evaluate the effect of the simulation operation and quickly locate and analyze the cause of failure. The output simulation results usually include the following aspects:

[0048] The total number of times each test case is executed during the simulation. Since the simulation may be repeated many times, especially when using different random stimulus seeds, the statistics of the number of simulations can help the verifier understand the degree of verification of each test case.

[0049] The simulation results will count the number of successes and failures for each test case. The number of successes refers to the number of times the simulation is successfully executed and passes the preset verification criteria; the number of failures refers to the number of simulation failures caused by functional abnormalities or coverage failures during the simulation process. The comparison between the number of successes and failures can intuitively reflect the stability of the simulation and the completeness of the test cases.

[0050] For failed simulation operations, corresponding detailed information will be output, including: waveform file storage directory. When the simulation fails, the waveform file will be saved and its storage path will be output. These waveform files contain dynamic change information of the internal signals of the design. By viewing the waveform diagram, the verifier can deeply analyze the specific signal status when the simulation fails, which helps to locate the source of the problem. In addition to the waveform file, the compiled file and random stimulus data of the failed simulation are also recorded. This information can help the verifier reproduce the problem and quickly perform subsequent debugging and repair work. Through these detailed simulation results, the verifier can fully grasp the execution of each test case, especially for failed simulations. By viewing the waveform file and analyzing the simulation stimulus, the problem points in the design can be accurately located.

[0051] Finally, a detailed coverage result report is generated and output. Coverage is an important indicator to measure the comprehensiveness of the verification process, reflecting how many design functions or code paths are triggered by the test case in the simulation. Through the coverage results, the verifier can evaluate the adequacy of the verification, find uncovered design areas, and optimize the test cases and verification strategies accordingly. The coverage result report usually contains detailed statistics on the following aspects:

[0052] Module coverage, calculates coverage for each module separately, showing the extent to which each module has been tested during simulation. By comparing the coverage of each module, the verifier can identify which modules have not been fully verified. For example, some key modules may have lower coverage than expected due to insufficient random excitation, and further test cases may be needed.

[0053] Coverage indicator statistics, the output coverage results will be classified and counted in detail according to different types of coverage indicators. Common coverage types include: line coverage, conditional coverage, flip coverage, state machine coverage, branch coverage, and functional coverage.

[0054] Not only does it output the current coverage results, but it can also generate a coverage trend chart to show how coverage changes with the number of simulations. With this data, verifiers can evaluate the coverage improvement speed and convergence trend, and identify which parts may need to add random stimuli or test cases to further improve coverage. Compare the current coverage results with the coverage targets set in the simulation configuration file. If the statistical results of certain modules or coverage types are lower than the target value, they will be highlighted in the report to remind the verifier that this part needs further optimization. Modules or indicators that do not meet the standards will prompt the verifier to adjust the verification strategy and add targeted test cases.

[0055] Through detailed coverage reports, verifiers can identify modules or functional areas with low coverage and take targeted optimization measures, such as writing new test cases for uncovered code paths or modules; modifying random stimulus generation strategies so that simulation can trigger more design functions; and optimizing existing test cases to ensure that they cover the edge conditions or extreme scenarios of the design.

[0056] The step division of the above methods is only for the purpose of clear description. When implemented, they can be combined into one step or some steps can be split and decomposed into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this patent; adding insignificant modifications to the algorithm or process or introducing insignificant designs without changing the core design of the algorithm and process are all within the scope of protection of this patent.

[0057] Third embodiment

[0058] The third embodiment of the present application relates to an automated chip verification system, which includes: a register model generation module, which is used to generate a register model based on a custom register table; a register test case generation module, which is used to generate a register test case based on register attributes; an automated verification module, which is used to simulate the register model and the register test case according to a simulation configuration file, and collect coverage information in the simulation results; the simulation configuration file includes the number of simulations, the test case name, and the coverage collection target.

[0059] It is not difficult to find that this embodiment is a system embodiment corresponding to the first embodiment, and this embodiment can be implemented in conjunction with the first embodiment. The relevant technical details mentioned in the first embodiment are still valid in this embodiment, and in order to reduce repetition, they are not repeated here. Accordingly, the relevant technical details mentioned in this embodiment can also be applied in the first embodiment.

[0060] It is worth mentioning that all modules involved in this embodiment are logic modules. In practical applications, a logic unit can be a physical unit, a part of a physical unit, or a combination of multiple physical units. In addition, in order to highlight the innovative part of this application, this embodiment does not introduce units that are not closely related to solving the technical problems proposed by this application, but this does not mean that there are no other units in this embodiment.

[0061] In addition, some embodiments of the present application also provide an electronic device. The electronic device may be a digital computer in various forms, such as a laptop computer, a desktop computer, a workbench, a personal digital assistant, a server, a blade server, a mainframe computer, etc. The electronic device may also be a mobile device in various forms, such as a personal digital processing, a cellular phone, a smart phone, a wearable device, and other similar computing devices.

[0062] The electronic device includes: one or more processors; and a memory storing computer program instructions, wherein when the computer program instructions are executed, the processor executes the steps of the method provided in any one or more of the above embodiments. Figure 3 An exemplary structural diagram of the electronic device is disclosed. Figure 3 As shown, the electronic device includes: one or more processors 1101, memory 1102, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. The various components are connected to each other using different buses, and can be installed on a common mainboard or installed in other ways as needed. The processor can process instructions executed in the electronic device, including instructions stored in or on the memory to display the graphical information of the GUI on an external input / output device (such as a display device coupled to the interface). In some other embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple electronic devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Among them, the components shown in this article, their connections and relationships, and their functions are only used as examples, and are not intended to limit the implementation of the present application described and / or required herein.

[0063] The electronic device may further include: an input device 1103 and an output device 1104. The processor 1101, the memory 1102, the input device 1103 and the output device 1104 may be connected via a bus or other means. Figure 3 The example of connecting through bus is taken in the following.

[0064] The input device 1103 can receive input digital or character information, and generate key signal input related to the user settings and function control of the electronic device, such as a touch screen, a keypad, a mouse, a track pad, a touch pad, an indicator bar, one or more mouse buttons, a trackball, a joystick and other input devices. The output device 1104 may include a display device, an auxiliary lighting device (e.g., an LED) and a tactile feedback device (e.g., a vibration motor), etc. The display device may include, but is not limited to, a liquid crystal display (LCD), a light emitting diode (LED) display and a plasma display. In some embodiments, the display device may be a touch screen.

[0065] To provide interaction with a user, the electronic device may be a computer. The computer has: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and a pointing device (e.g., a mouse or a trackball), through which the user can provide input to the computer. Other types of devices may also be used to provide interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form (including acoustic input, voice input, or tactile input).

[0066] In the embodiments of the present application, a computer program / instruction is stored on a computer-readable medium, and when the computer program / instruction is executed by a processor, the steps of the method provided by any one or more of the above embodiments are implemented. The computer-readable medium may be included in the electronic device described in the above embodiments; or it may exist independently without being assembled into the device. The above computer-readable medium carries one or more computer-readable instructions.

[0067] The memory 1102 can be used as a non-transient computer-readable storage medium, which can be used to store non-transient software programs, non-transient computer executable programs and modules. The processor 1101 executes various functional applications and data processing of the server by running the non-transient software programs, instructions and modules stored in the memory 1102, so as to implement the program instructions / modules corresponding to the method provided by any one or more embodiments in the embodiments of the present application.

[0068] The memory 1102 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 1102 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory 1102 may optionally include a memory remotely arranged relative to the processor 1101, and these remote memories may be connected to the electronic device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0069] It should be noted that the computer-readable medium described in the present application may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device.

[0070] Computer readable media include permanent and non-permanent, removable and non-removable media, and can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, modules of programs or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, read-only compact disk (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices or any other non-transmission medium that can be used to store information that can be accessed by a computing device.

[0071] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" language or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., using an Internet service provider to connect via the Internet).

[0072] In the above-described embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. For example, it can be implemented by using an application specific integrated circuit (ASIC), a general-purpose computer or any other similar hardware device. In certain embodiments, the software program of the present application can be executed by a processor to implement the above steps or functions. Similarly, the software program of the present application (including relevant data structures) can be stored in a computer-readable recording medium, for example, a RAM memory, a magnetic or optical drive or a floppy disk and similar devices. In addition, some steps or functions of the present application can be implemented by hardware, for example, as a circuit that cooperates with a processor to perform each step or function.

[0073] The computer program product provided in the embodiment of the present application includes one or more computer programs / instructions, and when the computer program / instructions are executed by the processor, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from a website site, a computer, a server or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or a data center that includes one or more available media integrations. The available medium may be a magnetic medium, (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive so lid state di sk (SSD)), etc.

[0074] The flow chart or block diagram in the accompanying drawings shows the possible architecture, function and operation of the equipment, method and computer program product according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented with a dedicated system for hardware that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0075] The scope of the present application is defined by the appended claims rather than the above description, and it is intended that all changes that fall within the meaning and scope of the equivalent elements of the claims are included in the present application. Any figure mark in the claims should not be regarded as limiting the claims involved. In addition, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices stated in the device claim may also be implemented by one unit or device through software or hardware. The words "first", "second", etc. are only used to distinguish the description, and do not indicate any particular order, nor can they be understood as indicating or implying relative importance.

[0076] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily mention changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims, and the above embodiments should be regarded as exemplary and non-restrictive.

Claims

1. An automated chip verification method, characterized in that: The method comprises: Generate register model based on custom register table; Generate register test cases based on register properties; The register model and the register test case are simulated according to the simulation configuration file, and coverage information in the simulation result is collected; the simulation configuration file includes the number of simulations, the test case name and the coverage collection target.

2. The method according to claim 1, characterized in that The register attributes include a read-write attribute, a write-clear attribute, and a read-only attribute.

3. The method according to claim 2, characterized in that The register test case includes: testing the read and write functions of the register according to the register attributes; Test the chip interface related to the register to verify the correctness of the register and chip interface circuit.

4. The method according to claim 3, characterized in that The simulation configuration file also includes a flag for whether to ignore the following coverage: line coverage, condition coverage, flip coverage, state machine coverage, branch coverage, and function coverage.

5. The method according to any one of claims 1 to 4, characterized in that: The performing of simulation operation and collecting coverage information in the simulation result includes: Use different random seeds to send random stimuli to simulate the chip under test and record the simulation results; The coverage rate is automatically counted. When the coverage rate reaches the coverage rate collection target in the simulation configuration file, the simulation operation is terminated; if not, the simulation is continued until the coverage rate collection target is met or a warning is output.

6. The method according to claim 5, characterized in that The simulation verification includes: For each simulation verification, if the simulation fails, save its compiled file and random excitation, and re-run the simulation verification; If the simulation is successful, collect coverage and delete unnecessary simulation artifacts to free up disk space.

7. The method according to claim 6, characterized in that The method further comprises: If the coverage increment collected by two consecutive simulation verifications does not reach the set threshold, the simulation verification is terminated and a warning message is output.

8. An automated chip verification system, characterized in that: The system comprises: A register model generation module, used to generate a register model according to a custom register table; A register test case generation module, used for generating register test cases based on register attributes; The automated verification module is used to simulate the register model and the register test case according to a simulation configuration file, and collect coverage information in the simulation results; the simulation configuration file includes the number of simulations, the test case name and the coverage collection target.

9. An electronic device, characterized in that: The electronic device comprises: one or more processors; and A memory storing computer program instructions, which, when executed, cause the processor to perform the steps of the method as claimed in any one of claims 1 to 7.

10. A computer readable medium having a computer program / instructions stored thereon, characterized in that: When the computer program / instructions are executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images