A multi-core chip data transmission method, system and device

Abstract

This invention discloses a multi-core chip data transmission method, system, and device, relating to the field of many-core processors, to improve the concurrent performance of multi-core chips. This application acquires transaction data to be transmitted; divides the transaction data into at least one transaction frame according to a set frame size; determines the logical address of the target computing core for each transaction frame; maps the logical address to the physical address of the target computing core; and sends the transaction frame to the target computing core according to the physical address. Based on a fixed physical connection architecture, this application dynamically adapts to the parallel distribution needs of shared data of different granularities and ranges; only one transmission is needed to cover all target computing cores, significantly improving forward bandwidth efficiency; forward transmission does not require a handshake, ensuring timely anomaly correction while effectively reducing reverse feedback link overhead and lowering feedback link bandwidth pressure.

Description

Technical Field

[0001] This invention relates to the field of many-core processor technology, and in particular to a multi-core chip data transmission method, system and device. Background Technology

[0002] In multi-core chip systems designed for massively parallel processing, there is often a problem of efficiently propagating a large number of shared data blocks and shared commands among numerous computing cores. As the system scales to a large number of cores, the way this shared information is propagated will directly affect the overall throughput, latency, and energy efficiency.

[0003] Taking scientific computing as an example, in large-scale matrix multiplication, solving sparse linear equations, finite element methods, spectral methods, or multibody simulations, certain matrix blocks, boundary condition blocks, iterative parameter updates, or intermediate result blocks often need to be reused by multiple computing cores. If a method of repeatedly sending data to each target is adopted, it will cause significant data transport redundancy and link congestion. Similarly, in AI (Artificial Intelligence) accelerators, deep learning training and inference typically involve large batches of shared weight blocks, normalized parameters, positional encoding parameters, tensor partitioning, and synchronization control commands. This information often needs to be consumed simultaneously by multiple computing cores in a large-scale parallel core array. As model size, batch size, and parallelism continue to increase, the efficient propagation of shared data and commands becomes a critical issue in system architecture.

[0004] However, existing massively parallel chips typically still have the following shortcomings when dealing with the aforementioned problems of large amounts of shared data and shared command propagation: 1. For shared data blocks that need to be delivered to multiple computing cores simultaneously, the common practice is still to repeatedly deliver the data to multiple targets via the control terminal, DMA, or on-chip network. This results in the same data being moved multiple times on the forward link, leading to low bandwidth utilization.

[0005] 2. As the core scale continues to expand, repeated transmission of shared parameters, matrix partitioning, or synchronization commands will lead to significant link congestion, accumulated transmission delays, and increased control overhead, especially in large-scale parallel arrays.

[0006] 3. Known systems typically favor data distribution methods oriented towards fixed task flows or static mappings. When application load changes, parallel granularity changes, or task grouping changes, it is difficult to efficiently adapt to the shared data propagation needs of different ranges and granularities.

[0007] 4. For data that needs to be delivered to multiple targets simultaneously, relying on target-by-target confirmation, software polling, or upper-layer scheduling and coordination to ensure reliability can easily lengthen the forward transmission path and reduce the overall throughput.

[0008] 5. For broadcast or multi-target distribution transactions, existing mechanisms often focus more on whether the data content is erroneous, but lack fast and unified hardware-level processing methods for sequential issues such as frame loss, duplicate arrivals, missing frames, and expired resending.

[0009] 6. When some targets fail to receive data, existing solutions often require reorganizing data, re-initiating transactions, or even relying on software rescheduling, resulting in long recovery paths and coarse recovery granularity, which is not conducive to the continuous execution of large-scale parallel pipelines.

[0010] Therefore, for scenarios involving the propagation of large amounts of shared data and commands in massively parallel chips, key issues that constrain the concurrency bottleneck of multi-core chips include how to reduce bandwidth waste and control overhead caused by repeated transmissions, how to adapt to dynamic load changes, how to achieve efficient propagation within a large target range, and how to quickly detect, respond to, and recover from local errors. Summary of the Invention

[0011] The purpose of this invention is to provide a multi-core chip data transmission method, system, and device to address all or part of the problems mentioned above, thereby solving at least one of the problems and improving the concurrent performance of multi-core chips.

[0012] The technical solution adopted in this invention is as follows: In a first aspect, this application provides a multi-core chip data transmission method, the method comprising: Obtain the transaction data to be transmitted; The transaction data is divided into at least one transaction frame according to the set frame size; Determine the logical address of the target computing core for each transaction frame; The logical address is mapped to the physical address of the target computing core; the logical address and the physical address are associated and mapped according to configurable information; The transaction frame is sent to the target computing core based on the physical address.

[0013] Optionally, mapping the logical address to the physical address of the target computing core includes: Based on the computation cluster identifier of the logical address, or based on the computation cluster identifier and the computation core index of the logical address, the slice identifier and port identifier of the target computation core are mapped; each computation cluster is mapped to at least one core slice, each core slice is fixedly connected to at least two computation cores, the core slice is located by the slice identifier, and the computation core is located within each core slice by the port identifier.

[0014] Optionally, the slice identifier and port identifier of the target computing core are mapped based on the computing cluster identifier of the logical address, or based on the computing cluster identifier and computing core index of the logical address, including: Calculate the global index of the target computing core based on the computing cluster identifier of the logical address, or based on the computing cluster identifier and computing core index of the logical address; Based on the global index, the slice identifier and port identifier of the target computing core are determined by the size of each core slice.

[0015] Optionally, the method also includes: Each transaction frame is identified by a sequence number, which indicates that the target computing core will only allow the current transaction frame to be formally received if the sequence number of the current transaction frame is in a normal state.

[0016] Optionally, the method also includes: A second buffer is constructed for each computing core. The second buffer includes a first partition and a second partition. The first partition stores transaction frames to be formally received, and the second partition stores transaction frames with abnormal sequence numbers.

[0017] Optionally, sending the transaction frame to the target computing core based on the physical address includes: Based on the slice identifier and port identifier, calculate the local mask of the corresponding core slice, whereby the local mask indicates the selected computing core; The transaction frame is sent to the selected computing core according to the local mask.

