Clock constraint file generation method and apparatus, electronic device, and medium

Abstract

This application provides a method, apparatus, electronic device, and medium for generating clock constraint files, relating to the field of chip technology. The method includes: acquiring hierarchical structure information, clock definition information, and clock connection relationships of at least one module in a chip; constructing a hierarchical tree based on the hierarchical structure information to characterize the hierarchical relationships between instances of each module, and generating matching hierarchical variables for each instance of the module according to the hierarchical tree; generating at least one clock creation command template corresponding to each module based on the clock definition information; and replacing variable placeholders in the at least one clock creation command template with variables based on the hierarchical tree, hierarchical variables, and clock connection relationships to obtain at least one clock creation command corresponding to each instance of the module, thereby generating a clock constraint file for the chip according to the at least one clock creation command. This achieves automatic generation and template reuse of clock constraints, improving generation efficiency and accuracy, and reducing manual maintenance costs.

Description

Technical Field

[0001] This application relates to the field of chip technology, and in particular to a method, apparatus, electronic device, and medium for generating clock constraint files. Background Technology

[0002] In digital chip design, the clock constraint file (SDC) is a critical input to ensure proper chip operation, with the definition of clock constraints being the most complex aspect. As chip size increases and designs become more reused, chip designs exhibit multi-level and multi-instantiation characteristics. A top-level design may contain dozens of sub-module instances, each requiring its clock path and name to vary according to its level. Simultaneously, maintaining consistency of constraints across different levels places higher demands on the flexibility and accuracy of clock constraint generation methods.

[0003] Currently, related technologies mainly use two methods to generate clock constraints: one is to manually write SDC files, where designers manually define clock constraints for each module; the other is a semi-automatic method based on Tcl scripts, which relies on simple variable passing to achieve a small amount of constraint reuse, but the clock definition still needs to be written specifically for each level.

[0004] However, existing technologies have obvious drawbacks: manual writing is inefficient and prone to errors, and maintenance costs are huge when chip design changes occur; semi-automated scripts lack a global awareness of the chip hierarchy, cannot automatically handle cross-module clock correlations, and lack template capabilities, so manual intervention is still required in some cases. Summary of the Invention

[0005] This application provides a clock constraint file generation method, apparatus, electronic device, and medium to at least solve the problems of low efficiency in clock constraint file generation, inability to automatically perceive hierarchical structure, difficulty in handling cross-module clock associations, and lack of templated reuse capabilities in related technologies.

[0006] The first aspect of this application proposes a method for generating clock constraint files. The method includes: acquiring hierarchical structure information, clock definition information, and clock connection relationships of at least one module in a chip, wherein the clock connection relationships characterize clock transmission paths between different modules; constructing a hierarchical tree based on the hierarchical structure information to characterize the hierarchical relationships between at least one module instance, thereby generating matching hierarchical variables for at least one module instance according to the hierarchical tree, wherein the at least one module instance is obtained by instantiating at least one module; generating at least one clock creation command template corresponding to each module in the at least one module based on the clock definition information, wherein the at least one clock creation command template includes variable placeholders corresponding to the hierarchical variables; and performing variable replacement on the variable placeholders in the at least one clock creation command template based on the hierarchical tree, hierarchical variables, and clock connection relationships to obtain at least one clock creation command corresponding to each module instance in the at least one module instance, thereby generating a clock constraint file for the chip according to the at least one clock creation instruction.

[0007] In some embodiments of this application, the hierarchical variables include hierarchical path variables and clock prefix variables. Generating matching hierarchical variables for at least one module instance based on the hierarchical tree includes: determining the first hierarchical depth of the first module instance based on the hierarchical tree, wherein the first module instance is any module instance among at least one module instance; and generating the hierarchical path variables and clock prefix variables corresponding to the first module instance based on the first hierarchical depth.

[0008] In some embodiments of this application, at least one clock creation command template includes a master clock creation command template and a generated clock creation command template. Based on clock definition information, generating at least one clock creation command template corresponding to each module in at least one module includes: determining the clock type of the clock contained in the first module based on the clock definition information, wherein the first module is any module in at least one module, and the clock type includes master clock and generated clock; using initial hierarchical variables as variable placeholders for the clock creation command template, constructing the master clock creation command template corresponding to the master clock, and / or the generated clock creation command template corresponding to the generated clock, wherein the initial hierarchical variables are fixed placeholders used to replace hierarchical variables.

[0009] In some embodiments of this application, constructing a hierarchical tree to characterize the hierarchical relationship between at least one module instance based on hierarchical structure information includes: determining the parent-child relationship between at least one module and the instantiation parameters corresponding to at least one module based on hierarchical structure information; determining at least one module instance corresponding to at least one module based on the instantiation parameters; determining the root node and child nodes corresponding to at least one module instance based on the parent-child relationship; and constructing the hierarchical tree based on the root node and child nodes.

[0010] In some embodiments of this application, based on the hierarchical tree, hierarchical variables, and clock connection relationships, variable replacement is performed on variable placeholders in at least one clock creation command template to obtain at least one clock creation command corresponding to each module instance in at least one module instance. This includes: determining the second hierarchical path value and the second preset clock prefix value of the second module instance based on the hierarchical tree, and generating a hierarchical variable assignment instruction for the second module instance based on the second hierarchical path value and the second preset clock prefix value, wherein the second module instance is any module instance in at least one module instance; determining at least one second clock creation command template corresponding to the second module instance in at least one clock creation command template; performing variable replacement on variable placeholders in at least one second clock creation command template using the hierarchical variables of the second module instance, and integrating the hierarchical variable assignment instructions to obtain at least one second initial clock creation command; and updating at least one second initial clock creation command based on clock connection relationships to obtain at least one second clock creation command.

[0011] In some embodiments of this application, updating at least one second initial clock creation command based on clock connection relationships to obtain at least one second clock creation command includes: determining whether the at least one second initial clock creation command includes a generated clock creation command with cross-module clock connection relationships based on clock connection relationships; if the at least one second initial clock creation command includes a generated clock creation command, performing source clock variable replacement on the generated clock creation command in the at least one second initial clock creation command based on clock connection relationships to obtain at least one second clock creation command; if the at least one second initial clock creation command does not include a generated clock creation command, determining the at least one second initial clock creation command as at least one second clock creation command.

[0012] In some embodiments of this application, based on clock connection relationships, performing source clock variable replacement on the generating clock creation command in at least one second initial clock creation command to obtain at least one second clock creation command includes: determining a source module instance that has a cross-module clock connection relationship with the second module instance based on clock connection relationships; determining a source clock variable replacement strategy based on the instance number mapping relationship between the second module instance and the source module instance; and performing source clock variable replacement on the generating clock creation command according to the source clock variable replacement strategy to obtain at least one second clock creation command.

[0013] A second aspect of this application provides a clock constraint file generation apparatus, the apparatus comprising: The acquisition unit is used to acquire the hierarchical structure information, clock definition information and clock connection relationship of at least one module in the chip. The clock connection relationship is used to characterize the clock transmission path between different modules. A building unit is used to construct a hierarchical tree based on hierarchical structure information to represent the hierarchical relationship between at least one module instance, so as to generate matching hierarchical variables for at least one module instance according to the hierarchical tree, wherein at least one module instance is obtained by instantiating at least one module. The generation unit is used to generate at least one clock creation command template corresponding to each module in at least one module based on clock definition information. The at least one clock creation command template includes variable placeholders corresponding to hierarchical variables. The replacement unit is used to replace variable placeholders in at least one clock creation command template based on the hierarchical tree, hierarchical variables and clock connection relationships, to obtain at least one clock creation command corresponding to each module instance in at least one module instance, so as to generate the chip's clock constraint file according to at least one clock creation instruction.

