SoC subsystem distributed configuration method and device, equipment and storage medium

Abstract

A SoC subsystem distributed configuration method, device and equipment and storage medium, relating to the field of semiconductor integrated circuits, including deploying a configuration engine in each subsystem of the SoC, and the configuration engine supports passive configuration mode and active configuration mode; in the passive configuration mode, the central processing unit directly sends a configuration command to the configuration engine through the bus, so that the configuration engine configures the sub-modules in the subsystem based on the configuration command; in the active configuration mode, the configuration engine reads the pre-stored configuration command sequence from the target storage module through the bus and executes it to realize the configuration of the sub-modules in the subsystem; wherein the configuration engines of multiple subsystems work in parallel to realize the distributed configuration of the SoC subsystem. The application realizes the distributed processing of the configuration task by deploying the configuration engine with dual working mode in each subsystem to improve the configuration efficiency and reduce the time consumed for the initialization of the SoC system.

Description

Technical Field

[0001] This application relates to the field of semiconductor integrated circuit technology, specifically to a distributed configuration method, apparatus, device, and storage medium for a SoC subsystem. Background Technology

[0002] With the continuous advancement of semiconductor process technology, modern SoC (System on Chip) systems integrate more and more functional sub-modules. These functional sub-modules are usually organized into multiple subsystems, and there are tight coupling relationships between these subsystems. During the SoC system power-on initialization process, these subsystems need to be configured (i.e., the process of setting the MMR (Memory Mapped Register) of the sub-module according to the sequence requirements, specifying the sub-module's operating mode). Traditional methods usually adopt a passive configuration approach, in which the CPU (Central Processing Unit) sends configuration commands to each subsystem one by one through the bus interface.

[0003] However, as the complexity of SoC systems increases, this passive configuration method suffers from the following technical problems:

[0004] First, since the CPU must access each subsystem sequentially for configuration, the time required for configuration increases linearly when there are multiple coupled subsystems. If such configuration is on the time-critical path of SoC system initialization, it will seriously affect the startup efficiency of the SoC system.

[0005] Secondly, the single passive configuration method, for complex systems, leads to a large number of configuration commands due to cumbersome configuration requirements, and the large delay between commands consumes a lot of configuration time.

[0006] In addition, the CPU is heavily occupied during the configuration process, making it impossible to execute other initialization tasks at the same time, which reduces the overall system initialization efficiency.

[0007] Therefore, how to achieve efficient configuration of the SoC subsystem is an urgent problem to be solved. Summary of the Invention

[0008] This application provides a distributed configuration method, apparatus, device, and storage medium for a SoC subsystem, which can solve the problem of low configuration efficiency caused by the use of a single passive configuration method to configure the SoC subsystem in the prior art.

[0009] In a first aspect, embodiments of this application provide a distributed configuration method for a SoC subsystem, the distributed configuration method for the SoC subsystem comprising:

[0010] A configuration engine is deployed in each subsystem of the SoC, and the configuration engine supports passive configuration mode and active configuration mode.

[0011] In the passive configuration mode, the central processing unit sends configuration commands directly to the configuration engine via the bus, so that the configuration engine can configure the sub-modules in its subsystem based on the configuration commands.

[0012] In the active configuration mode, the configuration engine reads and executes a pre-stored sequence of configuration commands from the target storage module to configure the sub-modules in its subsystem.

[0013] In this system, the configuration engines of multiple subsystems work in parallel to achieve distributed configuration of the SoC subsystems.

[0014] In conjunction with the first aspect, in one implementation, the configuration engine includes an address decoding module, and the method further includes:

[0015] When the configuration engine receives a configuration space access command sent by the central processing unit, the address decoding module performs address decoding on the configuration space access command to determine whether the configuration space access command is a local register access command or a coupled subsystem address space access command.

[0016] If the configuration space access command is a local register access command, then the control configuration engine is in active configuration mode;

[0017] If the configuration space access command is a coupled subsystem address space access command, then the control configuration engine is in passive configuration mode.

[0018] In conjunction with the first aspect, in one implementation, the configuration engine further includes a local register module, a master device command FIFO, an AXI4 master device interface generation module, a configuration command FIFO, a command finite state machine, an APB master device interface generation module, and a multiplexer; the configuration engine reads pre-stored configuration commands from the target storage module via a bus and executes them, including:

[0019] The local register module concatenates multiple local register access commands output by the address decoding module to obtain a master device command. The master device command includes the access start address and the access data length, and the master device command is pushed into the master device command FIFO.

[0020] The AXI4 master device interface generation module reads and parses the target master device command from the master device command FIFO to obtain the target access start address and the target access data length. Based on the target access start address and the target access data length, it reads the pre-stored configuration command and its corresponding configuration data from the target storage module and writes the configuration command and configuration data into the configuration command FIFO.

[0021] The command finite state machine reads and parses the target configuration command from the configuration command FIFO, obtains the target control flow, and sends it to the APB master device interface generation module;

[0022] After the APB master device interface generation module performs APB protocol conversion on the target control flow, it obtains the first APB control flow, which is then transmitted to the target submodule for execution via a multiplexer.

[0023] In conjunction with the first aspect, in one implementation, the configuration engine further includes reading command data FIFO, and the step of transmitting the first APB control flow to the target submodule for execution via a multiplexer includes:

[0024] When the first APB control flow is a write control flow, the first APB control flow is transmitted to the target submodule for execution through a multiplexer;

[0025] When the first APB control flow is a read control flow, the first APB control flow is transmitted to the target sub-module through a multiplexer, so that the target sub-module can generate the first read data based on the first APB control flow and transmit it to the APB master device interface generation module through a multiplexer. The APB master device interface generation module writes the first read data into the read command data FIFO.

[0026] When the first APB control flow is a repeating read control flow, the first APB control flow is transmitted to the target submodule through a multiplexer, so that the target submodule can generate the second read data based on the first APB control flow and transmit it to the APB master device interface generation module through a multiplexer. If the APB master device interface generation module determines that the second read data meets the preset requirements, it returns read completion to the command finite state machine.

[0027] In conjunction with the first aspect, in one implementation, the configuration engine further includes an APB bridge, wherein the configuration engine configures sub-modules in its subsystem based on the configuration command, including:

[0028] The APB bridge decodes the address space access commands of the coupled subsystem output by the address decoding module to determine the target submodule;

[0029] The APB protocol is converted to the address space access commands of the coupled subsystem, a second APB control flow is generated and transmitted to the target submodule for execution via a multiplexer;

[0030] The multiplexer is used to select one of the APB control flows from the first APB control flow and the second APB control flow according to the preset active-passive configuration mode and transmit it to the target submodule.

[0031] In conjunction with the first aspect, in one implementation, the APB master device interface generation module supports back-to-back transmission of configuration commands so that there is no idle state between two configuration commands.

[0032] In conjunction with the first aspect, in one implementation, the configuration commands include the Memory Write command, MemoryDump command, IO Write command, IO Read command, IO Probe command, and Delay command;

[0033] The Memory Write command is used to perform continuous write operations on the configuration space address of a submodule;

[0034] The Memory Dump command is used to continuously read the configuration space address of a submodule and specify the starting address for saving the read data.

[0035] The IO Write command is used to perform a single write operation on the configuration space address of a submodule;

[0036] The IO Read command is used to perform a single read operation on the configuration space address of a submodule;

[0037] The IO Probe command is used to repeatedly read a configuration space address of a submodule until a preset condition is met.

[0038] The Delay command is used to insert a delay of a specified duration between adjacent configuration operations.

[0039] Secondly, embodiments of this application provide a distributed configuration device for a SoC subsystem, including: a central processing unit and multiple subsystems, each subsystem including a configuration engine and multiple sub-modules, wherein the configuration engine supports passive configuration mode and active configuration mode;

[0040] In the passive configuration mode, the central processing unit sends configuration commands directly to the configuration engine via the bus, so that the configuration engine can configure the sub-modules in its subsystem based on the configuration commands.

[0041] In the active configuration mode, the configuration engine reads and executes a pre-stored sequence of configuration commands from the target storage module to configure the sub-modules in its subsystem.

[0042] In this system, the configuration engines of multiple subsystems work in parallel to achieve distributed configuration of the SoC subsystems.

[0043] In conjunction with the second aspect, in one implementation, the configuration engine includes an address decoding module;

[0044] When the configuration engine receives a configuration space access command sent by the central processing unit, the address decoding module performs address decoding on the configuration space access command to determine whether the configuration space access command is a local register access command or a coupled subsystem address space access command.

[0045] If the configuration space access command is a local register access command, then the control configuration engine is in active configuration mode;

[0046] If the configuration space access command is a coupled subsystem address space access command, then the control configuration engine is in passive configuration mode.

[0047] In conjunction with the second aspect, in one implementation, the configuration engine further includes a local register module, a master device command FIFO, an AXI4 master device interface generation module, a configuration command FIFO, a command finite state machine, an APB master device interface generation module, and a multiplexer.

[0048] The local register module concatenates multiple local register access commands output by the address decoding module to obtain a master device command. The master device command includes the access start address and the access data length, and the master device command is pushed into the master device command FIFO.

[0049] The AXI4 master device interface generation module reads and parses the target master device command from the master device command FIFO to obtain the target access start address and the target access data length. Based on the target access start address and the target access data length, it reads the pre-stored configuration command and its corresponding configuration data from the target storage module and writes the configuration command and configuration data into the configuration command FIFO.

[0050] The command finite state machine reads and parses the target configuration command from the configuration command FIFO, obtains the target control flow, and sends it to the APB master device interface generation module;

[0051] After the APB master device interface generation module performs APB protocol conversion on the target control flow, it obtains the first APB control flow, which is then transmitted to the target submodule for execution via a multiplexer.

[0052] In conjunction with the second aspect, in one implementation, the configuration engine further includes a read command data FIFO;

[0053] When the first APB control flow is a write control flow, the first APB control flow is transmitted to the target submodule for execution through a multiplexer;

[0054] When the first APB control flow is a read control flow, the first APB control flow is transmitted to the target sub-module through a multiplexer, so that the target sub-module can generate the first read data based on the first APB control flow and transmit it to the APB master device interface generation module through a multiplexer. The APB master device interface generation module writes the first read data into the read command data FIFO.

[0055] When the first APB control flow is a repeating read control flow, the first APB control flow is transmitted to the target submodule through a multiplexer, so that the target submodule can generate the second read data based on the first APB control flow and transmit it to the APB master device interface generation module through a multiplexer. If the APB master device interface generation module determines that the second read data meets the preset requirements, it returns read completion to the command finite state machine.

[0056] In conjunction with the second aspect, in one implementation, the configuration engine further includes an APB bridge, which is used for:

[0057] The address decoding module outputs the coupled subsystem address space access command to determine the target submodule;

[0058] The APB protocol is converted to the address space access commands of the coupled subsystem, a second APB control flow is generated and transmitted to the target submodule for execution via a multiplexer;

[0059] The multiplexer is used to select one of the APB control flows from the first APB control flow and the second APB control flow according to the preset active-passive configuration mode and transmit it to the target submodule.

[0060] In conjunction with the second aspect, in one implementation, the APB master device interface generation module supports back-to-back transmission of configuration commands so that there is no idle state between two configuration commands.

[0061] In conjunction with the second aspect, in one implementation, the configuration commands include Memory Write command, MemoryDump command, IO Write command, IO Read command, IO Probe command, and Delay command;

[0062] The Memory Write command is used to perform continuous write operations on the configuration space address of a submodule;

[0063] The Memory Dump command is used to continuously read the configuration space address of a submodule and specify the starting address for saving the read data.

[0064] The IO Write command is used to perform a single write operation on the configuration space address of a submodule;

[0065] The IO Read command is used to perform a single read operation on the configuration space address of a submodule;

[0066] The IO Probe command is used to repeatedly read a configuration space address of a submodule until a preset condition is met.

[0067] The Delay command is used to insert a delay of a specified duration between adjacent configuration operations.

[0068] Thirdly, embodiments of this application provide a SoC subsystem distributed configuration device, the SoC subsystem distributed configuration device including a processor, a memory, and an SoC subsystem distributed configuration program stored in the memory and executable by the processor, wherein when the SoC subsystem distributed configuration program is executed by the processor, it implements the steps of the SoC subsystem distributed configuration method as described above.

[0069] Fourthly, embodiments of this application provide a computer-readable storage medium storing a SoC subsystem distributed configuration program, wherein when the SoC subsystem distributed configuration program is executed by a processor, it implements the steps of the aforementioned SoC subsystem distributed configuration method.

[0070] The beneficial effects of the technical solutions provided in this application include:

[0071] In this application, a configuration engine is deployed in each subsystem of the SoC. This configuration engine supports both passive and active configuration modes. In passive configuration mode, the central processing unit (CPU) directly sends configuration commands to the configuration engine via the bus, allowing the engine to configure sub-modules within its subsystem based on these commands. In active configuration mode, the configuration engine reads a pre-stored sequence of configuration commands from a target storage module and executes it to configure sub-modules within its subsystem. Multiple configuration engines in different subsystems operate in parallel, enabling distributed configuration of the SoC subsystems. Therefore, this application achieves distributed processing of configuration tasks by deploying configuration engines with dual operating modes in each subsystem, effectively improving configuration efficiency and reducing the time required for SoC system initialization. Attached Figure Description

[0072] Figure 1 This is a flowchart illustrating an embodiment of the distributed configuration method for the SoC subsystem of this application;

[0073] Figure 2This is a schematic diagram showing the location of the configuration engine in the SoC system in the embodiments of this application;

[0074] Figure 3 This is a schematic diagram of the configuration engine functional structure involved in the embodiments of this application;

[0075] Figure 4 This is a schematic diagram illustrating the state transitions of the configuration engine involved in the embodiments of this application;

[0076] Figure 5 This is a schematic diagram of the hardware structure of the SoC subsystem distributed configuration device involved in the embodiments of this application. Detailed Implementation

[0077] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0078] First, some of the technical terms used in this application will be explained to help those skilled in the art understand this application.

