Timing constraint generation method and system, electronic equipment and storage medium

Abstract

The invention provides a timing constraint generation method and system, electronic equipment and a storage medium, and relates to the technical field of chip design. The method comprises the following steps: acquiring top-layer clock mapping information of a chip; acquiring clock description information of each module in the chip according to the top-layer clock mapping information, and analyzing the clock description information of each module to obtain module clock attribute information; and converting the module clock attribute information into top-layer clock attribute information, and generating a top-layer time sequence constraint according to the top-layer clock attribute information. According to the method, the top-layer time sequence constraint is automatically generated by analyzing the top-layer clock mapping information and the clock description information of the modules at the bottom layer, the process of manually compiling and maintaining the constraint layer by layer is avoided, the design workload is remarkably reduced, the consistency and the generation efficiency of the time sequence constraint are improved, and therefore the overall design period of a chip is shortened.

Description

Technical Field

[0001] This disclosure relates to the field of chip design technology, and more specifically, to a timing constraint generation method, system, electronic device, and storage medium. Background Technology

[0002] In the field of digital chip design, timing constraint files are crucial for ensuring the correctness of circuit logic and achieving performance targets. With the continuous expansion of chip design scale and the increasing sophistication of system integration levels, the number and complexity of timing constraint files have significantly increased. In related design flows, the top-level timing constraint files and the timing constraint files of lower-level modules are typically provided separately by different designers, lacking a unified constraint generation and management mechanism. Because the timing constraint relationships between the top level and modules are not planned holistically, the top level and modules often define constraints independently, lacking necessary correlation and consistency.

[0003] This decentralized design approach presents several problems. On the one hand, top-level designers need to repeatedly input the same or similar constraints as modules when writing timing constraints, resulting in redundant work. On the other hand, differences among designers in naming conventions, clock attributes, and constraint parameters can easily lead to conflicts in timing constraints between the top level and modules, such as inconsistent clock names or mismatched attribute values. These issues increase the workload of downstream verification personnel and reduce timing verification efficiency.

[0004] Furthermore, existing timing constraint files largely rely on manual writing and maintenance, which is prone to input errors or omissions, making it difficult to guarantee the completeness and consistency of timing definitions between the top level and modules. As chip design complexity increases, this manual approach can no longer meet the efficiency and accuracy requirements of timing constraint management, ultimately leading to extended chip design cycles and impacting chip project progress and product launch time.

[0005] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0006] The purpose of this disclosure is to provide a timing constraint generation method, system, electronic device, and storage medium. By parsing the top-level clock mapping information and the clock description information of each module at the bottom level, the top-level timing constraints are automatically generated, avoiding the process of manually writing and maintaining constraints layer by layer, significantly reducing the design workload, improving the consistency and generation efficiency of timing constraints, and thus shortening the overall design cycle of the chip.

[0007] According to a first aspect of this disclosure, a method for generating time-series constraints is provided, comprising: Obtain the chip's top-level clock mapping information; The clock description information of each module in the chip is obtained based on the top-level clock mapping information, and the module clock attribute information is parsed from the clock description information of each module. Convert the module clock attribute information into top-level clock attribute information, and generate top-level timing constraints based on the top-level clock attribute information.

[0008] According to a second aspect of this disclosure, a timing constraint generation system is provided, comprising: The top-level information acquisition module is used to acquire the chip's top-level clock mapping information; The underlying information parsing module is used to obtain the clock description information of each module in the chip based on the top-level clock mapping information, and to parse the module clock attribute information from the clock description information of each module. The top-level constraint generation module is used to convert module clock attribute information into top-level clock attribute information and generate top-level timing constraints based on the top-level clock attribute information.

[0009] According to a third aspect of this disclosure, an electronic device is provided, comprising: The processing unit; and the storage unit for storing executable instructions of the processing unit; wherein the processing unit is configured to execute the above timing constraint generation method by executing the executable instructions.

[0010] According to a fourth aspect of this disclosure, a computer-readable storage medium is provided, on which a computer program is stored, wherein the computer program, when executed by a processing unit, implements the above-described timing constraint generation method.

[0011] The exemplary embodiments disclosed herein may have some or all of the following beneficial effects: The timing constraint generation method provided in this exemplary embodiment automatically identifies and inherits the timing relationships between the top layer and modules by parsing the top-level clock mapping information and the clock description information of each module at the bottom layer. This automatically generates a top-level timing constraint file, avoiding manual layer-by-layer writing and maintenance of constraints. This method effectively reduces repetitive work and human error, improves the consistency and generation efficiency of timing constraints, thereby shortening the overall chip design cycle.

[0012] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0013] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure. It is obvious that the drawings described below are merely some embodiments of this disclosure, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0014] Figure 1 A flowchart illustrating a timing constraint generation method according to an embodiment of this disclosure is shown.

[0015] Figure 2 A schematic diagram illustrating the process of converting module clock attribute information into top-level clock attribute information in an embodiment of this disclosure is shown.

[0016] Figure 3 This illustration shows a flowchart of another embodiment of the present disclosure, illustrating the conversion of module clock attribute information into top-level clock attribute information.

[0017] Figure 4 This illustration shows a flowchart of another embodiment of the present disclosure, illustrating the conversion of module clock attribute information into top-level clock attribute information.

[0018] Figure 5 A block diagram of a timing constraint generation system according to an embodiment of the present disclosure is shown.

[0019] Figure 6 A schematic diagram of the structure of an electronic device suitable for implementing embodiments of the present disclosure is shown.

[0020] In the accompanying drawings, the same or corresponding reference numerals indicate the same or corresponding parts. Detailed Implementation

[0021] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this disclosure more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art. The described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a full understanding of embodiments of this disclosure. However, those skilled in the art will recognize that the technical solutions of this disclosure can be practiced with one or more specific details omitted, or other methods, components, apparatus, steps, etc., can be employed. In other instances, well-known technical solutions are not shown or described in detail to avoid obscuring various aspects of this disclosure.

[0022] Furthermore, the accompanying drawings are merely illustrative of this disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0023] In existing chip design flows, some solutions attempt to integrate module constraint data at the top level through modular constraint inheritance to reduce repetitive coding. However, this approach still requires designers to manually annotate exportable constraint items and perform merging operations. Due to inconsistencies in naming conventions, clock cycle definitions, and attribute descriptions across different modules, conflicts or redundant constraints can easily arise during top-level integration, leading to clock relationship mismatches and affecting overall timing convergence quality. Some methods introduce static RTL (Register Transfer Level) analysis, deriving the clock topology by detecting PLLs (Phase-Locked Loops), dividers, and multiplexers in the code. However, these methods rely on complete source code and cannot handle black-box units containing encryption logic or third-party IP, limiting their applicability in practical applications.

[0024] Furthermore, as chip design scales up and collaborative teams increase, different design groups often maintain their own clock constraint files independently. Due to the lack of a unified interaction format and hierarchical inheritance mechanism, issues such as clock name conflicts, broken master-slave relationships, and attribute mismatches easily arise during the top-level integration phase. Designers must manually compare, adjust, and verify the constraint content of each sub-unit during the integration phase, which not only increases the difficulty of timing convergence but also extends the design iteration cycle. When chips need to simultaneously cover multiple process technologies, voltages, and temperature conditions, the current constraint generation method struggles to maintain consistency across multiple operating conditions, requiring repeated manual modifications and verifications, further increasing the design burden.

[0025] To address one or more of the aforementioned technical problems, this disclosure provides an example implementation of a method for generating timing constraints. (See reference...) Figure 1 As shown, the timing constraint generation method may include the following steps S110 to S130: Step S110: Obtain the top-level clock mapping information of the chip; Step S120: Obtain the clock description information of each module in the chip according to the top-level clock mapping information, and parse the module clock attribute information from the clock description information of each module. Step S130: Convert the module clock attribute information into top-level clock attribute information, and generate top-level timing constraints based on the top-level clock attribute information.

