Aurora bus communication method based on chip testing machine

Abstract

The invention belongs to the technical field of chip testing, and particularly relates to an Aurora bus communication method based on a chip testing machine, which comprises the following steps: S1, building and initializing a system architecture: deploying a hardware architecture of PC + FPGA master control + multi-FPGA functional modules, and establishing a high-speed serial communication link among the modules through an Aurora bus; after the test machine is powered on, the PC terminal collects in-place states of all the FPGA function modules through a special instruction, distributes a unique attribute identifier for each FPGA function module in combination with a board card model and slot position information, and completes hardware readiness and identity calibration before communication; aurora bus parallel communication and FPGA distributed architecture are adopted, the multi-station test duration is not linearly increased along with the number of stations any more, and compared with a traditional PCIe bus scheme, the test efficiency is improved, and the efficient test requirement of large-scale chip production can be met; the communication performance is obviously optimized, and the communication time delay of the system is reduced by more than 50% by combining the characteristic of simplification of an Aurora bus protocol with the hardware acceleration capability of the FPGA.

Description

Technical Field

[0001] This invention belongs to the field of chip testing technology, specifically an Aurora bus communication method based on a chip testing machine. Background Technology

[0002] Chip testing machines are core testing equipment in the chip industry chain, widely used in all stages of chip R&D and mass production. They are mainly used to verify key indicators such as chip function, performance, and stability. The equipment sends test commands and collects test data through a bus communication link. It is a key link in screening out unqualified chips and ensuring product yield, and directly affects chip production efficiency and quality control.

[0003] In the current environment, multi-station testing scenarios of chip testers mostly use the PCIe bus as the core communication bus. Its typical working mode is to send test commands through point-to-point communication and receive the chip test results from each station in sequence to complete the entire test process.

[0004] The following problems exist in the existing technology: 1. Low efficiency of multi-station parallel testing: In point-to-point communication mode, test commands need to be sent to each station in sequence, and test results also need to be sent back to the control terminal one by one. It is impossible to realize synchronous data interaction between multiple stations. As the number of test stations increases, the total test time will increase linearly, which is difficult to meet the high-efficiency testing requirements of large-scale chip production. II. Insufficient Bus Adaptability and Communication Performance: The protocol architecture of the PCIe bus contains many additional functional modules, resulting in significant protocol overhead and directly increasing communication latency. Its routing mechanism is constrained by standardized protocols, and its flexibility in route adjustment during multi-station parallel communication is insufficient, making it impossible to dynamically optimize data transmission paths based on the distribution of test nodes. At the same time, the bandwidth allocation adopts a fixed priority mechanism, which has poor adaptability to the dynamic bandwidth requirements of multi-node synchronous testing, easily leading to situations where some workstations have redundant bandwidth and others have insufficient bandwidth, further restricting the improvement of testing efficiency. Third, the difficulty in controlling testing costs: Due to low communication efficiency and high latency, the time cost in the chip testing process increases significantly. In order to alleviate the bottleneck of multi-station testing, existing solutions often require additional hardware equipment or optimized configuration, which indirectly increases the deployment and maintenance costs of the testing system and is not conducive to cost control in the chip production process.

[0005] Therefore, the present invention provides an Aurora bus communication method based on a chip tester. Summary of the Invention

[0006] In order to overcome the shortcomings of the prior art, at least one technical problem raised in the background art is solved.