[0014] A third aspect of this application provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the methods described in the first aspect of this application.

[0015] A fourth aspect of this application provides a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to perform the methods described in the first aspect of this application.

[0016] In summary, the clock constraint file generation method proposed in this application obtains the hierarchical structure information, clock definition information, and clock connection relationships of at least one module in the chip. A hierarchical tree representing the hierarchical relationships between at least one module instance is constructed. Matching hierarchical variables are generated for at least one module instance based on the hierarchical tree. Simultaneously, at least one clock creation command template corresponding to each module is generated based on the clock definition information. Finally, variable placeholders in the at least one clock creation command template are replaced according to the hierarchical tree, hierarchical variables, and clock connection relationships to generate at least one clock creation command corresponding to each module instance, thus obtaining the chip's clock constraint file. This method automatically perceives the hierarchical structure of the chip design, generates matching hierarchical variables for each module instance, achieves "one-time definition, multiple reuse" of clock constraints through a template mechanism, and automatically completes variable replacement for cross-module clock associations based on clock connection relationships. This effectively improves the generation efficiency and accuracy of clock constraint files and reduces manual writing and maintenance costs.

[0017] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application, and do not constitute an undue limitation of this application.

[0019] Figure 1 A flowchart illustrating the first clock constraint file generation method provided in this application embodiment; Figure 2 A flowchart illustrating the second clock constraint file generation method provided in this application embodiment; Figure 3 A flowchart illustrating the third clock constraint file generation method provided in this application embodiment; Figure 4 A flowchart illustrating the generation of a specific clock constraint file is provided for an embodiment of this application; Figure 5 A schematic diagram of a clock constraint file generation device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0020] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0021] In modern digital chip design, timing constraints (SDC files) are crucial information for ensuring proper chip operation. Among these, clock constraints (including the master clock and the generated clock) are the most complex to define. With increasing chip size and design reuse (IP reuse), designs exhibit multi-level and multi-instantiation characteristics. A top-level design may contain dozens of sub-module instances, and the clock name, clock source path, and root path of the generated clock for each instance need to be modified according to its level, while maintaining consistency of constraints across different levels. Furthermore, clock naming conventions and partitioning methods may vary between different projects or versions, requiring a high degree of flexibility in constraint generation.

[0022] Currently, two main methods are used to generate clock constraints in related technologies: First, manually writing SDC files. Designers use text editors to manually write clock definitions and timing exceptions for each design module based on the design document. For projects with many modules and complex hierarchical structures, this requires a significant amount of manual work and alignment of information between different levels. Second, using Tcl scripts for semi-automated integration. Parent modules can directly call some constraints from child modules through Tcl variables, but this is generally limited to simple constraints such as timing exceptions (e.g., false path, multi-cycle path). Clock definitions still need to be written specifically for each level.

[0023] However, the relevant technologies have significant drawbacks: First, manual coding is extremely inefficient and prone to human error (such as omissions or incorrect path spelling), especially when dealing with a large number of similar module instances. Maintenance costs are enormous when the design changes (such as instance name modifications or hierarchy adjustments). Second, while semi-automated methods such as Tcl script control are an improvement over purely manual coding, they still suffer from the following problems: 1) Lack of awareness of hierarchical information: Designers of lower-level modules lack visibility into the instantiation paths and global clock architecture of upper layers. This information asymmetry often results in clock definitions within modules not being directly used for top-level integration, requiring manual conversion and alignment from local to global definitions. For complex hierarchical structures, variable mismatches can easily lead to the generation of incorrect commands.

[0024] 2) Difficulty in cross-module clock correlation: When the master clock that generates the clock is integrated across boundaries, cross-module clock correlation cannot be automatically established, and manual integration by designers is still required. Manual intervention is not only prone to human error, but may also lead to design reuse, requiring repeated information alignment during later maintenance.

[0025] 3) Lack of template capability: Semi-automated methods such as Tcl script control still require a certain degree of manual work, lack modular abstraction capabilities, and cannot achieve true "define once, reuse everywhere".

[0026] To address the aforementioned issues, this application proposes a clock constraint file generation method. By acquiring the hierarchical structure information, clock definition information, and clock connection relationship information between at least one module in the chip, the method first constructs a hierarchical tree representing the hierarchical relationships between module instances based on the hierarchical structure information, and then generates matching hierarchical variables for each module instance according to the hierarchical tree. Simultaneously, based on the clock definition information, a clock creation command template containing placeholders for corresponding hierarchical variables is generated for each module. Then, based on the hierarchical tree, hierarchical variables, and clock connection relationships, the placeholders in the clock creation command template are replaced to generate a complete clock creation command for each module instance, ultimately resulting in the chip's clock constraint file. This method automatically perceives the hierarchical structure of the chip design, generates matching hierarchical variables for each module instance, achieves "one-time definition, multiple reuse" of clock constraints through a template mechanism, and automatically completes variable replacement for cross-module clock associations based on clock connection relationships. This effectively improves the generation efficiency and accuracy of clock constraint files and reduces manual writing and maintenance costs.

[0027] The method for generating clock constraint files provided in this application will be described in detail below with reference to the accompanying drawings.

[0028] Figure 1 This is a flowchart illustrating the first clock constraint file generation method provided in this application embodiment. Figure 1 As shown, the clock constraint file generation method includes steps 101-104.

[0029] Step 101: Obtain the hierarchical structure information, clock definition information, and clock connection relationship of at least one module in the chip.

[0030] In the embodiments of this application, a module refers to a hardware design unit with independent functions in a chip, such as a PLL (phase-locked loop) clock module, a UART (universal asynchronous transceiver) serial port module, etc., and a module definition can be instantiated multiple times.

[0031] Hierarchical structure information is used to describe the hierarchical relationships between modules (including top-level modules and sub-modules) in chip design, the number of instantiations of each module, instance naming rules, and other information; clock definition information is used to describe what clocks (master clock or generator clock) are inside each module, the clock period, waveform, frequency division / multiplication factor, and other parameters; clock connection relationship is used to describe the clock transmission path between different modules, that is, a certain clock of a certain module is connected to a certain port of a certain module.

[0032] This application supports defining the chip's hierarchical structure information, the clock definition information of each module, and the clock connection relationships between modules through configuration files in various formats. Configuration files include, but are not limited to, Excel files, or other structured text formats such as YAML or JSON. This application uses an Excel spreadsheet file as an example. This application configures three worksheets for each module: the HIER table stores the hierarchical structure information, the CLK table stores the clock definition information of each module, and the INTG table stores the clock connection relationships between modules.

[0033] After the designers fill in the information according to the preset format, they use an Excel configuration parser to read and load this data for generating the clock creation command.

[0034] Step 102: Based on the hierarchical structure information, construct a hierarchical tree to represent the hierarchical relationship between at least one module instance, so as to generate matching hierarchical variables for at least one module instance according to the hierarchical tree.

