Method, device and system for generating a clock management file

Abstract

The present disclosure provides a clock management file generation method, device and system, and relates to the technical field of integrated circuit design. The method comprises the following steps: in response to receiving clock and reset demand update information, determining a target sub-level code to be updated in a clock management file and a target timing constraint item acting on the target sub-level code; wherein the clock management file is generated based on a preset demand configuration file, the clock management file comprises register transfer RTL (Register Transfer Language) code and a timing constraint item acting on the RTL code, and the target sub-level code is any one of a plurality of sub-level codes included in the RTL code; performing incremental update on the target sub-level code and the target timing constraint item according to the demand update information, and generating an updated clock management file. The method reduces the development repetition rate, and makes the obtained clock management file more in line with the use demand.

Description

Technical Field

[0001] This disclosure relates to the field of integrated circuit design technology, specifically to a method for generating clock management files, a device for generating clock management files, a system for generating clock management files, an electronic device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] In the design of a System-on-Chip (SoC), the clock and reset subsystem is the infrastructure layer that ensures the normal operation of the chip. However, because the clock and reset requirements are distributed and different developers write and maintain the register transfer module and the clock constraints acting on that module, the clock and reset subsystem may not meet the actual clock and reset requirements. This leads to inaccurate timing in the system, and when the clock and reset requirements change, repeated code-level updates are required, reducing development efficiency. Summary of the Invention

[0003] This disclosure provides a method for generating clock management files, a device for generating clock management files, a system for generating clock management files, an electronic device, a computer-readable storage medium, and a computer program product.

[0004] In a first aspect, embodiments of this disclosure propose a method for generating a clock management file. The method includes: in response to receiving clock and reset requirement update information, determining the target sub-code and target timing constraint entries acting on the target sub-code that need to be updated in the clock management file; wherein the clock management file is generated based on a preset requirement configuration file, the clock management file includes register transfer RTL code and timing constraint entries acting on the RTL code, and the target sub-code is any one of multiple sub-codes included in the RTL code; incrementally updating the target sub-code and target timing constraint entries according to the requirement update information to generate an updated clock management file.

[0005] Secondly, embodiments of this disclosure also provide a clock management file generation apparatus, the apparatus comprising: a determining module configured to, in response to receiving clock and reset requirement update information, determine a target sub-code and a target timing constraint entry acting on the target sub-code in the clock management file; wherein the clock management file is generated based on a preset requirement configuration file, the clock management file includes register transfer RTL code and timing constraint entries acting on the RTL code, and the target sub-code is any one of a plurality of sub-codes included in the RTL code; and an incremental update module configured to incrementally update the target sub-code and the target timing constraint entry according to the requirement update information, thereby generating an updated clock management file.

[0006] Thirdly, embodiments of this disclosure also provide a clock management file generation system, the system comprising: a requirement acquisition layer configured to acquire clock and reset requirement information; a configuration layer configured to store the clock and reset requirement information in a requirement configuration file based on a structured format; a clock management file generation layer configured to implement a clock management file generation method as described in any implementation of the first aspect to obtain an updated clock management file; and an output layer configured to output the updated clock management file.

[0007] Fourthly, embodiments of this disclosure provide 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 implement a method for generating a clock management file as described in any implementation of the first aspect.

[0008] Fifthly, embodiments of this disclosure provide a non-transitory computer-readable storage medium storing computer instructions that enable a computer, when executed, to implement a method for generating a clock management file as described in any implementation of the first aspect.

[0009] In a sixth aspect, embodiments of this disclosure provide a computer program product, including a computer program that, when executed by a processor, implements a method for generating a clock management file as described in any implementation of the first aspect.

[0010] The clock management file generation method provided in this disclosure generates register transfer RTL code and timing constraint entries acting on the RTL code based on a preset requirement configuration file. This enables code style consistency and reduces the proportion of errors introduced by manual coding. Upon receiving clock and reset requirement update information, the method determines the target sub-code and target timing constraint entries acting on the target sub-code that need to be updated. Based on the requirement update information, the method incrementally updates the target sub-code and target timing constraint entries. This not only makes the updated clock management file more in line with clock reset requirements but also greatly reduces development redundancy and makes the obtained clock management file more in line with user needs. Attached Figure Description

[0011] Other features, objects, and advantages of this disclosure will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 A flowchart illustrating a method for generating a clock management file provided in this embodiment of the disclosure; Figure 2A structural block diagram of a clock management file generation system provided in this embodiment of the disclosure; Figure 3 A flowchart illustrating another method for generating a clock management file provided in this disclosure embodiment; Figure 4 A flowchart illustrating an information parsing and verification method provided in this embodiment of the disclosure; Figure 5 A flowchart illustrating a method for evaluating demand update information provided in this embodiment of the disclosure; Figure 6 A flowchart illustrating an incremental update method provided in an embodiment of this disclosure; Figure 7 A schematic diagram illustrating a method for constructing a bidirectional traceability index provided in an embodiment of this disclosure; Figure 8 A flowchart of an instantiation method provided in an embodiment of this disclosure; Figure 9 A block diagram of a clock management file generation apparatus provided in this disclosure embodiment; Figure 10 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0012] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding; these should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description. It should be noted that, unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0013] In some related technical solutions, a SoC typically contains multiple subsystems with different functions. Each subsystem has its own corresponding clock and reset requirements. However, these different clock and reset requirements are scattered and written and maintained by different developers. This makes it impossible for the clock and reset subsystem to fully meet the clock and reset requirements of each subsystem, resulting in clock conflicts and other anomalies between the subsystems.

[0014] In other related technical solutions, since chip design goes through multiple design cycles, clock and reset requirements change frequently. If only some developers modify the code while other corresponding timing constraints are not modified, errors may occur in the chip processing, reducing the chip's stability.

[0015] Furthermore, manual maintenance of the clock and reset subsystem code often leads to problems such as spelling errors in signal names, missing port connections, incorrect calculation of frequency division coefficients, and incorrect configuration of synchronization stages due to manual coding. It also results in inconsistent coding styles due to different developers, which not only hinders maintenance but also increases the difficulty of code review and backend maintenance.

[0016] To address at least one problem existing in the above embodiments, this disclosure proposes a method for generating clock management files, a device for generating clock management files, a system for generating clock management files, an electronic device, a computer-readable storage medium, and a computer program product.

[0017] Figure 1 This is a flowchart illustrating a method for generating a clock management file according to an embodiment of the present disclosure. This method can be applied to a clock management file generation apparatus.

[0018] like Figure 1 As shown, the method specifically includes the following steps.

[0019] Step 101: In response to receiving the clock and reset requirement update information, determine the target sub-codes that need to be updated in the clock management file and the target timing constraint entries that act on the target sub-codes.

[0020] Among them, the requirement update information is the requirement information for updating the clock and / or reset.

[0021] The clock management file is generated based on a pre-defined requirements configuration file. For example, based on the same requirements configuration file, Register Transfer Level (RTL) code and timing constraint entries that act on the RTL code are generated synchronously. This ensures that the RTL code and timing constraint entries are synchronized, avoiding timing analysis errors, backend implementation errors, and iterative fixes caused by asynchrony between the RTL and timing constraint entries. Compared to traditional manual coding methods, this significantly improves coding speed and efficiency.

[0022] It should be noted that synchronously generating RTL code and its corresponding timing constraint entries ensures that the timing constraint entries for the RTL code meet the usage requirements of the RTL code. For example, if they are generated under the same clock (or related clock) at the same tick, the timing constraint entries constrain each sub-code in the RTL code so that each sub-code can work sequentially according to the corresponding timing relationship.

[0023] In some embodiments, clock management files can be generated by using a template skeleton combined with parameter population. For example, configuration parameters stored in the requirements configuration file can be populated into a predefined template in a predetermined format, thereby quickly generating clock management files.

[0024] The clock management file includes RTL code and timing constraint entries that apply to the RTL code. The target sub-code is any one of the multiple sub-codes included in the RTL code. The target timing constraint entry is used to apply timing constraints to the target sub-code.

[0025] RTL code is hardware functionality code described using a hardware description language, which has clearly defined interface boundaries and internal register logic. The hardware description language can include any of the following: Verilog, Very-High-Speed ​​Integrated Circuit Hardware Description Language (VHDL), SystemVerilog, etc.

[0026] Among them, timing constraint entries are the smallest semantic units in the timing constraint file that exist in the form of commands and are used to declare clock relationships, input / output time boundaries, path analysis rules, and environment. They are a prerequisite for the correctness of static timing analysis.

[0027] This step aims to generate RTL code and timing constraint entries that apply to the RTL code based on the same requirements configuration file. Then, upon obtaining requirements update information, it determines the target sub-code that needs to be updated from the multiple sub-codes included in the RTL code, as well as the target timing constraint entries that apply to the target sub-code, thereby facilitating subsequent updates.

[0028] Among them, the target sub-code is the sub-code that can solve the requirement update information. In other words, the requirement update information representation needs to update the target sub-code so that the updated target sub-code can meet the requirements of the requirement update information and better realize the corresponding function.

[0029] Step 102: Incrementally update the target sub-level code and target timing constraint entries according to the requirement update information, and generate the updated clock management file.

[0030] Incremental update is an update method that only updates the target sub-level code and the target timing constraint entries, while keeping other sub-level codes in the clock management file unchanged except for the target sub-level code.

[0031] This step aims to update only the target sub-code and target timing constraint entries based on the requirements of the requirement update information (e.g., regenerating the target sub-code). This not only satisfies the requirements of the requirement update information but also shortens the code update time and improves the update efficiency of the clock management file.

[0032] The clock management file generation method provided in this disclosure generates register transfer RTL code and timing constraint entries acting on the RTL code based on a preset requirement configuration file. This enables code style consistency and reduces the proportion of errors introduced by manual coding. Upon receiving clock and reset requirement update information, the method determines the target sub-code and target timing constraint entries acting on the target sub-code that need to be updated. Based on the requirement update information, the method incrementally updates the target sub-code and target timing constraint entries. This not only makes the updated clock management file more in line with clock reset requirements but also greatly reduces development redundancy and makes the obtained clock management file more in line with user needs.

