Search and cooperative control method, device and equipment based on heterogeneous multi-core processor

Abstract

This disclosure presents a method, apparatus, and device for lookup and collaborative control based on heterogeneous multi-core processors. One specific implementation of the method includes: controlling a scalar core cluster to normalize the token corresponding to a token ID to obtain an N-Gram key sequence to be queried; scheduling a vector core cluster to perform hash addressing on the N-Gram key sequence to obtain an address set; performing memory access optimization on the address set to obtain a burst access request set; reading data block data from off-chip memory and writing the data block data to a target tensor core cluster via a direct data injection path; controlling the target tensor core cluster to perform context fusion processing on the data block data to obtain a fusion result; generating a control instruction set based on the fusion result; and driving connected physical execution devices to perform corresponding physical actions according to the generated control instruction set. This implementation provides key technical support for the efficient deployment of large language models in the cloud, edge, and endpoint.

Description

Technical Field

[0001] The embodiments disclosed herein relate to the field of computer technology, and more specifically to a search and collaborative control method, apparatus, and device based on heterogeneous multi-core processors. Background Technology

[0002] With the continuous growth in the scale of large language models, the number of model parameters and computational complexity are increasing exponentially, posing a severe challenge to the computing power and energy efficiency of hardware platforms. To balance model capacity and computational cost, academia and industry have begun to explore sparse design paradigms. Among them, Conditional Memory, as an emerging and efficient solution, directly retrieves static knowledge from massive N-Gram embedding tables through hash lookups with O(1) time complexity, avoiding time-consuming dynamic reconstruction through multi-layer neural networks. In existing technologies, although heterogeneous multi-core processor architectures integrating multiple computing cores such as control cores, scalar cores, vector cores, and tensor cores have emerged, providing a basic hardware platform for handling mixed workloads, their general programming models have not been deeply optimized for the specific and tightly coupled computational pipeline of "lookup-retrieval-fusion". The collaboration efficiency between cores is low, and the data transport path is lengthy.

[0003] However, the above approach often presents the following technical challenges: First, the computation-to-memory ratio of the conditional memory module is extremely low. While hash calculations are relatively simple, they require accessing massive embedding tables far exceeding the on-chip cache capacity, severely limiting performance to memory bandwidth and latency—the so-called "memory wall" problem. Second, the operations are fragmented and of mixed types. Processing a single token involves multiple hash operations, collision handling, multiple scattered memory accesses, and subsequent vector fusion calculations, introducing significant control and scheduling overhead on general-purpose CPUs or GPUs, leading to idle core resources. Finally, there is a tight data dependency between hash lookups and subsequent calculations. Moving data between separate chips or cores results in additional latency and power consumption. The fragmented addresses generated by hash lookups cannot be efficiently aggregated to utilize burst memory transfer characteristics, and the retrieved embedding vectors must pass through a general-purpose cache layer before reaching the computation unit, introducing unnecessary copy latency. Furthermore, how to transform this fusion result generated by heterogeneous multi-core processors into a set of control instructions capable of driving physical execution devices to perform corresponding physical actions also constitutes a key technical obstacle.

[0004] The information disclosed in this background section is only intended to enhance the understanding of the background of the inventive concept, and therefore may contain information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] The summary portion of this disclosure is intended to provide a brief overview of the concepts, which will be described in detail in the detailed description portion. This summary portion is not intended to identify key or essential features of the claimed technical solutions, nor is it intended to limit the scope of the claimed technical solutions.

[0006] Some embodiments of this disclosure provide a search and cooperative control method, apparatus, electronic device, and computer-readable medium based on heterogeneous multi-core processors to solve one or more of the technical problems mentioned in the background section above.

[0007] In a first aspect, some embodiments of this disclosure provide a lookup and cooperative control method based on a heterogeneous multi-core processor, comprising: responding to a received token ID, controlling a scalar core cluster to normalize the token corresponding to the token ID to obtain a query N-Gram key sequence; scheduling a vector core cluster to perform hash addressing on the query N-Gram key sequence to obtain an address set corresponding to off-chip memory; performing memory access optimization on the address set to obtain a burst access request set; based on the burst access request set, reading data block data from the off-chip memory, and writing the read data block data into a target tensor core cluster through a direct data injection path; controlling the target tensor core cluster to perform context fusion processing on the data block data to obtain a fusion result; generating a control instruction set based on the fusion result; and driving a connected physical execution device to perform a corresponding physical action according to the generated control instruction set.

[0008] Secondly, some embodiments of this disclosure provide a lookup and collaborative control device based on a heterogeneous multi-core processor, comprising: a first control unit configured to, in response to a received token ID, control a scalar core cluster to perform normalization processing on the token corresponding to the token ID to obtain a query N-Gram key sequence; a scheduling unit configured to schedule a vector core cluster to perform hash addressing processing on the query N-Gram key sequence to obtain an address set corresponding to off-chip memory; a first processing unit configured to perform memory access optimization processing on the address set to obtain a burst access request set; a second processing unit configured to, based on the burst access request set, read data block data from the off-chip memory and write the read data block data to a target tensor core cluster through a direct data injection path; a second control unit configured to control the target tensor core cluster to perform context fusion processing on the data block data to obtain a fusion result; a generation unit configured to, based on the fusion result, generate a control instruction set; and a driving unit configured to, according to the generated control instruction set, drive a connected physical execution device to perform a corresponding physical action.

[0009] Thirdly, some embodiments of this disclosure provide an electronic device, including: one or more processors; and a storage device having one or more programs stored thereon, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the method described in any implementation of the first aspect above.

[0010] Fourthly, some embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the method described in any of the implementations of the first aspect above.

[0011] Fifthly, some embodiments of this disclosure provide a computer program product, including a computer program that, when executed by a processor, implements the method described in any of the implementations of the first aspect above.

[0012] The above embodiments of the present invention have the following beneficial effects: Through the search and cooperative control method based on heterogeneous multi-core processors in some embodiments of the present invention, low-latency, high-throughput search and fusion computation of massive N-Gram embedded tables in the conditional memory module can be achieved, significantly improving the cooperative efficiency and energy efficiency ratio of heterogeneous multi-core processors in the "search, retrieval, and fusion" pipeline. Specifically, although conditional memory operations (such as the Engram module) in traditional large language models can avoid dynamic reconstruction of neural networks through hash lookup, they may face the following technical problems when executed on actual hardware: memory wall problem caused by extremely low computation-to-memory ratio, control and scheduling overhead introduced by fine-grained operations, and transport delay caused by tight data dependency between hash lookup and subsequent computation; if only a general programming model based on general-purpose CPUs or GPUs or existing heterogeneous multi-core architectures is relied upon, insufficient memory bandwidth utilization, idle core resources, and lengthy data copy paths may occur, ultimately leading to high overall processing latency and low throughput. Based on this, some embodiments of the present invention employ a lookup and collaborative control method based on heterogeneous multi-core processors. First, in response to the received token ID, the scalar core cluster is controlled to normalize the token corresponding to the token ID, obtaining the N-Gram key sequence to be queried. Thus, utilizing the scalar cores' strengths in scalar operations and table lookup, the original token is transformed into a structured lookup key sequence, laying the foundation for subsequent parallel hash lookups. Simultaneously, the simplest operations are offloaded to the most suitable core, avoiding the consumption of complex computing resources. Then, the vector core cluster is scheduled to perform hash addressing on the N-Gram key sequence to be queried, obtaining the address set of the corresponding off-chip memory. This fully leverages the SIMD parallel computing capabilities of the vector cores, performing parallel computation on multiple N-Gram items and multiple hash functions, and quickly handling conflicts through on-chip lightweight conflict resolution lookup tables, significantly improving address generation efficiency and centrally accelerating fine-grained hash operations, reducing subsequent memory access pressure. Next, memory access optimization processing is performed on the above address set to obtain a set of bursty access requests. Therefore, through hardware-level optimizations such as sorting, merging, and cross-page detection, fragmented discrete address aggregation is used to efficiently burst requests, maximizing off-chip memory bandwidth utilization and alleviating the memory wall problem at its root. Subsequently, based on the aforementioned burst access request set, data blocks are read from the aforementioned off-chip memory, and the read data blocks are written to the target tensor kernel cluster via a direct data injection path. Thus, on the one hand, optimized burst requests are used to efficiently acquire data, and on the other hand, data is directly injected into the tensor kernel input buffer through a dedicated physical independent side link, completely bypassing the general cache hierarchy and register file, eliminating redundant data copying and transport delays, and achieving "computation as soon as data is available". Then, the aforementioned target tensor kernel cluster is controlled to perform context fusion processing on the aforementioned data blocks to obtain the fusion result.This allows the tensor kernel to focus on high-density vector and matrix operations, fusing statically embedded vectors with the dynamic state of the upstream context to perform operations such as context-aware gating and convolution, outputting high-quality semantic fusion results. Next, based on the fusion results, a set of control instructions is generated. This transforms the abstract semantic representation into concrete digital control parameters, providing information for subsequent physical execution. Finally, based on the generated set of control instructions, the connected physical execution devices are driven to perform corresponding physical actions. This translates the output of intelligent computing into concrete operations in the physical world, achieving end-to-end closed-loop control from token input to physical actions. Furthermore, because this method designs a hierarchical pipelined hash engine, a direct data injection path, and a collaborative compilation runtime system at the hardware level, it can be deeply customized for conditional memory operation modes, enabling scalar, vector, and tensor kernels to efficiently parallelize on their respective strengths, with tightly connected pipelines, fundamentally overcoming the collaboration overhead and data transport bottlenecks of general-purpose architectures. Simultaneously, through hardware-level address aggregation and direct injection, memory bandwidth utilization is significantly improved, and processing latency is significantly reduced. Thus, by performing fine-grained mapping and optimization of the conditional memory computation process on heterogeneous multi-core processors through hardware and software collaboration, the overall processing latency, system throughput, and energy efficiency of large-scale N-Gram hash lookup and fusion computation have been improved to a certain extent, providing key technical support for the efficient deployment of large language models in the cloud, edge, and terminal. Attached Figure Description

[0013] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and elements are not necessarily drawn to scale.

