A bridge device and system on chip

Abstract

This invention provides a bridging device and a system-on-a-chip (SoC). The bridging device connects multiple master devices and multiple slave devices within the SoC. The bridging device includes an operation judgment module, configured to receive AXI4 write requests from master devices, compare the data address and identifier in the AXI4 write request with the data address and identifier of each AXI4 data packet cached in a request monitoring module, and determine the operation type based on the comparison result. When the operation type is an atomic operation, the AXI4 write request is converted into a corresponding AIX5 atomic operation request; when the operation type is a non-atomic operation, the AXI4 write request is converted into a corresponding AIX5 write request. This invention provides a bridging device and SoC that solves the technical problem that SoCs using AXI4 and AXI5 protocols cannot utilize atomic operations.

Description

Technical Field

[0001] This invention relates to the field of chips, and more particularly to a bridging device and a system-on-a-chip. Background Technology

[0002] With the widespread adoption of multi-core processor architectures, the AXI5 protocol introduced atomic operations to enhance multi-core collaborative processing capabilities. However, many currently deployed IP cores are still based on the earlier AXI4 protocol and cannot directly support the atomic operation functionality of the AXI5 protocol. Existing technologies typically implement atomic operations through software simulation or hardware modification, but these methods suffer from significant performance overhead and compatibility limitations, making it difficult to efficiently meet the data consistency and concurrency efficiency requirements of multi-core systems.

[0003] Given the current situation, since master devices using the AXI4 protocol cannot directly utilize atomic operations, the on-chip system must rely on high-overhead software emulation or complex hardware modifications. This leads to increased data processing latency and intensified bus contention, limiting the overall performance and scalability of the on-chip system. Therefore, there are areas for improvement. Summary of the Invention

[0004] This invention provides a bridging device and a system-on-a-chip (SoC) to solve the technical problem that SoCs using the AXI4 and AXI5 protocols cannot utilize atomic operations.

[0005] This invention provides a bridging device that connects multiple master devices and multiple slave devices in a system-on-a-chip (SoC), wherein the master devices use the AXI4 protocol and the slave devices use the AXI5 protocol; the bridging device includes:

[0006] The request conversion module is used to receive AXI4 read requests from the master device, convert the AXI4 read requests into AXI5 read requests, and send them to the corresponding slave device according to their data addresses; the request conversion module is also used to receive AXI5 data packets read from the slave device and convert the AXI5 data packets into AXI4 data packets; The request monitoring module is used to cache AXI4 data packets and send them back to the corresponding master device based on the identifier of the AXI4 data packets; The operation judgment module is used to receive the AXI4 write request from the master device, compare the data address and identifier in the AXI4 write request with the data address and identifier of each AXI4 data packet cached in the request monitoring module, and determine the operation type based on the comparison result. The request conversion module is also used to determine the operation type: when the operation type is an atomic operation, the AXI4 write request is converted into the corresponding AIX5 atomic operation request; when the operation type is a non-atomic operation, the AXI4 write request is converted into the corresponding AIX5 write request. The request conversion module is also used to send the request to the corresponding slave device based on the data address of the AIX5 atomic operation request or the AIX5 write request.

[0007] In one embodiment of the present invention, the operation determination module includes: The operation matching submodule is used to receive AXI4 write requests from the master device and match the data address and identifier in the AXI4 write request with the data address and identifier of each AXI4 data packet cached in the request monitoring module to obtain the matching result; The operation inference submodule is used to compare the device data in the AXI4 write request with the device data in the corresponding matching AXI4 data packet when the matching result is a successful match, and to determine the operation type of the AXI4 write request based on the comparison result.

[0008] In one embodiment of the present invention, the operation matching submodule is further configured to receive an AXI4 write request from the master device and compare the data address of the AXI4 write request with a preset address region: When the data address does not belong to the preset address area, a matching result of failure is obtained; When the data address belongs to the preset address range, the data address and identifier in the AXI4 write request are matched with the data address and identifier of each AXI4 data packet cached in the request monitoring module.

[0009] In one embodiment of the present invention, when the data address belongs to a preset address range, the operation matching submodule is further configured to match the data address and identifier of the AXI4 write request with the data address and identifier of each AXI4 data packet cached in the request monitoring module: A match failure result is obtained when the data address of the AXI4 write request is different from the data address of all AXI4 packets, and / or the identifier of the AXI4 write request is different from the identifier of all AXI4 packets. When the data address and identifier of an AXI4 write request are the same as the data address and identifier of an AXI4 data packet, the write timestamp of the AXI4 write request and the read timestamp of the corresponding AXI4 data packet are obtained, and a first interval between the write timestamp and the read timestamp is calculated. The first interval is compared with a preset first duration threshold: if the first interval is less than the first duration threshold, a successful match is obtained; otherwise, a failed match is obtained.

[0010] In one embodiment of the present invention, when the matching result is a successful match, the operation inference submodule is further configured to: Obtain the device data for the AXI4 write request, as well as the device data for the corresponding matching AXI4 data packet; Perform arithmetic and / or bitwise operations on the device data of the AXI4 write request and the device data of the AXI4 data packet to obtain the corresponding operation results, and determine the operation type based on the operation results.

