A method for unified bus dynamic memory migration and in-transit transaction consistency verification

Abstract

The present application relates to the technical field of computer cluster, in particular to a unified bus dynamic memory migration and in-transit transaction consistency verification method, comprising: receiving and maintaining migration configuration information, then initializing migration reference state; collecting each bus transaction in the migration process respectively, performing data writing on the target memory region from the source memory region according to the bus transaction; routing mapping for the bus transaction completing writing and maintaining transaction state and submission account book; performing consistency check on the migration process and repairing. In view of the fact that the memory migration process in the prior art lacks management process of memory data and migration transaction in the migration intermediate process, by simultaneously maintaining double target expected state, migration stage, switching point and synchronization relationship, the problem of the same global address corresponding to two physical targets during migration is solved, and the in-transit transaction ownership is maintained, so that the before-and-after contrast relationship of the in-transit transaction and the writing times are effectively determined, and the data consistency is improved.

Description

Technical Field

[0001] This invention relates to the field of computer cluster technology, and specifically to a unified bus dynamic memory migration and in-transit transaction consistency verification method. Background Technology

[0002] Supernodes for AI computing and data centers typically connect CPUs, NPUs, GPUs, DPUs, memory devices, and storage devices via a unified interconnect protocol, enabling multiple computing devices to access pooled memory or share address spaces. A unified bus system can consist of multiple bus domains, switching devices, ports, links, a unified memory management unit, remote memory controllers, and management software. In practical applications, containers are usually pre-built for user-created instances, and based on virtualization technology, corresponding memory addresses, CPU / GPU / NPU nodes, etc., are allocated to each container, with resources dynamically adjusted according to actual business concurrency requirements. For data already existing in memory, memory migration is usually required during resource scheduling to ensure data consistency before and after migration.

[0003] For example, patent application CN201310086275.7 discloses a memory data migration method, apparatus, and system, which can realize the migration of kernel-mode memory data and is applicable to the migration of user-mode memory data. The method includes: the current processor receiving memory data migration instruction information, the instruction information being used to indicate the migration of data to be migrated on a first memory; notifying other processor cores to enter a silent Stop-machine state; allocating a second memory to the data to be migrated on the first memory; storing the data to be migrated on the first memory into the second memory; and modifying the address mapping information of the data to be migrated based on the physical address of the second memory.

[0004] For example, patent application CN201911422233.X discloses a memory data migration method, apparatus, and storage medium. The method first obtains the process memory information of the process to be migrated in a preset process memory space, and determines the address information corresponding to the process memory information in a preset physical memory page table. Then, based on the address information, it determines the position of the process to be migrated in the physical memory page table, and by querying the physical memory page table, it determines the end node between the process to be migrated and the previous process. Finally, it removes the physical memory information stored at the end node and rearranges the physical memory page table. Through this method, the memory information of the terminal process is migrated, redundant physical memory data is cleaned up, system memory space is optimized, and thus the smooth operation of the system is ensured.

[0005] However, in actual implementation, the inventors found that such technical solutions usually only focus on the process of migrating and verifying memory data, without further attention to which target a transaction that has been issued but not completed should access, which data version should be used, and whether it should be committed exactly once during the migration and switching process. This can easily lead to problems such as data errors or duplicate commits when a breakpoint occurs during the migration process. Summary of the Invention

[0006] To address the aforementioned problems in existing technologies, a unified bus dynamic memory migration and in-transit transaction consistency verification method is provided.

[0007] The specific technical solution is as follows: A unified bus dynamic memory migration and in-transit transaction consistency verification method, comprising: Step S1: receiving and maintaining migration configuration information, and then initializing the migration reference state; the migration configuration information includes the expected data tables of the source memory region before migration and the target memory region after migration; Step S2: collecting each bus transaction during the migration process, and writing data from the source memory region to the target memory region according to the bus transaction; Step S3: performing route mapping for the bus transaction that has completed writing and maintaining the transaction state and committing the ledger; Step S4: performing consistency checks and repairs on the migration process.

[0008] On the other hand, step S1 includes: step S11: obtaining the incoming migration configuration information and parsing the configuration fields; step S12: establishing the expected data table based on the configuration fields, and establishing a current mapping pointing to the source memory region and a candidate mapping pointing to the target memory region for the same global address region; step S13: establishing a migration stage table and an in-transit transaction table for the migration process based on the expected data table.

[0009] On the other hand, step S2 includes: step S21: generating multiple bus transactions sequentially according to the desired data table to trigger the migration process; step S22: executing the bus transactions sequentially to write the memory image of the source memory region into the target memory region; during the execution of step S22, recording the in-transit transaction table for each bus transaction.

