Method for parallel online testing of many-core network-on-chip based on software self-test

Abstract

The application belongs to the technical field of integrated circuit testing, and discloses a kind of online test method for many-core network on chip based on software self-test, comprising the following steps: step 1: using bounded model checking to automatically generate test vector for software self-test method;Step 2: using Monte Carlo simulation method to solve the selection problem of test data packet configuration;Step 3: increase multi-thread mechanism in Monte Carlo simulation process.The application can not only realize high test quality, but also reduce test overhead.In addition, the application carries out online test in the functional mode of many-core network on chip, which can effectively avoid the untestable turn of data packet in the functional mode, thereby avoiding the problem of excessive test.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of integrated circuit testing, and particularly relates to a kind of parallel online test method for thousands of core networks-on-chip based on software self-test. BACKGROUND

[0002] With excellent parallel communication capability, many-core networks-on-chip (NoC) has become a promising architecture in supercomputers. Currently, many research institutions are trying to design thousands of core NoC for the next generation of supercomputers. Thousands of core NoC requires strong robustness and fault tolerance. In actual operation, thousands of core NoC not only needs to be applicable to low fault conditions, but also may face more faults. A feasible solution to this problem is that thousands of core NoC isolates the fault part and reconfigures the resources after online testing, thereby maintaining normal operation. Therefore, online testing is crucial to ensure that the system based on thousands of core NoC runs without errors.

[0003] In existing test methods, although the test method based on automatic test equipment (ATE) can be used in the process of manufacturing many-core networks-on-chip, this method depends on ATE, and ATE is expensive, and also brings invasive hardware, which leads to high test overhead. In addition, the test method based on ATE is an offline test method, so it is not suitable for online testing of thousands of core NoC. The built-in self-test (BIST) method integrates the generation of test vectors and the collection and analysis of test responses into the circuit under test, thereby reducing the dependence on ATE, but the BIST method still needs additional test patterns, so the support for online testing is limited. More seriously, the BIST method needs invasive hardware, which brings high additional test area overhead. Considering the dependence on ATE and non-invasive hardware, the software-based-self-test (SBST) method has been proven to be an efficient NoC test method. However, SBST has limitations when facing a circuit with a large timing depth such as thousands of core NoC. In the face of thousands of core NoC online testing, SBST needs to solve the problem of automatic generation of test data packets, and needs to be able to activate difficult-to-test scenarios in NoC under a large timing depth. In addition, although the SBST method can achieve non-invasive hardware, the data packets used for online testing will occupy the L1 cache of thousands of core NoC, which is a key resource of thousands of core NoC. At the same time, SBST must perform testing during the idle period of thousands of core NoC. Therefore, the SBST method also needs to optimize the storage space and execution time when performing parallel online testing. SUMMARY

[0004] The application aims to provide a software self-test-based thousand-core network-on-chip parallel online test method to solve the above technical problems.

[0005] To solve the above technical problems, the specific technical scheme of the software self-test-based thousand-core network-on-chip parallel online test method is as follows:

[0006] A software self-test-based thousand-core network-on-chip online test method, comprising the following steps:

[0007] Step 1: using bounded model checking to automatically generate test vectors for the software self-test method;

[0008] Step 2: using a Monte Carlo simulation method to solve the selection problem of test data packet configuration;

[0009] Step 3: adding a multi-thread mechanism in the Monte Carlo simulation process.

[0010] Further, the software self-test method of the bounded model checking of step 1 comprises the following steps:

[0011] First step: extracting an EFSM model from the RTL design file of the thousand-core NoC routing node, and at the same time, taking the test scenarios to be covered by the BSBST as an attribute set P E and P F and storing them into a database;

[0012] Second step: the BSBST checks whether there is an unverified attribute in the database, if there is, the BSBST acquires an unverified attribute from the database and then proceeds to the next step; otherwise, if there is not, the BSBST terminates the process;

[0013] Third step: the BSBST reduces the scale of the model to alleviate the state space explosion problem;

[0014] Fourth step: the BSBST verifies the given attribute using a BMC tool; if the tool cannot give a guide sequence, the BSBST considers that the given attribute is not testable in the functional mode, at which time it returns to the second step; otherwise, if the tool gives a corresponding guide sequence, the BSBST proceeds to the next step;

[0015] Fifth step: if the verified attribute belongs to the set P E , the BSBST takes the input signal sequence in the guide sequence at this time as a test vector for activating the attribute p; otherwise, if the verified attribute belongs to the set P F , the BMC fixes the model to the time range in which a state update occurs and imposes the guide sequence, and then the BSBST generates a test vector for the fault activated during the state update using ATPG under the constraint.

[0016] Step 6: BSBST maps the test vectors to the SBST procedure and returns to step 2 of the entire process, repeating the above process.

[0017] Furthermore, step 2 involves developing a high-level simulator using the C language for the 1000-core NoC. This simulator is based on the Herms routing node design, retaining necessary variables in the 1000-core NoC while reducing many low-level details. The simulator also performs buffer and switch functions, and its results maintain consistent periodic accuracy with the gate-level netlist simulation results. Additionally, a high-level evaluation method for test packet configuration, cov=N, is provided. scen / sum scen and The former describes how the test coverage rate (cov) is calculated. The numerator represents the untested scenarios that the current packet configuration can cover, and the denominator represents the total number of test scenarios that need to be covered. The latter gives the objective formula for evaluating the current configuration. The numerator is the test coverage rate (cov), and the denominator is the product of the two parts. The former is the square root of the sum of the micro-slices in the test packet configuration, and the latter is the completion time (time) after adding the current test packet configuration to the 1000-core on-chip network. cur Compared to the time before this configuration was added pre The ratio of .

[0018] Furthermore, step 2 uses Monte Carlo simulation to search for an approximate optimal configuration within a large range of random spaces, including the following steps:

[0019] Step 1: When the 1000-core NoC can inject test data packets, the Monte Carlo simulation method at the current time T... s Execute random test data packet configuration generation, generating N rc Group random test data packet configuration;

[0020] Step 2: Place all data packets under each configuration into the high-level simulator for simulation and run until all data packets in the simulator have been transmitted, and record the termination time T at this point. e Monte Carlo simulations employ high-level evaluation methods to calculate target values ​​for different configurations.

[0021] The third step is to select N. rc The maximum target value and corresponding configuration of the group of random test data packets;

[0022] Fourth step: compare the current maximum target value with the target value obtained by the previous best configuration, check whether the current optimal configuration improves the historical optimal configuration; if improved, update the optimal configuration at this time, and then continue to execute Monte Carlo simulation; otherwise, if the current optimal configuration does not improve, select the historical optimal configuration as the best test data packet configuration of the current injection kernel NoC.

