RTL data path automatic beating method and system

Abstract

The invention discloses an RTL data path automatic beating method and system, and belongs to the technical field of integrated circuit design automation. The method comprises the steps that RTL codes are analyzed through AI, a communication interface protocol is recognized, and a corresponding beating rule is determined; calling a comprehensive tool to obtain time sequence information and physical distance information of the target data path; automatically determining the number of beating stages according to the time sequence information, the physical distance information and the beating rule; according to the number of beating stages and beating rules, beating logic with keyword marks is automatically combined into the RTL codes; and calling the comprehensive tool again to verify whether the time sequence is convergent or not, and if not, performing iterative optimization until the time sequence is convergent. According to the method, automatic analysis, automatic modification and automatic verification closed loop of data path beating are realized, manual intervention is greatly reduced, time sequence iteration is accelerated, and the function error risk is reduced.

Description

Technical Field

[0001] This invention relates to the field of integrated circuit design automation technology, specifically to an automatic data path timing method and system based on artificial intelligence for RTL (Register Transfer Level) data paths, which is applicable to the automatic pipelined processing of data paths based on physical distance and timing results in large-scale high-performance chip design. Background Technology

[0002] As chip size and operating frequency continue to increase, data path routing in the RTL design of large-scale SoCs and high-performance processors often spans significant physical distances. In such designs, whether data paths require pacing and the number of pacing stages are typically closely related to the physical distance between modules, process conditions, and timing objectives.

[0003] In existing design processes, it is difficult to accurately assess the actual physical distance after future placement and routing during the RTL design phase. Engineers can usually only make preliminary estimates of the data path based on experience. Subsequently, during the synthesis and placement / routing phases, the estimates are continuously adjusted based on the actual timing results. This process often requires multiple iterations to gradually approach a reasonable pipeline number.

[0004] Existing technologies have seen some attempts at automated timing tools, such as some synthesis tools that provide automatic register retiming based on timing reports. However, these are limited to the synthesis netlist level, cannot modify the RTL source code, and struggle to handle constraints from complex interface protocols. Other EDA vendors offer physically-aware pipeline insertion capabilities, but these are typically only applicable to specific process libraries or design flows, lacking versatility and protocol awareness.

[0005] The closest existing solution relies entirely on engineers manually analyzing synthesis and timing reports, combining this with their understanding of the design and interface protocols, and manually inserting registers into the RTL code for timing checks. The effectiveness is then verified through multiple synthesis and timing analyses. This approach has significant drawbacks: First, manual timing checks require engineers to repeatedly analyze timing reports and modify code, resulting in a lengthy process and significantly extending the design cycle. Second, manually inserting timing check registers can easily introduce functional errors, especially when dealing with complex interface protocols or cross-module communication, leading to high functional verification costs. Furthermore, the manual approach struggles to establish a stable automated loop, and design iterations heavily depend on the engineer's personal experience. Summary of the Invention

[0006] The purpose of this invention is to provide an AI-assisted automatic data path timing method and system. By automatically identifying the interface protocol in the RTL code and combining the timing and distance analysis results of the comprehensive tool, the system can automatically decide on the timing level of the data path and automatically modify the code, thereby reducing manual intervention, accelerating the timing iteration speed, and reducing the risk of functional errors.

[0007] To achieve the above objectives, the present invention provides an automatic snapshot method for RTL data paths, comprising:

[0008] Artificial intelligence algorithms are used to parse the RTL code, identify the communication interface protocols present in the RTL code, and determine the corresponding data path timing rules based on the identified communication interface protocols. The design is processed by a comprehensive tool to obtain the timing and physical distance information of the target data path; Based on the timing information, the physical distance information, and the data path timing rules, the required number of timing levels is automatically determined. Based on the number of beat levels and the beat rules of the data path, the corresponding beat logic is automatically merged into the RTL code, and keyword markers for tool recognition are added to the merged beat logic. The synthesis tool is called again to synthesize the modified RTL code, generate timing analysis results, and determine whether the timing violations in the data path have been reduced to the target range. If the timing violation does not converge, repeat the steps of automatically determining the timing level, automatically merging the timing logic, and calling the synthesis tool again until the timing violation converges.

