Vehicle-gauge-level input / output multiplexer verification system and method

Abstract

The invention relates to a verification system and method for a vehicle-specification-level input / output multiplexer, and the method comprises the steps: driving a script program to automatically generate a formalized assertion file through a configuration table of a structured input / output multiplexer based on a formalized verification tool, and automatically exhausting all possible states of the input / output multiplexer through the formalized verification tool, thereby achieving the verification of the vehicle-specification-level input / output multiplexer. According to the method, the 100% function coverage rate of the input and output multiplexer is achieved, the verification result is improved, the verification efficiency of the input and output multiplexer is improved by more than 10 times compared with the verification efficiency of a traditional UVM method, and the verification requirements of a vehicle-mounted chip IO MUX with high complexity and high safety requirements are met.

Description

Technical Field

[0001] This invention belongs to the field of chip verification technology and relates to an automotive-grade input / output multiplexer verification system and method. Background Technology

[0002] An IO MUX (Input / Output Multiplexer) is a hardware component commonly used to switch signals between multiple input / output (I / O) ports of a chip, enabling connections between multiple external devices and signal sources. In high-density integrated circuits, I / O multiplexers optimize limited I / O resources by selecting specific signal paths. Common operating modes of I / O multiplexers include: input selection mode, where the input signal is transmitted to the chip's internal circuitry when the selection signal is set to a certain value; output selection mode, where signals from external devices can be transmitted to different pins or signal lines through the I / O multiplexer based on the control signal; and bidirectional mode, where the I / O multiplexer determines whether to transmit a signal to or receive a signal from an external device based on the selection signal.

[0003] In automotive-grade input / output multiplexers, due to the large number of ports and the complex multiplexing relationships between them, traditional mainstream UVM (Universal Verification Methodology) methods are insufficient to fully verify the complex multiplexing capabilities of input / output multiplexers, and the verification code is also quite large. Therefore, improving the verification efficiency and results of input / output multiplexers 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 technologies, this invention proposes an automotive-grade input / output multiplexer verification system and an automotive-grade input / output multiplexer verification method, which can improve the verification efficiency of input / output multiplexers and improve the verification results.

[0005] To achieve the above objectives, the embodiments of the present invention adopt the following technical solutions: On the one hand, an automotive-grade input / output multiplexer verification system is provided, comprising: The configuration acquisition module is used to acquire the structured spreadsheet-style IOMUX configuration table of the input / output multiplexer under test; the IOMUX configuration table contains the input / output ports, selection signal logic, enable conditions, electrical attributes, and port multiplexing relationships of the input / output multiplexer; The configuration table parsing engine is used to parse the IO MUX configuration table and extract the signal path mapping relationship of the input / output multiplexer. An assertion generator is used to automatically generate assertion files compatible with formal verification tools based on preset parsing rules and signal path mapping relationships. The formal verification interface is used to automatically load the assertion file and RTL design file of the input / output multiplexer by calling the application interface of the formal verification tool through TCL scripts. The formal verification tool performs full-state-space mathematical modeling and exhaustive verification of the input / output multiplexer and outputs a verification report of the input / output multiplexer. The verification report marks the assertions that have passed verification and those that have failed verification. The formal verification tool provides corresponding counterexample waveforms for the failed assertions, which are used to indicate the debugging of the input / output multiplexer.

[0006] On the other hand, a verification method for automotive-grade input / output multiplexers is also provided, applied to an automotive-grade input / output multiplexer verification system. The automotive-grade input / output multiplexer verification method includes the following steps: Obtain the IO MUX configuration table of the input / output multiplexer under test in a structured spreadsheet format; the IO MUX configuration table contains the input / output ports, selection signal logic, enable conditions, electrical attributes, and port multiplexing relationships of the input / output multiplexer; Parse the IO MUX configuration table to extract the signal path mapping relationship of the input / output multiplexer; Based on preset parsing rules and signal path mapping relationships, assertion files compatible with formal verification tools are automatically generated. The assertion file and RTL design file of the input / output multiplexer are automatically loaded by calling the application interface of the formal verification tool through the TCL script; The formal verification tool performs full-state-space mathematical modeling and exhaustive verification of the input-output multiplexer, and outputs a verification report of the input-output multiplexer. The verification report marks the assertions that pass verification and the assertions that fail verification. The formal verification tool provides corresponding counterexample waveforms for the assertions that fail verification. The counterexample waveforms are used to indicate the debugging of the input-output multiplexer.

