Pooling management design method and system for peripheral resources under multiple SOCs

Abstract

The invention discloses a pooling management design method and system for peripheral resources under multiple SOCs, and relates to the technical field of pooling management, and the method comprises the steps: building an SOC set, and extracting a first SOC in the SOC set, the first SOC being provided with a first peripheral; the first peripheral is connected to a preset peripheral bus through a full-exchange high-speed bus, and the preset peripheral bus refers to an FPGA program; dynamically scanning the FPGA program to obtain a bus scanning result; reading a predetermined starting strategy, and judging whether the bus scanning result conforms to a predetermined starting constraint or not according to the predetermined starting strategy; and if the bus scanning result accords with the preset starting constraint, sending a starting instruction, and carrying out drive loading on a target drive based on the starting instruction. The technical problem of low peripheral resource sharing efficiency in the prior art is solved, and the technical effect of efficient management of peripheral resources is achieved.

Description

Technical Field

[0001] The present invention relates to the technical field of pooling management, and in particular to a pooling management design method and system for peripheral resources under multiple SOCs. Background Art

[0002] With the complexity and diversification of embedded application scenarios, the resources of a single SOC system can no longer meet the requirements of high performance and high efficiency. In this context, integrating multiple SOCs into a hardware board to form a multi-SOC architecture has become a mainstream design approach. However, in a multi-SOC environment, due to the lack of a unified peripheral resource sharing mechanism between SOCs, the utilization efficiency of peripheral resources is low, and resource conflicts and repeated occupancy often occur, which significantly limits the performance optimization and expansion capabilities of the multi-SOC system. Summary of the invention

[0003] The present application provides a pool management design method and system for peripheral resources under multiple SOCs, which are 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 pooling management design method and system for peripheral resources under multiple SOCs.

[0005] In a first aspect of the present application, a pooling management design method for peripheral resources under multiple SOCs is provided, the method comprising:

[0006] A SOC set is formed, and a first SOC in the SOC set is extracted, wherein the first SOC has a first peripheral; the first peripheral is connected to a predetermined peripheral bus through a fully switched high-speed bus, wherein the predetermined peripheral bus refers to an FPGA program; the FPGA program is dynamically scanned to obtain a bus scan result; a predetermined startup strategy is read, and whether the bus scan result meets a predetermined startup constraint is determined according to the predetermined startup strategy; if the bus scan result meets the predetermined startup constraint, a startup instruction is issued, and a driver is loaded to a target driver based on the startup instruction.

[0007] A second aspect of the present application provides a pooling management design system for peripheral resources under multiple SOCs, the system comprising:

[0008] A SOC set building module, the SOC set building module is used to build a SOC set and extract the first SOC in the SOC set, wherein the first SOC has a first peripheral; a connection module, the connection module is used to connect the first peripheral to a predetermined peripheral bus through a full-switching high-speed bus, wherein the predetermined peripheral bus refers to an FPGA program; a scanning module, the scanning module is used to dynamically scan the FPGA program to obtain a bus scanning result; a startup strategy reading module, the startup strategy reading module is used to read a predetermined startup strategy, and determine whether the bus scanning result meets the predetermined startup constraints according to the predetermined startup strategy; a driver loading module, the driver loading module is used to issue a startup instruction if the bus scanning result meets the predetermined startup constraints, and load the driver to the target driver based on the startup instruction.

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

[0010] The present application forms a SOC set, and extracts the first SOC in the SOC set, wherein the first SOC has a first peripheral; connects the first peripheral to a predetermined peripheral bus through a fully switched high-speed bus, wherein the predetermined peripheral bus refers to an FPGA program; dynamically scans the FPGA program to obtain a bus scan result; reads a predetermined startup strategy, and determines whether the bus scan result meets the predetermined startup constraints according to the predetermined startup strategy; if the bus scan result meets the predetermined startup constraints, issues a startup instruction, and loads the target driver based on the startup instruction. The present invention solves the technical problem of low efficiency in peripheral resource sharing in the prior art, connects the first peripheral of the first SOC to a predetermined peripheral bus through a fully switched high-speed bus, extracts bus information through dynamic scanning and determines the peripheral status in combination with a predetermined startup strategy, generates a startup instruction to implement driver loading, and achieves the technical effect of efficient management of peripheral resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0012] Figure 1 A schematic diagram of a flow chart of a pooling management design method for peripheral resources under multiple SOCs provided in an embodiment of the present application;

