Chip asynchronous path checking method and device, computer device, storage medium and computer program product

Abstract

This application relates to a method, apparatus, computer device, storage medium, and computer program product for asynchronous path checking of a chip. The method includes: obtaining the target path code for each asynchronous path during the chip design phase, the target path code including an identifier code representing the path type; identifying the identifier code in the target path code of each asynchronous path during the chip synthesis phase to determine the path type of each asynchronous path; and setting timing constraints corresponding to the path type for each asynchronous path based on the path type. This method enables automatic identification of asynchronous path types, reducing manual intervention and avoiding path omissions.

Description

Technical Field

[0001] This application relates to the field of chip technology, and in particular to an asynchronous path checking method, apparatus, computer device, storage medium, and computer program product for a chip. Background Technology

[0002] In static timing analysis of chips, setting timing constraints for asynchronous paths typically requires designers to manually select the asynchronous paths to be constrained through forward filtering or reverse scraping, and then set the corresponding timing constraints one by one. However, in large-scale chips, the number of asynchronous paths can reach tens of millions or more. Relying entirely on manual screening is labor-intensive, inefficient, and prone to missing critical paths, leading to incomplete timing checks and affecting chip timing convergence and overall performance. Therefore, how to achieve automatic identification of asynchronous path types to reduce manual intervention and avoid path omissions is a pressing technical problem to be solved in this field. Summary of the Invention

[0003] Therefore, it is necessary to provide a method, apparatus, computer device, storage medium, and computer program product for asynchronous path checking of chips to address the above-mentioned technical problems. This method can automatically identify asynchronous path types, reduce manual intervention, and avoid path omissions.

[0004] Firstly, this application provides an asynchronous path checking method for a chip, comprising:

[0005] Obtain the target path code for each asynchronous path in the chip design phase, wherein the target path code includes an identifier code representing the path type;

[0006] During the chip synthesis stage, the identifier code in the target path code of each asynchronous path is identified to determine the path type of each asynchronous path;

[0007] Based on the path type of each asynchronous path, set timing constraints corresponding to the path type for each asynchronous path.

[0008] In one embodiment, obtaining the target path code for each asynchronous path in the chip design phase includes:

[0009] During the chip design phase, asynchronous paths in the chip are classified, and the path type of each asynchronous path is determined.

[0010] Insert identification code to characterize the path type into the initial path code of each asynchronous path to obtain the target path code.

[0011] In one embodiment, the identification code is a specific keyword carried in the standard unit;

[0012] The identification code in the target path code of each asynchronous path during the chip synthesis stage, in order to determine the path type of each asynchronous path, includes:

[0013] During the chip synthesis stage, specific keywords carried in the standard cells are extracted using information recognition tools.

[0014] Identify the path type corresponding to the specific keyword, and determine the path type corresponding to the specific keyword as the path type of the asynchronous path where the standard unit is located.

[0015] In one embodiment, the path type includes: a first type that does not require asynchronous checks, or a second type that requires asynchronous checks;

[0016] The step of setting timing constraints for each asynchronous path according to its path type includes:

[0017] If the path type of the asynchronous path belongs to the first type, then no timing constraints are set or loose timing constraints are set by the script. The upper limit of the delay of the loose timing constraints is greater than or equal to the upper limit of the delay of all timing paths in the chip.

[0018] If the asynchronous path belongs to the second type, the clock information of the asynchronous path is obtained through the script, and the delay limit is set based on the clock information.

[0019] In one embodiment, the first type includes: a single-bit path type, or a control path type with no temporal association between multiple bits;

[0020] The asynchronous path of the control path type is used to transmit control information.

[0021] In one embodiment, the second type includes: a control path type with time-series association between multiple bits, or a data path type with multiple bits;

[0022] The asynchronous path of the data path type is used for data transmission.

[0023] Secondly, this application also provides an asynchronous path checking device for a chip, comprising:

[0024] The acquisition module is used to acquire the target path code of each asynchronous path in the chip design stage, wherein the target path code includes an identification code that represents the path type;

[0025] The identification module is used to identify the identification code in the target path code of each asynchronous path during the chip synthesis stage in order to determine the path type of each asynchronous path.

[0026] The timing constraint module is used to set timing constraints for each asynchronous path according to its path type.

[0027] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method described in the first aspect.

[0028] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in the first aspect.

[0029] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the method described in the first aspect.

