A state machine checking method, device and computer equipment

Abstract

The present disclosure relates to the technical field of computer, and particularly relates to a state machine checking method and device and computer equipment; the method comprises the following steps: obtaining a syntax tree corresponding to a state machine and a target checking matter, the target checking matter comprising a checking object and a checking rule; finding a target sub-tree corresponding to the checking object from the syntax tree; judging whether the target sub-tree conforms to the checking rule; determining the normativity of the state machine according to the judging result; the present scheme realizes the automatic checking of the normativity of the state machine by locating and traversing the target sub-tree, reduces the cost of manual checking, ensures the checking coverage, reduces the error probability in the comprehensive and simulation stage, and improves the maintenance efficiency of the state machine.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a state machine inspection method, apparatus, and computer device. Background Technology

[0002] In modern digital circuit design, the Finite State Machine (FSM) is one of the core components for implementing complex control logic. Issues with the specification of the FSM can lead to serious errors such as latch problems and race conditions. Furthermore, these problems typically only surface during synthesis or simulation, requiring code rewriting and process repetition for repair, significantly extending the development cycle. Therefore, rule checking of the FSM is crucial.

[0003] Field-Programmable Gate Arrays (FPGAs) have become an ideal platform for implementing high-performance state machines due to their reconfigurability and parallel processing capabilities. Current FPGA design tools can only perform rule checks on state machines manually. Summary of the Invention

[0004] To address the aforementioned technical problems, this disclosure provides a state machine inspection method, apparatus, and computer device.

[0005] Firstly, this disclosure provides a state machine inspection method, the method comprising:

[0006] Obtain the syntax tree and target check items corresponding to the state machine. The target check items include the check objects and check rules. Find the target subtree corresponding to the check objects from the syntax tree. Determine whether the target subtree conforms to the check rules. Determine the standardization of the state machine based on the determination result.

[0007] Secondly, this disclosure provides a state machine checking device, the device comprising:

[0008] The first acquisition module is used to acquire the syntax tree and target check items corresponding to the state machine. The target check items include the check object and the check rule. The first search module is used to search for the target subtree corresponding to the check object from the syntax tree. The judgment module is used to judge whether the target subtree conforms to the check rule. The first determination module is used to determine the normality of the state machine based on the judgment result.

[0009] Thirdly, this disclosure provides a computer device, including:

[0010] The memory and processor are interconnected and communicate with each other. The memory stores computer instructions, and the processor executes the state machine checking method of the first aspect and any embodiment thereof by executing the computer instructions.

[0011] The technical solution provided in this disclosure has the following advantages compared with the prior art:

[0012] The state machine inspection method provided in this disclosure obtains the syntax tree and target inspection items corresponding to the state machine. The target inspection items include inspection objects and inspection rules. The method searches for the target subtree corresponding to the inspection object from the syntax tree. The method determines whether the target subtree conforms to the inspection rules. The method determines the standardization of the state machine based on the determination result. This solution achieves automated inspection of the standardization of the state machine by locating and traversing the target subtree. It also reduces the cost of manual inspection, ensures inspection coverage, reduces the probability of errors in the synthesis and simulation stages, and improves the maintenance efficiency of the state machine. Attached Figure Description

[0013] 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.

[0014] 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.

[0015] Figure 1 A flowchart illustrating the state machine inspection method provided in this embodiment of the disclosure;

[0016] Figure 2 A schematic diagram of the syntax tree corresponding to a single-stage state machine provided in an embodiment of this disclosure;

[0017] Figure 3 A schematic diagram corresponding to a single-stage state machine provided in an embodiment of this disclosure;

[0018] Figure 4 A schematic diagram of the syntax tree corresponding to the two-stage state machine provided in the embodiments of this disclosure;

[0019] Figure 5 A schematic diagram corresponding to the two-stage state machine provided in the embodiments of this disclosure;

[0020] Figure 6 A schematic diagram of the syntax tree corresponding to the three-segment state machine provided in the embodiments of this disclosure;

[0021] Figure 7A schematic diagram corresponding to the three-stage state machine provided in the embodiments of this disclosure;

[0022] Figure 8 A structural connection diagram of the state machine inspection device provided in the embodiments of this disclosure;

[0023] Figure 9 This is a structural connection diagram of a computer device provided in an embodiment of the present disclosure. Detailed Implementation

[0024] 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.

[0025] Numerous specific details are set forth in the following description to provide a thorough 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 a part of the embodiments of this disclosure, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without inventive effort are within the scope of protection of this disclosure.

[0026] 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 apparatus 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 apparatus. 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 apparatus that includes said element.

[0027] In modern digital circuit design, the Finite State Machine (FSM) is one of the core components for implementing complex control logic. By defining a finite number of states and transition rules between states, the FSM efficiently controls complex timing behaviors and is widely used in communication protocols (such as Universal Asynchronous Receiver / Transmitter (UART) and Serial Peripheral Interface (SPI), industrial control systems (such as Programmable Logic Controllers), embedded systems (such as autonomous driving controllers), and other fields.

[0028] Therefore, the standardization of state machines is crucial. Issues with the standardization of state machines can lead to serious errors such as latch problems and race conditions. Furthermore, these problems typically only surface during synthesis or simulation; fixing them requires rewriting the code and repeating the process, significantly extending the development cycle. Therefore, rule checks on state machines are particularly important.

[0029] Field-Programmable Gate Arrays (FPGAs) have become an ideal platform for implementing high-performance state machines due to their reconfigurability and parallel processing capabilities. However, current FPGA design tools (such as Xilinx Vivado and Intel Quartus) can only perform rule checks on the state machine manually.

[0030] To address this issue, embodiments of this disclosure provide a state machine inspection method, apparatus, and computer device that, by locating and traversing the target subtree, achieve automated inspection of state machine conformity, reduce the cost of manual inspection, ensure inspection coverage, reduce the probability of errors during synthesis and simulation, and improve the maintenance efficiency of the state machine.

[0031] In addition, FPGA design tools have significant shortcomings in the automated identification of state machines. Specifically, designers need to manually read the code to identify the state machine structure, which is not only time-consuming but also prone to errors, resulting in low identification efficiency.

[0032] To address this issue, embodiments of this disclosure provide a state machine inspection method, apparatus, and computer device that achieve automated identification of state machine structures by traversing nodes in a syntax tree, thereby saving labor costs, reducing identification time, and improving identification accuracy.

[0033] According to an embodiment of this disclosure, a state machine inspection method embodiment is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0034] This embodiment provides a state machine inspection method that can be used in FPGA design tools. Figure 1 This is a flowchart of a state machine checking method according to an embodiment of the present disclosure, such as... Figure 1 As shown, the process includes the following steps:

[0035] S101, obtain the syntax tree and target check items corresponding to the state machine.

[0036] In this context, the state machine is the state machine to be inspected, implemented using a hardware description language (HDL) such as VHDL or Verilog. The target inspection item is the item to be inspected, and there can be one or more target inspection items. For example, a target inspection item may include at least one of the following: current state register inspection, next state register inspection, clock signal inspection, state transition integrity inspection, and output logic inspection. The target inspection item includes the inspection object and inspection rules. The inspection object can be understood as the scope of inspection, and the inspection rules can be understood as the inspection standards. It should also be noted that a target inspection item may contain one or more inspection sub-items. When multiple inspection sub-items exist within a target inspection item, each sub-item has a corresponding inspection object and inspection rules.

[0037] Specifically, the state machine is input into a pre-built syntax parser to obtain the syntax tree corresponding to the state machine. In response to check instructions triggered by external factors, the target check items are retrieved from a pre-built coding standard rule base. Thus, the syntax tree corresponding to the state machine and the target check items are obtained.

[0038] It should be noted that the syntax parser corresponds to the hardware description language. For example, the hardware description language VHDL corresponds to the VHDL syntax parser, and the hardware description language Verilog corresponds to the Verilog syntax parser. The pre-built coding standard rule base includes check items in international standards and regulations, as well as check items that users can customize based on their own needs. Target check items can be check items selected by the user or check items that are defaulted to by the platform; this disclosure does not specifically limit this.

[0039] S102, find the target subtree corresponding to the object being inspected from the syntax tree.

[0040] The syntax tree includes signal declaration nodes, event-driven nodes, and branch nodes. Signal declaration nodes have at least two preset states in their node attributes; these preset states are the states defined in the state machine. Event-driven nodes include sequential event-driven nodes and composite event-driven nodes. The state machine structure is categorized into one-stage, two-stage, and three-stage types. Branch nodes correspond to case statements. It should be noted that after S101, there is a step for automatically identifying the state machine by traversing the syntax tree. The specific steps of this step are described in the subsequent corresponding implementation. The logical classification of event-driven nodes and the determination of the state machine structure type are obtained through automatic state machine identification, and will not be elaborated further here.

[0041] Specifically, the syntax tree is traversed, the syntax subtree corresponding to the object being inspected is found, and that syntax subtree is identified as the target subtree.

[0042] In some optional implementations, when the target check is a current state register check, the target check includes two sub-items: whether there is a current state register update in the combinational logic and whether there is a direct modification to the current state register in the combinational logic. In this embodiment, the check object corresponding to both sub-items is the syntax subtree rooted at the combinational event-driven node. In this embodiment, the syntax subtree rooted at the combinational event-driven node can be found in the syntax tree and identified as the target subtree.

[0043] In some optional implementations, when the target check is a next-state register check, the target check includes two sub-items. Specifically, it checks whether the next-state register is assigned a value in all possible transfer paths within the combinational logic, and whether there are direct modifications to the next-state register in the sequential logic. In the first sub-item, the object of the check is the syntax subtree (i.e., the target subtree) rooted at the event-driven node; in the second sub-item, the object of the check is the syntax subtree (i.e., the target subtree) rooted at the sequential event-driven node.

[0044] In some optional implementations, when the target check is a clock signal check, the target check includes two sub-items: whether the sequential logic correctly defines the clock edge and whether the combinational logic uses a clock signal. In the first sub-item, the object of the check is the syntax subtree (i.e., the target subtree) rooted at the timing event-driven node; in the second sub-item, the object of the check is the syntax subtree (i.e., the target subtree) rooted at the combinational event-driven node.

[0045] In some optional implementations, when the target check is a state transition integrity check, the target check includes two sub-items: whether the state transition process of the combinational logic covers all preset states, and whether the state transition process of the combinational logic contains default statements. The check objects corresponding to the first and second sub-items are both syntax subtrees rooted at branch nodes.

[0046] In some alternative implementations, when the target inspection item is an output logic inspection, the inspection object and inspection rules for the output logic inspection need to be discussed in conjunction with the state machine's structure type. When the target inspection item is an output logic inspection and the state machine's structure type is a single-segment structure, the inspection object is the syntax subtree rooted at the timing event-driven node. When the target inspection item is an output logic inspection and the state machine's structure type is a multi-segment structure, the inspection object is the syntax subtree rooted at the composite event-driven node.

[0047] S103, determine whether the target subtree meets the inspection rules.

[0048] Specifically, after finding the target subtree, it is determined whether the target subtree meets the inspection rules, and the judgment result is obtained.

[0049] In some optional implementations, when the target check is a current state register check, the check rule corresponding to the sub-item "whether there is a current state register update in the combinational logic" is: there is no assignment statement that assigns a next-state variable to a current state variable. The check rule corresponding to the sub-item "whether there is a direct modification to the current state register in the combinational logic" is: there is no assignment statement that assigns a preset state to a current state variable.

[0050] Specifically, this embodiment and all subsequent embodiments are illustrated using a state machine implemented in VHDL as an example.