[0013] Figure 2 A schematic diagram of the structure of a pooled management design system for peripheral resources under multiple SOCs provided in an embodiment of the present application.

[0014] Description of the accompanying drawings: SOC 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 pooled 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. A first peripheral of a first SOC is connected to a predetermined peripheral bus through a fully switched high-speed bus, bus information is extracted by dynamic scanning, and the peripheral status is determined in combination with a predetermined startup strategy, and a startup instruction is generated to realize driver loading, thereby achieving the technical effect of efficient management of peripheral resources.

[0016] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0017] It should be noted that any variations of the terms "include" and "have" are intended to cover non-exclusive inclusions. For example, a process, method, system, product or server that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or modules that are not explicitly listed or inherent to these processes, methods, products or devices.

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

[0019] Step S100: forming a SOC set, and extracting a first SOC from the SOC set, wherein the first SOC has a first peripheral device.

[0020] In an embodiment of the present application, a SOC set is first formed. In this step, multiple independent SOCs are selected and combined into a unified system. Each SOC has certain computing power and peripheral resources, but they usually operate independently and cannot directly share peripheral resources. In order to enable these SOCs to work together and share resources, these SOCs are first integrated into a system through hardware interconnection (for example, a high-speed bus or a network connection). Currently, the interconnection between SOCs is achieved by designing hardware integrated circuits (ICs) or using high-performance bus standards (such as PCIe, Ethernet, etc.). These SOCs are interconnected through a high-speed bus and work together to form a SOC set.

[0021] After the SOC set is completed, a SOC is randomly 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, the peripherals possessed by the first SOC are determined through the steps of hardware scanning and peripheral initialization. Usually, the first SOC has at least one peripheral, called the first peripheral. These peripherals can be input and output devices (such as UART, SPI, GPIO interface, etc.), or hardware modules such as sensors and controllers. Specifically, peripherals are managed by configuring registers and drivers. First, the hardware interface is scanned to identify the peripheral type, and then control resources are allocated to these peripherals. Each peripheral will have a configuration space, including control fields and data storage space, to support sharing and management between multiple SOCs. Through this step, the peripherals of the first SOC are initialized and ready to be shared with other SOCs.

[0022] Step S200: Connecting the first peripheral to a predetermined peripheral bus via a fully switched high-speed bus, wherein the predetermined peripheral bus refers to an FPGA program.

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

[0024] Furthermore, in the method provided in the embodiment of the application, the first peripheral is connected to a predetermined peripheral bus through a fully switched high-speed bus, wherein the predetermined peripheral bus refers to an FPGA program, and further includes:

[0025] Acquire 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 to interconnect the first peripheral with the predetermined peripheral bus; acquire a protocol parsing layer, wherein the protocol parsing layer is used to convert the bus protocol soft core into a custom bus protocol; acquire a peripheral instance layer, wherein the peripheral instance layer is used to maintain and manage the first peripheral; and form the predetermined peripheral bus based on the peripheral interface layer, the protocol parsing layer and the peripheral instance layer.

[0026] In an embodiment of the present application, the peripheral interface layer is first obtained. 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 (such as SPI, UART, I2C, etc.) used by the peripheral 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 a pre-integrated soft core module. In this way, the protocol of the peripheral can adapt to the predetermined bus structure to ensure that the peripheral can correctly exchange data with other components.

[0027] Next, get the protocol parsing layer. The main function of the protocol parsing 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 by decoding and converting the peripheral protocol. The protocol parsing layer adapts the peripheral protocol to the internal bus protocol, so that the peripheral can communicate seamlessly with other devices according to specific needs.

[0028] Finally, the peripheral instance layer is obtained. 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 operating status and data of the peripheral to ensure that the resources of the peripheral can be shared between different SOCs without conflict.

[0029] Through the cooperation of the peripheral interface layer, protocol analysis layer and 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. These three work together to form a predetermined peripheral bus.

[0030] Furthermore, in the method provided in the application embodiment, the bus protocol soft core integrates at least SPI, UART and I2C protocols.

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

[0032] Furthermore, the method provided in the application embodiment also includes:

