Multi-scenario dynamic verification apparatus and method for chip retransmission function

Abstract

The application provides a multi-scene dynamic verification device and method for chip retransmission function. The device comprises a device configuration module for configuring scene parameters; a preprocessing module for receiving data packets sent by a chip to be verified, routing the data packets to corresponding receiving end simulation modules according to link states and mapping relationships, and sending a zero clearing instruction data to the corresponding receiving end simulation modules when it is monitored that the link state changes from reachable to unreachable; one or more receiving end simulation modules configured to process the data packets and generate retransmission response data, and clear the corresponding states maintained in the modules in response to the zero clearing instruction data; a data driving module for sending the retransmission response data back to the chip to be verified; and a verification result comparison module for receiving actual data from the preprocessing module and expected data from the receiving end simulation module, and automatically comparing the actual data with the expected data to output a verification result of the retransmission function of the chip to be verified.

Description

Technical Field

[0001] This application mainly relates to the field of communication technology, and in particular to a multi-scenario dynamic verification device and method for chip retransmission function. Background Technology

[0002] In modern high-performance network switching chips and data center interconnect chips, retransmission mechanisms are a core function ensuring reliable data transmission. They allow the receiver to request the sender to retransmit data when packet loss or errors are detected, achieving lossless networking. This requirement has become particularly urgent and critical in the rapidly developing AI computing networks of recent years. AI training clusters (such as those composed of thousands of GPUs or dedicated AI accelerator cards) rely on high-bandwidth, low-latency, zero-packet-loss interconnects for synchronizing massive amounts of parameters. Any tiny packet loss or transmission error can cause the entire training job to stall, experience a precipitous drop in performance, or even fail, resulting in a huge waste of computing power and time.

[0003] As AI clusters grow in scale and topology complexity, and as protocol stacks diversify (such as DD protocol between nodes and DH protocol from node to host), the design and verification of retransmission functionality becomes extremely challenging. Existing retransmission functionality verification schemes have the following limitations: First, verification environments are typically built for a single scenario, making it difficult to flexibly and quickly adapt to the verification needs of different application scenarios such as "single-chip" and "multi-chip networking," resulting in low platform reusability. Second, most schemes use random packet loss or static error injection, which cannot accurately simulate physical layer faults such as "dynamic instantaneous link disconnection" in real networks, let alone simulate the chain reaction of such faults on the upper-layer retransmission protocol state machine. Third, the verification process relies heavily on manual analysis or has coarse-grained comparisons, making it difficult to quickly and accurately locate the specific faulty queue and logic chip when errors occur in complex multi-queue, multi-destination networking scenarios.

[0004] Therefore, there is an urgent need for a verification scheme that can flexibly simulate multiple scenarios, dynamically inject link faults, and automatically and accurately compare them to ensure the completeness and reliability of the retransmission function design. Summary of the Invention

[0005] The purpose of this invention is to overcome the shortcomings of existing technologies and provide a multi-scenario dynamic verification device and method for chip retransmission functions. This device can be flexibly configured to simulate single-chip and network scenarios, supports receiver simulation for various retransmission protocol types, and achieves closed-loop, automated, and highly reliable verification by dynamically monitoring link status and triggering protocol-level reset and recovery mechanisms.

[0006] To achieve the above objectives, the present invention adopts the following technical solution:

[0007] Firstly, this application provides a multi-scenario dynamic verification device for chip retransmission function. The device is connected to the chip to be verified and includes: a device configuration module for configuring scenario parameters, the scenario parameters including the number and type of receiving simulation modules and a destination chip ID mapping relationship; a preprocessing module for receiving data packets sent by the chip to be verified, maintaining the link status of each link, routing data packets to the corresponding receiving simulation module according to the link status and the mapping relationship, and sending a clearing indication data to the corresponding receiving simulation module when the link status is detected to change from reachable to unreachable; one or more receiving simulation modules... A receiving-end simulation module, connected to the preprocessing module, is configured to simulate protocol behavior according to its configured type, process the data packets and generate retransmission response data, and clear its internally maintained corresponding state in response to the clearing instruction; a data-driven module, connected between the receiving-end simulation module and the chip to be verified, is used to send the retransmission response data back to the chip to be verified; a verification result comparison module is used to receive the actual data from the preprocessing module and the expected data from the receiving-end simulation module, perform automatic comparison, and output the verification result of the retransmission function of the chip to be verified.