[0009] The step of determining the corresponding data path timing rules based on the identified communication interface protocol includes: Based on a predefined rule base, one or more timing rules are determined for different communication interface protocol types. The timing rules specify the way to perform timing operations under the constraints of the corresponding protocol. The rule base includes at least a protocol type field, an allowed timing position field, a timing direction field, and a timing level limit field. The communication interface protocol types include AXI, AXI-Stream, TileLink, FIFO interface, or custom point-to-point interface.

[0010] Optionally, the timing information and physical distance information of the target data path include: path delay, physical distance information, and the maximum transmission distance that can be supported in a single cycle based on the target process conditions and design timing constraints.

[0011] Optionally, the automatic determination of the required number of beat levels includes: Determine whether there is a timing violation in the target data path based on the timing information; If a timing violation exists, the required number of beat cycles is calculated by combining the timing violation information extracted from the synthesis and timing report, and is used as the beat level.

[0012] Optionally, the automatic determination of the required number of beat levels includes: Based on the maximum transmission distance supported per cycle in the physical distance information, the number of preventative grading cycles required for the target data path is estimated, and this number is used as the grading level. For example, if the estimated physical distance of a data path is 4000 μm, and the maximum transmission distance per cycle is 1300 μm, then the estimated number of grading levels required is ceil(4000 / 1300) ≈ 4 levels, where ceil represents the rounding function. The grading method based on timing violations is suitable for path optimization scenarios where timing violations already exist, while the preventative grading method based on physical distance information is suitable for scenarios where pre-optimization is performed before placement and routing. The two methods can be used in parallel, with the ultimate goal of eliminating timing violations.

[0013] Optionally, the automatic integration of corresponding timing logic into the RTL code includes: an artificial intelligence algorithm automatically inserting registers or pipeline logic of the corresponding level between the start and end points of the target data path in the RTL code according to the timing level and the data path timing rules, and the modified RTL code meets the requirements of the original communication interface protocol; the artificial intelligence algorithm determines the timing position and method based on the protocol recognition result and the rule base.

[0014] Optionally, adding keyword markers for tool recognition at the merged timing logic includes: Add predefined comment tags or attribute keywords to the automatically inserted register or pipeline code to identify the insertion position of the pacing logic, the corresponding interface protocol, and the pipeline number.

[0015] The present invention also provides an RTL data path automatic snapshot system for performing the aforementioned RTL data path automatic snapshot method, comprising: The protocol identification module is used to parse the RTL code using artificial intelligence algorithms, identify the communication interface protocols present in the RTL code, and determine the corresponding data path timing rules based on the identified communication interface protocols. The information acquisition module is used to call the integrated tools to perform integrated processing on the design and obtain the time series information and physical distance information of the target data path; The slapping decision module is used to automatically determine the required number of slapping levels based on the time sequence information, the physical distance information, and the data path slapping rules. The code modification module is used to automatically merge the corresponding pausing logic into the RTL code according to the pausing level and the data path pausing rules, and add keyword markers for the tool to recognize at the merged pausing logic. The iterative verification module is used to call the synthesis tool again to synthesize the modified RTL code to generate timing analysis results and determine whether the timing violations of the data path have been reduced to the target range. If convergence is not achieved, the timing decision module and the code modification module are triggered to perform a new round of optimization.

[0016] Optionally, the timing decision module determines whether there is a timing violation in the target data path based on the timing information. If there is a timing violation, it calculates the required number of timing cycles based on the timing violation information extracted from the comprehensive and timing reports, and uses this as the timing level.

