A method and system for pool management of peripheral resources under multi-soc

Abstract

The application discloses a kind of pool management design methods and systems of peripheral resource under multiple SOC, it is related to pool management technical field, comprising: group SOC set, and extract the first SOC in the SOC set, wherein the first SOC has first peripheral equipment;The first peripheral equipment is connected to predetermined peripheral bus by full exchange high-speed bus, wherein the predetermined peripheral bus refers to FPGA program;The bus scanning result is obtained by dynamically scanning the FPGA program;Read predetermined start strategy, and whether the bus scanning result meets predetermined start constraint according to the predetermined start strategy;If the bus scanning result meets the predetermined start constraint, issue start instruction, and drive load is carried out to target drive based on the start instruction.The application solves the technical problem that the existing technology has low peripheral resource sharing efficiency, and achieves the technical effect of efficient management of peripheral resource.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of pool management, and particularly relates to a pool management design method and system for peripheral resources under multiple SOC. BACKGROUND

[0002] With the complication and diversification of embedded application scenarios, the resources of a single SOC system are difficult to meet the demand for high performance and high efficiency. Under this background, multiple SOCs are integrated into a piece of hardware board card to form a multi-SOC architecture, which has become a mainstream design method. However, in the multi-SOC environment, due to the lack of unified peripheral resource sharing mechanism among the SOCs, the utilization efficiency of peripheral resources is low, and resource conflicts and repeated occupation occur from time to time, which significantly limits the performance optimization and expansion capability of the multi-SOC system. SUMMARY

[0003] The present application provides a pool management design method and system for peripheral resources under multiple SOC, which is used to solve the technical problem of low peripheral resource sharing efficiency in the prior art.

[0004] In view of the above problems, the present application provides a pool management design method and system for peripheral resources under multiple SOC.

[0005] In a first aspect, the present application provides a pool management design method for peripheral resources under multiple SOC, which comprises:

[0006] Assembling a SOC set and extracting a first SOC in the SOC set, wherein the first SOC has a first peripheral; connecting the first peripheral to a predetermined peripheral bus through a full exchange high-speed bus, wherein the predetermined peripheral bus refers to an FPGA program; dynamically scanning the FPGA program to obtain a bus scan result; reading a predetermined startup strategy and judging whether the bus scan result meets a predetermined startup constraint according to the predetermined startup strategy; if the bus scan result meets the predetermined startup constraint, issuing a startup instruction and performing driving loading on a target driver based on the startup instruction.

[0007] In a second aspect, the present application provides a pool management design system for peripheral resources under multiple SOC, which comprises:

[0008] The SOC set assembly module is configured to assemble a SOC set and extract a first SOC in the SOC set, wherein the first SOC is provided with a first peripheral device; the connection module is configured to connect the first peripheral device to a predetermined peripheral bus through a full exchange high-speed bus, wherein the predetermined peripheral bus refers to an FPGA program; the scanning module is configured to perform dynamic scanning on the FPGA program to obtain a bus scanning result; the startup strategy reading module is configured to read a predetermined startup strategy and determine whether the bus scanning result meets a predetermined startup constraint according to the predetermined startup strategy; and the driver loading module is configured to issue a startup instruction if the bus scanning result meets the predetermined startup constraint, and perform driver loading on a target driver based on the startup instruction.

[0009] One or more technical solutions provided in the present application have at least the following technical effects or advantages:

[0010] The present application assembles a SOC set and extracts a first SOC in the SOC set, wherein the first SOC is provided with a first peripheral device; the first peripheral device is connected to a predetermined peripheral bus through a full exchange high-speed bus, wherein the predetermined peripheral bus refers to an FPGA program; the FPGA program is dynamically scanned to obtain a bus scanning result; a predetermined startup strategy is read, and it is determined whether the bus scanning result meets a predetermined startup constraint according to the predetermined startup strategy; if the bus scanning result meets the predetermined startup constraint, a startup instruction is issued, and driver loading is performed on a target driver based on the startup instruction. The present application solves the technical problem of low peripheral resource sharing efficiency in the prior art, connects the first peripheral device of the first SOC to the predetermined peripheral bus through the full exchange high-speed bus, extracts bus information by dynamic scanning and determines the peripheral state in combination with the predetermined startup strategy, generates a startup instruction to realize driver loading, and achieves the technical effect of efficient management of peripheral resources. BRIEF DESCRIPTION OF DRAWINGS

[0011] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0012] Figure 1 A multi-SOC peripheral resource pooling management design method flowchart is provided for the embodiments of the present application.

[0013] Figure 2 A multi-SOC peripheral resource pooling management design system structure schematic diagram is provided for the embodiments of the present application.

[0014] Explanation of reference signs: SOC set assembly module 11, connection module 12, scanning module 13, startup strategy reading module 14, driver loading module 15. DETAILED DESCRIPTION

