Chip post-simulation method and device

Abstract

The invention relates to a chip post-simulation method and device. The method comprises the following steps: acquiring a gate-level netlist and a standard delay format file of a designed chip; compiling simulation is carried out according to the gate-level netlist and the standard delay format file, and a simulation report containing time sequence violation information is generated; extracting time sequence violation information from the simulation report; and analyzing the extracted time sequence violation information, determining the time sequence violation information which does not need to be checked again, and recording the time sequence violation information in a file, so that the recorded time sequence violation information is not displayed in the post-simulation process again. According to the method, the workload of manual confirmation can be reduced, the workload of iterative regression repeated confirmation in a single project is reduced, the analysis result can be reused among multiple projects, the workload of multi-project repeated confirmation is reduced, the post-simulation working efficiency is improved, the post-simulation time is saved, and thus the chip tape-out time is shortened.

Description

Technical Field

[0001] The present application relates to chip simulation analysis technology, and in particular to a chip post-simulation method and apparatus, computing equipment and storage medium. Background Art

[0002] During the chip development process, in order to determine the timing constraints and rationality of layout and routing in the chip back-end design, it is necessary to simulate the netlist after layout and routing (PR netlist for short) and the standard delay format (SDF) in different scenarios. This simulation is called post-simulation. Post-simulation mainly focuses on verifying the actual performance of the circuit, including timing, power consumption, and signal integrity. Post-simulation can detect timing problems caused by layout and routing, such as increased delay caused by too long a signal path. In the post-simulation process, if the simulation timing does not match the expected timing in the SDF, a timing violation will be reported.

[0003] The existing technology requires manual confirmation of the rationality of timing violations, and each iterative regression needs to be confirmed repeatedly. In addition, the confirmation results cannot be used as input for subsequent projects, which means that repeated confirmation is also required during project iterations. This will increase the workload of manual confirmation and the workload of repeated confirmation of iterative regression within a single project. The inability to reuse analysis results between multiple projects also increases the workload of repeated confirmation of multiple projects, thereby reducing the efficiency of post-simulation work, increasing post-simulation time, and extending chip tape-out time. Summary of the invention

[0004] In view of the above problems in the prior art, the present application provides a chip post-simulation method and apparatus, a computing device and a storage medium, which can reduce the workload of manual confirmation and the workload of iterative regression and repeated confirmation within a single project. The analysis results can be reused among multiple projects, reducing the workload of repeated confirmation of multiple projects, improving the efficiency of post-simulation work, saving post-simulation time, and thus shortening the chip tape-out time.

[0005] To achieve the above-mentioned object, the present application provides a first aspect of a chip post-simulation method, comprising:

[0006] Obtain the gate-level netlist and standard delay format file of the designed chip;

[0007] Compile and simulate according to the gate-level netlist and the standard delay format file, and generate a simulation report containing timing violation information;

[0008] extracting timing violation information from the simulation report;

[0009] The extracted timing violation information is analyzed, and the timing violation information that does not need to be reviewed again is determined and recorded in a file so as not to display the recorded timing violation information in a subsequent simulation process.

[0010] From the above, the present application automatically extracts timing violation information from a simulation report containing timing violation information after simulation, analyzes the timing violation information to determine the timing violation information that does not need to be reviewed again, and does not display the recorded timing violation information during the post-simulation process. In this way, there is no need to manually reconfirm the timing violation information, which reduces the workload of manual confirmation and the workload of iterative regression and repeated confirmation within a single project. The timing violation information that does not need to be reviewed again is recorded in a file, so that the analysis results can be reused among multiple projects, reducing the workload of repeated confirmation of multiple projects, improving the efficiency of post-simulation work, saving post-simulation time, and thus shortening the chip tape-out time.

[0011] As a possible implementation of the first aspect, the following also includes:

[0012] Get the provided asynchronous interface paths, paths that need to confirm timing, and paths that have not converged timing;

[0013] Determine a test case based on the asynchronous interface path, the path that needs to confirm the timing, and the path that has not converged the timing;

[0014] Performing register transfer level simulation using the test case to ensure that the asynchronous interface path, the path that needs to confirm the timing, and the path that has not converged the timing are covered;

[0015] The compiling and simulating according to the gate-level netlist and the standard delay format file includes: loading the test case, and compiling and simulating according to the gate-level netlist and the standard delay format file.

[0016] As a possible implementation manner of the first aspect, after extracting the timing violation information from the simulation report, the method further includes:

[0017] The timing violation information is classified and saved in different files according to different levels.

[0018] As a possible implementation of the first aspect, analyzing the extracted timing violation information, determining the timing violation information that does not need to be reviewed again and recording it in a file so as not to display the recorded timing violation information in a subsequent simulation process, includes:

[0019] The extracted timing violation information is analyzed to determine the timing violation information that does not need to be checked again during compilation, and is recorded in a timing check prohibition file, wherein the timing check prohibition file is used in the process of recompiling the simulation, and the timing violation information recorded in the file is not recorded in the simulation report.

[0020] As a possible implementation of the first aspect, determining that the timing violation information that does not need to be checked again in the compilation is recorded in a timing check prohibition file includes:

[0021] The signal path corresponding to the timing violation information that does not need to be checked again is recorded in the timing check prohibition file.

[0022] As a possible implementation of the first aspect, the determining the timing violation information that does not need to be extracted from the simulation report and generating a corresponding filtering mode and recording it in a filtering file includes:

[0023] Determining that the timing violation information extracted from the simulation report is reasonable timing violation information;

[0024] The file paths corresponding to the timing violation information determined to be reasonable are recorded in the filter file.

