Trigger network formalized security verification and signing method and system for vehicle-gauge-level chip

Abstract

The invention relates to a vehicle gauge level chip-oriented trigger network formalized security approval method and system, and the method comprises the steps: verifying the attribute of a register in a trigger network module through employing a formalized tool CSR App, verifying the function point of the trigger network module through an FPV App, merging the coverage rates collected in the verification process of the CSR App and the FPV App through a COV App, and carrying out the verification of the coverage rates of the CSR App and the FPV App. And carrying out coverage rate analysis and iteration until the coverage rate reaches the standard, and forming a strategy driven by the coverage rate so as to achieve the safety sign-off of the trigger network module. The scheme can run through the design and development cycle of the whole trigger network, does not depend on design codes which are completely designed and developed, is short in verification environment building time, can exhaust all verification spaces, can timely find deep defects and can safely sign off the defects, and realizes complete verification of the trigger network.

Description

Technical Field

[0001] This invention belongs to the field of automotive-grade chip verification technology, and relates to a formal security verification method and system for trigger networks for automotive-grade chips. Background Technology

[0002] Automotive products not only have extremely high safety requirements, but their automotive-grade chips also need to meet stringent safety standards, such as ISO 26262, to ensure their reliability under various operating conditions. With the development of automotive intelligence, the functions of automotive-grade chips have become increasingly complex, including autonomous driving, vehicle networking, and advanced driver assistance systems. These functions place even higher demands on the reliability and functional safety of automotive-grade chips. As one of the core functional modules of automotive-grade chips, the trigger network typically has hundreds or even thousands of trigger sources and trigger destinations. It supports configuring any trigger source signal to reach the trigger destination, resulting in an explosion of states in the simulation space, which traditional dynamic simulation methods struggle to cover.

[0003] Trigger networks typically support functions such as filtering the trigger source signal, recording the trigger source state, widening the trigger destination signal, pulse modulation of the trigger destination signal, and redundant backup of critical logic. This places higher demands on the completeness of verification. Moreover, due to the special nature of trigger networks, the trigger source and trigger destination signals are often modified during project implementation. If traditional dynamic simulation methods are used, the verification environment must be modified and debugged again, resulting in significant waste of human resources and time. How to efficiently and completely verify the trigger network in automotive-grade chips has become one of the technical problems to be solved. Summary of the Invention

[0004] To address the problems existing in the above-mentioned traditional methods, this invention proposes a formal security verification method for trigger networks of automotive-grade chips and a formal verification system for trigger networks of automotive-grade chips, which can efficiently and completely verify the trigger networks in automotive-grade chips.

[0005] To achieve the above objectives, the embodiments of the present invention adopt the following technical solutions: On the one hand, a formal security verification method for trigger networks for automotive-grade chips is provided, including the following steps: Use a Python script to extract the register attribute information of the trigger network module to be verified in an automotive-grade chip and save it as a CSR file in CSR format. The CSR App, a formal tool, is used to verify the properties of registers in the trigger network module and the APB bus protocol. The formal tool is configured to generate corresponding assertions based on the register property information. The assertions include register reset value checks, read-write consistency checks, read-only checks, write-only checks, and security lock checks. The FPV App, a formalization tool, is used to verify the functional points of the trigger network module. Specifically, the FPV App extracts the functional points to be tested from the hardware detailed design specification document of the trigger network module and writes the corresponding attributes for assertion verification. After analyzing and expanding the input RTL file of the trigger network module and the written attributes, the FPV App obtains the corresponding functional point verification results. After merging the coverage data collected during the verification process of CSR App and FPV App using the COV App formalization tool, coverage analysis is performed and iterated until the coverage meets the target to complete the security signature of the triggering network module. The coverage includes attribute coverage, stimulus coverage, security assertion coverage, and functional coverage.

[0006] In one embodiment, when the CSR App of the formalization tool verifies the properties of the registers in the triggering network module, if the property assertion fails, it is checked whether the CSR file description is incorrect. If the CSR file is correct, it indicates that the network module design has a defect.