[0079] AMBA (Advanced Microcontroller Bus Architecture): Advanced Microcontroller Bus Architecture.

[0080] AXI (Advanced eXtensible Interface): The AXI protocol is a type of AMBA protocol.

[0081] APB (Advanced Peripheral Bus): The APB protocol is a type of AMBA protocol.

[0082] Subsystem: refers to a system in a SoC that has an independent specific function. A SoC contains multiple subsystems.

[0083] Submodule: refers to an independent module with a defined function in a subsystem. A subsystem contains multiple submodules that work together to complete the subsystem's functions.

[0084] Coupled subsystems: refer to multiple closely related subsystems in a SoC system, which need to work together to achieve the specific complete functions of the SoC.

[0085] Passive configuration: refers to the configuration method in which the CPU applies configuration commands to each submodule of the subsystem.

[0086] Active configuration: refers to the configuration method in which the subsystem reads a sequence of configuration commands from high-speed storage and applies the configuration commands to the submodules in sequence.

[0087] Back-to-back commands: These are commands that have no idle time between them, allowing the APB bus to reach maximum efficiency.

[0088] SRAM (Static Random-Access Memory): Static random access memory.

[0089] DUMP: The process of completely copying or saving the contents of memory, database, file system or other data source to another place (usually a file) in a certain format.

