Method and apparatus for post-silicon simulation

Abstract

The application relates to a chip post-simulation method and device, which comprises the following steps: obtaining a gate-level netlist and a standard delay format file of a designed chip; compiling and simulating according to the gate-level netlist and the standard delay format file, and generating a simulation report containing timing violation information; extracting the timing violation information from the simulation report; analyzing the extracted timing violation information, determining timing violation information that does not need to be viewed again, and recording the timing violation information to a file, so as to not show the recorded timing violation information in the subsequent post-simulation process. The application can reduce the workload of manual confirmation, reduce the workload of iterative regression repeated confirmation in a single project, reuse the analysis result among multiple projects, reduce the workload of repeated confirmation among multiple projects, improve the post-simulation work efficiency, save the post-simulation time, and thus shorten the chip tape-out time.

Description

TECHNICAL FIELD

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

[0002] In the chip development process, in order to determine the timing constraints in the chip back-end design and the rationality of the layout and routing, the post-layout netlist (referred to as PR netlist) and the standard delay file (Standard Delay Format, SDF) under different scenarios need to be simulated. Such simulation is called post-simulation, which 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 long signal paths. 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 prior art needs manual confirmation of rationality, and each iteration regression needs repeated confirmation. In addition, the confirmation result cannot be used as input for subsequent projects, resulting in repeated confirmation during project iteration. This increases the workload of manual confirmation, the workload of repeated confirmation in single project iteration regression, and the workload of repeated confirmation in multiple projects due to the inability to reuse analysis results across multiple projects, thereby reducing the efficiency of post-simulation, increasing the time of post-simulation, and prolonging the chip tape-out time. SUMMARY

[0004] In view of the above problems of the prior art, the present application provides a chip post-simulation method and device, a computing device and a storage medium, which can reduce the workload of manual confirmation, reduce the workload of repeated confirmation in single project iteration regression, reuse analysis results across multiple projects, reduce the workload of repeated confirmation in multiple projects, improve the efficiency of post-simulation, save the time of post-simulation, and thus shorten the chip tape-out time.

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

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

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

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

[0009] The extracted timing violation information is analyzed to determine timing violation information that does not need to be reviewed again and record the timing violation information to a file to not show the recorded timing violation information in a re-simulation process.

[0010] From the above, the application extracts timing violation information from a simulation report containing timing violation information after simulation, analyzes the timing violation information to determine timing violation information that does not need to be reviewed again, and does not show the recorded timing violation information in a re-simulation process. Thus, the workload of manual confirmation is reduced, the workload of repeated confirmation in a single project is reduced, the timing violation information that does not need to be reviewed again is recorded to a file, the analysis result can be reused between multiple projects, the workload of repeated confirmation in multiple projects is reduced, the work efficiency of post-simulation is improved, the post-simulation time is saved, and the chip tape-out time is shortened.

[0011] As a possible implementation of the first aspect, further comprising:

[0012] The provided asynchronous interface path, the path requiring timing confirmation, and the path with non-converged timing are acquired;

[0013] The test case is determined based on the asynchronous interface path, the path requiring timing confirmation, and the path with non-converged timing.

[0014] The register transfer level simulation is performed using the test case to ensure that the asynchronous interface path, the path requiring timing confirmation, and the path with non-converged timing are covered.

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

[0016] As a possible implementation of the first aspect, after the timing violation information is extracted from the simulation report, further comprising:

[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, the analysis of the extracted timing violation information to determine timing violation information that does not need to be reviewed again and record the timing violation information to a file to not show the recorded timing violation information in a re-simulation process includes:

[0019] The extracted timing violation information is analyzed to determine timing violation information that does not need to be reviewed again and record the timing violation information to a file to not show the recorded timing violation information in a re-simulation process includes:

[0020] As a possible implementation form of the first aspect, the determining of the timing violation information that does not need to be checked again in the compiling, and recording the timing violation information that does not need to be checked again into the forbidden timing check file, comprises:

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

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

[0023] The timing violation information that is determined to be reasonable timing violation information in the timing violation information extracted from the simulation report is determined.

[0024] The file path corresponding to the timing violation information that is determined to be reasonable timing violation information is recorded into the filtering file.

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

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

[0027] performing compiling simulation according to the gate-level netlist and the standard delay format file, and generating a simulation report containing timing violation information; wherein the forbidden timing check file records timing violation information that does not need to be checked, so that the timing violation information that does not need to be checked is not recorded into the simulation report in the compiling process;

[0028] 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 the corresponding timing violation information is filtered out according to the filtering mode when the timing violation information is extracted;

[0029] generating a result of the chip post-simulation based on the extracted timing violation information.

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

[0031] an obtaining module, configured to obtain a gate-level netlist and a standard delay format file of a designed chip;

[0032] a compiling simulation module, configured to perform compiling simulation according to the gate-level netlist and the standard delay format file, and generate a simulation report containing timing violation information;

[0033] an extracting module, configured to extract timing violation information from the simulation report;

[0034] A file generation module is configured to analyze the extracted timing violation information, determine timing violation information that does not need to be reviewed again, and record the timing violation information to a file, so as to not display the recorded timing violation information in a re-simulation process.

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

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

[0037] A obtaining module is configured to obtain a gate-level netlist and a standard delay format file of a designed chip.

[0038] A compiling simulation module is configured to perform compiling simulation according to the gate-level netlist and the standard delay format file, and a forbidden timing check file, and generate a simulation report containing timing violation information; wherein the forbidden timing check file records information of timing violations that do not need to be checked, so that these timing violation information is not recorded in the simulation report in the compiling process.

[0039] An extracting module is configured to extract 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 corresponding timing violation information is filtered out according to the filtering mode when extracting timing violation information.

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

[0041] The fifth aspect of the present application provides a computing device, comprising:

[0042] a processor, and

[0043] a memory having program instructions stored thereon, the program instructions, when executed by the processor, causing the processor to execute the method of any one of the first aspect.

[0044] The sixth aspect of the present application provides a computer readable storage medium having program instructions stored thereon, the program instructions, when executed by a computer, causing the computer to implement the method of any one of the first aspect. BRIEF DESCRIPTION OF DRAWINGS

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

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

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

[0048] Figure 4 This is a flowchart of a specific implementation of a chip post-simulation method provided in this application embodiment;

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

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

[0051] Figure 7 This is a schematic structural diagram of a computing device provided in an embodiment of this application.

[0052] It should be understood that the dimensions and shapes of the block diagrams in the above structural diagrams are for reference only and should not constitute an exclusive interpretation of the embodiments of this application. The relative positions and inclusion relationships between the block diagrams presented in the structural diagrams are only schematic representations of the structural relationships between the block diagrams, and are not intended to limit the physical connection methods of the embodiments of this application. Detailed Implementation

[0053] The technical solutions provided in this application will be further described below with reference to the accompanying drawings and embodiments. It should be understood that the system architecture and business scenarios provided in the embodiments of this application are mainly for illustrating possible implementations of the technical solutions of this application and should not be construed as the sole limitation on the technical solutions of this application. Those skilled in the art will recognize that the technical solutions provided in this application are equally applicable to similar technical problems as system architectures evolve and new business scenarios emerge.

[0054] It should be understood that the chip post-simulation solutions provided in this application include chip post-simulation methods and apparatus. Since these technical solutions solve problems based on the same or similar principles, some repetitive details may not be repeated in the following descriptions of specific embodiments. However, it should be considered that these specific embodiments have mutual references and can be combined with each other.

[0055] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. In case of any inconsistency, the meaning set forth in this specification or derived from the content described herein shall prevail. Furthermore, the terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application. To accurately describe the technical content of this application and to accurately understand the invention, the following explanations or definitions of the terms used in this specification are provided before describing specific embodiments:

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

[0057] 2. Placement and routing: refers to determining the location of each component on the chip and the connection method between them on the physical level.

[0058] 3. Netlist: is an abstract representation of circuit design, which defines how each component is connected together to form a circuit. The netlist after placement and routing (PR netlist) refers to the netlist that has completed physical placement and routing.

[0059] 4. SDF (Standard Delay Format): is a standard delay file format used to store and transmit 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, and other timing information.

[0060] 5. Post-simulation: is a simulation using gate-level netlist and standard delay format file after completing placement and routing, which aims to verify whether the actual performance of the circuit meets the expected design target.

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

[0062]

First embodiment of the method of post-simulation of chip

[0063] To solve the problem of manual confirmation of the rationality of timing violation in the prior art, each iteration regression needs to repeat the confirmation, and the confirmation result cannot be used as the input of the subsequent project, which leads to the need for repeated confirmation during project iteration. This increases the workload of manual confirmation, the workload of repeated confirmation in single project iteration regression, and the workload of repeated confirmation in multiple projects due to the inability to reuse the analysis results among multiple projects, thereby reducing the efficiency of post-simulation, increasing the time of post-simulation, and prolonging the time of chip tape-out. The present application provides a method of post-simulation of chip, as shown in Figure 1 , the method comprises:

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

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

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

[0067] S140: analyze the extracted timing violation information, determine timing violation information that does not need to be reviewed again, and record it to a file, so as to not display the recorded timing violation information in the re-simulation process.

[0068] In some embodiments, in S110, the physical implementation of the chip is completed in the backend department, and the layout and routing (PR) netlist and standard delay format (SDF) file are obtained after the physical implementation of the chip is completed. The PR netlist and SDF file contain specific physical implementation information about the chip design, including delay data, etc.

[0069] In implementation, in the simulation process of S120, test cases of register transfer level simulation (RTL stage simulation) are needed, where RTL stage simulation is a stage in which designers use HDL (hardware description language, such as Verilog or VHDL) to describe the behavior of a circuit. At this stage, the design focuses on the logical function, rather than the 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 perform as expected in logic. In the RTL stage, appropriate test cases need to be selected to cover the specified critical paths, such as asynchronous interface paths, paths that need to be confirmed timing, and paths with non-convergent 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, as shown in FIG. 2, it also includes: Figure 2

[0070] S210: obtain the provided asynchronous interface paths, paths that need to be confirmed timing, and paths with non-convergent timing;

[0071] S220: determine test cases based on the asynchronous interface paths, paths that need to be confirmed timing, and paths with non-convergent timing;

[0072] S230: perform register transfer level simulation using the test cases, to ensure that the asynchronous interface paths, paths that need to be confirmed timing, and paths with non-convergent timing are covered;

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

[0074] ​In a specific implementation, in S210, the asynchronous interface paths, paths requiring timing confirmation, and paths with non-converged timing are obtained from the chip design department.

[0075] The asynchronous interface paths refer to paths in integrated circuit design through which different modules or subsystems communicate via non-synchronous signals. The asynchronous interface paths may include but are not limited to:

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

[0077] The propagation path of an asynchronous reset signal;

[0078] The processing path of an asynchronous interrupt request;

[0079] The clockless external interface communication path;

[0080] In post-simulation, these asynchronous interface paths may cause timing violations, therefore, the designers will consider these paths in the RTL simulation stage and ensure that the test cases cover these important asynchronous communication scenarios, so as to find and solve problems as early as possible.

[0081] The paths requiring timing confirmation refer to signal paths in integrated circuit design that are crucial to chip performance, and 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] The paths with non-converged timing refer to signal paths in chip design that have not met the predetermined timing constraint requirements after multiple iterations of optimization. The problems of these paths may have a negative impact on the functions and performance of the entire chip.