[0051] In the current state register check, when checking for "whether there is a current state register update in the combinational logic," it is necessary to traverse the syntax subtree rooted at the combinational event-driven node and determine whether there is an assignment statement in this subtree that assigns a next-state variable to a current-state variable, such as `current_state <= next_state`. If it exists, it means that the syntax subtree rooted at the combinational event-driven node does not meet the check rule corresponding to the sub-item "whether there is a current state register update in the combinational logic." If it does not exist, it means that the syntax subtree rooted at the combinational event-driven node meets the check rule corresponding to the sub-item "whether there is a current state register update in the combinational logic." It should be noted that the assignment statement that assigns a next-state variable to a current-state variable is a node attribute. Therefore, when traversing the syntax subtree rooted at the combinational event-driven node, it is necessary to traverse each node in the syntax subtree and its corresponding node attribute to obtain the judgment result.

[0052] When checking for "whether there are direct modifications to the current state register in combinational logic", it is necessary to traverse the syntax subtree rooted at the combinational event-driven node and determine whether there are assignment statements in this syntax subtree that assign a preset state to the current state variable, such as current_state <= STATE_A, where STATE_A is the preset state defined in the state machine. If it exists, it means that the syntax subtree rooted at the combinational event-driven node does not meet the check rules corresponding to the sub-item "whether there are direct modifications to the current state register in combinational logic"; if it does not exist, it means that the syntax subtree rooted at the combinational event-driven node meets the check rules corresponding to the sub-item "whether there are direct modifications to the current state register in combinational logic".

[0053] In some optional implementations, when the target check is the next-state register check, the check rule corresponding to the sub-item "whether the next-state register is assigned a value in all possible transfer paths in combinational logic" is: all input combinations have corresponding statements that assign values ​​to the next-state variables, and the input combinations are combinations of preset states and input signals; the check rule corresponding to the sub-item "whether there is a direct modification to the next-state register in the sequential logic" is: there are no assignment statements that assign preset states to the next-state variables.

[0054] Specifically, in the next-state register check, when checking whether "the next-state register is assigned a value in all possible transfer paths in combinational logic," it is necessary to traverse the syntax subtree rooted at the event-driven node and determine whether all input combinations have a corresponding statement assigning a value to the next-state variable. If all input combinations have a corresponding statement assigning a value to the next-state variable, it means that the syntax subtree rooted at the event-driven node conforms to the check rule corresponding to the sub-item "whether the next-state register is assigned a value in all possible transfer paths in combinational logic." If at least one input combination does not have a corresponding statement assigning a value to the next-state variable, it means that the syntax subtree rooted at the event-driven node does not conform to the check rule corresponding to the sub-item "whether the next-state register is assigned a value in all possible transfer paths in combinational logic." In this embodiment, the input combination is (current_state, input), and an example of all input combinations having a corresponding statement assigning a value to the next-state variable is as follows:

[0055] CASE current_state IS

[0056] WHEN STATE_A=>

[0057] IF input='1'THENnext_state<= STATE_B;

[0058] ELSE

[0059] next_state <= STATE_A;

[0060] END IF;

[0061] WHEN STATE_B=>IF input='1'THEN……

[0062] END IF;

[0063] END CASE.

[0064] When checking for "whether there are direct modifications to the next-state register in the sequential logic", it is necessary to traverse the syntax subtree rooted at the timing event-driven node and determine whether there are assignment statements in this syntax subtree that assign a preset state to a next-state variable, such as current_state <= STATE_B, where STATE_B is a preset state defined in the state machine. If such an assignment exists, it means that the syntax subtree rooted at the timing event-driven node does not meet the check rules corresponding to the sub-item "whether there are direct modifications to the next-state register in the sequential logic"; if it does not meet the check rules, it means that the syntax subtree rooted at the timing event-driven node meets the check rules corresponding to the sub-item "whether there are direct modifications to the next-state register in the sequential logic".

[0065] In some optional implementations, when the target inspection item is a clock signal inspection, the inspection rule corresponding to the inspection sub-item "whether the timing logic correctly defines the clock edge" is: at least one of a clock edge trigger expression and a reset signal expression exists; the inspection rule corresponding to the inspection sub-item "whether a clock signal is used in combinational logic" is: no clock signal exists.

[0066] Specifically, in clock signal checking, when checking whether the timing logic correctly defines the clock edge, it is necessary to traverse the syntax subtree rooted at the timing event-driven node and determine whether the syntax subtree contains at least one of the following: a clock edge-triggered expression (such as rising_edge(clk) or falling_edge(clk)) and a reset signal expression (if reset = '1'). If the syntax subtree rooted at the timing event-driven node contains at least one of the clock edge-triggered expression and the reset signal expression, it indicates that the syntax subtree rooted at the timing event-driven node conforms to the checking rules corresponding to the sub-item "whether the timing logic correctly defines the clock edge." If the syntax subtree rooted at the timing event-driven node does not contain at least one of the clock edge-triggered expression and the reset signal expression, it indicates that the syntax subtree rooted at the timing event-driven node does not conform to the checking rules corresponding to the sub-item "whether the timing logic correctly defines the clock edge."

[0067] When checking whether a clock signal is used in combinational logic, it is necessary to traverse the syntax subtree rooted at the combinational event-driven node and determine whether a clock signal, such as clk, exists in that subtree. If a clock signal exists, it means that the syntax subtree rooted at the combinational event-driven node does not meet the checking rules for the sub-item "whether a clock signal is used in combinational logic"; if no clock signal exists, it means that the syntax subtree rooted at the combinational event-driven node meets the checking rules for the sub-item "whether a clock signal is used in combinational logic".

[0068] In some optional implementations, when the target inspection item is a state transition integrity check, the inspection rule corresponding to the inspection sub-item "whether all preset states are covered in the state transition process of combinational logic" is: there is a node corresponding to each preset state; the inspection rule corresponding to the inspection sub-item "whether default statements are included in the state transition process of combinational logic" is: there is a preset default statement.

[0069] Specifically, in the state transition integrity check, when checking whether "the state transition process of combinational logic covers all preset states," it is necessary to traverse the syntax subtree rooted at the branch node (i.e., the CASE node) and determine whether there exists a node corresponding to each preset state in the syntax subtree. For example, if the state machine defines two preset states, it is necessary to determine whether there exists a WHEN branch node in the syntax subtree corresponding to each preset state. If it exists, it means that the syntax subtree rooted at the branch node conforms to the check rule corresponding to the sub-item "whether the state transition process of combinational logic covers all preset states"; if it does not exist, it means that the syntax subtree rooted at the branch node does not conform to the check rule corresponding to the sub-item "whether the state transition process of combinational logic covers all preset states".