[0017] Optionally, the timing decision module is further configured to estimate the number of timing cycles required for preventative timing of the target data path based on the maximum transmission distance that can be supported per cycle in the physical distance information, and use this as the timing level. The timing method based on timing violations is suitable for path optimization scenarios where timing violations already exist, while the preventative timing method based on physical distance information is suitable for scenarios where pre-calculation optimization is performed before layout and routing. The two methods can be used in parallel, with the ultimate goal of eliminating timing violations.

[0018] Optionally, the code modification module uses an artificial intelligence algorithm to automatically insert registers or pipeline logic of the corresponding level between the start and end points of the target data path in the RTL code according to the number of pausing levels and the data path pausing rules; the artificial intelligence algorithm identifies the protocol type through syntax tree analysis, locates the protocol boundary through keyword matching, determines the allowed pausing positions and methods through rule base query, and finally generates pausing logic that conforms to the protocol specification.

[0019] Compared with the prior art, the present invention has at least the following beneficial effects: (1) By using automatic identification and pipeline insertion strategies based on interface protocols, this invention can effectively reduce the probability of functional errors while automatically inserting pipeline stages, and has higher reliability compared to manual pipeline insertion. For example, in a certain AXI interface design, this method was used to automatically identify the protocol and insert pipeline stages, avoiding the common address-data path mismatch problem in manual pipeline insertion, and the functional verification passed on the first try.

[0020] (2) By automatically calling the integrated tools and automatically extracting the timing / distance information, the linkage between physical implementation and front-end design was realized, making the timing decision based on real back-end data, which greatly improved the accuracy and first-time success rate of the timing scheme. In the practice of a certain N7 process project, this method was used to perform preventive timing on cross-module data paths, and the accuracy of timing level prediction reached more than 90%, and the number of iterations was reduced from 5 times manually to 2 times.

[0021] (3) By introducing an automated code modification and iterative verification closed loop with keyword tags, the entire process of code optimization is automated, which significantly shortens the design iteration cycle and reduces the repetitive labor intensity of engineers. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort, wherein: Figure 1 This is a flowchart illustrating the automatic snapshot method for RTL data paths provided by the present invention. Figure 2 A simplified flowchart of the automatic snapshot method for RTL data path provided in Embodiment 1 of the present invention; Figure 3 This is a structural block diagram of the RTL data path automatic stamping system provided in Embodiment 2 of the present invention. Detailed Implementation

[0023] 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, not all, of the embodiments of the present invention. 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.

[0024] The terms "first," "second," etc., used in this specification are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class, without limiting the number of objects; for example, the first object can be one or more. Furthermore, in the specification, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0025] Please see Figure 1 As shown, the present invention provides an automatic snapshot method for RTL data paths, comprising: Step S101: Parse the RTL code using artificial intelligence algorithms, identify the communication interface protocols present in the RTL code, and determine the corresponding data path timing rules based on the identified communication interface protocols. Step S102: Call the integration tool to perform integrated processing on the design and obtain the timing information and physical distance information of the target data path; Step S103: Automatically determine the required number of time-series levels based on the time-series information, the physical distance information, and the data path time-series rules; Step S104: Based on the number of beat levels and the beat rules of the data path, automatically merge the corresponding beat logic into the RTL code, and add keyword markers for the tool to recognize at the merged beat logic. Step S105: Call the synthesis tool again to synthesize the modified RTL code, generate timing analysis results, and determine whether the timing violations of the data path have been reduced to the target range; Step S106: If the timing violation does not converge, repeat the steps of automatically determining the timing level, automatically merging the timing logic, and calling the synthesis tool again until the timing violation converges.

[0026] In step S101, determining the corresponding data path timing rules based on the identified communication interface protocol includes: Based on a predefined rule base, one or more timing rules are determined for different communication interface protocol types. The timing rules specify the way to perform timing operations under the constraints of the corresponding protocol. The rule base includes at least a protocol type field, an allowed timing position field, a timing direction field, and a timing level limit field. The communication interface protocol types include AXI, AXI-Stream, TileLink, FIFO interface, or custom point-to-point interface.