[0083] In S220 and S230, appropriate test cases are selected in the RTL simulation stage, and simulation is performed to ensure that all asynchronous interface paths, paths requiring timing confirmation, and paths with non-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 consider the needs of functional verification and timing verification, and be adjusted according to actual situations. Through multi-angle and multi-level test cases, the correctness and reliability of the design can be verified more comprehensively.

[0084] After S210-S230 are executed, test cases covering all asynchronous interface paths, paths requiring timing confirmation, and paths with non-converged timing are obtained, which are used in the post-simulation process, i.e., in the execution of S120, the test cases obtained in S210-S230 are loaded, and then compiled and simulated according to the gate-level netlist and standard delay format file.

[0085] Specifically, the compilation in S120 can be performed using EDA tools to configure the simulation environment, load the PR netlist and the corresponding SDF file, and run the simulation. During the simulation, the software calculates the actual signal propagation time based on the delay information in the PR netlist and the SDF file, to determine whether there is a timing violation (TV) situation. If there is a timing violation, a simulation report containing the 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. In this stage, the circuit model after layout and routing is used for simulation, and the actual PR netlist and SDF file are used for simulation. Gate-level simulation is usually performed after register transfer level (RTL) simulation, and the purpose is to verify whether the behavior of the circuit at the physical implementation level meets the expectations. Gate-level simulation can more accurately reflect the behavior of the actual chip.

[0087] In S130, the timing violation information is extracted using automated scripts (such as ModelSim, VCS, etc.). The timing violation information can include timing violation signal paths, violation quantities, violation types (setup, hold, recovery, removal), etc. Then, according to the level of the timing violation information, the timing violation information is stored in different files. Here, "level" refers to the logical level or module level of the timing path. Specifically, the level can refer to different subsystems, modules, or hierarchical structures in the design. For example, in a complex SoC design, there can be multiple subsystems such as CPU, memory controller, DMA controller, etc., and each subsystem can contain multiple levels of modules. Such storage can help more efficiently manage timing information when dealing with large integrated circuit designs. Based on this, in some embodiments, after extracting the timing violation information from the simulation report, the method further includes:

[0088] Saving the timing violation information in different files according to different levels.

[0089] The following is an example of storing timing violation information in different files according to different levels:

[0090] 1. Suppose a complex microprocessor chip is designed, which contains the following main modules:

[0091] Cache controller (cache_controller)

[0092] Arithmetic logic unit (ALU)

[0093] branch predictor

[0094] memory interface

[0095] 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: 2 timing violations

[0098] alu: 5 timing violations

[0099] branch_predictor: 3 timing violations

[0100] memory_interface: 1 timing violation

[0101] clock_generator: 2 timing violations

[0102] 3. The timing violation information is stored in different files according to the hierarchy. Five different files are created for the five different modules: cache_controller / tv_report.txt, alu / tv_report.txt, branch_predictor / tv_report.txt, memory_interface / tv_report.txt, and clock_generator / tv_report.txt. A folder is created to organize these files, for example, named 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 the 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

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

[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.0 ns)

[0117] 13-Description: Tag match hold violation

[0118] Through this hierarchical storage method, timing violation information in each module can be clearly organized and managed. When a designer needs to view the timing violation of a specific module, the corresponding folder can be directly opened to view the relevant files, which greatly simplifies the process of searching and analyzing. At the same time, this classified storage method is also helpful for automatic tools to process this information, such as subsequent automatic generation of prohibited timing check files and filtering files, etc.

[0119] In S140, after the timing violation information is extracted, the timing violation information needs to be analyzed. The file where the timing violation information is located can be sent to the designer, who analyzes each timing violation by reading the file information to determine the cause (whether it is caused by routing delay or logic design problem) and propose a solution. Or the expert system running on the computer, or based on big data (AI) analysis / audit. Then, the timing violation information that does not need to be checked again is determined and recorded to the file, so as not to show the recorded timing violation information in the re-simulation process. Based on this, in some embodiments, the analysis of the extracted timing violation information determines the timing violation information that does not need to be checked again and records it to the file, so as not to show the recorded timing violation information in the re-simulation process, comprising:

[0120] analyzing the extracted timing violation information, determining the timing violation information that does not need to be checked again in the compilation, and recording it to the not timing check file, wherein the not timing check file is used in the process of re-compiling simulation, and the recorded timing violation information is not recorded in the simulation report.

[0121] Specifically, in S140, after the extracted timing violation information is analyzed, a "PR netlist simulation TV analysis result" document can be generated first. The document 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 not, the violation path of the timing violation, the specific location where the timing violation occurs, etc. The document can be analyzed and filled in by the designer. Based on the above-mentioned timing violation information classified according to different levels, the "PR netlist simulation TV analysis result" document can also be filled in according to different levels.

[0122] Then, in order to avoid repeated analysis of the same timing violation information in subsequent iterations and record it in the simulation report, the present application processes this "PR netlist simulation TV analysis result" document through an automatic script, and then extracts the timing violation information that does not need to be checked again from the "PR netlist simulation TV analysis result" document. These timing violation information that does not need to be checked again can also be recorded to the not timing check file (hereinafter referred to as notimingcheck.lst) according to different levels. In the next simulation, the compilation process will read notimingcheck.lst, and the recorded timing violation information will not be reported. The above process can be that the designer sends the "PR netlist simulation TV analysis result" document to the verification personnel, who performs the corresponding processing.

[0123] Taking the example in S130, after the timing analysis of the design, the following timing violation information is found to be considered not to be further checked:

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

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