[0033] In some optional implementations of the embodiments of this disclosure, the clock management file includes: a first clock control RTL code and a first type of timing constraint entry acting on the first clock control RTL code; wherein, the first clock control RTL code is used to control the clock and reset within a clock domain; and the first type of timing constraint entry is used to constrain the timing relationship between the clock and the enable signal.

[0034] For example, using a single requirements configuration file crg_config.yaml, different generators can be used to generate the first clock control RTL code and the first type of timing constraint entries. For instance, the requirements configuration file crg_config.yaml can be input into the function CRGRTLGenerator to generate the first clock control RTL code, and simultaneously, the requirements configuration file crg_config.yaml can be input into the function SDCGenerator to generate the first type of timing constraint entries. Then, the first clock control RTL code and the first type of timing constraint entries can be output to the corresponding memory address for subsequent calls.

[0035] This embodiment aims to synchronously generate a first clock control RTL code and a first type of timing constraint entries within a clock domain, so as to quickly obtain a first clock control RTL code with the same programming style that processes a clock domain, and a first type of timing constraint entries that act on the first clock control RTL code to constrain the timing relationship between clock domain enable signals in the first clock control RTL code.

[0036] For example, when the clock frequency configured for a clock domain is 1000 MHz, the generated first clock control RTL code is the clock gating sub-code for that clock domain, and the first type of timing constraint entry can be the create_clock constraint, with a corresponding clock period of 1.000.

[0037] In some optional implementations of the embodiments of this disclosure, the first type of timing constraint entries includes: clock generation constraint entries and clock gating constraint entries; the clock generation constraint entries are used to constrain the generation of the clock, and the clock gating constraint entries are used to constrain the switching state of the clock.

[0038] For example, when the clock frequency configured for a clock domain is 1000MHz, the generated clock generation constraint entry is the create_clock constraint, and its corresponding clock period is 1.000; the clock gating constraint entry is the set_clock_gating_check constraint, which defines the setup and hold time requirements of the enable signal of the clock gating sub-code relative to the clock signal, in order to prevent glitches or truncated pulses from occurring in the gated clock output.

[0039] For example, the clock gating subcode can be any of the following: Integrated Clock Gating (ICG) subcode, AND gated subcode, or OR gated subcode.

[0040] In some embodiments, the create_clock constraint is bound to the port or pin of the chip where the clock management file is located; the set_clock_gating_check constraint is bound to the clock control object to more specifically influence the processing logic of the RTL code.

[0041] This embodiment aims to achieve more refined clock management by limiting the constraint type of the first type of timing constraint entries, and by using clock-generated constraint entries and clock-gated constraint entries to more precisely define the clock constraint conditions within a clock domain.

[0042] In some optional implementations of the embodiments of this disclosure, the clock management file includes: a second clock control RTL code and a second type of timing constraint entries acting on the second clock control RTL code; wherein, the second clock control RTL code is used to control the clock and reset in multiple clock domains; and the second type of timing constraint entries are used to constrain the timing relationship between multiple clock domains.

[0043] Specifically, when asynchronous processing logic is started (e.g., the async flag in the configuration parameters is set to true), a second clock control RTL code and a second type of timing constraint entries are generated based on the same requirement configuration file. This allows the second clock control RTL code to control the clock and reset in multiple clock domains, and the second type of timing constraint entries to constrain the timing relationships between multiple clock domains.

[0044] Asynchronous Logic / Clock Domain Crossing (CDC) is a core principle in static timing analysis, used to examine the timing logic of clock setup or clock hold in different clock domains. The corresponding second type of timing constraint mainly cuts off timing analysis across clock paths while declaring asynchronous relationships.

[0045] For example, the second type of timing constraint entries includes timing constraint entries corresponding to multiple clock domains. Each clock domain can correspond to a set of timing constraint entries, and the clock and reset in each clock domain are constrained based on multiple sets of timing constraint entries.

[0046] This embodiment aims to achieve multi-point clock synchronization across clock domains, and simultaneously generate a second clock control RTL code and a second type of timing constraint entries through a single requirements configuration file, thereby realizing constraints between multiple clock domains.

[0047] In some embodiments, a requirement configuration file crg_config.yaml is parsed to obtain the configuration parameters described in the requirement configuration file that represent the handling of clock and reset in multiple clock domains; then, these configuration parameters are verified, and if the verification is successful, these configuration parameters are respectively input into different generators to generate second clock control RTL code and second type of timing constraint entries.

[0048] For example, the verified configuration parameters are input into the function CRGRTLGenerator to generate the second clock control RTL code (e.g., a file with the extension ".v"). At the same time, the requirement configuration file crg_config.yaml is input into the function SDCGenerator to generate the second type of timing constraint entries (e.g., a file with the extension ".sdc"). Then, the second clock control RTL code and the second type of timing constraint entries are output to the corresponding memory address for subsequent calls.

[0049] In some embodiments, configuration parameters are stored in the requirements configuration file in the form of a Python dictionary (dict), that is, in the form of key-value pairs. Then, a predefined template is read by the template engine, and the above configuration parameters are filled into the predefined template to generate Verilog code. The Verilog code can perform the functions of the RTL code corresponding to the requirements configuration file and the timing constraint entries that act on the RTL code.

[0050] By filling configuration parameters into predefined templates, RTL code and corresponding timing constraint entries can be generated. This not only maintains a consistent coding style and ensures that all generated code follows a unified format specification, such as maintaining consistency in indentation, naming, and comment style, thereby improving code maintainability, but also greatly improves coding speed.

[0051] In some optional implementations of the embodiments of this disclosure, the second type of timing constraint entries includes: clock group constraint entries and / or path constraint entries; the clock group constraint entries include timing constraint entries of multiple clock groups, the timing constraint entries of any two clock groups are mutually exclusive, and the clock sources corresponding to any two clock groups are different.

[0052] The clock group constraint entries can be implemented using the set_clock_groups constraint, which is a clock relationship level constraint to facilitate global management of clocks in multiple clock domains.

[0053] Path constraint entries can be implemented using the `set_false_path` constraint. For example, the `set_false_path` constraint can be bound to a pin on the chip corresponding to the clock management file, or to the clock itself, etc.

[0054] This embodiment aims to constrain the timing synchronization and reset within multiple clock domains in the second clock control RTL code by limiting the specific type of the second type of timing constraint entries, so that each sub-level code in the second clock control RTL code can work sequentially based on synchronized timing, thereby improving work efficiency.

[0055] Regarding the process of determining the target sub-level code and target timing constraint entries in step 101 of the above embodiment, a specific implementation method is given below.

[0056] In some optional implementations of the embodiments of this disclosure, the requirement configuration file includes configuration parameters that characterize clock and reset requirement information, and the correspondence between each configuration parameter and each sub-level code in the RTL code and its corresponding timing constraint entry is stored in a configuration-output mapping table.

[0057] In step 101, in response to the received clock and reset requirement update information, the target sub-code and the target timing constraint entries that need to be updated in the clock management file are determined. This can be achieved as follows: determine the updated configuration parameters based on the requirement update information; and based on the updated configuration parameters, search the configuration-output mapping table to determine the target sub-code and the target timing constraint entries.

[0058] The configuration parameters include at least one of the following: the number of clock domains, the start switch of the multi-level register buffer corresponding to each clock domain, the clock frequency information and reset information corresponding to each clock domain, the clock gating information in each clock domain, and the enable signal information.

[0059] It should be noted that before configuration parameters are used, they need to be checked to ensure their accuracy. For example, at least one of the following checks should be performed on the configuration parameters: field integrity check, clock frequency reasonableness check, synchronization level validity check, and clock source reference integrity check.

[0060] In some embodiments, upon obtaining updated requirement information, an updated requirement configuration file is obtained by modifying the requirement configuration file (e.g., a requirement configuration file stored in YAML format). Then, the updated requirement configuration file is compared with the original requirement configuration file to obtain the updated configuration parameters. These updated configuration parameters include parameter update types. If the parameter update type is the same as the original configuration parameter's parameter type, but the parameter value has changed, then by using the parameter update type as an index to look up the configuration-output mapping table, the target sub-level code and target timing constraint entries corresponding to that parameter update type can be obtained. This is because the configuration-output mapping table stores multiple configuration parameter types, their corresponding sub-level codes, and timing constraint entries acting on those sub-level codes.

[0061] Furthermore, updating the target sub-code and target timing constraint entries will satisfy the update requirements. Compared to the conventional approach of manually modifying code for each project, this method allows for faster identification of the target sub-code and target timing constraint entries that need modification, enabling precise adjustments and improving code modification efficiency.

[0062] In some embodiments, after modifying the target sub-code and target timing constraint entries, it is also necessary to synchronously update the configuration-output mapping table to facilitate future lookups.

[0063] In some optional implementations of the embodiments of this disclosure, the configuration-output mapping table further includes: first position information of configuration parameters in the requirements configuration file, and second position information of each sub-level code and its corresponding timing constraint entry in the RTL code.

[0064] The configuration-output mapping table can be stored in two ways: forward storage and / or reverse storage. Forward storage is a key-value pair storage method where the first position information is the key and the second position information is the value. Reverse storage is a key-value pair storage method where the second position information is the key and the first position information is the value.

[0065] Both forward storage and / or reverse storage are key-value pair storage methods, but the corresponding query results are different. This allows for quick retrieval of sub-level code and its corresponding target time-series constraint entries through configuration parameters, or retrieval of configuration parameters through target sub-level code (or target time-series constraint entries), achieving bidirectional tracing across the entire chain and improving update efficiency.

[0066] In some embodiments, the configuration-output mapping table can also store key-value pairs, using the chapter information of the design document corresponding to the configuration parameter as the value and the first position information (or, or, the second position information) as the key. This allows the system to find the chapter information in the design document that explains the configuration parameter (or target sub-code, or target timing constraint entry) by corresponding to the configuration parameter (or target sub-code, or target timing constraint entry). This facilitates the synchronous updating of the corresponding design document when the configuration parameter (or target sub-code) is updated, ensuring that every configuration change is traceable and verifiable, thus achieving traceability of parameters or code.

[0067] In some optional implementations of the embodiments of this disclosure, the configuration-output mapping table further includes: chapter information of the design document corresponding to the configuration parameters.

[0068] The method for generating clock management files in this disclosure further includes generating an update log based on the updated configuration parameters, the target sub-level code in the updated clock management file, the target timing constraint entries, and the chapter information of the design document.

