Chip clock control code automatic generation method, system, device and medium

Abstract

This application provides a method, system, device, and medium for automatically generating chip clock control code, effectively solving the problems of low efficiency, low design reliability, and low accuracy in chip clock design and implementation. The method includes: obtaining a user-provided structured file containing a chip clock tree structure; identifying and extracting various hardware elements from the structured file according to preset mapping rules; establishing an initial netlist topology based on the ports / modules and corresponding signal connections in the various hardware elements; automatically sorting the signal connections in the initial netlist topology using target merging rules to obtain a netlist topology diagram; executing a target code language generation strategy to obtain various instantiated codes based on the netlist topology diagram and corresponding connection signals; and assembling the various instantiated codes to obtain the control code corresponding to the chip clock.

Description

Technical Field

[0001] This application relates to the field of SOC design technology, and more specifically, to a method, system, device, and medium for automatically generating chip clock control code. Background Technology

[0002] As the integration density of System-on-a-Chip (SoC) increases, the Unified Clock and Reset Generation Unit (CGU) of the system undertakes the core task of distributing and recombining various reference frequencies and dispatching them to functional modules. In order to maintain design and code collaboration, various logic gates and multiplexed switches are usually planned in the graphical design canvas (such as auxiliary tools like draw.io) to form a mesh topology.

[0003] In a typical current design implementation scheme: after the graphics system design is completed and approved, the digital front-end developer must visually monitor the structure and flow of the topology diagram: manually writing Verilog RTL module code to implement hundreds of signal definitions and multiple basic modules; manually observing which lines merge into thick lines (buses); and then manually copying, instantiating, and splicing the basic module code one by one according to the meaning of each primitive. If the diagram shifts even slightly or the connection relationships change, the relevant code must also be manually traced and modified.

[0004] Disadvantages of existing technology: 1. Heavy labor and prone to errors: It is extremely unstable to have engineers manually copy the graphical connection of these hundred or so misconnected wires and port names. Connecting a single wire incorrectly can cause a peripheral device to malfunction or cause clock aliasing.

[0005] 2. Difficulty in determining format and bit width: Since topology drawing tools do not include syntax checking, when extracting and converting data, for example, if the graphic marks the line position of a certain flying line, and you want to manually connect it to another line and legally write it into the hardware code, it often results in oversights such as bit flipping or size mismatch. Summary of the Invention

[0006] In view of this, the purpose of this application is to provide a method, system, device and medium for automatically generating chip clock control code, which effectively solves the problems of low efficiency, low design reliability and low accuracy in chip clock design and transcription implementation.

[0007] In a first aspect, embodiments of this application provide a method for automatically generating chip clock control code, the method comprising: Obtain a structured file containing a chip clock tree structure provided by the user, and identify and extract various hardware elements from the structured file according to preset mapping rules; An initial netlist topology is established based on the ports / modules and corresponding signal connections in the various hardware elements. The signal connections in the initial netlist topology are automatically sorted out using target merging rules to obtain the netlist topology. Based on the netlist topology and the corresponding connection signals, a target code language generation strategy is executed to obtain multiple instantiated codes, and the multiple instantiated codes are assembled to obtain the control code corresponding to the chip clock.

[0008] In conjunction with the first aspect, this application provides a first possible implementation of the first aspect, wherein the step of automatically sorting out the signal connections in the initial netlist topology graph through target merging rules to obtain the netlist topology graph includes: The signal connection sorting logic is configured with a naming initialization stage, an explicit overriding stage, a homogeneous clustering stage, and an attribute alignment stage. The pre-configured sorting methods are executed in the naming initialization phase, explicit overriding phase, homogeneous clustering phase, and attribute alignment phase respectively to automatically sort the signal connections.

[0009] In conjunction with the first aspect, this application provides a second possible implementation of the first aspect, wherein a pre-configured sorting method is executed in the naming initialization phase, the explicit overriding phase, the homology clustering phase, and the attribute alignment phase, respectively, including: Extract the source node identifier of the driving source to which the signal connection without a display name belongs, and clean the source node identifier; Based on the signal flow direction, a preset suffix identifier is automatically added to the signal connection after the cleaning process is completed, generating an initial signal name.

