A method, device and storage medium for identifying a trigger signal
By extracting trigger signal features from FPGA design and verifying them using bidirectional transmission paths, the problem of low recognition accuracy in existing technologies is solved, achieving higher recognition accuracy and adaptability to complex designs, and supporting multi-level nested modules and cross-module signal transmission.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- AEROSPACE SOFTWARE TECH (BEIJING) CO LTD
- Filing Date
- 2025-12-10
- Publication Date
- 2026-07-31
AI Technical Summary
In existing FPGA designs, the identification methods for clock and reset signals rely on naming rule matching, which leads to the omission of non-standard named signals and the misjudgment of irrelevant signals, resulting in low identification accuracy and difficulty in adapting to complex design scenarios.
By acquiring the FPGA design code, traversing the module code to extract trigger signal features, and using bidirectional transmission path verification and reverse search algorithms to identify the trigger signals, recognition results are generated, reducing missed detections and false judgments.
It improves the accuracy of trigger signal recognition, enhances adaptability to complex design scenarios, significantly improves the accuracy and reliability of verification results, supports multi-level nested modules and cross-module signal transmission, and shortens the verification cycle.
Smart Images
Figure CN121303025B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer technology, and in particular to a trigger signal identification method, apparatus, device, and storage medium. Background Technology
[0002] In existing FPGA design flows, the identification of clock and reset signals is crucial for timing analysis and logic verification in the code. Most related methods rely on naming rule matching, using predefined keyword paths to perform regular expression matching on signal names, classifying signals that conform to the naming rules as clock or reset signals. However, this method is limited by standard named signals (such as the keyword "clk") in the naming rules, making it prone to missing non-standard named signals (such as "refcl") and potentially misclassifying irrelevant signals containing keywords (such as "clk_en)," resulting in low identification accuracy and difficulty in adapting to complex design scenarios. Summary of the Invention
[0003] To address the aforementioned technical problems, embodiments of this disclosure provide a trigger signal identification method, apparatus, device, and storage medium.
[0004] In a first aspect, embodiments of this disclosure provide a trigger signal identification method, including:
[0005] Obtain the FPGA design code for trigger signal recognition;
[0006] Traverse at least one module code within the FPGA design code and extract trigger signal features from block statements and / or target lists within the module code; wherein, the target list consists of at least one field corresponding to a preset identifier, and at least one field is used to characterize trigger signal information;
[0007] Functional identification is performed on the characteristics of the trigger signal to determine at least one trigger signal;
[0008] Based on at least one trigger signal and the name of the trigger signal in the corresponding module code, generate trigger signal identification results.
[0009] Optionally, the block statement is an always block, the target list is a list of sensitive terms in the always block, and at least one field includes the trigger signal and the edge type of the trigger signal.
[0010] Optionally, after performing functional identification on the trigger signal characteristics to determine at least one trigger signal, the method further includes:
[0011] Analyze the design hierarchy of the FPGA design code and establish a bidirectional transmission path to characterize global signal relationships based on the design hierarchy.
[0012] Verify at least one trigger signal along the transmission path in at least one direction of the bidirectional transmission path, and if the verification passes, determine the final trigger signal from the at least one trigger signal.
[0013] Optionally, the bidirectional transmission path includes a forward transmission path and a reverse transmission path. Verifying at least one trigger signal along the transmission path in at least one direction of the bidirectional transmission path includes:
[0014] When using a forward transmission path for verification, at least one trigger signal is verified layer by layer along the mapping relationship between different modules of the same signal recorded in the design hierarchy; wherein, the mapping relationship is used to characterize the hierarchical relationship between the combined name composed of signal name and module name; and / or,
[0015] When using a reverse transmission path for verification, the reverse search algorithm traces back from the target submodule corresponding to the trigger signal to the top-level module, and verifies the trigger signal based on the known signals in the top-level module; the FPGA design code includes the code of the target submodule and the top-level module.
[0016] Optionally, verifying at least one trigger signal along the transmission path in at least one direction of the bidirectional transmission path includes:
[0017] If the trigger signal characteristics are determined to be ambiguous, then at least one trigger signal is directly verified using the reverse transmission path.
[0018] Optionally, after performing functional identification on the trigger signal characteristics to determine at least one trigger signal, the method further includes:
[0019] When at least one trigger signal includes a reset signal, analyze the triggering conditions and / or execution logic in the target block statement corresponding to the reset signal to determine the reset type of the reset signal;
[0020] Based on at least one trigger signal and the name of the trigger signal in the corresponding module code, generate trigger signal identification results, including:
[0021] Based on at least one trigger signal, the reset type, and the name of the trigger signal in the corresponding module code, generate the trigger signal identification result.
[0022] Optionally, after generating the trigger signal identification result, the method further includes:
[0023] Obtain adjustment information for the FPGA design code;
[0024] The bidirectional transmission path is updated based on the adjustment information, and at least one trigger signal is re-determined based on the updated bidirectional transmission path.
[0025] Secondly, embodiments of this disclosure provide a trigger signal identification device, comprising:
[0026] The acquisition unit is used to acquire the FPGA design code to be identified by the trigger signal;
[0027] The feature extraction unit is used to traverse at least one module code within the FPGA design code and extract trigger signal features from block statements and / or target lists in the module code; wherein, the target list consists of at least one field corresponding to a preset identifier, and at least one field is used to characterize trigger signal information;
[0028] A signal determination unit is used to identify the function of the trigger signal characteristics and determine at least one trigger signal;
[0029] The result generation unit is used to generate a trigger signal identification result based on at least one trigger signal and the name of the trigger signal in the corresponding module code.
[0030] Thirdly, embodiments of this disclosure provide an electronic device, including:
[0031] Memory;
[0032] Processor; and
[0033] Computer programs;
[0034] The computer program is stored in memory and configured to be executed by a processor to implement the first aspect of the method described above.
[0035] Fourthly, embodiments of this disclosure provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in the first aspect above.
[0036] The trigger signal identification method disclosed herein includes: acquiring FPGA design code to be identified; traversing at least one module code within the FPGA design code, and extracting trigger signal features from block statements and / or target lists in the module code; wherein the target list consists of at least one field corresponding to a preset identifier, and the at least one field is used to characterize trigger signal information; performing functional identification on the trigger signal features to determine at least one trigger signal; and generating a trigger signal identification result based on the at least one trigger signal and its corresponding name in the module code. The method provided in this application improves the accuracy of trigger signal identification and is more adaptable to complex design scenarios. Attached Figure Description
[0037] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.
[0038] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0039] Figure 1 A flowchart illustrating a trigger signal identification method provided in an embodiment of this disclosure;
[0040] Figure 2 A design block diagram of the FPGA design code provided in the embodiments of this disclosure;
[0041] Figure 3 This is a technical framework diagram of a trigger signal recognition method provided in an embodiment of the present disclosure;
[0042] Figure 4 This is a schematic diagram of the structure of a trigger signal recognition device provided in an embodiment of the present disclosure;
[0043] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation
[0044] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.
[0045] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some, and not all, of the embodiments of this disclosure.
[0046] To address the aforementioned technical problems, this disclosure provides a trigger signal identification method. This will be described in detail through one or more of the following embodiments.
[0047] The trigger signal recognition method provided in this disclosure is applicable to trigger signal recognition scenarios. This method can be executed by a trigger signal recognition device, which can be implemented in software and / or hardware and can be integrated into an electronic device. The electronic device can include, but is not limited to, mobile terminals such as smartphones, laptops, digital radio receivers, personal digital assistants (PDAs), tablet PCs, PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), wearable devices, etc., as well as fixed terminals such as digital televisions, desktop computers, smart home devices, etc.
[0048] Figure 1 This is a flowchart illustrating a trigger signal identification method provided in an embodiment of the present disclosure, specifically including as follows: Figure 1 The following steps are shown:
[0049] S101. Obtain the FPGA design code for trigger signal recognition.
[0050] Understandably, FPGA design code is typically written using a hardware description language to describe an independent functional unit. FPGA design code consists of multiple module codes, each responsible for implementing a specific function. For example, module code might describe functions related to clock and / or reset signals. Modules are the basic building blocks of the design and can contain logic, registers, state machines, etc. In FPGA module design, there may also be hierarchical relationships between multiple modules, which are reflected in the code of each module.
[0051] For example, Figure 2 The design block diagram of the FPGA design code provided in the embodiments of this disclosure illustrates a hierarchical FPGA module design, such as... Figure 2 As shown, multiple modules include a top-level module (top, also known as the first-level module) and several sub-modules subA, subB, subC, and subD. SubA and subC are second-level modules, subB and subD are third-level modules, and subA and subC are sub-modules of top. Correspondingly, subB and subD are sub-modules of subA and subC, respectively, and so on. Figure 2The interconnection between the top-level module and multiple sub-modules is also demonstrated, and synchronization is achieved through a clock signal distribution network. One clock signal forward transmission path is shown: top transmits clock signal 'a' to subA, and then subA transmits clock signal 'b' to subB, where clock signal 'b' is determined based on clock signal 'a', or clock signal 'b' is clock signal 'a'. Other possible transmission paths are not described in detail.
[0052] Understandably, trigger signal identification refers to the identification of clock signals and / or reset signals. It can also identify other trigger signals in the FPGA design code as needed, which is not limited here.
[0053] S102. Traverse at least one module code within the FPGA design code and extract trigger signal features from block statements and / or target lists in the module code.
[0054] The target list consists of at least one field corresponding to a preset identifier, and the at least one field is used to characterize the trigger signal information.
[0055] Understandably, based on S101 above, the module code includes at least one block statement. Within this block statement, the target block statement for trigger signal feature extraction is defined. The module code typically begins with the `module` keyword and ends with `endmodule`. The module name (e.g., `subA`) and port list (e.g., `clk_a`) in the module code define the module's input and output interfaces. A block statement is a logical block formed by combining multiple statements. Each block statement includes at least one list, such as a port list, parameter list, and sensitivity list. Each list consists of at least one field, which represents the corresponding attribute information. At least one list includes a target list, such as `@(posedge clk or negedgereset)`, where `@` is a preset identifier, and `posedge clk or negedge reset` are at least one field corresponding to `@`. For example, the first field might be `posedge clk`, and the second field might be `negedge reset`. The target list represents the attribute information of the trigger signal, etc. Subsequently, trigger signal features can be extracted from the entire block statement, which contains contextual information; alternatively, trigger signal features can be extracted directly from the target list, which accurately reflects the name characteristics of the trigger signal; or, trigger signal features can be extracted from both the block statement and the target list, which not only accurately reflects the name characteristics of the trigger signal but also contains contextual information about that name. The specific method for extracting trigger signal features is not limited. This method of traversing the FPGA design code structure to perform semantic inference on the trigger signal function effectively reduces reliance on naming rules, further reducing the false negative rate and false positive rate, and improving the accuracy of recognition.
[0056] The block statement is an always block, the target list is the sensitivity list in the always block, and at least one field includes the trigger signal and the edge type of the trigger signal.
[0057] Understandably, target block statements characterize the execution logic and / or triggering conditions of trigger signals. Specifically, they can be always blocks, which are procedural blocks in Verilog used to describe sequential or combinational logic. The statements within them are procedural statements, executed sequentially. Furthermore, always blocks continue running from the start of the simulation until its end. The target list is the sensitivity list within the target block statements, specifically the sensitivity list within an always block. The execution of the always block is controlled by the sensitivity list. For example, a sensitivity list of always @(posedge clk or posedge reset) indicates that the logic within this block executes once when the rising edge of clk or the rising edge of reset arrives. For instance, a target block statement might include multiple statements like "always@(posedge clk or negedge reset); begin; if (!reset); q≤1b; else; q≤data; end", where "posedge clk or negedge reset" are contents of the target list, "clk and reset" are trigger signals, and "posedge and negedge" are the edge types of the trigger signals.
[0058] S103. Perform functional identification on the characteristics of the trigger signal to determine at least one trigger signal.
[0059] Understandably, based on the above S102, functional identification is performed on the trigger signal characteristics, such as identifying the trigger signal's alias (i.e., referential name), implemented function, implemented logic, and / or implemented conditions, to determine at least one trigger signal. Other possible trigger signal identification methods are not limited. Understandably, each target block statement in each module code of the FPGA design code can identify at least one trigger signal, such as a clock signal and / or a reset signal. For example, "aa1" is identified as a clock signal from target block statement a1 in module a, and "aa2" is also identified as a clock signal from target block statement a2 in module a. That is, the number of target block statements in each module is variable, and the identifier, alias, or field name of the same signal identified in a certain number of target block statements can be different, for example, "aa1" and "aa2" are different. The identifier of the same signal identified between different modules may also be different. For another example, "bb" is identified as a reset signal from target block statement b in module a. That is, the number and type of trigger signals identified from a module are variable.
[0060] Optionally, after performing functional identification on the trigger signal characteristics to determine at least one trigger signal, the method further includes:
[0061] Analyze the design hierarchy of the FPGA design code and establish a bidirectional transmission path to characterize global signal relationships based on the design hierarchy; verify at least one trigger signal along the transmission path in at least one direction of the bidirectional transmission path, and if the verification is successful, determine the final trigger signal from at least one trigger signal.
[0062] The bidirectional transmission path includes the forward transmission path and the reverse transmission path.
[0063] Understandably, after completing the block statement feature analysis or reset signal type determination, the design hierarchy of the FPGA design code is analyzed, for example, by traversing the design hierarchy from top to bottom, as described above. Figure 2 The hierarchical structure shown traverses from top to subA and then to subB, achieving full module coverage of the design through a hierarchical traversal algorithm. Furthermore, the design hierarchy can be recorded in the form of "top, subA, subB," with no restrictions on other possible formats representing the hierarchy between modules. Subsequently, a bidirectional transmission path is established based on the design hierarchy, representing the global signal relationships in the FPGA design code. This bidirectional transmission path includes a forward transmission path and a reverse transmission path. A forward transmission path refers to transmission from the top-level module to the last sub-module, such as "top→subA→subB," while a reverse transmission path refers to transmission from the last sub-module to the top-level module, such as "subB→subA→top." This bidirectional path verification mechanism effectively avoids missed detections and false positives, exhibiting high accuracy.
[0064] Optionally, at least one trigger signal is verified along the transmission path in at least one direction of the bidirectional transmission path, which can be achieved through the following steps:
[0065] When using a forward transmission path for verification, at least one trigger signal is verified layer by layer along the mapping relationship between different modules of the same signal recorded in the design hierarchy; wherein the mapping relationship is used to characterize the hierarchical relationship between the combined names composed of signal names and module names; and / or, when using a reverse transmission path for verification, the trigger signal is verified by backtracking from the target submodule corresponding to the trigger signal to the top-level module through a reverse search algorithm, and the trigger signal is verified based on the known signals in the top-level module; wherein the FPGA design code includes the code of the target submodule and the top-level module.
[0066] Understandably, at least one trigger signal can be verified using any transmission path in the bidirectional transmission path, or at least one trigger signal can be verified using separate bidirectional transmission paths. The specific verification order is not limited, and this is used to check whether a trigger signal is correct in the FPGA design. Specifically, the verification path to be used is determined within the bidirectional transmission path. If a forward transmission path is used for verification, at least one trigger signal is verified layer by layer along the mapping relationship of the same signal between different modules recorded in the design hierarchy. The verification process of the forward transmission path is also the forward propagation process, searching for paths along the signal alias mapping relationship recorded in the design hierarchy, such as... Figure 2 The design hierarchy shown shows a forward propagation pattern: top.clk → subA.clk_a → subB.clk_b. This means the clock signal is transmitted sequentially from the top-level module's clock port to the transmission ports of each sub-module. Here, subA.clk_a represents the clk_a clock port of subA (module name). The signal name can be either a port name (e.g., clk_a) or a specific signal name; subA.clk_a is denoted as the combined name. If a reverse propagation path is used for verification, the process starts from the sub-module containing the trigger signal (i.e., the target sub-module) and uses a reverse search algorithm to search upwards along the reverse propagation path until the top-level module is found. The known input signals in the top-level module are then used to determine if the trigger signal meets expectations; in other words, the trigger signal is verified through backtracking. The reverse search algorithm (e.g., DFS, Depth-First Search) works as follows: starting from the target sub-module, the source of the signal is searched upwards, and then the signal is traced backwards along the direction of transmission, gradually backtracking to the upper-level modules and finally reaching the top-level module. Figure 2 The reverse traversal process shown is: subB.clk_b → subA.clk_a → top.clk. Furthermore, top-level modules typically have explicit input interfaces (such as clock, reset, and control signals), which are known, confirmed, and predictable. These known signals are then used as references to deduce the expected behavior of trigger signals in submodules. Finally, the trigger signals are compared with theoretical values to determine if they are correct or if there are any logical errors. Using the DFS algorithm can further improve processing efficiency and perform efficiency optimization.
[0067] Optionally, at least one trigger signal is verified along the transmission path in at least one direction of the bidirectional transmission path, which can be achieved through the following steps:
[0068] If the trigger signal characteristics are determined to be ambiguous, then at least one trigger signal is directly verified using the reverse transmission path.
[0069] Understandably, before verifying the trigger signal via a bidirectional transmission path, it's advisable to first determine whether the extracted trigger signal features are fuzzy, as fuzzy features cannot determine the specific trigger signal. For example, when identifying a trigger signal based on its features, it might be impossible to determine if the trigger signal is a clock signal, meaning it's an unknown signal. In this case, the system directly traces back from the target submodule to which the unknown signal belongs to the top-level module via the reverse transmission path to the already confirmed trigger signal (referred to as the confirmed signal), establishing an authentication link. Then, the unknown signal is identified based on the confirmed signal. In other words, when the signal identity cannot be confirmed based on the trigger signal features, further judgment is made through global signal transmission relationships.
[0070] Understandably, if the trigger signal characteristics are determined to be obvious or clearly defined, the clock signal and / or reset signal can be directly identified, without requiring backtracking verification through the aforementioned bidirectional transmission path. Examples include the standard names clk and reset. In one embodiment, multiple trigger signals may contain some unknown signals and some defined signals; that is, some trigger signals have obvious characteristics, while others have ambiguous characteristics. In another embodiment, the target signal for bidirectional transmission path verification can be selected from among the multiple trigger signals; that is, the trigger signal to be verified can be chosen independently, as can the verification path.
[0071] Optionally, after performing functional identification on the trigger signal characteristics to determine at least one trigger signal, the method further includes:
[0072] If at least one trigger signal includes a reset signal, analyze the triggering conditions and / or execution logic in the target block statement corresponding to the reset signal to determine the reset type of the reset signal.
[0073] Understandably, if the identified trigger signal is a reset signal, the triggering conditions and / or execution logic in the target block statement containing the reset signal are further analyzed to determine the reset type, which includes asynchronous and synchronous resets. This correlation analysis between block statement triggering characteristics and execution logic solves the naming rule limitation problem and improves the accuracy of judgment. Understandably, bidirectional transmission path verification can be performed after the reset type determination is completed.
[0074] S104. Generate trigger signal identification results based on at least one trigger signal and the name of the trigger signal in the corresponding module code.
[0075] Understandably, based on S103 above, the referential name refers to the actual name used by the trigger signal in its target module code (such as reset, enable, trigger_in, etc.). Mapping the trigger signal to its name in the target module code forms a structured output result, facilitating subsequent analysis or verification. The trigger signal can be determined directly based on its characteristics (such as in cases with obvious characteristics), or it can be the final trigger signal verified through a bidirectional transmission path, or it can be determined based on reverse backtracking (such as in cases with ambiguous characteristics). In addition, the verification process of the trigger signal can also be recorded in the recognition result to intuitively demonstrate the entire recognition process of the trigger signal to the user.
[0076] Optionally, trigger signal identification results can be generated based on at least one trigger signal and the name of the trigger signal in the corresponding module code. This can be achieved through the following steps:
[0077] Based on at least one trigger signal, the reset type, and the name of the trigger signal in the corresponding module code, generate the trigger signal identification result.
[0078] Understandably, the identification results may further include the reset type of the reset signal, and other possible information during the identification process can be added to the identification results, which will not be elaborated here.
[0079] Optionally, after generating the trigger signal identification result, the method further includes:
[0080] Obtain adjustment information for the FPGA design code; update the bidirectional transmission path based on the adjustment information; and redetermine at least one trigger signal based on the updated bidirectional transmission path.
[0081] Understandably, after displaying the recognition results to the user, the system receives adjustment information from the user regarding the FPGA design code. This adjustment information may specifically include changes to execution logic, designator names, etc. Subsequently, based on the adjustment information, the trigger signal features are re-extracted, the bidirectional transmission path is updated, and at least one trigger signal is re-determined based on the updated bidirectional transmission path. In other words, the FPGA design code and recognition results can be adjusted in real time based on user feedback. For specific implementation details, please refer to the above embodiment; further elaboration is not provided here.
[0082] For example, Figure 3 This is a technical framework diagram of a trigger signal recognition method provided in an embodiment of the present disclosure. Figure 3The technical framework shown includes a single-module feature extraction engine, hierarchical signal tracing, and global signal association verification. The single-module feature extraction engine is used to extract trigger signal features, including block statement feature analysis and reset type discrimination. Block statement feature analysis analyzes block statement trigger signals, and reset type discrimination determines the reset type. Hierarchical signal tracing is used for DFS signal tracing and propagation path establishment, including top-down traversal of levels and construction of hierarchical connection relationships. Specifically, the DFS algorithm is used for forward propagation path recording. Global signal association verification, in reverse path backtracking, includes sub-module signal triggering, DFS reverse search, and top-level signal association. The forward path transmission process is described in the example above and will not be repeated here.
[0083] This disclosure provides a trigger signal identification method that employs a hierarchical traversal algorithm to automatically scan and analyze all modules in an FPGA design. This ensures the verification process covers the entire design structure without manual intervention, significantly improving the automation level of the verification process. A bidirectional path verification mechanism is subsequently introduced, performing forward tracing from the top to the target and backtracking from the target back to the top. This dual verification effectively avoids missed detections and false positives, significantly improving the accuracy and reliability of the verification results. Furthermore, the path finding and signal propagation analysis process is optimized using the DFS algorithm during verification, significantly improving processing speed and resource utilization, shortening the verification cycle, and meeting the development needs of high-performance FPGAs. It also supports complex engineering scenarios such as multi-level nested modules, cross-module signal transmission, and signal renaming, demonstrating good compatibility and flexibility for complex design structures and making it widely applicable to various large-scale FPGA design projects. The generated verification results can serve as reliable input for subsequent FPGA design inspection tasks, helping to identify potential logic errors and interface anomalies in advance, thereby reducing design risks and improving overall design quality and stability.
[0084] Figure 4 This is a schematic diagram of a trigger signal recognition device provided in an embodiment of the present disclosure. The trigger signal recognition device provided in this embodiment can execute the processing flow provided in the embodiment of the trigger signal recognition method, such as... Figure 4 As shown, the trigger signal recognition device 400 includes:
[0085] Acquisition unit 401 is used to acquire the FPGA design code to be identified by trigger signal;
[0086] The feature extraction unit 402 is used to traverse at least one module code in the FPGA design code and extract trigger signal features from block statements and / or target lists in the module code; wherein, the target list is composed of at least one field corresponding to a preset identifier, and at least one field is used to characterize trigger signal information;
[0087] The signal determination unit 403 is used to perform functional identification on the characteristics of the trigger signal and determine at least one trigger signal;
[0088] The result generation unit 404 is used to generate a trigger signal identification result based on at least one trigger signal and the name of the trigger signal in the corresponding module code.
[0089] The block statement is an always block, the target list is the sensitivity list in the always block, and at least one field includes the trigger signal and the edge type of the trigger signal.
[0090] Optionally, the trigger signal recognition device 400 is also used for:
[0091] Analyze the design hierarchy of the FPGA design code and establish a bidirectional transmission path to characterize global signal relationships based on the design hierarchy.
[0092] Verify at least one trigger signal along the transmission path in at least one direction of the bidirectional transmission path, and if the verification passes, determine the final trigger signal from the at least one trigger signal.
[0093] The bidirectional transmission path includes the forward transmission path and the reverse transmission path.
[0094] Optionally, the signal determination unit 403 is used for:
[0095] When using a forward transmission path for verification, at least one trigger signal is verified layer by layer along the mapping relationship between different modules of the same signal recorded in the design hierarchy; wherein, the mapping relationship is used to characterize the hierarchical relationship between the combined name composed of signal name and module name; and / or,
[0096] When using a reverse transmission path for verification, the reverse search algorithm traces back from the target submodule corresponding to the trigger signal to the top-level module, and verifies the trigger signal based on the known signals in the top-level module; the FPGA design code includes the code of the target submodule and the top-level module.
[0097] Optionally, the signal determination unit 403 is used for:
[0098] If the trigger signal characteristics are determined to be ambiguous, then at least one trigger signal is directly verified using the reverse transmission path.
[0099] Optionally, the trigger signal recognition device 400 is also used for:
[0100] When at least one trigger signal includes a reset signal, analyze the triggering conditions and / or execution logic in the target block statement corresponding to the reset signal to determine the reset type of the reset signal;
[0101] Based on at least one trigger signal and the name of the trigger signal in the corresponding module code, generate trigger signal identification results, including:
[0102] Based on at least one trigger signal, the reset type, and the name of the trigger signal in the corresponding module code, generate the trigger signal identification result.
[0103] Optionally, the trigger signal recognition device 400 is also used for:
[0104] Obtain adjustment information for the FPGA design code;
[0105] The bidirectional transmission path is updated based on the adjustment information, and at least one trigger signal is re-determined based on the updated bidirectional transmission path.
[0106] Figure 4 The trigger signal recognition device in the illustrated embodiment can be used to execute the technical solution of the above method embodiment. Its implementation principle and technical effect are similar, and will not be repeated here.
[0107] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. See below for details. Figure 5 The diagram illustrates a structural schematic suitable for implementing the electronic device 500 in the embodiments of this disclosure. The electronic device 500 in the embodiments of this disclosure may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), wearable electronic devices, etc., as well as fixed terminals such as digital TVs, desktop computers, smart home devices, etc. Figure 5 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.
[0108] like Figure 5 As shown, the electronic device 500 may include a processing unit 501 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a storage device 508 into a random access memory (RAM) 503 to implement the trigger signal recognition method as described in the embodiments of this disclosure. The RAM 503 also stores various programs and data required for the operation of the electronic device 500. The processing unit 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.
[0109] Typically, the following devices can be connected to I / O interface 505: input devices 506 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 508 including, for example, magnetic tapes, hard disks, etc.; and communication devices 509. Communication device 509 allows electronic device 500 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 5 An electronic device 500 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.
[0110] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts, thereby implementing the trigger signal recognition method described above. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 509, or installed from a storage device 508, or installed from a ROM 502. When the computer program is executed by the processing device 501, it performs the functions defined in the methods of embodiments of this disclosure.
[0111] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.
[0112] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.
[0113] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.
[0114] Optionally, when one or more of the above-described procedures are executed by the electronic device, the electronic device may also execute other steps of the above embodiments.
[0115] Computer program code for performing the operations of this disclosure can be written in one or more programming languages or a combination thereof, including but not limited to object-oriented programming languages such as Java, Smalltalk, and C++, as well as conventional procedural programming languages such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).
[0116] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.
[0117] The units described in the embodiments of this disclosure can be implemented in software or hardware. The names of the units are not, in some cases, intended to limit the specific unit.
[0118] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.
[0119] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.
[0120] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or gateway that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or gateway. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or gateway that includes said element.
[0121] The above description is merely a specific embodiment of this disclosure, enabling those skilled in the art to understand or implement it. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. A method of trigger signal identification, the method comprising: receiving a signal; determining a signal characteristic of the signal; and identifying the signal as a trigger signal based on the signal characteristic. include: Obtain the FPGA design code for trigger signal recognition; Traverse at least one module code within the FPGA design code and extract trigger signal features from block statements and / or target lists within the module code; wherein the target list consists of at least one field corresponding to a preset identifier, the at least one field being used to characterize trigger signal information, and the trigger signal features including name features reflecting the trigger signal name, and / or context information of the trigger signal name; The trigger signal features are functionally identified to determine at least one trigger signal. The functional identification includes identifying the referent name, implemented function, implemented logic and / or implemented conditions of the trigger signal in the trigger signal features. The design hierarchy of the FPGA design code is analyzed, and a bidirectional transmission path is established based on the design hierarchy to characterize global signal relationships. The bidirectional transmission path is used to characterize global signal relationships in the FPGA design code, including a forward transmission path and a reverse transmission path. Global signal association verification of the at least one trigger signal along at least one direction of the bidirectional transmission path includes: when the trigger signal feature is an ambiguous feature or the trigger signal is an unknown signal, tracing back from the target submodule to which the trigger signal belongs to the top-level module along the reverse transmission path using a reverse search algorithm, and verifying the trigger signal based on the known signals in the top-level module; and verifying the trigger signal layer by layer along the forward transmission path based on the mapping relationship between the same signal and different modules. If the verification is successful, a trigger signal identification result is generated based on the at least one trigger signal and the name of the at least one trigger signal in the corresponding module code.
2. The method of claim 1, wherein, The block statement is an always block, the target list is a sensitivity list in the always block, and the at least one field includes a trigger signal and the edge type of the trigger signal.
3. The method of claim 1, wherein, Verifying the at least one trigger signal along the transmission path in one direction of the bidirectional transmission path includes: When verifying using the forward transmission path, the at least one trigger signal is verified layer by layer along the mapping relationship between different modules of the same signal recorded in the design hierarchy; wherein, the mapping relationship is used to characterize the hierarchical relationship between the combined name composed of signal name and module name; or, When using the reverse transmission path for verification, the reverse search algorithm traces back from the target submodule corresponding to the trigger signal to the top-level module, and verifies the trigger signal based on the known signals in the top-level module; wherein, the FPGA design code includes the code of the target submodule and the top-level module.
4. The method of claim 1, wherein, After performing functional identification on the trigger signal features to determine at least one trigger signal, the method further includes: When the at least one trigger signal includes a reset signal, analyze the triggering conditions and / or execution logic in the target block statement corresponding to the reset signal to determine the reset type of the reset signal; The step of generating a trigger signal identification result based on the at least one trigger signal and its corresponding module code name includes: Based on the at least one trigger signal, the reset type, and the name of the at least one trigger signal in the corresponding module code, a trigger signal identification result is generated.
5. The method of claim 1, wherein, After generating the trigger signal identification result, the method further includes: Obtain adjustment information for the FPGA design code; The bidirectional transmission path is updated based on the adjustment information, and at least one trigger signal is re-determined based on the updated bidirectional transmission path.
6. A trigger signal recognition apparatus characterized by comprising: include: The acquisition unit is used to acquire the FPGA design code to be identified by the trigger signal; The feature extraction unit is used to traverse at least one module code within the FPGA design code and extract trigger signal features from block statements and / or target lists in the module code; wherein, the target list consists of at least one field corresponding to a preset identifier, the at least one field is used to characterize trigger signal information, and the trigger signal features include name features that reflect the trigger signal name, and / or context information of the trigger signal name; A signal determination unit is used to perform functional identification on the trigger signal features and determine at least one trigger signal. The functional identification includes identifying the referent name, implemented function, implemented logic and / or implemented conditions of the trigger signal in the trigger signal features. The trigger signal identification device is further configured to: analyze the design hierarchy of the FPGA design code, and establish a bidirectional transmission path for characterizing global signal relationships based on the design hierarchy, wherein the bidirectional transmission path is used to characterize global signal relationships in the FPGA design code, including a forward transmission path and a reverse transmission path; perform global signal association verification on the at least one trigger signal along the transmission path in at least one direction of the bidirectional transmission path, including: when the trigger signal feature is an ambiguous feature or the trigger signal is an unknown signal, backtracking from the target submodule to which the trigger signal belongs to the top-level module along the reverse transmission path using a reverse search algorithm, and verifying the trigger signal based on the known signals in the top-level module; and verifying the trigger signal layer by layer along the forward transmission path based on the mapping relationship between the same signal and different modules; The result generation unit is used to generate a trigger signal identification result based on the at least one trigger signal and the name of the at least one trigger signal in the corresponding module code, provided that the verification is successful.
7. An electronic device, comprising: include: Memory; processor; as well as Computer programs; The computer program is stored in the memory and configured to be executed by the processor to implement the trigger signal identification method as described in any one of claims 1 to 5.
8. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program, when executed by a processor, implements the steps of the trigger signal identification method as claimed in any of claims 1 to 5.