A method and system for checking timing paths based on logical depth splitting

Abstract

The application discloses a method and system for checking a timing path based on logical depth splitting, and the method comprises the following steps: acquiring a logical depth of a timing path; splitting the logical depth to obtain a buffer and inverter level and a register transfer level (RTL) level; and locating a timing problem source based on the logical depth, the buffer and inverter level and the RTL level. The timing path checking method and system provided by the application can locate the timing problem source accurately by splitting the logical depth into the buffer and inverter level and the RTL level, thereby improving timing convergence efficiency and reducing chip design complexity.

Description

Technical Field

[0001] This invention relates to the field of digital integrated circuit design technology, and in particular to a method and system for checking timing paths based on logic depth decomposition. Background Technology

[0002] In digital integrated circuit design, timing path optimization is a core task to ensure chip performance, power consumption, and reliability. As integrated circuit scale increases and process nodes improve, timing convergence issues become increasingly prominent: the number of buffer and inverter layers inserted during the physical implementation stage introduces additional latency, while the structural characteristics of RTL (Register Transfer Level) code (such as combinational logic complexity and register distribution) directly affect the latency distribution of the timing path. If the distribution of the physical implementation layer (Buf / InvLevel) and register transfer level (RTLLevel) is unreasonable, timing violations may be difficult to converge, thus affecting the chip's frequency performance and functional correctness.

[0003] In current technologies, engineers typically rely on experience or static timing analysis tools to locate timing problems, but lack a systematic approach to break down the hierarchical origins of timing paths (e.g., failing to clearly distinguish root causes such as "too many logic units," "too far physical distances," or "complex combinational logic"). This leads to vague optimization directions, requiring repeated attempts to adjust floorplans, insert buffers, or modify RTL code, resulting in inefficiency and a tendency to introduce redundant designs. Summary of the Invention

[0004] In view of the above-mentioned shortcomings in the current digital integrated circuit design technology field, this invention can achieve the effect of accurately locating the source of timing problems by quantizing logic depth, buffer / inverter level and RTL level.

[0005] To achieve the above objectives, the embodiments of the present invention adopt the following technical solutions:

[0006] A method for checking timing paths based on logical depth decomposition includes the following steps:

[0007] Obtain the logical depth of the timing path;

[0008] By breaking down the logic depth, we obtain the buffer and inverter levels and the register transfer level (RTL) level.

[0009] Based on the aforementioned logic depth, buffer and inverter levels, and register transfer level (RTL) level, the source of timing problems can be located.

[0010] According to one aspect of the present application, the logic depth of the timing path is obtained, specifically including: calling a timing report function of a design tool, and extracting a "cell connection arc number" attribute value of the specified timing path, which represents the number of all logic cells passed from the start point to the end point.

[0011] According to one aspect of the present application, before the timing report function of the design tool is called, it further includes: performing static timing analysis on the design to generate a report containing all timing paths.

[0012] According to one aspect of the present application, the splitting and obtaining of the buffer and inverter level and the register transfer level (RTL) level corresponding to the logic depth specifically includes:

[0013] Traversing all pins on the timing path, judging whether the cell connected by each pin is a buffer or an inverter, counting the number of cells meeting the condition and dividing by 2 to obtain the buffer and inverter level;

[0014] The register transfer level (RTL) level is the difference between the logic depth and the buffer and inverter level.

[0015] According to one aspect of the present application, the judgment of whether the cell connected by each pin is a buffer or an inverter specifically includes:

[0016] Filtering out the cells meeting "is_buffer==true or is_inverter==true" through a cell attribute query function of the design tool.

[0017] According to one aspect of the present application, the positioning of the timing problem source based on the logic depth, the buffer and inverter level, and the RTL level specifically includes:

[0018] If the logic depth exceeds a first preset threshold, it is determined that the timing problem is caused by too many logic cells;

[0019] If the buffer and inverter level exceeds a second preset threshold, it is determined that the timing problem is caused by buffer insertion due to too long physical distance or too large fan-out;

[0020] If the RTL level exceeds a third preset threshold, it is determined that the timing problem is caused by high complexity of combinational logic.