[0011] In one embodiment of the present invention, when performing arithmetic operations, the operation inference submodule is further configured to calculate the difference between the device data of the AXI4 write request and the device data of the AXI4 data packet, and when the difference is a constant, determine that the operation type is an atomic operation of arithmetic operations.

[0012] In one embodiment of the present invention, when performing bit operation operations, the operation inference submodule is further configured to perform bitwise AND operation processing, bitwise OR operation processing, and XOR operation processing on the device data of the AXI4 write request and the device data of the AXI4 data packet, respectively, and determine that the operation type is an atomic operation of the corresponding logical operation when the operation result satisfies the preset mask pattern.

[0013] In one embodiment of the present invention, the request monitoring module is further configured to: Get the read timestamp of each cached AXI4 data packet, and calculate the second interval between the read timestamp and the current time node; The second interval duration is compared with a preset second duration threshold, and the corresponding AXI4 data packet is deleted when the second interval duration is greater than the second duration threshold; the second duration threshold is greater than the first duration threshold.

[0014] In one embodiment of the present invention, the bridging device further includes a response generation module, the response generation module being used for: The system receives the read response from the slave device, and when the request monitoring module sends the response back to the corresponding master device based on the identifier of the AXI4 data packet, it synchronously sends the response back to the corresponding master device based on the identifier of the read response. The system receives the write response from the slave device, converts it into an AXI4 write response, and sends it back to the corresponding master device based on the identifier of the write response. When the request monitoring module has a cached AXI4 data packet with the same data address and identifier as the AXI4 write response, the corresponding AXI4 data packet in the request monitoring module is deleted at the same time as or before sending the write response back to the corresponding master device.

[0015] The present invention also provides a system-on-a-chip, including the aforementioned bridging device, multiple master devices, and multiple slave devices, wherein the master devices adopt the AXI4 protocol, the slave devices adopt the AXI5 protocol, and the bridging device is connected between the multiple master devices and the multiple slave devices.

[0016] The beneficial effects of this invention are as follows: First, it can detect and merge potentially atomic AXI4 read / write request pairs issued by the master device, converting them into corresponding AXI5 atomic operation requests, significantly improving system performance and efficiency while maintaining functional correctness. Second, it is completely transparent to master devices using the AXI4 protocol, requiring no modification to the design or software layer of existing IP cores. When an atomic operation cannot be inferred, the bridging device degenerates into performing standard protocol conversion, ensuring that all AXI4 requests are processed correctly, thus seamlessly integrating legacy designs into systems supporting new features. Finally, the inference and conversion of atomic operations are based on explicit address matching, identifier matching, and time window rules, making the behavior predictable. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0018] In the attached diagram: Figure 1 This is a schematic diagram of a system-on-a-chip provided in an embodiment of the present invention.

[0019] The reference numerals in the attached diagram are as follows: 100, Master device; 200, Bridging device; 300, Slave device; 210, Request monitoring module; 220, Operation matching submodule; 230, Operation inference submodule; 240, Request conversion module; 250, Response generation module. Detailed Implementation

[0020] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments. Various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. In the absence of conflict, the following embodiments and features in the embodiments can be combined with each other.

[0021] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. The drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0022] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the invention. However, it will be apparent to those skilled in the art that embodiments of the invention may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the invention.

[0023] Please see Figure 1 This invention discloses a bridging device applicable to integrated circuit and chip design using different versions of system-on-chip interconnect (SoC) protocols. With the increasing number of processor cores, the new generation AXI5 protocol, supporting advanced functions such as atomic operations, is becoming increasingly popular. However, many existing SoC master devices still widely use the previous generation AXI4 protocol. This invention solves the technical challenge of efficient and seamless collaboration between devices using these two protocols through a bridging device. Specifically, the bridging device 200 can connect multiple master devices 100 and multiple slave devices 300 of an SoC, where the master devices 100 use the AXI4 protocol and the slave devices 300 use the AXI5 protocol.

[0024] In some embodiments, multiple master devices 100, such as on-chip central processing unit (CPU) cores, direct memory access (DMA) controllers, or other functional units, all initiate read / write requests in accordance with the AXI4 bus protocol.

[0025] In some embodiments, multiple slave devices 300, such as on-chip static random access memory (SRAM), dynamic random access memory (DRAM) controllers, various peripheral IP cores or other functional modules, all support the AXI5 bus protocol and are able to respond to read / write requests, including atomic operations.

[0026] In some embodiments, the bridging device 200 is physically and logically located between multiple master devices 100 and multiple slave devices 300, forming a core hub for protocol conversion and request optimization. The bridging device 200 may include a request monitoring module 210, a request conversion module 240, a response generation module 250, an operation judgment module, etc.

[0027] In some embodiments, the request conversion module 240 is used to receive the AXI4 read request from the master device 100, convert the AXI4 read request into an AXI5 read request, and then send it to the corresponding slave device 300 according to its data address.