[0030] The aforementioned asynchronous path checking method, apparatus, computer device, storage medium, and computer program product for chips include: acquiring target path codes for each asynchronous path during the chip design phase, wherein the target path codes include identification codes characterizing the path type; identifying the identification codes in the target path codes of each asynchronous path during the chip synthesis phase to determine the path type of each asynchronous path; and setting timing constraints corresponding to the path type for each asynchronous path based on the path type. This approach marks asynchronous paths by type using identification codes during the design phase, and automatically captures, identifies, and classifies them for constraint setting during the synthesis phase. The entire process eliminates the need for manual path selection, thus achieving automatic identification of asynchronous path types, effectively reducing manual intervention and avoiding path omissions caused by manual operation. Attached Figure Description

[0031] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0032] Figure 1 This is a schematic diagram illustrating the design and implementation flow of the chip used in the asynchronous path checking method of a chip in one embodiment.

[0033] Figure 2 This is a flowchart illustrating the asynchronous path checking method for a chip in one embodiment;

[0034] Figure 3 This is a flowchart illustrating the method for obtaining the target path code in one embodiment;

[0035] Figure 4 This is a flowchart illustrating the asynchronous path checking method for a chip in another embodiment;

[0036] Figure 5 This is a structural block diagram of an asynchronous path checking device for a chip in one embodiment;

[0037] Figure 6 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0038] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0039] In static timing analysis of chips, setting timing constraints for asynchronous paths typically requires designers to manually select the asynchronous paths to be constrained through forward filtering or reverse scraping, and then set the corresponding timing constraints one by one. However, in large-scale chips, the number of asynchronous paths can reach tens of millions or more. Relying entirely on manual selection is labor-intensive, inefficient, and prone to missing critical paths, resulting in incomplete timing checks and affecting the chip's timing convergence and overall performance.

[0040] To address the aforementioned problems, embodiments of this application provide a method, apparatus, computer device, storage medium, and computer program product for asynchronous path checking of chips. This method can automatically identify asynchronous path types, effectively reducing manual intervention and avoiding path omissions caused by manual operation.

[0041] For example, Figure 1 This is a schematic diagram illustrating the design and implementation flow of the chip used in the asynchronous path checking method of a chip in one embodiment. For example... Figure 1 As shown, the process comprises two stages: a front-end and a back-end. The front-end includes chip design and chip synthesis. In the chip design stage, the target path code for each asynchronous path is obtained, and this target path code includes an identifier code representing the path type. In the chip synthesis stage, the identifier code in the target path code of each asynchronous path is identified to determine the path type of each asynchronous path, and timing constraints corresponding to the path type are set for each asynchronous path. The back-end receives the timing constraints set by the front-end and performs asynchronous path checks in static timing analysis on each asynchronous path.

[0042] The chip design stage, as described above, refers to the stage of writing and verifying Register Transfer Level (RTL) code based on the chip's functional and performance requirements. In this embodiment, identification code is added to asynchronous paths during this stage. The chip synthesis stage refers to the stage of converting RTL code into a gate-level netlist. In this embodiment, identification code is identified and timing constraints are set using an information identification tool during this stage.

[0043] In this embodiment, the asynchronous path checking method for the chip described above can be applied to an asynchronous path checking device for the chip or a computer device. The asynchronous path checking device for the chip can be a functional module or functional entity within the computer device used to implement the asynchronous path checking method for the chip described above.

[0044] For example, the aforementioned computer equipment can be a server, personal computer, workstation, Electronic Design Automation (EDA) server cluster, or cloud computing platform. Specifically, the computer equipment can be a dedicated workstation running EDA tools; it can also be an elastic computing instance deployed in the cloud for performing related processing in the chip design and synthesis stages; or it can be a distributed processing system composed of multiple computing nodes for parallel processing of the identification and constraint setting of tens of millions of asynchronous paths in large-scale chips.

[0045] In one exemplary embodiment, such as Figure 2 As shown, an asynchronous path checking method for a chip is provided, which includes the following steps 201 to 203:

[0046] 201. Obtain the target path code for each asynchronous path in the chip design phase.

[0047] The target path code includes an identifier code that represents the path type.

[0048] In the entire chip design process, the chip design stage mentioned above belongs to the front-end design stage. In this stage, register transfer level code is written using a hardware description language based on the chip's functional and performance specifications, and the code is functionally simulated and verified.

