Chip data storage method and apparatus

Abstract

This application relates to a chip data storage method and apparatus. The method includes: acquiring chip data to be stored, and determining the data type and size of the chip data to be stored; determining a target data storage method based on the data type and size; and storing the chip data to be stored based on the target data storage method. This method optimizes the storage method for chip data of different data types and sizes, adaptively allocating memory, and is particularly effective in efficiently storing and managing data from multiple sites in a test machine. It solves the memory fragmentation problem of traditional methods and avoids using different storage containers for different types and sizes of data, thus avoiding performance issues caused by storage.

Description

Technical Field

[0001] This application relates to the field of semiconductor technology, and in particular to a chip data storage method and apparatus. Background Technology

[0002] Test machine chip data processing typically relies on general-purpose STL containers (Standard Template Library), specific type containers, and other third-party container libraries, such as std::vector, std::map, and std::list. These containers are used to manage and store the large amounts of data generated during testing, including chip status, test results, and test parameters. These containers can store various data types, including built-in types, complex numbers, vectors, and matrices, making them suitable for small-scale testing or simple scenarios.

[0003] However, in test machine data scenarios, data sizes vary widely, from small data sets of only tens of bytes to large data sets of tens of gigabytes. In real-world applications, targeted storage optimization is needed for small, medium, and large datasets to reduce memory fragmentation and efficiency issues. Specifically, traditional technologies in standard container libraries require users to explicitly and dynamically select the container type based on the data volume. This can easily lead to incorrect container type selection when processing large amounts of test data, resulting in performance problems. Summary of the Invention

[0004] Therefore, it is necessary to provide a chip data storage method and apparatus that can avoid performance problems caused by storage, in order to address the above-mentioned technical problems.

[0005] In a first aspect, this application provides a chip data storage method, the method comprising:

[0006] Acquire the data of the chip to be stored, and determine the data type and size of the data.

[0007] Based on the data type and size, determine the target data storage method;

[0008] The data of the chip to be stored is stored based on the target data storage method.

[0009] In one embodiment, the data type includes pod type, non-pod type, and preset type, wherein the non-pod type includes matrix and vector; determining the target data storage method based on the data type and size includes:

[0010] When the data type is pod, the target data storage method is determined to be a combined storage method of inline storage and object pool;

[0011] If the data type is not pod type, determine whether the data to be stored on the chip is a preset type of data;

[0012] If the data to be stored in the chip is of a preset type, the target data storage method is determined to be a pre-allocated memory storage method;

[0013] If the data to be stored is not of a preset type and the size of the data to be stored is less than or equal to the distinction threshold, the target data storage method is determined to be a shared memory storage method.

[0014] If the data to be stored is not of a preset type and the size of the data to be stored is greater than the distinction threshold, the target data storage method is determined to be system memory storage.

[0015] In one embodiment, storing the chip data to be stored based on the target data storage method includes:

[0016] When the target data storage method is a combined storage method of inline storage and object pool, the target object is determined based on the stack memory corresponding to the object pool, and the chip data to be stored is stored into the target object in the object pool based on the inline storage.

[0017] When the target data storage method is pre-allocated memory storage, the first call location memory corresponding to the pre-allocated memory is determined, the corresponding first address memory is determined based on the first call location memory, and the chip data to be stored is stored into the corresponding pre-allocated memory based on the address of the pre-allocated memory in the first address memory.

[0018] When the target data storage method is shared memory storage, the second call location memory corresponding to the shared memory is determined, the corresponding second address memory is determined based on the second call location memory, and the chip data to be stored is stored into the corresponding shared memory based on the address of the shared memory in the second address memory.

[0019] When the target data storage method is system memory storage, the data of the chip to be stored is stored in system memory.

[0020] In one embodiment, the method further includes:

[0021] Receive status data operation request, wherein the status data is the status of each test site in each chip under test;

[0022] Based on the status data operation request and the pre-allocated contiguous target memory, the status data is processed, wherein the status data is stored separately from the data to be stored in the chip.

[0023] In one embodiment, the state data includes multiple levels, each level being a global state, a test item state, and a state corresponding to chip data; the operation processing of the state data based on the state data operation request and pre-allocated contiguous target memory includes:

[0024] Access determines the global state and the test item state;

[0025] When the global state, test item state, and chip data corresponding state are initially assigned values, a first target state object is determined from the target memory based on the global state, test item state, and chip data corresponding state, the state corresponding to the chip data is stored in the first target state object, and the pointer is pointed to the first target state.

[0026] If the global state, test item state, and chip data corresponding state are not initially assigned values, a second target state object is determined from the target memory based on the global state, test item state, and chip data corresponding state. The original target state object pointed to by the pointer is removed, and the state corresponding to the chip data is stored in the second target state object. The pointer is then pointed to the second target state object, wherein the removed original target state object becomes a usable object.

[0027] In one embodiment, the receiving status data operation request includes:

[0028] Receive status data operation requests sent by each parallel thread;

[0029] The operation processing of the state data based on the state data operation request and the pre-allocated contiguous target memory includes:

[0030] Acquire the read-write lock of the target state object determined in the target memory;

[0031] If a read-write lock is acquired on the target state object, each state data is stored in the target state object within a pre-allocated contiguous target memory.

[0032] In one embodiment, the method further includes:

[0033] Verify the global state, test item state, and chip data corresponding state stored in the contiguous target memory;

[0034] If the status verification of the global state, test item state, and chip data fails, an error message will be output.

[0035] In one embodiment, the method further includes:

[0036] The error type is determined based on the error information;

[0037] Determine the error handling mode based on the error type;

[0038] Error handling is performed according to the determined error handling mode.

[0039] In one embodiment, the method further includes:

[0040] Whether to initiate parallel processing is determined based on the size of the data to be stored in the chip.