[0026] The timing constraint generation method provided in this disclosure identifies and inherits the timing relationships between the top layer and modules by parsing the top-level clock mapping information and the clock description information of each module at the bottom layer. This automatically generates the top-level timing constraint file, avoiding the need for manual layer-by-layer writing and maintenance of constraints. This method effectively reduces repetitive work and human error, improves the consistency and generation efficiency of timing constraints, and thus shortens the overall chip design cycle.

[0027] The timing constraint generation method in this example embodiment will now be described in detail.

[0028] In step S110, the top-level clock mapping information of the chip is obtained.

[0029] In the exemplary embodiments of this disclosure, in order to improve the efficiency and accuracy of chip design, integration, and timing constraint management, the entire chip can be modularly divided according to functional units during the design phase. Each module can be any independent design unit. For example, in a specific implementation, a tile structure can be used as the smallest design and integration unit; of course, other instantiable design hierarchical units can also be used, and this disclosure does not limit this.

[0030] The chip top layer is the highest level of the system structure, used to uniformly manage the interconnection relationships, clock allocation, and global constraints between modules. The top layer does not directly carry specific business logic, but rather serves as the system integration and control layer, responsible for signal connections between different modules, global clock distribution, reset control, and cross-module communication.

[0031] Taking a tile structure as an example, each tile represents an independent functional subsystem within the chip, which can be viewed as a module unit instantiated at the top level. The entire chip can be considered as being composed of multiple tiles, each tile being instantiated in the hierarchical structure in the form of u${n}_${tile_name}. Here, n represents the instantiation sequence number of the tile at the top level, and tile_name represents the module name. For example, u0_tile_pcie represents the first PCIe (Peripheral Component InterconnectExpress) subsystem module, and u1_tile_ddr represents the second DDR (Double Data Rate) controller module.

[0032] Tiles are interconnected via top-level wire signals for data transmission, control command interaction, or state synchronization. For example, when performing storage access operations, u1_tile_ddr may need to receive a request signal from u0_tile_pcie, which is transmitted from u0_tile_pcie to u1_tile_ddr via the top-level wire.

[0033] It should be noted that there are no smaller dividing units between tiles, and the internal structure of each tile is relatively closed in the design to ensure the independence of its logic and clock system.

[0034] By using a tile-based architecture as the smallest design unit, the system can achieve a clear division of the internal hierarchy of the chip while ensuring modularity and reusability. This facilitates unified management of cross-layer clock paths and automated timing constraint generation, thereby ensuring that the hierarchical structure of clock paths remains consistent between the top layer and modules. It avoids constraint resolution errors caused by multi-level nesting or inconsistent naming, improves the accuracy of timing constraint generation and the reliability of system integration, and provides a foundation for the layered design and efficient integration of complex chips.

[0035] Specifically, top-level clock mapping information (such as clock map files) is used to characterize the correspondence between clock signals in the chip's top-level design and the instantiated ports of each module, describing the distribution and propagation path of the top-level clock signals in different modules. It's important to note that top-level clock mapping information can be exported from clock configuration files during the design phase, files generated by system integration tools, or user-defined clock connection tables, and used as external input for subsequent automatic generation of timing constraints and clock relationship resolution. By obtaining top-level clock mapping information as external input, the clock correspondence between the top level and each module can be uniformly resolved and managed without relying on a specific design environment, thereby improving the universality and compatibility of the constraint generation process.

[0036] Optionally, the carrier of the top-level clock mapping information can be an Excel spreadsheet, an XML (Extensible Markup Language File), or other structured data files that can represent clock connection relationships. This disclosure does not limit the specific storage format of the top-level clock mapping information.

[0037] In some example implementations, the top-level clock mapping information includes at least the top-level clock signal name, the corresponding module instantiation port name, clock direction attribute (input or output), clock frequency, phase relationship, and clock constraint type. Parsing the top-level clock mapping information allows for accurate acquisition of the distribution and correspondence of the top-level clock signal among various modules, clarifying the mapping path between the top-level clock and module ports. This provides fundamental data support for obtaining clock description information for subsequent modules and inheriting cross-layer clock attributes, thereby ensuring the consistency and traceability of clock relationships between the top-level clock and modules.

[0038] For example, during the design process, the top-level design lead defines a top-level clock mapping file, such as a file named clock_map.csv, to record clock connection relationships. This file clarifies the correspondence between top-level clock signals and port instances of various modules (such as tiles), enabling automatic identification and parsing of clock mapping information, thereby achieving automatic generation and inheritance of cross-level clock constraints. The contents of the clock_map.csv file are shown in Table 1. Table 1 In Table 1, the top-level clock signal `pcie_sys_clk` is connected to the `clk_i` port of the `u_tile_pcie` instance, providing the root clock input for the PCIe subsystem module. The top-level clock signal `ddr_sys_ref_clk` is connected to the `ref_clk_i` port of the `u_tile_ddr` instance, serving as the derived clock input for the DDR controller module. This mapping file can also contain clock frequency configuration information under different process and voltage conditions to support multi-condition timing analysis. For example, under `ssgnp0p675v` (slow operating condition, 0.675V), the PCIe clock signal frequency is 100MHz, and the DDR clock signal frequency is 25MHz. Under `tt0p75v` (typical operating condition, 0.75V), the PCIe clock signal frequency is 100MHz, and the DDR clock signal frequency is 25MHz. Under `ffgnp0p825v` (fast operating condition, 0.825V), the PCIe clock signal frequency is 100MHz, and the DDR clock signal frequency is 25MHz.

[0039] By defining top-level clock mapping information, a unified clock mapping model between the top level and each module can be established. When generating timing constraints, the clock source and hierarchical correspondence of each module can be accurately identified, thus providing a basis for the subsequent automated generation of timing constraints and avoiding errors and inconsistencies caused by manually marking clock connections repeatedly between the top level and modules.

[0040] In step S120, the clock description information of each module in the chip is obtained according to the top-level clock mapping information, and the module clock attribute information is parsed from the clock description information of each module.

[0041] In the exemplary embodiments of this disclosure, clock description information of each module also needs to be received from external input. This clock description information describes the clock definition within each module (e.g., a tile). The clock description information reflects the definition of all clocks within the module, including both input / output clocks at the module ports and clock signals at various levels derived from the master clock within the module.

[0042] In practice, the clock description information for each module is typically provided by the module's design lead based on the top-level clock mapping information. This ensures consistency between the internal clock definitions of the module and the top-level clock mapping. The clock description information for each module enables the extraction and unified management of module-level clock attributes, providing a data foundation for subsequent cross-level inheritance of clock attributes and the generation of timing constraints.

[0043] Optionally, the clock description information of each module can be carried in the form of an Excel spreadsheet, an XML file, or other structured data files that can characterize the clock attribute relationships within the module. This disclosure does not limit the specific storage format of the clock description information of each module.

[0044] Taking the design of a complex SoC (System on Chip) chip as an example, the chip includes multiple modules, such as the PCIe subsystem module (tile_pcie) and the DDR controller module (tile_ddr). Each module has an independent or associated clock architecture to meet the timing requirements of multi-functional collaborative operation.

[0045] The PCIe subsystem module is used to implement high-speed peripheral connectivity. Internally, this module contains a root clock, clk_pcie, with a frequency of 100MHz, generated by the module's clock generation unit, tile_pcie_crg. Simultaneously, clk_pcie, as the main clock source, further derives a divided clock, clk_pcie_div2, with a frequency of 50MHz, used to drive some of the module's internal logic units. In addition, the module includes a set of independent control clocks, pcie_ctrl_clk, with a frequency of 200MHz, used for control logic and management channel signals.

[0046] The DDR controller module enables high-speed data exchange between the on-chip system and external memory. This module receives a reference clock (clk_ref) at a frequency of 25MHz from an external crystal oscillator, directly provided by the chip's top-level port. Internally, the module uses a PLL to multiply the reference clock (clk_ref) to generate a high-speed memory clock (clk_ddr) at a frequency of 800MHz, which drives the memory control logic.

[0047] It should be noted that clock types can be divided into two categories: master clock, which refers to the clock signal defined directly on the port or signal through the create_clock command, and is used as the basic clock source for the system or module; and generated clock, which refers to the clock signal derived from the master clock through the create_generated_clock command, and is used to describe the derived clock after frequency division, multiplication, gating, or phase shifting.