[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 the external memory delay 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 need further checking

[0132] 4# 5

[0134] 6#Cache Controller

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

[0136] 8cache_controller / data_path / rd_data_to_cpu 9

[0138] 10#ALU

[0139] 11#There is a hold time violation in the carry propagate path of the adder unit, but it does not affect the overall performance

[0140] 12alu / adder_unit / carry_propagate 13

[0142] 14#Memory Interface

[0143] 15#The path of reading data from external memory is affected by external delay

[0144] 16 memory_interface / read_data_from_memory

[0145] In this file, each entry specifies a particular signal path, and timing violations on this path are considered known problems and are not further checked.

[0146] As can be seen from the above examples, the notimingcheck.lst file can only need to record the signal paths of the timing violation information, and the violation amount, violation type (setup, hold, recovery, removal), etc. included in the timing violation information can not be recorded.

[0147] In some embodiments, further comprising:

[0148] analyzing the extracted timing violation information, determining timing violation information that does not need to be extracted from the simulation report, and generating a corresponding filtering pattern and recording it in a filtering file, wherein the filtering file is used in the process of extracting timing violation information again, and the corresponding timing violation information is filtered out according to the filtering pattern recorded therein.

[0149] In some embodiments, the determination of timing violation information that does not need to be extracted from the simulation report and the generation of a corresponding filtering pattern and recording it in a filtering file comprise:

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

[0151] generating a filtering pattern according to the timing violation information determined to be reasonable and recording the filtering pattern in a filtering file.

[0152] Specifically, in S140, in order to avoid repeating the analysis and extraction of the same timing violation information from the simulation report in subsequent iterations, after the timing violation information is extracted from the "PR netlist simulation TV analysis result" document, the timing violation information can be analyzed to determine reasonable timing violation information, and a filtering pattern can also be generated for the reasonable timing violation information. Then, the filtering patterns are classified according to different levels and recorded in a filtering file (hereinafter referred to as a waive_pattern file). In the next simulation, the compilation process reads the waive_pattern and extracts timing violation information again, and according to the filtering pattern recorded therein, the corresponding timing violation information is filtered out, and these 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 result" document to the verification personnel, and the verification personnel performs the corresponding processing.

[0153] Specifically, the patterns in the waive_pattern file are rules or criteria to filter out timing violations. Using patterns, one can define more flexibly when a timing violation should be ignored. These patterns can be partial string matching based on (timing violation signal) path, based on timing check type (such as setup, hold), or based on other conditions (such as clock edge, data condition, etc.) combined rules.

[0154] 1. Path-based patterns are to specify 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 violations that occur on cpu / data_path can be ignored.

[0156] 2. Timing check type-based patterns are to specify certain types of timing checks can be ignored.

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

[0158] 3. Condition-based patterns are to specify timing violations that can be ignored under certain conditions.

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

[0160] Take the example in S130 as an example, after timing analysis of the design, the following timing violation information is considered to be unnecessary to further check:

[0161] In the cache_controller module, there is a setup time violation in the data_path / rd_data_to_cpu path, but it is confirmed through analysis that it 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 the 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 the external memory delay 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 file defines patterns for filtering timing violations

[0169] 4# 5

[0171] 6#Cache Controller

[0172] 7#The path of data read from cache to CPU is non-critical

[0173] 8cache_controller / data_path / * 9

[0175] 10#ALU

[0176] 11#There is a hold time violation in the carry propagate path in the adder unit, but it does not affect overall performance

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

[0179] 14#Memory Interface

[0180] 15#The path of reading data from external memory is affected by external delay

[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. One is that when filtering test cases, only the timing violation information reported by the specified test case simulation is filtered, and the timing violation information reported by the un-specified test case simulation cannot be filtered. The other is that when filtering all test cases, all test cases filter out the corresponding timing violation information.

[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 timing violation information that does not need to be reviewed again, and does not display the recorded timing violation information during the re-simulation process. Through a series of methods, such as automatic extraction of timing violation information, automatic filtering of interference information, analysis of information filtering, analysis of results processing, and the like, the workload of manual confirmation is reduced, the workload of iterative regression repeated confirmation within a single project is reduced, timing violation information that does not need to be reviewed again is recorded to a file, the analysis results can be reused between multiple projects, the workload of repeated confirmation of multiple projects is reduced, the efficiency of post-simulation is improved, the post-simulation time is saved, and the chip tape-out time is shortened.

[0186] A second embodiment of the device for post-simulation of a chip of the present application

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

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

[0189] S320: Compile and simulate according to the gate-level netlist, standard delay format file, and 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 these timing violation information is not recorded in the simulation report during the compilation process;

[0190] S330: Extract timing violation information from the simulation report according to the filtering file; wherein the filtering file records the filtering mode of the timing violation, so as to filter out the corresponding timing violation information according to the filtering mode when extracting the timing violation information;

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

[0192] Specifically, in the re-simulation, the re-compiled simulation report does not include the information of the timing violation that does not need to be checked recorded in the forbidden timing check file obtained by the last post-simulation, so that the noise in the timing analysis report can be reduced, and the engineers can focus more on the problems that really need to be solved. At the same time, in the extraction of the timing violation information, the timing violation information mentioned in the filter file is excluded according to the filter mode in the filter file, so that the noise in the timing analysis report can be reduced, and the engineers can focus more on the problems that really need to be solved.

[0193] Specifically, the filter file is divided into two types. One is that when the test case is specified for filtering, only the timing violation information of the simulation report of the specified test case is filtered, and the timing violation information of the simulation report of the un-specified test case cannot be filtered. The other is that when all test cases are filtered, all test cases are filtered out of the corresponding timing violation information.

[0194]

Chip post-simulation method first specific embodiment

[0195] The present application describes the whole process from selecting appropriate test cases in the design stage, to timing violation extraction in the back-end simulation stage, to analysis and automatic processing by the design personnel, and finally to document review and delivery. This series of steps can significantly improve the efficiency of the post-simulation process, reduce repetitive work, and help speed up the chip development cycle. As shown in Figure 4 , including:

[0196] (1) The design direction verification team provides asynchronous interface paths, paths that need to be confirmed timing, and paths that timing does not converge.

[0197] (2) The verification party selects appropriate test cases for register transfer level (RTL) simulation based on the above asynchronous interface paths, paths that need to be confirmed timing, and paths that timing does not converge information, to ensure that these paths are covered.

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

[0199] (4) The verification party will load the above test cases and use the PR netlist and SDF file for compilation simulation to obtain a simulation report. If there is timing violation information (violation), the simulation report contains timing violation information.

[0200] Then, the timing violation information is extracted from the simulation report using an automated script, if extracted, the timing violation information is saved according to the hierarchy and sent to the design side. If not extracted, it is determined whether the test cases are all simulated, if not, the simulation is continued to extract the timing violation information and determine whether there is a violation, if all the simulation is completed and there is no violation, it is ended.

[0201] During this phase, the backend side determines whether to obtain a new PR netlist or SDF at any time, if a new one is obtained, it is provided to the verification side for compilation simulation, if not, the automatic extraction of timing violation is continued.

[0202] (5) The design side receives the simulation report and analyzes the timing violation information (violation) therein, and fills in the "PR netlist simulation TV analysis result" document according to the analysis result, and sends it to the verification team for verification.

[0203] (6) The verification side uses an automated script to generate notimingcheck.lst and waive_pattern files according to the "PR netlist simulation TV analysis result" document. In the next round of simulation, notimingcheck.lst and waive_pattern files are used to filter out known and verified reasonable timing violation information.

[0204] Finally, the verification team and the design team need to review the "PR netlist simulation TV analysis result" document, notimingcheck.lst and waive_pattern files. The documents and files that pass the review are used as the delivery of the chip post-simulation, and can be used as the input of the subsequent project post-simulation stage. These files help the team of the subsequent project to quickly understand the potential problem points, and avoid repeated work.

[0205]

First embodiment of the chip post-simulation device of the present application

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

[0207] Among them, the acquisition module is used to acquire the gate level netlist and the standard delay format file of the designed chip.

[0208] a compiling simulation module, configured to perform compiling simulation according to the gate-level netlist and the standard delay format file, and generate a simulation report containing timing violation information;

[0209] an extracting module, configured to extract timing violation information from the simulation report;

[0210] a file generating module, configured to analyze the extracted timing violation information, determine timing violation information that does not need to be reviewed again, and record the timing violation information to a file, so as to not display the recorded timing violation information in a subsequent simulation process.

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

[0212] A second embodiment of the device for post-simulation of a chip is provided.

[0213] As shown in Figure 6 , the device for post-simulation of a chip can be used to implement the method for post-simulation of a chip in the above embodiments, as shown in Figure 6 , the device for post-simulation of a chip has an obtaining module 610, a compiling simulation module 620, an extracting module 630, and a result generating module 640.

[0214] The obtaining module is configured to obtain a gate-level netlist and a standard delay format file of a designed chip.

[0215] The compiling simulation module is configured to perform compiling simulation according to the gate-level netlist and the standard delay format file, and generate a simulation report containing timing violation information; wherein the forbidden timing check file records information of timing violations that do not need to be checked, so that these timing violation information is not recorded in the simulation report in the compiling process.

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

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

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

[0219] An embodiment of a computing device is provided.

[0220] Figure 7is a structural schematic diagram of a computing device 900 provided by an embodiment of the present application. The computing device can be used as a post-chip simulation device to perform each optional embodiment of the post-chip simulation method described above. The computing device can be a terminal or a chip or chip system inside the terminal. As shown in Figure 7 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 can be used for communication with other devices, and can specifically include one or more transceiver circuits or interface circuits.

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

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

[0224] It should be appreciated that the processor 910 can be a central processing unit (CPU) in the embodiments of the present application. The processor can 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 components, discrete hardware components, etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor. Alternatively, the processor 910 can be one or more integrated circuits for performing related programs to implement the technical solutions provided by the embodiments of the present application.

[0225] The memory 920 can include read-only memory and random access memory, and provide instructions and data to the processor 910. Part of the processor 910 can also include non-volatile random access memory. For example, the processor 910 can also store device type information.

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

[0227] It should be appreciated that the computing device 900 according to the embodiments of the present application can correspond to the execution of the corresponding subject in the method according to the embodiments of the present application, and the above and other operations and / or functions of each module in the computing device 900 are respectively for implementing the corresponding process of each method of the embodiments, and for brevity, will not be repeated here.

[0228] Those of ordinary skill in the art can realize that the units and algorithm steps of the examples described in combination with the embodiments disclosed herein can be realized in electronic hardware or a combination of computer software and electronic hardware. Whether the functions are performed in hardware or software depends on the specific application and design constraints of the technical solutions. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0229] Those skilled in the art can clearly understand that, for the convenience and brevity of the description, the specific working processes of the above-described system, device and unit can refer to the corresponding processes in the foregoing method embodiments, which will not be repeated here.

[0230] In several embodiments provided in the present application, it should be understood that the disclosed system, device and method can be implemented in other manners. For example, the described device embodiments are merely schematic. The division of the units is merely a logical function division. There can be another division manner for the actual implementation, for example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections can be indirect couplings or communication connections through some interfaces, devices or units, and can be in electrical, mechanical or other forms.

[0231] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, i.e., can be located in one place, or can be distributed on multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the embodiment.

[0232] In addition, each functional unit in the various embodiments of the present application can be integrated into a processing unit, or each unit can exist physically, or two or more units can be integrated into one unit.

[0233] If the functions are realized in the form of software function units and sold or used as independent products, they can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application or the essential part or part of the technical solutions that make contributions to the prior art can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various program codes that can be stored in the medium.

[0234] The embodiments of the present application also provide a computer readable storage medium, which stores a computer program. The program is executed by a processor to perform the above method. The method includes at least one of the schemes described in the various embodiments.

[0235] The computer storage medium of the embodiments of the present application can adopt any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium may, for example, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or apparatus, or any combination thereof. More specific examples (non-exhaustive list) of the computer-readable storage medium include an electrical connection having one or more wires, a portable computer diskette, 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 disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this document, the computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus or device.

[0236] The computer-readable signal medium can include a data signal propagated in baseband or propagated as a carrier wave, in which computer-readable program code is embodied. Such propagated data signals can take a wide variety of forms, including but not limited to electro-magnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium that is not a storage medium, that is, that is not a tangible medium, and that can communicate, propagate or transport programming for use by or in connection with an instruction execution system, apparatus or device.

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

[0238] Computer program code for carrying out operations of the present application can be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, 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 the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, application specific circuitry, or field programmable gate array (FPGA) circuitry can execute the computer program code.

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

[0240] In the above description, the reference signs indicating the steps, such as S110, S120, etc., do not necessarily mean that the steps are executed in the order, and the order of the steps can be interchanged, or the steps can be executed simultaneously, if permitted.

[0241] The term "comprising" used in the description and claims should not be interpreted as limiting to the listed steps; it does not exclude other elements or steps. It means that the specifying mentioned features, integers, steps or components are present, but do not preclude the presence or addition of one or more other features, integers, steps or components thereof. Thus, the expression "a device comprising means A and B" should not be limited to a device only consisting of means A and B.

[0242] The phrase "one embodiment" or "an embodiment" appearing in the present specification means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the application. The appearances of the phrase "in one embodiment" or "in an embodiment" in various places in the specification are not necessarily all referring to the same embodiment, but can refer to different embodiments. Furthermore, the particular features, structures, or characteristics can be combined in any suitable manner in one or more embodiments.

[0243] Note that the above only describes the preferred embodiments of the present application and the principles of the technology applied. 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, reconfigurations and substitutions can be made without departing from the scope of the present application. Therefore, although the present application has been described in detail through the above embodiments, the present application is not limited to the above embodiments, and can include more other equivalent embodiments without departing from the concept of the present application, and all fall within the scope of the present application.

Claims

1. A method for post-simulation of a chip, characterized in that, include: Obtain the provided asynchronous interface path, the path whose timing needs to be confirmed, and the path whose timing has not converged; Test cases are determined based on the asynchronous interface path, the path whose timing needs to be confirmed, and the path whose timing has not converged. Use the test cases to perform register transfer level simulation to ensure that the asynchronous interface path, the path that requires timing confirmation, and the path that has not converged are covered. Obtain the gate-level netlist and standard delay format file of the designed chip; The compilation and simulation based on the gate-level netlist and standard delay format file includes: loading the test cases, compiling and simulating based on the gate-level netlist and standard delay format file, and generating a simulation report containing timing violation information. Extract timing violation information from the simulation report; Analyze the extracted timing violation information, identify those that do not need to be reviewed again, and record them in a file so that the recorded timing violation information is not displayed in subsequent simulations.

2. The method as described in claim 1, characterized in that, After extracting timing violation information from the simulation report, the method further includes: The timing violation information is categorized and stored in different files according to its level.

3. The method as described in claim 1 or 2, characterized in that, The timing violation information extracted by the analysis is used to identify timing violations that do not need to be reviewed again and record them in a file so that the recorded timing violations are not displayed in subsequent simulations. This includes: Analyze the extracted timing violation information, determine the timing violations that do not need to be checked again during compilation, and record them in a timing violation prohibition file. The timing violation information recorded in the timing violation prohibition file is not recorded in the simulation report during the recompiling and simulation process.

4. The method as described in claim 1 or 2, 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 corresponding filtering patterns and record them in a filtering file. The filtering file is used to filter out the corresponding timing violation information according to the recorded filtering patterns during the process of extracting timing violation information again.

5. The method as described in claim 4, characterized in that, The step of determining the timing violation information that does not need to be extracted from the simulation report and generating corresponding filtering patterns and recording them in the filtering file includes: The timing violation information extracted from the simulation report is determined to be reasonable. A filtering pattern is generated based on the identified reasonable timing violation information, and the filtering pattern is recorded in the filtering file.

6. A method for post-simulation of a chip, characterized in that, include: Obtain the gate-level netlist and standard delay format file of the designed chip; Compilation and simulation are performed based on the gate-level netlist, standard delay format file, and timing check prohibition file, and a simulation report containing timing violation information is generated; 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 compilation process; wherein, the timing check prohibition file is generated using the chip post-simulation method described in claim 3; Timing violation information is extracted from the simulation report according to the filter file; wherein, the filter file records the filtering mode of timing violations, so as to filter out the corresponding timing violation information according to the filtering mode when extracting timing violation information; The results of post-chip simulation are generated based on the extracted timing violation information.

7. A device for post-chip emulation, characterized in that, include: The acquisition module is used to acquire the gate-level netlist and standard delay format file of the designed chip; The compilation and simulation module is used to perform compilation and simulation based on the gate-level netlist and standard delay format file, including: loading test cases, performing compilation and simulation based on the gate-level netlist and standard delay format file, and generating a simulation report containing timing violation information; wherein, the test cases are determined by: obtaining the provided asynchronous interface path, the path requiring timing confirmation, and the path of non-converged timing; determining test cases based on the asynchronous interface path, the path requiring timing confirmation, and the path of non-converged timing; and using the test cases to perform register transfer level simulation to ensure that the asynchronous interface path, the path requiring timing confirmation, and the path of non-converged timing are covered; The extraction module is used to extract timing violation information from the simulation report; The file generation module is used to analyze the extracted timing violation information, identify timing violations that do not need to be viewed again, and record them in a file so that the recorded timing violation information is not displayed in subsequent simulations.

8. A device for post-chip emulation, characterized in that, include: The acquisition module is used to acquire the gate-level netlist and standard delay format file of the designed chip; The compilation simulation module is used to perform compilation simulation based on the gate-level netlist, standard delay format file, and timing check prohibition file, and generate 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 compilation process; wherein, the timing check prohibition file is generated using the chip post-simulation method described in claim 3; An extraction module is used to extract timing violation information from the simulation report based on a filter file; wherein the filter file records a filtering mode for timing violations, so as to filter out the corresponding timing violation information according to the filtering mode when extracting timing violation information; The result generation module is used to generate the results of post-chip simulation based on the extracted timing violation information.

9. A computing device, characterized in that, include: processor, and A memory having stored program instructions that, when executed by the processor, cause the processor to perform the method according to any one of claims 1 to 6.

Images