[0010] In conjunction with the first aspect, this application provides a third possible implementation of the first aspect, wherein a pre-configured sorting method is executed in the naming initialization phase, the explicit overriding phase, the homology clustering phase, and the attribute alignment phase, respectively, including: The text annotations added by the designer to the graphic connections are analyzed, and the explicit signal names and bit width annotation information are captured simultaneously. The captured explicit signal name and bit width constraint are used as the highest priority to override the generated initial signal name and its corresponding bit width information.

[0011] In conjunction with the first aspect, this application provides a fourth possible implementation of the first aspect, wherein a pre-configured sorting method is executed in the naming initialization phase, the explicit overriding phase, the homology clustering phase, and the attribute alignment phase, respectively, including: Based on the initial netlist topology graph, traverse and cluster the network to classify all branch connections connected to the same output port into the same signal network. The same signal network is sequentially aligned with signal name attributes and signal bit width attributes to obtain a netlist topology after alignment.

[0012] In conjunction with the first aspect, this application provides a fifth possible implementation of the first aspect, wherein multiple hardware elements are identified and extracted from the structured file according to preset mapping rules, including: Traverse the chip clock tree structure in the structured file and read the attribute fields of multiple primitive nodes; the attribute fields include type identifiers and label attributes; Based on the type identifier and label attribute, determine the hardware element type corresponding to the primitive node and extract the name and bit width label information of each hardware element.

[0013] In conjunction with the first aspect, this application provides a sixth possible implementation of the first aspect, wherein, based on the netlist topology and corresponding connection signals, a target code language generation strategy is executed to obtain various instantiated codes, including: For a specific pre-defined functional module, check whether its preset port is connected in the netlist topology diagram; If not, search for the preset global system port and automatically connect the preset port to the global system port.

[0014] Secondly, embodiments of this application provide an automatic generation system for chip clock control code, the system comprising: The acquisition module is used to acquire a structured file provided by the user that contains a chip clock tree structure, and to identify and extract various hardware elements from the structured file according to preset mapping rules. A module is established to create an initial netlist topology based on the ports / modules and corresponding signal connections among the various hardware elements. Through target merging rules, the signal connections in the initial netlist topology are automatically sorted out to obtain the netlist topology. The execution module is used to execute the target code language generation strategy to obtain multiple instantiated codes based on the netlist topology diagram and the corresponding connection signals, and assemble the multiple instantiated codes to obtain the control code corresponding to the chip clock.

[0015] Thirdly, embodiments of this application provide an electronic device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, the steps of the automatic generation method for chip clock control code described in any one of the claims are executed.

[0016] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the automatic generation method for chip clock control code as described in any one of the claims.

[0017] This application provides an automatic generation method for chip clock control code. The method first obtains a structured file containing a chip clock tree structure provided by the user, and identifies and extracts various hardware elements from the structured file according to preset mapping rules. Then, an initial netlist topology is established based on the ports / modules and corresponding signal connections in the various hardware elements. The signal connections in the initial netlist topology are automatically sorted out using target merging rules to obtain a netlist topology diagram. Finally, based on the netlist topology diagram and the corresponding connection signals, a target code language generation strategy is executed to obtain various instantiated codes, and the various instantiated codes are assembled to obtain the control code corresponding to the chip clock. Based on the above methods, this application completely changes the traditional manual transcription work mode by establishing an automated mapping mechanism from graphical architecture diagrams to hardware description language code. It also avoids human errors such as missing connections, port mismatches, and inconsistent bit widths caused by visual fatigue and distraction during manual transcription. The automated mapping mechanism also fully respects the naming intentions of designers on the diagrams, making the generated code self-documenting. Downstream verification engineers and backend engineers can understand the meaning of signals without having to go back to the original diagrams, reducing the cost of code reading. At the same time, the automated mapping also makes the connection signals have unified signal naming and standardized code structure, providing high-quality input for subsequent simulation verification, synthesis, placement and routing, and improving efficiency, design reliability and accuracy. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating an automatic generation method for chip clock control code provided in an embodiment of this application is shown. Figure 2 A flowchart illustrating another method for automatically generating chip clock control code provided in an embodiment of this application is shown. Figure 3 The illustration shows a flowchart of obtaining various instantiation codes according to an embodiment of this application; Figure 4This paper shows a structural block diagram of an automatic chip clock control code generation system provided in an embodiment of this application; Figure 5 A structural block diagram of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0021] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0022] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0023] Currently, designers typically use graphical tools to draw clock tree topology diagrams, and then manually transcribe the modules, ports, and connections in the diagram into hardware description language code. This manual transcription method suffers from inefficiency, is prone to introducing wiring errors and bit width mismatches, and affects design reliability and development efficiency.