[0008] Secondly, this application provides a multi-scenario dynamic verification method for chip retransmission function, comprising: configuring scenario parameters through a device configuration module, the scenario parameters including the number and type of receiving end simulation modules and the destination chip ID mapping relationship; a preprocessing module receiving data packets sent by the chip to be verified, and routing the data packets to the corresponding receiving end simulation modules according to the current link status and the mapping relationship, and mirroring the data packets as actual data; the receiving end simulation modules simulating protocol behavior according to their configured type, processing the data packets to generate retransmission response data, and generating expected data; a data driving module aggregating the retransmission response data generated by each receiving end simulation module and sending it back to the chip to be verified; the preprocessing module monitoring the link status in real time, and when the status changes from reachable to unreachable, sending clearing indication data to the corresponding receiving end simulation module, the receiving end simulation module responding to the clearing indication data and clearing the corresponding status maintained internally; and a verification result comparison module receiving the actual data and the expected data, performing automatic comparison, and outputting the verification result of the retransmission function of the chip to be verified.

[0009] Compared with the prior art, this application has the following advantages:

[0010] This application presents a multi-scenario dynamic verification device and method for chip retransmission functionality. Through a device configuration module, the number, type (e.g., DD / DH), and network mapping relationships of the receiver simulation modules can be flexibly defined. A single device can cover verification needs across all scenarios, from single-chip to complex networks, and from homogeneous to heterogeneous protocols, significantly improving the reusability and deployment efficiency of the verification platform. The preprocessing module monitors and simulates dynamic changes in the link state in real time and can proactively trigger a zeroing instruction when the state changes from reachable to unreachable. This accurately simulates real physical link failures and verifies the complete fault-tolerant recovery link of the retransmission protocol stack, from fault detection and state zeroing to retransmission recovery, with a verification depth far exceeding that of static random error injection. Attached Figure Description

[0011] The accompanying drawings are included to provide a further understanding of this application. They are incorporated into and constitute a part of this application. The drawings illustrate embodiments of this application and, together with this specification, serve to explain the principles of this application.

[0012] Figure 1 This is an architecture block diagram of a multi-scenario dynamic verification device for chip retransmission function in a single-chip scenario according to this application.

[0013] Figure 2 This is an architecture block diagram of a multi-scenario dynamic verification device for chip retransmission function in the networking scenario of this application.

[0014] Figure 3 This is a flowchart of a multi-scenario dynamic verification method for chip retransmission function according to an embodiment of this application. Detailed Implementation

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

[0016] Figure 1 This is an architectural block diagram of a multi-scenario dynamic verification device for chip retransmission function in a single-chip scenario, as described in this application. Figure 1 As shown, a multi-scenario dynamic verification device 100 for chip retransmission function is connected to the chip to be verified. The multi-scenario dynamic verification device 100 includes a device configuration module 1, a preprocessing module 2, a receiver simulation module 3, a data driving module 4, a verification result comparison module 5, and a retransmission configuration module 6.

[0017] Device configuration module 1 is used to configure scenario parameters, including but not limited to the number and type of receiving simulation modules and the target chip ID mapping relationship. Device configuration module 1 is the control center of the verification environment, providing users with an interface for flexibly defining verification scenarios. Through the configuration of this module, the same verification device can quickly switch between different test modes, greatly improving verification efficiency and platform reusability.

[0018] The number of receiver simulation modules 3 can be configured via device configuration module 1. This parameter directly determines the network scale simulated by the verification device. Figure 1 As shown, when the number of receiver simulation modules 3 is one, it is used to simulate a single-chip scenario. In a single-chip scenario, the data sender and receiver are on the same chip. The device simulates communication between various modules or ports within the chip, and all data streams point to the same simulated receiving endpoint, which is used to verify the efficiency and correctness of the on-chip retransmission mechanism.