[0090] APB Slave: APB protocol slave interface.

[0091] FIFO: First-In-First-Out storage device.

[0092] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0093] In a first aspect, embodiments of this application provide a distributed configuration method for a SoC subsystem.

[0094] In one embodiment, reference is made to Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the distributed configuration method for the SoC subsystem of this application. Figure 1 As shown, the distributed configuration method for the SoC subsystem includes:

[0095] Step S10: Deploy a configuration engine in each subsystem of the SoC. The configuration engine supports passive configuration mode and active configuration mode. The configuration engines of multiple subsystems work in parallel to realize distributed configuration of the SoC subsystems.

[0096] Exemplary, see Figure 2 As shown, in this embodiment, a configuration engine will be deployed in each subsystem of the SoC system (it should be understood that the subsystem includes both coupled and uncoupled subsystems) to implement the configuration of sub-modules in the subsystem. The configuration engine realizes data interaction with the CPU and SRAM / high-speed storage through APB / AXI and Interconnect bus in sequence, and realizes data interaction with sub-modules through APB / AXI.

[0097] It should be noted that the configuration engines of different subsystems support parallel operation, meaning that multiple configuration engines can achieve parallel configuration of the coupled system, thereby realizing distributed configuration of the SoC subsystems and effectively reducing the time required for SoC system initialization. When multiple configuration engines work in parallel, they can use the same configuration command sequence or different configuration command sequences, and the configuration command sequence can reside in any SRAM / high-speed memory within the SoC system. It should be understood that the prerequisite for using the exact same configuration sequence is that the objects (i.e., subsystems) served by the configuration engines using this sequence are identical. However, there are some special cases that should also be classified as using the same configuration command sequence. For example, if a Memory Dump command (i.e., a continuous read command) exists, then the Dump Data Store StartAddress 32 Bits field in this command should have an independent address for each configuration engine; otherwise, it will lead to DUMP data overwriting. Based on this, this situation can still be classified as using the same configuration command sequence because this address field does not affect the definition that the commands sent to the configuration engine service objects are exactly the same.

[0098] Understandably, the advantage of using the same configuration command sequence is that it saves storage space for the configuration sequence. However, when the objects served by the configuration engines are exactly the same, but the system storage space is large enough, even if the configuration command sequence is the same, multiple copies of the same configuration sequence can be kept in storage and used by each configuration engine to avoid bus conflicts and maximize the utilization of the configuration engine's bus interface.

[0099] If the objects served by the configuration engine are not the same, and each object has its own unique configuration sequence, then only different configuration command sequences can be used by the corresponding configuration engine to avoid bus conflicts caused by address contention. If SRAM space is insufficient, other storage spaces need to be considered, such as DDR (Double Data Rate Synchronous Dynamic Random-Access Memory) / EMMC (Embedded Multi Media Card) / USB (Universal Serial Bus), etc.

[0100] As can be seen, this embodiment provides flexibility in the configuration command sequence, including flexibility in its physical storage location and flexibility in being partially or fully reused by multiple configuration engines.

[0101] It is worth noting that the configuration engine in this embodiment supports both passive and active configuration modes. That is, it supports both the CPU applying configuration commands to each submodule of the subsystem and the subsystem reading configuration command sequences from high-speed storage and applying the configuration commands to the submodules in sequence. The software can switch between active and passive configuration at appropriate times through preset methods. For example, when all coupled subsystems are configured and only the event completion status needs to be read, it can switch to passive configuration mode, and the CPU actively reads commands for each coupled subsystem. As another example, during the SoC system initialization phase, each configuration engine uses active configuration mode to achieve synchronous or orderly configuration of multiple coupled subsystems, while after the system is running stably, it can switch to passive configuration mode, and the CPU directly controls the configuration engine to perform status queries or parameter adjustments.

[0102] In addition, see Figure 3 As shown, in a fully synchronous design, for certain scenarios, such as when the configuration engine does not need to work, the configuration engine clock can be statically disabled by enabling clock_enable, or the active configuration clock can be partially disabled to achieve low power consumption requirements.

[0103] Step S20: In the passive configuration mode, the central processing unit sends configuration commands directly to the configuration engine via the bus, so that the configuration engine can configure the sub-modules in its subsystem based on the configuration commands.

[0104] As an example, in this embodiment, when the system is in passive configuration mode, the CPU sends configuration commands directly to the configuration engine through the Interconnect bus, and then the configuration engine applies the configuration commands to each sub-module in its subsystem, thereby realizing the configuration of the sub-module.

[0105] Furthermore, in one embodiment, the configuration commands include Memory Write command, Memory Dump command, IOWrite command, IO Read command, IO Probe command, and Delay command;

[0106] The Memory Write command is used to perform continuous write operations on the configuration space address of a submodule;

[0107] The Memory Dump command is used to continuously read the configuration space address of a submodule and specify the starting address for saving the read data.

[0108] The IO Write command is used to perform a single write operation on the configuration space address of a submodule;

[0109] The IO Read command is used to perform a single read operation on the configuration space address of a submodule;

[0110] The IO Probe command is used to repeatedly read a configuration space address of a submodule until a preset condition is met.

[0111] The Delay command is used to insert a delay of a specified duration between adjacent configuration operations.

[0112] As an example, the configuration engine in this embodiment supports the following command formats: Memory Write command, MemoryDump command, IO Write command, IO Read command, IO Probe command, and Delay command; it can be seen that the format and types of configuration commands provided in this embodiment effectively cover various configuration requirements.

[0113] The format of the Memory Write command is as follows:

[0114] Table 1 Memory Write Format

[0115]