[0070] When checking whether "the state transition process of combinational logic contains default statements", it is necessary to traverse the syntax subtree rooted at the branch node and determine whether there are preset default statements in the syntax subtree, such as ELSE statements, WHENOTHERS statements, etc., which represent other undefined cases. If they exist, it means that the syntax subtree rooted at the branch node meets the checking rules corresponding to the sub-item "whether the state transition process of combinational logic contains default statements". If they do not exist, it means that the syntax subtree rooted at the branch node does not meet the checking rules corresponding to the sub-item "whether the state transition process of combinational logic contains default statements".

[0071] In some optional implementations, when the target inspection item is an output logic inspection and the state machine structure type is a single segment, the inspection rule is: the node corresponding to the output statement has a corresponding output statement in the subtree rooted at the clock edge trigger node or the reset trigger node, and in each preset state; when the target inspection item is an output logic inspection and the state machine structure type is a multi-segment, the inspection rule is: each preset state has a corresponding output statement.

[0072] Specifically, in the output logic check, when the state machine structure is a single-stage structure, it is necessary to traverse the syntax subtree rooted at the timing event-driven node and determine whether the node corresponding to the output statement is rooted at the clock edge-triggered (rising_edge(clk) or falling_edge(clk)) or reset-triggered (if reset= '1') node. It is also necessary to determine whether each preset state has a corresponding output statement, such as current_state<= STATE_A; output<='1'; current_state<= STATE_B; output<='0'. If either of the above two conditions is not met, it indicates that the syntax subtree rooted at the timing event-driven node does not conform to the check rules corresponding to the "output logic check"; if both conditions are met, it indicates that the syntax subtree rooted at the timing event-driven node conforms to the check rules corresponding to the "output logic check".

[0073] Similarly, when the state machine structure is multi-segmented, it is necessary to traverse the syntax subtree rooted at the combined event-driven node and determine whether each preset state in the syntax subtree has a corresponding output statement, such as WHEN STATE_A=>output<='1'; WHEN STATE_B=>output<='0', etc. If the syntax subtree has an output statement corresponding to each preset state, it means that the syntax subtree rooted at the combined event-driven node conforms to the check rules corresponding to the "output logic check"; if at least one preset state in the syntax subtree does not have a corresponding output statement, it means that the syntax subtree rooted at the combined event-driven node does not conform to the check rules corresponding to the "output logic check".

[0074] S104, determine the normalization of the state machine based on the judgment result.

[0075] Specifically, if the judgment results for all target inspection items are that the target subtree conforms to the inspection rules, it indicates that the state machine has no normative issues. If at least one of the judgment results for all target inspection items is that the target subtree does not conform to the inspection rules, it indicates that the state machine has normative issues.

[0076] The state machine inspection method provided in this disclosure obtains the syntax tree and target inspection items corresponding to the state machine. The target inspection items include inspection objects and inspection rules. The method searches for the target subtree corresponding to the inspection object from the syntax tree. The method determines whether the target subtree conforms to the inspection rules. The method determines the standardization of the state machine based on the determination result. This solution achieves automated inspection of the standardization of the state machine by locating and traversing the target subtree. It also reduces the cost of manual inspection, ensures inspection coverage, reduces the probability of errors in the synthesis and simulation stages, and improves the maintenance efficiency of the state machine.

[0077] In some optional implementations, after S104, the method further includes: when it is determined that there is a normative problem in the state machine, identifying the code segment in the code segment corresponding to the abnormal subtree that is associated with the inspection rule as an abnormal code segment; based on the normative problem, searching for the optimization suggestion corresponding to the normative problem from the pre-built mapping relationship between problems and optimization suggestions; and binding the optimization suggestion, the normative problem, and the abnormal code segment.

[0078] In this system, normative issues correspond to target inspection items or inspection sub-items within target inspection items. Anomaly subtrees are target subtrees containing normative issues. Code segments associated with inspection rules refer to the lines or segments of code corresponding to the statements described in the inspection rules. The mapping between issues and optimization suggestions is a pre-built relationship that is continuously updated.

[0079] Specifically, when a normative problem is identified in the state machine, firstly, the target subtree (i.e., the abnormal subtree) with the normative problem is located based on the normative problem, and the corresponding code segment is found in the state machine. Secondly, the code segments in the code segment corresponding to the abnormal subtree that are associated with the inspection rules are identified as abnormal code segments. Thirdly, the optimization suggestions corresponding to the current normative problem are found from the mapping relationship between problems and optimization suggestions. Finally, the optimization suggestions, normative problems, and abnormal code segments are bound together. It should be noted that an abnormal code segment may have multiple normative problems. In this case, multiple normative problems and the optimization suggestions corresponding to each normative problem are bound together with the abnormal code segment. This embodiment binds normative problems and optimization suggestions to abnormal code segments so that when the user views an abnormal code segment, they can also view the normative problems existing in the abnormal code segment and the optimization suggestions given based on the normative problems, thus facilitating reference when modifying the abnormal code segment. It should also be noted that after the binding operation, the standardization issues and their corresponding optimization suggestions can be displayed on the interactive interface simultaneously with the exception code segment, or the standardization issues and their corresponding optimization suggestions can be hidden in the tag information corresponding to the exception code segment. In response to the user's triggering of the tag information, the standardization issues and their corresponding optimization suggestions will be displayed.