[0025] To achieve the above-mentioned object, the second aspect of the present application provides a chip post-simulation method, comprising:

[0026] Obtain the gate-level netlist and standard delay format file of the designed chip;

[0027] Compile and simulate according to the gate-level netlist, the standard delay format file, and the timing check prohibition file, and generate a simulation report containing timing violation information; wherein the timing check prohibition file records information of timing violations that do not need to be checked, so that such timing violation information is not recorded in the simulation report during the compilation process;

[0028] Extracting timing violation information from the simulation report according to a filter file; wherein the filter file records a filtering mode of timing violation, so that when extracting timing violation information, corresponding timing violation information is filtered out according to the filtering mode;

[0029] Post-chip simulation results are generated based on the extracted timing violation information.

[0030] To achieve the above-mentioned purpose, the third aspect of the present application provides a chip post-simulation device, comprising:

[0031] An acquisition module, used to acquire a gate-level netlist and a standard delay format file of the designed chip;

[0032] A compiling and simulating module, used for compiling and simulating according to the gate-level netlist and the standard delay format file, and generating a simulation report including timing violation information;

[0033] An extraction module, used for extracting timing violation information from the simulation report;

[0034] The file generation module is used to analyze the extracted timing violation information, determine the timing violation information that does not need to be checked again and record it in a file so as not to display the recorded timing violation information in a subsequent simulation process.

[0035] As a possible implementation of the third aspect,

[0036] To achieve the above-mentioned purpose, the fourth aspect of the present application provides a device method for post-chip simulation, comprising:

[0037] An acquisition module, used to acquire a gate-level netlist and a standard delay format file of the designed chip;

[0038] A compiling and simulating module, for compiling and simulating according to the gate-level netlist, the standard delay format file, and the timing check prohibition file, and generating a simulation report containing timing violation information; wherein the timing check prohibition file records information on timing violations that do not need to be checked, so that such timing violation information is not recorded in the simulation report during the compiling process;

[0039] An extraction module, configured to extract timing violation information from the simulation report according to a filter file; wherein the filter file records a filtering mode of timing violation, so that when extracting timing violation information, corresponding timing violation information is filtered out according to the filtering mode;

[0040] The result generation module is used to generate the result of post-chip simulation based on the extracted timing violation information.

[0041] A fifth aspect of the present application provides a computing device, including:

[0042] processor, and

[0043] A memory having program instructions stored thereon, wherein when the program instructions are executed by the processor, the processor executes any of the methods described in the first aspect above.

[0044] In a sixth aspect, the present application provides a computer-readable storage medium having program instructions stored thereon, wherein when the program instructions are executed by a computer, the computer implements any of the methods described in the first aspect above. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Figure 1 It is a flowchart of a first embodiment of a chip post-simulation method provided in an embodiment of the present application;

[0046] Figure 2 It is a flowchart of RTL simulation in a first embodiment of a post-chip simulation method provided in an embodiment of the present application;

[0047] Figure 3is a flowchart of a second embodiment of a chip post-simulation method provided in an embodiment of the present application;

[0048] Figure 4 It is a flowchart of a specific implementation of a chip post-simulation method provided in an embodiment of the present application;

[0049] Figure 5 is a schematic structural diagram of a chip post-simulation device provided in an embodiment of the present application;

[0050] Figure 6 is a schematic structural diagram of a chip post-simulation device provided in an embodiment of the present application;

[0051] Figure 7 It is a structural schematic diagram of a computing device provided in an embodiment of the present application.

[0052] It should be understood that the size and shape of each block diagram in the above structural diagram are for reference only and should not constitute an exclusive interpretation of the embodiments of the present application. The relative positions and inclusion relationships between the blocks presented in the structural diagram are only schematic representations of the structural associations between the blocks, and do not limit the physical connection methods of the embodiments of the present application. DETAILED DESCRIPTION

[0053] The technical solution provided by the present application is further described below with reference to the accompanying drawings and examples. It should be understood that the system structure and business scenarios provided in the examples of the present application are mainly to illustrate the possible implementation methods of the technical solution of the present application and should not be interpreted as the only limitation on the technical solution of the present application. It is known to those of ordinary skill in the art that with the evolution of the system structure and the emergence of new business scenarios, the technical solution provided by the present application is also applicable to similar technical problems.

[0054] It should be understood that the chip post-simulation solution provided in the embodiments of the present application includes a chip post-simulation method and device. Since the principles of solving the problems in these technical solutions are the same or similar, some repetitions may not be repeated in the introduction of the following specific embodiments, but it should be regarded as that these specific embodiments have been referenced to each other and can be combined with each other.

[0055] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by technicians in the technical field of this application. In the event of any inconsistency, the meaning described in this specification or the meaning derived from the contents recorded in this specification shall prevail. In addition, the terms used herein are only for the purpose of describing the embodiments of the present application and are not intended to limit the present application. In order to accurately describe the technical content in this application and to accurately understand the present invention, the following explanations or definitions are given to the terms used in this specification before describing the specific embodiments:

[0056] 1. Timing constraints: refers to the time limit of signal transmission inside the chip, such as maximum propagation delay, setup time and hold time, etc. These are necessary conditions to ensure the normal operation of the circuit.

[0057] 2. Layout and routing: refers to determining the location of components on the chip and how they are connected at the physical level.

[0058] 3. Netlist: It is an abstract representation of circuit design, which defines how the components are connected together to form a circuit. The netlist after layout and routing (PR netlist) refers to the netlist after physical layout and routing have been completed.

[0059] 4. SDF (Standard Delay Format): It is a standard delay file format, which is used to store and transmit the delay data of each component in the circuit under different working conditions. The standard delay format file usually contains the minimum and maximum propagation delay of each gate, path, etc., as well as other timing information.