[0014] Figure 1 This is a flowchart of some embodiments of the search and cooperative control method based on heterogeneous multi-core processors according to the present disclosure; Figure 2 This is a schematic diagram of the structure of some embodiments of the search and cooperative control device based on heterogeneous multi-core processors according to the present disclosure; Figure 3 This is a schematic diagram of the structure of an electronic device suitable for implementing some embodiments of the present disclosure. Detailed Implementation

[0015] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0016] It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings. Unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0017] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0018] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0019] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0020] This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0021] Figure 1 A flow 100 of some embodiments of the heterogeneous multi-core processor-based search and cooperative control method according to this disclosure is shown. The heterogeneous multi-core processor-based search and cooperative control method includes the following steps: Step 101: In response to the received token ID, control the scalar core cluster to normalize the token corresponding to the token ID to obtain the N-Gram key sequence to be queried.

[0022] In some embodiments, the execution entity of the heterogeneous multi-core processor-based lookup and cooperative control method (e.g., a heterogeneous multi-core processor chip or a computing device containing such a chip) can, in response to a received token ID, control a scalar core cluster to perform normalization processing on the token corresponding to the token ID, thereby obtaining the N-Gram key sequence to be queried. Here, a scalar core cluster refers to a computing unit integrated on a heterogeneous multi-core processor chip, consisting of multiple scalar processing cores. Each scalar core is configured with a private L1 cache for performing tasks such as scalar operations, table lookup operations, and sequence generation.

[0023] In some optional implementations of certain embodiments, the aforementioned execution entity may, in response to the received token ID, control the scalar core cluster to perform normalization processing on the token corresponding to the token ID to obtain the N-Gram key sequence to be queried: Step one involves performing vocabulary projection processing on the aforementioned token ID to obtain the corresponding vocabulary index. Vocabulary projection processing refers to the process of mapping the input token ID to the index number of the corresponding lexical unit in the model vocabulary, typically achieved through a lookup table operation. The vocabulary index is a unique identifier of a lexical unit within the vocabulary, used for subsequent embedding vector lookup and text representation. In practice, the aforementioned execution entity can control the scalar kernel to read the vocabulary mapping table stored in its private L1 cache, using the received 32-bit token ID as the lookup key to retrieve the corresponding vocabulary index from the mapping table. For example, assuming the received token ID is "1024", and the vocabulary mapping table records the lexical unit corresponding to ID "1024" as "love", then the vocabulary projection processing yields the vocabulary index "2048" for that lexical unit.

[0024] Step two: Based on the aforementioned vocabulary index, the token ID is subjected to character-level normalization to obtain a normalized token. Character-level normalization refers to the standardization of the text characters represented by the token, including but not limited to case conversion, Unicode normalization, whitespace merging, and stemming, to ensure that the same text in different forms is processed uniformly. The normalized token is a text representation with a unified format obtained after the above standardization process. In practice, the aforementioned execution entity can control the arithmetic logic unit (ALU) of the scalar kernel to retrieve the corresponding original text string based on the vocabulary index, and then sequentially perform case conversion (e.g., unifying English characters to lowercase) and Unicode normalization (e.g., converting é to e). The normalized token is generated by performing at least one of the following operations: combining different forms of characters, merging whitespace (e.g., removing leading and trailing spaces and merging consecutive spaces), and stemming (e.g., restoring "running" to "run"). For example, after character-level normalization, the token "Running" may be uniformly converted to lowercase and its stem restored to obtain the normalized token "run".

[0025] Step 3 involves concatenating suffix sequences of the normalized token and its preceding tokens within a preset window to obtain the N-Gram key sequence to be queried. The preset window refers to the context range centered on the current token and tracing back a certain number of tokens, typically measured in tokens. Suffix sequence concatenation involves combining the current normalized token with its preceding tokens within the window in chronological order to form a fixed-length N-Gram item. The N-Gram key sequence is a set of N-Gram items of different orders (e.g., 2-gram, 3-gram, 4-gram), each encoded as a 64-bit key for subsequent hash lookups. In practice, the execution entity can control the scalar kernel to combine the current normalized token and its preceding tokens within the window according to a preset order N (e.g., N=2, 3, 4), generating all possible suffix N-Gram sequences, and encoding each N-Gram sequence as a 64-bit key, forming an ordered key sequence output to the vector kernel cluster. For example, assuming the preset window size is 3, the current normalized token is "love", and its preceding tokens are "i" and "really", the generated N-Gram key sequence may include: the 64-bit key value corresponding to the 2-gram term "really love", the 64-bit key value corresponding to the 3-gram term "i really love", etc.

[0026] Step 102: The scheduling vector kernel cluster performs hash addressing on the N-Gram key sequence to be queried to obtain the address set of the corresponding off-chip memory.

[0027] In some embodiments, the aforementioned execution entity can schedule a vector core cluster to perform hash addressing processing on the N-Gram key sequence to be queried, thereby obtaining the address set of the corresponding off-chip memory. Here, a vector core cluster refers to a computing unit integrated on a heterogeneous multi-core processor chip, consisting of multiple vector processing cores. Each vector core has a built-in SIMD (Single Instruction Multiple Data) unit and a hash acceleration unit, used to perform vectorized operations such as parallel hash calculation and conflict resolution. Hash addressing processing refers to the process of mapping N-Gram keys to the physical addresses of the corresponding embedded vectors stored in off-chip memory using hash functions, typically involving parallel calculation of multiple hash functions and conflict resolution. Off-chip memory refers to storage devices located outside the heterogeneous multi-core processor chip, such as HBM (High Bandwidth Memory) or DRAM, used to store large-scale N-Gram embedding tables. The address set is a collection of multiple physical addresses, each pointing to a specific storage location in off-chip memory for subsequent data retrieval.

[0028] In some optional implementations of certain embodiments, the execution entity may schedule the vector kernel cluster to perform hash addressing on the N-Gram key sequence to be queried through the following steps to obtain the address set of the corresponding off-chip memory: Step 1: Apply various hash functions in parallel to each N-Gram item in the N-Gram key sequence to generate hash values, obtaining a set of candidate hash values ​​for each N-Gram item. Here, an N-Gram item refers to a sequence unit consisting of N consecutive tokens, and each N-Gram item has been encoded as a 64-bit key value in step 101. A hash function is a mathematical algorithm that maps input data to a fixed-length hash value. In this embodiment, multiple lightweight hash functions (such as multiply-add-XOR fusion hash) are used to achieve fast computation. Hash value generation refers to the operation of calculating the hash value corresponding to the input data using a hash function. The set of candidate hash values ​​refers to the set of multiple hash values ​​obtained by applying multiple different hash functions to the same N-Gram item. In practice, the aforementioned execution entity can control the SIMD unit of the vector kernel to load multiple N-Gram items in parallel, and apply K different hash functions (e.g., K=3) to each N-Gram item simultaneously within one clock cycle through the hash acceleration unit, obtaining K candidate hash values ​​corresponding to each N-Gram item, thus forming a set of candidate hash values ​​for each N-Gram item. For example, for a certain N-Gram item "love", applying three hash functions may yield hash values ​​{0x3A2F, 0x8C1D, 0x5B7E}, which constitute the set of candidate hash values ​​corresponding to that N-Gram item.

[0029] Step two: Based on the aforementioned candidate hash value sets, generate a candidate hash value set for hash collisions. A hash collision refers to the situation where different N-Gram items are mapped to the same storage slot after hash function calculation. The candidate hash value set for hash collisions is the set of candidate hash values ​​selected from the various candidate hash value sets that collide with other N-Gram items or existing storage entries. In practice, the execution entity can control the vector core to query a locally maintained collision detection table or identify which candidate hash values ​​will cause collisions by comparing the slot occupancy status of each candidate hash value, and collect these conflicting hash values ​​to form the candidate hash value set for hash collisions. For example, assuming that the slot corresponding to the candidate hash value 0x3A2F of an N-Gram item is already occupied by another item, this hash value is determined to be a collision value and added to the candidate hash value set for hash collisions.

[0030] Step 3: Obtain the set of address correction records corresponding to the candidate hash value set that has caused a hash collision. Address correction records refer to address adjustment information used to resolve hash collisions, typically including the corrected address or offset corresponding to the conflicting hash value. The set of address correction records is a collection of multiple address correction records, which can be obtained from the on-chip lightweight collision resolution lookup table. In practice, the execution entity can control the vector core to query its locally integrated on-chip lightweight collision resolution lookup table. This lookup table uses a TCAM (Tri-State Content Addressing Memory) structure and stores the address correction records for high-frequency collision items. For each collision value in the candidate hash value set, the vector core uses that hash value as a key to perform parallel matching in the lookup table. If a match is found, the corresponding corrected address is read, thus obtaining the corresponding address correction record, which is ultimately aggregated to form the address correction record set. For example, if the collision value 0x3A2F matches a record in the lookup table indicating its corrected address is 0xC000, then that record is obtained.

[0031] Step four: Based on the aforementioned address correction record set, perform address correction processing on the candidate hash value set that has experienced hash collisions to obtain the corresponding off-chip memory address set. Address correction processing refers to the operation of replacing the conflicting hash value with the corrected physical address according to the address correction record. In practice, the executing entity can control the vector kernel to replace each conflicting value in the candidate hash value set with the corrected address obtained in step three; for candidate hash values ​​that have not experienced collisions, they are directly retained as valid addresses. After correction processing, the valid physical addresses corresponding to all N-Gram entries are aggregated to form an address set pointing to off-chip memory. Each address entry typically contains a 64-bit physical address and related metadata (such as a burst length flag). For example, of the three candidate hash values ​​of an N-Gram entry, two non-conflicting values ​​(0x8C1D, 0x5B7E) are directly used as addresses, and a conflicting value 0x3A2F is corrected to 0xC000. Finally, the address set corresponding to this N-Gram entry contains {0x8C1D, 0x5B7E, 0xC000}.

[0032] Step 103: Perform memory access optimization on the address set to obtain a set of burst access requests.