[0024] Based on this, embodiments of this application provide a method, system, device, and medium for automatically generating chip clock control code, which are described below through embodiments.

[0025] Example 1 To facilitate understanding of this embodiment, a method for automatically generating chip clock control code disclosed in this application will first be described in detail. For example... Figure 1The diagram shows a flowchart of a method for automatically generating chip clock control code. Figure 2 The flowchart shown illustrates another method for automatically generating chip clock control code. This application provides a method for automatically generating chip clock control code, the method comprising: S101. Obtain a structured file containing a chip clock tree structure provided by the user, and identify and extract various hardware elements from the structured file according to preset mapping rules. S102. Based on the ports / modules and corresponding signal connections in the various hardware elements, an initial netlist topology diagram is established. Through target merging rules, the signal connections in the initial netlist topology diagram are automatically sorted out to obtain the netlist topology diagram. S103. Based on the netlist topology and the corresponding connection signals, execute the target code language generation strategy to obtain multiple instantiated codes, and assemble the multiple instantiated codes to obtain the control code corresponding to the chip clock.

[0026] In step S101, this application obtains a structured file containing a chip clock tree structure provided by the user by receiving a drawing exported by the user through a graphical editing tool. The structured file is in XML format or a format supported by auxiliary tools such as draw.io. When processing the structured file, a preset mapping rule is invoked. The mapping rule is as follows: based on the specific attributes of the primitive nodes in the structured file, such as type identifiers and text labels, it is distinguished whether they represent ports, modules, or connections. The type identifier comes from the tag attribute, and the text label attribute comes from the text label. For functional modules, the module type and instance identifier they represent are further extracted, where the module type is used to map the exact IP primitives later. For signal connections, not only are the source node and target node identifiers extracted, but also the location information (endpoint coordinates) of the connection to the specific node is extracted to resolve the connection ambiguity of multi-port modules. Based on the above method, this application identifies and extracts various hardware elements from the structured file, namely ports / modules and corresponding signal connections, specifically including top-level input ports, top-level output ports, functional module instances such as multiplexers and frequency dividers, and signal connections connecting these elements.

[0027] In a specific implementation of step S101, one embodiment involves identifying and extracting various hardware elements from the structured file according to preset mapping rules, including: S1011. Traverse the chip clock tree structure in the structured file and read the attribute fields of multiple primitive nodes; the attribute fields include type identifiers and label attributes; S1012. Based on the type identifier and label attribute, determine the hardware element type corresponding to the graphic element node and extract the name and bit width label information of each hardware element.

[0028] In steps S1011-S1012, when processing the structured file, this application traverses the chip clock tree structure in the structured file and reads the attribute fields of multiple primitive nodes on the chip clock tree structure. The attribute fields in the preset mapping rules of this application include type identifiers and tag attributes. The type identifier is used to uniquely identify the hardware semantic type represented by the primitive node. The system completes the type determination by matching preset keywords (such as input, output, wire, mux, divider, clock_gating, etc.). The tag attribute is used to carry explicit design information such as hardware element names, bit width labels, and bus indexes defined by the designer. Then, according to the preset mapping rules, the data is retrieved from multiple primitive nodes in the structured file, such as... <userobject>Predefined attributes, such as tooltip tags, serve as type identifiers to match keywords like 'wire' and 'input'. The label attribute is extracted to obtain specific port names or line width annotations. By traversing the XML tree structure, a precise mapping between hardware entities and graphical nodes is achieved, providing standardized input data for subsequent netlist topology construction, signal normalization, and code generation.