[0028] In some embodiments, the request conversion module 240 can perform bidirectional signal mapping and request conversion between the AXI4 protocol and the AXI5 protocol, and the conversion process is performed as standard protocol behavior for both the master device 100 and the slave device 300.

[0029] In some embodiments, in the direction from master device 100 to slave device 300, the request conversion module 240 first receives a read request sent by master device 100 through the AXI4 read address channel. This read request includes standard AXI4 signals such as data address (the data address of the data to be read), identifier (the identifier of the read request, indicating which master device it originates from), and burst length and size.

[0030] In some embodiments, the request conversion module 240 parses the AXI4 read request and performs a signal mapping operation. Specifically, the request conversion module 240 converts the signals of the AXI4 read address channel, including ARADDR (the starting data address of the read request), ARID (the identifier of the read request), ARLEN (the length of the burst transfer), ARSIZE (the number of bytes transmitted in each burst transfer), ARBURST (the type of burst transfer), etc., into the signals of the AXI5 read address channel.

[0031] In some embodiments, during signal mapping, for signal fields newly introduced in the AXI5 protocol but not present in the AXI4 protocol, such as attribute fields related to atomic operations or cache consistency, the request conversion module 240 will fill them with preset default values ​​to ensure that the generated AXI5 read request is complete and valid in format. After signal mapping is completed, the request conversion module 240 forwards the data address in the converted AXI5 read request to the on-chip interconnect network and finally routes it to the corresponding slave device 300.

[0032] In some embodiments, the request conversion module 240 is further configured to receive an AXI5 data packet read from the device 300 and convert the AXI5 data packet into an AXI4 data packet.

[0033] In some embodiments, in the return direction from slave device 300 to master device 100, when slave device 300 is ready to read data, it returns an AXI5 data packet through the AXI5 read data channel. This AXI5 data packet contains device data, corresponding response signals, identifiers, data addresses, etc. The request conversion module 240 receives this AXI5 data packet and performs a reverse protocol conversion. The request conversion module 240 converts the signals of the AXI5 read data channel into the corresponding signals of the AXI4 read data channel.

[0034] In some embodiments, after the conversion is completed, the request conversion module 240 generates an AXI4 data packet that conforms to the AXI4 standard, and feeds it back to the request monitoring module 210 for further processing through the internal path of the bridging device 200, and finally feeds it back to the master device 100 that initiated the read request.

[0035] In some embodiments, the request monitoring module 210 is used to cache AXI4 data packets and feed them back to the corresponding master device 100 according to the identifier of the AXI4 data packets.

[0036] In some embodiments, the request monitoring module 210 can receive and cache the AXI4 data packet that has been converted by the request conversion module 240 and is ready to be returned to the master device 100. Specifically, when the request conversion module 240 successfully converts an AXI5 data packet returned from the device 300 into an AXI4 format data packet, the data packet is sent to the buffer pool inside the request monitoring module 210 for temporary storage.

[0037] In some embodiments, the buffer pool inside the request monitoring module 210 can be a first-in-first-out queue or a content-addressable memory structure, where each entry records information related to a complete AXI4 data packet. Each entry contains at least the following fields: the identifier in the AXI4 data packet, i.e., the RID signal; the device data in the AXI4 data packet, i.e., the RDATA signal; the data address in the AXI4 data packet; and the read timestamp when the AXI4 data packet was received. The read timestamp is generated by a globally incrementing counter to record the time when the AXI4 data packet was buffered.

[0038] In some embodiments, when it is necessary to feed data back to the master device 100, the request monitoring module 210 will feed back the identifier carried in the AXI4 data packet to the master device 100 with the same identifier, ensuring that each AXI4 data packet can be correctly routed to the master device 100 that originally initiated the read request.

[0039] In some embodiments, the response generation module 250 is used to receive the read response fed back by the slave device 300, and when the request monitoring module 210 feeds it back to the corresponding master device 100 according to the identifier of the AXI4 data packet, it synchronously feeds it back to the corresponding master device 100 according to the identifier of the read response.

[0040] In some embodiments, for a read request, the response generation module 250 receives the read response ultimately fed back by the slave device 300 through the internal path of the bridging device 200. When the request monitoring module 210 completes the lookup based on the identifier of the AXI4 data packet and is ready to feed back the AXI4 data packet to the corresponding master device 100, the response generation module 250 performs a synchronization operation based on the identifier in the read response. The response generation module 250 ensures that the read response corresponding to the AXI4 data packet, i.e., the RRESP and RLAST signals in the AXI4 protocol, can be fed back to the corresponding master device 100 at the same clock cycle or at a time that conforms to the protocol timing relationship as the AXI4 data packet.

[0041] In some embodiments, through the close cooperation between the request monitoring module 210 and the response generation module 250, the bridging device 200 can ensure that all read requests between multiple master devices 100 and multiple slave devices 300, after protocol conversion, have their AXI4 data packets and corresponding read responses accurately mapped and returned, maintaining the protocol correctness and request integrity of the entire interconnection architecture.