[0033] In some embodiments, the execution entity can perform memory access optimization on the address set to obtain a burst access request set. Memory access optimization refers to a series of operations, such as sorting, merging, and boundary detection, on the discrete physical addresses obtained through hash addressing to generate efficient burst read requests that conform to the memory controller specification. The burst access request set is a collection of multiple burst access requests, each containing fields such as a starting address and burst length, used to continuously read data blocks from off-chip memory.

[0034] In some optional implementations of certain embodiments, the aforementioned execution entity can perform memory access optimization processing on the aforementioned address set through the following steps to obtain a burst access request set: Step one involves sorting the physical addresses in the address set to obtain an ordered address sequence. Sorting refers to arranging the discrete addresses in ascending or descending order according to their numerical values, aiming to organize randomly distributed addresses into an ordered sequence, laying the foundation for subsequent continuous address identification. An ordered address sequence is a list of physical addresses arranged in ascending order after sorting. In practice, the execution entity can store all physical addresses in the address set obtained in step 102 into the address sorting buffer of the address aggregation unit. A hardware-accelerated sorting algorithm, such as bitonic sorting or parity merge sort, is then executed using a parallel address comparator array (e.g., 64 comparators) to complete the sorting within several clock cycles, resulting in an ordered address sequence. For example, assuming the original address set is {0x1040, 0x1000, 0x1080, 0x10C0}, after sorting, the ordered address sequence {0x1000, 0x1040, 0x1080, 0x10C0} is obtained.

[0035] Step two involves merging the ordered address sequence to obtain a merged set of contiguous address blocks. Merging refers to combining multiple consecutive entries in the ordered address sequence into a single contiguous address block. A contiguous address block is an address range consisting of a set of physical addresses that are consecutive and spaced at intervals equal to a preset cache line size (e.g., 64 bytes). The merged set of contiguous address blocks is a collection of multiple such contiguous address blocks. In practice, the execution entity can traverse the ordered address sequence using a burst merging logic unit, checking if the difference between adjacent addresses equals the cache line size (e.g., 64 bytes). If they are equal, they are grouped into the same contiguous address block, and the block length is accumulated. When a non-contiguous address is encountered, the current block ends and a new block begins. For example, for the ordered address sequence {0x1000, 0x1040, 0x1080, 0x10C0}, the difference between adjacent addresses is 64 bytes, therefore they are merged into a single contiguous address block, starting at address 0x1000, with a contiguous length of 4, forming one of the merged contiguous address blocks in the merged set.

[0036] Step 3: Perform page cross-page detection processing on each of the merged contiguous address blocks in the above-mentioned merged contiguous address block set to obtain each intra-page address sub-block. Page cross-page detection processing refers to the operation of checking whether a contiguous address block crosses a memory page boundary. Its purpose is to divide the cross-page block into multiple intra-page address sub-blocks to meet the intra-page burst transfer requirements of the memory controller. An intra-page address sub-block is an address sub-block that is completely located within a single memory page after the contiguous address block has been divided by the page boundary. In practice, the above-mentioned execution entity can use a page boundary detection circuit to perform boundary calculations on each merged contiguous address block based on the page size of the off-chip memory (e.g., 4KB or 2MB): calculate the remaining space of the page containing the starting address of the block; if the continuous length of the block exceeds the number of cache lines that the remaining space of the page can accommodate, then divide it at the page boundary to obtain multiple intra-page address sub-blocks, each with its own starting address and continuous length. For example, assuming a page size of 4KB (4096 bytes) and a cache line size of 64 bytes, a merged contiguous block starts at address 0x1FC0 and has a length of 16. The offset within the page from address 0x1FC0 is 0xFC0 (4032 bytes). The remaining space in the page is 4096-4032=64 bytes, which can only hold one cache line. Therefore, the merged contiguous block is divided into two sub-blocks: the first sub-block starts at address 0x1FC0 with a length of 1 (corresponding to the remaining space within the page), and the second sub-block starts at address 0x2000 (the start of the next page) with a length of 15.

[0037] Step four: Based on the starting address and continuous length of each of the above-mentioned intra-page address sub-blocks, generate the corresponding burst access request set. A burst access request is a command unit conforming to the memory controller interface specification, used to continuously read multiple cache lines from off-chip memory. It typically includes fields such as starting address, burst length, and request type. In practice, the execution entity uses the starting address of each intra-page address sub-block as the starting address of the burst access request, its continuous length as the burst length of the burst access request, and sets the request type to read. It can also attach metadata such as priority and target tensor kernel ID to generate the corresponding burst access request. All burst access requests generated from the intra-page address sub-blocks constitute the burst access request set, which will be submitted to the memory controller for actual data reading. For example, for the two intra-page address sub-blocks obtained in step three, burst access requests are generated respectively: burst access request A (starting address 0x1FC0, burst length 1) and burst access request B (starting address 0x2000, burst length 15).

[0038] Step 104: Based on the burst access request set, read data block data from off-chip memory and write the read data block data into the target tensor kernel cluster through the direct data injection path.

[0039] In some embodiments, the execution entity can read data block data from the off-chip memory based on the burst access request set, and write the read data block data into the target tensor core cluster through a direct data injection path. The burst access request set is a collection of multiple burst access requests generated in step 103. Each burst access request includes a starting address and a burst length, used to continuously read data blocks from the off-chip memory. Off-chip memory refers to storage devices located outside the heterogeneous multi-core processor chip, such as HBM (High Bandwidth Memory) or DRAM, used to store large-scale N-Gram embedding tables. Data block data refers to continuous data content read from the off-chip memory containing multiple N-Gram embedding vectors, typically organized in cache lines, each cache line being 64 bytes in size and containing two 256-bit embedding vectors. The target tensor core cluster refers to a computing unit integrated on the heterogeneous multi-core processor chip, consisting of multiple tensor processing cores. Each tensor core is configured with a dedicated input buffer (e.g., 64KB, divided into multiple banks) for performing vector and matrix fusion calculations. The direct data injection path is a physically independent dedicated hardware side link connecting the memory controller or shared last-level cache to a dedicated input buffer of the target tensor kernel cluster. It directly writes data blocks into the tensor kernel, completely bypassing the general cache hierarchy and register file. This path typically includes a direct memory access engine, a dedicated parallel bus, and a hardware handshake signal mechanism. The direct memory access engine is the hardware unit responsible for actively fetching data and controlling transmission. The dedicated parallel bus is a physical data channel independent of the on-chip network (e.g., 1024-bit wide, 2GHz operating frequency). The hardware handshake signal mechanism includes data ready signals and buffer full signals, used to implement asynchronous flow control. In practice, the aforementioned execution entity can initiate burst read operations to off-chip memory based on a burst set of access requests through the memory controller. The memory controller is a hardware module integrated on a heterogeneous multi-core processor chip, responsible for managing off-chip memory access. It receives burst access requests and translates them into commands conforming to memory protocols (such as the HBM protocol). The shared last-level cache (LLC) is the last level of on-chip cache used to temporarily store data read from off-chip memory, reducing repeated accesses to off-chip memory. Specifically, the memory controller reads the corresponding consecutive cache lines of data from off-chip memory (e.g., HBM) based on the starting address and burst length in the burst access request; these data constitute the data block data. After reading, the data block data is first temporarily stored in the shared last-level cache. Subsequently, the direct memory access engine in the direct data injection path detects that the data is ready and is triggered via a dedicated interrupt line or polling mechanism. It actively retrieves the data block data from the shared last-level cache and transmits the data block data directly to the dedicated input buffer of the target tensor kernel in burst write mode via a dedicated parallel bus.Throughout the write process, hardware handshake signals (such as the idle status feedback from the buffer status register) ensure that the transfer rate matches the buffer capacity, eliminating the need for software intervention in the tensor kernel and thus achieving zero-wait pipelined computation as soon as data is available. For example, suppose a burst access request set contains a single burst access request: starting address 0x2000, burst length 16. The memory controller reads 16 consecutive 64-byte cache lines from the HBM, totaling 1024 bytes of data, containing 16 N-Gram embedding vectors (32 bytes each). This data block is written to the dedicated input buffer of a target tensor kernel in the tensor kernel cluster via a direct data injection path for subsequent fusion computation.

[0040] Step 105: Control the target tensor kernel cluster to perform context fusion processing on the data block data to obtain the fusion result.

[0041] In some embodiments, the execution entity can control the target tensor kernel cluster to perform context fusion processing on the data block data to obtain a fusion result. The target tensor kernel cluster refers to a computing unit integrated on a heterogeneous multi-core processor chip, consisting of multiple tensor processing cores. Each tensor kernel is configured with a dedicated input buffer and a computation buffer for performing high-density vector and matrix fusion calculations. The data block data refers to continuous data content containing multiple N-Gram embedding vectors, written to the dedicated input buffer of the target tensor kernel through a direct data injection path. Context fusion processing refers to the process of jointly calculating the static N-Gram embedding vectors and the dynamic context hidden state vectors, generating a fused semantic representation through operations such as gating, weighting, and convolution. The fusion result is the final vector representation output by the context fusion processing, typically a 256-bit dense vector, used for subsequent control instruction generation.

[0042] In some optional implementations of certain embodiments, the aforementioned execution entity can control the aforementioned target tensor kernel cluster to perform context fusion processing on the aforementioned data block data through the following steps to obtain the fusion result: Step 1: Obtain the context hidden state vector via the on-chip network. The on-chip network refers to a communication network integrated on a heterogeneous multi-core processor chip, connecting various computing cores and storage resources, used for transmitting data and instructions between cores. The context hidden state vector is a dynamic semantic representation output from upstream of the model (such as the layer above the Transformer), containing rich information about the current processing context. In practice, the aforementioned execution entity can control the target tensor kernel to receive the pre-transmitted context hidden state vector from upstream computing units (such as the previous layer tensor kernel or control core) via its dedicated context channel through the on-chip network, and store it in a dedicated context register or buffer within the tensor kernel. For example, suppose the upstream of the model outputs a 256-bit vector [0.12, 0.34, ..., 0.78], which is transmitted to the target tensor kernel via the on-chip network as the context hidden state vector.

