Dynamic reconfigurable machine learning acceleration system

Abstract

The invention discloses a dynamically reconfigurable machine learning acceleration system, which ensures the structural correctness of a processing flow and no data loss by checking the sequence exchange consistency and queue / storage conservation in a running process in a cloud edge collaborative environment. The system includes a plurality of seat modules, referred to as EDGE, NODE, CORE, FIN, and GOV, and a cross-seat exchange interconnect structure connecting these modules. During operation, the system performs continuous consistency check on a key service link, and once an inconsistency or tearing fault is detected, the system only allows to adopt a single repair action once, and selects repair measures according to a priority sequence of topology / path priority, secondary format / protocol and secondary time sequence / window, so that the repair efficiency is improved. And it is ensured that one inconsistency can be eliminated only through one-time repair each time. The process converges in a unit stepping mode, and each iteration enables the inconsistent count mu to be reduced by 1 (delta mu = 1) until the system reaches a consistent state of sealing.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of machine learning accelerator and dynamic reconfigurable computing, and particularly relates to a machine learning acceleration system with high performance and auditable operation, which is realized by using partial dynamic reconfiguration technology, combining runtime scheduling and structure consistency verification in a cloud-edge collaborative artificial intelligence computing environment. BACKGROUND

[0002] In existing distributed artificial intelligence computing and accelerator management methods, self-healing mechanisms or dynamic recompilation mechanisms based on threshold triggering are often used to handle faults or performance degradation during operation. However, such mechanisms usually operate as a black box, which is not transparent and difficult to audit, and may introduce hidden internal door behavior. For example, when a certain internal error count exceeds the threshold, the node may silently stop accepting new tasks or adjust the processing flow without any external visible record. This internal threshold control lacks explicit audit records, making the behavior of the system difficult to predict and reproduce, and unable to meet the requirements of determinism and compliance for critical applications. In addition, although traditional partially reconfigurable hardware (such as FPGA or coarse-grained reconfigurable array CGRA) allows loading new hardware configurations at runtime, it does not solve the problem of flow consistency during operation, and also lacks an audit mechanism for internal state transitions. Similarly, in cloud-edge collaborative scheduling, commonly used orchestration based on performance indicators or machine learning strategies (such as load balancing and fault tolerance processing according to a scoring function of load, threshold alarm or AI model decision) are also difficult to perform fine-grained audit or accurate reproduction due to algorithm complexity or lack of interpretability.

[0003] Therefore, it can be seen that the existing technology lacks a method that can make the structure consistency explicit and provide an engineering closed-loop correction, i.e. checking the operation sequence and data conservation during system operation, performing a structured one-time repair when an anomaly is found, and converging to a verified consistent state through unit steps, while recording the entire process as evidence for manual audit. There is no solution in the existing technology that combines dynamic reconfigurable hardware acceleration technology with strict step-by-step consistency verification and audit tracking. Therefore, it is necessary to provide a new system architecture and method to ensure that in a cloud-edge collaborative machine learning acceleration environment, highly flexible dynamic acceleration is achieved while ensuring strict operational consistency and full auditability. SUMMARY

[0004] The present application relates to the field of machine learning accelerator and dynamic reconfigurable computing, and particularly relates to a machine learning acceleration system with high performance and auditable operation, which is realized by using partial dynamic reconfiguration technology, combining runtime scheduling and structure consistency verification in a cloud-edge collaborative artificial intelligence computing environment. OBJECTIVE: To provide a dynamic reconfigurable machine learning acceleration system to solve the problems of insufficient flexibility of accelerators, internal operation opacity and lack of audit tracking in the prior art. Through the system architecture of the present application, structured consistency checking and traceable self-correction during operation can be realized while ensuring high performance and high throughput, thereby improving the reliability and monitorability of the system.

[0005] Technical solution: A dynamically reconfigurable machine learning acceleration system, including a processor subsystem (PS), a programmable logic subsystem (PL), memory, and a runtime controller.

[0006] A. A deformable partially reconfigurable region (MRR) is provided within the PL, the boundary of which can be expanded or shrunk at runtime according to the discrete step length without changing the structure of the static shell within the PL;

[0007] B. The PL is equipped with dual bank bitstream channels to realize the streaming loading and in-situ switching of differential or relocatable bitstreams for partial reconfiguration operations;

[0008] C. The system provides a unified Shell interface and an Application Binary Interface (ABI) with version control, enabling the acceleration module to achieve binary-level hot-plugging without modifying the Shell;

[0009] D. During operation, the system constrains the execution path through structured consistency checks, including at least the following two types of checks: operation order swap consistency checks (verifying whether swapping the order of two operations still produces equivalent observable behavior, for example, checking...). and (equivalence) and queue / storage balance check (verifying that the system satisfies Σ) in -Σ out -Δ store -The conservation relationship of loss=0); When any inconsistency or "tear" fault is detected, the system only allows one-time repair operation, and selects repair measures in the order of topology / path (Geometry) first, then format / protocol (Frame), and then timing / window (Field); Each repair reduces the inconsistency μ by 1 (Δμ=1), achieving unit step convergence until the system reaches a closed consistency state; The system outputs all events and results only in text form as an audit log, and calculates a deterministic natural number fold check value as a "Fence" for external verification for each closed operation window; The final result acceptance of the system is performed by a six-input AND logic gate set outside each module, and the processing result is considered valid only when all six independent condition signals are true.

[0010] Further, the dual-bank streaming partial reconfiguration loads new configuration by transferring bitstream differential data blocks with size of 4-64KB, and includes XOR differential synthesis and decompression logic on-chip, performs block-level CRC check on the loaded bitstream to ensure integrity verification passes before activating the new configuration, thus supporting in-place fast switching of the acceleration module configuration.

[0011] Further, the morphable reconfiguration region (MRR) achieves millisecond-level region boundary expansion or contraction without affecting the timing convergence of the Shell fixed logic through pre-defined boundary parameter table and clock / reset domain retention techniques.

[0012] Further, the processor subsystem and programmable logic subsystem are integrated in a single system-on-chip (SoC), the processor communicates with the reconfigurable region through AXI4-Lite bus as control plane interface and AXI4-Stream bus as data plane interface, the on-chip interconnect employs credit-managed network-on-chip (NoC) to support zero-copy data transfer and back-to-back transfer; the memory includes high-bandwidth memory (HBM) or DDR to achieve high-speed data throughput and partial reconfiguration bitstream transfer.

