An integrated verification system and method based on multi-protocol bridging

Abstract

The present disclosure relates to the technical field of integrated circuit design, and particularly relates to an integrated verification system and method based on multi-protocol bridging. By configuring a control and bridging conversion module, instructions of a first communication interface are dynamically converted into a bottom layer target protocol timing, thereby constructing a unified register access entry. This design effectively avoids the redundant work of writing driving code for each peripheral protocol in traditional verification. Meanwhile, during the system level simulation stage, this mechanism completely decouples the high-level test sequence from the bottom layer physical protocol, reduces the time overhead caused by frequent development and mounting of different interfaces, and improves the cross-level reuse rate and overall simulation efficiency of the verification environment. After introducing a built-in self-test test engine, the system can automatically generate continuous target access addresses and expected test data internally according to preset instructions through hardware logic. The automated internal excitation generation can improve the automation level and screening efficiency in the chip mass production test stage.

Description

Technical Field

[0001] This invention relates to the field of integrated circuit design technology, and more specifically to an integrated verification system and method based on multi-protocol bridging. Background Technology

[0002] As System-on-Chip (SoC) design and chip verification become increasingly complex, multi-interface communication plays a crucial role in chip-level system-level interaction, and configuring registers for external devices through different interfaces has become a standard function. Consequently, verification and testing environments for such complex multi-protocol systems face severe challenges, including cumbersome test case development and low factory testing efficiency.

[0003] In related technologies, there are often problems such as excessive consumption of testing resources and weak verification mechanisms. Therefore, how to improve the automated self-testing and multi-interface cross-verification capabilities of the chip's internal registers while unifying the register access entry point and reducing the overhead of multi-protocol verification has become an urgent problem to be solved. Summary of the Invention

[0004] In view of this, the present invention provides an integrated verification system and method based on multi-protocol bridging to solve the problem of how to improve the automated self-testing and multi-interface cross-verification capabilities of the chip's internal registers while unifying the register access entry and reducing the multi-protocol verification overhead.

[0005] This disclosure provides an integrated verification system based on multi-protocol bridging, the system comprising:

[0006] The configuration control module is used to receive test configuration instructions via the first communication interface, and parse the test configuration instructions to obtain the target address range, data generation rules, specified write protocol type and specified read protocol type.

[0007] The self-test engine, connected to the configuration control module, is used to automatically generate the target access address and the expected data to be written based on the target address range and data generation rules through hardware logic when receiving an automated test trigger command.

[0008] The bridging conversion and caching module includes a first storage unit and a second storage unit. The bridging conversion and caching module is used to convert the expected write data into a first timing signal based on the write protocol type and send it to the target access address of the device under test, and store the expected write data in the first storage unit; and to generate a second timing signal based on the read protocol type to obtain the actual returned data from the target access address, and store the actual returned data in the second storage unit.

[0009] The hardware comparison module is used to sequentially extract data from the first storage unit and the second storage unit for comparison, and update the verification status indication information of the internal status register according to the comparison result, so that external devices can obtain and execute target screening control actions; wherein, the reading protocol type and the writing protocol type are the same or different.

[0010] This disclosure also provides an integration verification method based on multi-protocol bridging, applied to the aforementioned integration verification system based on multi-protocol bridging, the method comprising:

[0011] The test configuration command is received via the first communication interface, and the test configuration command is parsed to obtain the target address range, data generation rules, specified write protocol type and specified read protocol type.

[0012] Upon receiving an automated test trigger command, the target access address and the expected data to be written are automatically generated through hardware logic based on the target address range and data generation rules.

[0013] Based on the write protocol type, the expected write data is converted into a first timing signal and sent to the target access address of the device under test, and the expected write data is stored in the first storage unit; and based on the read protocol type, a second timing signal is generated to obtain the actual returned data from the target access address, and the actual returned data is stored in the second storage unit.

[0014] The data in the first storage unit and the second storage unit are extracted sequentially and compared. The verification status indication information of the internal status register is updated according to the comparison result so that the external device can obtain and execute the target screening control action. The read protocol type and the write protocol type may be the same or different.

[0015] This disclosure also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of the above-described integrated verification method based on multi-protocol bridging when executing the computer program.

[0016] This disclosure also provides a computer-readable storage medium storing computer instructions for causing a computer to implement the aforementioned integrated verification method based on multi-protocol bridging.

[0017] This disclosure also provides a computer program product, including computer instructions for causing a computer to execute the aforementioned integrated verification method based on multi-protocol bridging.

[0018] The integrated verification system and method based on multi-protocol bridging in the above embodiments of this disclosure dynamically converts the instructions of the first communication interface into the timing of the underlying target protocol by configuring the control and bridging conversion module, thereby constructing a unified register access entry point. This design effectively avoids the redundant work of writing driver code separately for each peripheral protocol in traditional verification. At the same time, in the system-level simulation stage, this mechanism completely decouples the high-level test sequence from the underlying physical protocol, reducing the time overhead caused by frequent development and mounting of different interfaces, and improving the cross-level reuse rate and overall simulation efficiency of the verification environment. Secondly, after introducing the built-in self-test engine, the system can automatically generate continuous target access addresses and expected test data internally through hardware logic according to preset instructions. The automated internal stimulus generation not only speeds up the traversal test of massive registers, but also reduces the dependence on intervention in the complex timing of external test equipment, thereby improving the automation level and wafer screening efficiency in the chip mass production testing stage.

[0019] Finally, to address the challenge of consistency verification when different communication interfaces access the same physical data, an innovative architecture combining dual storage units and a hardware comparison module was adopted. During single-protocol loopback or multi-interface cross-testing, the independent asynchronous caching mechanism effectively handles the data transmission rate differences caused by bandwidth variations between read and write protocols. The system directly performs sequential data alignment, extraction, and cross-comparison at the hardware level, enhancing the fault exposure capability and intrinsic testing reliability of complex systems with multi-protocol interactions. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the specific embodiments or related technologies of this disclosure, the accompanying drawings used in the description of the specific embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 An exemplary schematic diagram of the architecture of an integrated verification system based on multi-protocol bridging according to an embodiment of the present disclosure is shown;