[0049] The aforementioned asynchronous path refers to the logical path through which data signals are transmitted from one clock domain to another.

[0050] In digital chips, multiple clock sources or different clock signals generated by frequency division exist, and these clocks are often asynchronous, meaning their phases and frequencies do not have a fixed correspondence. When data is transmitted along such cross-clock domain paths, metastability and data errors can easily occur without proper constraints and checks. Therefore, timing constraints for asynchronous paths are an important aspect of static timing analysis.

[0051] In this embodiment, the target path code can refer to an RTL code snippet containing an asynchronous path description. It may be a complete module code, or a specific assignment statement or instantiation statement. Crucially, the target path code includes an identifier code representing the path type. This identifier code is a manually added marker; it can be a string, a specific comment, a macro definition, an attribute, or the name of an instantiated standard unit. The purpose of this identifier code is to provide a basis for identification in subsequent automated processing.

[0052] In one implementation, the identifier code can be a special comment that the designer manually inserts when writing RTL code.

[0053] In one implementation, the identifier code can be a parameter set via a defparam statement in Verilog (a name for a hardware description language), or an attribute in system Verilog (an enhanced version of Verilog that adds object-oriented features, assertions, etc.).

[0054] In one implementation, the identifier code is represented as a standard unit carrying specific keywords.

[0055] 202. During the chip synthesis stage, identify the identifier code in the target path code of each asynchronous path to determine the path type of each asynchronous path.

[0056] In some implementations, the identifier code is a specific keyword carried in the standard cell. During the chip synthesis stage, the standard cell carrying the specific keyword can be captured by an information identification tool; then, the path type corresponding to the specific keyword is identified, and the path type corresponding to the specific keyword is determined as the path type of the asynchronous path where the standard cell is located.

[0057] In the chip synthesis stage described above, RTL code can be converted into a gate-level netlist. During this process, the information recognition tool reads the RTL code, performs logic optimization on it, maps it to standard cells provided by the process library, and extracts specific keywords carried by the standard cells.

[0058] The aforementioned standard cells refer to predefined circuit units with specific logical functions in the technology library, such as AND gates, OR gates, NOT gates, and flip-flops. Standard cells carrying specific keywords refer to special standard cells instantiated by designers in RTL code, whose names or instantiation tags contain a predefined keyword.

[0059] The aforementioned information identification tools may refer to Electronic Design Automation (EDA) tools used in the chip synthesis stage, which are mainly used to capture preset keywords in standard cells, and then identify and determine asynchronous paths and their types.

[0060] For example, designers can instantiate a buffer cell named "Asynchronous Path Marker_Gray Code" in the RTL code; this name is the preset keyword. This standard cell serves only as an identification anchor and has no actual logical function, or only performs signal transmission. During chip synthesis, relying on EDA tools, and using corresponding commands and scripts along with the wildcard "Asynchronous Path Marker," standard cells containing this specific keyword can be batched. Then, by tracing back based on the cell's location and circuit connections, if it is in a data path between different clock domains or its pins belong to different clock domain registers, the corresponding path can be determined to be an asynchronous path. Finally, parsing the keyword can determine the specific type of the asynchronous path.

[0061] In the above implementation method, by using specific keywords in the standard cell and using information identification tools in the chip synthesis stage to capture specific keywords, asynchronous paths between different clock domains can be quickly identified and their types can be determined without affecting the original circuit logic and signal transmission, thus improving the efficiency and convenience of asynchronous path detection and classification.

[0062] 203. Based on the path type of each asynchronous path, set timing constraints corresponding to the path type for each asynchronous path.

[0063] After determining the type of each asynchronous path, the next step is to set appropriate timing constraints for it. Timing constraints are rules used by static timing analysis tools to determine whether the timing of a circuit meets the requirements.

[0064] For asynchronous paths, a common constraint is the set_max_delay constraint, which specifies the maximum allowable transmission delay for data from the source clock domain register to the destination clock domain register.

[0065] In step 203, a script (such as a Tcl script) can be used to set constraints in batches. The script can execute different constraint generation logic based on the path type identified in step 202.

[0066] In some embodiments, the path types mentioned above include: a first type that does not require asynchronous checks, or a second type that requires asynchronous checks. Setting timing constraints corresponding to the path type for each asynchronous path, based on the path type of each asynchronous path, may include, but is not limited to:

[0067] (1) If the path type of the asynchronous path belongs to the first type, then the timing constraint is not set or a loose timing constraint is set by the script. The upper limit of the delay of the loose timing constraint is greater than or equal to the upper limit of the delay of all timing paths in the chip.

[0068] The first type includes: single-bit path type, or control path type with no temporal correlation between multiple bits; asynchronous paths of the control path type are used to transmit control information.

[0069] (2) If the path type of the asynchronous path is the second type, the clock information of the asynchronous path is obtained through the script, and the delay limit is set based on the clock information.

[0070] The second type includes: a control path type with time-series association between multiple bits, or a data path type with multiple bits; the asynchronous path of the data path type is used to transmit data.

[0071] For example, for a single-bit control path (i.e., an asynchronous control signal path), since it is not sensitive to delay or there is a handshake protocol, it may not be necessary to set a strict delay limit, or a very lenient delay limit can be set, which is greater than or equal to the delay limit of all timing paths in the chip.

[0072] For example, for a multi-bit control path encoded with Gray code, since the characteristics of Gray code require that only one bit changes during the transition of a multi-bit signal, a relatively strict but reasonable upper limit of delay needs to be set to ensure that no erroneous sampling occurs when multiple bits change simultaneously when all bits are sampled in the target clock domain.

[0073] For example, for a typical multi-bit data bus path, it may be necessary to set a suitable upper limit for latency based on the actual data throughput and clock frequency.

[0074] The specific implementation of the above script can include, but is not limited to: First, for each identified asynchronous path, obtain information about its source and destination clocks, including clock period, clock edge, and clock uncertainty. Then, look up a pre-configured delay limit calculation formula or lookup table based on the path type. For example, for Gray code paths, the delay limit can be set to a percentage of the destination clock period (e.g., 70%); for data bus paths, it can be set to a percentage of the minimum of the source and destination clock periods. Finally, the script outputs one or more `set_max_delay` commands, specifying the delay limit value, the path from the source register to the destination register, and possible additional options. In some implementations, for paths that do not require asynchronous checks, the script may not output any constraints, or may output an extremely large delay limit (e.g., 1000 times the system clock period), effectively relaxing the constraints. The technical advantage of this step is that it automates constraint setting and allows for the application of differentiated constraints based on the different characteristics of the path, avoiding over- or under-constraint problems caused by uniform constraints.

[0075] The asynchronous path checking method described above can obtain the target path code of each asynchronous path during the chip design phase. The target path code includes an identifier code representing the path type. During the chip synthesis phase, the identifier code in the target path code of each asynchronous path is identified to determine the path type of each asynchronous path. Based on the path type of each asynchronous path, timing constraints corresponding to the path type are set for each asynchronous path. This scheme marks the asynchronous paths with type identifiers during the design phase, and the tool automatically captures, identifies, and classifies them to set constraints during the synthesis phase. The entire process eliminates the need for manual path selection, thus achieving automatic identification of asynchronous path types, effectively reducing manual intervention and avoiding path omissions caused by manual operation.

[0076] In one exemplary embodiment, such as Figure 3 The diagram illustrates a process for obtaining a target path code, which includes the following steps 301 to 302:

[0077] 301. During the chip design phase, classify the asynchronous paths in the chip and determine the path type of each asynchronous path.

[0078] During or after RTL (Real-Time Script) writing, the chip design phase can systematically categorize all asynchronous paths within the chip. The categorization criteria can be based on the characteristics and inspection requirements of the asynchronous paths. A common categorization method is as follows:

[0079] (1) The first category is paths that do not require asynchronous checking, such as single-bit asynchronous paths or asynchronous paths where there is no timing relationship between multiple bits. Single-bit asynchronous paths are usually used for control signals such as interrupts and enable signals. These signals are often processed by dual-register synchronizers, and their timing requirements are relatively relaxed, and they do not necessarily need strict delay upper limit constraints. Paths where there is no timing relationship between multiple bits are, for example, multiple independent control signals that span clock domains respectively. There is no interdependence between them, and they do not need to be checked as a whole.