[0010] On the other hand, in step S22, for each bus transaction, the corresponding migration stage table is also modified respectively; the migration stage table changes according to the preset migration stage definition, which includes preparation, snapshot, copy, dirty write catch-up, switchover and commit stages; each migration stage definition is configured with corresponding effective conditions, allowed transaction types and allowed memory targets.

[0011] On the other hand, the execution of step S2 also includes a dirty write interception process, which includes: step A21: intercepting the data write request to the source memory region and transferring the write address range and write memory data corresponding to the data write request to the dirty write partition; step A22: adding a corresponding catch-up transaction to the end of the queue of the bus transaction for the data write request, so as to overwrite the write memory data to the corresponding range of the target memory region after the write is completed.

[0012] On the other hand, it also includes: step A23: determine whether a new write has occurred in the write address range corresponding to the catch-up transaction; if yes, merge the old and new data in the repeated write address range; if no, return to step A23 to continuously monitor the changes in the write address range.

[0013] On the other hand, step S3 includes: step S31: when each bus transaction is completed, address translation and routing mapping are performed on the bus transaction; step S32: the bus transaction is removed from the in-transit transaction table, and the migration stage table is modified to the completion stage, and then written into the commit ledger.

[0014] On the other hand, during the execution of step S31, when the bus transaction enters the observation point, the corresponding processing stage is divided and the in-transit transaction table is modified.

[0015] On the other hand, step S4 includes: Step S41: Applying a consistency check to the source memory region and the target memory region to obtain a consistency check result; the consistency check includes target memory target data integrity check, consistency check of the actual target accessed by the transaction and its bound mapping version, migration switching effective order check, retry deduplication check, data read version check after migration, partial write byte merging check, and error and rollback result check; Step S42: Extracting error records from the consistency check result, and backtracking the committed ledger based on the error records to locate the corresponding bus transaction; Step S43: Replaying the bus transaction to complete the repair process.

[0016] A storage medium includes computer instructions that, when executed by a computer device, perform the aforementioned dynamic memory migration and in-transit transaction consistency verification method.

[0017] The above technical solution has the following advantages or beneficial effects: Addressing the lack of management processes for memory data and migration transactions during the intermediate migration process in existing technologies, this solution simultaneously maintains the expected states of the two targets, migration stages, switching points, and synchronization relationships, thereby solving the problem of the same global address corresponding to two physical targets during migration. Furthermore, by maintaining the ownership of transactions in transit, the solution effectively determines the before-and-after comparison relationships and write counts of transactions in transit, thus improving data consistency. Attached Figure Description

[0018] 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.

[0019] 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 S2 in an embodiment of the present invention; Figure 4 This is a schematic diagram of the dirty write interception process in an embodiment of the present invention; Figure 5 This is a schematic diagram of step A23 in an embodiment of the present invention; Figure 6 This is a schematic diagram of step S3 in an embodiment of the present invention; Figure 7 This is a schematic diagram of step S4 in an embodiment of the present invention. Detailed Implementation

[0020] 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.

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

[0022] For ease of understanding, the English abbreviations and verification terms appearing in the manual are explained as follows: UB stands for Unified Bus; UMMU stands for Unified Memory Management Unit; DUT stands for Design Under Test; RTL stands for Register Transfer Level; Monitor stands for Transaction Monitoring Component; Reference Model / Predictor stands for Reference Model for Calculating Expected Migration States; Interface / Checker stands for Checking Component for Comparing Actual Transactions with Expected Transactions; Coverage stands for Coverage Statistics Component; DMA stands for Direct Memory Access.

[0023] The term "unified bus" as used in this article refers to an on-chip or in-package interconnect bus used for interconnecting various communication and computing resources within a supernode. This includes, but is not limited to, UB, UALink, and other similar interconnect protocols with unified addressing, transaction, routing, flow control, or inter-device access semantics. The term "unified bus" is used as a general term below and does not limit the solution to any specific protocol.

[0024] 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.

[0025] This invention includes: a unified bus dynamic memory migration and in-transit transaction consistency verification method, such as... Figure 1 As shown, the process includes: Step S1: Receive and maintain migration configuration information, and then initialize the migration reference state; the migration configuration information includes the expected data tables of the source memory region before migration and the target memory region after migration; Step S2: Collect each bus transaction during the migration process, and write data from the source memory region to the target memory region according to the bus transaction; Step S3: Perform route mapping for the bus transactions that have completed writing, maintain the transaction state, and commit the ledger; Step S4: Perform consistency checks and repairs during the migration process.

[0026] Specifically, in order to achieve better migration status recording, in this embodiment, migration configuration information is first received and maintained, and then the migration reference status is initialized.