[0043] Step two involves loading the N-Gram embedding vectors contained in the data block from the dedicated input buffer of the target tensor kernel. Loading refers to the operation of reading data from storage media into the computation unit. N-Gram embedding vectors are pre-trained static vector representations corresponding to N-Gram sequences. Each embedding vector is typically a 256-bit floating-point number, stored in a large-scale embedding table in off-chip memory, and written to the dedicated input buffer via a direct data injection path. In practice, the execution entity can control the loading storage unit of the target tensor kernel to detect the data readiness flag in the dedicated input buffer. Once the data is ready, it sequentially reads each N-Gram embedding vector from the dedicated input buffer and loads it into the tensor kernel's internal registers or operation queue, ready for subsequent computation. For example, if the dedicated input buffer stores 16 N-Gram embedding vectors, the loading unit reads them all into the vector register file inside the tensor kernel.

[0044] Step 3 involves key projection processing on each of the aforementioned N-Gram embedding vectors to obtain the corresponding key vector set. Key projection processing refers to the operation of mapping the input embedding vectors to key vectors through a linear transformation matrix. This is one of the core steps in the attention mechanism, aiming to transform the original embeddings to a representation space used to compute attention weights. The key vector set is a collection of multiple key vectors, each corresponding to an input N-Gram embedding vector. In practice, the execution entity can control the multiply-accumulate array of the target tensor kernel, performing matrix multiplication operations between each N-Gram embedding vector and the pre-loaded key projection matrix to obtain the corresponding key vector. For example, assuming the embedding vector dimension is 256 and the key projection matrix size is 256×256, after matrix multiplication, each embedding vector generates a 256-dimensional key vector, and all key vectors constitute the key vector set.

[0045] Step four involves value projection processing on each of the aforementioned N-Gram embedding vectors to obtain the corresponding set of value vectors. Value projection, which maps the input embedding vectors to value vectors using a linear transformation matrix, is another core step in the attention mechanism, aiming to transform the original embeddings into a representation space used for weighted output. The set of value vectors consists of multiple value vectors, each corresponding to an input N-Gram embedding vector. In practice, the execution entity can control the multiply-accumulate array of the target tensor kernel, performing matrix multiplication operations between each N-Gram embedding vector and a pre-loaded value projection matrix to obtain the corresponding value vector. For example, multiplying an embedding vector by a 256×256 value projection matrix generates a 256-dimensional value vector, and all value vectors constitute the set of value vectors.

[0046] Step 5: Perform attention score generation processing on the aforementioned context hidden state vector and each key vector in the aforementioned key vector set to obtain the corresponding gating score set. The attention score generation processing refers to the operation of calculating the similarity or correlation between the context hidden state vector and each key vector to generate attention scores for weighted fusion. The gating score set is a set of multiple scalar scores, each representing the relevance between the context and the corresponding key vector. In practice, the aforementioned execution entity can control the multiply-accumulate array of the target tensor kernel, performing a dot product operation between the context hidden state vector and each key vector in the key vector set to obtain the corresponding dot product value; then, an activation function (such as sigmoid or softmax) is used to map the dot product value to a gating score between 0 and 1. For example, if the context hidden state vector is H and the key vector set is {K1, K2, ..., Kn}, calculate H·K1, H·K2, ... respectively, obtain the dot product value, and then process it with the sigmoid function to obtain the gating score set {g1, g2, ..., gn}.

[0047] Step Six: Based on the aforementioned set of gated scores, perform a weighted combination process on each value vector in the aforementioned set of value vectors to obtain a fused vector. The weighted combination process refers to using the gated scores as weights to perform a weighted summation of each value vector, aiming to dynamically fuse static knowledge based on contextual relevance. The fused vector is a single vector obtained after the weighted combination, fusing information from all value vectors and modulating it according to relevance. In practice, the aforementioned execution entity can control the multiply-accumulate array of the target tensor kernel, multiplying each score in the set of gated scores with its corresponding value vector, and then summing all the product results to obtain the fused vector. For example, given the set of gated scores {g1, g2, ..., gn} and the set of value vectors {V1, V2, ..., Vn}, the fused vector = g1×V1 + g2×V2 + ... + gn×Vn.

[0048] Step seven involves performing convolution on the fused vector to obtain the convolutional vector. Convolution refers to applying a one-dimensional depthwise convolution operation to the vector to capture local features and enhance representational power. Depthwise convolution means the convolution kernel slides only along a single dimension of the input channel, with each input channel convolved independently, and the number of output channels being the same as the number of input channels. The convolutional vector is the enhanced vector obtained after convolution. In practice, the execution entity can control the depthwise convolution unit of the target tensor kernel, taking the fused vector as input and performing a depthwise convolution operation with a preset lightweight convolution kernel (e.g., a kernel size of 3), outputting a convolutional vector with the same dimension as the input. For example, if the fused vector is 256-dimensional, after depthwise convolution with a kernel size of 3, a 256-dimensional convolutional vector is obtained.

[0049] Step eight involves performing residual connection processing on the convolutional vector to obtain the fusion result. Residual connection processing involves adding the convolutional vector to the original input (i.e., the initial fusion vector or an earlier input), aiming to alleviate the vanishing gradient problem and facilitate deep network training. The fusion result is the semantic representation of the final output, used for subsequent control instruction generation. In practice, the execution entity can control the tensor kernel's addition unit to add the convolutional vector obtained in step seven to the fusion vector obtained in step six (or to an intermediate result) element-wise to obtain the fusion result. For example, if the convolutional vector is C and the fusion vector is F, the fusion result = C + F. This fusion result is then written back to the shared final buffer for use in the next layer's computation or control instruction generation.

[0050] Step 106: Based on the fusion results, generate a set of control commands.

[0051] In some embodiments, the execution entity can generate a control instruction set based on the fusion result. The fusion result refers to the result generated in step 105, typically a 256-bit dense vector containing semantic information extracted from the input token and context. The control instruction set is a collection of multiple control instruction messages, each conforming to a specific communication protocol (such as CAN bus protocol, PWM signal format, or analog voltage standard) to drive the physical execution device to perform corresponding physical actions.

[0052] In some optional implementations of certain embodiments, the aforementioned execution entity may generate a set of control instructions based on the aforementioned fusion result through the following steps: Step one involves parsing the fusion result to extract various control parameter fields. Parameter parsing refers to mapping specific bits or numerical ranges in the fusion result to physically meaningful control parameters. Control parameter fields are numerical values ​​with clear physical meanings obtained after parsing, such as angle, speed, torque, and switching quantity. In practice, the execution entity extracts each control parameter field from a specified position in the fusion result according to a preset field mapping table. For example, assuming the fusion result is 256 bits of data, with the first 32 bits preset as the steering angle field, the middle 32 bits as the braking pressure field, and the last 32 bits as the acceleration field, the execution entity extracts the steering angle parameter of 30 degrees from bits 0-31, the braking pressure parameter of 5 MPa from bits 32-63, and the acceleration parameter of 2 m / s² from bits 224-255.

[0053] Step two involves format conversion processing of each control parameter field to obtain the corresponding control signals for each actuator. Format conversion refers to the process of converting digitized control parameters into the electrical signal form required by the actuator, such as converting a digital angle value into the duty cycle of a PWM wave, or a digital torque value into an analog voltage value. The control signal is an electrical signal generated after format conversion that can be directly used to drive the actuator, such as a PWM pulse, analog voltage, digital level, or CAN message data field content. In practice, the aforementioned actuator calls the corresponding conversion function or hardware conversion unit according to the type of the target physical actuator to convert the control parameter fields into the corresponding control signals. For example, for a steering servo motor, a digital angle value of 30 degrees is converted into a PWM signal with a 50% duty cycle; for a brake pump, a digital pressure value of 5MPa is converted into a 10V analog voltage signal; for acceleration control, a digital acceleration value of 2m / s² is converted into the corresponding digital control word 0x7F.

[0054] Step 3 involves protocol encapsulation processing of each control signal to generate a corresponding set of control commands. Protocol encapsulation refers to the process of assembling control signals into data frames or messages conforming to a specific communication protocol (such as CAN 2.0B, Modbus, I²C, etc.). The control command message is a complete encapsulated command unit, containing a protocol header, data field, and checksum field, and can be sent to the execution device via a physical interface. In practice, the execution entity fills the control signals into the corresponding protocol data frame according to the communication protocol supported by the target execution device, and adds the necessary protocol header, address field, and checksum field to generate a complete control command message. For example, for a steering servo motor, a 50% PWM duty cycle is encapsulated as a CAN message, with message ID set to 0x123, and the data field containing the duty cycle value 0x80; for a brake pump, a 10V analog voltage value is encapsulated as a CAN message, with message ID set to 0x124, and the data field containing the voltage value 0xFF; the final generated control command set contains these two CAN messages.

[0055] In addressing the problem of efficient lookup and fusion calculation of the conditional memory module in the aforementioned background technology using the search and cooperative control method based on heterogeneous multi-core processors, the following technical issues often arise in the actual operation environment of multi-axis robotic arms with high frequency, high precision, and variable load, such as industrial automation, precision assembly, and material handling: When the control commands generated by the upper-level intelligent computing are sent to the multi-axis robotic arm, traditional servo control schemes often use a single position closed loop or a simple speed loop control. Under complex working conditions such as sudden load changes, high-speed start-stop, and multi-axis cooperation, dynamic response lag is likely to occur. Issues such as overshoot, position overshoot, and accumulated trajectory tracking errors exist. Simply relying on feedback control cannot compensate for load torque disturbances in advance, leading to decreased motion accuracy under varying load conditions. In multi-joint coordinated motion, the control of each axis is isolated, lacking joint optimization of multiple target parameters such as angle, speed, and torque, making it difficult to achieve high-precision spatial trajectory tracking of the end effector. Furthermore, the link from control command parsing to the application of three-phase drive voltage is lengthy, lacking end-to-end hardware-level optimization from message parsing, parameter extraction, multi-loop control, feedforward compensation to power amplification, failing to meet the stringent requirements of millisecond-level real-time response for high-speed, high-precision operations. Considering the following requirements for this application scenario: dynamic response speed and trajectory tracking accuracy under high-frequency operations, disturbance rejection capability and operational stability under varying load conditions, synchronization and consistency during multi-axis coordinated motion, and control reliability and robustness under long-term continuous operation, we have decided to adopt the following solution: Step 107: Based on the generated set of control instructions, drive the connected physical actuators to perform the corresponding physical actions.