[0022] Figure 2 An exemplary schematic diagram of the architecture of another integrated verification system based on multi-protocol bridging according to an embodiment of the present disclosure is shown;

[0023] Figure 3 A flowchart illustrating an integrated verification method based on multi-protocol bridging provided in an embodiment of this disclosure is shown.

[0024] Figure 4 A schematic diagram of the structure of an electronic device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0025] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this disclosure.

[0026] Please refer to Figure 1 , Figure 1 An exemplary schematic diagram of the architecture of an integrated verification system based on multi-protocol bridging, according to an embodiment of this disclosure, is shown. Figure 1 As shown, the integrated verification system based on multi-protocol bridging (hereinafter referred to as the system) includes:

[0027] The configuration control module 11 is used to receive test configuration instructions via the first communication interface, and parse the test configuration instructions to obtain the target address range, data generation rules, specified write protocol type and specified read protocol type.

[0028] In this embodiment, the configuration control module 11 can be understood as a logical component or control unit deployed at the top level of the system, responsible for receiving master control commands and global state scheduling.

[0029] The first communication interface can refer to the standardized communication link between the system and the external master control node; the test configuration command can refer to the control data stream containing verification task parameters and mode selection status.

[0030] The target address range can refer to the physical addressing range within the device under test (DUT) where data interaction or functional verification is required; the data generation rules can refer to the algorithmic strategies or logical conventions used to guide the underlying hardware to automatically generate regular test stimuli; the specified write protocol type and the specified read protocol type can refer to the specific communication timing specifications followed by the underlying target peripheral when sending and reading data.

[0031] Specifically, after receiving the test configuration command via the first communication interface, the configuration control module 11 performs internal decoding processing on the command. The configuration control module 11 converts the parsed and extracted parameters such as the target address range and data generation rules into global control signals or status indicators within the system to establish the control baseline for the current verification task.

[0032] Furthermore, the configuration control module 11 independently identifies and determines the underlying communication protocol types required for the data transmission link and the data readback link based on the mode control parameters in the test configuration instruction, thereby providing a routing and scheduling basis for subsequent hardware to perform single-protocol self-test or multi-protocol cross-verification.

[0033] For example, when the system performs automated testing, the external master node sends a series of transaction-level instructions to the configuration control module 11 via the system-level bus. The configuration control module 11 extracts the specific start and end addresses of the peripheral devices to be tested, determines the data test characteristics used for verification, and sets up the process of writing the data to the peripheral device via a first-type communication protocol, and then reading the data back via a second-type communication protocol.

[0034] Understandably, this design highly unifies the configuration entry point for complex multi-protocol verification, reduces the strong coupling dependency of upper-layer driver software on multiple underlying physical communication protocols, reduces code redundancy in repeatedly developing test cases for different underlying interfaces, and improves the test scheduling flexibility and top-level interface reusability of multi-peripheral systems.

[0035] The self-test engine 12 is connected to the configuration control module 11. When it receives an automated test trigger command, it automatically generates the target access address and the expected data to be written through hardware logic based on the target address range and data generation rules.

[0036] In this embodiment, the self-test engine 12 can refer to a built-in hardware test vector generator that runs independently of the external main control processor and is responsible for automatically generating the stimulus sequence required for traversal testing at the underlying level.

[0037] The automated test trigger instruction can refer to a hardware enable signal or status indicator used within the system to activate the self-test process; the target access address can refer to the physical storage location identifier that needs to be accessed during the test; the data to be written can refer to a standard reference payload that matches the current access address and is used for subsequent verification and comparison.

[0038] Specifically, when the self-test engine 12 is activated by a trigger command, its internal logic circuits automatically perform traversal calculations based on the range determined by the configuration control module to continuously output the target access address sequence. Simultaneously, based on the parsed data generation rules, the self-test engine 12 synchronously calculates and outputs the expected write data, strictly aligned with each target access address, at the hardware level. Here, the entire generation process is executed entirely in a closed-loop manner by the underlying hardware, without any intervention from the software layer.

[0039] For example, when performing large-scale continuous space read and write tests on the underlying peripherals, the self-test engine 12 does not need to issue instructions to each device via the external system bus. Instead, it generates test address streams and corresponding test data streams continuously within the hardware and delivers them directly to the downstream transmission module for packet processing.

[0040] Understandably, this design endows the chip system with the ability to generate self-excitation without the high-frequency intervention of external testing platforms. By completely sinking the heavy workload of test vector generation to the hardware level, it not only eliminates the communication bandwidth bottleneck caused by relying on external slow test interfaces to write data one by one in traditional testing, but also greatly improves the efficiency of traversing massive register spaces and the automation throughput in the chip mass production stage.

[0041] The bridging conversion and caching module 13 includes a first storage unit 131 and a second storage unit 132. The bridging conversion and caching module 13 is used to convert the expected write data into a first timing signal based on the write protocol type and send it to the target access address of the device under test, and store the expected write data in the first storage unit 131; and to generate a second timing signal based on the read protocol type to obtain the actual returned data from the target access address, and store the actual returned data in the second storage unit 132.

[0042] In this embodiment, the bridging conversion and caching module 13 can refer to a comprehensive hardware execution component responsible for generating physical layer protocol waveforms and bidirectionally isolating and caching underlying data.

[0043] The first storage unit 131 and the second storage unit 132 may refer to internal buffers or temporary storage arrays used to independently store test data streams at different stages; the first timing signal may refer to physical electrical waveforms or bus timing sequences that conform to the specified write communication standard; the second timing signal may refer to physical probe waveforms or bus read timing sequences that conform to the specified read communication standard; the actual returned data may refer to the current state or stored value that is actually read from the device under test via the underlying physical communication link.

[0044] Specifically, during the data delivery phase, the bridging conversion and caching module 13 calls the matching physical layer conversion logic according to the write protocol type allocated by the system, converts the received parallel expected write data into a first timing signal and drives it to an external pin to complete the write operation to the target access address; during this process, the bridging conversion and caching module 13 simultaneously pushes a copy of the expected write data into the first storage unit 131 for retention.