[0041] When parallel processing is initiated, thread resources are acquired, and target parallel threads are determined based on the size of the data to be stored in the chip and the thread resources.

[0042] The data to be stored in the chip is processed in parallel by each of the target parallel threads.

[0043] In one embodiment, the method further includes:

[0044] When the data size of the chip data to be stored is greater than the calculation threshold, the processing procedure corresponding to the chip data to be stored is decomposed into multiple independent processing stages, and the chip data to be stored is processed sequentially based on each of the processing stages, wherein each of the independent processing stages is connected in a pipeline manner.

[0045] Secondly, this application also provides a chip data storage device, the device comprising:

[0046] The data acquisition module is used to acquire data from the chip to be stored and to determine the data type and size of the data.

[0047] The storage method determination module is used to determine the target data storage method based on the data type and size.

[0048] A storage module is used to store the chip data to be stored based on the target data storage method.

[0049] The aforementioned chip data storage method and apparatus acquire chip data to be stored and determine the data type and size of the chip data to be stored; based on the data type and size, determine a target data storage method; and based on the target data storage method, store the chip data to be stored. This optimizes the storage method for chip data of different data types and sizes, adaptively allocates memory, and efficiently stores and manages data from multiple sites, especially in test machines. It solves the memory fragmentation problem of traditional methods and avoids using different storage containers for different types and sizes of data, thus avoiding performance problems caused by storage. Attached Figure Description

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

[0051] Figure 1 This is a flowchart illustrating a chip data storage method in one embodiment;

[0052] Figure 2 Here is a flowchart of step S104 in one embodiment;

[0053] Figure 3 This is a comparison chart of inline storage and non-inline storage in one embodiment;

[0054] Figure 4 This is a schematic diagram of the combined inline storage and object pool storage in one embodiment;

[0055] Figure 5 This is a schematic diagram of the object pool SOO objects and the shared memory pool storing objects in one embodiment;

[0056] Figure 6 This is a schematic diagram comparing the coexistence and independent storage of SiteMask state and data in one embodiment;

[0057] Figure 7 This is a schematic diagram illustrating the relationship between the state pool, state objects, and data objects in one embodiment.

[0058] Figure 8 Here is a flowchart of the SiteMask status setting and updating process in one embodiment;

[0059] Figure 9 This is a schematic diagram of an error handling process in one embodiment;

[0060] Figure 10 This is a flowchart of the hardware adaptive parallel computing workflow in one embodiment;

[0061] Figure 11 This is a memory diagram illustrating the storage of a large data structure in one embodiment;

[0062] Figure 12 Here is a flowchart of the site data operation interface and intelligent data management process optimized for copy-on-write in one embodiment;

[0063] Figure 13 This is a schematic diagram of pipeline data processing and lazy evaluation in one embodiment;

[0064] Figure 14 This is a structural block diagram of a chip data storage device in one embodiment;

[0065] Figure 15 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0066] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0067] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0068] In one embodiment, such as Figure 1 As shown, a chip data storage method is provided. This embodiment illustrates the application of this method to a terminal. It is understood that this method can also be applied to a server, and further to a system including both a terminal and a server, and is implemented through interaction between the terminal and the server. In this embodiment, the method includes the following steps:

[0069] S102: Obtain the data to be stored from the chip and determine the data type and size of the data.

[0070] The data to be stored on the chip refers to the test data obtained during each site test, i.e., SiteData. The data types of the data to be stored on the chip include pod type (Plain Old Data, simple data structure), non-pod type, and preset types. Non-pod types include matrices and vectors. The size of the data to be stored on the chip is related to the data type. Generally, the data size of pod type is between 80-144 bytes. Optionally, the data size of small pod type is less than 32 bytes, and the number of sites is less than 8. The size of non-pod type includes normal size and extremely large type. A threshold can be set to distinguish between normal size and extremely large type, and the size of non-pod type can be distinguished based on this threshold.

[0071] S104: Determine the target data storage method based on data type and size.

[0072] In this embodiment, the data type of the chip data to be stored can be obtained, such as pod type, non-pod type, and preset type, wherein the preset type may include multidimensional array or specific data structure; then the size of the chip data to be stored corresponding to the data type can be obtained; finally, the target data storage method is determined based on the data type and size.

[0073] S106: Stores the chip data to be stored based on the target data storage method.

[0074] Once the target data storage method is determined, it can be used to store the data of the chip to be stored, avoiding excessive overhead when allocating single data and reducing the generation of memory fragmentation.

[0075] The aforementioned chip data storage method acquires the chip data to be stored and determines its data type and size; based on the data type and size, it determines the target data storage method; and based on the target data storage method, it stores the chip data to be stored. This method optimizes the storage of chip data of different data types and sizes, adaptively allocates memory, and efficiently stores and manages data from multiple sites, especially in test machines. It solves the memory fragmentation problem of traditional methods and avoids using different storage containers for different types and sizes of data, thus avoiding performance issues caused by storage.

[0076] In some alternative embodiments, combined with Figure 2 As shown, Figure 2The flowchart for step S104 in one embodiment is as follows. Step S104, which determines the target data storage method based on data type and size, includes: if the data type is pod, determining the target data storage method as a combined storage method of inline storage and object pool; if the data type is not pod, determining whether the data to be stored is of a preset data type; if the data to be stored is of a preset data type, determining the target data storage method as a pre-allocated memory storage method; if the data to be stored is not of a preset data type and its size is less than or equal to a distinction threshold, determining the target data storage method as a shared memory storage method; if the data to be stored is not of a preset data type and its size is greater than a distinction threshold, determining the target data storage method as a system memory storage method.