[0018] Optionally, the transaction frame is written to a first buffer; the method further includes: Upon receiving error feedback from the target computing core, the current transaction frame is sent first, and then the transaction frame that caused the error is read from the first buffer and resent. When a missing frame feedback is received from the target computing core, check whether the missing transaction frame has been retransmitted. If so, ignore the missing frame feedback; otherwise, read the missing transaction frame from the first buffer and retransmit it. The error feedback and / or missing frame feedback are provided through a reverse feedback network, which only provides feedback when an error or missing frame occurs.

[0019] Optionally, the method also includes: Each transaction frame is identified by a verification identifier, which indicates the integrity verification information of each transaction frame. This means that the target computing core will only allow the current transaction frame to be formally received if the integrity verification of the current transaction frame based on the integrity verification information passes.

[0020] In a second aspect, this application also provides a multi-core chip data transmission system, comprising: The control core is configured to: acquire transaction data to be transmitted; and divide the transaction data into at least one transaction frame according to a set frame size. A global distributor is configured to: map the logical address of the target computing core to the physical address of the target computing core based on the determined logical address of each transaction frame; the logical address and the physical address are associated and mapped according to configurable information; A local dispatcher is configured to send the transaction frame to the target computing core based on the physical address.

[0021] In a third aspect, this application also provides an electronic device comprising: Storage medium containing computer programs; The processor is connected to the storage medium and runs the computer program to execute the multi-core chip data transmission method described above.

[0022] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are: This application maps the logical addresses of computing cores to their physical addresses using configurable information, decoupling logical computing clusters from physical distribution addresses and improving the flexibility of multi-core data concurrency. By changing this configurable information, it can quickly adapt to changes in load, parallel granularity, or task grouping, dynamically meeting the parallel distribution needs of shared data at different granularities and ranges. Transaction data only needs to be sent once to cover all target computing cores, eliminating the need to repeatedly send shared data, significantly improving forward bandwidth efficiency, which increases with the number of target computing cores. Through the configuration of sequence number identifiers and / or checksum identifiers, it enables rapid detection of timing errors and / or transaction data errors, improving data transmission reliability while achieving idempotent communication and reducing data transmission redundancy. Anomaly feedback is achieved through a reverse feedback network independent of the forward broadcast link, eliminating the need for handshakes in forward transmission. This ensures timely anomaly correction while effectively reducing reverse feedback link overhead and lowering feedback link bandwidth pressure. Furthermore, the buffer's send / receive mechanism enables rapid response to retransmission of erroneous frames, avoiding retransmission of leading frames. Attached Figure Description

[0023] The present invention will be described by way of example and with reference to the accompanying drawings, wherein: Figure 1 This is a flowchart of the stages of a multi-core chip data transmission method in one embodiment.

[0024] Figure 2 This is a flowchart of a logical address to physical address mapping method in one embodiment.

[0025] Figure 3 This is a flowchart illustrating the implementation of a multi-core chip data transmission method in a complete embodiment.

[0026] Figure 4 This is a system architecture diagram of a multi-core chip data transmission system in one embodiment. Detailed Implementation

[0027] All features disclosed in this specification, or all steps in all disclosed methods or processes, may be combined in any way, except for mutually exclusive features and / or steps.

[0028] Any feature disclosed in this specification (including any appended claims and abstract) may be replaced by other equivalent or similar features, unless specifically stated otherwise. That is, unless specifically stated otherwise, each feature is merely one example of a series of equivalent or similar features.

[0029] To address several problems existing in current multi-core chip shared data transmission methods, this application proposes a multi-core chip data transmission method, aiming to solve all or some of the following problems: 1. How to flexibly map the logical address of transaction data to different computing cores while keeping the physical connection of the computing cores fixed.

[0030] 2. How to avoid performance loss caused by frame-by-frame handshake in high-throughput forward broadcast links.

[0031] 3. How to promptly detect abnormal frames, such as corrupted data, lost frames, duplicate frames, and expired frames, without a handshake.

[0032] 4. How to achieve rapid recovery after an anomaly occurs.

[0033] 5. How to ensure that receiving errors do not contaminate the target computing core's official registers or local storage state.

[0034] In response to the above problems, such as Figure 1 As shown, in one optional implementation, the multi-core chip data transmission method proposed in this application includes the following steps: S1. Obtain the transaction data to be transmitted.

[0035] Transaction data to be transmitted can be understood as shared data to be distributed to a set of target computing cores for repeated use. As mentioned earlier, in scientific computing scenarios such as large-scale matrix multiplication, solving sparse linear equations, finite element analysis, spectral method computation, or multibody simulation, certain matrix blocks, boundary condition blocks, iterative update parameters, or intermediate results often need to be reused by multiple computing cores. This repeatedly used data is transaction data. In traditional methods, transaction data is repeatedly distributed to various target computing cores, resulting in the same data being transported multiple times in the forward broadcast link, leading to low forward bandwidth utilization.

[0036] S2. Divide the transaction data into at least one transaction frame according to the set frame size.

[0037] Transaction data varies in size, while the size of a single transaction frame (the maximum payload of a single transaction frame) is fixed and finite. Typically, multiple transaction frames are needed to contain complete transaction data. Therefore, after acquiring transaction data, it is used as the payload of a transaction frame and divided into one or more transaction frames. If a single transaction frame can contain the complete transaction data, only one transaction frame is needed. Otherwise, the transaction data is divided into multiple (two or more) transaction frames, each containing one transaction data segment. If the payload of the last transaction frame is not full, it is padded with zeros or other methods.

[0038] For example, assuming each transaction frame can carry a 32-byte payload (transaction data segment), then 64KB of transaction data corresponds to 2048 transaction frames, 128KB of transaction data corresponds to 4096 transaction frames, and so on.

[0039] S3. Determine the logical address of the target computing core for each transaction frame.

[0040] The target computing core is the computing core that needs to share transaction data. The target computing core of each transaction frame is the same, so the logical address of each transaction frame is also the same. The difference lies in the transaction data segment where its payload is located.

[0041] In the embodiments of this application, the logical address represents the logical set of the target computing cores. It is not bound to any fixed computing core, so as to achieve decoupling between the logical address and the physical computing core. Thus, even when the physical connection architecture of the computing core is fixed, the logical address can still be flexibly mapped to different sets of computing cores to achieve efficient adaptation for the propagation of shared data of different ranges and granularities.