[0045] During the data readback phase, the bridging conversion and caching module 13 switches to control logic that matches the read protocol type, initiates a read transaction to the same target access address, outputs a second timing signal, and after capturing the actual returned data from the device under test, inputs it into the second storage unit 132 for synchronous retention.

[0046] For example, when performing hybrid protocol access to a low-level peripheral, the module first drives the communication link to output test characteristic values ​​according to the timing specifications of the first type of communication protocol, and stores the raw baseline data of these characteristic values ​​in the first internal buffer. Subsequently, the module switches to the timing specifications of the second type of communication protocol to initiate a read-back transaction, storing the response data actually read from the peripheral into the second internal buffer, thereby completing the heterogeneous interaction and separate data storage for the same physical address at the hardware level.

[0047] Understandably, this design not only enables flexible bridging and conversion between system-level data sequences and various underlying physical timing sequences, but more importantly, by introducing a dual-channel independent caching architecture, it achieves strict physical isolation between the written baseline data and the read result data. This isolation mechanism lays the underlying hardware buffer foundation for the subsequent system to handle access latency caused by different communication protocols, effectively preventing the risks of data overwriting, tampering, and timing disorder that are easily caused by traditional single-cache architectures when performing complex cross-accesses.

[0048] The hardware comparison module 14 is used to sequentially extract data from the first storage unit 131 and the second storage unit 132 for comparison, and update the verification status indication information of the internal status register according to the comparison result, so that the external device can obtain and execute the target screening control action; wherein, the reading protocol type and the writing protocol type are the same or different.

[0049] In this embodiment, the hardware comparison module 14 can refer to a digital logic execution unit deployed at the end of the data stream readback, responsible for performing underlying data consistency arbitration and state tracking.

[0050] Internal status registers can refer to physical storage nodes within the system dedicated to storing test result status flags; verification status indication information can refer to comprehensive status data that characterizes whether the current data comparison process has passed or records the occurrence of errors; external devices can be automated test platforms that perform chip factory testing or on-chip main control processors responsible for system-level scheduling; target screening control actions can refer to response behaviors such as yield determination, defective product sorting, system interruption, or alarm based on test results.

[0051] Specifically, during the data readback phase, the hardware comparison module 14 sequentially retrieves the expected data to be written from the first storage unit 131 and the corresponding actual returned data from the second storage unit 132 according to the trigger conditions, and synchronously sends both to the internal comparison logic unit for consistency verification. If they match, the interaction is considered normal; if they do not match, a verification error is considered to have occurred. The hardware comparison module 14 updates the verification status indication information in the internal status register in real time according to the dynamic changes in the comparison result. Furthermore, regardless of whether the communication protocol for performing the write and read operations is in homogeneous access mode or heterogeneous cross-access mode, the hardware comparison module 14 can complete the final comparison based on the data stored in the first storage unit 131 and the second storage unit 132.

[0052] For example, when screening wafers or testing chips in batches, after the system completes a series of automated read-write interactions using specific protocols, the hardware comparison module 14 automatically checks the sent baseline data and the received response data at the underlying level to see if they match. External testing equipment does not need to intervene in the tedious byte-by-byte reading and verification process; it only needs to read the status feedback in the internal status register. If an error status is detected and marked, the external testing equipment can directly control the physical robotic arm to sort the problematic chip to the defective product warehouse.

[0053] Understandably, this design completely offloads the arduous and real-time-critical data comparison work to the pure hardware layer for automated execution, significantly reducing the computational and scheduling load on upper-layer software or external test machines. Simultaneously, through the dual-storage architecture at the end of the interface, the system natively supports single-protocol self-testing and multi-protocol cross-verification scenarios, filling the technical gap in traditional testing solutions that struggle to efficiently verify the consistency of heterogeneous physical interfaces accessing the same target address. This improves the accuracy of fault screening and overall throughput in chip mass production testing.

[0054] In one possible implementation of the above embodiments, the configuration control module 11 internally maps a configuration register group, which includes at least:

[0055] The first control register is used to configure the system's operating mode as either normal read / write mode or automated self-test mode.

[0056] The second control register is used to configure the start and end addresses of the target address range, data generation rules, and single protocol test enable status in the automated self-test mode.

[0057] The third control register is used to configure the specified write protocol type and the specified read protocol type separately when the read protocol type and the write protocol type are different;

[0058] The fourth status register is used to update the verification status indication information according to the comparison result during the comparison process performed by the hardware comparison module 14. Specifically, the fourth status register is used to: when it is determined that a certain expected data to be written is inconsistent with the corresponding actual returned data, record the target access address where the error occurred in the error address field, record the corresponding expected data to be written and the actual returned data in the expected data field and the actual data field respectively, and perform hardware accumulation operation on the internal error counter; after completing all comparisons within the target address range, receive the global flag bit representing the self-test completion and self-test pass status.

[0059] In this embodiment, in order to achieve more refined and flexible underlying verification control, the register group inside the configuration control module 11 can be further divided into multiple specific physical control and status fields.

[0060] It should be noted that the specific names and bit width encoding definitions of the register fields below are only illustrative examples of preferred embodiments and do not constitute a limitation on the scope of protection of this solution. In actual chip architecture design, those skilled in the art can make equivalent additions, subtractions or modifications according to the actual bus bit width or protocol requirements.

[0061] As a concrete example, the first control register is mainly used for top-level configuration of system modes. Its internal fields may include, but are not limited to, an output mode field (e.g., OUTPUT_MODE) and an operation type field (e.g., OPERATION). For example, the output mode field can be encoded as 00 to indicate the use of Advanced Peripheral Bus (APB) timing, 01 to indicate the use of Serial Peripheral Interface (SPI) timing, 10 to indicate the use of Inter-Integrated Circuit (I2C) timing, and 11 reserved as an extension bit; the operation type field can be encoded specifically (such as 00 and 01) to distinguish whether the system is in a normal register read / write state or in a state where a low-level automatic self-test is initiated.