[0007] In one embodiment, the process of verifying the APB bus protocol includes: By constraining the APB input signal to meet protocol requirements and checking whether the APB output signal meets expectations; By observing whether the APB bus behavior actually occurs.

[0008] In one embodiment, if the function point verification result is that the verification fails, the attribute waveform is viewed using the FPV App tool; If the analysis of the attribute waveform confirms that the problem is a function point design issue, then a prompt will be made to modify the function point design. If the analysis of the attribute waveform confirms that the problem is due to environmental issues, it will prompt you to modify the attributes and constraints; environmental issues include over-constraints, under-constraints, and attribute mismatches. After resolving the issues that failed verification, the simulation is restarted, and the verification process is iterated until there are no more attributes that failed verification.

[0009] In one embodiment, the formalization tool is JasperGold or VC-Formal.

[0010] On the other hand, a formal verification system for trigger networks for automotive-grade chips is also provided, applying the aforementioned formal safety verification method for trigger networks in automotive-grade chips. This formal verification system for trigger networks in automotive-grade chips includes an adapter, an input proxy, an APB component, an output proxy, an alarm proxy, a register probe, a scoreboard, and an assertion library. The input proxy connects to the trgin interface of the trigger network module to be verified, and is used to combine all trigger signals from the input trigger network module into a single signal. The output proxy connects to the trgout interface of the trigger network module, and is used to combine all trigger signals output by the trigger network module into a single signal. The alarm proxy connects to the alarm interface of the trigger network module, and is used to perform functional safety signal assertion checks. The APB component connects to the APB interface of the trigger network module, and is used to process APB bus protocol signals; processing APB bus protocol signals includes constraints on input signals and checks on output signals. The register probe connects to the registers inside the trigger network module, and is used to obtain the values ​​of the registers inside the trigger network module. The scoreboard connects to the input proxy, the output proxy, and the register probe respectively, and is used to perform end-to-end comparison of data between the trgin and trgout interfaces. The assertion library is used to store assertions generated by formalization tools based on the register attribute information of the triggering network module.

[0011] In one embodiment, for the verification of the input / output selection function of the trigger network module, an output index and an input index are set. The output index is used to indicate the selected trigger output signal, and the input index is used to indicate the selected trigger input signal. The formalization tool automatically exhausts all possible values ​​and combinations of the output index and the input index.

[0012] In one embodiment, during the verification of the input / output selection function of the trigger network module, the selection register used by the inspection logic is set as a black box, or the output logic of the selection register is shortened using the stopat instruction.

[0013] In one embodiment, the input filtering process in the trigger input processing of the network module is checked as follows: Check if the pulse width of the output signal is greater than the set filter register value; wherein, a counter is set to count the pulse width of the output signal and use the output index to check the constraint.

[0014] In one embodiment, during the verification of the input state recording in the trgin input processing of the trigger network module and the broadening and pulse adjustment functions in the trgout output processing, the pulse width of the signal is counted by a set counter.

[0015] One of the above technical solutions has the following advantages and beneficial effects: The aforementioned formal security verification method and system for trigger networks targeting automotive-grade chips utilizes a CSR App (Content Response App) to verify the attributes of registers in the trigger network module, an FPV App to verify the functionalities of the trigger network module, and a COV App (Content Response App) to merge the coverage data collected during the verification processes of the CSR App and FPV App. Coverage analysis is then performed and iterated until the coverage meets the target, forming a coverage-driven strategy to achieve secure verification of the trigger network module. This solution can be implemented throughout the entire design and development cycle of the trigger network, without relying on fully designed and developed code. The verification environment setup time is short, and it can exhaustively explore all verification spaces, promptly identifying deep-seated defects and enabling secure verification, thus achieving complete verification of the trigger network. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention or the conventional technology, the drawings used in the description of the embodiments or the conventional technology will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating a formal security signature method for trigger networks for automotive-grade chips in one embodiment. Figure 2 This is a schematic diagram of the simulation verification process of a formal security signature method for trigger networks for automotive-grade chips in one embodiment; Figure 3 This is a flowchart illustrating the process of verifying functional points using an FPV App in one embodiment. Figure 4 This is a schematic diagram of the component architecture of a trigger network formal verification system for automotive-grade chips in one embodiment. Figure 5 This is a schematic diagram of an end-to-end comparison connection for a trigger network formal verification system for automotive-grade chips in one embodiment. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention.