[0077] In this application, when the data type is pod, a combined storage method of inline storage and object pooling is used. Figure 3 As shown, Figure 3 This diagram compares inline and non-inline storage in one embodiment. Inline storage stores data directly within the data object, rather than allocating additional memory, thus avoiding the overhead of memory allocation. This effectively improves the speed of accessing small data and reduces the cost of memory allocation and reclamation. SOO (Small Object Optimization) is particularly suitable for frequently accessed small data structures, such as scalar data types and simple arrays. Furthermore, to avoid SOO optimization causing objects to reach hundreds of bytes in size and severely compressing the available runtime stack space, this application also introduces an object pool mechanism to alleviate the stack space pressure brought by SOO technology and improve the availability of the software system in complex scenarios. For example, combining... Figure 4 As shown, Figure 4 This illustration shows a combined inline storage and object pool storage in one embodiment. An object pool is provided in this application, with a size of 4MB (other sizes are possible in other embodiments). This object pool centrally manages small data objects, avoiding memory allocation every time they are used, thus improving memory management efficiency. The object pool can dynamically reclaim and reuse memory, reducing fragmentation. Because the object pool stores small inline pod objects, PIMLP and type erasure technologies are employed in the design and implementation. This approach further isolates the implementation and interface, providing a stable binary interface and ensuring the stability of software interface releases.

[0078] Specifically, when it is detected that the data to be stored on the chip is not of type pod, it is then checked whether the data to be stored on the chip is of a preset type. For non-pod type data, the data structure is more complex and the memory requirement is larger. This application determines the corresponding target data storage method based on the data type and size.

[0079] When the data to be stored in the chip is of a preset type, such as data in an object with a multidimensional array or a specific data structure, a pre-allocated memory storage method can be adopted. The pre-allocated memory storage method can use a non-pod object memory pool. In other embodiments, the size of the non-pod object memory pool can be 64MB. This non-pod object memory pool is specifically used to manage large and complex objects. In this way, by introducing a memory pool corresponding to the preset type of data, that is, by pre-allocating a large memory block, the non-pod object pool can effectively reduce the fragmentation problem and ensure the efficient use of storage space.

[0080] If the data to be stored on the chip is not of a preset type, the target data storage method can be determined based on the size of the data to be stored on the chip.

[0081] If the data to be stored on the chip is not of a preset type, the target data storage method can be determined based on the size of the data. For example, it can be determined whether the current site's data volume exceeds a distinguishing threshold; if so, system memory storage is used; otherwise, shared memory storage is used. Figure 5 As shown, Figure 5 This diagram illustrates the object pool (SOO) and shared memory pool storage objects in one embodiment. For non-pod types, such as larger or more complex data types (e.g., matrices, vectors), a 16MB shared memory pool (data pool) is used. This memory pool provides a shared memory area for data of different sizes, avoiding excessive overhead during single data allocation and reducing memory fragmentation, ensuring memory consistency during large-scale data storage. For particularly large non-pod objects (e.g., extremely large matrices, large vectors), i.e., data sizes exceeding the distinguishing threshold, this embodiment provides a system memory allocation strategy. This strategy avoids additional limitations of the memory pool, directly utilizing the operating system's memory management system for allocation, ensuring that large-scale data objects can be fully stored while avoiding wasted memory pool space. This design ensures that even with extremely high memory requirements, the system maintains efficient memory utilization and data processing capabilities.

[0082] In some optional embodiments, storing the chip data to be stored based on the target data storage method includes: when the target data storage method is a combined storage method of inline storage and object pool, determining the target object based on the stack memory corresponding to the object pool, and storing the chip data to be stored in the target object in the object pool based on inline storage; when the target data storage method is a pre-allocated memory storage method, determining the first call location memory corresponding to the pre-allocated memory, determining the corresponding first address memory based on the first call location memory, and storing the chip data to be stored in the corresponding pre-allocated memory based on the address of the pre-allocated memory in the first address memory; when the target data storage method is a shared memory storage method, determining the second call location memory corresponding to the shared memory, determining the corresponding second address memory based on the second call location memory, and storing the chip data to be stored in the corresponding shared memory based on the address of the shared memory in the second address memory; when the target data storage method is a system memory storage method, storing the chip data to be stored in system memory.

[0083] For ease of understanding, the above is combined with... Figure 3 and Figure 4 As shown, when the target data storage method is a combined storage method of inline storage and object pool, the address of the target object is first determined according to the stack memory corresponding to the object pool. Then, based on the inline storage and the address of the target object, the data to be stored in the chip is stored in the target object in the object pool. The data is stored directly in the object to avoid the extra overhead of memory allocation, and the target object is indexed through the stack to avoid the storage pressure of the stack space.

[0084] If the target data storage method is pre-allocated memory storage, the first call location memory corresponding to the data is directly determined. Then, based on the dynamic allocation method and the pre-allocated memory pointed to by each first call location in the first call location memory, the pre-allocated memory is allocated. That is, the first address memory is first determined, which is the heap memory that stores the address. Then, based on the first address stored in the heap memory, the pre-allocated memory is determined, and then the data is stored in the pre-allocated memory.

[0085] If the target data storage method is shared memory storage, then the second call location memory is determined. Then, based on the dynamic allocation method and the shared memory pointed to by each second call location in the second call location memory, the shared memory is allocated. That is, first, the second address memory, i.e. the heap memory that stores the address, is determined. Then, based on the second address stored in the heap memory, the shared memory is determined, and then the data is stored in the shared memory.

[0086] If the target data storage method is system memory storage, then the data will be directly stored in system memory.

[0087] In the above embodiments, an adaptive memory allocation mechanism and a multi-layered memory pool design dynamically adjust memory management strategies based on data type, scale, and usage scenario. For small data types, SSO optimization technology is used to improve performance; for medium-sized data, object pools and shared memory pools are used to improve memory utilization efficiency; and for large-scale data, system memory allocation is used to ensure storage capacity. The overall design significantly improves memory utilization efficiency, reduces memory fragmentation, and optimizes data access performance. This enables the test machine chip to not only have higher efficiency when processing large-scale data but also maintain superior stability.