[0019] like Figure 2 As shown, in a network scenario, the multi-scenario dynamic verification device 200 needs to be configured with multiple receiver simulation modules 3. That is, when multiple receiver simulation modules 3 are configured, this mode is used to simulate a network scenario with multiple interconnected nodes. For example, configuring three receiver simulation modules can construct a simplified network model containing three peer nodes, which can be used to verify the retransmission behavior, flow control fairness, and fault isolation capability of the chip under test in multi-hop, multi-destination communication.

[0020] The device configuration module 1 can also configure the type of the receiver simulation module 3. This parameter is used to simulate heterogeneous endpoint devices in the network. Optionally, the type of receiver simulation module 3 includes, but is not limited to, a first receiver simulation module supporting the DD (Device-to-Device) protocol and a second receiver simulation module supporting the DH (Device-to-Host) protocol. In this embodiment, of the three configured receiver simulation modules, two can be designated as the first receiver simulation module and the other as the second receiver simulation module.

[0021] In this context, the DD protocol represents a protocol for direct communication between devices. In AI computing networks, this can simulate high-speed interconnection and data synchronization communication between GPUs, AI accelerator cards, or switches. The first receiver simulation module simulates this type of endpoint. The DH protocol represents a protocol for communication between a device and the host system. In AI computing networks, this can simulate communication between an AI accelerator card and the host CPU. The second receiver simulation module simulates this type of endpoint.

[0022] The device configuration module 1 can also configure the destination chip ID mapping relationship, which defines how the large logical address space of the chip under test is mapped to a limited number of physical simulation modules. The destination chip ID is the chip ID to which the chip under test will send its data during communication. Assume the chip under test is designed to support up to 1024 logical destination chip IDs (range 0-1023). In a network scenario with 5 receiver simulation modules (assuming they are identified as Chip0 to Chip4), these 1024 logical IDs can be divided and mapped to the 5 receiver simulation modules by configuring mapping rules. An intuitive mapping rule could be uniform interval division:

[0023] Chip0 is responsible for processing packets with destination IDs 0-204;

[0024] Chip1 is responsible for processing packets with destination IDs 205-408;

[0025] Chip2 is responsible for processing packets with destination IDs 409-612;

[0026] Chip3 is responsible for processing packets with destination IDs 613-817;

[0027] Chip4 is responsible for processing packets with destination IDs 818-1023.

[0028] The mapping rules can also be random algorithms such as hashing to simulate more realistic, non-uniform network addressing. This mapping relationship enables the verification device to realistically simulate the scenario of communication between the chip to be verified and a large-scale logic network with a small amount of physical resources, and is one of the core mechanisms supporting "multi-scenario" verification.

[0029] Preprocessing module 2 maintains an independent state machine for each link it manages leading to a specific receiver simulation module. The states of this state machine include, but are not limited to, normal link state, interrupted link state, and degraded link state, each simulating different physical link conditions. The normal link state indicates that the link is physically connected and has excellent signal quality, allowing error-free data transmission. This is the default state after link initialization. The interrupted link state indicates that the link is completely unusable due to physical faults (such as fiber optic cable removal, port power failure, negotiation failure, etc.), and no data can be transmitted. The degraded link state indicates that the link is physically connected, but the signal quality is severely degraded (e.g., high bit error rate). This state is used to simulate unstable links where data may be randomly corrupted or lost.

[0030] When the link is in normal working order, preprocessing module 2 will perform its "intelligent routing" and "data acquisition" functions as usual. All data packets sent to the receiver simulation module associated with this link will be forwarded completely after a configurable transmission delay (to simulate real link latency).

