Data transmission method and device for bus protocol, electronic equipment and medium

Abstract

This disclosure provides a data transmission method, apparatus, electronic device, and medium for a bus protocol. The master device identifier is split, with the low-order bits used as the slave device identifier and the high-order bits stored in the corresponding preset storage unit, replacing a global queue. Each slave device identifier has independent space, and the high-order bits do not interfere with each other when multiple master devices use the same slave device identifier. During response, the corresponding storage unit is located based on the slave device identifier, and the high-order bits are popped sequentially, resolving ID confusion and untraceable responses. Each storage unit can hold multiple high-order bits, enabling multiple incomplete transactions to be concurrently executed for the same slave device identifier, improving the parallel performance of the master device. Whether it is a burst is determined based on the burst length; if so, it is split into multiple single-transmission transactions. The address is dynamically calculated based on the starting address, length, and data width, enabling slave devices that only support single-access to correctly respond to burst requests, saving storage resources, reducing idle periods, and improving pipeline efficiency.

Description

Technical Field

[0001] This disclosure relates to chip design technology, and in particular to a data transmission method and apparatus, electronic device and medium for a bus protocol. Background Technology

[0002] In SoC (System on Chip) design, high-performance master devices, such as CPUs (Central Processing Units), use the AXI4 (Advanced eXtensible Interface 4) protocol to support burst transfers (i.e., transferring multiple data items in a single address request). However, many simple slave devices, such as SRAM (Static Random-Access Memory) controllers and low-speed peripheral registers, only support single transfers (burst length = 0). Therefore, a burst-to-single transfer bridge is needed between the master and slave devices.

[0003] In related technologies, during the AXI4 burst-to-single bridging process, the master device identifier (corresponding to the master device ID below) has a larger bit width than the slave device identifier (corresponding to the slave device ID below), and existing bridges use a single global queue to store identifier information. This leads to a problem where, when multiple master devices concurrently access the same slave device identifier, the response result cannot correctly restore the complete master device identifier, resulting in master device identifier confusion. To avoid confusion, only forced serialization processing can be used, limiting the number of incomplete transactions under the same slave device identifier to 1, severely restricting the system's concurrency performance. Summary of the Invention

[0004] In view of the above-mentioned problems in related technologies, embodiments of this disclosure provide a data transmission method and apparatus, electronic device and medium for a bus protocol.

[0005] In a first aspect, this disclosure provides a data transmission method for a bus protocol, applied in a bridge connecting a master device and a slave device, the method comprising: In response to receiving a bus transaction request from the master device, the master device identifier is split to obtain a first wide part and a second wide part, so as to use the second wide part as a slave device identifier, and use the slave device identifier as an index to store the first wide part into a preset storage unit, wherein the bus transaction request includes the master device identifier, the starting address, the burst length and the transaction data; Determine whether the bus transaction request is a burst transaction based on the burst length; In response to the bus transaction request being a burst transaction, the bus transaction request is split into multiple single transmission transactions. Each single transmission transaction includes a slave device address and a data tick. The slave device address points to a storage unit inside the slave device and is calculated sequentially based on the starting address, the burst length, and the width of the corresponding tick data. Any one of the single transmission transactions is associated with the slave device identifier and sent to the slave device, so that the slave device can access the data ticks in the single transmission transaction according to the slave device address and return a response result.

[0006] As an optional embodiment, the method further includes: In response to the bus transaction request being a non-burst transaction, the transaction data and the starting address are used as the single transmission transaction. After associating the single transmission transaction with the slave device identifier, it is sent to the slave device indicated by the starting address, so that the slave device can access the single transmission transaction according to the starting address and return a response result.

[0007] As an optional embodiment, determining whether the bus transaction request is a burst transaction based on the burst length includes: Compare the burst length with a preset length value; In response to the burst length being the preset length value, the bus transaction request is determined to be a non-burst transaction; If the burst length is greater than the preset length value, the bus transaction request is determined to be a burst transaction.

[0008] As an optional embodiment, in response to the bus transaction request being a burst transaction, the bus transaction request is split into multiple single transmission transactions. Each single transmission transaction includes a slave device address and a data tick, wherein the slave device address is calculated sequentially based on the start address, the burst length, and the width of the corresponding tick data, and includes: The total number of data beats is determined based on the burst length, and the total number of data beats is equal to the burst length plus a preset value; Based on the total number of data ticks and the width of the tick data, the transaction data carried by the bus transaction request is split into multiple single transmission data, and one single transmission data corresponds to one data tick. For any data tick, the slave device address corresponding to the data tick is determined based on the starting address and the offset of the data tick, wherein the offset is equal to the product of the sequence number of the data tick and the width of the tick data; The slave device address corresponding to each data cycle is combined with the single transmission data of that data cycle to form a single single transmission transaction, thereby obtaining multiple single transmission transactions of the bus transaction request.

[0009] As an optional embodiment, the step of splitting the transaction data carried by the bus transaction request into multiple single transmission data according to the total number of data ticks and the width of the tick data, wherein one single transmission data corresponds to one data tick, includes: The length of each single data transmission is determined based on the width of the clock data; Based on the starting position of the bus transaction request, the bus transaction request is divided according to the length of each single data transmission to obtain a number of single data transmissions equal to the total number of data ticks; Establish a correspondence between the order of the segmentation and the sequence number of the data beats, so that the order of each single transmission data obtained from the segmentation corresponds to the sequence number of the data beats.

[0010] As an optional embodiment, for any given data tick, determining the slave device address corresponding to that data tick based on the starting address and the offset of that data tick, wherein the offset is equal to the product of the sequence number of the data tick and the width of the tick data, includes: For any given data tick, obtain the sequence number of that data tick in the bus transaction request; Multiply the sequence number by the width of the beat data to obtain the offset of the beat data; Add the starting address to the offset to obtain the slave device address corresponding to the data cycle.

[0011] As an optional embodiment, associating any one of the single transmission transactions with the slave device identifier and sending it to the slave device includes: Determine the type of the bus transaction request, which includes write transactions and read transactions; In response to the bus transaction request being a write transaction request, for any single transmission transaction, the slave device identifier is associated with the slave device address in the current single transmission transaction and sent on the write address channel, and the single transmission data in the single transmission transaction is sent on the write data channel; wherein, the write address channel and the write data channel are transmitted in parallel and independently. In response to the bus transaction request being a read transaction request, for any single transmission transaction, the slave device identifier and slave device address of the single transmission transaction are sequentially sent on the read address channel using a preset lead address sending method, and the read data for the single transmission transaction returned by the slave device is received through the read data channel; wherein, the preset lead address sending method includes: after sending the slave device address of the current single transmission transaction, before the corresponding read data returns from the read data channel, generating and temporarily storing the slave device address of the next single transmission transaction, and sending the temporarily stored next slave device address after the read data corresponding to the current single transmission transaction returns.

[0012] As an optional embodiment, associating any one of the single transmission transactions with the slave device identifier and sending it to the slave device further includes: In response to the bus transaction request being a write transaction request, before associating the slave device identifier with the slave device address in the current single transmission transaction on the write address channel and before sending the single transmission data in the single transmission transaction on the write data channel for any single transmission transaction: Compare the current value of the write transaction flow control counter corresponding to the slave device identifier with the first threshold; In response to the current value of the write transaction flow control counter being less than a first threshold, the write transaction request is received, and the write transaction flow control counter is incremented by 1; In response to the current value of the write transaction flow control counter being greater than or equal to a first threshold, the ready signal of the write address channel corresponding to the slave device identifier is kept low to prevent the master device from continuing to send write transaction requests; In response to the bus transaction request being a read transaction request, before sequentially sending the slave device identifier and slave device address of any single transmission transaction on the read address channel using a preset lead address sending method, and before receiving the read data for that single transmission transaction returned by the slave device through the read data channel: Compare the current value of the read transaction flow control counter corresponding to the slave device identifier with the second threshold; In response to the current value of the read transaction flow control counter being less than the second threshold, the read transaction request is received, and the read transaction flow control counter is incremented by 1; In response to the current value of the read transaction flow control counter being greater than or equal to the second threshold, the read address channel corresponding to the slave device identifier is kept at a low level to prevent the master device from continuing to send read transaction requests; In response to the slave device returning a write response result or a read response result for any single transmission transaction, the write transaction flow control counter or the read transaction flow control counter corresponding to that single transmission transaction is decremented by 1.

[0013] As an optional embodiment, the method further includes: In response to receiving a response result returned by the slave device for any of the single transmission transactions, based on the slave device identifier in the response result, one or more corresponding first-width portions are searched from the preset storage unit; The target first width portion is determined from one or more first width portions according to the storage order; The master device identifier is obtained by concatenating the first width portion of the target with the slave device identifier; The master device identifier and the response result are returned to the master device.

[0014] A second aspect of this disclosure provides a data transmission apparatus for a bus protocol, applied in a bridge connecting a master device and a slave device, the apparatus comprising: The identifier splitting module is used to split the master device identifier in response to receiving a bus transaction request from the master device to obtain a corresponding first bit width part and a second bit width part, so as to use the second bit width part as a slave device identifier, and use the slave device identifier as an index to store the first bit width part into a preset storage unit, wherein the bus transaction request includes the master device identifier, the starting address, the burst length and the transaction data. The request type determination module is used to determine whether the bus transaction request is a burst transaction based on the burst length. The request splitting module is used to split the bus transaction request into multiple single transmission transactions in response to the bus transaction request being a burst transaction. Each single transmission transaction includes a slave device address and a data tick, wherein the slave device address points to a storage unit inside the slave device and is calculated sequentially based on the starting address, the burst length, and the width of the corresponding tick data. The associated sending module is used to associate any one of the single transmission transactions with the slave device identifier and send it to the slave device, so that the slave device can access the data ticks in the single transmission transaction according to the slave device address and return a response result.

[0015] As an optional embodiment, the device further includes: The non-burst transaction processing module is used to respond to the bus transaction request as a non-burst transaction, using the transaction data and the starting address as the single transmission transaction, associating the single transmission transaction with the slave device identifier, and sending it to the slave device indicated by the starting address, so that the slave device can access the single transmission transaction according to the starting address and return a response result.

[0016] As an optional embodiment, the request type determination module includes: A burst length comparison unit is used to compare the burst length with a preset length value; The first determining unit is configured to determine that the bus transaction request is a non-burst transaction in response to the burst length being the preset length value; The second determining unit is configured to determine the bus transaction request as a burst transaction in response to the burst length being greater than the preset length value.

[0017] As an optional embodiment, the request splitting module includes: A beat count determination unit is used to determine the total number of data beats based on the burst length, wherein the total number of data beats is equal to the burst length plus a preset value; The transaction data splitting unit is used to split the transaction data carried by the bus transaction request into multiple single transmission data according to the total number of data ticks and the width of the tick data, with one single transmission data corresponding to one data tick; The slave device address determination unit is used to determine the slave device address corresponding to any data beat based on the starting address and the offset of the data beat, wherein the offset is equal to the product of the sequence number of the data beat and the width of the beat data. The data combination unit is used to combine the slave device address corresponding to each data cycle with the single transmission data of that data cycle to form a single single transmission transaction, so as to obtain multiple single transmission transactions of the bus transaction request.

[0018] As an optional embodiment, the transaction data splitting unit includes: The data length determination subunit is used to determine the length of each single data transmission based on the width of the clock data; A data segmentation unit is used to segment the bus transaction request according to the length of each single data transmission based on the starting position of the bus transaction request, so as to obtain a number of single data transmissions equal to the total number of data ticks. The sorting subunit is used to establish a correspondence between the order of the segmentation and the arrangement number of the data beat, so that the arrangement order of each single transmission data obtained by the segmentation corresponds to the arrangement number of the data beat.

[0019] As an optional embodiment, the slave device address determination unit includes: The first acquisition subunit is used to acquire the sequence number of the data cycle in the bus transaction request for any given data cycle. The offset calculation subunit is used to multiply the arrangement number by the width of the beat data to obtain the offset of the data beat; The address determination subunit is used to add the starting address to the offset to obtain the slave device address corresponding to the data cycle.

[0020] As an optional embodiment, the associated sending module includes: A request type determination unit is used to determine the type of the bus transaction request, wherein the type includes write transactions and read transactions; The first data transmission unit is configured to respond to the bus transaction request as a write transaction request, and for any single transmission transaction, associate and transmit the slave device identifier with the slave device address in the current single transmission transaction on the write address channel, and transmit the single transmission data in the single transmission transaction on the write data channel; wherein the write address channel and the write data channel are transmitted in parallel and independently. The second data transmission unit is configured to respond to the bus transaction request as a read transaction request, and for any given single transmission transaction, sequentially transmit the slave device identifier and slave device address of the single transmission transaction on the read address channel using a preset lead address transmission method, and receive the read data returned by the slave device for the single transmission transaction through the read data channel; wherein, the preset lead address transmission method includes: after transmitting the slave device address of the current single transmission transaction, before the corresponding read data returns from the read data channel, generating and temporarily storing the slave device address of the next single transmission transaction, and transmitting the temporarily stored next slave device address after the read data corresponding to the current single transmission transaction returns.