[0062] The second control register, when implemented as a self-test mode configuration, may include a start address field (e.g., START_ADDR) and an end address field (e.g., END_ADDR) to indicate the start and end range of the test. It may also include a test data mode field (e.g., PATTERN_SEL) to select the data generation logic, and a self-test mode field (e.g., MODE_SEL) to indicate single-protocol or cross-validation mode. Furthermore, this register may optionally be configured with independent enable bits for each protocol, such as APB mode enable (APB_MODE_EN), SPI mode enable (SPI_MODE_EN), and I2C mode enable (I2C_MODE_EN).

[0063] Furthermore, the third control register can serve as a dedicated parameter channel for cross-validation configuration. In a preferred configuration, it can internally be divided into a write mode field (such as WRITE_MODE) to select the APB, SPI, or I2C protocol when sending test stimuli; and simultaneously divided into read mode fields (such as READ_MODE1 and READ_MODE2) to specify the communication protocol used during readback, thereby supporting the free combination and scheduling of underlying heterogeneous protocols at the hardware level.

[0064] Finally, the fourth status register, serving as the output for status queries, can include internal fields representing the overall process progress, such as a self-test completion flag (e.g., BIST_DONE) and a self-test pass flag (e.g., BIST_PASS). To achieve precise hardware fault tracing, this register can be further refined into error address fields (e.g., ERROR_ADDR), expected data fields (e.g., ERROR_EXPECTED), and actual data fields (e.g., ERROR_ACTUAL). Optionally, to support intensive pipeline comparison statistics, this register can also be configured with verification count recording fields (e.g., CHECK_COUNT) and error count recording fields (e.g., ERROR_COUNT).

[0065] Through the multi-protocol bridging-based integrated verification system and method of the above embodiments of this disclosure, the external test equipment or main control software can complete the high degree of freedom configuration and in-depth fault state capture of the underlying complex multi-protocol bridging link with extremely low register read / write overhead through this refined field division mechanism.

[0066] In one possible implementation of the above embodiments, the self-test engine 12 integrates address generation logic and data generation logic.

[0067] When the first control register is configured to indicate the automated self-test mode, the address generation logic generates an incrementing target access address based on the start address and end address in the second control register through hardware stepping.

[0068] The data generation logic generates the expected data to be written corresponding to the current target access address by means of address mapping, address inversion or fixed feature value output, according to the data generation rules configured in the second control register.

[0069] In this embodiment, the self-test engine 12 can be internally structured into address generation logic and data generation logic. This architecture places the test stimulus generation process in the underlying digital circuitry, reducing the computational cycles required by the external main control processor.

[0070] In a specific implementation scenario, when the external control software or test equipment triggers and enables the automated self-test mode through the aforementioned first control register, the address generation logic reads the physical space boundary latched in the second control register. For example, if the start address is configured as 0x0000 and the end address is configured as 0x00FF, the hardware accumulator inside the address generation logic will perform clockwise accumulation with a bus-aligned step size that meets the requirements of the target peripheral, thereby outputting an incrementing target access address sequence on the internal hardware bus.

[0071] Synchronized with the address generation logic, the data generation logic, based on the data generation rules issued by the second control register, schedules internal hardware logic circuits to generate test data. For example, when the generation rule is configured for address mapping, the data generation logic directly extracts the current physical address value as the data payload output; when the rule is configured for address inversion, the current address data is passed through internal NOT gate logic to output the bit-inverted result; when the rule is configured for fixed feature value output, alternating test code streams such as 0x55 and 0xAA are directly output. The automatically generated expected write data, driven by the system clock, is clock-aligned with the corresponding target access address to form a test vector for the underlying layer to send packets.

[0072] The integrated verification system and method based on multi-protocol bridging in the above embodiments of this disclosure firstly eliminates the redundancy of repeatedly developing driver code for each heterogeneous underlying interface by unifying the access entry of multiple protocols through the configuration control module, significantly reducing the configuration communication overhead in system-level simulation and factory testing; secondly, the introduction of a hardware-level self-test engine to automatically generate test stimuli in a closed loop breaks the bandwidth bottleneck of traditionally relying heavily on external low-speed interfaces to issue instructions one by one, significantly improving the efficiency of traversing and self-testing massive register spaces; finally, relying on the unique dual-storage unit asynchronous buffer architecture and underlying digital comparison logic, it effectively resolves the interference of transmission rate differences between heterogeneous read and write protocols, fills the technical gap that traditional single-point self-test modules cannot perform multi-protocol cross-verification for the same physical address, thereby greatly enhancing the intrinsic testing accuracy and fault screening capability of complex chip interaction links.

[0073] In one possible implementation of the above embodiments, the bridging and caching module 13 integrates multi-protocol timing generation logic, which is configured as follows:

[0074] In response to the first preset high-speed bus protocol being the write protocol type or read protocol type, the expected write data and target access address are transmitted out in a timing-based transparent manner.

[0075] In response to a low-speed serial peripheral protocol being either the write or read protocol type, the built-in protocol conversion engine packages the expected write data into a corresponding serial data frame, or parses the received serial data frame into the actual return data; wherein, the low-speed serial peripheral protocol includes a serial peripheral interface protocol or an internal integrated circuit bus protocol.

[0076] In this embodiment, the multi-protocol timing generation logic can serve as the physical routing and waveform control unit of the underlying interface, and can dynamically select the corresponding data processing channel according to the protocol type identifier issued by the configuration command.

[0077] As a specific implementation, the first preset high-speed bus protocol can refer to a parallel bus protocol used internally by the chip or system, such as the APB protocol. When the system recognizes that the currently issued write or read protocol type is this parallel bus protocol, the multi-protocol timing generation logic synchronizes the input parallel data, target access address, and read / write control signals, and then directly transmits them out as parallel bus timing without performing parallel-to-serial conversion on the data itself. This pass-through mechanism is mainly used for data interaction between modules within the system or for read / write access to high-speed nodes on the chip.

[0078] Conversely, when the system identifies a low-speed serial peripheral protocol as the write or read protocol type, the multi-protocol timing generation logic will call the corresponding built-in protocol conversion engine to process the data stream. For example, the low-speed serial peripheral protocol here can include, but is not limited to, SPI or I2C protocols.