[0042] A logical address describes a logical target rather than a physical location. In one optional implementation, a logical address can be defined as the identifier of the computing cluster to which the target computing core belongs, and the index of the computing core within the corresponding computing cluster. The computing cluster identifier indicates the computing cluster to which the target computing cluster belongs; each computing cluster corresponds to a set of computing cores after the configurable information is determined, and the computing core index indicates the logical location of the target computing core within that computing cluster.

[0043] As an optional implementation method, the logical address format design is shown in Table 1.

[0044] Table 1 Logical Address Configuration Table

[0045] Among them, TYPE represents the transaction type, which includes three types: global broadcast, compute cluster multicast, and unicast; ClusterID represents the compute cluster identifier; Local_Index represents the compute core index within the compute cluster, which is only used in unicast scenarios.

[0046] In addition, for each logical layer of the computing cluster, in one optional implementation, configurable information as shown in Table 2 is maintained.

[0047] Table 2 Configurable Information Table

[0048] Here, ENABLE represents the enable flag, indicating whether the current computing cluster is allowed to be decoded (i.e., mapped), with 1 indicating an enabled state and 0 indicating a disabled state; BASE represents the starting value of the global index corresponding to the computing cluster, represented in the format BASE[ClusterID], that is, the starting value of the global index of the computing cluster corresponding to ClusterID; COUNT represents the number of computing cores covered by the computing cluster, represented in the format COUNT[ClusterID], that is, the number of computing cores covered by the computing cluster corresponding to ClusterID. Clearly, Local_Index and COUNT[ClusterID] should have a corresponding relationship. If Local_Index is encoded using sequence numbers (such as 0, 1, 2, ...), its value should not exceed COUNT[ClusterID], i.e. In one specific embodiment, Local_Index is encoded sequentially starting from 0. This definition can be used as one of the constraints to check for errors in logical addresses.

[0049] In unicast scenarios, the logical target can be uniquely located by combining the computing cluster identifier and the computing core index.

[0050] In multicast / broadcast scenarios, all computing cores within the entire computing cluster belong to the target computing core. Therefore, there is no need to consider the computing core index; all logical targets can be located through the computing cluster identifier (for multicast scenarios).

[0051] S4. Map the logical address to the physical address of the target computing core.

[0052] Logical addresses and physical addresses are associated and mapped based on configurable information. By changing the configurable information (e.g., changing the BASE and / or COUNT fields of the compute cluster), logical addresses can be mapped to different compute core sets, thereby enabling flexible concurrent propagation of transactional data.

[0053] Before explaining the mapping method, let's first describe the hardware connection architecture of a multi-core chip. A multi-core chip consists of multiple computing cores, which are divided into multiple core slices. Each core slice connects to a fixed number (two or more) of physical layer computing cores. Each core slice can be represented and located using a slice identifier (LDR_ID). Within each core slice, each computing core is represented and located using a port identifier (PORT).

[0054] In one alternative implementation, the way logical addresses are mapped to physical addresses is determined by the transaction type (i.e., TYPE), such as... Figure 2 As shown, it includes the following three cases: (1) For unicast scenarios, the slice identifier and port identifier of the target computing core are mapped based on the computing cluster identifier and computing core index of the logical address.

[0055] Based on the compute cluster identifier, the starting value of the global index for the corresponding compute cluster can be determined. Combined with the compute core index, the global index (GlobalID) of the target compute core (i.e., the logical target) can then be calculated. Based on this global index and the size of each core slice, the slice identifier and port identifier of the target compute core can then be determined.

[0056] For multi-core chips, all computing cores can be indexed using the GlobalID global index. For example, slice identifiers and port identifiers can be mapped using the following method: (1.1) Calculate the global index of the target computing core based on the computing cluster identifier and computing core index of the logical address.

[0057] Read ClusterID, and based on its corresponding configurable information, read BASE[ClusterID] and COUNT[ClusterID].

[0058] As a preferred embodiment, check whether Local_Index<COUNT[ClusterID] holds, if yes, proceed, otherwise terminate the process.

[0059] According to Calculate the global index GlobalID of the target computing core.

[0060] (1.2) According to the global index and the size of each core slice, determine the slice identifier and port identifier of the target computing core.

[0061] Assuming that the size of each core slice (i.e., the number of computing cores it contains) is K, and the slice identifiers LDR_ID of each core slice are defined to be encoded sequentially, the slice identifier of the target computing core can be determined by the following method: ; Determine the port identifier PORT by the following method: .

[0062] In a specific embodiment, the number K of computing cores contained in each core slice is defined as a power of 2, then the slice identifier LDR_ID and the port identifier can be efficiently encoded / mapped by the following shift and low-order truncation method: ; .

[0063] (2) For the multicast scenario, map the slice identifier and port identifier of the target computing core according to the computing cluster identifier of the logical address.

[0064] According to the computing cluster identifier, the starting value of the global index of the target computing core can be determined, and then combined with the number of computing cores contained in the computing cluster, the end value of the global index of the target computing core can be calculated. Then, based on the calculated global index and the size of each core slice, the slice identifiers of all core slices covered by the computing cluster and the port identifiers of the computing cores covered in each core slice are determined.

[0065] For example, the slice identifier and the port identifier can be obtained by mapping according to the following method: (2.1) Calculate the global index of the target computing core according to the computing cluster identifier of the logical address.

[0066] Read ClusterID, and read BASE[ClusterID] and COUNT[ClusterID] according to its corresponding configurable information.

[0067] According to Determine the global index start value (start) and the global index end value (end) respectively.

[0068] (2.2) Based on the global index, determine the slice identifier and port identifier of the target computing core by the size of each core slice.

[0069] Based on the global index start value start, determine the slice identifier start value start_ldr: ; If K is a power of 2, then it can be achieved through... Implement fast encoding of the slice identifier start_ldr.

[0070] Based on the global index end value `end`, determine the slice identifier end value `end_ldr`: ; If K is a power of 2, then it can be achieved through... Implement fast encoding of the slice identifier end_ldr.

[0071] The slice identifier of the target computation core is then... The slice identifier start_ldr and slice identifier end_ldr may point to the same core slice or different core slices.