[0021] According to one aspect of the present application, if the RTL level exceeds the third preset threshold, it is determined that the timing problem is caused by high complexity of combinational logic, further including: if the RTL level exceeds the preset threshold and no high threshold voltage (HVT) cell or weak drive cell is used in the path, it is determined that the timing problem is caused by complex combinational logic network, which needs to be fed back to the RTL designer for optimization.

[0022] According to one aspect of the present application, after the positioning timing problem source, further comprising: generating optimization suggestion report according to the positioning result, the optimization suggestion report includes the suggestion of adjusting Floorplan, adding physical constraints or modifying RTL code.

[0023] According to one aspect of the present application, the adjustment Floorplan includes adding area constraints for the registers on the timing path in the physical implementation tool, placing the registers close to their associated storage units to shorten the physical distance and reduce the buffer insertion requirement.

[0024] A system for checking timing path based on logical depth splitting, comprising:

[0025] An acquisition module acquires the logical depth of the timing path;

[0026] A splitting module splits the logical depth to obtain the buffer and inverter level and the register transfer level RTL level;

[0027] A positioning module positions the timing problem source based on the logical depth, the buffer and inverter level and the register transfer level RTL level.

[0028] The advantages of the present application are as follows:

[0029] Improving timing convergence speed

[0030] The present application accurately locates the timing problem source through the logical depth splitting method, distinguishes the root causes such as logic unit redundancy, physical layout or combined logic complexity, avoids the traditional repeated trial and error depending on experience, significantly speeds up the timing convergence process, and shortens the chip design cycle.

[0031] Optimizing design efficiency

[0032] The present application systematically splits the timing path level, optimizes (such as adjusting Floorplan or modifying RTL) after identifying the root cause, reduces redundant design iteration, improves overall design efficiency, and reduces development cost.

[0033] Reducing power consumption and area

[0034] The present application reduces the physical implementation redundancy caused by excessive insertion of Buffer / Inverter, optimizes the logical level distribution, thereby reducing the chip power consumption and area, and improving the power efficiency and integration.

[0035] Enhancing maintainability

[0036] The application provides a standardized timing analysis process and quantitative indicators (such as logic depth, Buf / Inv level threshold) to facilitate the design team to quickly reproduce problems, verify optimization effects, and enhance design maintainability and team collaboration efficiency.

[0037] Improve chip reliability

[0038] The application avoids chip function errors caused by timing violations in the later stage by early and accurate identification of timing problems of the critical path (such as high complexity of combinational logic), thereby significantly improving the reliability and stability of the chip.

[0039] Support complex design scenarios

[0040] The application is suitable for high-complexity digital integrated circuit design such as multi-core processors and high-speed interfaces, and can effectively handle large-scale timing path analysis requirements to meet chip design requirements under advanced process nodes. BRIEF DESCRIPTION OF DRAWINGS

[0041] In order to more clearly illustrate the technical solutions in the embodiments of the application, the drawings needed in the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the application, and other drawings can be obtained by those skilled in the art without creative labor on the basis of these drawings.

[0042] Figure 1 The timing path described in the application is a schematic diagram.

[0043] Figure 2 The report graph of get_logic_level_on_path described in the application is a report graph.

[0044] Figure 3 The logic diagram of adjusting Floorplan described in the application is a logic diagram.

[0045] Figure 4 The schematic diagram of addregisters described in the application is a schematic diagram.

[0046] Figure 5 The report graph of get_buf_inv_level_on_path described in the application is a report graph.

[0047] Figure 6 The flowchart of a timing path checking method based on logic depth splitting described in the application is a flowchart. DETAILED DESCRIPTION

[0048] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0049] Example 1

[0050] like Figures 1 to 6 As shown, we can first use the following script to easily obtain the logic depth (the number of all cells traversed from the start point to the endpoint) on a specified timing path. This logic depth value directly reflects the number of logic units on the timing path and is an important indicator for evaluating whether the timing of a timing path is easy to meet. In the physical implementation of digital integrated circuits, a larger logic depth value usually means that there are more logic units traversed on the path, leading to an increase in accumulated cell delay and making timing convergence more difficult. If the logic depth on a path is very deep, its timing is generally not easy to meet (it has a large number of cells, and the cell delay will be large), which often becomes a key bottleneck for timing optimization. In fact, we can also split it into two parts (buflevel and rtllevel) to help us better locate whether it is caused by the complexity of the combinational logic itself or the large physical distance requiring the insertion of more buf / inv. This splitting method provides us with a more refined perspective for diagnosing timing problems.

