Cross-clock domain detection method and system based on programmable logic design

Abstract

The application discloses a kind of, belong to electronic hardware design technical field.The method includes: obtaining the design file package formed by multiple hardware description language design files, tree structure analysis and depth marking are carried out, and the file tree structure with depth marking is obtained;From bottom to top, each design file is traversed and analyzed layer by layer, and six signal sets are extracted into clock and data signal;For the design file with subfile, the signal set of current file is cross-file bonded with the corresponding signal set of subfile, and the clock path information of each signal is updated;Based on the internal bonding data set and data input set after updating, the clock domain crossing checkpoint is generated by clock path consistency comparison and multi-purpose clock sampling determination, and the checkpoint set is obtained.The application does not need to specify clock constraint in advance, can complete clock domain crossing detection in early design stage, supports mixed analysis of multiple hardware description language files.

Description

Technical Field

[0001] This invention relates to the field of electronic hardware design technology, specifically to a cross-clock domain detection method and system based on programmable logic design. Background Technology

[0002] In programmable logic design, cross-clock domain detection is a critical step in ensuring system stability and functional correctness. With the increasing complexity of modern programmable logic devices and heterogeneous system architectures, designs often need to handle data interaction between multiple different clock domains. These clock domains may have different frequencies, phases, or jitter characteristics, leading to metastability, data loss, or logic errors during data transmission, thereby causing system failures.

[0003] In existing technologies, cross-clock domain detection can be performed using static timing analysis tools or plugins built into development tools during the design completion phase. Static timing analysis tools require explicit definition of clock domain relationships in the design and detect cross-clock domain paths through clock design constraints, but they cannot fully cover the metastability risks of asynchronous clock domains. Using cross-clock domain analysis plugins in programmable device development tools, combined with routing resources and clock design constraints, can identify unsynchronized cross-clock domain signals. However, these existing technologies require pre-determining relevant clock design constraints during runtime and can only perform cross-clock domain detection after design completion, preventing intervention in the early design stages.

[0004] Therefore, there is a need for a method that allows for cross-clock domain detection early in the design process without clock design constraints. Summary of the Invention

[0005] To address the problems existing in the prior art, this invention provides a cross-clock domain detection method and system based on programmable logic design. By parsing the design file package in a tree structure, the design file is parsed layer by layer from the maximum depth node to the root node, and clock and data signals are automatically extracted. After cross-file glue processing, cross-clock domain checkpoints are generated, realizing automatic cross-clock domain detection in the early stage of design when there are no clock design constraints.

[0006] This invention is achieved through the following technical solution: In a first aspect, this application provides a cross-clock domain detection method based on programmable logic design, comprising the following steps: Step 1: Obtain a design file package consisting of multiple hardware description language design files, perform tree structure parsing on the design file package, and perform depth marking on each file according to the file tree structure to obtain the file tree structure with depth marking and the maximum depth of the design file package; Step 2: Starting from the deepest level, traverse the file tree structure layer by layer from bottom to top, select the design files of each level in turn for parsing, extract the clock signals and data signals of each design file, and classify the clock signals and data signals into the corresponding signal sets respectively. The signal set includes an internal clock set, an internal glued data set, a clock output set, a clock input set, a data output set, and a data input set; Step 3: For the current design file to be processed, determine whether it has subordinate sub-files; if subordinate sub-files exist, perform cross-file glue processing on the signal sets of the current design file and the corresponding signal sets of its sub-files, and update the source clock file tree path and destination clock file tree path of each signal through inter-level signal matching. Step 4: Based on the internal glued data set and data input set that have completed the glued update, generate cross-clock domain checkpoints by comparing clock path consistency and determining multi-purpose clock sampling. Based on the cross-clock domain checkpoints at all levels, obtain the checkpoint set.

[0007] Preferably, step 1, which involves parsing the design file package into a tree structure, includes: Identify the hierarchical calls and dependencies between various design files, and construct a file tree structure with the top-level design file as the root node and the bottom-level sub-module design files as leaf nodes; Each design file is marked with a depth according to the hierarchical rule from root node to leaf node, and the depth value corresponding to the deepest leaf node is determined as the maximum depth of the design file package.