[0021] As an optional embodiment, the associated sending module further includes: A write transaction count comparison unit is used to compare the current value of the write transaction flow control counter corresponding to the slave device identifier with a first threshold. The first request receiving unit is configured to receive the write transaction request and increment the write transaction flow control counter by 1 in response to the current value of the write transaction flow control counter being less than a first threshold. The first reverse pressure unit is used to keep the ready signal of the write address channel corresponding to the slave device identifier at a low level in response to the current value of the write transaction flow control counter being greater than or equal to a first threshold, so as to prevent the master device from continuing to send write transaction requests. The read transaction count comparison unit is used to compare the current value of the read transaction flow control counter corresponding to the slave device identifier with a second threshold. The second request receiving unit is configured to receive the read transaction request and increment the read transaction flow control counter by 1 in response to the current value of the read transaction flow control counter being less than the second threshold. The second reverse pressure unit is used to keep the read address channel corresponding to the slave device identifier at a low level in response to the current value of the read transaction flow control counter being greater than or equal to the second threshold, so as to prevent the master device from continuing to send read transaction requests. The resource release unit is configured to decrement the write transaction flow control counter or the read transaction flow control counter corresponding to the single transmission transaction by 1 when the slave device returns a write response result or a read response result for any single transmission transaction.

[0022] As an optional embodiment, the device further includes: The high-order lookup module is used to, in response to receiving a response result returned by the slave device for any of the single transmission transactions, search for one or more corresponding first-order width portions from the preset storage unit based on the slave device identifier in the response result; The target high-order determination module is used to determine the first width portion of the target from the more than one first width portion according to the storage order; The identifier splicing module is used to splice the first wide portion of the target with the slave device identifier to obtain the master device identifier; The response return module is used to return the master device identifier and the response result to the master device.

[0023] A third aspect of this disclosure provides an electronic device, including: Memory, used to store computer program products; A processor for executing a computer program product stored in memory, wherein when the computer program product is executed, it implements the method of any of the first aspects described above.

[0024] A fourth aspect of this disclosure provides a computer-readable storage medium having computer program instructions stored thereon, which, when executed by a processor, implement the method of any one of the first aspects described above.

[0025] The fifth aspect of this disclosure provides a computer program product including computer program instructions that, when executed by a processor, implement any of the methods described in the first aspect above.

[0026] In this embodiment, after receiving a bus transaction request from a master device, the bridge splits the master device identifier, using the lower-order part as the slave device identifier and storing the higher-order part in a preset storage unit indexed by the slave device identifier. This distributed independent storage method replaces the traditional single global queue. Each slave device identifier has its own independent storage space, ensuring that even if multiple master devices use the same slave device identifier, their higher-order parts can be saved separately without interference. When a slave device returns a response, the bridge can accurately locate the corresponding storage unit based on the slave device identifier in the response and pop the higher-order part according to the storage order, thus completely solving the problems of ID confusion and untraceable responses during multi-master concurrency. Simultaneously, each storage unit can accommodate multiple higher-order parts, meaning that the same slave device identifier can simultaneously contain multiple incomplete transactions. This releases the Outstanding (i.e., the number of incomplete transactions) capability, which was originally forcibly limited to 1, into a configurable depth value, leveraging the parallel performance of the master devices and improving bus utilization. Furthermore, determining whether a transaction is a burst based on its burst length provides a basis for subsequent differentiated processing. When a burst transaction is identified, the bridge splits it into multiple single-transmission transactions. Each transaction contains a slave device address and a data tick. The slave device address is dynamically calculated sequentially based on the starting address, burst length, and tick data width. This splitting method allows slave devices that only support single access to correctly respond to burst requests, solving the fundamental problem of protocol mismatch. Furthermore, dynamic address calculation replaces pre-storing all addresses, saving storage resources. Address calculation and data splitting can be performed in parallel, reducing idle periods caused by addresses waiting for data or data waiting for addresses, thus improving pipeline efficiency. Finally, each single-transmission transaction is associated with a slave device identifier and sent to the slave device, enabling the slave device to perform access based on the address and return a response. This ensures that the slave device can correctly identify the transaction's ownership, forming a complete closed loop with the aforementioned ID splitting storage and recovery mechanism, guaranteeing data consistency and system reliability in multi-transaction concurrent scenarios. In summary, the embodiments of this disclosure solve the problems of ID confusion and outstanding limitation through core operations such as distributed ID mapping storage, burst length discrimination, dynamic address calculation and transaction splitting. At the same time, they achieve accurate conversion from burst to single, improving the bus transmission efficiency between high-performance master devices and simple slave devices in SoC.

[0027] The technical solutions of this disclosure will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0028] The accompanying drawings, which form part of this specification, illustrate embodiments of this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0029] This disclosure will become clearer with reference to the accompanying drawings and the following detailed description, wherein: Figure 1 This is an overall structural block diagram of an AXI4 burst-to-single bridge, which is an exemplary embodiment of this disclosure.

[0030] Figure 2 This is a schematic flowchart illustrating a data transmission method for a bus protocol, which is an exemplary embodiment of this disclosure.

[0031] Figure 3 This is a schematic diagram of a parameterizable distributed ID mapping FIFO array structure, which is an exemplary embodiment of the present disclosure.

[0032] Figure 4 This is a flowchart illustrating a data transmission method for a bus protocol, which is another exemplary embodiment of this disclosure.

[0033] Figure 5 This is a flowchart illustrating a data transmission method for a bus protocol, which is another exemplary embodiment of this disclosure.

[0034] Figure 6 This is a flowchart illustrating a data transmission method for a bus protocol, which is another exemplary embodiment of this disclosure.

[0035] Figure 7 This is a flowchart illustrating a data transmission method for a bus protocol, which is another exemplary embodiment of this disclosure.

[0036] Figure 8 This is a schematic diagram of the write channel state machine transition in an embodiment of this disclosure.

[0037] Figure 9 This is a schematic diagram of the read channel state machine transition in an embodiment of this disclosure.

[0038] Figure 10 This is a flowchart illustrating a data transmission method for a bus protocol, which is another exemplary embodiment of this disclosure.

[0039] Figure 11 This is a structural block diagram of a data transmission apparatus for a bus protocol, which is an exemplary embodiment of this disclosure.

[0040] Figure 12 This is a structural block diagram of an electronic device according to an exemplary embodiment of the present disclosure. Detailed Implementation

[0041] Various exemplary embodiments of the present disclosure will now be described in detail with reference to the accompanying drawings. It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of the present disclosure.

[0042] The following description of at least one exemplary embodiment is merely illustrative and is not intended to limit the scope of this disclosure or its application or use.

[0043] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and equipment should be considered part of the specification.

[0044] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0045] This disclosure can be applied to electronic devices such as computer systems / servers, which can operate with a wide range of other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations suitable for use with electronic devices such as computer systems / servers include, but are not limited to: personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments including any of the above systems, etc.

[0046] Electronic devices such as computer systems / servers can be described in the general context of computer-executable instructions (such as program modules) executed by the computer system. Typically, program modules can include routines, programs, object programs, components, logic, data structures, etc., which perform specific tasks or implement specific abstract data types. Computer systems / servers can be implemented in distributed cloud computing environments, where tasks are performed by remote processing devices linked through communication networks. In distributed cloud computing environments, program modules can reside on local or remote computing system storage media, including storage devices.

[0047] In order to accurately describe the technical content in this disclosure, and to accurately understand the embodiments of this disclosure, the terms used in the embodiments of this disclosure are explained or defined as follows: AXI4 (Advanced eXtensible Interface 4): The fourth-generation advanced eXtensible interface protocol in the AMBA bus specification introduced by ARM, which supports burst transmission, independent address / data channels, and multiple ID concurrency.

[0048] Master Device: A bus interface module that conforms to the AXI4 bus protocol and is capable of initiating burst transfers, such as a CPU or DMA controller.

[0049] Slave Device: A bus interface module that only supports single transmissions (burst length AxLEN=0), such as a simple SRAM controller, a low-speed peripheral register interface, etc.

[0050] Bridge: A logical module connecting the master device interface and the slave device interface, used to convert AXI4 burst transmissions initiated by the master device into single transmissions that the slave device can accept.

[0051] Burst Transfer: A transmission method in the AXI4 protocol that transmits multiple data ticks consecutively after a single address handshake. The burst length is determined by the AxLEN signal, and the actual number of data ticks = AxLEN + 1.

[0052] Single Transfer: A transfer with a burst length of zero (AxLEN=0), containing only one data clock cycle. Some slave devices only support this type of transfer.

[0053] A data beat is an independent unit of data transmission within a burst. A burst contains multiple data beats, each corresponding to a single data value.

[0054] Burst Length: The value of the AxLEN signal in the AXI4 protocol. The actual number of data ticks = burst length + 1. When the burst length = 0, it indicates a single transmission.

[0055] Master ID (also known as Master Device ID): A complete ID signal issued by the master device (e.g., m_awid or m_arid), with a bit width of M_ID_WIDTH. This identifier is used to distinguish between different master devices or different transactions on the same master device.

[0056] Slave ID (also known as slave device ID): The ID signal (e.g., s_awid or s_arid) sent by the bridge to the slave device, with a bit width of S_ID_WIDTH (usually less than M_ID_WIDTH). Its value is, for example, equal to the lower S_ID_WIDTH bits of the master device ID.

[0057] High-order and low-order portions: The master device identifier is split according to its bit width: the lower S_ID_WIDTH bits are called the low-order portion (i.e., the slave device identifier), and the remaining high-order bits (M_ID_WIDTH - S_ID_WIDTH bits) are called the high-order portion. The high-order portion can be stored in a preset storage unit for later recovery of the complete master device identifier.

[0058] Predefined Storage Unit: An internal storage structure (e.g., FIFO) within the bridge, independently configured for each possible slave device identifier, used to sequentially store the high-order bits corresponding to that slave device identifier. Each storage unit can store multiple high-order bits, and its depth can be parameterized.

[0059] Slave Address: The physical address pointing to the internal storage unit or register of the slave device. The bridge dynamically calculates the slave address for each single transmission transaction based on the starting address, burst length, data width, and burst type sent by the master device.

[0060] Write Transaction: A write operation in the AXI4 protocol uses the write address channel (AW) and the write data channel (W), and the slave device returns a response through the write response channel (B).

[0061] Read Transaction: A read operation in the AXI4 protocol uses the read address channel (AR) to send the address, and the slave device returns the read data through the read data channel (R).

[0062] Write Address Channel / Write Data Channel / Read Address Channel / Read Data Channel: Independent data transmission channels in the AXI4 protocol. The Write Address Channel (AW) is used to transmit write address and write control signals; the Write Data Channel (W) is used to transmit write data; the Read Address Channel (AR) is used to transmit read address and read control signals; and the Read Data Channel (R) is used to transmit read data and responses.

[0063] Ready Signal: A handshake instruction in the AXI4 protocol. The receiver pulls the ready signal low to indicate that it cannot receive data, thus putting pressure on the sender. Examples include m_awready and m_arready.

[0064] Flow Control Counter: An independently configured counter for each slave device ID, used to record the number of currently incomplete transactions under that slave device ID. Write transactions and read transactions are configured with independent flow control counters, and have a configurable maximum threshold for the number of incomplete transactions (i.e., outstanding capability).

[0065] Look-ahead Address Transmission: A pipelined processing method in read transactions. After sending the slave device address for the current single-transmission transaction, and before the corresponding read data returns, the slave device address for the next single-transmission transaction is generated and temporarily stored. This stored address is then sent only after the current read data returns. In this scheme, only one address is sent in advance.

[0066] Bypass Mode: This is a working mode that the bridge automatically enters when a burst length of zero is detected. In this mode, except for the ID signal which still goes through distributed storage mapping, the address, data, and response channel signals are directly bypassed from the master device to the slave device without going through the state machine, achieving zero-latency forwarding.

[0067] The technical solutions involved in the embodiments of this disclosure will be described in detail below.

[0068] Figure 1 This is an overall structural block diagram of an AXI4 burst-to-single bridge, which is an exemplary embodiment of this disclosure. Figure 1 As shown, the AXI4 burst-to-single bridge disclosed herein connects the AXI4 master device interface to the slave device interface, which only supports single transmissions. The internal structure of the bridge is designed according to the principle of separate read / write channels, including: Write Channel State Machine and Datapath, Read Channel State Machine and Datapath, Distributed ID Mapping FIFO Array, Per-ID Outstanding Control Counters, Address Generation / Read Address Generation logic, and Direct Path Selection module.