[0060] 5. Post-simulation: It is a simulation performed after the layout and routing is completed, using the gate-level netlist and standard delay format file, in order to verify whether the actual performance of the circuit meets the expected design goals.

[0061] 6. Timing Violation: Timing Violation usually refers to the situation in digital circuit design, especially in integrated circuit design such as FPGA (Field-Programmable Gate Array), where the actual signal transmission time exceeds the predetermined maximum limit or does not meet the minimum requirement.

[0062] [First embodiment of the post-chip simulation method]

[0063] In order to solve the problem that the prior art requires manual confirmation of the rationality of timing violations, each iterative regression needs to be confirmed repeatedly. In addition, the confirmation results cannot be used as input for subsequent projects, which means that repeated confirmation is also required during project iterations. This will increase the workload of manual confirmation and the workload of repeated confirmation of iterative regression within a single project. The inability to reuse analysis results between multiple projects also increases the workload of repeated confirmation of multiple projects, thereby reducing the efficiency of post-simulation work, increasing post-simulation time, and extending chip tape-out time. The present application provides a chip post-simulation method, such as Figure 1 As shown, the method includes:

[0064] S110: Obtain the gate-level netlist and standard delay format file of the designed chip;

[0065] S120: compile and simulate according to the gate-level netlist and the standard delay format file, and generate a simulation report including timing violation information;

[0066] S130: extracting timing violation information from the simulation report;

[0067] S140: Analyze the extracted timing violation information, determine the timing violation information that does not need to be checked again, and record it in a file, so as to avoid displaying the recorded timing violation information in a subsequent simulation process.

[0068] In some embodiments, in S110, the backend department completes the physical implementation of the chip and provides a circuit netlist (PR) and a standard delay format (SDF) file after placement and routing. The PR netlist and SDF file contain specific physical implementation information about the chip design, including delay data, etc.

[0069] In specific implementation, the test cases of register transfer level simulation (RTL stage simulation) are required in the simulation process of S120, wherein the RTL stage simulation is that the designer uses HDL (hardware description language, such as Verilog or VHDL) to describe the behavior of the circuit. At this stage, the design focuses on logical functions rather than specific physical implementation details. RTL simulation is mainly used to verify the functional correctness of the design, that is, to ensure that the circuit can logically perform as expected. At the RTL stage, it is necessary to select appropriate test cases to cover the critical paths specified in the design, such as asynchronous interface paths, paths that need to confirm timing, and paths that have not converged timing. This step is to ensure that the performance of these paths can be accurately evaluated in the post-simulation stage. Based on this, in some embodiments, such as Figure 2 As shown, it also includes:

[0070] S210: Acquire the provided asynchronous interface path, the path that needs to confirm the timing, and the path that has not converged the timing;

[0071] S220: Determine a test case based on the asynchronous interface path, the path that needs to confirm the timing, and the path that has not converged the timing;

[0072] S230: Perform register transfer level simulation using the test case to ensure that the asynchronous interface path, the path that needs to confirm the timing, and the path that has not converged the timing are covered;

[0073] The compiling and simulating according to the gate-level netlist and the standard delay format file includes: loading the test case, and compiling and simulating according to the gate-level netlist and the standard delay format file.

[0074] During specific implementation, in S210 , the asynchronous interface path, the path that needs to confirm the timing, and the path that has not converged the timing are obtained from the chip design department.

[0075] The asynchronous interface path refers to the path through which different modules or subsystems communicate through asynchronous signals in integrated circuit design. The asynchronous interface path may include but is not limited to:

[0076] The data conversion path from one clock domain to another clock domain;

[0077] Propagation path of asynchronous reset signal;

[0078] Processing path of asynchronous interrupt request;

[0079] No clocked external interface communication path;

[0080] In the post-simulation process, these asynchronous interface paths may cause timing violations. Therefore, designers will consider these paths in the RTL simulation stage and ensure that the test cases can cover these important asynchronous communication scenarios so that problems can be discovered and resolved as early as possible.

[0081] Among them, the paths that need to confirm the timing refer to the signal paths that are critical to chip performance in integrated circuit design. The timing characteristics of these paths must be strictly verified to ensure the correctness of chip functions and the reliability of performance. For example, data paths, control logic, clock networks, memory access paths, etc.

[0082] Among them, the unconverged timing path refers to the signal path that still fails to meet the predetermined timing constraint requirements after multiple iterations of optimization during the chip design process. The problems of these paths may have a negative impact on the function and performance of the entire chip.

[0083] In S220 and S230, appropriate test cases are selected in the RTL simulation stage and simulated to ensure that all asynchronous interface paths, paths that need to confirm timing, and paths that have not converged timing are covered. In actual operation, multiple test cases are usually selected to ensure that all critical paths and timing-sensitive areas in the design are covered. The selection of test cases should comprehensively consider the needs of functional verification and timing verification, and be adjusted according to actual conditions. Through multi-angle and multi-level test cases, the correctness and reliability of the design can be more comprehensively verified.

[0084] After executing S210-S230, test cases covering all asynchronous interface paths, paths that need to confirm timing, and paths that have not converged timing are obtained. This test case will be used in the post-simulation process, that is, when executing S120, the test case obtained by S210-S230 will be loaded, and then compiled and simulated according to the gate-level netlist and standard delay format file.

[0085] Specifically, when executing S120, an EDA tool may be used to compile, configure a simulation environment, load a PR netlist and a corresponding SDF file, and run a simulation. During the simulation, the software will calculate the actual signal propagation time according to the delay information in the PR netlist and the SDF file to determine whether there is a timing violation (TV). If there is a timing violation, a simulation report containing TV is generated.