[0008] Preferably, step 2, parsing each design file, includes: The internal timing logic section of the design document is parsed, and internal clock signals that do not exist in the input / output signal list of the design document are included in the internal clock set. The file tree path and clock name of each clock signal are recorded. Data signals transmitted across clock domains internally are grouped into the internal glued data set, and the source clock file tree path and destination clock file tree path of each data signal are recorded.

[0009] Preferably, step 2, parsing each design file, further includes: The input and output signal list of the design document is parsed, and clock signals are classified into the clock input set and the clock output set according to the transmission direction, and data signals are classified into the data input set and the data output set according to the transmission direction.

[0010] Preferably, the cross-document bonding process in step 3 includes: If the clock input of a subfile comes from the clock input set of the current design file or the internal clock set, then the source clock file tree path of the corresponding clock in the current design file is added to the source clock file tree path of the corresponding clock input in the subfile. If the data input of the subfile comes from the data input set of the current design file or the internal glued data set, then the source clock information of the corresponding data in the current design file will be copied to the source clock file tree path of the corresponding data input of the subfile.

[0011] Preferably, the cross-document bonding process in step 3 further includes: If the clock output or internal clock used in the current design file originates from the clock output set of the sub-file, then the file tree path of the corresponding clock output of the sub-file is added to the source clock file tree path of the corresponding clock in the current design file; If the data output or internal glued data of the current design file originates from the data output set of the sub-file, then the source clock and destination clock information of the corresponding data output of the sub-file will be copied to the source clock file tree path of the corresponding data in the current design file.

[0012] Preferably, the clock path consistency comparison in step 4 includes: Traverse the set of internal glued data, compare the source clock file tree path and the destination clock file tree path of each piece of internal glued data. If the two are inconsistent, generate a checkpoint based on the internal glued data.

[0013] Preferably, steps 2 to 2 are executed in a bottom-up hierarchical iterative manner, specifically as follows: Starting from the maximum depth level, after parsing, gluing and checking all unparsed design files at the current depth, the traversal depth value is decremented by 1, and the design files of the previous level are processed until all processing of the root node level is completed. All cross-clock domain checkpoints generated at all levels are summarized to obtain the final checkpoint set.

[0014] Preferably, the multi-purpose clock sampling determination in step 4 includes: Traverse the data input set and count the number of destination clock file tree paths corresponding to each data input. If the same data input corresponds to multiple different destination clock file tree paths, then generate a checkpoint based on that data input.

[0015] Secondly, this application provides a cross-clock domain detection system based on programmable logic design, comprising: The file structure parsing module is used to obtain a design file package consisting of multiple hardware description language design files, perform tree structure parsing on the design file package, and perform depth marking on each file according to the file tree structure to obtain the file tree structure with depth marking and the maximum depth of the design file package. The signal parsing module is used to traverse the file tree structure layer by layer from the deepest level in a bottom-up direction, select the design files at each level for parsing, extract the clock signals and data signals of each design file, and classify the clock signals and data signals into the corresponding signal sets; the signal sets include the internal clock set, the internal glued data set, the clock output set, the clock input set, the data output set, and the data input set; The cross-file bonding module is used to determine whether there are subordinate sub-files for the current design file to be processed. If there are subordinate sub-files, the signal sets of the current design file and the corresponding signal sets of its sub-files are bonded together across files. The source clock file tree path and the destination clock file tree path of each signal are updated by matching signals between levels. The cross-clock domain check module is used to generate cross-clock domain checkpoints based on the internal glued data set and data input set that have completed glued updates, through clock path consistency comparison and multi-purpose clock sampling determination. Based on the cross-clock domain checkpoints at all levels, a checkpoint set is obtained.