[0088] In some optional embodiments, the method further includes: receiving a status data operation request, wherein the status data is the status of each test site in each chip under test; and performing operation processing on the status data based on the status data operation request and pre-allocated contiguous target memory, wherein the status data is stored separately from the chip data to be stored and managed independently.

[0089] One chip corresponds to one site, and a chip has multiple test site states. Each test site state corresponds to a site mask (SiteMask). The site mask (SiteMask) is a key tool for marking the state of each test site, allowing the real-time reflection of each chip's state during testing, such as "on" or "off". In this application, the SiteMask state is stored separately from the chip data to be stored, ensuring that the state information and the data itself are managed independently, thereby achieving more efficient memory utilization and more flexible state management.

[0090] The pre-allocated contiguous target memory is used to store state data. This way, when a state data operation request is received, the corresponding data in the pre-allocated contiguous target memory can be processed directly, reducing memory allocation operations and minimizing memory fragmentation.

[0091] Combination Figure 6 As shown, Figure 6 This diagram illustrates a comparison between the coexistence and independent storage of SiteMask state and data in one embodiment. In this embodiment, the state information of each site is stored independently from the data to be stored on the chip. The state of each site is represented by an independent mask, and each site uses an independent bit (e.g., on / off, pass / fail). The state and the data to be stored on the chip no longer interfere with each other. Since the state of each site only occupies one bit, the overall data volume is usually very small. Therefore, using a pre-allocated state pool can significantly accelerate the creation, management, and destruction of SiteMask states.

[0092] In some optional embodiments, the state data includes multiple levels, each level being the global state, the test item state, and the state corresponding to the chip data. Based on the state data operation request and pre-allocated contiguous target memory, the state data is processed, including: accessing and determining the global state and the test item state; if the global state, the test item state, and the state corresponding to the chip data are initially assigned values, determining a first target state object from the target memory based on the global state, the test item state, and the state corresponding to the chip data, storing the state corresponding to the chip data in the first target state object, and pointing a pointer to the first target state; if the global state, the test item state, and the state corresponding to the chip data are not initially assigned values, determining a second target state object from the target memory based on the global state, the test item state, and the state corresponding to the chip data, removing the original target state object pointed to by the pointer, storing the state corresponding to the chip data in the second target state object, and pointing a pointer to the second target state object, wherein the removed original target state object becomes a usable object.

[0093] For ease of understanding, combined with Figure 7 As shown, Figure 7 This is a schematic diagram illustrating the relationship between the state pool, state objects, and data objects in one embodiment. To improve access speed and storage efficiency, the state data in this application employs multi-level storage. Figure 7 The system employs a three-level state management mechanism, with the three levels being the global state, the test item state, and the state corresponding to the chip data.

[0094] The global state is used to mark the overall state of all sites, suitable for states that need to be controlled and managed throughout the testing process, such as the overall success or failure of a test task. Data objects do not own the global SiteMask state; they can only access it.

[0095] Test item states are marked for each individual test item, ensuring that state management between different test items does not interfere with each other and allowing for flexible switching of test scenarios. In actual implementation, test items are strongly bound to threads, and TLS technology is used to isolate test item SiteMasks, eliminating the need to manage test item SiteMasks. Data objects do not own the state of test item SiteMasks; they can only access it.

[0096] Test data status is recorded during each test, precisely marking the progress of each test stage, suitable for refined test data processing tasks. Data objects own the sitemask status for a single test and are readable and writable.

[0097] This application optimizes the storage of global SiteMask, test item SiteMask, and single-data SiteMask information, and centralizes the management of these information, thereby solving the efficiency problem of state update and query during multi-site parallel testing.

[0098] Among them, combined Figure 8 As shown, Figure 8 This is a flowchart illustrating the SiteMask state setting and updating workflow in one embodiment. First, the global state and test item state are accessed. Then, it is determined whether this is the first copy. If it is the first assignment, a first target state object is determined from the target memory based on the global state, test item state, and the state corresponding to the chip data. The state corresponding to the chip data is stored in the first target state object, and the pointer is set to point to the first target state. In other words, when a new state mask is needed, an object (or a set of bits) is directly allocated from the pool, without frequently requesting memory from the operating system.

[0099] If it's not the initial assignment, a second target state object is determined from the target memory based on the global state, test item state, and the state corresponding to the chip data. The original target state object pointed to by the pointer is removed, and the state corresponding to the chip data is stored in the second target state object. The pointer is then set to point to the second target state object. The removed original target state object becomes a usable object. In other words, when a state object (such as the DataSiteMask after a single test) is no longer referenced, the memory it occupies is marked as free and can be allocated and reused later, rather than being truly released. In parallel testing across multiple sites, the state pool can dynamically update and reuse state information. After each test data usage, the used SiteMask information is marked as a reusable resource, thus avoiding redundant memory allocation and reducing memory waste. At the same time, the state pool's update mechanism ensures that the state information remains consistent with the testing process.

[0100] In the above embodiments, the state information of all three levels of SiteMask is centrally stored in a large state pool and managed through hierarchical storage. Each level of SiteMask can be optimized according to its storage and access frequency. The global SiteMask and test item SiteMask adopt efficient storage methods to support fast access and updates; while the state of a single Mask is managed through a fine-grained storage mechanism to avoid unnecessary memory overhead.

[0101] In some optional embodiments, receiving state data operation requests includes: receiving state data operation requests sent by each parallel thread; and performing operation processing on state data based on the state data operation requests and pre-allocated contiguous target memory, including: acquiring a read-write lock on a target state object determined in the target memory; and, if the read-write lock on the target state object is acquired, storing each state data in the target state object in the pre-allocated contiguous target memory.

