Dynamic Verification Method for SOC Chips Based on Memory Consistency Model

Abstract

This invention relates to the field of system-on-chip (SoC) testing technology, specifically to a dynamic verification method for SoC chips based on a memory consistency model. The method includes collecting memory access data entering the cache controller and generating feature vectors; classifying the feature vectors using a decision tree to filter out risky memory data; expanding test cases based on the risky memory data to obtain test cases; testing the SoC chip based on the test cases; and iterating the decision tree model based on the test results. Addressing the problem that existing SoC verification test cases are ineffective against dynamically changing memory read / write patterns, this invention introduces a hardware monitoring unit into the cache controller to directly capture memory read / write data appearing in the cache. A decision tree model is then used to filter out risky memory data that may cause failures. Based on this, test cases are constructed and expanded to facilitate testing of the SoC's memory read / write mechanism, and the decision tree model is improved to obtain more test cases.

Description

Technical Field

[0001] This invention relates to the field of system-on-chip testing technology, and specifically to a dynamic verification method for SOC chips based on a memory consistency model. Background Technology

[0002] Memory consistency verification of SoC chips is a crucial step in the SoC design process. It addresses the issue of consistent memory operation execution order across different processor cores in a parallel programming model. Common verification methods primarily rely on a fixed test case library (such as the IEEE 1800 UVM standard), writing specific transaction sequences to generate random but controlled memory access scenarios. The verification engine then executes simulations according to these pre-defined test cases to perform the tests.

[0003] For example, patent application CN202311125925.4 discloses a testing system, relating to the field of testing technology. The testing system includes: at least one I / O unit, multiple devices, and a shared memory unit. The shared memory unit includes: a shared memory and a memory operation unit connected in communication. Each of the devices is directly or indirectly connected to the memory operation unit. The devices are used to acquire operation instructions for operating the shared memory and send the operation instructions to the memory operation unit. The memory operation unit is used to receive the operation instructions from the devices and execute the operation instructions to interact with the shared memory with the target data corresponding to the operation instructions. This system can ensure data consistency among multiple devices and has the advantages of high sharing efficiency, good accuracy, and low latency.

[0004] However, in actual implementation, the inventors found that the memory access pattern changes continuously and dynamically during SOC operation, but the existing verification environment cannot capture these changes in real time, resulting in a rigid verification strategy. Summary of the Invention

[0005] To address the aforementioned problems in existing technologies, a dynamic verification method for SOC chips based on a memory consistency model is provided.

[0006] The specific technical solution is as follows: A dynamic verification method for SOC chips based on a memory consistency model, applicable to SOC chips, wherein a hardware monitoring unit is pre-integrated in the cache controller of the SOC chip; the dynamic verification method for SOC chips includes: Step S1: collecting memory access data entering the cache controller and generating feature vectors; Step S2: performing decision tree classification based on the feature vectors to filter out risky memory data; Step S3: expanding test cases based on the risky memory data to obtain test cases; Step S4: testing the SOC chip based on the test cases, and iterating the decision tree model based on the test results.

[0007] On the other hand, step S1 includes: step S11: the hardware monitoring unit acquires the memory access data entering the cache controller and adds it to the circular buffer; step S12: the redundant data in the circular buffer is filtered according to the preset filtering rules to obtain valid data; step S13: the valid data is feature extracted and quantized to obtain the feature vector.

[0008] On the other hand, step S12 includes: step S121: extracting the memory access data within the last 500 milliseconds from the circular buffer as first filtered data; step S122: traversing the first filtered data according to the time sequence and determining consecutive identical operation intervals, retaining only the first and last data of the consecutive identical operation intervals to obtain second filtered data; step S123: merging adjacent address operations on the second filtered data to obtain third filtered data; step S124: filtering the third filtered data to obtain cached abnormal records to form the valid data.