[0007] The technical solution adopted by this invention to solve its technical problem is: an Aurora bus communication method based on a chip tester, which includes the following steps: S1. System Architecture Setup and Initialization: The hardware architecture consists of a PC, an FPGA main controller, and multiple FPGA functional modules. A high-speed serial communication link between the modules is established through the Aurora bus. After the test machine is powered on, the PC collects the on-site status of all FPGA functional modules through dedicated instructions. Combined with the board model and slot information, a unique attribute identifier is assigned to each FPGA functional module to complete the hardware readiness and identity verification before communication. S2. Test task configuration and result request initiation: The PC acts as the control center, pre-configuring chip test parameters and initiating specific test tasks. After each FPGA functional module completes the test execution, the PC sends a request for results command to the FPGA main control module, formally triggering the test data collection process. S3. Generation of the Expectation Matrix and Broadcasting of Requests: After receiving the result request from the PC, the FPGA main control module generates an expectation matrix, which clearly records the test data entries that each FPGA functional module should return, serving as the benchmark for subsequent data integrity verification. At the same time, based on the request content and the unique attribute identifier of each FPGA functional module, the system embeds the corresponding unique token and token verification rules into the communication data packet, and broadcasts the result request to all target FPGA functional modules via the Aurora bus. S4. Multi-station test execution and data feedback: After receiving the broadcast request, each FPGA functional module retrieves its own completed test data, associates the test results with its own unique attribute identifier and token, and generates a feedback data packet containing a valid token; the feedback data packet is synchronously transmitted back to the FPGA main control module through the Aurora bus to complete the test data output of a single module; S5, Data Reception, Token Verification and Matrix Update: The FPGA main control module continuously monitors the status of the data returned by each FPGA functional module: 1. If no data is received, proceed to timeout check. If the timeout threshold is not exceeded, continue waiting; otherwise, trigger an error message. 2. If data is received, first verify the validity of the token. Invalid data is discarded directly, while valid data is stored in the result matrix, and the integrity status of the matrix is ​​updated in real time. 3. Repeat the above detection and verification process until the data reception judgment of all target modules is completed; S6. Result Integrity Verification and Final Feedback: The FPGA main control module compares the result matrix with the expected matrix in real time to determine whether all the test data that should be returned has been collected. If the matrix is ​​complete, the complete result matrix is ​​sent back to the PC via the Aurora bus. The PC analyzes and stores the data, completing one test loop. If the matrix is ​​not complete, it returns to S5 to continue the data receiving and verification process.

[0008] Preferably, the FPGA main control module continuously monitors the data return status of each FPGA functional module and introduces a dynamic timeout and intelligent retry mechanism: Data reception and preliminary judgment: If data is received, the token validity is first verified; invalid data is discarded directly; valid data is stored in the result matrix, and the integrity status of the matrix is ​​updated in real time. Timeout detection and intelligent retry triggering: If no data is received from a certain module within the preset basic timeout threshold, the system will not immediately report an error, but will instead initiate dynamic timeout assessment; Dynamic timeout assessment: The system calculates a personalized extended timeout based on the module's historical communication performance (such as average response time and historical timeout rate), current bus load (obtained by monitoring bus data traffic and conflict status), and the module's importance weight in this test. During the extended timeout period, the system will send 1-N (configurable number) higher priority data retransmission requests to the unresponsive module, and attach a unique token for this communication in the request to ensure that the module can correctly identify and respond to it. Final timeout handling: If no valid data is received within the extended timeout period, or if the number of retries is exhausted, the module is determined to have lost data or failed to communicate, and only then will the corresponding error reporting mechanism be triggered. The process is repeated: Repeat the above detection, verification, and retry process until all target modules have completed data reception and judgment or all retry mechanisms have been executed successfully.

[0009] Preferably, after receiving the result request from the PC, the FPGA main control module, based on the priority and data type characteristics of the test task, completes the construction of a hierarchical matrix and the generation of a dynamic token, and then broadcasts it through the Aurora bus. Hierarchical construction of the expectation matrix: The system splits the expected matrix into hierarchical submatrices according to the data importance levels preset in the test task; Set differentiated verification weights and integrity thresholds for matrices at different levels, and clarify the verification benchmarks for data at each level; Adaptive dynamic token generation: The token no longer contains only the static attribute identifier of the FPGA module, but instead integrates the module's unique identification code, the ID of this test task, and the feature hash value of the corresponding level of data to generate a dynamic composite token; The system calculates the current communication load of the Aurora bus in real time. If the load is greater than or equal to a preset threshold (e.g., 80%), it automatically adds a communication priority flag to the token. Tokens corresponding to high-priority first-level matrix data can preempt bus resources and complete transmission and verification first. Synchronously generate hierarchical token verification rules: Level 1 matrix tokens require verification of identity + hash value + task ID, while Level 2 / 3 matrix tokens can simplify the verification dimensions, balancing security and verification efficiency; Differentiated broadcast distribution: When broadcasting request data packets via the Aurora bus, priority tags are added to the request instructions corresponding to different matrix levels. The bus scheduling module prioritizes forwarding the result requests of the first-level core matrix to ensure the timeliness of communication of core test data. The data packet includes hierarchical verification rules. After receiving the data, each FPGA functional module can generate a feedback token for the corresponding level of data, reducing the encapsulation and transmission of invalid data.