[0027] It should be further explained that the artificial intelligence algorithm is implemented based on a combination of a predefined structured rule base and static code analysis technology. First, the RTL code is parsed into an abstract syntax tree by a syntax analyzer; then, based on the protocol feature pattern library in the rule base (which includes at least a protocol type field, regular expressions for key signal names, and typical handshake signal combinations), a pattern matching algorithm is used to locate protocol boundaries and interface instances in the code; finally, based on the matching results, the protocol constraint table in the rule base is queried to determine the allowed additional steps during the stepping operation (for example, the AXI protocol only allows additional steps on data / address signals within a channel and does not allow moving registers across channels), the stepping direction (forward / reverse pipeline), and the upper limit of the number of stepping levels.

[0028] The rule base is pre-built by engineers based on the standard manuals of various communication interface protocols, using structured input or natural language processing-assisted extraction, and stored in machine-readable formats such as JSON or XML. This rule base is independent of the algorithm code and can support new protocols by updating the library files without modifying the core algorithm logic.

[0029] In step S102, the timing information and physical distance information of the target data path include: path delay, physical distance information, and the maximum transmission distance that can be supported in a single cycle based on the target process conditions and design timing constraints.

[0030] It should be noted that the "maximum transmission distance supported in a single cycle" is a crucial physical basis for subsequent timing decisions. This value is automatically obtained through one of the following methods: a) Reading configuration files: Read the empirical values ​​for this process node directly from the preset process parameter configuration file (such as .tcl or .conf file), for example, "set_max_tran_distance -tech N7 1900um"; b) Process library calculation: By calling the built-in RC parasitic parameter model of the synthesis tool and combining it with the clock frequency constraints of the design, the typical or maximum distance that the signal can be transmitted in one clock cycle is automatically estimated under the premise of meeting the timing target. c) User-defined input: If the user has more accurate backend evaluation data, they can directly specify the distance value through the script interface, overriding the tool's default settings.

[0031] In step S103, automatically determining the required number of beat levels includes: Determine whether there is a timing violation in the target data path based on the timing information; If a timing violation exists, the required number of beat cycles is calculated by combining the timing violation information extracted from the synthesis and timing report, and is used as the beat level.

[0032] In another embodiment, the automatic determination of the required number of beat levels includes: Based on the maximum transmission distance supported per cycle in the physical distance information, the number of puncturing cycles required for preventative puncturing of the target data path is estimated, and this number is used as the puncturing level. The timing violation-based puncturing method is suitable for path optimization scenarios where timing violations already exist, while the physical distance-based preventative puncturing method is suitable for scenarios where pre-optimization is performed before placement and routing. Both methods can be used in parallel, with the ultimate goal of eliminating timing violations.

[0033] In step S104, the automatic incorporation of the corresponding timing logic into the RTL code includes: an artificial intelligence algorithm automatically inserts registers or pipeline logic of the corresponding level between the start and end points of the target data path in the RTL code according to the timing level and the data path timing rules, and the modified RTL code meets the requirements of the original communication interface protocol; the artificial intelligence algorithm identifies the protocol type through syntax tree analysis, locates the protocol boundary through keyword matching, determines the allowed timing positions and methods through rule base query, and finally generates timing logic that conforms to the protocol specification.

[0034] The addition of keyword markers for tool recognition at the merged striking logic includes: Add predefined comment tags or attribute keywords to the automatically inserted register or pipeline code to identify the insertion position of the pacing logic, the corresponding interface protocol, and the pipeline number.

[0035] In step S105, it is determined whether the timing violations of the data path have been reduced to the target range. The "target range" refers to the relaxation amount in the timing analysis report becoming a non-negative number, that is, the establishment time violations of all related paths have been eliminated; or, to further improve the robustness of the design, a more stringent convergence target can be preset, such as requiring the relaxation amount to be greater than or equal to 5% of the clock cycle or a fixed positive value (such as +50ps).