[0069] The update log contains relevant information about the changes, allowing testers to determine which configuration parameters or sub-code were modified in each update, as well as the corresponding section information in the design document, thus enabling update tracking.

[0070] In some optional implementations of the embodiments of this disclosure, the updated configuration parameters include parameter update values; before incrementally updating the target sub-level code and target timing constraint entries according to the demand update information in step 102 to generate the updated clock management file, the method further includes: obtaining a first hash value of the parameter values ​​of the original configuration parameters corresponding to the target sub-level code; and performing a hash operation on the parameter update values ​​corresponding to the target sub-level code to obtain a second hash value; in response to the difference between the first hash value and the second hash value, determining that the target sub-level code is the sub-level code that needs to be updated; Correspondingly, in step 102, the target sub-level code and target timing constraint entries are incrementally updated based on the requirement update information, generating an updated clock management file, including: Based on the current configuration parameters corresponding to the target sub-code, the target sub-code is regenerated to obtain the updated target sub-code; the target timing constraint entries are updated to obtain the updated target timing constraint entries; and the updated clock management file is determined based on the updated target sub-code and the updated target timing constraint entries.

[0071] Once the target sub-code is found, it indicates that the updated configuration parameters are recorded in the target sub-code. However, whether the target sub-code needs to be updated still needs to be determined based on the comparison result of the first hash value and the second hash value.

[0072] In some optional implementations of the embodiments of this disclosure, the method for generating clock management files in this disclosure further includes: in response to the first hash value being the same as the second hash value, keeping the target sub-level code and the target timing constraint entries unchanged.

[0073] If the first hash value and the second hash value are the same, it means that the parameter update value in the target sub-code is the same as the parameter value of its corresponding original configuration parameter. In this case, there is no need to modify or update the target sub-code. Keep the target sub-code and the target timing constraint entries unchanged to reduce the amount of code modification.

[0074] If the first hash value and the second hash value are different, it means that the parameter update value in the target sub-code is different from the parameter value of its corresponding original configuration parameter. At this time, the target sub-code is determined to be the sub-code that needs to be updated. That is, the target sub-code needs to be updated based on the parameter update value, such as regenerating the target sub-code, so as to obtain the updated target sub-code that meets the configuration requirements of the updated configuration parameters. Furthermore, the target timing constraint entries are updated.

[0075] In this embodiment, by calculating and comparing hash values, it is determined whether to update the target sub-level code, which can ensure the security of the code update (or the regeneration of the target sub-level code) process and achieve accurate updates.

[0076] In some optional implementations of the embodiments of this disclosure, after executing step 101 in response to receiving the clock and reset requirement update information, and before executing step 101 in determining the target sub-code that needs to be updated in the clock management file and the target timing constraint entries acting on the target sub-code, the method for generating the clock management file in this disclosure further includes: Analyze the updated requirements information to determine the impact of the changes; based on the impact information, determine the risk level of the changes; and in response to the review results regarding the risk level of the changes, determine that the clock management files need to be updated.

[0077] Among them, the change impact information is information that characterizes the scope and degree of impact of the requirement update on the clock management file; the change risk level is information that characterizes the degree of impact of changes to the clock and reset requirement information on the stability of the clock management file.

[0078] It should be noted that different risk levels correspond to different review levels. For example, risk levels include high risk, medium risk, and low risk.

[0079] The highest level of review corresponds to a high-risk level, such as requiring at least two reviewers to review the change and obtain a result. The next highest level of review corresponds to a medium-risk level, such as requiring at least one reviewer to review the change and obtain a result. The lowest level of review corresponds to a low-risk level, such as requiring no review and directly determining whether the clock management file needs to be updated based on the change type.

[0080] The review results for changing the risk level include: approved and unapproved. If the review result is approved, the clock management file needs to be updated; if the review result is unapproved, the clock management file does not need to be updated.

[0081] In this embodiment, the risk level of the change is determined by analyzing the information on the requirement update. Then, based on different review mechanisms, different risk levels of the change are reviewed to determine whether the code needs to be updated, so as to achieve risk control in the update process.

[0082] In some optional implementations of the embodiments of this disclosure, determining the change risk level based on the change impact information includes: determining the change risk level based on the change type and impact scope in the change impact information.

[0083] The impact information includes the change type and the scope of impact. The change type includes at least one of the following: parameter modification, adding a module, or deleting a module; the scope of impact includes at least one of the following: RTL code list, SDC constraint item list, or document chapter list.

[0084] The risk level change includes at least three levels, with each level corresponding to a different review level.

[0085] For example, if the change type is adding or deleting a module, the corresponding scope of impact includes the RTL code list, the SDC constraint item list, and the document chapter list. In this case, the change risk level can be determined as high risk.

[0086] For example, if the change type is parameter modification, the corresponding impact scope may only include the RTL code list. In this case, the change risk level can be determined as medium risk.

[0087] For example, if the change type is a modification of the parameter explanation in parameter modification, the corresponding impact scope only includes the explanation of a certain line of code in the RTL code. In this case, the change risk level can be determined to be low risk level.

[0088] This disclosure embodiment defines the change risk level specifically based on the change type and scope of impact, which refines the determination and review methods for change risk levels. Under the premise of ensuring system security, code-level modifications are made to the clock management file, thereby improving code stability.

[0089] In traditional clock management circuits, the gate enable signal needs to pass through a cross-clock domain synchronizer before it can directly drive the ICG. With the updating of process node types, the clock frequency is constantly increasing, and the steepness of the clock edge is increasing, leading to increasingly serious electromagnetic interference problems.

[0090] In some optional implementations of the embodiments of this disclosure, the method for generating the clock management file in this disclosure includes not only the steps 101-102 described above, but also the following: when the clock management file is packaged using a first process node type, the obtained synchronized enable signal is processed based on a multi-level register buffer to obtain a target enable signal; and the second clock control RTL code is instantiated according to the target enable signal to obtain the instantiated second clock control RTL code.

[0091] Among them, the synchronized enable signal is the signal used to synchronize the target clock domain with other clock domains. The target enable signal is used to authorize the enable time in the target clock domain. This enable time is the start time when the second clock control RTL code can perform data sampling or start control actions (such as resource scheduling or data distribution).

[0092] In some embodiments, the multi-level register buffer can be implemented using multi-phase clock tree synthesis (MPCTS). By inserting multi-level register buffers into the enable signal path, the synchronized enable signal is re-tied, so that the edge of the synchronized enable signal is better aligned with the clock edge, thereby reducing the instantaneous current spike during clock gating switching and improving electromagnetic compatibility performance.

[0093] The first process node type refers to the physical and structural properties of the manufacturing technology itself. For example, a chip using this first process node type is a chip with a size smaller than or equal to a preset size threshold (e.g., 5nm).

[0094] The synchronized enable signal is an enable signal that operates across clock domains; in other words, the synchronized enable signal comes from another clock domain. For example, after clock domain A and clock domain B are synchronized, clock domain B receives the synchronized enable signal from clock domain A so that clock domain A and clock domain B can remain synchronized according to this enable signal.

[0095] This step aims to process the acquired synchronized enable signal using a multi-level register buffer to obtain a target enable signal with a stable state. Because multi-level registers can store signals in a time-division manner, the initially stored metastable enable signal can be buffered over time by multiple levels of registers to produce a final output signal with a stable target enable signal. Based on this target enable signal, the second clock control RTL code can be instantiated more stably, improving the stability of the instantiation process.

[0096] For example, for clock-gated sub-code in RTL code, it can be instantiated at the top level based on the target enable signal so that the clock-gated sub-code can obtain the clock signal, enable signal and corresponding input signal; the clock gating constraint entries acting on the clock-gated sub-code are constraint entries acting on the instantiated clock-gated sub-code.

[0097] For example, for the asynchronous synchronous sub-code in the second clock control RTL code, the sub-code can be instantiated at the point where the clocks cross, so that the two sub-codes with different clock sources can be synchronized based on asynchronous constraints.

[0098] In some optional implementations of the embodiments of this disclosure, the second clock control RTL code includes clock gating sub-level code; the acquired synchronized enable signal is processed based on a multi-level register buffer to obtain the target enable signal, including: in response to starting the multi-level register and receiving a clock trigger signal, acquiring the synchronized enable signal; assigning values ​​to the multi-level registers corresponding to the target clock domain according to the synchronized enable signal, and using the value output by the last level register of the multi-level registers as the target enable signal.

[0099] The target enable signal is used to enable the clock domain corresponding to the authorized clock gating sub-code. This enable moment indicates that from this moment onwards, the clock gating sub-code can begin acquiring data or performing corresponding resource scheduling operations. Because the target enable signal is determined through multi-level register buffering, it has better stability, ensuring more stable synchronization signals between different clock domains.

[0100] It should be noted that instantiating the second clock control RTL code under the control of the target enable signal ensures that the instantiated second clock control RTL code does not contain conditional compilation instructions, making it more user-friendly for backend synthesis and placement and routing tools.

[0101] In this embodiment, the synchronized enable signal is buffered sequentially by a multi-level register based on the time dimension to make the synchronized enable signal tend to be stable. Furthermore, the value output by the last level register of the multi-level register is used as the target enable signal, which can ensure that the obtained target enable signal is an enable signal with a stable state. Then, the second clock control RTL code is instantiated based on the target enable signal, which ensures that the code corresponding to the obtained instantiated second clock control RTL code is instantiated under the enable of the signal in a stable state, thus ensuring the stability of the instantiation.

[0102] In some optional implementations of the embodiments of this disclosure, the multi-level register includes a first-level register and a second-level register connected in sequence; assigning a value to the multi-level register corresponding to the target clock domain according to the synchronized enable signal, and using the value output by the last-level register of the multi-level register as the target enable signal, includes: storing the synchronized enable signal in the first-level register; in response to receiving the next clock trigger signal, assigning the signal value stored in the first-level register to the second-level register; and using the signal value stored in the second-level register as the target enable signal.

[0103] The first-level register and the second-level register are two levels of registers connected in sequence. Each level of register has a different clock trigger signal, and the clock trigger signals of the two levels of registers have a certain timing relationship to ensure that the synchronized enable signal stored in the first-level register can gradually stabilize the state over time.