[0029] In step S102, an initial netlist topology is established based on the ports / modules and corresponding signal connections among the various hardware elements. Specifically, for each signal connection, the spatial coordinate information of its two ends is retrieved. The coordinates of the starting end of the connection are precisely matched with the coordinates of the corresponding functional module output port and the top-level input port to locate the signal driving source. The coordinates of the ending end of the connection are matched with the coordinates of the corresponding functional module input port and the top-level output port to locate the signal receiving end. All connections are paired and bound to ports and modules one by one, clarifying the flow path and fan-in / fan-out relationship of each signal, and resolving the scattered... The hardware elements are connected in series to form a complete mesh structure, forming an initial netlist topology diagram, thereby restoring the complete physical connection relationship and logical transmission path of the chip clock. At this time, the initial netlist topology diagram has problems such as chaotic signal naming, inconsistent naming of branches of the same source signal, conflicting bit width labels, and numerous redundant signals, which cannot be directly used for code generation. Therefore, it is necessary to carry out a comprehensive and automated sorting of all connection signals inside the initial netlist topology diagram through preset target merging rules, remove redundant information, unify signal attributes, and standardize signal naming, so as to finally obtain a standardized, rigorous, and directly reusable target netlist topology diagram.

[0030] In this application, the original connection information, including start-point coordinates, end-point coordinates, and primitive identifiers, obtained directly from the graphical file, is referred to as a "signal connection." The structured signal object generated after processing by the signal naming rules, homogeneous clustering rules, and attribute alignment rules proposed in this application, possessing a unified signal name, unified signal bit width, and a clearly defined driving source and load list, is referred to as a "connection signal." Signal connections are the direct output of the data extraction stage, while connection signals are the core processing object in the logical relationship derivation stage. Multiple homogeneous signal connections are grouped into the same connection signal after processing.

[0031] In a specific implementation of step S102, one embodiment is as follows: The automatic sorting of signal connections in the initial netlist topology diagram using target merging rules to obtain the netlist topology diagram includes: S1021. For the sorting logic of the signal connection, set up a naming initialization stage, an explicit overlay stage, a homogeneous clustering stage, and an attribute alignment stage; S1022. Execute the pre-configured sorting methods in the naming initialization stage, explicit overriding stage, homogeneous clustering stage, and attribute alignment stage respectively to automatically sort the signal connections.

[0032] In steps S1021-S1022, this application sets up a hierarchical execution and layer-by-layer verification sorting logic for the signal connections. Based on this logic, it sets up a naming initialization stage, an explicit overlay stage, a homogeneous clustering stage, and an attribute alignment stage. Pre-configured sorting methods are executed in each of these stages, ensuring that the corresponding sorting method is applied at each stage. Each stage is executed sequentially and seamlessly, leaving no logical loopholes, and balancing signal connectivity, naming standardization, and bit width validity. After completing all stages of sorting, a full-domain verification is performed on the sorted netlist topology to check for issues such as signal breaks, duplicate names, and bit width mismatches, and to fix minor vulnerabilities. Through this automated sorting process, the originally messy initial netlist topology is transformed into a netlist topology with unified signal naming, standardized bit widths, clear logic, and no redundant conflicts. It fully preserves the hardware connection relationships and design intent of the clock tree, while possessing high standardization and usability, providing reliable data support for the subsequent automated assembly of hardware description language code.

[0033] In the specific implementation of step S1022, one embodiment is as follows: Pre-configured sorting methods are executed in the naming initialization stage, explicit coverage stage, homogeneous clustering stage, and attribute alignment stage, respectively, including: A1. Extract the source node identifier of the driving source to which the signal connection without a display name belongs, and clean the source node identifier. A2. Automatically add preset suffix identifiers to the signal lines after cleaning based on the signal flow direction, and generate initial signal names.

[0034] In steps A1-A2, during the naming initialization phase, this application extracts the source node identifier of the driver for signal connections without displayed names. The source node identifier is then cleaned to remove illegal characters and redundant prefixes that do not conform to the hardware description language specification. After the cleaned signal connections are cleaned, a preset suffix identifier is automatically added to the signal connections according to the signal flow direction to generate an initial signal name. This forms an implicit name that is unique and traceable. For example, a specific suffix such as automatically adding _o is added based on the source module instance name, clearly indicating the source module and transmission direction of the signal. This also ensures that each signal connection has a valid identifier, preventing topology breaks and compilation errors caused by unnamed signals.