[0102] In this application, each state data object contains a read-write lock to ensure the safety of concurrent access. In multi-site parallel testing, multiple parallel threads exist, each receiving state data operation requests. Generally, each parallel thread operates on different storage chip data or state data, allowing multiple threads to access state information from different sites concurrently, ensuring the efficiency and security of state management during multi-site parallel testing. However, if multiple parallel threads operate on the same storage chip data, a read-write lock is introduced to avoid operational errors. Each thread needs to acquire a read-write lock on a pre-allocated contiguous target memory. This lock allows state data to be stored in a target state object within the pre-allocated contiguous target memory. Only the thread with the read-write lock can write state data, preventing chaos caused by multiple threads writing to the same state data object.

[0103] In the above embodiments, the state pool design specifically considers the needs of parallel computing and multi-threaded access. Through an efficient concurrency management mechanism, multiple threads can access the state information of different sites in parallel, ensuring the efficiency and security of state management during multi-site parallel testing. The internal design of the state pool ensures independent read and write operations between threads, avoiding access conflicts and improving the stability of parallel testing.

[0104] In some optional embodiments, the method further includes: verifying the global state, test item state, and chip data stored in contiguous target memory; and outputting error information if the verification of the global state, test item state, and chip data state fails.

[0105] In actual testing, the state pool not only supports efficient state storage and retrieval, but also ensures the validity and consistency of state information through a state checking mechanism.

[0106] The status information of each site is stored in a discrete form in a status pool, and can be queried and updated at any time. By introducing a status inspection mechanism, the validity and consistency of the current SiteMask can be verified on each access. If an anomaly is found in the status information, an error handling mechanism will be triggered to correct it, and the error will be handled or reported according to the error level.

[0107] This status check mechanism verifies the global status, test item status, and chip data status in the target memory to ensure that the global status, test item status, and chip data status are consistent. For example, if all chip data statuses pass the verification, the test item statuses should also pass the verification. If each test item status passes the verification, the global status should also pass the verification. In this embodiment, if the global status, test item status, and chip data status are inconsistent, an error can be reported.

[0108] In the above embodiments, a status check mechanism is introduced to ensure that the validity and consistency of the current SiteMask can be verified each time it is accessed. If abnormal status information is found, an error handling mechanism will be triggered to correct it, and error processing or reporting will be performed according to the error level.

[0109] In some optional embodiments, the method further includes: determining an error type based on error information; determining an error handling mode based on the error type; and performing error handling according to the determined error handling mode.

[0110] The error types include critical errors, non-critical errors, and minor errors. In this application, the types and impacts of errors typically have different levels, therefore, appropriate handling methods need to be adopted according to the severity of the errors.

[0111] Critical errors can cause the entire testing process to fail and even affect the functional integrity of the chip being tested. Examples include hardware failures, corruption of important data, and serious system anomalies. When faced with a critical error, the system will trigger a fast-fail mechanism, immediately stopping the current test and reporting the error upon detection. This prevents the error from spreading and causing more serious consequences. For critical errors, the system will not continue executing the current test task but will terminate the process and output a detailed error report for developers to fix. Critical errors typically occur when system resources are overloaded, hardware fails, or operational errors occur, and their impact is widespread and severe. In such cases, timely stopping of the test helps reduce unnecessary resource consumption and prevents the error from spreading in the system, thereby protecting the safety of the device and data.

[0112] Non-critical errors have a minor impact on the overall system performance and test results. They are typically edge cases or minor anomalies, possibly related to data inconsistencies or minor test item failures. For example, inaccurate test results for a particular site or the inability to complete certain operations may not affect the overall test results. In these cases, the system logs the error and continues execution. Users can identify and handle these issues based on the error log without immediately halting the entire test task. Non-critical errors often occur occasionally during testing; they may affect the results of individual tasks but do not disrupt the overall test flow. To avoid excessive interruptions when these errors occur, the system allows execution to continue while providing error tracking for later optimization.

[0113] Minor errors are typically associated with very minor issues or occasional testing errors. They do not have a substantial impact on test results and are usually just some slight anomalies or data fluctuations. The system logs and monitors these minor errors but does not trigger any other actions. Minor errors generally originate from environmental changes, minor hardware fluctuations, or small random factors during testing. Although they have a minimal impact on the overall test results of the system, they still need to be logged for monitoring and analysis.

[0114] In this embodiment, different error handling modes are configured for different error types to ensure that the system can minimize losses when encountering errors, while improving fault tolerance.

[0115] To flexibly handle different error types and operating modes, this embodiment also includes three working modes: debug mode, mass production mode, and hybrid mode. Each mode employs a different error handling strategy, helping developers and operators select the most appropriate error handling method based on different testing scenarios. Figure 9 As shown, Figure 9 This is a schematic diagram of an error handling process in one embodiment.

[0116] In debug mode, the system logs all errors in detail and provides as much information as possible to developers for debugging and fixing. For critical errors, the system triggers a fast failure and reports the error; for non-critical errors, the system logs the error and continues executing the test. Debug mode allows developers to deeply analyze errors, helping to optimize the system's stability and performance.

[0117] In mass production mode, the system ensures the continuity of the testing process to the greatest extent possible. In this mode, non-critical errors are ignored or only logged to ensure smooth testing during mass production. Critical errors still trigger the fail-fast mechanism to prevent the spread of errors in large-scale production. Mass production mode emphasizes testing efficiency and reliability, minimizing interruptions during error handling.

[0118] The hybrid mode combines the features of debug and production modes, dynamically switching according to the actual situation. In the early stages of testing, the system can enter debug mode to provide more detailed error information; as testing progresses, the system can automatically switch to production mode, ensuring efficiency while still monitoring and handling important errors.