[0072] For port identifiers, this covers all ports between the global index start value (start) and the global index end value (end). Specifically, it may involve the following three parts: (a) In the slice identifier start value start_ldr, the global index start value start corresponds to all ports after the port identifier. This can be represented as: .

[0073] (b) All ports of all complete core slices between the slice identifier start_ldr and the slice identifier end_ldr. This "intermediate core slice" may not exist, or it may exist as one or more; the port identifiers involved in each core slice can be represented as: .

[0074] (c) In the slice identifier end value end_ldr, the global index end value end corresponds to all ports before the port identifier. This can be represented as: .

[0075] In this way, the slice identifier and port identifier of all target computing cores in the multicast scenario can be mapped.

[0076] (3) In the global broadcast scenario, all slice identifiers and port identifiers are mapped to the physical address of the target computing core. That is, all core slices are hit, and all ports in each core slice are selected.

[0077] Through the above mapping from logical addresses to physical addresses, the physical location of the computing cores that need to share transaction data is achieved at the physical level, with the logical target and the physical architecture of the computing cores completely decoupled. Furthermore, configuration files can be adjusted as needed, allowing for flexible adjustment of the computing core distribution targets while maintaining a fixed computing core connection architecture, thus adapting to the distribution of shared data at different ranges and granularities.

[0078] Furthermore, in an optional implementation, this application embodiment also designs a handshake-free broadcast method for the forward broadcast link to improve the high throughput of the forward broadcast link. Specifically, in the multi-core chip data transmission method, for the transaction frame encapsulation format, a sequence number identifier SEQ is used to indicate the transaction sequence number of each transaction frame, so as to instruct the target computing core to formally receive the current transaction frame only when the sequence number status of the current transaction frame is normal.

[0079] By using the sequence number (SEQ) to indicate the transaction sequence number of each transaction frame, and sending each transaction frame in sequence according to the transaction sequence number, the receiving end (target computing core) can achieve handshakeless broadcasting of transaction data by continuously receiving each transaction frame in the same order. When the target computing core verifies that the transaction sequence number of each transaction frame indicates that it should be received, it will normally receive the current transaction frame without considering other verification measures (such as integrity verification); otherwise, it will postpone receiving.

[0080] Using the above method, it is not necessary to perform ACK verification (i.e., frame-by-frame ACK verification) when each transaction frame is transmitted. The (control core Ccore) does not need to wait for frame-by-frame confirmation from the target computing core, which greatly reduces the transmission delay caused by ACK verification and improves data transmission efficiency.

[0081] In addition, to ensure the reliability of data transmission, in an optional implementation, a check identifier (CRC) is used to indicate the integrity check information of each transaction frame, so that the target computing core can only officially receive the current transaction frame if the integrity check of the current transaction frame based on the integrity check information passes.

[0082] In one specific implementation, integrity verification information covers all valid fields of the transaction frame (i.e., all fields except those that serve as frame identifiers—such as frame start and frame end). Integrity verification information (such as a CRC checksum) is calculated from these valid fields. During integrity verification, the integrity verification information is recalculated based on the valid fields of the received transaction frame and compared with the integrity verification information indicated by the CRC checksum in the received transaction frame. If the comparison result matches, the verification passes; otherwise, the verification fails, indicating that the received transaction frame is an erroneous frame, and corresponding error feedback can be provided.

[0083] For example, suppose the frame format of a complete transaction frame is as shown in Table 3.

[0084] Table 3 Transaction Frame Encapsulation Format Table

[0085] In this structure, SOF stands for Start of Frame; RETRY is the retransmission flag, indicating whether the current transaction frame is a retransmission frame (1 for retransmission, 0 for non-retransmission); OFFSET indicates the offset position of the current transaction frame (payload portion) within the current transaction data (complete data block), used to indicate the position where the corresponding transaction data segment is written to the target buffer; PAYLOAD represents the payload data, i.e., the divided transaction data segment; CRC represents the checksum flag; and EOF stands for End of Frame. The CRC checksum covers TYPE + ClusterID + Local_Index + SEQ + RETRY + OFFSET + PAYLOAD. If the transaction frame is encapsulated in another format, such as removing the RETRY and OFFSET fields, the coverage range will be adjusted accordingly.

[0086] It should be noted that the configuration of the check flag (CRC) and the sequence number flag (SEQ) can be implemented separately or simultaneously. When both the check flag (CRC) and the sequence number flag (SEQ) are configured simultaneously, reliable broadcasting without a handshake is achieved. Furthermore, this provides a foundation for the design of streaming CRC detection methods.

[0087] The streaming CRC detection method involves sequentially verifying the integrity of each transaction frame without needing to return the verification results frame by frame. No feedback is required during normal transmission; feedback is only given when transmission is abnormal.

[0088] Specifically, in addition to synchronously configuring the check identifier CRC and the sequence number identifier SEQ, this application embodiment also designs an independent reverse feedback network. This reverse feedback network is independent of the forward broadcast link and only provides feedback when an error or missing frame (or a fault) occurs.

[0089] The target computing core performs integrity verification on the received transaction frames based on the CRC checksum and provides error feedback when an error occurs. Upon receiving error feedback from the target computing core, the core first completes the transmission of the current transaction frame (i.e., the new transaction frame to be distributed) and then retransmits the transaction frame that had the error.

[0090] The target computing core verifies the sequence status of received transaction frames based on the sequence number identifier SEQ, and provides feedback when a frame is missed. Upon receiving the missing frame feedback from the target computing core, it checks whether the missed transaction frame has been retransmitted. If so, the missing frame feedback is ignored; otherwise, the missed transaction frame is retransmitted.

[0091] In an optional implementation, the target computing core also performs a validity check on the received transaction frames to verify their legality under the current configuration, and issues an illegal feedback if the check is invalid. Upon receiving the illegal feedback from the target computing core, the transmission of transaction data is terminated, and information reflecting configuration errors, such as configuration anomalies or address anomalies, is uploaded to the upper-layer scheduling or management logic unit.

[0092] As an optional implementation, the data sending end is the control core, which is configured with a first buffer, Replay Buffer. All transaction frames generated by it are sequentially written into the first buffer, Replay Buffer, according to the sequence number identifier SEQ.