[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 the device type, which is used to identify the type of the peripheral, the second field refers to the device serial number, which is used to distinguish peripherals of the same type, the third field refers to the occupancy status, and 1 represents occupied and 0 represents unoccupied, and the fourth field refers to the peripheral loading and unloading request, and 1 represents loading and 0 represents unloading.

[0034] In an embodiment of the present application, the custom bus protocol identifies and manages peripherals through multiple fields, including a first field, a second field, a third field, and a fourth field. These fields define the data transmission format of the peripherals and are used to realize the identification, management, and control of the peripherals.

[0035] The first field indicates the device type, which is 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 distinguish the type of peripheral by assigning specific values ​​(for example, 0×1 for UART peripherals, 0×2 for SPI peripherals, etc.). In the implementation process, the peripheral passes its type information to the control end through this field so that subsequent operations can select the corresponding processing method based on the peripheral type.

[0036] The second field represents the device serial number, which is 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 conflicts or confusion, the device serial number field assigns a unique identifier to each peripheral of the same type. This field can accurately identify each peripheral and ensure that each peripheral can be accessed and operated correctly. In implementation, the device serial number is used as an identifier during data exchange to distinguish different peripherals of the same type.

[0037] The third field is the occupancy status, which is used to mark whether the peripheral is occupied. This field is represented in binary form, 1 means that the peripheral is occupied, and 0 means that the peripheral is idle. The occupancy status field is crucial in peripheral management, especially when multiple SOCs share peripherals, the occupancy of each peripheral must be tracked dynamically. This field can be used to track the usage of peripherals in real time. When a peripheral is accessed, the occupancy status field will be set to 1, indicating that the peripheral is occupied and cannot be accessed again; if the field is 0, it means that the peripheral is available.

[0038] The fourth field indicates the peripheral loading and unloading request, which is used to control the dynamic loading and unloading of peripherals. 1 indicates a request to load a peripheral, and 0 indicates a request to unload a peripheral. Through this field, dynamic management of peripherals can be achieved, and peripherals can be loaded or unloaded at any time according to demand. Load requests usually occur when a new peripheral needs to be used, while unload requests are issued when the peripheral is no longer needed. The purpose of this field is to load or unload peripherals instantly when needed to optimize resource utilization and control the life cycle of peripherals.

[0039] Through the coordination of these four fields, the custom bus protocol achieves precise management and efficient control of peripherals.

[0040] Furthermore, the method provided in the application embodiment also includes:

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

[0042] In an embodiment of the present application, the first peripheral device has a first configuration space and a first data space. The first configuration space is used to store a control field, which includes operating parameters, status settings, and control commands of the peripheral device, and is used to manage the operating mode and functional configuration of the peripheral device. The first data space is used to store communication data, which includes information received or sent by the peripheral device during data transmission, and supports data exchange between the peripheral device and other devices or interfaces, thereby realizing functional operation and information transmission.

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

[0044] In the embodiment of the present application, when the dynamic scan is started, the FPGA program first activates the peripheral interface layer, which presets the bus protocol soft cores such as SPI, UART, and I2C for real-time monitoring of the communication activities of the peripherals on the bus. The peripheral interface layer captures the communication data of the peripherals through the protocol soft core and extracts key information such as device type and device serial number. Subsequently, these data are passed to the protocol parsing layer for further processing. In the protocol parsing layer, the FPGA program parses and converts the captured data according to the format of the custom bus protocol, and the parsed data fields include key information such as device type, device serial number, occupancy status, and peripheral loading and unloading requests. The parsed 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 to ensure that the status information of each peripheral is complete and up-to-date. Finally, the peripheral instance layer summarizes and organizes the information of all peripherals to generate a bus scan result.

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

[0046] In an embodiment of the present application, a predetermined startup policy is first read, which is a pre-configured rule set for defining startup conditions of peripherals, such as matching requirements of key fields such as the device type, device serial number, and occupancy status of the peripherals.

[0047] Next, extract the peripheral information in the bus scan results in turn, especially the key fields in the configuration space of each peripheral, including the device type field (used to identify the type of peripheral, such as UART, GPIO, etc.), the occupancy status field (indicates whether the peripheral is currently occupied, 1 indicates occupied, 0 indicates unoccupied) and other custom protocol fields. By comparing with the conditions in the predetermined startup strategy, determine whether the current peripheral meets the startup constraints. For example, the startup constraint may stipulate that only unoccupied (occupancy status is 0) UART type devices are allowed to be loaded.

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

[0049] Step S500: If the bus scan result meets the predetermined startup constraint, a startup instruction is issued, and a driver is loaded to a 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 startup and driver loading stage is entered. Specifically, when the information of a peripheral device (such as device type, device serial number, occupancy status and other fields) fully meets the conditions of the predetermined startup constraint, a startup instruction is generated. The startup instruction is control information used to trigger driver loading, including the identification field of the peripheral device, which is used to clarify the target of the loading operation.

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

[0052] Then, the loading process is started according to the startup instruction. The first step of the loading process is to locate the corresponding driver according to the device type field of the peripheral. The driver is stored in the preset driver library, and the target driver is quickly indexed through the device type field. Subsequently, the occupancy status field of the peripheral is checked (this field is used to indicate whether the peripheral is in use, a value of 1 indicates occupied, and a value of 0 indicates unoccupied). If the occupancy status is unoccupied (a value of 0), the corresponding driver is loaded.

[0053] After the driver is loaded, the peripheral's running configuration is initialized and its occupied status field is updated to occupied (value 1) to prevent other drivers from reusing the peripheral resources.

[0054] Through this process, qualified peripherals are loaded into the specified environment so that they can be put into use, while ensuring the exclusivity of the peripherals to avoid resource conflicts and duplicate operations.

[0055] Furthermore, in the method provided in the embodiment of the application, if the bus scan result meets the predetermined startup constraint, a startup instruction is issued, and the target driver is loaded with a driver based on the startup instruction, and further includes:

[0056] Step a: extracting the first scan result of the first peripheral device from the bus scan result; step b: extracting the first configuration space scan result from the first scan result, the first configuration space scan result including a first occupied status field; step c: judging whether the first occupied status field complies with the predetermined startup constraint according to the predetermined startup strategy; step d: issuing a first startup instruction if the first occupied status field complies with the predetermined startup constraint; step e: based on the first startup instruction, loading the first driver corresponding to the first peripheral device as the target driver.

[0057] In the embodiment of the present application, when executing step a, a first scan result of the first peripheral 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, including but not limited to the device type, device serial number and configuration space information.

[0058] Then proceed to step b, extracting the first configuration space scanning result from the first scanning result. The first configuration space scanning result includes a first occupancy status field, which is a key parameter for determining the current usage of the first peripheral device. A value of 1 indicates that it is occupied, and a value of 0 indicates that it is not occupied.

[0059] In step c, according to the predetermined startup policy, it is determined whether the first occupied state field meets the predetermined startup constraint. The predetermined startup policy is a set of preset rules for determining whether the peripheral device meets the startup conditions. For example, the first occupied state field must be 0 (unoccupied) to meet the predetermined startup constraint. If the value of the first occupied state field meets the predetermined startup constraint, proceed to the next step; otherwise, skip the peripheral device.

[0060] Entering step d, if the first occupied state field meets the predetermined startup constraint, a first startup instruction is generated and issued. The first startup instruction includes the device type and device serial number of the first peripheral device, which is used to clearly specify the target peripheral device of the loading operation.

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

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

[0063] Furthermore, in the method provided in the embodiment of the application, judging whether the first occupancy status field meets the predetermined startup constraint according to the predetermined startup strategy further includes:

[0064] If the first occupied status field does not meet the predetermined startup constraint, issue a first return instruction; return to the second scan result of the second peripheral in the bus scan result based on the first return instruction; use the second scan result as the first scan result, and repeat steps b to e.

[0065] In the embodiment of the present application, when the first occupied state field does not meet the predetermined startup constraint, a first return instruction is immediately issued. The first return instruction is a control signal for instructing to skip the operation of the current peripheral and return to the scan results of other peripherals in the bus scan results to continue the judgment and processing of the peripheral.

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

[0067] Then, the second scan result is used as the first scan result to continue the subsequent processing steps. Specifically, the configuration space information in the second scan result is extracted, including the second occupancy status field. This field is also used to indicate whether the second peripheral device is occupied (a value of 1 indicates occupied, and a value of 0 indicates unoccupied).

[0068] According to the predetermined startup strategy, determine again whether the second occupied status field meets the predetermined startup constraints. If the second occupied status field meets the predetermined startup constraints, a first startup instruction is issued to execute the driver loading process corresponding to the first peripheral. On the contrary, if it does not meet the requirements, a first return instruction is issued again to skip the peripheral and extract the scan result of the next peripheral from the bus scan result. This process ensures that all peripherals on the bus are checked one by one by repeating the above steps b to e, and a startup instruction is issued to the peripherals that meet the predetermined startup constraints to complete the driver loading. By introducing the first return instruction and the dynamic jump mechanism, it is possible to efficiently skip peripherals that do not meet the conditions and avoid waste of resources. At the same time, it is ensured that peripherals that meet the conditions are correctly loaded in order of priority, so as to achieve accurate allocation and management of peripheral resources.

[0069] Furthermore, the method provided in the application embodiment also includes:

[0070] Determine whether the target driver has a target configuration file; if not, load the target driver through the first peripheral; if so, match the target peripheral of the target driver according to the target configuration file, and load the target driver through the target peripheral.

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

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

[0073] If the target driver has a target configuration file, the target peripherals of the target driver are matched according to the target configuration file. The matching process compares the device type and device serial number recorded in the configuration file with the peripheral information in the bus scan result item by item to ensure the accuracy of the match between the target configuration file and the actual peripherals.

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

[0075] Through this process, it is possible to flexibly determine whether the target driver has the target configuration file, and select the appropriate loading method based on the judgment result. Regardless of whether the target configuration file is available, it can ensure that peripheral resources are effectively managed, while improving the adaptability and operating efficiency of driver loading.

[0076] Furthermore, the method provided in the application embodiment also includes:

[0077] Send a peripheral load and unload request through the bus protocol soft core; extract the load and unload device type and the load and unload device serial number in the peripheral load and unload request; match the target load and unload peripheral according to the load and unload device type and the load and unload device serial number; determine whether the target load and unload peripheral is occupied, if not occupied, load the corresponding peripheral driver, and set the occupied field in the target load and unload configuration space of the target load and unload peripheral to occupied; if occupied, uninstall the corresponding peripheral driver, and set the occupied field in the target load and unload configuration space to unoccupied.

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

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

[0080] After the matching is completed, check the occupancy status of the target loading and unloading peripherals. By reading the occupancy field in the configuration space of the target peripheral, determine whether the peripheral is currently in use. If the occupancy field is 0, it means that the peripheral is not occupied, and if it is 1, it means that the peripheral is occupied. If the target peripheral is not occupied, start loading the peripheral driver. During the loading process, according to the type of loading and unloading device, search for the matching driver file from the driver file library and complete the loading operation. At the same time, update the occupancy field of the target peripheral to 1, marking the peripheral as being in use to prevent repeated operations.

[0081] If the occupied field shows that the target peripheral is occupied, the uninstall operation is performed. Uninstallation includes unbinding the peripheral from the driver, releasing resources, and updating the occupied field to 0, indicating that the peripheral is not occupied and allows reloading.

[0082] Through this process, peripherals can be dynamically loaded or unloaded according to demand, ensuring flexible allocation and effective utilization of resources.

[0083] In the embodiments of the present application, in summary, the embodiments of the present application have at least the following technical effects:

[0084] The present application forms a SOC set, and extracts the first SOC in the SOC set, wherein the first SOC has a first peripheral; connects the first peripheral to a predetermined peripheral bus through a fully switched high-speed bus, wherein the predetermined peripheral bus refers to an FPGA program; dynamically scans the FPGA program to obtain a bus scan result; reads a predetermined startup strategy, and determines whether the bus scan result meets the predetermined startup constraints according to the predetermined startup strategy; if the bus scan result meets the predetermined startup constraints, issues a startup instruction, and loads the target driver based on the startup instruction. The present invention solves the technical problem of low efficiency in peripheral resource sharing in the prior art, connects the first peripheral of the first SOC to a predetermined peripheral bus through a fully switched high-speed bus, extracts bus information through dynamic scanning and determines the peripheral status in combination with a predetermined startup strategy, generates a startup instruction to implement driver loading, and achieves the technical effect of efficient management of peripheral resources.

[0085] Embodiment 2 is based on the same inventive concept as the design method for pooling management of peripheral resources under multiple SOCs in the above embodiment. Figure 2 As shown, the present application provides a pooled management design system for peripheral resources under multiple SOCs. The system and method embodiments in the embodiments of the present application are based on the same inventive concept.

[0086] Wherein, the system comprises:

[0087] A SOC set building module 11, the SOC set building module 11 is used to build a SOC set and extract the first SOC in the SOC set, wherein the first SOC has a first peripheral; a connection module 12, the connection module 12 is used to connect the first peripheral to a predetermined peripheral bus through a full-switching high-speed bus, wherein the predetermined peripheral bus refers to an FPGA program; a scanning module 13, the scanning module 13 is used to dynamically scan the FPGA program to obtain a bus scanning result; a startup strategy reading module 14, the startup strategy reading module 14 is used to read a predetermined startup strategy, and determine whether the bus scanning result meets the predetermined startup constraint according to the predetermined startup strategy; a driver loading module 15, the driver loading module 15 is used to issue a startup instruction if the bus scanning result meets the predetermined startup constraint, and load the driver to the target driver based on the startup instruction.

[0088] Furthermore, the system is also used to implement the following functions:

[0089] Acquire 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 to interconnect the first peripheral with the predetermined peripheral bus; acquire a protocol parsing layer, wherein the protocol parsing layer is used to convert the bus protocol soft core into a custom bus protocol; acquire a peripheral instance layer, wherein the peripheral instance layer is used to maintain and manage the first peripheral; and form the predetermined peripheral bus based on the peripheral interface layer, the protocol parsing layer and the peripheral instance layer.

[0090] Furthermore, the system is also used to implement the following functions:

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

[0092] Furthermore, the system is also used 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 the device type, which is used to identify the type of the peripheral, the second field refers to the device serial number, which is used to distinguish peripherals of the same type, the third field refers to the occupancy status, and 1 represents occupied and 0 represents unoccupied, and the fourth field refers to the peripheral loading and unloading request, and 1 represents loading and 0 represents unloading.

[0094] Furthermore, the system is also used to implement the following functions:

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

[0096] Furthermore, the system is also used to implement the following functions:

[0097] Step a: extracting the first scan result of the first peripheral device from the bus scan result; step b: extracting the first configuration space scan result from the first scan result, the first configuration space scan result including a first occupied status field; step c: judging whether the first occupied status field complies with the predetermined startup constraint according to the predetermined startup strategy; step d: issuing a first startup instruction if the first occupied status field complies with the predetermined startup constraint; step e: based on the first startup instruction, loading the first driver corresponding to the first peripheral device as the target driver.

[0098] Furthermore, the system is also used to implement the following functions:

[0099] If the first occupied status field does not meet the predetermined startup constraint, issue a first return instruction; return to the second scan result of the second peripheral in the bus scan result based on the first return instruction; use the second scan result as the first scan result, and repeat steps b to e.

[0100] Furthermore, the system is also used to implement the following functions:

[0101] Determine whether the target driver has a target configuration file; if not, load the target driver through the first peripheral; if so, match the target peripheral of the target driver according to the target configuration file, and load the target driver through the target peripheral.

[0102] Furthermore, the system is also used to implement the following functions:

[0103] Send a peripheral load and unload request through the bus protocol soft core; extract the load and unload device type and the load and unload device serial number in the peripheral load and unload request; match the target load and unload peripheral according to the load and unload device type and the load and unload device serial number; determine whether the target load and unload peripheral is occupied, if not occupied, load the corresponding peripheral driver, and set the occupied field in the target load and unload configuration space of the target load and unload peripheral to occupied; if occupied, uninstall the corresponding peripheral driver, and set the occupied field in the target load and unload configuration space to 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. And the above-mentioned specific embodiments of this specification are described. The processes depicted in the accompanying drawings do not necessarily require the specific order and continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0105] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included in the protection scope of the present application.