[0019] It should be noted that, in this document, the reference to "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The presentation of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art will understand that the embodiments described herein can be combined with other embodiments. The term "and / or" as used herein refers to any combination of one or more of the associated listed items, and all possible combinations, including such combinations.

[0020] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0021] In one embodiment, such as Figure 1 As shown, a formal security signature method for trigger networks for automotive-grade chips is provided, which may include the following steps S10 to S16: S10, use a Python script to extract the register attribute information of the trigger network module to be verified in the automotive-grade chip and save it as a CSR file in CSR format; S12, the CSR App of the formal tool is used to verify the attributes of the registers in the trigger network module, and the APB bus protocol is verified at the same time; among them, the formal tool is configured to generate corresponding assertions based on the register attribute information, and the assertions include register reset value checks, read-write consistency checks, read-only checks, write-only checks and security lock checks. S14, use the formalization tool FPV App to verify the functional points of the trigger network module; wherein, the FPV App is used to extract the functional points to be tested from the hardware detailed design specification document of the trigger network module and write the corresponding attributes for assertion verification. After analyzing and expanding the input RTL file of the trigger network module and the written attributes, the FPV App obtains the corresponding functional point verification results. S16: After merging the coverage data collected during the verification process of CSR App and FPV App using the COV App formalization tool, coverage analysis is performed and iterated until the coverage meets the standard to complete the security signature of the triggering network module; the coverage includes attribute coverage, incentive coverage, security assertion coverage and functional coverage.

[0022] It is understood that this embodiment provides a formalized security verification process for complex trigger networks in automotive-grade chips, using formal tools to verify the trigger network module to be verified. The formal tool can be any existing vendor tool (e.g., but not limited to JasperGold and VC-Formal), and the verification language can be SVA (SystemVerilog Assertion) or PSL (Property Specification Language). For ease of explanation, this embodiment uses the JasperGold tool (other tools are similarly described) as an example. Figure 2 As shown, the CSR (Control and Status Register) App verifies the register attributes and bus protocol of the trigger network module to be verified; the FPV (Formal Property Verification) App verifies the functional points of the trigger network module to be verified; and the COV (coverage) App collects and analyzes the verification coverage, using a coverage-driven strategy to achieve secure signature verification. Among these, the CSR App, FPV App, and COV App are core applications in the formal tools, used for specific verification during the secure signature verification phase of the chip design flow.

[0023] Specifically, the CSR App can be used to verify the attributes of the registers in the trigger network module to be verified, while simultaneously verifying the bus protocol. First, a Python script can be used to extract the register attribute information of the trigger network module and save it as a CSR file in CSR format. A formalization tool is then configured to generate corresponding assertions based on the register attribute information. Assertions can include register reset value checks, read-write consistency checks, read-only checks, write-only checks, and security lock checks, among others.

[0024] Optionally, when using the CSR App of the formalization tool to verify the properties of the registers in the trigger network module, if the property assertion fails, check if the CSR file description is incorrect. If the CSR file is correct, indicate that the trigger network module design has defects, and prompt the verifier to overcome the corresponding defects.

[0025] Furthermore, the verification process for the APB bus protocol may specifically include: constraining the APB input signals to meet the protocol requirements and checking whether the APB output signals meet expectations; and observing whether the APB bus behavior actually occurs.

[0026] Specifically, the verification of the APB (Advanced Peripheral Bus) protocol can be completed in two ways: firstly, by constraining the APB input signals to meet the protocol requirements and checking whether the APB output signals meet expectations; secondly, by observing whether the APB bus behavior actually occurs, for example, by initiating an APB write operation and checking whether the corresponding register value changes.