[0013] Further, the operation order swap consistency check at least includes verification of quantize°convolve order and concat°normalize order to ensure that the two operations occur in the correct order and produce consistent results.

[0014] Further, the queue and storage conservation check at least includes monitoring of the following two types of conservation relations:

[0015] Buffer queue conservation: verify that the number of queue input frames - the number of queue output frames - the number of dropped frames = the amount of change in queue length (i.e. Q in - Q out -drop = Δqueue) to ensure that no data is added or removed from the queue without a trace;

[0016] Storage level conservation: verify that the number of DMA written bytes - the sum of the number of bytes occupied at each storage level - the number of DMA readout (or eviction) bytes = 0 (i.e. ingested - ∑(level bytes ) - evicted = 0) to ensure that the total amount of data in the multi-level storage layer is balanced; when any conservation relation is not established, it is determined to be "torn" inconsistent, and only one repair is performed and verified Δμ = 1.

[0017] Further, the one-time operation for repairing the "inconsistency" fault is classified into three levels of priority, corresponding to the topology / path (Geometry), format / protocol (Frame), and timing / window (Field) priorities in claim 1, and specifically includes but is not limited to:

[0018] Topology / path level repair: for example, edge_patch (edge port / connection / path reconstruction), boresight (channel alignment correction);

[0019] Format / protocol level repair: for example, frame_select (data format or protocol switching), contractual_bridge (bridge or re-binding of contracts / accounts / keys);

[0020] Timing / window level repair: for example, retime (adjustment of timing window or batch processing alignment), paired_margin (pairing margin normalization processing);

[0021] Each time only one repair action is selected from the above three levels to handle the inconsistency fault.

[0022] Further, the check value (Fence) of the text audit log is obtained by sequentially encoding and summing each row of the log in the audit window, and the calculation formula is:

[0023] Fence = ∑((i+1) x (∑code(line i ) mod 1009))

[0024] Where index i represents the i-th row in the audit log, code(line i ) is a predefined function of encoding the row of text into a number, and the encoding value of each row is first folded by taking modulo 1009 (the 1009 is a fixed prime number), then multiplied by (i+1) for weighting and summed to obtain the final Fence value; the Fence value is a pure natural number and not encrypted, and can be independently calculated and verified by any observer according to the log content, thereby verifying the integrity and correct order of the audit log.

[0025] Further, when the system contains a photonic input / output link or interconnection, further performing consistency checking and conservation monitoring in the optical domain, including verifying the O / E sequential consistency of optical signals (such as the sequential matching of transmitted and received optical signals after serial-parallel / parallel-serial conversion and clock recovery) and optical power conservation (monitoring whether the difference between the optical power entering the optical fiber and the output optical power and the loss is within the expected range, i.e. in -P out- Loss = AU satisfies conservation); once an inconsistency is detected on the optical link (e.g. optical signal phase out-of-lock or abnormal loss), a corresponding corrective action (e.g. adjusting the laser phase, switching to a backup optical path or adjusting the optical amplifier gain) is performed only once, and the repair operation is ensured to reduce the degree of inconsistency μ by 1 (Δμ = 1).

[0026] Further, the system records a long-period time continuity proof (TTB-warp receipt) after reaching the sealed state, which includes time stamps or count values from multiple time references and a cross-period "warp" time difference (e.g. millisecond level), and the receipt is archived as audit evidence to prove that the system has been continuously consistent for a longer running period, but does not have any gating effect on the system running process.

[0027] Advantages:

[0028] The dynamic reconfigurable machine learning acceleration system of the present application can greatly improve the reliability and transparency of distributed AI computing systems without sacrificing performance, and is suitable for industrial environments with high requirements for performance and correctness. For example, large data centers can use the system to improve the availability and maintainability of services, telecommunications network nodes can use its fast hot switching capability to meet the adjustment of real-time traffic, and edge computing devices can integrate into data processing processes that need to be supervised through its audit capability. The system is compatible with existing hardware and software standards (AXI bus, IPv6 network protocol, etc.), and can be smoothly integrated into existing infrastructure to add structured self-checking and self-healing capabilities without completely changing the surrounding system architecture. Therefore, the present application has broad industrial application prospects. BRIEF DESCRIPTION OF DRAWINGS

[0029] Figure 1 is the overall architecture diagram of the dynamic reconfigurable acceleration system of the present application. It shows the integration of processing system (PS, 1) and programmable logic (PL, 2) on a single chip, the connection relationship between local dynamic reconfiguration area (3), double configuration bank (4), Shell / ABI interface logic (5), high bandwidth memory (HBM, 6), DDR memory interface (7), on-chip network (NoC, 8), and external seat modules (EDGE, CORE, FIN, GOV, etc.), and 6-AND external acceptance door (Door).

[0030] Figure 2 It illustrates the hierarchical checking architecture for sequential consistency and conservation within the system. It illustrates how the operation sequence (such as route-policy sequence, cache-authorize correspondence) is verified within each seat module, and how the income and expenditure conservation of the queue and storage is monitored.

[0031] Figure 3 The minimum area replacement (MRR) partial reconfiguration scheme is shown. The bitstream difference streaming, on-chip XOR / decompression logic, and the process of verification by CRC check before activating the new hardware module are highlighted.

[0032] Figure 4 The partial reconfiguration double bank hot swap timing diagram is described. The timeline of flushing data, pausing region, swapping configuration pointers, and resuming operation during the swap process is shown, as well as the changes in AXI4-Stream lane handshake mechanism (VALID / READY signals) during this process.

[0033] Figure 5 The unified Shell / ABI interface logic block diagram implemented in programmable logic is shown. All reconfigurable hardware acceleration modules communicate with the rest of the system through this Shell interface, which provides standard AXI bus adaptation and interrupt control functions, ensuring consistent interfaces when modules are replaced.

[0034] Figure 6 This is a representative data path segment diagram. Taking the Quantization to Convolution pipeline as an example, the locations for structural checks on the data path are marked (e.g., ensuring that the quantization parameters match the format expected by the convolution module, which is a Frame-level check).

[0035] Figure 7 This is another data path segment diagram. The Concatenation to Normalization processing flow is shown, illustrating the process of multiple convolution outputs entering the normalization module after concatenation, and indicating monitoring points to ensure that all data streams are correctly aligned and normalized (examples of Frame / Field-level checks).