[0056] In some embodiments, the aforementioned execution entity can drive connected physical execution devices to perform corresponding physical actions based on the generated set of control instructions. The connected physical execution devices include the servo motors of each joint of a multi-axis robotic arm. A multi-axis robotic arm is a robotic arm system composed of multiple rotary or translational joints, capable of complex movements in space, and is typically used in industrial automation, precision assembly, and other similar applications. A joint servo motor is a servo motor in a multi-axis robotic arm used to drive the movement of each joint. Each joint servo motor is typically equipped with an independent driver and encoder for precise position, speed, and torque control. The set of control instructions is a collection of multiple control instruction messages generated in step 106, each containing control parameters for a specific joint servo motor.

[0057] In some optional implementations of certain embodiments, the aforementioned execution entity can drive the connected physical execution device to perform corresponding physical actions according to the generated set of control instructions through the following steps: The first step is to parse the joint control messages corresponding to each joint servo motor from the aforementioned control command set. These joint control messages encapsulate control parameters (such as target angle, angular velocity, and torque) for a specific joint servo motor and typically conform to industrial communication protocols such as CAN bus. In practice, the executing entity can filter the control messages belonging to each joint servo motor from the control command set based on preset message identifiers (IDs) or address fields. For example, assuming the control command set contains a message with ID=0x101 corresponding to joint 1 and ID=0x102 corresponding to joint 2, the executing entity distributes the messages to the corresponding joint servo motor control channels by matching the IDs.

[0058] The second step involves protocol parsing of each joint control message to obtain a set of target parameters for each joint servo motor. Each target parameter set includes target angle parameters, target angular velocity parameters, and target torque parameters. Protocol parsing refers to the process of extracting data fields from the message and restoring them to the original control parameters according to the format definition of the communication protocol (e.g., CAN 2.0B). The target parameter set is a collection of multiple target parameters, including target angle parameters, target angular velocity parameters, and target torque parameters. The target angle parameter refers to the desired angle value to which the joint servo motor will rotate, usually in degrees or radians. The target angular velocity parameter refers to the desired rotational speed of the joint servo motor, usually in degrees per second or radians per second. The target torque parameter refers to the desired output torque value of the joint servo motor, usually in Newton-meters. In practice, the executing entity parses each joint control message, extracting the target angle value, target angular velocity value, and target torque value from the data field according to the protocol specification, forming a target parameter set. For example, after parsing a joint control message, the target angle is 30°, the target angular velocity is 15° / s, and the target torque is 2N·m.

[0059] Third, for any set of target parameters corresponding to a joint servo motor, perform the following steps: The first sub-step involves inputting the aforementioned target parameter set into the driver of the joint servo motor. The driver is an electronic device integrated into the servo motor control system, responsible for receiving control commands and generating electrical signals to drive the motor. In practice, the execution entity sends the target parameter set to the driver of the corresponding joint servo motor via a physical interface (such as PWM output, analog output, or digital communication). For example, the target parameter set can be sent to the driver of joint 1 via a CAN bus.

[0060] The second sub-step involves using the aforementioned driver to perform difference processing on the target angle parameter and the current angle feedback value to obtain the angle deviation value. The current angle feedback value refers to the actual current angle of the joint servo motor, acquired in real-time by the encoder. Difference processing refers to the operation of calculating the error between the target value and the actual value. The angle deviation value is the difference between the target angle and the current angle, used in subsequent control algorithms. In practice, the driver reads the current angle value fed back from the encoder and subtracts it from the target angle parameter to obtain the angle deviation value. For example, if the target angle is 30° and the current feedback is 28°, the angle deviation value is 2°. The encoder can be an incremental photoelectric encoder or an absolute magnetic encoder, typically with a resolution of 17 to 23 bits to ensure the accuracy of the angle feedback. For example, this embodiment uses a 19-bit absolute encoder, which can provide an angle resolution of 0.001°, meeting the requirements of high-precision servo control.

[0061] The third sub-step involves generating the digital control quantity corresponding to the joint servo motor based on the aforementioned angle deviation value and target angular velocity parameters. The digital control quantity refers to the digitized command value used to adjust the motor speed and position, calculated using a control algorithm (such as proportional-integral-derivative control). In practice, the driver inputs the angle deviation value and target angular velocity parameters into the PID controller to calculate the digital control quantity. For example, based on an angle deviation of 2° and a target angular velocity of 15° / s, the PID controller outputs a digital quantity 0x7F.

[0062] The fourth sub-step involves performing torque feedforward compensation on the aforementioned digital control quantity based on the target torque parameters, resulting in the compensated digital control quantity. Torque feedforward compensation refers to adding the target torque parameters as a feedforward quantity to the control output to compensate for the impact of load torque on the system in advance, thereby improving dynamic response accuracy. The compensated digital control quantity is the final control quantity obtained after feedforward compensation. In practice, the driver multiplies the target torque parameters by a compensation coefficient and then adds it to the digital control quantity to obtain the compensated digital control quantity. For example, a target torque of 2 N·m corresponds to a compensation value of 0x10, and the digital control quantity of 0x7F is added to the compensation value of 0x8F. The compensation coefficient is usually pre-calibrated or dynamically adjusted and is related to parameters such as the torque constant of the servo motor and the load inertia. In actual systems, the compensation coefficient can be stored in the driver's non-volatile memory or issued by the upper-level controller during system initialization. For example, for a certain type of servo motor, the torque constant is 0.5 Nm / A, then the torque compensation coefficient can be set to 1 / 0.5 = 2, that is, the target torque parameter 2 N·m corresponds to the compensation current value of 4 A, which is converted into a digital compensation amount of 0x10.

[0063] The fifth sub-step involves inputting the compensated digital control quantity to a pulse width modulation (PWM) generator to obtain the corresponding PWM signal. The PWM generator is a hardware unit that converts the digital control quantity into a square wave signal with an adjustable duty cycle. A PWM signal simulates different voltage values ​​by changing the pulse width and is commonly used for motor speed control. In practice, the driver sends the compensated digital control quantity to the PWM generator, which adjusts the duty cycle of the output pulse according to the magnitude of the digital quantity to generate the corresponding PWM signal. For example, a digital control quantity of 0x8F corresponds to a 75% duty cycle, and the PWM generator outputs a square wave with a 75% duty cycle. The PWM generator typically has configurable resolution and carrier frequency. For example, this embodiment uses a 12-bit resolution PWM generator, which can linearly map the digital control quantity 0x000 to 0xFFF to a duty cycle of 0% to 100%. The carrier frequency can be configured according to the motor type and control requirements; for example, 8kHz to 16kHz PWM carrier frequencies are commonly used for servo motors to avoid audible noise and ensure current loop response speed.

[0064] The sixth sub-step involves outputting the aforementioned pulse width modulation (PWM) signal to the power drive circuit of the joint servo motor. The power drive circuit is a circuit that amplifies the PWM signal, typically including power transistors and a driver chip, to provide the high current and high voltage required by the motor. In practice, the driver outputs the PWM signal to the input terminal of the power drive circuit via a pin.

[0065] The seventh sub-step involves amplifying the pulse width modulation (PWM) signal using the power drive circuit to obtain the three-phase drive voltage. This three-phase drive voltage refers to the three-phase sinusoidal voltage required to drive a three-phase AC servo motor, typically converted from DC to AC by an inverter circuit. In practice, the inverter in the power drive circuit controls the switching transistors according to the PWM signal, converting the DC bus voltage into a three-phase AC voltage with adjustable frequency and amplitude, which is then output to the motor's three-phase windings. For example, based on the PWM signal, the inverter outputs three-phase voltage amplitudes of +24V, -12V, and -12V, respectively.

[0066] The eighth sub-step involves applying the aforementioned three-phase drive voltage to the three-phase stator windings of the joint servo motor. The three-phase stator windings refer to the three sets of coils on the servo motor stator, which generate a rotating magnetic field when energized. In practice, the power drive circuit directly connects the three-phase drive voltage to the U, V, and W terminals of the motor stator, and the current flows through the windings to generate a magnetic field, driving the rotor to rotate.

[0067] The fourth step involves applying the three-phase drive voltage to the three-phase stator windings of each joint servo motor, and then controlling these motors to operate collaboratively according to their respective target angle, angular velocity, and torque parameters. Collaborative operation refers to the coordinated movement of multiple joint servo motors according to their respective target parameters, jointly completing complex actions such as spatial trajectory tracking and workpiece grasping by the robotic arm's end effector. In practice, once all joint servo motors receive their corresponding three-phase drive voltage, each motor begins to rotate. Encoder feedback forms a closed-loop control, enabling each joint to work collaboratively according to the set target angle, angular velocity, and torque, driving the robotic arm to perform the predetermined task. For example, joint 1 rotates to 30°, joint 2 rotates to 45°, and joint 3 rotates to -10°, collectively bringing the robotic arm's end effector to the grasping position.