[0027] The migration configuration information includes source and target memory regions, address mapping, permissions and routing configuration, copy granularity, dirty write record granularity, migration phase definition, switching conditions, in-transit transaction processing rules, retry rules, error response rules, and migration configuration rules.

[0028] Migration configuration rules include parameters such as whether to allow old version transactions to complete in the source memory region, whether to allow in-transit transactions to be redirected to the target memory region, whether to synchronously add dirty writes before migration commit, and whether to allow rollback in case of failure. Based on the above migration configuration information, expected memory data tables, data version tables, and valid byte tables are established for the source and target memory regions respectively, thereby completing the initialization of the migration reference state.

[0029] Subsequently, each bus transaction is collected during the migration process, and data is written to the target memory region according to the source memory region of the bus transaction. The collection process is mainly implemented by each monitor.

[0030] Specifically, the request source monitor is set at the request interface of the CPU, NPU, DMA, or verification driver; the memory monitor is set at the address translation and permission check interface; the UB transaction monitor is set at the UB transaction entry point, split point, routing point, retry point, and completion point; the migration status monitor is set at the stage status, copy progress, switch point, and commit confirmation interface of the migration control module; and the source memory region / target memory region target monitor is set at the actual memory commit interface.

[0031] Through the above monitoring points, it was verified that the platform collects bus transactions one by one during the migration process and writes the memory image in the source memory region into the target memory region according to the collected bus transactions.

[0032] Subsequently, route mapping is performed for bus transactions that have completed writing, and the transaction state is maintained and the ledger is committed.

[0033] The commit ledger maintains the expected byte range, actual committed range, pending child transactions, retry sequence number, source / target path, mapping version, and commit status for each parent transaction. For each byte range, the ledger records its first valid commit, subsequent retries, migration synchronization, and target read visibility status, thus forming a traceable commit record for each bus transaction that has completed writing.

[0034] Finally, a consistency check is applied to the source and target memory regions. When the check finds lost writes, double writes, old reads, incorrect targets, or incorrect completions, the failure backtracking component locates the first difference and replays the corresponding transaction to complete the repair process.

[0035] In actual implementation, the CPU, NPU, or DMA is the initiator of the access; the UMMU or equivalent address translation module is responsible for translating the global address into the target memory address and performing permission checks. Decoders, switching devices, and routing modules are responsible for selecting the target domain, port, link, and memory controller. The source and target memory regions can be memory controllers in different domains, different memory nodes, different memory channels, or pooled memory resources. The global address region G is a unified address range used by the CPU, NPU, or DMA for a segment of shared data; for example, G can be from 0x8000_0000 to 0x8FFF_FFFF. "G points to the source memory region" means that the address mapping table, target identifier, and UB routing configuration in the system jointly define that transactions accessing G are sent to the source memory region after address translation; "G points to the target memory region" means that the same G is sent to the target memory region after a new address mapping and routing configuration. Here, "points to" is a simplified expression of the address translation result and routing target; G itself does not move, nor does it require the CPU, NPU, or DMA to modify the global address it uses.

[0036] In one embodiment, such as Figure 2 As shown, step S1 includes: step S11: obtaining the incoming migration configuration information and parsing the configuration fields; step S12: establishing an expected data table based on the configuration fields, and establishing a current mapping pointing to the source memory region and a candidate mapping pointing to the target memory region for the same global address region; step S13: establishing a migration stage table and an in-transit transaction table for the migration process based on the expected data table.

[0037] Specifically, to achieve better state maintenance, this embodiment first obtains the incoming migration configuration information and parses the configuration fields. The migration configuration, initial memory content, permission routing rules, and control state come from different configuration sources. The migration test case component parses the incoming migration configuration information item by item to obtain configuration fields such as source memory region, target memory region, address mapping, permissions, routing configuration, copy granularity, dirty write record granularity, switching conditions, in-transit transaction processing rules, retry rules, and error response rules.

[0038] Then, a desired data table is established based on the configuration fields, and a current mapping pointing to the source memory region and a candidate mapping pointing to the target memory region are established for the same global address region. This includes establishing an initial mapping with mapping_version=30 as the current mapping, that is, the global address region G points to the source memory region, and the target memory region is in an uncommitted state.

[0039] For each data granularity, the Reference Model records the initial data summary and version number of the source memory region and marks the target memory region as not yet synchronized. Meanwhile, for the switch point C in the migration rule, the Reference Model pre-establishes a candidate mapping with mapping_version=31, which points to the target memory region, but does not apply the new mapping to all transactions before the CUTOVER event arrives.

[0040] In the configuration table, the target memory identifier corresponding to the global address G is the source memory region. The address translation result uses the target address or target identifier of the source memory region. The routing configuration selects the domain, port or link where the source memory region is located.