[0116] Based on this, the Memory Write command is designed as a configuration operation that writes the configuration space address of a submodule in the subsystem continuously. It can perform DATA_NUM consecutive 4-byte configuration write operations, and the effective write data is DATA_NUM×4 bytes. The total length of the Memory Write command is (DATA_NUM+2)×4 bytes, and the command code CMD_TYPE of Memory Write is 3'b001, which is used to uniquely identify the Memory Write command.

[0117] The format of the Memory Dump command is as follows:

[0118] Table 2 Memory Dump Format

[0119]

[0120] Based on this, the Memory Dump command is designed as a configuration operation that continuously reads the configuration space of submodules in the subsystem. It performs a 4-byte read operation on each 32-bit address, with no address order requirement, and can perform ADDR_NUM 4-byte configuration read operations, with the effective read data being ADDR_NUM × 4 bytes. At the same time, the Memory Dump command also specifies the starting address for storing the read data in SRAM / high-speed storage. The total length of the Memory Dump command is (ADDR_NUM+2) × 4 bytes, and the command code CMD_TYPE of Memory Dump is 3'b010, which is used to uniquely identify the Memory Dump command.

[0121] The format of the IO Write command is as follows:

[0122] Table 3 IO Write Format

[0123]

[0124] Based on this, the IO Write command is designed as a configuration operation that writes to the configuration space address of a submodule in the subsystem, implementing a 4-byte configuration write operation with 4 bytes of effective write data. The total length of the IO Write command is 2×4 bytes, and the command code CMD_TYPE of IO Write is 3'b011 to uniquely identify the IO Write command. In addition, it is worth noting that the reason for separating the IO Write command from the Memory Write command in this embodiment is that the latter occupies more space in SRAM / high-speed storage than the former.

[0125] The format of the IO Read command is as follows:

[0126] Table 4 IO Read Format

[0127]

[0128] Based on this, the IO Read command is designed as a configuration operation that reads a single configuration space address of a submodule in the subsystem, implementing a 4-byte configuration read operation with 4 bytes of effective read data; the total length of the IO Read command is 1×4 bytes, and the IO Read command code CMD_TYPE is 3'b100, which is used to uniquely identify the IO Read command; in addition, it can be understood that the reason for separating the IO Read command from the Memory Dump in this embodiment is that the latter occupies more space in SRAM / high-speed storage than the former.

[0129] The format of the IO Probe command is as follows:

[0130] Table 5 IO Probe Format

[0131]

[0132] Based on this, the IO Probe command is designed as a configuration operation that repeatedly reads a configuration space address of a submodule in the subsystem. It implements a 4-byte configuration read repetitive operation until the Enable bit is equal to or not equal to the Probe value (i.e., the preset condition), that is, 32 Bits Config read data & 32 Bits Enable Bits == 32 Bits Probe Value (i.e., EQ == 1) or 32 Bits Config read data & 32 Bits Enable Bits ! == 32 Bits Probe Value (i.e., EQ == 0). In addition, the IO Probe implementation supports a timeout function to prevent the Command FSM from hanging. The total length of the IO Probe command is 3×4 bytes, and the command code CMD_TYPE of the IO Probe is 3'b101, which is used to uniquely identify the IO Probe command.

[0133] The format of the Delay command is as follows:

[0134] Table 6 Delay Format

[0135]

[0136] Based on this, the Delay command is designed to delay between two configuration operations, achieving an accurate delay from the end of one command to the start of the next, and the unit of the Delay Cycle is clock cycles. The total length of the Delay command is 1×4 bytes, and its command code is 3'b111, used to uniquely identify the Delay command. Based on this, multiple configuration engines are distributed across subsystems in a parallel-working method, allowing them to work completely synchronously or using effective delay commands to ensure the order in which the configuration engines complete their tasks.

[0137] Step S30: In the active configuration mode, the configuration engine reads and executes the pre-stored configuration command sequence from the target storage module to configure the sub-modules in its subsystem.

[0138] As an example, it should be noted that the target storage module can be SRAM or other high-speed storage, which is not limited here; in this embodiment, when the system is in active configuration mode, the subsystem reads the configuration command sequence from SRAM / high-speed storage through the configuration engine and applies the configuration commands to each submodule in sequence, thereby realizing the configuration of the submodule.

[0139] As can be seen, this embodiment achieves distributed processing of configuration tasks by deploying configuration engines with dual working modes in each subsystem, thereby effectively improving configuration efficiency and reducing the time required for SoC system initialization. Moreover, the configuration engine not only has no impact on the original SoC structure and can be inserted into the original bus structure without loss, but also supports the original passive configuration path and has no impact on the original functions.

[0140] Furthermore, in one embodiment, the configuration engine includes an address decoding module, and the method further includes:

[0141] When the configuration engine receives a configuration space access command sent by the central processing unit, the address decoding module performs address decoding on the configuration space access command to determine whether the configuration space access command is a local register access command or a coupled subsystem address space access command.

[0142] If the configuration space access command is a local register access command, then the control configuration engine is in active configuration mode;

[0143] If the configuration space access command is a coupled subsystem address space access command, then the control configuration engine is in passive configuration mode.

[0144] Exemplary, see Figure 3As shown, the configuration engine in this embodiment is equipped with an address decoding module (AddressDecode), which can distinguish between local register access commands and coupled subsystem address space access commands. It should be noted that during the SoC system design phase, non-overlapping address ranges are allocated to the local registers and coupled subsystem address spaces of the configuration engine. Based on this, when an APB Slave bus (e.g., APB3 Slave) receives a configuration space access command from the CPU, the Address Decode module performs address decoding on the configuration space access command to determine whether it is a local register access command. If the configuration space access command is a local register access command (i.e., the address decoding result indicates the address is a local address, i.e., local address == TRUE), the configuration engine is controlled to be in active configuration mode; if the configuration space access command is a coupled subsystem address space access command (i.e., the address decoding result indicates the address is not a local address, i.e., local address == FALSE), the configuration engine is controlled to be in passive configuration mode. It should be understood that the workflow and principles of address decoding are common knowledge in this field, and for the sake of brevity, they will not be elaborated upon here; furthermore, Figure 3 The "32 bits A / 32 bits D" (i.e., 32-bit address / 32-bit data) means that a 32-bit conversion is required, while "*bits A / *bits D" (i.e., configurable bit address / configurable bit data) means that a 32-bit or 64-bit conversion is not required.

[0145] Further, in one embodiment, the configuration engine further includes a local register module, a master device command FIFO, an AXI4 master device interface generation module, a configuration command FIFO, a command finite state machine, an APB master device interface generation module, and a multiplexer; the configuration engine reads pre-stored configuration commands from the target storage module via a bus and executes them, including:

[0146] The local register module concatenates multiple local register access commands output by the address decoding module to obtain a master device command. The master device command includes the access start address and the access data length, and the master device command is pushed into the master device command FIFO.

[0147] The AXI4 master device interface generation module reads and parses the target master device command from the master device command FIFO to obtain the target access start address and the target access data length. Based on the target access start address and the target access data length, it reads the pre-stored configuration command and its corresponding configuration data from the target storage module and writes the configuration command and configuration data into the configuration command FIFO.