[0015] The present application provides a pool management design method and system for peripheral resources under multiple SOCs, aiming to solve the technical problem of low peripheral resource sharing efficiency in the prior art. The first peripheral of the first SOC is connected to a predetermined peripheral bus through a full exchange high-speed bus, bus information is extracted by dynamic scanning, and the peripheral state is judged in combination with a predetermined startup strategy to generate a startup instruction to realize driver loading, thereby achieving the technical effect of efficient management of peripheral resources.

[0016] The technical solutions in the embodiments of the present application will be described clearly and completely in combination with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work fall within the scope of protection of the present application.

[0017] It should be noted that any variation of the terms "comprise" and "have" is intended to cover non-exclusive inclusion, for example, a process, method, system, product or server comprising a series of steps or units does not have to be limited to those steps or units clearly listed, but can include other steps or modules that are not clearly listed or inherent to the process, method, product or device.

[0018] Embodiment one, as shown in the present application provides a pool management design method for peripheral resources under multiple SOCs, which comprises: Figure 1

[0019] Step S100: Assemble a SOC set and extract a first SOC in the SOC set, wherein the first SOC has a first peripheral.

[0020] In the embodiments of the present application, a SOC set is first assembled. In this step, multiple independent SOCs are selected and combined into a unified system. Each SOC has a certain computing power and peripheral resource, but they usually run independently and cannot directly share peripheral resources. In order to enable these SOCs to work cooperatively and share resources, these SOCs are first integrated into a system through hardware interconnection (for example, high-speed bus or network connection). At present, hardware integrated circuits (IC) are designed or high-performance bus standards (such as PCIe, Ethernet, etc.) are used to realize the interconnection between SOCs. These SOCs are connected to each other through high-speed buses, work together, and form a SOC set. ​

[0021] After the SOC set is completed, a random SOC is extracted as the first SOC. After the first SOC is extracted, the peripheral resources possessed by the SOC are identified and configured. At this time, through the steps of hardware scanning and peripheral initialization, it is determined which peripherals the first SOC possesses. Generally, the first SOC at least possesses one peripheral, referred to as the first peripheral. These peripherals can be input-output devices (such as UART, SPI, GPIO interface, etc.), or sensors and controllers, and the like hardware modules. Specifically, the peripherals are managed by configuring registers and drivers, first, the hardware interface is scanned to identify the peripheral type, and then the peripherals are allocated control resources. Each peripheral will have a configuration space, including control fields and data storage space, for supporting sharing and management between multiple SOCs. Through this step, the peripherals of the first SOC are initialized and prepared for sharing with other SOCs.

[0022] Step S200: connecting the first peripheral to a predetermined peripheral bus through a full exchange high-speed bus, wherein the predetermined peripheral bus refers to an FPGA program.

[0023] In the embodiment of the application, the first peripheral is connected to the predetermined peripheral bus through the full exchange high-speed bus, that is, the efficient connection between the first peripheral and multiple SOCs is realized through the full exchange high-speed bus. The full exchange high-speed bus allows direct and non-blocking data transmission between devices, ensuring that the first peripheral can share resources with multiple SOCs without being limited by data transmission bottlenecks. At the same time, the predetermined peripheral bus is realized by the FPGA program, and the FPGA is responsible for protocol conversion and data management, so that the first peripheral can be compatible and efficiently communicate with other SOCs, thereby realizing resource sharing and collaborative work in a multi-SOC environment.

[0024] Further, the method provided by the application embodiment further comprises:

[0025] obtaining a peripheral interface layer, wherein the bus protocol soft core is pre-stored in the peripheral interface layer, and the bus protocol soft core is used to interconnect the first peripheral and the predetermined peripheral bus; obtaining a protocol analysis layer, the protocol analysis layer is used to convert the bus protocol soft core into a self-defined bus protocol; obtaining a peripheral instance layer, the peripheral instance layer is used to maintain and manage the first peripheral; based on the peripheral interface layer, the protocol analysis layer and the peripheral instance layer, the predetermined peripheral bus is composed.

[0026] In the embodiment of the present application, the peripheral interface layer is first acquired. The key function of this layer is to provide an interface for the interconnection between the peripheral and the bus. The bus protocol soft core is pre-stored in the peripheral interface layer, which is a protocol module implemented by a hardware description language (such as Verilog or VHDL). The bus protocol soft core is responsible for converting the communication protocol used by the peripheral (such as SPI, UART, I2C, etc.) into a protocol compatible with the predetermined peripheral bus. Specifically, the peripheral interface layer ensures that the first peripheral can communicate with the predetermined peripheral bus (implemented by FPGA) through an appropriate hardware interface through the pre-integrated soft core module. In this way, the protocol of the peripheral can adapt to the predetermined bus structure, ensuring that the peripheral can correctly exchange data with other components.

