Concurrent data transmission method, remote control module and SOC chip
Patent Information
- Application Number
- CN202611234788.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-08-14
- Publication Date
- 2026-10-30
AI Technical Summary
[0004]但串行处理模式会大幅拖慢初始化速度;系统运行期间,多核CPU对同一IP的不同设备进行配置时,可能会导致多设备配置相互阻塞,降低系统运行性能;并且在芯片量产测试阶段,需对大量芯片执行寄存器配置与功能验证,过长的访问耗时会直接增加测试时间,进而推高芯片量产的测试成本
[0009]本申请实施例提供的并发数据控制方法、远程控制模块以及SOC芯片,通过将远程控制模块内部的从数据接收到返回响应的一整个状态机拆分成数据接收状态机和返回响应状态机,实现了远程控制模块的并发数据控制功能,使系统管理总线即使没有接收到上一笔数据的响应信号也可以发送下一笔数据给远程控制模块,并对同一个IP的其它设备进行读写操作,大大节省了寄存器的配置效率;同时通过记录每一笔数据的ID信息,确定IP返回的响应信号对应的访问请求,确保响应数据的准确性,进而支持系统管理总线的并发传输,使得软件在配置各个IP寄存器的时候可以并行发送数据访问,优化了整体系统性能,节省了测试成本。
Smart Images