[0148] The command finite state machine reads and parses the target configuration command from the configuration command FIFO, obtains the target control flow, and sends it to the APB master device interface generation module;

[0149] After the APB master device interface generation module performs APB protocol conversion on the target control flow, it obtains the first APB control flow, which is then transmitted to the target submodule for execution via a multiplexer.

[0150] Exemplary, see Figure 3 As shown, the configuration engine in this embodiment also deploys a local register module, a master command FIFO, an AXI4 master interface generation module, a configuration command FIFO, a command finite state machine (FSM), an APB master interface generation module, and a multiplexer (Mux). It should be noted that the master command FIFO is preferably 64 bits, but other bit widths can be selected according to actual needs; this is not limited here. The APB master interface generation module can be an APB3 master interface generation module or an APB4 master interface generation module, which can be determined according to actual needs and is not limited here.

[0151] The Command FSM is primarily responsible for controlling the pace of reading commands from the Config Command FIFO. It parses the first command line and subsequent content of the read Config Command according to the command format and length supported by the configuration engine, and breaks down the parsed content into individual read / write / query (i.e., repeated read) probe commands before sending them to the APB Master GEN module. Furthermore, it can record illegal commands through the Status function, placing the Command FSM in an Error state and stopping the parsing of subsequent content. Notably, for the Command FSM, writing configuration data is confirmed as complete after the command is sent. It also receives the number of read configuration data and Probe Done (i.e., query complete) information returned by the APB Master GEN module to confirm the completion of the current configuration command. It records commands that time out and fail to complete through the Status function, placing the Command FSM in a Timeout state and stopping the parsing of subsequent content.

[0152] The following combination Figure 3 and Figure 4Explain the process of the Command FSM control state machine implementing the Status transition:

[0153] If the current state is S_HEAD (i.e., the first 4 bytes of the command state), then the first state command (i.e. Figure 4 The command transmitted by the green arrow is read and it is determined whether it is an illegal command. If it is, the current state is set to S_INV_CMD (i.e., illegal command state); if not, the judgment of S_MW_ADDR (memory write address state), S_MD_ADDR (memory dump address state), S_IW_DATA (IO write data state), S_IR_EXE (IO read execution state), S_IP_VAL_0 (IO probe retrieves 4-byte probe value state), S_DLY_EXE (delay execution state), etc. can continue.

[0154] Specifically, if the command == MEMORY WRITE is detected, the current state is determined to be S_MW_ADDR. If the Config Command FIFO is not empty at this time, the process enters S_MW_EXE_P0 (i.e., the first stage of Memory Write execution). If the current APB command is received, the process enters S_MW_EXE_P1 (i.e., the second stage of Memory Write execution). During this process, if an APB BUS error occurs, the process enters S_ERROR (i.e., the APB bus error state). After S_MW_EXE_P1 ends, if MEMORY WRITE is not yet completed, the process re-enters S_MW_EXE_P0; if MEMORY WRITE is completed, the process re-enters S_HEAD.

[0155] If the command == MEMORY DUMP is detected, the current state is determined to be S_MD_ADDR. If the Config Command FIFO is not empty, then it enters S_MD_EXE_P0 (i.e., the first stage of Memory Dump execution). If the current APB command is received, it enters S_MD_EXE_P1 (i.e., the second stage of Memory Dump execution). During this process, if an APB BUS error occurs, it enters S_ERROR (i.e., the APB bus error state). After S_MD_EXE_P1 ends, if MEMORY DUMP is not yet complete, it re-enters S_MD_EXE_P0. If MEMORY WRITE is complete, it enters S_MD_PUSH (i.e., the last data of Memory Dump is pushed into the Read Command Data FIFO state), and then unconditionally enters S_MD_EXP (i.e., the Read Command Data FIFO data read state). Then, if the Read Command Data FIFO is detected to be empty, it re-enters S_HEAD.

[0156] If the command == IO WRITE is detected, it is determined that the current state is S_IW_DATA. If the ConfigCommand FIFO is not empty, it enters S_IW_EXE (i.e., IO Write execution state). During this process, if an APBBUS error occurs, it enters S_ERROR (i.e., APB bus error state). When it is detected that IO WRITE has been completed, it re-enters S_HEAD.

[0157] If the command == IO READ is detected, it is determined that the current state is S_IR_EXE. During this process, if an APBBUS error occurs, it will enter S_ERROR (i.e., APB bus error state); when it is detected that IO READ has been completed, it will re-enter S_HEAD.

[0158] If the command == IO PROBE is detected, the current state is determined to be S_IP_VAL_0, and the system sequentially enters S_IP_VAL_1 (i.e., IO Probe 4-byte Enable state) and S_IP_EXE (i.e., IO Probe execution state). During this process, if an APB BUS error occurs, the system enters S_ERROR (i.e., APB bus error state). If a command timeout is detected, the system enters S_TIME_OUT (i.e., IO Probe command timeout state). After S_IP_EXE ends, if IO PROBE has completed, the system re-enters S_HEAD.

[0159] If the command ==DELAY is detected, it is determined that the current state is S_DLY_EXE. After this state ends, it will re-enter S_HEAD.

[0160] In this embodiment, Mux is mainly responsible for configuring two sets of direct configuration paths (APB3 / 4) from the CPU. Figure 3 The blue path in the diagram) and the configuration path (APB3 / 4) generated by the configuration engine based on configuration commands. Figure 3 The green path in the Mux is selected quasi-statically, and the selection control is completed by the register bit. The register bit represents the configuration path that the Mux needs to select, while the register bit is configured by software.

[0161] The APB Master GEN module is primarily responsible for converting Probe commands into repeated read commands until the read data meets the Probe command requirements, and then transmitting the Probe Done information to the Command FSM. Secondly, it is used to decode the address information provided upstream and send read / write commands to the two downstream APB3 / 4 Master buses. Simultaneously, it supports back-to-back APB transmission and allows the command data bit width to be converted from 32 bits to 16 bits. It collects and concatenates the read data information from the two APB3 / 4 buses and pushes it sequentially into the Read Command Data FIFO. Furthermore, it is used to record APB Error Responses via the Status function.

[0162] The following embodiments will be combined with Figure 3 The workflow and principles of the configuration engine are explained by examining the various modules within the configuration engine.

[0163] After determining that the configuration space access command is a local register access command, the Address Decode module will execute active configuration, i.e., the corresponding... Figure 3 The green configuration path is as follows: Specifically, the local register access command is transmitted to the LocalRegister module, so that the Local Register module can combine multiple received local register access commands into a master command (i.e., the Master command) through Combined Register Content to Command. The Master command includes the access start address and the access data length. The specific format is shown in Table 7. Then, the combined Master command is pushed into the Master Command FIFO.

[0164] Table 7 Master Command Format

[0165]

[0166] Understandably, all configuration commands are pre-stored in the software program. After compilation, these configuration commands are assigned addresses, such as in SRAM / high-speed storage. That is, all configuration commands used to configure submodules are pre-stored in the target storage module. Based on this, the AXI4 Master GEN reads and parses the target Master command from the Master Command FIFO to obtain the target access start address and target access data length. It then sends the target access start address and target access data length to the AXI4 bus, enabling the AXI4 protocol master device (i.e., AXI4Master) to read the pre-stored configuration commands and their corresponding configuration data from the target storage module based on the target access start address and target access data length, and write the configuration commands and configuration data into the Config Command FIFO.