[0080] (2) The second category is paths that require asynchronous checking, which can be further subdivided into control paths with time-related relationships between multiple bits (such as Gray code control paths) and multi-bit data paths. Gray code control paths refer to control paths where multiple bits are transmitted in Gray code form and have time-related relationships, such as the read pointer and write pointer of a FIFO. The characteristic of Gray code is that only one bit changes between adjacent values, so there are strict requirements for path delay differences. If the delay difference between different bits is too large, it may cause multiple bits to change during sampling of the Gray code, thus compromising its correctness. Multi-bit data paths refer to paths used for transmitting data, such as bus data. These paths usually require data to be sampled stably in the target clock domain, so a reasonable upper limit for delay needs to be set. When classifying, designers need to comprehensively consider factors such as the purpose of the signal, the transmission method, and the sensitivity to timing. The classification results can be recorded in a design document or spreadsheet, but in this method, the purpose of classification is to insert identification codes later, so the classification results will be directly mapped to different types of identification codes.

[0081] 302. Insert identification code to characterize the path type into the initial path code of each asynchronous path to obtain the target path code.

[0082] After determining the type of each asynchronous path, designers need to insert identifier code into the corresponding initial path code. Initial path code refers to the raw, unmarked RTL code. There are several ways to insert identifier code.

[0083] One approach is to add comments directly to the code. For example, for a Gray code path, comments can be added next to the relevant assignment or instantiation statements. The advantage of this approach is its simplicity and intuitiveness, without changing the circuit logic. The disadvantage is that the comments may be ignored by information recognition tools, requiring the use of custom scripts for extraction, and they are easily lost during code formatting or migration.

[0084] Another approach is to label them using parameters or attributes. This method is more structured, and some advanced information recognition tools can directly read these attributes.

[0085] In another approach, inserting an identifier code refers to inserting a specific keyword carried by a standard cell. Specifically, a special marker cell can be instantiated at a critical location in the asynchronous path (e.g., the output of the source register, the input of the destination register, or in the middle of the path). This marker cell can be a buffer or inverter already existing in the technology library, or it can be a virtual cell specifically designed for this method. The name of the marker cell or its instantiation label contains keywords representing the path type.

[0086] For example, for a Gray code path, a buffer named "u_gray_marker" is instantiated; for a data bus path, a buffer named "u_data_bus_marker" is instantiated; and for a single-bit path, a buffer named "u_single_bit_marker" can be instantiated. The inputs and outputs of this marker unit can be directly connected or shorted to avoid affecting circuit functionality. After inserting the marker unit, the initial path code is transformed into the target path code, which contains markers that can be automatically recognized by tools. The technical advantage of this step is that by inserting physical marker units, path type information is embedded in the design as circuit elements. This marking method can be reliably identified and captured by all standard information recognition tools, exhibiting extremely high robustness and versatility.

[0087] The above embodiments describe how to add identification codes to target path codes during the design phase. By classifying and inserting identification codes during the chip design phase, the workload of asynchronous path management is shifted from the arduous later-stage screening to the design phase. This leverages the designer's deep understanding of circuit functionality to guide the classification, and by inserting specific keywords carried by standard cells, a reliable technical foundation is provided for automated identification during the synthesis phase. This embodiment is similar to... Figure 2 The various implementations work together to form a complete automated process from the chip design stage to the chip synthesis stage.

[0088] In one exemplary embodiment, such as Figure 4 As shown, Figure 4 This is a flowchart illustrating an asynchronous path checking method for a chip in another embodiment. The method includes the following steps 401 to 406:

[0089] 401. During the chip design phase, classify the asynchronous paths in the chip and determine the path type of each asynchronous path.

[0090] For the technical details of step 401, please refer to [reference needed]. Figure 3 A detailed explanation of step 301 in the document.

[0091] It should be noted that the granularity of asynchronous path classification can be further refined. In addition to the broad categories mentioned above, such as no-check paths, Gray code controlled paths, and multi-bit data paths, more detailed classifications can be made based on factors such as clock frequency ratio, data width, and handshake protocol type. For example, multi-bit data paths can be further divided into streaming data paths, burst data paths, and register configuration paths. Different subtypes may require different constraint strategies. The classification results should form a clear path type mapping table to guide the subsequent insertion of identification code.

[0092] In some implementations, the classification process can be partially automated. For example, scripts can automatically identify all cross-clock domain paths, which are then categorized by designers. This semi-automated approach combines the breadth of tools with the depth of human expertise, further improving efficiency.

[0093] 402. Insert identification code, which is implemented using specific keywords carried by standard units, into the initial path code of each asynchronous path to obtain the target path code.