[0023] Further, the step 3 uses a multi-thread technique to generate the optimal test data packet configuration for the online self-test problem of the kernel NoC, and the parallel test data packet configuration selection method under the multi-thread contains four different types of threads, namely, a master thread, a configuration generation thread, a configuration simulation thread and a configuration statistics thread, the four threads undertake different functions and interact with each other to complete the multi-thread task.

[0024] Further, the configuration generation thread comprises the following steps:

[0025] First step: the configuration generation thread generates a large number of different configuration test data packets in the system and temporarily stores them;

[0026] Second step: when N conf configurations are needed for the current Monte Carlo simulation, the configuration generation thread sets the flags of the existing configurations in the state table to 1, which indicates that these configurations are ready;

[0027] Third step: when the number of ready configurations reaches the number of available threads avail thread supported by the computing platform, the configuration generation thread sends a ready signal to the master thread, at this time, the master thread will notify the configuration simulation thread that the configuration is ready;

[0028] Fourth step: the configuration generation thread needs to wait for the return request signal of the master thread; when the return request signal is obtained, the configuration generation thread delivers N thread test data packet configurations to the configuration simulation thread, and sets the state flags of these configurations in the state table to 2; if N conf configurations have been generated, and the state flags of these configurations are 2, the configuration generation thread will clear the units corresponding to the N conf configurations; otherwise, if the number of configurations delivered to the configuration simulation thread is less than N conf , the configuration generation thread will return to the third step;

[0029] Fifth step: after generating N conf configurations, the configuration generation thread waits for the signal of the master thread; if the iteration signal is received, the configuration generation thread will return to the second step to generate another group of N confthe number of idle input ports N is updated according to the state of the NoC at this time free At this point, the configuration generation thread ends this task and waits for the next call from the master thread.

[0030] Further, the configuration simulation thread comprises the following steps:

[0031] First step: the configuration simulation thread obtains the state information of the current NoC from the master thread, and sends a signal to the master thread to request configuration injection;

[0032] Second step: when receiving the ready confirmation signal returned by the master thread, the configuration simulation thread obtains the avail thread number of test data packet configurations;

[0033] Third step: the configuration simulation thread simulates the avail thread configurations using the NoC high-level simulator, and obtains the test scenario coverage and completion time T thread for each of the avail e configurations during the simulation process; if the completion time of the test data packet configuration is within the idle time allowed by the NoC, the configuration simulation thread calculates the target value of the configuration using the high-level evaluation method; otherwise, if a timeout occurs, the configuration simulation thread directly sets the target value of the corresponding configuration to 0; after that, the configuration simulation thread performs a synchronous update operation to update the target values of all configurations; only when the simulation and evaluation calculation of the avail thread test data packet configurations are completed, the configuration simulation thread transmits the evaluation results of the avail thread configurations to the configuration statistics thread; at this point, the task of the configuration simulation thread in the current stage ends, and it waits for the next call from the master thread.

[0034] Further, the configuration statistics thread comprises the following steps:

[0035] First step: the configuration statistics thread receives the avail thread evaluation results submitted by the configuration simulation thread each time;

[0036] Second step, the configuration statistics thread selects the maximum target value max new and the corresponding test data packet configuration from the avail thread evaluation results;

[0037] Third step: the configuration statistics thread compares max new with the previous maximum target value max tem saved in the temporary memory.comparison is made; if max new is greater than max tem , the configuration statistics thread updates max new with max tem ; otherwise, if max new is less than max conf , max pre is discarded;

[0038] In the fourth step, the configuration statistics thread determines whether the configuration number has reached the total configuration number N conf ; if so, the configuration statistics thread determines whether the maximum target value max pre obtained in the last Monte Carlo simulation iteration exists; if not, the configuration statistics thread updates max tem with max pre ; otherwise, if max pre exists, the configuration statistics thread compares the size of max tem and max pre ; if max tem is greater than max pre , the configuration statistics thread updates max tem with max pre , and records the configuration corresponding to max tem as the optimal configuration at this time, and then sends an iteration signal to the master thread to request the Monte Carlo simulation iteration to continue; if max tem is less than max pre , the configuration statistics thread regards the configuration corresponding to max pre as the final optimal test data packet configuration at this stage and transmits it to the master thread for updating.

[0039] Further, the configuration master thread comprises the following steps:

[0040] In the first step, the master thread starts the configuration generation thread, and transmits the state information of the NoC at this time to the configuration simulation thread;

[0041] In the second step, if the configuration simulation thread sends a request signal and the configuration generation thread sends a ready signal, the master thread schedules the configuration generation thread to import the generated test data packet configuration into the configuration simulation thread;

[0042] In the third step, when all the synchronization operations in the configuration simulation thread are executed, the master thread sends a signal to the configuration statistics thread;

[0043] Step 4: If the iteration signal sent by the configuration statistics thread is received, it indicates that the Monte Carlo simulation needs to be continued, and the master thread sends the iteration signal to the configuration generation thread and the configuration simulation thread to perform the next round of iteration; if the update signal sent by the configuration statistics thread is received, it indicates that the optimal data packet configuration has been obtained, and the master thread stops the Monte Carlo simulation and gives the detailed information of the configuration; in addition, in the configuration simulation thread, if the termination time of the test data packet configuration on the high-level simulator exceeds the idle time allowed by the many-core NoC, the master thread reads the starting state of this round of Monte Carlo simulation, and returns the state information of the many-core NoC to the corresponding time, and clears all temporary variables in the process;

[0044] Step 5: The other three kinds of threads are restarted from the returned NoC state to generate the optimal test data packet configuration in the next idle period; if there is no timeout phenomenon and the optimal test data packet configuration is generated, the master thread simulates the configuration using the high-level simulator until any data packet in the configuration is transmitted to the target routing node, and the time at this moment is recorded as T first ;

[0045] Step 6: The master thread updates the state of the many-core NoC using the state at the time of T first .

[0046] The many-core network-on-chip parallel online testing method based on software self-testing has the following advantages:

[0047] 1. The method of the application proposes a parallel software self-testing method (PSBST) based on bounded model checking, which completes the online testing of the many-core NoC as the research object. PSBST can automatically generate a series of optimal test data packet configurations to complete the online testing of the many-core NoC with high test quality and low test cost.

[0048] 2. The software self-testing method based on bounded model checking proposed by the method of the application can efficiently generate test data packets for each routing node and its key components in the NoC, and each test data packet can cover the buffer on the corresponding routing node and the to-be-tested scene of the feasible steering, and can cover the conflict arbitration scene in the switch under the cooperation of multiple data packets.