[0167] The Command FSM reads and parses the target configuration command from the Config Command FIFO to obtain the target control flow, which includes the address and / or data. It then sends the target control flow to the APB Master GEN, so that the APB Master GEN performs APB protocol conversion on the target control flow to obtain the first APB control flow. The first APB control flow is then transmitted to the target submodule for execution via the multiplexer Mux. It should be noted that the target submodule refers to the submodule to be configured that corresponds to the first APB control flow.

[0168] It is worth noting that an appropriate number of outstanding items allows the configuration engine to initiate subsequent configuration command read requests while waiting for the previous read operation to complete, thereby achieving resource optimization, system performance improvement, and system balancing. Based on this, in this embodiment, the AXI4 Master supports a configurable number of outstanding items (i.e., the number of incomplete items), and the size of the number of outstanding items depends on the ratio of the upstream (SRAM / high-speed storage / interconnect) and the configuration engine data rate.

[0169] See Figure 3As shown, it is understandable that the configuration engine may be interrupted during operation, in which case the Interrupt module will output an interrupt. Table 8 below shows the interrupt and status information involved in the configuration engine. Among them, the status / interrupt information is usually divided into two categories: one is error information, which indicates that the current configuration engine is malfunctioning and cannot continue to work; the other is normal status information, which gives the status that the CPU may be interested in, in order to confirm the general working status of the configuration engine.

[0170] Table 8 Interrupt and Status Information Table

[0171]

[0172] It should be understood that in Table 8, ENGINE_IDLE indicates that the configuration engine is in an idle state, meaning that all components within the configuration engine have no unfinished work, including all FIFOs being empty, all buses being in an IDLE state, and all finite state machines being in an initial or error state; FSM_INV_CMD indicates that the Command FSM has entered the S_INV_CMD state, which is an error message caused by an incorrect command sequence; CMDFIFO_ERR indicates that the Master Command FIFO has overflowed, which is an error message caused by software configuration; APB_ERR indicates that the APB bus has an error, which is a functional error, usually caused by an incorrect APB address; FSM_TO indicates that the Command FSM has entered the S_TIME_OUT state, which is both an error message and a functional error, caused by multiple reasons; APB_IDLE indicates that all APB buses are in an idle state, which is a normal state; RDATAFIFO_EMPTY indicates that the Read Command Data FIFO is empty, which is a normal state; RDATAFIFO_FULL indicates that the Read Command Data FIFO is full, which is a normal state, and also indicates that the AXI4 Master... The slow speed of data reading from the FIFO due to the GEN protocol and the slow speed of the AXI4 protocol master device interface are the causes of this problem.

[0173] CFGFIFO_EMPTY indicates that the Config Command FIFO is empty, which is a normal state and means that all Config Commands have been parsed. CFGFIFO_FULL indicates that the Config Command FIFO is full, which is also a normal state, caused by the APB3 / 4 protocol master device interface sending commands too slowly. CMDFIFO_ALEMPTY indicates that the Master Command FIFO is almost empty, which is a normal state. CMDFIFO_EMPTY indicates that the Master Command FIFO is empty, which is a normal state. CMDFIFO_ALFULL indicates that the Master Command FIFO is almost full, which is a normal state. When the software sees this state, it should choose not to write any more Commands. CMDFIFO_FULL indicates that the Master Command FIFO is full. At this time, the software should not write any more Commands, otherwise it will result in CMDFIFO_ERR.

[0174] Furthermore, in one embodiment, the configuration engine further includes a read command data FIFO, and the step of transmitting the first APB control flow to the target submodule for execution via a multiplexer includes:

[0175] When the first APB control flow is a write control flow, the first APB control flow is transmitted to the target submodule for execution through a multiplexer;

[0176] When the first APB control flow is a read control flow, the first APB control flow is transmitted to the target sub-module through a multiplexer, so that the target sub-module can generate the first read data based on the first APB control flow and transmit it to the APB master device interface generation module through a multiplexer. The APB master device interface generation module writes the first read data into the read command data FIFO.

[0177] When the first APB control flow is a repeating read control flow, the first APB control flow is transmitted to the target submodule through a multiplexer, so that the target submodule can generate the second read data based on the first APB control flow and transmit it to the APB master device interface generation module through a multiplexer. If the APB master device interface generation module determines that the second read data meets the preset requirements, it returns read completion to the command finite state machine.

[0178] Exemplary, see Figure 3As shown, if the first APB control flow is a write control flow, then the APBMaster GEN writes the first APB control flow onto the APB bus, so that the APB protocol master device (i.e., the APB Master) transmits the first APB control flow to the multiplexer Mux, so that the multiplexer Mux can decide whether to transmit the first APB control flow to the target submodule for execution, and the target submodule does not need to return information to the APB Master GEN.

[0179] If the first APB control flow is a read control flow, it is written to the APB bus. Specifically, the read address bits are written to the APB bus and then transmitted to the multiplexer (Mux) via the APB Master. The multiplexer (Mux) then decides whether to transmit the first APB control flow to the target submodule. If so, the target submodule receives the first APB control flow, executes it to generate the first read data (i.e., the read data requested by the read command), and returns it to the APB Master GEN sequentially via the APB protocol master device and the multiplexer (Mux). The APB Master GEN then writes the received first read data into the Read Command Data FIFO in sequence. The data format in the Read Command Data FIFO is shown in Table 9.

[0180] Table 9 Read Command Data FIFO Data Format

[0181]

[0182] If the first APB control flow is a repeated read control flow (i.e., probe), then the first APB control flow is written to the APB bus, that is, the read address bit is written to the APB bus, and then transmitted to the multiplexer Mux through the APB Master, so that the multiplexer Mux can decide whether to transmit the first APB control flow to the target submodule. If so, after receiving the first APB control flow, the target submodule will execute the first APB control flow to generate the second read data and return it to the APB Master GEN in sequence through the APB protocol master device and the multiplexer Mux. The APB Master GEN then determines whether the received second read data meets the requirements of the probe command (i.e., the preset conditions in the IO Probe command). If it meets the requirements, it returns Probe Done to the Command FSM; otherwise, it continues to execute the probe command.

[0183] Furthermore, in one embodiment, the configuration engine further includes an APB bridge, and the configuration engine configures sub-modules in its subsystem based on the configuration command, including:

[0184] The APB bridge decodes the address space access commands of the coupled subsystem output by the address decoding module to determine the target submodule;

[0185] The APB protocol is converted to the address space access commands of the coupled subsystem, a second APB control flow is generated and transmitted to the target submodule for execution via a multiplexer;

[0186] The multiplexer is used to select one of the APB control flows from the first APB control flow and the second APB control flow according to the preset active-passive configuration mode and transmit it to the target submodule.