[0027] During register verification, coverage can be collected to check for completeness. Through the use of the CSR App, verifiers can quickly verify registers and perform debugging, significantly reducing verification time.

[0028] When verifying the functional points of the triggering network module to be verified through the FPV App, the process can be as follows: Figure 3 As shown, the FPV App extracts the functional points to be tested from the specification (hardware detailed design specification) document and writes the corresponding properties for assertion verification. The RTL (Register-Transfer Level) and the written properties are input into the FPV App tool. After analysis and elaboration, verification can be performed. The resulting functional point verification result may be either "proved" or "failed".

[0029] Optionally, if the function point verification result is that the verification fails, the attribute waveform is viewed using the FPV App tool; if the analysis of the attribute waveform confirms that the problem is a function point design issue, the function point design is prompted to be modified; if the analysis of the attribute waveform confirms that the problem is due to environmental issues, the attributes and constraints are prompted to be modified; environmental issues include over-constraint, under-constraint, and attribute mismatch; after the verification failure problem is resolved, the simulation is re-entered and the verification process is iterated until there are no attributes that fail verification.

[0030] Specifically, if the verification fails, the verification personnel can use the FPV App tool to view the property waveform. If the analysis confirms a function point design problem, the verification personnel can modify the function point design. If the analysis confirms an environmental problem (such as over-constraint, under-constraint, or property incompatibility), the verification personnel can modify the property and constraints. After resolving the verification failure, the simulation can be re-entered, and the above verification process can be iterated until there are no more properties that fail verification. Then, the next step of coverage collection and evaluation can be carried out.

[0031] The COV App tool was used to merge the coverage data collected during the verification process of the CSR App and FPV App mentioned above for coverage analysis. Coverage can be divided into property coverage, stimulus coverage, security assertion (checker) coverage (including the two core dimensions of COI coverage and proof core coverage), and functional coverage. Except for functional coverage, all other types of coverage were automatically generated by the COV App tool.

[0032] It's important to note that COI (Cone of Influence Coverage) is a key metric used to measure which parts of the design's logic were actually analyzed and used by the formal verification tool when proving an attribute, thus identifying verification "blind spots." Its core function is to locate and expose insufficiently explored code areas in formal verification, guiding verifiers to improve attributes or constraints and avoid overlooking critical defects. COI coverage = (Number of logic units actually analyzed by the formal proof engine / Total number of logic units within the attribute's influence cone) × 100%. While both proof core (ProofCore Coverage) and COI coverage originate from the attribute proof process in formal verification, their perspectives are completely opposite. COI coverage focuses on "which logic might be used," belonging to the scope of pre-emptive, static analysis; while Proof Core coverage focuses on "which logic is actually used," representing a post-emptive, dynamic proof result. This fundamental difference determines their uses: COI coverage is used to discover verification blind spots, while Proof Core coverage is used to simplify problems and accelerate debugging.

[0033] Among these, property coverage indicates whether all types of properties (including cover, assertion, and assumption) have been proven. Stimuli coverage indicates whether the environment is over-constrained and whether all code can be executed. Checker coverage indicates whether the code has properties that have been verified. Functional coverage is written by the verifier and is used to indicate whether certain states of particular concern to the verifier have been verified. If any coverage does not reach 100%, the verifier is instructed to find the cause and continuously iterate the environment until the coverage reaches 100% (i.e., the coverage target is met), thus completing the security signature of the trigger network module to be verified.

[0034] The aforementioned formal security verification method for trigger networks targeting automotive-grade chips utilizes a CSR App (Content Response Scheme) to verify the properties of registers within the trigger network module, an FPV App (Functional Functionality Verification Scheme) to verify the functionalities of the trigger network module, and a COV App (Content Response Verification Scheme) to merge the coverage data collected during the verification processes of the CSR App and FPV App. Coverage analysis is then performed and iterated until the coverage meets the target, forming a coverage-driven strategy for secure verification of the trigger network module. This solution can be implemented throughout the entire design and development cycle of the trigger network, without relying on fully designed and developed code. It offers a short verification environment setup time, exhaustively examines all verification spaces, promptly identifies deep-seated defects, and enables secure verification, achieving complete verification of the trigger network.

[0035] It should be understood that, although Figure 1 The steps are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in this document, there is no strict order in which these steps are executed; they can be performed in other orders. Figure 1 At least some of the steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0036] In one embodiment, a formal verification system for trigger networks of automotive-grade chips is also provided, which applies the aforementioned formal safety verification method for trigger networks of automotive-grade chips. This formal verification system for trigger networks of automotive-grade chips includes an adapter, an input proxy, an APB component, an output proxy, an alarm proxy, a register probe, a scoreboard, and an assertion library. The input proxy connects to the trgin interface of the trigger network module to be verified, and is used to combine all trigger signals from the input trigger network module into a set of signals. The output proxy connects to the trgout interface of the trigger network module, and is used to combine all trigger signals output by the trigger network module into a set of signals. The alarm proxy connects to the alarm interface of the trigger network module, and is used to perform functional safety signal assertion checks. The APB component connects to the APB interface of the trigger network module, and is used to process APB bus protocol signals; processing APB bus protocol signals includes constraints on input signals and checks on output signals. The register probe connects to the registers inside the trigger network module, and is used to obtain the values ​​of the registers inside the trigger network module. The scoreboard connects to the input proxy, the output proxy, and the register probe respectively, and is used to perform end-to-end comparison of data between the trgin and trgout interfaces. The assertion library is used to store assertions generated by formalization tools based on the register attribute information of the triggering network module.