[0031] When a link is in an interrupted state, preprocessing module 2 will discard all data packets attempting to be sent through this link, simulating that data cannot be delivered to the other end. This is also a key condition for triggering "dynamic fault injection and zeroing." The module will immediately execute the zeroing trigger procedure the instant it detects a link state transitioning from a normal or degraded state to an interrupted state.

[0032] When the link is in a degraded state, the preprocessing module 2 can randomly discard or tamper with some data packets destined for that link according to a configurable error rate (e.g., a 1% packet loss rate or bit error rate), thereby simulating intermittent transmission failures caused by an unstable link. Unlike the link interruption state, the link degradation state will not trigger a zeroing indication because it simulates a link that still exists but with poor quality, rather than a complete interruption.

[0033] Based on the real-time maintained link status and the destination chip ID mapping relationship, preprocessing module 2 performs routing decisions. For each data packet from the chip to be verified, the destination chip ID is first extracted from the data packet, the mapping table is consulted to find the target receiving simulation module, and then the link status to that module is checked. Data packets are only forwarded if the link status is normal or degraded; if the link is interrupted, the data packets are silently discarded.

[0034] Secondly, the preprocessing module 2 mirrors all the data packets sent by the chip to be verified and sends them to the verification result comparison module 5 as "actual data".

[0035] The receiver simulation module 3 is a protocol behavior simulator. Each module operates independently, maintaining an independent receiver state machine for each assigned logical queue. This state machine includes fields such as expected sequence number, acknowledgment counter, and queue status. Optionally, the receiver simulation module 3 is configured to: maintain the expected sequence number for each queue; when a data packet is received, determine whether its sequence number is equal to the currently maintained expected sequence number; if equal, increment the expected sequence number, and generate a correct retransmission response when the number of consecutively received data packets reaches a configured threshold; if not equal, immediately generate a retransmission response indicating a reception error.

[0036] Assume a verification scenario: The receiver simulation module Chip0 is responsible for processing data packets with destination IDs in the range of 0-204. According to the configuration, this module needs to maintain the states of queues 0, 2, and 7. The module's protocol behavior parameters are configured with an acknowledgment threshold of 4 (i.e., sending a cumulative acknowledgment after every 4 consecutive correctly received data packets), and enable 5% random packet loss simulation and a zero-acknowledgment response function.

[0037] The following section uses queue 2 as an example to explain its workflow in detail:

[0038] Queue 2 is initially expected to have its sequence number set to the starting value (e.g., 1), the acknowledgment counter is cleared, and the status is active. When the module receives data packet P1 from preprocessing module 2, it first extracts its queue number, sequence number, and payload. Data packet P1 is: {Destination chip ID: 150 (mapped to Chip0), Queue number: 2, Sequence number: 1, Data payload: "Data_A"}.

[0039] If the sequence number of the data packet is exactly equal to the expected sequence number of the current queue, it is determined that the packet was received in the correct order. That is, the sequence number of the data packet = the expected sequence number = 1. Then, the module performs the following operations: increments the expected sequence number (i.e., the expected sequence number is 2, indicating that the next data packet with sequence number 2 is expected to be received), increments the acknowledgment counter, generates an "expected data" record containing key information about the packet, and sends it to the verification result comparison module. The "expected data" is: {Destination chip ID: 150, Queue number: 2, Sequence number: 1, Data payload: "Data_A", Status: Received}.

[0040] Subsequently, after the module receives four data packets consecutively, the acknowledgment counter reaches the preset acknowledgment threshold, generating a cumulative acknowledgment response conforming to the protocol format. This response is sent to the data driver module, which then sends it back to the chip under test, subsequently resetting the acknowledgment counter.

[0041] Suppose the next arriving packet is data packet P6, which skips data packet P5. The sequence number of data packet P6 is checked and found to be 6, while the expected sequence number in queue 2 is 5. This indicates a sequence number discontinuity, suggesting that packet with sequence number 5 was lost. The module immediately generates a receive error response: {Response Type: NACK, Queue Number: 2, Retransmission Sequence Number: 5}. This response is sent to the chip to be verified via the data driver module. Subsequently, a retransmission packet is received, with its sequence number equal to the expected sequence number in queue 2 (5). The retransmission packet is received, and the expected sequence number in queue 2 is updated to 6. In other words, if the sequence number of a data packet is greater than the current expected sequence number, a sequence number discontinuity is determined, suggesting a packet loss. The module will immediately generate a receive error response (e.g., a negative acknowledgment, specifying the missing sequence number) and send it via data driver module 4, while maintaining the expected sequence number and waiting for the retransmission of the lost packet.