[0079] During data write operations, the protocol conversion engine packages and assembles the parallel, anticipated data into serial data frames conforming to the selected serial protocol specification, adding addressing information, control bits, or parity bits as needed. This data is then output bit-by-bit via physical pins to the external device under test (DUT). During data read operations, the protocol conversion engine captures the level sequence returned by the external device via the serial link, unpacks it according to the corresponding protocol specification, and restores the serial bit stream to the parallel actual return data recognizable by the system's internal comparison logic.

[0080] Through the multi-protocol bridging-based integrated verification system and method of the above embodiments of this disclosure, the system, through this split-processing architecture of multi-protocol timing generation logic, can be compatible with two different data transmission mechanisms—parallel timing pass-through and serial protocol packetization—within the bridging conversion and caching module. This provides the upper-layer self-test engine or configuration control module with general access support to the underlying heterogeneous communication interface, decoupling the generation of test data streams from the underlying physical transmission timing.

[0081] In one possible implementation of the above embodiments, the first storage unit 131 and the second storage unit 132 are independent asynchronous storage entities;

[0082] In the event of a mismatch between the data transfer rates of the write protocol type and the read protocol type, the hardware comparison module 14 is configured as follows:

[0083] Real-time monitoring of the data write status of the first storage unit 131 and the second storage unit 132;

[0084] When it is detected that at least one complete piece of data is stored in both the first storage unit 131 and the second storage unit 132, the first piece of information in the first storage unit 131 and the second storage unit 132 is extracted for the first round of logical comparison.

[0085] According to the data interaction order, the next piece of information is extracted from the first storage unit 131 and the second storage unit 132 in sequence for iterative comparison, so as to eliminate the interference of the rate difference between the first timing signal and the second timing signal on the hardware comparison process.

[0086] In this embodiment, the first storage unit 131 and the second storage unit 132 within the bridging and caching module 13 are physically designed as mutually isolated asynchronous buffer queues. As a specific example, these two storage units can be implemented using independent asynchronous first-in-first-out queues or dual-port random access memory. This independent asynchronous memory structure allows data to be stored and retrieved according to their respective independent clock domains and physical bus rates.

[0087] As a specific application scenario, when the system performs cross-validation testing, the write protocol type (e.g., SPI protocol) and read protocol type (e.g., I2C protocol) issued by the configuration control module 11 usually have inherent differences in baud rate or clock frequency. In this case of data transmission rate mismatch, in order to prevent data misalignment, the hardware comparison module 14 does not directly verify the transient levels on the bus, but instead monitors the cache depth or empty / full flag bits of the first storage unit 131 and the second storage unit 132 in real time.

[0088] During the monitoring process, the hardware comparison module 14 will trigger the comparison action only when the hardware comparison module 14 detects through the hardware connection that the corresponding expected data to be written has been stored in the first storage unit 131 and the actual returned data has been completely received and stored in the second storage unit 132.

[0089] Specifically, the hardware comparison module 14 extracts the first piece of information from the first storage unit 131 and the second storage unit 132, and sends it to the internal digital comparator for the first round of logical comparison. Subsequently, according to the first-in-first-out or pipelined order, the hardware comparison module 14 extracts the next piece of information to be checked from the first storage unit 131 and the second storage unit 132 in turn, and performs iterative comparison in a loop.

[0090] Through this verification mechanism based on dual asynchronous storage buffers and status monitoring, the system constructs a flexible data alignment channel at the underlying level. This channel allows the hardware comparison operation to depend only on the actual residency state of the data, rather than being limited by the absolute synchronization requirements of transmission and reception times between heterogeneous buses. This design objectively eliminates the interference caused by the difference in transmission delay and rate between the first and second timing signals during the comparison process, providing reliable hardware logic support for multi-protocol hybrid cross-validation.

[0091] In one possible implementation of the above embodiments, the first communication interface is an APB interface, and the configuration control module 11 receives test configuration instructions through the APB interface and realizes the reuse of the top-level interface;

[0092] The write protocol type and read protocol type are low-speed serial peripheral protocols, and are configured independently as SPI protocol or I2C protocol respectively;

[0093] The bridging conversion and caching module 13 is specifically configured to automatically package and convert the transaction-level configuration instructions issued based on the APB interface into underlying data frames that conform to the SPI protocol or I2C protocol for output.

[0094] In this embodiment, as a preferred application scenario, the first communication interface is represented as the APB interface. The configuration control module 11 connects to this APB interface, serving as a unified communication bridge between the external system-level master control device and the internal hardware self-test logic, thus achieving the reuse of the top-level interface. This reuse mechanism eliminates the need for additional control pins or dedicated test buses for testing and verification functions, controlling the overall chip pin overhead and hardware routing complexity.

[0095] Furthermore, for the underlying multi-physical interface verification scenario, the write and read protocol types in this embodiment are limited to low-speed serial peripheral protocols. As a specific example of protocol combination, these two protocol types can be configured separately and independently as SPI or I2C protocols. Based on this independent configuration architecture, external instructions can not only specify homogeneous single-protocol loopback access (e.g., SPI write and SPI read), but also flexibly specify heterogeneous cross-combination access (e.g., SPI write and I2C read).

[0096] When performing specific protocol conversion operations, the bridging conversion and buffer module 13 directly interfaces with the aforementioned top-level APB interface and the underlying serial physical pins. When the configuration control module 11 receives a parallel transaction-level configuration command issued by the external master controller via the APB bus, the protocol conversion hardware inside the bridging conversion and buffer module 13 extracts the payload data from the transaction. Subsequently, based on the current protocol configuration state, the bridging conversion and buffer module 13 encapsulates and packages the parallel data at the hardware level, adds necessary start bits, stop bits, or response bits according to the target protocol, converts it into a low-level serial data frame conforming to the timing specifications of the SPI or I2C protocol, and outputs it serially through the corresponding physical interface.