[0035] In the embodiments of this application, a module instance is an entity unit with an independent hierarchical path and independent circuit node formed by instantiating and calling a functional module in the top-level design of the chip design. The same functional module can be instantiated multiple times to generate multiple independent module instances, each module instance having its own exclusive hierarchical path and timing constraint configuration requirements. Among them, at least one module instance is obtained by instantiating at least one module.

[0036] A hierarchical tree is a tree-like data structure used to represent the parent-child hierarchical relationship between instances of modules. The root node represents the top-level module, and the child nodes represent the instantiated child modules.

[0037] Optionally, this application may construct a hierarchical tree based on the hierarchical structure information of each module, that is, based on the hierarchical structure information, determine the parent-child relationship between at least one module and the instantiation parameters corresponding to at least one module; based on the instantiation parameters, determine at least one module instance corresponding to at least one module; based on the parent-child relationship, determine the root node and child nodes corresponding to at least one module instance; and construct a hierarchical tree based on the root node and child nodes.

[0038] The hierarchical structure information of each module (recorded in the HIER table) is divided into two main parts: BLOCK and MODULE. The BLOCK part records the module name of the current layer module, while the MODULE part records the submodule information of the current module, including module name (submodule name), instance name (instance name template), ins num (number of instances), prefix (prefix template), and var loop (for loop parameter configuration). Based on the above information, the parent-child relationship between modules is analyzed, a unique internal identifier is assigned to each module instance (even multiple module instances of the same module), and a tree structure (tree_hier_struc) and parent-child relationship mapping (parent_ref, children_ref) are constructed.

[0039] Hierarchical variables are placeholders generated for each module instance, including hierarchical path variables and clock prefix variables. They are used to represent the physical hierarchical path and clock name prefix of the module instance in the clock creation command template. By traversing the hierarchy tree, corresponding hierarchical path variables and clock prefix variables are generated for each module instance based on its depth in the hierarchy tree.

[0040] Step 103: Based on the clock definition information, generate at least one clock creation command template corresponding to each module in at least one module.

[0041] In the embodiments of this application, the clock creation command template is a standardized SDC command framework generated on a module-by-module basis. It does not include specific instance paths, but only retains fixed parameters and general variable placeholders. At least one clock creation command template includes variable placeholders corresponding to hierarchical variables. These placeholders are reserved variable slots in the template, used to later replace the hierarchical variables of the module instance, including hierarchical path variables and clock prefix variables.

[0042] Optionally, at least one clock creation command template includes a master clock creation command template and a generator clock creation command template. The master clock creation command template is a pre-built clock creation command template conforming to SDC syntax for the master clock, used to generate chip reference clock constraint commands. The generator clock creation command template is a pre-built clock creation command template conforming to SDC syntax for the generator clock, used to generate derived clock constraint commands, and reserves cross-module source clock placeholders to adapt to frequency division, frequency multiplication, and cross-module clock transfer scenarios.

[0043] By reading the clock definition information of the module, a fixed SDC command skeleton is built according to the clock parameters. The actual physical path and clock prefix information of each module instance are replaced with general variable placeholders to generate a modular clock command template.

[0044] Step 104: Based on the hierarchical tree, hierarchical variables and clock connection relationships, the variable placeholders in at least one clock creation command template are replaced to obtain at least one clock creation command corresponding to each module instance in at least one module instance, so as to generate the chip's clock constraint file according to at least one clock creation instruction.

[0045] In the embodiments of this application, variable replacement is the process of replacing the corresponding variable placeholders in the clock creation command template with the hierarchical path variables and clock prefix variables of the module instance.

[0046] Specifically, by traversing each module instance in the hierarchy tree, for each module instance, the actual hierarchical path value and actual clock prefix value of the instance are first obtained, and a hierarchical variable assignment instruction is generated based on the actual hierarchical path value and actual clock prefix value; then, the clock creation command template of the module type to which the module instance belongs is retrieved; the variable placeholders in the template are replaced with the hierarchical variables of the module instance, and the clock creation command template containing the replaced hierarchical variable placeholders is integrated with the hierarchical variable assignment instruction to obtain a complete initial clock creation command; then, based on the clock connection relationship (INTG table), it is determined whether the command needs cross-module integration correction. If so, the -source (used to define the source clock pin or port for generating the clock) and -master (used to define the source clock name for generating the clock) placeholders in the command line are replaced with the actual root path and clock name of the source module instance; finally, all the generated complete clock creation commands are written to the SDC file, which can be directly read and executed by EDA tools.

[0047] Optionally, the clock constraint file includes at least one of a clock creation command and a clock group setting command. The clock creation command includes a master clock creation command and a generate clock creation command.

[0048] In summary, the clock constraint file generation method provided in this application obtains the hierarchical structure information, clock definition information, and clock connection relationships of at least one module in the chip; based on the hierarchical structure information, a hierarchical tree is constructed to represent the hierarchical relationship between at least one module instance, and matching hierarchical variables are generated for at least one module instance according to the hierarchical tree; based on the clock definition information, at least one clock creation command template corresponding to each module in at least one module is generated; based on the hierarchical tree, hierarchical variables, and clock connection relationships, variable placeholders in at least one clock creation command template are replaced to obtain at least one clock creation command corresponding to each module instance in at least one module instance, so as to generate the chip's clock constraint file according to at least one clock creation instruction. This achieves automatic perception of the chip design's hierarchical structure, generates matching hierarchical variables for each module instance, realizes "one-time definition, multiple reuse" of clock constraints through a template mechanism, and automatically completes variable replacement for cross-module clock associations based on clock connection relationships, thereby effectively improving the generation efficiency and accuracy of clock constraint files and reducing manual writing and maintenance costs.

[0049] Figure 2 This is a flowchart illustrating a second clock constraint file generation method provided in an embodiment of this application. Figure 2 based on Figure 1 The illustrated embodiment further defines steps 102 and 103. Figure 2 In the illustrated embodiment, step 102 includes steps 201 and 202, and step 103 includes steps 203 and 204. For example... Figure 2 As shown, the method includes the following steps: Step 201: Determine the first level depth of the first module instance based on the hierarchical tree.

[0050] In the embodiments of this application, the first module instance is any one of at least one module instance.

[0051] The nesting depth is the number of nested levels of a module instance in the hierarchy tree. Starting from the top-level module, the nesting depth of the top-level module is 0, the nesting depth of its direct child modules is 1, and so on down the hierarchy tree. The nesting depth is used to standardize the naming format of subsequent level variables and assign standardized variable identifiers to module instances at different depths.

[0052] Specifically, the get_top_down_hierarchy_info method is called to traverse the constructed hierarchical tree from top to bottom; starting from the top root node, all child nodes are traversed layer by layer to identify the hierarchical tree position of any selected first module instance and determine the first level depth corresponding to the first module instance.

[0053] Step 202: Based on the first level depth, generate the level path variable and clock prefix variable corresponding to the first module instance.

[0054] In the embodiments of this application, based on the hierarchical depth of the module instance, a preset variable generation rule is matched to generate hierarchical path variables and clock prefix variables with a uniform format for modules of different depths.