[0086] Specifically, the compilation simulation in S120 refers to gate-level simulation, which is a link in the post-simulation process of integrated circuits. At this stage, the circuit model that has completed layout and routing is used for simulation, and the simulation is based on the actual PR netlist and SDF file. Gate-level simulation is usually performed after register transfer level (RTL) simulation, and its purpose is to verify whether the behavior of the circuit at the physical implementation level meets expectations. Gate-level simulation can more accurately reflect the behavior of the actual chip.

[0087] In S130, an automated script (such as ModelSim, VCS, etc.) is used to extract timing violation information. The timing violation information may include the timing violation signal path, the violation amount, the violation type (setup, hold, recovery, removal), etc. Then, according to the level at which the timing violation information is located, the timing violation information is stored in different files. The "level" here refers to the logical level or module level where the timing path is located. Specifically, the level can refer to different subsystems, modules or hierarchical structures in the design. For example, in a complex SoC design, there may be multiple subsystems, such as CPU, memory controller, DMA controller, etc., and each subsystem may contain multiple levels of modules. Such storage can help manage timing information more efficiently when processing large integrated circuit designs. Based on this, in some embodiments, after extracting the timing violation information from the simulation report, it also includes:

[0088] The timing violation information is classified and saved in different files according to different levels.

[0089] The following example illustrates the storage of timing violation information in different files according to hierarchical classification:

[0090] 1. Suppose you design a complex microprocessor chip that contains the following main modules:

[0091] Cache Controller (cache_controller)

[0092] Arithmetic logic unit (ALU)

[0093] Branch prediction unit (branch_predictor)

[0094] Memory interface (memory_interface)

[0095] Clock Generator (clock_generator)

[0096] 2. During the post-simulation process, some timing violations were found. These timing violations are distributed in different modules, as follows:

[0097] cache_controller: There are 2 timing violations

[0098] alu: There are 5 timing violations

[0099] branch_predictor: There are 3 timing violations

[0100] memory_interface: There is 1 timing violation

[0101] clock_generator: There are 2 timing violations

[0102] 3. Store these timing violation information in different files according to the hierarchy. Create 5 different files corresponding to 5 different modules: cache_controller / tv_report.txt, alu / tv_report.txt, branch_predictor / tv_report.txt, memory_interface / tv_report.txt, clock_generator / tv_report.txt. And create a folder to organize these files, such as tv_analysis.

[0103] The tv_report.txt file in each folder will contain the timing violation information for that module. An example of the contents of one of these files is as follows:

[0104] cache_controller / tv_report.txt

[0105] 1#Cache Controller Timing Violation Report 2

[0107] 3##Timing Violation 1

[0108] 4-Path:cache_controller / data_path / rd_data_to_cpu (timing violation signal path)

[0109] 5-Type: Setup Violation (Violation type)

[0110] 6-Violation Value: 1.2 ns (Expected < 1.0 ns) (Violation value)

[0111] 7-Description:Data read from cache to CPU setup violation 8

[0113] 9##Timing Violation 2

[0114] 10-Path:cache_controller / tag_compare_unit / tag_match_to_cache_ctrl

[0115] 11-Type:Hold Violation

[0116] 12-Violation Value:0.8 ns(Expected>1.0ns)

[0117] 13-Description:Tag match hold violation

[0118] This hierarchical storage method can clearly organize and manage the timing violation information in each module. When designers need to view the timing violation of a specific module, they can directly open the corresponding folder to view the relevant files, which greatly simplifies the search and analysis process. At the same time, this classified storage method also helps automated tools process this information, such as automatically generating files for disabling timing checks and filtering files.

[0119] In S140, after the timing violation information is extracted, the timing violation information needs to be analyzed. The file containing the timing violation information can be sent to the designer, and the designer analyzes each timing violation by reading the file information, determines the cause (whether it is caused by wiring delay or logic design problem), and proposes a solution. Or an expert system running on a computer, or based on big data (AI) for analysis / review. Then, the timing violation information that does not need to be reviewed again is determined and recorded in a file, so as not to display the recorded timing violation information in the subsequent simulation process. Based on this, in some embodiments, the analysis of the extracted timing violation information, the determination of the timing violation information that does not need to be reviewed again and the recording in a file, so as not to display the recorded timing violation information in the subsequent simulation process, includes:

[0120] The extracted timing violation information is analyzed to determine the timing violation information that does not need to be checked again during compilation, and is recorded in a timing check prohibition file, wherein the timing check prohibition file is used in the process of recompiling the simulation, and the timing violation information recorded in the file is not recorded in the simulation report.

[0121] Specifically, in S140, after analyzing the extracted timing violation information, a "PR netlist simulation TV analysis result" document can be generated first, which includes the analysis results of the timing violation information in the chip post-simulation process, such as which timing violations are acceptable and which are unacceptable, the violation paths of these timing violations, the specific locations where they occur, etc. The document can be analyzed and filled in by the designer. Based on the above-mentioned timing violation information being saved in different files according to different levels, the "PR netlist simulation TV analysis result" document can also fill in the timing violation information according to different levels.

[0122] Then, in order to avoid repeatedly analyzing the same timing violation information in subsequent iterations and recording it in the simulation report, this application processes this "PR Netlist Simulation TV Analysis Results" document through an automated script, and then extracts the timing violation information that does not need to be checked again from the "PR Netlist Simulation TV Analysis Results" document. These timing violation information that do not need to be checked again can also be recorded in the prohibited timing check file (hereinafter referred to as notimingcheck.lst) according to the different levels at which they are located. During the next simulation, the compilation process will read notimingcheck.lst, and the recorded timing violation information will no longer be reported. The above process can be that the designer sends the "PR Netlist Simulation TV Analysis Results" document to the verification personnel, and the verification personnel perform corresponding processing.