[0080] For example, optimization suggestions generally include code refactoring suggestions, state coding suggestions, redundant logic merging suggestions, and asynchronous reset handling suggestions. Code refactoring suggestions may include: splitting a single-stage state machine into three stages, separating state transitions, register updates, and output logic. For example, extracting the output logic from a single-stage code into a separate process. State coding suggestions may include: recommending one-hot encoding to reduce logic levels and improve timing performance; recommending Gray code to reduce power consumption during state transitions, etc. Redundant logic merging suggestions can detect duplicate state transition conditions and merge similar logic to reduce resource consumption. Asynchronous reset handling suggestions can ensure that reset signals are correctly processed in the timing process to avoid reset conflicts. This includes confirming that the reset operation must be synchronized with the clock signal, and only checking and executing the reset operation when a valid clock edge arrives, etc.

[0081] In some optional implementations, the method further includes: generating an anomaly detection report based on the abnormal code segment, normative issues, and optimization suggestions, and displaying the anomaly detection report on the interactive interface.

[0082] Specifically, after the state machine check is completed, an anomaly detection report can be generated based on the abnormal code segment, the normative issues found in the abnormal code segment, and the corresponding optimization suggestions. This anomaly detection report is then displayed on the interactive interface for easy viewing by state machine developers, shortening code review time and improving review efficiency.

[0083] In some alternative implementations, the method further includes: inputting at least one of the normative issues and optimization suggestions and the abnormal code segment into a pre-built optimization tool to obtain an optimized code segment corresponding to the abnormal code segment; and binding the optimized code segment to the abnormal code segment.

[0084] Specifically, after obtaining the normative issues and optimization suggestions corresponding to the abnormal code segment, the normative issues and abnormal code segment can be input into a pre-built optimization tool, or the optimization suggestions and abnormal code segment can be input into a pre-built optimization tool, or all three can be input together to obtain an optimized code segment. After obtaining the optimized code segment, it is bound to the abnormal code segment. When a user views the abnormal code segment, they can modify it themselves, or use the optimized code segment as a reference to modify the abnormal code segment. Alternatively, after confirming that the optimized code segment is correct, it can directly replace the abnormal code segment. This embodiment, by generating optimized code segments, not only improves the automation of modification operations, reduces the manual cost in the state machine maintenance process, and improves the maintenance efficiency of the state machine, but also unifies the coding style.

[0085] In some optional implementations, the syntax tree includes at least one event-driven node and a list of sensitive signals corresponding to each event-driven node. Before S102, the method further includes: for each event-driven node, determining the logical type of the event-driven node based on the signal type of the signals in the list of sensitive signals; and determining the structure type of the state machine based on the number of event-driven nodes in the syntax tree, the logical type of each event-driven node, and the preset logical statements contained in the syntax subtree rooted at the event-driven node.

[0086] In this context, an event-driven node refers to the node in the syntax tree corresponding to the code in a state machine used to execute specific operations through events (or triggers). Event-driven nodes correspond to hardware description languages. For example, when the state machine is implemented using VHDL, the event-driven node is the process node. When the state machine is implemented using Verilog, the event-driven node is the always node. The sensitive signal list is a node attribute of the event-driven node. The signal types in the sensitive signal list include clock signals, reset signals, and input signals. The logic types of event-driven nodes include sequential logic and combinational logic. The structure types of state machines include one-stage, two-stage, and three-stage. Predefined logic statements include at least one of register update statements, state transition statements, and output statements. A register update statement is a statement that updates the current state variable. A state transition statement is a statement that assigns a value to the next state variable based on the input combination. An output statement is an output statement.

[0087] Specifically, the event-driven nodes in the syntax tree are traversed, and the list of sensitive signals corresponding to each event-driven node is obtained from its node attributes. Then, the logic type of the event-driven node is determined based on the signal types of the signals contained in the sensitive signal list. For example, if the sensitive signal list contains clock signals and / or reset signals, the logic type of the event-driven node is determined to be sequential logic. If the sensitive signal list contains input signals, the logic type of the event-driven node is determined to be combinational logic. After determining the logic type of the event-driven nodes, the structure type of the state machine is determined based on the number of event-driven nodes in the syntax tree, the logic type of each event-driven node, and the preset logic statements contained in the syntax subtree rooted at the event-driven node.

[0088] The structure type of a state machine is determined as follows:

[0089] When a syntax tree contains a timing event-driven node, and the syntax subtree rooted at the timing event-driven node includes register update statements, state transition statements, and output statements, the state machine's structure type is determined to be a single-stage state machine. A timing event-driven node is an event-driven node whose logic type is sequential logic.

[0090] For example, in Figure 2 The syntax tree shown contains timing event-driven nodes (i.e., process nodes whose sensitivity list includes the clock signal clk). The syntax tree rooted at a timing event-driven node also contains statements updating the current state register (e.g., current_state <= STATE_B, current_state <= STATE_A), state transition statements (statements in the node attributes corresponding to CASE nodes, WHEN nodes, and IF-ELSE nodes), and output statements (output statements corresponding to output nodes). Therefore, Figure 2 The syntax tree shown corresponds to a state machine with a single-stage structure. Figure 3 for Figure 2 The state machine corresponding to the syntax tree shown.

[0091] When there is a sequential event-driven node and a combinational event-driven node in the syntax tree, and the syntax subtree rooted at the sequential event-driven node includes register update statements, and the syntax subtree rooted at the combinational event-driven node includes state transition statements, the structure type of the state machine is determined to be two-stage, and the combinational event-driven node is an event-driven node with combinational logic.

[0092] For example, in Figure 4 The syntax tree shown contains one timing event-driven node (i.e., a process node whose sensitivity list includes the clock signal clk) and one composite event-driven node (i.e., a process node whose sensitivity list includes the input signals current_state and input). The syntax subtree rooted at the timing event-driven node includes the statement `current_state <= next_state` for updating the current state register (the node attribute corresponding to the current state register update node). Simultaneously, the syntax subtree rooted at the composite event-driven node includes state transition statements (statements in the node attributes corresponding to the CASE node, WHEN node, and IF-ELSE node). Therefore, Figure 4 The syntax tree shown corresponds to a state machine with a two-stage structure. Figure 5 for Figure 4 The state machine corresponding to the syntax tree shown.