[0055] Hierarchical path variables are placeholder combinations used to represent the physical path of a module instance. For example, ${sub1_hier}${sub2_hier} indicates that the module instance is located at the third level (i.e., the second-level submodule of the top-level module, since the top-level module itself does not need to instantiate a path). When generating the final clock creation command, the fixed variable placeholders (such as variable placeholders with the word ${HIER}) in the clock creation command template corresponding to the module instance are replaced with the variable combination of the hierarchical path variables ${sub1_hier}${sub2_hier}...${subn_hier}, resulting in a clock creation command containing hierarchical path variable placeholders. Simultaneously, corresponding variable assignment instructions (e.g., set subn_hier xxx) are generated. During the execution of the SDC file, the Tcl interpreter replaces these variables with the actual path values, thus obtaining the complete physical path. Hierarchical path variables are stored through the hier_var attribute. Specifically, the system constructs a data block for each module (or module instance) to store various information of the module in the form of a hash table, where hier_var is a key name in the hash table and its corresponding value is the combination of hierarchical path variables of the module instance.

[0056] Clock prefix variables are placeholder combinations used to represent the prefix of a module instance's clock name. For example, ${prefix1}${prefix2} represents the prefix variable combination required by the module instance when generating clock names. When generating the final clock creation command, the fixed variable placeholders in the corresponding clock creation command template for the module instance (such as variable placeholders with the word ${PRE}) are replaced with the variable combinations of clock prefix variables ${prefix1}${prefix2}...${prefixn}, resulting in a clock creation command containing clock prefix variable placeholders. Simultaneously, corresponding variable assignment instructions (such as `set prefixn xxx`) are generated. During the execution of the SDC file, the Tcl interpreter replaces these variables with actual prefix values ​​(such as prefixes converted from instance names or user-defined prefixes), ultimately concatenating them to form the unified prefix part of all clock names within the module. Similarly, clock prefix variables are stored through the `prefix_var` attribute. `prefix_var` is a key name in a hash table, and its corresponding value is the clock prefix variable combination for the module instance.

[0057] Specifically, based on the hierarchical depth of the first module instance, the combination of hierarchical path variables and clock prefix variables is determined. For example, when the depth is 1, the generated hierarchical path variable is ${sub1_hier} and the generated clock prefix variable is ${prefix1}; when the depth is 2, the generated hierarchical path variable is ${sub1_hier}${sub2_hier} and the generated clock prefix variable is ${prefix1}${prefix2}, and so on.

[0058] Additionally, it should be noted that during subsequent variable replacement, for modules with configured for loop fields (i.e., the var_loop field in the HIER table is configured with loop variables (such as {0,3,i})), the expand_template_string method is called to expand the module instance based on the Cartesian product algorithm, generating a specific list of instance names and a list of prefix names.

[0059] Step 203: Based on the clock definition information, determine the clock type of the clocks contained in the first module.

[0060] In embodiments of this application, the first module is any one of at least one modules. The clock type includes a master clock and a generated clock.

[0061] Clock definition information is configured in the CLK table, which contains the following fields: clock: The name of the clock, which can contain variables (such as ${var}) or be named directly; root: Clock root node, supports port or pin, can contain loop variables (such as $i, $j, which must be consistent with the variable names in the for loop configuration); type: Clock type, c indicates master clock, g indicates generator clock; master: The name of the master clock on which the generated clock depends (only required for generating clocks); master source: The master clock source pin or port for generating the clock (only required for generating the clock); waveform: Clock waveform, such as {0 5}, used to define the duty cycle of the master clock; period: clock cycle (required for the master clock). div(multi): The division or multiplication factor for generating the clock. It supports *N to represent multiplication, / N to represent division, and 1 to represent combinational logic clock. custom: Custom options, such as -edges, -comment, etc.

[0062] for loop: Loop variable definition, supports multi-level loops, each loop level is separated by {} (e.g., two loops {1,8,2,i}{1,5,1,j}). This application will automatically expand this loop configuration into nested Tcl for loop statements and automatically generate the corresponding loop body command line, thereby realizing the automatic expansion of the loop variable and batch generating multiple clock creation commands.

[0063] This application uses the parse_clock method to read the type field in the CLK table configured in the first module to determine the clock type of the clocks contained in the first module. If the type field is c (type='c'), it means that the clock type is a master clock; if the type field is g (type='g'), it means that the clock type is a generator clock.

[0064] Step 204: Use the initial hierarchical variables as variable placeholders for the clock creation command template to construct the master clock creation command template corresponding to the master clock, and / or the generated clock creation command template corresponding to the generated clock.

[0065] In the embodiments of this application, the initial hierarchical variables are fixed placeholders used to be replaced with hierarchical variables later. That is, they are placeholders with specific meanings temporarily used in the clock creation command template (such as ${HIER} representing the hierarchical path and ${PRE} representing the clock prefix). During the variable replacement phase, the system will replace these fixed placeholders with the corresponding combinations of hierarchical variables (such as ${sub1_hier}${sub2_hier}...) according to the hierarchical depth of the module instance, and generate the corresponding Tcl variable assignment statements. Finally, when the SDC file is executed, it is resolved into the actual path and prefix value.

[0066] Based on the clock type contained in the first module, the clock generation command line is determined. Initial hierarchical variables (including initial hierarchical path variables, such as ${HIER}, and initial clock prefix variables, such as ${PRE}) are used as variable placeholders in the clock generation command line. Additionally, key fields in the clock definition information (CLK table) (such as clock, root, master, etc.) support variable placeholders in the form of $var or ${var}, thereby generating corresponding clock creation command templates. The variable placeholders in the templates will subsequently be dynamically expanded into combinations of hierarchical variables of the module instance based on the module instance's hierarchical depth in the hierarchy tree.

[0067] Specifically, for the master clock, the template uses ${HIER} as a fixed path variable placeholder (for the root field) and ${PRE} as a fixed prefix variable placeholder (for the clock field). For the generated clock, the template uses ${HIER} as a hierarchical path variable placeholder (for the root and master_source fields) and ${PRE} as a clock name prefix variable placeholder (for the clock field).

[0068] Furthermore, this application supports defining loop variables via the `for loop` field. The syntax supports numeric ranges (e.g., `{1,10,2,i}`, representing a step size of 2 from 1 to 10; if the step size is not specified, it defaults to 1, and the variable name is `i`) or enumerated lists (e.g., `{a,b,c,var}`). The configuration is parsed using the `parse_brace_string` method to extract the loop variable name and its value range, generating the internal structure. The `check_loop_var_exist` method verifies whether the loop variable is correctly referenced in fields such as clock name and root path, ensuring that variable references in the expanded loop command are legal and semantically correct at the Tcl syntax level.

[0069] Additionally, when constructing the clock creation command line, the clock source type is determined by parsing the CLK table and analyzing the format of the root field: if it contains a backslash " / " but does not begin or end with a backslash " / ", it is identified as a pin type; otherwise, it is a port type. The `get_pins` or `get_ports` methods are used to retrieve the object during the clock creation command line construction.

[0070] The command line generation process generates a loop body command line based on the loop configuration parameters, automatically handles nested scenarios with multiple loop variables, and has a built-in variable name conflict detection mechanism (such as automatically renaming the inner conflicting variable when duplicate loop variable names are detected at different levels in the same large loop body, and synchronously updating the reference to the variable in the template field) to achieve one-time definition and automatic instantiation.