[0036] To make the objectives, technical solutions, and advantages of the present invention clearer, the embodiments of the present invention will be described in further detail below with reference to the accompanying drawings.

[0037] Example 1: Method Example Combined Figure 2 As shown, this embodiment provides an automatic snapshot method for RTL data paths, including the following steps: Step S201: RTL code parsing and protocol identification.

[0038] Artificial intelligence algorithms are used to perform semantic and structural analysis on the input RTL code, automatically identifying the types of communication interface protocols present in the code. These AI algorithms can identify communication interface protocols and determine the corresponding data path timing methods and rules.

[0039] Specifically, the communication interface protocol types include, but are not limited to, AXI, AXI-Stream, TileLink, FIFO interfaces, and custom point-to-point interfaces. For each interface protocol, one or more corresponding timing rules can be predefined to form a rule base. Timing rules specify the method of timing operations under the constraints of the corresponding protocol. For example, for a FIFO interface, when a timing violation occurs in the data path, timing can only be added to the address path to ensure correct functionality; adding timing directly to the data path would introduce functional problems. The AI ​​algorithm needs to read the protocol document or rule base to generate these rules; different protocols have different rules. The AI ​​algorithm parses the protocol document using natural language processing technology or accesses the rule base using structured query language to generate a mapping table between protocols and timing rules. This step achieves a preliminary understanding of the design intent, laying the foundation for subsequent timing operations that conform to the protocol specifications, and avoiding protocol violations and functional errors caused by blind timing from the source.

[0040] Step S202: Integration and acquisition of time / distance information.

[0041] Using synthesis tools (such as FusionCompiler, DCG, Genus, etc.), the design is initially synthesized under the target process conditions to obtain key data path information. The timing and physical distance information of the target data path includes: path delay, physical distance information, and the maximum transmission distance that can be supported per cycle based on the target process conditions and design timing constraints.

[0042] It should be noted that the determination of the "maximum transmission distance supported per cycle" is determined by the semiconductor metal layer process. If the process conditions involve more metal layers and lower resistance, the transmission distance will be greater. For example, the typical transmission distance is approximately 1300 μm under the N12 process and approximately 1900 μm under the N7 process. This information is a crucial physical basis for subsequent timing decisions. This step achieves linkage between front-end design and actual physical implementation conditions, enabling timing decisions to be based on real process data. This significantly improves the accuracy of timing stage estimation and avoids over-design or timing non-convergence caused by relying solely on empirical estimations.

[0043] Step S203: Automatic decision-making on the number of beats.

[0044] Based on the identified interface protocol and corresponding module name, the algorithm automatically extracts data path timing information related to that protocol from the comprehensive and timing reports. Then, combining the timing information and / or physical distance information, the algorithm automatically determines the required number of beat levels.

[0045] Specifically, there are two ways to determine the beat level: Method 1 (based on timing violations): Determine whether there are timing violations in the target data path based on the timing information; if there are timing violations, calculate the required number of beat cycles by combining the timing violation information (such as VO size) extracted from the synthesis and timing report, and use it as the beat level.

[0046] Method 2 (Based on Physical Distance Estimation): Based on the maximum transmission distance supported per cycle in the physical distance information, estimate the number of sniping cycles required for preventative sniping of the target data path, and use this number as the sniping level. For example, if the estimated physical distance of a data path is 4000μm, and the maximum transmission distance per cycle is 1300μm, then the estimated number of sniping levels required is ceil(4000 / 1300)≈4 levels, where ceil represents the rounding up function.

[0047] The timing violation-based sampling method is suitable for path optimization scenarios where timing violations already exist, while the preventive sampling method based on physical distance information is suitable for scenarios where prediction and optimization are performed before placement and routing. The two methods can be used in parallel, with the ultimate goal of eliminating timing violations.