[0010] Preferably, the system architecture setup and initialization formula in S1 consists of the following: Algorithm formula: ; in, : A unique identifier for an FPGA functional module; A cryptographic hash function; : FPGA module model information; : The physical slot number where the FPGA module is located; The timestamp when the system was powered on; : String concatenation operator.

[0011] Preferably, the test task configuration and result request initiation formula in S2 consists of the following: Algorithm formula: ; in, Test result request data packet; : A unique identifier for the test task; Test configuration parameter set; The hardware information or public key of the FPGA main control module is used to verify the legitimacy of the request source.

[0012] Preferably, the formulas for generating the expectation matrix and requesting broadcasting in S3 are composed of the following: Algorithm Formula 1 (Generation of Expectation Matrix): ; It is a two-dimensional matrix, where each row Representative to Module expectations; Algorithm Formula 2 (Dynamic Token Generation): ; in, :for A unique dynamic token generated by the module; (): A symmetric encryption algorithm; : The ID of the current test task; : The ID of the target FPGA module; : Zhongyu The corresponding row; The session key shared between the FPGA main control module and various functional modules; Final broadcast data packet: .

[0013] Preferably, the multi-station test execution and data feedback formula in S4 consists of the following: Algorithm formula: ; ; in, (): Test execution function inside the FPGA functional module; : The raw test data generated after the module executes the test; : The data packets that the module sends back to the main controller; The module parses its own token from the broadcast packet.

[0014] Preferably, the data reception, token verification, and matrix update formulas in S5 are composed of the following: Algorithm formula: Reception and Preliminary Verification: ; ; Dynamic timeouts and intelligent retries: ; ; ; ; ; ; ; Result matrix update: ; in, : The ID of the task currently being processed by the main control module; : Module historical average response latency; Current Aurora bus load rate; Weighting coefficients; : The result matrix that is updated in real time.

[0015] Preferably, the result integrity verification and final feedback formula in S6 consists of the following: Algorithm formula: ; ; ; ; ; ; ; ; ; ; ; ; ; in, A boolean flag used to determine whether data reception is complete; (): A helper function used to check whether the data type of the returned data is consistent with the expectation; : A list of all faulty modules and their error types.

[0016] The beneficial effects of this invention are as follows: 1. The Aurora bus communication method based on a chip tester described in this invention offers a breakthrough improvement in testing efficiency: Utilizing parallel communication via the Aurora bus and a distributed FPGA architecture, the testing time for multiple workstations no longer increases linearly with the number of workstations. Compared to traditional PCIe bus solutions, this method significantly improves testing efficiency and meets the high-efficiency testing requirements of large-scale chip production. Communication performance is significantly optimized: The simplified Aurora bus protocol, combined with FPGA hardware acceleration capabilities, reduces system communication latency by more than 50%. Bandwidth utilization increases dramatically with the number of test workstations compared to traditional solutions, perfectly adapting to the high real-time requirements of multi-node synchronous testing. System reliability and fault tolerance are enhanced: Through timeout protection, data token mechanisms, and result expectation matrix design, system stagnation caused by single workstation failures is effectively avoided, significantly improving the stability of the testing system and reducing the probability of test interruptions in abnormal scenarios. Cost control is significantly advantageous: High-efficiency multi-workstation testing can be achieved without adding a large amount of additional hardware resources, reducing the deployment and maintenance costs of the testing system. Simultaneously, it shortens the chip production cycle, indirectly reducing chip time costs and production losses.

[0017] 2. The Aurora bus communication method based on a chip tester described in this invention, through intelligent retry and dynamic timeout, enables the system to better cope with instantaneous communication failures or module processing delays, thereby acquiring more data that might otherwise be lost due to strict timeouts; at the same time, it makes the communication process more tolerant to environmental interference and module performance fluctuations, and also avoids unnecessary interruptions or restarts of the entire test process due to slight delays in individual modules, thus improving overall test efficiency. Attached Figure Description

[0018] The invention will now be further described with reference to the accompanying drawings.

[0019] Figure 1 This is a system hardware architecture diagram of the present invention; Figure 2 This is the core workflow closed-loop diagram in this invention; Figure 3 This is a flowchart of the token generation and verification process in this invention. Detailed Implementation