[0071] In summary, this application determines the module hierarchy depth by traversing the hierarchy tree and automatically generates standardized hierarchy path variables and clock prefix variables based on the depth, ensuring clock path and naming conventions across multiple instances and levels. It utilizes structured configuration files such as Excel to parse module clock definitions, accurately distinguishing between the master clock and generated clocks. By combining variable referencing, loop expansion, variable conflict detection, and port pin identification, reusable master clock templates and generated clock templates are constructed. This application templates and abstracts clock constraint rules, eliminating the need for manual writing of commands for each instance. A single configuration allows for the automatic batch generation of numerous clock constraint commands, solving problems such as high redundancy, high error rate, poor adaptability, and excessive manual intervention associated with traditional methods. This significantly improves the automated generation capability, versatility, and maintainability of clock constraint files for complex multi-level and multi-instance chips.

[0072] Figure 3 This is a flowchart illustrating the third clock constraint file generation method provided in this application embodiment. Figure 3 based on Figure 1 The illustrated embodiment further defines step 104. Figure 3 In the illustrated embodiment, step 104 includes steps 301, 302, 303, and 304. For example... Figure 3 As shown, the method includes the following steps: Step 301: Based on the hierarchy tree, determine the second-level path value and the second preset clock prefix value of the second module instance, and generate the hierarchy variable assignment instruction of the second module instance based on the second-level path value and the second preset clock prefix value.

[0073] In the embodiments of this application, the second module instance is any module instance among at least one module instance; the second level path value is the actual physical path string of the second module instance in the top layer of the chip; the second preset clock prefix value is the actual clock name prefix string corresponding to the second module instance (such as a prefix converted from the module instance name or a user-defined prefix).

[0074] Hierarchical variable assignment instructions are Tcl statements used to assign actual values ​​to variable placeholders at each level. Specifically, based on the hierarchical depth of the module instance, a corresponding set assignment instruction is generated for each level, assigning the hierarchical variable placeholders (such as sub1_hier, sub2_hier, prefix1, prefix2, etc.) to the corresponding actual path segments and actual prefix segments.

[0075] Based on the hierarchical tree constructed from the parsed hierarchical structure information, each module instance is traversed level by level from the root node. For the currently traversed second module instance, the existing path is inherited from its parent node and concatenated with the instance name of the second module instance to obtain the second-level path value of that instance. Simultaneously, based on the instance name corresponding to the second module instance and the current value of the loop variable (if there are multiple module instances), a second preset clock prefix value for that instance is generated. Based on the second-level path value and the second preset clock prefix value, hierarchical variable assignment instructions are generated for the second module instance. These assignment instructions are written into the final SDC file. When the SDC file is executed, the Tcl interpreter replaces the variables in the clock creation command with the actual path value and prefix value of the module instance.

[0076] Step 302: Determine at least one second clock creation command template corresponding to the second module instance in at least one clock creation command template.

[0077] In the embodiments of this application, the second clock creation command template is a clock template object of the module type to which the second module instance belongs, including the main clock creation command template and / or the generated clock creation command template.

[0078] Since all module instances of the same module type share the same set of templates, this application retrieves a list of pre-generated clock creation command templates for that module type based on the module type of the module instance, rather than creating a new template for each module instance individually. This achieves "define once, reuse everywhere".

[0079] Step 303: Use the hierarchical variables of the second module instance to replace the variable placeholders in at least one second clock creation command template, and integrate the hierarchical variable assignment instructions to obtain at least one second initial clock creation command.

[0080] In the embodiments of this application, after determining the clock creation command template (including the main clock creation command template and / or the generated clock creation command template) corresponding to the second module instance, the variable placeholders in the template are replaced with the hierarchical path variables and clock prefix variables of the second module instance to obtain the clock creation command after variable expansion. This clock creation command is then integrated with the hierarchical variable assignment instructions to obtain the initial clock creation command of the second module instance (i.e., the second initial clock creation command). The second initial clock creation command includes the initial main clock creation command and / or the initial generated clock creation command.

[0081] If the initial clock creation command contains a generated clock creation command that requires cross-module integration (i.e., when the master clock source relied upon by a generated clock within a module is not within that module but comes from the output clock of another module, then this cross-module clock association needs to be automatically established, and the generated clock creation command needs to be corrected to establish the cross-module clock chain), then the -master and -source in the generated clock creation command line will be specially handled during the clock creation command template construction stage. Specifically, they will be used as placeholders, with the format being -master $NAME_<clock_name> _master and -source $HIER_<clock_name> _master, where<clock_name> This is the current clock name, with NAME_ and HIER_ being fixed prefixes. When performing variable substitution, these variables are replaced with the complete clock name and root path of the source clock.

[0082] Step 304: Based on the clock connection relationship, update at least one second initial clock creation command to obtain at least one second clock creation command.

[0083] In the embodiments of this application, the clock connection relationship is defined by the inter-module clock transfer path through the INTG table. Each row in the table defines a clock (srcclock) from a certain instance (src instance) of the source module (src block) connected to a certain port (port) of a certain instance (sink instance) of the target module (sink block). For the clock creation command with cross-module clock connection relationships, the -master and -source placeholders in the command line are replaced with the root path and clock name of the actual clock of the source module instance to obtain a complete and accurate clock creation command.

[0084] Optionally, updating at least one second initial clock creation command based on clock connection relationships to obtain at least one second clock creation command includes: determining whether the at least one second initial clock creation command includes a generated clock creation command with cross-module clock connection relationships based on clock connection relationships; if the at least one second initial clock creation command includes a generated clock creation command, performing source clock variable replacement on the generated clock creation command in the at least one second initial clock creation command based on clock connection relationships to obtain at least one second clock creation command; if the at least one second initial clock creation command does not include a generated clock creation command, determining the at least one second initial clock creation command as at least one second clock creation command.

[0085] Specifically, the `parse_intg` method reads the `INTG` table, parses the clock connection relationships (dictionary `self.intg_sink_to_src`), and when generating a clock creation command, it first checks if the `mst_name_var` and `mst_hier_var` fields exist in the dictionary of the current generated clock. If they do not exist, it is determined that the generated clock does not need to perform cross-module integration processing, that is, it is determined that at least one second initial clock creation command does not include a generated clock creation command with cross-module clock connection relationships, and in this case, the initial clock creation command is determined to be the final clock creation command. If they exist, it is determined that the generated clock needs to perform cross-module integration processing, that is, it is determined that at least one second initial clock creation command includes a generated clock creation command with cross-module clock connection relationships. In this case, the `-master` and `-source` in the generated clock creation command line need to be replaced with source clock variables to obtain the final clock creation command.

[0086] Optionally, based on clock connection relationships, performing source clock variable replacement on the generating clock creation command in at least one second initial clock creation command to obtain at least one second clock creation command includes: determining a source module instance that has a cross-module clock connection relationship with the second module instance based on clock connection relationships; determining a source clock variable replacement strategy based on the instance number mapping relationship between the second module instance and the source module instance; and performing source clock variable replacement on the generating clock creation command according to the source clock variable replacement strategy to obtain at least one second clock creation command.

[0087] Specifically, _get_integration_info is called, and based on the master_source field of the currently generated clock (which corresponds to the input port where the module receives its external master clock), the dictionary self.intg_sink_to_src is used to look up the master clock source module instance and its clock definition information corresponding to the second module instance (corresponding to the target module instance).