[0035] In the specific implementation of step S1022, another embodiment is as follows: Pre-configured sorting methods are executed in the naming initialization stage, explicit coverage stage, homogeneous clustering stage, and attribute alignment stage, respectively, including: B1. Parse the text annotations added by the designer on the graphic connection lines, and simultaneously capture the explicit signal name and bit width annotation information; B2. The captured explicit signal name and bit width constraint are used as the highest priority to override the generated initial signal name and its corresponding bit width information.

[0036] In steps B1-B2, after completing the naming initialization phase, this application executes the explicit overriding phase. In this phase, a regular expression matching engine is activated to scan all explicit labels on signal connections within the initial netlist topology diagram, extracting key information such as signal names and bit-width constraints manually labeled by the designer. These explicit labels represent the designer's core design intent and have higher priority than the implicit names automatically generated during the naming initialization phase. Once an explicit label is detected, it immediately overwrites the original implicit name, synchronously binding the corresponding bit-width parameters, preserving the original design intent, and ensuring that the final netlist topology diagram conforms to the architecture design document, achieving complete inheritance of design intent. Furthermore, this design allows designers to forcibly define the names of critical clock domains, enabling the generated control code, i.e., Verilog RTL module code, to directly conform to the interface standards of the top-level architecture document.

[0037] In the specific implementation of step S1022, there is also an embodiment in which the pre-configured sorting method is executed in the naming initialization stage, explicit overriding stage, homogeneous clustering stage, and attribute alignment stage, respectively, including: C1. Based on the initial netlist topology graph, perform traversal clustering to group all branch connections connected to the same output port into the same signal network; C2. Align the signal name attribute and the signal bit width attribute of the same signal network in sequence to obtain the netlist topology after the alignment is completed.

[0038] In steps C1-C2, this application switches from the explicit coverage stage to the homogeneous clustering stage and the attribute alignment stage. Based on the homogeneous clustering stage, the initial netlist topology graph after the explicit coverage stage is processed. The processing method is homogeneous signal normalization. Specifically, when the same source node, such as an input port or an output terminal of a module, fans out to multiple target nodes, multiple logical connections will be generated. These homogeneous connections are clustered, and the simplest name or the source port name is directly inherited from this group of connections. The names of all connections in the group are uniformly covered in reverse. This approach integrates multiple scattered connections into a single system, resolving the issue of inconsistent naming of multiple branches of the same source signal. It ensures that in the generated control code, the same physical drive source has only one unified internal variable name, avoiding redundant variable declarations and assignments. Furthermore, it can iterate through the names of all connections within a group, selecting the shortest and most standardized legal identifier and setting it as the globally unified name for that signal network. This covers all redundant and lengthy names within the group, simplifying the netlist structure, improving readability, and automatically correcting repetitive long labels used by designers, thus optimizing code size. In the attribute alignment stage, it addresses the issue that designers may annotate different bit widths on different branches of the same signal network during graphical rendering—for example, annotating full bit width in one place, only a specific bit width in another, or omitting annotations altogether. Therefore, it is necessary to perform attribute unification calibration on each group of same source signal networks to achieve dual normalization of name and bit width. Specifically, in terms of bit width processing, the bit width parameters of all branches labeled in the signal network are extracted, and the maximum effective bit width value is parsed out, for example, uniformly in the form of `[maximum bit width: 0]`. Based on this standard, the bit width format of the entire signal network is unified, eliminating potential problems such as bit width conflicts and high-bit truncation.

[0039] This application also introduces "non-intrusive dynamic boundary-aware constraints" for verification. The merging effect brought about by automated sorting is not a simple rewrite, but rather a regular expression scan of all occurrences of declarations, extracting the largest quantization boundary value, and forcibly filling all downgraded to the underlying standard format during the final merging. The technical effect lies in its "fault-tolerant and complete defense capability," dynamically calculating the required upper bound of the bus bit width, completely eliminating the fatal high-level truncation and loss accidents that are extremely prone to occur during the digital logic synthesis stage.