[0036] Figure 8 The conservation monitoring mechanism for buffer queues is illustrated. The diagram shows that the counters count the number of elements entering the queue (Q in ), the number of elements leaving the queue (Q out ), and the number of discarded elements (drop), and calculate the change in queue occupancy Δqueue. If Q in -Q out -drop is not equal to the actual observed change in queue length, an exception alarm will be triggered.

[0037] Figure 9Conservation of storage (DMA) in multi-level storage hierarchy. The figure shows a data ingestion module writing data into a multi-level storage (L1 cache, L2 cache, etc.), and by metering the number of bytes stored in each level and the amount of data evicted, verifies whether the ingested = ∑(stored bytes )+evicted relationship holds, thus monitoring for any memory leaks or repeated computation.

[0038] Figure 10 An example scenario of a topology / path repair action. The figure gives a service network topology, and when a node or policy on one of the paths fails (marked as torn), the system re-routes the traffic (new path shown in dashed line) to a backup node or service chain through topology-level repair, achieving Geometry-level repair of route°policy order inconsistency.

[0039] Figure 11 An alignment calibration scenario. For example in photon link calibration (or generally parallel process synchronization), the system uses an ABBA pattern to send reference signals for phase alignment. The figure shows the signal sequence from sender to receiver and back (A→B→A), and the process of correcting misalignment through a one-time phase adjustment. The figure can also be understood as a schematic of keeping synchronization between logical parallel processes (e.g. the difference in step count between two domains A and B is denoted by ρ(A→B) in the figure, and the ABBA check ensures that the two are in step).

[0040] Figure 12 A schematic of the "Sealer" finite state machine (FSM) and related components. The figure details the various states of the FSM: IDLE, CHECK, APPLY, VERIFY, SEALED, and illustrates the interaction between the Arbiter and the Adapters. The figure emphasizes the principle of a unit step reduction of inconsistency degree Δμ = 1 in each round of loop, and the role of the TXTLogger text logger and the Fence counter in each step (e.g. logging and updating the Fence in the APPLY and VERIFY phases).

[0041] Figure 13The figure shows the organization of the acceleration module library and its organization in memory, as well as the structure of the text audit logger and Fence computation ("TXT Fence logger and replay pipeline"). The figure depicts the storage structure and metadata of several hardware acceleration modules (e.g. CNN accelerator, FFT module, etc.), as well as how the logging module collects events from different seats (log lines labeled RECT, TRI, STEP, etc. of different types) and updates the Fence value in real time through a pipeline computation.

[0042] Figure 14 The figure illustrates an example of the control timing of a hot exchange reconfiguration, including steps such as data draining, pause section, execution of the configuration pointer exchange (between the dual bank configuration storage) and resuming operation, as well as the timing of key handshake signals (e.g. ACLK clock, AXI lane VALID / READY signals) during the process. The timing diagram of the figure illustrates graphically that the hot exchange only brings a very short pause, thus having a very small impact on the data flow processing.

[0043] Figure 15 The figure shows an end-to-end flow timeline illustration and corresponding audit log excerpts. The figure depicts the operation markers of multiple seat modules (Edge, Core, Fin) along the time axis, including the respective execution of the consistency check, one-time repair action and sealing point. On the side of the figure, an example of a "fairness snapshot" is given, which integrates the information of the LoL bypass audit, such as the step count difference between different nodes or committee indicators, and intuitively reflects the balance of the workloads of each part of the system during the entire operation.

[0044] Figure 16 The figure shows the implementation structure of the integrated optical link of the present application, including the optical transceiver, the transmission of the ABBA calibration sequence between two nodes, and the cooperation relationship with the electronic control part (serial / parallel converter, clock data recovery circuit, etc.). The figure also emphasizes how the optical link state is fed back to the consistency check (e.g. phase, parity, etc. conditions as part of the 6-AND input signal).

[0045] Figure 17 The figure illustrates the schematic diagram of the optical power budget verification mechanism, in which the input and output optical powers and the expected loss are monitored, and the powers at both ends are compared to ensure balance within the threshold range. The figure is similar to the optical counterpart of the electronic data conservation, ensuring that there is no unexplained optical power loss (such as fiber leakage). If the power imbalance exceeds the limit, the corresponding tear alert is triggered, such as switching to a redundant link or adjusting the device parameters for repair. DETAILED DESCRIPTION

[0046] In order to make the technical scheme of the present application more clear, the present application will be further described in detail below in combination with the drawings and specific embodiments.

[0047] Embodiments

[0048] The dynamic reconfigurable machine learning acceleration system combines a processing system (PS) and programmable logic (PL) in a single chip or tightly coupled module. The PL contains one or more partially reconfigurable hardware acceleration module regions, which can be dynamically loaded with different hardware configurations during runtime as needed by the task. The static logic region in the PL provides a unified Shell interface and on-chip network, allowing all reconfigurable modules to communicate with the rest of the system through standard interfaces (such as AXI4-Stream data channels and AXI4-Lite control channels, as well as interrupt lines, etc.), regardless of the module being loaded, using a consistent communication protocol. High-bandwidth memory (HBM) or DDR memory and a network-on-chip (NoC) are used for high-speed data transfer and configuration bitstream loading, ensuring low-latency reconfiguration operations with minimal disruption to running tasks.

[0049] The core of the present application is a runtime consistency guarantee closed loop. Each seat module (such as Edge edge node, Core cloud core service node, Fin financial settlement node, Gov governance / audit node, etc.) in the system implements two types of runtime monitoring internally: one is sequential exchange consistency check, which is used to verify whether the key operations occur in the correct structural order; the other is queue and storage conservation check, which is used to verify whether the data in the buffer queue and storage hierarchy is balanced, not lost or duplicated. These checks cover typical cross-service transaction scenarios. For example, in the EDGE or CORE seat module, the system checks whether the routing decision is strictly made according to the corresponding policy (ensuring the order of route and policy, such as route°policy correct order, as shown, there is sequential consistency check between operations of each layer); checks whether the cached data all have correct authorization tokens corresponding (cache°authorize pairing consistency); checks whether the financial settlement records are consistent with the imported transaction logs (settle°import corresponding check); and in the network data processing environment, checks whether the Segment Routing (SRv6) policy execution is performed in the correct encapsulation order (sr_policy°encap order consistency). Each pair of operations described above is a key link that needs to maintain the order and correspondence, such as deviation (for example, applying a policy to a wrong route, or a cache item missing a corresponding authorization), which is marked as structural inconsistency. Figure 2