[0068] Steps one through four and their sub-steps in this embodiment of the invention address the technical problem of "how to accurately, efficiently, and collaboratively transform the fusion results obtained from upper-level intelligent computing into the physical movements of the servo motors of each joint in multi-axis robotic arm control, so as to achieve complex trajectory tracking and workpiece grasping." Existing technologies in robotic arm servo control have the following shortcomings: Firstly, traditional control schemes often employ a single position closed loop, which is prone to overshoot and oscillation when the load changes, resulting in slow dynamic response. Secondly, in multi-axis collaborative motion, the joint controls are isolated from each other, lacking torque feedforward compensation, leading to the accumulation of trajectory tracking errors and a decrease in grasping accuracy. Thirdly, the control command generation and execution chain is lengthy, lacking end-to-end hardware-level optimization from message parsing to drive voltage application, failing to meet the stringent real-time requirements of high-speed, high-precision operations. Finally, there is a lack of a joint control mechanism for multiple target parameters such as angle, speed, and torque, making it difficult to adapt to complex working conditions with varying loads and attitudes. Solving the above problems enables precise, smooth, and robust conversion from control commands to the coordinated operation of multiple joint servo motors within milliseconds, achieving high-precision trajectory tracking and reliable grasping by the robotic arm's end effector. To achieve this, this disclosure proposes the following steps: First, parsing the control messages corresponding to each joint servo motor from the aforementioned control command set. This ensures accurate distribution of multi-joint control commands, resolving the problem of mixed and difficult-to-identify commands in multi-axis systems. Second, performing protocol parsing on each joint control message to obtain the target parameter sets corresponding to each joint servo motor, where each target parameter set includes target angle parameters, target angular velocity parameters, and target torque parameters. This restores the communication messages to physically meaningful control parameters, providing complete input for refined control and resolving the disconnect between abstract commands and specific physical quantities. Third, for any target parameter set corresponding to a joint servo motor, the following steps are executed: First sub-step, inputting the target parameter set to the driver of the joint servo motor. This establishes a bridge between the upper-level control and the lower-level driver, ensuring accurate parameter delivery and resolving the problem of control link interruption. The second sub-step involves processing the difference between the target angle parameter and the current angle feedback value using the aforementioned driver to obtain the angle deviation value. This introduces a real-time position closed loop, enabling control to respond to actual deviations and avoiding the accumulation of position errors in open-loop control. The third sub-step generates the digital control quantity corresponding to the joint servo motor based on the angle deviation value and the target angular velocity parameter. This converts the deviation into an adjustment quantity using PID and other control algorithms, achieving joint adjustment of position and velocity and solving the problem of insufficient dynamic response in single-loop control. The fourth sub-step performs torque feedforward compensation processing on the digital control quantity based on the target torque parameter, obtaining the compensated digital control quantity.This process proactively offsets load torque disturbances, improving the system's anti-interference capability and dynamic tracking accuracy under varying loads, and resolving the overshoot problem caused by the lag in traditional feedback control. The fifth sub-step inputs the compensated digital control quantity to a pulse width modulation (PWM) generator to obtain the corresponding PWM signal. This converts the digital quantity into a PWM signal capable of driving the power circuit, achieving efficient power modulation and solving the problem of digital control not being able to directly drive the motor. The sixth sub-step outputs the PWM signal to the power drive circuit of the joint servo motor. This transmits the low-voltage control signal to the power stage, ensuring signal integrity and resolving the isolation problem between low-voltage control and high-voltage drive. The seventh sub-step amplifies the PWM signal through the power drive circuit, obtaining a three-phase drive voltage. This amplifies the PWM signal to a three-phase AC sufficient to drive the motor, completing the power conversion and resolving the problem of insufficient control signal power. The eighth sub-step applies the three-phase drive voltage to the three-phase stator windings of the joint servo motor. Thus, electrical energy is converted into electromagnetic torque to drive the motor to rotate, realizing the conversion from electrical signal to mechanical motion and solving the problem of missing final execution link. In the fourth step, in response to applying the three-phase drive voltage to the three-phase stator windings of the aforementioned joint servo motors, the aforementioned joint servo motors are controlled to operate collaboratively according to their corresponding target angle parameters, target angular velocity parameters, and target torque parameters. Therefore, through the synchronous drive and closed-loop feedback of multiple joints, the end effector of the robotic arm can accurately track the predetermined trajectory and complete complex tasks, solving the problems of trajectory deviation and action conflict in multi-axis collaborative motion. In summary, the first to fourth steps and their sub-steps of this embodiment cooperate with each other, starting from the entire link of "instruction parsing, parameter extraction, multi-loop control, feedforward compensation, PWM modulation, power amplification to collaborative operation," and by constructing a multi-level control framework integrating position closed loop, velocity feedforward, and torque compensation, a precise, efficient, and robust conversion from upper-level intelligent decision-making to lower-level physical action of the multi-axis robotic arm is achieved. This effectively eliminates problems such as dynamic response lag, load disturbance error, and multi-axis coordination mismatch, ensuring the trajectory tracking accuracy and grasping reliability of the robotic arm under complex working conditions, and to a certain extent meeting the core requirements of high-speed and high-precision motion control for application scenarios such as industrial automation and precision assembly.

[0069] In some optional implementations of certain embodiments, the aforementioned execution entity can control the aforementioned joint servo motors to operate collaboratively according to their respective target angle parameters, target angular velocity parameters, and target torque parameters through the following steps: The first step is to generate the target spatial pose trajectory of the robotic arm's end effector based on the aforementioned target angle parameters. The end effector is the device installed at the very end of the robotic arm to directly perform the task, such as a gripper, suction cup, or welding head. The target spatial pose trajectory is the continuous path of the end effector in three-dimensional space, representing the desired position and orientation. It is typically represented by position coordinates (x, y, z) and orientation angles (roll, pitch, yaw) or a rotation matrix. In practice, the actuator can be converted from the target angle parameters of each joint servo motor into the target pose of the end effector in Cartesian space using forward kinematics calculations, generating a continuous target spatial pose trajectory. For example, for a six-axis robotic arm, given the target angles of each joint (30°, 45°, -20°, 10°, 25°, 15°), the target position of the end effector is (0.5m, 0.3m, 0.2m) and the orientation is (0°, 0°, 90°) obtained through forward kinematics calculations.

[0070] The second step involves interpolating the target spatial pose trajectory to obtain a sequence of interpolated points. This sequence includes consecutive target pose points. Interpolation refers to the process of calculating multiple discrete intermediate points between the known starting and ending points of the trajectory using a specific interpolation algorithm (such as linear or circular interpolation) to enable smooth movement of the robotic arm. Target pose points are a series of temporally continuous desired pose points obtained after interpolation, each containing both position and attitude information. In practice, the executing entity inserts multiple intermediate points at equal intervals or at equal times along the target spatial pose trajectory based on the robotic arm control cycle (e.g., 1 ms) and movement speed, generating the interpolated point sequence. For example, a straight trajectory from the starting point (0, 0, 0) to the ending point (0.5, 0.3, 0.2) can be interpolated to obtain 100 intermediate points, each spaced 0.005m apart.

[0071] The third step involves performing inverse kinematics calculations on each target pose point in the aforementioned trajectory interpolation point sequence to obtain the set of intermediate angle parameters corresponding to each joint servo motor. Inverse kinematics calculation refers to the process of calculating the joint angles required to achieve the target pose of the end effector. The set of intermediate angle parameters refers to the set of angle values ​​that each joint servo motor should achieve for each target pose point, obtained through inverse kinematics calculation. In practice, the aforementioned actuator performs inverse kinematics calculations on each target pose point in the trajectory interpolation point sequence sequentially to obtain a set of joint angle values, forming the set of intermediate angle parameters corresponding to that point. For example, for target pose point 1, the calculated joint angles are (30.1°, 45.2°, -20.3°, 10.4°, 25.5°, 15.6°); for target pose point 2, the calculated angles are (30.3°, 45.5°, -20.6°, 10.7°, 25.8°, 15.9°), and so on.

[0072] The fourth step involves generating a trajectory tracking deviation value set based on the aforementioned sets of intermediate angle parameters and the real-time acquired current angle feedback values. The real-time acquired current angle feedback values ​​refer to the actual angles of the servo motors of each joint, obtained in real-time by the encoder. The trajectory tracking deviation value set is the set of differences between the intermediate angle parameters of each joint and the current actual angle for each target pose point. In practice, the execution entity subtracts the intermediate angle parameter set corresponding to each target pose point element-wise from the current acquired actual angle of each joint to obtain the deviation value for each joint, thus forming the trajectory tracking deviation value set. For example, if the intermediate angle parameters at a certain moment are (30.1°, 45.2°, -20.3°), and the current feedback value is (29.8°, 45.0°, -20.1°), then the deviation value set is (0.3°, 0.2°, -0.2°).

[0073] The fifth step involves real-time control quantity adjustment processing of the aforementioned trajectory tracking deviation value set and the aforementioned target angular velocity parameters, resulting in a set of adjusted digital control quantities. Real-time control quantity adjustment processing refers to the operation of dynamically adjusting the control quantities of each joint based on the trajectory tracking deviation and target angular velocity using a control algorithm (such as PID). The set of adjusted digital control quantities refers to the set of digital control quantities used to correct the motion of each joint after real-time adjustment. In practice, the aforementioned execution entity inputs each deviation value and the corresponding target angular velocity parameter from the trajectory tracking deviation value set into the PID controller, calculates the control quantity that needs to be adjusted for each joint, and forms the set of adjusted digital control quantities. For example, based on a deviation of 0.3° and an angular velocity of 15° / s, the PID outputs an adjustment quantity of 0x05; based on a deviation of 0.2°, it outputs 0x03; based on a deviation of -0.2°, it outputs -0x03, resulting in the set of adjusted digital control quantities {0x05, 0x03, -0x03}. The parameters of the PID controller (proportional coefficient Kp, integral coefficient Ki, and derivative coefficient Kd) are typically tuned based on the mechanical characteristics of the servo motor and the load conditions. In actual systems, these parameters can be obtained through automatic tuning or manual adjustment. For example, for the servo motor of joint 1, after tuning, Kp=2.5, Ki=0.1, and Kd=0.05 to ensure rapid convergence of the angle deviation and an overshoot of less than 5%.

[0074] Step 6: Superimpose the adjusted digital control quantity sets mentioned above onto the compensated digital control quantities of the corresponding joint servo motors to obtain the corrected digital control quantity sets. The compensated digital control quantity refers to the digital control quantity generated in the fourth sub-step of step 107 after torque feedforward compensation. The corrected digital control quantity set refers to the set of final control quantities used for actual drive, obtained by superimposing the real-time adjustment quantity onto the original compensation quantity. In practice, the execution entity adds the adjusted digital control quantity corresponding to each joint to the compensated digital control quantity generated in step 107 for that joint to obtain the corrected digital control quantity. For example, the original compensated digital control quantity for joint 1 is 0x8F, the adjustment quantity is 0x05, and the corrected quantity is 0x94; the original for joint 2 is 0x7A, the adjustment quantity is 0x03, and the corrected quantity is 0x7D; the original for joint 3 is 0x82, the adjustment quantity is -0x03, and the corrected quantity is 0x7F.