[0048] By classifying clocks, the master-slave relationship and hierarchical correspondence of clocks within and across modules can be clearly defined when generating timing constraint files. This enables a unified description of the clock structure between the top level and modules, providing a standardized structural foundation for the automatic generation and attribute inheritance of subsequent timing constraint files, and ensuring the accuracy and consistency of system-level clock management.

[0049] During the design process, the Tile_PCIE design lead can provide the tile_pcie_clocks.xlsx file, which describes all the clock information within Tile_PCIE. The contents of the tile_pcie_clocks.xlsx file are shown in Table 2. Table 2 In Table 2, the reference clock `sys_pcie_clk` is defined at the module input port `clk_i`, with type `port`, and is input externally to the PCIe subsystem module. The derived clock `pcie_div2_clk` is defined at the register output pin `u_clk_div / Q`, with type `pin`, and its corresponding master clock is `pcie_sys_clk`, with a divide_by=2 frequency division relationship. In addition, this module also has an independent control clock `pcie_ctrl_clk`, defined at `u_clk_ctrl_dont_touch_buf / Z`, with type `pin`, which serves as an independent input clock signal to drive the control logic.

[0050] Referring to Table 3, the clock frequency information for some clocks under various operating conditions for the modules shown in Table 2 is as follows: Table 3 As shown in Table 3, the clock frequency remains consistent under different operating conditions. Specifically, the reference clock sys_pcie_clk operates at 100MHz under slow, typical, and fast process conditions. The control clock pcie_ctrl_clk operates at 200MHz under all process conditions.

[0051] Additionally, the Tile_ddr design lead can provide the tile_ddr_clocks.xlsx file, which describes all the clock information within the Tile_ddr. The contents of the tile_ddr_clocks.xlsx file are shown in Table 4. Table 4 In Table 4, the clock sys_ddr_ref_clk is the input reference clock for the DDR controller module. It is defined at the input port ref_clk_i, of type port, and is directly provided by the top layer of the chip. Internally, the master clock for the clock ddr_core_clk is the clock ddr_sys_ref_clk, defined at the pin u_pll / CLKOUT, of type pin, and its multiplication relative to the master clock is indicated by the configuration divide_by=32.

[0052] Referring to Table 5, the clock frequency information for some clocks under various operating conditions for the modules shown in Table 4 is as follows: Table 5 Additionally, the design lead for tile_pcie_crg can provide the tile_pcie_crg.xlsx file, which describes the generation of the internal clock in tile_ddr. The contents of this file are shown in Table 6. Table 6 Referring to Table 7, the clock frequency information for the modules shown in Table 6 under various operating conditions is as follows: Table 7 Similar to the explanations in Tables 2 and 3, the information in Tables 6 and 7 will not be repeated here. The clock description information for each module, as shown in Tables 2 to 7, clearly characterizes the definition points, hierarchical relationships, and frequency division characteristics of each clock within the module. This provides a data foundation for the subsequent parsing of module clock attribute information and the generation of cross-layer clock constraints, ensuring consistency in clock inheritance relationships between the top layer and modules, and a clear hierarchical structure.

[0053] In addition, the top-level design lead also needs to provide the association information for the clock description information of each module. For example, a YAML (Lightweight Data Description Language) file, such as instance_tile_map.yaml, can be provided to identify the correspondence between module types and their instances. This file serves as part of the clock description information for each module, establishing the association between the top-level instance and the module clock description file, facilitating the quick location of the corresponding module type based on the instance when parsing clock information.

[0054] In a YAML file, each line defines a mapping between an instance name and a module type name, in the format: ${instance_name}:${tile_name}. For example: u_tile_pcie:tile_pcie indicates that the top-level instance u_tile_pcie belongs to the module tile_pcie, that is, this instance is an instantiation unit of a PCIe subsystem module; u_tile_ddr:tile_ddr indicates that the top-level instance u_tile_ddr belongs to the module tile_ddr, that is, this instance is a DDR controller module used to manage the data interaction between the on-chip system and external memory; u_tile_pcie_crg:tile_pcie_crg indicates that the top-level instance u_tile_pcie_crg belongs to the module tile_pcie_crg, meaning that this instance is used to generate and manage the clock signals and reset logic inside the PCIe module.

[0055] This associated file enables the automatic matching of clock description information of each module based on the top-level instance name during the clock attribute parsing and constraint generation process. This achieves clock data association and hierarchical mapping between the top-level and modules, thereby ensuring the correctness and consistency of cross-level clock inheritance relationships.

[0056] For example, the module instantiation port corresponding to each top-level clock signal can be determined based on the top-level clock mapping information, and the clock description information of each module associated with the module instantiation port can be obtained.

[0057] Specifically, based on the top-level clock mapping information, the module instantiation ports connected to each top-level clock signal can be analyzed one by one, and the corresponding target module can be located according to the module instantiation port. By performing an association search on the target module, the clock description information of each module in the chip of that module instantiation port can be obtained, including the input and output clocks on the module port and their master-slave relationships. This information can reflect the hierarchical structure and inheritance logic of each clock within the module, and is an important basis for establishing the mapping relationship between the top-level and module clocks.

[0058] For example, as shown in Tables 1 and 2, the top-level clock signal pcie_sys_clk is connected to the module instantiation port clk_i. Based on this mapping, the target module u_tile_pcie can be located, allowing external input of the clock description information for each module within the target module chip. The clock description information for each module in the target module chip, such as the module instantiation port clk_i as the input clock, is of type master clock. This clock internally derives a divided clock pcie_div2_clk to drive some logic units.

[0059] Furthermore, by parsing the clock description information of each module, the module clock attribute information corresponding to the module instantiation port is extracted. The module clock attribute information is used to characterize the key features and hierarchical relationships of each clock signal within the module, including but not limited to clock period, waveform characteristics, master-slave relationship, and inheritance relationship between derived clocks.

[0060] In practical implementation, the clock description information of each module can be structured and parsed to extract clock definition items and their corresponding attribute values. For example, based on a preset data structure template (schema), module clock definition data can be read from Excel spreadsheets, XML files, or other structured clock description files, and the corresponding clock attribute information can be extracted.

[0061] For example, during the parsing process, semantic mapping and name normalization can be performed by field. For instance, ports and pins can be uniformly classified as definition points, the correspondence between instance names and module names can be established through the instance_tile_map.yaml file, and the top-level clock name mapping can be completed based on the clock_map.csv file.

[0062] Clock types and hierarchical relationships can also be identified based on field rules: when a record contains the fields master_clk, source_name, or generated=1, the clock is determined to be a generated clock; if it does not contain the above fields, it is determined to be the master clock; when a record is marked combined=1 or Is_lib_clk=1, it is identified as a combined generated clock and a library clock, respectively; combining the startpoint and startpoint_type fields, the definition point type can be distinguished, such as port, pin, or internal node of a module. For waveform and frequency-related attributes, calculations and reconstructions can be performed based on parameters such as waveform, edges, divide_by, multiply_by, invert, and edge_shift: under a specified operating condition (corner), the derived clock period is derived based on the master clock period, combined with divide_by and multiply_by, the duty cycle and edge position are determined based on edges and waveform, and the clock polarity and edge offset are corrected by invert and edge_shift.

[0063] After parsing, the final module clock attribute information is used to characterize the key features and hierarchical relationships of each clock in the module, including clock name, clock type, clock definition point and type, period and duty cycle under different operating conditions, waveform characteristics, master-slave relationship, source node information, clock domain synchronous or asynchronous relationship, and mapping relationship with the top-level clock name, etc.

[0064] This step enables structured parsing and attribute mapping of module-level clock information, ensuring accurate inheritance and reuse of module clock definitions during the generation of top-level timing constraints. This guarantees the consistency and constraint integrity of the multi-level clock system. Furthermore, the extracted module clock attribute information can be saved as an Excel spreadsheet, XML file, or other structured data file format, allowing for automatic conversion into top-level timing constraint files via scripts. This enables automated output and traceable management of constraint information.