[0007] One of the above technical solutions has the following advantages and beneficial effects: The aforementioned automotive-grade input / output multiplexer verification system and method automatically generates formal assertion files using a configuration table-driven script program based on formal verification tools. It automatically exhaustively enumerates all possible states of the input / output multiplexer using these tools, achieving 100% functional coverage and improving verification results. This results in verification efficiency more than 10 times higher than the traditional UVM method, meeting the verification requirements of highly complex and high-safety automotive chip IO MUXs. Attached Figure Description

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

[0009] Figure 1 This is a block diagram of a verification system for an automotive-grade input / output multiplexer in one embodiment; Figure 2 This is a schematic diagram of the assertion file generation process in one embodiment; Figure 3 This is a schematic diagram of a GPIO MUX verification scenario for an in-vehicle MCU in one embodiment. Figure 4 This is a flowchart illustrating a method for verifying an automotive-grade input / output multiplexer in one embodiment. Detailed Implementation

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

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

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

[0013] In one embodiment, such as Figure 1 As shown, an automotive-grade input / output multiplexer verification system is provided, including a configuration acquisition module 11, a configuration table parsing engine 13, an assertion generator 15, and a formal verification interface 17. The configuration acquisition module 11 acquires a structured spreadsheet-style IOMUX configuration table of the input / output multiplexer under test (referred to as an IO MUX). The IO MUX configuration table includes the input / output ports, selection signal logic, enable conditions, electrical attributes, and port multiplexing relationships of the input / output multiplexer. The configuration table parsing engine 13 parses the IO MUX configuration table to extract the signal path mapping relationships of the input / output multiplexer. The assertion generator 15 automatically generates assertion files compatible with formal verification tools based on preset parsing rules and the signal path mapping relationships. The formal verification interface 17 automatically loads the assertion files and RTL design files of the input / output multiplexer by calling the application programming interface of the formal verification tool through a TCL script, performs full-state-space mathematical modeling and exhaustive verification of the input / output multiplexer through the formal verification tool, and outputs a verification report of the input / output multiplexer.

[0014] The verification report marks the assertions that passed verification and those that failed verification. The formal verification tool provides corresponding counterexample waveforms for the failed assertions, which are used to indicate the debugging of the input-output multiplexer.

[0015] It is understood that the configuration acquisition module 11 is used to receive the IO MUX configuration table of the input / output multiplexer under test. This IO MUX configuration table is defined in the form of a structured spreadsheet, including data such as the input / output ports, selection signal logic, enable conditions, electrical attributes, and port multiplexing relationships determined after the design of the input / output multiplexer under test is completed. The configuration table parsing engine 13 is used to execute a pre-developed script program to parse the IO MUX configuration table and extract the signal path mapping relationship of the input / output multiplexer. The assertion generator 15 is used to convert the signal path mapping relationship into an assertion file in SVA / PSL code form using a template engine (such as Jinja2). The formal verification interface 17 is used to automatically load the RTL (Register-Transfer Level Design) design file and assertion file of the input / output multiplexer through a TCL (ToolCommand Language, a scripting language widely used in EDA tools) script calling the formal verification tool's application programming interface, and then perform full-state-space mathematical modeling and exhaustive verification of the input / output multiplexer through the formal verification tool, outputting a verification report.