[0093] When the control core receives error feedback from the target computing core, it first completes the transmission of the current transaction frame, and then reads the transaction frame that caused the error from the first buffer, the Replay Buffer, according to the sequence number identifier SEQ, and retransmits it.

[0094] When the control core receives a missing frame feedback from the target computing core, it checks whether the missing transaction frame has been retransmitted. For example, according to the embodiment in Table 3, it checks whether the RETRY field is 1. If it is, it means that it is a retransmitted frame, and the missing frame feedback is ignored. If not, it reads the corresponding transaction frame from the first buffer Replay Buffer and retransmits it according to the sequence number identifier SEQ of the missing transaction frame.

[0095] Based on the retransmission and supplementary transmission mechanism of the first buffer, the error frame / missing frame has the characteristics of short recovery path and fast response.

[0096] At least one of the aforementioned error feedback, missing frame feedback, or illegal feedback is fed back through the reverse feedback network (to the control core) only when the corresponding state occurs.

[0097] As an optional implementation method, such as Figure 3As shown, an idempotent transmission method was also designed using the sequence number SEQ and the check CRC.

[0098] Specifically, to address the detection of missing, duplicate, and expired frames, a frame record field, LAST_COMMITTED_SEQ, is maintained for each computing core, representing the sequence number of the most recently received transaction frame. Specific idempotent transmission methods include: For the currently received transaction frame: (a) If SEQ==LAST_COMMITTED_SEQ+1 and the integrity check passes (e.g., CRC check passes), then the current transaction frame is a normal new frame and can be formally received.

[0099] (b) If SEQ==LAST_COMMITTED_SEQ and RETRY=1, then the current transaction frame is a historical transaction frame that has been officially received or a transaction frame that has been repeatedly delivered, and the current transaction frame is discarded directly.

[0100] (c) If SEQ > LAST_COMMITTED_SEQ + 1 and the integrity check passes, it indicates a missing frame. In this case, the current transaction frame is determined to be a leading frame and is temporarily buffered. For example, a second buffer, Shadow Buffer, is built for each computing core to buffer the current transaction frame. At this point, a missing frame feedback can be triggered via a reverse feedback network. This feedback carries the sequence number (SEQ) of the missing transaction frame, which can be determined using LAST_COMMITTED_SEQ and SEQ. Typically, a missing frame feedback is triggered for frames where SEQ == LAST_COMMITTED_SEQ + 1, thus triggering the (control core) to retransmit the missing transaction frame.

[0101] As a further preferred alternative implementation, the second buffer, ShadowBuffer, constructed for each computing core, is divided into a first partition (pending commit area) and a second partition (out-of-order temporary storage area). The first partition stores transaction frames to be formally received. Formal reception of transaction frames is completed by submitting the transaction frames (payloads, i.e., transaction data segments) in the first partition from the second buffer to the formal state (such as submitting them to the formal registers or local SRAM of the computing core). The second partition stores transaction frames with abnormal sequence numbers. The current transaction frame received in scenario (a) above is written to the first partition, and the current transaction frame received in scenario (c) above is written to the second partition. After the missing frame is formally received, it is released back to the first partition. This design of the second buffer, ShadowBuffer, can effectively prevent erroneous data (including erroneous frames and out-of-order frames) from contaminating the formal data.

[0102] In addition, for the transaction frame encapsulation format designed in the embodiment of Table 3, the advance frame is written into the second partition of the second buffer Shadow Buffer at the position indicated by OFFSET in the second buffer Shadow Buffer.

[0103] (d) If SEQ < LAST_COMMITTED_SEQ, it indicates that the current transaction frame is an expired frame, which is directly discarded.

[0104] Through the above idempotent transmission method, the detection of missing frames, duplicate frames and expired frames is realized, which further improves the data transmission reliability of the handshake-free broadcast method.

[0105] S5. Send the transaction frame to the target computing core according to the physical address.

[0106] By mapping the logical address to the physical address, the positioning from the logical target to the physical computing core is completed, and then the transaction frame is distributed to each target computing core in parallel according to the mapped physical address. Through one-time issuing, the synchronous data distribution to a batch of target computing cores can be completed without repeatedly sending transaction data, which greatly improves the bandwidth utilization of the forward broadcast link.

[0107] In an optional implementation manner, after the slice identifier and port identifier of the target computing core are obtained by mapping, the transaction frame is transmitted according to the following method: (1) Calculate the local mask of the corresponding core slice according to the slice identifier and the port identifier, where the local mask indicates the selected computing cores in the core slice.

[0108] For example, each core slice maintains a local mask whose length corresponds to the number of computing cores in the core slice, that is, a mask with a length of K. In this mask, the computing core corresponding to the data bit with a value of 1 is selected.

[0109] For the unicast scenario, the data bit corresponding to the port identifier in the local mask of the core slice corresponding to the slice identifier is set to 1, and the remaining data bits are kept as 0.

[0110] For the multicast scenario, all bits of the local mask of the core slice corresponding to the slice identifier are set to 1.

[0111] For the broadcast scenario, all bits of the local masks of all core slices are set to 1.

[0112] (2) Send the transaction frame to the selected computing cores according to the local mask.

[0113] Based on the local mask calculated for the core slice, computing cores with data bits set to 1 are selected, and transaction frames are transmitted in parallel to all selected computing cores. At this time, the transaction frames transmitted to the selected computing cores are transaction frames distributed by the control core. For implementations with verification mechanisms, the computing cores will also perform corresponding checks / verifications after receiving the transaction frames to determine whether to formally accept the transaction frames.

[0114] Based on the ideas in this application, such as Figure 4 As shown, this application embodiment also discloses a multi-core chip data transmission system, which includes: The control core (Ccore) is configured to: acquire transaction data to be transmitted; and divide the transaction data into at least one transaction frame based on the set frame size.

[0115] The Global Distributor (GDC) is configured to map logical addresses to physical addresses of target compute cores based on the determined logical addresses of each transaction frame. The logical and physical addresses are associated and mapped according to configurable information.

[0116] The Local Distributor (LDR) is configured to send transaction frames to the target computing core based on the physical address.