[0048] This step transforms abstract time-series reports and physical distances into concrete, actionable beat counts, automating and data-driven decision-making processes and eliminating the uncertainty of human experience.

[0049] Step S204: Automatic code modification and marking.

[0050] Based on the number of beat levels determined in step S203 and the beat rules determined in step 1, the corresponding beat logic is automatically merged into the RTL code, and keyword markers for tool recognition are added to the merged beat logic.

[0051] Specifically, an artificial intelligence algorithm automatically inserts registers or pipeline logic of the corresponding number of stages between the start and end points of the target data path in the RTL code, based on the number of stages and the stage rules of the data path. The AI ​​first needs to read the rule document or query the rule base, identify the protocol type through syntax tree analysis, locate the protocol boundary through keyword matching, and determine the allowed stage positions and methods of the protocol through rule base query (for example, for asynchronous FIFO, stage should be added to the address path rather than the data path). Then, it modifies the code according to the required number of stages, and the modified code still meets the requirements of the original communication interface protocol.

[0052] At the same time, predefined comment markers or attribute keywords are added to the automatically inserted register or pipeline code, such as " / / AUTO_PIPE:IF=AXI,STAGE=2" or " / pipe_info interface=tlink,stage=3 The slash " / " is used to identify the insertion position of the timing logic, the corresponding interface protocol, and the sequence number. These keyword markers facilitate automatic identification, tracing, and processing by tools in subsequent processes, providing a foundation for forming an automated closed loop.

[0053] This step enables the automatic implementation of decisions into code, significantly reducing the workload of manual code modification and the risk of introducing errors, while keyword tagging provides traceability for subsequent iterations.

[0054] Step S205: Iterative verification and closed-loop convergence.

[0055] The synthesis tool is invoked again to synthesize the modified RTL code, generating the corresponding timing analysis results, and determining whether the timing violations of the data path have been reduced to the target range. If the timing violations have not converged, steps S203 (automatically determining the timing level), S204 (automatically merging the timing logic), and S205 (invoking the synthesis tool again) are repeated until the timing violations converge.

[0056] This step verifies the effects of modifications by calling comprehensive tools and forms a closed-loop process of "analysis-decision-modification-verification". It realizes automated iteration of timing optimization, which can automatically approach the optimal pipeline configuration without manual intervention until the timing converges, significantly improving design efficiency and final design quality.

[0057] Example 2: System Example Combined Figure 3 As shown, this embodiment provides an automatic snapshot system for RTL data paths, used to implement the method described in Embodiment 1. The system includes a protocol identification module 1, an information acquisition module 2, a snapshot decision module 3, a code modification module 4, and an iterative verification module 5.

[0058] Figure 3The diagram below shows the structure of the automatic RTL data path timing system provided in Embodiment 2 of the present invention. It illustrates five core modules and their interactions. The workflow is as follows: Protocol identification module 1 sends the parsed protocol type and corresponding timing rules to timing decision module 3; Information acquisition module 2 also sends the timing information and physical distance information obtained by calling the comprehensive tool to timing decision module 3; Timing decision module 3 determines the required timing level based on the above information and passes this level along with the protocol rules to code modification module 4; Code modification module 4 inserts timing logic with keyword tags into the RTL code accordingly and feeds back the modified code path to iterative verification module 5; Iterative verification module 5 calls the comprehensive tool again for verification. If the timing does not converge, timing decision module 3 and code modification module 4 are re-triggered, forming a closed-loop optimization process.

[0059] The protocol identification module 1 is used to parse the RTL code using artificial intelligence algorithms, identify the communication interface protocols present in the RTL code, and determine the corresponding data path timing rules based on the identified communication interface protocols. This module analyzes the code semantics, understands the design intent, and provides a rule-based basis for subsequent timing operations that conform to the protocol specifications, avoiding functional errors caused by blind timing.