[0069] Write Channel Section: After the write address channel (AW) and write data channel (W) enter the bridge, they first pass through the direct path selection module. When the write burst length AxLEN from the master device is detected to be 0, the bridge automatically selects a direct path, bypassing the master device's write address, write data, and response signal directly to the slave device side without state machine processing. When AxLEN > 0, the bridge enters the normal splitting path: the write channel state machine controls the write address generation logic, splitting a write burst from the master device into multiple single write transmissions, sequentially generating the slave device address (s_awaddr) and forwarding the write data (s_wdata). Simultaneously, the write channel's ID mapping unit extracts the low-order bits from the master device ID as the slave device ID (s_awid) and stores the high-order bits in the distributed FIFO array corresponding to that slave device ID. The write channel's independent Outstanding counter tracks the number of currently incomplete write transactions for each slave device ID. When a preset threshold is reached, it pulls m_awready low to apply back pressure to the master device.

[0070] The read channel section: The structure of the read address channel (AR) and read data channel (R) is symmetrical to that of the write channel. In pass-through mode, the master device's read address is directly bypassed to the slave device, while the ID still follows the mapping logic. In normal split mode, the read channel state machine controls the read address generation logic, supporting lead address sending (leading by only one address at a time), generating and temporarily storing the next address before the read data returns. The read ID mapping unit also uses the low-order bits of the master device ID as the slave device ID (s_arid), and stores the high-order bits in the read ID FIFO. The independent Outstanding counter of the read channel controls the number of concurrent read transactions.

[0071] Distributed ID Mapping FIFO Array: This array consists of a write ID FIFO group and a read ID FIFO group, with each possible slave device ID corresponding to an independent FIFO. Each FIFO stores the high-order bits of all concurrent transactions under that slave device ID in a first-in, first-out (FIFO) order. When the slave device returns a response (write response s_bid or read data s_rid), the bridge uses the slave device ID in the response as an index to pop the earliest stored high-order bit from the corresponding FIFO, concatenates it with the slave device ID, and restores the complete master device ID (m_bid or m_rid) to be returned to the master device.

[0072] Independent Outstanding Control Counters per ID: Independent write transaction counters and read transaction counters are set for each slave device ID. The maximum value of the counters can be parameterized (PER_ID_WR_OUTSTAND, PER_ID_RD_OUTSTAND). This module checks the counters when a transaction is initiated. If the counters are not full, a handshake is allowed and the counter is incremented by 1; otherwise, backpressure is applied to the master device. When a response is received from the slave device, the counter is decremented by 1, releasing resources.

[0073] Straight-through path selection module: Located at the front end of each channel, it detects the AxLEN signal in real time through combinational logic. When AxLEN=0 is detected, the selector switches to allow address, data, and response signals to bypass the state machine, address generator, and FIFO array, and be directly transmitted between the master and slave devices; however, ID mapping is still completed through a distributed FIFO to ensure correct ID recovery.

[0074] The steps of the method are described in detail below with reference to specific embodiments.

[0075] Figure 2 This is a schematic flowchart illustrating a data transmission method for a bus protocol, as shown in an exemplary embodiment of this disclosure. Figure 2 As shown, a data transmission method for a bus protocol, applied in a bridge connecting a master device and a slave device, may include the following steps: Step 110: In response to receiving a bus transaction request from the master device, the master device identifier is split to obtain the corresponding first wide part and second wide part. The second wide part is used as the slave device identifier, and the first wide part is stored in a preset storage unit using the slave device identifier as an index. The bus transaction request includes the master device identifier, the starting address, the burst length, and the transaction data.

[0076] In step 110, the bridge receives a bus transaction request from the master device and preprocesses it. The master device is a module that conforms to the AXI4 (Advanced eXtensible Interface 4) bus protocol and is capable of initiating burst transfers, such as a Central Processing Unit (CPU) or a Direct Memory Access (DMA) controller. The bus transaction request issued by the master device can be a write transaction or a read transaction. Each bus transaction request includes at least the master device identifier (i.e., Master ID, whose bit width identifier is, for example, M_ID_WIDTH), the starting address, the burst length (AxLEN), and the transaction data (for a write transaction, the sequence of data to be written; for a read transaction, the request itself does not carry data but the data must be returned by the slave device later).

[0077] In this embodiment, the bridge performs a splitting process on the master device identifier. Specifically, the bridge extracts the second bit width portion of the master device identifier (e.g., the lower S_ID_WIDTH bits) as the slave device identifier (i.e., Slave ID), which can be directly sent to the slave device for transaction identification and response routing. The remaining first bit width portion (e.g., the high-order bits, which can be represented as M_ID_WIDTH - S_ID_WIDTH bits) is stored as information that needs to be temporarily stored, indexed by the slave device identifier, in a preset storage unit corresponding to that slave device identifier. The preset storage unit can be a storage structure (e.g., a first-in-first-out queue, FIFO) independently configured within the bridge for each possible slave device identifier. Each storage unit can sequentially store multiple high-order bits, and its depth can be configured by the parameter PER_ID_FIFO_DEEP.

[0078] As an example, the pre-defined storage unit can be implemented in various hardware ways. For instance, a globally shared memory (such as a single RAM block, managing storage areas for different slave device identifiers via address pointers) can be used. This approach offers high resource utilization but complex control logic. Alternatively, a register set (one register for each slave device identifier) ​​can be employed, which is simple to implement but only supports storage at a depth of 1, failing to unlock outstanding capabilities. A linked-list cache can also be used, offering flexible storage allocation but incurring significant overhead. Designers can choose the appropriate implementation scheme based on the system's requirements for concurrency, resource consumption, and latency.

[0079] In a preferred embodiment of this disclosure, the preset storage unit may be a distributed ID mapping FIFO array. For example... Figure 3 As shown, this array sets up an independent First-In-First-Out (FIFO) queue for each possible slave device identifier, and the depth of each FIFO is parameterizable (parameter PER_ID_FIFO_DEEP). This structure not only stores multiple high-order bits sequentially, achieving independent caching at the slave device identifier level, but also ensures the consistency of the high-order bits with the response order through the FIFO's FIFO characteristic, thereby completely solving the ID confusion problem and unlocking Outstanding capabilities. The following section combines... Figure 3 The specific structure and operation of the distributed ID mapping FIFO array are described in detail.

[0080] Figure 3 This is a schematic diagram of a parameterizable distributed ID mapping FIFO array structure, which is an exemplary embodiment of this disclosure. Figure 3 As shown, the array consists of multiple independent First-In-First-Out (FIFO) queues, the number of which can be equal to the number of possible slave device identifiers, i.e., 2 to the power of S_ID_WIDTH. Each FIFO corresponds to a slave device identifier, where the slave device identifier takes values ​​from 0 to 2^S_ID_WIDTH-1, and its depth is parameterizable (parameter PER_ID_FIFO_DEEP), used to store multiple high-order bits corresponding to that slave device identifier.

[0081] Specifically, when the master device initiates a write or read transaction, the bridge splits the complete master device identifier (width M_ID_WIDTH, i.e., M bits) into a low-order part (low S bits, i.e., the slave device identifier) ​​and a high-order part (high MS bits). The low-order part serves as an index, and the corresponding FIFO is selected by the selector; the high-order part is then written into that FIFO, stored in the order of writing. When the slave device returns a response (write response or read data), the response carries the slave device identifier. The bridge uses this slave device identifier as an index to select the same FIFO again by the selector, and pops a high-order part (i.e., the earliest stored high-order data) from it in a first-in-first-out order. Subsequently, the splicer concatenates the popped high-order part with the slave device identifier in the current response to recover the complete master device identifier (i.e., the original master device identifier, width M_ID_WIDTH, i.e., M bits), and returns this recovered master device identifier to the master device along with the response.

[0082] pass Figure 3 The structure shown features an independent FIFO for each slave device identifier, ensuring complete isolation between transactions of different slave device identifiers and resolving ID confusion issues caused by global queues. Simultaneously, each FIFO can store multiple high-order bits (depth N), allowing the same slave device identifier to support multiple incomplete transactions, releasing limited outstanding capabilities and fully leveraging the master device's concurrency performance. This structure employs a fully parameterized design. Specifically, the number of FIFOs is determined by the bit width S_ID_WIDTH of the slave device identifier (specifically, 2 to the power of S_ID_WIDTH), the depth of each FIFO is configured by the parameter PER_ID_FIFO_DEEP, and the bit width of each FIFO is equal to the bit width of the high-order bits of the master device identifier (i.e., M_ID_WIDTH minus S_ID_WIDTH). By adjusting these parameters, it can flexibly adapt to master and slave devices with different bit widths, greatly improving IP reusability.

[0083] For example, suppose the master device identifier is 12 bits wide and the slave device identifier is 4 bits wide. Master device A initiates a write burst, and its complete master device identifier is 12'hABC (hexadecimal representation). The bridge uses its lower 4 bits (4'hC) as the slave device identifier and stores the higher 8 bits (8'hAB) in a write identifier (ID) first-in-first-out (FIFO) queue indexed by the slave device identifier 4'hC. Subsequently, another master device B uses the same slave device identifier 4'hC (its complete master device identifier is 12'hDEC), and its higher 8'hDE bits will be stored in the same FIFO queue, after 8'hAB. In this way, even if multiple master devices use the same slave device identifier, their higher-order parts are stored separately in independent FIFO queues for their corresponding sub-identifiers, without interference.

[0084] This embodiment solves the ID confusion problem caused by global queues by setting up an independent storage unit for each slave device ID. Specifically, upon response, the bridge only needs to index the dedicated FIFO queue based on the sub-ID in the response, pop the high-order bits in storage order, and accurately recover the complete master device ID. Secondly, each storage unit can store multiple high-order bits (depth N), allowing each sub-ID to have N incomplete transactions simultaneously. The master device does not need to wait for the previous transaction to complete before sending the next one, thus releasing the previously limited incomplete transaction capability (Outstanding capability) to N, improving bus utilization and system throughput. Furthermore, even if different master devices use the same sub-ID, system behavior remains predictable and reliable. Finally, by parameterizing the master-slave ID width, number of storage units, and depth, it can flexibly adapt to different System-on-Chip (SoC) designs, exhibiting good IP reusability.

[0085] Step 120: Determine whether the bus transaction request is a burst transaction based on the burst length.

[0086] In this step, the bridge determines the type of the received bus transaction request, that is, whether it is a burst transaction or a non-burst transaction. The basis for this determination includes, but is not limited to, parsing the burst length signal (AxLEN) in the AXI4 protocol, the transaction type label, or auxiliary information from the address channel.

[0087] This step enables the bridge to quickly and accurately identify the type of transaction request, allowing it to adopt the optimal processing strategy for both bursty and non-burst transactions. For example, bursty transactions are split into smaller parts, while single-transmission transactions are passed through to achieve zero-latency forwarding, thereby improving overall processing efficiency.

[0088] Step 130: In response to the bus transaction request being a burst transaction, the bus transaction request is split into multiple single transmission transactions. Each single transmission transaction includes a slave device address and a data tick. The slave device address points to the storage unit inside the slave device and is calculated sequentially based on the starting address, burst length, and width of the corresponding tick data.

[0089] When a bus transaction request is determined to be a burst transaction (e.g., burst length AxLEN ≥ 1), in this step, the burst transaction is split into multiple single-transmission transactions. Each single-transmission transaction may include a slave device address and a data tick, where the slave device address points to a memory unit (e.g., a register or static random access memory (SRAM) unit) inside the slave device, specifying the specific location of this single access.

[0090] Specific implementations of breaking down this bursty transaction into multiple single-transmission transactions include, but are not limited to: As one embodiment, after receiving a complete burst transaction, all slave device addresses are pre-calculated based on the starting address, burst length, data width, and burst type, and then combined with the corresponding data clock cycles and sent out one by one.

[0091] As another embodiment, the bridge calculates the address and sends it at the same time, without having to pre-store all the addresses, which can reduce storage overhead; another approach is based on state machine-based pipelined decomposition, for example, in the write channel, address sending and data forwarding are performed in parallel and independently, and the read channel supports advance address sending, so that subsequent addresses can be sent in advance before the current data has been returned, thereby hiding access latency.

[0092] The generation methods of device addresses include, but are not limited to: for example, they can be calculated sequentially according to modes such as fixed increment (INCR), loopback (WRAP), or fixed address (FIXED) based on the starting address, burst length, and data width of each tick (indicated by the AxSIZE signal) provided by the master device; or the entire address sequence can be pre-cached, or dynamically generated through an independent state machine.

[0093] All of the above-mentioned splitting methods can achieve the transition from burst to single-time, and the corresponding implementation method can be selected according to factors such as resource consumption, latency requirements, and system pipeline depth.