[0088] For a source module instance, its clock definition information is parsed to find the referenced clock definition and obtain its root (original root path). Then, using the `parse_intg_src_parent_hier` method, the complete root path of the source module clock from the top-level perspective is dynamically calculated based on the positions of the source and target module instances in the hierarchy tree. For example, if the root of `src_block` (the source module) is `$CLK_A / div_clk`, and its parent instance is `top / u_pll / ` (assuming the source and target module instances do not belong to the same parent module instance), then the final concatenated complete root path is `top / u_pll / $CLK_A / div_clk`. This root path and the complete clock name of the source clock are used to replace variables to obtain a complete and accurate clock creation command, which, together with the initial master clock creation command, forms the second clock creation command.

[0089] It's important to note that if the source module instance and the target module instance share a common parent module, the placeholder for the hierarchical variable corresponding to the common parent module is retained. Starting from the branch point, the next-level hierarchical variable is replaced with the actual path of the source module instance. For example, if the source module instance and the target module instance are both second-level modules and belong to the same parent module, then ${sub1_hier} (the hierarchical variable corresponding to the common parent module) will be retained, while ${sub2_hier} (the hierarchical variable below the branch point) will be replaced with the actual path value of the source module instance. In subsequent execution, the hierarchical variable corresponding to the parent module will be replaced with the actual path value of the parent module.

[0090] In addition, for cross-module integration scenarios, based on the mapping relationship between the number of instances of the target module (second module instance) and the source module instance, there are three source clock variable replacement strategies: Strategy 1: For many-to-one scenarios, where the target module is a multi-instance module and all module instances originate from the same clock source, use the target clock's $NAME_<clock_name> _master is mapped to the source clock ([get_clocks ...]), $HIER_<clock_name> _master is mapped to the definition point of the source clock ([get_pins / get_ports ...]), and the relevant fields in the command line are replaced according to the mapping relationship.

[0091] Strategy 2: For many-to-many and one-to-one correspondences, where both the source module instance and the target module instance are multi-instance modules and there is a one-to-one correspondence in the clock flow, a mapping relationship similar to Strategy 1 is generated. However, the mapping will include the loop variables of the multi-module instances. In this case, the source clock name prefix and the variable name in the root path will be automatically synchronized with the variable name on the target instance side to prevent the source clock and target clock definition fields from having variable mismatch problems.

[0092] Strategy 3: For many-to-many relationships that are not one-to-one, i.e., when the source module instance and the target module instance cannot be matched one-to-one, such as when the clock stream of one source module instance flows into two target module instances, first group the source module instances, generate group definition commands and conditional judgment commands, and insert corresponding Tcl variable assignment statements into different branches of the conditional judgment, thereby ensuring that the creation of the clock in the target module instance can match the correct source clock.

[0093] For the different scenarios mentioned above, the initial clock creation command for generating the clock is replaced and modified according to different strategies. The final clock creation command is then written into the SDC file according to the structure, thus completing the automated construction of the cross-module clock chain.

[0094] Optionally, the SDC file generated by this application can be compatible with two different application scenarios to adapt to different chip design flows: 1) Hierarchical Mode (Submodule Read Netlist): In this mode, all clocks of the submodule except for the port master clock from outside the module (including the master clock with root as pin type and all generated clocks) must be explicitly defined in the SDC file. The method provided in this application will generate complete clock creation commands for all the above-mentioned clocks within the module.

[0095] 2) Block Only Mode (Submodule reads *db file): In this mode, some clock information of the submodule is encapsulated in the *db file. Only the master clock created by a non-port (i.e., the master clock of root type pin) needs to be explicitly defined in the SDC file; other generated clock information is obtained from the db file and does not need to be redefined in the SDC.

[0096] The two modes are controlled by if conditional branches in the SDC file, and users can select the desired mode by setting a global variable.

[0097] In summary, this application determines the actual hierarchical path value and actual clock prefix value of a module instance based on a hierarchical tree, and uses this actual value to generate a hierarchical variable assignment instruction. The hierarchical variables replace the variable placeholders in the clock creation command template, and are integrated with the hierarchical variable assignment instruction to obtain the initial clock creation command. Then, based on the clock connection relationship, the source clock variable is replaced in the cross-module generated clock in the initial clock creation command. This achieves automated generation of clock constraints and automatic construction of cross-module clock chains, and has the following beneficial effects: 1) Efficiency improvement: Designers only need to define the hierarchical structure information, clock definition information and clock connection relationship once in the configuration file, and the system can automatically generate all clock constraints for the entire chip level.

[0098] 2) High accuracy: Automated path concatenation and variable substitution avoid human spelling errors, and a strict variable matching check mechanism ensures the logical correctness of the generated commands.

[0099] 3) High maintainability: When design specifications or levels change, only the corresponding configuration files need to be modified, without modifying the script code, which greatly reduces maintenance costs.

[0100] 4) Integrated Automation: Cross-module clock connections are automatically handled through the INTG table, eliminating the need for manual analysis and achieving true "plug-and-play" clock integration.

[0101] 5) High flexibility: A single clock constraint file can support both Hierarchical mode and Block Only mode database application scenarios, providing high flexibility.

[0102] Furthermore, to help better understand the overall process of the clock constraint file generation method provided in this application, such as... Figure 4 As shown, Figure 4 This is a flowchart illustrating a specific clock constraint file generation method provided in this application embodiment.

[0103] Reference Figure 4 First, the top-level Excel file configured by the user is obtained. The Excel configuration parser reads each sheet, including the HIER sheet (defining hierarchical structure information), CLK sheet (defining clock definition information), and INTG sheet (defining clock connection relationships). Specifically, the hierarchical structure information in the HIER sheet is parsed to construct a hierarchical tree, and matching hierarchical variables are generated for at least one module instance based on the hierarchical tree. The clock definition information in the CLK sheet is parsed to generate at least one clock creation command template for each module. The integration relationships in the INTG sheet are parsed to construct cross-module clock mapping relationships. Then, through the hierarchical variable extension engine, based on the hierarchical tree and hierarchical variables, instance path variables are extended and variable placeholders in the templates are replaced. The clock command generator then generates the initial clock creation commands for each module instance. Next, through the clock integration parser, based on the cross-module clock mapping relationships, the source clock variables are replaced for the generated clock creation commands that require cross-module integration, generating integrated clock commands. Finally, the clock command generator outputs the chip's clock constraint file (SDC file, including hierarchical variable assignment instructions and clock creation commands containing hierarchical variables) based on the above processing results. In addition, the clock command generator also supports outputting the hierarchical structure diagram of the entire chip and the global clock tree structure diagram of the clock level, which can be used to assist designers in verifying the correctness of the hierarchical relationship and the completeness of the clock definition.

[0104] To implement the above embodiments, this application also provides a clock constraint file generation apparatus. Figure 5 This is a schematic diagram of a clock constraint file generation device 400 provided in an embodiment of this application. Figure 5 As shown, the device includes: The acquisition unit 410 is used to acquire the hierarchical structure information, clock definition information and clock connection relationship of at least one module in the chip. The clock connection relationship is used to characterize the clock transmission path between different modules. Construction unit 420 is used to construct a hierarchical tree based on hierarchical structure information to represent the hierarchical relationship between at least one module instance, so as to generate matching hierarchical variables for at least one module instance according to the hierarchical tree, wherein at least one module instance is obtained by instantiating at least one module. The generation unit 430 is used to generate at least one clock creation command template corresponding to each module in at least one module based on clock definition information. The at least one clock creation command template includes variable placeholders corresponding to hierarchical variables. Replacement unit 440 is used to replace variable placeholders in at least one clock creation command template based on hierarchical tree, hierarchical variables and clock connection relationship, to obtain at least one clock creation command corresponding to each module instance in at least one module instance, so as to generate the chip's clock constraint file according to at least one clock creation instruction.