[0009] On the other hand, step S13 includes: calculating the read / write ratio feature, sequence complexity feature, concurrency feature, and cache anomaly feature respectively, and then concatenating them after normalization to obtain the feature vector; the calculation process of the read / write ratio feature includes: R / W_ratio = number of read operations / (number of read operations + number of write operations); the calculation process of the sequence complexity feature includes: Seq_complexity = number of state transitions in the sequence / sequence length; the calculation process of the concurrency feature includes: Concurrency = number of concurrently active threads / maximum number of threads; the calculation process of the cache anomaly feature includes: Cache_anomaly = number of abnormal state transitions / total number of state transitions.

[0010] On the other hand, in step S2, the decision tree model includes: a gain calculation module, which calculates information gain for each feature of the input feature vector; a node generation module, which is connected to the gain calculation module; the node generation module generates split nodes by comparing the information gain and the gain threshold; multiple split nodes constitute a decision tree; a path rule generation module, which is connected to the node generation module; the path rule generation module generates decision tree path rules by sequentially reading the split nodes and adding test case tags indicating whether they can be used for testing; in step S2, the risk memory data is obtained by filtering based on the decision tree path rules.

[0011] On the other hand, step S3 includes: step S31: cleaning the risky memory data and generating valid test parameters; step S32: generating a normal output range for the valid test parameters to obtain example test cases; step S33: expanding the example test cases to obtain the test cases.

[0012] On the other hand, step S31 includes: step S311: filling missing values ​​of the risk memory data with historical averages to obtain first cleaned data; step S312: marking outliers in the first cleaned data and removing data with excessively high outliers to obtain second cleaned data; step S313: checking the timestamp continuity of the second cleaned data and segmenting the power outage to obtain third cleaned data; step S314: standardizing the format of the third cleaned data to obtain fourth cleaned parameters; step S315: determining the validity and prioritizing the fourth cleaned parameters to obtain the valid test parameters.

[0013] On the other hand, step S32 includes: step S321: establishing a benchmark verification test for the effective test parameters to obtain benchmark test results; step S322: statistically obtaining the benchmark output result distribution based on the benchmark test results; step S323: generating the normal output range based on the benchmark output result distribution and assembling it to obtain the example use case.

[0014] On the other hand, step S33 includes: step S331: expanding the parameter range according to the example use case to obtain the expanded parameters; step S332: generating the corresponding expected output according to the expanded parameters; step S333: obtaining the test case according to the expanded parameters and the expected output.

[0015] On the other hand, step S4 includes: step S41: using the test cases to test the SOC chip to obtain actual test results; step S42: generating consistency problem trigger points based on the actual test results; step S43: updating the split nodes of the decision tree based on the consistency problem trigger points.

[0016] The above technical solution has the following advantages or beneficial effects: addressing the problem that existing SOC verification test cases are not effective in dealing with dynamically changing memory read and write modes, a hardware monitoring unit is introduced into the cache controller to directly capture memory read and write data appearing in the cache, and a decision tree model is used to filter out risky memory data that may cause failures. On this basis, test cases are constructed and expanded to facilitate the testing of the SOC's memory read and write mechanism, and the decision tree model is improved to obtain more test cases. Attached Figure Description

[0017] Embodiments of the invention will be described more fully with reference to the accompanying drawings. However, the drawings are for illustration and explanation only and do not constitute a limitation on the scope of the invention.

[0018] Figure 1 This is an overall schematic diagram of an embodiment of the present invention; Figure 2 This is a schematic diagram of step S1 in an embodiment of the present invention; Figure 3 This is a schematic diagram of step S12 in an embodiment of the present invention; Figure 4 This is a schematic diagram of a model in an embodiment of the present invention; Figure 5 This is a schematic diagram of step S3 in an embodiment of the present invention; Figure 6 This is a schematic diagram of step S31 in an embodiment of the present invention; Figure 7 This is a schematic diagram of step S32 in an embodiment of the present invention; Figure 8 This is a schematic diagram of step S33 in an embodiment of the present invention; Figure 9 This is a schematic diagram of step S4 in an embodiment of the present invention. Detailed Implementation

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

[0020] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.

[0021] The present invention will be further described below with reference to the accompanying drawings and specific embodiments, but this is not intended to limit the scope of the invention.