[0042] In this application, the preprocessing module 2 allows the user to dynamically and precisely change the state of any link during testing. For example, through test script commands, the link state of Chip2 can be forcibly changed from a normal state to a broken state at a specific moment. When this "from reachable to unreachable" state transition occurs, the preprocessing module 2 immediately generates a structured reset instruction data.

[0043] Specifically, if, according to the configuration, this link carries multiple logical queues, the preprocessing module 2 will generate an independent zeroing instruction for each affected queue, thereby achieving refined simulation and isolation of the fault's impact. During verification device initialization or scenario configuration, the system explicitly knows the binding relationship between each simulated physical link and one or more logical queue numbers. For example, the configuration file might define that Link_2, leading to the receiver simulation module Chip2, carries traffic originating from queues 1, 3, and 5 in the chip to be verified. This binding simulates the situation in a real chip where a single physical network port (corresponding to one link) serves multiple upper-layer logical queues or application traffic through time-division multiplexing or virtual channel technology. Within each receiver simulation module, the desired sequence number is maintained independently on a queue-by-queue basis. This means that Chip2 will maintain independent receiver state machines for queues 1, 3, and 5 respectively. When the preprocessing module detects that Link_2's state changes from normal to interrupted, it does not send a general "link failure" signal to Chip2. Instead, it executes the following refined process: First, the preprocessing module immediately queries its internally stored "link-queue mapping table" to obtain a list of all logical queue numbers associated with Link_2, such as [1, 3, 5]. For each queue number in the list, the preprocessing module generates an independent, structured clearing indication data message. These independent clearing indication messages are sent sequentially or in a controlled timing sequence to the target receiving simulation module Chip2.

[0044] When Chip2 receives the clear instruction data for queue 1, it only clears all the states it maintains for queue 1 (such as resetting the expected sequence number to 0 and stopping the ACK timer for that queue). The states of queues 3 and 5 remain unchanged until they receive the corresponding instructions. This simulates the protocol layer's ability to distinguish between different logical flows on the same physical link. This mechanism creates a critical verification scenario: the chip under test must be able to correctly handle independent "no response" or "state reset" events from different queues on the same link (Link_2). This verifies the correctness of the chip under test's queue management logic, fault isolation capabilities, and queue-based retransmission recovery.

[0045] Traditional methods often simply mark the entire port or the peer end as failed when a link fails, causing all queues to be reset simultaneously. This fails to verify the chip's fine-grained queue management and fault recovery strategies. In summary, this application's multi-queue independent zeroing indication mechanism elevates the simulation of physical layer link failures from coarse-grained port-level to fine-grained queue-level protocol events. It not only simulates the fault phenomenon but also more accurately triggers the corresponding receiver behavior that conforms to the protocol specifications. This provides an indispensable and highly controllable verification infrastructure for validating the retransmission and recovery coordination capabilities of highly reliable AI computing network chips under extremely complex conditions.

[0046] The verification result comparison module 5 is an automated verification decision engine. Its core function is to receive and compare the "actual data" from the preprocessing module 2 with the "expected data" from the simulation modules 3 at each receiving end, and output the verification result.

[0047] Optionally, the verification result comparison module 5 establishes an "actual data pool" and an "expected data pool" using the queue number and the target chip ID as a joint primary key. All data from the preprocessing module 2 and the receiving simulation module 3 are categorized and stored according to this index.

[0048] For example, "actual data" is:

[0049] {Destination Chip ID: 150, Queue Number: 2, Serial Number: 1, Data Payload: "Data_A"};