[0049] 3. The method of the application develops a high-level simulator and proposes a high-level evaluation method for test data packet configuration, which can greatly reduce the simulation and evaluation time of the test data packet configuration. On this basis, the application uses Monte Carlo simulation to solve the selection problem of the test data packet configuration. This method searches for the approximately optimal configuration in a wide range of random space, which can ensure the test quality and maximize the reduction of test cost.

[0050] 4. The method of the present application uses multi-thread technology to solve the selection problem of test data packet configuration. Through the interaction and cooperation of the four threads of master thread, configuration generation thread, configuration simulation thread and configuration statistics thread, the multi-thread mechanism ensures that the Monte Carlo simulation can select the approximate optimal configuration of the test data packet in a large enough search space, while also reducing the generation time of the test data packet configuration.

[0051] 5. The method of the present application can achieve high test quality and complete the online testing of many-core NoC. At the same time, the method of the present application performs online testing in the functional mode of many-core NoC, which can effectively avoid the untestable transition of data packets in the functional mode, thereby avoiding the problem of over-testing.

[0052] 6. The method of the present application can effectively reduce test overhead without any additional area overhead or expensive automatic test equipment. BRIEF DESCRIPTION OF DRAWINGS

[0053] Figure 1 Flowchart of the software self-test method for delay testing based on bounded model checking;

[0054] Figure 2 Flowchart of the software self-test method based on bounded model checking;

[0055] Figure 3 Flowchart of the high-level simulator simulating data packet transmission;

[0056] Figure 4 Flowchart of the Monte Carlo simulation solving the selection problem of test data packet configuration;

[0057] Figure 5 Flowchart of parallel test data packet configuration selection under multi-thread technology;

[0058] Figure 6 Flowchart of the configuration generation thread;

[0059] Figure 7 Flowchart of the configuration simulation thread;

[0060] Figure 8 Flowchart of the configuration statistics thread;

[0061] Figure 9 Flowchart of the master thread;

[0062] Figure 10 Schematic diagram of the target value change of Monte Carlo iteration;

[0063] Figure 11 Schematic diagram of the number of Monte Carlo simulation iterations and coverage rate;

[0064] Figure 12 Fault coverage plot for different random test data volume;

[0065] Figure 13 Gray scale plot of PSBST in buffer test coverage of many-core NoC;

[0066] Figure 14 Gray scale plot of random test in buffer test coverage of many-core NoC;

[0067] Figure 15 Gray scale plot of PSBST in router node test coverage of many-core NoC;

[0068] Figure 16 Gray scale plot of random test in router node test coverage of many-core NoC;

[0069] Figure 17 Execution time plot of Monte Carlo simulation iteration. DETAILED DESCRIPTION

[0070] In order to better understand the purpose, structure and function of the present application, a many-core network-on-chip parallel online testing method based on software self-testing is described in further detail below in combination with the accompanying drawings.

[0071] I. Related definitions and related indexes

[0072] 1. Related definitions

[0073] Software-based self-testing (SBST): when SBST uses software programs to perform online testing of NoC, the core idea is that the SBST program directly uses NoC to transmit test data packets to activate faults in NoC, and then receives the test response generated by NoC, thereby achieving the purpose of online testing. The test data packets are stored in the functional processing unit of NoC in the form of 01 binary.

[0074] Bounded model checking (BMC): BMC is a very important automatic verification technique. It makes full use of the characteristics of SAT (Satisfiability) solving tools, encodes the BMC problem into a SAT instance, and effectively increases the number of variables in model checking by more than one order of magnitude. It not only can automatically verify the correctness of the proposition in the finite state system, but also can provide a violation of the proposition that does not satisfy the proposition once the proposition is wrong.

[0075] Leading Sequence: The leading sequence refers to the sequence of input signals and variable values of each time slice from the initial configuration of the extended finite state machine to the configuration satisfying the property p, which is used to activate the property p.

[0076] Monte Carlo method: also known as statistical simulation method, random sampling technique, is a numerical calculation method based on random numbers and guided by probability and statistics theory. The method originated from the direct simulation of the random diffusion process of neutrons in the atomic energy industry. With the rapid development of computer technology, modern computers can quickly and effectively perform millions of simulations, which enables the Monte Carlo method to quickly give an approximate solution while ensuring the accuracy of the approximate solution, especially when faced with problems that are too complex to be directly handled.

[0077] 2. Related indicators

[0078] In order to measure the effectiveness of the method of the present application, the following indicators are used for evaluation:

[0079] Fault coverage: The fault coverage is the proportion of the faults detected by the software self-test method to the total number of overall faults. To obtain the fault coverage, the fault simulation is performed using the commercial test vector automatic generation tool TetraMAX, and the fault coverage is obtained.

[0080] Test overhead: including area overhead, use of external test instruments, test data volume and test time.

[0081] II. Principle of the method of the present application

[0082] The present application proposes a software self-test based online test method for a thousand-core network on chip, which can automatically generate a series of optimal test data packet configurations to complete the online test of the thousand-core NoC with high test quality and low test overhead. As shown in Figure 1 The method of the present application comprises the following steps:

[0083] Step 1: Use bounded model checking to automatically generate test vectors for the software self-test method; the present application models the buffer and switch in the routing node of the thousand-core network on chip into a finite state automaton, which can be automatically extracted from the register transfer level design file corresponding to the routing node. The present application uses bounded model checking to extract the leading sequence required to activate the internal function of the state machine. For the faults corresponding to the enable circuit in the routing node, the present application regards the input signal sequence in the leading sequence as the test vector; for the faults corresponding to the timing control circuit, after obtaining the leading sequence, the present application fixes the timing control circuit to the moment when the function transition occurs, and then generates test vectors for the timing circuit by deleting the internal registers and using the test vectors under constraints to automatically generate test vectors.

[0084] As shown in Figure 2 , the BSBST method extracts EFSM model from the RTL design file of the core NoC routing node. At the same time, BSBST stores the test scenarios to be covered as a property set P E and P F into the database. In the second step, BSBST checks whether there are still unverified properties in the database. If yes, BSBST obtains an unverified property from the database and then proceeds to the next step; otherwise, BSBST terminates the process. In the third step, BSBST alleviates the state space explosion problem by reducing the size of the model. In the fourth step, BSBST verifies the given property using the BMC tool. If the tool cannot give a guide sequence, BSBST considers that the given property is not testable in the functional mode, and returns to the second step; otherwise, if the tool gives a corresponding guide sequence, BSBST proceeds to the next step. Next, if the verified property belongs to the set P E , BSBST regards the input signal sequence in the guide sequence at this time as a test vector that activates the property p; otherwise, if the verified property belongs to the set P F , the BMC tool fixes the model to the time range in which the state update occurs and imposes the guide sequence, and then BSBST uses the ATPG under the constraint to generate a test vector for the fault activated during the state update. Finally, BSBST maps the test vector into an SBST program and returns to the second step of the entire process to repeat the above process.