[0027] Next, the protocol analysis layer is acquired. The main role of the protocol analysis layer is to convert the protocol transmitted through the peripheral interface layer into a custom bus protocol. This process ensures that the peripheral can use the predetermined custom protocol for data exchange through decoding and conversion of the peripheral protocol. The protocol analysis layer adapts between the peripheral protocol and the internal bus protocol, allowing the peripheral to communicate seamlessly with other devices according to specific needs.

[0028] Finally, the peripheral instance layer is acquired. The main task of the peripheral instance layer is to maintain and manage the first peripheral. It ensures that the peripheral can operate normally and is responsible for allocating and managing the configuration and data space of the peripheral. The peripheral instance layer monitors the status of the peripheral, manages the life cycle of the peripheral, and ensures that the peripheral can be loaded, configured, started, and unloaded when needed. It is also responsible for recording the running state and data of the peripheral, ensuring that the resources of the peripheral can be shared between different SOCs without conflict.

[0029] Through the cooperative work of the peripheral interface layer, the protocol analysis layer, and the peripheral instance layer, the peripheral interface layer provides the connection between the peripheral and the bus, the protocol analysis layer converts the protocol into a custom protocol, and the peripheral instance layer is responsible for the management and maintenance of the peripheral. The three work together to form the predetermined peripheral bus.

[0030] Further, the method provided by the embodiment of the application further comprises:

[0031] In the embodiment of the present application, the bus protocol soft core refers to a protocol module integrated in hardware, which can support the processing of multiple communication protocols. The bus protocol soft core at least integrates SPI, UART, and I2C protocols, providing multiple communication methods between the peripheral and the SOC.

[0032] Further, the method provided by the embodiment of the application further comprises:

[0033] The custom bus protocol includes a first field, a second field, a third field and a fourth field, wherein the first field refers to a device type, used to identify the type of peripheral, the second field refers to a device serial number, used to distinguish the same type of peripheral, the third field refers to an occupation state, and 1 represents occupied and 0 represents unoccupied, and the fourth field refers to a peripheral loading and unloading request, and 1 represents loading and 0 represents unloading.

[0034] In the embodiments of the present application, the custom bus protocol identifies and manages the peripheral through multiple fields, including a first field, a second field, a third field and a fourth field, which define the data transmission format of the peripheral, for realizing the identification, management and control of the peripheral.

[0035] The first field represents the device type, used to identify the type of peripheral. Different types of peripherals (such as communication devices, sensors, storage devices, etc.) use different processing methods and communication protocols. The device type field helps to distinguish the type of peripheral by assigning specific values (for example, 0x1 represents UART peripheral, 0x2 represents SPI peripheral, etc.). In the implementation process, the peripheral transmits its type information to the control end through this field, so that the subsequent operation can select the corresponding processing mode according to the type of peripheral.

[0036] The second field represents the device serial number, used to distinguish multiple peripherals of the same type. In an environment, there may be multiple peripherals of the same type, such as multiple UART devices or multiple sensors. To avoid conflict or confusion, the device serial number field assigns a unique identifier to each peripheral of the same type. Through this field, each peripheral can be accurately identified, and each peripheral can be correctly accessed and operated. In the implementation, the device serial number is used as an identifier in data exchange to distinguish different peripherals of the same type.

[0037] The third field is the occupation state, used to mark whether the peripheral is occupied. This field is represented in binary, 1 representing that the peripheral has been occupied, and 0 representing that the peripheral is idle. The occupation state field is crucial in peripheral management, especially when multiple SOCs share peripherals, the occupation of each peripheral must be dynamically tracked. Through this field, the use of the peripheral can be tracked in real time. When a peripheral is accessed, the occupation state field is set to 1, indicating that the peripheral has been occupied and cannot be accessed again; if the field is 0, the peripheral is available.

[0038] The fourth field represents a peripheral loading and unloading request, which is used to control the dynamic loading and unloading of the peripheral. 1 represents a request to load the peripheral, and 0 represents a request to unload the peripheral. Through this field, the dynamic management of the peripheral can be realized, and the peripheral can be loaded or unloaded at any time according to the demand. The loading request usually occurs when a new peripheral needs to be used, and the unloading request is issued when the peripheral is no longer needed. The function of this field is to load or unload the peripheral in time when needed, so as to optimize the resource utilization and control the life cycle of the peripheral.

[0039] Through the cooperation of the four fields, the self-defined bus protocol realizes accurate management and efficient control of the peripheral.

[0040] Further, the method provided by the application embodiment further comprises:

[0041] The first peripheral has a first configuration space and a first data space, wherein the first configuration space is used to store the control field, and the first data space is used to store the communication data.

[0042] In the application embodiment, the first peripheral has a first configuration space and a first data space. The first configuration space is used to store the control field, and the control field includes the running parameters, state settings and control commands of the peripheral, which are used to manage the operation mode and function configuration of the peripheral. The first data space is used to store the communication data, which includes the information received or sent by the peripheral in the data transmission process, supports the data exchange between the peripheral and other devices or interfaces, and thus realizes the function operation and information transmission.