[0020] To make the technical means, creative features, objectives and effects of this invention easier to understand, the invention will be further described below in conjunction with specific embodiments.

[0021] like Figures 1 to 3 As shown in the embodiment of the present invention, an Aurora bus communication method based on a chip tester includes the following steps: S1. System Architecture Setup and Initialization: The hardware architecture consists of a PC, an FPGA main controller, and multiple FPGA functional modules. A high-speed serial communication link between the modules is established through the Aurora bus. After the test machine is powered on, the PC collects the on-site status of all FPGA functional modules through dedicated instructions. Combined with the board model and slot information, a unique attribute identifier is assigned to each FPGA functional module to complete the hardware readiness and identity verification before communication. S2. Test task configuration and result request initiation: The PC acts as the control center, pre-configuring chip test parameters (such as test standards, data acquisition thresholds, etc.) and initiating specific test tasks. After each FPGA functional module completes the test execution, the PC sends a request for results command to the FPGA main control module, formally triggering the test data collection process. S3. Generation of the Expectation Matrix and Broadcasting of Requests: After receiving the result request from the PC, the FPGA main control module generates an expectation matrix, which clearly records the test data entries that each FPGA functional module should return, serving as the benchmark for subsequent data integrity verification. At the same time, based on the request content and the unique attribute identifier of each FPGA functional module, the system embeds the corresponding unique token and token verification rules into the communication data packet, and broadcasts the result request to all target FPGA functional modules via the Aurora bus. S4. Multi-station test execution and data feedback: After receiving the broadcast request, each FPGA functional module retrieves its own completed test data, associates the test results with its own unique attribute identifier and token, and generates a feedback data packet containing a valid token; the feedback data packet is synchronously transmitted back to the FPGA main control module through the Aurora bus to complete the test data output of a single module; S5, Data Reception, Token Verification and Matrix Update: The FPGA main control module continuously monitors the status of the data returned by each FPGA functional module: 1. If no data is received, proceed to timeout check. If the timeout threshold is not exceeded, continue waiting; otherwise, trigger an error message. 2. If data is received, first verify the validity of the token. Invalid data is discarded directly, while valid data is stored in the result matrix, and the integrity status of the matrix is ​​updated in real time. 3. Repeat the above detection and verification process until the data reception judgment of all target modules is completed; S6. Result Integrity Verification and Final Feedback: The FPGA main control module compares the result matrix with the expected matrix in real time to determine whether all test data that should be returned has been collected (matrix alignment). If the matrix is ​​aligned, the complete result matrix is ​​sent back to the PC via the Aurora bus. The PC analyzes and stores the data, completing one test loop. If the matrix is ​​not aligned, the process returns to S5 to continue the data reception and verification process.

[0022] Bus selection optimization: Abandoning the traditional PCIe bus, the Aurora bus is adopted to achieve high-speed serial communication. Its simplified protocol, low latency and flexible routing characteristics solve the communication bottleneck of multi-station parallel testing.

[0023] Architecture design optimization: It adopts a multi-functional FPGA distributed architecture with a single main controller, which is naturally adapted to multi-station parallel testing scenarios and improves testing efficiency through hardware-level parallelism.

[0024] Process control optimization: The design incorporates a triple control logic of expectation matrix, token mechanism, and timeout protection to ensure the synchronization and integrity of data across multiple workstations while preventing overall process blockage due to anomalies at individual workstations.