[0097] By defining the abstract first communication interface as the APB interface and the underlying read and write protocols as SPI or I2C protocols, this embodiment provides a protocol conversion framework that can be directly applied to industrial-grade SoC designs. This framework isolates the high-speed bus domain and low-speed peripheral clock domain of the on-chip system, enabling the timing packing and unpacking operations across protocols to be performed autonomously by the underlying hardware, thus reducing the computational load on the upper-layer main control software for driving multiple serial communication protocols.

[0098] To facilitate a better understanding of the complete workflow of this disclosure, the following explanation uses two comprehensive system application scenarios as examples:

[0099] As a specific application scenario, in Scenario 1, namely the chip factory testing stage, the automated testing process of this system includes: First, the system performs a power-on operation; then, the system executes a cross-test sequence, the specific actions of which include: writing reference data 0x5555_5555 via the SPI protocol and reading back the response data via the I2C protocol for logical comparison; writing reference data 0xAAAA_AAAA via the SPI protocol and reading back the response data via the I2C protocol for logical comparison; writing reference data 0xFFFF_FFFF via the I2C protocol and reading back the response data via the SPI protocol for logical comparison; writing reference data 0x0000_0000 via the I2C protocol and reading back the response data via the SPI protocol for logical comparison; next, the system performs an automated operation of data incrementing cross-traversal; finally, the system records the test comparison results so that external devices can screen out faulty chips with physical defects.

[0100] As another specific application scenario, in scenario 2, namely the system-level EDA simulation verification stage, the workflow of this system specifically includes: First, configuring the system to normal read / write mode, and inputting read / write sequences conforming to the APB bus timing from the system-level test platform (testbench); Second, the system selects the timing conversion output mode as I2C mode, SPI mode, or APB mode according to the specific requirements of the verification environment; Finally, connecting the corresponding driver to the device under test, thereby completing the efficient mounting of the simulation environment and multi-protocol verification.

[0101] The integrated verification system and method based on multi-protocol bridging in the above embodiments of this disclosure firstly eliminates the redundancy of repeatedly developing driver code for each heterogeneous underlying interface by unifying the access entry of multiple protocols through the configuration control module, thereby reducing the configuration communication overhead in system-level simulation and factory testing. Secondly, the introduction of a hardware-level self-test engine to automatically generate test stimuli in a closed loop breaks the bandwidth bottleneck of traditionally relying heavily on external low-speed interfaces to issue instructions one by one, and improves the efficiency of traversing and self-testing massive register spaces. Finally, relying on the unique dual-storage unit asynchronous buffer architecture and underlying digital comparison logic, the interference of transmission rate differences between heterogeneous read and write protocols is effectively resolved, filling the technical gap that traditional single-point self-test modules cannot perform multi-protocol cross-verification for the same physical address, and enhancing the intrinsic testing accuracy and fault screening capability of complex chip interaction links.

[0102] In one possible embodiment, please refer to Figure 2 , Figure 2 An exemplary schematic diagram of the architecture of another integrated verification system based on multi-protocol bridging, according to an embodiment of this disclosure, is shown. Figure 2 As shown, the system is divided into multiple logical layers for collaborative interaction in its overall hardware architecture from top to bottom.

[0103] Specifically, at the very top of the system is the mode and master control configuration and status query module, namely the apb_bridge_ctrl logic unit marked in the figure. Functionally, this part corresponds to the aforementioned configuration control module 11. The mode and master control configuration and status query module directly interfaces with the APB interface of the external system to send and receive APB signals. It is responsible for receiving test configuration instructions issued by the external master control node, completing the selection of the system working mode, setting the start and end addresses, and providing an interface for reading the internal execution status to the outside.

[0104] Below the aforementioned mode and master control configuration and status query module is connected an output mode selection and timing conversion engine, namely the apb_bridge logic unit marked in the figure. This conversion engine branches downward to three parallel protocol master controllers, specifically including the APB master controller responsible for APB timing pass-through, the SPI master controller responsible for SPI timing generation, and the I2C master controller responsible for I2C timing generation. This part of the structure logically corresponds to the aforementioned bridging conversion and caching module 13 and its internally integrated multi-protocol timing generation logic. Its main function is to write internal test instructions or parallel expected data according to the top-level configuration, route and convert them into physical timing waveforms that conform to the specific underlying communication protocol specifications.

[0105] At the lower layer of the protocol main controller, a self-testing and cross-validation engine is deployed. This engine logically integrates the functions of the aforementioned self-testing engine 12 and hardware comparison module 14. Internally, it includes a self-testing configuration control unit for overall scheduling, and integrates address generation logic and data generation logic for generating test stimuli, as well as a comparison engine for performing data consistency verification.

[0106] In terms of physical connections and data flow Figure 2 The architecture shown exhibits multi-path characteristics. On one hand, the self-test and cross-validation engine receives timing signals from various protocol master controllers at its top, and directly connects to the various underlying physical interfaces of the device under test (DUT) below, specifically including the DUT's APB, I2C, and SPI interfaces, enabling the physical layer transmission of test stimuli and the readback of response data. On the other hand, the left and right sides of the self-test and cross-validation engine respectively lead out control links and status feedback links directly to the top-level configuration control module.

[0107] In the specific operational flow of the system's cross-validation test, after parsing the instructions, the top-level configuration control module 11 sends out the configuration parameters and activates the self-test and cross-validation engine through the control link on the left. The address generation logic and data generation logic inside the engine automatically perform hardware stepping and rule calculations to generate the target access address and the expected data to be written. These data streams are packaged in timing by the selected protocol master controller above and then sent to the corresponding interface of the device under test. Subsequently, the actual return data returned by the device under test is transmitted back through the corresponding interface, and the internal comparison engine extracts the expected value and the actual value in sequence to perform hardware comparison. After the comparison is completed, the updated verification status indication information such as the error address and error count is reported in real time to the internal status register of the top-level configuration control module through the feedback link on the right for external devices to obtain. This hierarchical hardware architecture, with the control link isolated from the data link, further improves the system's flexibility in scheduling multi-peripheral protocol interactions and the stability of the underlying physical routing.