[0105] In some embodiments of this application, the hierarchical variables include hierarchical path variables and clock prefix variables. The construction unit 420 is used to: determine the first hierarchical depth of the first module instance based on the hierarchical tree, wherein the first module instance is any module instance among at least one module instance; and generate the hierarchical path variables and clock prefix variables corresponding to the first module instance based on the first hierarchical depth.

[0106] In some embodiments of this application, at least one clock creation command template includes a master clock creation command template and a generated clock creation command template. The generation unit 430 is used to: determine the clock type of the clock included in the first module based on clock definition information, wherein the first module is any one of at least one modules, and the clock type includes master clock and generated clock; construct the master clock creation command template corresponding to the master clock and / or the generated clock creation command template corresponding to the generated clock by using the initial hierarchical variable as a variable placeholder for the clock creation command template, wherein the initial hierarchical variable is a fixed placeholder used to replace the hierarchical variable.

[0107] In some embodiments of this application, the construction unit 420 is used to: determine the parent-child relationship between at least one module and the instantiation parameters corresponding to at least one module based on the hierarchical structure information; determine at least one module instance corresponding to at least one module based on the instantiation parameters; determine the root node and child node corresponding to at least one module instance based on the parent-child relationship; and construct a hierarchical tree based on the root node and child nodes.

[0108] In some embodiments of this application, the replacement unit 440 is configured to: determine the second-level path value and the second preset clock prefix value of the second module instance based on the hierarchical tree, and generate a hierarchical variable assignment instruction for the second module instance based on the second-level path value and the second preset clock prefix value, wherein the second module instance is any module instance among at least one module instance; determine at least one second clock creation command template corresponding to the second module instance in at least one clock creation command template; use the hierarchical variables of the second module instance to perform variable replacement on the variable placeholders in at least one second clock creation command template, and integrate the hierarchical variable assignment instructions to obtain at least one second initial clock creation command; and update at least one second initial clock creation command based on the clock connection relationship to obtain at least one second clock creation command.

[0109] In some embodiments of this application, the replacement unit 440 is configured to: determine, based on clock connection relationships, whether at least one second initial clock creation command includes a generated clock creation command with cross-module clock connection relationships; if at least one second initial clock creation command includes a generated clock creation command, perform source clock variable replacement on the generated clock creation command in at least one second initial clock creation command based on clock connection relationships to obtain at least one second clock creation command; if at least one second initial clock creation command does not include a generated clock creation command, determine at least one second initial clock creation command as at least one second clock creation command.

[0110] In some embodiments of this application, the replacement unit 440 is used to: determine a source module instance that has a cross-module clock connection relationship with the second module instance based on the clock connection relationship; determine a source clock variable replacement strategy based on the instance number mapping relationship between the second module instance and the source module instance; and perform source clock variable replacement on the generated clock creation command according to the source clock variable replacement strategy to obtain at least one second clock creation command.

[0111] Since the apparatus provided in this application corresponds to the methods provided in the above-mentioned embodiments, the implementation of the methods is also applicable to the apparatus provided in this embodiment, and will not be described in detail in this embodiment.

[0112] The methods and apparatus provided in the embodiments of this application have been described above. To implement the functions of the methods provided in the embodiments of this application, the electronic device may include a hardware structure and software modules, and may implement the above functions in the form of a hardware structure, software modules, or a hardware structure plus software modules. One of the above functions may be executed in the form of a hardware structure, software modules, or a hardware structure plus software modules.

[0113] Figure 6 This is a block diagram illustrating an electronic device 500 for implementing the above-described clock constraint file generation method according to an exemplary embodiment.

[0114] Reference Figure 6 The electronic device 500 may include one or more of the following components: processing component 502, memory 504, power supply component 506, multimedia component 508, audio component 510, input / output (I / O) interface 512, sensor component 514, and communication component 516.

[0115] Processing component 502 typically controls the overall operation of electronic device 500, such as operations associated with display, telephone calls, data communication, camera operation, and recording. Processing component 502 may include one or more processors 520 to execute instructions to perform all or part of the steps of the methods described above. Furthermore, processing component 502 may include one or more modules to facilitate interaction between processing component 502 and other components. For example, processing component 502 may include a multimedia module to facilitate interaction between multimedia component 508 and processing component 502.

[0116] Memory 504 is configured to store various types of data to support the operation of electronic device 500. Examples of this data include instructions for any application or method operating on electronic device 500, contact data, phonebook data, messages, pictures, videos, etc. Memory 504 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0117] Power supply component 506 provides power to various components of electronic device 500. Power supply component 506 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to electronic device 500.

[0118] Multimedia component 508 includes a screen that provides an output interface between electronic device 500 and user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 508 includes a front-facing camera and / or a rear-facing camera. When electronic device 500 is in an operating mode, such as a shooting mode or video mode, the front-facing camera and / or rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

[0119] Audio component 510 is configured to output and / or input audio signals. For example, audio component 510 includes a microphone (MIC) configured to receive external audio signals when electronic device 500 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 504 or transmitted via communication component 516. In some embodiments, audio component 510 also includes a speaker for outputting audio signals.

[0120] I / O interface 512 provides an interface between processing component 502 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.

[0121] Sensor assembly 514 includes one or more sensors for providing state assessments of various aspects of electronic device 500. For example, sensor assembly 514 may detect the on / off state of electronic device 500, the relative positioning of components such as the display and keypad of electronic device 500, changes in position of electronic device 500 or a component of electronic device 500, the presence or absence of user contact with electronic device 500, orientation or acceleration / deceleration of electronic device 500, and temperature changes of electronic device 500. Sensor assembly 514 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 514 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, sensor assembly 514 may also include an accelerometer, gyroscope, magnetometer, pressure sensor, or temperature sensor.

[0122] Communication component 516 is configured to facilitate wired or wireless communication between electronic device 500 and other devices. Electronic device 500 can access wireless networks based on communication standards, such as WiFi, 2G or 3G, 4G LTE, 5G NR (NewRadio), or combinations thereof. In one exemplary embodiment, communication component 516 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 516 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0123] In an exemplary embodiment, the electronic device 500 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the methods described above.

[0124] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 504 including instructions, which can be executed by a processor 520 of an electronic device 500 to perform the above-described method. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0125] Embodiments of this application also propose a chip including one or more interface circuits and one or more processors; the interface circuits are used to receive signals from the memory of an electronic device and send signals to the processors, the signals including computer instructions stored in the memory, and when the processor executes the computer instructions, it causes the electronic device to execute the clock constraint file generation method described in the above embodiments of this application.

[0126] Embodiments of this application also propose a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to execute the clock constraint file generation method described in the above embodiments of this application.

[0127] Embodiments of this application also propose a computer program product, including a computer program that is executed by a processor using the clock constraint file generation method described in the above embodiments of this application.

[0128] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0129] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0130] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of the invention pertain.