[0094] Taking a write transaction as an example (refer to Example 3 in the detailed implementation below): The master device initiates an 8-beat incremental write burst, starting at address 0x1000, with each beat having a data width of 4 bytes. The bridge sequentially calculates 8 slave device addresses: 0x1000, 0x1004, 0x1008...0x101C, and splits the master device's write data sequence into 8 independent single-transmission data segments according to the beat. Each address and its corresponding single-beat data are combined into a single-transmission transaction. For read transactions, the bridge also calculates addresses according to the data beat, but the data return direction is reversed.

[0095] By breaking down bursts into multiple single transmissions, simple slave devices that originally did not support bursts can now access the network normally, resolving the protocol incompatibility issue. Compatibility with multiple address calculation modes (incrementing, fixed, and loopback) enhances the bridge's versatility, making it suitable for different types of slave device access needs.

[0096] Step 140: Associate any single transmission transaction with the slave device identifier and send it to the slave device, so that the slave device can access the data ticks in the single transmission transaction according to the slave device address and return a response result.

[0097] In this step, each individual transmission transaction is associated with its corresponding slave device identifier and sent to the slave device. This enables the slave device to perform access operations on the corresponding data tick based on its address and return a response. The core of this step is to correctly transmit the split individual access requests to the slave device and ensure that the slave device can recognize the identifier and address corresponding to the request.

[0098] In this embodiment of the disclosure, according to the channel structure of the AXI4 protocol, the transmission of a single transaction can be implemented in several ways: One implementation method is sequential serial transmission. Specifically, the address and identifier are sent first, followed by the data (write transaction), or the address is sent first and then the data is received (read transaction). This method is simple to implement but inefficient.

[0099] As another implementation method, parallel transmission via independent channels can be used. Taking advantage of the inherent separation between the AXI4 read / write address channels and data channels, the address (including the slave device identifier) ​​and data are transmitted simultaneously through different channels. In write transactions, address and data transmission can overlap, while in read transactions, address transmission and data reception are decoupled.

[0100] Another implementation approach is pipelined transmission. While sending the current transaction, the address or data of the next transaction is pre-fetched or pre-calculated, thus hiding transmission latency. Furthermore, for read transactions, a lead address transmission strategy can be used, where the next read address is sent before the current read data has been returned, allowing the slave device to prepare data in advance and reducing the master device's waiting time.

[0101] This embodiment enables the slave device to correctly receive and execute a single transmission transaction. By associating the address, identifier, and data, the slave device can accurately identify the access target and the transaction it belongs to. Since each single transmission transaction carries the slave device identifier, and the response returned by the slave device also includes this identifier, the bridge can accurately associate the response with the original master device, ensuring correctness when multiple transactions are concurrent.

[0102] Figure 4 This is a flowchart illustrating a data transmission method for a bus protocol, as shown in another exemplary embodiment of this disclosure. Figure 4 As shown, in Figure 2 Based on the illustrated embodiments, the data transmission method for a bus protocol provided in this disclosure may further include the following steps: Step 110: In response to receiving a bus transaction request from the master device, the master device identifier is split to obtain the corresponding first wide part and second wide part. The second wide part is used as the slave device identifier, and the first wide part is stored in a preset storage unit using the slave device identifier as an index. The bus transaction request includes the master device identifier, the starting address, the burst length, and the transaction data.

[0103] See details Figure 2 For the sake of brevity, the relevant descriptions in the illustrated embodiments will not be repeated here.

[0104] Step 120: Determine whether the bus transaction request is a burst transaction based on the burst length.

[0105] See details Figure 2 For the sake of brevity, the relevant descriptions in the illustrated embodiments will not be repeated here.

[0106] Step 130: In response to the bus transaction request being a burst transaction, the bus transaction request is split into multiple single transmission transactions. Each single transmission transaction includes a slave device address and a data tick. The slave device address points to the storage unit inside the slave device and is calculated sequentially based on the starting address, burst length, and width of the corresponding tick data.

[0107] See details Figure 2 For the sake of brevity, the relevant descriptions in the illustrated embodiments will not be repeated here.

[0108] Step 140: Associate any single transmission transaction with the slave device identifier and send it to the slave device, so that the slave device can access the data ticks in the single transmission transaction according to the slave device address and return a response result.

[0109] See details Figure 2 For the sake of brevity, the relevant descriptions in the illustrated embodiments will not be repeated here.

[0110] Step 150: In response to the bus transaction request being a non-burst transaction, the transaction data and the starting address are used as the single transmission transaction. After associating the single transmission transaction with the slave device identifier, it is sent to the slave device indicated by the starting address, so that the slave device can access the single transmission transaction according to the starting address and return a response result.

[0111] If step 120 determines that the bus transaction request is a non-burst transaction, step 150 directly forwards the single transmission. Unlike burst transactions, which require splitting, non-burst transactions are already single transmissions and do not require address calculation or burst splitting. Therefore, the bridge directly uses the starting address and transaction data from the received bus transaction request as the content of the single transmission transaction, associates it with the slave device identifier obtained in step 110, and sends it to the slave device indicated by the starting address. The slave device performs access to the single transmission transaction based on the starting address (write operations write data to this address, read operations read data from this address) and returns a response result (write response or read data).

[0112] As one implementation approach, for non-burst transactions (e.g., AxLEN=0), the same state machine process as for bursty transactions is still followed, but without the need for multiple iterations. This approach is simple to implement but introduces unnecessary state transition delays.

[0113] As another implementation method, a bypass mode can be adopted. Specifically, for example, after detecting AxLEN=0, the bridge automatically bypasses the state machine, address generator, and clock counter by directly connecting the address, data, and response channel signals from the master device to the slave device.

[0114] As another implementation, a combinational logic fast path can be used. Specifically, combinational logic completes the forwarding of address and data within half a clock cycle, further reducing latency. A preferred embodiment of this disclosure can employ a pass-through mode, where combinational logic combined with burst / single read / write completion signals achieves dynamic switching without the need for idle cycles.

[0115] For example, suppose the master device initiates a single write request, AxLEN=0, starting address 0x2000, write data 0x12345678, and the master device identifier is 12'hABC. The bridge determines this is a non-burst transaction and associates the slave device identifier 4'hC with address 0x2000 (the slave device identifier comes from the splitting of the master device identifier 12'hABC, with the high-order 8'hAB stored in the corresponding FIFO). Simultaneously, it sends the write data 0x12345678 and the address in parallel to the slave device, bypassing address calculation and the burst splitting state machine. Upon receiving this, the slave device writes data at address 0x2000 and returns a write response. Upon receiving the response, the bridge pops the high-order 8'hAB from the corresponding FIFO based on the slave device identifier (4'hC) in the response, concatenates them to form 12'hABC, and returns it to the master device. For single read requests, the process is similar: after sending the address and identifier, the slave device returns the read data, and the bridge similarly completes ID recovery.

[0116] Thus, by achieving zero-latency forwarding for a single transmission in this embodiment, the unnecessary delay caused by the complete splitting logic still being used even when AxLEN=0 in the prior art (corresponding to defect 4 in the background art) is avoided. Through the pass-through mode, the address, data, and response channels bypass the state machine and address generator; only the combinational logic selector delay exists on the signal path, thereby minimizing transmission latency and fully utilizing the outstanding capabilities of the slave device itself. Furthermore, the switching between pass-through and non-pass-through modes is automatically completed by hardware without software intervention, and the switching process does not introduce additional idle cycles, maintaining the continuity of the bus pipeline.

[0117] Figure 5 This is a flowchart illustrating a data transmission method for a bus protocol, as shown in another exemplary embodiment of this disclosure. Figure 5 As shown in the figure, a data transmission method for a bus protocol according to an embodiment of this disclosure may further include the following steps: Step 121: Compare the burst length with the preset length value.

[0118] The bridge extracts the burst length signal (AxLEN, an 8-bit binary number according to the AXI4 protocol) from the bus transaction request. Simultaneously, the bridge internally presets a length threshold to distinguish between single transmissions and burst transmissions. The burst length is, for example, the number of data ticks = AxLEN + 1. Therefore, when AxLEN = 0, the number of data ticks is 1, indicating a single transmission; when AxLEN ≥ 1, the number of data ticks ≥ 2, indicating a burst transmission. Based on this, in this embodiment, the preset length value can be set to 0. The bridge compares the received burst length with this preset length value to determine their relative magnitudes.

[0119] Step 122: In response to the burst length being a preset length value, determine that the bus transaction request is a non-burst transaction.

[0120] If the comparison result in step 121 is that the burst length is equal to the preset length value (i.e., AxLEN=0), then the current bus transaction request can be determined to be a non-burst transaction. It can be determined that the bus transaction request contains only one data tick and does not need to be burst-broken. It will then enter the pass-through mode (step 150) for processing.

[0121] Step 123: In response to the burst length being greater than the preset length value, the bus transaction request is determined to be a burst transaction.

[0122] When the comparison result in step 121 is that the burst length is greater than the preset length value (i.e., AxLEN ≥ 1), it can be determined that the current bus transaction request is a burst transaction. Therefore, it can be determined that the bus transaction request includes two or more data ticks, requiring burst splitting, address calculation, and pipelined processing. The subsequent steps 130 and 140 will then proceed to the splitting and transmission process.

[0123] For example, when the master device initiates a write operation, its burst length signal AxLEN = 0. The bridge extracts this value and compares it with the preset value of 0, finding that they are equal. Based on this, the bridge determines that the transaction is a non-burst transaction. Subsequently, the bridge skips the burst decomposition logic and directly enters the pass-through mode: it associates the starting address, write data, and slave device identifier and sends them to the slave device, which completes the single write and returns a response. Furthermore, when the master device initiates a read operation, its burst length signal AxLEN = 7 (indicating an 8-buzz burst). The bridge extracts this value and compares it with 0, finding that 7 > 0. Based on this, the bridge determines that the transaction is a burst transaction. Subsequently, the bridge enters the burst processing flow: it decomposes the burst into 8 single read transactions, calculates the slave device address for each buzzer, and sends them sequentially using a lead-ahead address sending method, while simultaneously completing ID mapping and flow control.

[0124] By comparing the burst length with a preset length value (e.g., 0), the AXI4 transaction type is quickly and accurately identified, providing a reliable basis for subsequent selection of pass-through or split-through modes. This comparison logic requires only one comparator, resulting in minimal hardware overhead. The judgment can be completed within the same cycle of receiving the address channel signal, without introducing additional latency, thus ensuring overall pipeline efficiency. Furthermore, this judgment method fully complies with the definition of AxLEN in the AXI4 protocol (data tick count = AxLEN + 1), ensuring complete compatibility with the existing ecosystem without requiring modification to the master or slave devices. Through parameterized design of the preset length value, such as configuring it to any value according to different bus standards, the bridge possesses excellent flexibility and scalability. This embodiment is a prerequisite for automatic switching between pass-through and burst / split-through modes. By timely identifying single transmissions and bypassing complex split-through state machines, zero-latency forwarding is achieved, while ensuring that burst transactions correctly enter pipeline split-through processing, thus balancing low latency and high throughput in mixed transmission scenarios.

[0125] Figure 6 This is a flowchart illustrating a data transmission method for a bus protocol, as shown in another exemplary embodiment of this disclosure. Figure 6 As shown in the figure, a data transmission method for a bus protocol according to an embodiment of this disclosure may further include the following steps: Step 131: Determine the total number of data beats based on the burst length, where the total number of data beats is equal to the burst length plus a preset value.

[0126] In this step, the burst length signal (AxLEN) sent by the master device can be parsed. For example, the burst length (AxLEN) can be an 8-bit signal, then the total number of data ticks = AxLEN + 1. The preset value is, for example, 1. For instance, if the master device sets AxLEN = 7, the total number of data ticks is 8; if AxLEN = 1, the total number is 2; if AxLEN = 0 (single transmission), the total number is 1 (but step 130 only applies to burst transactions, so AxLEN ≥ 1). This step clarifies the number of single transmission transactions that need to be split, providing a quantitative basis for subsequent data splitting and address calculation.

[0127] Step 132: Based on the total number of data ticks and the width of the tick data, the transaction data carried by the bus transaction request is split into multiple single transmission data, where one single transmission data corresponds to one data tick.

[0128] After obtaining the total number of data ticks, the continuous transaction data (write data sequence) carried in the master device write transaction can be split into multiple independent single transmission data. The splitting is based on, for example, two parameters: the total number of data ticks and the width of the tick data. One implementation involves determining the length of each single transmission data based on the width of the tick data. Then, based on the starting position of the bus transaction request, the bus transaction request is divided according to the length of each single transmission data, resulting in a number of single transmission data equal to the total number of data ticks. The order of the splitting is then correlated with the sequence number of the data ticks, ensuring that the order of the split single transmission data corresponds to the sequence number of the data ticks.