[0050] The “expected data” is:

[0051] {Destination Chip ID: 150, Queue Number: 2, Serial Number: 1, Data Payload: "Data_A", Status: Received}

[0052] At the test node or at the end of the test, the verification result comparison module compares the two sets of data under each index:

[0053] a) Quantity Comparison: Check whether the actual number of data packets sent matches the expected number of data packets received. The module counts the total number of data packets recorded in the "Actual Data Pool" under this index, and compares it with the total number of data packets recorded in the "Expected Data Pool". Consistency comparison is the basis of verification, aiming to confirm whether all data packets sent by the chip under verification have been correctly received by the expected receiver, without overall packet loss or extra transmission.

[0054] b) Content Comparison: For each pair of data packets with the same index, the content (such as sequence number, data payload, etc.) is compared field by field to ensure complete consistency. For example, assuming the quantity is consistent, the module will perform a precise field-by-field comparison of all data packets with the same index in both data pools, in sequence order. The fields compared include at least: sequence number, data payload, and critical timestamps or verification information. This step is the core of the verification process, ensuring that the content of each received data packet is completely correct and that no bit errors or data tampering have occurred.

[0055] The verification result comparison module outputs a detailed comparison report, clearly indicating whether the verification result is pass or fail. If it fails, it precisely locates the queue and logic chip ID where the error occurred.

[0056] Therefore, the verification result comparison module of this application transforms the traditionally cumbersome and error-prone manual result analysis into a fast, accurate, and traceable automated process through indexed management, dual-dimensional comparison, and structured error reporting. This not only greatly improves verification efficiency, but more importantly, it provides indispensable and precise guidance for quickly diagnosing and repairing deep-seated interaction defects in complex retransmission protocols, making it a key verification link to ensure the high reliability of AI intelligent computing network chips.

[0057] Optionally, the device also includes a retransmission configuration module 6. For example... Figure 2 As shown, multiple retransmission configuration modules 6 correspond one-to-one with each receiver simulation module 3. Each retransmission configuration module is used to independently configure the protocol behavior parameters of its corresponding receiver simulation module. The protocol behavior parameters include at least one of the following: packet drop ratio, correct response threshold, and clear response strategy.

[0058] The retransmission configuration module 6 configures the packet drop rate of its corresponding receiver simulation module 3 to simulate unreliable physical links. By setting different packet loss rates for different receiver simulation modules 3, the adaptive retransmission and flow control performance of the chip under test under different network quality conditions can be verified.

[0059] The retransmission configuration module 6 configures the correct response threshold ratio of its corresponding receiver simulation module 3 to control the frequency of receiver acknowledgment (ACK) message generation. For example, it can be configured to "reply with a cumulative ACK after every 4 successfully received data packets" or "reply with an ACK after every 1 received packet". By setting different thresholds for different modules, the behavior of the chip under test in handling peer devices with different response habits can be tested.

[0060] The retransmission configuration module 6 configures the clearing response strategy of its corresponding receiver simulation module 3, defining the specific reaction method of the receiver module after receiving a clearing instruction from the preprocessing module. The strategy can be configured as follows: a) Silent clearing: Only the internal state is cleared, without sending any response; b) Sending acknowledgment: After clearing the state, a clearing acknowledgment message is sent to the chip under test via the data driver module; c) Delayed response: After clearing the state, an acknowledgment is sent after a delay of several clock cycles to simulate processing delay. This allows verification of the robustness of the chip under test's response and recovery logic to various fault notifications.

[0061] For example, in a verification scenario simulating a five-node AI computing cluster, verifiers can configure five receiver simulation modules using five independent retransmission configuration modules: two slow-responding nodes (high ACK threshold), one unstable node (high packet loss rate), one node that reacts quickly to faults (immediately clears acknowledgments), and one node with standard behavior. Subsequently, by running a unified test stimulus, the fairness, correctness, and robustness of the chip under verification's retransmission, flow control, and fault recovery mechanisms when interacting with this highly heterogeneous network environment can be comprehensively verified.