[0042] In some embodiments, the request monitoring module 210 is further configured to obtain the read timestamp of each cached AXI4 data packet, and calculate the second interval between the read timestamp and the current time node; compare the second interval with a preset second duration threshold, and delete the corresponding AXI4 data packet when the second interval is greater than the second duration threshold; wherein the second duration threshold is greater than the first duration threshold.

[0043] In some embodiments, the request monitoring module 210 is responsible not only for caching completed AXI4 data packets, but also for periodically cleaning up the cached AXI4 data packets. During the cleaning process, the request monitoring module 210 first obtains the current time point and calculates the difference between the read timestamp of each valid AXI4 data packet in the buffer pool and this current time point, i.e., the second interval duration. The second interval duration directly reflects how long the AXI4 data packet has resided in the buffer pool.

[0044] In some embodiments, the request monitoring module 210 internally presets a second duration threshold, which is greater than the first duration threshold used in the operation matching submodule 220 to determine the validity of the association. For example, the first duration threshold may be set to 100 clock cycles to ensure the timeliness of the association, while the second duration threshold may be set to thousands or even tens of thousands of clock cycles to determine whether an AXI4 data packet can be safely deleted. The request monitoring module 210 compares the calculated second interval duration of each AXI4 data packet with the preset second duration threshold.

[0045] In some embodiments, if the second interval duration corresponding to an AXI4 data packet exceeds a second duration threshold, it indicates that the read request has occurred for too long. Within such a long time window, at the time scale represented by the second duration threshold, it can be considered that the read response corresponding to the data packet has already been fed back to the corresponding master device 100, and the interaction cycle of the read request has long been completed. Therefore, continuing to retain this AXI4 data packet in the buffer pool would occupy storage resources. Therefore, the request monitoring module 210 will delete the corresponding AXI4 data packet from the buffer pool, releasing the storage resources it occupies for new AXI4 data packets.

[0046] In some embodiments, the operation determination module is used to receive an AXI4 write request from the master device 100, compare the data address and identifier in the AXI4 write request with the data address and identifier of each AXI4 data packet cached in the request monitoring module 210, and determine the operation type based on the comparison result. The operation determination module may include an operation matching submodule 220 and an operation inference submodule 230.

[0047] In some embodiments, the operation matching submodule 210 is further configured to receive an AXI4 write request from the master device 100 and compare the data address of the AXI4 write request with a preset address area: when the data address does not belong to the preset address area, a matching result of failure is obtained; when the data address belongs to the preset address area, the data address and identifier in the AXI4 write request are matched with the data address and identifier of each AXI4 data packet cached in the request monitoring module 210 to obtain a matching result.

[0048] In some embodiments, the operation matching submodule 220 internally includes a configurable address region mapping table that defines the range of data addresses that the bridging device 200 can attempt to perform special operation translations, i.e., a preset address region. This preset address region corresponds to the slave device 300 that supports advanced features such as atomic operations, for example, a shared memory controller. The operation matching submodule 220 first extracts the data address from the AXI4 write request and compares it with the preset address region.

[0049] In some embodiments, if the data address in the AXI4 write request does not belong to any preset address range, the operation matching submodule 220 will directly generate a matching result that fails to match. In this case, the AXI4 write request will be treated as an ordinary AXI4 write request and processed by the bridging device 200 according to the standard AXI4 to AXI5 protocol conversion process, without triggering subsequent special operation inference logic.

[0050] In some embodiments, if the data address in the AXI4 write request belongs to a certain preset address range, the operation matching submodule 220 initiates a matching process. At this time, the operation matching submodule 220 compares the data address and identifier in the AXI4 write request, namely the AWADDR and AWID signals, with the data address and identifier (i.e., the previously recorded ARADDR and ARID) corresponding to each AXI4 data packet currently cached in the buffer pool of the request monitoring module 210 one by one.

[0051] In some embodiments, a failed match result is obtained when the data address of the AXI4 write request is different from the data address of all AXI4 packets, and / or the identifier of the AXI4 write request is different from the identifier of all AXI4 packets.

[0052] In some embodiments, if the comparison result shows that the data address of the AXI4 write request is different from the data addresses of all AXI4 packets, it indicates that no previous read request for the same data address was found. In this case, regardless of whether the identifiers match, the operation matching submodule 220 immediately generates a match failure result. Similarly, even if the data addresses match, the operation matching submodule 220 continues to compare the identifiers, i.e., the AWID signal of the AXI4 write request with the corresponding identifier. If the AWID signal is different from the identifiers of all AXI4 packets, this indicates that although the data addresses are the same, the current write request and the previous read request may come from different ports or different logical threads of the master device 100, and they cannot be considered as related operations, thus also generating a match failure result.

[0053] In some embodiments, when the data address and identifier of an AXI4 write request are the same as the data address and identifier of an AXI4 data packet, the write timestamp of the AXI4 write request and the read timestamp of the corresponding AXI4 data packet are obtained, and a first interval between the write timestamp and the read timestamp is calculated; the first interval is compared with a preset first duration threshold: if the first interval is less than the first duration threshold (e.g., 100 clock cycles), a successful match is obtained; otherwise, a failed match is obtained.