[0187] Exemplary, see Figure 3 As shown, the configuration engine also deploys an APB Bridge. The APB Bridge performs further address decoding on the coupled subsystem address space access commands that are diverted from the Address Decode and directs the commands to the respective target submodules (such as Module 1 and Module 2). It also implements protocol conversion between APB3 and APB4 as needed. In addition, the APB Bridge supports data bit conversion, for example, converting a 32-bit data width to a 16-bit data width.

[0188] Specifically, the APB bridge decodes the address space access command of the coupled subsystem output by the address decoding module to determine the target submodule; and after performing APB protocol conversion on the coupled subsystem address space access command, it generates a second APB control flow, which is then transmitted to the multiplexer Mux. The multiplexer Mux determines whether to transmit the second APB control flow to the target submodule for execution. That is, the multiplexer Mux selects one of the first and second APB control flows to transmit to the target submodule for execution according to the active / passive configuration mode preset in the Register bit. Based on this, it can be seen that the APB3 / 4 Master bus is generated by the MUX from the downstream bus of the APB Bridge (passive configuration path) and the bus of the APB MasterGEN (active configuration path).

[0189] Furthermore, in one embodiment, the APB master device interface generation module supports back-to-back transmission of configuration commands so that there is no idle state between two configuration commands.

[0190] As an example, in this embodiment, the APB Master GEN will provide back-to-back transmission of configuration commands, enabling the configuration engine to send configuration commands back-to-back, i.e., without any idle state between the two commands, thereby maximizing the efficiency of the APB bus.

[0191] Secondly, embodiments of this application also provide a distributed configuration device for a SoC subsystem.

[0192] In one embodiment, the SoC subsystem distributed configuration device includes: a central processing unit and multiple subsystems, each subsystem including a configuration engine and multiple sub-modules, wherein the configuration engine supports passive configuration mode and active configuration mode;

[0193] In the passive configuration mode, the central processing unit sends configuration commands directly to the configuration engine via the bus, so that the configuration engine can configure the sub-modules in its subsystem based on the configuration commands.

[0194] In the active configuration mode, the configuration engine reads and executes a pre-stored sequence of configuration commands from the target storage module to configure the sub-modules in its subsystem.

[0195] In this system, the configuration engines of multiple subsystems work in parallel to achieve distributed configuration of the SoC subsystems.

[0196] Furthermore, in one embodiment, the configuration engine includes an address decoding module;

[0197] When the configuration engine receives a configuration space access command sent by the central processing unit, the address decoding module performs address decoding on the configuration space access command to determine whether the configuration space access command is a local register access command or a coupled subsystem address space access command.

[0198] If the configuration space access command is a local register access command, then the control configuration engine is in active configuration mode;

[0199] If the configuration space access command is a coupled subsystem address space access command, then the control configuration engine is in passive configuration mode.

[0200] Furthermore, in one embodiment, the configuration engine further includes a local register module, a master device command FIFO, an AXI4 master device interface generation module, a configuration command FIFO, a command finite state machine, an APB master device interface generation module, and a multiplexer;

[0201] The local register module concatenates multiple local register access commands output by the address decoding module to obtain a master device command. The master device command includes the access start address and the access data length, and the master device command is pushed into the master device command FIFO.

[0202] The AXI4 master device interface generation module reads and parses the target master device command from the master device command FIFO to obtain the target access start address and the target access data length. Based on the target access start address and the target access data length, it reads the pre-stored configuration command and its corresponding configuration data from the target storage module and writes the configuration command and configuration data into the configuration command FIFO.

[0203] The command finite state machine reads and parses the target configuration command from the configuration command FIFO, obtains the target control flow, and sends it to the APB master device interface generation module;

[0204] After the APB master device interface generation module performs APB protocol conversion on the target control flow, it obtains the first APB control flow, which is then transmitted to the target submodule for execution via a multiplexer.

[0205] Furthermore, in one embodiment, the configuration engine further includes a read command data FIFO;

[0206] When the first APB control flow is a write control flow, the first APB control flow is transmitted to the target submodule for execution through a multiplexer;

[0207] When the first APB control flow is a read control flow, the first APB control flow is transmitted to the target sub-module through a multiplexer, so that the target sub-module can generate the first read data based on the first APB control flow and transmit it to the APB master device interface generation module through a multiplexer. The APB master device interface generation module writes the first read data into the read command data FIFO.

[0208] When the first APB control flow is a repeating read control flow, the first APB control flow is transmitted to the target submodule through a multiplexer, so that the target submodule can generate the second read data based on the first APB control flow and transmit it to the APB master device interface generation module through a multiplexer. If the APB master device interface generation module determines that the second read data meets the preset requirements, it returns read completion to the command finite state machine.

[0209] Furthermore, in one embodiment, the configuration engine further includes an APB bridge, which is used for:

[0210] The address decoding module outputs the coupled subsystem address space access command to determine the target submodule;

[0211] The APB protocol is converted to the address space access commands of the coupled subsystem, a second APB control flow is generated and transmitted to the target submodule for execution via a multiplexer;

[0212] The multiplexer is used to select one of the APB control flows from the first APB control flow and the second APB control flow according to the preset active-passive configuration mode and transmit it to the target submodule.

[0213] Furthermore, in one embodiment, the APB master device interface generation module supports back-to-back transmission of configuration commands so that there is no idle state between two configuration commands.

[0214] Furthermore, in one embodiment, the configuration commands include Memory Write command, Memory Dump command, IOWrite command, IO Read command, IO Probe command, and Delay command;

[0215] The Memory Write command is used to perform continuous write operations on the configuration space address of a submodule;

[0216] The Memory Dump command is used to continuously read the configuration space address of a submodule and specify the starting address for saving the read data.

[0217] The IO Write command is used to perform a single write operation on the configuration space address of a submodule;

[0218] The IO Read command is used to perform a single read operation on the configuration space address of a submodule;

[0219] The IO Probe command is used to repeatedly read a configuration space address of a submodule until a preset condition is met.

[0220] The Delay command is used to insert a delay of a specified duration between adjacent configuration operations.

[0221] The functions of each part in the above-mentioned SoC subsystem distributed configuration device correspond to the steps in the above-mentioned SoC subsystem distributed configuration method embodiment, and their functions and implementation processes will not be described in detail here.

[0222] Thirdly, embodiments of this application provide a SoC subsystem distributed configuration device, which can be a personal computer (PC), laptop computer, server, or other device with data processing capabilities.

[0223] Reference Figure 5 , Figure 5This is a schematic diagram of the hardware structure of the SoC subsystem distributed configuration device involved in the embodiments of this application. In the embodiments of this application, the SoC subsystem distributed configuration device may include a processor, memory, communication interface, and communication bus.

[0224] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.

[0225] Communication interfaces include input / output (I / O) interfaces, physical interfaces, and logical interfaces used for interconnecting devices within the SoC subsystem's distributed configuration device, as well as interfaces used for interconnecting the SoC subsystem's distributed configuration device with other devices (such as other computing devices or user equipment). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.