[0040] In step S103, after obtaining the netlist topology diagram, this application traverses the top-level input ports and top-level output ports in the target netlist topology diagram, and generates module port declaration code according to the syntax specifications of the target code language, in conjunction with the corresponding connection signals. Then, it extracts all internal connection signals in the netlist topology diagram, including signal name, bit width, and signal type (such as wire), and generates connection signal declaration code according to the signal declaration specifications of the target code language. Furthermore, it generates direct connection assignment statements (such as the Assign statement in Verilog) based on the flow and connection relationships of the connection signals in the netlist topology diagram. Finally, it traverses all functional module instances in the netlist topology diagram, such as multiplexers, clock dividers, and clock gating units, and generates corresponding module instantiation code by combining the module type, instance identifier, and signal connection relationships. After completing the generation of the above various instantiation codes (port declaration, internal signal declaration, direct connection assignment, and functional module instantiation), the code assembly process is initiated, and various types of code are systematically integrated according to the standard structure of the target code language. The assembly sequence is: module port declaration, internal signal declaration, functional module instantiation, and direct connection assignment, ensuring a clear code structure, logical coherence, and compliance with hardware description language execution specifications. Simultaneously, necessary comments are automatically added, annotating module functions, signal uses, and key design nodes to improve code readability and maintainability. After assembly, the generated chip clock control code undergoes full-domain syntax and logic verification to check for syntax errors, port mapping errors, bit width mismatches, signal open circuits, and other issues, ensuring the chip clock control code can be directly compiled and synthesized. Finally, complete, standardized, and highly usable control code corresponding to the chip clock is output. This control code is Verilog RTL module code, achieving fully automated conversion from the target netlist topology to industrial-standard control code, completely overcoming the bottleneck of manual transcription and ensuring the reliability and development efficiency of the control code.

[0041] This application can also convert draw.io XML format into a structured intermediate description (JSON or YAML format), explicitly describing all ports, modules, and connection relationships. Using the intermediate JSON / YAML file as input, it generates Verilog RTL module code, which can be manually reviewed and modified (improving transparency). It can also be used as input for other code generation tools (such as SystemVerilog and VHDL generators) to achieve better decoupling. Furthermore, the XML text of the graph can be directly sent to large language models (such as GPT and Gemini), guiding the model to understand the graph structure and generate Verilog RTL module code through Prompt Engineering. This eliminates the need to write parsing rules for specific XML formats, resulting in stronger generalization capabilities. However, the output stability and repeatability are not as good as rule-based deterministic algorithms, and it relies on external APIs. In chip design environments with high confidentiality requirements, the service poses a data leakage risk. Instead of selecting the "shortest name," users could explicitly assign unique names to each signal in draw.io, replacing automatic derivation and sacrificing convenience for complete control over naming. In addition to using the maximum bit width, the system could report an error and require manual correction if bit width conflicts exist for the same signal, thus avoiding potential problems introduced by silently expanding the bit width. Furthermore, instead of hardcoding it in the script, the system could declare in the configuration file which module types and ports should be connected to which signal by default, making the DFT rules configurable and adaptable to projects with different DFT specifications.