[0041] As an optional implementation, when converting the target address or target identifier, the local address offset can be kept unchanged while only the target node identifier is changed, or the target memory base address can be changed at the same time.

[0042] Finally, based on the expected data table, a migration stage table and an in-transit transaction table are created for the migration process.

[0043] The migration phase table records the current phase of the migration process, the conditions for each phase to take effect, the allowed transaction types, and the allowed memory targets.

[0044] The in-transit transaction table records the processing stage, mapping version, byte range, and commit status of each bus transaction that has been issued but not yet completed.

[0045] By using a migration phase table, a dual-target expected data table for the source / target memory region, and candidate mapping versions, this invention addresses the problem that a typical single-target Reference Model cannot express the migration process. Furthermore, since simply copying data does not change the subsequent transaction target, this invention treats mapping activation, routing activation, and data synchronization completion as interrelated but separately observable conditions, preventing the system from sending access requests to the global address G to the source memory region even when the target memory region already has a copy.

[0046] In one embodiment, such as Figure 3 As shown, step S2 includes: step S21: generating multiple bus transactions sequentially according to the desired data table to trigger the migration process; step S22: executing bus transactions sequentially to write the memory image of the source memory region to the target memory region; during the execution of step S22, recording the in-transit transaction table for each bus transaction.

[0047] After maintaining the desired data table, multiple bus read / write transactions targeting the global address region G can be generated sequentially via CPU RTL to execute the driver image or via the DMA / NPU transaction stimulus component, thereby triggering and advancing the migration process in the DUT. During the migration process, data at each granularity in the source memory region is sequentially read out and written to the corresponding range in the target memory region, forming a memory image; the copy monitor records the data read from the source memory region, written to the target memory region, the target range, the copy round, and the copy completion status.

[0048] Specifically, during step S22, an in-transit transaction table is recorded for each bus transaction, meaning the in-transit transaction table is tracked synchronously during the write process. Each bus transaction's record in the in-transit transaction table includes at least: transaction trace ID (trace_id), initiating device (source_device), global address (global_addr), operation type (operation), length, byte range (byte_range), mapping version (mapping_version), permission version (permission_version), route version (route_version), parent transaction ID (parent_txn_id), transaction ID (txn_id), subtransaction ID (subtxn_id), retry index (retry_index), observation stage (stage_at_observation), target memory (target_memory), data version (data_version), data digest (data_digest), and completion status (completion_status). These records enable the verification platform to determine the incomplete byte range and corresponding transaction lineage based on the in-transit transaction table when transmission is interrupted (e.g., link retry, migration failure, or partial sub-transaction delay), for subsequent backtracking and repair.

[0049] For split write requests, the migration transaction association component creates a set of sub-transactions for the parent transaction and records, by byte range, whether each sub-transaction has entered the source memory area, whether it has been committed, whether it has been retried, or whether it is pending synchronization. For retried transactions, the genealogical relationship between the original transaction and the retried transaction is preserved, avoiding the judgment of a new independent write based solely on the new local transaction number. Thus, even if the same upper-layer request has old mappings, multiple sub-transactions, and multiple retried instances during the migration switch, the in-transit transactions can be identified through the observation phase, parent-child transaction relationship, configuration version, and byte range, forming a migration-specific transaction ledger.

[0050] In one embodiment, in step S22, for each bus transaction, the corresponding migration stage table is also modified respectively; the migration stage table changes according to the preset migration stage definition, which includes preparation, snapshot, copy, dirty write catch-up, switchover and commit stages; each migration stage definition is configured with corresponding effective conditions, allowed transaction types and allowed memory targets.

[0051] In addition, a migration stage table is maintained to achieve better tracking of the processing of each bus transaction.

[0052] The migration phase table changes according to the preset migration phase definitions, which include the PREPARE, SNAPSHOT, COPY, CATCH_UP, CUTOVER, and COMMIT phases. Each migration phase definition is configured with corresponding activation conditions, allowed transaction types, and allowed memory access targets. The specific processing of each phase is as follows: PREPARE preparation phase: The migration control module receives the migration configuration, and the Reference Model establishes dual target expected data tables and candidate mappings for the source memory region and the target memory region; during this phase, normal business read and write transactions are allowed to access the source memory region, but no transactions are allowed to access the target memory region.

[0053] SNAPSHOT Phase: When the migration control module enters the SNAPSHOT phase, the Reference Model records the snapshot version and data summary for each data granularity in the source memory region. This phase still uses the source memory region as the allowed memory target, and at the same time begins to record concurrent writes to the source memory region during the migration.