[0022] This invention includes: a dynamic verification method for SOC chips based on a memory consistency model, applicable to SOC chips, wherein the cache controller of the SOC chip has a hardware monitoring unit pre-integrated; such as Figure 1 As shown, the dynamic verification method for SOC chips includes: Step S1: Collect memory access data entering the cache controller and generate feature vectors; Step S2: Perform decision tree classification based on the feature vectors to filter out risky memory data; Step S3: Expand test cases based on the risky memory data to obtain test cases; Step S4: Test the SOC chip based on the test cases and iterate the decision tree model based on the test results.

[0023] Specifically, to address the issue that existing SOC verification test cases are ineffective when dealing with dynamically changing memory read / write patterns, a hardware monitoring unit is introduced into the cache controller to directly capture memory read / write data appearing in the cache. A decision tree model is then used to filter out risky memory data that may cause failures. Based on this, test cases are constructed and expanded to facilitate the testing of the SOC's memory read / write mechanism, and the decision tree model is improved to obtain more test cases.

[0024] Specifically, the above solution is implemented as a set of testing systems, including a host computer and a hardware monitoring unit integrated into the SOC chip. The SOC chip itself has a corresponding cache and cache controller. The cache stores the SOC's memory read / write instructions, forming memory read / write data. The scheduling and operation of these read / write instructions are executed by the cache controller.

[0025] Therefore, by adding a hardware monitoring unit within the cache controller, it is possible to capture and add memory data to a circular buffer for collection with minimal area overhead. Furthermore, by calculating corresponding feature values, certain fragments of memory read and write data can be effectively represented. Subsequently, a decision tree model is used for rule filtering to match risky memory data that may cause read and write failures.

[0026] This section of risk memory data simulates real-world read / write failures that an SOC chip might encounter while executing actual business data, including operational data on a series of dynamic read / write pattern changes. Based on this data, a series of test cases with approximate read / write logic can be written and generated through parameter amplification.

[0027] Using these test cases, reliability testing of the SOC chip can be performed, and the data obtained during the test that caused the power outage due to failure can be further iterated on the decision tree to facilitate a more accurate screening process for failure data.

[0028] In one embodiment, such as Figure 2 As shown, step S1 includes: step S11: the hardware monitoring unit acquires the memory access data entering the cache controller and adds it to the circular buffer; step S12: the redundant data in the circular buffer is filtered according to the preset filtering rules to obtain valid data; step S13: the valid data is feature extracted and quantized to obtain the feature vector.

[0029] Specifically, in response to the problem that the memory access data of the SOC chip is very complex and has a huge amount of data, in this embodiment, in order to filter out the actual effective data, the cache controller was first modified and a hardware monitoring unit was added. The hardware monitoring unit will obtain the memory access data entering the cache controller and add it to the circular buffer.

[0030] A circular buffer uses a first-in-first-out (FIFO) order for memory access data. It typically only needs to retain memory read and write operations within a few hundred milliseconds, discarding any data that exceeds this time, thereby reducing chip area overhead.

[0031] The data collected includes: access frequency: the proportion of read and write operations under the current chip load; access order: a sequence of consecutive memory read and write operations; cache status: changes in the cache line status corresponding to the memory read and write operation sequence.

[0032] The collected data provides a good representation of the chip's current memory access data. The collected data is then stored in a circular buffer. The circular buffer has a capacity of 1024 operation records, each containing: timestamp, operation type (read / write), address range, cache status, and thread ID.

[0033] Subsequently, redundant data in the circular buffer is filtered according to preset filtering rules to remove obviously normal and continuous memory access data, so as to obtain valid data for further judgment.

[0034] Finally, specific dimension features are calculated for the selected valid data, and the feature vectors are concatenated.

[0035] In one embodiment, such as Figure 3 As shown, step S12 includes: Step S121: Extracting memory access data within the last 500 milliseconds from the circular buffer as the first filtered data; Step S122: Traversing the first filtered data according to the time sequence and determining consecutive identical operation intervals, retaining only the first and last data of the consecutive identical operation intervals to obtain the second filtered data; Step S123: Merging adjacent address operations on the second filtered data to obtain the third filtered data; Step S124: Filtering the third filtered data to obtain cached abnormal records to form valid data.