[0106] This specification and drawings are merely exemplary illustrations of the present application and are deemed to cover any and all modifications, variations, combinations or equivalents within the scope of the present application. Obviously, a person skilled in the art may make various modifications and variations to the present application without departing from the scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the present application and its equivalents, the present application intends to include these modifications and variations.

Claims

1. A pool management design method for peripheral resources under multiple SOCs, characterized in that: include: Building a SOC set, and extracting a first SOC from the SOC set, wherein the first SOC has a first peripheral device; Connecting the first peripheral to a predetermined peripheral bus via a fully switched high-speed bus, wherein the predetermined peripheral bus is 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, a startup instruction is issued, and the target driver is loaded with a driver based on the startup instruction.

2. The method according to claim 1, characterized in that Connecting the first peripheral to a predetermined peripheral bus via a fully switched high-speed bus, wherein the predetermined peripheral bus refers to an FPGA program, including: Acquire 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 to interconnect the first peripheral with the predetermined peripheral bus; Acquire a protocol parsing layer, wherein the protocol parsing layer is used to convert the bus protocol soft core into a custom bus protocol; Acquire a peripheral device instance layer, where the peripheral device instance layer is used to maintain and manage the first peripheral device; The predetermined peripheral bus is formed based on the peripheral interface layer, the protocol parsing layer and the peripheral instance layer.