[0043] Step S300: dynamically scanning the FPGA program to obtain a bus scanning result.

[0044] In the application embodiment, when the dynamic scanning is started, the FPGA program first activates the peripheral interface layer, which is pre-configured with SPI, UART, I2C and other bus protocol soft cores, and is used to monitor the communication activities of the peripheral on the bus in real time. The peripheral interface layer captures the communication data of the peripheral through the protocol soft core, and extracts the device type, device serial number and other key information. Then, the data is transmitted to the protocol analysis layer for further processing. In the protocol analysis layer, the FPGA program analyzes and converts the captured data according to the format of the self-defined bus protocol, and the analyzed data fields include the device type, device serial number, occupation state and peripheral loading and unloading request and other key information. The analyzed data is sent to the peripheral instance layer, and the peripheral instance layer dynamically updates the configuration space and data space of the corresponding peripheral according to the received information, so as to ensure that the state information of each peripheral is complete and up-to-date. Finally, the peripheral instance layer summarizes and arranges the information of all peripherals, and generates a bus scanning result.

[0045] Step S400: reading a predetermined startup strategy, and judging whether the bus scan result meets the predetermined startup constraint according to the predetermined startup strategy.

[0046] In the embodiment of the present application, the predetermined startup strategy is first read, which is a pre-configured rule set used to define the startup condition of the peripheral device, such as the matching requirement of the key fields of the peripheral device, such as the device type, device serial number, and occupation state.

[0047] Next, the peripheral device information in the bus scan result is extracted in sequence, especially the key fields in the configuration space of each peripheral device, including the device type field (used to identify the peripheral device type, such as UART, GPIO, etc.), the occupation state field (indicating whether the peripheral device is currently occupied, 1 indicating occupied, and 0 indicating not occupied), and other self-defined protocol fields. By comparing with the conditions in the predetermined startup strategy, it is judged whether the current peripheral device meets the startup constraint. For example, the startup constraint may stipulate that only the UART type device which is not occupied (occupation state is 0) is allowed to be loaded.

[0048] If the field value of a peripheral device completely matches the startup strategy, it is considered that the peripheral device meets the startup constraint, and a startup instruction is generated, and the driver of the target peripheral device is loaded onto the specified SOC. If a peripheral device does not meet the startup constraint, the peripheral device is skipped, and the next peripheral device is judged, until all scan results are traversed.

[0049] Step S500: if the bus scan result meets the predetermined startup constraint, issuing a startup instruction, and performing driver loading on the target driver based on the startup instruction.

[0050] In the embodiment of the present application, if the bus scan result meets the predetermined startup constraint, the stage of starting and loading the driver is entered, specifically, when the information of a peripheral device (such as the device type, device serial number, occupation state, and other fields) completely meets the conditions of the predetermined startup constraint, a startup instruction is generated. The startup instruction is control information used to trigger driver loading, which contains the identification field of the peripheral device, used to explicitly indicate the target of the loading operation.

[0051] First, the configuration information of the target peripheral device is extracted from the bus scan result. These configuration information includes the device type field (indicating the type of the peripheral device, such as UART, I2C, etc.) and the device serial number field (used to distinguish specific instances of the same type of device), through which the pertinence of the startup instruction is ensured.

[0052] Then, the loading process is started according to the start instruction. The first step of the loading process is to locate the corresponding driver according to the device type field of the peripheral device. The driver is stored in a preset driver library, and the target driver is quickly indexed through the device type field. Then, the occupation state field of the peripheral device is checked (this field is used to indicate whether the peripheral device has been used, and a value of 1 indicates that it is occupied, and a value of 0 indicates that it is not occupied). If the occupation state is not occupied (value 0), the corresponding driver is started to be loaded.

[0053] After the driver is loaded, the running configuration of the peripheral device is initialized, and the occupation state field of the peripheral device is updated to occupied (value 1) to prevent other drivers from repeatedly using the peripheral device resource.

[0054] Through this process, the peripheral device that meets the conditions is loaded into the specified environment and can be put into use, while ensuring the exclusivity of the peripheral device and avoiding resource conflicts and repeated operations.

[0055] Further, the method provided by the application embodiment further comprises the following steps if the bus scan result meets the predetermined start constraint:

[0056] Step a: extracting the first scan result of the first peripheral device in the bus scan result; step b: extracting the first configuration space scan result in the first scan result, the first configuration space scan result comprising a first occupation state field; step c: judging whether the first occupation state field meets the predetermined start constraint according to the predetermined start strategy; step d: issuing a first start instruction if the first occupation state field meets the predetermined start constraint; and step e: loading the first driver corresponding to the first peripheral device as the target driver based on the first start instruction.