[0036] Specifically, to achieve better filtering of redundant data, this embodiment employs the aforementioned filtering rules. The length of the circular buffer is determined by the number of instructions. For a large number of instructions, the timestamp end can be read, and only the memory read / write data within the most recent 500 milliseconds can be retained as the first filtering data, thereby eliminating historical data redundancy.

[0037] Meanwhile, for continuous read and write operations, since the data that may cause failures usually occurs during the transition between read and write modes, it is necessary to filter out consecutive identical operations. This includes traversing the first filtered data in chronological order and reading the markers of read / write operations. When a certain number of identical markers appear, the middle part of the consecutive read and write operations in that interval is removed, and only the first and last data are retained.

[0038] Then, in response to changes in adjacent memory addresses, an operation to merge adjacent addresses was performed to facilitate subsequent parameter expansion. This included traversing the target addresses pointed to by read and write operations in the second filtered data, comparing each target address, and replacing the later read and write operation address with the original operation address when the address difference between the subsequent read and write operation address and the previously appeared operation address was within 64 bytes.

[0039] Finally, in the third filtering data, the retained entries are prioritized and filtered. This includes first judging the cache status field, assigning higher priority to operation records at the cache status word end that point to a fault, and then using a single output window to judge and retain the high-priority entries to complete the filtering process.

[0040] In one embodiment, step S13 includes: calculating the read / write ratio feature, sequence complexity feature, concurrency feature, and cache anomaly feature respectively, and then concatenating them after normalization to obtain a feature vector; the calculation process of the read / write ratio feature R / W_ratio includes: R / W_ratio = number of read operations / (number of read operations + number of write operations); the calculation process of the sequence complexity feature Seq_complexity includes: Seq_complexity = number of state transitions in the sequence / sequence length; the calculation process of the concurrency feature Concurrency includes: Concurrency = number of concurrently active threads / maximum number of threads; the calculation process of the cache anomaly feature Cache_anomaly includes: Cache_anomaly = number of anomaly state transitions / total number of state transitions.

[0041] Specifically, to achieve better vector construction results, this embodiment selects four dimensions for feature calculation: read-write ratio, sequence complexity, concurrency, and cache anomaly. For the extracted valid data, the read-write ratio is calculated by reading the read and write operations of an instruction. For memory read / write operations within an instruction, the number of state transitions is calculated by reading the cache state changes and the total length of the sequence corresponding to the instruction, and the sequence complexity is further calculated. For the number of threads in an entry, the proportion of active threads relative to the maximum number of threads is calculated to obtain the concurrency feature. For the number of transitions, the total number of transitions and the number of abnormal state transitions conforming to the anomaly rules are extracted to calculate cache anomaly conditions.

[0042] After calculating the above parameters, normalization is performed according to the parameter range that the SOC chip may appear in the pre-calibrated form, and each feature is mapped to the range of [0,1]. Finally, the feature vectors are concatenated to obtain the feature vector.

[0043] In one embodiment, such as Figure 4 As shown, in step S2, the decision tree model includes: a gain calculation module 21, which calculates the information gain for each feature of the input feature vector; a node generation module 22, which is connected to the gain calculation module 21; the node generation module 22 compares the information gain and the gain threshold to generate split nodes; multiple split nodes constitute a decision tree; a path rule generation module 23, which is connected to the node generation module 22; the path rule generation module 23 generates decision tree path rules by sequentially reading the split nodes and adds test case tags indicating whether they can be used for testing; in step S2, risk memory data is obtained by filtering based on the decision tree path rules.

[0044] Specifically, in order to achieve a better identification effect on memory data that may cause faults, this embodiment uses the above-mentioned decision tree model to generate decision tree path rules for actual screening.

[0045] Specifically, after collecting the feature vectors, the information gain IG can be calculated for each feature. The calculation method is as follows: IG (feature) = H (parent node) - Σ (child node weight × H (child node)); H represents the calculation of information entropy: H = -Σ(p_i × log2(p_i)), where p_i represents the i-th word vector in the features; After calculating the information gain of each feature, features with an information gain > 0.3 are used as split nodes. For example, the information gain of the parent node, the read / write ratio feature R / W_ratio, is 0.5. The information gain of the next child node (split node), the cache anomaly feature Cache_anomaly, is 0.4. The information gain of the lower-level concurrency feature Concurrency is 0.7. Split nodes at multiple levels form a decision tree.