Figure CN123011558A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of chip technology, and more specifically, to a concurrent data transmission method, a remote control module, and a SOC chip. Background Technology
[0002] With the continuous iteration of integrated circuit technology and the increasing richness of chip functions, the integration scale of System-on-Chip (SoC) continues to expand. The number and types of intellectual property cores (IPs) integrated within a single SoC have increased significantly, and different IPs have differentiated functional characteristics and configuration requirements. To achieve unified scheduling and independent management of multiple IPs, the industry generally adds a remote control module (RCM) between each IP and the System Management Bus (SMN). The Central Processing Unit (CPU) can configure the registers of the RCM via the System Management Bus, thereby completing operations such as security management, clock control, power-on / power-off, and memory repair of the target IP.
[0003] In the current data transmission architecture based on remote control modules, a single remote control module can connect to multiple devices with the same IP address. However, the state machine design of existing remote control modules is a serial processing mode. The module can only receive one data access from the system management bus at a time and must wait for the access completion response signal to be returned to the bus before it can receive the next transmission command, thereby ensuring the security and stability of the access.
[0004] However, serial processing mode will significantly slow down the initialization speed; during system operation, when multiple core CPUs configure different devices of the same IP, it may cause multiple device configurations to block each other, reducing system performance; and during the chip mass production testing phase, a large number of chips need to perform register configuration and functional verification, and excessive access time will directly increase the test time, thereby increasing the test cost of chip mass production. Summary of the Invention
[0005] In view of this, the purpose of this application is to provide a concurrent data control method, a remote control module, and a SOC chip, which can solve at least one of the above-mentioned problems.
[0006] In a first aspect, embodiments of this application provide a concurrent data transmission method applied to a System-on-a-Chip (SOC) chip. The SOC chip includes a system management bus, multiple remote control modules, and multiple IP devices under the same IP connected to each remote control module. Each remote control module internally configures an independently operating data receiving state machine and a response return state machine. The method includes: The data receiving state machine receives a first data access request from the system management bus. After passing the security check, it sends the first access data corresponding to the first data access request to the first IP device and saves the first ID information of the first access data. The first data access request is a register access request initiated by the first CPU to the first IP device under the target IP. The response return state machine receives the first response data returned by the first IP device, matches the ID information carried in the first response data with the stored first ID information, and returns the first response data to the system management bus after the ID information is successfully matched. Before the response return state machine returns the first response data, the data receiving state machine continues to receive the second data access request from the system management bus. After passing the security check, it sends the second access data corresponding to the second data access request to the second IP device and saves the second ID information of the second access data. The second data access request is a register access request initiated by the second CPU for the second IP device under the same target IP.
[0007] Secondly, this application embodiment also provides a remote control module, including: an ID storage module, a data receiving state machine and a response return state machine that operate independently of each other, and a security check module. The output terminal of the security check module is connected to the input terminal of the data receiving state machine. The output terminal of the data receiving state machine is connected to the ID storage module and the IP device respectively. The response return state machine is connected to the ID storage module, the IP device and the system management bus respectively. The data receiving state machine receives a first data access request from the system management bus. After passing the security check by the security check module, it sends the first access data corresponding to the first data access request to the first IP device and saves the first ID information of the first access data to the ID storage module. The first data access request is a register access request initiated by the first CPU to the first IP device under the target IP. The response return state machine receives the first response data returned by the first IP device, matches the ID information carried in the first response data with the stored first ID information, and returns the first response data to the system management bus after the ID information is successfully matched. Before the response return state machine returns the first response data, the data receiving state machine continues to receive the second data access request from the system management bus. After the security check by the security check module passes the security check, the second access data corresponding to the second data access request is sent to the second IP device, and the second ID information of the second access data is saved to the ID storage module. The second data access request is a register access request initiated by the second CPU for the second IP device under the same target IP.
[0008] Thirdly, embodiments of this application also provide a SOC chip, including at least one CPU, a system management bus, a plurality of remote control modules as described in claim 8, and a plurality of IP devices under the same IP connected to each remote control module, wherein the at least one CPU communicates with the remote control module through the system management bus.
[0009] The concurrent data control method, remote control module, and SOC chip provided in this application embodiment achieve concurrent data control functionality by splitting the entire state machine within the remote control module—from data reception to response—into a data reception state machine and a response state machine. This allows the system management bus to send the next data to the remote control module even without receiving a response signal from the previous data, and to perform read / write operations on other devices with the same IP, significantly improving register configuration efficiency. Simultaneously, by recording the ID information of each data entry, the access request corresponding to the IP's response signal is determined, ensuring the accuracy of the response data and supporting concurrent transmission on the system management bus. This allows the software to send data access in parallel when configuring various IP registers, optimizing overall system performance and saving testing costs.
[0010] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description
[0011] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0012] Figure 1 A flowchart illustrating a concurrent data transmission method provided in an embodiment of this application; Figure 2 A flowchart illustrating another concurrent data transmission method provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a remote control module provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a SOC chip provided in an embodiment of this application. Detailed Implementation
[0013] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. Based on the embodiments of this application, every other embodiment obtained by those skilled in the art without inventive effort falls within the scope of protection of this application.
[0014] This application provides a concurrent data transmission method applied to a System-on-a-Chip (SOC) chip. The SOC chip includes a system management bus, multiple remote control modules, and multiple IP devices under the same IP address connected to each remote control module. Each remote control module internally has a data receiving state machine and a response return state machine that operate independently. Please refer to... Figure 1 , Figure 1 This is a flowchart illustrating a concurrent data transmission method provided in an embodiment of this application. Figure 1 As shown in the embodiments of this application, the method includes: S101, the data receiving state machine receives the first data access request from the system management bus, and after passing the security check, sends the first access data corresponding to the first data access request to the first IP device, and saves the first ID information of the first access data; wherein, the first data access request is a register access request initiated by the first CPU to the first IP device under the target IP; S102. The response return state machine receives the first response data returned by the first IP device, matches the ID information carried by the first response data with the stored first ID information, and returns the first response data to the system management bus after the ID information is successfully matched. S103. Before the response return state machine returns the first response data, the data receiving state machine continues to receive the second data access request from the system management bus. After passing the security check, the second access data corresponding to the second data access request is sent to the second IP device, and the second ID information of the second access data is saved. The second data access request is a register access request initiated by the second CPU for the second IP device under the same target IP.
[0015] This application embodiment achieves concurrent data control functionality by splitting the entire state machine of the remote control module, from data reception to response, into a data reception state machine and a response state machine. This allows the system management bus to send the next data to the remote control module even without receiving a response signal from the previous data, and to perform read and write operations on other devices with the same IP, significantly improving register configuration efficiency. Simultaneously, by recording the ID information of each data entry, the access request corresponding to the IP's response signal is determined, ensuring the accuracy of the response data. This supports concurrent transmission on the system management bus, enabling the software to send data accesses in parallel when configuring various IP registers, optimizing overall system performance and saving testing costs.
[0016] The following is a detailed explanation of steps S101 to S103 above: In step S101, the data receiving state machine is an independent state machine set up inside the remote control module, which is specifically used to receive data access requests sent by the system management bus and complete data forwarding. It operates independently of the response return state machine and can execute the next data receiving operation without waiting for the response return state machine to complete the response sending. It can realize efficient reception, forwarding and access identification recording of data access requests, and provide a basis for concurrent transmission.
[0017] The first data access request is a register access request initiated by the first CPU to the first IP device under the target IP. Specifically, it is the instruction data sent by the CPU to implement the configuration of a specific IP device (such as security management, clock control, power-on / power-off, storage repair, etc.), which includes key information such as access address, access type (read / write), data to be transferred, transfer type identifier, and target IP device identifier.
[0018] In an optional implementation, the format of the first data access request conforms to the AMBA protocol specification. Its data frame contains header information and data information. The header information identifies the relevant parameters of the access request, and the data information stores data to be written to the IP device register or receives data read from the IP device register. For example, if the first CPU needs to configure the clock frequency of the USB 3.0 controller (first IP device) under the USB 3.0 IP, the first CPU will generate a first data access request. The header information of this request includes the target IP identifier (USB 3.0 IP), the target device identifier (USB 3.0 controller), the access address (the clock configuration register address of the USB 3.0 controller), and the access type (write operation). The data information includes the clock frequency parameter to be configured (e.g., 500MHz). The first CPU then sends this request to the system management bus, which forwards it to the remote control module corresponding to the USB 3.0 IP.
[0019] Furthermore, the security check is a verification of the legality, permissions, and security of the data access requests received by the remote control module. This is used to ensure the compliance of the data access requests, prevent unauthorized access and unauthorized access from posing security risks to IP devices and SOC chips, and ensure the security of data transmission and IP configuration.
[0020] Optionally, security checks include address validity checks, access permission verification, and security level matching. These three checks are performed sequentially, and access data is only allowed to be sent to the IP device after all checks pass. For example, when the data receiving state machine receives the first data access request, it first performs an address validity check to verify whether the access address in the request falls within the register address range of the first IP device (USB 3.0 controller). If the address is outside the range, it is determined to be an illegal request and forwarding is rejected. If the address is valid, access permission verification is performed to verify whether the first CPU has access to the registers of the IP device (e.g., some sensitive registers are only accessible to specific CPUs). If the permissions do not match, forwarding is rejected. If the permissions match, security level matching is performed to verify whether the security level of the access request is consistent with the security level of the IP device (e.g., security levels are divided into three levels: normal, confidential, and top secret; access is only allowed if the levels are consistent). Only after all checks pass is the first access data sent to the first IP device.
[0021] The first access data is the data carried in the first data access request, used for reading / writing operations on the registers of the first IP device. Its data length and format match the interface type and register configuration requirements of the IP device, and it is the core data for configuring the IP device.
[0022] Here, the first IP device is a specific device under the target IP. The target IP is a functional module in the SOC chip (such as USB3.0 IP, PCIe IP, UART IP, etc.). A target IP can contain multiple IP devices (such as USB3.0 IP containing two devices: USB3.0 controller and USB3.0 PHY). The first IP device is directly connected to the remote control module, receives the access data forwarded by the remote control module, performs the corresponding register operations, and returns response data.
[0023] For example, the target IP can be a USB 3.0 IP, the first IP device can be a USB 3.0 controller, and the second IP device can be a USB 3.0 PHY. Both are connected to the same remote control module and can receive access requests forwarded by the remote control module. For instance, a first data access request initiated by the first CPU targets the USB 3.0 controller, requesting configuration of its data transfer rate. After the data receiving state machine of the remote control module receives the request and completes the security check, it sends the first access data (transfer rate configuration parameters) to the USB 3.0 controller. After receiving the data, the USB 3.0 controller modifies the corresponding parameters in its registers and prepares to return response data. Simultaneously, the second CPU can initiate a second data access request targeting the USB 3.0 PHY, which can be received and processed by the remote control module without waiting for the response to the first request.
[0024] The first ID information is the identity information used to uniquely identify the first access data. It is generated by the remote control module or extracted from the first data access request. It is used to associate the first access data with the corresponding first response data, ensuring that the response return state machine can accurately identify the access request corresponding to the response data returned by the IP device, avoiding response data corruption, and providing an identification basis for concurrent and burst transmission.
[0025] For example, the first ID information can be represented by 8-bit binary data, with a value range of 0-255. This supports storing the ID information of multiple access data simultaneously, meeting the needs of concurrent transmission. Simultaneously, the first ID information is also bound to a transmission type identifier for the first data access request, used to identify whether the access request is a burst transmission. For instance, the remote control module assigns ID information "00000001" to the first access data and binds it to a transmission type identifier "0" (indicating non-burst transmission). This ID information is stored in the internal ID storage module. When the IP device returns response data, the response return state machine compares the ID information carried in the response data with the stored ID information to determine that the response data corresponds to the first access data, and simultaneously uses the transmission type identifier to determine whether the response data is a burst transmission response.
[0026] In step S102, the response return state machine is an independent state machine set up inside the remote control module, which is dedicated to receiving response data returned by IP devices and completing ID matching and response forwarding. It operates independently from the data receiving state machine. While the data receiving state machine receives the next access request, it can process the response data returned by the current IP device, thereby achieving accurate identification, matching and forwarding of response data, and ensuring that the system management bus can obtain the operation feedback of the IP device in a timely manner.
[0027] Here, the first response data is the feedback data returned by the first IP device to the remote control module after receiving the first access data and performing the corresponding register operation. It may include key information such as operation result (e.g., configuration successful or configuration failed), ID information (corresponding to the first ID information of the first access data), and data identifier. It is an important basis for the CPU to determine whether the IP device configuration is successful.
[0028] Optionally, the format of the first response data can be adapted to the format of the first data access request, conforming to the AMBA protocol specification. Its data frame may include header ID information, operation result identifier, and feedback data (if it is a read operation). For example, after the USB 3.0 controller (first IP device) receives the first access data (power-on configuration data), it performs a power-on operation. If the power-on is successful, it generates the first response data. The header ID information of this response data is "00000001" (consistent with the first ID information), the operation result identifier is "00" (indicating successful configuration), and the feedback data is the current power supply status parameters of the USB 3.0 controller. If the power-on fails, the operation result identifier is "01" (indicating configuration failure), and the feedback data is the failure reason code (such as abnormal power supply voltage). Subsequently, the USB 3.0 controller sends the first response data to the response return state machine of the remote control module.
[0029] The ID information matching process involves the response return state machine comparing the ID information carried in the first response data with the first ID information stored in the data receiving state machine. This process is used to confirm which access request the first response data corresponds to, thus avoiding mismatches between response data and access requests and ensuring the accuracy of the response data. Especially in concurrent transmission scenarios, it can effectively distinguish the response data corresponding to multiple concurrent accesses.
[0030] Optionally, ID information matching can be performed bit by bit. The response return state machine extracts the ID information from the header of the first response data and compares it bit by bit with the first ID information stored in the ID storage module. If all bits are consistent, the match is considered successful; if any bit is inconsistent, the match is considered unsuccessful.
[0031] In the above steps, after the ID information is successfully matched, the response return state machine forwards the first response data to the system management bus according to the AMBA protocol specification, and then the system management bus forwards it to the first CPU that initiated the first data access request, so as to feed back the operation result of the IP device to the CPU, so that the CPU can understand the configuration status in a timely manner and then execute subsequent operations.
[0032] In step S103, the execution time of step S103 is before the response return state machine returns the first response data. That is, there is no need to wait for the response data of the previous access request to be returned. The data receiving state machine can receive and process the next access request, breaking the limitation of "only one access can be received at a time" in the prior art and greatly improving the data transmission efficiency.
[0033] Optionally, the response return state machine may return the first response data in two scenarios: first, the response return state machine has not yet received the first response data returned by the first IP device; second, the response return state machine has received the first response data, but has not yet completed ID information matching or has not yet forwarded the response data to the system management bus. For example, after the data receiving state machine completes step S101, it immediately enters a state of waiting to receive the next data access request. At this time, the response return state machine has not yet received the first response data returned by the USB3.0 controller. The system management bus sends a second data access request, and the data receiving state machine immediately receives and processes the request; or, the response return state machine has received the first response data, but is performing ID information matching and has not yet forwarded the response data to the system management bus. In this case, the data receiving state machine can also receive and process the second data access request to achieve concurrent operation.
[0034] The second data access request is a register access request initiated by the second CPU for the second IP device under the same target IP. It has the same structure and format as the first data access request, but the difference lies in the initiating entity (second CPU) and the target device (second IP device). Both are for the same target IP, reflecting the application scenario of concurrent configuration of multiple devices under the same IP.
[0035] In an optional implementation, the second CPU and the first CPU are two independent cores in the SOC chip, which can initiate data access requests simultaneously; for example, the target IP is a USB 3.0 IP, the second IP device is a USB 3.0 PHY, which belongs to the same USB 3.0 IP as the first IP device (USB 3.0 controller), and both are connected to the same remote control module.
[0036] Here, the second access data is the data carried in the second data access request for reading / writing operations on the registers of the second IP device. It has the same nature as the first access data. The data length and format can be matched according to the interface type and register configuration requirements of the second IP device. It can be processed in the remote control module at the same time as the first access data to achieve concurrent transmission.
[0037] The second ID information is used to uniquely identify the second access data. Its generation and storage methods are the same as those of the first ID information, but its value is different from that of the first ID information. It is used to distinguish the second access data from the first access data, ensuring that the response return state machine can accurately identify the second response data returned by the second IP device, avoid confusion with the first response data, and ensure the orderliness of concurrent transmission.
[0038] For example, the second ID information can be represented by 8-bit binary data with the value "00000010", distinguishing it from the first ID information "00000001". It is also bound to the transmission type identifier of the second data access request (e.g., "0" indicates a non-burst transmission) and stored in the ID storage module, alongside the first ID information, to achieve parallel management of ID information for multiple access data. For instance, after the data receiving state machine receives the second data access request and completes the security check, it generates the second ID information "00000010", binds it to the transmission type identifier "0", and stores it together with the first ID information "00000001" in the ID storage module. When the USB 3.0 PHY returns the second response data, the response return state machine compares the ID information carried in the second response data with the stored second ID information to determine that the response data corresponds to the second access data, thus completing the response forwarding.
[0039] Here, the second IP device is another specific device under the same target IP. It belongs to the same target IP as the first IP device and shares the same remote control module. It can receive access data and perform operations at the same time as the first IP device, realizing the concurrent configuration of multiple devices under the same IP and solving the defect in the prior art that different devices under the same IP cannot be configured at the same time.
[0040] In an optional implementation, the target IP can be a USB 3.0 IP, the first IP device is a USB 3.0 controller, and the second IP device is a USB 3.0 PHY. Both are connected to the remote control module corresponding to the USB 3.0 IP. The remote control module communicates with both through two independent interfaces and can send access data to both simultaneously. For example, while the data receiving state machine sends the first access data to the USB 3.0 controller, it can also send the second access data to the USB 3.0 PHY. The two IP devices simultaneously perform register configuration operations and generate response data. The response return state machine can process these two response data separately, realizing concurrent configuration of multiple devices under the same IP. This greatly improves the configuration efficiency of the USB 3.0 IP, especially during the system initialization phase, where the USB 3.0 controller and USB 3.0 PHY can be configured simultaneously, shortening the initialization time.
[0041] Therefore, it can be seen that the data receiving state machine can successfully receive and process the second data access request without waiting for the first response data to return, realizing the concurrent configuration of multiple devices under the same IP, greatly improving the system initialization efficiency, and solving the defect of existing technologies that can only process one access at a time.
[0042] In an optional embodiment, when the remote control module is connected to each IP device via an APB bus, such as Figure 2 As shown, embodiments of this application also include: S201. When the first data access request or the second data access request is a burst transmission, the data receiving state machine will split the burst transmission into multiple single-step data and send them to the corresponding IP devices in sequence.
[0043] S202. When the first response data corresponding to the first data access request or the second response data corresponding to the second data access request is a burst transmission, the response return state machine continues to receive data after the ID information is successfully matched until the last piece of first response data or second response data with the transaction end flag set to 1 is received. After completing the current transaction, it returns all response data corresponding to the burst transmission to the system management bus.
[0044] In steps S201 and S202 above, if the remote control module is connected to each IP device via the APB bus, and the APB bus does not support burst transmission (burst transmission is a one-time read / write access to registers with consecutive addresses), the burst transmission needs to be split into multiple single-step data entries through the data receiving state machine to adapt to the transmission characteristics of the APB bus. At the same time, for the response data corresponding to the burst transmission, the response return state machine needs to continuously receive until the last response data with the transaction end flag (LAST signal) set to 1 is received. Then, all response data is integrated and returned to the system management bus to ensure the integrity and accuracy of the burst transmission.
[0045] For example: Suppose that the first data access request initiated by CPU0 is a burst transfer, requesting to configure the registers of four consecutive addresses of the USB 3.0 controller at one time (addresses 0x10000000, 0x10000004, 0x10000008, and 0x1000000C respectively). The corresponding first access data consists of four 32-bit data entries (0x00000001, 0x00000002, 0x00000003, and 0x00000004). This request carries the transfer type identifier "1" (indicating a burst transfer) and is sent to the remote control module through the system management bus. After receiving the first data access request, the data receiving state machine first performs a security check. After the check passes, it detects that the remote control module and the USB 3.0 controller are connected via the APB bus, and that the request is a burst transmission. Therefore, the burst transmission is split into four single-step data entries (each 32 bits), which are sent to the USB 3.0 controller in the following order: data 0x00000001 corresponding to address 0x10000004, data 0x00000002 corresponding to address 0x10000008, and data 0x00000003 corresponding to address 0x1000000C. At the same time, the first ID information "00000001" is saved, and the transmission type identifier "1" is bound.
[0046] After receiving the four single-step data entries, the USB 3.0 controller configures the corresponding registers sequentially. After configuring each data entry, it returns a response data entry. The transaction end flag (LAST signal) of the last response data entry is set to 1, indicating that all responses for this burst transfer have been returned. The response return state machine receives the first response data (the response to the first single-step data entry), extracts the ID information "00000001," and successfully matches it with the saved first ID information. Then, based on the bound transfer type identifier "1," it identifies this response data as the response data for a burst transfer and continues to receive subsequent response data until it receives the last response data entry with the LAST signal set to 1. After receiving all four response data entries, the response return state machine integrates them into a single burst transfer response data entry and sends it to the system management bus according to the AMBA protocol specification. The system management bus then forwards it to CPU0, which confirms the successful burst transfer configuration.
[0047] Similarly, if the second data access request initiated by CPU1 is a burst transfer, requesting the configuration of three consecutive address registers of the USB 3.0 PHY at once, the data receiving state machine also splits it into three single-step data entries, which are sent sequentially to the USB 3.0 PHY. The response return state machine continuously receives response data until it receives the last entry with a LAST signal of 1, then integrates it and returns it to the system management bus, thus supporting burst transfers. Furthermore, the processing of this burst transfer and the processing of the first data access request can be executed in parallel. That is, while the data receiving state machine is splitting and sending the first burst transfer data, it can also receive and split the second burst transfer data. The response return state machine can process the response data of both burst transfers simultaneously, further improving data transmission efficiency.
[0048] Optionally, in step S201, when the first data access request or the second data access request is a burst transmission, the data receiving state machine splits the burst transmission into multiple 32-bit access data and sends them to the corresponding IP device; wherein, starting from the second access data, the address of each access data is incremented by 4 bytes based on the address of the previous data.
[0049] Here, since the standard data width of the APB bus is 32 bits (4 bytes), the data receiving state machine breaks down the burst transmission into multiple 32-bit single-step access data to ensure that each data can adapt to the transmission width of the APB bus. At the same time, through the address increment rule, the continuous address characteristics of the burst transmission are guaranteed, ensuring that the IP device can accurately identify the continuous register addresses and complete the batch configuration.
[0050] For example, the first data access request initiated by CPU0 is a burst transfer, requesting access to the consecutive address register of the USB 3.0 controller, with a starting address of 0x10000000 and a burst length of 4 (i.e., 4 consecutive data entries). The corresponding first access data are 0x00000001 (data corresponding to the starting address), 0x00000002, 0x00000003, and 0x00000004. The data receiving state machine detects that the request is a burst transmission, and since the remote control module and the USB 3.0 controller are connected via the APB bus, the burst transmission is split into four 32-bit single-step access data entries. The address of each data entry follows the rule that "starting from the second entry, the address of each entry increases by 4 bytes from the previous entry": the address of the first access data entry is 0x10000000 (starting address), and the data is 0x00000001; the address of the second access data entry is 0x10000004, and the data is 0x00000002; the address of the third access data entry is 0x10000008, and the data is 0x00000003; the address of the fourth access data entry is 0x1000000C, and the data is 0x00000004.
[0051] The data receiving state machine sequentially sends four 32-bit single-step access data packets to the USB 3.0 controller according to the address order described above. After receiving each data packet, the USB 3.0 controller writes it to the corresponding register based on its address, ensuring that registers with consecutive addresses are accurately configured. Since each data packet is 32 bits, matching the transmission width of the APB bus, byte alignment issues during data transmission are avoided, improving data transmission stability. Simultaneously, the address increment rule strictly follows a 4-byte increment, ensuring that the consecutive address characteristics of burst transmissions are consistent with burst access requests initiated by the CPU, achieving accurate splitting and forwarding of burst transmissions.
[0052] Optionally, the remote control module determines whether the first data access request or the second data access request is a burst transmission by means of the following steps: the remote control module determines whether the first data access request or the second data access request is a burst transmission based on the transmission type identifier carried in the first data access request or the second data access request.
[0053] Here, the transmission type identifier is a flag bit (or multiple flag bits) added to the header of the request data frame when the CPU initiates a data access request. This flag bit is used to specify the transmission type (burst transmission or non-burst transmission) of the data access request. The data receiving state machine of the remote control module can quickly determine the type of access request by parsing this flag bit, and then execute the corresponding processing flow (burst transmission is split, and non-burst transmission is forwarded directly) to ensure the accuracy and efficiency of the processing flow.
[0054] For example, the transfer type identifier can be a 1-bit flag, with a value of "0" indicating a non-burst transfer and a value of "1" indicating a burst transfer. This flag is located in the header information of the data access request and is transmitted along with parameters such as ID information and access address. When CPU0 initiates the first data access request, if the request is a non-burst transfer (such as configuring a single register), the transfer type identifier "0" is added to the request header; if the request is a burst transfer (such as configuring multiple consecutive address registers in batches), the transfer type identifier "1" is added.
[0055] After receiving the first data access request, the data receiving state machine of the remote control module first parses the transmission type identifier in the header of the first data access request. If the transmission type identifier is "0", the first data access request is determined to be a non-burst transmission. After passing the security check, the first access data is directly sent to the first IP device without splitting. If the transmission type identifier is "1", the first data access request is determined to be a burst transmission. Based on the interface type between the remote control module and the IP device (such as the APB bus), the burst transmission is split into multiple single-step data packets before being sent to the first IP device. For example, if the transmission type identifier in the header of the first data access request initiated by CPU0 is "1", the data receiving state machine parses the identifier and determines that it is a burst transmission. It also detects that the remote control module and the USB 3.0 controller are connected via the APB bus, so it performs a splitting operation, splitting the burst transmission into multiple 32-bit single-step data packets. If the transmission type identifier is "0", the first access data is directly sent to the USB 3.0 controller without splitting.
[0056] The above judgment method is simple and efficient, requiring no complex logical operations. It can be completed simply by parsing the transmission type identifier carried in the data access request, ensuring that the data receiving state machine can quickly respond to different types of data access requests and improve data processing efficiency.
[0057] Optionally, in step S202, the first ID information is bound to the transmission type identifier of the first data access request, and the second ID information is bound to the transmission type identifier of the second data access request. The following steps are used to determine whether the first response data corresponding to the first data access request or the second response data corresponding to the second data access request is a burst transmission: After the ID information is successfully matched, the response return state machine obtains the transmission type identifier of the first response data based on the first ID information to identify whether the first response data is a burst transmission. Alternatively, after the ID information is successfully matched, the response return state machine obtains the transmission type identifier of the second response data based on the second ID information to identify whether the second response data is a burst transmission.
[0058] In the above steps, since the first ID information is bound to the transmission type identifier of the first data access request and the second ID information is bound to the transmission type identifier of the second data access request, the response return state machine can quickly obtain the corresponding transmission type identifier through the ID information after completing the ID information matching, and then determine whether the response data is the response data of a burst transmission. There is no need to parse other parameters of the response data again, which improves the recognition efficiency of the response data and ensures the correct processing of burst transmission responses.
[0059] For example: If the first data access request initiated by CPU0 is a burst transfer with a transfer type identifier of "1", the data receiving state machine generates the first ID information "00000001" and binds the transfer type identifier "1" with this ID information, storing them together in the ID storage module. The binding method is to combine the ID information and the transfer type identifier into a 16-bit data (the first 8 bits are the ID information, and the last 8 bits are the transfer type identifier), i.e., "0000000100000001". The USB 3.0 controller returns the first response data (the response to the burst transfer), which carries the ID information "00000001". After receiving the response data, the response return state machine extracts the ID information "00000001" and compares it with the bound data stored in the ID storage module. If a match is found, the last 8 bits of the transfer type identifier "1" are extracted from the bound data. Based on this, the first response data is identified as the response data for a burst transfer, and the operation of continuously receiving response data is executed until the last response data with a LAST signal of 1 is received.
[0060] If the first data access request initiated by CPU0 is a non-burst transmission with a transmission type identifier of "0", then the first ID information "00000001" is bound to the transmission type identifier "0" and stored as "0000000100000000". After the response return state machine receives the first response data, it successfully matches the ID information, extracts the transmission type identifier "0", and identifies the response data as non-burst transmission response data. Therefore, there is no need to continuously receive it, and the response data is directly forwarded to the system management bus.
[0061] The judgment method for the second response data corresponding to the second data access request is the same as above: after the response return state machine successfully matches the second ID information, it identifies whether the second response data is the response data of a burst transmission from the transmission type identifier bound to the second ID information, and then executes the corresponding processing flow.
[0062] The above method achieves rapid identification of response data transmission type by binding ID information with transmission type identifier, ensuring that response data of burst transmission and non-burst transmission can be correctly distinguished and processed, thus guaranteeing the accuracy and efficiency of data transmission.
[0063] In one optional embodiment, the method provided in this application further includes: Step a: If the ID information carried by the returned first response data does not match any of the saved ID information, discard the first response data and send a backpressure flow control signal to the system management bus to suspend receiving new data access requests issued by the system management bus. And / or, in step b, after all the response data carrying ID information and successfully matched under the burst transmission have been received, if it is detected that there is still a missing register physical address in the preset continuous address range of this burst transmission that has not received an IP return response, then the missing register physical address is saved to the internal register, and a hardware interrupt is reported to the system, and an error status response is returned to the system management bus for this burst transmission.
[0064] Regarding step a, after the remote control module RCM receives the first response data returned by the IP device, it extracts the ID information carried in the first response data; it compares the ID information with the ID information corresponding to all data access requests already stored in the remote control module RCM one by one. If no set of ID information can be matched, the first response data is considered to be an invalid response.
[0065] When the first response data is determined to be invalid, the remote control module RCM directly discards this abnormal response data, without performing ID matching, forwarding it to the upstream system management bus, or entering the normal response processing flow. This avoids invalid data occupying the module's internal cache and state machine resources, and prevents abnormal messages from interfering with the matching and scheduling of normal transactions.
[0066] Furthermore, the RCM outputs a backpressure flow control signal to the upstream system management bus, informing the upstream system management bus that the RCM has received an abnormal illegal message and is temporarily unable to continuously receive new transactions. After the system management bus recognizes the backpressure flow control signal, it stops sending new data access requests to the remote control module, temporarily locking the upstream message inflow to avoid a large number of new data access requests from continuously flooding in, causing problems such as internal buffer overflow, state machine disorder, and transaction errors and deadlocks.
[0067] Step a above performs a full ID comparison and verification on the IP response data. Abnormal responses that cannot match any of the locally stored valid IDs are directly discarded. This filters out illegal and redundant messages and noisy responses at the source, preventing invalid data from occupying the cache resources of the remote control module and disrupting the ID matching logic and state machine transition process of normal transactions. At the same time, when a mismatched abnormal response is detected, a backpressure flow control signal is actively sent to the upstream system management bus to temporarily suspend the reception of new data access requests from the upstream system management bus. This can promptly block the continuous influx of new upstream transactions when abnormal messages are impacted, preventing problems such as buffer overflow, transaction blocking, concurrent transmission link disorder, and state machine deadlock within the module. This ensures the stability and reliability of the concurrent data transmission architecture of the remote control module, reduces the interference of abnormal messages on the overall register configuration process of the SOC chip, and improves the fault tolerance and anti-interference capabilities of the system in multi-core parallel access scenarios.
[0068] And / or, in step b, for a burst transmission, it was originally agreed that a contiguous range of register physical addresses would be accessed; the remote control module has received all valid response data belonging to this burst with normal ID verification, and the normal response portion has been fully processed. However, within the preset contiguous address range corresponding to this burst transmission, there is still a portion of register addresses that should have received response data from the IP device, but have not received any response data from the IP device. This portion is the missing register physical address.
[0069] To address the issues mentioned above, the missing register address segments for which no IP response was received are saved in the internal registers of the remote control module, facilitating subsequent software retrieval to pinpoint the fault location. The RCM initiates a hardware interrupt to the SOC system's interrupt controller, ultimately notifying the CPU-side firmware / driver software of an address response missing anomaly in this burst transfer, requiring upper-layer intervention. An error status response is sent to the upstream system management bus for the entire burst transfer transaction, marking it as failed, thus alerting the upstream CPU and bus to the anomaly and preventing it from being processed as a normal transaction.
[0070] In this way, after all valid responses matching the IDs in a burst transmission have been received, the physical address of the missing register that did not receive an IP response can be accurately identified. By latching the physical address of the missing register into an internal register, the abnormal fault address is preserved on-site, making it easier for upper-layer software to accurately locate the fault address range and the type of abnormality. At the same time, by reporting hardware interrupts, the software can complete transaction retransmission, address repair, fault diagnosis, and fault tolerance fallback. Furthermore, an error status response is returned to the upstream system management bus, clearly indicating that the burst transmission transaction execution was abnormal, so that the system management bus and CPU can promptly perceive the transaction failure status and prevent the system from continuing with incorrect configuration according to the normal process.
[0071] The above solution improves the fault tolerance, debuggability, and system stability of the remote control module in sudden transmission scenarios, and reduces IP configuration abnormalities, system malfunctions, and hidden faults in mass production testing caused by incomplete register access.
[0072] Secondly, embodiments of this application provide a remote control module, which is applied to a SOC chip to implement... Figure 1 as well as Figure 2 The aforementioned concurrent data transmission method based on a remote controller addresses the shortcomings of existing technologies where the remote control module can only receive one data access at a time and cannot achieve concurrent transmission. It supports concurrent configuration and burst transmission of multiple devices under the same IP, improving IP register configuration efficiency and system performance.
[0073] like Figure 3As shown, the remote control module 30 in this embodiment includes: an ID storage module 301, a data receiving state machine 302 and a response return state machine 303 that operate independently of each other, and a security check module 304. The output of the security check module 304 is connected to the input of the data receiving state machine 302. The output of the data receiving state machine 302 is connected to the ID storage module 301 and the IP device respectively. The response return state machine 303 is connected to the ID storage module 301, the IP device and the system management bus respectively. Furthermore, such as Figure 4 As shown, the data receiving state machine 302 receives the first data access request from the system management bus 20. After the security check is passed by the security check module 304, the first access data corresponding to the first data access request is sent to the first IP device 40, and the first ID information of the first access data is saved to the ID storage module 301. The first data access request is a register access request initiated by the first CPU 10 to the first IP device 40 under the target IP. The response return state machine 303 receives the first response data returned by the first IP device 40, matches the ID information carried in the first response data with the stored first ID information, and returns the first response data to the system management bus 20 after the ID information is successfully matched. Before the response return state machine returns the first response data, the data receiving state machine continues to receive the second data access request from the system management bus. After the security check module passes the security check, the second access data corresponding to the second data access request is sent to the second IP device, and the second ID information of the second access data is saved to the ID storage module. The second data access request is a register access request initiated by the second CPU for the second IP device under the same target IP.
[0074] The ID storage module is a storage unit inside the remote control module used to store access data ID information. For example, it stores the first ID information, the second ID information (and the ID information of subsequent access data) sent by the data receiving state machine. At the same time, it stores the binding relationship between the ID information and the corresponding data access request transmission type identifier, providing data support for ID matching and transmission type judgment of the response return state machine, ensuring the accurate correspondence between the response data and the access request, and avoiding the confusion of response data during concurrent transmission.
[0075] In an optional implementation, the ID storage module can be implemented using a register array, with a storage capacity supporting at least 8 bits of ID information storage (value range 0-255). It can simultaneously store the ID information of multiple access data and the corresponding transmission type identifier, supports parallel read and write operations, and ensures that the data receiving state machine's saving of ID information and the response return state machine's reading of ID information do not interfere with each other, thereby improving concurrent processing efficiency.
[0076] Here, the data receiving state machine and the response return state machine operate independently. The system can receive the next data access request without waiting for the response return state machine to complete its response forwarding. It is primarily used to receive various data access requests sent by the system management bus, perform security checks through the security inspection module, forward the access data to the corresponding IP device, and save the access data's ID information to the ID storage module. It is one of the core modules for achieving concurrent transmission. The response return state machine is mainly used to receive response data returned by the IP device, extract the ID information from the response data, match it with the ID information in the ID storage module, determine the transmission type of the response data, and forward the successfully matched response data to the system management bus. This ensures that the response data is accurately fed back to the CPU that initiated the access request, without affecting the concurrent receiving operation of the data receiving state machine.
[0077] The security check module is a security verification unit of the remote control module. It is connected to the data receiving state machine and is used to perform security checks on the data access requests received by the data receiving state machine. This includes address validity checks, access permission verification, and security level matching. Only after all checks pass can the data receiving state machine forward the access data to the IP device. This prevents unauthorized access and unauthorized access from posing security risks to the IP device and SOC chip, and ensures the security of data transmission and IP configuration.
[0078] Thirdly, according to an embodiment of this application, a SOC chip is provided, which includes at least one CPU, a system management bus, and multiple components such as... Figure 3 The diagram shows a remote control module and multiple IP devices under the same IP address connected to each remote control module. At least one CPU communicates with the remote control module via a system management bus. For example, the specific structure of the SOC chip provided in this application embodiment can be found by referring to... Figure 4 .
[0079] The SOC chip provided in this embodiment achieves concurrent data transmission by utilizing the independent data receiving state machine and response return state machine within the remote control module, thus overcoming the limitation of existing technologies where the remote control module can only receive one data access at a time. Simultaneously, the architecture design, which connects the CPU and the remote control module via a system management bus and allows the remote control module to connect to multiple IP devices under the same IP, supports parallel configuration of multiple devices under the same IP by multiple CPUs and supports burst data transmission. This improves the initialization speed and normal operating performance of the SOC chip, shortens mass production testing time, and reduces testing costs. By assigning multiple remote control modules to different IPs, independent and customized configuration of multiple IPs within the SOC chip is achieved, adapting to the design requirements of modern SOC chips with large scale and numerous IPs.
[0080] Among them, multiple IP devices under the same IP are multiple hardware components belonging to the same functional IP in the SOC chip. Each IP device has an independent register group and function, and can independently receive access data, perform configuration operations, and return response data. Multiple IP devices share the same remote control module, and communicate with the CPU through the remote control module. According to the access data forwarded by the remote control module, they configure their own register parameters to realize the corresponding hardware functions (such as data transmission, signal processing, clock control, etc.) and return the configuration results. It supports concurrent configuration and burst transmission, which is the basis for the SOC chip to realize diverse functions.
[0081] For example, a USB 3.0 IP (target IP) includes two IP devices: a USB 3.0 controller and a USB 3.0 PHY. Both are connected to the remote control module corresponding to the USB 3.0 IP. The USB 3.0 controller is responsible for protocol processing, data buffering, and control of USB 3.0 data transmission, while the USB 3.0 PHY is responsible for sending and receiving USB 3.0 signals, signal amplification, and filtering. Both have independent register groups and can independently receive access data from the remote control module, enabling concurrent configuration. For instance, the remote control module can simultaneously forward a USB 3.0 controller clock configuration request initiated by CPU0 and a USB 3.0 PHY signal gain configuration request initiated by CPU1 to the two IP devices. The two IP devices simultaneously perform configuration operations, generating response data and returning it to the remote control module, thus enabling concurrent configuration of multiple devices under the same IP and improving configuration efficiency.
[0082] Furthermore, multiple IP devices under the same IP can use different bus interface types. Some devices use APB interfaces, while others use AXI interfaces. The remote control module flexibly adjusts the data transmission method according to the interface type of the device to adapt to the needs of different devices. For example, a PCIe IP includes a PCIe controller (AXI interface) and a PCIePHY (APB interface). The PCIe controller uses an AXI interface, supports burst transmission, and can directly receive burst transmission data sent by the remote control module. The PCIePHY uses an APB interface, does not support burst transmission, and the remote control module splits the burst transmission data into multiple 32-bit single-step data before sending it to the PCIePHY to ensure data transmission compatibility.
[0083] In one optional embodiment, the bus connection type between the remote control module and each IP device directly affects the efficiency and compatibility of data transmission. Here, the remote control module is connected to each IP device via an AXI bus, APB bus, or AHB bus to adapt to the interface requirements of different types of IP devices, ensuring stable and efficient data transmission between the remote control module and the IP devices. Simultaneously, combined with the burst transmission splitting function of the remote control module, it achieves compatibility support for IP devices with different interface types, further improving the adaptability and practicality of the SOC chip.
[0084] Among them, the AXI bus (Advanced deXtensible Interface) is a high-performance, high-bandwidth, low-latency bus protocol that supports burst transmission, multi-master access, and out-of-order transmission. It is suitable for IP devices with high data transmission rate requirements (such as PCIe controllers, DDR controllers, etc.), has high transmission efficiency, and can meet the needs of high-frequency, large-volume data transmission. It is compatible with the burst transmission function of remote control modules and can directly receive burst transmission data sent by remote control modules without splitting, thus improving transmission efficiency.
[0085] The Advanced Peripheral Bus (APB) is a low-power, easy-to-use bus protocol suitable for peripheral IP devices with low data transmission rate requirements (such as USB PHYs, UART transmitters, SPI controllers, etc.). It has a simple structure, low power consumption, and adapts to the configuration requirements of low-speed peripheral devices. Since the APB bus does not support burst transmission, when the remote control module sends burst transmission data to the IP device with the APB interface, it needs to split the burst transmission into multiple 32-bit single-step data and then send it through the APB bus to ensure data transmission compatibility.
[0086] AHB (Advanced High-performance Bus) is a high-performance, high-bandwidth bus protocol that falls between AXI and APB buses. It is suitable for IP devices (such as SD card controllers and Ethernet controllers) that have certain requirements for data transmission rates but do not require the high performance of AXI buses. It balances transmission efficiency and complexity, supports burst transmissions, and can directly receive burst transmission data sent by remote control modules without splitting. At the same time, its structure is simpler than that of AXI buses, and its power consumption is lower than that of AXI buses, making it suitable for the needs of medium-speed IP devices.
[0087] This diverse bus connection method enables the SOC chip to adapt to different types of IP devices, improving the compatibility and practicality of the SOC chip. At the same time, combined with the burst transmission splitting and integration function of the remote control module, it ensures that concurrent transmission and burst transmission can be supported regardless of the bus connection type used, further optimizing the performance of the SOC chip.
[0088] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can perform the above-described actions. Figure 1 as well as Figure 2 The method steps in the method embodiment shown are described in detail in the method embodiment, and will not be repeated here.
[0089] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.
[0090] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the shown or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.
[0091] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0092] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0093] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0094] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The scope of protection of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A concurrent data transmission method, characterized in that, Applied to a System-on-a-Chip (SoC) chip, the SoC chip includes a system management bus, multiple remote control modules, and multiple IP devices under the same IP connected to each remote control module. Each remote control module internally sets up an independently operating data receiving state machine and a response return state machine. The method includes: The data receiving state machine receives a first data access request from the system management bus. After passing the security check, it sends the first access data corresponding to the first data access request to the first IP device and saves the first ID information of the first access data. The first data access request is a register access request initiated by the first CPU to the first IP device under the target IP. The response return state machine receives the first response data returned by the first IP device, matches the ID information carried in the first response data with the stored first ID information, and returns the first response data to the system management bus after the ID information is successfully matched. Before the response return state machine returns the first response data, the data receiving state machine continues to receive the second data access request from the system management bus. After passing the security check, it sends the second access data corresponding to the second data access request to the second IP device and saves the second ID information of the second access data. The second data access request is a register access request initiated by the second CPU for the second IP device under the same target IP.
2. The method according to claim 1, characterized in that, When the remote control module is connected to each IP device via an APB bus, the method further includes: When the first data access request or the second data access request is a burst transmission, the data receiving state machine will split the burst transmission into multiple single-step data and send them to the corresponding IP devices in sequence. When the first response data corresponding to the first data access request or the second response data corresponding to the second data access request is a burst transmission, the response return state machine continues to receive data after the ID information is successfully matched until it receives the last first response data or second response data with the transaction end flag set to 1. After completing the current transaction, it returns all response data corresponding to the burst transmission to the system management bus.
3. The method according to claim 2, characterized in that, When the first data access request or the second data access request is a burst transmission, the data receiving state machine breaks down the burst transmission into multiple single-step access data and sends them sequentially to the corresponding IP devices, including: When the first data access request or the second data access request is a burst transmission, the data receiving state machine will split the burst transmission into multiple 32-bit access data and send them to the corresponding IP device. Starting with the second access data, the address of each access data is incremented by 4 bytes based on the address of the previous access data.
4. The method according to claim 2, characterized in that, The following steps are used to determine whether the first data access request or the second data access request is a burst transmission: The remote control module determines whether the first data access request or the second data access request is a burst transmission based on the transmission type identifier carried in the first data access request or the second data access request.
5. The method according to claim 2, characterized in that, The first ID information is bound to the transmission type identifier of the first data access request, and the second ID information is bound to the transmission type identifier of the second data access request. The following steps are used to determine whether the first response data corresponding to the first data access request or the second response data corresponding to the second data access request is a burst transmission: After the ID information is successfully matched, the response return state machine obtains the transmission type identifier of the first response data based on the first ID information to identify whether the first response data is a burst transmission; or, after the ID information is successfully matched, the response return state machine obtains the transmission type identifier of the second response data based on the second ID information to identify whether the second response data is a burst transmission.
6. The method according to claim 2, characterized in that, The method further includes: If the ID information carried by the returned first response data does not match any of the saved ID information, the first response data is discarded, and a backpressure flow control signal is sent to the system management bus to suspend receiving new data access requests issued by the system management bus. And / or, after all the response data carrying ID information and successfully matched under the burst transmission has been received, if it is detected that there is still a missing register physical address in the preset continuous address range of this burst transmission that has not received an IP return response, then the missing register physical address is saved to the internal register, a hardware interrupt is reported to the system, and an error status response is returned to the system management bus for this burst transmission.
7. The method according to claim 1, characterized in that, The security checks include address validity checks, access permission verification, and security level matching.
8. A remote control module, characterized in that, include: The system comprises an ID storage module, an independently operating data receiving state machine and a response return state machine, and a security check module. The output of the security check module is connected to the input of the data receiving state machine. The output of the data receiving state machine is connected to the ID storage module and the IP device, respectively. The response return state machine is connected to the ID storage module, the IP device, and the system management bus, respectively. The data receiving state machine receives a first data access request from the system management bus. After passing the security check by the security check module, it sends the first access data corresponding to the first data access request to the first IP device and saves the first ID information of the first access data to the ID storage module. The first data access request is a register access request initiated by the first CPU to the first IP device under the target IP. The response return state machine receives the first response data returned by the first IP device, matches the ID information carried in the first response data with the stored first ID information, and returns the first response data to the system management bus after the ID information is successfully matched. Before the response return state machine returns the first response data, the data receiving state machine continues to receive the second data access request from the system management bus. After the security check by the security check module passes the security check, the second access data corresponding to the second data access request is sent to the second IP device, and the second ID information of the second access data is saved to the ID storage module. The second data access request is a register access request initiated by the second CPU for the second IP device under the same target IP.
9. A SOC chip, characterized in that, It includes at least one CPU, a system management bus, multiple remote control modules as described in claim 8, and multiple IP devices under the same IP connected to each remote control module, wherein the at least one CPU communicates with the remote control modules through the system management bus.
10. The chip according to claim 9, characterized in that, The remote control module is connected to each IP device via an AXI bus, APB bus, or AHB bus.