[0016] Specifically, simply drag the IO MUX configuration table (existing in Excel format) generated after the IO MUX design is completed into the designated directory of the system. After running the corresponding Python script to parse the configuration, you can obtain the corresponding IO MUX formal assertion file (a formal verification assertion file for the IO MUX, used to verify the functional correctness of the IO MUX through formal methods (such as Formal Verification)). Then, run the corresponding IO MUX and its corresponding IO MUX formal assertion file through a formal verification tool (such as, but not limited to, Jaspergold formal software, which is one of the mainstream tools in the field of hardware design verification, used to verify the functional correctness of chip hardware design through formal methods (based on mathematical logic reasoning)) to finally obtain the corresponding verification results.

[0017] Since formal verification tools are formal verification tools, they use mathematical tools for definition, development and verification. They automatically perform mathematical modeling of the IO MUX design circuit, and then exhaustively enumerate all states that the design circuit can reach during system operation. Functional verification and rule checks are performed in the form of assertions, which can greatly improve the verification efficiency of IO MUX and improve the reliability of verification results.

[0018] The aforementioned automotive-grade input / output multiplexer verification system automatically generates formal assertion files using a configuration table-driven script program based on formal verification tools. It automatically exhaustively enumerates all possible states of the input / output multiplexer using these tools, achieving 100% functional coverage and improving verification results. This results in verification efficiency more than 10 times higher than the traditional UVM method, meeting the verification requirements of highly complex and high-safety automotive chip IO MUXs and conforming to the ISO 26262 ASIL D standard.

[0019] More specifically, the process first receives an IO MUX configuration table provided by the user. This configuration table is defined in a structured spreadsheet (e.g., Excel), including the input / output ports, selection signal logic, enable conditions, electrical attributes, and port multiplexing relationships of the IO MUX under test after its design is completed. Then, a script (e.g., Python) parses the IO MUX configuration table to extract the signal path mapping relationships of the IO MUX under test and automatically generates an assertion file compatible with the formal verification tool based on preset parsing rules. Next, the generated assertion file and the IO MUX's RTL design file (or gate-level netlist) are input into the formal verification tool (e.g., but not limited to JasperGold or VC Formal, currently the most mainstream formal verification tools in the hardware design verification field) to automatically perform full-state-space mathematical modeling and exhaustive verification of the IO MUX. Finally, the formal verification tool outputs a verification report for the IO MUX, marking successful or failed assertions. For failed assertions, counterexample waveforms are provided to indicate debugging needs for the IO MUX.

[0020] In one embodiment, the configuration acquisition module can also be used to check the integrity of the IO MUX configuration table to ensure that the selection signal, enable signal and direction field of all ports are defined. The integrity check follows the existing configuration information consistency comparison requirements of the IO MUX. If the configuration table is found to be incomplete, a prompt message can be output to the user for confirmation or to fill in the missing information to ensure the accuracy of the configuration information used in subsequent steps.

[0021] In one embodiment, the assertion file includes direction control assertions, level compatibility assertions, functional correctness assertions, conflict detection assertions, electrical rule assertions, and resistor configuration assertions.

[0022] Specifically, the assertion generator can also be used to automatically generate direction control assertions for bidirectional ports. For example, when DIR (Direction Control Signal) = 1, the IO PAD (Input / Output Pad) outputs an internal signal; when DIR = 0, the input signal is latched into an internal register. The assertion generator can also be used to generate level compatibility assertions for multi-voltage domain ports (e.g., a 1.8V input signal cannot directly drive a 3.3V output port).