[0075] Step 7: Based on the aforementioned sets of corrected digital control quantities, repeat the steps of pulse width modulation signal generation, power amplification, and three-phase drive voltage application, and apply the generated three-phase drive voltages to the corresponding three-phase stator windings of the joint servo motors. Repeated execution means that for each corrected digital control quantity, the operations of sub-steps 5 to 8 in step 107 are executed again. In practice, the execution entity inputs each corrected digital control quantity to the pulse width modulation generator of the corresponding joint to generate a new pulse width modulation signal. After amplification by the power drive circuit, a new three-phase drive voltage is obtained, and these three-phase drive voltages are applied to the three-phase stator windings of the corresponding joint servo motor, driving the motor to operate according to the corrected control quantity. For example, the corrected digital control quantity 0x94 generates a PWM signal with a 78% duty cycle, which is amplified and applied to the joint 1 motor to adjust its operating state.

[0076] Step 8: In response to the robotic arm end effector reaching the target gripping position along the aforementioned trajectory interpolation point sequence, based on the aforementioned target torque parameters, the gripper servo motor is controlled to apply a preset gripping force to complete the workpiece gripping action. Here, the gripper servo motor refers to the servo motor mounted on the robotic arm end effector used to drive the gripper to open and close to grip the workpiece. The target gripping position refers to the position and posture that the robotic arm end effector ultimately expects to reach to grip the workpiece. The preset gripping force refers to the torque value pre-set according to the workpiece material and weight to ensure stable gripping without damaging the workpiece. In practice, the aforementioned actuator monitors the actual position of the robotic arm end effector in real time through encoders and sensors. When it moves to the target gripping position along the trajectory interpolation point sequence, it switches to torque control mode, converting the various target torque parameters into control signals for the gripper servo motor, driving the gripper to close with the preset gripping force to complete the workpiece gripping. For example, after the end effector of the robotic arm reaches the workpiece position (0.5m, 0.3m, 0.2m), the gripper servo motor applies a clamping force according to the target torque parameter of 2N·m, and the gripper closes to grasp the workpiece.

[0077] Steps one through eight of this embodiment are another inventive point of this disclosure, solving the technical problem of "how to further improve the accuracy of complex spatial trajectory tracking and the reliability of end-effector grasping on the basis of the basic servo drive already implemented in multi-axis robotic arms". Existing technologies have the following shortcomings in robotic arm trajectory tracking and grasping control: On the one hand, traditional solutions mostly use point-to-point joint space control, lacking the ability to plan and track the continuous trajectory of the end effector in Cartesian space, resulting in uneven motion under complex paths; on the other hand, relying solely on the single control quantity generation in step 107 cannot correct real-time deviations during dynamic trajectory tracking online, leading to amplified cumulative errors as the movement distance increases; furthermore, inverse kinematics calculation is only used for the initial and target points, lacking continuous calculation and closed-loop correction for intermediate trajectory points, making it difficult to achieve high-precision curved motion; and yet anotherly, the grasping and motion links are separated, with grasping only starting after reaching the target position, lacking coordinated control of clamping force and motion state, easily leading to grasping failure or workpiece damage due to inertial impact or insufficient torque. Solving the above problems will enable sub-millimeter tracking accuracy in continuous trajectory motion, real-time dynamic deviation correction in multi-axis collaboration, and force-position coordinated control in end-effector grasping, achieving a seamless transition from coarse positioning to fine grasping. To achieve this, this disclosure proposes the following steps: First, based on the aforementioned target angle parameters, a target space pose trajectory for the robotic arm's end effector is generated. This converts the target angles in joint space into a continuous path description of the end effector in Cartesian space, establishing an intuitive task space reference system and solving the problem of intuitively planning the end-effector trajectory in joint space control. Second, the aforementioned target space pose trajectory is interpolated to obtain a sequence of interpolated points, which includes each continuous target pose point. This discretizes the macroscopic continuous trajectory into a sequence of microscopic target points matching the control cycle, providing a fine tracking reference for high-frequency closed-loop control and solving the problem of non-smooth motion caused by sparse control points. Third, inverse kinematics is performed on each target pose point in the aforementioned trajectory interpolation point sequence to obtain a set of intermediate angle parameters corresponding to each joint servo motor. Therefore, the desired end-effector pose at each moment is mapped to the desired angle of each joint in real time, ensuring that trajectory tracking is always performed in a closed loop within the joint space, thus resolving the coordinate transformation gap between end-effector trajectory planning and joint control. The fourth step generates a trajectory tracking deviation value set based on the aforementioned intermediate angle parameter sets and the real-time acquired current angle feedback values. This quantifies the error between the actual joint angle and the desired joint angle within each control cycle, providing a precise basis for real-time correction and solving the problem of imperceptible errors in open-loop trajectory execution. The fifth step involves real-time adjustment of the aforementioned trajectory tracking deviation value set and the aforementioned target angular velocity parameters to obtain the adjusted sets of digital control quantities.Therefore, by using PID and other control algorithms, the perceived deviation is dynamically converted into a correction value, enabling each joint to actively correct trajectory deviations and solving the problem of cumulative error not being compensated online. The sixth step involves superimposing the adjusted digital control sets onto the compensated digital control values ​​of the corresponding joint servo motors to obtain the corrected digital control set. This integrates the dynamic correction of trajectory tracking with the torque feedforward compensation in step 107, forming a composite control quantity that combines load pre-compensation and real-time trajectory correction, solving the problem of difficulty in coordinating the optimization of multi-objective control parameters. The seventh step involves repeatedly executing the pulse width modulation signal generation, power amplification, and three-phase drive voltage application steps based on the corrected digital control set, and applying the generated three-phase drive voltages to the corresponding three-phase stator windings of each joint servo motor. This rapidly converts the corrected control quantity into actual motor drive, enabling the robotic arm to move according to the latest corrected command in each control cycle, achieving a dynamic closed loop for trajectory tracking and solving the problem of disconnect between control calculation and physical execution. In the eighth step, in response to the robotic arm's end effector reaching the target gripping position along the aforementioned trajectory interpolation point sequence, based on the aforementioned target torque parameters, the gripper servo motor is controlled to apply a preset gripping force to complete the workpiece gripping action. Thus, after the motion accuracy reaches the target, it immediately switches to torque-controlled gripping mode, achieving a smooth switch between motion and gripping, and ensuring gripping reliability and workpiece safety with precise gripping force, solving the problems of disconnected motion and gripping, and uncontrollable gripping force. In summary, the first to eighth steps of this embodiment cooperate with each other, starting from the entire chain of "trajectory planning, interpolation discretization, inverse demapping, deviation sensing, real-time correction, composite control, dynamic execution to force-position coordinated gripping," and by constructing a continuous trajectory tracking and adaptive gripping framework that integrates feedforward compensation and real-time feedback, sub-millimeter-level tracking accuracy and highly reliable end-effector operation of a multi-axis robotic arm in complex spatial motion is achieved. This effectively eliminates problems such as accumulated errors in trajectory tracking, lag in dynamic disturbance response, and poor motion grasping connection, ensuring the smoothness of motion, consistency of trajectory, and reliability of grasping of the robotic arm in high-speed and high-precision operation scenarios. To a certain extent, it meets the core requirements of intelligent robot motion control for high-end industrial applications such as precision assembly and complex path processing.

[0078] The above embodiments of the present invention have the following beneficial effects: Through the search and cooperative control method based on heterogeneous multi-core processors in some embodiments of the present invention, low-latency, high-throughput search and fusion computation of massive N-Gram embedded tables in the conditional memory module can be achieved, significantly improving the cooperative efficiency and energy efficiency ratio of heterogeneous multi-core processors in the "search, retrieval, and fusion" pipeline. Specifically, although conditional memory operations (such as the Engram module) in traditional large language models can avoid dynamic reconstruction of neural networks through hash lookup, they may face the following technical problems when executed on actual hardware: memory wall problem caused by extremely low computation-to-memory ratio, control and scheduling overhead introduced by fine-grained operations, and transport delay caused by tight data dependency between hash lookup and subsequent computation; if only a general programming model based on general-purpose CPUs or GPUs or existing heterogeneous multi-core architectures is relied upon, insufficient memory bandwidth utilization, idle core resources, and lengthy data copy paths may occur, ultimately leading to high overall processing latency and low throughput. Based on this, some embodiments of the present invention employ a lookup and collaborative control method based on heterogeneous multi-core processors. First, in response to the received token ID, the scalar core cluster is controlled to normalize the token corresponding to the token ID, obtaining the N-Gram key sequence to be queried. Thus, utilizing the scalar cores' strengths in scalar operations and table lookup, the original token is transformed into a structured lookup key sequence, laying the foundation for subsequent parallel hash lookups. Simultaneously, the simplest operations are offloaded to the most suitable core, avoiding the consumption of complex computing resources. Then, the vector core cluster is scheduled to perform hash addressing on the N-Gram key sequence to be queried, obtaining the address set of the corresponding off-chip memory. This fully leverages the SIMD parallel computing capabilities of the vector cores, performing parallel computation on multiple N-Gram items and multiple hash functions, and quickly handling conflicts through on-chip lightweight conflict resolution lookup tables, significantly improving address generation efficiency and centrally accelerating fine-grained hash operations, reducing subsequent memory access pressure. Next, memory access optimization processing is performed on the above address set to obtain a set of bursty access requests. Therefore, through hardware-level optimizations such as sorting, merging, and cross-page detection, fragmented discrete address aggregation is used to efficiently burst requests, maximizing off-chip memory bandwidth utilization and alleviating the memory wall problem at its root. Subsequently, based on the aforementioned burst access request set, data blocks are read from the aforementioned off-chip memory, and the read data blocks are written to the target tensor kernel cluster via a direct data injection path. Thus, on the one hand, optimized burst requests are used to efficiently acquire data, and on the other hand, data is directly injected into the tensor kernel input buffer through a dedicated physical independent side link, completely bypassing the general cache hierarchy and register file, eliminating redundant data copying and transport delays, and achieving "computation as soon as data is available". Then, the aforementioned target tensor kernel cluster is controlled to perform context fusion processing on the aforementioned data blocks to obtain the fusion result.This allows the tensor kernel to focus on high-density vector and matrix operations, fusing statically embedded vectors with the dynamic state of the upstream context to perform operations such as context-aware gating and convolution, outputting high-quality semantic fusion results. Next, based on the fusion results, a set of control instructions is generated. This transforms the abstract semantic representation into concrete digital control parameters, providing information for subsequent physical execution. Finally, based on the generated set of control instructions, the connected physical execution devices are driven to perform corresponding physical actions. This translates the output of intelligent computing into concrete operations in the physical world, achieving end-to-end closed-loop control from token input to physical actions. Furthermore, because this method designs a hierarchical pipelined hash engine, a direct data injection path, and a collaborative compilation runtime system at the hardware level, it can be deeply customized for conditional memory operation modes, enabling scalar, vector, and tensor kernels to efficiently parallelize on their respective strengths, with tightly connected pipelines, fundamentally overcoming the collaboration overhead and data transport bottlenecks of general-purpose architectures. Simultaneously, through hardware-level address aggregation and direct injection, memory bandwidth utilization is significantly improved, and processing latency is significantly reduced. Thus, by performing fine-grained mapping and optimization of the conditional memory computation process on heterogeneous multi-core processors through hardware and software collaboration, the overall processing latency, system throughput, and energy efficiency of large-scale N-Gram hash lookup and fusion computation have been improved to a certain extent, providing key technical support for the efficient deployment of large language models in the cloud, edge, and terminal.