[0119] Regardless of the error type, all errors are logged in the error log, which is then analyzed to help developers optimize the system. The error log not only contains the error type and location, but also records relevant system status information for subsequent analysis and debugging. By analyzing the error log, developers can identify potential problems in the system and optimize testing processes and chip performance.

[0120] In the above embodiments, different handling measures are automatically taken based on the severity of the error and the application scenario. Through this strategy, the system can not only respond quickly to critical errors but also ensure the continuation of the testing process when non-critical errors occur, and effectively record error information for subsequent analysis and optimization. The tiered error strategy combines handling mechanisms for different error types, ensuring that the system can take different measures according to the actual situation when errors occur, thereby improving the system's stability and flexibility. Through three working modes and intelligent error management, the system can automatically adjust its behavior in different application scenarios, providing developers and operators with a more efficient and reliable testing platform.

[0121] In some optional embodiments, the method further includes: determining whether to initiate parallel processing based on the size of the data to be stored on the chip; if parallel processing is initiated, acquiring thread resources, determining target parallel threads based on the size of the data to be stored on the chip and the thread resources; and performing parallel processing on the data to be stored on the chip through the target parallel threads.

[0122] In order to improve the efficiency of the test machine chip when processing large-scale data to be stored, this application can determine whether to start parallel processing. For example, if the size of the data to be stored is greater than a certain threshold, parallel processing is adopted. However, parallel processing needs to take into account hardware resources, such as thread resources, to determine the number of target parallel threads, and then the data to be stored can be processed by the target parallel threads.

[0123] Combination Figure 10 As shown, Figure 10This is a hardware adaptive parallel computing workflow diagram in one embodiment. When it is determined that parallel processing is to be used, thread resources are acquired, and each target parallel thread is determined based on the size of the data to be stored on the chip and the thread resources. That is, the computing process can be dynamically optimized according to different hardware resource configurations and task loads. Thus, the data to be stored on the chip can be processed in parallel by each target parallel thread to improve processing efficiency.

[0124] This application automatically monitors the hardware load (i.e., the size of the data to be stored on the chip) and adjusts the parallelism according to the testing requirements to ensure optimal allocation of system resources (thread resources), thereby improving the efficiency of multi-site parallel computing. The above embodiments solve the problem that traditional parallel computing architectures cannot flexibly adapt to changes in hardware configuration and load, improve the system's flexibility and responsiveness when handling a large number of test tasks, significantly simplify users' consideration of hardware resources when processing multi-threaded data, and improve performance under complex hardware conditions.

[0125] In some optional embodiments, determining the target data storage method based on the data type and size includes: determining an optimization strategy for the chip data to be stored based on the data type and size; and optimizing the chip data to be stored based on the optimization strategy.

[0126] This application employs an adaptive computation model that automatically selects the most suitable optimization strategy based on data type and size, significantly improving computation speed, especially in large-scale data scenarios. Specifically, it uses a dynamic adaptation strategy to adjust the computation method according to different data types and data sizes, thereby increasing computation speed. Optimization for specific types of algorithms reduces memory resource waste during computation. Optimization for specific types of algorithms refers to applying different optimization rules to basic built-in types, complex numbers, vectors, and matrices.

[0127] In this application, for basic built-in types (such as scalar types like int, float, and double) and struct pod types, inline storage (SOO) and object pooling techniques are used for optimization; for complex number types (siteComplex), vectorized operations are accelerated using the SIMD instruction set; for vector types (std::vector) and small to medium-sized matrix data, a shared memory pool is used in conjunction with a reference counting mechanism, and a copy-on-write (COW) strategy is enabled when the data volume exceeds the distinguishing threshold; for large and sparse matrices, block storage and CSR format compression techniques are used to optimize memory access efficiency; and for string types (std::string), a string resident pool is used to avoid redundant storage.

[0128] Data size is divided into four levels: stack inline storage is used when the data size is less than 32 bytes; a shared memory pool is used when the data size is 32 bytes to 1KB; copy-on-write mechanism is enabled when the data size is 1KB to 1MB; and a system-level memory allocator is used when the data size is greater than 1MB, in conjunction with block loading and caching optimization techniques.

[0129] In some optional embodiments, the method further includes: receiving a data operation request for data to be stored in the chip; if the data operation request is to copy or transfer the data to be stored in the chip, copying pointer data of the data to be stored, and copying or transferring the data to be stored in the chip based on the copied pointer data; if the data operation request is to modify the data to be stored in the chip, copying the data to be stored in the chip, and modifying the copied data to be stored.

[0130] During testing, data operations at each site require high efficiency and flexibility. Traditional operation interfaces cannot provide fine-grained management of the status and data types of each site. This application designs an intelligent data management interface that enables dynamic adjustment and optimization of data for each site. Through intelligent data lifecycle management, this application automatically analyzes the size of data at each site in the test scenario, optimizes data storage methods and access paths, and combines... Figure 11 and Figure 12 As shown, Figure 11 This is a memory diagram illustrating the storage of a large data structure in one embodiment. Figure 12 This is a flowchart of the site data operation interface and intelligent data management process optimized for copy-on-write in one embodiment.

[0131] For large data structures, Copy-on-Write (COW) optimization is adopted to reduce the data copying cost of a single site, thereby improving the overall data operation efficiency across multiple sites. Specifically, when the data operation request is to copy or transfer the data to be stored, only the pointer data of the data to be stored is copied, instead of copying the entire data to be stored, thus reducing the number of copies. Furthermore, when the data operation request is to modify the data to be stored, the data to be stored is copied, and the copied data to be stored is modified.

[0132] Compared with traditional single data structures, this application can dynamically optimize operations according to the data characteristics and real-time needs of different sites, reducing multiple data copying, memory overhead and performance bottlenecks.