[0123] Taking the example in S130 as an example, after performing timing analysis on the design, the following timing violation information is found and is considered not to require further review:

[0124] In the cache_controller module, there is a setup time violation in the data_path / rd_data_to_cpu path, but analysis confirmed that this is a non-critical path.

[0125] In the alu module, there is a hold time violation in the adder_unit / carry_propagate path, but due to redundancy in the design, this violation will not affect the overall performance.

[0126] In the memory_interface module, there is a setup time violation in the read_data_from_memory path, but this violation is caused by external memory latency and cannot be controlled.

[0127] Based on the above information, a simple notimingcheck.lst file can be constructed:

[0128] plaintext

[0129] 1#notimingcheck.lst

[0130] 2#

[0131] 3# This file records timing violations that do not require further inspection

[0132] 4# 5

[0134] 6#Cache Controller

[0135] 7# The path from cache to CPU is a non-critical path

[0136] 8cache_controller / data_path / rd_data_to_cpu 9

[0138] 10#ALU

[0139] The carry propagation path in the adder unit #11 has a hold time violation, but it does not affect the overall performance

[0140] 12alu / adder_unit / carry_propagate 13

[0142] 14#Memory Interface

[0143] 15# The path to read data from external memory is affected by external delays

[0144] 16memory_interface / read_data_from_memory

[0145] In this file, each entry specifies a specific signal path where timing violations are considered known issues and are not further checked.

[0146] From the above example, it can be seen that the notimingcheck.lst file only needs to record the timing violation signal path included in the timing violation information, and the violation amount and violation type (setup, hold, recovery, removal) included in the timing violation information may not be recorded.

[0147] In some embodiments, it also includes:

[0148] Analyze the extracted timing violation information, determine the timing violation information that does not need to be extracted from the simulation report, and generate a corresponding filter mode and record it in a filter file, wherein the filter file is used to filter out the corresponding timing violation information according to the recorded filter mode during the process of extracting the timing violation information again.

[0149] In some embodiments, the determining the timing violation information that does not need to be extracted from the simulation report and generating a corresponding filtering mode record in a filtering file includes:

[0150] Determining that the timing violation information extracted from the simulation report is reasonable timing violation information;

[0151] A filtering pattern is generated according to the timing violation information determined to be reasonable, and the filtering pattern is recorded in a filtering file.

[0152] Specifically, in S140, in order to avoid repeatedly analyzing and extracting the same timing violation information from the simulation report in subsequent iterations, after extracting the timing violation information from the "PR Netlist Simulation TV Analysis Results" document, the timing violation information can be analyzed to determine the reasonable timing violation information therein, and the reasonable timing violation information can also generate a filtering pattern, and then the filtering pattern is recorded in the filtering file (hereinafter referred to as waive_pattern file) according to the different levels of classification. In the next simulation, the compilation process will read waive_pattern, and in the process of extracting the timing violation information again, the corresponding timing violation information will be filtered out according to the recorded filtering pattern, and the timing violation information will not appear in the simulation report. The above process can be that the designer sends the "PR Netlist Simulation TV Analysis Results" document to the verification personnel, and the verification personnel perform corresponding processing.

[0153] Specifically, the patterns in the waive_pattern file are rules or standards used to filter timing violations. Using patterns can more flexibly define when a timing violation should be ignored. These patterns can be based on partial string matching of the (timing violation signal) path, based on timing check types (such as setup, hold), or based on other conditions (such as clock edges, data conditions, etc.) Combination rules.

[0154] 1. The path-based mode specifies certain timing paths or parts of paths. If timing violations occur on these paths, these violations can be ignored.

[0155] For example: *cpu / data_path / * means any timing violation occurring under cpu / data_path can be ignored.

[0156] 2. The mode based on the timing check type is to specify that a specific type of timing check can be ignored.

[0157] For example: *setup* means that all setup type timing violations can be ignored.

[0158] 3. The condition-based mode specifies timing violations that can be ignored under certain conditions.

[0159] For example: *clk_period>2ns setup* means that the setup type timing violation can be ignored only when the clock period is greater than 2 nanoseconds.

[0160] Taking the example in S130 as an example, after performing timing analysis on the design, the following timing violation information is found and is considered not to require further review:

[0161] In the cache_controller module, there is a setup time violation in the data_path / rd_data_to_cpu path, but analysis confirmed that this is a non-critical path.

[0162] In the alu module, there is a hold time violation in the adder_unit / carry_propagate path, but due to redundancy in the design, this violation will not affect the overall performance.

[0163] In the memory_interface module, there is a setup time violation in the read_data_from_memory path, but this violation is caused by external memory latency and cannot be controlled.

[0164] Based on the above information, a simple waive_pattern file can be constructed:

[0165] plaintext

[0166] 1#waive_pattern

[0167] 2#

[0168] 3#This document defines the mode for filtering timing violations

[0169] 4# 5

[0171] 6#Cache Controller

[0172] 7# The path from cache to CPU is a non-critical path

[0173] 8cache_controller / data_path / * 9

[0175] 10#ALU

[0176] The carry propagation path in the adder unit #11 has a hold time violation, but it does not affect the overall performance

[0177] 12alu / adder_unit / carry_propagate / * 13

[0179] 14#Memory Interface

[0180] 15# The path to read data from external memory is affected by external delays

[0181] 16memory_interface / read_data_from_memory / *