[0129] Specifically, starting from the beginning of the transaction data, it is sequentially divided according to the length of each single transmission (equal to the width of the tick data), resulting in a total of a certain number of data blocks. Each data block corresponds to one data tick. The order of division strictly corresponds to the sequence number of the data ticks: the first data block corresponds to data tick 0 (sequence number 0), the second corresponds to tick 1, and so on. For read transactions, the transaction data itself is not sent with the request, but when the read data returns, the received data needs to be reassembled into a burst response in the same order. This splitting logic applies to the data sending direction of write transactions.

[0130] Splitting transaction data into multiple single data transmissions can be implemented using hardware logic circuits. Specifically, it involves sequentially extracting data blocks from the beginning of the transaction data based on the width of the tick data (i.e., the number of bytes in each single transmission) and the total number of data segments. This splitting can be achieved in several hardware ways: One implementation method is to use pointer offsets and data selectors. Specifically, an address counter (or byte offset pointer) is used to point to the starting position of the current data to be split, and a multiplexer (MUX) or shift register is used to extract a fixed-length data block from continuous transaction data.

[0131] As another implementation method, a FIFO can be used in conjunction with a tick counter. Specifically, the transaction data is written into a temporary FIFO, and then the data of the corresponding length is read out according to the tick width. The counter is incremented by one for each read until the total number is reached.

[0132] As another implementation, DMA-style descriptor splitting can be adopted. Specifically, for bursts of large amounts of data, descriptors can be used to record the starting address, length, and tick parameters, and the data path can be automatically truncated by the hardware state machine.

[0133] As a preferred implementation, a byte offset counter can be maintained internally within the bridge. Each tick uses the counter value as the starting index for reading data from a data buffer (e.g., a write buffer). The read width is equal to the tick data width, and then the counter is incremented by that width. This process is repeated until the total number of ticks is reached. This approach has low resource consumption and is easily piped.

[0134] Step 133: For any data tick, determine the slave device address corresponding to the data tick based on the starting address and the offset of the data tick, wherein the offset is equal to the product of the sequence number of the data tick and the width of the tick data.

[0135] Specifically, for any data tick, the sequence number of the data tick in the bus transaction request is obtained, the sequence number is multiplied by the width of the tick data to obtain the offset of the data tick, and finally the starting address is added to the offset to obtain the slave device address corresponding to the data tick.

[0136] Specifically, for each data tick (with sequence number i, counting from 0), the slave device address corresponding to that tick can be calculated. The calculation formula is, for example: Offset = sequence number × width of clock data, slave device address = start address + offset.

[0137] Taking Incremental Burst (INCR) as an example, with the starting address being Start_Addr and the data width being Width, then: 0th beat (i=0): Offset = 0, Address = Start_Addr; First beat (i=1): Offset = 1×Width, Address = Start_Addr + Width; Second beat (i=2): Offset = 2×Width, Address = Start_Addr + 2×Width; ... The (N-1)th beat (i=N-1): Address = Start_Addr + (N-1)×Width; For fixed-address bursts (FIXED), the offset is always 0, and all clock cycles have the same address. For WRAP bursts (WRAP), the address calculation rules are slightly different, requiring boundary alignment and wraparound. Boundary alignment means aligning the starting address according to the boundary of the total data volume transmitted in the burst (data width × burst length), usually in powers of 2. Wraparound means that when the address increments to the end of the boundary, it automatically wraps back to the beginning of the boundary, thus forming a loop. Specifically, the loop boundary (i.e., the starting aligned address of the total transmitted data volume) is first calculated based on the data width and burst length. Then, the address of each data clock cycle increases linearly within the boundary. When the address reaches the end of the boundary (boundary starting address + total data volume), the next address wraps back to the boundary starting address and continues to increment. This rule ensures that the WRAP burst is transmitted cyclically within the specified boundary and is often used in scenarios such as cache line filling.

[0138] Step 134: Combine the slave device address corresponding to each data cycle with the single transmission data of that data cycle to form a single single transmission transaction, so as to obtain multiple single transmission transactions of bus transaction request.

[0139] After completing the aforementioned steps, the slave device address corresponding to each data tick and the single transmission data of that tick can be combined to form a complete single transmission transaction. For a write transaction, this transaction includes: the slave device address, the single-tick write data, and the slave device identifier (derived from the master device identifier). For a read transaction, it only includes the slave device address and the slave device identifier (the data is filled in upon return). Through combination, what was originally a bursty transaction is broken down into multiple independent single transmission transactions, each of which can be independently processed by a slave device that only supports single-access.

[0140] For example, suppose the master device initiates a write burst transaction with the following parameters: Starting address: 0x1000; Burst length AxLEN = 7 (total number of data ticks = 8); Data width AxSIZE = 2 (representing 4 bytes, or 32 bits); Burst type AxBURST = INCR (incrementing); Transaction data: 32 consecutive bytes of data, denoted as D0 (address 0x1000), D1 (0x1004), D2 (0x1008)...D7 (0x101C); Therefore, the total number of data clock cycles calculated by the bridge is 7 + 1 = 8.

[0141] Furthermore, based on the total number of 8 and the width of 4 bytes, the 32 bytes of data are divided into 8 4-byte data blocks: block 0 = D0, block 1 = D1, ..., block 7 = D7.

[0142] Then calculate the slave device address for each data cycle in sequence: Beat 0 (Sequence number 0): Offset = 0 × 4 = 0, Address = 0x1000; Beat 1 (Sequence Number 1): Offset = 1 × 4 = 4, Address = 0x1004; Beat 2 (Sequence number 2): Offset = 2 × 4 = 8, Address = 0x1008; ... Beat 7 (Sequence number 7): Offset = 7 × 4 = 28, Address = 0x1000 + 28 = 0x101C.

[0143] Finally, each address is combined with its corresponding data block to obtain 8 single-transmission transactions: Transaction 0: Address 0x1000, Data D0; Transaction 1: Address 0x1004, Data D1; ... Transaction 7: Address 0x101C, Data D7; These single-transfer transactions are then sent sequentially to the slave device, with each transaction independently completing the write operation and returning a response.

[0144] Thus, by splitting the addresses and data of burst transactions one by one according to the clock ticks, a precise conversion from burst to single transaction is achieved. This splitting method fully complies with the definitions of burst length, data width, and address increment in the AXI4 protocol, ensuring that the converted single transmission sequence is semantically equivalent to the original burst transaction. By explicitly stating that the total number of data clock ticks equals the burst length plus one, the bridge can accurately predict the number of splits required, thereby rationally allocating internal counter resources and pipeline depth. Segmenting transaction data according to the clock tick width and combining it with the corresponding address ensures that each single transmission transaction carries the correct address and data, eliminating the risk of data misalignment or address offset. This splitting logic works in conjunction with the decoupled address and data pipeline processing (address and data are sent in parallel and independently in the write channel, and lead address transmission is supported in the read channel), allowing address calculation and data transmission to overlap, reducing bus idle cycles and improving system throughput. Furthermore, this splitting method supports multiple burst types (such as INCR, FIXED, WRAP). By calculating the offset using the product of the permutation number and the data width, the bridge can dynamically generate addresses using low-cost hardware (multipliers or accumulators), eliminating the need to pre-store the entire address sequence and saving storage resources. It can be adapted by adjusting the offset calculation rules, demonstrating good versatility.

[0145] Figure 7 This is a flowchart illustrating a data transmission method for a bus protocol, as shown in another exemplary embodiment of this disclosure. Figure 7 As shown in the embodiments of this disclosure, a data transmission method for a bus protocol may further include the following steps: Step 141: Determine the type of bus transaction request, which includes write transactions and read transactions.

[0146] In this step, it is determined whether the current bus transaction request is a write transaction or a read transaction. In this embodiment, write and read transactions use independent channels: write transactions can send requests through the write address channel (AW) and the write data channel (W), while read transactions can send requests through the read address channel (AR). In this embodiment, the determination can be based on detecting the identifier or handshake instruction of the address channel: for example, if a valid address and handshake signal appear on the write address channel, it is a write transaction; if a valid signal appears on the read address channel, it is a read transaction. The purpose of step 141 is to distinguish between the two transaction types so that different sending strategies can be adopted subsequently.

[0147] Step 142: In response to the bus transaction request being a write transaction request, for any single transmission transaction, the slave device identifier and the slave device address in the current single transmission transaction are associated and sent on the write address channel, and the single transmission data in the single transmission transaction is sent on the write data channel; wherein, the write address channel and the write data channel are transmitted in parallel and independently.

[0148] When step 141 determines that it is a write transaction, for each single transmission transaction, the bridge performs the following operations: (1) Associated transmission on the write address channel: The slave device identifier and the slave device address of the current single transmission transaction are sent to the slave device on the write address channel. The two are carried in parallel on the address channel. For example, the slave device identifier is placed in the AWID signal (i.e., the write address channel identifier signal), and the slave device address is placed in the AWADDR signal (i.e., the write address channel address signal).

[0149] (2) Send data on the write data channel: Send the single transmission data in the current single transmission transaction (see the relevant content in step 132) to the slave device on the write data channel.

[0150] (3) Parallel independent transmission: The write address channel and the write data channel are independent of each other, and they can handshake simultaneously without blocking each other. That is, the bridge does not need to wait for the write address handshake to be completed before sending write data, nor does it need to wait for the write data to be completed before sending the next address. This decoupling allows address transmission and data transmission to overlap, achieving high pipeline efficiency.

[0151] For example, suppose a write transaction has been broken down into eight single-transfer transactions. For the first transaction, the bridge sends the slave identifier 4'hC and address 0x1000 on the write address channel, and simultaneously sends the first data packet D0 on the write data channel. The slave device may complete the address handshake before receiving the data, but the two channels proceed in parallel. While sending the address and data for the first transaction, the bridge can begin preparing the address 0x1004 and the second data packet D1 for the second transaction, and send them at the appropriate time (e.g., after the first address handshake is successful), without waiting for the write response from the first transaction. This significantly reduces idle time.

[0152] Step 143: In response to the bus transaction request being a read transaction request, for any single transmission transaction, the slave device identifier and slave device address of the single transmission transaction are sequentially sent on the read address channel using a preset lead address sending method, and the read data for the single transmission transaction returned by the slave device is received through the read data channel.

[0153] When step 141 determines it to be a read transaction, for multiple single-transmission transactions, the bridge can sequentially send the slave device identifier and slave device address of each single-transmission transaction on the read address channel using a preset lookahead address sending method, and receive the read data returned by the slave device through the read data channel. The preset lookahead address sending method includes: after sending the slave device address of the current single-transmission transaction, before the corresponding read data returns from the read data channel, generating and temporarily storing the slave device address of the next single-transmission transaction; and sending the temporarily stored next slave device address after the read data corresponding to the current single-transmission transaction returns. Specifically, this means: After sending the slave device address for the current single-transfer transaction, and before the corresponding read data returns from the read data channel, the slave device address for the next single-transfer transaction is generated and temporarily stored. The temporarily stored next slave device address is then sent after the read data for the current single-transfer transaction returns.

[0154] In short, the read channel allows for sending one address ahead: after the current address is sent, the next address can be prepared without waiting for the data to return, but the next address must be sent after the current data returns. This avoids idling the bus while waiting for data and does not excessively increase the buffer pressure on the slave device (because it only needs to be one address ahead).

[0155] For example, suppose a read transaction is split into eight single read transactions, starting at address 0x1000 and with a data width of 4 bytes. The bridge first sends the slave device identifier and address 0x1000 for the first transaction on the read address channel. Then, without waiting for the read data to return, it immediately calculates and temporarily stores the address 0x1004 for the second transaction. When the slave device returns the first read data, the bridge immediately sends the temporarily stored second address 0x1004 and simultaneously returns the first read data to the master device. This cycle continues until all transactions are completed. This pipelining method hides read latency through the advance of address transmission, improving read throughput.