[0133] In some optional embodiments, the method further includes: when the data size of the chip data to be stored is greater than a calculation threshold, decomposing the processing process corresponding to the chip data to be stored into multiple independent processing stages, and processing the chip data to be stored sequentially based on each processing stage, wherein each independent processing stage is connected in a pipeline manner.

[0134] In some optional embodiments, the data to be stored on the memory chip is processed sequentially based on each processing stage, including: when the current processing stage is reached, the data to be stored on the memory chip involved in the current processing stage is processed.

[0135] Combination Figure 13 As shown, Figure 13 This is a schematic diagram of pipelined data processing and lazy evaluation in one embodiment. To improve memory utilization efficiency and reduce unnecessary computation, a pipelined data processing and lazy evaluation mechanism is introduced. Pipeline processing decomposes the processing of data to be stored into multiple independent processing stages, allowing data to flow and be processed step-by-step within these stages.

[0136] Lazy evaluation ensures that computations are performed only when needed, meaning that only the data to be stored on the chip relevant to the current processing stage is processed. This strategy is particularly suitable for processing large-scale data, reducing the cost of intermediate data storage and computation.

[0137] In the above embodiments, by treating the data processing flow as a pipeline and combining it with lazy evaluation, the memory consumption of pre-calculating all results in the traditional approach is avoided. The system performs on-demand calculations based on the needs of the data flow, significantly reducing the waste of memory and computing resources.

[0138] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0139] Based on the same inventive concept, this application also provides a chip data storage device for implementing the chip data storage method described above. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more chip data storage device embodiments provided below can be found in the limitations of the chip data storage method described above, and will not be repeated here.

[0140] In one exemplary embodiment, such as Figure 14 As shown, a chip data storage device is provided, including: a data acquisition module 1401, a storage mode determination module 1402, and a storage module 1403, wherein:

[0141] The data acquisition module 1401 is used to acquire data from the chip to be stored and to determine the data type and size of the data.

[0142] The storage method determination module 1402 is used to determine the target data storage method based on the data type and size;

[0143] Storage module 1403 is used to store the data of the chip to be stored based on the target data storage method.

[0144] In some optional embodiments, the data types include pod type, non-pod type, and preset type, where non-pod type includes matrix and vector. Specifically, the storage method determination module 1402 is used to: determine if the data type is pod type, the target data storage method is a combined storage method of inline storage and object pool; determine if the data type is non-pod type, whether the data to be stored is of a preset type; determine if the data to be stored is of a preset type, the target data storage method is pre-allocated memory storage; determine if the data to be stored is not of a preset type and its size is less than or equal to a distinction threshold, the target data storage method is shared memory storage; and determine if the data to be stored is not of a preset type and its size is greater than a distinction threshold, the target data storage method is system memory storage.

[0145] In some optional embodiments, the storage module 1403 is specifically used as follows: when the target data storage method is a combined storage method of inline storage and object pool, it determines the target object based on the stack memory corresponding to the object pool, and stores the chip data to be stored in the target object in the object pool based on the inline storage; when the target data storage method is a pre-allocated memory storage method, it determines the first call location memory corresponding to the pre-allocated memory, determines the corresponding first address memory based on the first call location memory, and stores the chip data to be stored in the corresponding pre-allocated memory based on the address of the pre-allocated memory in the first address memory; when the target data storage method is a shared memory storage method, it determines the second call location memory corresponding to the shared memory, determines the corresponding second address memory based on the second call location memory, and stores the chip data to be stored in the corresponding shared memory based on the address of the shared memory in the second address memory; when the target data storage method is a system memory storage method, it stores the chip data to be stored in the system memory.

[0146] In some optional embodiments, the above apparatus further includes: a status data processing module, configured to receive a status data operation request, wherein the status data is the status of each test site in each chip under test; and to perform operation processing on the status data based on the status data operation request and pre-allocated contiguous target memory, wherein the status data is stored separately from the chip data to be stored.

[0147] In some optional embodiments, the state data includes multiple levels, each level being the global state, the test item state, and the state corresponding to the chip data. Specifically, the state data processing module is used to access and determine the global state and the test item state. When the global state, the test item state, and the state corresponding to the chip data are initially assigned values, a first target state object is determined from the target memory based on these values, the state corresponding to the chip data is stored in the first target state object, and a pointer is set to the first target state. When the global state, the test item state, and the state corresponding to the chip data are not initially assigned values, a second target state object is determined from the target memory based on these values, the original target state object pointed to by the pointer is removed, the state corresponding to the chip data is stored in the second target state object, and a pointer is set to the second target state object, wherein the removed original target state object becomes a usable object.

[0148] In some optional embodiments, the aforementioned state data processing module is specifically used to receive state data operation requests sent by each parallel thread; acquire a read-write lock for the target state object determined in the target memory; and, if the read-write lock for the target state object is acquired, store each state data in the target state object in a pre-allocated contiguous target memory.

[0149] In some optional embodiments, the aforementioned state data processing module is specifically used to verify the global state, test item state, and chip data corresponding state stored in the contiguous target memory; if the verification of the global state, test item state, and chip data corresponding state fails, an error message is output.

[0150] In some optional embodiments, the above apparatus further includes: an error handling module, configured to determine an error type based on error information; determine an error handling mode based on the error type; and perform error handling according to the determined error handling mode.

[0151] In some optional embodiments, the above apparatus further includes: a parallel processing module, configured to determine whether to initiate parallel processing based on the size of the data to be stored on the chip; if parallel processing is initiated, acquire thread resources, determine each target parallel thread based on the size of the data to be stored on the chip and the thread resources; and perform parallel processing on the data to be stored on the chip through each target parallel thread.

[0152] In some optional embodiments, the above apparatus further includes: a data optimization module, configured to determine an optimization strategy for the data to be stored on the chip based on the data type and size; and to optimize the data to be stored on the chip based on the optimization strategy.