[0046] After forming the decision tree, the nodes at multiple levels are traversed sequentially according to the decision tree to establish decision tree path rules. For each rule, it is determined whether it will cause further read / write failures and use case tags are generated. The results are shown in Table 1.

[0047]

[0048] Table 1 In the actual screening process, risk data is generated by matching the established rules one by one and hitting the available decision tree path rules.

[0049] In one embodiment, such as Figure 5 As shown, step S3 includes: step S31: cleaning the risky memory data and generating valid test parameters; step S32: generating a normal output range for the valid test parameters to obtain example test cases; step S33: expanding the example test cases to obtain test cases.

[0050] Specifically, in order to achieve better amplification results, in this embodiment, risky memory data is first cleaned to remove abnormal or missing items, thereby obtaining usable and valid test data.

[0051] For valid test data, the corresponding normal output range can be matched according to the pre-collected benchmark test data, such as the normal range of read and write data, the range of accessible addresses, etc., and example test cases can be formed. Finally, the actual test cases are obtained by expanding according to the parameter characteristics of the example test cases.

[0052] In one embodiment, such as Figure 6 As shown, step S31 includes: Step S311: Filling missing values ​​in the risk memory data with historical averages to obtain first cleaned data; Step S312: Marking outliers in the first cleaned data and removing data with excessively high outliers to obtain second cleaned data; Step S313: Checking the continuity of timestamps in the second cleaned data and segmenting the power outage to obtain third cleaned data; Step S314: Standardizing the format of the third cleaned data to obtain fourth cleaned parameters; Step S315: Determining the validity and prioritizing the fourth cleaned parameters to obtain valid test parameters.

[0053] Specifically, to achieve better data cleaning results, this embodiment employs the aforementioned sequential cleaning process, including: First, missing values ​​are handled by iterating through the risk memory data. If a certain feature value is missing, the historical mean corresponding to that feature word is used to fill it in to obtain the first cleaned data.

[0054] Then, outliers are measured, including traversing the first cleaned data, marking data that exceed the mean ± 3 times the standard deviation as outliers, and then calculating the outliers in the overall data entries. If the proportion of outliers is <5%, they are retained and marked as high risk; if it is >5%, they are removed to form the second cleaned data.

[0055] Consistency checks are then performed, including checking the continuity of timestamps on the second cleaned data. Records with a time interval > 1ms are considered breakpoints and then split into two data entries to obtain the third cleaned data.

[0056] Then, the fields of each numerical type in the third cleaned data are uniformly normalized to form the fourth cleaned data by normalizing all numerical features to the [0,1] interval.

[0057] The data validity is then determined, including parameter validity, to determine whether the fourth cleaned data obtained after the above cleaning process can still trigger the example rules indicated as usable in the decision tree path rules.

[0058] After the parameter validity is determined, the parameters are sorted according to the confidence level of the triggered decision tree path rule to obtain their priority. A priority field is added to form the output of valid test parameters. The output format is as follows: { "Parameter ID": "P001", "Eigenvector": [0.72, 0.65, 0.88, 0.53], Triggering rule: "R001", Problem type: Write conflict Confidence level: 0.95 Priority: High } In one embodiment, such as Figure 7 As shown, step S32 includes: step S321: establishing a benchmark verification test for the effective test parameters to obtain the benchmark test results; step S322: statistically obtaining the benchmark output result distribution based on the benchmark test results; step S323: generating the normal output range based on the benchmark output result distribution and assembling it to obtain example test cases.

[0059] Specifically, in order to achieve a better determination of the effective output range, in this embodiment, benchmark verification is first performed using a standard test case library (1000 test cases), and the output results are statistically analyzed to form benchmark test results.