[0060] The information acquisition module 2 is used to call the integrated tool to perform comprehensive processing of the design and obtain the timing information and physical distance information of the target data path. This module realizes the linkage between the front-end design and the back-end physical implementation, enabling the timing decision to be based on real process data, which greatly improves the accuracy of the decision.

[0061] The timing decision module 3 is used to automatically determine the required number of timing levels based on the timing information, the physical distance information, and the data path timing rules. In one specific embodiment, the timing decision module determines whether there are timing violations in the target data path based on the timing information. If timing violations exist, it calculates the required number of timing cycles based on the timing violation information extracted from the aggregation and timing report, which is used as the timing level. In another specific embodiment, the timing decision module estimates the number of timing cycles required for preventative timing of the target data path based on the maximum transmission distance supported per cycle in the physical distance information, which is used as the timing level. The timing violation-based timing method is suitable for path optimization scenarios where timing violations already exist, while the preventative timing method based on physical distance information is suitable for scenarios where pre-optimization is performed before layout and routing. The two methods can be used in parallel, with the ultimate goal of eliminating timing violations. This module transforms abstract data into specific levels, realizing automated and data-driven decision-making.

[0062] The code modification module 4 is used to automatically merge the corresponding timing logic into the RTL code according to the timing level and the data path timing rules, and add keyword markers for tool recognition at the merged timing logic. The code modification module uses an artificial intelligence algorithm to automatically insert registers or pipeline logic of the corresponding level between the start and end points of the target data path in the RTL code according to the timing level and the data path timing rules. The artificial intelligence algorithm identifies the protocol type through syntax tree analysis, locates the protocol boundary through keyword matching, and determines the allowed timing positions and methods through rule base queries, ultimately generating timing logic that conforms to the protocol specification. This module realizes automatic implementation from decision to code, significantly reducing the workload and error risk of manual modification.

[0063] The iterative verification module 5 is used to call the synthesis tool again to synthesize the modified RTL code to generate timing analysis results, and to determine whether the timing violations of the data path have been reduced to the target range. If convergence has not been achieved, the timing decision module and the code modification module are triggered to perform a new round of optimization. This module forms a complete automated closed loop, ensuring that the final design can converge stably.

[0064] The collaborative work of the above modules enables automatic analysis, modification, and verification of data path timing, achieving the technical effects of reducing manual intervention, accelerating timing iteration, and reducing the risk of functional errors.

[0065] Example 3: Storage Medium Example This embodiment provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the automatic stamping method for RTL data paths as described in Embodiment 1.

[0066] The computer-readable storage medium can be any medium capable of storing program code, such as ROM, RAM, magnetic disk, or optical disk. When the program is loaded onto the processor and executed, it can drive relevant software and hardware resources to implement the method flow of this invention.

[0067] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. An automatic snapshot method for RTL data paths, characterized in that, include: Artificial intelligence algorithms are used to parse the RTL code, identify the communication interface protocols present in the RTL code, and determine the corresponding data path timing rules based on the identified communication interface protocols. The design is processed by a comprehensive tool to obtain the timing and physical distance information of the target data path; Based on the timing information, the physical distance information, and the data path timing rules, the required number of timing levels is automatically determined. Based on the number of beat levels and the beat rules of the data path, the corresponding beat logic is automatically merged into the RTL code, and keyword markers for tool recognition are added to the merged beat logic. The synthesis tool is called again to synthesize the modified RTL code, generate timing analysis results, and determine whether the timing violations in the data path have been reduced to the target range. If the timing violation does not converge, repeat the steps of automatically determining the timing level, automatically merging the timing logic, and calling the synthesis tool again until the timing violation converges.