[0054] The COPY phase: The migration control module copies the snapshot data from the source memory region to the target memory region. During the COPY phase, if the CPU, NPU, or DMA writes data to the source memory region, the source memory region target monitor records the writer, byte range, written data summary, and new data version; the dirty write tracing component adds this range to the dirty_set and records the dirty_version and the corresponding transaction lineage. If multiple writes occur to the same range, the final expected data is retained according to data version and transaction dependencies, while intermediate writes are retained for checking transactions in transit.

[0055] CATCH_UP dirty write catch-up phase: The migration control module synchronizes the data in dirty_set from the source memory region to the target memory region. The Reference Model establishes a copy dependency for each synchronization operation, checks whether the synchronized data in the target memory region covers the latest valid byte range of the source memory region; for partial writes, it enables merging of old and new data byte by byte, and cannot replace the expected byte-level state with whole-line copying.

[0056] CUTOVER Switchover Phase: The migration status monitor collects events such as CUTOVER start, address mapping register activation, route update activation, old target access denied, and new target access allowed. The verification platform records the first mapping activation event that satisfies the migration rules as switchover point C, and generates a switchover sequence number cutover_seq and a switchover condition cutover_condition for C. The new configuration is marked as effective only when the target memory region has obtained snapshot data and valid dirty writes during the migration, and address translation, routing, permission caching, and target memory state meet the switchover conditions. After the switchover is complete, newly issued transactions must use mapping_version=31 and access the target memory region.

[0057] COMMIT phase: The migration status monitor collects migration commit confirmation events, and the migration phase table enters the completed state; thereafter, the migration interface performs a final check on the data integrity of the target memory area, the commit results of transactions in transit, etc.

[0058] During migration switching, address mapping, routing, permission caching, and target memory may take effect at different times; migration switching is not a single clock event. This implementation uses observable binding points and cutover_conditions as the basis for judgment: the migration transaction association component binds the transaction to mapping_version=30 or mapping_version=31 according to the configuration version when the transaction reaches the specified binding point. The binding point can be address translation completion, permission check completion, decoder target selection completion, UB route path locking, or other irreversible stages specified by the protocol. The specific binding point is determined by the migration configuration and protocol rules. After binding, the interface does not reinterpret the transaction due to changes in the latest configuration, avoiding simply using simulation time points or migration control states to replace the actual ownership of the transaction.

[0059] In one embodiment, such as Figure 4As shown, the execution of step S2 also includes a dirty write interception process, which includes: step A21: intercepting data write requests to the source memory region and transferring the write address range corresponding to the data write request and the write memory data to the dirty write partition; step A22: adding a corresponding catch-up transaction to the end of the bus transaction queue for the data write request, so as to overwrite the write memory data to the corresponding range of the target memory region after the write is completed.

[0060] Specifically, in order to prevent new writes from occurring in the source memory address and causing memory data errors, this embodiment also intercepts the dirty write process.

[0061] Specifically, when performing memory migration, during the concurrent snapshot copying and runtime access, if the CPU, NPU, or DMA initiates a data write request to the address range that has been copied or is to be copied in the source memory region, the dirty write tracing component intercepts the write request, transfers the write address range and the write memory data to the dirty write partition, that is, records it in the dirty write partition, and records the writer, data summary, new data version and corresponding transaction lineage.

[0062] Subsequently, when the state transitions to the catch-up phase (CATCH_UP), the dirty write data recorded in the dirty write partition is synchronized from the source memory region and overwritten to the corresponding byte range of the target memory region by catching up transactions appended to the end of the bus transaction queue. At the same time, a replication dependency is established for each catching up transaction, and it is checked whether the synchronized data in the target memory region covers the latest valid byte range of the source memory region. For partial writes, the merging of old and new data is enabled byte by byte.

[0063] In one embodiment, such as Figure 5 As shown, it also includes: Step A23: Determine whether a new write has occurred in the write address range corresponding to the chasing transaction; if yes, merge the old and new data in the duplicate write address range; if no, return to step A23 to continuously monitor the changes in the write address range.

[0064] Specifically, for each catch-up transaction, it checks whether a new write has occurred within the corresponding write address range. If a new write occurs within this range before the catch-up transaction completes the overwrite, the old and new data are merged according to data version and transaction dependency, updating the expected data with the latest valid data and retaining intermediate write records. If no new write has occurred, it continues to monitor until the range is synchronized and no more dirty writes occur. A traceable migration write chain is established through snapshot version, dirty write partition, byte range, and replication dependency to avoid missing partial writes or duplicate writes by only comparing the entire memory block before and after migration.

[0065] In one embodiment, such as Figure 6As shown, step S3 includes: step S31: when each bus transaction is completed, address translation and routing mapping are performed on the bus transaction; step S32: the bus transaction is removed from the in-transit transaction table, and the migration stage table is modified to the completion stage, and then written into the commit ledger.