[0054] In some embodiments, the initial matching condition of double consistency of data address and identifier is satisfied only when the operation matching submodule 220 finds an AXI4 data packet whose data address is exactly the same as the data address of the current AXI4 write request, and whose identifier is also exactly the same as the identifier of the current AXI4 write request. At this time, the operation matching submodule 220 obtains the read timestamp of the AXI4 data packet and generates a write timestamp for the current AXI4 write request. Both timestamps originate from the same globally incrementing counter, ensuring time comparability.

[0055] In some embodiments, the operation matching submodule 220 calculates the difference between the write timestamp and the read timestamp, i.e., the first interval duration. This first interval duration represents the number of clock cycles elapsed from the completion of a read operation at the data address to the initiation of the corresponding write operation. The operation matching submodule 220 internally presets a first duration threshold, such as 100 clock cycles. The operation matching submodule 220 compares the calculated first interval duration with this first duration threshold.

[0056] In some embodiments, if the first interval duration is less than a first duration threshold, it indicates that the AXI4 read request and the AXI4 write request are closely linked in time, forming an atomic "read-modify-write" operation sequence. Therefore, the operation matching submodule 220 ultimately generates a matching result that passes the match and outputs the matched AXI4 data packet.

[0057] In some embodiments, if the first interval duration is greater than or equal to a first duration threshold, it indicates that the read request and write request are too far apart, losing their timeliness association as atomic operations, and should be considered as two independent requests. In this case, the operation matching submodule 220 also generates a matching result that fails to match, and the AXI4 write request will be processed according to the normal process. Through strict filtering based on the three conditions of data address, identifier, and time window, the operation matching submodule 220 can accurately identify those associated read and write request pairs that truly need to be merged or transformed.

[0058] In some embodiments, the operation inference submodule 230 is used to compare the device data in the AXI4 write request with the device data in the corresponding matched AXI4 data packet when the matching result is a successful match, and determine the operation type of the AXI4 write request based on the comparison result.

[0059] In some embodiments, when the matching result is a successful match, the operation inference submodule 230 is further configured to obtain the device data of the AXI4 write request and the device data of the corresponding matched AXI4 data packet; perform arithmetic operations and / or bitwise operations on the device data of the AXI4 write request and the device data of the AXI4 data packet to obtain the corresponding operation results, and determine the operation type based on the operation results.

[0060] In some embodiments, the operation inference submodule 230 first obtains two data inputs from the operation matching submodule 220: the first is the device data in the AXI4 write request initiated by the current master device 100, i.e., the WDATA signal; the second is the device data in the previously cached AXI4 data packet matched by the operation matching submodule 220, i.e., the RDATA signal returned by the previous read operation at that data address. The operation inference submodule 230 has the ability to perform multiple operations in parallel or sequentially, and internally includes an arithmetic logic unit for performing arithmetic operations and a bit operation logic unit for performing bit operations.

[0061] In some embodiments, when performing arithmetic operations, the operation inference submodule 230 is further configured to calculate the difference between the device data of the AXI4 write request and the device data of the AXI4 data packet, and if the difference is a constant, determine that the operation type is an atomic operation of arithmetic operations.

[0062] In some embodiments, when performing arithmetic operations, the arithmetic logic unit of the operation inference submodule 230 calculates the difference between the device data of the AXI4 write request and the device data of the AXI4 data packet. Specifically, the arithmetic logic unit calculates two differences simultaneously or sequentially: subtracting the device data of the AXI4 data packet from the device data of the AXI4 write request, and subtracting the device data of the AXI4 write request from the device data of the AXI4 data packet.

[0063] In some embodiments, the operation inference submodule 230 checks the numerical characteristics of these differences. If the difference between the device data in the AXI4 write request and the device data in the AXI4 packet equals a constant C, it indicates that the operation performed by the master device 100 is to add the constant C to the read device data and then write it back to the original data address, i.e., an atomic addition operation. In this case, the operation inference submodule 230 determines that the operation type is an atomic arithmetic operation, and can further extract the constant C as the operand of this atomic operation. Similarly, if the difference between the device data in the AXI4 packet and the device data in the AXI4 write request equals a constant C, it can be inferred that it is an atomic subtraction operation.

[0064] In some embodiments, when performing bitwise operations, the operation inference submodule 230 is further configured to perform bitwise AND operation processing, bitwise OR operation processing, and XOR operation processing on the device data of the AXI4 write request and the device data of the AXI4 data packet, respectively, and determine the operation type as an atomic operation of the corresponding logical operation when the operation result satisfies the preset mask pattern.

[0065] In some embodiments, when performing bitwise operations, the bitwise operation logic unit of the operation inference submodule 230 performs various basic bitwise logic operations on the device data of the AXI4 write request and the device data of the AXI4 data packet, and obtains the corresponding operation results. The bitwise logic operation processing includes bitwise AND logic operation processing, bitwise OR logic operation processing, and bitwise XOR logic operation processing.