[0037] It is understandable that, in order to perform secure signature verification on the triggering network module to be verified, this embodiment proposes a suitable formal verification platform, such as... Figure 4 and Figure 5 As shown, the formal verification platform mainly includes an adapter, input proxy, APB component, output proxy, alarm proxy, register probe, scoreboard, and assertion library. The adapter acts as an intermediate bridge connecting the DUT (Design Under Test, i.e., the trigger network module to be verified) and a series of components and proxies in the verification environment.

[0038] An adapter is a specially designed connection and translation layer located between the physical interface of the DUT and the verification environment. Its core responsibility is to bridge the gap between the underlying hardware signals and the higher-level verification transactions, ensuring that the verification environment can interact with the DUT in a correct, convenient, and consistent manner. Specific functions include signal mapping and connectivity, resolving naming and bit-width mismatches by providing a unified access point: providing all components in the verification environment with a single, stable interface to access DUT signals, avoiding direct and fragmented dependencies on the DUT's physical interface. Other examples include protocol conversion and signal timing generation, transforming "transactions" into "waveforms": transactions (such as "performing a write operation") in the verification environment are abstract. The adapter (often working in conjunction with the driver) is responsible for breaking down this transaction and converting it into precise signal timing that conforms to the interface protocol (such as AXI and APB protocols). This timing includes handshake control signals valid and ready, and changes in the transmission content signals addr and data at specific clock edges. In reverse conversion, the adapter also assembles the raw signal waveforms captured from the DUT's physical interface (such as data transmission during a successful handshake) into an abstract transaction object for use by the monitor and scoreboard.

[0039] The input agent connects to the DUT's trgin interface (an input port for receiving external trigger signals). It combines all (such as hundreds or thousands) trigger signals from different external modules into a single signal for easy management and selection, including constraints on the input signals.

[0040] The output agent connects to the DUT's trgout interface (the trigger output port used to send trigger signals), and combines all (such as hundreds or thousands of trigger signals that need to be output to different external modules) trigger signals from the DUT into a group of signals for easy selection, including assertion checks on the output signals.

[0041] The alarm proxy connects to the alarm interface of the DUT and is used to perform functional safety signal alarm assertion checks. For example, if no alarm is initiated, the alarm signal should remain low; if an alarm is initiated, the alarm signal should be pulled high for 1 to 2 cycles.