[0104] For example, the synchronized enable signal initially stored in the first-level register is in a metastable state. After one clock cycle, the state of the synchronized enable signal gradually transitions from metastable to stable. Thus, when the next clock trigger signal is received, the signal value stored in the first-level register is assigned to the second-level register, so that the stable signal value output by the second-level register can be used as the target enable signal. This ensures that the final target enable signals are all in a stable state, guaranteeing the stability of subsequent operations.

[0105] In some optional implementations of the embodiments of this disclosure, the second clock control RTL code includes reset synchronization sub-level code. The method for generating the clock management file in this disclosure further includes: in response to starting the multi-level register and receiving a reset trigger signal, clearing the multi-level register based on the reset synchronization sub-level code.

[0106] When a reset trigger signal is received, it indicates that the multi-level registers need to be reset. That is, the state of each register in the multi-level registers is forcibly set to a preset initial value (such as "0" or "1") to prevent the circuit from entering a chaotic state due to the uncertainty of the internal node level after power-on.

[0107] Specifically, the signal values ​​in the multi-level registers can be cleared by resetting the synchronization sub-level code, that is, the signal values ​​stored in each level of register are set to "0", so that the multi-level registers can be synchronized and the signal values ​​subsequently stored in each level of register can meet the corresponding timing requirements.

[0108] In some optional implementations of the embodiments of this disclosure, the method for generating the clock management file in this disclosure further includes: when the clock management file is packaged using a second process node type, using the obtained synchronized enable signal as the target enable signal.

[0109] Specifically, the chip size corresponding to the second process node type is larger than the chip size corresponding to the first process node type. For example, the chip size corresponding to the second process node type is a chip larger than a preset size threshold (e.g., 5nm).

[0110] In this embodiment, by defining different methods for acquiring the target enable signal based on different process node types, adaptive configuration of the processing methods for different process nodes can be achieved within the same set of code. This avoids the burden of maintaining multiple sets of code for different process nodes and reduces code maintenance workload. Furthermore, when it is determined that the clock management file is packaged using the second process node type, directly using the synchronized enable signal as the target enable signal allows for faster acquisition of the target enable signal, improving the data processing speed within the chip.

[0111] In some optional implementations of the embodiments of this disclosure, instantiating the second clock control RTL code according to the target enable signal to obtain the instantiated second clock control RTL code includes: determining the connection statement corresponding to the second clock control RTL code according to the target enable signal; and determining the instantiated second clock control RTL code according to the second clock control RTL code and its corresponding connection statement.

[0112] The connection statements can be implemented using consecutive assignment statements to connect the second clock control RTL code with other instantiated child code. For example, consecutive assignment statements can be implemented using the `assign` statement.

[0113] The assign statement is a Verilog statement that represents a continuous connection relationship in hardware. In this embodiment, the assign statement is used to connect the second clock control RTL code with other sub-level codes to realize the conversion of software code into implementable hardware wiring relationships.

[0114] This embodiment automatically generates connection statements for connecting the second clock control RTL code with other sub-level codes when triggered by the target enable signal. Without manual intervention, the second clock control RTL code can be connected with other sub-level codes, and / or the various sub-level codes in the second clock control RTL code can be connected to each other, generating instantiated second clock control RTL code, thus improving the efficiency of code instantiation.

[0115] Based on the same inventive concept as the above method, this disclosure also provides a clock management file generation system.

[0116] Figure 2 This is a structural block diagram of a clock management file generation system provided in an embodiment of this disclosure. Figure 2 As shown, the clock management file generation system 200 includes: The requirement acquisition layer 210 is configured to acquire clock and reset requirement information.

[0117] Configuration layer 220 is configured to store clock and reset requirement information in a requirement configuration file based on a structured format.

[0118] The clock management file generation layer 230 is configured to implement the clock management file generation method as described in any of the above implementations to obtain the updated clock management file.

[0119] Output layer 240 is configured to output the updated clock management file.

[0120] In this embodiment, the specific processing of the clock management file generation layer 230 and its resulting technical effects can be referred to separately. Figure 1 The relevant descriptions of the steps in the corresponding embodiments will not be repeated here.

[0121] The clock management file generation system provided in this disclosure generates register transfer RTL code and timing constraint entries acting on the RTL code based on a preset requirement configuration file. This enables code style consistency and reduces the proportion of errors introduced by manual coding. Upon receiving clock and reset requirement update information, the system determines the target sub-code and target timing constraint entries acting on the target sub-code that need to be updated. Based on the requirement update information, the system incrementally updates the target sub-code and target timing constraint entries. This not only makes the updated clock management file more in line with clock reset requirements but also greatly reduces development redundancy and makes the obtained clock management file more in line with user needs.

[0122] In some embodiments, clock and reset requirement information can be stored in a requirements configuration file in YAML format. This requirements configuration file serves as a single data source, and all output generation is based on this file.

[0123] In some embodiments, the configuration layer 220 is used to collect templates according to requirements and store the clock and reset requirement information input by the requirement acquisition layer 210 into the requirement configuration file.

[0124] The requirements gathering template is a template for storing information in a structured format. For example, if the requirements gathering template uses Markdown format, inputting clock and reset requirements into the template will generate a requirements configuration file with a structured format. Markdown is a lightweight markup language. Markdown format uses plain text to write documents and supports exporting to various formats, such as HTML, PDF, and Word. The file extension is usually .md or .markdown.

[0125] The requirements collection template may include at least one of the following information: clock domain name, frequency, division factor, gating strategy, reset strategy, and Design For Test (DFT) mode, which are mandatory fields. DFT modes are different operating modes used in chip testability design to test chip defects and verify logic, including scan mode, capture mode, and boundary scan mode.

[0126] In some embodiments, the clock management file generation layer 230 includes an RTL generator, an SDC constraint generator, and a document generator. The RTL generator is used to generate code-level RTL code based on configuration parameters in the configuration file, such as RTL code implemented in Verilog. The RTL generator also supports incremental generation, that is, based on requirement update information, it incrementally updates the target sub-code and the target timing constraint entries acting on the target sub-code in the RTL code to obtain the updated RTL code.

[0127] The SDC constraint generator generates timing constraint entries that act on the RTL code based on the configuration parameters in the configuration file. The documentation generator generates design documents and change reports for the code-level RTL code and its corresponding timing constraint entries.

[0128] In some embodiments, the updated clock management file output by the output layer 240 includes RTL code and SDC timing constraint entries acting on the RTL code, and may also output the corresponding design document and bidirectional traceability index file.

[0129] The bidirectional traceability index file stores a configuration-output mapping table, which includes the correspondence between each configuration parameter in the requirements configuration file and each sub-code in the RTL code and its corresponding timing constraint entries.

[0130] For example, the configuration-output mapping table also includes: the first position information of the configuration parameters in the requirements configuration file, and the second position information of each sub-level code and its corresponding timing constraint entries in the RTL code. The configuration-output mapping table can be stored in two ways: forward storage and / or reverse storage. Forward storage is a key-value pair storage method where the first position information is the key and the second position information is the value. Reverse storage is a key-value pair storage method where the second position information is the key and the first position information is the value.

[0131] By using the information stored in the configuration-output mapping table, it is easy to modify the RTL code corresponding to the configuration parameters, or to trace back to the corresponding configuration parameters based on the RTL code, thus improving modification efficiency.

[0132] For example, the configuration-output mapping table also includes the chapter information of the design document corresponding to the configuration parameters, so that the corresponding chapter of the design document can be updated synchronously when the configuration parameters are modified, ensuring the consistency between the code and the document.

[0133] Figure 3 A flowchart of another method for generating a clock management file provided in an embodiment of this disclosure.

[0134] like Figure 3 As shown, when the clock management file generation system executes the clock management file generation method, the steps performed include, but are not limited to, the following: Step 301: The requirement elicitation layer 210 obtains the requirement configuration file.

[0135] The requirement configuration file can be a file storing clock and reset requirement information in YAML format. For example, the clock and reset requirement information may include at least one of the following: project information, global configuration information, clock domain information, reset domain information, port configuration information, etc.

[0136] The project information includes at least one of the following: project name, version information, and process node type. Global configuration information includes at least one of the following: default synchronization level and multi-level register buffer start flag. Clock domain information includes at least one of the following: clock domain name, clock source, clock frequency, asynchronous flag, and related clock list. Reset domain information includes at least one of the following: reset domain name, synchronization level, assertion period, and release delay information. Port configuration information includes at least one of the following: clock gating information, frequency classification information, and port information corresponding to the enable signal.

[0137] Step 302: The configuration layer 220 parses and verifies the information stored in the configuration file to obtain the information verification result.

[0138] The information verification result includes whether the information verification was successful or failed.

[0139] In some embodiments, the method of verifying the information stored in the configuration file may include at least one of the following: verification of the integrity of required fields, verification of the reasonableness of clock frequency (e.g., whether the clock frequency value is within the range of 100~5000MHz), verification of the validity of synchronization level (e.g., determining whether the synchronization level is greater than or equal to a preset level threshold (e.g., 2 or 3 levels)), and verification of the integrity of clock source references (e.g., whether all referenced clock sources have been declared in the clock domain definition).

[0140] Step 303: If the information verification result is successful, the clock management file generation layer 230 generates the clock management file based on the requirement configuration file.

[0141] The clock management file includes: register-transmitted RTL code and timing constraint entries applied to the RTL code.

[0142] Since the RTL code and its corresponding timing constraint entries are generated based on the same requirement configuration file, the consistency of the code style can be guaranteed, which facilitates subsequent maintenance.

[0143] In some embodiments, a template skeleton combined with parameter population can be used to generate the clock management file. For example, a predefined template includes an immutable code structure and variable parameter placeholders. Then, the parameter values ​​stored in the configuration file are populated into the parameter placeholders of the predefined template, and the clock management file is selectively generated according to the configuration conditions. The predefined template corresponding to the clock gating sub-code includes at least one of the following code structures: module declaration, port definition, synchronizer instantiation, and clock gating unit instantiation. The parameter placeholders include the module name and the synchronization level.

[0144] For example, the requirements configuration file is a file that stores configuration parameters in YAML format. By mapping each configuration parameter in the requirements configuration file to code with explicit fields and types that can be statically analyzed by the program (such as Python code or VHDL code), the clock management file can be obtained.