[0050] ​At the same time, the system monitors the conservation relationship of various queues and storages to prevent data from being lost or created out of thin air. For example, for the flow of data packets through a buffer, the system verifies that the number of packets entering the buffer minus the number of packets flowing out of the buffer minus the number of discarded packets should equal the change in the length of the buffer (pkt_in - pkt_out - drop = Δqueue). Similarly, at each level of the storage hierarchy, the system tracks the number of data bytes written to storage, subtracts the total number of data bytes actually stored at each level, and subtracts the number of data bytes evicted, resulting in zero (ingested - Σ(level_bytes) - evicted = 0), ensuring that there is no data missing or duplication in a multi-level cache or storage system. These conservation constraints can be formalized as the above equation expressions, where each term can be collected and monitored in real time by hardware counters or software metrics. As shown in Figure 8 , the input, output, and discard counts of a buffer are used to calculate the difference in queue length to enforce the conservation relationship of the buffer; as shown in Figure 9 , in a hierarchical storage architecture, the usage of each layer of storage is measured to ensure that the total ingestion equals the sum of the storage occupancy of each layer plus the amount that has been moved out. By making such conservation laws explicit, the system can detect "tears" in the flow - i.e., points of discontinuity in the order violation or data anomaly.

[0051] When a tear (inconsistency) is detected through the above checks, the system's scheduler / arbitrator component will initiate a controlled remediation flow. A major feature of the present invention is to strictly limit remediation operations to "one-time" single actions, and to pre-classify available repair measures into three major priority levels: Geometry, Data Frame, and Timing / Window. Examples of repair actions include but are not limited to: Geometry-level repairs (e.g., reroute data flow to a different path or service instance, avoiding the problematic node; adjust network topology, switch to a backup link); Frame / Protocol-level repairs (e.g., change data packet format or encoding, align encryption frame format, re-encapsulate packets to conform to the expected protocol); Timing / Window-level repairs (e.g., add a small delay, adjust timeout window, reorder local operations to eliminate jitter). The system has repair adapter modules corresponding to the above three categories (e.g., Geometry, Frame, Timing) built in. Figure 12The selection rules follow the principle of as high level and minimal intervention as possible: prefer structural solutions (Geometry level) with wider scope, e.g. bypassing the fault by modifying topology or re-allocating task chain; if topology level cannot fully resolve or the tear is topology-agnostic, then try format / protocol level adjustment, e.g. switching protocol, correcting data format mismatch or padding metadata; if none of the above is applicable or sufficient, then finally resort to timing / window level fine-tuning, e.g. introducing temporary delay in the flow, resynchronizing timing, shaping burst traffic, etc. At each level, only one repair action is allowed to be executed at a time. This one-at-a-time intervention avoids the complexity of making multiple changes at the same time, so that the effect of each step can be observed and verified in isolation.

[0052] After the repair action is executed, the system strictly enforces a unit step convergence strategy. That is, the system requires that the overall consistency metric μ (e.g. the count of unresolved structural issues or the inconsistency metric value) must be exactly reduced by 1 with each repair. Formally, if the inconsistency before repair is μ before , then after repair it should satisfy μ after = μ before - 1. If the selected repair action fails to completely eliminate the target tear (e.g. the issue is complex and one repair is not sufficient), then it is considered as invalid or unsealed, does not count towards the convergence step, and a new repair measure needs to be re-evaluated and taken. In practice, however, since a tear is strictly defined as a structured and independent issue, one repair should correspond to resolving one issue. Therefore, the system repeats the “detect → repair → verify” process in an iterative loop: each round processes one tear, reduces μ by 1, and then globally checks whether there are still inconsistencies. If μ > 0, then it enters the next round, where the monitoring module detects the next inconsistency point, the arbitrator selects a new one-time repair action, and so on, until μ = 0, i.e. the system state is completely sealed and consistent. Figure 12 A finite state machine model (Sealer FSM) of this process is given, where the states include IDLE (normal operation), CHECK (detecting tears), APPLY (executing repair actions), VERIFY (confirming whether Δμ is 1 and the inconsistency is eliminated), and SEALED (reaching the complete consistent state). In each cycle, the FSM triggers the TXTLogger to record the taken actions and their results, and updates the check count.

[0053] The present invention requires that all critical operations, state changes, and fixes in the system's operation be recorded in a textual audit log. Rather than relying on private counters or obscure flag bits, the system uses human-readable text lines to record each step. For example, the result of each consistency check, each fix action performed, and its effect form a log entry containing information such as the identity of the relevant seat module, the nature of the check or action, a timestamp, and measured values. An example log fragment might look like this:

[0054] EVIDENCE seat=EDGE timestamp=... check=queue_conservation Δqueue=5 action=retime applied result=sealed FENCE=48179

[0055] This log entry indicates that an evidence record (EVIDENCE) was generated at the EDGE seat module, with a timestamp, the check was a queue conservation check, a queue length difference Δqueue=5 was found, the system performed a timing fix action "retime" as a result, the result was sealed after applying the action, and the Fence value computed at the end of the round was 48179. Similarly, a textual record is made whenever an important event occurs. All of these logs are securely stored in an append-only audit buffer (accessible by the GOV seat module or an external audit server). These logs can be used for later offline inspection or compliance verification, precisely reproducing what decisions the system made at each step and how the results turned out, providing a human-readable chain of evidence for the system's operation.

[0056] To facilitate quick verification of log integrity and locating a specific execution window, the present invention introduces a deterministic natural number checksum, called "Fence". The system computes this checksum value from the textual log content in real time according to a predetermined algorithm, which represents a digest of the log for a certain execution session, and outputs the value when the session is closed. The computation method is as described in the preceding claim 8, characterized by simplicity, determinism and independence from any secret key. A preferred implementation is to sum the encoded values of each line in the log, fold each line's data modulo a small prime number (e.g. 1009), and accumulate the weighted sum according to line number to generate a single integer result. For example, for a log segment within a closed session, the Fence value is computed in order to be 48179. As long as the audit log content is not altered, two independent observers will compute the same Fence value for the same log segment. If even a single character in the log is tampered with, the computed results will not match. This checksum is similar to a digital fingerprint, but does not require any cryptographic hash or secret key, and is therefore completely transparent and public. On hardware, a deterministic logic can be added in the PL's log recording module to update the Fence value in sync with the log generation (see Figure 13 where the TXT recorder updates the Fence count in real time while collecting events). It is emphasized that the Fence value is only used for external audit verification, and does not participate in the system's own control decisions or gating.