[0066] Specifically, in order to achieve better write control, in this embodiment, when a transaction is completed, the migration transaction association component obtains the target address of the transaction after UMMU address translation, and performs route mapping in combination with the routing configuration of the decoder and routing module to determine the actual target memory reached by the transaction.

[0067] For each transaction, the component simultaneously records the global memory address (global_addr), the mapped target (translated_target), the target memory region (target_memory), the route version (route_version), and the binding point, enabling traceability for each bus transaction. For transactions that are bound to the old version before the switch point and whose completion is permitted by the rules, the Reference Model retains their processing path of accessing the source memory region or redirecting to the target memory region according to the rules, and establishes synchronization requirements. For transactions that are not bound before the switch point, the configuration determines whether they should continue to use the old version, re-execute address translation, or terminate directly.

[0068] Once a transaction has been committed in the target memory, it is removed from the in-transit transactions table, the corresponding phase record in the migration phase table is updated, and the commit result is written to the commit ledger.

[0069] The commit ledger maintains the expected byte range, actual committed range, pending child transactions, retry index (retry_index), source / target path, mapping version (mapping_version), and commit status (commit_status) for each parent transaction. For each byte range, the ledger records its first valid commit, subsequent retries, migration synchronization, and target read visibility status.

[0070] When an old version of a transaction in transit completes in the source memory region, the ledger marks its write range as committed to the old target. When the range is synchronized to the target memory region, a relationship of synchronization to the new target is established, but the synchronization operation is not counted as a new upper-level write. When a retry transaction arrives at the target again, it is determined whether it belongs to the same commit attempt based on the parent transaction, byte range, data digest, and retry index.

[0071] If the same byte range is committed by both the old transaction and the retry transaction, the ledger marks it as a duplicate request; if the parent transaction declares completion but there are still gaps in the byte range, it is marked as a missing byte range.

[0072] This distinguishes between the original commit, migration copy, and retry commit, enabling an exact-once check during migration and providing a basis for repair after transmission interruptions.

[0073] In one embodiment, during the execution of step S31, when a bus transaction enters an observation point, the corresponding processing stages are divided and the in-transit transaction table is modified.

[0074] Specifically, to enable the identification and repair of breakpoints, the processing stage of a transaction is determined based on the observation point it enters, and the in-transit transaction table is modified accordingly: transaction records that have completed old version address translation but have not yet completed route selection are considered completed translations; transaction records that have selected the source memory region path but have not yet completed target commits are considered routes pointing to the source memory region; transaction records that have completed some sub-transactions in the source memory region but whose parent transactions have not been completed are considered partially completed transactions; and transaction records newly issued after migration are considered new version responses.

[0075] By dividing the processing phases according to observation points, transactions in transit are not just incomplete transaction numbers, but determinate objects with clear processing phases. This allows us to determine whether a transaction should continue accessing the source memory region, access the target memory region after retransformation, be redirected, or terminated when a migration or switch occurs.

[0076] In one embodiment, such as Figure 7 As shown, step S4 includes: Step S41: Apply consistency checks to the source memory region and the target memory region to obtain consistency check results; the consistency checks include target memory target data integrity checks, consistency checks of the actual target accessed by the transaction and its bound mapping version, migration switching effective order checks, retry deduplication checks, data read version checks after migration, partial write byte merging checks, and error and rollback result checks; Step S42: Extract error records from the consistency check results, and backtrack the processing ledger based on the error records to locate the corresponding processing transaction; Step S43: Replay the processing transaction to complete the repair process.

[0077] Specifically, to achieve better memory consistency verification, a consistency check is first applied to the source and target memory regions to obtain the consistency check results, as follows: Data integrity check of the target memory region: After the migration is committed, the actual valid bytes and data digest of the migrated region in the target memory region should be equal to the expected data after the Reference Model merges snapshots, dirty writes, synchronous writes and new version writes, and there should be no missing byte range.

[0078] Transaction target check: The source or target memory region actually accessed by a transaction should conform to its mapping version, transaction binding phase, and migration rules; new transactions after the switch point must not incorrectly access the old target.

[0079] Migration switchover activation order check: The activation order of mapping version, routing version, permission version, and migration stage should meet the preset switchover conditions; there should be no situation where the address table has been switched but the route still points to the old target and the verification platform does not report any abnormalities.

[0080] Retry deduplication check: Retry of the same parent transaction, the same byte range, and the same commit version should not result in two valid commits; when a retry is lost, the missing range and the corresponding retry chain should be reported.