[0182] In this file, each entry specifies a pattern that is used to match a specific signal path.

[0183] Specifically, the filtering file can be divided into two types. First, when filtering specified test cases, only the timing violation information of the specified test case simulation report is filtered, while the timing violation information of the unspecified test case simulation report cannot be filtered; second, when filtering all test cases, the corresponding timing violation information is filtered out of all test cases.

[0184] In this way, it can be ensured that these timing violations that have been confirmed to be acceptable are ignored in subsequent simulations, thereby optimizing the simulation process and reducing unnecessary checks.

[0185] From the above, the present application automatically extracts timing violation information from a simulation report containing timing violation information after simulation, analyzes the timing violation information to determine the timing violation information that does not need to be reviewed again, and does not display the recorded timing violation information during the subsequent simulation process. In this way, through a series of methods, such as automatic extraction of timing violations, automatic filtering of interference information, information filtering after analysis, and retention of analysis results, the workload of manual confirmation is reduced, the workload of iterative regression and repeated confirmation within a single project is reduced, and the timing violation information that does not need to be reviewed again is recorded in a file. In this way, the analysis results can be reused among multiple projects, reducing the workload of repeated confirmation of multiple projects, improving the efficiency of post-simulation work, saving post-simulation time, and thus shortening the chip tape-out time.

[0186] [Second embodiment of the device for post-chip simulation of the present application]

[0187] In some embodiments, the above-generated "PR netlist simulation TV analysis results", notimingcheck.lst and waive_pattern files need to be reviewed. After the review, these files can be used as the delivery results of chip post-simulation and can be used as input materials for the post-simulation stage of subsequent projects. Figure 3 The following is a method for performing post-simulation using the notimingcheck.lst and waive_pattern files. The specific process is as follows:

[0188] S310: Obtaining a gate-level netlist and a standard delay format file of the designed chip;

[0189] S320: compile and simulate according to the gate-level netlist, the standard delay format file, and the timing check prohibition file, and generate a simulation report containing timing violation information; wherein the timing check prohibition file records information of timing violations that do not need to be checked, so that such timing violation information is not recorded in the simulation report during the compilation process;

[0190] S330: extracting timing violation information from the simulation report according to a filtering file; wherein the filtering file records a filtering mode of timing violation, so that when extracting timing violation information, corresponding timing violation information is filtered out according to the filtering mode;

[0191] S340: Generate post-chip simulation results based on the extracted timing violation information.

[0192] Specifically, when performing post-simulation again, the recompiled simulation report will not include the information of timing violations that do not need to be checked recorded in the prohibited timing check file obtained from the last post-simulation. The advantage of this is that it can reduce the noise in the timing analysis report, allowing engineers to focus more on the problems that really need to be solved. At the same time, when extracting the timing violation information this time, the timing violation information mentioned in the filter file will be excluded according to the filter mode in the filter file. The advantage of this is that it can reduce the noise in the timing analysis report, allowing engineers to focus more on the problems that really need to be solved.

[0193] Specifically, there are two types of filter files. First, when filtering specified test cases, only the timing violation information of the specified test case simulation report is filtered, while the timing violation information of the unspecified test case simulation report cannot be filtered; second, when filtering all test cases, the corresponding timing violation information is filtered out of all test cases.

[0194] [First specific implementation method of the chip post-simulation method]

[0195] This application describes the entire process from selecting appropriate test cases in the design phase, to extracting timing violations in the back-end simulation phase, to analysis and automated processing by designers, and finally to document review and delivery. This series of steps can significantly improve the efficiency of the post-simulation process, reduce duplication of work, and help speed up the chip development cycle. Figure 4 As shown, including:

[0196] (1) The design direction verification team provides asynchronous interface paths, paths that need to confirm timing, and paths that have not converged timing.

[0197] (2) Based on the asynchronous interface paths, paths that need to confirm timing, and paths that have not converged timing, the verifier selects appropriate test cases for register transfer level (RTL) simulation to ensure that these paths are covered.

[0198] (3) The back-end party provides the netlist after layout and routing (PR netlist) and standard delay file (SDF).

[0199] (4) The verifier will load the above test case and compile and simulate it using the PR netlist and SDF file to obtain a simulation report. If there is timing violation information, the simulation report will include the timing violation information.

[0200] Then, use the automated script to extract the timing violation information from the simulation report. If it is extracted, the timing violation information is saved by hierarchical classification and sent to the designer. If it is not extracted, determine whether all the above test cases have been simulated. If not, return to continue compiling and simulating, continue to extract the timing violation information and determine whether it exists. If all the simulations are completed and there is no violation, then end.

[0201] During this stage, the back-end party will determine at any time whether to obtain a new PR netlist or SDF. If a new one is obtained, it will be provided to the verification party for compilation and simulation. If no new one is obtained, the automatic extraction of timing violations will continue.

[0202] (5) The designer will receive the simulation report and analyze the timing violation information therein. Based on the analysis results, the designer will fill out the “PR Netlist Simulation TV Analysis Results” document and send it to the verification team for verification.

[0203] (6) The verifier will use an automated script to generate two files, notimingcheck.lst and waive_pattern, based on the "PR Netlist Simulation TV Analysis Results" document. In the next round of simulation, the notimingcheck.lst and waive_pattern files are used to filter out known and verified timing violation information.

[0204] Finally, the verification team and the design team need to review the "PR netlist simulation TV analysis results" document, notimingcheck.lst and waive_pattern files. The reviewed documents and files are used as the deliverables of chip post-simulation and can be used as inputs for the post-simulation phase of subsequent projects. These files help the teams of subsequent projects quickly understand potential problem points and avoid duplication of work.