[0145] The configuration conditions are based on the generation conditions applied to different clock domains. For example, the clock management file generation layer 230 can generate the clock management file in the following way: in response to the clock and reset requirement information stored in the configuration file, which is the clock gating processing requirement information for a clock domain, a first clock control RTL code for each clock domain is generated, and a first type of clock constraint entry applied to the first clock control RTL code is generated simultaneously.

[0146] The first clock control RTL code is used to control the clock and reset within a clock domain. The first clock control RTL code is a hardware logic unit implemented based on software coding. This unit may include clock sub-level code, reset sub-level code, etc.

[0147] Type I clock constraint entries are used to constrain the timing relationship between the clock and the enable signal. Type I clock constraint entries can also constrain the execution order of each sub-level code in the first clock control RTL code.

[0148] For example, the first type of clock constraint entries includes: clock generation constraint entries and clock gating constraint entries; clock generation constraint entries are used to constrain the generation of the clock, and clock gating constraint entries are used to constrain the on / off state of the clock, that is, to control the on / off state of the clock of the hardware module connected to the first clock control RTL code.

[0149] For example, the clock generation constraint entry is the `create_clock` constraint entry; the clock gating constraint entry is the `clock_gating_check` constraint entry. For instance, based on the frequency period (period = 1000.0 / freq MHz), a `create_clock` constraint entry is generated, which includes the period and waveform definition. This can also include setting clock uncertainty, clock delay, and clock transition time.

[0150] In some embodiments, the clock management file generation layer 230 may generate the clock management file in the following manner: in response to the clock and reset requirement information stored in the configuration file being asynchronous processing requirement information between multiple clock domains, a second clock control RTL code for multiple clock domains is generated, and a second type of clock constraint entries acting on the second clock control RTL code are generated simultaneously.

[0151] The second clock control RTL code is used to control the reset of clock domains within multiple clock domains; the second type of clock constraint entries are used to constrain the timing relationships between multiple clock domains. The second type of clock constraint entries includes: clock group constraint entries and / or path constraint entries.

[0152] Clock group constraint entries include timing constraint entries for multiple clock groups. The timing constraint entries for any two clock groups are mutually exclusive, and the clock sources corresponding to any two clock groups are different. This allows for timing control of the clock domain corresponding to each clock group using its timing constraint entries. Furthermore, when synchronization is required between multiple clock domains, the clock group constraint entries are used for clock synchronization. For example, each clock group's timing constraint entry corresponds to a clock domain marked as "async"; clock group constraint entries can be set_clock_groups constraint entries.

[0153] A path constraint entry is a timing constraint command used to specify dummy paths, primarily for excluding paths that do not require timing analysis. For example, a path constraint entry like the `set_false_path` constraint entry can be used to apply synchronizer constraints, facilitating the automatic identification of synchronizer registers.

[0154] In some embodiments, the second clock control RTL code includes at least one of the following sub-codes: a synchronization sub-code across clock domains, a clock gating sub-code for each clock domain, and a reset synchronization sub-code, with each clock sub-code corresponding to a reset synchronization sub-code.

[0155] In some embodiments, the clock management file may also include Clock and ResetGeneration (CRG) sub-code, which is used to convert each sub-code into a corresponding hardware implementation, that is, to instantiate each sub-code and generate a unified port list.

[0156] In some embodiments, for the second clock control RTL code, a multi-level register buffer-based approach can be used to obtain a more stable target enable signal, so that each sub-level code in the second clock control RTL code can be instantiated based on the target enable signal.

[0157] Step 304: In response to receiving the clock and reset requirement update information, the clock management file generation layer 230 determines the target sub-codes that need to be updated in the clock management file and the target timing constraint entries that act on the target sub-codes.

[0158] The target sub-code is any one of the multiple sub-codes included in the RTL code.

[0159] In some embodiments, the requirement configuration file includes configuration parameters that characterize clock and reset requirement information, and the correspondence between each configuration parameter and each sub-level code in the RTL code and its corresponding timing constraint entry is stored in the configuration-output mapping table. Determine the updated configuration parameters based on the updated requirements; based on the updated configuration parameters, locate the configuration-output mapping table to determine the target sub-code and target timing constraint entries.

[0160] The configuration-output mapping table further includes: the first position information of the configuration parameters in the requirements configuration file, and the second position information of each sub-code and its corresponding timing constraint entry in the RTL code. The storage method of the configuration-output mapping table includes: forward storage method and / or, reverse storage method. The forward storage method is a key-value pair storage method with the first position information as the key and the second position information as the value. The reverse storage method is a key-value pair storage method with the second position information as the key and the first position information as the value.

[0161] In some embodiments, the configuration-output mapping table may also include: chapter information of the design document corresponding to the configuration parameters.

[0162] It should be noted that forward storage and / or reverse storage methods facilitate the quick retrieval of the corresponding target sub-code and its corresponding timing constraint entries through the configuration-output mapping table.

[0163] For example, the second location information includes the line number of each sub-code in the RTL code, the sequence number of the corresponding timing constraint entry, and the chapter information in the design document corresponding to each sub-code. Starting from the first location information of the configuration parameter in the requirements configuration file, by searching the information stored in the configuration-output mapping table in a forward-looking manner, we can obtain which line of RTL code, which SDC constraint, and which document chapter the configuration parameter specifically affects, thus achieving forward tracing. Correspondingly, after knowing the line number of the target sub-code, by searching the information stored in the configuration-output mapping table in a reverse-looking manner, we can obtain the configuration parameters used by the target sub-code, accelerating the search speed.

[0164] In some embodiments, the above-mentioned forward and reverse tracing processes can also be automatically parsed and visualized through script tools, making code review and verification of requirement update information more intuitive and convenient.

[0165] Step 305: The clock management file generation layer 230 incrementally updates the target sub-level code and target timing constraint entries according to the required update information, and generates the updated clock management file.

[0166] Incremental update is an update method that updates only the target sub-level code and target timing constraint entries based on the requirement update information, while keeping other sub-level code in the clock management file unchanged, in order to reduce the amount of code modification and improve the update speed.

[0167] In some embodiments, the updated configuration parameters include not only the parameter update type but also the parameter update value, and incremental updates can be achieved by: obtaining the first hash value of the parameter value of the original configuration parameter corresponding to the target sub-code; and performing a hash operation on the parameter update value corresponding to the target sub-code to obtain the second hash value; In response to the difference between the first hash value and the second hash value, the target sub-code is determined to be the sub-code that needs to be updated; then, based on the current configuration parameters corresponding to the target sub-code, the target sub-code is regenerated to obtain the updated target sub-code, and the target timing constraint entries are updated to obtain the updated target timing constraint entries; based on the updated target sub-code and the updated target timing constraint entries, the updated clock management file is determined. If the first hash value is the same as the second hash value, the target sub-code and target timing constraint entries remain unchanged.

[0168] In this system, the parameter update type and the parameter update value must be matched. For example, if the parameter update type is clock frequency, the corresponding parameter update value could be 1000Hz, and the original clock frequency parameter value could be 800Hz. Based on the parameter update type, the configuration-output mapping table is consulted to determine the target sub-code and target timing constraint entries that use the clock frequency parameter. However, during the incremental update of the target sub-code, the second hash value of the corresponding parameter update value also needs to be calculated.

[0169] For example, if the first hash value (i.e., the hash value obtained by hashing the original clock frequency of 800Hz) and the second hash value (i.e., the hash value obtained by hashing the updated clock frequency of 1000Hz) are different for the target sub-code, the target sub-code is determined to be the sub-code that needs to be updated. That is, the target sub-code and its corresponding target timing constraint entries need to be regenerated.

[0170] For two target sub-codes with the same hash value (e.g., the frequency value remains unchanged before and after the change), it is determined that there is no need to update the target sub-code, so as to reduce the amount of code modification and shorten the modification time.

[0171] Step 306: The generation layer 230 of the clock management file performs code-level verification on the updated clock management file and obtains the code verification results.

[0172] The code verification result includes either "code verification successful" or "code verification failed".

[0173] In some embodiments, code-level verification may involve using a static code analysis tool (such as the Lint tool) to verify the RTL code in the updated clock management file and performing syntax checks on the timing constraint entries corresponding to the RTL code to obtain code verification results.

[0174] Step 307: If the code verification result is successful, the clock management file generation layer 230 instantiates the updated clock management file to obtain the instantiated clock management file, and outputs the instantiated clock management file through the output layer 240.

[0175] The clock management file can be instantiated by iterating through each sub-level code within it. This instantiated clock management file can include at least one of the following: module name, instance name, clock input port connection, reset input port connection, enable port connection, test mode port connection, scan ICG mode port connection, and clock output port connection.

[0176] With the above instantiation method, there is no need to manually maintain the instantiation code. Instead, only the target sub-code in the updated clock management file needs to be instantiated, which can effectively reduce the instantiation time and improve the instantiation efficiency.

[0177] In some embodiments, different encapsulation methods can be used to encapsulate the clock management file.

[0178] For example, the clock management file can be packaged using either a first process node type or a second process node type, where the chip size corresponding to the second process node type is larger than the chip size corresponding to the first process node type. For example, the chip size corresponding to the first process node type is 5nm or 3nm, and the chip size corresponding to the second process node type is 7nm or 16nm, etc.

[0179] In some embodiments, when the clock management file is encapsulated using a first process node type, the acquired synchronized enable signal is processed based on a multi-level register buffer to obtain a target enable signal; the synchronized enable signal is the signal used for synchronization between the target clock domain and other clock domains, and the target enable signal is used to authorize the enable time in the target clock domain; the second clock control RTL code is instantiated according to the target enable signal to obtain the instantiated second clock control RTL code.

[0180] Among them, the multi-level register buffering method is a technique that uses multi-level registers to buffer signals (such as synchronized enable signals) to obtain more stable enable signals.

[0181] For example, when the value of the global setting parameter mpcts_enable stored in the read requirement configuration file is true, it indicates that multi-level registers are started for signal buffering. At this time, multi-level registers are used to buffer the received synchronized enable signal in order to obtain the target enable signal with a stable state.