[0081] Post-migration data version check: Reads to G after migration commit must not return data versions that were invalid before migration; if the protocol allows reading from the old target, the specified visibility window and synchronization conditions must be met. For post-migration read requests, committed data from the source memory region, dirty writes during migration, data synchronized to the target memory region, and new writes under mapping_version=31 are merged according to the migration rules to generate the expected data and expected version for the target memory region.

[0082] Partial write byte merging check: Concurrent writes with different byte enable should be merged according to the valid bytes. Partial write loss should not be masked by copying the whole line or comparing the whole block.

[0083] Error and rollback result checks: When errors occur during migration replication, route switching, or target commit, the actual error response, transaction termination, rollback, or retry result should be consistent with the migration rules. Migration success and data incompleteness should not be reported simultaneously.

[0084] When the migration interface reports a lost write, double write, old read, incorrect target, or incorrect completion, the failure backtracking component starts from the failed transaction object and backtracks the committed ledger and the in-transit transaction ledger based on the error record. It backtracks the migration stage, switch point, configuration version binding, parent and child transactions, retries, source memory area commit, dirty write synchronization, target memory area commit, and read results in sequence. For each stage, it compares the actual fields with the expected fields, identifies the first difference, and thus locates the corresponding processing transaction.

[0085] For example, if the data in both the source and target memory regions is correct, but a transaction accesses the source memory region, the first difference may occur during mapping version binding or routing updates; if both mapping and routing are correct, but the target memory region is missing a byte range, the first difference may occur during dirty write partition updates or synchronous commits; if both the original transaction and the retry transaction commit, then the first difference is deduplicated.

[0086] The identified transactions are replayed, and the correct data version is resubmitted to the target memory region. Alternatively, erroneous submissions are rolled back and deduplicated according to migration rules to complete the repair. Simultaneously, the minimum reproducibility scenario extraction component removes transactions unrelated to the failure address range, migration switching point, transaction parent-child relationship, retry chain, data version, and migration stage. The remaining scenarios are executed iteratively, retaining the minimum set of in-transit transactions, minimum migration configuration, and minimum timing constraints that can reproduce the failure. The output verification package includes at least the initial data summary of the source / target memory region, migration configuration, migration stage sequence, mapping / permission / routing version, in-transit transaction records, parent-child transaction relationships, retry index, dirty write partition, synchronization relationship, random seed, waveform window, and expected data.

[0087] It should be noted that the migration can be updated and the above checks can be performed online, or the software component can perform offline merging at simulation checkpoints or after the simulation is completed. For cases where the amount of data in the source memory region / target memory region is large, the data digest and version number can be used for online judgment. If the digest is inconsistent, the relevant address range can be replayed to obtain the complete data.

[0088] Furthermore, for migration verification, the definition covers phase coverage, transaction phase coverage, version switching coverage, data version coverage, retry coverage, and result coverage. Phase combinations must include at least writes during COPY, writes during CATCH_UP, concurrent reads and writes before and after CUTOVER, retries before COMMIT, migration failure rollbacks, and old reads after migration. Cross-statistics are performed on combinations such as the transaction phase and mapped version, the number of parent transaction splits and switching points, the range of dirty write bytes and synchronization rounds, the number of retries and target memory, barrier locations and migration commits, permission changes and migration switching, and error locations and rollback results. When a combination is not covered, the scenario generation software generates driving tasks, DMA traffic, partial writes, delay windows, retry injections, and routing switching constraints based on the migration state machine and transaction reachability conditions. The generated scenario is then added to RTL regression; the regression results update the Coverage database and failure mode library, forming a verification closed loop oriented towards the migration boundary.

[0089] A storage medium includes computer instructions that, when executed by a computer device, perform the aforementioned dynamic memory migration and in-transit transaction consistency verification method.

[0090] Those skilled in the art will understand that various aspects, or possible implementations of various aspects, of the present invention can be embodied as systems, methods, or computer program products. Therefore, various aspects, or possible implementations of various aspects, of the present invention can take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, etc.), or embodiments combining software and hardware aspects, all collectively referred to herein as "circuit," "module," or "system." Furthermore, various aspects, or possible implementations of various aspects, of the present invention can take the form of computer program products, which are computer instructions stored in memory.

[0091] The memory can be a computer-readable signal medium or a computer-readable storage medium. Computer-readable storage media include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or apparatuses, or any suitable combination thereof, such as random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, and portable read-only memory (CD-ROM).

[0092] A processor in a computer reads computer instructions stored in memory, enabling the processor to execute the functional actions specified in each step or combination of steps in a flowchart; and to generate means for implementing the functional actions specified in each block or combination of blocks in a flowchart.

[0093] It should be understood that a processor in a computer can be understood as one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers (MCUs), microprocessors, or other electronic components used to execute the aforementioned computer instructions.