[0025] like Figures 1 to 3 The aforementioned FPGA main control module continuously monitors the data return status of each FPGA functional module and introduces a dynamic timeout and intelligent retry mechanism: Data reception and preliminary judgment: If data is received, the token validity is first verified; invalid data is discarded directly; valid data is stored in the result matrix, and the integrity status of the matrix is ​​updated in real time. Timeout detection and intelligent retry triggering: If no data is received from a certain module within the preset basic timeout threshold, the system will not immediately report an error, but will instead initiate dynamic timeout assessment; Dynamic timeout assessment: The system calculates a personalized extended timeout based on the module's historical communication performance (such as average response time and historical timeout rate), current bus load (obtained by monitoring bus data traffic and conflict status), and the module's importance weight in this test. During the extended timeout period, the system will send 1-N (configurable number) higher priority data retransmission requests to the unresponsive module, and attach a unique token for this communication in the request to ensure that the module can correctly identify and respond to it. Final timeout handling: If no valid data is received within the extended timeout period, or if the number of retries is exhausted, the module is determined to have lost data or failed to communicate. Only then will the corresponding error reporting mechanism be triggered (such as marking it as missing data or communication failure in the result matrix and notifying the PC). The process is repeated: Repeat the above detection, verification, and retry process until all target modules have completed data reception and judgment or all retry mechanisms have been executed successfully. Through intelligent retries and dynamic timeouts, the system can better cope with momentary communication failures or module processing delays, thereby acquiring more data that might otherwise be lost due to strict timeouts. At the same time, it makes the communication process more tolerant of environmental interference and module performance fluctuations, and avoids unnecessary interruptions or restarts of the entire test process due to slight delays in individual modules, thus improving overall test efficiency.

[0026] like Figures 1 to 3 After receiving the result request from the PC, the FPGA main control module, based on the priority and data type characteristics of the test task, completes the hierarchical matrix construction and dynamic token generation, and then broadcasts it down via the Aurora bus. Hierarchical construction of the expectation matrix: The system splits the expected matrix into hierarchical sub-matrices (first-level core matrix, second-level auxiliary matrix, and third-level redundancy matrix) based on the data importance level preset by the test task (e.g., core function test data is level 1, power consumption auxiliary data is level 2, and log data is level 3). Set differentiated verification weights and integrity thresholds for different levels of matrices (e.g., first-level matrices require 100% data collection, second-level matrices allow ≤5% missing data, and third-level matrices only record data without affecting the overall process), and clarify the verification benchmarks for data at each level; Adaptive dynamic token generation: The token no longer contains only the static attribute identifier of the FPGA module, but instead integrates the module's unique identification code, the ID of this test task, and the feature hash value of the corresponding level of data to generate a dynamic composite token; The system calculates the current communication load of the Aurora bus in real time. If the load is greater than or equal to a preset threshold (e.g., 80%), it automatically adds a communication priority flag to the token. Tokens corresponding to high-priority first-level matrix data can preempt bus resources and complete transmission and verification first. Synchronously generate hierarchical token verification rules: Level 1 matrix tokens need to verify identity + hash value + task ID, while Level 2 / 3 matrix tokens can simplify the verification dimensions (such as only verifying identity + task ID), balancing security and verification efficiency; Differentiated broadcast distribution: When broadcasting request data packets via the Aurora bus, priority tags are added to the request instructions corresponding to different matrix levels. The bus scheduling module prioritizes forwarding the result requests of the first-level core matrix to ensure the timeliness of communication of core test data. The data packet includes hierarchical verification rules. After receiving the data, each FPGA functional module can generate a feedback token for the corresponding level of data, reducing the encapsulation and transmission of invalid data. The dynamic composite token integrates data feature hash values ​​to verify both the module's identity and the integrity of the data itself, avoiding the risk of legitimate identity but data tampering / abnormality; the hierarchical matrix can accurately locate core data anomalies, solving the problem of full matrix verification focusing on the entire dataset while neglecting core data. By dynamically adjusting the token priority based on bus load, core data is transmitted first, avoiding the core test data from having its bandwidth occupied by auxiliary data under high load, and further reducing communication latency (latency can be reduced by 15%-20% compared to the original solution). The layered verification threshold can be flexibly configured according to different chip testing scenarios (such as mass production sampling inspection and R&D full-function testing), solving the adaptability problem of the traditional general matrix with one-size-fits-all approach, and adapting to the differentiated needs of different testing tasks. This mechanism upgrades static identity verification to dynamic feature verification and full matrix verification to hierarchical priority verification, breaking through the industry's conventional design where tokens only serve as identity identifiers and matrices only record the full data, thus forming an original technical solution. The newly added adaptive dynamic token and matrix hierarchical verification mechanism complements the dynamic timeout and intelligent retry mechanism added in the fifth step: the former optimizes communication efficiency and security from the data generation-distribution stage, while the latter optimizes fault tolerance and robustness from the data reception-verification stage. Together, they constitute the core innovation of differentiated and intelligent management and control throughout the entire process, significantly enhancing the inventiveness and novelty of the invention patent, and distinguishing it from the single-dimensional and static management and control communication methods in the existing technology. The newly added adaptive dynamic token and matrix hierarchical verification mechanism complement the previously added dynamic timeout and intelligent retry mechanism: the former optimizes communication efficiency and security from the data generation-distribution stage, while the latter optimizes fault tolerance and robustness from the data reception-verification stage. Together, they constitute the core innovation of differentiated and intelligent management and control throughout the entire process, significantly enhancing the inventiveness and novelty of the invention patent, and distinguishing it from the single-dimensional and static management and control communication methods in the existing technology.