[0085] Step 2: Solve the selection problem of test data packet configuration using the Monte Carlo simulation method.

[0086] After obtaining the test data packet generated by BSBST, the present application solves the selection problem of test data packet configuration using the Monte Carlo simulation method based on a high-level simulator and a high-level evaluation method. First, if simulation and solving are directly performed on the gate-level netlist file of the core NoC, the process will be very time-consuming because the gate-level netlist of the core NoC contains too many underlying details. Second, because EDA tools have strict limitations on parallel computing when simulating faults, the evaluation process of a large number of test data packet configurations will be very long. In response to the above two problems to be solved, the present application develops a high-level simulator using C language for the core NoC. As shown in Figure 3As shown, the simulator is based on the Herms routing node design, which reduces many underlying details while preserving the necessary variables in a NoC, thus ensuring its accuracy and efficiency. The simulator also implements the functions of buffers and switches, and the results are consistent with the cycle accuracy of gate-level netlist simulation. Meanwhile, in order to evaluate the test quality and test overhead of a given test packet configuration, the present application provides a high-level evaluation method cov=N scen / sum scen and The former describes the calculation method of test coverage (cov), and the numerator part represents the current packet configuration that can cover the untested scenarios (N scen ), and the denominator part represents the total test scenarios to be covered (sum scen ). The latter gives the formula for evaluating the objective value of the current configuration, and the numerator is the test coverage (cov), and the denominator is the product of two parts, the former is the square root of the sum of the tiles in the test packet configuration, and the latter is the ratio of the completion time (time cur ) after adding the current test packet configuration to the time (time pre ) before adding the configuration in the NoC.

[0087] Based on the above description, the present application uses Monte Carlo simulation to search for an approximate optimal configuration in a large range of random space. As shown in Figure 4 , the Monte Carlo simulation has the following steps: first, when the NoC can inject test packets, the Monte Carlo simulation method performs random test packet configuration generation at the current time T s , generating N rc groups of random test packet configurations. Second, the method puts all the packets under each configuration into the high-level simulator for simulation, and stops until all the packets in the simulator are transmitted, and records the termination time T e . In this step, the Monte Carlo simulation calculates the objective value of different configurations by the high-level evaluation method. Third, the method selects N rcThe maximum target value of the group random test data packet configuration and the corresponding configuration are configured. Next, the method compares the current maximum target value with the target value obtained by the previous best configuration, checks whether the current best configuration improves the historical best configuration. If it is improved, the method updates the optimal configuration at this time, and then continues to perform Monte Carlo simulation; otherwise, if the current optimal configuration is not improved, the historical optimal configuration is selected as the best test data packet configuration of the current injection kernel NoC. The best test data packet configuration at this time is selected from a large number of random configurations, and in this process, there is no configuration with a larger target value. Therefore, the best test data packet configuration at this time is an approximate optimal solution according to the Monte Carlo simulation principle. It can not only guarantee the test quality, but also maximize the reduction of test overhead.

[0088] Step 3: Increase the multi-thread mechanism in the Monte Carlo simulation process.

[0089] Even if the high-level simulator and the high-level evaluation method described in the foregoing are used, the execution and solution time of the Monte Carlo simulation is still slightly long. The Monte Carlo simulation method itself needs a large number of random trials to ensure that the quality of the obtained solution result is an approximate optimal solution. In order to reduce the iteration time of the Monte Carlo simulation, the present application notices that the starting state of the high-level simulator and the high-level evaluation method is consistent when the Monte Carlo simulation method performs iterations of different test data packet configurations. At the same time, all iteration processes do not interfere with each other, because different test data packet configurations are independent. Therefore, considering that the current computing platform often supports multi-thread programs to improve computing efficiency, the present application further uses a multi-thread technology to generate an optimal test data packet configuration for the online self-test problem of the kernel NoC.

[0090] As shown in Figure 5 , the parallel test data packet configuration selection method under multi-threading mainly includes four different types of threads, which are a master thread, a configuration generation thread, a configuration simulation thread and a configuration statistics thread. The four threads respectively undertake different functions and interact with each other to complete the multi-thread task.

[0091] As shown in Figure 6 , the configuration generation thread mainly has the following steps: first, the configuration generation thread generates a large number of different configuration test data packets in the system and temporarily stores them. Second, when N conf number of configurations are needed for the current Monte Carlo simulation, the configuration generation thread sets the flags of the existing configurations in the state table to 1, which indicates that these configurations are ready. Then, when the ready configurations reach the available thread number (avail threadWhen the configuration generation thread sends a ready signal to the main control thread, the main control thread notifies the configuration simulation thread that the configuration is ready. Next, the configuration generation thread waits for a return request signal from the main control thread. Upon receiving the return request signal, the configuration generation thread will then enable the configuration. thread The number of test data packets configured is passed to the configuration simulation thread, and the status flag of these configurations in the status table is set to 2. If N has already been generated... conf When the number of configurations is specified, and the corresponding status flag for these configurations is 2, the configuration generation thread will clear N. conf The number of units corresponding to the configuration is configured; conversely, if the number of configurations passed to the configuration simulation thread is less than N, the configuration quantity is not specified. conf The configuration and generation thread will return to step three. After generating N... conf After configuring the quantity, the configuration generation thread needs to wait for a signal from the main control thread. If an iteration signal is received, the configuration generation thread will return to the second step and regenerate another group N. conf The configuration thread generates a test packet of a certain number of cores. If an update signal is received, the configuration generation thread updates the number N of idle input ports according to the current state of the NoC cores. free At this point, the configuration generation thread finishes its task and awaits the next call from the main control thread.

[0092] like Figure 7 As shown, the configuration simulation thread mainly involves the following steps: First, the configuration simulation thread obtains the current NoC status information from the main control thread and simultaneously sends a signal requesting configuration injection to the main control thread. Second, upon receiving a ready confirmation signal from the main control thread, the configuration simulation thread receives the available information passed from the configuration generation thread. thread Configure the number of test data packets. Next, configure the simulated thread for avail. thread Each configuration was simulated using the NoC high-level simulator, and the avail was obtained during the simulation process. thread The test scenario coverage and completion time (T) for each configuration are as follows: e It is particularly important to note that if the test data packet configuration completion time is within the allowed idle time (period) of the 1000-core NoC, the configuration simulation thread will use the high-level evaluation method to calculate the target value of the configuration; otherwise, if a timeout occurs, the configuration simulation thread will directly set the target value of the corresponding configuration to 0. Afterwards, the configuration simulation thread will perform a synchronous update operation to update the target values ​​of all configurations. This will only happen if and only if avail is completed. thread After the simulation and evaluation calculations for each test data package configuration are completed, the configuration simulation thread will then allocate the available resources. threadThe quantity assessment results are passed to the configuration statistics thread. At this point, the current phase of the configuration simulation thread's task ends, and it awaits the next call from the main control thread.

[0093] like Figure 8 As shown, the configuration statistics thread mainly involves the following steps: First, the configuration statistics thread receives the available data submitted by the configuration simulation thread each time. thread The evaluation results. Then, the configuration statistics thread is set from available. thread The maximum target value (max) is selected from the evaluation results. new ) and its corresponding test data package configuration. Next, the configuration statistics thread will configure max new Compared with the previous maximum target value (max) stored in temporary storage tem ) for comparison. If when max new Greater than max tem The configuration statistics thread will use max new Update max tem Conversely, if it is less than the maximum, then discard it. new Next, the configuration statistics thread will determine whether the number of configurations has reached the total number of configurations N. conf If the target value is reached, the configuration statistics thread will then look for the maximum target value (max) obtained in the previous Monte Carlo simulation iteration. pre Does it exist? If not, the configuration statistics thread will use max. tem Update max pre Conversely, if a max exists... pre The configuration statistics thread will compare with max. tem and max pre The size of max. tem Greater than max pre The configuration statistics thread will use max tem Update max pre and max tem The corresponding configuration record is the optimal configuration at this time, and then an iteration signal is sent to the main control thread to request continued execution of the Monte Carlo simulation iteration; if max tem Less than max pre Configuring the statistics thread will set the max pre The corresponding configuration is considered the final optimal test data package configuration for this stage and is passed to the main control thread for updating.