[0066] In some embodiments, the operation inference submodule 230 compares and analyzes these operation results with a preset mask pattern. The preset mask pattern defines the data characteristics that a specific atomic operation should produce. For example, if the result of a bitwise AND operation between the device data of an AXI4 write request and the device data of an AXI4 data packet is exactly equal to a preset mask value, it indicates that the master device 100 used the mask value to perform a bitwise AND clearing operation on the original device data in the corresponding slave device 300. If the operation result satisfies a preset mask pattern, the operation inference submodule 230 can determine that the operation type is an atomic operation of the corresponding logical operation, such as a bitwise AND atomic operation, a bitwise OR atomic operation, or an XOR atomic operation, and extract the specific operands from the mask pattern.

[0067] In some embodiments, the operation inference submodule 230 can cover common atomic operation patterns by sequentially performing arithmetic and bitwise operation detection. The operation inference submodule 230 internally includes a priority arbitration logic to sort the order of performing arithmetic operations and bitwise operations. The finally determined operation type and extracted operands are passed to the downstream request conversion module 240 as the basis for converting the original AXI4 read / write request pair into a single, efficient AXI5 atomic operation.

[0068] In some embodiments, the request conversion module 240 is further configured to determine the operation type: when the operation type is an atomic operation, the AXI4 write request is converted into the corresponding AIX5 atomic operation request; when the operation type is a non-atomic operation, the AXI4 write request is converted into the corresponding AIX5 write request. The request conversion module 240 is further configured to send the AIX5 atomic operation request or the AIX5 write request to the corresponding slave device 300 according to the data address of the AIX5 atomic operation request or the AIX5 write request.

[0069] In some embodiments, the request conversion module 240 receives a determination result from the operation inference submodule 230 regarding the operation type of the current AXI4 write request. The request conversion module 240 internally contains general logic for converting AXI4 requests to AXI5 requests and supports generating atomic operation requests defined by the AXI5 protocol.

[0070] In some embodiments, when the operation type is determined to be an atomic operation, the request conversion module 240 no longer simply treats the original AXI4 read request and AXI4 write request as two independent requests. Instead, the request conversion module 240 constructs a single AXI5 atomic operation request conforming to the AXI5 protocol specification based on the specific atomic operation type (such as addition, swap, bitwise AND, etc.) provided by the operation inference submodule 230 and the extracted operands (such as the constant for addition), combined with the control information such as the data address, identifier, and data width in the original AXI4 write request. This AXI5 atomic operation request encapsulates the complete intent of "read-modify-write," and the entire atomic operation can be completed on the slave device 300 that supports this feature with a single bus access, thereby significantly reducing bus occupancy and latency.

[0071] In some embodiments, when the operation type is determined to be a non-atomic operation, that is, when the operation matching submodule 220 determines that the match has failed, or the operation inference submodule 230 cannot infer a valid atomic operation mode, the request conversion module 240 will convert the AXI4 write request sent by the master device 100 into a standard AXI5 write request according to the conventional write request conversion rules.

[0072] In some embodiments, regardless of whether an AXI5 atomic operation request or an AXI5 write request is generated, the request conversion module 240 will ultimately send the request accurately to the corresponding slave device 300 based on the data address in the request and through the internal routing mechanism of the bridging device 200.

[0073] In some embodiments, the response generation module 250 is further configured to receive the write response fed back by the slave device 300, convert it into an AXI4 write response, and feed it back to the corresponding master device 100 according to the identifier of the AXI4 write response.

[0074] In some embodiments, the response generation module 250 is further configured to process write responses from the slave device 300, completing the final loop of the request. After the slave device 300 processes the AXI5 atomic operation request or AXI5 write request sent by the request conversion module 240, it returns a write response. The response generation module 250 receives this write response from the slave device 300 and converts it into an AXI4 write response. For the write response to an atomic operation request, the response may contain status information indicating whether the atomic operation was successfully completed; for the response to a normal write request, it mainly indicates whether the data write was successful.

[0075] In some embodiments, the response generation module 250 accurately feeds back the identifier carried in the write response to the corresponding master device 100. This identifier is maintained throughout the request process: initially issued by the master device 100 in the AXI4 write request, correctly transmitted to the AXI5 write request after being converted by the bridging device 200, and finally returned from the write response of the slave device 300. Using this identifier, the response generation module 250 can correctly route the write response back to the master device 100 that initially initiated the write request, and complete the final handshake with the master device 100 through the write response channel according to the timing requirements of the AXI4 protocol.

[0076] In some embodiments, when there is a cached AXI4 data packet in the request monitoring module 210 with the same data address and identifier as the AXI4 write response from the slave device 300, the response generation module 250 needs to delete the corresponding AXI4 data packet in the request monitoring module 210 at the same time as or before sending the AXI4 write response to the corresponding master device.