[0062] This application also provides a multi-scenario dynamic verification method for chip retransmission functions. For example... Figure 3 As shown, the multi-scenario dynamic verification method 300 for chip retransmission function includes:

[0063] Step S31: Configure scene parameters through the device configuration module. Scene parameters include the number and type of receiving simulation modules and the target chip ID mapping relationship.

[0064] Step S32: The preprocessing module receives the data packet sent by the chip to be verified, routes the data packet to the corresponding receiving simulation module according to the current link status and mapping relationship, and mirrors the data packet as the actual data;

[0065] Step S33: The receiver simulation module simulates protocol behavior according to its configured type, processes data packets to generate retransmission response data, and generates expected data;

[0066] Step S34: The retransmission response data generated by the analog modules of each receiving end is aggregated through the data driving module and sent back to the chip to be verified;

[0067] Step S35: The preprocessing module monitors the link status in real time. When the status changes from reachable to unreachable, it sends a clearing indication data to the corresponding receiving simulation module. The receiving simulation module responds to the clearing indication data and clears the corresponding status maintained internally.

[0068] Step S36: The verification result comparison module receives the actual data and the expected data, performs automatic comparison, and outputs the verification result of the retransmission function of the chip to be verified.

[0069] Optionally, in the automatic comparison step, the queue number carried in the data and the target chip ID are used as a joint index to store and compare the actual data and the expected data respectively.

[0070] Optionally, automatic comparison includes: comparing the quantity of actual data with the expected data, and comparing the data content with the same index in both fields.

[0071] This application presents a multi-scenario dynamic verification device and method for chip retransmission functionality. Through a device configuration module, the number, type (e.g., DD / DH), and network mapping relationships of the receiver simulation modules can be flexibly defined. A single device can cover verification needs across all scenarios, from single-chip to complex networks, and from homogeneous to heterogeneous protocols, significantly improving the reusability and deployment efficiency of the verification platform. The preprocessing module monitors and simulates dynamic changes in the link state in real time and can proactively trigger a zeroing instruction when the state changes from reachable to unreachable. This accurately simulates real physical link failures and verifies the complete fault-tolerant recovery link of the retransmission protocol stack, from fault detection and state zeroing to retransmission recovery, with a verification depth far exceeding that of static random error injection.

[0072] Flowcharts are used in this application to illustrate the operations performed by the system according to embodiments of this application. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, various steps can be processed in reverse order or simultaneously. Furthermore, other operations may be added to these processes, or one or more steps may be removed from these processes.

[0073] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions, capable of running on a network device or stored on any available medium. When the computer program product runs on at least one network device, it causes the at least one network device to execute a multi-scenario dynamic verification method for chip retransmission functionality.

[0074] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a network device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the network device to execute a multi-scenario dynamic verification method for chip retransmission functionality.

[0075] Furthermore, it should be noted that the use of terms such as "first" and "second" to define components is merely for the purpose of distinguishing the corresponding components. Unless otherwise stated, these terms have no special meaning and therefore should not be construed as limiting the scope of protection of this application. In addition, although the terminology used in this application is selected from commonly known and used terms, some terms mentioned in this application's specification may have been chosen by the applicant according to his or her judgment, and their detailed meanings are explained in the relevant sections of this description. Moreover, this application should be understood not only through the actual terms used, but also through the meaning implied by each term.

[0076] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present invention.