[0057] In the application embodiment, when step a is performed, the first scan result of the first peripheral device is extracted from the bus scan result. The first scan result is an entry in the bus scan result, which contains all information related to the first peripheral device, including but not limited to the device type, the device serial number and the configuration space information.

[0058] Then, step b is entered, and the first configuration space scan result is extracted from the first scan result. The first configuration space scan result comprises a first occupation state field, which is a key parameter for judging the current use of the first peripheral device, and a value of 1 indicates that it is occupied, and a value of 0 indicates that it is not occupied.

[0059] In step c, it is judged whether the first occupation state field meets the predetermined start constraint according to a predetermined start strategy. The predetermined start strategy is a preset set of rules for determining whether the peripheral device meets the start condition. For example, the first occupation state field must be 0 (unoccupied) to meet the predetermined start constraint. If the value of the first occupation state field meets the predetermined start constraint, the next step is executed; otherwise, the peripheral device is skipped.

[0060] In step d, if the first occupation state field meets the predetermined start constraint, a first start instruction is generated and sent. The first start instruction contains the device type and device serial number of the first peripheral device, and is used to specify the target peripheral device of the loading operation.

[0061] Finally, in step e, the first driver corresponding to the first peripheral device is loaded as the target driver based on the first start instruction. When the driver is loaded, the driver program matched with the device type of the first peripheral device is searched from the driver library, and the loading process is completed. After the loading is successful, the first occupation state field in the first configuration space of the first peripheral device is updated and set to 1 (occupied) to prevent other devices from repeatedly using the first peripheral device.

[0062] Through the above steps, it is ensured that the use of the first peripheral device meets the predetermined start strategy, and the driver loading is efficiently completed, thereby maintaining the accuracy and consistency of the peripheral resource pooling management in the multi-SOC environment.

[0063] Further, in the method provided by the application embodiment, according to the predetermined start strategy, it is judged whether the first occupation state field meets the predetermined start constraint, and the method further includes:

[0064] If the first occupation state field does not meet the predetermined start constraint, a first return instruction is sent; based on the first return instruction, the second scan result of the second peripheral device in the bus scan result is returned; the second scan result is taken as the first scan result, and steps b to e are repeated.

[0065] In the application embodiment, when the first occupation state field does not meet the predetermined start constraint, the first return instruction is immediately sent. The first return instruction is a control signal for instructing to skip the operation of the current peripheral device and return to the scan result of other peripheral devices in the bus scan result to continue the judgment and processing of the peripheral devices.

[0066] Based on the first return instruction, the second scan result of the second peripheral device is extracted from the bus scan result. The second scan result has the same structure as the first scan result, and contains the device type, device serial number, configuration space and other key information of the peripheral device.

[0067] The second scanning result is then used as the first scanning result to continue the subsequent processing steps. Specifically, configuration space information is extracted from the second scanning result, including a second occupancy status field. This field is also used to indicate whether the second peripheral device has been occupied (a value of 1 indicates that it has been occupied, and a value of 0 indicates that it has not been occupied).

[0068] According to the predetermined startup strategy, it is determined again whether the second occupancy status field meets the predetermined startup constraint. If the second occupancy status field meets the predetermined startup constraint, a first startup instruction is issued to perform a drive loading process corresponding to the first peripheral device. Otherwise, if the second occupancy status field does not meet the predetermined startup constraint, a first return instruction is issued again to skip the peripheral device, and the scanning result of the next peripheral device is extracted from the bus scanning result. This process repeats steps b to e described above to ensure that all peripheral devices on the bus are checked one by one, and a startup instruction is issued to the peripheral device that meets the predetermined startup constraint to complete the drive loading. By introducing the first return instruction and the dynamic jump mechanism, peripheral devices that do not meet the condition can be efficiently skipped, resource waste is avoided, and peripheral devices that meet the condition are correctly loaded in priority order, thereby achieving precise allocation and management of peripheral device resources.

[0069] Further, the method provided by the application embodiment further comprises:

[0070] It is determined whether the target drive has a target configuration file. If not, the target drive is loaded through the first peripheral device. If yes, a target peripheral device of the target drive is matched according to the target configuration file, and the target drive is loaded through the target peripheral device.

[0071] In the application embodiment, in the drive loading process, it is first determined whether the target drive has a target configuration file. The target configuration file is a file that provides specific parameters and running rules for drive loading and peripheral device initialization, and usually contains information such as the device type, device serial number, and communication parameters of the peripheral device. The process of determining whether the target configuration file is present is implemented through a file indexing mechanism, and the drive loading logic will search for the configuration file corresponding to the target drive in a preset path.

[0072] If the target drive does not have a target configuration file, the target drive is directly loaded through the first peripheral device. The process of direct loading includes searching for a drive file that matches the device type and device serial number of the first peripheral device from a drive library, and initializing the drive according to default parameters after loading. In this case, the basic information of the peripheral device is used to complete the drive binding, ensuring that the basic functions of the peripheral device are available.