[0051] #getlogiclevelonthespecifiedtimingpath

[0052] procget_logic_level_on_path{timing_path}{

[0053] setlogic_depth[get_property$timing_pathnum_cell_arcs]

[0054] return $logic_depth

[0055] }

[0056] define_proc_argumentsget_logic_level_on_path-info "Getlogiclevelonthespecifiedtimingpath"

[0057] This proc is mainly obtained by the num_cell_arcs attribute of gettimingpath, but this proc can facilitate the script to directly obtain the value of its logicdepth, without calling get_property again, which will be more convenient. For example, we can grab those paths that violate in the place stage, and pick out those with logiclevel greater than 40 from them. They are generally timing-critical, that is, more difficult to fix, and are paths that need to be focused on and analyzed. According to the path shown in Figure 1 The path can be verified. This automated method significantly improves the efficiency of timing analysis and reduces the workload of manual inspection.

[0058] The method and examples are as follows:

[0059] setpath[report_timing-fromu_top / u_core / u_pred_inter_mopee / u_pred_mopee_rdcost / PAD_LOGIC_FRAME_COPY_0__PAD_LOGIC_PIPELINE_COPY_2__u_pad_left_avail / Q_reg_0_ / Q-collection]

[0060] get_logic_level_on_path$path 37

[0062] Or directly:

[0063] get_logic_level_on_path[report_timing-fromu_top / u_core / u_pred_inter_mopee / u_pred_mopee_rdcost / PAD_LOGIC_FRAME_COPY_0__PAD_LOGIC_PIPELINE_COPY_2__u_pad_left_avail / Q_reg_0_ / Q-collection] 37

[0065] The above is the Proc of reporting the logic depth on the timing path, and it is mentioned that we can actually divide it into two parts, buflevel and rtllevel. This splitting method provides us with the ability to analyze timing problems from different angles, enabling us to more targetedly solve timing violation problems.

[0066] Now start reporting the buf / inv level and rtl level on the timing path.

[0067] Buf level means the number of buffers and inverters on a path. If there is a timing violation on a path and the buf / inv number on the path is large, it should be due to the long physical distance, the tool added a lot of buf / inv to do buffering, or there is a multifanout case, the tool added buf / inv tree to split fanout. This judgment is very important for us to understand the physical nature of timing problems. If it is the former, we can also go further to confirm by getting the distance of the start point and endpoint of the path. At this time, we generally need to adjust the floorplan (put the modules / Ram with talk close together, such as RAMA and RAMB, RAMC and RAMD as shown below Figure 3 ) or add a physical constraint to shorten the distance to help optimize timing (such as registers-1 to registers-2 in the following Figure 4 , if there is some margin between registers-1 and registers-2, we can appropriately add some regions to registers-1 to put it closer to RAMA). This optimization method based on physical distance analysis can effectively reduce unnecessary buffer insertion, thereby reducing power consumption and area.

[0068] The following is the proc to report buf / inv level:

[0069] #get buf / inv number on the specified timing path

[0070] proc get_buf_inv_level_on_path { timing_path}

[0071] set buf_inv_cnt 0

[0072] foreach_in_collection pin [get_property [get_property $timing_path timing_points] pin]

[0073] if{[get_property $pin object_type]=="pin" && [sizeof_collection [filter_collection [get_cells-of_object $pin] "is_buffer==true || is_inverter==true"]]}{

[0074] puts "here is one buf / inv [get_object_name $pin]"

[0075] incr buf_inv_cnt

[0076] }

[0077] }

[0078] set buf_inv_depth [expr $buf_inv_cnt / 2]

[0079] return $buf_inv_depth

[0080] }

[0081] define_proc_arguments get_buf_inv_level_on_path -info "Get buf / inv number on the specified timing path"

[0082] Usage and example as follows:

[0083] get_buf_inv_level_on_path [report_timing -from u_top / u_core / u_pred_inter_mop ee / u_pred_mop ee_rdcost / PAD_LOGIC_FRAME_COPY_0__PAD_LOGIC_PIPELINE_COPY_2__u_pad_left_avail / Q_reg_0_ / Q-collection] 14

[0085] This value directly reflects the number of Buffer and Inverter on the path, providing us with a quantitative indicator of physical implementation quality, enabling us to objectively assess the physical implementation status of the current design.

[0086] RTL level is the number of logic depth excluding Buf and Inverter. It mainly refers to the number of combinational logic excluding Buf / Inv. If this number is high, the combinational logic network is complex, so the delay is difficult to be greatly optimized, and the timing is also critical. This is generally the focus of the early stage. If there is no HVT or weakly driven cell above, it means that the tool has done a good job. If there is timing violation, it needs to be checked whether there is Timing margin on the path of the previous and next level to do Early / Late skew. If the RTL level of the previous and next level is also very high, it is very difficult to do. It needs to be considered whether the margin of multi-level path can be borrowed (the back-end needs to analyze the multi-level path of the previous and next level and do some useful skew control), and this problem also needs to be fed back to the RTL designer as soon as possible to see whether it can be optimized on the RTL. Because the earlier the problem is modified, the easier it is to be accepted, the closer to the end of the project, the more difficult it is to be accepted (the impact is larger, and there may not be enough time to verify the changes). This hierarchical method enables us to distinguish whether the timing problem is caused by physical implementation or RTL design, so as to guide us to adopt the most effective optimization strategy.

[0087] #getrtllevelonthespecifiedtimingpath

[0088] procget_rtl_level_on_path{timing_path}{

[0089] setbuf_inv_cnt0

[0090] setlogic_depth[get_property$timing_pathnum_cell_arcs]

[0091] foreach_in_collectionpin[get_property[get_property$timing_pathtiming_points]pin]{

[0092] if{[get_property$pinobject_type]=="pin"&&[sizeof_collection

[0093] [filter_collection[get_cells-of_object$pin]"is_buffer==true|| is_inverter==true"]]}{

[0094] incrbuf_inv_cnt

[0095] }

[0096] }

[0097] setbuf_inv_depth[expr$buf_inv_cnt / 2]

[0098] setrtl_depth[expr$logic_depth-$buf_inv_depth]

[0099] return$rtl_depth

[0100] }

[0101] define_proc_argumentsget_rtl_level_on_path-info"Getrtllevelonthespecifiedtimingpath"

[0102] get_rtl_level_on_path[report_timing-fromu_top / u_core / u_pred_inter_mopee / u_pred_mopee_rdcost / PAD_LOGIC_FRAME_COPY_0__PAD_LOGIC_PIPELINE_COPY_2__u_pad_left_avail / Q_reg_0_ / Q-collection] 23

[0104] Usage and examples are as follows:

[0105] get_rtl_level_on_path[report_timing-fromu_top / u_core / u_pred_inter_mopee / u_pred_mopee_rdcost / PAD_LOGIC_FRAME_COPY_0__PAD_LOGIC_PIPELINE_COPY_2__u_pad_left_avail / Q_reg_0_ / Q-collection] 23

[0107] The RTL level values provide us a direct indicator of the combinational logic complexity, allowing us to evaluate the quality of the RTL design and the optimization space.

[0108] These two procs can be called very conveniently in other scripts that analyze Timingpath. This scripting approach improves the automation level of timing analysis, reduces the need for manual intervention, and makes the timing optimization process more efficient and repeatable.

[0109] Embodiment Two

[0110] First, perform global static timing analysis (STA) on the chip design, generating a detailed report containing all timing paths. This report covers all potential timing critical paths in the design, providing basic data for subsequent analysis.

[0111] After static timing analysis is complete, extract the "number of cell arcs" attribute value of the specified timing path through the timing report function of the design tool. This attribute value directly represents the number of logic cells passed from the starting point of the path (such as the output end of a register) to the end point (such as the input end of another register), i.e., the logic depth. The larger the logic depth value, the more logic cells accumulate on the path, the more significant the cumulative effect of cell delay, and the more difficult it is to meet timing.

[0112] The logic depth can be automatically obtained through a Tcl script:

[0113] proc get_logic_level_on_path {timing_path} {

[0114] set logic_depth [get_property $timing_path num_cell_arcs]

[0115] return $logic_depth

[0116] }

[0117] define_proc_arguments get_logic_level_on_path -info "Get logic levelon the specified timing path"

[0118] In actual chip design, for example, the clock domain crossing path of a processor chip, the logic depth of a certain path is extracted as 52, far exceeding the preset threshold (such as 40), indicating that the path may have serious timing convergence problems and needs to be further split and analyzed.

[0119] Logical depth split and problem location, based on the extracted logical depth value, this embodiment splits the path into buffer and inverter level (Buf / Inv Level) and register transfer level RTL level by automated script.

[0120] By traversing all the pin-connected cells on the path, filter out the buffer (Buffer) and inverter (Inverter) type cells, count their number and divide by 2 (because Buffer / Inverter usually appears in pairs), get the level value. If the value exceeds the preset threshold (such as 15), it indicates that the tool has inserted a large number of buffers to maintain signal integrity due to the physical distance being too far or the fanout being too large on the path. At this time, the physical layout needs to be optimized or the fanout distribution needs to be adjusted.

[0121] The following script can be used to achieve this:

[0122] proc get_buf_inv_level_on_path {timing_path} {

[0123] set buf_inv_cnt 0

[0124] foreach_in_collection pin [get_property [get_property $timing_path timing_points] pin] {

[0125] if {[get_property $pin object_type] == "pin" && [sizeof_collection [filter_collection [get_cells -of_object $pin] "is_buffer==true ||is_inverter==true"]]} {

[0126] incr buf_inv_cnt

[0127] }

[0128] }

[0129] set buf_inv_depth [expr $buf_inv_cnt / 2]

[0130] return $buf_inv_depth

[0131] }

[0132] define_proc_arguments get_buf_inv_level_on_path -info "Get buf / invnumber on the specified timing path"

[0133] In actual chip design, for example, the above-mentioned path with a logic depth of 52, after splitting, the Buf / Inv level is 18 (exceeding the threshold 15), indicating that the physical distance is too far or the fanout is too large, resulting in a large number of buffers inserted by the tool. At this time, the physical layout needs to be optimized, for example, by adjusting Floorplan or adding physical constraints (such as Region constraints) to shorten the signal path and reduce the need for buffer insertion.

[0134] By subtracting the buffer and inverter level from the logic depth, the RTL level value is obtained. This value represents the number of combinational logic levels on the path excluding Buffer / Inverter, reflecting the complexity of combinational logic. If this value exceeds the preset threshold (such as 23), it indicates that the combinational logic network of the path is too complex, and the signal delay is difficult to solve through physical optimization, which needs to be fed back to the RTL designer to optimize the logic design.

[0135] The following script can be used to achieve this:

[0136] proc get_rtl_level_on_path {timing_path} {

[0137] set buf_inv_cnt 0

[0138] set logic_depth [get_property $timing_path num_cell_arcs]

[0139] foreach_in_collection pin [get_property [get_property $timing_path timing_points] pin] {

[0140] if {[get_property $pin object_type] == "pin" && [sizeof_collection [filter_collection [get_cells -of_object $pin] "is_buffer==true ||is_inverter==true"]]} {

[0141] incr buf_inv_cnt

[0142] }

[0143] }

[0144] set buf_inv_depth [expr $buf_inv_cnt / 2]

[0145] set rtl_depth [expr $logic_depth - $buf_inv_depth]

[0146] return $rtl_depth

[0147] }

[0148] define_proc_arguments get_rtl_level_on_path -info "Get rtl level on the specified timing path"

[0149] In actual chip design, for example, the path with the above-mentioned logic depth of 52, the RTL level after splitting is 34 (exceeding the threshold 23), indicating that the combinational logic network is too complex. At this time, the RTL designer needs to be fed back to optimize the logic design, such as simplifying the combinational logic structure, merging redundant logic gates, or using register retiming technology to balance the logic level.

[0150] According to the level splitting result, the embodiment automatically generates an optimization suggestion report and verifies the optimization effect through actual chip design.