[0182] Specifically, clock synchronization is initiated when the rising edge of the clock is active (e.g., active high). If the multi-level register includes a first-level register mpcts_reg0 and a second-level register mpcts_reg1, the received synchronized enable signal needs to be stored in mpcts_reg0 when the first rising edge of the clock is active. Then, when the second rising edge of the clock is active, the signal value stored in mpcts_reg0 is assigned to mpcts_reg1, and the signal value stored in mpcts_reg1 is used as the target enable signal.

[0183] This makes the target enable signal more stable. When the first rising edge of the clock is valid, the synchronized enable signal stored in mpcts_reg0 is usually in a metastable state. After one clock cycle, the stability of the synchronized enable signal in the metastable state can be improved, thus obtaining a target enable signal with a stable state.

[0184] For example, the target enable signal can be sent as a gating enable signal to the enable terminal of the ICG sub-code. This target enable signal is used to authorize the enable time of the ICG sub-code in the target clock domain, that is, to start data sampling and other processing at this enable time.

[0185] In some embodiments, the multi-level register may further include multiple levels such as three-level registers and four-level registers to obtain a target enable signal with better stability. The target enable signal is the signal value output by the last level register in the multi-level register.

[0186] When the falling edge of the reset is active (e.g., active low), a reset operation is initiated, which involves clearing the multi-level registers. If the multi-level registers include the first-level register mpcts_reg0 and the second-level register mpcts_reg1, then both mpcts_reg0 and mpcts_reg1 need to be cleared.

[0187] For example, when the value of the global setting parameter mpcts_enable stored in the read requirement configuration file is false, it indicates that the multi-level register is not started. In this case, a series of assignment statements (such as the assign statement) are generated directly, and the synchronized enable signal is directly connected to the enable terminal of the ICG sub-code to control the enable terminal of the ICG sub-code.

[0188] The continuous assignment statement is a connection statement used to link ICG sub-codes with other sub-codes. The ICG sub-codes are sub-codes obtained after instantiation.

[0189] Compared to the existing technology that uses the Verilog language-based generate statement, the conditional generation method in this embodiment determines whether to start the multi-level register buffer logic during the code generation stage, so that the final output code does not contain conditional compilation instructions such as ifdef and generate, reducing the number of lines of code and enhancing code readability.

[0190] Furthermore, the RTL code generated in this embodiment has a defined hierarchical structure in both backend synthesis and placement / routing tools, eliminating the need for conditional expansion by these tools and avoiding timing issues caused by insufficient tool optimization. Moreover, the deterministic nature of the RTL code generated in this embodiment reduces verification complexity.

[0191] Step 308: If the code verification result is a code verification failure, or if new requirement update information is received, return to continue executing step 304.

[0192] In some embodiments, the process of parsing and verifying the information stored in the configuration file in step 302 above can be adopted as follows: Figure 4 This is achieved as shown.

[0193] Figure 4 This is a flowchart illustrating an information parsing and verification method provided in an embodiment of this disclosure. Figure 4 As shown, the method includes the following steps: Step 401: Read the requirement configuration file and parse it to obtain the parsed information represented by a data structure.

[0194] Step 402: Perform an integrity check on the required fields in the parsed information.

[0195] If the integrity check of the required fields is successful, proceed to step 403; if the integrity check of the required fields fails, end the process.

[0196] The integrity check of required fields is to ensure that all fields marked as required in the parsed information have valid values, and to avoid situations such as NULL, empty strings, and placeholders (such as "N / A" and "-") that "appear to have values ​​but are actually invalid".

[0197] Step 403: Perform a reasonableness check on the clock frequency in the parsed information.

[0198] If the clock frequency is determined to be within the preset frequency threshold range, the check is considered successful, and step 404 is executed; if the clock frequency is determined to be outside the preset frequency threshold range, the check is considered unsuccessful, and the process ends.

[0199] Step 404: Perform a validity check on the synchronization levels in the parsed information.

[0200] If the synchronization level is determined to be within the preset level threshold range, the check is considered successful, and step 405 is executed; if the synchronization level is determined to be outside the preset level threshold range, the check is considered unsuccessful, and the process ends.

[0201] Among them, the validity check of the synchronization level is to verify the validity of the "level / level number" itself when synchronizing the clock of a certain level, so as to prevent problems such as gaps, skipping levels, loops, and exceeding limits.

[0202] Step 405: Check the integrity of the clock source reference in the parsed information.

[0203] Among them, clock source reference integrity means that for all modules that reference a clock source, the clock source they point to must actually exist, be in a valid state, have matching parameters, and cannot be illegally deleted or tampered with.

[0204] If the clock source reference integrity check is successful, proceed to step 406; if the clock source reference integrity check fails, end the process.

[0205] Step 406: Confirm that the parsing and verification of the information stored in the configuration file is complete, and the corresponding information verification result is that the information verification is successful.

[0206] In some embodiments, before performing step 304 above, it is also necessary to evaluate the received clock and reset requirement update information to determine the risks and impacts of updating the clock management file based on the requirement update information.

[0207] Figure 5 A flowchart illustrating a method for evaluating demand update information provided in an embodiment of this disclosure. Figure 5 As shown, the method includes the following steps: Step 501: Obtain the original requirements configuration file and the modified configuration file after adding requirements update information.

[0208] Step 502: Based on recursive traversal, perform key-value pair difference detection on the original requirement configuration file and the modified configuration file to generate structured difference data.

[0209] For example, a YAML parser is used to load the original requirements configuration file and the modified configuration file separately. Then, all key-value pairs in these two files are recursively traversed to identify the differences. These differences include at least one of the following: newly added keys, deleted keys, and keys whose values ​​have changed. The differences are then stored as structured difference data, which includes the change path (e.g., clock_domains.cpu_clk.freq), the value before the change (e.g., clock frequency of 800Hz), the value after the change (e.g., clock frequency of 1000Hz), and the change type (e.g., modified data).

[0210] Step 503: Based on the structured difference data, query the configuration-output mapping table to obtain the query results.

[0211] There can be one or more structured difference data. If structured difference data is determined to exist, steps 503-505 can be repeated to obtain all target sub-codes and target timing constraint entries.

[0212] Step 504: If it is determined that the query result is structured difference data and there are corresponding target sub-codes and target time-series constraint entries that need to be updated in the configuration-output mapping relationship table, record the target sub-codes and target time-series constraint entries.

[0213] In some embodiments, the configuration-output mapping table further includes: chapter information of the design document corresponding to the configuration parameters; by querying the configuration-output mapping table, the chapter information of the design document that needs to be updated corresponding to the structured difference data can be obtained, so that the corresponding design document can be updated synchronously after the code is updated.

[0214] Step 505: If it is determined that the structured difference data in the query result does not have a corresponding code or time-series constraint entry that needs to be updated in the configuration-output mapping table, mark the structured difference data as data with no impact.

[0215] Step 506: Based on the query results of Step 504 or Step 505, determine the impact information of the change, and based on the impact information of the change, determine the risk level of the change.

[0216] Among them, the change impact information is information that characterizes the scope and degree of impact of the requirement update on the clock management file; the change risk level is information that characterizes the degree of impact of changes to the clock and reset requirement information on the stability of the clock management file.

[0217] For example, if you need to configure the clock frequency (clock_domains) of a specific clock domain in the configuration parameters. If you modify the clock frequency (e.g., change it from 800MHz to 1.0GHz), you need to modify at least one of the following: the CLK_FREQ parameter of the clock gate sub-code corresponding to the clock domain, the timing constraint entry acting on the clock gate sub-code is the create_clock-period constraint (e.g., change the clock period from 1.25ns to 1.0ns), and the description line of the clock frequency in the design document (e.g., the configuration table corresponding to the clock frequency).

[0218] In some embodiments, the change impact information includes the change type and the scope of impact, and the change risk level is determined based on the change type and the scope of impact. Furthermore, the change risk level includes at least three levels, with the risk level decreasing sequentially. For example, high risk level, medium risk level, and low risk level.

[0219] For example, high-risk modifications affect the clock tree topology, such as changing the clock source frequency or adding a new clock domain. Medium-risk modifications only affect the timing convergence within a specific clock domain, or modify the enabling strategy of a clock gate within that domain. Low-risk modifications are merely formal changes and do not affect the functionality of the code; for example, modifying the comments in the corresponding code.

[0220] Step 507: Generate a risk assessment report.

[0221] The risk assessment report includes at least one of the following: structured difference data, target sub-codes and target timing constraint entries that need to be updated, design documents that need to be updated, change risk level, and change impact information.

[0222] In some embodiments, the risk assessment report may be presented in a structured format, such as Markdown or HTML, to facilitate quick viewing by users.

[0223] In some embodiments, steps 304-305 above can also be implemented using the following incremental update method: The generated risk assessment report is approved; based on the approval result, it is determined whether to incrementally update the target sub-level code and target timing constraint entries; incremental updates are then performed to obtain the updated clock management file.

[0224] Figure 6 This is a flowchart illustrating an incremental update method provided in an embodiment of this disclosure. Figure 6 As shown, the method includes the following steps: Step 601: Obtain the risk assessment report and review the risk level of the change in the risk assessment report.

[0225] Step 602: In response to the audit results regarding the risk level of the change, determine whether the clock management file needs to be updated.

[0226] The review levels differ depending on the risk level of the change. For example, the highest review level (P0) corresponds to a high-risk level, requiring at least two reviewers to review the change and obtain a result. The next highest review level (P1) corresponds to a medium-risk level, requiring at least one reviewer to review the change and obtain a result. The lowest review level (P2) corresponds to a low-risk level, requiring no review and directly determining whether the clock management file needs to be updated based on the change type.

[0227] It should be noted that approvers at all levels can view the discrepancies in the risk assessment report through the approval interface to facilitate their approval decisions.

[0228] If the audit result is approved, determine that the clock management file needs to be updated and proceed to step 603; if the audit result is rejected, determine that the clock management file does not need to be updated and proceed to step 604.

[0229] Step 603: In response to receiving the clock and reset requirement update information, based on the configuration-output mapping relationship table stored in the bidirectional traceability index file, determine the target sub-level code that needs to be updated in the clock management file and the target timing constraint entries that act on the target sub-level code.

[0230] The configuration-output mapping table includes the correspondence between each configuration parameter in the requirements configuration file and each sub-level code in the RTL code and its corresponding timing constraint entries, as well as the chapter information of the design document corresponding to the configuration parameter.