[0060] The benchmark test results include the question types and values ​​that trigger the test cases. Then, for each question type, the output distribution in the benchmark test is statistically analyzed, and the mean μ and standard deviation σ are calculated.

[0061] Subsequently, the normal output range [μ-2σ, μ + 2σ] can be calculated based on the baseline output result distribution, and then concatenated with the valid test parameters of the corresponding problem type to obtain example test cases.

[0062] As an optional implementation, the normal output range can be dynamically updated during the verification process. For example, after every 100 verifications, the mean μ and standard deviation σ are recalculated, and an exponentially weighted moving average is used to calculate μ when recalculating it. μ_new = 0.1×μ_current + 0.9×μ_historical.

[0063] Where μ_new is the updated mean, μ_current is the mean directly calculated for the current round, and μ_historical is the mean before the update.

[0064] The updated mean is used as the basis for calculating the standard deviation in the iterative process.

[0065] In one embodiment, such as Figure 8 As shown, step S33 includes: step S331: expanding the parameter range according to the example test case to obtain the expanded parameters; step S332: generating the corresponding expected output according to the expanded parameters; step S333: obtaining the test case according to the expanded parameters and the expected output.

[0066] Specifically, in order to expand the test cases, in this embodiment, the parameter range is first expanded based on the example test cases to obtain expanded parameters.

[0067] The amplification methods include the following three: 1. The data boundaries of "valid test data" have been expanded. For the values ​​of each feature dimension, the upper and lower boundaries have been expanded by ±15%.

[0068] 2. Perform cross-mutation on several example use cases and historical use cases, including randomly selecting two similar use cases and performing cross-mutation on the feature vector: new feature = 0.6 × feature1 + 0.4 × feature2, and weighted to obtain the feature values ​​of each dimension, thereby forming a new feature vector.

[0069] 3. Set upper and lower boundary extreme values ​​for the values ​​of each feature dimension to form extreme value test cases.

[0070] After splicing the above amplification parameters, the corresponding expected outputs are generated, including: 1. Problem type-based mapping: Write conflict → Expected output: ≥1 write conflict detected Cache line contention → Expected output: Contention latency within the range of [28.8, 62.8] ns Cache consistency failure → Expected output: ≥1 consistency failure event detected 2. Parameter priority-based mapping: High-priority parameters (confidence > 90%) → Expected output tolerance ±5% Medium priority parameters (confidence level 80%-90%) → expected output tolerance ±10% Low priority parameters (confidence level <80%) → expected output tolerance ±15%.

[0071] After completing the above two mapping methods, the output results are verified to determine whether the output of the relevant amplification parameters after the test meets the range of the expected output obtained by mapping. After the verification is passed, the test cases are obtained by splicing the amplification parameters and the expected output.

[0072] In one embodiment, such as Figure 9 As shown, step S4 includes: step S41: using test cases to test the SOC chip to obtain actual test results; step S42: generating consistency problem trigger points based on the actual test results; step S43: updating the split nodes of the decision tree based on the consistency problem trigger points.

[0073] Specifically, in order to achieve a better effect on decision tree updates, in this embodiment, test cases are first used to test the SOC chip to obtain actual test results, including test results that pass and test results that trigger anomalies. For test results that trigger anomalies, the corresponding memory read and write data are extracted in the same way, and each feature value is calculated to form a consistency problem trigger point.

[0074] Then, the consistency problem trigger point is input into the decision tree model, and it is divided into corresponding nodes according to the node traversal method. The next level of split nodes is then updated, thereby completing the update of the decision tree.

[0075] The above are merely preferred embodiments of the present invention and are not intended to limit the implementation methods and protection scope of the present invention. Those skilled in the art should recognize that any equivalent substitutions and obvious changes made based on the description and illustrations of the present invention should be included within the protection scope of the present invention.

Claims