[0156] Based on the embodiments shown in steps 141 to 143 above, this disclosure further introduces an independent flow control mechanism for each slave device identifier to achieve precise control over the number of incomplete transactions for each slave device identifier, avoiding resource contention and head blocking. Specifically, within the bridge, independent write transaction flow control counters and read transaction flow control counters can be set for each slave device identifier (a total of 2^S_ID_WIDTH). The upper limit of the write transaction flow control counter can be configured, for example, by the parameter PER_ID_WR_OUTSTAND (first threshold), and the upper limit of the read transaction flow control counter can be configured by the parameter PER_ID_RD_OUTSTAND (second threshold). The values ​​of these counters represent the number of transactions that have not yet been completed (sent but not yet received a response) under the current slave device identifier. Specifically: (1) For write transactions, the specific flow control process is as follows: When the master device initiates a write burst transaction, after it is broken down into multiple single-transmission transactions in step 130, for each single-transmission transaction, before executing step 142 (sending the address and identifier on the write address channel and sending the data on the write data channel), the following flow control checks are first performed: Read the current value of the write transaction flow control counter corresponding to the slave device identifier (i.e., the low-order part (or the second bit-width part) of the master device identifier) ​​of this single transmission transaction; Compare the current value with the first threshold (PER_ID_WR_OUTSTAND); If the current value is less than the first threshold, it is determined that there are still available uncompleted transaction resources under the slave device identifier. The bridge can then accept the write transaction request and increment the corresponding write transaction flow control counter by 1. Subsequently, step 142 proceeds normally: the address and identifier are sent on the write address channel, and the data is sent on the write data channel. If the current value is greater than or equal to the first threshold, it is determined that the number of incomplete transactions under that slave device identifier has reached saturation, and the bridge cannot receive the transaction. In this case, the bridge can keep the ready signal (m_awready) of the write address channel corresponding to that slave device identifier low, thereby putting back pressure on the master device and preventing it from sending new write transaction requests. The master device will keep the address and signal of the current transaction stable until the ready signal goes high and then retry.

[0157] (2) For read transactions, the specific flow control process is as follows: For read burst transactions, after being split into multiple single-transmission transactions in step 130, a similar flow control check is performed for each single-transmission transaction before executing step 143 (sending the address and identifier using a preset lead address sending method): Read the current value of the read transaction flow control counter; Compare the current value of the read transaction flow control counter with the second threshold (PER_ID_RD_OUTSTAND); If the current value is less than the second threshold, the read transaction request is received, the read transaction flow control counter is incremented by 1, and then step 143 (send address and identifier, and prepare to receive data) is executed.

[0158] If the current value is greater than or equal to the second threshold, the read address channel's ready signal (m_arready) is kept low, and the master device is pressured until the resource is released.

[0159] Furthermore, when a slave device completes a single transmission transaction and returns a response (a write transaction returns a write response, and a read transaction returns read data), the bridge extracts the slave device identifier from the response and decrements the corresponding write transaction flow control counter or read transaction flow control counter by 1, releasing a resource slot. At this point, if the master device was previously pressured due to counter saturation, its corresponding ready signal will go high again, allowing it to continue sending new transactions.

[0160] For example, suppose the parameters are configured as follows: First threshold (maximum number of incomplete write transactions per ID) = 4, and the slave device identifier is 4'h1. The master device continuously initiates 5 write burst transactions to the same slave device identifier (each burst transaction contains multiple single-transmission transactions, but flow control counting is based on burst transactions). The processing is as follows: The first write burst arrives: counter = 0 < 4, receive transaction, counter increments by 1 to become 1, step 142 normally sends all single transmission transactions; The second, third, and fourth write bursts are similar, with the counters changing to 2, 3, and 4 respectively; When the 5th write burst arrives, the counter equals 4 (equal to the threshold), and no transactions are accepted. The bridge pulls m_awready low, corresponding to the slave device identifier 4'h1, putting back pressure on the master device; After the slave device completes a single transfer transaction (or the entire burst) of the first write burst and returns a write response, the bridge decrements the counter from 4 to 3 and releases a resource. m_awready returns to high, the fifth write burst is received, and the counter goes back to 4.

[0161] Meanwhile, the counter for another slave device, 4'h2, is initially set to 0, so its write transactions are unaffected by congestion at 4'h1 and can proceed normally. This demonstrates the fairness of independent flow control per ID and completely eliminates head-end blocking.

[0162] Through the above embodiments, read and write transactions are distinguished, and optimal channel utilization strategies are implemented for each. These strategies are tightly coupled with an independent flow control counter mechanism, forming a closed-loop control system of pre-detection, post-transmission accumulation, and response release. Specifically, write transactions utilize the parallel and independent transmission of write addresses and write data channels, eliminating the idle periods introduced by address blocking data or data blocking addresses in traditional schemes, thus improving write pipeline efficiency. Read transactions employ a preset lead address sending method, pre-calculating and temporarily storing the next address before the current data returns. This allows address sending and read data return to form a pipeline, hiding the read response latency of the slave device. Furthermore, limiting the lead address to only one address ensures low buffer pressure on the slave device and avoids resource exhaustion caused by excessive pipeline depth. This mechanism is fully compatible with the AXI4 protocol, requiring no modification to the master and slave devices. The bridge only needs to add address generation and temporary storage logic to the standard interface to flexibly adapt to slave devices with different latency. It offers significant advantages for slow slave devices and incurs no additional overhead for fast slave devices. Meanwhile, each slave device has an independent write / read flow control counter that performs a threshold check before sending a transaction: if the upper limit is not reached, the transaction is received and the counter is incremented; otherwise, the ready signal of the corresponding address channel is lowered to put back pressure on the master device. When the slave device returns a response, the counter is decremented to release resources. In write transactions, flow control checks precede address and data transmission, controlling the injection rate at the source and avoiding buffer overflows. In read transactions, advance address transmission, combined with the flow control counter, hides read latency and prevents the number of incomplete transactions from getting out of control. When a response is returned, the counter is decremented and the master device ID recovery step is executed synchronously, ensuring the atomicity of resource release and transaction completion. This collaborative work enables the bridge to maintain stable and efficient protocol conversion capabilities in high-load, multi-master concurrent scenarios, solving the problems of resource contention and head blocking. At the same time, the decoupling of read / write channels and advance address transmission further unleash the system's concurrency potential.

[0163] The following is combined with Figure 8 and Figure 9 The write channel state machine and read channel state machine shown further illustrate the above technical solution. Both state machines adopt a two-state design (IDLE state and BURST state) to control the transition process from burst to single state using a concise and efficient finite state machine.

[0164] Figure 8 This is a schematic diagram of the write channel state machine transition in an embodiment of this disclosure. Figure 9 This is a schematic diagram of the read channel state machine transition in an embodiment of this disclosure.

[0165] like Figure 8As shown, the write channel state machine is initially in the IDLE state. When the master device initiates a write transaction, it pulls the write address valid signal (awvalid) high. Simultaneously, the bridge is ready and pulls the write address ready signal (awready) high to complete the handshake. After this, the state machine transitions from the IDLE state to the BURST state. In the BURST state, the bridge performs the following operations: converting the current burst transaction into multiple single-transmission transactions and continuously sending single transmissions of burst length (i.e., sending the address and data sequentially according to the total number of data ticks). During this process, the bridge utilizes the parallel independent channel mechanism of step 142, i.e., the write address channel (AW) and the write data channel (W) are transmitted simultaneously and independently, and the address and data do not need to wait for each other. At the same time, a threshold check is performed before the state transition using an independent flow control counter: only when the current value of the write transaction flow control counter corresponding to the slave device identifier is less than the first threshold can awready (ready signal) be pulled high, allowing the transition from IDLE to BURST state; otherwise, awready (ready signal) remains low, the master device is reverse-pressurized, and cannot enter the BURST state. When the device returns the last write response (valid signal), the state machine jumps back to the IDLE state and triggers the corresponding write transaction flow control counter to decrement by 1, releasing resources.

[0166] like Figure 9 As shown, the read channel state machine is also initially in the IDLE state. When the master device initiates a read transaction, after the read address valid signal (arvalid) and the read address ready signal (arready) successfully handshake, the state machine enters the BURST state. In the BURST state, the bridge converts the burst read transaction into multiple single read transmissions and continuously reads data cycles of the burst length. During this process, the preset lead address sending method in step 143 is fully reflected: the bridge sequentially sends the address and slave device identifier of each single transmission transaction on the read address channel, and calculates and temporarily stores the next address before the current read data returns. The temporarily stored address is sent after the current data (rvalid) returns, realizing the pipeline overlap of address sending and data return. The flow control mechanism also applies to the read channel: only when the current value of the read transaction flow control counter corresponding to the slave device identifier is less than the second threshold can the ready be pulled high, allowing the transition from IDLE to BURST state; otherwise, it applies back pressure to the master device. When the device returns the last read data (rvalid signal), the state machine jumps back to the IDLE state and triggers the read transaction flow control counter to decrement by 1.

[0167] In this embodiment, the design of the write channel state machine and the read channel state machine, together with steps 141 to 143 and the independent flow control counter mechanism, forms a tightly coupled overall solution: (1) Decoupling of state machine and channel: In the BURST state, the address and data are sent in parallel and independently, and can proceed without waiting for the other party to complete the handshake, thus eliminating the idle cycle in traditional sequential processing. In the BURST state, the read channel is sent with a lead address, and the next address is prepared before the data is returned, thus hiding the read delay.

[0168] (2) Flow control and state entry binding: The jump from IDLE to BURST is strictly controlled by an independent counter for each ID. When the counter is not full, the ready signal is high, allowing handshake to enter BURST; when the counter is full, the ready signal is low, the master device is back-pressured and cannot enter BURST. This ensures that the number of incomplete transactions for each slave device does not exceed a preset threshold, completely avoiding the head-blocking problem where an aggressive ID occupies all global resources and blocks other IDs.

[0169] (3) Response-driven state return and resource release: When the last write response (bvalid) or the last read data (rvalid) arrives, the state machine returns from BURST to IDLE, and the corresponding flow control counter is decremented by one, releasing a resource slot. The master device (with the same slave device identifier) ​​that was previously back-pressurized is released from back pressure, and new sudden transactions can enter IDLE and handshake again, forming an orderly flow control closed loop.

[0170] Thus, in high-load, multi-master concurrent scenarios, the number of Outstanding identifiers for each slave device can be accurately controlled. Simultaneously, the decoupling of the read / write channels and the pipelined advantages brought by lead address transmission are fully utilized. This not only solves ID obfuscation but also further eliminates resource contention and head-end blocking, achieving high throughput and low latency protocol conversion. Furthermore, the read / write channel state machine implementation in this embodiment is simple and reliable, facilitating hardware synthesis and timing convergence.

[0171] Figure 10 This is a flowchart illustrating a data transmission method for a bus protocol, as shown in another exemplary embodiment of this disclosure. Figure 10 As shown in the embodiments of this disclosure, a data transmission method for a bus protocol may further include the following steps: Step 160: In response to receiving a response result returned by the slave device for any single transmission transaction, based on the slave device identifier in the response result, search for one or more corresponding first-width portions from the preset storage unit.

[0172] After a device completes a single transmission transaction, it returns a response: for a write transaction, the response is a write response channel (B channel), which may carry the slave device identifier (s_bid); for a read transaction, the response is a read data channel (R channel), carrying the slave device identifier (s_rid). Upon receiving the response, the bridge extracts the slave device identifier (i.e., the low-order part (or the second bit-width part) obtained in step 110), and then uses this slave device identifier as an index to search for the corresponding storage area in the preset storage unit. This storage area may store more than one first bit-width part (i.e., the high-order part).

[0173] Because a separate preset storage unit (e.g., FIFO) is set up for each possible slave device identifier, when multiple master devices (or different burst transactions of the same master device) concurrently access the same slave device identifier (i.e., their lower-order bits of the complete master device identifier are the same), the higher-order bits of these transactions are sequentially stored in the same preset storage unit. For example, if master device A's complete ID is 12'hABC (high-order bits 8'hAB, slave device identifier 4'hC) and master device B's complete ID is 12'hDEC (high-order bits 8'hDE, slave device identifier is also 4'hC), and both initiate burst transactions sequentially, then the storage unit corresponding to slave device identifier = 4'hC will sequentially store 8'hAB and 8'hDE, forming two higher-order bits. Therefore, when the slave device returns a response, the storage unit corresponding to that slave device identifier may already have multiple higher-order bits that have not yet been popped (i.e., have not yet matched a response).

[0174] There are several ways to find the high-order part (first wide part) of the corresponding preset memory unit based on the device identifier: As a preferred embodiment of this disclosure, a FIFO (First-In, First-Out) approach can be used. Each preset storage unit can be a FIFO queue. The corresponding FIFO is directly selected using the slave device identifier as an index. The lookup operation involves reading the data at the head of the queue (the earliest stored high-order part) from the read port of the FIFO. This method does not require additional address calculation; only the read pointer needs to be incremented.

[0175] As another implementation method, a register array + read pointer approach can be used. That is, each memory unit is a set of registers, equipped with an independent read pointer. During lookup, the corresponding register set is selected based on the index, and then the high-order bits are read from the address currently pointed to by the read pointer, with the read pointer incremented by one.

[0176] As another implementation method, a linked list approach can be used. Each storage unit is a linked list head, and the high-order parts are stored in shared memory as nodes. During a search, the linked list head is found based on the index, and then the high-order parts of the next node are retrieved according to the link order.