[0073] If the target driver has a target configuration file, the target peripheral of the target driver is matched according to the target configuration file. The matching process is performed by comparing the device type and device serial number recorded in the configuration file with the peripheral information in the bus scanning result item by item to ensure the matching accuracy of the target configuration file and the actual peripheral.

[0074] After the matching is completed, the target driver is loaded by the target peripheral. This step uses the specific parameters (such as data format, protocol type, etc.) provided in the target configuration file to initialize and load the target driver, and at the same time, the occupation state field of the peripheral is updated to occupied (value 1) to avoid resource conflicts. After the loading is completed, a communication connection is established between the driver and the target peripheral to ensure that the peripheral can normally operate in the manner defined by the configuration file.

[0075] Through this process, flexible judgment is realized on whether the target driver has a target configuration file, and appropriate loading mode is selected according to the judgment result. Whether the target driver has a target configuration file or not, the peripheral resource can be effectively managed, and the adaptability and running efficiency of the driver loading are improved.

[0076] Further, the method provided by the application embodiment further comprises:

[0077] sending a peripheral loading and unloading request through the bus protocol soft core; extracting a loading and unloading device type and a loading and unloading device serial number in the peripheral loading and unloading request; matching a target loading and unloading peripheral according to the loading and unloading device type and the loading and unloading device serial number; judging whether the target loading and unloading peripheral is occupied, if not, loading a corresponding peripheral driver, and setting an occupation field in a target loading and unloading configuration space of the target loading and unloading peripheral to occupied, if yes, unloading the corresponding peripheral driver, and setting the occupation field in the target loading and unloading configuration space to unoccupied.

[0078] In the application embodiment, the key step of realizing the dynamic management of the peripheral is to send the peripheral loading and unloading request through the bus protocol soft core. The bus protocol soft core encapsulates the control information of the peripheral operation, and sends the loading and unloading request in the form of a data packet, which contains the loading and unloading device type and the loading and unloading device serial number. The loading and unloading device type is used to distinguish the types of the peripheral, such as UART, etc.; and the loading and unloading device serial number is used to uniquely identify the specific peripheral of the same type.

[0079] After receiving the loading and unloading request, the loading and unloading device type and the loading and unloading device serial number are extracted, and the target loading and unloading peripheral is matched from the peripheral list. The matching is based on the device type and the serial number in the request, and is compared with the information in the peripheral list item by item to locate the peripheral to be operated.

[0080] After the matching is completed, the occupancy status of the target loadable peripheral device is checked. By reading the occupancy field in the configuration space of the target peripheral device, it is determined whether the peripheral device is currently in use. An occupancy field of 0 indicates that the peripheral device is not occupied, and an occupancy field of 1 indicates that the peripheral device is occupied. If the target peripheral device is not occupied, the peripheral device driver is loaded. During the loading process, according to the type of the loadable peripheral device, a matching driver file is searched from the driver file library, and the loading operation is completed. At the same time, the occupancy field of the target peripheral device is updated to 1, indicating that the peripheral device is in use, preventing repeated operations.

[0081] If the occupancy field indicates that the target peripheral device is occupied, an unloading operation is performed. The unloading includes unbinding the peripheral device from the driver, releasing resources, and updating the occupancy field to 0, indicating that the peripheral device is in an unoccupied state, allowing reloading.

[0082] Through this process, the peripheral device can be dynamically loaded or unloaded according to the needs, ensuring flexible allocation and effective use of resources.

[0083] In the embodiments of the present application, the above-mentioned embodiments have at least the following technical effects:

[0084] The SOC set is constructed, and a first SOC in the SOC set is extracted, wherein the first SOC has a first peripheral device; the first peripheral device is connected to a predetermined peripheral bus through a full exchange high-speed bus, wherein the predetermined peripheral bus refers to an FPGA program; a bus scan result is obtained by dynamically scanning the FPGA program; a predetermined startup strategy is read, and it is judged whether the bus scan result conforms to the predetermined startup constraint according to the predetermined startup strategy; if the bus scan result conforms to the predetermined startup constraint, a startup instruction is issued, and a target driver is loaded based on the startup instruction. The present application solves the technical problem of low peripheral resource sharing efficiency in the prior art, connects the first peripheral device of the first SOC to the predetermined peripheral bus through the full exchange high-speed bus, extracts bus information by dynamic scanning and judges the peripheral device state in combination with the predetermined startup strategy, generates a startup instruction to realize driver loading, and achieves the technical effect of efficient management of peripheral resources.

[0085] Embodiment two, based on the same inventive concept as the peripheral resource pooling management design method in one of the preceding embodiments, as Figure 2 shown, the present application provides a peripheral resource pooling management design system under multiple SOCs, and the system and method embodiments in the present application are based on the same inventive concept.