[0077] In some embodiments, the example is taken where the master device 100 (e.g., a CPU core) needs to increment the data stored at data address 0x1000. The value at this data address in the slave device 300's memory is 5. First, the master device 100 issues an AXI4 read request, where the data address ARADDR is 0x1000 and the identifier ARID is 1. The request conversion module 240 receives this AXI4 read request, performs basic address mapping and protocol signal conversion, and converts it into an AXI5 read request, keeping the data address and identifier unchanged. This request is then passed to the slave device 300, which supports the AXI5 protocol. Upon receiving this read request, the slave device 300 reads the data 5 from data address 0x1000 and returns the read data RDATA=5 and its read response to the master device 100 via the bridging device 200.

[0078] In some embodiments, the request monitoring module 210 caches the corresponding AXI4 data packet in its internal buffer pool at the same time the AXI4 read request is completed and the data is returned. The AXI4 data packet contains at least: a data address addr of 0x1000, an identifier id of 1, device data rdata of 5, and a read timestamp T1 that captures the moment.

[0079] In some embodiments, the master device 100 subsequently initiates a corresponding AXI4 write request with a data address AWADDR of 0x1000, an identifier AWID of 1, and device data WDATA of 6 to be written. The operation matching submodule 220 detects that the address 0x1000 of the write request is located in a preset address region, and then performs a lookup in the buffer pool.

[0080] In some embodiments, the operation matching submodule 220 detects an AXI4 data packet whose data address is exactly the same as the data address of the AXI4 write request, and whose identifier is also 1, satisfying the dual matching condition of physical address and identifier. Subsequently, the operation matching submodule 220 obtains the write timestamp T2, calculates the first interval duration between the write timestamp T2 and the read timestamp T1. Assuming the first interval duration is 10 clock cycles, and the preset first duration threshold is 100 cycles, the AXI4 write request is considered to be highly correlated with the previous AXI4 read request within the valid time window, and the match is successful, thereby triggering the subsequent atomic operation conversion process.

[0081] In some embodiments, the operation inference submodule 230 obtains device data 5 from the matched AXI4 data packet and device data 6 from the current AXI4 write request. The operation inference submodule 230 performs a difference calculation to obtain a difference of 1. Since the difference is a constant 1, the operation inference submodule 230 infers that the operation type performed by the master device 100 is addition in arithmetic atomic operations, i.e., ATOMIC_ADD, and extracts the operand as 1.

[0082] In some embodiments, the request conversion module 240 converts the original AXI4 write request into an AXI5 atomic operation request: ATOMIC_ADD, with a target address of 0x1000 and an operand of 1, based on the operation type ATOMIC_ADD and operand 1 determined by the operation inference submodule 230, and then sends it to the slave device 300.

[0083] In some embodiments, regarding response processing, for the first AXI4 read request issued by the master device 100, the bridging device 200 directly passes the read response RRESP from the slave device 300 to the master device 100. For the second write request that is converted into an atomic operation, the request conversion module 240 needs to appropriately convert the AXI5 write response returned by the slave device 300 before feeding it back to the master device 100. Specifically, if the AXI5 write response returned by the slave device 300 is EXOKAY, the request conversion module 240 converts it to the OKAY status defined by the AXI4 protocol and returns it to the master device 100; if it returns SLVERR or DECERR, it is returned directly with the same SLVERR or DECERR status. If the AXI4 write request is not determined to be an atomic operation, that is, it is sent as a normal AXI5 write request, then the write response status code returned by the slave device 300 (whether OKAY, SLVERR, or DECERR) will be returned to the master device 100 unchanged. Through this series of steps, the bridging device 200 successfully identified and optimized a "read-add-write" operation sequence, converting it into a single efficient AXI5 atomic operation, while correctly handling all requests and responses and maintaining transparency of protocol behavior to the master device 100.

[0084] The present invention also discloses a system-on-a-chip, which may include the bridging device 200, multiple master devices 100, and multiple slave devices 300 in the above embodiments. The master devices 100 adopt the AXI4 protocol, the slave devices 300 adopt the AXI5 protocol, and the bridging device 200 is connected between the multiple master devices 100 and the multiple slave devices 300.

[0085] As can be seen, the above solution firstly detects and merges potentially atomic AXI4 read / write request pairs issued by the master device, converting them into corresponding AXI5 atomic operation requests, significantly improving system performance and efficiency while maintaining functional correctness. Secondly, it is completely transparent to master devices using the AXI4 protocol, requiring no modification to the design or software layer of existing IP cores. When an atomic operation cannot be inferred, the bridging device degenerates into performing standard protocol conversion, ensuring that all AXI4 requests are processed correctly, thus seamlessly integrating legacy designs into systems supporting new features. Finally, the inference and conversion of atomic operations are based on explicit address matching, identifier matching, and time window rules, making the behavior predictable.

[0086] The above embodiments are merely illustrative of the principles and effects of the present invention and are not intended to limit the invention. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in the present invention should still be covered by the claims of the present invention.

Claims