[0065] In summary, timing constraints are automatically generated through two types of external input files (top-level clock mapping information and clock description information of each module), thereby decoupling constraint information from RTL design code. This supports automatic parsing and constraint inheritance of clock relationships for black-box modules containing encryption logic or third-party IP during system-level integration, significantly improving the scalability and automated integration capabilities of complex chip designs.

[0066] In step S130, the module clock attribute information is converted into top-level clock attribute information, and top-level timing constraints are generated based on the top-level clock attribute information.

[0067] Top-level clock attribute information refers to the data set used in the chip's top-level design to characterize the characteristics and hierarchical relationships of various clock signals. This information is typically obtained by mapping and transforming module clock attribute information and includes attributes such as clock name, definition point location, period, phase, waveform, master-slave relationship, and derivation relationship. It is used to describe the distribution path, signal transmission, and control logic relationships of the top-level clock in the system. Through top-level clock attribute information, a complete clock hierarchy model can be established at the system level, providing a data foundation for subsequent timing constraint generation.

[0068] Correspondingly, top-level timing constraints refer to constraint files generated based on top-level clock attribute information, used to guide timing analysis and static timing verification. Top-level timing constraints define the timing relationships between all master and derived clocks at the chip's top level, including period, phase, edge, synchronous / asynchronous domain partitioning, etc., and are typically represented in SDC (Synopsys Design Constraints) format. They are used to ensure that the chip meets design timing requirements during logic synthesis, placement and routing, and timing closure. SDC format files are usually written in plain text with the extension .sdc, and their content uses a Tcl (Tool Command Language)-like syntax structure, which is recognized and executed by EDA (Electronic Design Automation) tools to guide static timing analysis and physical design.

[0069] For example, the module clock attribute information includes clock type, which is used to characterize the definition method and hierarchical relationship of each clock within the module. When converting the module clock attribute information into top-level clock attribute information, a conversion rule corresponding to the clock type can be used to convert the module clock attribute information into top-level clock attribute information.

[0070] The clock types include at least the module input port clock, the module's internal master clock, and the module's internal derived clock. The module input port clock refers to the clock signal transmitted from the chip's top layer through the input port to the module's internal clock system; it typically serves as the reference or source clock for the module's internal clock architecture. The module's internal master clock is the master clock signal directly defined within the module, usually generated by a clock generation unit or PLL. The module's internal derived clock is a clock signal generated based on the master clock through methods such as frequency division, frequency multiplication, gating, or phase shifting, used to meet the operating frequency or phase requirements of different logic units.

[0071] The conversion rule corresponding to the clock type refers to using the clock type contained in the module's clock attribute information as the basis for judgment, and determining the expression method and belonging level of different clocks in the top-level clock according to their source, generation method and dependency relationship within the module.

[0072] For example, when the module clock attribute information indicates that a certain clock belongs to the module's input port clock, the conversion rule stipulates that this clock is expressed in the top-level clock attribute information by referencing or binding an existing clock source, and a top-level clock definition is generated based on the corresponding port or pin position, without introducing a new clock source or derivation relationship. As another example, when the module clock attribute information indicates that a certain clock belongs to the module's internal master clock, the conversion rule stipulates that this clock is treated as an independently generated master clock within the module, and a corresponding independent clock definition item is generated in the top-level clock attribute information. As yet another example, when the module clock attribute information indicates that a certain clock belongs to the module's internal derived clock, the conversion rule stipulates that a corresponding derived clock definition is generated in the top-level clock attribute information, preserving its derivation relationship with the corresponding master clock during the generation process, and not defining it as an independent source clock.

[0073] Based on the conversion rules corresponding to clock types, it can be ensured that the clock hierarchy, propagation path and constraint parameters between modules and the top layer are structurally consistent, thus providing basic support for the automatic generation of subsequent timing constraint files and system-level clock consistency verification.

[0074] In some example implementations, for the module input port clock, refer to Figure 2 As shown, the module clock attribute information can be converted into top-level clock attribute information according to steps S210 and S220: Step S210: Based on the clock description information of each module, determine the module input port clock corresponding to the input port of each module, and obtain the attribute parameters of the module input port clock.

[0075] For example, in the clock description information of each module, a clock definition item whose clock name is consistent with the input port of each module and whose definition point type is pin can be queried and used as the module input port clock corresponding to the input port of that module.

[0076] For example, in the module clock description file, the clock definition item that matches the module's input port name is retrieved, and the item with the definition point type of pin is further filtered to determine that the item is the clock object corresponding to the module's input port.

[0077] If a match is successful, the attribute parameters of the clock object are extracted, including but not limited to clock period, waveform, duty cycle, jitter, phase offset, clock source identifier, and frequency division factor, for subsequent attribute inheritance and unified constraint modeling of the top-level clock object with the same name.

[0078] Step S220: Assign the attribute parameters of the module input port clock to the clock object with the same name in the top-level clock attribute information.

[0079] The attribute parameters of the module input port clock obtained in step S210 are assigned to the clock object generated at the top level with the same name as the module input port clock, thus forming the corresponding top-level clock attribute information.

[0080] Specifically, the extracted clock cycle, waveform description, duty cycle, jitter, phase offset, source clock name, and frequency division factor are written into the attribute fields of the clock object with the same name to ensure that the clock object can be correctly identified and referenced in the subsequent constraint generation process.

[0081] This step ensures the consistency and compatibility of clock attributes between the top-level clock object and the module input ports, providing a unified basic clock definition for the subsequent generation of cross-level timing constraints.

[0082] Additionally, top-level clock configuration information can be obtained, which is used to define a top-level clock signal that exists independently of each module.

[0083] For example, during the design process, the top-level design lead also needs to provide a top-level clock configuration file, such as a file named top.xlsx. This file is used to centrally describe all clock signals directly driven by the top level, excluding modules (such as tiles). The contents of this file are shown in Table 8. Table 8 Referring to Table 9, the clock frequency information for various operating conditions shown in Table 8 is as follows: Table 9 By introducing top-level clock configuration information, supplementary data sources can be provided for clock attribute inheritance and timing constraint generation in scenarios where modules do not provide corresponding clock definitions or where shared clocks are used across modules, ensuring the integrity of the overall clock system and the consistency of the timing model.

[0084] Furthermore, if the clock description information of each module does not include the module input port clock corresponding to the input port of each module, as a supplementary method, a query can be made from the top-level clock configuration information for a top-level clock object whose clock name matches the input port of each module and whose definition point type is pin or port. If a match is successful, the top-level clock object can be regarded as the source of the clock definition for that input port. Subsequently, the attribute parameters of the top-level clock object are extracted, including but not limited to period, waveform, duty cycle, phase offset, etc., and the attribute parameters of the top-level clock object are inherited to obtain the top-level clock attribute information, thereby completing the clock information that is not defined on the module side for that input port.

[0085] In this way, even if the clock description information of each module is incomplete, the clock attributes can still be automatically inherited and completed by relying on the top-level configuration, ensuring the continuity and integrity of the clock definition during the constraint generation process, and avoiding the impact of local omissions on the accuracy of the overall clock model.

[0086] Additionally, if no clock object corresponding to the input port of any module is found in the clock description information and top-level clock configuration information of each module, a clock missing alarm message is output to indicate that the required clock definition for that input port does not exist. The clock missing alarm message includes the name of the missing input port and the corresponding clock mapping entry, clearly indicating the specific location and context of the missing clock, facilitating subsequent checks and supplementary configurations by designers.

[0087] This step can effectively avoid constraint generation interruptions or tool malfunctions caused by undefined critical clocks, enhancing the fault tolerance and problem traceability of the constraint generation process.

[0088] In one specific embodiment, for the mapping entries marked as tile input ports in the clock_map.csv file, the top-level attribute generation process of the module input port clock is executed.