[0094] like Figure 9As shown, the main thread has the following steps: first, the main thread starts the configuration generation thread, and passes the state information of the NoC to the configuration simulation thread. Next, if the configuration simulation thread sends a request signal and the configuration generation thread sends a ready signal, the main thread schedules the configuration generation thread to import the generated test packet configuration into the configuration simulation thread. Next, when all the synchronization operations in the configuration simulation thread are completed, the main thread sends a signal to the configuration statistics thread. After that, if an iteration signal is received from the configuration statistics thread, which indicates that the Monte Carlo simulation needs to continue, the main thread sends an iteration signal to the configuration generation thread and the configuration simulation thread to perform the next iteration; if an update signal is received from the configuration statistics thread, which indicates that the optimal test packet configuration has been obtained, the main thread stops the Monte Carlo simulation and gives the detailed information of the configuration. In addition, in the configuration simulation thread, if the termination time of the test packet configuration on the high-level simulator exceeds the idle time allowed by the NoC, the main thread reads the starting state of the current Monte Carlo simulation, returns the state information of the NoC to the corresponding time, and clears all temporary variables in the process. After that, the other three threads restart from the returned NoC state to generate the optimal test packet configuration in the next idle period. If there is no timeout and the optimal test packet configuration is generated, the main thread uses the high-level simulator to simulate the configuration until any data packet in the configuration is transmitted to the target routing node, and the time at this moment is recorded as T first . Then, the main thread uses the state at T first to update the state of the NoC. The above process will be repeated, and the four threads continue to generate the optimal test packet configuration to test the test scenarios that have not been covered, until all the test scenarios are covered.

[0095] III. Experimental process and result analysis

[0096] In this experiment, the PSBST method based on software self-test is used on a 32x32 two-dimensional grid structure NoC. In this experiment, the number of simulation times in the Monte Carlo simulation process, the test coverage of the optimal configuration, and the target value changes are given, and the advantages of the high-level simulator, the high-level evaluation method, the Monte Carlo simulation, and the multi-thread technology in testing the NoC are analyzed and proved. Secondly, the test quality of the PSBST testing the NoC is given. Finally, the test overhead of the PSBST is given, including the additional test area overhead, the generation time of the test packet configuration, the test execution time, and the test data size, etc.

[0097] 1. Monte Carlo simulation under multi-thread

[0098] When a thousand-core NoC can inject test packets, this invention uses Monte Carlo simulation to find the near-optimal test packet configuration under the current state. This optimal configuration must not only cover as many test scenarios as possible, but also minimize test overhead. This paper characterizes both aspects simultaneously through high-level evaluation using target values.

[0099] Figure 10 This paper demonstrates the change in the maximum target value of the 1000-core NoC during each Monte Carlo simulation iteration in its initial state. It should be noted that although this paper uses Monte Carlo simulation to select the optimal configuration from 1000 different test packet configurations, these configurations still represent a small proportion of the algorithm's search space, and other configurations may exist that can achieve larger target values. To conduct a thorough search, after the current Monte Carlo simulation completes the simulation of 1000 configurations and the maximum target value is statistically analyzed, a new 1000-configuration Monte Carlo simulation iteration is started under the same initial state to search for a better configuration than the current optimal configuration. This Monte Carlo simulation process continues until no better test packet configurations emerge. The approximate optimal configuration at this point is not necessarily the optimal configuration, but most configurations cannot achieve a target value comparable to the optimal configuration.

[0100] Figure 11 This demonstrates the number of Monte Carlo simulation iterations performed by PSBST and the corresponding test scenario coverage each time a test packet configuration is injected into the current 1000-core NoC. The number of iterations in each Monte Carlo simulation ranges from 2 to 8. Since the Monte Carlo simulation generates 1000 different test packet configurations and evaluates the target value of each configuration, PSBST needs to simulate at least 2000 configurations to obtain the current optimal configuration. In this process, the high-level simulator, high-level evaluation method, and multi-threading mechanism effectively support the Monte Carlo simulation in solving the test packet configuration selection problem. Figure 11 The red line in the graph shows that during the Monte Carlo simulation, the cumulative coverage of the test scenarios continuously increased until it reached 100%. The high-level evaluation method calculates newly activated test scenarios across the entire 1000-core NoC, and once a new test scenario is activated, it is removed from the set of untested scenarios. This prevents PSBST from repeatedly activating test scenarios, thus reducing the overhead of online testing.

[0101] 2. Test quality

[0102] First, the present application uses BSBST to test the routing nodes and their key components in many-core NoC. The experiment uses full-scan testing (FScan), functional testing (FTest) and structural software-based self-test (SSBST) as comparison.

[0103] Table 1 Comparison of fault coverage of routing nodes and key components under different methods

[0104] Buffer Switch Routing node Fscan (16 bits) -- -- 100 Ftest (32 bits) 88.9 76.5 85 SSBST (8 bits) -- -- 96.5 BSBST (16 bits) 99.3 89.4 98