[0151] In this embodiment, the optimization suggestion report is generated by adjusting Floorplan, modifying RTL code, and adding physical constraints. The specific optimization suggestion content is:

[0152] Adjusting Floorplan: For the path with high Buf / Inv level, it is suggested to add area constraints for the registers on the path in the physical implementation tool, and place them close to the associated storage unit (such as RAM) to shorten the physical distance and reduce the buffer insertion demand (corresponding to Embodiment One "Adjusting Floorplan to reduce Buffer insertion"). For example, Figure 3 After the layout optimization of RAM A and RAM B shown in the figure, the Buf / Inv level of the path is reduced from 18 to 12, reducing the buffer insertion demand by 33%.

[0153] Modify RTL code: For the path with high RTL level, suggest the RTL designer to simplify the combinational logic structure (corresponding to embodiment one "feedback RTL designer to optimize combinational logic"). For example, by merging redundant logic gates, reducing multi-level nested logic, or using register retiming techniques, the RTL level is reduced from 34 to 28, reducing the delay of combinational logic by 17%.

[0154] Add physical constraints: For paths sensitive to physical distance, add physical constraints (such as Region constraints, Group constraints) to limit the unit placement area, avoid long-distance wiring to introduce additional delay (corresponding to embodiment one "add physical constraints to optimize timing"). For example, in the RAM A and registers-1 path shown in FIG. 1, after adding Region constraints, the Buf / Inv level of the path is reduced from 18 to 15, further optimizing the timing. Figure 4

[0155] Embodiment three

[0156] A system for checking timing paths based on logic depth splitting, based on the method for checking timing paths based on logic depth splitting described in embodiment one, comprising:

[0157] An acquisition module acquires the logic depth of the timing path;

[0158] A splitting module splits the logic depth to obtain the buffer and inverter level and the register transfer level RTL level;

[0159] A positioning module positions the source of the timing problem based on the logic depth, the buffer and inverter level, and the register transfer level RTL level.

[0160] The beneficial effects of the present application are that the present application realizes accurate positioning and efficient optimization of timing problems through the logic depth splitting method, significantly improves the timing convergence speed, physical implementation quality and RTL design reliability of digital integrated circuit design, while reducing design cost and cycle, and has significant engineering application value and industrialization prospect.

[0161] The algorithms and displays provided herein are not inherently related to any particular computer, virtual system, or other apparatus. Various general purpose systems can be used with these teachings, based on the description as provided herein. In addition, the present application is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages can be used to implement the teachings of the application as described herein, and any references below to specific languages are provided for disclosure of enablement only.

[0162] ​In the description provided herein, numerous specific details are set forth. However, it is understood that embodiments of the application can be practiced without these specific details. In some instances, well-known methods, structures and techniques have not been described in detail in order not to obscure the understanding of this description.

[0163] Similarly, it is to be understood that the embodiments of the present application can be readily combined with one another and / or various features from one embodiment can be combined with various features from another embodiment, as will be apparent to one of ordinary skill in the art. In this respect, the above description is intended to be illustrative, and not restrictive, of the scope of the various aspects of the present application. One skilled in the art will readily appreciate that the present application is well adapted to carry out the objects and obtain the ends and advantages mentioned, as well as those inherent therein, and that the embodiments described herein are exemplary implementations of the methods and devices of the present application. Accordingly, the disclosure is not intended to be limited to the details of the foregoing illustrative examples which are presented by way of example and illustration only.

[0164] Those skilled in the art will appreciate that the modules in the apparatuses in the embodiments can be adapted and placed in one or more apparatuses other than the embodiments. The modules or units or components in the embodiments can be combined into one module or unit or component, and further can be divided into more sub-modules or sub-units or sub-components. Any combination of all the features disclosed in the specification (including the accompanying claims, abstract and drawings), and any method or apparatus so disclosed, can be used in any combination, except that at least some of such features and / or processes or units are mutually exclusive, unless explicitly stated otherwise. Each feature disclosed in the specification (including the accompanying claims, abstract and drawings) can be replaced by alternative features serving the same, equivalent or a similar purpose, unless explicitly stated otherwise.