[0094] Step 402 is... Figure 3 The specific details of step 302 emphasize that the inserted element is a specific keyword carried within the standard cell. Further explanation of the implementation of the standard cell follows: A standard cell can be a pre-existing cell with a specific function in the technology library, such as a buffer (BUF) or a NAND gate. A cell that does not functionally affect the circuit logic can be selected; for example, directly connecting the input and output of a buffer, or shorting the two inputs of a NAND gate to turn it into an inverter. To avoid adding unnecessary logic, virtual cells from the technology library can also be selected. These cells are typically designed for filling or connecting, do not have logical functions, but are retained in the netlist.

[0095] The specific keywords in the aforementioned standard units can be implemented in several ways: First, the unit name itself contains the keyword, such as "BUF_GRAY_MARKER", where "GRAY" is the keyword representing the Gray code path; second, the keyword is used as the instantiation name of the standard unit, such as instantiating the standard unit as "u_gray_marker", where "gray" is the keyword; third, the keyword is carried by setting attributes for the standard unit, such as attaching an attribute "async_path_type = gray" to the unit.

[0096] After the information recognition tool reads the RTL code containing these standard cells, these standard cells exist as actual elements in the netlist. Information recognition tools typically provide a rich set of commands to query and manipulate information about the standard cells in the netlist, allowing for the filtering of standard cells carrying specific keywords. Therefore, by inserting specific keywords carried by the standard cells, the existing functionality of the information recognition tool can be leveraged to achieve accurate labeling and identification of asynchronous paths.

[0097] 403. During the chip integration stage, specific keywords are captured using information recognition tools.

[0098] Step 403 is... Figure 2 The identification code is specified in step 202. After completing RTL compilation and preliminary optimization, the information identification tool generates a gate-level netlist. This gate-level netlist contains information about the standard cells inserted in step 402. At this point, specific keywords in these standard cells can be easily extracted using the scripting language and query commands provided by the information identification tool.

[0099] For example, the "Get Cells" command provided by the information recognition tool can be used in conjunction with the wildcard "*" for fuzzy matching to determine the preset keywords contained in the names of standard cells. For instance, if the preset keyword is "Gray code", then "Gray code *" can be used as the matching pattern to capture all cells whose names contain the string "Gray code". The captured cells will return a set, and subsequent scripts can iterate through each cell in this set.

[0100] For each standard cell corresponding to a preset keyword, the script can further obtain information about its path. Typically, the script can trace the source register connected to the cell's input pins and the destination register connected to its output pins. Using commands such as "Get Pins," "Get Nets," and "Get All Connections," a complete path from the source clock domain to the destination clock domain can be constructed.

[0101] 404. Identify the path type corresponding to the specific keyword, and determine the path type corresponding to the specific keyword as the path type of the asynchronous path where the standard unit is located.

[0102] After capturing standard cells carrying specific keywords, the script needs to parse the keywords to determine the path type. Keywords can be strings with clear semantics, such as "gray," "data_bus," or "single_bit." The script can extract keywords from cell or instance names using Tcl (tool command language) string manipulation commands, such as `regexp` or `string match`. After extracting the keywords, the script can compare them with a predefined mapping table. For example, the mapping table might define: "gray" corresponds to "Gray code control path, requiring a relatively strict latency limit"; "data_bus" corresponds to "multi-bit data path, requiring a moderate latency limit"; and "single_bit" corresponds to "single-bit path, no asynchronous checking required."

[0103] In some implementations, keywords can directly indicate timing constraints; for example, "gray_2ns" represents a Gray code path with a maximum delay of 2 nanoseconds. This approach is more direct but less flexible. After determining the path type, the script can record this information in a data structure, such as an associative array, using the path identifier (e.g., a combination of source and destination register names) as keys to store the path type and other relevant information. The technical advantage of this step is that it transforms simple string keywords into meaningful path type information, providing accurate input for the next step of constraint setting.

[0104] 405. Based on the path type of each asynchronous path, set timing constraints corresponding to the path type for each asynchronous path.

[0105] Step 405 above is... Figure 2 Step 203 is then elaborated. After obtaining the path type information, the script begins generating timing constraints. During constraint generation, the clock information for each path needs to be obtained.

[0106] An asynchronous path typically involves a launch clock and a latch clock. The launch clock drives the source register, and the latch clock drives the destination register. These two clocks may have different frequencies and phases. Scripts can obtain clock information using commands from information recognition tools. After obtaining the clock object, further attributes such as clock period and waveform can be retrieved.