[0117] There is at least one Local Distributor (LDR), and each LDR is connected to a fixed number of computing cores.

[0118] The optional implementations of the control core, global distributor, and local distributor can be found in the corresponding optional implementations in the previous multi-core chip data transmission method embodiment, and will not be described in detail here.

[0119] Furthermore, based on the concept of this application, embodiments of this application also provide an electronic device, which includes: Storage medium containing computer programs; The processor is connected to a storage medium and runs the computer program described above to execute the multi-core chip data transmission method described in the preceding embodiments.

[0120] The multi-core chip data transmission method proposed in this application has unique application value in modern high-performance computing and dedicated accelerator architectures.

[0121] To facilitate understanding of the technical solutions of this application, the embodiments of this application provide the following examples to illustrate the technical solutions of this application. It should be noted that the following examples are merely illustrative of various optional implementation methods and do not limit the implementation of this application to the use of all optional implementation methods.

[0122] Unified system configuration: The total number of computing cores is N=256, denoted as core_0 to core_255, which is the global index GlobalID of the computing cores.

[0123] The number of secondary local distributors (LDRs) is M=16, denoted as LDR_0 to LDR_15; these can serve as core slice identifiers. Each LDR is fixedly connected to K=16 computational cores.

[0124] For any GlobalID, we have .

[0125] The physical connection relationship of LDR is fixed as follows: ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; .

[0126] The 14-bit logical target address field is used: |TYPE[13:12]|ClusterID[11:8]|Local_Index[7:0]|, where TYPE=00 indicates unicast, TYPE=01 indicates cluster multicast, and TYPE=11 indicates global broadcast; ClusterID is the Cluster number, i.e., the computing cluster identifier, which can support 16 logical computing clusters; Local_Index is the local index within the Cluster, which can support... The local number can be set to 0 during cluster multicast or all broadcast.

[0127] PAYLOAD is fixed at 256 bits, and each frame can carry 32 bytes of data. A 64KB data block corresponds to 2048 frames, and a 128KB data block corresponds to 4096 frames.

[0128] Example 1: Multicast distribution of material parameter blocks and integral coefficient tables in a finite element scenario.

[0129] This embodiment uses the element integration and stiffness assembly process in the three-dimensional linear elastic finite element method as an example for illustration.

[0130] (1) Background of the finite element task.

[0131] 1. In large-scale finite element solutions, it is usually necessary to repeatedly perform shape function evaluation, Jacobian matrix calculation, integral point strain and stress calculation, and element stiffness or residual assembly on a large number of elements.

[0132] 2. For the implementation using grid-based parallel processing, the computation domain can be divided into multiple cell blocks, each of which is managed by one or more core clusters.

[0133] 3. In actual engineering models, multiple continuous element blocks often belong to the same material region, so they need to share the same material constitutive parameter block.

[0134] 4. At the same time, the shape function value table, shape function derivative table, Gaussian integral weight table, and coordinate mapping auxiliary coefficient table of higher-order units usually need to be accessed repeatedly by all active core clusters.

[0135] 5. Both types of data mentioned above are read-only shared inputs. The material parameter block is suitable for multicasting to a portion of the cluster, while the integral coefficient table is suitable for global broadcasting to the entire cluster.

[0136] (2) Unit block partitioning and logical computing cluster configuration. The three-dimensional finite element model to be solved is divided into 16 consecutive element blocks, denoted as ElemBlock_0 to ElemBlock_15. For ease of explanation, only the logical cluster configuration actually used in this embodiment is listed below: correspond ; correspond ; correspond ; correspond ; correspond ; correspond ; correspond .

[0137] in, Corresponding to ElemBlock_2 Local unit integration and assembly tasks in ElemBlock_7. Corresponding to one logical cluster, covering That is, simultaneous coverage These 6 consecutive unit blocks.

[0138] In this embodiment, Since they belong to the same material region, all six unit blocks need to access the same material parameter block MatParam_A within this load step. Because MatParam_A is read-only shared data and its contents are consistent across all six unit blocks, it is suitable to distribute it all at once using a logical cluster multicast method.

[0139] (3) Multicast transmission of material parameter blocks.

[0140] The MatParam_A may include elastic modulus tensor components, Poisson's ratio, density, coefficient of thermal expansion, piecewise linear constitutive interpolation points, yield criterion auxiliary parameters, or other material model constants.

[0141] Ccore determination Since MatParam_A is required for all data, a multicast transaction is initiated targeting ClusterID=12. Because each frame PAYLOAD in this embodiment is fixed at 256 bits (32 bytes), the 64KB MatParam_A is divided into 2048 transaction frames. The sequence number range for this round of transmission is set to... Before sending, Ccore writes 2048 frames sequentially. .

[0142] GDC decodes ClusterID=12: start = BASE

[12] = 32; end= BASE

[12] + COUNT

[12] - 1 = 127; start_ldr = 32>>4 = 2; end_ldr = 127>>4 = 7.

[0143] Because this range exactly covers the entire area. Therefore, the local mask of each LDR is all 1. For each frame, GDC simultaneously sends hit signals to LDR_2, LDR_3, LDR_4, LDR_5, LDR_6, and LDR_7. MatParam_A is sent to the following cores all at once: .

[0144] Each target calculation core first writes the received material parameter data into its local Shadow Buffer. After the CRC check (i.e., integrity check) is correct and the sequence number (SEQ) meets the sequential submission condition, it then writes the data into the formal material parameter cache or SRAM. Once all 2048 frames have been correctly submitted, The corresponding 6 physical computation clusters simultaneously obtain a consistent MatParam_A.

[0145] (4) Global broadcast of the integral coefficient table.

[0146] In addition to the material parameter blocks, the finite element solution also requires repeated access to shared integral data, such as the shape function value table, shape function derivative table, Gaussian point coordinates and weight table, and the mapping auxiliary coefficient table from reference elements to physical elements. In this embodiment, a preprocessed integral coefficient table, QuadCoeffTable, is assumed to be 32KB in size. This integral coefficient table needs to be used by all 16 physical computation clusters during the current solution phase.

[0147] Therefore, the control core Ccore uses a global broadcast method with TYPE=10 for it, instead of specifying a specific ClusterID.