[0089] Taking the entry `pcie_sys_clk→clk_i` as an example, firstly, the tile port name in this entry is identified as the module input port `clk_i`. A clock object with the same name, `pcie_sys_clk`, is then created in the top-level clock model. Next, the clock definition entry named `clk_i` is searched in the module clock description file (e.g., the `tile_pcie_crg` file) corresponding to this tile instance, and its definition point type is determined to be pin. If a match is found, the clock's period, waveform, duty cycle, phase offset, and other attribute parameters are extracted and assigned to the top-level clock object corresponding to `pcie_sys_clk`, completing the inheritance of top-level clock attributes.

[0090] If the clock object is not found in the module clock description file, the search continues in the top-level clock configuration file (such as top.xlsx file) for a clock object named pcie_sys_clk, defined at port or pin, defined in the top-level clock configuration file, and not appearing in the clock description information of any module. If a matching top-level clock object is found, its attribute parameters are extracted and assigned to pcie_sys_clk, thus completing the top-level clock information.

[0091] If neither of the above two information sources is matched successfully, an error message will be output, and a clock missing alarm message will be generated, which includes the missing clock name pcie_sys_clk, the corresponding tile port clk_i, and its complete mapping entry in the clock_map.csv file, so that designers can locate and correct it.

[0092] This implementation method ensures that the top-level clock corresponding to the module input port has a stable and traceable attribute inheritance mechanism in scenarios where the module definition is incomplete or shared across layers, thereby improving the consistency of system-level clock modeling and the engineering controllability of the constraint generation process.

[0093] In some example implementations, for the internal master clock of the module, refer to Figure 3 As shown, the module clock attribute information can be converted into top-level clock attribute information according to steps S310 to S330: Step S310: Based on the module clock attribute information, identify the internal master clock of the module that has not established a connection with the top layer through the module input port.

[0094] Specifically, it can iterate through all clock objects with a defined point type as the master clock in the module's clock attribute information, exclude module input port clocks that have established a top-level mapping relationship through clock_map.csv, and retain independent master clocks that are only generated within the module and not exposed to the top level as the processing target of this step.

[0095] Step S320: Under the hierarchical path at the top level of the chip, perform hierarchical mapping on the internal master clock of the module to obtain the hierarchical definition point corresponding to the internal master clock of the module.

[0096] Among them, the hierarchical definition point is used to uniquely identify the complete path expression of the internal clock of the module in the top-level structure of the chip, which is usually formed by concatenating the top-level instance path and the local clock name within the module.

[0097] For example, it is possible to obtain the top-level instance name of the module to which the internal master clock belongs, and construct a hierarchical definition point corresponding to the internal master clock of the module based on the instance name.

[0098] Specifically, the instance level name of the module instance containing the internal master clock can be obtained at the top level. The instance level name is used to identify the unique position of the module in the chip hierarchy. Then, the path is concatenated based on the instance level name and the local name of the module's internal master clock to form a hierarchical definition point that can be uniquely identified in the top-level environment.

[0099] For example, when the name of the internal master clock of a module is clk_main, and the instance path of the module at the top level is chip_top / tile_3, the hierarchical definition point constructed is chip_top / tile_3 / clk_main.

[0100] This hierarchical mapping process preserves the original naming of the master clock within the module, while also incorporating the instance path of the module in the system hierarchy. This ensures that the generated hierarchical definition points have an accurate naming context in the top-level environment, facilitating the inheritance and referencing of subsequent clock attributes and the generation of related timing constraints.

[0101] Step S330: Inherit the clock attributes of the module's internal master clock from the module clock attribute information to generate top-level clock attribute information corresponding to the hierarchical definition point.

[0102] After completing the hierarchical path mapping of the master clock within the module, attribute inheritance can be performed on the corresponding hierarchical definition points based on the master clock attribute parameters recorded in the clock description information of each module. By assigning these attribute parameters to the top-level clock object corresponding to the hierarchical definition point, the clock characteristics of the master clock within the module can be fully reproduced in the top-level environment, ensuring the consistency of the clock during timing constraint generation, clock relationship resolution, and subsequent verification.

[0103] This step enables lossless inheritance and mapping of the module's internal master clock attributes to the top-level clock system, ensuring the consistency of the module-level and system-level clock models in terms of logical semantics and parameter definitions, and providing a reliable attribute foundation for the accurate generation of top-level timing constraints.

[0104] In some example implementations, for a derived clock within the module, refer to Figure 4 As shown, the module clock attribute information can be converted into top-level clock attribute information according to steps S410 to S430: Step S410: Determine the current master clock source to which the derived clock inside the module belongs based on the module clock attribute information.

[0105] Specifically, by parsing the source clock field associated with each derived clock in the clock description information of each module, the main clock object that the derived clock inside the module depends on is identified, and the initial association between the derived clock inside the module and the current main clock source is established.

[0106] The master clock is usually defined at the module input port, but its actual clock source may be located outside the module. Therefore, the master clock source identified in the local context is only a preliminary identifier.

[0107] Step S420: Based on the top-level clock mapping information, determine the actual master clock source at the top level for the derived clock inside the module.

[0108] Based on the current master clock source name identified in step S410, the hierarchical definition point corresponding to the master clock name inside the module can be found in the set of clock objects established in the top-level environment, that is, in the top-level clock mapping file and the top-level clock mapping results generated in steps S310 to S330. This hierarchical definition point is then used as the real master clock source of the derived clock inside the module at the top level.

[0109] This real master clock source is used to replace the master clock reference in the original module, thereby ensuring that the derived clock has an accurate and unique dependency object in the top-level path, and solving the problem that the master clock defined by the internal port of the module actually points to the wrong one.

[0110] Step S430: Replace the current master clock source with the real master clock source, and complete the hierarchical path of the derived clock inside the module at the top level to generate top-level clock attribute information.

[0111] The current master clock source of the derived clock within the module is replaced with the parsed real master clock source, and the hierarchical path of the derived clock within the module at the top level is completed to form a complete top-level derived clock object. Subsequently, the derived clock attributes recorded in the module are assigned to this top-level derived clock object to generate complete top-level clock attribute information.

[0112] This example implementation enables accurate mapping and master-slave relationship correction of derived clocks within a module in the top-level environment. It ensures the establishment of correct cross-module dependency chains based on automatic completion of the definition point hierarchical path, providing a clock model with a clear structure and consistent semantics to support the generation of top-level timing constraints.

[0113] In some example implementations, module clock attribute information includes a clock name, which can be used as a unique clock identifier. In actual chip design, multiple modules may be developed by different design teams, leading to inconsistencies or overlaps in the clock names defined within them. When these modules are integrated into the top-level design, or when the internal clock attributes of modules are mapped to top-level clock objects, if clock names are not uniformly managed and conflict detected, naming conflicts may occur in timing constraint files, leading to problems such as timing tool recognition failures, constraint overriding errors, or functional misjudgments. Therefore, clock naming conflict detection and adjustment are necessary before module clock attribute information participates in top-level timing constraints or module timing constraint generation.

[0114] For example, when performing naming conflict detection on the clock names within each module, all clock names defined within each module can be obtained, including the module's main clock name and derived clock names. The clock names within that module are compared with the clock names of other modules to detect whether multiple modules use the same clock name. Simultaneously, the top-level clock names obtained by mapping the clock names within the module are compared with the top-level clock names mapped from other modules and the existing top-level global clock names to determine whether there are overlapping or duplicate mappings.

[0115] If any form of name duplication exists, it is determined to be a naming conflict, and the conflicting clock name, its module, and conflict type are recorded for subsequent name adjustment or conflict reporting processing.

[0116] If the clock names of different modules are found to be the same, or if the clock names within a module are converted to the top level and become the same as the top-level clock names, the conflicting target clock names will be adjusted according to a preset strategy.

[0117] The preset strategies may include, but are not limited to, the following methods: Add module identifier prefix: For cases where different modules have the same clock name, add the corresponding module name or instance name before the conflicting clock name, such as changing clk_ref in the tile_1 module to tile_1_clk_ref; Call the mapping file alias: Replace or unify the module clock name according to the alias rules defined in the mapping file, such as replacing clk_main with its unique alias in the global naming table; Instance name suffix differentiation: When the same module is instantiated multiple times and the same clock name exists in each instance, an instance name suffix is ​​added to the name to differentiate them. For example, clk_main is renamed to clk_main_tileA and clk_main_tileB respectively. Master-slave derivation path update: When the master clock of the derived clock has been mapped to the top level, the corresponding master clock field in the clock attribute information is replaced with the name of the top-level clock to achieve name hierarchy correspondence; Priority replacement rule: If the conflicting name already exists and is defined at the top level, the clock name defined at the top level shall be retained first, and the clock with the same name inside the module shall be forcibly adjusted to avoid the top-level timing constraint overriding the conflict.