[0226] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0227] The processor can be a general-purpose processor, which can call the SoC subsystem distributed configuration program stored in memory and execute the SoC subsystem distributed configuration method provided in the embodiments of this application. For example, the general-purpose processor can be a CPU. The method executed when the SoC subsystem distributed configuration program is called can be referred to in the various embodiments of the SoC subsystem distributed configuration method of this application, and will not be repeated here.

[0228] Those skilled in the art will understand that Figure 5 The hardware structure shown does not constitute a limitation of this application and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0229] Fourthly, embodiments of this application also provide a computer-readable storage medium.

[0230] The present application stores a SoC subsystem distributed configuration program on a readable storage medium, wherein when the SoC subsystem distributed configuration program is executed by a processor, it implements the steps of the SoC subsystem distributed configuration method as described above.

[0231] The method implemented when the SoC subsystem distributed configuration program is executed can be referred to in various embodiments of the SoC subsystem distributed configuration method of this application, and will not be repeated here.

[0232] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0233] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0234] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0235] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0236] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0237] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0238] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A distributed configuration method for a SoC subsystem, characterized in that, The SoC subsystem distributed configuration method includes: A configuration engine is deployed in each subsystem of the SoC, and the configuration engine supports passive configuration mode and active configuration mode. In the passive configuration mode, the central processing unit sends configuration commands directly to the configuration engine via the bus, so that the configuration engine can configure the sub-modules in its subsystem based on the configuration commands. In the active configuration mode, the configuration engine reads and executes a pre-stored sequence of configuration commands from the target storage module to configure the sub-modules in its subsystem. Among them, the configuration engines of multiple subsystems work in parallel to realize distributed configuration of SoC subsystems; The configuration engine includes an address decoding module, and the method further includes: When the configuration engine receives a configuration space access command sent by the central processing unit, the address decoding module performs address decoding on the configuration space access command to determine whether the configuration space access command is a local register access command or a coupled subsystem address space access command. If the configuration space access command is a local register access command, then the control configuration engine is in active configuration mode; If the configuration space access command is a coupled subsystem address space access command, then the control configuration engine is in passive configuration mode.

2. The SoC subsystem distributed configuration method as described in claim 1, characterized in that, The configuration engine also includes a local register module, a master device command FIFO, an AXI4 master device interface generation module, a configuration command FIFO, a command finite state machine, an APB master device interface generation module, and a multiplexer; The configuration engine reads and executes pre-stored configuration commands from the target storage module via the bus, including: The local register module concatenates multiple local register access commands output by the address decoding module to obtain a master device command. The master device command includes the access start address and the access data length, and the master device command is pushed into the master device command FIFO. The AXI4 master device interface generation module reads and parses the target master device command from the master device command FIFO to obtain the target access start address and the target access data length. Based on the target access start address and the target access data length, it reads the pre-stored configuration command and its corresponding configuration data from the target storage module and writes the configuration command and configuration data into the configuration command FIFO. The command finite state machine reads and parses the target configuration command from the configuration command FIFO, obtains the target control flow, and sends it to the APB master device interface generation module; After the APB master device interface generation module performs APB protocol conversion on the target control flow, it obtains the first APB control flow, which is then transmitted to the target submodule for execution via a multiplexer.

3. The SoC subsystem distributed configuration method as described in claim 2, characterized in that, The configuration engine also includes a read command data FIFO, and the transmission of the first APB control flow to the target submodule for execution via a multiplexer includes: When the first APB control flow is a write control flow, the first APB control flow is transmitted to the target submodule for execution through a multiplexer; When the first APB control flow is a read control flow, the first APB control flow is transmitted to the target sub-module through a multiplexer, so that the target sub-module can generate the first read data based on the first APB control flow and transmit it to the APB master device interface generation module through a multiplexer. The APB master device interface generation module writes the first read data into the read command data FIFO. When the first APB control flow is a repeating read control flow, the first APB control flow is transmitted to the target submodule through a multiplexer, so that the target submodule can generate the second read data based on the first APB control flow and transmit it to the APB master device interface generation module through a multiplexer. If the APB master device interface generation module determines that the second read data meets the preset requirements, it returns read completion to the command finite state machine.

4. The SoC subsystem distributed configuration method as described in claim 2, characterized in that, The configuration engine also includes an APB bridge, which configures sub-modules in its subsystem based on the configuration commands, including: The APB bridge decodes the address space access commands of the coupled subsystem output by the address decoding module to determine the target submodule; The APB protocol is converted to the address space access commands of the coupled subsystem, a second APB control flow is generated and transmitted to the target submodule for execution via a multiplexer; The multiplexer is used to select one of the APB control flows from the first APB control flow and the second APB control flow according to the preset active-passive configuration mode and transmit it to the target submodule.

5. The SoC subsystem distributed configuration method as described in claim 2, characterized in that: The APB master device interface generation module supports back-to-back transmission of configuration commands, so that there is no idle state between two configuration commands.

6. The SoC subsystem distributed configuration method as described in claim 1, characterized in that: The configuration commands include the MemoryWrite command, Memory Dump command, IO Write command, IO Read command, IO Probe command, and Delay command; The Memory Write command is used to perform continuous write operations on the configuration space address of a submodule; The Memory Dump command is used to continuously read the configuration space address of a submodule and specify the starting address for saving the read data. The IO Write command is used to perform a single write operation on the configuration space address of a submodule; The IO Read command is used to perform a single read operation on the configuration space address of a submodule; The IO Probe command is used to repeatedly read a configuration space address of a submodule until a preset condition is met. The Delay command is used to insert a delay of a specified duration between adjacent configuration operations.

7. A distributed configuration device for a SoC subsystem, characterized in that, include: The central processing unit and multiple subsystems, each subsystem including a configuration engine and multiple sub-modules, wherein the configuration engine supports passive configuration mode and active configuration mode; In the passive configuration mode, the central processing unit sends configuration commands directly to the configuration engine via the bus, so that the configuration engine can configure the sub-modules in its subsystem based on the configuration commands. In the active configuration mode, the configuration engine reads and executes a pre-stored sequence of configuration commands from the target storage module to configure the sub-modules in its subsystem. Among them, the configuration engines of multiple subsystems work in parallel to realize distributed configuration of SoC subsystems; The configuration engine includes an address decoding module. When the configuration engine receives a configuration space access command sent by the central processing unit, the address decoding module performs address decoding on the configuration space access command to determine whether the configuration space access command is a local register access command or a coupled subsystem address space access command. If the configuration space access command is a local register access command, the configuration engine is controlled to be in active configuration mode; if the configuration space access command is a coupled subsystem address space access command, the configuration engine is controlled to be in passive configuration mode.

8. A distributed configuration device for a SoC subsystem, characterized in that, The SoC subsystem distributed configuration device includes a processor, a memory, and an SoC subsystem distributed configuration program stored in the memory and executable by the processor, wherein when the SoC subsystem distributed configuration program is executed by the processor, it implements the steps of the SoC subsystem distributed configuration method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a SoC subsystem distributed configuration program, wherein when the SoC subsystem distributed configuration program is executed by a processor, it implements the steps of the SoC subsystem distributed configuration method as described in any one of claims 1 to 6.

Images