[0231] By using the information stored in the configuration-output mapping table in a forward storage mode and / or a reverse storage mode, the target sub-level code and target timing constraint entries can be quickly retrieved.

[0232] Step 604: Provide feedback on the proposed changes to the technical staff, but do not perform incremental updates to the clock management file, and then end the process.

[0233] Step 605: Incrementally update the target sub-level code and target timing constraint entries according to the requirement update information, and generate the updated clock management file.

[0234] It should be noted that updating only the target sub-level code and target timing constraint entries based on the requirement update information, while keeping the unaffected code and timing constraint entries unchanged, can not only speed up the update process, but also reduce the verification burden caused by a full update.

[0235] For example, to modify the clock frequency in a certain clock domain, you only need to incrementally update the CLK_FREQ parameter of the clock gating sub-code corresponding to that clock domain and the create_clock -period constraint applied to that clock gating sub-code, while keeping other codes (such as clock gating sub-codes in other clock domains, reset sub-codes, etc.) unchanged.

[0236] Step 606: Perform code-level verification on the updated clock management file and obtain the code verification results.

[0237] The code verification result includes either "code verification successful" or "code verification failed".

[0238] If the code verification result is successful, proceed to step 607; if the code verification result is unsuccessful, return to step 605.

[0239] Step 607: Instantiate the updated clock management file to obtain the instantiated clock management file, and output the instantiated clock management file through output layer 240.

[0240] Step 608: Generate an update log based on the updated configuration parameters, the target sub-codes in the updated clock management file, the target timing constraint entries, and the chapter information in the design document; and update the configuration-output mapping table based on the update log.

[0241] The update configuration-output mapping table updates the information in the table corresponding to the updated configuration parameters. This includes updating the target sub-code's code and line number, the clock constraint entries affecting that sub-code, and the section of the design document corresponding to the updated configuration parameters. This facilitates subsequent searching and improves the speed of locating the target sub-code.

[0242] In some instances, the incrementally updated code-level target sub-code and its corresponding target timing constraint entries, as well as the corresponding updated design documents, can be stored in a preset address for easy access by other modules.

[0243] In this embodiment, by reviewing the risk level of the change in the risk assessment report, it is possible to more accurately determine whether an incremental update of the clock management file is required. If an incremental update is required (i.e., the review is approved), the target sub-level code and target timing constraint entries can be updated quickly while keeping other sub-level code unchanged. Compared with traditional modification methods (such as manually modifying functions in Verilog code, modifying create_clock constraints in timing constraint problems, and updating design documents), this method can greatly shorten the modification time, improve modification efficiency, and ensure the accuracy of the modification.

[0244] In some embodiments, Figure 7 This diagram illustrates a method for constructing a bidirectional traceability index according to an embodiment of this disclosure. Figure 7 As shown, during the code generation process, RTL code is generated by filling in the configuration parameters of the RTL code, timing constraint entries that act on the RTL code are generated by filling in the configuration parameters of the timing constraint entry template, and corresponding design documents are generated by filling in the configuration parameters of the document template.

[0245] During the above process, it is necessary to record the corresponding source configuration paths. For example, the source configuration path for RTL code is the RTL file and the corresponding line number; the source configuration path for timing constraint entries is the specific entry number corresponding to the timing constraint entry; and the source configuration path for design documents is the corresponding chapter information in the design document.

[0246] Then, the various source configuration paths recorded above are summarized to generate a traceability index file, which includes forward index information, reverse index information, and change history information.

[0247] It should be noted that this traceability index file can also be generated based on the configuration-output mapping table in the requirements configuration file. It stores the correspondence between configuration parameters and each sub-level code and its corresponding timing constraint entries in the RTL code through forward storage and / or reverse storage. This allows for quick retrieval of the required target sub-level code or target constraint entry from the configuration-output mapping table based on the configuration parameters through forward storage, or quick retrieval of the corresponding configuration parameter from the configuration-output mapping table based on the target sub-level code through reverse storage.

[0248] Taking the RTL code generation process as an example, RTL code is generated by filling the clock frequency parameter (e.g., 800Hz) in a certain clock domain into a preset RTL code template. This RTL code includes the code "parameter CLK_FREQ =800". At the same time, the corresponding forward trace record is the following information stored in forward storage mode: "{source: "clock_domains.cpu_clk.freq",target:"rtl / cpu_clk_gate.v",line:15,type:"RTL_PARAM"}. Here, "clock_domains.cpu_clk.freq" indicates that the configuration parameter is the clock frequency of the CPU in the clock domain clock_domains; "rtl / cpu_clk_gate.v" indicates the source file corresponding to this code; "line:15" indicates the corresponding code line number; and "RTL_PARAM" indicates that the parameter type is RTL code.

[0249] Correspondingly, the forward or reverse trace records in the traceability index file corresponding to the timing constraint entries and design documents are recorded in the same way as the traceability records of the RTL code, and will not be elaborated here.

[0250] In some embodiments, the forward traceability record includes key-value pairs constructed using the storage path corresponding to the requirement configuration file stored in YAML format as the key and the location information of all output products affected by the configuration parameters in the requirement configuration file as the value.

[0251] The reverse traceability record includes key-value pairs constructed using the location information of the output product as the key and the storage path of the corresponding configuration parameter in the requirement configuration file as the value.

[0252] Change history information includes at least one of the following: timestamp information for each generation, hash value corresponding to the version information of the configuration file, and a list of all output artifacts.

[0253] Applications of traceability indexes include: quickly locating the source of changes during code reviews, reverse locating configuration issues when verification fails, enabling new members to quickly understand the correspondence between code and configuration, and providing a complete traceable chain of evidence for changes during compliance audits.

[0254] In some embodiments, Figure 8 A flowchart illustrating an instantiation method provided in an embodiment of this disclosure. For example... Figure 8 As shown, the instantiation method includes the following steps: Step 801: Traverse all child code in the RTL code of the clock management file.

[0255] Case 1 indicates that the clock management file includes clock gating sub-code and reset synchronization sub-code in at least one clock domain; Case 2 indicates that the clock management file does not contain clock gating sub-code and reset synchronization sub-code, in which case it is only necessary to generate and instantiate the top-level code.

[0256] Step 802: For each clock gate sub-code in each clock domain, if it is determined that the clock gate sub-code needs to be instantiated, generate the instantiation code of the clock gate sub-code and generate signal connections. Based on the instantiation code and signal connections of the reset synchronization sub-code, obtain the instantiated clock gate sub-code.

[0257] Step 803: For each reset synchronization sub-code in each clock domain, if it is determined that the reset synchronization sub-code needs to be instantiated, generate the instantiation code of the reset synchronization sub-code and generate signal connections. Based on the instantiation code and signal connections of the reset synchronization sub-code, obtain the instantiated reset synchronization sub-code.

[0258] Step 804: Determine the generation of the top-level port list.

[0259] Step 805: Based on the top-level port list, perform instantiation to obtain the instantiated top-level module.

[0260] Based on the same inventive concept as the above method, this disclosure also provides a clock management file generation apparatus. Figure 9 This is a block diagram of a clock management file generation apparatus provided in an embodiment of the present disclosure. Figure 9 As shown, the clock management file generation device 900 includes, but is not limited to, the following modules.

[0261] The determination module 901 is configured to, in response to receiving clock and reset requirement update information, determine the target sub-code and the target timing constraint entries that need to be updated in the clock management file; wherein, the clock management file is generated based on a preset requirement configuration file, and the clock management file includes register transfer RTL code and timing constraint entries that act on the RTL code, and the target sub-code is any one of the multiple sub-codes included in the RTL code; The incremental update module 902 is configured to incrementally update the target sub-level code and target timing constraint entries based on the required update information, and generate an updated clock management file.

[0262] It should be noted that the clock management file generation device provided in this embodiment is a device corresponding to the clock management file generation method described above. The specific implementation details of this device and the technical effects it brings are the same as the implementation details and technical effects of the clock management file generation method embodiment described above, and will not be repeated here.

[0263] The clock management file generation apparatus provided in this embodiment generates register transfer RTL code and timing constraint entries acting on the RTL code based on a preset requirement configuration file. This enables uniformity in code style and reduces the proportion of errors introduced by manual coding. Upon receiving clock and reset requirement update information, a determination module determines the target sub-code that needs to be updated and the target timing constraint entries acting on the target sub-code. An incremental update module then incrementally updates the target sub-code and the target timing constraint entries according to the requirement update information. This not only makes the updated clock management file more in line with clock reset requirements but also greatly reduces development redundancy and makes the obtained clock management file more in line with user needs.

[0264] According to embodiments of this disclosure, this disclosure also provides an electronic device, which includes: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to implement the clock management file generation method described in any of the above embodiments when executing the instructions stored in the memory.

[0265] According to embodiments of this disclosure, this disclosure also provides a chip including a processor for executing the clock management file generation method described in any of the above embodiments.

[0266] According to embodiments of this disclosure, this disclosure also provides a non-volatile computer-readable storage medium storing computer program instructions thereon, which, when executed by a processor, can implement the clock management file generation method described in any of the above embodiments.

[0267] For example, the computer instructions corresponding to the clock management file generation method in this embodiment of the present disclosure can be stored on storage media such as optical discs, hard disks, and USB flash drives. When the computer instructions corresponding to the clock management file generation method in the storage media are read or executed by a computer, the clock management file generation method as described in any of the above embodiments can be implemented.

[0268] According to embodiments of this disclosure, this disclosure also provides a computer program product including a computer program that, when executed by a processor, can implement the clock management file generation method described in any of the above embodiments.

[0269] Figure 10 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this disclosure. The electronic device 1000 proposed in this embodiment includes a processor 1001 and a memory 1002 storing an executable computer program. When the processor 1001 executes the executable computer program stored in the memory 1002, it implements the clock management file generation method provided in this embodiment of the disclosure.

[0270] In some optional implementations of the embodiments of this disclosure, the electronic device 1000 may further include a communication interface 1003 and a bus 1004 for connecting the processor 1001, the memory 1002 and the communication interface 1003.

[0271] In some optional implementations of the embodiments of this disclosure, bus 1004 is used to connect communication interface 1003, processor 1001 and memory 1002 to realize mutual communication between these devices.