[0093] When a syntax tree contains one sequential event-driven node and two combined event-driven nodes, including a first combined event-driven node and a second combined event-driven node, and the syntax subtree rooted at the sequential event-driven node includes register update statements, the syntax subtree rooted at the first combined event-driven node includes state transition statements, and the syntax subtree rooted at the second combined event-driven node includes output statements, the state machine's structure type is determined to be three-stage.

[0094] For example, in Figure 6 The syntax tree shown contains sequential event-driven nodes and two combined event-driven nodes. The subtree rooted at the sequential event-driven node includes the statement `current_state <= next_state`, which updates the current state register. The subtree rooted at one of the combined event-driven nodes (the first combined event-driven node) includes state transition statements (statements in the CASE node's corresponding node attributes, the WHEN node's corresponding node attributes, and the IF-ELSE node's corresponding node attributes). The subtree rooted at the other combined event-driven node (the second combined event-driven node) includes output statements (the `output` statement in the output node's corresponding node attributes). Therefore, Figure 6 The state machine structure corresponding to the syntax tree shown is a three-stage structure. Figure 7 for Figure 6 The state machine corresponding to the syntax tree shown.

[0095] The state machine inspection method provided in this embodiment achieves automated identification of state machine structure by traversing the nodes in the syntax tree, saving labor costs, reducing identification time, and improving identification accuracy.

[0096] In some optional implementations, the method further includes: obtaining at least two preset states of the state machine from the signal declaration node; obtaining the transition conditions and transition relationships between the preset states from the syntax subtree with the branch node as the root node; constructing a state transition diagram based on the preset states, transition conditions and transition relationships; and displaying the state transition diagram on the interactive interface.

[0097] The syntax tree also includes signal declaration nodes and branch nodes. Signal declaration nodes are the nodes corresponding to signal declaration statements. Branch nodes are the nodes corresponding to CASE statements. Transition conditions are the conditions required to transition from preset state A to preset state B, such as input signals. Transition relationships are the transition paths between preset states. For example, preset state A can transition to preset state B through a certain transition condition, and preset state A can also transition to preset state C through another transition condition, and so on.

[0098] Specifically, after obtaining the syntax tree corresponding to the state machine, at least two preset states defined in the state machine can be retrieved from the node attributes corresponding to the signal declaration node. Simultaneously, by traversing the syntax subtree rooted at the branch node, the transition conditions and relationships between the preset states can be obtained from that subtree. For example, in... Figure 2 In the syntax tree shown, based on the syntax subtree rooted at the CASE node, the transition relationships are STATE_A to STATE_A and STATE_A to STATE_B. The transition condition from STATE_A to STATE_A is that the input signal is a value other than 1. The transition condition from STATE_A to STATE_B is that the input signal is 1. Then, a state transition diagram is constructed based on the preset state, transition conditions, and transition relationships, and the constructed state transition diagram is displayed on the interactive interface.

[0099] This embodiment provides a state machine inspection device, such as... Figure 8 As shown, it includes:

[0100] The first acquisition module 801 is used to acquire the syntax tree and target check items corresponding to the state machine. The target check items include the check objects and check rules.

[0101] The first lookup module 802 is used to find the target subtree corresponding to the object being checked from the syntax tree.

[0102] The judgment module 803 is used to determine whether the target subtree meets the inspection rules.

[0103] The first determining module 804 is used to determine the standardization of the state machine based on the judgment result.

[0104] In some alternative embodiments, the apparatus further includes:

[0105] The second determination module is used to determine the code segment associated with the inspection rule in the code segment corresponding to the abnormal subtree as the abnormal code segment when the state machine is determined to have a normative problem. The abnormal subtree is the target subtree with the normative problem. The second search module is used to search for the optimization suggestion corresponding to the normative problem from the pre-built mapping relationship between the problem and the optimization suggestion based on the normative problem. The first binding module is used to bind the optimization suggestion, the normative problem and the abnormal code segment.

[0106] In some alternative embodiments, the apparatus further includes:

[0107] The generation module is used to generate an anomaly detection report based on abnormal code segments, standardization issues, and optimization suggestions, and then display the anomaly detection report on the interactive interface.

[0108] In some alternative embodiments, the apparatus further includes:

[0109] The input module is used to input at least one of the normative issues and optimization suggestions, as well as the abnormal code segment, into the pre-built optimization tool to obtain the optimized code segment corresponding to the abnormal code segment; the second binding module is used to bind the optimized code segment and the abnormal code segment.

[0110] In some optional implementations, the syntax tree includes at least one event-driven node and a list of sensitive signals corresponding to each event-driven node, and the apparatus further includes:

[0111] The third determining module is used to determine the logical type of each event-driven node based on the signal type of the signal in the sensitive signal list after obtaining the syntax tree and target check items corresponding to the state machine. The fourth determining module is used to determine the structure type of the state machine based on the number of event-driven nodes in the syntax tree, the logical type of each event-driven node, and the preset logical statements contained in the syntax subtree with the event-driven node as the root node.

[0112] In some optional implementations, the logic types include sequential logic and combinational logic, the preset logic statements include at least one of register update statements, state transition statements, and output statements, and the fourth determining module includes:

[0113] The first determining submodule is used to determine the state machine's structure type as a single-stage node and the event-driven node as an event-driven node with sequential logic as its logic type when the syntax tree contains a timing event-driven node and the syntax subtree rooted at the timing event-driven node includes register update statements, state transition statements, and output statements. The second determining submodule is used to determine the state machine's structure type as a single-stage node and the event-driven node as a sequential logic event-driven node when the syntax tree contains a timing event-driven node and a combination event-driven node, and the syntax subtree rooted at the timing event-driven node includes register update statements, and the syntax subtree rooted at the combination event-driven node includes state transition statements. The structure type is two-segment, and the combined event-driven node is an event-driven node with combinational logic. The third determining submodule is used to determine that the structure type of the state machine is three-segment when there is one sequential event-driven node and two combined event-driven nodes in the syntax tree, and the syntax subtree rooted at the sequential event-driven node includes register update statements, the syntax subtree rooted at the first combined event-driven node includes state transition statements, and the syntax subtree rooted at the second combined event-driven node includes output statements.