[0016] Compared with the prior art, the present invention has the following beneficial technical effects: This application presents a cross-clock domain detection method based on programmable logic design. First, the design file package undergoes tree structure parsing and depth marking, organizing the scattered design files into a hierarchical file tree and establishing a bottom-up parsing order from the deepest leaf node to the top root node. Then, starting from the deepest level, each design file is parsed layer by layer from bottom to top, extracting clock and data signals and categorizing them into six signal sets: internal usage clock, internal glued data, clock and data input / output, and converting hardware description language code into computable structured data. Next, cross-file glued processing is performed on design files with sub-files. Through inter-level signal matching, the port signals of the sub-module are associated with the internal signals of the parent module, and the bottom-level clock path information is passed upwards layer by layer, ensuring that the source and destination clocks of each data transmission path have complete file tree path identifiers. Finally, based on the updated internal glued data set and data input set, cross-clock domain checkpoints are generated through two checking methods: clock path consistency comparison and multi-destination clock sampling judgment. The former identifies the risk of signals crossing different clock domains from generation to use, while the latter identifies the risk of the same data being sampled by multiple clock domains. This method can automatically complete cross-clock domain detection without pre-specifying clock design constraints, and can intervene in the early stages of design, avoiding the limitations of traditional methods that rely on clock constraints and can only detect after the design is completed; the bottom-up parsing and glue-in mechanism ensures the integrity of signal path information, avoiding path breaks and risk omissions caused by module partitioning; it supports mixed parsing of multiple hardware description language files and is not limited to a specific development platform.

[0017] This application also proposes a cross-clock domain detection system based on programmable logic design, an electronic device, and a computer storage medium, which possess all the advantages of the aforementioned cross-clock domain detection method based on programmable logic design. Attached Figure Description

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

[0019] Figure 1 This is a schematic diagram of the cross-clock domain detection method based on programmable logic design according to the present invention; Figure 2 This is a schematic diagram of the data organization for the cross-clock domain detection method of the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0021] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0022] This application provides a cross-clock domain detection method based on programmable logic design. By parsing a design package consisting of multiple design files, it achieves cross-clock domain detection in the early stages of design when there are no clock design constraints. This method is not limited by a development platform and only requires the original design files to automatically detect clock relationships. (See reference...) Figure 1 and Figure 2 The following is a further detailed description of this technical solution.

[0023] Step 1: Obtain a design file package consisting of multiple hardware description language design files, perform tree structure parsing on the design file package, mark the depth of each file according to the file tree structure, determine the maximum depth of the design package, and obtain a file tree structure with depth marking.

[0024] The specific implementation method of step 1 will be described in detail below.

[0025] S1.1: Obtain the design file package to be tested, which consists of multiple hardware description language design files, identify the hierarchical calls and dependencies between the design files, and construct a file tree structure; the root node of the tree structure corresponds to the top-level design file, and the leaf nodes correspond to the bottom-level submodule design files.

[0026] S1.2: According to the hierarchical relationship of the file tree structure, mark the depth of the node corresponding to each design file. The depth mark value increases sequentially from the root node to the leaf node, and the depth mark of the root node is 1. Calculate the maximum depth M of the design file package, and set the initial traversal depth variable N to be equal to the maximum depth M.

[0027] By using a tree-structured parsing method, scattered design documents are organized into hierarchical structured objects. Depth markers clearly define the hierarchical position of each document, establishing a bottom-up parsing order from the deepest leaf node to the top root node. This method ensures that when parsing upper-level documents, all their sub-files have been parsed and their information summarized. This guarantees that complete underlying path information can be obtained when tracing signals across documents, avoiding the problem of missing signal source information caused by top-down parsing. It also provides a structural foundation for subsequent cross-document bonding and full-path inspection.

[0028] In some embodiments, file depth marking can be implemented by top-down recursive traversal or by breadth-first search to mark depth layer by layer.

[0029] In some embodiments, if there are multiple top-level design files in the design file package, multiple independent file tree structures can be constructed and depth-marked respectively, and the detection process of each subtree can be completed in sequence.

[0030] In some embodiments, mixed parsing of multiple hardware description language files such as Verilog, VHDL, and SystemVerilog can be supported, and it is not limited to a single language type of design file package.

[0031] Step 2: Based on the file tree structure with depth marking, select an unparsed design file from the file with depth N, parse its timing logic part and input / output signal list respectively, extract the clock signal and data signal and classify them into the corresponding signal set respectively; The signal set includes the internal clock set, the internal glued data set, the clock output set, the clock input set, the data output set, and the data input set.

[0032] The specific implementation method of step 2 will be described in detail below.