[0042] In addition to exporting XML format, draw.io, used in this application, also supports exporting SVG vector graphics format. Alternative implementations based on SVG DOM parsing can be developed, by parsing rectangles (`...`) within the SVG. <rect>`), character (` <text>`) and path (` <path>The `) element infers port connection relationships using geometric coordinate relationships (the spatial proximity of endpoint coordinates and module borders), generating the same Verilog RTL control code output. This approach does not rely on draw.io's specific XML attribute conventions (such as tooltip) and can be extended to other SVG export tools, but the parsing algorithm has higher requirements for coordinate accuracy, making robustness more difficult to guarantee.

[0043] In the specific implementation of step S103, one embodiment is as follows: Figure 3 As shown, based on the netlist topology and corresponding connection signals, a target code language generation strategy is executed to obtain various instantiated codes, including: S1031. For a pre-defined specific functional module, detect whether its preset port is connected in the netlist topology diagram; S1032. If not, search for the preset global system port and automatically connect the preset port to the global system port.

[0044] In steps S1031-S1032, this application targets specific functional modules, such as dedicated test modules or dft_mux modules related to Design for Testability (DFT), which require connection to the global test clock and test control mode signals. Therefore, when generating instantiation code for such specific modules, if it is detected that their test ports are not explicitly connected in the graphics and are in a floating state, the application searches for preset global system ports, such as the global test clock (test_clk) and test control mode (test_mode) ports, and automatically connects them to the preset global system ports, such as the global test clock (test_clk) and test control mode (test_mode) ports, to supplement the generation of default connection code, thereby reducing the risk of designers missing test specifications.

[0045] This application also maintains a mapping configuration table from logical module names to physical primitive names. This table allows graphic files to use generic, abstract module names (such as the generic `mux_4to1`) and dynamically map them to the exact module names specified by a specific process library or project during the code generation phase, thereby improving the reusability of graphics.

[0046] Example 2 This application also provides an automatic generation system for chip clock control code, such as... Figure 4 The diagram shows a block diagram of an automatic chip clock control code generation system. This system implements functions corresponding to the steps of the aforementioned automatic chip clock control code generation method executed on a terminal device. The device can be understood as a server component including a processor. The automatic chip clock control code generation system described in this application includes: The acquisition module 401 is used to acquire a structured file provided by the user that contains a chip clock tree structure, and to identify and extract various hardware elements from the structured file according to a preset mapping rule. The module 402 is used to establish an initial netlist topology based on the ports / modules and corresponding signal connections in the various hardware elements. Through target merging rules, the signal connections in the initial netlist topology are automatically sorted out to obtain the netlist topology. The execution module 403 is used to execute a target code language generation strategy to obtain multiple instantiated codes based on the netlist topology diagram and the corresponding connection signals, and assemble the multiple instantiated codes to obtain the control code corresponding to the chip clock.

[0047] In one feasible implementation, the module includes: The signal connection sorting logic is configured with a naming initialization stage, an explicit overriding stage, a homogeneous clustering stage, and an attribute alignment stage. The pre-configured sorting methods are executed in the naming initialization phase, explicit overriding phase, homogeneous clustering phase, and attribute alignment phase respectively to automatically sort the signal connections.

[0048] In one feasible implementation, the module further includes: Extract the source node identifier of the driving source to which the signal connection without a display name belongs, and clean the source node identifier; Based on the signal flow direction, a preset suffix identifier is automatically added to the signal connection after the cleaning process is completed, generating an initial signal name.

[0049] In one feasible implementation, the module also includes: The text annotations added by the designer to the graphic connections are analyzed, and the explicit signal names and bit width annotation information are captured simultaneously. The captured explicit signal name and bit width constraint are used as the highest priority to override the generated initial signal name and its corresponding bit width information.

[0050] In one feasible implementation, the module further includes: Based on the initial netlist topology graph, traverse and cluster the network to classify all branch connections connected to the same output port into the same signal network. The same signal network is sequentially aligned with signal name attributes and signal bit width attributes to obtain a netlist topology after alignment.

[0051] In one feasible implementation, the acquisition module includes: Traverse the chip clock tree structure in the structured file and read the attribute fields of multiple primitive nodes; the attribute fields include type identifiers and label attributes; Based on the type identifier and label attribute, determine the hardware element type corresponding to the primitive node and extract the name and bit width label information of each hardware element.

[0052] In one feasible implementation, the execution module includes: For a specific pre-defined functional module, check whether its preset port is connected in the netlist topology diagram; If not, search for the preset global system port and automatically connect the preset port to the global system port.

[0053] Example 3 This application also provides an electronic device, such as Figure 5 As shown, it includes: a processor 501, a memory 502, and a bus 503. The memory 502 stores machine-readable instructions that can be executed by the processor 501. When the electronic device is running, the processor 501 and the memory 502 communicate through the bus 503. When the machine-readable instructions are executed by the processor 501, the steps of any one of the chip clock control code automatic generation methods described above are executed.

[0054] Example 4 This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of any one of the chip clock control code automatic generation methods described above.

[0055] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and devices described above can be referred to the corresponding processes in the method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection can be through some communication interfaces; the indirect coupling or communication connection of devices or modules can be electrical, mechanical, or other forms.

[0056] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0057] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0058] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a platform server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0059] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.< / path> < / text> < / rect> < / userobject>

Claims

1. A method for automatically generating chip clock control code, characterized in that, The method includes: Obtain a structured file containing a chip clock tree structure provided by the user, and identify and extract various hardware elements from the structured file according to preset mapping rules; An initial netlist topology is established based on the ports / modules and corresponding signal connections in the various hardware elements. The signal connections in the initial netlist topology are automatically sorted out using target merging rules to obtain the netlist topology. Based on the netlist topology and the corresponding connection signals, a target code language generation strategy is executed to obtain multiple instantiated codes, and the multiple instantiated codes are assembled to obtain the control code corresponding to the chip clock.

2. The method according to claim 1, characterized in that, The step of automatically sorting out the signal connections in the initial netlist topology graph using target merging rules to obtain the netlist topology graph includes: The signal connection sorting logic includes a naming initialization stage, an explicit overriding stage, a homogeneous clustering stage, and an attribute alignment stage. The pre-configured sorting methods are executed in the naming initialization phase, explicit overriding phase, homogeneous clustering phase, and attribute alignment phase respectively to automatically sort the signal connections.

3. The method according to claim 2, characterized in that, The pre-configured sorting methods are executed in the naming initialization phase, explicit overriding phase, homogeneous clustering phase, and attribute alignment phase, respectively, including: Extract the source node identifier of the driving source to which the signal connection without a display name belongs, and clean the source node identifier; Based on the signal flow direction, a preset suffix identifier is automatically added to the signal connection after the cleaning process is completed, generating an initial signal name.

4. The method according to claim 3, characterized in that, The pre-configured sorting methods are executed in the naming initialization phase, explicit overriding phase, homogeneous clustering phase, and attribute alignment phase, respectively, including: The text annotations added by the designer to the graphic connections are analyzed, and the explicit signal names and bit width annotation information are captured simultaneously. The captured explicit signal name and bit width constraint are used as the highest priority to override the generated initial signal name and its corresponding bit width information.

5. The method according to claim 4, characterized in that, The pre-configured sorting methods are executed in the naming initialization phase, explicit overriding phase, homogeneous clustering phase, and attribute alignment phase, respectively, including: Based on the initial netlist topology graph, traverse and cluster the network to classify all branch connections connected to the same output port into the same signal network. The same signal network is sequentially aligned with signal name attributes and signal bit width attributes to obtain a netlist topology diagram after alignment.

6. The method according to claim 1, characterized in that, Based on preset mapping rules, various hardware elements are identified and extracted from the structured file, including: Traverse the chip clock tree structure in the structured file and read the attribute fields of multiple primitive nodes; the attribute fields include type identifiers and label attributes; Based on the type identifier and label attribute, determine the hardware element type corresponding to the primitive node and extract the name and bit width label information of each hardware element.

7. The method according to claim 1, characterized in that, Based on the netlist topology and corresponding connection signals, a target code language generation strategy is executed to obtain various instantiated codes, including: For a specific pre-defined functional module, check whether its preset port is connected in the netlist topology diagram; If not, search for the preset global system port and automatically connect the preset port to the global system port.

8. An automatic generation system for chip clock control code, characterized in that, The system includes: The acquisition module is used to acquire a structured file provided by the user that contains a chip clock tree structure, and to identify and extract various hardware elements from the structured file according to preset mapping rules. A module is established to create an initial netlist topology based on the ports / modules and corresponding signal connections among the various hardware elements. Through target merging rules, the signal connections in the initial netlist topology are automatically sorted out to obtain the netlist topology. The execution module is used to execute the target code language generation strategy to obtain multiple instantiated codes based on the netlist topology diagram and the corresponding connection signals, and assemble the multiple instantiated codes to obtain the control code corresponding to the chip clock.

9. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, the steps of an automatic generation method for chip clock control code as described in any one of claims 1 to 7 are performed.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of an automatic generation method for chip clock control code as described in any one of claims 1 to 7.

Images