[0177] Alternatively, a Content Addressable Memory (CAM) approach can be used, where a CAM can be maintained for each slave device identifier, enabling rapid matching via identifier and timestamp.

[0178] Step 170: Determine the target first width portion from one or more first width portions according to the storage order.

[0179] After locating multiple high-order portions in the corresponding preset storage unit, it is further determined which high-order portion should match the current response, i.e., the target first high-order portion. In this embodiment of the disclosure, the target high-order portion is selected according to the storage order of the high-order portions.

[0180] As one implementation method, if the preset storage unit adopts the FIFO method, then the FIFO has a first-in-first-out order, so each time the highest-order part of the queue (i.e., the earliest stored) is directly popped as the target. This is the most natural and simplest correspondence.

[0181] As another implementation method, if the preset storage unit adopts the register array + read pointer method, a read pointer can be maintained. Each time the register pointed to by the current pointer is read, the pointer is incremented by one, thereby simulating the FIFO order.

[0182] As another implementation method, if the preset storage unit adopts a linked list, the high-order part of the first node is retrieved according to the linked list link order, and then the head pointer points to the next node to achieve sequential retrieval.

[0183] As another implementation method, if the preset storage unit adopts the CAM method, then the timestamp sorting is maintained, and the data is retrieved in the order of timestamp sorting.

[0184] Step 180: The master device identifier is obtained by concatenating the first wide part of the target device with the slave device identifier.

[0185] In this step, the determined target high-order part (first wide part) is concatenated with the slave device identifier (second wide part) carried in the response. For example, the concatenation rule can be: the high-order part is used as the high-order part of the complete master device identifier, and the slave device identifier is used as the low-order part, combined to form a complete master device identifier with a width of M_ID_WIDTH. For example, if the target high-order part is 8'hAB and the slave device identifier is 4'hC, the concatenation result is 12'hABC. This value is the original identifier used by the master device that initiated the transaction.

[0186] Step 190: Return the master device identifier and response result to the master device.

[0187] In this step, the recovered complete master device identifier is returned to the master device along with the response. Specifically: for write transactions, the recovered identifier is returned to the master device as m_bid, along with the write response (m_bvalid and m_bresp); for read transactions, the recovered identifier is returned to the master device as m_rid, along with the read data (m_rdata and m_rlast). This completes a burst-to-single transition and response tracing process.

[0188] For example, continuing with the example from the previous embodiment: Master device A (ID=12'hABC) and Master device B (ID=12'hDEC) successively initiate write bursts using the same slave device identifier = 4'hC. The bridge stores the high-order bits 8'hAB and 8'hDE sequentially into the write ID FIFO corresponding to slave device identifier = 4'hC. After the slave device processes the first single transaction in sequence, it returns a write response carrying s_bid=4'hC. The bridge executes step 160: finding the corresponding FIFO using 4'hC as the index. Step 170: popping the head data 8'hAB from the FIFO in first-in-first-out order as the target high-order part. Step 180: concatenating to obtain 12'hABC. Step 190: returning 12'hABC as m_bid along with the write response to Master device A. Subsequently, when the second response returns, the remaining 8'hDE in the FIFO is popped, concatenated to form 12'hDEC, and returned to Master device B.

[0189] Through the above embodiments, the high-order bits are retrieved from the preset storage unit in storage order and concatenated with the slave device identifier, achieving accurate recovery of the complete master device identifier. Since each slave device identifier has an independent storage unit, different high-order bits are stored separately without interference. Popping them in storage order (e.g., FIFO first-in-first-out) ensures a strict correspondence between the response and the initiated transaction, avoiding the problem of not being able to distinguish different high-order bits of the same slave device identifier in existing global queues. Simultaneously, since the storage unit can accommodate multiple high-order bits (depth N), the same slave device identifier can have multiple incomplete transactions simultaneously, increasing the Outstanding capability, originally limited to 1, to N, fully releasing the concurrency performance of the master device. Furthermore, various lookup implementation methods (FIFO, register array, linked list, etc.) are provided, allowing designers to flexibly choose according to resources, performance, and concurrency depth.

[0190] In summary, in this embodiment, after receiving a bus transaction request from a master device, the bridge splits the master device identifier, using the lower-order part as the slave device identifier and storing the higher-order part in a preset storage unit indexed by the slave device identifier. This distributed independent storage method replaces the traditional single global queue. Each slave device identifier has its own independent storage space, ensuring that even if multiple master devices use the same slave device identifier, their higher-order parts can be saved separately without interference. When a slave device returns a response, the bridge can accurately locate the corresponding storage unit based on the slave device identifier in the response and pop the higher-order part according to the storage order, thus completely solving the problems of ID confusion and untraceable responses during multi-master concurrency. Simultaneously, each storage unit can accommodate multiple higher-order parts, meaning that the same slave device identifier can simultaneously have multiple incomplete transactions. This releases the Outstanding capability, originally forcibly limited to 1, into a configurable depth value, leveraging the parallel performance of the master devices and improving bus utilization. Furthermore, determining whether a transaction is a burst based on its burst length provides a basis for subsequent differentiated processing. When a burst transaction is identified, the bridge splits it into multiple single-transmission transactions. Each transaction contains a slave device address and a data tick. The slave device address is dynamically calculated sequentially based on the starting address, burst length, and tick data width. This splitting method allows slave devices that only support single access to correctly respond to burst requests, solving the fundamental problem of protocol mismatch. Furthermore, dynamic address calculation replaces pre-storing all addresses, saving storage resources. Address calculation and data splitting can be performed in parallel, reducing idle periods caused by addresses waiting for data or data waiting for addresses, thus improving pipeline efficiency. Finally, each single-transmission transaction is associated with a slave device identifier and sent to the slave device, enabling the slave device to perform access based on the address and return a response. This ensures that the slave device can correctly identify the transaction's ownership, forming a complete closed loop with the aforementioned ID splitting storage and recovery mechanism, guaranteeing data consistency and system reliability in multi-transaction concurrent scenarios. In summary, the embodiments of this disclosure fundamentally solve the problems of ID confusion and outstanding limitation through core operations such as distributed ID mapping storage, burst length discrimination, dynamic address calculation and transaction splitting. At the same time, they achieve accurate conversion from burst to single transaction, improving the bus transmission efficiency between high-performance master devices and simple slave devices in SoC.

[0191] This disclosure provides a data transmission method for a bus protocol applicable to System-on-Chip (SoC) design environments. In this environment, high-performance master devices (such as CPUs, GPUs, DSPs, or DMAs) interact with multiple slave devices via the AXI4 bus protocol. Some of these slave devices support full AXI4 burst transfers (e.g., high-speed DDR controllers, caches), while others support only single transfers (burst length = 0), such as simple static random access memory (SRAM) controllers, low-speed peripheral register interfaces (e.g., UART, I2C, GPIO), and certain custom hardware accelerators that only support single read / write operations. A bridge module, acting as an intermediate layer, connects the master device interface and the single-transfer-only slave device interface. It receives AXI4 burst requests (including write and read transactions) from the master device, converts the burst requests into a sequence of single transfers acceptable to the slave device, and restores the slave device's single response to a burst response consistent with the master device's expectations.

[0192] The input data includes, but is not limited to, write transaction data (a continuous multi-beat data sequence) initiated by the master device and the address and control signals of read transactions. The data type is a digital signal encapsulated according to the AXI4 protocol, including but not limited to master device identifier (ID), starting address, burst length, data width, burst type, and write data. The output data is a single transmission transaction (address, data, control signals) sent to the slave device after conversion, and the response (write response or read data) recovered by the bridge and forwarded to the master device after the slave device returns. The technical solution provided by the embodiments of this disclosure can be flexibly parameterized to adapt to different master device ID widths, slave device ID widths, storage cell depths, and outstanding thresholds per ID, thus being suitable for various SoC integration scenarios, such as mobile terminals, IoT chips, artificial intelligence accelerators, automotive electronics, and other fields that require efficient bridging of high-performance master devices and low-performance slave devices. Through the bridge of this disclosure, system designers can achieve low-latency, high-throughput conversion from burst to single-transaction without modifying existing master or slave device IP cores, improving the reusability of chip design and overall system performance.

[0193] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as ROM, RAM, magnetic disk, or optical disk.

[0194] Correspondingly, this disclosure also provides apparatus embodiments corresponding to the foregoing method embodiments.

[0195] Figure 11 This is a structural block diagram of a data transmission apparatus for a bus protocol, as an exemplary embodiment of this disclosure. Figure 11 As shown, an embodiment of this disclosure provides a data transmission device for a bus protocol, applied in a bridge connecting a master device and a slave device. The device includes: The identifier splitting module 1101 is used to split the master device identifier in response to receiving a bus transaction request from the master device to obtain a corresponding first bit width part and a second bit width part, so as to use the second bit width part as a slave device identifier, and use the slave device identifier as an index to store the first bit width part into a preset storage unit, wherein the bus transaction request includes the master device identifier, the starting address, the burst length and the transaction data. The request type determination module 1102 is used to determine whether the bus transaction request is a burst transaction based on the burst length. The request splitting module 1103 is used to split the bus transaction request into multiple single transmission transactions in response to the bus transaction request being a burst transaction. Each single transmission transaction includes a slave device address and a data tick, wherein the slave device address points to a storage unit inside the slave device and is calculated sequentially based on the starting address, the burst length, and the width of the corresponding tick data. The associated sending module 1104 is used to associate any one of the single transmission transactions with the slave device identifier and send it to the slave device, so that the slave device can access the data tick in the single transmission transaction according to the slave device address and return a response result.

[0196] As an optional embodiment, the device further includes: The non-burst transaction processing module is used to respond to the bus transaction request as a non-burst transaction, using the transaction data and the starting address as the single transmission transaction, associating the single transmission transaction with the slave device identifier, and sending it to the slave device indicated by the starting address, so that the slave device can access the single transmission transaction according to the starting address and return a response result.

[0197] As an optional embodiment, the request type determination module includes: A burst length comparison unit is used to compare the burst length with a preset length value; The first determining unit is configured to determine that the bus transaction request is a non-burst transaction in response to the burst length being the preset length value; The second determining unit is configured to determine the bus transaction request as a burst transaction in response to the burst length being greater than the preset length value.

[0198] As an optional embodiment, the request splitting module includes: A beat count determination unit is used to determine the total number of data beats based on the burst length, wherein the total number of data beats is equal to the burst length plus a preset value; The transaction data splitting unit is used to split the transaction data carried by the bus transaction request into multiple single transmission data according to the total number of data ticks and the width of the tick data, with one single transmission data corresponding to one data tick; The slave device address determination unit is used to determine the slave device address corresponding to any data beat based on the starting address and the offset of the data beat, wherein the offset is equal to the product of the sequence number of the data beat and the width of the beat data. The data combination unit is used to combine the slave device address corresponding to each data cycle with the single transmission data of that data cycle to form a single single transmission transaction, so as to obtain multiple single transmission transactions of the bus transaction request.

[0199] As an optional embodiment, the transaction data splitting unit includes: The data length determination subunit is used to determine the length of each single data transmission based on the width of the clock data; A data segmentation unit is used to segment the bus transaction request according to the length of each single data transmission based on the starting position of the bus transaction request, so as to obtain a number of single data transmissions equal to the total number of data ticks. The sorting subunit is used to establish a correspondence between the order of the segmentation and the arrangement number of the data beat, so that the arrangement order of each single transmission data obtained by the segmentation corresponds to the arrangement number of the data beat.

[0200] As an optional embodiment, the slave device address determination unit includes: The first acquisition subunit is used to acquire the sequence number of the data cycle in the bus transaction request for any given data cycle. The offset calculation subunit is used to multiply the arrangement number by the width of the beat data to obtain the offset of the data beat; The address determination subunit is used to add the starting address to the offset to obtain the slave device address corresponding to the data cycle.

[0201] As an optional embodiment, the associated sending module includes: A request type determination unit is used to determine the type of the bus transaction request, wherein the type includes write transactions and read transactions; The first data transmission unit is configured to respond to the bus transaction request as a write transaction request, and for any single transmission transaction, associate and transmit the slave device identifier with the slave device address in the current single transmission transaction on the write address channel, and transmit the single transmission data in the single transmission transaction on the write data channel; wherein the write address channel and the write data channel are transmitted in parallel and independently. The second data transmission unit is configured to respond to the bus transaction request as a read transaction request, and for any given single transmission transaction, sequentially transmit the slave device identifier and slave device address of the single transmission transaction on the read address channel using a preset lead address transmission method, and receive the read data returned by the slave device for the single transmission transaction through the read data channel; wherein, the preset lead address transmission method includes: after transmitting the slave device address of the current single transmission transaction, before the corresponding read data returns from the read data channel, generating and temporarily storing the slave device address of the next single transmission transaction, and transmitting the temporarily stored next slave device address after the read data corresponding to the current single transmission transaction returns.