3. The method according to claim 2, characterized in that The bus protocol soft core integrates at least SPI, UART and I2C protocols.

4. The method according to claim 2, characterized in that The custom bus protocol includes a first field, a second field, a third field and a fourth field, wherein the first field refers to the device type, which is used to identify the type of the peripheral, the second field refers to the device serial number, which is used to distinguish peripherals of the same type, the third field refers to the occupancy status, and 1 represents occupied and 0 represents unoccupied, and the fourth field refers to the peripheral loading and unloading request, and 1 represents loading and 0 represents unloading.

5. The method according to claim 2, characterized in that The first peripheral device has a first configuration space and a first data space, wherein the first configuration space is used to store a control field, and the first data space is used to store communication data.

6. The method according to claim 1, characterized in that If the bus scan result meets the predetermined startup constraint, a startup instruction is issued, and a driver is loaded to the target driver based on the startup instruction, including: Step a: extracting the first scanning result of the first peripheral device from the bus scanning result; Step b: extracting a first configuration space scanning result from the first scanning result, wherein the first configuration space scanning result includes a first occupied state field; Step c: judging whether the first occupancy status field meets the predetermined startup constraint according to the predetermined startup strategy; Step d: If the first occupancy status field meets the predetermined startup constraint, issuing a first startup instruction; Step e: Based on the first startup instruction, load the first driver corresponding to the first peripheral device as the target driver.