[0033] S2.1: Based on the file tree structure generated in step 1, select a design file that has not yet been parsed as the current processing object from all file nodes corresponding to the current traversal depth N.

[0034] S2.1: Perform syntax parsing on the internal timing logic part of the current design file, identify the timing logic units inside the file, and extract clock signals and data signals from them; Internal clock signals that do not belong to the input / output ports of this design file are classified into the internal clock set, and the file tree path and clock name corresponding to each clock signal are recorded. Data signals transmitted across clock domains within a file are grouped into an internal glued data set, and the source clock file tree path and destination clock file tree path corresponding to each data signal are recorded.

[0035] S2.2: Parse the input / output signal list of the current design file and classify them into clock signals and data signals according to their type; Clock signals are categorized into clock input set and clock output set according to their transmission direction. Data signals are categorized into data input and data output sets according to their transmission direction, and the file tree path corresponding to each port signal is recorded.

[0036] The source clock file tree path refers to the file tree path of the clock to which the corresponding data signal generation logic belongs, and the destination clock file tree path refers to the file tree path of the clock to which the corresponding data signal sampling logic belongs.

[0037] By breaking down the analysis process into two dimensions—internal timing logic and input / output ports—it can clearly distinguish between internal module signals and external interface signals. This not only fully covers cross-clock domain transmission paths within the file but also reserves standardized interface data for cross-level signal connections. By transforming hardware description language text code into structured sets of categorized signals and abstract circuit logic into computable and comparable standardized data objects, it provides a unified data foundation for subsequent cross-file signal path tracing and cross-clock domain risk assessment, ensuring the accuracy and traceability of subsequent bonding and inspection processes.

[0038] In some embodiments, the parsing of the internal sequential logic part can be implemented in different ways, such as regular expression matching and abstract syntax tree parsing. Among them, the parsing method based on abstract syntax tree has higher syntax recognition accuracy and complex logic adaptation capability.

[0039] In some embodiments, the internal glued data set can supplement the recording of attribute information such as data signal bit width, signal type, and synchronizer configuration, for subsequent risk level classification and screening of checkpoints.

[0040] In some embodiments, the parsing of the input / output signal list can support the identification and splitting of complex port forms such as bus ports and array ports, adapting to the cross-clock domain detection requirements of multi-bit wide signals.

[0041] In some embodiments, corresponding parsing logic can be adapted for design files in the gate-level netlist format to support cross-clock domain detection in the netlist stage after synthesis.

[0042] Step 3: Based on the signal sets of the current design file obtained from parsing, determine whether there are subordinate sub-files in the current design file in combination with the file tree structure; if there are sub-files, then use the signal name matching and clock path tracing method to perform cross-file glue processing on the signal set of the current file and the corresponding signal set of each sub-file, update the source clock file tree path and the destination clock file tree path of each signal, and obtain the complete signal set with completed hierarchical mapping.

[0043] The specific implementation method of step 3 will be described in detail below.

[0044] S3.1: Based on the file tree structure obtained in step 1, query the node information corresponding to the current design file to determine whether the current design file has subordinate sub-files; if subordinate sub-files exist, perform cross-file glue processing; if subordinate sub-files do not exist, directly enter the cross-clock domain check stage.

[0045] S3.2: Traverse the clock input set of all sub-files in the current design file. If the clock input of a sub-file comes from the clock input set of the current design file or the internal clock set, add the source clock file tree path of the corresponding clock in the current design file to the source clock file tree path of the corresponding clock input in the sub-file to complete the full path tracing of the clock input of the sub-file.

[0046] S3.3: Traverse the data input sets of all sub-files in the current design file. If the data input of a sub-file comes from the data input set of the current design file or the internal glued data set, copy the source clock information of the corresponding data in the current design file to the source clock file tree path of the corresponding data input in the sub-file to complete the source clock path mapping of the sub-file data input.

[0047] S3.4: Traverse the clock output set and internal clock set of the current design file. If the clock output or internal clock of the current design file originates from the clock output set of the sub-file, add the file tree path of the corresponding clock output of the sub-file to the source clock file tree path of the corresponding clock output or internal clock of the current design file to complete the full path tracing of the clock output of the current design file.