1. A bridging device, characterized in that, A bridging device is connected between multiple master devices and multiple slave devices of a system-on-a-chip, wherein the master devices use the AXI4 protocol and the slave devices use the AXI5 protocol; the bridging device includes: The request conversion module is used to receive AXI4 read requests from the master device, convert the AXI4 read requests into AXI5 read requests, and send them to the corresponding slave device according to their data addresses; the request conversion module is also used to receive AXI5 data packets read from the slave device and convert the AXI5 data packets into AXI4 data packets; The request monitoring module is used to cache AXI4 data packets and send them back to the corresponding master device based on the identifier of the AXI4 data packets; The operation judgment module is used to receive the AXI4 write request from the master device, compare the data address and identifier in the AXI4 write request with the data address and identifier of each AXI4 data packet cached in the request monitoring module, and determine the operation type based on the comparison result. The request conversion module is also used to determine the operation type: when the operation type is an atomic operation, the AXI4 write request is converted into the corresponding AIX5 atomic operation request; when the operation type is a non-atomic operation, the AXI4 write request is converted into the corresponding AIX5 write request. The request conversion module is also used to send the request to the corresponding slave device based on the data address of the AIX5 atomic operation request or the AIX5 write request.

2. The bridging device according to claim 1, characterized in that, The operation determination module includes: The operation matching submodule is used to receive AXI4 write requests from the master device and match the data address and identifier in the AXI4 write request with the data address and identifier of each AXI4 data packet cached in the request monitoring module to obtain the matching result; The operation inference submodule is used to compare the device data in the AXI4 write request with the device data in the corresponding matching AXI4 data packet when the matching result is a successful match, and to determine the operation type of the AXI4 write request based on the comparison result.

3. The bridging device according to claim 2, characterized in that, The operation matching submodule is also used to receive AXI4 write requests from the master device and compare the data address of the AXI4 write request with a preset address area: When the data address does not belong to the preset address area, a matching result of failure is obtained; When the data address belongs to the preset address range, the data address and identifier in the AXI4 write request are matched with the data address and identifier of each AXI4 data packet cached in the request monitoring module.

4. The bridging device according to claim 3, characterized in that, When the data address belongs to a preset address range, the operation matching submodule is further configured to match the data address and identifier of the AXI4 write request with the data address and identifier of each AXI4 data packet cached in the request monitoring module: A match failure result is obtained when the data address of the AXI4 write request is different from the data address of all AXI4 packets, and / or the identifier of the AXI4 write request is different from the identifier of all AXI4 packets. When the data address and identifier of an AXI4 write request are the same as the data address and identifier of an AXI4 data packet, the write timestamp of the AXI4 write request and the read timestamp of the corresponding AXI4 data packet are obtained, and a first interval between the write timestamp and the read timestamp is calculated. The first interval is compared with a preset first duration threshold: if the first interval is less than the first duration threshold, a successful match is obtained; otherwise, a failed match is obtained.

5. The bridging device according to claim 2, characterized in that, When the matching result is a successful match, the operation inference submodule is further used for: Obtain the device data for the AXI4 write request, as well as the device data for the corresponding matching AXI4 data packet; Perform arithmetic and / or bitwise operations on the device data of the AXI4 write request and the device data of the AXI4 data packet to obtain the corresponding operation results, and determine the operation type based on the operation results.

6. The bridging device according to claim 5, characterized in that, When performing arithmetic operations, the operation inference submodule is also used to calculate the difference between the device data of the AXI4 write request and the device data of the AXI4 data packet, and when the difference is a constant, determine that the operation type is an atomic operation of arithmetic.

7. The bridging device according to claim 5, characterized in that, When performing bitwise operations, the operation inference submodule is also used to perform bitwise AND, bitwise OR, and XOR operations on the device data of the AXI4 write request and the device data of the AXI4 data packet, respectively, and determine the operation type as the atomic operation of the corresponding logical operation when the operation result meets the preset mask pattern.

8. The bridging device according to claim 1, characterized in that, The request monitoring module is also used for: Get the read timestamp of each cached AXI4 data packet, and calculate the second interval between the read timestamp and the current time node; The second interval duration is compared with a preset second duration threshold, and the corresponding AXI4 data packet is deleted when the second interval duration is greater than the second duration threshold; the second duration threshold is greater than the first duration threshold.

9. The bridging device according to claim 1, characterized in that, The bridging device further includes a response generation module, which is used for: The system receives the read response from the slave device, and when the request monitoring module sends the response back to the corresponding master device based on the identifier of the AXI4 data packet, it synchronously sends the response back to the corresponding master device based on the identifier of the read response. The system receives the write response from the slave device, converts it into an AXI4 write response, and sends it back to the corresponding master device based on the response identifier. If the request monitoring module has a cached AXI4 data packet with the same data address and identifier as the AXI4 write response, the corresponding AXI4 data packet in the request monitoring module is deleted at the same time as or before the write response is sent back to the corresponding master device.

10. A system-on-a-chip, characterized in that, The device includes a bridging device as described in any one of claims 1 to 9, a plurality of master devices, and a plurality of slave devices, wherein the master devices adopt the AXI4 protocol, the slave devices adopt the AXI5 protocol, and the bridging device is connected between the plurality of master devices and the plurality of slave devices.

Images