[0114] In some alternative implementations, the syntax tree further includes signal declaration nodes and branch nodes, and the apparatus further includes:

[0115] The second acquisition module is used to acquire at least two preset states of the state machine from the signal declaration node; the third acquisition module is used to acquire the transition conditions and transition relationships between the preset states from the syntax subtree with the branch node as the root node; the construction module is used to construct a state transition diagram based on the preset states, transition conditions and transition relationships, and display the state transition diagram on the interactive interface.

[0116] In some optional implementations, the target inspection items include at least one of the following: current state register inspection, next state register inspection, clock signal inspection, state transition integrity inspection, and output logic inspection. When the target inspection item is a current state register inspection, the inspection object is the syntax subtree rooted at the combined event-driven node, and the inspection rule is that there is no assignment statement that assigns the next state variable to the current state variable, and / or, the inspection rule is that there is no assignment statement that assigns the preset state to the current state variable. When the target inspection item is a next state register inspection, the inspection object is the syntax subtree rooted at the event-driven node, and the inspection rule is that all input combinations have corresponding statements that assign values ​​to the next state variables, and the input combinations are combinations of the preset state and the input signal; and / or, the inspection object is the syntax subtree rooted at the timing event-driven node, and the inspection rule is that there is no assignment statement that assigns the preset state to the next state variable. When the target inspection item is a clock signal inspection, the inspection object is the syntax subtree rooted at the timing event-driven node. The checking rules are as follows: The checking object is the syntax subtree rooted at a clock edge triggering expression and a reset signal expression; and / or, the checking object is the syntax subtree rooted at a combined event-driven node, and the checking rule is the absence of a clock signal; when the target check is a state transition integrity check, the checking object is the syntax subtree rooted at a branch node, and the checking rule is the existence of a node corresponding to each preset state; and / or, the checking rule is the existence of a preset default statement; when the target check is an output logic check and the state machine structure type is a single-segment state, the checking object is the syntax subtree rooted at a timing event-driven node, and the checking rule is that the node corresponding to the output statement exists in the subtree rooted at a clock edge triggering node or a reset triggering node, and that a corresponding output statement exists for each preset state; when the target check is an output logic check and the state machine structure type is a multi-segment state, the checking object is the syntax subtree rooted at a combined event-driven node, and the checking rule is that a corresponding output statement exists for each preset state.

[0117] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0118] In this embodiment, the state machine checking device is presented in the form of a functional unit. Here, a unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0119] This disclosure also provides a computer device having the above-described features. Figure 8 The state machine inspection device shown.

[0120] Please see Figure 9 , Figure 9 This is a schematic diagram of the structure of a computer device provided in an optional embodiment of this disclosure, such as... Figure 9 As shown, the computer device includes one or more processors 901, memory 902, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 9 Take the 901 processor as an example.

[0121] Processor 901 may be a central processing unit, a network processor, or a combination thereof. Processor 901 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0122] The memory 902 stores instructions executable by at least one processor 901 to cause the at least one processor 901 to perform the method shown in the above embodiments.

[0123] The memory 902 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device. Furthermore, the memory 902 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 902 may optionally include memory remotely located relative to the processor 901, and these remote memories can be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0124] The memory 902 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 902 may also include a combination of the above types of memory.

[0125] The computer device also includes a communication interface 903 for communicating with other devices or communication networks.

[0126] This disclosure also provides a computer-readable storage medium in which the methods described in this disclosure can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium after being downloaded over a network. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium may be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium may also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code that, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0127] In addition to the computer devices and computer-readable storage media described above, embodiments of this application may also be computer program products, which include computer program instructions that, when executed by a processor, cause the processor to perform the steps of the sound source localization method provided in any embodiment of this application.

[0128] Computer program products can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0129] 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 state machine checking method, characterized by, The method comprises: acquiring a syntax tree corresponding to the state machine and target checking items, the target checking items comprising a checking object and a checking rule; finding a target sub-tree corresponding to the checking object from the syntax tree; judging whether the target sub-tree conforms to the checking rule; determining the normativity of the state machine according to the judgment result; the syntax tree comprising at least one event-driven node and a list of sensitive signals corresponding to each of the at least one event-driven node, after acquiring the syntax tree corresponding to the state machine and the target checking items, the method further comprises: for each of the event-driven nodes, determining the logic type of the event-driven node according to the signal type of the signals in the list of sensitive signals; determining the structure type of the state machine according to the number of the event-driven nodes in the syntax tree, the logic type of each of the event-driven nodes, and the preset logic statements contained in the syntax sub-tree with the event-driven node as the root node; the logic type comprising sequential logic and combinational logic, the preset logic statements comprising at least one of a register update statement, a state transition statement, and an output statement, the determination of the structure type of the state machine according to the number of the event-driven nodes in the syntax tree, the logic type of each of the event-driven nodes, and the preset logic statements contained in the syntax sub-tree with the event-driven node as the root node comprising: when there is one sequential event-driven node in the syntax tree, and the syntax sub-tree with the sequential event-driven node as the root node simultaneously comprises the register update statement, the state transition statement, and the output statement, determining that the structure type of the state machine is one-segment, the sequential event-driven node being an event-driven node with the logic type of sequential logic; when there is one sequential event-driven node and one combinational event-driven node in the syntax tree, and the syntax sub-tree with the sequential event-driven node as the root node comprises the register update statement, and the syntax sub-tree with the combinational event-driven node as the root node comprises the state transition statement, determining that the structure type of the state machine is two-segment, the combinational event-driven node being an event-driven node with the logic type of combinational logic; when there is one sequential event-driven node and two combinational event-driven nodes in the syntax tree, and the syntax sub-tree with the sequential event-driven node as the root node comprises the register update statement, the syntax sub-tree with the first combinational event-driven node as the root node comprises the state transition statement, and the syntax sub-tree with the second combinational event-driven node as the root node comprises the output statement, determining that the structure type of the state machine is three-segment, the two combinational event-driven nodes comprising the first combinational event-driven node and the second combinational event-driven node.