[0048] S3.5: Traverse the data output set and internal glued data set of the current design file. If the data output or internal glued data of the current design file originates from the data output set of the sub-file, copy the source clock and destination clock information of the corresponding data output of the sub-file to the clock path of the corresponding data output or internal glued data of the current design file to complete the full path mapping of the data output of the current design file.

[0049] Cross-file bonding processing establishes a relationship between the port signals of a submodule and the internal signals of the upper-level module by matching signal names between different levels. This allows for the transmission of clock path information from the lower levels upwards, achieving full signal path traceability across levels. This mechanism solves the problem of signal paths being scattered across different files in modular design, ensuring that the source and destination clocks of each data transmission path have complete file tree path identifiers. This guarantees that cross-clock domain checks can cover the entire signal link, avoiding path breaks and missed detections caused by module partitioning.

[0050] In some embodiments, cross-file glue processing can support advanced matching logic such as signal bit width matching and port mapping expression parsing, adapting to port connection scenarios involving bit width conversion and logic combination.

[0051] In some embodiments, a signal alias mapping table can be introduced to associate and identify signals that have been renamed or indirectly connected, thereby improving the accuracy of bonding under complex connection relationships.

[0052] In some embodiments, the signal path after bonding can be checked for cyclic dependency to avoid path parsing anomalies caused by logical loops in the design code.

[0053] In some embodiments, for designs containing multi-level nested sub-files, a recursive glue method can be used to complete the path information transfer of all sub-levels layer by layer.

[0054] Step 4: Based on the complete signal set of the current design file and its sub-files after the glue update in Step 3, take the internal glue data set and data input set as the inspection objects, and generate cross-clock domain checkpoints at the corresponding levels through clock path consistency comparison and multi-purpose clock sampling judgment respectively; then, through a bottom-up hierarchical iteration mechanism with decreasing depth, repeat Step 2 to Step 4 to complete the file parsing, glue, and inspection at all depth levels, and obtain the checkpoint set of the entire design scope.

[0055] The specific implementation method of step 4 will be described in detail below.

[0056] S4.1: Traverse the internal glued data set of the current design file and its subfiles, comparing the source clock file tree path with the destination clock file tree path for each piece of internal glued data. If they are inconsistent, it indicates that the generation clock domain and the usage clock domain of the data signal are different, posing a risk of cross-clock domain transmission. Therefore, the data transmission path is determined to have a cross-clock domain risk. A checkpoint is generated based on this internal glued data and added to the checkpoint set. The checkpoint records the name of the data signal, the source clock path, the destination clock path, and the file location.

[0057] S4.2: Traverse the data input set of the current design file and its sub-files, and count the number of destination clock file tree paths corresponding to each data input; if the same data input is used for multiple different destination clock file tree paths, it indicates that the same data is used by multiple clock domains, and it is determined that the data input has the risk of multi-clock domain sampling. Based on the data, generate the corresponding checkpoint and add it to the checkpoint set.

[0058] S4.3: After completing the parsing, gluing, and checking of the current design file, determine whether there is an unparsed design file at the current traversal depth N; if there is, return to step 2 and continue to select the next unparsed design file for processing; if there is no unparsed design file, perform a depth reduction operation.

[0059] S4.4: Decrement the value of the traversal depth variable N by 1, and determine whether the updated depth variable N is greater than 0; if so, return to step 2 and continue parsing the design file at the corresponding depth; otherwise, complete the traversal of all levels to obtain a set of checkpoints covering the entire design.

[0060] Two types of targeted inspection rules cover two typical cross-clock domain risk scenarios: intra-module cross-clock transmission and single-input multi-clock domain sampling. This enables the identification of metastability issues in the vast majority of asynchronous clock domain interactions. The bottom-up, iterative inspection approach ensures that each level of inspection is based on complete underlying path information, preventing the omission of internal risks in lower-level submodules and accurately identifying cross-level cross-clock domain paths, achieving comprehensive, blind-spot-free inspection across the entire design scope. Furthermore, it eliminates the need for pre-specified clock constraints, automatically identifying clock domain relationships and adapting to early-stage design inspection requirements.