[0023] Furthermore, the assertion files generated by the assertion generator can also include the following types: Functional correctness assertions are used to verify the mapping relationship between the selection signal and the output signal, for example: SystemVerilog (SV language) assert property (@(posedge clk) (SEL == 2'b01&&EN) |->(OUT == IN1))” This means that when SEL=2'b01 and EN=1, the output OUT must be equal to the input IN1; SEL represents the selection signal, and EN represents the enable signal.

[0024] Conflict detection assertions are used to ensure that no multiple inputs are selected simultaneously, for example: SystemVerilog "assert property (@(posedge clk) !(SEL == 2'b00&&SEL == 2'b01))" This means that no two valid combinations of SELs can be activated simultaneously.

[0025] Electrical rule assertions are used to check voltage domain and drive strength constraints, for example: systemverilog “assert property (@(posedge clk) (VOLTAGE == 3.3V) |->(OUT>2.7V&&OUT<3.6V))” This indicates that when the 3.3V port outputs a high level, the drive voltage must be within the range of 2.7V to 3.6V.

[0026] Specifically, the execution process of formal verification tools may include: The formal verification tool performs static property checks on the IO MUX's RTL design file (e.g., no deadlock, no uninitialized signals); then, it generates a state transition diagram for the IO MUX, covering all possible input combinations and selection signal sequences. If the check finds behavior that violates assertions, the formal verification tool provides a minimal counterexample waveform.

[0027] For example, the IO MUX configuration table for automotive-grade IO MUX can be shown in Table 1: Table 1

[0028] Among them, Output represents output, Input represents input, Bidirectional represents bidirectional, Pull-Up represents pull-up, None represents none, and Pull-Down represents pull-down.

[0029] In one embodiment, the preset parsing rules include: if direction = output, then generate an output path assertion; if direction = bidirectional, then generate a direction control assertion; if pull-up / pull-down is not empty, then generate a pull-up / pull-down resistor assertion.

[0030] Specifically, the preset parsing rules can be as follows: If Direction=Output, then an output path assertion is generated; If Direction=Bidirectional, then generate a direction control assertion; If Pull-Up / Down is not empty, then a pull-up / pull-down resistor assertion is generated.

[0031] In some implementations, such as Figure 2 As shown, the algorithm code used in the generated assertion file can be, for example: Python def generate_assertions(config_table): assertions = [] for _, row in config_table.iterrows(): if row["Direction"] == "Output": assertion = f"assert property (@(posedge clk) (SEL == {row['SelectSignal']}&&EN == {row['Enable']}) |->(OUT == {row['Port Name']});" assertions.append(assertion) elif row["Direction"] == "Bidirectional": dir_assertion = f"assert property (@(posedge clk) (DIR == 1'b1) |->(IO_PAD == internal_{row['Port Name']});" assertions.append(dir_assertion) if row["Pull-Up / Down"] == "Pull-Up": pu_assertion = f"assert property (@(posedge clk) (IO_PAD == 'z') |->(PULLUP == 1'b1));" assertions.append(pu_assertion) return assertions The code generates hardware verification assertions based on the configuration table. Its function is to iterate through each row of the configuration table, and based on the port direction and pull-up / down configuration, generate corresponding hardware assertion statements to verify whether the circuit behavior meets expectations. `config_table`: Configuration table data, containing the following key columns: "Direction": Port direction, possible values ​​are "Output" or "Bidirectional"; "Select Signal": Select signal value, used as the selection condition for the output port; "Enable": Enable signal value, used to enable the output port; "Port Name": The port name used for signal references in assertions; "Pull-Up / Down": Pull-up / down configuration, possible values ​​are "Pull-Up" (pull-up), etc.

[0032] Returns: A list of generated assertion strings, each string being a hardware assertion statement (e.g., SVA assertion sva.sv).

[0033] In some implementations, the formal verification tool (using JasperGold as an example) execution flow includes input file preparation and command execution. Input file preparation includes RTL design files (such as IO MUX.v), generated assertion files (such as IO MUX_sva.sv), and constraint files (such as clock and reset timing).

[0034] The pseudocode for JasperGold executing commands can be as follows: “tcl read_verilog -top IO MUX IO MUX.v # Load the design; `read_sva -file IO MUX_sva.sv` # Load assertions; `create_clock -name clk -period 10ns` # Sets clock constraints; `prov -all` # Run formal verification; # Generate a report using the format text and output verification_report.txt.

[0035] Finally, the verification results are analyzed: (1) By assertion: marked in green, for example: text [PASS] Assertion A1: SEL=00 → OUT=GPIO0: (2) Failure assertion: Marked in red and provide counterexample waveforms, for example: text [FAIL] No conflict when Assertion A2: SEL=01 Counterexample: When SEL=01, GPIO0 and UART_RX are activated simultaneously. The following demonstrations use the GPIO MUX verification of the automotive MCU and the IO MUX verification of the automotive Ethernet PHY as examples: like Figure 3 As shown, the GPIO MUX verification of the vehicle MCU is as follows: the design specification is 128 GPIOs, supporting 8 multiplexed functions (UART, CAN and SPI ports, etc.).

[0036] Verification process: Fill in the Excel configuration table (128 rows × 10 columns), the Python script generates 10,240 SVA assertions, JasperGold runs for 2 hours and finds 2 conflicts: CAN_TX and SPI_MISO are activated at the same time when SEL=3'b110, and the 1.8V UART signal is mistakenly connected to the 3.3V GPIO. Figure 3 In Python, `json.loads` and `yaml.safe_load` are functions used to parse structured data. Pandas is the most popular data processing and analysis library in Python, specifically designed for handling structured data such as tabular data, CSV / Excel data, and database tables.

[0037] IO MUX verification for automotive Ethernet PHY: Special requirements include impedance matching (50Ω) and differential signals (i.e., RX+ / RX-).

[0038] Generate assertions: systemverilog assert property (@(posedge clk) (DIFF_MODE == 1'b1) |->(Z_IMPEDANCE == 50Ω))” / / Differential pair impedance matching check The verification results of the above automotive-grade input / output multiplexer verification system are compared with those of the traditional mainstream UVM method, as shown in Table 2 below: Table 2

[0039] Automotive-grade compatibility: Supports fault mode injection as required by ISO 26262 ASIL D (such as forced selection of signal errors, verification of safety mechanisms). Scalable to AEC-Q100 Grade 1 temperature range (-40°C-125°C) for electrical characteristic verification. High degree of automation; no manual coding required from configuration sheet to verification report, reducing human error.

[0040] Each component in the aforementioned automotive-grade input / output multiplexer verification system can be implemented entirely or partially through software, hardware, or a combination thereof. These components can be embedded in hardware or independently of a device with data processing capabilities, or stored in software within the memory of the aforementioned device, so that the processor can call and execute the operations corresponding to each module. The aforementioned device can be, but is not limited to, various types of chip verification computers already existing in the art.

[0041] In one embodiment, an automotive-grade input / output multiplexer verification method is provided, applied to the automotive-grade input / output multiplexer verification system in any of the above embodiments, such as... Figure 4 As shown, the verification method for automotive-grade input / output multiplexers includes the following steps S10 to S18: S10, Obtain the IO MUX configuration table of the input / output multiplexer under test in a structured spreadsheet format; the IO MUX configuration table contains the input / output ports, selection signal logic, enable conditions, electrical attributes, and port multiplexing relationships of the input / output multiplexer; S12, parse the IO MUX configuration table to extract the signal path mapping relationship of the input / output multiplexer; S14, Based on the preset parsing rules and the signal path mapping relationship, automatically generate assertion files compatible with formal verification tools; S16, automatically loads the assertion file and RTL design file of the input / output multiplexer by calling the application interface of the formal verification tool through the TCL script; S18. Perform full-state-space mathematical modeling and exhaustive verification of the input-output multiplexer using a formal verification tool, and output a verification report of the input-output multiplexer. The verification report marks the assertions that pass verification and the assertions that fail verification. The formal verification tool provides corresponding counterexample waveforms for the assertions that fail verification. The counterexample waveforms are used to indicate the debugging of the input-output multiplexer.

[0042] The aforementioned automotive-grade input / output multiplexer verification method automatically generates formal assertion files using a configuration table-driven script program based on a formal verification tool. This method automatically exhaustively enumerates all possible states of the input / output multiplexer, achieving 100% functional coverage and improving verification results. This results in verification efficiency more than 10 times higher than the traditional UVM method, meeting the verification requirements of highly complex and high-safety automotive chip IO MUXs.

[0043] In one embodiment, the above-described automotive-grade input / output multiplexer verification method may further include the following steps: Check the integrity of the IO MUX configuration table.

[0044] For specific limitations on the verification method of automotive-grade input / output multiplexers, please refer to the corresponding limitations of the automotive-grade input / output multiplexer verification system mentioned above, which will not be repeated here.

[0045] It should be understood that, although Figure 4The 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 4 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.

[0046] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), memory bus DRAM (RDRAM), and interface DRAM (DRDRAM), etc.

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

[0048] 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 verification system for automotive-grade input / output multiplexers, characterized in that, include: The configuration acquisition module is used to acquire the IO MUX configuration table of the input / output multiplexer under test in a structured spreadsheet format; The IO MUX configuration table lists the input / output ports, selection signal logic, enable conditions, electrical attributes, and port multiplexing relationships of the input / output multiplexer. The configuration table parsing engine is used to parse the IO MUX configuration table and extract the signal path mapping relationship of the input / output multiplexer. An assertion generator is used to automatically generate assertion files compatible with formal verification tools based on preset parsing rules and signal path mapping relationships. The formal verification interface is used to automatically load the assertion file and RTL design file of the input / output multiplexer by calling the application interface of the formal verification tool through TCL scripts. The formal verification tool performs full-state-space mathematical modeling and exhaustive verification of the input / output multiplexer and outputs a verification report of the input / output multiplexer. The verification report marks the assertions that have passed verification and those that have failed verification. The formal verification tool provides corresponding counterexample waveforms for the failed assertions, which are used to indicate the debugging of the input / output multiplexer.

2. The automotive-grade input / output multiplexer verification system according to claim 1, characterized in that, The configuration acquisition module is also used to check the integrity of the IO MUX configuration table.

3. The automotive-grade input / output multiplexer verification system according to claim 2, characterized in that, The assertion file includes direction control assertions, level compatibility assertions, functional correctness assertions, conflict detection assertions, electrical rule assertions, and resistor configuration assertions.

4. The automotive-grade input / output multiplexer verification system according to any one of claims 1 to 3, characterized in that, Formal verification tools include JasperGold or VC Formal.

5. The automotive-grade input / output multiplexer verification system according to claim 2, characterized in that, The preset parsing rules include: If direction = output, then generate an output path assertion; If direction = bidirectional, then generate a direction control assertion; If the pull-up / pull-down resistor is not empty, then a pull-up / pull-down resistor assertion is generated.

6. A verification method for automotive-grade input / output multiplexers, characterized in that, The automotive-grade input / output multiplexer verification method, applied to the verification system for automotive-grade input / output multiplexers as described in any one of claims 1 to 5, includes the following steps: Obtain the IO MUX configuration table of the input / output multiplexer under test in a structured spreadsheet format; the IO MUX configuration table contains the input / output ports, selection signal logic, enable conditions, electrical attributes, and port multiplexing relationships of the input / output multiplexer; Parse the IO MUX configuration table to extract the signal path mapping relationship of the input / output multiplexer; Based on preset parsing rules and signal path mapping relationships, assertion files compatible with formal verification tools are automatically generated. The assertion file and RTL design file of the input / output multiplexer are automatically loaded by calling the application interface of the formal verification tool through the TCL script; The formal verification tool performs full-state-space mathematical modeling and exhaustive verification of the input-output multiplexer, and outputs a verification report of the input-output multiplexer. The verification report marks the assertions that pass verification and the assertions that fail verification. The formal verification tool provides corresponding counterexample waveforms for the assertions that fail verification. The counterexample waveforms are used to indicate the debugging of the input-output multiplexer.

7. The verification method for automotive-grade input / output multiplexers according to claim 6, characterized in that, It also includes the following steps: Check the integrity of the IO MUX configuration table.

Images