[0148] The 32KB QuadCoeffTable is divided into 1024 transaction frames. The sequence number range for this round of transmission is set to... Before sending, Ccore writes 1024 frames sequentially. .

[0149] After the Global Distributor (GDC) recognizes TYPE=10, it processes all... A hit signal is emitted, and the local mask of each LDR is all 1s. Therefore, QuadCoeffTable is broadcast to [the relevant authority / organization] all at once. Each target core first writes its parameters to the local parameter Shadow Buffer. After the CRC check is successful and the SEQ meets the sequential submission conditions, it is submitted to the formal parameter cache or SRAM. At this point, all physical computing clusters have obtained the same integration coefficient table and can perform unit integration and assembly calculations in parallel on their respective unit blocks.

[0150] (5) The calculation and processing process of each cluster.

[0151] Taking ClusterID=6 as an example, this Cluster physically corresponds to It is responsible for the integration and stiffness assembly of the elements in ElemBlock_6. In the current load step, in addition to accessing the local node coordinate block, element connection relationship and state variables, the Cluster also reads the MatParam_A that has been multicast locally and the QuadCoeffTable that has been globally broadcast locally.

[0152] The 16 cores in this cluster can be divided into tasks according to a range of cell numbers, for example: core_96 -> Processing ElemBlock_6 Unit number; core_97->Processing ElemBlock_6 Unit number; core_98->Processing ElemBlock_6 Unit number; ... core_111 -> Processing ElemBlock_6 Unit number.

[0153] Each computational core reads the corresponding integration point data from the QuadCoeffTable and the corresponding material constants from MatParam_A for the set of elements it is responsible for, and performs strain matrix construction, stress calculation, and element stiffness or residual vector assembly. In this way, although multiple physical computation clusters process different element blocks, they can share the same material parameter block and the same integration coefficient table, without the sending end needing to repeatedly send data to each cluster.

[0154] Example 2: Distribution of model parameter blocks in deep learning scenarios.

[0155] This embodiment uses a Transformer language model as an example. This model is a large language model inference network with 24 Transformer blocks, 4096 hidden dimensions, and 32 attention heads. The following uses Layer 3 as an example to illustrate the two types of data that need to be efficiently distributed: shared parameter blocks and input activation blocks.

[0156] In this model, the query projection weight matrix of layer 3 is denoted as WQ_3, and its size is... Each element is represented using BF16 and occupies 2 bytes, therefore the entire WQ_3 is 32MB in size. To facilitate on-chip distribution and parallel consumption, WQ_3 is further divided into multiple... The weighted sub-blocks. Each sub-block is 128KB in size. WQ_3_blk0 specifically refers to the 0th element of the query projection weight matrix WQ_3 in the 3rd layer of the model. Segmentation.

[0157] Logical Computing Cluster Configuration: Assume the following cluster description table is pre-configured in GDC: ; ; ; ; ; ; ; .

[0158] Their meanings are as follows: correspond ; correspond ; correspond ; correspond ; correspond ; correspond ; correspond ; correspond .

[0159] Deep learning task division: In this example: Processing micro-batch MB0 ; Processing micro-batch MB1 ; Processing micro-batch MB2 ; Processing micro-batch MB3 ; Processing micro-batch MB4 ; Processing micro-batch MB5 .

[0160] The above 6 sets of computational cores perform attention calculations on the same Layer_3 layer, therefore they need to share the same query projection weight block WQ_3_blk0.

[0161] Transmission and processing of model parameter block WQ_3_blk0: Control core Ccore determination This parameter block is required for all of them, therefore select... This means that the sender only needs to initiate a single orientation. Multicast transactions within a logical cluster, rather than separate transactions for each cluster. , , , , and Six independent transactions were initiated in sequence.

[0162] The control core (Ccore) divides the 128KB parameter block into 4096 transaction frames, with sequence numbers ranging from... Each transaction frame carries the following information when written to the Replay Buffer [SEQ]: TYPE=01, ClusterID=12, Local_Index=0, RETRY=0, PAYLOAD[256bit], CRC.

[0163] GDC decodes ClusterID=12: start = BASE

[12] = 32; end = BASE

[12] + COUNT

[12] - 1 = 127; start_ldr = 32>>4 = 2; end_ldr = 127>>4 = 7.

[0164] Since start=32 and end=127 exactly cover the entire LDR_2 to LDR_7, the local mask for each LDR is: LDR_2 mask = 11111111111111111b; LDR_3 mask = 11111111111111111b; LDR_4 mask = 11111111111111111b; LDR_5 mask = 11111111111111111b; LDR_6 mask = 11111111111111111b; LDR_7 mask = 11111111111111111b.

[0165] After completing one decoding of Cluster_ID=12, the Global Distributor (GDC) determines that the logical cluster covers six physical slices from LDR_2 to LDR_7. Therefore, it simultaneously sends hit signals to LDR_2, LDR_3, LDR_4, LDR_5, LDR_6 and LDR_7 for the same transaction frame.

[0166] Each hit LDR is fanned out to its respective 16 cores using a local all-one mask. Upon receiving a frame, each target computing core first writes the PAYLOAD to the corresponding parameter buffer in its local Shadow Buffer. Each core then synchronously calculates the CRC for TYPE + ClusterID + Local_Index + SEQ + RETRY + PAYLOAD. When a frame's CRC check is correct and the SEQ meets the sequential submission requirements, the frame data is submitted from the Shadow Buffer to the formal parameter buffer or SRAM.

[0167] After all 4096 frames were submitted correctly All obtained a consistent WQ_3_blk0. Then, the six core groups executed the following respectively: MB0_Q = X_MB0 × WQ_3_blk0; MB1_Q = X_MB1 × WQ_3_blk0; MB2_Q = X_MB2 × WQ_3_blk0; MB3_Q = X_MB3 × WQ_3_blk0; MB4_Q = X_MB4 × WQ_3_blk0; MB5_Q = X_MB5 × WQ_3_blk0.

[0168] If, for example If CRC_MISMATCH is detected when receiving SEQ=1088, then core_91 reports it through its corresponding LDR_5: ERRTYPE=CRC_MISMATCH,SEQ=1088,LDR_ID=5.

[0169] After receiving the error message, the control core Ccore directly reads the original complete frame from the Replay Buffer