[0108] Further reference Figure 3 , Figure 3 This diagram illustrates a flowchart of an integrated verification method based on multi-protocol bridging provided in an embodiment of this disclosure, applied to the above-mentioned... Figures 1-2 In any of the integrated verification systems based on multi-protocol bridging shown in any of the embodiments, the process of this method may include the following steps:

[0109] Step S301: Receive test configuration instructions via the first communication interface, and parse the test configuration instructions to obtain the target address range, data generation rules, specified write protocol type, and specified read protocol type;

[0110] Step S302: Upon receiving the automated test trigger instruction, based on the target address range and data generation rules, the target access address and the expected data to be written are automatically generated through hardware logic.

[0111] Step S303: Based on the write protocol type, the expected write data is converted into a first timing signal and sent to the target access address of the device under test, and the expected write data is stored in the first storage unit; and based on the read protocol type, a second timing signal is generated to obtain the actual returned data from the target access address, and the actual returned data is stored in the second storage unit.

[0112] Step S304: Extract data from the first storage unit and the second storage unit sequentially for comparison, and update the verification status indication information of the internal status register according to the comparison result so that the external device can obtain and execute the target screening control action; wherein, the reading protocol type and the writing protocol type are the same or different.

[0113] In one possible implementation of the above embodiments, the integrated verification system based on multi-protocol bridging internally maps a configuration register group, which includes at least a first control register, a second control register, a third control register, and a fourth status register; the method further includes:

[0114] The system's operating mode is configured as either normal read / write mode or automated self-test mode via the first control register.

[0115] In the automated self-test mode, the start and end addresses of the target address range, data generation rules, and single protocol test enable status are configured through the second control register.

[0116] When the read protocol type and the write protocol type are different, the specified write protocol type and the specified read protocol type can be configured separately through the third control register;

[0117] During the comparison process, the verification status indication information is updated through the fourth status register based on the comparison results. Specifically, updating the verification status indication information through the fourth status register based on the comparison results includes: when it is determined that a certain expected data to be written is inconsistent with the corresponding actual returned data, the target access address where the error occurred is recorded in the error address field, the corresponding expected data to be written and the actual returned data are recorded in the expected data field and the actual data field respectively, and the internal error counter is incremented in hardware; after all comparisons within the target address range are completed, a global flag indicating the self-test completion and self-test pass status is received.

[0118] In one possible implementation of the above embodiments, the target access address and the data to be written are automatically generated by hardware logic, specifically including:

[0119] When the first control register is configured to indicate the automated self-test mode, an incremental target access address is generated by hardware stepping based on the start address and end address in the second control register.

[0120] According to the data generation rules configured in the second control register, the expected data to be written corresponding to the current target access address is generated through address mapping, address inversion, or fixed feature value output.

[0121] In one possible implementation of the above embodiments, converting the data to be written into a first timing signal based on the write protocol type, and generating a second timing signal based on the read protocol type to obtain the actual returned data, specifically includes:

[0122] In response to the first preset high-speed bus protocol being the write protocol type or read protocol type, the expected write data and target access address are transmitted out in a timing-based transparent manner.

[0123] In response to a low-speed serial peripheral protocol being either the write protocol type or the read protocol type, the expected write data is packaged into a corresponding serial data frame, or the received serial data frame is parsed into the actual return data; wherein, the low-speed serial peripheral protocol includes a serial peripheral interface protocol or an internal integrated circuit bus protocol.

[0124] In one possible implementation of the above embodiments, the first storage unit and the second storage unit are independent asynchronous storage entities;

[0125] When the data transfer rates of the write protocol type and the read protocol type do not match, the data in the first storage unit and the second storage unit are extracted sequentially for comparison, specifically including:

[0126] Real-time monitoring of the data write status of the first and second storage units;

[0127] When it is detected that at least one complete piece of data is stored in both the first storage unit and the second storage unit, the first piece of information in the first storage unit and the second storage unit are extracted for the first round of logical comparison.

[0128] According to the data interaction order, the next piece of information is extracted from the first storage unit and the second storage unit in turn for iterative comparison, so as to eliminate the interference of the rate difference between the first timing signal and the second timing signal on the hardware comparison process.

[0129] In one possible implementation of the above embodiments, the first communication interface is an APB interface, which receives test configuration instructions and enables the reuse of the top-level interface.

[0130] The write protocol type and read protocol type are low-speed serial peripheral protocols, and are configured independently as SPI protocol or I2C protocol respectively;

[0131] Based on the write protocol type, the expected write data is converted into a first timing signal and sent to the target access address of the device under test. Specifically, this includes automatically packaging and converting the transaction-level configuration instructions issued based on the APB interface into low-level data frames that conform to the SPI or I2C protocol for output.

[0132] It should be noted that the multi-protocol bridging-based integrated verification system provided in the above embodiments is only illustrated by the division of the above program modules when implementing the corresponding multi-protocol bridging-based integrated verification method. In practical applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the above system can be divided into different program modules to complete all or part of the processing described above. In addition, the system provided in the above embodiments and the corresponding Figure 3The embodiments of the methods shown belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0133] This disclosure also provides an electronic device having the above-described features. Figures 1-2 The integrated verification system shown is based on multi-protocol bridging.

[0134] Figure 4 A schematic diagram of the structure of an electronic device according to an embodiment of the present disclosure is shown.

[0135] The following is a detailed reference. Figure 4 The diagram illustrates a structural schematic suitable for implementing an electronic device according to embodiments of the present disclosure. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 401, which can perform various appropriate actions and processes based on a program stored in read-only memory (ROM) 402 or a program loaded from memory 408 into random access memory (RAM) 403. RAM 403 also stores various programs and data required for the operation of the electronic device. The processor 401, ROM 402, and RAM 403 are interconnected via bus 404. Input / output (I / O) interface 405 is also connected to bus 404.

[0136] Typically, the following devices can be connected to I / O interface 405: input devices 406 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 407 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 408 including, for example, magnetic tapes, hard disks, etc.; and communication devices 409. Communication device 409 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 4 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0137] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 409, or installed from memory 408, or installed from ROM 402. When the computer program is executed by processor 401, it performs the functions defined in the multi-protocol bridging-based integrated verification method of embodiments of this disclosure.

