Multicast AXI crossbar switch design method and device adaptive to ML accelerator
By designing a multicast AXI cross switch adapted to ML accelerators, the problem of insufficient communication link bandwidth in large-scale parallel ML accelerators was solved, achieving efficient multicast function support and transmission efficiency improvement, while reducing hardware resource overhead and power consumption.
Patent Information
- Application Number
- CN202511503246.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-21
- Publication Date
- 2026-02-03
AI Technical Summary
Existing technologies in massively parallel ML accelerators struggle to meet the bandwidth requirements of communication links, and the simplified cache consistency function leads to excessive storage and communication pressure, while lacking effective multicast support.
Design a multicast AXI cross switch adapted to ML accelerators. The AXI_Demux module splits write requests and uses an address mapping table to match requests to corresponding slaves. When defining multicast transactions, the aw_user channel is used to transmit the multicast mask, limiting the multicast area to an exponential size of 2. The target area is determined by an encoding formula. The AXI_Demux module processes write responses, and the AXI_Mux module ensures orderly transmission.
It achieves efficient and flexible multicast support, reduces hardware resource overhead, improves transmission efficiency and performance, and controls power consumption and latency.
Smart Images
Figure CN121455869A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The application relates to the field of on-chip communication technology, and particularly provides a multicast AXI crossbar design method and device suitable for an ML accelerator. BACKGROUND
[0002] In recent years, with the continuous development of the field of artificial intelligence, in order to meet the computing requirements of modern machine learning (ML) workloads, various special-purpose / general-purpose accelerators have emerged, and the overall computing power and functional coverage of chips are improved by constructing a multi-core system. However, to convert the theoretical peak performance into actual application performance, one of the keys is to keep all coprocessor sub-kernels busy in most periods of system runtime, which further poses a great challenge to the communication link of the on-chip interconnection, and the communication link needs to provide sufficient bandwidth to meet the data transmission requirements of the coprocessor sub-kernel.
[0003] In order to reduce the pressure on on-chip storage and communication links, one of the common deployment methods is to reuse data on-chip as much as possible, and to reduce data traffic by using the data reuse mode of calculation. Taking the core operator matrix multiplication C=AxB of the ML workload as an example: the row blocks of matrix A are loaded into different calculation arrays, and the column blocks of matrix B need to be multicast to all calculation arrays. In many scenarios of ML workloads, multicast communication has been proven to be extremely beneficial, and many researchers and manufacturers have started to research on-chip networks that support multicast.
[0004] However, most of the existing research works mainly continue the design concept of the multi-core CPU era, focusing on the design of cache-consistent shared storage systems, and the multicast function serves the implementation of the consistency protocol. However, for large-scale parallel ML accelerators, the cache consistency function is usually simplified in PPA consideration, and storage management is relied on software. There are relatively few studies on the scalability of large-scale ML accelerators. SUMMARY
[0005] The application is aimed at the deficiencies of the prior art, and provides a multicast AXI crossbar design method suitable for an ML accelerator, which has strong practicability.
[0006] The further technical task of the application is to provide a multicast AXI crossbar design device suitable for an ML accelerator, which is reasonable in design and safe in use.
[0007] The technical scheme adopted by the application to solve the technical problems is:
[0008] A multicast AXI crossbar design method suitable for ML accelerator, AXI transmission is initiated by the host, AXI transmission is responded by the slave, in multicast task, one write request of the host is distributed to multiple slaves, each host interface is connected to an AXI_Demux module for write request splitting, and each slave interface is connected to an AXI_Mux module to be connected with different AXI hosts;
[0009] The whole crossbar is configured with an address mapping table Address Map, and the complete address space is divided into a plurality of address intervals, and each address space is mapped to a slave;
[0010] When a host initiates a write request, the target address is compared with the address mapping rule in the address mapping table, so that the request is matched to the corresponding slave, and the AXI related bus signals are transmitted to the corresponding slave as they are, and for multicast transactions, only the AW, W and B channels of AXI are involved.
[0011] Further, when defining a multicast transaction, a write request must carry multiple target addresses, and the specific operation is as follows:
[0012] The multicast mask is transmitted based on the user extension signal line aw_user channel preset by AXI, if a bit in the mask is 1, the corresponding bit of the address is interpreted as X, that is, 0 and 1 are both target addresses, and the mask should be the same as the bit width of the address or multicast available address.
[0013] Further, the multicast area in the network communication mode is limited to:
[0014] (1) The size of the area must be an exponential of 2;
[0015] (2) The start address of the area must be an integer multiple of its size.
[0016] Further, each slave or multicast target address is encoded in the form of {mask, address} by the following formula:
[0017] address=start_addr;
[0018] mask=end_addr-start_addr-1;
[0019] Where start_addr and end_addr are the start address in the traditional address representation method, and the {mask, address} binary tuple of all multicast areas is stored in each AXI_Demux module.
[0020] Further, when a multicast request occurs, the AXI_Demux module first converts the multicast target address into the form of {req.mask, req.address}, and determines the multicast target through the following formula:
[0021] mask_bit = req.mask | region.mask, as long as one side is don't care, it is regarded as X;
[0022] match_bit = ~(req.addr ^ region.mask), find the number of matching bits in the address;
[0023] select[region.idx] = &(mask_bits | match_bits), remove the bits masked (not cared) and all bits match, then regard the region numbered as region idx as the target region of the current multicast, and the {mask, address} sent to the region is:
[0024] Further, if all bits of the address, except the number of don't care bits, are matched, it means that the region idx corresponds to the target region of the current multicast, and the {mask, address} sent to the region is:
[0025] aw_user = out.mask = req.mask & region.mask;
[0026] aw_addr = (~req.mask & req.addr) | (req.mask & rule.addr);
[0027] When the request and the region mask are both don't care, the bit can be regarded as don't care;
[0028] For the multicast address, if a bit is ignored in the request, it is in accordance with the address bit of the region;
[0029] If it is not ignored, it is in accordance with the address bit of the request.
[0030] Further, the AXI_Demux module is also responsible for multiplexing the slave write response channel (B) back to the host, and the AXI_Demux will block the AW transaction with the same AXI ID as any uncompleted transaction, except that the target is the same slave; at the same time, a table entry is maintained to record the transaction completion status of each AXI ID involved slave.
[0031] Further, in order to avoid deadlock and generate high logical design overhead, it is provided that:
[0032] Unicast transactions and multicast transactions cannot exist simultaneously;
[0033] A multicast must wait until all outstanding unicast transactions are completed, and vice versa;
[0034] If a multicast transaction is to be initiated, the target region of the multicast must be the same.
[0035] Further, the AXI Mux module is responsible for orderly issuing transmission requests of each master to the slave, and when the unicast logic and the multicast logic are performed simultaneously, the priority of the multicast logic is high.
[0036] A multicast AXI crossbar design device adapted to an ML accelerator, comprising at least one memory and at least one processor;
[0037] The at least one memory is configured to store a machine-readable program;
[0038] The at least one processor is configured to invoke the machine-readable program to execute a multicast AXI crossbar design method adapted to an ML accelerator.
[0039] Compared with the prior art, the multicast AXI crossbar design method and device adapted to an ML accelerator has the following outstanding beneficial effects:
[0040] The application designs a highly scalable, flexible and low-overhead address encoding scheme, and adapts to the AXI protocol. At the same time, a detailed adaptive hardware module component design is given to realize the multicast function with an advantage of hardware resources, which guarantees the performance while bringing significant transmission efficiency improvement and multicast function support, and controls the power consumption and delay overhead in an acceptable range. BRIEF DESCRIPTION OF DRAWINGS
[0041] In order to more clearly illustrate the technical solutions in the embodiments of the application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiment or prior art description. Obviously, the drawings in the following description are some embodiments of the application, and for those skilled in the art, other drawings can also be obtained without creative labor based on these drawings.
[0042] Figure 1 An AXI crossbar overview diagram in a multicast AXI crossbar design method adapted to an ML accelerator;
[0043] Figure 2 An address interval representation schematic diagram in a multicast AXI crossbar design method adapted to an ML accelerator;
[0044] Figure 3Demux address encoding and multicast enable logic diagram in a multicast AXI crossbar design method for adapting ML accelerator
[0045] Figure 4 AXI Demux module aw channel handshake logic diagram in a multicast AXI crossbar design method for adapting ML accelerator
[0046] Figure 5 AXI Demux module b channel handshake logic diagram in a multicast AXI crossbar design method for adapting ML accelerator
[0047] Figure 6 Mux module logic diagram in a multicast AXI crossbar design method for adapting ML accelerator DETAILED DESCRIPTION
[0048] In order to make the personnel in the art better understand the scheme of the present application, the present application will be further described in detail below in combination with specific embodiments. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application.
[0049] A preferred embodiment is given below:
[0050] The multicast AXI crossbar design method for adapting ML accelerator in the embodiment has a clear division of master and slave for the access device of AXI bus by AXI protocol, and the AXI transmission is initiated by the master and responded by the slave.
[0051] In the multicast task, a write request of the master is distributed to multiple slaves (as there is almost no demand for multicast read in actual application, the present scheme does not discuss the AR and R channels of AXI), therefore, as shown in Figure 1 the present method connects each master interface to an AXI Demux module for write request splitting, and connects each slave interface to an AXI Mux module to be connected with different AXI masters.
[0052] The whole crossbar is configured with address map, and the complete address space is divided into several address intervals, each address space being mapped to a slave.
[0053] When a master initiates a write request, the target address is compared with the address mapping rules in the Address Map, so as to match the request to the corresponding slave. The AXI related bus signals are transmitted to the corresponding slave as they are, and for multicast transactions, only the AXI AW, W and B channels are involved.
[0054] However, if a multicast transaction is to be defined, a write request must carry multiple target addresses, which is not consistent with the design of the AXI single-channel aw_addr. Therefore, the AXI protocol is extended without breaking backward compatibility, and the specific extension is as follows:
[0055] The application transmits a multicast mask through the AXI preset user extension signal line aw_user channel. If a bit in the mask is 1, the corresponding bit of the address is interpreted as X, i.e., 0 and 1 are both target addresses, and the mask should be as wide as the address or the multicast available address as much as possible.
[0056] As Figure 2 It is shown how the method represents the address interval of the multicast region through the two AXI inherent signals aw_addr and aw_user. Although the proposed address encoding method cannot represent all possible address sets, it is very suitable for large-scale parallel accelerator design. When the total size of the address space increases, the growth rate of the multicast encoding scale presents a logarithmic growth, and is independent of the scale of the multicast target region set. However, the encoding method that can represent all address sets not only has a linear growth of the encoding scale with the increase of the address space, but also has an increase of the encoding scale with the increase of the scale of the target region set.
[0057] The method focuses on the scalability of the encoding method, and considering that large-scale ML accelerators usually deploy operators by region, the encoding limitation brought by the scheme will be further diluted.
[0058] The proposed multicast encoding strategy has limitations for the multicast region:
[0059] (1) The size of the region must be an exponential of 2;
[0060] (2) The start address of the region must be an integer multiple of its size.
[0061] Based on the encoding method, each slave in the method, or the multicastable target address, can be encoded in the form of {mask, address} through the following formula:
[0062] address = start_addr;
[0063] mask = end_addr - start_addr - 1;
[0064] Where start_addr and end_addr are the start address in the traditional address representation. All the {mask, address} tuples of the multicastable regions are stored in each AXI_Demux module.
[0065] When a multicast request occurs, AXI_Demux will first convert the multicast target address into the form of {req.mask, req.address}, and determine the multicast target by the following equation:
[0066] mask_bit = req.mask | region.mask (as long as one of them is don't care, it is regarded as X);
[0067] match_bit = ~(req.addr ^ region.mask) (find the number of matching bits in the address);
[0068] select[region.idx] = &(mask_bits | match_bits);
[0069] If all the bits of the address, except the number of don't care bits, are matched, it means that the region corresponding to region.idx is the target region of the current multicast. The {mask, address} sent to this region is:
[0070] aw_user = out.mask = req.mask & region.mask;
[0071] aw_addr = (~req.mask & req.addr) | (req.mask & rule.addr);
[0072] When the mask of the request and the mask of the region are both don't care, the bit can be regarded as don't care.
[0073] For the multicast address, if a bit is ignored in the request, it follows the bit of the address of the region; if it is not ignored, it follows the bit of the address of the request.
[0074] Thus, the target region of the multicast is determined, and the additional AXI signals required for the multicast are also calculated.
[0075] As shown in FIG. 1, Figure 3 the generation of the address decoding logic and the multicast enable logic is shown, Figure 4 the handshake logic of the aw channel in the multicast state is shown, Figure 5The processing logic of the b channel is shown, where the left side signals are master side signals, the right side signals are slave side signals, and the up and down side signals are internal signals of the Demux.
[0076] The AXI Demux module is also responsible for multiplexing the slave write response channel (B) back to the master. Since B responses from different slaves can arrive out of order, the AXI Demux module will block AW transactions with the same AXI ID as any outstanding transaction unless they are targeting the same slave (since AXI naturally maintains the order of execution of IDs in the same slave), while maintaining a table entry to record the transaction completion status of each AXI ID involved slave.
[0077] In addition, in order to avoid deadlock and possible high logical design overhead, the application provides:
[0078] Unicast transactions and multicast transactions cannot exist at the same time;
[0079] Multicast must be initiated after all outstanding unicast transactions are completed, and vice versa.
[0080] If an outstanding multicast transaction is to be initiated, the target region of the multicast must be the same.
[0081] As shown in Figure 6 The AXI Mux module is mainly responsible for sequentially issuing transmission requests of each master to the slave. The upper half mainly includes unicast logic, and the lower half includes multicast logic. The two cannot be performed at the same time, and the multicast has higher priority.
[0082] Based on the above method, the multicast AXI crossbar design device adapted to the ML accelerator in the embodiment comprises at least one memory and at least one processor.
[0083] The at least one memory is used to store a machine readable program.
[0084] The at least one processor is used to call the machine readable program and execute a multicast AXI crossbar design method adapted to the ML accelerator.
[0085] The processor can be a central processing unit (CPU), and can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), ready-to-program gate arrays (FPGAs), or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. The processor can be a microprocessor or any conventional processor.
[0086] The memory can be used to store computer programs and / or modules, and the processor realizes various functions of the electronic device by running or executing the computer programs and / or modules stored in the memory, and calling data stored in the memory. The memory can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, at least one application required by a function, etc.; and the data storage area can store data created according to the use of the terminal, etc. In addition, the memory can also include a high-speed random access memory, and can also include a non-volatile memory, such as a hard disk, a memory, a plug-in hard disk, a smart memory card (SMC), a secure digital (SD) card, a flash memory card, at least one disk storage device, a flash memory device, or other volatile solid-state memory devices.
[0087] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that: it can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for part or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.
Claims
1. A design method for a multicast AXI cross switch adapted to ML accelerators, characterized in that, The host initiates an AXI transmission, and the slave responds to the AXI transmission. In a multicast task, a write request from the host is distributed to multiple slaves. Each host interface is connected to an AXI_Demux module to split the write request, and each slave interface is connected to an AXI_Mux module to connect to different AXI hosts. The entire crossbar switch is configured with an address map, and the complete address space is divided into several address ranges, with each address space mapped to a slave device. When a host initiates a write request, the target address is compared with the address mapping rules in the address mapping table, thereby matching the request to the corresponding slave. The AXI related bus signals are transmitted to the corresponding slave as is. For multicast transactions, only the AXI AW, W and B channels are involved.
2. The multicast AXI cross switch design method for adapting ML accelerators according to claim 1, characterized in that, When defining a multicast transaction, a write request must carry multiple target addresses. The specific operation is as follows: The multicast mask is transmitted based on the user extension signal line aw_user channel of AXI. If a bit in the mask is 1, the corresponding bit of the address is interpreted as X, that is, 0 and 1 are both the target address. The mask should have the same bit width as the address or the multicast available address.
3. The multicast AXI cross switch design method for adapting ML accelerators according to claim 2, characterized in that, In network communication modes, the multicast area is limited as follows: (1) The size of the region must be a power of 2; (2) The starting address of the region must be an integer multiple of its size.
4. The multicast AXI cross switch design method for adapting ML accelerators according to claim 3, characterized in that, Each slave device, or multicast target address, is encoded using the following formula to obtain the form {mask, address}: address = start_addr; mask=end_addr–start_addr–1; Here, start_addr and end_addr are the starting addresses in the traditional address representation method, and the {mask, address} tuples of all multicast regions are stored in each AXI_Demux module.
5. A multicast AXI cross switch design method for adapting ML accelerators according to claim 4, characterized in that, When a multicast request occurs, the AXI_Demux module first converts the multicast target address into the form {req.mask, req.address}, and determines the multicast target using the following formula; mask_bit = req.mask|region.mask, if one party doesn't care, it is considered X; match_bit = ~(req.addr^region.mask), finds the matching bit in the address; The `select[region.idx]=&(mask_bits|match_bits)` option removes the mask bits (which are missing) and matches all other bits. This means that the region with the ID `regionidx` is selected.
6. A multicast AXI cross switch design method for adapting ML accelerators according to claim 5, characterized in that, If all bits in the address, excluding the "Don't care" bits, match, then the region corresponding to region.idx is the target region for the current multicast, and the {mask, address} sent to that region is: aw_user=out.mask=req.mask®ion.mask; aw_addr=(~req.mask&req.addr)|(req.mask&rule.addr); This bit can only be considered "Don't care" if both the request and the region's mask are "Don't care"; For multicast addresses, if a bit is omitted in the request, the address bits of the region shall apply. If not ignored, then the requested address bits will be used.
7. A multicast AXI cross switch design method for adapting ML accelerators according to claim 6, characterized in that, The AXI_Demux module is also responsible for reusing the slave's write response channel (B) back to the master. AXI_Demux will block any AW transaction with the same AXI ID as any incomplete transaction, except that the target is the same slave. At the same time, it maintains an entry to record the transaction completion status of the slave involved in each AXI ID.
8. A multicast AXI cross switch design method for adapting ML accelerators according to claim 7, characterized in that, To avoid deadlocks and excessive logic design overhead, the following is stipulated: Unicast and multicast transactions cannot coexist. Multicast can only be initiated after all unfinished unicast transactions are completed, and vice versa; To initiate an outstanding multicast transaction, the target regions for the multicast must be the same.
9. A multicast AXI cross switch design method for adapting ML accelerators according to claim 8, characterized in that, The AXI Mux module is responsible for distributing the transmission requests from each master to the slave in an orderly manner. When unicast and multicast logic are performed simultaneously, the multicast logic has higher priority.
10. A multicast AXI cross switch design device adapted to ML accelerators, characterized in that, include: At least one memory and at least one processor; The at least one memory is used to store a machine-readable program; The at least one processor is configured to invoke the machine-readable program to perform the method according to any one of claims 1 to 9.