[0105] As shown in Table 1, the test quality of BSBST is very high: first, the fault coverage of BSBST on routing nodes is as high as 98%, which is very close to 100% that can be achieved by FScan. Second, BSBST tests the buffer very sufficiently, which can achieve 99.3%. Although FScan can achieve the highest fault coverage in all methods, it is limited to rely on ATE and offline testing, and thus cannot be applied to online testing of many-core NoC. Compared with FTest, BSBST can more effectively test the timing circuit in many-core NoC, and the test coverage achieved on the buffer, switch and routing node is much higher than FTest. Compared with SSBST, BSBST tests the circuit with large timing depth more sufficiently. For example, the activation of the counter in the buffer requires more than 10 clock cycles, and BSBST can still achieve 100% fault coverage of the unit regardless of how large its timing depth is. In summary, in terms of test quality of routing nodes and their key components in many-core NoC, BSBST is superior to existing test methods.

[0106] Next, the present application uses PSBST to test the many-core NoC, and the test results are shown in Table 2. Table 2 mainly focuses on showing the test coverage of PSBST and the comparison of FScan, random test method (Random) on the buffer, switch and the whole many-core NoC.

[0107] Table 2 Comparison of test quality of different test methods of many-core NoC

[0108]

[0109] The PSBST achieved 94.11% overall fault coverage on the KiloNoC. The PSBST abstracts the test packets generated by the BSBST into test scenarios, and then uses Monte Carlo simulation to ensure that all test scenarios are exercised at every router node of the KiloNoC. Thus, the PSBST achieves high fault coverage on the KiloNoC when the test packets are applied to every router node in parallel. Considering that the time required to perform fault simulation on the KiloNoC is prohibitively long, the invention reduced the buffer depth size from 16 to 4, and the percentage of faults related to external signals (e.g., tx signals) that the PSBST cannot directly test increased. Thus, the PSBST achieved lower fault coverage on the KiloNoC buffers than the BSBST, from 99.3% to 98.18%. Furthermore, the KiloNoC that the invention tested was designed based on Herms, and its router nodes contain all steering from any input port to any output port. However, when the KiloNoC uses the XY routing algorithm, some steering channels are not activated. In actual operation, even if a steering channel that is not activated has a fault, the functionality of the KiloNoC is not affected. Thus, the PSBST achieved lower test coverage than the FScan, but the invention considers the PSBST to have higher test quality than the FScan because of the problem of over-testing.

[0110] Existing testing methods cannot meet the requirements of online testing of the KiloNoC. First, the FScan is an effective method for testing the KiloNoC, and as shown in Table 2, the FScan achieved 100% fault coverage. However, the FScan requires the use of ATE to inject test data, and requires a dedicated test mode other than the normal working mode. Thus, the FScan is only suitable for testing during the manufacturing process, and is not suitable for online self-testing of the KiloNoC. Second, the KiloNoC is large in scale, and the proportion of data packets generated by random testing in the set of valid test packets is small. Thus, random testing is difficult to achieve ideal fault coverage. Figure 12 The fault coverage obtained by random testing is shown, where the horizontal axis shows "NX" to indicate that the total number of data packets of the random testing is N times that of the PSBST. As the number of test packets increases from 1 times to 4 times, the growth rate of the fault coverage of the KiloNoC under random testing gradually slows down, and the fault coverage that can be achieved at most is only 57.27%. Thus, random testing cannot meet the requirements of online testing of the KiloNoC due to the low fault coverage.

[0111] Next, the invention uses a set of gray-scale images to illustrate how the PSBST effectively tests the buffers and router nodes at different positions of the KiloNoC. First, the gray-scale Figure 13 and 14The fault coverage of PSBST and random test on each buffer of the k-ary NoC is shown.

[0112] As shown in the gray scale Figure 13 , PSBST achieves high fault coverage on each buffer of the k-ary NoC. The reason for this phenomenon is that the test packets generated by BSBST have excellent test performance, and PSBST ensures that these test packets appear on each buffer of the k-ary NoC. In contrast, the gray scale Figure 14 reflects that the fault coverage of random test on most buffers of the k-ary NoC is low, and the fault coverage of the internal routing nodes is even lower. This is because many internal circuit units in the buffer are not fully triggered by the random test packets. In addition to this reason, the routing nodes around the k-ary NoC can be connected to the outside through boundary scan or JTAG, while the internal routing nodes are difficult to access.

[0113] As shown in the gray scale Figure 14 , PSBST effectively tests the routing nodes at any position in the k-ary NoC, while also avoiding the problem of over-testing. As mentioned earlier, many of the turns in the internal routing nodes of the k-ary NoC will not be triggered in the functional mode, i.e., these turns are not functionally testable. The present invention counts the untestable conditions of the internal nodes, and an internal routing node contains 25 turn channels, but only 68% (= (25-4-4) / 25) of them can be functionally tested. Based on the above reasons, the test coverage achieved by PSBST on the edge routing nodes of the k-ary NoC is slightly higher than that on the internal routing nodes, which is a reasonable and acceptable situation.

[0114] In addition, the arbitration logic corresponding to the circuit in the k-ary NoC is also difficult to test, as it requires multiple test packets to arrive at the routing node at the same time. This requirement is difficult to meet in the k-ary NoC, especially for the switches in the internal routing nodes. PSBST abstracts all feasible turns in the routing node into test scenarios, and Monte Carlo simulation does not terminate until all test scenarios are covered. At the same time, the high-level simulator also implements accurate cycle simulation by referring to the gate-level netlist design. Therefore, PSBST can ensure that test packets arrive at the routing node on time, thereby effectively testing the arbitration circuit. As shown in the gray scale Figure 15 , PSBST can achieve high fault coverage on each routing node. Since the edge routing nodes of the k-ary NoC can obtain packets from the external boundary scan or JTAG, they have more testable times, and thus have higher fault coverage. As shown in the gray scale Figure 16As shown, the random test has a low fault coverage on the routing nodes of the many-core NoC. Meanwhile, the test coverage of the routing nodes in different locations fluctuates greatly. In summary, the present application concludes that PSBST can achieve a high test quality on the many-core NoC.

[0115] 3. Test overhead

[0116] Another advantage of PSBST for testing the many-core NoC on-line is that the test overhead of the method is low.

[0117] Table 3 Comparison of different test methods for the many-core NoC in terms of test overhead

[0118]

[0119] As shown in Table 3, PSBST uses on-chip resources to transmit data packets between the routing nodes of the many-core NoC to complete the test, so it does not require any intrusive hardware and does not introduce any additional area overhead. In contrast, FScan requires an additional area overhead of up to 17.14% of the total area of the many-core NoC. Due to the large scale, the area of the many-core NoC is 5.31 x 106um 2 Therefore, the total area after inserting the scan chain is up to 6.22 x 106um 2 .