7. The method according to claim 6, characterized in that Judging, according to the predetermined startup strategy, whether the first occupancy status field meets the predetermined startup constraint includes: If the first occupied state field does not meet the predetermined startup constraint, issuing a first return instruction; Returning a second scan result of a second peripheral device in the bus scan result based on the first return instruction; The second scanning result is used as the first scanning result, and steps b to e are repeated.

8. The method according to claim 1, characterized in that Also includes: Determining whether the target driver has a target configuration file; If not, loading the target driver through the first peripheral device; If available, the target peripheral device of the target driver is matched according to the target configuration file, and the target driver is loaded through the target peripheral device.

9. The method according to claim 2, characterized in that Also includes: Sending peripheral loading and unloading requests through the bus protocol soft core; Extracting the loading and unloading device type and loading and unloading device serial number in the peripheral loading and unloading request; Matching a target loading and unloading peripheral device according to the loading and unloading device type and the loading and unloading device sequence number; Determine whether the target load and unload peripheral is occupied. If it is not occupied, load the corresponding peripheral driver and set the occupied field in the target load and unload configuration space of the target load and unload peripheral to occupied. If it is occupied, uninstall the corresponding peripheral driver and set the occupied field in the target load and unload configuration space to unoccupied.

10. A pool management design system for peripheral resources under multiple SOCs, characterized in that: The system comprises: An SOC set building module, the SOC set building module is used to build an SOC set and extract a first SOC in the SOC set, wherein the first SOC has a first peripheral; A connection module, the connection module is used to connect the first peripheral to a predetermined peripheral bus through a fully switched high-speed bus, wherein the predetermined peripheral bus is an FPGA program; A scanning module, the scanning module is used to dynamically scan the FPGA program to obtain a bus scanning result; A startup strategy reading module, the startup strategy reading module is used to read a predetermined startup strategy, and determine whether the bus scan result meets the predetermined startup constraint according to the predetermined startup strategy; A driver loading module is used to issue a startup instruction if the bus scanning result meets the predetermined startup constraint, and load the driver to the target driver based on the startup instruction.

Images