[0057] To avoid any hidden or threshold-based internal gating, the present invention moves all final result decision logic to the system periphery. Individual seat modules do not shut down or change behavior on their own due to an internal count or threshold reaching an upper limit. Instead, a dedicated six-input AND (6-AND) logic gate is set at the system output stage to make a comprehensive judgment of the system's health and readiness. The six inputs correspond to six independent conditions, examples of which include: (1) a data parity check signal indicating no parity check errors in the data stream; (2) a phase synchronization status signal indicating that the clock / phases of the system parts are properly aligned; (3) a twist / orientation signal indicating that the order or orientation is consistent in data conversion or parallel processes, without unexpected flips or misordering; (4) a tag / authentication signal indicating that all data units have passed the correct tag or token verification; (5) a resource measurement signal indicating that all resource utilization rates are within the expected range (no overload or unresponsive state); and (6) an interface adhesion signal indicating that the cooperation of cross-module interfaces (as the "glue" between components) is consistent and the communication protocol handshake is correct. These six signals are connected through an AND gate logic at the system output, and only when all six conditions are true (high level) is the result considered valid and finally submitted. In other words, if any one of the conditions is not met, the system output result will not be accepted, and the repair loop described above will be used to correct the relevant problems until all six conditions are met. This external gating mechanism (represented by the Door module in the system overview of Figure 1 ensures that no single seat module can silently affect the overall system due to its internal state: all important acceptance conditions are included in explicit, monitorable signals, and are uniformly judged outside the system. Therefore, the system avoids any form of hidden gating, and only uses the above-mentioned external 6-AND gate as the only acceptance criterion, and the inputs of this gate are also driven by explicit monitoring logic and recorded.

[0058] In addition to the core consistency and repair mechanism, the acceleration system of the present invention also incorporates advanced partial reconfiguration technology, allowing hardware functions to be dynamically adjusted on the fly and minimizing the impact of the process. As shown in Figure 1 the present system is implemented on a system-on-chip (SoC), which includes a processing system (PS) and a programmable logic (PL) as its two main parts. One or more partially reconfigurable regions are divided in the PL for loading different hardware acceleration modules. A reconfiguration management module called minimum region replacement (MRR) is integrated in the PL, which is responsible for loading new accelerator configurations with minimal overhead. Figure 3The working principle of MRR is illustrated: the system maintains a library of accelerator modules, which stores hardware configuration bitstreams of various machine learning operators or functional modules (such as neural network layers of different architectures, acceleration modules implementing compression, etc.). When a module needs to be switched, instead of transmitting the complete bitstream, the MRR module attempts to transmit the delta data between the current configuration and the target configuration. By performing XOR comparison between the existing configuration and the target configuration, and supplemented by compression algorithms, the amount of data to be transmitted can be greatly reduced to the level of 4-64 KB (much smaller than the size of the complete bitstream). These delta data are sent to the configuration controller in the PL in the form of a stream through the NoC, and the configuration controller decodes and applies XOR to the delta data on the chip to update the current configuration to the target configuration. At the same time, CRC and other check information are embedded or attached in the data stream, and the reconfiguration controller on the chip calculates the CRC or other integrity check of the updated configuration, and activates the new module after confirming that the configuration is correct.