[0027] like Figures 1 to 3The system architecture setup and initialization formula in S1 above consists of the following: Algorithm formula: ; in, : A unique identifier for an FPGA function module (Function Module Unique ID); A cryptographic hash function, such as SHA-256; : FPGA module model information; : The physical slot number where the FPGA module is located; The timestamp when the system was powered on; : String concatenation operator; This formula generates a unique identifier that is difficult to forge by combining and hashing the module's inherent hardware information (model, slot) with its power-on timestamp. This ID will serve as the basis for all subsequent communication and authentication, ensuring the uniqueness and security of the identity identification during the system initialization phase.

[0028] like Figures 1 to 3 The test task configuration and result request initiation formula in S2 above consists of the following: Algorithm formula: ; in, Test Result Request Packet; : A unique identifier for the test task (Test Task ID); : Test configuration parameter set, for example, P_Config={VDD,Frequency,Test_Pattern}; The hardware information or public key of the FPGA main control module is used to verify the legitimacy of the request source. This formula defines a structured request data packet; Used to uniquely identify a test task throughout the entire communication process; It contains all the parameters required to perform the test; This provides source authentication for the request, ensuring that the request indeed comes from an authorized PC.

[0029] like Figures 1 to 3 The formulas for generating the expectation matrix and requesting broadcasting in S3 above are composed of the following: Algorithm Formula 1 (Generation of Expectation Matrix): ; It is a two-dimensional matrix, where each row Representative to Module expectation: It should return Data of the same type; Algorithm Formula 2 (Dynamic Token Generation): ; in, :for A unique dynamic token generated by the module; (): A symmetric encryption algorithm, such as AES; : The ID of the current test task; : The ID of the target FPGA module; : Zhongyu The corresponding row; The session key shared between the FPGA main control module and various functional modules; Final broadcast data packet: ; The FPGA main control module first according to The task requirements in the document are to build It clearly records what data is expected to be received from each module; Then, it is for each module Generate a The token is generated by encrypting the task ID, module ID, and expected matrix row information, ensuring the token's dynamism and uniqueness; each module can only decrypt and process its own token. Finally, the main control module packages the original request, expectation matrix, and all tokens into... It is broadcast out via the Aurora bus.

[0030] like Figures 1 to 3 The multi-station test execution and data feedback formula in S4 above consists of the following: Algorithm formula: ; ; in, (): Test execution function inside the FPGA functional module; : The raw test data generated after the module executes the test; : The data packets that the module sends back to the master controller. The module parses its own token from the broadcast packet; Each functional module received After that, first through Filter out what belongs to you Then, use the shared key. Decryption , obtain and It then verifies that the information matches the information in the broadcast packet; after successful verification, the module executes... The `()` function is used for testing to obtain data. Finally, With your own ID, task ID and Packaged together It is then sent back to the main control module.

[0031] like Figures 1 to 3 The formulas for data reception, token verification, and matrix update in S5 above consist of the following: Algorithm formula: Reception and Preliminary Verification: ; ; Dynamic timeouts and intelligent retries: ; ; ; ; ; ; ; Result matrix update: ; in, : The ID of the task currently being processed by the main control module; : Module historical average response latency; : Current Aurora bus load rate (0-1); Weighting coefficients are used to adjust the impact of historical latency and current load on timeout. Result Matrix (updated in real time) The main control module received Next, a strict identity and task matching verification is performed; for modules that fail to return data on time, the system will calculate a dynamic timeout period based on their historical performance and current bus status. It then initiates an intelligent retry mechanism; only when the number of retries is exhausted and no data is received is it marked as an error. Verified data will be filled in. The corresponding position in the matrix enables real-time updates of the result matrix.