1. A dynamic verification method for SOC chips based on a memory consistency model, characterized in that, Applicable to SOC chips, wherein the cache controller of the SOC chip has a hardware monitoring unit pre-integrated; The SOC chip dynamic verification method includes: Step S1: Collect memory access data entering the cache controller and generate feature vectors; Step S2: Perform decision tree classification based on the feature vectors to filter and obtain risky memory data; Step S3: Expand test cases based on the risk memory data to obtain test cases; Step S4: Test the SOC chip based on the test cases, and iterate the decision tree model according to the test results; Step S1 includes: Step S11: The hardware monitoring unit acquires the memory access data entering the cache controller and adds it to the circular buffer; Step S12: Filter the redundant data in the circular buffer according to the preset filtering rules to obtain valid data; Step S13: Extract features from the effective data and quantize them to obtain the feature vector; Step S12 includes: Step S121: Extract the memory access data within the last 500 milliseconds from the circular buffer as the first filtered data; Step S122: Traverse the first filtered data according to the time sequence and determine the consecutive identical operation intervals. Only retain the first and last data of the consecutive identical operation intervals to obtain the second filtered data. Step S123: Merge adjacent addresses in the second filtered data to obtain the third filtered data; Step S124: Filter the third filtered data to obtain cached abnormal records to form the valid data.

2. The SOC chip dynamic verification method according to claim 1, characterized in that, Step S13 includes: calculating the read-write ratio feature, sequence complexity feature, concurrency feature, and cache anomaly feature respectively, and then normalizing and concatenating them to obtain the feature vector; The calculation process for the read / write ratio feature includes: R / W_ratio = read operands / (read operands + write operands); The calculation process for the sequence complexity feature includes: Seq_complexity = Number of state transitions in the sequence / Sequence length; The calculation process for the concurrency characteristic includes: Concurrency = Number of concurrently active threads / Maximum number of threads; The calculation process for the cache anomaly characteristics includes: Cache_anomaly = Number of abnormal state transitions / Total number of state transitions.

3. The SOC chip dynamic verification method according to claim 1, characterized in that, In step S2, the decision tree model includes: A gain calculation module, wherein the gain calculation module calculates the information gain for each feature of the input feature vector; A node generation module, which is connected to the gain calculation module; The node generation module generates split nodes by comparing the information gain and the gain threshold. Multiple split nodes constitute a decision tree; A path rule generation module, which is connected to the node generation module; The path rule generation module generates decision tree path rules by sequentially reading the split nodes and adds test case markers indicating whether the rules are usable for testing. In step S2, the risk memory data is obtained by filtering based on the decision tree path rules.

4. The SOC chip dynamic verification method according to claim 1, characterized in that, Step S3 includes: Step S31: Clean the risky memory data and generate valid test parameters; Step S32: Generate a normal output range for the valid test parameters to obtain example test cases; Step S33: Expand the example use case to obtain the test case.

5. The SOC chip dynamic verification method according to claim 4, characterized in that, Step S31 includes: Step S311: Fill the missing values ​​of the risk memory data with the historical average to obtain the first cleaned data; Step S312: Mark outliers in the first cleaned data and remove data with excessively high outliers to obtain the second cleaned data; Step S313: Check the timestamp continuity of the second cleaning data and segment the power outage data to obtain the third cleaning data; Step S314: Standardize the format of the third cleaning data to obtain the fourth cleaning parameters; Step S315: Determine the validity and prioritize the fourth cleaning parameter to obtain the valid test parameters.

6. The SOC chip dynamic verification method according to claim 4, characterized in that, Step S32 includes: Step S321: Establish a benchmark verification test for the effective test parameters and obtain the benchmark test results; Step S322: Statistically obtain the distribution of benchmark output results based on the benchmark test results; Step S323: Generate the normal output range based on the baseline output result distribution and assemble the example use case.

7. The SOC chip dynamic verification method according to claim 4, characterized in that, Step S33 includes: Step S331: Expand the parameter range according to the example use case to obtain the expanded parameters; Step S332: Generate the corresponding desired output based on the amplification parameters; Step S333: Obtain the test cases according to the amplification parameters and the expected output.

8. The SOC chip dynamic verification method according to claim 3, characterized in that, Step S4 includes: Step S41: Test the SOC chip using the test cases to obtain actual test results; Step S42: Generate consistency issue trigger points based on the actual test results; Step S43: Update the split node of the decision tree according to the consistency problem trigger point.

Images