[0086] The system comprises:

[0087] The SOC set assembly module 11 is configured to assemble a SOC set and extract a first SOC in the SOC set, wherein the first SOC is provided with a first peripheral device; the connection module 12 is configured to connect the first peripheral device to a predetermined peripheral bus through a full exchange high-speed bus, wherein the predetermined peripheral bus refers to an FPGA program; the scanning module 13 is configured to perform dynamic scanning on the FPGA program to obtain a bus scanning result; the startup strategy reading module 14 is configured to read a predetermined startup strategy and determine whether the bus scanning result meets a predetermined startup constraint according to the predetermined startup strategy; and the driver loading module 15 is configured to issue a startup instruction if the bus scanning result meets the predetermined startup constraint, and load a target driver based on the startup instruction.

[0088] Further, the system is further configured to implement the following functions:

[0089] The peripheral interface layer is obtained, wherein the peripheral interface layer pre-stores a bus protocol soft core, and the bus protocol soft core is configured to interconnect the first peripheral device and the predetermined peripheral bus; the protocol analysis layer is obtained, wherein the protocol analysis layer is configured to convert the bus protocol soft core into a custom bus protocol; the peripheral instance layer is obtained, wherein the peripheral instance layer is configured to maintain and manage the first peripheral device; and the predetermined peripheral bus is composed based on the peripheral interface layer, the protocol analysis layer and the peripheral instance layer.

[0090] Further, the system is further configured to implement the following functions:

[0091] The bus protocol soft core at least integrates SPI, UART and I2C protocols.

[0092] Further, the system is further configured to implement the following functions:

[0093] The custom bus protocol includes a first field, a second field, a third field and a fourth field, wherein the first field refers to a device type, is configured to identify the type of peripheral device, the second field refers to a device serial number, is configured to distinguish peripheral devices of the same type, the third field refers to an occupation state, and is represented by 1 to indicate that it has been occupied, and is represented by 0 to indicate that it has not been occupied, and the fourth field refers to a peripheral device loading and unloading request, and is represented by 1 to indicate loading, and is represented by 0 to indicate unloading.

[0094] Further, the system is further configured to implement the following functions:

[0095] The first peripheral device is provided with a first configuration space and a first data space, wherein the first configuration space is configured to store a control field, and the first data space is configured to store communication data.

[0096] Further, the system is further used to realize the following functions:

[0097] Step a: extracting the first scan result of the first peripheral device in the bus scan result; step b: extracting the first configuration space scan result in the first scan result, the first configuration space scan result including a first occupation state field; step c: judging whether the first occupation state field conforms to the predetermined start constraint according to the predetermined start strategy; step d: if the first occupation state field conforms to the predetermined start constraint, issuing a first start instruction; step e: loading the first drive corresponding to the first peripheral device as the target drive based on the first start instruction.

[0098] Further, the system is further used to realize the following functions:

[0099] If the first occupation state field does not conform to the predetermined start constraint, a first return instruction is issued; based on the first return instruction, returning to the second scan result of a second peripheral device in the bus scan result; taking the second scan result as the first scan result, and repeating steps b to e.

[0100] Further, the system is further used to realize the following functions:

[0101] Judging whether the target drive has a target configuration file; if not, loading the target drive through the first peripheral device; if yes, matching the target peripheral device of the target drive according to the target configuration file, and loading the target drive through the target peripheral device.

[0102] Further, the system is further used to realize the following functions:

[0103] Sending a peripheral loading and unloading request through the bus protocol soft core; extracting a loading and unloading device type and a loading and unloading device serial number in the peripheral loading and unloading request; matching a target loading and unloading peripheral according to the loading and unloading device type and the loading and unloading device serial number; judging whether the target loading and unloading peripheral is occupied, if not, loading a corresponding peripheral drive, and setting an occupation field in a target loading and unloading configuration space of the target loading and unloading peripheral as occupied, if yes, unloading a corresponding peripheral drive, and setting the occupation field in the target loading and unloading configuration space as unoccupied.

[0104] It should be noted that the above-mentioned sequence of the embodiments of the present application is only for description, and does not represent the advantages and disadvantages of the embodiments. The above-mentioned specific embodiments of the present application are described. The processes depicted in the drawings do not necessarily require the specific order and continuous order shown to achieve the desired results. In some embodiments, multi-task processing and parallel processing are possible or can be advantageous.

[0105] The above description is merely exemplary of the application, one skilled in the art will readily devise many variations and modifications of the application without departing from the scope of the application as defined by the following claims. Accordingly, all such variations and modifications are intended to be included within the scope of the application.

[0106] The description and drawings are merely illustrative of the application and do not limit the scope of the application as do the appended claims, which by themselves are illustrative of the application. Consequently, any modifications, changes, combinations, or equivalents of the application falling within the scope of the application are intended to be included in the scope of the application.