[0032] like Figures 1 to 3 The formula for result integrity verification and final feedback in S6 above consists of the following: Algorithm formula: ; ; ; ; ; ; ; ; ; ; ; ; ; in, A boolean flag used to determine whether data reception is complete; (): A helper function used to check whether the data type of the returned data is consistent with the expectation; : A list of all faulty modules and their error types; The algorithm iterates through a loop. ,and The system searches for the corresponding entry and performs dual validation of its status and data type; if all entries meet the expectations, it is determined to be... = The successful results and the complete Send to PC; if verification fails, the system will decide, according to the preset strategy, whether to return to S5 to continue waiting / retry, or to directly return an incomplete result with error information to PC and end the task.

[0033] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the claimed invention.

Claims

1. A method for Aurora bus communication based on a chip tester, characterized by: The method includes the following steps: S1. System Architecture Setup and Initialization: The hardware architecture deploys a PC, an FPGA main controller, and multiple FPGA functional modules. A high-speed serial communication link is established between the modules through the Aurora bus. After the test machine is powered on, the PC collects the on-site status of all FPGA functional modules through dedicated instructions. Combining the board model and slot information, a unique attribute identifier is assigned to each FPGA functional module to complete the hardware readiness and identity verification before communication. S2. Test task configuration and result request initiation: The PC acts as the control center, pre-configuring chip test parameters and initiating specific test tasks. After each FPGA functional module completes the test execution, the PC sends a request for results command to the FPGA main control module, formally triggering the test data collection process. S3. Generation of the Expectation Matrix and Broadcasting of Requests: After receiving the result request from the PC, the FPGA main control module generates an expectation matrix, which clearly records the test data entries that each FPGA functional module should return, serving as the benchmark for subsequent data integrity verification. At the same time, based on the request content and the unique attribute identifier of each FPGA functional module, the system embeds the corresponding unique token and token verification rules into the communication data packet, and broadcasts the result request to all target FPGA functional modules via the Aurora bus. S4. Multi-station test execution and data feedback: After receiving the broadcast request, each FPGA functional module retrieves its own completed test data, associates the test results with its own unique attribute identifier and token, and generates a feedback data packet containing a valid token; the feedback data packet is synchronously transmitted back to the FPGA main control module through the Aurora bus to complete the test data output of a single module; S5, Data Reception, Token Verification and Matrix Update: The FPGA main control module continuously monitors the status of the data returned by each FPGA functional module:

1. If no data is received, proceed to timeout check. If the timeout threshold is not exceeded, continue waiting; otherwise, trigger an error message.

2. If data is received, first verify the validity of the token. Invalid data is discarded directly, while valid data is stored in the result matrix, and the integrity status of the matrix is ​​updated in real time.

3. Repeat the above detection and verification process until the data reception and judgment of all target modules are completed; S6. Result Integrity Verification and Final Feedback: The FPGA main control module compares the result matrix with the expected matrix in real time to determine whether all the test data that should be returned has been collected. If the matrix is ​​complete, the complete result matrix is ​​sent back to the PC via the Aurora bus. The PC analyzes and stores the data, completing one test loop. If the matrix is ​​not complete, it returns to S5 to continue the data receiving and verification process.

2. The method of claim 1, wherein: The FPGA main control module continuously monitors the data return status of each FPGA functional module and introduces a dynamic timeout and intelligent retry mechanism: Data reception and preliminary judgment: If data is received, first verify the validity of the token; Invalid data is discarded directly; valid data is stored in the result matrix, and the integrity status of the matrix is ​​updated in real time. Timeout detection and intelligent retry triggering: If no data is received from a certain module within the preset basic timeout threshold, the system will not immediately report an error, but will instead initiate dynamic timeout assessment; Dynamic timeout assessment: The system calculates a personalized extended timeout based on the module's historical communication performance, current bus load, and the module's importance weight in this test; During the extended timeout period, the system will send 1-N higher priority data retransmission requests to the unresponsive module, and attach a unique token for this communication in the request to ensure that the module can correctly identify and respond to it. Final timeout handling: If no valid data is received within the extended timeout period, or if the number of retries is exhausted, the module is determined to have lost data or failed to communicate, and only then will the corresponding error reporting mechanism be triggered. The process is repeated: Repeat the above detection, verification, and retry process until all target modules have completed data reception and judgment or all retry mechanisms have been executed successfully.

