Motion planning hardware acceleration method and device based on sphere-level speculative scheduling
By adopting a pipeline architecture of 'generate first, predict later' and processing high and low priority queues, the problem of granularity mismatch in existing technologies is solved, achieving high-precision collision detection and high recall rate, thus improving the performance of robot motion planning.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- ZHEJIANG UNIV
- Filing Date
- 2026-01-05
- Publication Date
- 2026-04-17
AI Technical Summary
Existing hash-based collision predictors suffer from granularity mismatch when dealing with multi-sphere robot models, leading to decreased prediction accuracy and recall in complex environments and limiting the improvement of motion planning performance.
Employing a pipeline architecture of 'generate first, predict later', it achieves accurate collision detection by parallel computing of the world coordinates of all spheres in the robot model, parallel hash prediction and speculative assignment, using high and low priority queues to process sphere tasks, and combining dynamic feedback and self-correction mechanisms.
It significantly improves the prediction accuracy and system throughput of collision detection, reduces the risk of false negatives in complex environments, reduces computational load, and improves resource efficiency.
Smart Images
Figure CN121876989A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of robot motion planning and hardware acceleration technology, and particularly relates to a motion planning hardware acceleration method and device based on sphere-level speculative scheduling. Background Technology
[0002] Motion planning is a fundamental capability for autonomous robots operating in dynamic environments, supporting a variety of tasks from industrial assembly to human-robot collaboration. In sampling-based planning algorithms (such as RRT* and PRM), a large number of robot poses need to be validated to find feasible paths. Collision detection (CD) is typically the most computationally intensive and time-consuming step, with studies showing it often accounts for over 90% of the total planning time. Therefore, addressing the latency issue in collision detection is crucial for achieving real-time motion planning.
[0003] To ensure safety and achieve efficient distance queries, modern motion planning frameworks (such as NVIDIA's cuRobo) are increasingly adopting sphere-based modeling. In this modeling approach, complex robot links are no longer represented by oriented bounding boxes (OBBs), but by a set of approximate multi-spheres. Compared to complex OBB geometric operations, spheres possess rotational invariance, and intersection testing between spheres is simpler and more efficient.
[0004] To address the computational challenges of collision detection, the industry has begun to turn to dedicated hardware accelerators. Early hardware accelerators primarily targeted simple geometry or graph search stages. Currently, the most advanced collision predictor is the COPU (Collision Prediction Unit) architecture proposed by Shah and Aamodt. COPU employs a "predict-then-generate" pipeline. Its core mechanism is based on "link-level" hash indexing: the hardware calculates the hash value of the geometric center of the robot's links and uses it to query the Collision History Table (CHT). Only when the prediction indicates a potential collision will the system generate a detailed bounding volume for accurate intersection testing.
[0005] While COPU is effective in handling single-link systems, it suffers from a serious "granularity mismatch" problem when applied to modern multi-sphere-based robot models, specifically manifested in the following aspects: The center of a link cannot represent spatial discrepancy: such as Figure 2 As shown, robot links are typically long, and their geometric centers are often far from the specific spheres that make up the link. Different spheres within the link may be in completely different collision states (e.g., a sphere at one end of the link collides while a sphere at the other end remains safe). Coarse-grained predictions based on the link center lead to frequent false negatives (missed risks) and false positives (wasted computation).
[0006] Rotation sensitivity: such as Figure 1 As shown, the collision state of an OBB or link is highly dependent on orientation, and hashes based on link centers often ignore orientation information. In contrast, a sphere has rotational invariance, but this property is not fully utilized in COPU's "pre-prediction" process.
[0007] Blind spots in assembly line structures: such as Figure 3 As shown, COPU employs a "predict first, generate later" process, meaning that the predictor cannot obtain the precise spatial coordinates of each sphere inside the link when making scheduling decisions. This architectural limitation forces the predictor to rely solely on the link center for fuzzy inference, preventing it from using more refined sphere coordinates for precise filtering.
[0008] In summary, existing hardware acceleration technologies for robot motion planning, especially hash-based collision predictors, suffer from a mismatch between prediction and detection granularities when dealing with modern multi-sphere-based robot models. This leads to a decrease in prediction accuracy and recall in complex, high-obstacle-density environments, limiting further improvements in overall motion planning performance. Summary of the Invention
[0009] This invention aims to solve the core technical problem of how to eliminate the granularity mismatch between collision prediction and collision detection, and improve the prediction accuracy and system throughput of collision detection based on the multi-sphere model without increasing on-chip storage overhead.
[0010] To address the aforementioned technical problems, the present invention provides a specific technical solution for a motion planning hardware acceleration method and device based on sphere-level speculative scheduling, as follows: A hardware acceleration method for motion planning based on sphere-level speculative scheduling, employing a "generate first, predict later" pipeline architecture, includes the following steps: Step 1: Sphere generation; Using the sphere generation unit, based on the input robot joint angle configuration and robot kinematics model, the world coordinates of all spheres in the robot model are calculated in parallel through forward kinematics. Step 2: Parallel hash prediction and speculative allocation; For each sphere generated in step 1, perform hash prediction and classification assignment in parallel; Step 3: Speculative execution; The collision detection unit array is used to process tasks in the queue based on the "early exit" principle.
[0011] Furthermore, step 1 includes: Iterate through each link of the robot model, and for each sphere within a link, convert its local coordinates to world coordinates, thereby generating a list of spheres containing the precise positions of all spheres.
[0012] Furthermore, step 2 includes the following sub-steps: Step 2.1: Calculate the spatial hash index: Using a parallel hash prediction engine, read the world coordinates of the sphere, and generate a hash index by selecting specific bit combinations of the center coordinates of the sphere through bit extraction and concatenation. Step 2.2: Query the collision history table: Use the calculated hash index to query the collision history table CHT. CHT returns the historical collision prediction status for this spatial location. Step 2.3: Speculative Assignment: Distribute the ball task to queues of different priorities according to the predicted state: if the predicted state is "1", it indicates a potential collision, and push the ball task into the high-priority queue; if the predicted state is "0", it indicates safety, and push the ball task into the low-priority queue.
[0013] Furthermore, step 3 includes the following sub-steps: Step 3.1: Prioritize high-priority queues: As long as the high-priority queue is not empty, the scheduler will take the sphere task from the queue and send it to the collision detection unit array for precise geometric intersection testing. If a real collision is found in the test, it is determined that the current robot posture has collided, all subsequent tasks are immediately terminated and the "collision" result is returned. At the same time, the query update unit is used to confirm the state of the position in CHT as "1". Step 3.2: Secondary processing of low-priority queues: The scheduler only processes tasks in the low-priority queue when the high-priority queue is empty and no premature exit has occurred. If a real collision is detected while processing a low-priority task, the task is immediately terminated and a "collision" result is returned. The query update unit is used to correct the CHT, and the status bit of the corresponding hash index is updated and flipped to "1" to achieve self-correction. Step 3.3: If no collision is detected after clearing both queues, return a "no collision" result.
[0014] This invention also discloses a hardware acceleration device for implementing the aforementioned motion planning hardware acceleration method based on sphere-level speculative scheduling, the device comprising the following core modules: Sphere generation unit: Located at the front end of the pipeline, used to receive joint configuration data of the robot; Parallel hash prediction engine: Connected to the output of the sphere generation unit, this engine contains a set of hash calculation units that work in parallel; Collision history table: This is an on-chip memory used to store the collision history state of the discretized space; Speculative Sphere Distributor: Connected to the parallel hash prediction engine and collision detection unit, this module adopts an asymmetric routing architecture and contains two physical FIFO queues; Collision detection unit array: connected to the speculative ball dispatcher, containing multiple parallel geometry test cores for receiving ball tasks and performing accurate ball-obstacle distance calculations or intersection tests; Query Update Unit: Connected between the collision detection unit array and the collision history table, it is used to receive the actual detection results of CDUs and write and update the corresponding entries in the collision history table when the detection results are inconsistent with the prediction results.
[0015] Furthermore, the sphere generation unit adopts a "macro-micro" two-layer pipeline design: Positive kinematics engine: As the first-stage pipeline, it adopts a deeply pipelined pulsating array structure to calculate the pose matrix of each link in real time and uses a double buffering mechanism to mask the calculation delay. Parallel Transformation Engine: As the second-stage pipeline, it contains P=4 parallel computing channels. This engine reads the local geometric parameters stored in the Link lookup table, combines them with the pose matrix generated by the FK engine, and outputs the world coordinates of the four spheres in parallel in a single cycle. Effective masking mechanism: For cases where the number of spheres is not aligned, a mask signal is dynamically generated to mark invalid calculation channels, and downstream modules can automatically filter invalid data accordingly.
[0016] Furthermore, the hash calculation unit of the parallel hash prediction engine includes: Spatial gridded hashing: Each cell performs hardware hashing based on coordinate position extraction and splicing, extracting specific segments of coordinates through configurable shift parameters, mapping a continuous 3D space into discrete grid indices; Three-dimensional interleaved storage: The low-order bits of the grid index are used to generate the Bank selection signal and the high-order bits are used to generate the row address, so as to achieve conflict-free parallel access to the multi-bank CHT. Ratio prediction logic: Read the collision counter and safety counter in CHT, perform ratio comparison, and generate a binarized prediction result.
[0017] Furthermore, the two physical FIFO queues of the speculative sphere distributor include: High-priority queue: of moderate depth, used to cache sphere tasks predicted as "potential collisions", employing serialized write logic to handle sparse collision risks; Low-priority queue: It has a larger depth and is used to cache sphere tasks that are predicted to be "safe". It adopts wide-bus parallel write logic and absorbs 4 safe spheres per cycle to ensure that the upstream pipeline is not blocked.
[0018] Furthermore, the speculative sphere dispatcher is configured with dequeue arbitration logic: strictly prioritizing the reading of tasks in QCOLL and sending them to the backend; and has a bubble filtering function to automatically remove invalid gaps in the low-priority queue caused by parallel packaging.
[0019] The hardware acceleration method and apparatus for motion planning based on sphere-level speculative scheduling of the present invention have the following advantages: The "Generate First, Predict Later" spherical-level pipeline architecture breaks away from the traditional "predict first, generate later" process. Before hash prediction, it utilizes a two-layer pipeline (positive kinematics engine + parallel transformation engine) to calculate the precise world coordinates of all spheres in the robot in parallel. By refining the prediction granularity to the "spherical level," it directly uses spherical coordinates for spatial hashing, fundamentally eliminating the rotational sensitivity and spatial variability problems caused by link center proxy, significantly improving prediction accuracy and recall.
[0020] Historical Speculative Scheduling: A dual-queue dispatch mechanism with high-priority (QCOLL) and low-priority (QNONCOLL) tasks is designed. A parallel hash engine queries the collision history table (CHT) to obtain the historical collision status of the spheres, and dynamically routes the spheres to different queues accordingly. The hardware scheduler strictly prioritizes tasks in the high-priority queue to achieve rapid detection of potential collisions (Early Exit); low-priority tasks are only processed when the high-priority queue is empty to prevent false negatives.
[0021] Dynamic feedback and self-correction mechanism: Establishing a closed-loop update path from detection to prediction. When a real collision is detected in a low-priority queue (i.e., a task predicted to be safe), the query update unit immediately corrects the corresponding entry in the collision history table. This mechanism utilizes the principle of temporal locality, enabling the system to adapt to environmental changes and achieve efficient collision filtering through constructed spatial aliasing without increasing on-chip storage overhead (maintaining a small capacity of SRAM). Attached Figure Description
[0022] Figure 1 This is a schematic diagram of the rotational sensitivity (OrientationAliasing) in collision prediction based on the link center in the existing technology; Figure 2 This is a schematic diagram illustrating the spatial discrepancy problem in collision prediction based on the link center in existing technologies. Figure 3 This is a schematic diagram of the "predict-then-generate" pipeline used in existing technology (COPU); Figure 4 This is a schematic diagram of a motion planning acceleration method based on sphere-level speculative scheduling. Figure 5 This is an overall architecture block diagram of the motion planning hardware acceleration device based on sphere-level speculative scheduling provided in this embodiment of the invention; Figure 6 This is a comparison chart showing the effect of the embodiments of the present invention in reducing the number of collision detection queries (CDQ) compared with the prior art under different obstacle densities (G1-G5); Figure 7 This is a comparison chart of the end-to-end delay acceleration effect of the embodiments of the present invention under different obstacle density environments compared with the prior art. Detailed Implementation
[0023] To better understand the purpose, structure, and function of this invention, the following detailed description, in conjunction with the accompanying drawings, provides a method and apparatus for accelerating motion planning based on sphere-level speculative scheduling.
[0024] This invention provides a hardware acceleration method for motion planning based on sphere-level speculative scheduling, employing a "Generate-then-Predict" pipeline architecture. For example... Figure 4 As shown, the method specifically includes the following steps: Step 1: Sphere Generation Unlike existing techniques that only calculate link centers, this step is performed before the prediction phase. Using a sphere generation unit, based on the input robot joint angle configuration (Robot Pose) and the robot kinematics model (containing sphere definitions for each link), the world coordinates of all spheres in the robot model are calculated in parallel via forward kinematics. Specifically, each link in the robot model is traversed, and for each sphere within a link, its local coordinates are converted to world coordinates. This generates a list of spheres containing the precise positions of all spheres.
[0025] Step 2: Parallel Prediction & Speculative Dispatching For each sphere generated in step 1, perform hash prediction and classification / assignment in parallel. The specific sub-steps are as follows: Step 2.1: Calculate the spatial hash index: Using a parallel hash prediction engine, read the world coordinates of the sphere. Through bit extraction and concatenation, select specific bits (such as the most significant bit, MSBs) of the sphere's center coordinates to generate a hash index.
[0026] Step 2.2: Query the Collision History Table: Query the Collision History Table (CHT) using the calculated hash index. The CHT returns the historical collision prediction status (Prediction Bit) for this spatial location.
[0027] Step 2.3: Speculative Assignment: Distribute the sphere task to queues of different priorities according to the predicted state: If the predicted state is "1" (indicating potential collision), push the sphere task into the high-priority queue (QCOLL); if the predicted state is "0" (indicating safe), push the sphere task into the low-priority queue (QNONCOLL).
[0028] Step 3: Speculative Execution Collision detection unit arrays (CDUs) are used to process tasks in the queue based on the "early exit" principle.
[0029] Step 3.1: Prioritize high-priority queues: As long as the high-priority queue (QCOLL) is not empty, the scheduler retrieves the sphere task from the queue and sends it to CDUs for precise geometric intersection testing. If a true positive collision is found during the test, it is determined that a collision has occurred in the current robot posture, all subsequent tasks are immediately terminated, and a "collision" result is returned. Simultaneously, the query update unit confirms the state of that position in the CHT as "1".
[0030] Step 3.2: Secondary processing of the low-priority queue: The scheduler processes tasks in the low-priority queue (QNONCOLL) only if the high-priority queue is empty and no premature exit has occurred (i.e., no collision has been detected). This is to prevent "false negatives" (missed detections). If a real collision is detected while processing a low-priority task, it means the previous prediction was incorrect (predicted to be safe but actually resulted in a collision). In this case, the task is immediately terminated, a "collision" result is returned, and the CHT is corrected using the query update unit, updating and flipping the status bit of the corresponding hash index to "1" to achieve self-correction.
[0031] Step 3.3: If no collision is detected after clearing both queues, return a "no collision" result.
[0032] like Figure 5 As shown, this embodiment provides a hardware acceleration device (S-COPU) for implementing the above method. The device mainly includes the following core modules: (1) Sphere Generation Unit (SGU) Positioned at the front end of the pipeline, this unit receives joint configuration data from the robot. It employs a dual-level pipeline design: Forward Kinematics (FK) Engine: As the first-stage pipeline, it employs a deeply pipelined pulsating array structure to calculate the pose matrix of each link in real time. A double-buffering (Ping-Pong Buffer) mechanism is used to mask computational latency.
[0033] Parallel Transformation Engine: As the second-stage pipeline, it contains P=4 parallel computing channels. This engine reads the local geometric parameters stored in the Link Lookup Table (LLUT), combines them with the pose matrix generated by the FK engine, and outputs the world coordinates of the four spheres in parallel in a single cycle.
[0034] Valid Mask Mechanism: For cases where the number of spheres is not aligned, a mask signal is dynamically generated to mark invalid calculation channels (Bubble), and downstream modules can automatically filter invalid data accordingly.
[0035] (2) Parallel Hash Units Connect to the output of the sphere generation unit. To match the high throughput of sphere generation, the engine includes a set of hash calculation units that work in parallel (e.g., P=4).
[0036] Spatial gridded hashing: Each cell performs hardware hashing based on coordinate bit extraction and concatenation. Specific bit segments of the coordinates are extracted using a configurable shift parameter (cfg_shift), mapping a continuous 3D space to discrete grid indices.
[0037] 3D Interleaving uses the low-order bits (LSB) of the grid index to generate the bank selection signal and the high-order bits to generate the row address, enabling conflict-free parallel access to multi-banked CHTs.
[0038] Ratio prediction logic: Read the collision counter (Coll) and safety counter (Non-Coll) in CHT, perform ratio comparison, and generate a binarized prediction result.
[0039] (3) Collision History Table (CHT) An on-chip memory (e.g., 4KB SRAM) is used to store the collision history states of the discretized space. This table is addressed through a spatial hashing mechanism and utilizes the principle of constructed spatial aliasing to compress and store the collision states of a large number of spatial points within a limited storage space.
[0040] (4) Speculative Sphere Dispatcher It connects to the parallel hash prediction engine and collision detection unit. This module employs an asymmetric routing architecture and contains two physical FIFO queues: High-priority queue (QCOLL): Moderately deep (e.g., 64 Entries × 10B), used to cache sphere tasks predicted as "potential collisions". Serializable write logic is used to handle sparse collision risks.
[0041] Low-priority queue (QNONCOLL): Larger in depth (e.g., 1024 Entries × 10B), used to cache sphere tasks predicted as "safe". Employs wide-bus parallel write logic, absorbing up to 4 safe spheres per cycle, ensuring the upstream pipeline does not block.
[0042] The dispatcher is configured with dequeue arbitration logic: strictly prioritizes reading tasks from QCOLL and sending them to the backend; and has a bubble filtering function to automatically remove invalid gaps in QNONCOLL caused by parallel packaging.
[0043] (5) Collision Detection Units (CDUs) Connected to the speculative ball dispatcher, it contains multiple parallel geometry test cores. It receives ball assignments and performs precise ball-obstacle distance calculations or intersection tests.
[0044] (6) Query Update Unit It connects between CDUs and CHT. It is used to receive the actual detection results from CDUs and to write and update the corresponding entries in CHT when the detection results are inconsistent with the prediction results (especially when the prediction is safe but a collision actually occurs).
[0045] like Figure 6 Figure 7 As shown, the present invention has the following advantages compared with the prior art: High accuracy and high recall: Experiments show that the recall rate remains above 89% in complex environments, effectively avoiding the risk of missed reports.
[0046] Computational load is significantly reduced: High-precision filtering greatly reduces the number of costly precision geometry tests (CDQs are reduced by approximately 25%).
[0047] Significant acceleration effect: In high obstacle density scenarios, end-to-end latency is reduced by approximately 15% (1.18x speedup).
[0048] High resource efficiency: Despite the increased number of tracked geometry points, performance improvements are achieved without increasing on-chip memory (maintaining 4KB CHT) by leveraging the “constructive aliasing” property of spatial hashing.
[0049] It is understood that the present invention has been described through some embodiments, and those skilled in the art will recognize that various changes or equivalent substitutions can be made to these features and embodiments without departing from the spirit and scope of the invention. Furthermore, under the teachings of the present invention, these features and embodiments can be modified to adapt to specific situations and materials without departing from the spirit and scope of the invention. Therefore, the present invention is not limited to the specific embodiments disclosed herein, and all embodiments falling within the scope of the claims of this application are within the protection scope of the present invention.
Claims
1. A motion planning hardware acceleration method based on sphere level speculation scheduling, characterized in that, The pipeline architecture employing a "generate first, predict later" approach includes the following steps: Step 1: Sphere generation; Using the sphere generation unit, based on the input robot joint angle configuration and robot kinematics model, the world coordinates of all spheres in the robot model are calculated in parallel through forward kinematics. Step 2: Parallel hash prediction and speculative allocation; For each sphere generated in step 1, perform hash prediction and classification assignment in parallel; Step 3: Speculative execution; Using a collision detection unit array, tasks in the queue are processed based on the "early exit" principle.
2. The sphere-level speculation scheduling based motion planning hardware acceleration method of claim 1, wherein, Step 1 includes: Iterate through each link of the robot model, and for each sphere within a link, convert its local coordinates to world coordinates, thereby generating a list of spheres containing the precise positions of all spheres.
3. The motion planning hardware acceleration method based on sphere-level speculative scheduling according to claim 1, characterized in that, Step 2 includes the following sub-steps: Step 2.1: Calculate the spatial hash index: Using a parallel hash prediction engine, read the world coordinates of the sphere, and generate a hash index by selecting specific bit combinations of the center coordinates of the sphere through bit extraction and concatenation. Step 2.2: Query the collision history table: Use the calculated hash index to query the collision history table CHT. CHT returns the historical collision prediction status for this spatial location. Step 2.3: Speculative Assignment: Distribute the ball task to queues of different priorities according to the predicted state: if the predicted state is "1", it indicates a potential collision, and push the ball task into the high priority queue; if the predicted state is "0", it indicates a safe collision, and push the ball task into the low priority queue.
4. The motion planning hardware acceleration method based on sphere-level speculative scheduling according to claim 3, characterized in that, Step 3 includes the following sub-steps: Step 3.1: Prioritize high-priority queues: As long as the high-priority queue is not empty, the scheduler will take the sphere task from the queue and send it to the collision detection unit array for precise geometric intersection testing. If a real collision is found in the test, it is determined that the current robot posture has collided, all subsequent tasks are immediately terminated and the "collision" result is returned. At the same time, the query update unit is used to confirm the state of the position in CHT as "1". Step 3.2: Secondary processing of low-priority queues: The scheduler only processes tasks in the low-priority queue when the high-priority queue is empty and no premature exit has occurred. If a real collision is detected while processing a low-priority task, the task is immediately terminated and a "collision" result is returned. The query update unit is used to correct the CHT, and the status bit of the corresponding hash index is updated and flipped to "1" to achieve self-correction. Step 3.3: If no collision is detected after clearing both queues, return "no collision" result.
5. A hardware acceleration device for implementing the motion planning hardware acceleration method based on sphere-level speculative scheduling as described in any one of claims 1-4, characterized in that, The device includes the following core modules: Sphere generation unit: Located at the front end of the pipeline, used to receive joint configuration data of the robot; Parallel hash prediction engine: Connected to the output of the sphere generation unit, this engine contains a set of hash calculation units that work in parallel; Collision history table: This is an on-chip memory used to store the collision history state of the discretized space; Speculative Sphere Distributor: Connected to the parallel hash prediction engine and collision detection unit, this module adopts an asymmetric routing architecture and contains two physical FIFO queues; Collision detection unit array: connected to the speculative ball dispatcher, containing multiple parallel geometry test cores for receiving ball tasks and performing accurate ball-obstacle distance calculations or intersection tests; Query Update Unit: Connected between the collision detection unit array and the collision history table, it is used to receive the actual detection results of CDUs and update the corresponding entries in the collision history table when the detection results are inconsistent with the prediction results.
6. The hardware acceleration device according to claim 5, characterized in that, The sphere generation unit adopts a "macro-micro" two-layer pipeline design: Positive kinematics engine: As the first-stage pipeline, it adopts a deeply pipelined pulsating array structure to calculate the pose matrix of each link in real time and uses a double buffering mechanism to mask the calculation delay. Parallel Transformation Engine: As the second-stage pipeline, it contains P=4 parallel computing channels. This engine reads the local geometric parameters stored in the Link lookup table, combines them with the pose matrix generated by the FK engine, and outputs the world coordinates of the four spheres in parallel in a single cycle. Effective masking mechanism: For cases where the number of spheres is not aligned, a mask signal is dynamically generated to mark invalid calculation channels, and downstream modules can automatically filter invalid data accordingly.
7. The hardware acceleration device according to claim 5, characterized in that, The hash calculation unit of the parallel hash prediction engine includes: Spatial gridded hashing: Each cell performs hardware hashing based on coordinate position extraction and splicing, extracting specific segments of coordinates through configurable shift parameters, mapping a continuous 3D space into discrete grid indices; Three-dimensional interleaved storage: The low-order bits of the grid index are used to generate the Bank selection signal and the high-order bits are used to generate the row address, so as to achieve conflict-free parallel access to the multi-bank CHT. Ratio prediction logic: Read the collision counter and safety counter in CHT, perform ratio comparison, and generate a binarized prediction result.
8. The hardware acceleration device according to claim 5, characterized in that, The two physical FIFO queues of the speculative sphere distributor include: High-priority queue: of moderate depth, used to cache sphere tasks predicted as "potential collisions", employing serialized write logic to handle sparse collision risks; Low-priority queue: It has a larger depth and is used to cache sphere tasks that are predicted to be "safe". It adopts wide-bus parallel write logic and absorbs 4 safe spheres per cycle to ensure that the upstream pipeline is not blocked.
9. The hardware acceleration device according to claim 5, characterized in that, The speculative sphere dispatcher is configured with dequeue arbitration logic: strictly prioritizes reading tasks in QCOLL and sending them to the backend; and has a bubble filtering function to automatically remove invalid gaps in low-priority queues caused by parallel packaging.