[0205] [The first embodiment of the device for post-chip simulation of the present application]

[0206] like Figure 5 As shown, the embodiment of the present application provides a device for post-chip simulation, and the device for post-chip simulation can be used to implement the method for post-chip simulation in the first embodiment above, such as Figure 5 As shown, the chip post-simulation device comprises an acquisition module 510 , a compilation simulation module 520 , an extraction module 530 , and a file generation module 540 .

[0207] The acquisition module is used to obtain the gate-level netlist and standard delay format file of the designed chip;

[0208] A compiling and simulating module, used for compiling and simulating according to the gate-level netlist and the standard delay format file, and generating a simulation report including timing violation information;

[0209] An extraction module, used for extracting timing violation information from the simulation report;

[0210] The file generation module is used to analyze the extracted timing violation information, determine the timing violation information that does not need to be checked again and record it in a file so as not to display the recorded timing violation information in a subsequent simulation process.

[0211] For details, please refer to the detailed description in the first embodiment of the method, which will not be repeated here.

[0212] [Second embodiment of the device for post-chip simulation of the present application]

[0213] like Figure 6 As shown, the embodiment of the present application provides a device for post-chip simulation, and the device for post-chip simulation can be used to implement the method for post-chip simulation in the above embodiment, such as Figure 6 As shown, the chip post-simulation device comprises an acquisition module 610 , a compilation simulation module 620 , an extraction module 630 , and a result generation module 640 .

[0214] The acquisition module is used to obtain the gate-level netlist and standard delay format file of the designed chip;

[0215] A compiling and simulating module, for compiling and simulating according to the gate-level netlist, the standard delay format file, and the timing check prohibition file, and generating a simulation report containing timing violation information; wherein the timing check prohibition file records information on timing violations that do not need to be checked, so that such timing violation information is not recorded in the simulation report during the compiling process;

[0216] An extraction module, configured to extract timing violation information from the simulation report according to a filter file; wherein the filter file records a filtering mode of timing violation, so that when extracting timing violation information, corresponding timing violation information is filtered out according to the filtering mode;

[0217] The result generation module is used to generate the result of post-chip simulation based on the extracted timing violation information.

[0218] For details, please refer to the detailed description in the second embodiment of the method, which will not be repeated here.

[0219] [Embodiment of the computing device of the present application]

[0220] Figure 7900 is a schematic structural diagram of a computing device 900 provided in an embodiment of the present application. The computing device can be used as a post-chip simulation device to perform various optional embodiments of the post-chip simulation method described above. The computing device can be a terminal or a chip or chip system inside a terminal. Figure 7 As shown, the computing device 900 includes: a processor 910 , a memory 920 , and a communication interface 930 .

[0221] It should be understood that Figure 7 The communication interface 930 in the computing device 900 shown may be used to communicate with other devices, and may specifically include one or more transceiver circuits or interface circuits.

[0222] The processor 910 may be connected to a memory 920. The memory 920 may be used to store the program code and data. Therefore, the memory 920 may be a storage unit inside the processor 910, or an external storage unit independent of the processor 910, or a component including a storage unit inside the processor 910 and an external storage unit independent of the processor 910.

[0223] Optionally, the computing device 900 may further include a bus. The memory 920 and the communication interface 930 may be connected to the processor 910 via the bus. The bus may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 7 A line without an arrow is used to represent the bus, but this does not mean that there is only one bus or one type of bus.

[0224] It should be understood that in the embodiment of the present application, the processor 910 may adopt a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. Alternatively, the processor 910 may adopt one or more integrated circuits to execute relevant programs to implement the technical solutions provided in the embodiment of the present application.

[0225] The memory 920 may include a read-only memory and a random access memory, and provides instructions and data to the processor 910. A portion of the processor 910 may also include a nonvolatile random access memory. For example, the processor 910 may also store information on the device type.

[0226] When the computing device 900 is running, the processor 910 executes the computer-executable instructions in the memory 920 to perform any operation step of the above method and any optional embodiment thereof.

[0227] It should be understood that the computing device 900 according to the embodiment of the present application can correspond to the corresponding subjects in the methods according to the embodiments of the present application, and the above-mentioned and other operations and / or functions of each module in the computing device 900 are respectively for realizing the corresponding processes of each method of the present embodiment, which will not be repeated here for the sake of brevity.

[0228] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0229] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0230] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0231] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0232] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0233] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0234] An embodiment of the present application also provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, it is used to execute the above method, which includes at least one of the solutions described in the above embodiments.

[0235] The computer storage medium of the embodiment of the present application can adopt any combination of one or more computer-readable media. Computer-readable media can be computer-readable signal media or computer-readable storage media. Computer-readable storage media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or devices, or any combination of the above. More specific examples (non-exhaustive lists) of computer-readable storage media include: electrical connections with one or more wires, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above. In this document, computer-readable storage media can be any tangible medium containing or storing programs, which can be used by instruction execution systems, devices or devices or used in combination with them.

[0236] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, which carry computer-readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0237] The program code embodied on the computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0238] Computer program code for performing the operation of the present application can 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 can 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 can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., using an Internet service provider to connect through the Internet).

[0239] In addition, the words "first, second, third, etc." or module A, module B, module C and other similar terms in the specification and claims are only used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that the specific order or sequence can be interchanged where permitted so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0240] In the above description, the numbers representing the steps, such as S110, S120, etc., do not necessarily mean that the steps will be executed in this manner. If permitted, the order of the steps can be interchanged or they can be executed simultaneously.