[0107] In this embodiment of the application, for paths that require asynchronous checks, the script needs to determine a reasonable upper limit for latency. The strategy for determining the upper limit for latency can vary depending on the path type.

[0108] For example, for Gray code paths, the upper limit of the delay can be set to be less than the destination clock period, while ensuring that the delay difference between multiple signals is small enough. A common practice is to set the upper limit of the delay to 60% to 80% of the destination clock period, or to a certain proportion of the minimum of the source clock period and the destination clock period.

[0109] For example, for multi-bit data paths, the latency ceiling typically depends on whether the data is sampled on the rising or falling edge of the destination clock, and the setup and hold times the data needs to meet. In some implementations, the latency ceiling can be set to the destination clock cycle minus the setup time of the destination register.

[0110] For example, for paths that do not require asynchronous checks, the script may not generate constraints at all, or it may generate an extremely large delay cap, such as 100 nanoseconds or 1 microsecond. The script that generates constraints will eventually output a series of `set_max_delay` commands. These commands can be written to a separate constraint file or executed directly in the information recognition tool.

[0111] The above step 405 can realize the batch and differentiated generation of constraints through scripts, which greatly improves the efficiency and accuracy of constraint setting.

[0112] 406. Send the timing constraints set for each asynchronous path to the backend so that the backend can perform timing checks.

[0113] The timing constraints generated during the synthesis phase ultimately need to be passed to backend tools for static timing analysis and physical implementation.

[0114] Backend tools typically include place-and-route tools and a standalone static timing analysis tool. These tools can read constraint files in a standard format, usually SDC. An SDC file is a text-based file containing various timing constraint commands. The script writes all constraints generated in step 405 into one or more Synopsys Design Constraints (SDC) files. These SDC files are passed to the backend along with the netlist. Upon startup, the backend tool reads the netlist and SDC constraint files and then performs static timing analysis. During the analysis, the backend tool checks whether each asynchronous path meets its corresponding latency cap. If it does, timing convergence is achieved; otherwise, a violation is reported.

[0115] Because the above method has already set constraints reasonably according to path type, the violations reported by the backend are often timing issues that need to be resolved, rather than false violations caused by over-constraints. Furthermore, for paths that do not require checking, or have no constraints or excessively large constraints, the backend tool will not perform rigorous checks, thus avoiding a large number of useless violation reports. This method can be seamlessly integrated into existing chip design flows. By passing differentiated constraints to the backend, it effectively guides the backend's timing convergence work, reduces unnecessary iterations, and improves the efficiency of backend design.

[0116] Figure 4 The illustrated embodiment covers all stages from design phase classification and tag insertion to synthesis phase identification and constraint setting, and finally to back-end timing checks. Compared to existing technologies, it has at least the following significant advantages: First, through automated path identification and constraint setting, it completely solves the problem of the huge workload and easy omissions in manual screening of asynchronous paths in large-scale chips; Second, through differentiated constraint strategies, it avoids the problems of over-constraint and rampant violations caused by uniform constraints, making the back-end timing convergence process smoother; Third, by connecting constraint generation with back-end tools, a complete automated process is formed, reducing the number of design iterations and shortening the chip design cycle; Fourth, based on standard Electronic Design Automation (EDA) tools and standard scripting languages, it does not require special tools or complex development, and has high practical value and scalability.

[0117] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0118] Based on the same inventive concept, this application also provides an asynchronous path checking device for a chip to implement the asynchronous path checking method for the chip described above. The solution provided by this device is similar to the implementation described in the above method. Therefore, the specific limitations in the embodiments of the asynchronous path checking device for one or more chips provided below can be found in the limitations of the asynchronous path checking method for chips described above, and will not be repeated here.

[0119] In one exemplary embodiment, such as Figure 5 As shown, an asynchronous path checking device for a chip is provided, comprising:

[0120] The acquisition module 501 is used to acquire the target path code of each asynchronous path in the chip design stage, wherein the target path code includes an identification code that represents the path type;

[0121] The identification module 502 is used to identify the identification code in the target path code of each asynchronous path during the chip synthesis stage in order to determine the path type of each asynchronous path.

[0122] The timing constraint module 503 is used to set timing constraints corresponding to the path type for each asynchronous path based on the path type of each asynchronous path.

[0123] In some embodiments, the acquisition module 501 is specifically used for:

[0124] During the chip design phase, asynchronous paths in the chip are classified, and the path type of each asynchronous path is determined.

[0125] Insert identification code to characterize the path type into the initial path code of each asynchronous path to obtain the target path code.

[0126] In some embodiments, the identification code is a specific keyword carried in the standard unit; the identification module 502 is used for:

[0127] During the chip synthesis stage, specific keywords carried in the standard cells are extracted using information recognition tools.

[0128] Identify the path type corresponding to the specific keyword, and determine the path type corresponding to the specific keyword as the path type of the asynchronous path where the standard unit is located.

[0129] In some embodiments, the path type includes: a first type that does not require asynchronous checking, or a second type that requires asynchronous checking; the timing constraint module 503 is specifically used to: if the path type of the asynchronous path belongs to the first type, then by means of a script, not set timing constraints or set relaxed timing constraints. The upper limit of the delay of the relaxed timing constraint is greater than or equal to the upper limit of the delay of all timing paths in the chip;

[0130] If the asynchronous path belongs to the second type, the clock information of the asynchronous path is obtained through the script, and the delay limit is set based on the clock information.

[0131] In some embodiments, the first type includes: a single-bit path type, or a control path type with no temporal association between multiple bits;

[0132] The asynchronous path of the control path type is used to transmit control information.

[0133] In some embodiments, the second type includes: a control path type with time-series association between multiple bits, or a data path type with multiple bits;

[0134] The asynchronous path of the data path type is used for data transmission.

[0135] The modules in the asynchronous path checking method device of the aforementioned chip can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0136] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 6As shown, the computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements the asynchronous path checking method for the chip as described in the above method embodiment.

[0137] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0138] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the asynchronous path checking method for a chip as shown in the above method embodiment.

[0139] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the asynchronous path checking method for a chip as shown in the above method embodiment.

[0140] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the asynchronous path checking method for a chip as shown in the above method embodiment.

[0141] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0142] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0143] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method of asynchronous path checking of a chip, characterized by, include: Obtain the target path code for each asynchronous path in the chip design phase, wherein the target path code includes an identifier code representing the path type; During the chip synthesis stage, the identifier code in the target path code of each asynchronous path is identified to determine the path type of each asynchronous path; Based on the path type of each asynchronous path, set timing constraints corresponding to the path type for each asynchronous path.

2. The method of claim 1, wherein, The acquisition of the target path code for each asynchronous path in the chip design phase includes: During the chip design phase, asynchronous paths in the chip are classified, and the path type of each asynchronous path is determined. Insert identification code to characterize the path type into the initial path code of each asynchronous path to obtain the target path code.

3. The method of claim 1, wherein, The identification code is a specific keyword carried in the standard unit; The identification code in the target path code of each asynchronous path during the chip synthesis stage, in order to determine the path type of each asynchronous path, includes: During the chip synthesis stage, specific keywords carried in the standard cells are extracted using information recognition tools. Identify the path type corresponding to the specific keyword, and determine the path type corresponding to the specific keyword as the path type of the asynchronous path where the standard unit is located.

4. The method according to any one of claims 1 to 3, characterized in that, The path types include: a first type that does not require asynchronous checks, or a second type that requires asynchronous checks; The step of setting timing constraints for each asynchronous path according to its path type includes: If the path type of the asynchronous path belongs to the first type, then no timing constraints are set or loose timing constraints are set by the script. The upper limit of the delay of the loose timing constraints is greater than or equal to the upper limit of the delay of all timing paths in the chip. If the asynchronous path belongs to the second type, the clock information of the asynchronous path is obtained through the script, and the delay limit is set based on the clock information.

5. The method of claim 4, wherein, The first type includes: single-bit path type, or control path type with no temporal correlation between multiple bits; The asynchronous path of the control path type is used to transmit control information.

6. The method of claim 4, wherein, The second type includes: control path types with time-series correlation between multiple bits, or data path types with multiple bits; The asynchronous path of the data path type is used for data transmission.

7. A chip asynchronous path checking apparatus characterized by comprising: The device includes: The acquisition module is used to acquire the target path code of each asynchronous path in the chip design stage, wherein the target path code includes an identification code that represents the path type; The identification module is used to identify the identification code in the target path code of each asynchronous path during the chip synthesis stage in order to determine the path type of each asynchronous path. The timing constraint module is used to set timing constraints for each asynchronous path according to its path type.

8. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having stored thereon a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images