2. The method of claim 1, wherein, The method further comprises: when it is determined that the state machine has normativity problems, determining a code segment corresponding to an abnormal sub-tree as an abnormal code segment, the abnormal sub-tree being a target sub-tree having the normativity problems, the abnormal code segment being associated with the checking rule; According to the normative problem, an optimization suggestion corresponding to the normative problem is searched from a mapping relationship between pre-constructed problems and optimization suggestions; The optimization suggestion, the normative problem and the abnormal code segment are bound.

3. The method of claim 2, wherein, The method further comprises: An abnormal detection report is generated according to the abnormal code segment, the normative problem and the optimization suggestion, and the abnormal detection report is displayed on an interactive interface.

4. The method of claim 2, wherein, The method further comprises: The normative problem and at least one of the optimization suggestion and the abnormal code segment are input into a pre-constructed optimization tool to obtain an optimization code segment corresponding to the abnormal code segment; The optimization code segment and the abnormal code segment are bound.

5. The method of claim 1, wherein, The syntax tree further comprises a signal declaration node and a branch node, and the method further comprises: At least two preset states of the state machine are obtained from the signal declaration node; A transition condition and a transition relationship between the preset states are obtained from a syntax sub-tree with the branch node as a root node; A state transition graph is constructed according to the preset states, the transition condition and the transition relationship, and the state transition graph is displayed on an interactive interface.

6. The method of claim 5, wherein, The target checking matter at least comprises one of a present state register check, a next state register check, a clock signal check, a state transition integrity check and an output logic check; When the target checking matter is the present state register check, the checking object is a syntax sub-tree with the combined event driven node as a root node, the checking rule is that there is no assignment statement of a next state variable to a present state variable, and / or the checking rule is that there is no assignment statement of the preset state to the present state variable; When the target checking matter is the next state register check, the checking object is a syntax sub-tree with the event driven node as a root node, the checking rule is that all input combinations have corresponding statements of assignment of the next state variable, and the input combination is a combination of the preset state and an input signal; and / or the checking object is a syntax sub-tree with the timing event driven node as a root node, and the checking rule is that there is no assignment statement of the preset state to the next state variable; When the target checking matter is the clock signal check, the checking object is a syntax sub-tree with the timing event driven node as a root node, and the checking rule is that there is at least one of a clock edge trigger expression and a reset signal expression; and / or the checking object is a syntax sub-tree with the combined event driven node as a root node, and the checking rule is that there is no clock signal; When the target checking matter is the state transition integrity check, the checking object is a syntax sub-tree with the branch node as a root node, and the checking rule is that there is a node corresponding to each preset state, and / or the checking rule is that there is a preset default statement; when the target checking matter is the output logic checking and the structure type of the state machine is one-segment type, the checking object is a syntax sub-tree with the timing event driven node as a root node, the checking rule is that the node corresponding to the output statement is in a sub-tree with a clock edge triggered node or a reset triggered node as a root node, and each of the preset states has the output statement corresponding thereto; when the target checking matter is the output logic checking and the structure type of the state machine is multi-segment type, the checking object is a syntax sub-tree with the combination event driven node as a root node, and the checking rule is that each of the preset states has the output statement corresponding thereto.

7. A state machine checking apparatus characterized by comprising: The device comprises: a first obtaining module configured to obtain a syntax tree corresponding to a state machine and a target checking matter, the target checking matter comprising a checking object and a checking rule; a first searching module configured to search for a target sub-tree corresponding to the checking object from the syntax tree; a judging module configured to judge whether the target sub-tree conforms to the checking rule; a first determining module configured to determine the normality of the state machine according to a judging result; the syntax tree comprises at least one event driven node and a list of sensitive signals corresponding to each of the at least one event driven node; The device further comprises: a third determining module configured to, after obtaining the syntax tree corresponding to the state machine and the target checking matter, determine, for each event driven node, a logic type of the event driven node according to a signal type of a signal in the list of sensitive signals; a fourth determining module configured to determine a structure type of the state machine according to a number of the event driven nodes in the syntax tree, the logic types of the event driven nodes, and preset logic statements contained in a syntax sub-tree with the event driven nodes as root nodes; the logic type comprises timing logic and combination logic, and the preset logic statement comprises at least one of a register update statement, a state transition statement, and an output statement; the fourth determining module further comprises a first determining submodule, a second determining submodule, and a third determining submodule; the first determining submodule is configured to, when there is one timing event driven node in the syntax tree and a syntax sub-tree with the timing event driven node as a root node simultaneously comprises the register update statement, the state transition statement, and the output statement, determine that the structure type of the state machine is one-segment type, the timing event driven node being an event driven node with timing logic as a logic type; the second determining submodule is configured to, when there is one timing event driven node and one combination event driven node in the syntax tree and a syntax sub-tree with the timing event driven node as a root node comprises the register update statement and a syntax sub-tree with the combination event driven node as a root node comprises the state transition statement, determine that the structure type of the state machine is two-segment type, the combination event driven node being an event driven node with combination logic as a logic type; and the third determining submodule is configured to, when there is one timing event driven node and one combination event driven node in the syntax tree and a syntax sub-tree with the timing event driven node as a root node comprises the register update statement and a syntax sub-tree with the combination event driven node as a root node comprises the state transition statement, determine that the structure type of the state machine is multi-segment type, the combination event driven node being an event driven node with combination logic as a logic type. The third determining sub-module is configured to determine that the structure type of the state machine is three-segmented when there is one time sequence event driven node and two combination event driven nodes in the syntax tree, the register updating statement is included in a syntax sub-tree with the time sequence event driven node as a root node, the state transition statement is included in a syntax sub-tree with a first combination event driven node as a root node, and the output statement is included in a syntax sub-tree with a second combination event driven node as a root node, and the first combination event driven node and the second combination event driven node are included in the two combination event driven nodes.

8. A computer device, comprising: The application further provides a state machine checking device, comprising: a memory and a processor, which are in communication connection with each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the state machine checking method in any one of claims 1 to 6.

Images