Claims

1. A method for managing a pool of peripheral resources in a multi-SOC system, the method comprising: identifying a plurality of peripheral resources in a plurality of SOC systems; and pooling the plurality of peripheral resources in the plurality of SOC systems. The method comprises the following steps: Assembling a SOC set and extracting a first SOC in the SOC set, wherein the first SOC is provided with a first peripheral device; Connecting the first peripheral device to a predetermined peripheral bus through a full exchange high-speed bus, wherein the predetermined peripheral bus refers to an FPGA program; Performing dynamic scanning on the FPGA program to obtain a bus scanning result; Reading a predetermined startup strategy and judging whether the bus scanning result meets the predetermined startup constraint according to the predetermined startup strategy; If the bus scanning result meets the predetermined startup constraint, issuing a startup instruction and loading a target driver based on the startup instruction.

2. The method of claim 1, wherein, Connecting the first peripheral device to a predetermined peripheral bus through a full exchange high-speed bus, wherein the predetermined peripheral bus refers to an FPGA program, comprising: Obtaining a peripheral interface layer, wherein a bus protocol soft core is pre-stored in the peripheral interface layer, wherein the bus protocol soft core is used for interconnecting the first peripheral device and the predetermined peripheral bus; Obtaining a protocol analysis layer, which is used for converting the bus protocol soft core into a self-defined bus protocol; Obtaining a peripheral instance layer, which is used for maintaining and managing the first peripheral device; Based on the peripheral interface layer, the protocol analysis layer and the peripheral instance layer, the predetermined peripheral bus is composed.

3. The method of claim 2, wherein, The bus protocol soft core at least integrates SPI, UART and I2C protocols.

4. The method of claim 2, wherein, The self-defined bus protocol comprises a first field, a second field, a third field and a fourth field, wherein the first field refers to a device type, which is used for identifying the type of the peripheral device, the second field refers to a device serial number, which is used for distinguishing the peripheral devices of the same type, the third field refers to an occupation state, and 1 represents occupied and 0 represents unoccupied, and the fourth field refers to a peripheral loading and unloading request, and 1 represents loading and 0 represents unloading.

5. The method of claim 2, wherein, The first peripheral device is provided with a first configuration space and a first data space, wherein the first configuration space is used for storing a control field, and the first data space is used for storing communication data.

6. The method of claim 1, wherein, If the bus scanning result meets the predetermined startup constraint, issuing a startup instruction and loading a target driver based on the startup instruction, comprising: Step a: extracting a first scanning result of the first peripheral device in the bus scanning result; Step b: extracting a first configuration space scanning result in the first scanning result, wherein the first configuration space scanning result comprises a first occupation state field; Step c: judging whether the first occupation state field meets the predetermined startup constraint according to the predetermined startup strategy; Step d: if the first occupation state field meets the predetermined startup constraint, issuing a first startup instruction; Step e: loading a first driver corresponding to the first peripheral device as the target driver based on the first startup instruction.

7. The method of claim 6, wherein, If the first occupation state field does not meet the predetermined startup constraint, issuing a first return instruction. ​ returning to the bus scan result based on the first return instruction to a second peripheral of the bus scan result; repeating steps b to e with the second scan result as the first scan result.

8. The method of claim 1, wherein, Further comprising: determining whether the target driver has a target configuration file; if not, loading the target driver through the first peripheral; if yes, matching the target peripheral of the target driver according to the target configuration file, and loading the target driver through the target peripheral.

9. The method of claim 2, wherein, Further comprising: sending a peripheral loading and unloading request through the bus protocol soft core; extracting the loading and unloading device type and the loading and unloading device serial number in the peripheral loading and unloading request; matching a target loading and unloading peripheral according to the loading and unloading device type and the loading and unloading device serial number; determining whether the target loading and unloading peripheral is occupied, if not, loading the corresponding peripheral driver, and setting the occupation field in the target loading and unloading configuration space of the target loading and unloading peripheral as occupied, if yes, unloading the corresponding peripheral driver, and setting the occupation field in the target loading and unloading configuration space as unoccupied.

10. A pool management design system for peripheral resources under multiple SOCs, characterized by: The system comprises: a SOC set assembly module, configured to assemble a SOC set and extract a first SOC in the SOC set, wherein the first SOC has a first peripheral; a connection module, configured to connect the first peripheral to a predetermined peripheral bus through a full exchange high-speed bus, wherein the predetermined peripheral bus refers to an FPGA program; a scan module, configured to dynamically scan the FPGA program to obtain a bus scan result; a start strategy reading module, configured to read a predetermined start strategy, and determine whether the bus scan result meets a predetermined start constraint according to the predetermined start strategy; a driver loading module, configured to issue a start instruction if the bus scan result meets the predetermined start constraint, and load a target driver based on the start instruction.

Images