[0061] In some embodiments, synchronizer identification rules can be added. If there are already deployed two-stage synchronizers, asynchronous first-in-first-out memory, or other synchronization circuits on the cross-clock domain path, the corresponding checkpoints will be marked as low-risk or exempted to reduce invalid alarms.

[0062] In some embodiments, checkpoints can be classified into risk levels, and divided into three risk levels: high, medium, and low, based on factors such as the type of cross-clock domain signal, data bit width, and clock frequency difference, so that designers can prioritize high-risk issues.

[0063] In some embodiments, the iterative traversal method may employ variations of depth-first search or breadth-first search to adapt to design file packages of different sizes while ensuring the bottom-up parsing order.

[0064] In some embodiments, a new rule for checking reset signals across clock domains can be added to include the cross-domain transmission of asynchronous reset signals in the check scope, further improving the comprehensiveness of the detection.

[0065] Step 5: Based on the full set of design checkpoints, combined with deduplication, classification and location information completion methods, generate structured cross-clock domain detection results; these results can directly help designers locate the location and type of risk points, and guide design optimization and synchronization circuit supplementation.

[0066] All checkpoints in the checkpoint set are deduplicated to remove duplicate cross-clock domain paths; for each checkpoint, location information such as the corresponding design file path, signal name, source clock information, and destination clock information is added and categorized according to risk type.

[0067] By deduplicating and organizing data to avoid duplicate alarms, and supplementing location information to improve the readability of the results, the detection results can directly guide design corrections. The output content covers risk locations, signal attributes, and clock path information, eliminating the need for designers to trace back the code, effectively improving the efficiency of troubleshooting cross-clock domain issues; at the same time, the output results are not dependent on a specific development platform and can run independently of design tools, possessing good versatility.

[0068] In some embodiments, the detection results can be linked with programmable logic development tools to directly jump to the corresponding line of code in the design file, enabling rapid problem location.

[0069] In some embodiments, a test report can be generated based on checkpoint statistics, including statistical information such as the total number of risks, the distribution of risks at each level, and the proportion of risk types, to provide data support for design quality assessment.

[0070] In some embodiments, it is possible to export test result files that conform to industry standard formats, which facilitates data linkage with other static time series analysis and code review tools.

[0071] In some embodiments, corresponding risk rectification suggestions can be synchronously pushed in the output results, such as recommending adaptation solutions such as two-level synchronizers and asynchronous first-in-first-out memory, to help designers quickly fix problems.

[0072] The cross-clock domain detection method based on programmable logic design provided in this embodiment parses the design file package into a tree structure, sequentially parsing the design files from the deepest node to the root node, extracting the clock-related sets and data-related sets of each file, and generating cross-clock domain checkpoints after cross-file glue concatenation. This method has the following beneficial effects: First, it requires no development platform restrictions and has low input requirements; only the original design files are needed to complete the test, and it does not rely on specific programmable logic device development tools or static timing analysis tools.

[0073] Secondly, it intervenes early, automatically detecting cross-clock domain issues in the early stages of design, without having to wait until the design is completed to perform the detection, effectively avoiding design iterations caused by cross-clock domain issues.

[0074] Third, it supports mixed detection of multiple hardware description language files, and can process design files of different language types such as Verilog, VHDL, and SystemVerilog at the same time, without being limited to a single language file input.

[0075] Fourth, it does not require pre-specifying clock relationships and can automatically identify clock domains in each design file. It can automatically complete cross-clock domain detection through full-link traceability of signal paths, reducing the constraint configuration burden on designers.

[0076] Correspondingly, this application provides a cross-clock domain detection system based on programmable logic design, including: The file structure parsing module is used to obtain a design file package consisting of multiple hardware description language design files, perform tree structure parsing on the design file package, and perform depth marking on each file according to the file tree structure to obtain the file tree structure with depth marking and the maximum depth of the design file package. The signal parsing module is used to traverse the file tree structure layer by layer from the deepest level in a bottom-up direction, select the design files at each level for parsing, extract the clock signals and data signals of each design file, and classify the clock signals and data signals into the corresponding signal sets; the signal sets include the internal clock set, the internal glued data set, the clock output set, the clock input set, the data output set, and the data input set; The cross-file bonding module is used to determine whether there are subordinate sub-files for the current design file to be processed. If there are subordinate sub-files, the signal sets of the current design file and the corresponding signal sets of its sub-files are bonded together across files. The source clock file tree path and the destination clock file tree path of each signal are updated by matching signals between levels. The cross-clock domain check module is used to generate cross-clock domain checkpoints based on the internal glued data set and data input set that have completed glued updates, through clock path consistency comparison and multi-purpose clock sampling determination. Based on the cross-clock domain checkpoints at all levels, a checkpoint set is obtained.