[0118] The updated clock name will be written into the module clock attribute information and used as input data for subsequent top-level mapping and module timing constraint generation, thereby ensuring the uniqueness and consistency of the entire system clock namespace.

[0119] In addition, to prevent timing constraint generation errors due to naming anomalies, if conflicting target clocks cannot be eliminated according to the preset strategy, an error message will be output and timing constraint generation will be terminated.

[0120] Specifically, after performing naming conflict detection, if a target clock name is duplicated with other module names or top-level clock names, it will attempt to automatically adjust it using preset strategies such as adding prefixes, replacing suffixes, and using numbering to distinguish them. If all adjustment strategies still cannot guarantee name uniqueness, or if new conflicts arise after adjustment, the conflict is considered irreversible. In this case, the conflict name, its module, and path information are recorded, and an error message is output to prompt the designer to handle it manually. At the same time, the current constraint generation process is terminated to prevent abnormal generation results or tool recognition failures, ensuring the correctness and controllability of the overall constraint output.

[0121] After generating the top-level clock attribute information, the converted top-level clock attribute information can be saved to an intermediate file, such as top_clocks_info.xlsx. This file records the name, type, frequency, master-slave relationship of the top-level clock, and its mapping information to the ports of each module. By saving this intermediate file, designers can easily check and trace the clock attributes during subsequent debugging, review, or clock consistency verification.

[0122] It should be noted that saving the converted top-level clock attribute information to an intermediate file is an optional operation. It does not affect the automatic generation process of timing constraint files, but it can significantly improve the visualization and maintainability of the system during the debugging and verification phase.

[0123] Furthermore, based on the generated top-level clock attribute information, or by directly reading the top-level clock attribute information recorded in the intermediate file top_clocks_info.xlsx, the final top-level timing constraints can be automatically generated according to the SDC syntax rules, and saved as a top_clock.sdc file. This file is used to uniformly describe the clock definition, master-slave relationship, and timing boundary conditions at the chip's top level, and can fully reflect the chip's top-level clock structure and its mapping relationship with each module. The generated top-level timing constraint file can be directly applied to design stages such as logic synthesis, placement and routing, and static timing analysis, achieving semantic consistency and structural continuity between top-level and module-level timing constraints, thereby improving the completeness of the constraint system and the accuracy of design verification.

[0124] For example, when parsing the clock_map.csv file, the mapping entry pcie_sys_clk→clk_i is read, where clk_i is the module input port. According to steps S210 and S220, for the mapping of input port types, firstly, a clock record with the same name as the top-level clock and a definition point type of pin is searched in the corresponding module clock attribute information. If a match is found, the key attributes of the clock are extracted, including period, waveform, and definition point path.

[0125] Based on this, the corresponding top-level timing constraints are generated according to the SDC syntax rules, namely: create_clock -name pcie_sys_clk -period 10 -waveform {0 5} [get_pinsu_tile_pcie_crg / u_pcie_crg_div / Q] Here, name pcie_sys_clk represents the top-level clock name, period 10 represents the clock period of 10ns, waveform {0 5} represents the rising edge and falling edge at 0ns and 5ns respectively, and [get_pins u_tile_pcie_crg / u_pcie_crg_div / Q] represents the definition point of this clock as the internal pin Q of the module.

[0126] For example, when parsing the clock attribute information of the tile_pcie module, the internal clock pcie_ctrl_clk is identified as the master clock, with a period of 5ns, a waveform of {0 2.5}, and a defined point of u_clk_ctrl_dont_touch_buf / Z. Based on the module's top-level instance path, the prefix u_tile_pcie is added before the defined point, and the corresponding top-level timing constraints are generated according to the SDC syntax rules. create_clock -name pcie_ctrl_clk -period 5 -waveform {0 2.5} [get_pins u_tile_pcie / u_clk_ctrl_dont_touch_buf / Z] For example, taking the derived clock pcie_div2_clk inside the tile_pcie module as an example, its definition point is u_clk_div / Q, and its period relationship is the division of the master clock by 2. When generating the top-level timing constraints, the module prefix is ​​automatically added before the definition point according to the hierarchical instance path of the module to form a complete top-level hierarchical path [get_pins u_tile_pcie / u_clk_div / Q].

[0127] Subsequently, analysis of the derived clock's master clock attributes revealed that its master clock was defined on the module's input port, not originating from within the module itself. At this point, using the clock_map.csv file and the existing top-level clock set, the true source of the master clock at the top level was located: pcie_sys_clk. The local master clock name originally recorded in the module's clock attribute table was then replaced with this top-level clock name, thus ensuring the correct inheritance of the derivation relationship.

[0128] Finally, the corresponding top-level timing constraints are automatically generated according to the SDC syntax rules: create_generated_clock -name pcie_div2_clk [get_pins u_tile_pcie / u_clk_div / Q] -source [get_pins u_tile_pcie_crg / u_pcie_crg_div / Q] -master_clockpcie_sys_clk -divide_by 2 -add Here, name pcie_div2_clk represents the derived clock name, [get_pins u_tile_pcie / u_clk_div / Q] is the definition point path of this clock at the top level, source indicates its signal source, master_clock pcie_sys_clk specifies its parent master clock, and divide_by 2 indicates that this clock is a divide-by-two signal of the master clock.

[0129] In the example implementation of this disclosure, the top-level clock configuration information and the currently generated top-level timing constraints are merged to obtain the final top-level timing constraints. The final top-level timing constraint file fully describes the clock definition, derivation relationships, and timing boundaries of the chip's top level, and can be directly used in design stages such as logic synthesis, placement and routing, and static timing analysis.

[0130] In the process of constructing chip timing constraints, in addition to generating top-level clock attributes and constructing top-level timing constraints based on module clock attribute information, it is also necessary to generate corresponding module-level timing constraints for each module to ensure the integrity and consistency of cross-level clock relationships.

[0131] For example, the clock type and master-slave relationship of the internal clocks of each module can be determined based on the module clock attribute information. For instance, when parsing the module clock attribute information, key attribute parameters of the internal clocks of each module are extracted, including clock type, master-slave dependency relationship, and master clock association parameters of derived clocks. The master clock association parameter characterizes the inheritance relationship between the derived clock and the master clock, and corresponds to the `master` parameter in the `create_generated_clock` command when generating timing constraints, specifying the name of the master clock inherited by the derived clock.

[0132] After resolving the clock relationships within the module, the naming relationships of the master clocks within the module are calibrated based on the top-level clock mapping information. For example, the master clock names within the module are replaced with the corresponding top-level clock names, and the master clock association parameters of the derived clocks within the module are adjusted so that the master clock association parameters point to the corresponding top-level master clock.

[0133] Specifically, if the master clock defined on a module port originates from a top-level input port, the master clock name defined within the module is replaced with the corresponding top-level clock name based on the top-level clock mapping information. This mapping operation ensures that the master clock name referenced in the module's timing constraints is consistent with the top-level timing constraints, thereby guaranteeing correct matching of the top-level clock source during subsequent cross-level constraint resolution.

[0134] For derived clocks within a module, the master clock relationship pointed to by their master clock association parameters is further examined. When the clock pointed to by the master clock association parameters has been mapped to the top-level clock, the master clock association parameters in the definition of the derived clock will be automatically adjusted when generating the module timing constraints, so that they refer to the updated top-level clock name instead of the old name within the module.

[0135] This example ensures that the master-slave relationship of derived clocks is correctly passed during cross-level inheritance, avoiding constraint failures due to naming differences or hierarchical inconsistencies. If the master clock attribute of a derived clock fails to map to the top level, verification logic will be triggered to log the exception, allowing designers to manually confirm it during subsequent clock attribute review.