[0042] The APB component connects to the DUT's APB interface and is used to process APB bus protocol signals. This includes constraining input signals (such as the peripheral select signal psel, the peripheral enable signal penable, the read / write control signal pwrite, and the write data bus pwdata, etc., which are core signals of the APB bus protocol) to meet the APB bus protocol requirements. For example, the penable signal is pulled high for one clock cycle after the psel signal is pulled high. It also includes checking output signals (such as the peripheral ready signal preprey and the peripheral error response signal pslverr, etc.). For example, the pslverr signal cannot be pulled high.

[0043] The register probe connects to the registers inside the DUT. The register probe internally declares all the registers used to obtain their values ​​for inspection processing in the scoreboard.

[0044] like Figure 5 As shown, the scoreboard is connected to the input proxy, output proxy, and register probe respectively, and is used to process the end-to-end comparison of data between the trgin and trgout interfaces. Specifically, it can include input and output selection comparison, input filtering and input recording, output expansion and modulation checking, etc.

[0045] Using the aforementioned formal verification system for trigger networks, the CSR App of formal tools verifies the properties of registers in the trigger network module, the FPV App verifies the functional points of the trigger network module, and the COV App merges the coverage data collected during the verification processes of the CSR App and FPV App, performs coverage analysis, and iterates until the coverage meets the target, forming a coverage-driven strategy to achieve secure signature of the trigger network module. This solution can be implemented throughout the entire design and development cycle of the trigger network, does not rely on fully designed and developed code, has a short verification environment setup time, can exhaustively explore all verification spaces, promptly discover deep-seated defects, and can securely sign off, enabling rapid and complete verification of the trigger network module to be verified.

[0046] Furthermore, for the verification of the input / output selection function of the trigger network module, output index and input index are set. The output index is used to indicate the selected trigger output signal, and the input index is used to indicate the selected trigger input signal. The formalization tool automatically exhausts all possible values ​​and combinations of the output index and input index.

[0047] Specifically, for verifying the input / output selection function of the trigger network module, free variables such as the output index trgout_index and the input index trgin_index can be set to indicate which trgout (trigger output) signal and trgin (trigger input) signal were selected, respectively. The Formal tool will automatically exhaust all possible values ​​and combinations of trgout_index and trgin_index, thereby greatly simplifying the verification difficulty.

[0048] The inspection logic can be as follows: sel_reg represents the selection register, and the value of this selection register comes from the register probe. The pseudocode for the inspection logic can be as follows: If sel_reg[trgout_index] == trgin_index, then trgout[trgout_index] == trgin[trgout_index] for 1 to 3 cycles.

[0049] Since the internal sel_reg register is typically a large two-dimensional array, it increases the complexity of simulation. Therefore, alternatively, the design can be simplified by setting the sel_reg register as a black box or by using the stopat instruction to shorten the output logic of the sel_reg register. For example, the stopat instruction can improve simulation speed by limiting the time boundary (clock cycle) or signal triggering conditions of the formal analysis, allowing the tool to analyze only the output behavior of the selection register within a specified range. It can be understood that when the stopat instruction is used on a signal, it is essentially instructing the formal verification tool: "Temporarily ignore all current logic drivers and constraints of this signal, allowing it to freely take any possible value in the subsequent analysis." This operation achieves two goals: isolating influence, i.e., cutting off the connection between the signal and the logic driving it, helping verifiers determine whether the problem originates from the upstream logic of the signal; and observing behavior, i.e., allowing the signal to be freed up, observing how the design behaves under different input values, thereby verifying the robustness of the design or locating failures in specific scenarios.

[0050] Optionally, for input filtering in the trigger network module's input processing: if the input signal pulse width is less than or equal to the configured filter register value (denoted as gf_cnt), the input signal will be filtered out. The checking logic is as follows: check if the output signal pulse width is greater than the set filter register value. A counter can be set to count the output signal pulse width plus_width, and simultaneously detect the falling edge of the output signal. When the falling edge of the output signal is detected (the falling edge sig_negedge is pulled high), check if the pulse width plus_width value is greater than the set filter register value gf_cnt. The pseudocode for this check is as follows: If sig_negedge == 1, then plus_width > gf_cnt.