[0120] Table 3 also shows the time taken by PSBST to generate the test packets. First, the test data packet generation time of PSBST includes the solving time of the BMC. Due to the slice technique significantly reducing the size of the state machine model of the routing node buffer and switch of the many-core NoC, the entire solving process of the BMC only takes 2.48 seconds. Second, the test data packet generation time of PSBST also involves the solving time of the Monte Carlo simulation. PSBST uses multi-threading technology to greatly reduce the time of the simulation process. Figure 17 The execution time of each Monte Carlo simulation iteration is shown in detail, with the maximum solving time being nearly 5000 seconds, which is within an acceptable range. If a platform with more processing cores and better computing performance is used, the solving time of the Monte Carlo simulation can be further optimized.

[0121] Finally, the present application notes that the test data volume and test time of PSBST are reasonable. Since the high-level simulator and the high-level evaluation method count the number of test scenarios covered by the test data packets on the whole many-core NoC, PSBST will preferentially select the data packets covering multiple untested scenarios. Meanwhile, once a test data packet is selected, PSBST will remove the test scenario newly covered by the data packet from the untested scenarios. Thus, by setting the target value of the test data packet to 0, PSBST can avoid selecting the data packets repeatedly covering the tested scenarios. In addition, in the case of covering new test scenarios, PSBST minimizes the test cost using the Monte Carlo simulation and the high-level evaluation method. In contrast, random testing fails to effectively test the routing nodes, but instead repeatedly tests the easily testable areas in the many-core NoC. Therefore, although random testing uses 4 times the test data volume of PSBST, it only achieves a fault coverage rate of 57.27%. In addition, FScan does not take advantage of the interconnection structure and the high-reuse characteristics of the NoC for parallel testing, but needs to connect all the registers in the many-core NoC into a scan chain, which will result in a very large number of test vectors, up to 991848KB. In contrast, PSBST only has 485KB, which is 1 / 2000 of the test data volume of FScan. Meanwhile, FScan needs to move the test vectors into and out of the many-core NoC through the scan chain, which will result in an abnormally high test time, up to 8.13x10 9 cycles. In contrast, PSBST only has 81815 cycles. From the above experimental data, it can be known that the overhead of FScan is several orders of magnitude higher than that of PSBST in terms of test data volume and test execution time. In summary, the present application concludes that the test overhead of PSBST is very low when testing the many-core NoC.

[0122] It can be understood that the present application is described through some embodiments, and those skilled in the art know that various changes or equivalent replacements can be made to the features and embodiments without departing from the spirit and scope of the present application. In addition, the features and embodiments can be modified to adapt to specific conditions and materials under the guidance of the present application without departing from the spirit and scope of the present application. Therefore, the present application is not limited by the specific embodiments disclosed herein, and all embodiments falling within the scope of the claims of the present application are within the scope of the present application.

Claims

1. A method for online testing of a NoC based on software self-test, characterized in that, The method comprises the following steps: step 1, automatically generating test vectors for a software self-testing method by using bounded model checking; step 2, solving the selection problem of test data packet configuration by using a Monte Carlo simulation method; and step 3, increasing a multithreading mechanism in the Monte Carlo simulation process. The step 2 uses Monte Carlo simulation to search for an approximately optimal configuration in a large range of random spaces, and comprises the following steps: step 1, initializing a random seed; step 2, generating a random configuration; step 3, calculating a target value of the current configuration; step 4, comparing the current maximum target value with a target value obtained by a previous optimal configuration, checking whether the current optimal configuration improves the historical optimal configuration; if yes, updating the optimal configuration at this time, and then continuing to perform Monte Carlo simulation; otherwise, selecting the historical optimal configuration as the optimal test data packet configuration of the NoC at this time; and step 5, repeating the above steps until a preset number of iterations is reached. The step 3 uses a multithreading technology to generate an optimal test data packet configuration for the online self-testing problem of the NoC, and a parallel test data packet configuration selection method under the multithreading comprises four different types of threads, namely, a master thread, a configuration generation thread, a configuration simulation thread and a configuration statistical thread. First step: When the K-ary NoC can inject test packets, the Monte Carlo simulation method generates a set of random test packet configurations at the current time T s performs random test packet configuration generation to generate N rc a set of random test packet configurations; Second step: put all data packets in each configuration into high layer simulator respectively to simulate running, stop until all data packets in simulator are transmitted, and record the termination time at this time T e Monte Carlo simulation performs high layer evaluation mode to calculate target value size of different configurations; Third, select N rc The maximum target value of the group random test data packet configuration and the corresponding configuration; The software self-testing method of the step 1 comprises the following steps: step 1, initializing a BSBST; step 2, checking whether there is an unverified property in a database of the BSBST, if yes, obtaining an unverified property from the database, and then performing the next step; otherwise, terminating the process; step 3, reducing the size of a model to alleviate the state space explosion problem; step 4, verifying the given property by using a BMC tool; if the tool cannot give a guide sequence, the BSBST considers that the given property is not testable in the functional mode, and returns to the second step; otherwise, if the tool gives a corresponding guide sequence, the BSBST performs the next step; step 5, obtaining a test vector from the guide sequence; step 6, mapping the test vector into an SBST program, and returning to the second step of the whole process to repeat the above process. time time 2. The software self-test based many-core network-on-chip online testing method according to claim 1, wherein, The configuration generation thread comprises the following steps: step 1, generating a large number of test data packets with different configurations in the system, and temporarily storing the test data packets; step 2, obtaining the state information of the NoC from the master thread; and step 3, sending a signal to the master thread to request configuration injection. First step: Extract EFSM model from RTL design file of the thousand-core NoC routing node, at the same time, BSBST will cover the test scenario as a set of attributes P E and P F Stored in the database; avail avail The configuration simulation thread comprises the following steps: step 1, obtaining the state information of the NoC from the master thread, and sending a signal to the master thread to request configuration injection; step 2, obtaining the test data packet configuration from the master thread; and step 3, sending the test data packet configuration to the master thread. Step 5: If the property being verified belongs to the set P E , BSBST treats the input signal sequence in the guided sequence at this time as a test vector for activating the property p; otherwise, if the property being verified belongs to the set P F , BMC fixes the model to the time range in which the state update occurs and imposes the guided sequence, and then BSBST generates a test vector for the fault activated during the state update under the constraint using ATPG. avail 3. The software self-test based many-core network-on-chip online testing method according to claim 1, wherein, The step 2 is a high-level simulator using C language for the development of the tile NoC, which is based on the Herms routing node design, reduces many underlying details while keeping the necessary variables in the tile NoC, and also completes the functions of the buffer and the switch, and the cycle accuracy of the results is consistent with that of the gate-level netlist simulation, and a high-level evaluation method for the test data packet configuration is given The former describes the calculation method of the test coverage cov, the numerator indicates that the current data packet configuration can cover the untested scenario, and the denominator indicates the total test scenarios to be covered; the latter gives the target value of the evaluation of the current configuration The formula, the numerator is the test coverage cov, and the denominator is the product of two parts, the former is the square root of the sum of the tiles in the test data packet configuration, and the latter is the completion time of the tile network after adding the current test data packet configuration avail cur The ratio of the time at the moment before adding the configuration avail pre to the time at the moment after adding the configuration 4. The software self-test based many-core network-on-chip online testing method of claim 1, wherein, avail avail Second step: when the configurations for the current Monte Carlo simulation are needed N conf The configuration generation thread sets the flag in the state table for the existing configurations to 1, which indicates that these configurations are ready. Step 3: When the ready configuration reaches the number of threads supported by the computing platform The configuration statistical thread comprises the following steps: step 1, obtaining the test data packet configuration from the master thread; step 2, obtaining the state information of the NoC from the master thread; step 3, obtaining the target value of the test data packet configuration from the master thread; and step 4, sending the target value to the master thread. thread The configuration generation thread sends a ready signal to the master thread, and the master thread notifies the configuration simulation thread that the configuration is ready. The fourth step: the configuration generating thread needs to wait for the return request signal of the master thread; when the return request signal is obtained, the configuration generating thread will avail thread The test data packet configurations are passed to the configuration simulation thread, and the state flags of these configurations in the state table are set to 2; if the configurations have been generated N conf The configurations are passed to the configuration simulation thread, and the state flags of these configurations in the state table are set to 2; if the configurations have been generated N conf The configurations are passed to the configuration simulation thread, and the state flags of these configurations in the state table are set to 2; if the configurations have been generated Conversely, if the configuration quantity passed to the configuration simulation thread is insufficient N conf， The configuration generation thread returns to the third step; Fifth step: After the generation of N conf After the configuration of the number of test data packets, the configuration generation thread waits for the signal of the master thread; if the received signal is iteration, the configuration generation thread returns to the second step to generate another group of N conf If the received signal is update, the configuration generation thread updates the number of idle input ports according to the current state of the NoC N free At this point, the configuration generation thread ends this task and waits for the next call of the master thread.