[0153] In some optional embodiments, the above apparatus further includes: a data operation module, configured to receive a data operation request for data to be stored in the chip; when the data operation request is to copy or transmit the data to be stored in the chip, copy pointer data of the data to be stored, and copy or transmit the data to be stored in the chip based on the copied pointer data; when the data operation request is to modify the data to be stored in the chip, copy the data to be stored in the chip, and modify the copied data to be stored.

[0154] In some optional embodiments, the above apparatus further includes: a pipelined processing module, used to decompose the processing process corresponding to the data to be stored into multiple independent processing stages when the data size of the data to be stored is greater than a calculation threshold, and to process the data to be stored in sequence based on each processing stage, wherein each independent processing stage is connected in a pipeline manner.

[0155] In some optional embodiments, the above apparatus further includes an inertial processing module for processing the chip data to be stored in the current processing stage when the current processing stage is reached.

[0156] Each module in the aforementioned chip data storage device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0157] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 15As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a chip data storage method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0158] Those skilled in the art will understand that Figure 15 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0159] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0160] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0161] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0162] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0163] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0164] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0165] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A chip data storage method, characterized in that, The method includes: Acquire the data of the chip to be stored, and determine the data type and size of the data. Based on the data type and size, determine the target data storage method; The data of the chip to be stored is stored based on the target data storage method.

2. The method according to claim 1, characterized in that, The data types include pod types, non-pod types, and preset types, where non-pod types include matrices and vectors; determining the target data storage method based on the data types and sizes includes: When the data type is pod, the target data storage method is determined to be a combined storage method of inline storage and object pool; If the data type is not pod type, determine whether the data to be stored on the chip is a preset type of data; If the data to be stored in the chip is of a preset type, the target data storage method is determined to be a pre-allocated memory storage method; If the data to be stored is not of a preset type and the size of the data to be stored is less than or equal to the distinction threshold, the target data storage method is determined to be a shared memory storage method. If the data to be stored is not of a preset type and the size of the data to be stored is greater than the distinction threshold, the target data storage method is determined to be system memory storage.

3. The method according to claim 2, characterized in that, The process of storing the chip data to be stored based on the target data storage method includes: When the target data storage method is a combined storage method of inline storage and object pool, the target object is determined based on the stack memory corresponding to the object pool, and the chip data to be stored is stored into the target object in the object pool based on the inline storage. When the target data storage method is pre-allocated memory storage, the first call location memory corresponding to the pre-allocated memory is determined, the corresponding first address memory is determined based on the first call location memory, and the chip data to be stored is stored into the corresponding pre-allocated memory based on the address of the pre-allocated memory in the first address memory. When the target data storage method is shared memory storage, the second call location memory corresponding to the shared memory is determined, the corresponding second address memory is determined based on the second call location memory, and the chip data to be stored is stored into the corresponding shared memory based on the address of the shared memory in the second address memory. When the target data storage method is system memory storage, the data of the chip to be stored is stored in system memory.

4. The method according to any one of claims 1 to 3, characterized in that, The method further includes: Receive status data operation request, wherein the status data is the status of each test site in each chip under test; Based on the status data operation request and the pre-allocated contiguous target memory, the status data is processed, wherein the status data is stored separately from the data to be stored in the chip.

5. The method according to claim 4, characterized in that, The status data includes multiple levels, each of which is the global status, the test item status, and the status corresponding to the chip data. The operation processing of the state data based on the state data operation request and the pre-allocated contiguous target memory includes: Access determines the global state and the test item state; When the global state, test item state, and chip data corresponding state are initially assigned values, a first target state object is determined from the target memory based on the global state, test item state, and chip data corresponding state, the state corresponding to the chip data is stored in the first target state object, and the pointer is pointed to the first target state. If the global state, test item state, and chip data corresponding state are not initially assigned values, a second target state object is determined from the target memory based on the global state, test item state, and chip data corresponding state. The original target state object pointed to by the pointer is removed, and the state corresponding to the chip data is stored in the second target state object. The pointer is then pointed to the second target state object, wherein the removed original target state object becomes a usable object.

6. The method according to claim 5, characterized in that, The request to receive status data includes: Receive status data operation requests sent by each parallel thread; The operation processing of the state data based on the state data operation request and the pre-allocated contiguous target memory includes: Acquire the read-write lock of the target state object determined in the target memory; If a read-write lock is acquired on the target state object, each state data is stored in the target state object within a pre-allocated contiguous target memory.

7. The method according to claim 5, characterized in that, The method further includes: Verify the global state, test item state, and chip data corresponding state stored in the contiguous target memory; If the status verification of the global state, test item state, and chip data fails, an error message will be output.

8. The method according to claim 7, characterized in that, The method further includes: The error type is determined based on the error information; Determine the error handling mode based on the error type; Error handling is performed according to the determined error handling mode.

9. The method according to any one of claims 1 to 3, characterized in that, The method further includes: Whether to initiate parallel processing is determined based on the size of the data to be stored in the chip. When parallel processing is initiated, thread resources are acquired, and target parallel threads are determined based on the size of the data to be stored in the chip and the thread resources. The data to be stored in the chip is processed in parallel by each of the target parallel threads.

10. The method according to any one of claims 1 to 3, characterized in that, The method further includes: When the data size of the chip data to be stored is greater than the calculation threshold, the processing procedure corresponding to the chip data to be stored is decomposed into multiple independent processing stages, and the chip data to be stored is processed sequentially based on each of the processing stages, wherein each of the independent processing stages is connected in a pipeline manner.

11. A chip data storage device, characterized in that, The device includes: The data acquisition module is used to acquire data from the chip to be stored and to determine the data type and size of the data. The storage method determination module is used to determine the target data storage method based on the data type and size. A storage module is used to store the chip data to be stored based on the target data storage method.

Images