[0131] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a system including a processing module, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (control method), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic device, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which programs can be printed, because programs can be obtained electronically, for example, by optically scanning the paper or other media, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0132] It should be understood that various parts of the embodiments of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0133] Those skilled in the art will understand that all or part of the steps of the methods described in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0134] Furthermore, the functional units in the various embodiments of the present invention can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc.

[0135] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A method for generating clock constraint files, characterized in that, The method includes: Obtain the hierarchical structure information, clock definition information, and clock connection relationship of at least one module in the chip, wherein the clock connection relationship is used to characterize the clock transmission path between different modules; Based on the hierarchical structure information, a hierarchical tree is constructed to represent the hierarchical relationship between at least one module instance, so as to generate matching hierarchical variables for the at least one module instance according to the hierarchical tree, wherein the at least one module instance is obtained by instantiating the at least one module; The hierarchical variables include hierarchical path variables and clock prefix variables, and generating matching hierarchical variables for the at least one module instance based on the hierarchical tree includes: Based on the hierarchy tree, the first level depth of the first module instance is determined, wherein the first module instance is any module instance among the at least one module instance; Based on the first level depth, generate the level path variable and the clock prefix variable corresponding to the first module instance; Based on the clock definition information, at least one clock creation command template is generated for each module in the at least one module, and the at least one clock creation command template includes variable placeholders corresponding to the hierarchical variables; The at least one clock creation command template includes a master clock creation command template and a generated clock creation command template. The step of generating at least one clock creation command template corresponding to each module in the at least one module, based on the clock definition information, includes: Based on the clock definition information, the clock type of the clock included in the first module is determined. The first module is any one of the at least one modules. The clock type includes the master clock and the generated clock. The initial hierarchical variable is used as a variable placeholder in the clock creation command template to construct the master clock creation command template corresponding to the master clock, and / or the generated clock creation command template corresponding to the generated clock. The initial hierarchical variable is a fixed placeholder used to replace the hierarchical variable. Based on the hierarchical tree, the hierarchical variables, and the clock connection relationship, the variable placeholders in the at least one clock creation command template are replaced to obtain at least one clock creation command corresponding to each module instance in the at least one module instance, so as to generate the clock constraint file of the chip according to the at least one clock creation command; The step of replacing variable placeholders in the at least one clock creation command template based on the hierarchical tree, the hierarchical variables, and the clock connection relationships to obtain at least one clock creation command corresponding to each module instance in the at least one module instance includes: Based on the hierarchy tree, the second-level path value and the second preset clock prefix value of the second module instance are determined, and a hierarchy variable assignment instruction for the second module instance is generated based on the second-level path value and the second preset clock prefix value. The second module instance is any module instance among the at least one module instance. Determine at least one second clock creation command template corresponding to the second module instance in the at least one clock creation command template; The hierarchical variables of the second module instance are used to replace the variable placeholders in the at least one second clock creation command template, and the hierarchical variable assignment instructions are integrated to obtain at least one second initial clock creation command; Based on the clock connection relationship, the at least one second initial clock creation command is updated to obtain at least one second clock creation command.

2. The method according to claim 1, characterized in that, The step of constructing a hierarchical tree to represent the hierarchical relationship between at least one module instance based on the hierarchical structure information includes: Based on the hierarchical structure information, determine the parent-child relationship between the at least one module and the instantiation parameters corresponding to the at least one module; Based on the instantiation parameters, at least one module instance corresponding to the at least one module is determined; Based on the parent-child relationship, determine the root node and child nodes corresponding to the at least one module instance; The hierarchical tree is constructed based on the root node and the child nodes.

3. The method according to claim 1, characterized in that, The step of updating the at least one second initial clock creation command based on the clock connection relationship to obtain at least one second clock creation command includes: Based on the clock connection relationship, determine whether the at least one second initial clock creation command includes a clock generation creation command with a cross-module clock connection relationship; When the at least one second initial clock creation command includes the generated clock creation command, based on the clock connection relationship, the source clock variable of the generated clock creation command in the at least one second initial clock creation command is replaced to obtain the at least one second clock creation command; If the at least one second initial clock creation command does not include the generated clock creation command, then the at least one second initial clock creation command is determined to be the at least one second clock creation command.

4. The method according to claim 3, characterized in that, The step of replacing the source clock variable in the generated clock creation command of the at least one second initial clock creation command based on the clock connection relationship to obtain the at least one second clock creation command includes: Based on the clock connection relationship, determine the source module instance that has a cross-module clock connection relationship with the second module instance; Based on the instance number mapping relationship between the second module instance and the source module instance, the source clock variable replacement strategy is determined; The source clock variable is replaced according to the source clock variable replacement strategy to obtain the at least one second clock creation command.

5. A clock constraint file generation device, characterized in that, The device includes: The acquisition unit is used to acquire the hierarchical structure information, clock definition information and clock connection relationship of at least one module in the chip, wherein the clock connection relationship is used to characterize the clock transmission path between different modules; A construction unit is configured to construct a hierarchical tree representing the hierarchical relationship between at least one module instance based on the hierarchical structure information, so as to generate matching hierarchical variables for the at least one module instance according to the hierarchical tree, wherein the at least one module instance is obtained by instantiating the at least one module. The hierarchical variables include hierarchical path variables and clock prefix variables, and generating matching hierarchical variables for the at least one module instance based on the hierarchical tree includes: Based on the hierarchy tree, the first level depth of the first module instance is determined, wherein the first module instance is any module instance among the at least one module instance; Based on the first level depth, generate the level path variable and the clock prefix variable corresponding to the first module instance; The generation unit is used to generate at least one clock creation command template corresponding to each module in the at least one module based on the clock definition information. The at least one clock creation command template includes variable placeholders corresponding to the hierarchical variables. The at least one clock creation command template includes a master clock creation command template and a generated clock creation command template. The step of generating at least one clock creation command template corresponding to each module in the at least one module, based on the clock definition information, includes: Based on the clock definition information, the clock type of the clock included in the first module is determined. The first module is any one of the at least one modules. The clock type includes the master clock and the generated clock. The initial hierarchical variable is used as a variable placeholder in the clock creation command template to construct the master clock creation command template corresponding to the master clock, and / or the generated clock creation command template corresponding to the generated clock. The initial hierarchical variable is a fixed placeholder used to replace the hierarchical variable. The replacement unit is used to replace the variable placeholders in the at least one clock creation command template based on the hierarchical tree, the hierarchical variables and the clock connection relationship, so as to obtain at least one clock creation command corresponding to each module instance in the at least one module instance, so as to generate the clock constraint file of the chip according to the at least one clock creation command; The step of replacing variable placeholders in the at least one clock creation command template based on the hierarchical tree, the hierarchical variables, and the clock connection relationships to obtain at least one clock creation command corresponding to each module instance in the at least one module instance includes: Based on the hierarchy tree, the second-level path value and the second preset clock prefix value of the second module instance are determined, and a hierarchy variable assignment instruction for the second module instance is generated based on the second-level path value and the second preset clock prefix value. The second module instance is any module instance among the at least one module instance. Determine at least one second clock creation command template corresponding to the second module instance in the at least one clock creation command template; The hierarchical variables of the second module instance are used to replace the variable placeholders in the at least one second clock creation command template, and the hierarchical variable assignment instructions are integrated to obtain at least one second initial clock creation command; Based on the clock connection relationship, the at least one second initial clock creation command is updated to obtain at least one second clock creation command.

6. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-4.

7. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-4.

Images