5. The software self-test based many-core network-on-chip online testing method according to claim 1, wherein, avail max Second step: When receiving the ready confirmation signal returned by the main thread, the configuration simulation thread gets the configuration generation thread passed max thread a number of test data packets Third step: configuring simulation thread pair max thread The simulation of each configuration is performed by using NoC high-level simulator, and the test scenario coverage and completion time of each configuration are obtained during the simulation max thread The test scenario coverage and completion time of each configuration are obtained during the simulation If the completion time of the test data packet configuration is within the idle time allowed by the many-core NoC, the configuration simulation thread uses the high-level evaluation method to calculate the target value of the configuration; otherwise, if a timeout occurs, the target value of the corresponding configuration is directly set to 0. After this, the configuration simulation thread performs a synchronous update operation to update all the configuration target values; and only when this is complete max thread After the simulation and evaluation calculation of the test data packet configuration, the configuration simulation thread passes the max thread evaluation calculation results to the configuration statistics thread, and at this point the task of the current phase of the configuration simulation thread ends, and the next call of the main control thread is awaited.

6. The software self-test based many-core network-on-chip online testing method according to claim 1, wherein, max The first step is to configure the statistics thread to receive the configuration of the simulation thread for each commit max thread evaluation results; The second step is to configure the statistics thread from max thread The maximum target value was selected from the evaluation results. max new and its corresponding test data package configuration; Step 3: The configuration thread compares the new value with the previous maximum target value held in temporary storage max new max tem If the new value is greater than the previous maximum target value, the configuration thread updates the maximum target value max new max tem max new max tem max new ; otherwise, the new value is discarded​​​​​ Step 4: Configure the statistical thread to determine whether the configured number reaches the total number of configurations N conf ; If reached, the configuration statistics thread looks for the maximum target value obtained in the last Monte Carlo simulation iteration max pre If not, the configuration statistics thread uses max tem to update max pre ; otherwise, if max pre , the configuration statistics thread compares the size of max tem and The configuration master thread comprises the following steps: step 1, starting the configuration generation thread, and transmitting the state information of the NoC at this time to the configuration simulation thread; step 2, obtaining the test data packet configuration from the configuration generation thread; step 3, obtaining the state information of the NoC from the configuration simulation thread; step 4, obtaining the target value of the test data packet configuration from the configuration statistical thread; and step 5, sending the test data packet configuration to the configuration simulation thread. pre ; if ​ tem is greater than ​ pre , the configuration statistics thread uses ​ tem to update ​ pre , and the corresponding configuration record ​ tem is the optimal configuration at this time, and then sends an iteration signal to the master thread, requesting to continue the Monte Carlo simulation iteration; if ​ tem is less than ​ pre , the configuration statistics thread considers the configuration corresponding to ​ pre as the final optimal test data packet configuration at this stage and passes it to the master thread for updating.

7. The software self-test based many-core network-on-chip online testing method according to claim 1, wherein, ​ ​ Second step: If the configuration simulation thread sends a request signal and the configuration generation thread sends a ready signal, the master thread dispatches the configuration generation thread to import the generated test packet configuration into the configuration simulation thread; Third step: When all the synchronization operations in the configuration simulation thread are executed, the master thread sends a signal to the configuration statistics thread; Fourth step: If the iteration signal sent by the configuration statistics thread is received, it means that the Monte Carlo simulation needs to continue, so the master thread sends an iteration signal to the configuration generation thread and the configuration simulation thread to perform the next iteration. If the update signal sent by the configuration statistics thread is received, it means that the optimal test packet configuration has been obtained, so the master thread stops the Monte Carlo simulation and gives the detailed configuration information. In addition, in the configuration simulation thread, if the termination time of the test packet configuration on the high-level simulator exceeds the allowed idle time of the many-core NoC, the master thread reads the starting state of this round of Monte Carlo simulation and returns the NoC state information to the corresponding time, while clearing all temporary variables in the process; Fifth step: The other three threads restart from the returned NoC state to generate the optimal test packet configuration in the next idle period; If no timeout occurs and an optimal test packet configuration is generated, the master thread uses the high-level simulator to simulate the configuration until any packet in the configuration is transmitted to the target router node, and the time at this moment is recorded as T T first ; Step 6: The master thread uses T first the state of the moment to update the state of the many-core NoC.

Images