[0272] In some optional implementations of the embodiments of this disclosure, the processor 1001 may be at least one of the following: Application Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Digital Signal Processing Device (DSPD), Programmable Logic Device (PLD), Field Programmable Gate Array (FPGA), Central Processing Unit (CPU), Controller, Microcontroller, and Microprocessor. It is understood that, for different devices, the electronic device used to implement the functions of the processor 1001 may also be other types, and the embodiments of this disclosure do not specifically limit this.

[0273] The aforementioned memory 1002 is used to store executable computer programs and data. The executable computer program includes computer operation instructions. Memory 1002 may include high-speed RAM and may also include non-volatile memory, such as at least two disk drives. In practical applications, the aforementioned memory 1002 may be volatile memory, such as random-access memory (RAM); or non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); or a combination of the above types of memory, and provides executable computer programs and data to the processor.

[0274] Furthermore, the functional modules in this embodiment 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. The integrated unit can be implemented in hardware or as a software functional module.

[0275] If the integrated units described above are implemented as software functional modules and not sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of this disclosure, in essence, or the parts that contribute to the prior art, or all or part of the technical solutions, 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, server, or network device, etc.) or processor to execute all or part of the steps of the methods of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0276] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this disclosure can be achieved, and this is not limited herein.

[0277] It should also be understood that expressions such as "comprising," "including," "having," "containing," and / or "comprising" are open-ended rather than closed-ended expressions in this disclosure, indicating the presence of the stated features, elements, and / or components, but not excluding the presence of one or more other features, elements, components, and / or combinations thereof. Furthermore, when expressions such as "at least one of..." appear after a list of listed features, they modify the entire list of features, not just individual elements in the list. Additionally, when describing embodiments of this disclosure, the word "may" is used to mean "one or more embodiments of this disclosure." And the term "exemplary" is intended to refer to an example or illustration.

[0278] Unless otherwise specified, all terms used herein (including engineering and technical terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. It should also be understood that, unless expressly stated in this disclosure, terms as defined in common dictionaries shall be interpreted as having the meaning consistent with their meaning in the context of the relevant art, and not as having an idealized or overly formalized meaning.

[0279] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for generating a clock management file, wherein, The method includes: In response to receiving clock and reset requirement update information, the target sub-code that needs to be updated in the clock management file and the target timing constraint entries acting on the target sub-code are determined; wherein, the clock management file is generated based on a preset requirement configuration file, the clock management file includes register transfer RTL code and timing constraint entries acting on the RTL code, and the target sub-code is any one of the multiple sub-codes included in the RTL code; Based on the required update information, the target sub-level code and the target timing constraint entries are incrementally updated to generate an updated clock management file.

2. The method according to claim 1, wherein, The requirement configuration file includes configuration parameters that characterize the clock and reset requirement information. The correspondence between each configuration parameter and each sub-level code in the RTL code and its corresponding timing constraint entries is stored in the configuration-output mapping table. In response to receiving clock and reset requirement update information, the process determines the target sub-code that needs to be updated in the clock management file and the target timing constraint entries acting on the target sub-code, including: Determine the updated configuration parameters based on the aforementioned requirement update information; Based on the updated configuration parameters, the configuration-output mapping table is searched to determine the target sub-level code and the target timing constraint entries.

3. The method according to claim 2, wherein, The configuration-output mapping table further includes: the first position information of the configuration parameters in the requirement configuration file, and the second position information of each sub-level code and its corresponding timing constraint entry in the RTL code. The configuration-output mapping table is stored in two ways: forward storage and / or reverse storage. The forward storage method is a key-value pair storage method with the first location information as the key and the second location information as the value. The reverse storage method is a key-value pair storage method with the second location information as the key and the first location information as the value.

4. The method according to claim 3, wherein, The configuration-output mapping table also includes: chapter information of the design document corresponding to the configuration parameters; The method further includes generating an update log based on the updated configuration parameters, the target sub-code in the updated clock management file, the target timing constraint entries, and the chapter information of the design document.

5. The method according to claim 2, wherein, The updated configuration parameters include updated parameter values; before incrementally updating the target sub-level code and the target timing constraint entries according to the requirement update information to generate the updated clock management file, the method further includes: Obtain the first hash value of the parameter value of the original configuration parameter corresponding to the target sub-code; and perform a hash operation on the parameter update value corresponding to the target sub-code to obtain a second hash value; in response to the first hash value and the second hash value being different, determine that the target sub-code is the sub-code that needs to be updated; Correspondingly, the incremental update of the target sub-level code and the target timing constraint entries based on the requirement update information, generating an updated clock management file, includes: Based on the current configuration parameters corresponding to the target sub-code, the target sub-code is regenerated to obtain the updated target sub-code; and the target timing constraint entries are updated to obtain the updated target timing constraint entries; based on the updated target sub-code and the updated target timing constraint entries, the updated clock management file is determined.

6. The method according to claim 5, wherein, The method further includes: In response to the first hash value being the same as the second hash value, the target sub-code and the target timing constraint entry remain unchanged.

7. The method according to any one of claims 1 to 6, wherein, In response to receiving clock and reset requirement update information, before determining the target sub-code that needs to be updated in the clock management file and the target timing constraint entries acting on the target sub-code, the method further includes: The requirement update information is analyzed to determine the impact information of the change; the impact information of the change is information that characterizes the scope and degree of impact of the requirement update on the clock management file; Based on the change impact information, the change risk level is determined; the change risk level is a characterization of the degree of impact of changes to the clock and reset requirement information on the stability of the clock management file. Based on the audit results regarding the risk level of the change, it is determined that the clock management file needs to be updated.

8. The method according to claim 7, wherein, The step of determining the risk level of the change based on the change impact information includes: The change risk level is determined based on the change type and scope of impact in the change impact information; wherein the change risk level includes at least three levels with decreasing risk levels, and each change risk level corresponds to a different review level.

9. The method according to claim 1, wherein, The clock management file includes: a first clock control RTL code and a first type of timing constraint entries that act on the first clock control RTL code; The first clock control RTL code is used to control the clock and reset within a clock domain; the first type of timing constraint entry is used to constrain the timing relationship between the clock and the enable signal.

10. The method according to claim 9, wherein, The first type of timing constraint entries includes: clock generation constraint entries and clock gating constraint entries; The clock generation constraint entry is used to constrain the generation of the clock, and the clock gating constraint entry is used to constrain the switching state of the clock.

11. The method according to claim 1, wherein, The clock management file includes: a second clock control RTL code and a second type of timing constraint entries that act on the second clock control RTL code; The second clock control RTL code is used to control the clock and reset within multiple clock domains; the second type of timing constraint entries are used to constrain the timing relationships between multiple clock domains.

12. The method according to claim 11, wherein, The second type of timing constraint entries includes: clock group constraint entries and / or path constraint entries; The clock group constraint entries include timing constraint entries for multiple clock groups. The timing constraint entries for any two clock groups are mutually exclusive, and the clock sources corresponding to any two clock groups are different.

13. The method according to claim 11, wherein, The method further includes: When the clock management file is packaged using the first process node type, the obtained synchronized enable signal is processed based on a multi-level register buffer to obtain the target enable signal; the synchronized enable signal is the signal used for synchronization between the target clock domain and other clock domains, and the target enable signal is used to authorize the enable time in the target clock domain. The second clock control RTL code is instantiated according to the target enable signal to obtain the instantiated second clock control RTL code.

14. The method according to claim 13, wherein, The second clock control RTL code includes clock gating sub-code; The method of processing the acquired synchronized enable signal based on multi-level register buffering to obtain the target enable signal includes: In response to starting the multi-level register and receiving a clock trigger signal, the synchronized enable signal is obtained; The multi-level registers corresponding to the target clock domain are assigned values ​​according to the synchronized enable signal, and the value output by the last level register of the multi-level registers is used as the target enable signal; wherein, the target enable signal is used to authorize the enable time in the target clock domain corresponding to the clock gate sub-code.

15. The method according to claim 14, wherein, The multi-level register includes a first-level register and a second-level register connected in sequence; the step of assigning values ​​to the multi-level registers corresponding to the target clock domain according to the synchronized enable signal, and using the value output by the last level register of the multi-level registers as the target enable signal, includes: The synchronized enable signal is stored in the first-level register; In response to receiving the next clock trigger signal, the signal value stored in the first-level register is assigned to the second-level register; and the signal value stored in the second-level register is used as the target enable signal.

16. The method according to claim 13, wherein, The second clock control RTL code includes reset synchronization sublevel code, and the method further includes: In response to starting the multi-level registers and receiving a reset trigger signal, the multi-level registers are cleared based on the reset synchronization sub-level code.

17. The method according to claim 13, wherein, The method further includes: When the clock management file is packaged using the second process node type, the obtained synchronized enable signal is used as the target enable signal; The chip size corresponding to the second process node type is larger than the chip size corresponding to the first process node type.

18. The method according to any one of claims 13-17, wherein, The step of instantiating the second clock control RTL code according to the target enable signal to obtain the instantiated second clock control RTL code includes: Based on the target enable signal, determine the connection statement corresponding to the second clock control RTL code; The instantiated second clock control RTL code is determined based on the second clock control RTL code and its corresponding connection statements.

19. A device for generating clock management files, wherein, The device includes: The determination module is configured to, in response to receiving clock and reset requirement update information, determine the target sub-code that needs to be updated in the clock management file and the target timing constraint entries acting on the target sub-code; wherein, the clock management file is generated based on a preset requirement configuration file, the clock management file includes register transfer RTL code and timing constraint entries acting on the RTL code, and the target sub-code is any one of the multiple sub-codes included in the RTL code; The incremental update module is configured to incrementally update the target sub-level code and the target timing constraint entries according to the required update information, and generate an updated clock management file.

20. A system for generating clock management files, wherein, The system includes: The requirement elicitation layer is configured to obtain clock and reset requirement information; The configuration layer is configured to store the clock and reset requirement information in a requirement configuration file based on a structured format; The clock management file generation layer is configured to execute the clock management file generation method according to any one of claims 1 to 18 to obtain an updated clock management file; The output layer is configured to output the updated clock management file.

21. 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 clock management file generation method according to any one of claims 1 to 18.

22. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to execute the method for generating a clock management file according to any one of claims 1 to 18.

23. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the method for generating a clock management file according to any one of claims 1 to 18.

Images