[0165] Furthermore, those skilled in the art will appreciate that different embodiments of the application can have different features and advantages, and no one feature or advantage is necessary to every implementation of the application. Features and advantages of the application will become apparent to those skilled in the art from the following description, which is by way of illustration, one of the objectives of the application being to provide novel methods and devices. The description is not to be regarded as limiting the scope of the application, which is defined purely by the claims.

[0166] It should be noted that the above-mentioned embodiments illustrate rather than limit the application, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word 'comprising' does not exclude the presence of elements or steps other than those listed in a claim. The word 'a' or 'an' preceding an element does not exclude the presence of a plurality of such elements. The application can be implemented by means of both hardware and software, and any combination thereof. In a unitary claim, several devices or means can be listed, comprising means performing the same function. The use of the word 'a' or 'an' does not exclude the presence of a plurality of such devices or means. The word 'first','second', 'third', and the like in the description do not necessarily have a chronological order.

[0167] The above description is only the specific implementation of the present application, but the protection scope of the present application is not limited to this. Any skilled person in the art can easily think of the changes or replacements within the technical range disclosed by the present application, which should be covered in the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A method for checking timing paths based on logical depth decomposition, characterized in that, Includes the following steps: Obtain the logical depth of the timing path; The logic depth is split to obtain the buffer and inverter level and the register transfer level (RTL) level. The specific process includes: traversing all pins on the timing path, determining whether the unit connected to each pin is a buffer or an inverter, counting the number of units that meet the conditions and dividing by 2 to obtain the buffer and inverter level. The register transfer level (RTL) level is the difference between the logic depth and the buffer and inverter level. Based on the logic depth, buffer and inverter levels, and register transfer level (RTL) level, the source of timing problems is located. The specific process includes: if the logic depth exceeds a first preset threshold, the timing problem is determined to be caused by an excessive number of logic units; if the buffer and inverter levels exceed a second preset threshold, the timing problem is determined to be caused by buffer insertion due to excessive physical distance or excessive fan-out; if the RTL level exceeds a third preset threshold, the timing problem is determined to be caused by high combinational logic complexity.

2. The method for checking timing paths based on logical depth decomposition according to claim 1, characterized in that, The process of obtaining the logical depth of the timing path specifically includes: calling the timing report function of the design tool to extract the "number of unit connection arcs" attribute value of the specified timing path, wherein the attribute value represents the number of all logical units traversed from the start point to the end point.

3. The method for checking timing paths based on logical depth decomposition according to claim 2, characterized in that, Before invoking the timing report function of the design tool, the process also includes: performing static timing analysis on the design and generating a report containing all timing paths.

4. The method for checking timing paths based on logical depth decomposition according to claim 1, characterized in that, The determination of whether each pin-connected unit is a buffer or an inverter specifically includes: Use the cell attribute query function of the design tool to filter out cells that satisfy "is_buffer==true or is_inverter==true".

5. The method for checking timing paths based on logical depth decomposition according to claim 1, characterized in that, If the RTL level exceeds the third preset threshold, the timing problem is determined to be caused by high combinational logic complexity. In addition, if the RTL level exceeds the preset threshold and no high threshold voltage unit (HVT) or weak drive unit is used in the path, the timing problem is determined to be caused by the complexity of the combinational logic network and should be given priority feedback to the RTL designer for optimization.

6. The method for checking timing paths based on logical depth decomposition according to claim 1, characterized in that, Following the source of the positioning timing problem, the method further includes: generating an optimization suggestion report based on the positioning results, which includes suggestions for adjusting the floorplan, adding physical constraints, or modifying the RTL code.

7. The method for checking timing paths based on logical depth decomposition according to claim 6, characterized in that, The adjustment of the floorplan includes adding region constraints to the registers on the timing path in the physical implementation tool, placing the registers close to their associated memory cells to shorten the physical distance and reduce buffer insertion requirements.

8. A timing path inspection system based on logical depth decomposition, characterized in that, The timing path inspection method based on logical depth splitting according to any one of claims 1 to 7 includes: The module retrieves the logical depth of the timing path; The module is split, and the logic depth is split to obtain the buffer and inverter level and the register transfer level (RTL) level. The positioning module, based on the aforementioned logic depth, buffer and inverter levels, and register transfer level (RTL) level, locates the source of timing problems.

Images