[1088] , sets RETRY to 1, and retransmits it. Other cores that have correctly submitted the frame will discard the retransmitted frame directly because they detect that seq == LAST_COMMITTED_SEQ and RETRY=1, and no duplicate submission will occur.

[0170] Transmission and processing of batch input activation block X_MB2_tile5: Besides sharing model parameters, some batch input blocks are also suitable for being delivered all at once via multicast to multiple cores that need to collaboratively process the input block. In this example, let the specific details of the activation block X_MB2_tile5 be as follows: X_MB2_tile5 is an input activation block of micro-batch MB2, with a size of 64KB.

[0171] Control core Ccore determination The input block needs to be consumed collaboratively, so ClusterID=13 is selected.

[0172] The control core Ccore divides the 64KB X_MB2_tile5 into 2048 frames, with the sequence number range set to... GDC decodes ClusterID=13: start = 50; end = 93; start_ldr = 50 >> 4 = 3; end_ldr = 93>>4 = 5; Since the start and end positions are not aligned with the LDR boundary, the local masks are as follows: LDR_3 mask = 1111111111111100b corresponds to ; LDR_4 mask = 1111111111111111b corresponds to ; LDR_5 mask = 0011111111111111b corresponds to ; The Global Distributor (GDC) sends each frame to LDR_3, LDR_4, and LDR_5 simultaneously. LDR_3 only opens its local memory. LDR_4 opens all 16 channels; LDR_5 opens .

[0173] Each target computation core first writes the PAYLOAD to the corresponding parameter buffer in its local Shadow Buffer, and synchronously calculates the CRC for TYPE + ClusterID + Local_Index + SEQ + RETRY + PAYLOAD. When the CRC check is correct and the SEQ meets the sequential submission requirements, the frame data is submitted from the Shadow Buffer to the formal parameter buffer or SRAM. Subsequently, Perform linear mapping, normalization, or attention preprocessing operations from Layer 3 on the input block. For example: : Processing the first of X_MB2_tile5 The work song block; : Processing the first of X_MB2_tile5 The work song block; : Processing the first of X_MB2_tile5 Work order blocks.

[0174] If core_87 detects SEQ_GAP, it only reports NACK for the SEQ corresponding to the missing frame, and the sending end retransmits according to the ReplayBuffer without having to reschedule the entire 64KB data block.

[0175] This invention is not limited to the specific embodiments described above. The invention extends to any new feature or combination disclosed in this specification, as well as any new method or process step or combination disclosed herein.

Claims

1. A multi-core chip data transmission method, characterized in that, The methods include: Obtain the transaction data to be transmitted; The transaction data is divided into at least one transaction frame according to the set frame size; Determine the logical address of the target computing core for each transaction frame; Map the logical address to the physical address of the target computing core; The logical address and the physical address are associated and mapped according to configurable information; The transaction frame is sent to the target computing core based on the physical address.

2. The multi-core chip data transmission method as described in claim 1, characterized in that, Mapping the logical address to the physical address of the target computing core includes: Based on the computation cluster identifier of the logical address, or based on the computation cluster identifier and the computation core index of the logical address, the slice identifier and port identifier of the target computation core are mapped; each computation cluster is mapped to at least one core slice, each core slice is fixedly connected to at least two computation cores, the core slice is located by the slice identifier, and the computation core is located within each core slice by the port identifier.

3. The multi-core chip data transmission method as described in claim 2, characterized in that, Based on the computation cluster identifier of the logical address, or based on the computation cluster identifier and computation core index of the logical address, map the slice identifier and port identifier of the target computation core, including: Calculate the global index of the target computing core based on the computing cluster identifier of the logical address, or based on the computing cluster identifier and computing core index of the logical address; Based on the global index, the slice identifier and port identifier of the target computing core are determined by the size of each core slice.

4. The multi-core chip data transmission method as described in any one of claims 1-3, characterized in that, Also includes: Each transaction frame is identified by a sequence number, which indicates that the target computing core will only allow the current transaction frame to be formally received if the sequence number of the current transaction frame is in a normal state.

5. The multi-core chip data transmission method as described in claim 4, characterized in that, Also includes: A second buffer is constructed for each computing core, and the second buffer includes a first partition and a second partition; The first partition stores transaction frames that are to be formally received, and the second partition stores transaction frames with abnormal sequence numbers.

6. The multi-core chip data transmission method as described in claim 2 or 3, characterized in that, Sending the transaction frame to the target computing core based on the physical address includes: Based on the slice identifier and port identifier, calculate the local mask of the corresponding core slice, whereby the local mask indicates the selected computing core; The transaction frame is sent to the selected computing core according to the local mask.

7. The multi-core chip data transmission method as described in any one of claims 1-3, characterized in that, The transaction frame is written to the first buffer; the method further includes: Upon receiving error feedback from the target computing core, the current transaction frame is sent first, and then the transaction frame that caused the error is read from the first buffer and resent. When a missing frame feedback is received from the target computing core, check whether the missing transaction frame has been retransmitted. If so, ignore the missing frame feedback; otherwise, read the missing transaction frame from the first buffer and retransmit it. The error feedback and / or missing frame feedback are provided through a reverse feedback network, which only provides feedback when an error or missing frame occurs.

8. The multi-core chip data transmission method as described in any one of claims 1-3, characterized in that, Also includes: Each transaction frame is identified by a verification identifier, which indicates the integrity verification information of each transaction frame. This means that the target computing core will only allow the current transaction frame to be formally received if the integrity verification of the current transaction frame based on the integrity verification information passes.

9. A multi-core chip data transmission system, characterized in that, include: The control core is configured to: acquire transaction data to be transmitted; The transaction data is divided into at least one transaction frame according to the set frame size; A global distributor is configured to: map the logical address of the target computing core to the physical address of the target computing core based on the determined logical address of each transaction frame; the logical address and the physical address are associated and mapped according to configurable information; A local dispatcher is configured to send the transaction frame to the target computing core based on the physical address.

10. An electronic device, characterized in that, include: Storage medium containing computer programs; A processor, connected to the storage medium, runs the computer program to perform the multi-core chip data transmission method as described in any one of claims 1-8.

Images