[0051] When checking the pulse width of the input signal, simultaneously checking the width of all bits and the signal edges of the output signal trgout would require an extremely large counter, significantly increasing the complexity of verification and simulation time. Therefore, a free variable such as the output index trgout_index can be used for constraint checking, meaning that only the width and signal edges of the output signal trgout[trgout_index] corresponding to the output index are checked.

[0052] Optionally, in the verification of recording the input state in the trgin input processing of the trigger network module and the widening function and pulse adjustment function in the trgout output processing, the pulse width of the signal is counted by a set counter.

[0053] Specifically, regarding the recording of input status in the trgin input processing of the trigger network module, if a rising edge of the input signal is detected, the corresponding status register value trgin_status should be 1. The pseudocode for this check is as follows: If $rose(trgin[trgin_index]), then trgin_status[index] == 1.

[0054] Optionally, for the widening function in the trgout output processing of the trigger network module: if extend_en (widening enable) is configured to equal 1, the output signal is widened by one pulse relative to the input signal. The checking logic is as follows: A counter is set to count the pulse width of the output signal, dest_plus_width, while simultaneously detecting the falling edge of the output signal. A counter is also set to count the pulse width of the input signal, src_plus_width. When the falling edge of the output signal arrives (the falling edge dest_negedge is pulled high), the pulse width dest_plus_width of the output signal is checked to be equal to the pulse width of the input signal, src_plus_width + 1. The pseudocode for this check is as follows: If dest_negedge == 1 && extend_en == 1, then dest_plus_width == src_plus_width + 1; If dest_negedge == 1 && extend_en == 0, then dest_plus_width == src_plus_width; Optionally, for the pulse adjustment function in the trgout output processing of the trigger network module: if mod_en (pulse enable) is configured, the pulse width of the output signal is equal to mod_width. The checking logic is as follows: a counter is set to count the pulse width dest_plus_width of the output signal, and the falling edge of the output signal is detected simultaneously. The pseudocode for checking is as follows: If dest_negedge==1&&mod_en==1, then dest_plus_width == mod_width.

[0055] Optionally, for the functional safety of the triggering network module: for example, when no alarm injection is initiated, the alarm signal should remain low; if an alarm injection is initiated (i.e., alarm_inject == 1), the alarm signal should be pulled high for 1 to 2 cycles, etc. The pseudocode is as follows: If alarm_inject == 1, then alarm == 1 for 1 to 2 cycles.

[0056] If alarm_inject == 0, then alarm == 0.

[0057] When the registers and buses in the trigger network module are verified by the CSR App and the function points are verified by the FPV App, the coverage can be collected and analyzed by the COV App, and the trigger network module can be securely signed in the continuous iteration.

[0058] Each module component in the aforementioned formal verification system for trigger networks for automotive-grade chips can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware or independently of a device with data processing capabilities, or stored in software within the memory of that device, allowing the processor to execute the operations corresponding to each module. The aforementioned device can be, but is not limited to, various types of verification computer equipment already existing in the art.

[0059] It is understandable that the specific limitations of the trigger network formal verification system for automotive-grade chips can be found in the corresponding limitations of the trigger network formal security verification method for automotive-grade chips mentioned above, and will not be repeated here.

[0060] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0061] The above embodiments merely illustrate several implementation methods of the present invention, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of protection of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and all such modifications and improvements fall within the scope of protection of the present invention.

Claims

1. A formal security verification method for trigger networks of automotive-grade chips, characterized in that, Including the following steps: Use a Python script to extract the register attribute information of the trigger network module to be verified in an automotive-grade chip and save it as a CSR file in CSR format. The CSR App, a formal tool, is used to verify the properties of registers in the trigger network module and the APB bus protocol. The formal tool is configured to generate corresponding assertions based on the register property information. The assertions include register reset value checks, read-write consistency checks, read-only checks, write-only checks, and security lock checks. The functional points of the trigger network module are verified using the formalization tool FPV App. Specifically, the FPV App extracts the functional points to be tested from the hardware detailed design specification document of the trigger network module and writes the corresponding attributes for assertion verification. After analyzing and expanding the input RTL file of the trigger network module and the written attributes, the FPV App obtains the corresponding functional point verification results. After merging the coverage data collected during the verification process of CSR App and FPV App using the COV App formalization tool, coverage analysis is performed and iterated until the coverage meets the target to complete the security signature of the triggering network module. The coverage includes attribute coverage, stimulus coverage, security assertion coverage, and functional coverage.