3. The Aurora bus communication method based on a chip tester according to claim 1, characterized in that: After receiving the result request from the PC, the FPGA main control module, based on the priority and data type characteristics of the test task, completes the hierarchical matrix construction and dynamic token generation, and then broadcasts it down via the Aurora bus. Hierarchical construction of the expectation matrix: The system splits the expected matrix into hierarchical submatrices according to the data importance levels preset in the test task; Set differentiated verification weights and integrity thresholds for matrices at different levels, and clarify the verification benchmarks for data at each level; Adaptive dynamic token generation: The token no longer contains only the static attribute identifier of the FPGA module, but instead integrates the module's unique identification code, the ID of this test task, and the feature hash value of the corresponding level of data to generate a dynamic composite token; The system calculates the current communication load of the Aurora bus in real time. If the load is greater than or equal to the preset threshold, it automatically adds a communication priority flag to the token. The token corresponding to the first-level matrix data with higher priority can preempt bus resources and complete the transmission and verification first. Synchronously generate hierarchical token verification rules: Level 1 matrix tokens need to verify identity, hash value and task ID, while Level 2 / 3 matrix tokens can simplify the verification dimensions, balancing security and verification efficiency; Differentiated broadcast distribution: When broadcasting request data packets via the Aurora bus, priority tags are added to the request instructions corresponding to different matrix levels. The bus scheduling module prioritizes forwarding the result requests of the first-level core matrix to ensure the timeliness of communication of core test data. The data packet includes hierarchical verification rules. After receiving the data, each FPGA functional module can generate a feedback token for the corresponding level of data, reducing the encapsulation and transmission of invalid data.

4. The Aurora bus communication method based on a chip tester according to claim 1, characterized in that: The system architecture setup and initialization formula in S1 consists of the following: Algorithm formula: ； in, : A unique identifier for an FPGA functional module; A cryptographic hash function; : FPGA module model information; : The physical slot number where the FPGA module is located; The timestamp when the system was powered on; : String concatenation operator.

5. The Aurora bus communication method based on a chip tester according to claim 1, characterized in that: The test task configuration and result request initiation formula in S2 consists of the following: Algorithm formula: ； in, Test result request data packet; : A unique identifier for the test task; Test configuration parameter set; The hardware information or public key of the FPGA main control module is used to verify the legitimacy of the request source.

6. The Aurora bus communication method based on a chip tester according to claim 1, characterized in that: The formulas for generating the expectation matrix and requesting broadcast distribution in S3 are as follows: Algorithm Formula 1 (Generation of Expectation Matrix): ； It is a two-dimensional matrix, where each row Representative to Module expectations; Algorithm Formula 2 (Dynamic Token Generation): ； in, :for A unique dynamic token generated by the module; (): A symmetric encryption algorithm; : The ID of the current test task; : The ID of the target FPGA module; : Zhongyu The corresponding row; The session key shared between the FPGA main control module and various functional modules; Final broadcast data packet: 。 7. The Aurora bus communication method based on a chip tester according to claim 1, characterized in that: The multi-station test execution and data feedback formula in S4 consists of the following: Algorithm formula: ； ； in, (): Test execution function inside the FPGA functional module; : The raw test data generated after the module executes the test; : The data packets that the module sends back to the main controller; The module parses its own token from the broadcast packet.

8. The Aurora bus communication method based on a chip tester according to claim 1, characterized in that: The data reception, token verification, and matrix update formulas in S5 consist of the following: Algorithm formula: Reception and Preliminary Verification: ； ； Dynamic timeouts and intelligent retries: ； ； ； ； ； ； ； Result matrix update: ； in, : The ID of the task currently being processed by the main control module; : Module historical average response latency; Current Aurora bus load rate; Weighting coefficients; : The result matrix that is updated in real time.

9. The Aurora bus communication method based on a chip tester according to claim 1, characterized in that: The formula for result integrity verification and final feedback in S6 consists of the following: Algorithm formula: ； ； ； ； ； ； ； ； ； ； ； ； ； in, A boolean flag used to determine whether data reception is complete; (): A helper function used to check whether the data type of the returned data is consistent with the expectation; : A list of all faulty modules and their error types.

Images