[0136] Finally, module timing constraints are generated based on the updated clock dependencies. That is, after adjusting the master clock and derived clock relationships, module-level SDC files are generated based on the updated clock dependencies. During the generation process, the instance path information in the module timing constraint template is simultaneously adjusted to adapt to the module's naming system within the chip hierarchy, ensuring consistency in path resolution across all constraint files. The resulting module timing constraints can not only participate in timing analysis independently but also seamlessly integrate with top-level timing constraints through the clock inheritance chain.

[0137] In some example implementations, the timing constraint generation method may include the following steps: Step 1: The top layer of the chip is divided into multiple tiles to form a layered, modular design structure: For example, multiple tiles include two key tiles, tile_pcie and tile_ddr, and the hierarchical instance names of each tile are u_tile_pcie and u_tile_ddr, respectively.

[0138] By dividing the top layer of the chip into tiles, a structural foundation is provided for subsequent clock information management and timing constraint generation.

[0139] Step 2: Provide the top-level clock mapping file: After completing the tile partitioning of the chip's top layer, a top-level clock mapping file, such as clock_map.csv, is defined to specify the correspondence between the top-level clock signals and the port instances of each tile. Additionally, a top-level clock configuration file, such as top.xlsx, is required, which defines the top-level clocks for all tiles except those for each individual tile. Finally, a YAML file, such as instance_tile_map.yaml, is also needed, where each line defines the correspondence between an instance name and a module type name.

[0140] The top-level clock-related description files, including the top-level clock mapping file, enable a unified description of the top-level clock structure and tile relationships.

[0141] Step 3: Provide a tile clock description file: Specifically, a clock description file is provided for each tile to describe the clock structure and clock generation relationship within the tile.

[0142] For example, a `tile_pcie_clocks.xlsx` file is provided for `tile_pcie` to describe all the clock information within `tile_pcie`. A `tile_ddr_clocks.xlsx` file is provided for `tile_ddr` to describe all the clock information within `tile_ddr`. A `tile_pcie_crg.xlsx` file is provided for `tile_pcie_crg` to describe the generation of the clock within `tile_ddr`. These tile clock description files are used to characterize the clock source, attributes, and generation relationships within each tile. Step 4: Parse the tile clock information and generate the top-level clock information: After obtaining the top-level clock description file and the clock description files of each tile, the tile clock information is parsed and the corresponding top-level clock information is generated.

[0143] Here, tile clock information refers to the tile clock description file, and top-level clock information refers to the top-level timing constraint file. Specifically, tile clock attribute information can be parsed from each tile clock description file, converted into top-level clock attribute information, and finally generated into the top-level timing constraint file based on the top-level clock information.

[0144] The specific implementation of this step can be referred to step S130 in other embodiments, and will not be repeated here.

[0145] This exemplary implementation combines the clock description information of each module with the top-level clock mapping information to automate the clock definition and mapping process, forming an independent and decoupled module input structure. This structure allows each module to independently execute the generation and verification process of timing constraints without integrating a complete top-level design, thereby significantly improving the parallelism and verification efficiency of module-level development.

[0146] Specifically, by introducing standardized clock description information for each module and top-level clock mapping information, accurate and complete top-level timing constraint files and timing constraint files for each module can be automatically generated without the need for manual writing of timing constraints line by line. This significantly reduces the workload and time required for manual writing and debugging of timing constraint files, and improves the automation level of timing constraint generation.

[0147] Secondly, the system automatically establishes the definition and dependency relationships between the top-level clock and the clocks of each module through preset conversion rules, so that the top-level clock and the clocks of each module are consistent in terms of naming, period, waveform and master-slave relationship, avoiding the problem of inconsistent timing constraints between the top-level and modules due to improper manual processing, such as clock naming conflicts, incorrect frequency or waveform parameters, and missing master-slave relationship of derived clocks.

[0148] Furthermore, this disclosure can fully reuse detailed clock information provided and verified by module designers, including the master clock and derived clock parameters within the module. This eliminates the need to repeatedly define the complex clock structure within the module during the generation of top-level timing constraints. Top-level designers only need to focus on the timing constraints defined on the top-level ports and critical paths, thereby improving the reusability and reliability of clock constraint information.

[0149] Furthermore, since the entire time series constraint generation process is based on an automated parsing, conversion, and generation mechanism, it reduces the risk of errors caused by human input and manual modification, and improves the reliability of the generated time series constraint files in terms of accuracy and consistency.

[0150] Meanwhile, the parsing, conversion and generation process disclosed herein can be implemented through scripting or tooling, which can greatly accelerate the chip top-level timing constraint integration process and significantly shorten the chip design cycle. In particular, it can demonstrate more significant efficiency advantages in large-scale timing constraint designs that contain a large number of modules and have complex internal clock structures.

[0151] Finally, by requiring chip design to use modules (such as tiles) as basic units and provide corresponding clock information files for each module, it is beneficial to promote the implementation of modular design processes. This enables different design teams to carry out the design and timing constraint verification of their respective modules in parallel, thereby improving overall collaborative efficiency and reducing coordination costs in the cross-module integration phase.

[0152] In the early stages of design, before physical design begins and when layout information is incomplete, traditional timing constraint generation processes that rely on physical information are often impossible to implement. This solution, however, based on a structured clock description mechanism and pre-defined mapping rules, can directly generate complete SDC files during the RTL stage. This enables logic-level timing modeling and early detection of convergence risks, bringing the timing convergence process forward to the early design phase, thereby shortening the overall design cycle and reducing later modification costs.

[0153] Furthermore, for heterogeneous chip design scenarios that integrate third-party black-box IP, this solution can complete interface clock attribute modeling without source code by forcibly defining the clock mapping relationship at the port level of the black-box IP in the top-level clock mapping information. This enables automatic identification and constraint generation of the clock of the black-box module, thereby ensuring the integrity and consistency of constraints of each clock domain in the heterogeneous system and improving the accuracy and automation of the overall timing analysis.

[0154] In a unified testing environment, comparative experiments were conducted between relevant methods and this solution. As shown in Table 10, this solution has significant advantages in terms of constraint generation speed and accuracy.

[0155] Table 10 This solution significantly improves constraint generation speed, reducing the time required by experienced engineers to weeks to within one hour, decreasing manual intervention by over 90%. It is particularly suitable for complex SoC designs with more than 50 modules. The solution also boasts excellent black-box IP compatibility. For heterogeneous modules lacking RTL source code support, it automatically generates corresponding interface-level timing constraints by declaring port clock mapping relationships in the top-level clock mapping file, meeting the timing convergence requirements of black-box modules. Furthermore, to address potential clock naming conflicts during parallel development by multiple teams, the solution introduces a naming conflict detection mechanism and automatic renaming strategy. When duplicate clock names are detected between modules or between a module and the top-level design, the module name is automatically injected as a prefix to adjust the target clock, ensuring the uniqueness of the global clock namespace. This avoids backend verification failures and repeated iterations caused by naming conflicts, improving cross-team collaboration efficiency by over 80%. In summary, this solution significantly improves the automation level and engineering stability of timing constraint generation, providing an efficient and reliable means of timing constraint integration and verification for large-scale SoC designs.

[0156] Furthermore, in an exemplary embodiment of this disclosure, a timing constraint generation system is also provided. (See reference...) Figure 5 As shown, the timing constraint generation system 500 may include a top-level information acquisition module 501, a bottom-level information parsing module 502, and a top-level constraint generation module 503, wherein: Top-level information acquisition module 501 is used to acquire the top-level clock mapping information of the chip; The underlying information parsing module 502 is used to obtain the clock description information of each module in the chip according to the top-level clock mapping information, and to parse the module clock attribute information from the clock description information of each module. The top-level constraint generation module 503 is used to convert the module clock attribute information into top-level clock attribute information and generate top-level timing constraints based on the top-level clock attribute information.

[0157] The specific details of each module in the aforementioned timing constraint generation system 500 have been described in detail in the corresponding timing constraint generation methods, so they will not be repeated here.