2. The formal security verification method for trigger networks for automotive-grade chips according to claim 1, characterized in that, When using a formalization tool to verify the properties of registers in the triggering network module using a CSR App, if the property assertion fails, check if the CSR file description is incorrect. If the CSR file is correct, it indicates that the network module design has a defect.

3. The formal security verification method for trigger networks for automotive-grade chips according to claim 1 or 2, characterized in that, The verification process for the APB bus protocol includes: By constraining the APB input signal to meet protocol requirements and checking whether the APB output signal meets expectations; By observing whether the APB bus behavior actually occurs.

4. The formal security verification method for trigger networks for automotive-grade chips according to claim 1, characterized in that, If the function point verification result is that the verification fails, use the FPV App tool to view the attribute waveform; If the analysis of the attribute waveform confirms that the problem is a function point design issue, then a prompt will be made to modify the function point design. If the analysis of the attribute waveform confirms that the problem is due to environmental issues, then a prompt will be made to modify the attributes and constraints; Environmental issues include over-constraints, under-constraints, and attribute mismatches; After resolving the issues that failed verification, the simulation is restarted, and the verification process is iterated until there are no more attributes that failed verification.

5. The formal security verification method for trigger networks for automotive-grade chips according to claim 3, characterized in that, Formalization tools include JasperGold or VC-Formal.

6. A formal verification system for trigger networks of automotive-grade chips, characterized in that, The formal security signature method for trigger networks for automotive-grade chips, as described in any one of claims 1 to 5, is used for verification. The formal verification system for trigger networks for automotive-grade chips includes an adapter, input proxy, APB component, output proxy, alarm proxy, register probe, scoreboard, and assertion library; The input proxy connects to the trgin interface of the trigger network module to be verified, and is used to combine all the trigger signals of the input trigger network module into a set of signals. The output proxy connects to the trgout interface of the trigger network module, which is used to combine all the trigger signals output by the trigger network module into a set of signals. The alarm proxy connects to the alarm interface of the trigger network module to perform functional safety signal assertion checks. The APB component connects to the APB interface of the trigger network module to process APB bus protocol signals; processing APB bus protocol signals includes constraining input signals and checking output signals. The register probe connects to the registers inside the trigger network module and is used to obtain the values ​​of the registers inside the trigger network module; The scoreboard is connected to the input agent, output agent, and register probe respectively, and is used to process the end-to-end comparison of data between the trgin and trgout interfaces; The assertion library is used to store assertions generated by formalization tools based on the register attribute information of the triggering network module.

7. The formal verification system for trigger networks for automotive-grade chips according to claim 6, characterized in that, For the verification of the input / output selection function of the trigger network module, output and input indices are set. The output index is used to indicate the selected trigger output signal, and the input index is used to indicate the selected trigger input signal. The formalization tool automatically exhausts all possible values ​​and combinations of the output and input indices.

8. The formal verification system for trigger networks for automotive-grade chips according to claim 7, characterized in that, In verifying the input / output selection function of the trigger network module, the selection register used by the inspection logic is set as a black box, or the output logic of the selection register is shortened using the stopat instruction.

9. The formal verification system for trigger networks for automotive-grade chips according to any one of claims 6 to 8, characterized in that, The input filtering process in the trigger input handling of the network module is checked as follows: Check if the pulse width of the output signal is greater than the set filter register value; wherein, a counter is set to count the pulse width of the output signal and use the output index to check the constraint.

10. The formal verification system for trigger networks for automotive-grade chips according to claim 9, characterized in that, In the verification of the input state recording in the trgin input processing of the trigger network module and the pulse width and pulse adjustment functions in the trgout output processing, the pulse width of the signal is counted by the set counter.

Images