[0079] Further reference Figure 2 As an implementation of the methods shown in the above figures, this disclosure provides some embodiments of a search and collaborative control device based on a heterogeneous multi-core processor. These device embodiments are similar to... Figure 1 Corresponding to the method embodiments shown, the device can be specifically applied to various electronic devices.

[0080] like Figure 2As shown, the search and collaborative control device 200 based on a heterogeneous multi-core processor in some embodiments includes: a first control unit 201, a scheduling unit 202, a first processing unit 203, a second processing unit 204, a second control unit 205, a generation unit 206, and a driving unit 207. The system comprises the following components: a first control unit 201 configured to, in response to a received token ID, control a scalar core cluster to normalize the token corresponding to the token ID to obtain a query N-Gram key sequence; a scheduling unit 202 configured to schedule a vector core cluster to perform hash addressing on the query N-Gram key sequence to obtain a set of addresses for the corresponding off-chip memory; a first processing unit 203 configured to perform memory access optimization on the address set to obtain a set of burst access requests; a second processing unit 204 configured to, based on the set of burst access requests, read data block data from the off-chip memory and write the read data block data to the target tensor core cluster via a direct data injection path; a second control unit 205 configured to, control the target tensor core cluster to perform context fusion processing on the data block data to obtain a fusion result; a generation unit 206 configured to, based on the fusion result, generate a set of control instructions; and a driving unit 207 configured to, according to the generated set of control instructions, drive the connected physical execution device to perform corresponding physical actions.

[0081] It is understandable that the units described in the device 200 are related to the reference. Figure 1 The steps in the described method correspond to each other. Therefore, the operations, features, and beneficial effects described above for the method also apply to the device 200 and the units contained therein, and will not be repeated here.

[0082] The following is for reference. Figure 3 It shows a schematic diagram of the structure of an electronic device 300 suitable for implementing some embodiments of the present disclosure. Figure 3 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of this disclosure.

[0083] like Figure 3 As shown, the electronic device 300 may include a processing unit 301 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 into a random access memory (RAM) 303. The RAM 303 also stores various programs and data required for the operation of the electronic device 300. The processing unit 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0084] Typically, the following devices can be connected to I / O interface 305: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; and communication devices 309. Communication device 309 allows electronic device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 An electronic device 300 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively. Figure 3 Each box shown can represent a device or multiple devices as needed.

[0085] In particular, according to some embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, some embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 309, or installed from storage device 308, or installed from ROM 302. When the computer program is executed by processing device 301, it performs the functions defined in the methods of some embodiments of this disclosure.

[0086] It should be noted that, in some embodiments of this disclosure, the computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In some embodiments of this disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In some embodiments of this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0087] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0088] The aforementioned computer-readable medium may be included within the aforementioned electronic device; or it may exist independently without being assembled into the electronic device. The aforementioned computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to: respond to a received token ID, control a scalar core cluster to normalize the token corresponding to the token ID to obtain a query N-Gram key sequence; schedule a vector core cluster to perform hash addressing on the query N-Gram key sequence to obtain a corresponding off-chip memory address set; perform memory access optimization on the address set to obtain a burst access request set; based on the burst access request set, read data block data from the off-chip memory and write the read data block data to a target tensor core cluster via a direct data injection path; control the target tensor core cluster to perform context fusion processing on the data block data to obtain a fusion result; generate a control instruction set based on the fusion result; and drive connected physical execution devices to perform corresponding physical actions according to the generated control instruction set.

[0089] Computer program code for performing operations of some embodiments of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0090] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0091] The units described in some embodiments of this disclosure can be implemented in software or hardware. The described units can also be housed in a processor; for example, a processor may be described as including a first control unit, a scheduling unit, a first processing unit, a second processing unit, a second control unit, a generation unit, and a driving unit. The names of these units do not necessarily limit the specific unit; for example, a generation unit may also be described as "a unit that generates a set of control instructions based on the fusion result."

[0092] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0093] Some embodiments of this disclosure also provide a computer program product, including a computer program that, when executed by a processor, implements any of the above-described methods for searching and co-controlling heterogeneous multi-core processors.

[0094] The above description is merely a selection of preferred embodiments of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A search and cooperative control method based on heterogeneous multi-core processors, comprising: In response to the received token ID, the scalar core cluster is controlled to perform normalization processing on the token corresponding to the token ID to obtain the N-Gram key sequence to be queried; The scheduling vector kernel cluster performs hash addressing on the N-Gram key sequence to be queried to obtain the address set of the corresponding off-chip memory; The address set is subjected to memory access optimization processing to obtain a burst access request set; Based on the burst access request set, data block data is read from the off-chip memory, and the read data block data is written to the target tensor kernel cluster through the direct data injection path; The target tensor kernel cluster is controlled to perform context fusion processing on the data block data to obtain the fusion result; Based on the fusion results, a set of control commands is generated; Based on the generated set of control commands, the connected physical actuators are driven to perform corresponding physical actions.

2. The method of claim 1, wherein, In response to the received token ID, the scalar core cluster is controlled to perform normalization processing on the token corresponding to the token ID to obtain the N-Gram key sequence to be queried, including: The token ID is subjected to vocabulary projection processing to obtain the corresponding vocabulary index; Based on the vocabulary index, the token ID is normalized at the character level to obtain a normalized token; The normalized token and the preceding token in the preset window are concatenated with suffix sequences to obtain the N-Gram key sequence to be queried.

3. The method of claim 1, wherein, The scheduling vector core cluster performs hash addressing on the N-Gram key sequence to be queried, obtaining the address set of the corresponding off-chip memory, including: Each N-Gram key in the N-Gram key sequence to be queried is processed by applying various hash functions in parallel to generate hash values, thereby obtaining a set of candidate hash values ​​corresponding to each N-Gram key. Based on the aforementioned candidate hash value sets, a candidate hash value set in which hash collisions occur is generated; Obtain the set of address correction records corresponding to the set of candidate hash values ​​that have caused hash collisions; Based on the address correction record set, address correction processing is performed on the candidate hash value set that has a hash collision to obtain the address set of the corresponding off-chip memory.

4. The method of claim 1, wherein, The memory access optimization process performed on the address set to obtain a bursty access request set includes: The physical addresses in the address set are sorted to obtain an ordered address sequence; The ordered address sequence is merged to obtain a merged set of contiguous address blocks; Perform page cross-page detection processing on each consecutive address block in the set of consecutive address blocks to obtain each page intra-address sub-block; Based on the starting address and continuous length of each page address sub-block, a corresponding set of burst access requests is generated.

5. The method of claim 1, wherein, The control of the target tensor kernel cluster to perform context fusion processing on the data block data to obtain the fusion result includes: Obtain the context hidden state vector through an on-chip network; Load the individual N-Gram embedding vectors contained in the data block data from the dedicated input buffer of the target tensor kernel; Perform key projection processing on each of the N-Gram embedding vectors to obtain the corresponding set of key vectors; Value projection processing is performed on each of the N-Gram embedding vectors to obtain the corresponding set of value vectors; Attention scores are generated by processing the context hidden state vector and each key vector in the key vector set to obtain the corresponding gating score set. Based on the set of gated scores, the value vectors in the set of value vectors are weighted and combined to obtain a fusion vector; The fused vector is convolved to obtain the convolved vector; The convolutional vector is then subjected to residual concatenation to obtain the fusion result.

6. The method of claim 1, wherein, The generation of a set of control commands based on the fusion result includes: The fusion results are subjected to parameter parsing processing to extract each control parameter field; The control parameter fields are format-converted to obtain the control signals for each actuator. Each control signal is encapsulated using a protocol to generate a corresponding set of control commands.

7. A search and cooperative control device based on a heterogeneous multi-core processor, comprising: The first control unit is configured to, in response to a received token ID, control the scalar core cluster to perform normalization processing on the token corresponding to the token ID to obtain the N-Gram key sequence to be queried; The scheduling unit is configured to schedule the vector kernel cluster to perform hash addressing on the N-Gram key sequence to be queried, so as to obtain the address set of the corresponding off-chip memory; The first processing unit is configured to perform memory access optimization processing on the address set to obtain a burst access request set. The second processing unit is configured to read data block data from the off-chip memory based on the burst access request set, and to write the read data block data into the target tensor kernel cluster through a direct data injection path. The second control unit is configured to control the target tensor kernel cluster to perform context fusion processing on the data block data to obtain a fusion result. The generation unit is configured to generate a set of control instructions based on the fusion result; The drive unit is configured to drive the connected physical actuators to perform corresponding physical actions according to the generated set of control instructions.

8. An electronic device, comprising: One or more processors; A storage device on which one or more programs are stored; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1 to 6.

9. A computer readable medium having stored thereon a computer program, wherein, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 6.

Images