[0158] Exemplary embodiments of this disclosure also provide a computer-readable storage medium having a program product stored thereon capable of implementing the methods described above in this specification. In some possible embodiments, various aspects of this disclosure may also be implemented as a program product including program code that, when run on an electronic device, causes the electronic device to perform the steps described in the "Exemplary Methods" section of this specification according to the various exemplary embodiments of this disclosure. This program product may be a portable compact disc read-only memory (CD-ROM) including program code and may run on an electronic device, such as a personal computer. However, the program product of this disclosure is not limited thereto. In this document, the readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0159] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0160] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0161] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0162] Program code for performing the operations of this disclosure can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C#, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0163] Exemplary embodiments of this disclosure also provide an electronic device capable of implementing the above-described method. Referring below... Figure 6 To describe an electronic device 600 according to such an exemplary embodiment of the present disclosure. Figure 6 The electronic device 600 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments disclosed herein.

[0164] like Figure 6 As shown, the electronic device 600 can be represented as a general-purpose computing device. The components of the electronic device 600 may include, but are not limited to: at least one processing unit 610, at least one storage unit 620, a bus 630 connecting different system components (including storage unit 620 and processing unit 610), and a display unit 640.

[0165] Storage unit 620 stores program code that can be executed by processing unit 610, causing processing unit 610 to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of this disclosure. For example, processing unit 610 can execute... Figures 1 to 4 The methods and steps in the text.

[0166] Storage unit 620 may include readable media in the form of volatile storage units, such as random access memory (RAM) 621 and / or cache memory (Cache) 622, and may further include read-only memory (ROM) 623.

[0167] Storage unit 620 may also include a program / utility 624 having a set (at least one) of program modules 625, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0168] Bus 630 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0169] Electronic device 600 can also communicate with one or more external devices 700 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 600, and / or with any device that enables electronic device 600 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 650. Furthermore, electronic device 600 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 660. As shown, network adapter 660 communicates with other modules of electronic device 600 via bus 630. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 600, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0170] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the method according to the exemplary embodiments of this disclosure.

[0171] Furthermore, the above figures are merely illustrative representations of the processes included in the methods according to exemplary embodiments of this disclosure, and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0172] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0173] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and embodiments are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the claims.

[0174] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A method for generating time-series constraints, characterized in that, include: Obtain the chip's top-level clock mapping information; The clock description information of each module in the chip is obtained based on the top-level clock mapping information, and the module clock attribute information is parsed from the clock description information of each module. The module clock attribute information is converted into top-level clock attribute information, and the top-level timing constraints are generated based on the top-level clock attribute information.

2. The time-series constraint generation method according to claim 1, characterized in that, The module clock attribute information includes the clock type; The step of converting the module clock attribute information into top-level clock attribute information includes: The module clock attribute information is converted into top-level clock attribute information using a conversion rule corresponding to the clock type.

3. The time-series constraint generation method according to claim 2, characterized in that, The clock type includes the module input port clock; The step of converting the module clock attribute information into top-level clock attribute information using a conversion rule corresponding to the clock type includes: Based on the clock description information of each module, determine the module input port clock corresponding to the input port of each module, and obtain the attribute parameters of the module input port clock; The attribute parameters of the module input port clock are assigned to the clock object with the same name in the top-level clock attribute information.

4. The time-series constraint generation method according to claim 3, characterized in that, The step of determining the module input port clock corresponding to the input port of each module based on the clock description information of each module includes: In the clock description information of each module, query the module input port clock whose clock name is consistent with the input port of each module and whose defined point type is pin.

5. The time-series constraint generation method according to claim 3, characterized in that, The method further includes: If the clock description information of each module does not contain the module input port clock corresponding to the input port of each module, query the top-level clock configuration information for the top-level clock object whose clock name is consistent with the input port of each module and whose definition point type is pin or port. Inherit the attribute parameters of the top-level clock object to obtain the attribute information of the top-level clock.

6. The timing constraint generation method according to claim 3, characterized in that, The method further includes: If no clock object corresponding to the input port of each module is found in the clock description information and top-level clock configuration information of each module, an output clock missing alarm message will be issued. The clock missing alarm information includes the name of the missing input port and the corresponding clock mapping entry.

7. The time-series constraint generation method according to claim 2, characterized in that, The clock type includes the module's internal master clock; The step of converting the module clock attribute information into top-level clock attribute information using a conversion rule corresponding to the clock type includes: Based on the module clock attribute information, identify the internal master clock of the module that has not established a connection with the top layer through the module input port; Under the top-level hierarchical path of the chip, the internal master clock of the module is hierarchically mapped to obtain the hierarchical definition point corresponding to the internal master clock of the module; Inherit the clock attributes of the master clock inside the module from the module clock attribute information, and generate top-level clock attribute information corresponding to the hierarchical definition point.

8. The time-series constraint generation method according to claim 7, characterized in that, The step of performing hierarchical mapping on the internal master clock of the module to obtain hierarchical definition points corresponding to the internal master clock of the module includes: Obtain the top-level instance name of the module to which the internal master clock belongs; Based on the instance hierarchy name, construct a hierarchical definition point corresponding to the master clock inside the module.

9. The time-series constraint generation method according to claim 2, characterized in that, The clock type includes module-derived clocks; The step of converting the module clock attribute information into top-level clock attribute information using a conversion rule corresponding to the clock type includes: The current master clock source to which the derived clock within the module belongs is determined based on the module clock attribute information; Based on the top-level clock mapping information, the true master clock source at the top level of the derived clock inside the module is determined; Replace the current master clock source with the actual master clock source, and complete the hierarchical path of the derived clock within the module at the top level to generate the top-level clock attribute information.

10. The method for generating timing constraints according to any one of claims 1 to 9, characterized in that, The method further includes: Based on the module clock attribute information, determine the clock type and master-slave relationship of the internal clocks of each module; Based on the top-level clock mapping information, the master clock name within the module is replaced with the corresponding top-level clock name, and the master clock association parameters of the derived clocks within the module are adjusted so that the master clock association parameters point to the corresponding top-level master clock. Timing constraints are generated based on the updated clock association relationships.

11. The time-series constraint generation method according to any one of claims 1 to 9, characterized in that, The module clock attribute information includes the clock name, and the method further includes: Name conflict detection is performed on the clock names within each module; If the clock names of different modules are found to be the same, or if the clock names within a module are converted to the top level and become the same as the top-level clock names, the conflicting target clock names will be adjusted according to a preset strategy.

12. The time-series constraint generation method according to any one of claims 1 to 9, characterized in that, The top-level clock mapping information is used to characterize the correspondence between the top-level clock signal and the module instantiation port; The step of obtaining clock description information for each module in the chip based on the top-level clock mapping information, and parsing module clock attribute information from the clock description information of each module, includes: The module instantiation port corresponding to each top-level clock signal is determined based on the top-level clock mapping information, and the clock description information of each module associated with the module instantiation port is obtained. The clock description information of each module is parsed to extract the module clock attribute information corresponding to the instantiation port of the module.

13. The method for generating time-series constraints according to any one of claims 1 to 9, characterized in that, The method further includes: Obtain top-level clock configuration information; wherein, the top-level clock configuration information is used to define a top-level clock signal independent of each module; The top-level clock configuration information and the currently generated top-level timing constraints are combined to obtain the final top-level timing constraints.

14. A timing constraint generation system, characterized in that, include: The top-level information acquisition module is used to acquire the chip's top-level clock mapping information; The underlying information parsing module is used to obtain the clock description information of each module in the chip according to the top-level clock mapping information, and to parse the module clock attribute information from the clock description information of each module. The top-level constraint generation module is used to convert the module clock attribute information into top-level clock attribute information, and generate the top-level timing constraints based on the top-level clock attribute information.

15. An electronic device, characterized in that, include: Processing unit; as well as A storage unit for storing the executable instructions of the processing unit; The processing unit is configured to execute the timing constraint generation method of any one of claims 1 to 13 by executing the executable instructions.

16. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processing unit, it implements the timing constraint generation method according to any one of claims 1 to 13.

Images