[0094] Computer instructions may be executed entirely on the user's local computer, partially on the user's local computer, as a separate software package, partially on the user's local computer and partially on a remote computer, or entirely on a remote computer or server. It should also be noted that in some alternative implementations, the functions indicated by the steps in the flowchart or the blocks in the block diagram may not occur in the order shown in the diagram. For example, depending on the functions involved, two consecutive steps or blocks may actually be executed approximately simultaneously, or these blocks may sometimes be executed in reverse order.

[0095] Of course, in practical applications, the various components of a computer system are coupled together through a bus system. The bus system is used to enable communication and connection between these components. In addition to the data bus, the bus system also includes a power bus, a control bus, and a status signal bus.

[0096] 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 unified bus dynamic memory migration and in-transit transaction consistency verification method, characterized in that, include: Step S1: Receive and maintain migration configuration information, and then initialize the migration reference state; The migration configuration information includes expected data tables for the source memory region before migration and the target memory region after migration. Step S2: Collect each bus transaction during the migration process, and write data from the source memory region to the target memory region according to the bus transaction; Step S3: Perform route mapping for the bus transactions that have completed writing, maintain the transaction status, and commit the ledger; Step S4: Perform consistency checks and repairs on the migration process.

2. The unified bus dynamic memory migration and in-transit transaction consistency verification method according to claim 1, characterized in that, Step S1 includes: Step S11: Obtain the incoming migration configuration information and parse the configuration fields; Step S12: Establish the expected data table based on the configuration fields, and establish a current mapping pointing to the source memory region and a candidate mapping pointing to the target memory region for the same global address region; Step S13: Establish a migration stage table and an in-transit transaction table for the migration process based on the expected data table.

3. The unified bus dynamic memory migration and in-transit transaction consistency verification method according to claim 2, characterized in that, Step S2 includes: Step S21: Generate multiple bus transactions sequentially according to the desired data table to trigger the migration process; Step S22: Execute the bus transactions sequentially to write the memory image of the source memory region into the target memory region; During the execution of Step S22, record the in-transit transaction table for each bus transaction.

4. The unified bus dynamic memory migration and in-transit transaction consistency verification method according to claim 3, characterized in that, In step S22, for each bus transaction, the corresponding migration stage table is also modified. The migration stage table changes according to the preset migration stage definition, which includes preparation, snapshot, copy, dirty write catch-up, switchover, and commit stages. Each migration stage definition is configured with corresponding activation conditions, allowed transaction types, and allowed memory targets.

5. The unified bus dynamic memory migration and in-transit transaction consistency verification method according to claim 1, characterized in that, The execution of step S2 also includes a dirty write interception process, which includes: step A21: intercepting data write requests to the source memory region and transferring the write address range and write memory data corresponding to the data write request to the dirty write partition; step A22: adding a corresponding catch-up transaction to the end of the bus transaction queue for the data write request, so as to overwrite the write memory data to the corresponding range of the target memory region after the write is completed.

6. The unified bus dynamic memory migration and in-transit transaction consistency verification method according to claim 5, characterized in that, It also includes: Step A23: Determine whether a new write has occurred in the write address range corresponding to the catch-up transaction; if yes, merge the old and new data in the duplicate write address range; if no, return to step A23 to continuously monitor the changes in the write address range.

7. The unified bus dynamic memory migration and in-transit transaction consistency verification method according to claim 3, characterized in that, Step S3 includes: Step S31: When each bus transaction is completed, address translation and routing mapping are performed on the bus transaction; Step S32: The bus transaction is removed from the in-transit transaction table, and the migration stage table is modified to the completion stage, and then written into the commit ledger.

8. The unified bus dynamic memory migration and in-transit transaction consistency verification method according to claim 7, characterized in that, During the execution of step S31, when the bus transaction enters the observation point, the corresponding processing stage is divided and the in-transit transaction table is modified.

9. The unified bus dynamic memory migration and in-transit transaction consistency verification method according to claim 1, characterized in that, Step S4 includes: Step S41: Applying a consistency check to the source memory region and the target memory region to obtain a consistency check result; the consistency check includes target memory target data integrity check, consistency check of the actual target accessed by the transaction and its bound mapping version, migration switching effective order check, retry deduplication check, data read version check after migration, partial write byte merging check, and error and rollback result check; Step S42: Extracting error records from the consistency check result, and backtracking the committed ledger based on the error records to locate the corresponding bus transaction; Step S43: Replaying the bus transaction to complete the repair process.

10. A storage medium comprising computer instructions, characterized in that, When the computer device executes the computer instructions, it performs the unified bus dynamic memory migration and in-transit transaction consistency verification method as described in any one of claims 1-9.

Images