[0241] The term "comprising" as used in the description and claims should not be interpreted as being limited to what is listed thereafter; it does not exclude other elements or steps. Therefore, it should be interpreted as specifying the presence of the features, integers, steps or components mentioned, but does not exclude the presence or addition of one or more other features, integers, steps or components and groups thereof. Therefore, the expression "a device comprising means A and B" should not be limited to a device consisting of components A and B only.

[0242] References to "one embodiment" or "an embodiment" in this specification mean that a particular feature, structure, or characteristic described in conjunction with the embodiment is included in at least one embodiment of the present application. Therefore, the phrases "in one embodiment" or "in an embodiment" appearing in various places in this specification do not necessarily refer to the same embodiment, but may refer to the same embodiment. In addition, in one or more embodiments, the particular features, structures, or characteristics can be combined in any appropriate manner, as would be apparent to one of ordinary skill in the art from this disclosure.

[0243] Note that the above are only preferred embodiments of the present application and the technical principles used. Those skilled in the art will understand that the present application is not limited to the specific embodiments described herein, and that various obvious changes, readjustments and substitutions can be made by those skilled in the art without departing from the scope of protection of the present application. Therefore, although the present application is described in more detail through the above embodiments, the present application is not limited to the above embodiments, and may also include more other equivalent embodiments without departing from the concept of the present application, all of which belong to the scope of protection of the present application.

Claims

1. A chip post-simulation method, characterized in that: include: Obtain the gate-level netlist and standard delay format file of the designed chip; Compile and simulate according to the gate-level netlist and the standard delay format file, and generate a simulation report containing timing violation information; extracting timing violation information from the simulation report; The extracted timing violation information is analyzed, and the timing violation information that does not need to be reviewed again is determined and recorded in a file so as not to display the recorded timing violation information in a subsequent simulation process.

2. The method according to claim 1, characterized in that Also includes: Get the provided asynchronous interface paths, paths that need to confirm timing, and paths that have not converged timing; Determine a test case based on the asynchronous interface path, the path that needs to confirm the timing, and the path that has not converged the timing; Performing register transfer level simulation using the test case to ensure that the asynchronous interface path, the path that needs to confirm the timing, and the path that has not converged the timing are covered; The compiling and simulating according to the gate-level netlist and the standard delay format file includes: loading the test case, and compiling and simulating according to the gate-level netlist and the standard delay format file.

3. The method according to claim 1, characterized in that After extracting the timing violation information from the simulation report, the method further includes: The timing violation information is classified and saved in different files according to different levels.

4. The method according to claim 1 or 3, characterized in that The analyzing the extracted timing violation information, determining the timing violation information that does not need to be checked again and recording it in a file so as not to display the recorded timing violation information in a subsequent simulation process, includes: The extracted timing violation information is analyzed to determine the timing violation information that does not need to be checked again during compilation, and is recorded in a timing check prohibition file, wherein the timing check prohibition file is used in the process of recompiling the simulation, and the timing violation information recorded in the file is not recorded in the simulation report.

5. The method according to claim 1 or 3, characterized in that: Also includes: Analyze the extracted timing violation information, determine the timing violation information that does not need to be extracted from the simulation report, and generate a corresponding filter mode and record it in a filter file, wherein the filter file is used to filter out the corresponding timing violation information according to the recorded filter mode during the process of extracting the timing violation information again.

6. The method according to claim 5, characterized in that The determining of timing violation information that does not need to be extracted from the simulation report and generating a corresponding filtering mode record in a filtering file includes: Determining that the timing violation information extracted from the simulation report is reasonable timing violation information; A filtering pattern is generated according to the timing violation information determined to be reasonable, and the filtering pattern is recorded in a filtering file.

7. A chip post-simulation method, characterized in that: include: Obtain the gate-level netlist and standard delay format file of the designed chip; Compile and simulate according to the gate-level netlist, the standard delay format file, and the timing check prohibition file, and generate a simulation report containing timing violation information; wherein the timing check prohibition file records information of timing violations that do not need to be checked, so that such timing violation information is not recorded in the simulation report during the compilation process; Extracting timing violation information from the simulation report according to a filter file; wherein the filter file records a filtering mode of timing violation, so that when extracting timing violation information, corresponding timing violation information is filtered out according to the filtering mode; Post-chip simulation results are generated based on the extracted timing violation information.

8. A device for post-chip simulation, characterized in that: include: An acquisition module, used to acquire a gate-level netlist and a standard delay format file of the designed chip; A compiling and simulating module, used for compiling and simulating according to the gate-level netlist and the standard delay format file, and generating a simulation report including timing violation information; An extraction module, used for extracting timing violation information from the simulation report; The file generation module is used to analyze the extracted timing violation information, determine the timing violation information that does not need to be checked again and record it in a file so as not to display the recorded timing violation information in a subsequent simulation process.

9. A device for post-chip simulation, characterized in that: include: An acquisition module, used to acquire a gate-level netlist and a standard delay format file of the designed chip; A compiling and simulating module, for compiling and simulating according to the gate-level netlist, the standard delay format file, and the timing check prohibition file, and generating a simulation report containing timing violation information; wherein the timing check prohibition file records information on timing violations that do not need to be checked, so that such timing violation information is not recorded in the simulation report during the compiling process; An extraction module, configured to extract timing violation information from the simulation report according to a filter file; wherein the filter file records a filtering mode of timing violation, so that when extracting timing violation information, corresponding timing violation information is filtered out according to the filtering mode; The result generation module is used to generate the result of post-chip simulation based on the extracted timing violation information.

10. A computing device, characterized in that include: processor, and A memory having program instructions stored thereon, wherein when the program instructions are executed by the processor, the processor is caused to execute the method according to any one of claims 1 to 6.

Images