[0077] It should be noted that, in the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another device, or some features may be ignored or not executed. The modules described as separate components may or may not be physically separated. The components shown as modules may be one or more physical units, that is, they may be located in one place or distributed in multiple different places. Some or all of the modules can be selected to achieve the purpose of the solution in this embodiment according to actual needs.

[0078] Furthermore, in the various embodiments of the present invention, the modules can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The integrated unit described above can be implemented in hardware or as a software functional unit.

[0079] An electronic device provided in this application includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements the steps of the cross-clock domain detection method based on programmable logic design as described in any of the above embodiments.

[0080] Another electronic device provided in this application embodiment may further include: an input port connected to a processor for transmitting multimodal data collected by an external acquisition device to the processor; a display unit connected to the processor for displaying the processor's processing results to the outside world; and a communication module connected to the processor for enabling communication between the electronic device and the outside world. The display unit may be a display panel, a laser scanning display, etc.; the communication method adopted by the communication module includes, but is not limited to, Mobile High Definition Link (HML), Universal Serial Bus (USB), High Definition Multimedia Interface (HDMI), and wireless connection (including Wi-Fi, Bluetooth, Bluetooth Low Energy, and IEEE 802.11s-based communication technology).

[0081] This application provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the steps of the cross-clock domain detection method based on programmable logic design as described in any of the above embodiments.

[0082] For descriptions of relevant parts in the cross-clock domain detection system, electronic device, and computer-readable storage medium based on programmable logic design provided in this application, please refer to the detailed descriptions of the corresponding parts in the cross-clock domain detection method based on programmable logic design provided in this application, which will not be repeated here. Furthermore, parts of the technical solutions provided in this application that are consistent with the implementation principles of corresponding technical solutions in the prior art have not been described in detail to avoid excessive elaboration.

[0083] The above content is only for illustrating the technical concept of the present invention and should not be construed as limiting the scope of protection of the present invention. Any modifications made to the technical solution based on the technical concept proposed in this invention shall fall within the scope of protection of the claims of this invention.

Claims

1. A cross-clock domain detection method based on programmable logic design, characterized in that, Includes the following steps: Step 1: Obtain a design file package consisting of multiple hardware description language design files, perform tree structure parsing on the design file package, and perform depth marking on each file according to the file tree structure to obtain the file tree structure with depth marking and the maximum depth of the design file package; Step 2: Starting from the deepest level, traverse the file tree structure layer by layer from bottom to top, select the design files of each level in turn for parsing, extract the clock signals and data signals of each design file, and classify the clock signals and data signals into the corresponding signal sets respectively. The signal set includes an internal clock set, an internal glued data set, a clock output set, a clock input set, a data output set, and a data input set; Step 3: For the current design file to be processed, determine whether it has subordinate sub-files; if subordinate sub-files exist, perform cross-file glue processing on the signal sets of the current design file and the corresponding signal sets of its sub-files, and update the source clock file tree path and destination clock file tree path of each signal through inter-level signal matching. Step 4: Based on the internal glued data set and data input set that have completed the glued update, generate cross-clock domain checkpoints by comparing clock path consistency and determining multi-purpose clock sampling. Based on the cross-clock domain checkpoints at all levels, obtain the checkpoint set.

2. The cross-clock domain detection method based on programmable logic design according to claim 1, characterized in that, Step 1, which involves parsing the tree structure of the design file package, includes: Identify the hierarchical calls and dependencies between various design files, and construct a file tree structure with the top-level design file as the root node and the bottom-level sub-module design files as leaf nodes; Each design file is marked with a depth according to the hierarchical rule from root node to leaf node, and the depth value corresponding to the deepest leaf node is determined as the maximum depth of the design file package.