[0077] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0078] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A multi-scenario dynamic verification device for chip retransmission function, characterized in that, The device is connected to the chip to be verified and includes: The device configuration module is used to configure scene parameters, which include the number and type of receiving simulation modules and the target chip ID mapping relationship. The preprocessing module is used to receive data packets sent by the chip to be verified, maintain the link status of each link, route data packets to the corresponding receiving end simulation module according to the link status and the mapping relationship, and send clearing instruction data to the corresponding receiving end simulation module when the link status is detected to change from reachable to unreachable. One or more receiver simulation modules are connected to the preprocessing module. Each receiver simulation module is configured to simulate protocol behavior according to its configured type, process the data packets and generate retransmission response data, and clear the corresponding state maintained internally in response to the clearing instruction data. A data-driven module, connected between the receiving end simulation module and the chip to be verified, is used to send the retransmission response data back to the chip to be verified. The verification result comparison module is used to receive the actual data from the preprocessing module and the expected data from the receiving end simulation module, and automatically compare them to output the verification result of the retransmission function of the chip to be verified. The receiving simulation module maintains the receiving status in units of queues, and the verification result comparison module uses the queue number carried in the data packet and the destination chip ID as a joint index to store and compare the actual data and the expected data respectively.

2. The apparatus as claimed in claim 1, characterized in that, When a link becomes unreachable, if the preprocessing module determines that the link is associated with multiple queues, it generates and sends independent clearing instruction data for each associated queue.

3. The apparatus as described in claim 1, characterized in that, The actual data is the data packet received and mirrored by the preprocessing module from the chip to be verified; the expected data is the data information generated by the receiving simulation module after processing the data packet according to the protocol rules, which is used to characterize that it should be correctly received.

4. The apparatus as claimed in claim 1, characterized in that, The automatic comparison includes: comparing the quantity of the actual data with the quantity of the expected data, and comparing the data content with the same index in both fields.

5. The apparatus as claimed in claim 1, characterized in that, The verification scenarios configured by the device configuration module include single-chip scenarios and network scenarios; The types of receiver simulation modules include a first receiver simulation module that supports the DD protocol and a second receiver simulation module that supports the DH protocol.

6. The apparatus as claimed in claim 1, characterized in that, Also includes: Multiple retransmission configuration modules are provided, each corresponding to one of the receiver simulation modules. Each retransmission configuration module is used to independently configure the protocol behavior parameters of its corresponding receiver simulation module. The protocol behavior parameters include at least one of the following: packet drop ratio, correct response threshold, and clear response strategy.

7. The apparatus as claimed in claim 1, characterized in that, The receiver simulation module is configured as follows: Maintain the expected sequence number for each queue; When the data packet is received, determine whether its sequence number is equal to the currently maintained expected sequence number; If equal, the expected sequence number is incremented, and when the number of continuously received data packets reaches the configured threshold, a correct retransmission response data is generated. If the values ​​are not equal, a retransmission response for a reception error will be generated immediately.

8. The apparatus as claimed in claim 1, characterized in that, The preprocessing module maps the logical destination chip ID in the data packet to the physical identifier of the corresponding receiving simulation module inside the verification device, based on the destination chip ID mapping relationship.

9. A multi-scenario dynamic verification method for chip retransmission function, applied to the apparatus as described in any one of claims 1 to 8, characterized in that, include: The scene parameters are configured through the device configuration module. The scene parameters include the number and type of the receiving end simulation modules and the target chip ID mapping relationship. The preprocessing module receives the data packets sent by the chip to be verified, routes the data packets to the corresponding receiving simulation module according to the current link status and the mapping relationship, and mirrors the data packets as the actual data. The receiving end simulation module simulates protocol behavior according to its configured type, processes the data packet to generate retransmission response data, and generates expected data; The data-driven module aggregates the retransmission response data generated by the simulation modules of each receiving end and sends it back to the chip to be verified. The preprocessing module monitors the link status in real time. When the status changes from reachable to unreachable, it sends a clearing indication data to the corresponding receiving simulation module. The receiving simulation module responds to the clearing indication data and clears the corresponding status maintained internally. The verification result comparison module receives the actual data and the expected data, performs automatic comparison, and outputs the verification result of the retransmission function of the chip to be verified. The receiving simulation module maintains the receiving status in units of queues. In the automatic comparison step, the queue number carried in the data packet and the destination chip ID are used as a joint index to store and compare the actual data and the expected data.

10. The method as described in claim 9, characterized in that, The automatic comparison includes: comparing the quantity of the actual data with the quantity of the expected data, and comparing the data content with the same index in both fields.

Images