[0138] Figure 4The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0139] 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 can 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. When the software or computer code is accessed and executed by the computer, processor, or hardware, the multi-protocol bridging-based integrated verification method shown in the above embodiments is implemented.

[0140] A portion of this disclosure can be applied to computer program products, such as computer program instructions, which, when executed by a computer, can invoke or provide methods and / or technical solutions according to this disclosure through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, and installation package files. Accordingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions; the computer compiling the instructions and then executing the corresponding compiled program; the computer reading and executing the instructions; or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0141] Although embodiments of the present disclosure have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present disclosure, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. An integrated verification system based on multi-protocol bridging, characterized in that, The system includes: The configuration control module is used to receive test configuration instructions via the first communication interface, and parse the test configuration instructions to obtain the target address range, data generation rules, specified write protocol type and specified read protocol type; The self-test engine, connected to the configuration control module, is used to automatically generate the target access address and the expected data to be written through hardware logic based on the target address range and the data generation rules when receiving an automated test trigger command. A bridging and caching module includes a first storage unit and a second storage unit. The bridging and caching module is used to convert the expected write data into a first timing signal based on the write protocol type and send it to the target access address of the device under test, and store the expected write data in the first storage unit; and to generate a second timing signal based on the read protocol type to obtain the actual returned data from the target access address, and store the actual returned data in the second storage unit. The hardware comparison module is used to sequentially extract data from the first storage unit and the second storage unit for comparison, and update the verification status indication information of the internal status register according to the comparison result, so that external devices can obtain and execute target screening control actions; wherein, the read protocol type is the same as or different from the write protocol type.

2. The system according to claim 1, characterized in that, The configuration control module internally maps a configuration register group, which includes at least: The first control register is used to configure the system's operating mode as either normal read / write mode or automated self-test mode. The second control register is used to configure the start and end addresses of the target address range, the data generation rules, and the single protocol test enable status in the automated self-test mode. The third control register is used to configure the specified write protocol type and the specified read protocol type separately when the read protocol type and the write protocol type are different; The fourth status register is used to update the verification status indication information according to the comparison result during the comparison process performed by the hardware comparison module. Specifically, the fourth status register is used to: when it is determined that a certain expected data to be written is inconsistent with the corresponding actual returned data, record the target access address where the error occurred in the error address field, record the corresponding expected data to be written and the actual returned data in the expected data field and the actual data field respectively, and perform a hardware accumulation operation on the internal error counter; after all comparisons within the target address range are completed, receive a global flag bit representing the self-test completion and self-test pass status.

3. The system according to claim 2, characterized in that, The self-test engine integrates address generation logic and data generation logic. When the first control register is configured to indicate the automated self-test mode, the address generation logic generates an incrementing target access address based on the start address and end address in the second control register through hardware stepping. The data generation logic generates the expected data to be written corresponding to the current target access address by means of address mapping, address inversion, or fixed feature value output, according to the data generation rules configured in the second control register.

4. The system according to claim 1, characterized in that, The bridging and caching module integrates multi-protocol timing generation logic, which is configured as follows: In response to the write protocol type or read protocol type being a first preset high-speed bus protocol, the input expected write data and the target access address are transmitted out in a timing-based transparent manner. In response to the write protocol type or read protocol type being a low-speed serial peripheral protocol, the expected write data is packaged into a corresponding serial data frame through the built-in protocol conversion engine, or the received serial data frame is parsed into the actual returned data; wherein, the low-speed serial peripheral protocol includes a serial peripheral interface protocol or an internal integrated circuit bus protocol.

5. The system according to claim 1, characterized in that, The first storage unit and the second storage unit are independent asynchronous storage units; In the event that the data transfer rates of the write protocol type and the read protocol type do not match, the hardware comparison module is configured as follows: Real-time monitoring of the data write status of the first storage unit and the second storage unit; When it is detected that at least one complete piece of data is stored in both the first storage unit and the second storage unit, the first piece of information in each storage unit is extracted for the first round of logical comparison. According to the data interaction order, the next piece of information is extracted from the first storage unit and the second storage unit in sequence for iterative comparison, so as to eliminate the interference of the rate difference between the first timing signal and the second timing signal on the hardware comparison process.

6. The system according to claim 1, characterized in that, The first communication interface is the APB interface, and the configuration control module receives the test configuration command through the APB interface and realizes the reuse of the top-level interface; The write protocol type and the read protocol type are low-speed serial peripheral protocols, and are configured independently as SPI protocol or I2C protocol respectively; The bridging conversion and caching module is specifically configured to automatically package and convert the transaction-level configuration instructions issued based on the APB interface into underlying data frames that conform to the SPI protocol or the I2C protocol for output.

7. An integration verification method based on multi-protocol bridging, applied to the integration verification system based on multi-protocol bridging as described in any one of claims 1-6, characterized in that, The method includes: The test configuration command is received via the first communication interface, and the test configuration command is parsed to obtain the target address range, data generation rules, specified write protocol type and specified read protocol type; Upon receiving an automated test trigger command, the target access address and the expected data to be written are automatically generated through hardware logic based on the target address range and the data generation rules. Based on the write protocol type, the expected write data is converted into a first timing signal and sent to the target access address of the device under test, and the expected write data is stored in the first storage unit; and based on the read protocol type, a second timing signal is generated to obtain the actual returned data from the target access address, and the actual returned data is stored in the second storage unit. The data in the first storage unit and the second storage unit are extracted sequentially and compared. The verification status indication information of the internal status register is updated according to the comparison result so that the external device can obtain and execute the target screening control action. The read protocol type is the same as or different from the write protocol type.

8. An electronic device, characterized in that, include: The system includes a memory and a processor, which are interconnected. The memory stores computer instructions, and the processor executes these computer instructions to perform the integrated verification method based on multi-protocol bridging as described in claim 7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the integrated verification method based on multi-protocol bridging as described in claim 7.

10. A computer program product, characterized in that, It includes computer instructions for causing a computer to execute the integrated verification method based on multi-protocol bridging as described in claim 7.

Images