3. The cross-clock domain detection method based on programmable logic design according to claim 1, characterized in that, Step 2, parsing each design file, includes: The internal timing logic section of the design document is parsed, and internal clock signals that do not exist in the input / output signal list of the design document are included in the internal clock set. The file tree path and clock name of each clock signal are recorded. Data signals transmitted across clock domains internally are grouped into the internal glued data set, and the source clock file tree path and destination clock file tree path of each data signal are recorded.

4. The cross-clock domain detection method based on programmable logic design according to claim 1, characterized in that, Step 2, parsing each design file, also includes: The input and output signal list of the design document is parsed, and clock signals are classified into the clock input set and the clock output set according to the transmission direction, and data signals are classified into the data input set and the data output set according to the transmission direction.

5. The cross-clock domain detection method based on programmable logic design according to claim 1, characterized in that, The cross-document bonding process described in step 3 includes: If the clock input of a subfile comes from the clock input set of the current design file or the internal clock set, then the source clock file tree path of the corresponding clock in the current design file is added to the source clock file tree path of the corresponding clock input in the subfile. If the data input of the sub-file comes from the data input set of the current design file or the internal glued data set, then the source clock information of the corresponding data in the current design file will be copied to the source clock file tree path of the corresponding data input of the sub-file.

6. The cross-clock domain detection method based on programmable logic design according to claim 1, characterized in that, The cross-document bonding process described in step 3 also includes: If the clock output or internal clock used in the current design file originates from the clock output set of the sub-file, then the file tree path of the corresponding clock output of the sub-file is added to the source clock file tree path of the corresponding clock in the current design file; If the data output or internal glued data of the current design file originates from the data output set of the sub-file, then the source clock and destination clock information of the corresponding data output of the sub-file will be copied to the source clock file tree path of the corresponding data in the current design file.

7. The cross-clock domain detection method based on programmable logic design according to claim 1, characterized in that, The clock path consistency comparison in step 4 includes: Traverse the set of internally bonded data, and compare the source clock file tree path with the destination clock file tree path for each piece of internally bonded data. If the two are inconsistent, generate a checkpoint based on the internally bonded data.

8. The cross-clock domain detection method based on programmable logic design according to claim 1, characterized in that, Steps 2 through 4 are executed using a bottom-up hierarchical iterative approach, specifically as follows: Starting from the maximum depth level, after parsing, gluing and checking all unparsed design files at the current depth, the traversal depth value is decremented by 1, and the design files of the previous level are processed until all processing of the root node level is completed. All cross-clock domain checkpoints generated at all levels are summarized to obtain the final checkpoint set.

9. The cross-clock domain detection method based on programmable logic design according to claim 1, characterized in that, The multi-purpose clock sampling determination in step 4 includes: Traverse the data input set and count the number of destination clock file tree paths corresponding to each data input. If the same data input corresponds to multiple different destination clock file tree paths, then generate a checkpoint based on that data input.

10. A cross-clock domain detection system based on programmable logic design, characterized in that, include: The file structure parsing module is used to obtain a design file package consisting of multiple hardware description language design files, perform tree structure parsing on the design file package, and perform depth marking on each file according to the file tree structure to obtain the file tree structure with depth marking and the maximum depth of the design file package. The signal parsing module is used to traverse the file tree structure layer by layer from the deepest level in a bottom-up direction, select the design files at each level for parsing, extract the clock signals and data signals of each design file, and classify the clock signals and data signals into the corresponding signal sets; the signal sets include the internal clock set, the internal glued data set, the clock output set, the clock input set, the data output set, and the data input set; The cross-file bonding module is used to determine whether there are subordinate sub-files for the current design file to be processed. If there are subordinate sub-files, the signal sets of the current design file and the corresponding signal sets of its sub-files are bonded together across files. The source clock file tree path and destination clock file tree path of each signal are updated by matching signals between levels. The cross-clock domain check module is used to generate cross-clock domain checkpoints based on the internal glued data set and data input set that have completed glued updates, through clock path consistency comparison and multi-purpose clock sampling determination. Based on the cross-clock domain checkpoints at all levels, a checkpoint set is obtained.

Images