[0202] As an optional embodiment, the associated sending module further includes: A write transaction count comparison unit is used to compare the current value of the write transaction flow control counter corresponding to the slave device identifier with a first threshold. The first request receiving unit is configured to receive the write transaction request and increment the write transaction flow control counter by 1 in response to the current value of the write transaction flow control counter being less than a first threshold. The first reverse pressure unit is used to keep the ready signal of the write address channel corresponding to the slave device identifier at a low level in response to the current value of the write transaction flow control counter being greater than or equal to a first threshold, so as to prevent the master device from continuing to send write transaction requests. The read transaction count comparison unit is used to compare the current value of the read transaction flow control counter corresponding to the slave device identifier with a second threshold. The second request receiving unit is configured to receive the read transaction request and increment the read transaction flow control counter by 1 in response to the current value of the read transaction flow control counter being less than the second threshold. The second reverse pressure unit is used to keep the read address channel corresponding to the slave device identifier at a low level in response to the current value of the read transaction flow control counter being greater than or equal to the second threshold, so as to prevent the master device from continuing to send read transaction requests. The resource release unit is configured to decrement the write transaction flow control counter or the read transaction flow control counter corresponding to the single transmission transaction by 1 when the slave device returns a write response result or a read response result for any single transmission transaction.

[0203] As an optional embodiment, the device further includes: The high-order lookup module is used to, in response to receiving a response result returned by the slave device for any of the single transmission transactions, search for one or more corresponding first-order width portions from the preset storage unit based on the slave device identifier in the response result; The target high-order determination module is used to determine the first width portion of the target from the more than one first width portion according to the storage order; The identifier splicing module is used to splice the first wide portion of the target with the slave device identifier to obtain the master device identifier; The response return module is used to return the master device identifier and the response result to the master device.

[0204] The data transmission device for bus protocols in this disclosure corresponds to the data transmission methods for bus protocols described above in this disclosure in terms of specific implementation and beneficial technical effects. Related contents can be referenced, cited, and combined with each other, and will not be repeated here.

[0205] Below, for reference Figure 12 This describes an electronic device according to embodiments of the present disclosure. The electronic device may be either or both of a first device and a second device, or a standalone device independent of them, which may communicate with the first device and the second device to receive acquired input signals from them.

[0206] Figure 12 A block diagram of an electronic device according to an embodiment of the present disclosure is shown.

[0207] like Figure 12 As shown, the electronic device includes one or more processors and memory.

[0208] A processor can be a central processing unit (CPU) or other form of processing unit with data processing and / or instruction execution capabilities, and can control other components in an electronic device to perform desired functions.

[0209] The memory can store one or more computer program products, and the memory can include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program products can be stored on the computer-readable storage medium, and the processor can run the computer program products to implement the data transmission methods for bus protocols and / or other desired functions described in the various embodiments of this disclosure above.

[0210] In one example, the electronic device may also include input devices and output devices, which are interconnected via a bus system and / or other forms of connection mechanism (not shown).

[0211] In addition, the input device may also include, for example, a keyboard, a mouse, etc.

[0212] This output device can output various information to the outside, including determined distance information, direction information, etc. The output device may include, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, etc.

[0213] Of course, for the sake of simplicity, Figure 12 Only some of the components of the electronic device relevant to this disclosure are shown, omitting components such as buses, input / output interfaces, etc. In addition, the electronic device may include any other suitable components depending on the specific application.

[0214] In addition to the methods and apparatus described above, embodiments of this disclosure may also be computer program products comprising computer program instructions that, when executed by a processor, cause the processor to perform the steps in the data transmission methods for bus protocols according to various embodiments of this disclosure as described in the foregoing portions of this specification.

[0215] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this disclosure. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on a user's computing device, partially on a user's computing device, as a standalone software package, partially on a user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0216] Furthermore, embodiments of this disclosure may also be computer-readable storage media storing computer program instructions thereon, which, when executed by a processor, cause the processor to perform the steps in the data transmission method for a bus protocol according to various embodiments of this disclosure as described in the foregoing portion of this specification.

[0217] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable 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.

[0218] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0219] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For system embodiments, since they largely correspond to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0220] The block diagrams of devices, apparatuses, devices, and systems disclosed herein are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0221] The methods and apparatus of this disclosure may be implemented in many ways. For example, they may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order of steps for the methods is for illustrative purposes only, and the steps of the methods of this disclosure are not limited to the order specifically described above unless otherwise specifically stated. Furthermore, in some embodiments, this disclosure may also be implemented as a program recorded on a recording medium, the program including machine-readable instructions for implementing the methods according to this disclosure. Thus, this disclosure also covers recording media storing programs for performing the methods according to this disclosure.

[0222] It should also be noted that in the apparatus, devices, and methods of this disclosure, the components or steps can be disassembled and / or recombined. These disassemblies and / or recombinations should be considered as equivalent solutions to this disclosure.

[0223] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0224] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations thereof.

Claims

1. A data transmission method for a bus protocol, characterized in that, The method, applied in a bridge connecting a master device and a slave device, includes: In response to receiving a bus transaction request from the master device, the master device identifier is split to obtain a first wide part and a second wide part, so as to use the second wide part as a slave device identifier, and use the slave device identifier as an index to store the first wide part into a preset storage unit, wherein the bus transaction request includes the master device identifier, the starting address, the burst length and the transaction data; Determine whether the bus transaction request is a burst transaction based on the burst length; In response to the bus transaction request being a burst transaction, the bus transaction request is split into multiple single transmission transactions. Each single transmission transaction includes a slave device address and a data tick. The slave device address points to a storage unit inside the slave device and is calculated sequentially based on the starting address, the burst length, and the width of the corresponding tick data. Any one of the single transmission transactions is associated with the slave device identifier and sent to the slave device, so that the slave device can access the data ticks in the single transmission transaction according to the slave device address and return a response result.

2. The method of claim 1, wherein, The method further includes: In response to the bus transaction request being a non-burst transaction, the transaction data and the starting address are used as the single transmission transaction. After associating the single transmission transaction with the slave device identifier, it is sent to the slave device indicated by the starting address, so that the slave device can access the single transmission transaction according to the starting address and return a response result.

3. The method according to claim 1 or 2, characterized in that, Determining whether the bus transaction request is a burst transaction based on the burst length includes: Compare the burst length with a preset length value; In response to the burst length being the preset length value, the bus transaction request is determined to be a non-burst transaction; If the burst length is greater than the preset length value, the bus transaction request is determined to be a burst transaction.

4. The method according to claim 1 or 2, characterized in that, In response to the bus transaction request being a burst transaction, the bus transaction request is split into multiple single-transmission transactions. Each single-transmission transaction includes a slave device address and a data tick. The slave device address is calculated sequentially based on the start address, the burst length, and the width of the corresponding tick data, including: The total number of data beats is determined based on the burst length, and the total number of data beats is equal to the burst length plus a preset value; Based on the total number of data ticks and the width of the tick data, the transaction data carried by the bus transaction request is split into multiple single transmission data, and one single transmission data corresponds to one data tick. For any data tick, the slave device address corresponding to the data tick is determined based on the starting address and the offset of the data tick, wherein the offset is equal to the product of the sequence number of the data tick and the width of the tick data; The slave device address corresponding to each data cycle is combined with the single transmission data of that data cycle to form a single single transmission transaction, thereby obtaining multiple single transmission transactions of the bus transaction request.

5. The method according to claim 4, characterized in that, The step of splitting the transaction data carried by the bus transaction request into multiple single-transmission data according to the total number of data ticks and the width of the tick data, wherein one single-transmission data corresponds to one data tick, includes: The length of each single data transmission is determined based on the width of the clock data; Based on the starting position of the bus transaction request, the bus transaction request is divided according to the length of each single data transmission to obtain a number of single data transmissions equal to the total number of data ticks; Establish a correspondence between the order of the segmentation and the sequence number of the data beats, so that the order of each single transmission data obtained from the segmentation corresponds to the sequence number of the data beats.

6. The method according to claim 4, characterized in that, For any given data cycle, the slave device address corresponding to that data cycle is determined based on the starting address and the offset of that data cycle, wherein the offset is equal to the product of the sequence number of the data cycle and the width of the cycle data, including: For any given data tick, obtain the sequence number of that data tick in the bus transaction request; Multiply the sequence number by the width of the beat data to obtain the offset of the beat data; Add the starting address to the offset to obtain the slave device address corresponding to the data cycle.

7. The method according to claim 1 or 2, characterized in that, Associating any one of the single transmission transactions with the slave device identifier and sending it to the slave device includes: Determine the type of the bus transaction request, which includes write transactions and read transactions; In response to the bus transaction request being a write transaction request, for any single transmission transaction, the slave device identifier is associated with the slave device address in the current single transmission transaction and sent on the write address channel, and the single transmission data in the single transmission transaction is sent on the write data channel; wherein, the write address channel and the write data channel are transmitted in parallel and independently. In response to the bus transaction request being a read transaction request, for any single transmission transaction, the slave device identifier and slave device address of the single transmission transaction are sequentially sent on the read address channel using a preset lead address sending method, and the read data for the single transmission transaction returned by the slave device is received through the read data channel; wherein, the preset lead address sending method includes: after sending the slave device address of the current single transmission transaction, before the corresponding read data returns from the read data channel, generating and temporarily storing the slave device address of the next single transmission transaction, and sending the temporarily stored next slave device address after the read data corresponding to the current single transmission transaction returns.

8. The method according to claim 7, characterized in that, Associating any one of the single transmission transactions with the slave device identifier and sending it to the slave device further includes: In response to the bus transaction request being a write transaction request, before associating the slave device identifier with the slave device address in the current single transmission transaction on the write address channel and before sending the single transmission data in the single transmission transaction on the write data channel for any single transmission transaction: Compare the current value of the write transaction flow control counter corresponding to the slave device identifier with the first threshold; In response to the current value of the write transaction flow control counter being less than a first threshold, the write transaction request is received, and the write transaction flow control counter is incremented by 1; In response to the current value of the write transaction flow control counter being greater than or equal to a first threshold, the ready signal of the write address channel corresponding to the slave device identifier is kept low to prevent the master device from continuing to send write transaction requests; In response to the bus transaction request being a read transaction request, before sequentially sending the slave device identifier and slave device address of any single transmission transaction on the read address channel using a preset lead address sending method, and before receiving the read data for that single transmission transaction returned by the slave device through the read data channel: Compare the current value of the read transaction flow control counter corresponding to the slave device identifier with the second threshold; In response to the current value of the read transaction flow control counter being less than the second threshold, the read transaction request is received, and the read transaction flow control counter is incremented by 1; In response to the current value of the read transaction flow control counter being greater than or equal to the second threshold, the read address channel corresponding to the slave device identifier is kept at a low level to prevent the master device from continuing to send read transaction requests; In response to the slave device returning a write response result or a read response result for any single transmission transaction, the write transaction flow control counter or the read transaction flow control counter corresponding to that single transmission transaction is decremented by 1.

9. The method according to claim 1 or 2, characterized in that, The method further includes: In response to receiving a response result returned by the slave device for any of the single transmission transactions, based on the slave device identifier in the response result, one or more corresponding first-width portions are searched from the preset storage unit; The target first width portion is determined from one or more first width portions according to the storage order; The master device identifier is obtained by concatenating the first width portion of the target with the slave device identifier; The master device identifier and the response result are returned to the master device.

10. A data transmission device for a bus protocol, characterized in that, The device, used in a bridge connecting a master device and a slave device, includes: The identifier splitting module is used to split the master device identifier in response to receiving a bus transaction request from the master device to obtain a corresponding first bit width part and a second bit width part, so as to use the second bit width part as a slave device identifier, and use the slave device identifier as an index to store the first bit width part into a preset storage unit, wherein the bus transaction request includes the master device identifier, the starting address, the burst length and the transaction data. The request type determination module is used to determine whether the bus transaction request is a burst transaction based on the burst length. The request splitting module is used to split the bus transaction request into multiple single transmission transactions in response to the bus transaction request being a burst transaction. Each single transmission transaction includes a slave device address and a data tick, wherein the slave device address points to a storage unit inside the slave device and is calculated sequentially based on the starting address, the burst length, and the width of the corresponding tick data. The associated sending module is used to associate any one of the single transmission transactions with the slave device identifier and send it to the slave device, so that the slave device can access the data ticks in the single transmission transaction according to the slave device address and return a response result.

11. An electronic device, characterized in that, include: Memory, used to store computer program products; A processor for executing a computer program product stored in the memory, wherein when the computer program product is executed, it implements the method described in any one of claims 1-9.

12. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1-9.

13. A computer program product comprising computer program instructions, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1-9.

Images