[0059] In order to realize uninterrupted fast reconfiguration, the present application adopts a dual-bank architecture to store and switch hardware configurations (such as Figure 4The PL is configured with two banks (Bank A and Bank B) that can alternate between active and standby configuration. The system runs the current hardware module on one configuration bank while preloading the next required hardware configuration bitstream on the idle standby bank. The hot swap of reconfiguration is done through a carefully designed micro-sequence that minimizes the disturbance to normal data processing. The steps include: (a) Drain: The scheduler first suspends sending new data to the accelerator module that will be reconfigured and waits for the module to finish processing the existing data (ensured by monitoring the AXI4-Stream FIFO status that there is no pending data at the module input); (b) Quiesce: Send a suspend signal to the target reconfigurable partition to ensure it stops accepting new inputs and enters an idle stable state; (c) CRC Check: The new partial bitstream in the standby bank is loaded at this point, the system triggers a complete integrity check (e.g. compute CRC or hash through the on-chip ICAP interface or vendor-provided reconfiguration controller) on the new configuration to ensure the bitstream is not corrupted and compatible with the current shell; (d) Pointer Swap: After confirming the new configuration is reliable, the system swaps the pointers of the active and standby banks in an atomic operation - i.e. mark the bank with the new configuration as active and let the corresponding accelerator logic take over the data path. This swap operation happens in one clock cycle, so the reconfiguration is instantaneous from the system's perspective (if this reconfiguration is triggered to fix a tear, this hot swap action is also logged as a single-step fix in the audit log and verified for its patching effect); (e) Un-quiesce: Un-suspend the reconfigured region so that the newly loaded hardware module starts to receive and process the subsequent data stream. The entire swap process is very short - the data stream pause introduced by this hot swap is only about 68-91 microseconds (ps) in the test, which is almost negligible. Due to the dual-bank design and stream-based differential loading, the preloading of the new module is almost parallel to the running of the old module, with only a momentary pause at the end of the swap. Therefore, the reconfiguration operation does not break the system's structural consistency check, as the system treats it as a controlled single-step operation, and the reconfiguration event and its verification are also logged in the log (the module swap event is noted in the log and confirmed in the subsequent check steps that the replacement has solved the corresponding problem).

[0060] The acceleration module library contains hardware implementations of various machine learning operators or functions (such as quantization modules, convolution engines, matrix multipliers, FFT accelerators, sorting / search cores, etc.). Each module is optimized for a specific algorithm category and follows a unified Shell / ABI interface specification, allowing for dynamic plug-and-play replacement within the system without modifying other parts. These modules can be stored in on-board flash memory or external storage and are maintained and loaded by the PS. The module library typically also includes metadata (such as module compatibility IDs, resource usage, interface versions, etc.) to ensure that modules match the current Shell at load time. The system can preload certain modules: the scheduler can preload the accelerator modules that will be needed soon in idle reconfigurable areas based on known task patterns or by predicting future task requirements through machine learning, reducing real-time latency. If all reconfigurable areas are occupied and a high-priority task arrives, the system can also interrupt a low-priority module: wait for it to finish processing its current data before unloading it and replacing it with the module required by the high-priority task. All of these dynamic module management behaviors are carried out within the aforementioned consistency framework: any such module replacement is logged in the audit log and resource conservation is verified (e.g., ensuring that the state of the removed module is saved or that the data it processes is not lost).

[0061] Throughout the operation, the system not only maintains logs and performs validations, but also provides additional audit bypass channels to offer visual insights into performance and fairness without impacting control decisions. One such channel is called the "LoL" bypass audit (internally nicknamed "Ledger-of-Ledgers"). This channel aggregates and compares progress metrics from different modules or task domains to form a "conference" view. For example, if two edge nodes A and B are processing tasks in parallel, the system can calculate the difference in their step counts over a certain period, ρ(A→B) = |steps_A - steps_B|. This ρ value reflects the deviation in the progress of the two nodes; if one node is significantly lagging, the ρ value increases. The LoL bypass can collect multiple similar metrics (across multiple edge nodes or between the edge and the cloud) and aggregate them into a comprehensive fairness or synchronicity assessment (i.e., a "conference" metric, which may be represented by a set of ρ values ​​or their statistical summary). It is important to emphasize that these metrics are only used for monitoring and post-event analysis; the system does not make any real-time control adjustments or gating decisions based on these metrics. These are provided to operations personnel through audit logs or dedicated visualization interfaces. The reason it is called LoL (possibly alluding to "book within a book") is because it is like a committee report that compares multiple execution ledgers. Figure 15A timeline diagram of the execution across multiple modules is provided, which marks each checkpoint, one-time repair, and closure point, and highlights the differences in steps recorded by LoL bypass, providing a "snapshot" of the system's load balancing status during this period.

[0062] Another audit extension is the "TTB-warp" mechanism. TTB-warp is used to record evidence of continuity across cycles after the system reaches a sealing state. When the system completes a sealing cycle (i.e., all inconsistencies are resolved, μ returns to 0) and continues long-term operation, information from multiple time domains can be captured to demonstrate the continuity of long-term operation. For example, the system can record the current local monotonic clock count, the real-time clock value, and an external reference time (such as GPS or network time), and then calculate the time difference "warp" (e.g., in milliseconds) experienced between the start and end of this sealing cycle. These three timestamps from different sources and the warp difference together constitute a receipt for long-term continuity. This receipt is archived in a long-term audit log (which may be called a Panorama Book) for retrospective review of the system's long-term behavior to ensure that the system seals periodically and without interruption, even over hours or days of operation. Like all other audit logs, TTB-warp data does not affect runtime controls; even if it shows some drift trends (e.g., increased clock drift), it does not automatically trigger actions at runtime but is left for offline processing by engineers or governance processes. Through these audit bypass mechanisms, this invention greatly enhances operational transparency and auditability without affecting system performance.

[0063] This invention supports commonly used network and service configurations and can be applied to various complex environments. For example, the system is fully compatible with IPv6 and SRv6 network protocols, meaning that consistency checks and repair mechanisms can be applied to systems using IPv6 addressing and segment routing. For instance, when a structure check failure is detected during SRv6 policy execution, the system can perform a one-time frame-level repair by reordering the segment list in the SRv6 header or repackaging the packet with the correct segment list format, and then continue execution and verify unit-step convergence. Similarly, the system can handle ECMP (Equal Cost Multipath) and VRF (Virtual Router Forwarding) environments: the topology-level logic understands these concepts and incorporates them into geometry-level decisions, switching to an alternative equal cost path when path problems occur, or adjusting across multiple virtual routing domains. The system is also suitable for hierarchical caching architectures (multi-level caching from edge to core), as previously demonstrated through storage conservation checks, auditing and guaranteeing data movement at each level of cache. Furthermore, for new flow control semantics brought about by new transport protocols such as HTTP / 3 (QUIC), the system can also extend new order check rules in a modular manner. In summary, this framework is protocol-agnostic and can add corresponding inspection rules for new protocols or processes. It can be implemented modularly in the PS software or the accompanying monitoring logic.

[0064] Performance data: The system of this invention demonstrated significant performance and reliability advantages in prototype testing. The following figures were collected from system operation in the form of audit receipts, proving the effectiveness of the system:

[0065] Reconfiguration latency: In a single test deployment (N=5 sample runs), the measured 50th percentile (median) latency for partial reconfiguration and sealing completion was 27.4–31.6 ms per run (median approximately 29.0 ms), and the 95th percentile latency was 41.9–52.1 ms (typically approximately 45.8 ms). This means that from detecting the need to replace a hardware module to completing a repair and verifying sealing, it typically takes only tens of milliseconds, which is acceptable even in scenarios with high real-time requirements.

[0066] Throughput: The system can maintain a processing throughput of 1620–2140 operations / second (average of about 1890 ops / s) under continuous task flow, showing that dynamic replacement of accelerator modules does not cause a significant bottleneck to the overall throughput, and the system can run continuously at a speed close to that of fixed hardware.

[0067] Energy efficiency: The measured performance-per-watt (PPW) ratio is between 2.6 and 3.2 (unit is normalized index, central value is about 3.0), indicating that the system still maintains high hardware utilization efficiency under strict consistency monitoring mechanism.

[0068] Partial reconfiguration bandwidth: The internal bitstream loading path achieves an effective throughput of approximately 2.3–2.7 Gb / s (average approximately 2.5 Gb / s) through NoC and ICAP, thanks to streaming differential loading and compression, which significantly reduces the time required for reconfiguration.

[0069] Hot-switch time: The downtime for each partial reconfiguration hot-switch process (from pausing the data stream to resuming) is only 68–91 μs (median approximately 79 μs), which is negligible in most processing pipelines. This demonstrates that the dual-bank fast switchover mechanism reduces downtime to an extremely low level.

[0070] NoC utilization: The effective latency utilization of the on-chip network in continuous transmission is approximately 0.69–0.80 (average approximately 0.74, relative to the theoretical maximum of 1.0), indicating that the NoC maintains efficient operation and does not become a bottleneck even during reconfiguration of burst data transmission.

[0071] All the above data were output by the system as audit receipts (rather than measured manually) and can be found in logs or operation summary reports. These results demonstrate that the method of this invention not only guarantees correctness and auditability but also has acceptable performance overhead, making it competitive with traditional acceleration methods.

[0072] Extended Implementation: Photonic Links and Other Improvements

[0073] Extended Implementation: Photonic Links and Other Improvements In an extended embodiment, the acceleration system of this invention integrates a photonic communication link for providing ultra-high bandwidth, ultra-low latency connectivity between certain bores modules (e.g., between an edge device and a core data center). Even in the optical communication domain, the consistency paradigm of this invention is extended and applied. Reliable operation of the optical link requires maintaining signal alignment in the optical domain—e.g., laser phase synchronization, wavelength calibration, etc. This system integrates an optical-to-electrical transceiver interface (O / E interface) module and an optical power monitor module in the PL circuit. To ensure the sequential consistency of optical signal exchange, the system employs a reference signal calibration sequence (internally also known as the "ABBA" mode, used to synchronize phase by sending a specific alternating bit sequence). During the boresight calibration process, paired optical modulators and detectors send a predetermined ABBA signal sequence, thereby locking the phase and frequency of the transmitting and receiving sides into a consistent state. During this process, structural checks verify that the optical signals from bores A to bores B and back (A→B→A) are correctly aligned within specified error tolerances, without periodic slippage or polarity "twisting". Once a "tear" is detected in the optical link, such as a phase shift lock, the system performs a one-time repair action: this could be a phase adjustment (by fine-tuning the laser's phase) or switching to a backup fiber channel (which can be classified as a Geometry-level repair, as it adjusts the link's topology). As with issues in other domains, this calibration repair is a one-step process. The monitoring logic then verifies that the phase signal has relocked, the optical link is back to normal, and the event is logged (e.g., the log notes "Optical link out of sync, phase shift Δϕ correction applied, alignment verified as passed").

[0074] Optical links also follow similar conservation principles: the system monitors the optical power entering and exiting the fiber, and, considering known line losses, calculates the optical power budget to ensure there are no unexplained losses exceeding a threshold (e.g., if a sudden drop in optical power is detected that exceeds expectations, it may mean the fiber connection is broken or there is severe attenuation). If the optical power budget is unbalanced (exceeding the allowable error), the system treats this as a "tear" and can take one-time corrective measures, such as switching to a redundant fiber path (if available) at the topology level, or adjusting the optical amplifier gain at the frame level to compensate for the loss. Similar to other corrective actions, the system guarantees that the action is performed only once and verifies Δμ=1.

[0075] In long-running systems involving optical communication, TTB-warp logs are particularly important for verifying time continuity. Although optical links are fast, slight drifts in the local oscillator and network clock can occur if the system runs continuously for several hours. The timestamps recorded by the TTB-warp mechanism after each system completes a sealing process and continues operating for an extended period reflect this drift. As mentioned earlier, a TTB-warp log entry might contain: Core = CORE, Period = 3600 seconds, μ / m / M = 0 / 0 / 1 (potentially indicating that μ eventually reaches 0 within this period, with no inconsistencies or hidden gating triggers), warp = 5ms, and Fence = 37291. This means that during one hour (3600 seconds) of operation, the optical link remained sealed, with a 5-millisecond offset (warp) between different time domain readings and the starting point. The calculated Fence value for all logs within this period is 37291. This information is archived in the long-term audit log (PanoramaBook) for compliance review and is not involved in runtime control. Even if the warp value increases slightly over a period of time (indicating possible clock drift), the system will not intervene automatically; instead, decisions will be made manually or by upper-level governance after the fact. This approach ensures that even when complex optical links are involved, the system still follows the approach of one-time repair, log auditing, and external judgment, avoiding frequent and disordered adjustments due to noise or drift at the analog layer, thus maintaining the auditability and determinism of optical layer behavior.

[0076] The dynamically reconfigurable machine learning acceleration system described in this invention has broad application prospects in modern data centers, communication networks, and edge computing deployments. It can be deployed as a reconfigurable accelerator card in a cloud server or as an embedded AI acceleration module in an edge device. For scenarios requiring high performance and strict accuracy, this system can flexibly update hardware functions or correct operational errors without service interruption. For example, in a financial trading platform, this system can be used to build a collaborative acceleration architecture spanning edge devices (market data collection, EDGE), core cloud services (risk computation, CORE), clearing / settlement systems (FIN), and regulatory audit modules (GOV). Once a risk model hardware update is detected (e.g., algorithm upgrade) or inconsistencies in transaction records, this system can automatically perform partial hardware reconfiguration (loading the new model within microseconds) or adjust the data processing flow to fix the problem step-by-step, while logging the entire process. The validity of the final transaction execution is determined by a comprehensive set of six external conditions. These six conditions correspond to: data verification passed, clock synchronization normal, transaction direction correct, identity tag verification passed, account balance / resource check normal, and cross-module interface consistency. Only when all conditions are met is the transaction allowed to proceed; otherwise, the system continues to correct itself through the aforementioned closed loop. This allows the platform to automatically prevent abnormal transactions while remaining completely transparent and auditable. Every decision is supported by logs, meeting financial regulatory requirements (such as the detailed recording of automated trading systems required by MiFID II).

[0077] The transparency and auditability of this system also make it suitable for fields with extremely high requirements for process compliance, such as healthcare and government cloud. All decisions made by internal thresholds, counts, or machine learning models are reflected in the audit logs, ensuring that any reasoning process or adaptive behavior is no longer a black box. For example, in a healthcare data processing scenario, if a privacy budget (ε,δ) is used to control differential privacy leaks, this system will not lock down internally when the budget is exhausted, as is the case with traditional solutions. Instead, it will only record the budget value in the logs for regulatory review, and external policies will determine subsequent actions. This ensures that the implementation of privacy policies is auditable and does not affect system real-time performance, providing a basis for human intervention when necessary.

[0078] Furthermore, because all critical actions are recorded as evidence and can be recalculated and verified, this system greatly facilitates debugging and quality assurance. In a production environment, known inconsistencies can be triggered to verify whether the system corrects them as expected in a single step and outputs the correct logs and fence checksums. This is much more intuitive than traditional systems that require guessing internal states or waiting for errors to reproduce, thereby reducing maintenance difficulty and mean time to repair (MTTR).

[0079] Compared to existing technologies, this invention integrates hardware flexibility, operational correctness, and process transparency. On one hand, through partial dynamic reconfiguration and fine-grained scheduling, it achieves efficient utilization and on-demand adaptation of hardware resources. On the other hand, through closed-loop control of sequential checks, conservation checks, and single-step sealing, it ensures strict consistency and verifiability of the operational process. Furthermore, through full text recording and deterministic verification, it achieves comprehensive auditing and reproducibility of the operational process. This combination is crucial in next-generation intelligent cloud-edge infrastructure: it allows systems to quickly adapt to changes, automatically correct themselves, and provide credible operational evidence to meet compliance and trust requirements.

[0080] In summary, the dynamically reconfigurable machine learning acceleration system of this invention can significantly improve the reliability and transparency of distributed AI computing systems without sacrificing performance, making it suitable for industrial environments with high requirements for both performance and accuracy. For example, large data centers can use this system to improve service availability and maintainability, telecommunications network nodes can leverage their rapid hot-switching capabilities to meet real-time traffic adjustments, and edge computing devices can integrate into data processing workflows requiring oversight through their auditing capabilities. This system is compatible with existing hardware and software standards (AXI bus, IPv6 network protocol, etc.) and can be smoothly integrated into existing infrastructure, adding structured self-checking and self-healing capabilities without requiring comprehensive changes to the surrounding system architecture. Therefore, this invention has broad prospects for industrial applications.

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

Claims

1. A dynamically reconfigurable machine learning acceleration system, comprising a processor subsystem (PS), a programmable logic subsystem (PL), a memory, and a runtime controller, characterized in that: A. A deformable partially reconfigurable region (MRR) is provided within the PL, the boundary of which can be expanded or shrunk at runtime according to the discrete step size without changing the structure of the static shell within the PL; B. The PL is equipped with dual bank bitstream channels to realize the streaming loading and in-situ switching of differential or relocatable bitstreams for partial reconfiguration operations; C. The system provides a unified Shell interface and an Application Binary Interface (ABI) with version control, enabling the acceleration module to achieve binary-level hot-plugging without modifying the Shell; D. During operation, the system constrains the execution path through structured consistency checks, including at least the following two types of checks: operation order exchange consistency check and queue / storage balance check; when any inconsistency or "tear" fault is detected, the system only allows one-time repair operation, and selects repair measures in the order of topology / path (Geometry) first, then format / protocol (Frame), and then timing / window (Field); each repair reduces the inconsistency μ by 1, achieving unit step convergence until the system reaches a closed consistency state; the system outputs all events and results only in text form as an audit log, and calculates a deterministic natural number fold check value as a "Fence" for external verification for each closed operation window; the final result acceptance of the system is performed by a six-input AND logic gate set outside each module, and the processing result is considered valid only when all six independent condition signals are true.

2. The dynamically reconfigurable machine learning acceleration system according to claim 1, characterized in that, The dual-bank streaming partial reconfiguration loads the new configuration by transmitting differential data blocks of bitstream size 4–64KB, and includes on-chip XOR differential synthesis and decompression logic. Block-level CRC checks are performed on the loaded bitstream to ensure that integrity verification passes before activating the new configuration, thereby supporting in-situ fast switching of the acceleration module configuration.

3. The dynamically reconfigurable machine learning acceleration system according to claim 1, characterized in that, The deformable reconfigurable region (MRR) achieves millisecond-level region boundary expansion or contraction through a predefined boundary parameter table and clock / reset domain retention technology, without affecting the timing convergence of the Shell fixed logic.

4. The dynamically reconfigurable machine learning acceleration system according to claim 1, characterized in that, The processor subsystem and programmable logic subsystem are integrated in a single system-on-a-chip (SoC). The processor communicates with the reconfigurable region via an AXI4-Lite bus as a control plane interface and an AXI4-Stream bus as a data plane interface. The on-chip interconnect uses a credit-managed network chip (NoC) to support zero-copy data transmission and back-to-back transmission. The memory includes high-bandwidth memory (HBM) or DDR to achieve high-speed data throughput and partial reconfiguration bitstream transmission.

5. The dynamically reconfigurable machine learning acceleration system according to claim 1, characterized in that, The operation order exchange consistency check includes at least the verification of the quantization → convolution order and the concatenation → normalization order to ensure that the two operations occur in the correct order and produce consistent results.

6. The dynamically reconfigurable machine learning acceleration system according to claim 1, characterized in that, The queue and storage conservation checks include monitoring at least the following two types of conservation relationships: Buffer queue conservation: Verify that the number of input frames to the queue - the number of output frames to the queue - the number of discarded frames = the change in queue length, ensuring that no data is added to or disappears from the queue out of thin air; Storage tier conservation: Verify that the number of bytes written by DMA - the sum of the number of bytes occupied by each storage level - the number of bytes read out (or evicted) by DMA = 0, to ensure that the total amount of data in the multi-level storage tier is balanced; if any conservation relationship is not found, it is immediately determined to be a "tear" inconsistency, and only one repair is performed and Δμ = 1 is verified.

7. The dynamically reconfigurable machine learning acceleration system according to claim 1, characterized in that, The one-time operation used to repair the "inconsistency" fault is classified into three priority levels, corresponding to the topology / path (Geometry), format / protocol (Frame), and timing / window (Field) priorities, specifically including but not limited to: topology / path level repair; format / protocol level repair; timing / window level repair; each time only one repair action is selected from the above three levels to be executed to handle the inconsistency fault.

8. The dynamically reconfigurable machine learning acceleration system according to claim 1, characterized in that, The checksum (Fence) of the text audit log is obtained by summing the sequentially encoded log lines within the audit window. The calculation formula is as follows: Fence=∑((i+1)×(∑code(line i )mod1009)) Where index i represents the i-th line in the audit log, code(line i The function is a predefined function that encodes the text of a line into a number. The encoded value of each line is first folded by taking the modulo 1009, then multiplied by (i+1) for weighting, and then summed to obtain the final Fence value. The Fence value is a pure natural number and is not encrypted. It can be independently calculated and verified by any observer based on the log content, thereby verifying the integrity and correctness of the audit log.

9. The dynamically reconfigurable machine learning acceleration system according to claim 1, characterized in that, When the system includes photonic input / output links or interconnects, further optical domain consistency checks and conservation monitoring are performed, including verifying the O / E sequence consistency of optical signals and optical power conservation; once an inconsistency is detected on an optical link, the corresponding correction is performed only once, and the correction operation is ensured to reduce the inconsistency μ by 1.

10. The dynamically reconfigurable machine learning acceleration system according to claim 1, characterized in that, After the system reaches the sealing state, it records a long-term time continuity proof. The receipt includes timestamps or counts from multiple time bases and a "warp" time difference across the period. This receipt is archived as audit evidence to prove that the system has maintained a consistent state over a long operating period, but does not have any gating effect on the system operation process.

Images