2. The automatic snapshot method for RTL data paths according to claim 1, characterized in that, The step of determining the corresponding data path timing rules based on the identified communication interface protocol includes: determining one or more timing rules for different communication interface protocol types based on a predefined rule base, wherein the timing rules specify the way to perform timing operations under the constraints of the corresponding protocol; the rule base includes at least a protocol type field, an allowed additional timing position field, an additional timing direction field, and an upper limit field for additional timing levels; wherein the communication interface protocol type includes AXI, AXI-Stream, TileLink, FIFO interface, or a custom point-to-point interface.

3. The automatic snapshot method for RTL data paths according to claim 1, characterized in that, The timing and physical distance information of the target data path includes: path delay, physical distance information, and the maximum transmission distance that can be supported in a single cycle based on the target process conditions and design timing constraints.

4. The automatic snapshot method for RTL data paths according to claim 1, characterized in that, The automatic determination of the required number of time stamping levels includes: determining whether there are timing violations in the target data path based on the timing information; if there are timing violations, calculating the required number of time stamping cycles based on the timing violation information extracted from the comprehensive and timing reports, and using this as the number of time stamping levels.

5. The automatic snapshot method for RTL data paths according to claim 1, characterized in that, The automatic determination of the required number of timing violation levels includes: estimating the number of timing violation cycles required for preventive timing violation of the target data path based on the maximum transmission distance that can be supported per cycle in the physical distance information, and using this as the number of timing violation levels; the timing violation-based timing violation method is suitable for path optimization scenarios where timing violations already exist, while the preventive timing violation method based on physical distance information is suitable for scenarios where pre-optimization is performed before layout and routing. The two methods can be used in parallel, with the ultimate goal of eliminating timing violations.

6. The automatic snapshot method for RTL data paths according to claim 1, characterized in that, The automatic integration of corresponding timing logic into the RTL code includes: an artificial intelligence algorithm automatically inserting registers or pipeline logic of the corresponding level between the start and end points of the target data path in the RTL code according to the timing level and the data path timing rules, so that the modified RTL code meets the requirements of the original communication interface protocol; the artificial intelligence algorithm determines the timing position and method based on the protocol recognition result and the rule base.

7. The automatic snapshot method for RTL data paths according to claim 1, characterized in that, The step of adding keyword markers for tool recognition at the merged timing logic includes: adding predefined comment markers or attribute keywords to the automatically inserted register or pipeline code to identify the insertion position of the timing logic, the corresponding interface protocol, and the pipeline number.

8. An automatic RTL data path timing system for executing the automatic timing method for RTL data paths according to any one of claims 1-7, characterized in that, include: The protocol identification module is used to parse the RTL code using artificial intelligence algorithms, identify the communication interface protocols present in the RTL code, and determine the corresponding data path timing rules based on the identified communication interface protocols. The information acquisition module is used to call the integrated tools to perform integrated processing on the design and obtain the time series information and physical distance information of the target data path; The slapping decision module is used to automatically determine the required number of slapping levels based on the time sequence information, the physical distance information, and the data path slapping rules. The code modification module is used to automatically merge the corresponding pausing logic into the RTL code according to the pausing level and the data path pausing rules, and add keyword markers for the tool to recognize at the merged pausing logic. The iterative verification module is used to call the synthesis tool again to synthesize the modified RTL code to generate timing analysis results and determine whether the timing violations of the data path have been reduced to the target range. If convergence is not achieved, the timing decision module and the code modification module are triggered to perform a new round of optimization.

9. The automatic photo-taking system for RTL data paths according to claim 8, characterized in that, The timing decision module determines whether there are timing violations in the target data path based on the timing information. If there are timing violations, it calculates the required number of timing cycles based on the timing violation information extracted from the comprehensive and timing reports, which is used as the timing level.

10. The automatic photo-taking system for RTL data paths according to claim 8, characterized in that, The strike decision module is also used to estimate the number of strike cycles required for preventive strikes on the target data path based on the maximum transmission distance that can be supported per cycle in the physical distance information, so as to serve as the strike level.

Images