Method, device and equipment for managing complex programmable logic device (CPLD)

Abstract

The invention provides a complex programmable logic device (CPLD) management method, device and equipment, and the method comprises the steps: generating a business operation instruction for a target virtual interface in an application layer, and transmitting the business operation instruction to a kernel, the target virtual interface being a virtual interface of a virtual controller registered in the kernel in advance; the method comprises the following steps: searching a target operation function registered in an equipment driving layer by a virtual controller through a kernel based on a business operation instruction, and calling the target operation function of the equipment driving layer to execute the following steps: based on a mapping relation between a virtual interface and a register base address in CPLD equipment; and converting the service operation instruction aiming at the target virtual interface into a register access command aiming at a target register base address in the target CPLD equipment, and sending the register access command to the target CPLD equipment through the bus. According to the method, the CPLD is designed to be a virtual controller to shield hardware equipment details upwards, software and hardware decoupling is achieved, and drive universality and maintainability are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of server monitoring, and in particular to a complex programmable logic device (CPLD) management method, device and equipment. BACKGROUND

[0002] In a modern server monitoring system, a baseboard management controller (BMC) is one of the core components, responsible for monitoring and managing the hardware state of the server (such as temperature, voltage, fan speed, etc.). The BMC usually runs a Linux operating system and communicates with various hardware devices through an Inter-Integrated Circuit (I2C) bus, including a complex programmable logic device (CPLD), which performs important functions in the system, such as detecting module status, monitoring the boot stage, managing hardware state, and transmitting control signals.

[0003] In a traditional system management scheme, the BMC directly accesses the registers of the CPLD through a general-purpose device driver to achieve communication, which has the advantage of simple structure, but as the system complexity increases, it gradually exposes problems such as outstanding performance bottlenecks, insufficient robustness, and poor compatibility. Especially in the context of multiple projects and multiple hardware platforms, any changes in hardware design, such as signal pin definitions or register mapping adjustments, will directly lead to modifications in BMC software logic. This close coupling between hardware dependency and software logic significantly increases the complexity and cost of system development and maintenance. SUMMARY

[0004] The CPLD management method, device, equipment and readable storage medium provided by the embodiments of the present application design the CPLD as a virtual controller, and through the virtual controller, the specific details of the CPLD device are shielded upwards, thereby reducing system calls, reducing software system overhead, and improving the real-time performance of monitoring data acquisition. Furthermore, by registering the virtual controller to a standard subsystem framework, the subsystem framework provides a unified interface, making the upper layer software design independent of hardware, enhancing the robustness and compatibility of the system.

[0005] In a first aspect, the embodiments of the present application propose a complex programmable logic device (CPLD) management method, comprising: generating a service operation instruction for a target virtual interface in an application layer, and sending it to a kernel, the target virtual interface being a virtual interface of a virtual controller pre-registered in the kernel; ​​The kernel finds a target operation function registered by the virtual controller in a device driver layer based on the service operation instruction, and calls the target operation function of the device driver layer to execute: The service operation instruction for the target virtual interface is converted into a register access command for a target register base address in a target CPLD device based on a mapping relationship between the virtual interface and the register base address in the CPLD device, and the register access command is sent to the target CPLD device via a bus protocol.

[0006] In some possible embodiments, the conversion of the service operation instruction for the target virtual interface into the register access command for the target register base address in the target CPLD device based on the mapping relationship between the virtual interface and the register base address in the CPLD device, and the sending of the register access command to the target CPLD device via the bus protocol include: The target register base address in the target CPLD device corresponding to the target virtual interface is determined based on a data structure stored in the device driver layer in advance, and the service operation instruction for the target virtual interface is converted into the register access command for the target register base address in the target CPLD device; The target CPLD device corresponding to the target virtual interface is determined based on a data structure stored in the device driver layer in advance, and the target bus address is determined based on the target bus address, and the register access command is sent to the target CPLD device via the bus based on the target bus address.

[0007] In some possible embodiments, before the service operation instruction for the target virtual interface is generated in the application layer, the method further includes: When the device driver layer performs initialization by traversing CPLD device nodes based on a predefined CPLD device hierarchical architecture, configuration information of each CPLD device node is read, and a virtual interface corresponding to each CPLD sub-device under each top-level CPLD device node is determined based on the configuration information; A virtual controller is created for each top-level CPLD device node by the device driver layer, and the virtual controller is configured and initialized according to the virtual interface, so that the virtual controller can manage the virtual interface, and a predefined operation function is configured into the virtual controller.

[0008] In some possible embodiments, the initialization of the device driver layer by traversing the CPLD device nodes based on the predefined CPLD device hierarchical architecture further includes: For the current CPLD device node traversed, based on the attribute of the CPLD device node and the predefined CPLD device hierarchical architecture, a data structure of the CPLD device node is initialized and configured, and is stored in private data in the device driver layer according to the predefined CPLD device hierarchical architecture.

[0009] In some possible embodiments, the initialization and configuration of the data structure of the CPLD device node based on the attribute of the CPLD device node and the predefined CPLD device hierarchical architecture comprises: When the CPLD device node is determined to be a top-layer CPLD device, the initialization and configuration of the data structure of the CPLD device node comprises a bus address, a virtual controller identifier, and a CPLD device identifier of a lower-layer CPLD device of the top-layer CPLD device; When the CPLD device node is determined to be a bottom-layer CPLD sub-device, the initialization and configuration of the data structure of the CPLD device node comprises a function description identifier corresponding to the CPLD sub-device, a CPLD device pointer of an upper-layer CPLD device of the CPLD sub-device, and a function description corresponding to a function of the CPLD sub-device is created and configured based on the function of the CPLD sub-device. The function description as a bottommost layer of the CPLD device hierarchical architecture comprises a CPLD sub-device pointer of an upper-layer of the function description, at least one virtual interface, a register base address corresponding to the CPLD sub-device, and a length of corresponding read-write data.

[0010] In some possible embodiments, the initialization and configuration of the data structure of the CPLD device node based on the attribute of the CPLD device node and the predefined CPLD device hierarchical architecture further comprises: When the CPLD device node is determined to be a middle-layer CPLD sub-device, the initialization and configuration of the data structure of the CPLD device node comprises a CPLD device pointer of an upper-layer CPLD device of the CPLD sub-device, a CPLD sub-device linked list, and a CPLD device identifier of a lower-layer CPLD device of the CPLD sub-device; If there is no CPLD sub-device, the CPLD device of the lower layer of the top-layer CPLD device is a CPLD sub-device; if there is a CPLD sub-device, the CPLD device of the lower layer of the top-layer CPLD device is a CPLD sub-device, and the CPLD device of the lower layer of the CPLD sub-device is a CPLD sub-device.

[0011] In some possible embodiments, the determination of the pin offset corresponding to the target virtual interface and the target register base address in the target CPLD device based on the data structure stored in the device driver layer in advance comprises: acquire a predefined CPLD device hierarchical architecture stored in the private data of the device driver layer, find a target function description corresponding to the target virtual interface based on the target virtual interface and the function description of the lowest layer in the CPLD device hierarchical architecture in the private data; find a data structure of a target CPLD sub-device corresponding to the target virtual interface based on the CPLD sub-device pointer of the upper layer in the target function description; find a target register base address corresponding to the target virtual interface based on the data structure of the target CPLD sub-device.

[0012] In some possible embodiments, the target CPLD device corresponding to the target virtual interface is determined based on a data structure stored in the device driver layer in advance. the bus address includes: find a data structure of a target upper layer CPLD device based on the CPLD device pointer of the upper layer in the data structure of the target CPLD sub-device, and acquire the target bus address in the corresponding data structure. the bus address includes: when the target upper layer CPLD device is determined to be a top layer CPLD device, acquire the target bus address in the corresponding data structure. the bus address includes: when the target upper layer CPLD device is determined to be an intermediate layer CPLD sub-device, find a data structure of a target upper layer CPLD device based on the CPLD device pointer of the upper layer in the data structure, until the target upper layer CPLD device is determined to be a top layer CPLD device, and acquire the target bus address in the corresponding data structure. the bus address includes:

[0013] In some possible embodiments, the service operation instruction includes a GPIO (General-Purpose Input / Output) control instruction or a HWMON (Hardware Monitoring) monitoring instruction.

[0014] In a second aspect, the embodiments of the present application provide a management apparatus of a complex editable logic device CPLD, which comprises: an instruction generation module, configured to generate a service operation instruction for a target virtual interface in an application layer, and send the service operation instruction to a kernel, the target virtual interface being a virtual interface of a virtual controller registered in the kernel in advance; The execution module is configured to, based on the service operation instruction, find a target operation function registered by the virtual controller in a device driver layer, and call the target operation function of the device driver layer to perform: based on a mapping relationship between the virtual interface and a register base address in a CPLD device, converting the service operation instruction for the target virtual interface into a register access command for a target register base address in the target CPLD device, and sending the register access command to the target CPLD device via the bus. The bus sends the register access command to the target CPLD device.

[0015] In a third aspect, an electronic device is provided, which includes at least one processor, and a memory connected to the at least one processor in communication; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the steps in the management method of a complex programmable logic device (CPLD) according to any one of the first aspect.

[0016] In a fourth aspect, a computer readable storage medium is provided, which stores computer executable instructions for performing the steps in the management method of a complex programmable logic device (CPLD) according to any one of the first aspect.

[0017] By the management method, device, and readable storage medium of a CPLD, the CPLD is designed as a virtual controller, and the specific details of the CPLD device are shielded to the upper layer software design, so that the hardware is irrelevant, thereby improving the performance, robustness, and compatibility of the system.

[0018] Other features and advantages of the present application will be set forth in the following description, and in part will become apparent to those skilled in the art from the following description, or can be learned by practice of the present application. The objects and other advantages of the present application can be achieved and obtained by means of the structures particularly pointed out in the written description, claims, and accompanying drawings. BRIEF DESCRIPTION OF DRAWINGS

[0019] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments of the present application. Obviously, the drawings to be introduced below are only some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor on the basis of these drawings.

[0020] Figure 1 A schematic diagram of the architecture of communication between the BMC and various hardware devices in the prior art; Figure 2 A flow chart of a management method of a complex programmable logic device (CPLD) in an embodiment of the present application; Figure 3 A system structure including a virtual GPIO controller in an embodiment of the present application; Figure 4 A system structure including a virtual HWMON operation node file in an embodiment of the present application; Figure 5 A three-level architecture of a CPLD device in an embodiment of the present application; Figure 6 A four-level architecture of a CPLD device in an embodiment of the present application; Figure 7 A data structure of a top-level CPLD device in an embodiment of the present application; Figure 8 A data structure of a bottom-level CPLD sub-device in an embodiment of the present application; Figure 9 A data structure of a bottommost-level function description in an embodiment of the present application; Figure 10 A data structure of an intermediate-level CPLD sub-device in an embodiment of the present application; Figure 11 A process of initialization in an embodiment of the present application; Figure 12 A flow chart of determining a target register base address and a target bus address in an embodiment of the present application; A flow chart of determining a target register base address and a target bus address in an embodiment of the present application; Figure 13 A flow chart of controlling a target virtual GPIO pin in an embodiment of the present application; Figure 14 A flow chart of controlling a target virtual HWMON operation node file in an embodiment of the present application; Figure 15 A management device of a CPLD in an embodiment of the present application; Figure 16 A data storage device in an embodiment of the present application. DETAILED DESCRIPTION

[0021] In order to make the purpose, technical solutions and advantages of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely below in combination with the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of protection of the present application. The embodiments in the present application and the features in the embodiments can be combined with each other arbitrarily without conflict. Moreover, although a logical order is shown in the flowchart, in some cases, the steps shown or described can be performed in an order different from that here.

[0022] The terms "first" and "second" in the description and claims of the present application and the above drawings are used to distinguish different objects, and are not used to describe a specific order. In addition, the term "comprising" and any variations thereof are intended to cover non-exclusive protection. For example, a process, method, system, product or device including a series of steps or units is not limited to the listed steps or units, but can optionally include steps or units not listed, or can optionally include other steps or units inherent to the process, method, product or device. "Multiple" in the present application can mean at least two, for example, two, three or more, and the embodiments of the present application are not limited.

[0023] In the following, some terms in the embodiments of the present application are explained and described in order to facilitate understanding by those skilled in the art.

[0024] (1) In the embodiments of the present application, the term "CPLD" refers to a programmable logic device which includes a series of logic units that can perform various logic functions through programming, and is usually used to implement complex digital logic circuits, and its characteristics are that it can be programmed on the circuit board and can be reconfigured multiple times; (2) In the embodiments of the present application, the term "GPIO" refers to a general input / output port on a microcontroller or processor, which can be configured as an input (read state) or an output (set state); (3) In the embodiments of the present application, the term "HWMON" refers to a subsystem in the Linux kernel, which provides support for hardware monitoring, such as temperature, voltage, fan speed, etc; (4) In the embodiments of the present application, the term "DTS (Device Tree Source)" refers to a data structure that describes hardware devices in an embedded system in a tree-like form, as well as their attributes and mutual relationships. The DTS file is usually used to pass to the Linux kernel by the bootloader during system startup, so that the kernel can correctly configure and use these hardware devices; (5) The term "in the embodiments of the present invention" "" refers to a two-wire half-duplex serial bus developed by PHILIPS in the 1980s for connecting microcontrollers and their peripheral devices. To facilitate understanding, the technical background of the embodiments of this application will be described in detail below.

[0025] In modern server monitoring systems, the BMC (Baseboard Management Controller) is a core component responsible for monitoring and managing the server's hardware status (such as temperature, voltage, fan speed, etc.). Figure 1 As shown, BMC typically runs the Linux operating system and can be accessed via... It uses various bus protocols such as Inter-Integrated Circuit (IIC) bus and SPI (Serial Peripheral Interface) to communicate with various hardware devices, including CPLD (Complex Programmable Logic Device). CPLD plays an important role in the system, such as detecting the presence of modules, monitoring the startup phase, managing hardware status, and transmitting control signals.

[0026] CPLDs play a crucial role in the server field. They are high-performance, programmable logic chips that process and optimize data streams in real time during server operation. Highly programmable, they can adjust data processing logic in real time according to the server's operational needs, enabling the server to better adapt to various application scenarios and improve data processing efficiency. Within servers, CPLDs can handle protocol conversion and adaptation, ensuring smooth communication between different hardware devices and improving server compatibility and scalability. Furthermore, CPLDs can monitor the server hardware status in real time, promptly detecting and handling faults. When server problems occur, CPLDs can quickly take measures to ensure stable system operation.

[0027] In traditional system management solutions, BMC uses a general approach. Device drivers directly access CPLD registers for communication, which has the advantage of simple structure. However, as system complexity increases, problems such as prominent performance bottlenecks, insufficient robustness, and poor compatibility have gradually emerged. For example: There is a special application process in the current BMC, which provides a unified CPLD access interface for higher layer logic code, directly accesses the CPLD register through frequent read-write system calls, resulting in a large software system overhead. This indiscriminate data access method reduces system performance, especially in high real-time scenarios, the efficiency of monitoring data acquisition is affected. The data provided by the CPLD is directly read in the register mode, and the software logic is strongly coupled with the hardware design. When the hardware design changes (such as changing a state signal from a CPLD register to a GPIO pin), the software needs to redesign the data acquisition logic, resulting in poor robustness and compatibility, and further affecting the development efficiency. The data acquisition of the physical hardware in the existing scheme is tightly coupled with the software business logic, which results in insufficient flexibility and scalability of the server system, making it difficult to adapt to the needs of multiple projects and multiple hardware platforms. Especially in the scenario of multiple projects and multiple hardware platforms, any change in hardware design, such as signal pin definition or register mapping adjustment, will directly lead to the modification of BMC software logic. This close coupling between hardware dependency and software logic significantly increases the complexity and cost of system development and maintenance.

[0028] In view of the technical problem of the close coupling between hardware dependency and software logic in the above-mentioned traditional system management scheme, which significantly increases the complexity and cost of system development and maintenance, the embodiments of the present application propose a management method for complex programmable logic devices CPLD, as shown in Figure 2 The method comprises the following steps: Step S201, generating a business operation instruction for a target virtual interface at the application layer, and sending it to the kernel, the target virtual interface being a virtual interface of a virtual controller pre-registered in the kernel; The virtual controller is at least one virtual interface created when the CPLD device is initialized and determined based on the configuration information of each CPLD device. The virtual controller is configured to abstract the CPLD device, wherein according to different subsystems, corresponding virtual GPIO pins and HWMON operation node files can be created as the virtual interface; Step S202, based on the business operation instruction, the kernel finds the target operation function registered by the virtual controller in the device driver layer, and calls the target operation function of the device driver layer to execute: based on the mapping relationship between the virtual interface and the register base address in the CPLD device, the business operation instruction for the target virtual interface is converted into a register access command for the target register base address in the target CPLD device, and the register access command is sent to the target CPLD device via a bus protocol.

[0029] Through the above method, the hardware details are shielded at the application layer, the CPLD device is abstracted into a virtual controller, and is registered into a Linux standard subsystem framework in a device driver layer, so that decoupling between software and hardware is realized, and the complexity of system development and maintenance is reduced.

[0030] In the embodiment of the present application, before generating the service operation instruction for the target virtual interface at the application layer, the CPLD device in the current hardware layer needs to be initialized, specifically including the following steps: When the device driver layer initializes the CPLD device nodes based on the pre-defined CPLD device hierarchical architecture, the configuration information of each CPLD device node is read, and the pin offset corresponding to each CPLD sub-device under each top-level CPLD device node is determined based on the configuration information; A virtual controller is created for each top-level CPLD device node through the device driver layer, and the virtual controller is configured and initialized according to the range of the pin offset, so that the virtual controller can manage the virtual interface, and the pre-defined operation function is configured into the virtual controller.

[0031] Specifically, taking the bus protocol as an example During the power-on startup process of the BMC system, the Linux kernel detects all CPLD devices through bus device detection device enumeration according to the pre-registered CPLD device information in the DTS device tree, and circulates each device node according to the DTS device tree to configure the data structure of each CPLD device node and create the corresponding virtual controller, thereby completing the initialization of each CPLD device. During the power-on startup process of the BMC system, the Linux kernel detects all CPLD devices through bus device detection device enumeration according to the pre-registered CPLD device information in the DTS device tree, and circulates each device node according to the DTS device tree to configure the data structure of each CPLD device node and create the corresponding virtual controller, thereby completing the initialization of each CPLD device.

[0032] In some possible embodiments, the configuration information includes device identification, bus address, register base address, function module configuration information, hardware characteristics and the like, based on the configuration information, the virtual interface corresponding to each CPLD sub-device under each top-level CPLD device node is determined, including: According to the function module configuration information, the basic interface corresponding to the CPLD sub-device is determined; According to the hardware characteristics, the virtual interface corresponding to the physical pin for implementing a non-standard function is allocated.

[0033] Further, after the basic interface and the virtual interface are determined, the corresponding virtual controller is configured and initialized based on the virtual interface, and the pre-defined operation function is configured into the virtual controller, wherein configuring the virtual controller according to the virtual interface and configuring the operation function belong to the conventional technology in the field, and are not described in detail here.

[0034] Finally, the virtual controller is enabled to manage the various base interfaces and virtual interfaces. In order to enable the abstracted virtual controller to perform access of virtual resources in accordance with original logic, the virtual controller can be a standard GPIO controller or a HWMON operation node file set, which is not specifically limited in the embodiments of the present application, and can be selectively created according to the functions of an actual CPLD device. Correspondingly, the service operation instruction includes a GPIO control instruction or a HWMON monitoring instruction.

[0035] After the virtual GPIO controller is registered to the GPIO subsystem framework or the virtual HWMON operation node file set is registered to the HWMON subsystem framework, the related functions of the CPLD can be accessed and controlled through existing standard interfaces. The registration process follows the standard implementation of each subsystem, and thus is not described herein.

[0036] Referring to FIGS. 1, 2, 3, and 4, Figure 3 and Figure 4 As shown, the registered virtual GPIO controller or virtual HWMON operation node file and other hardware devices under the corresponding subsystem framework are all managed by various software logics of the application layer through standard interfaces provided by the subsystem framework.

[0037] In the embodiments of the present application, the CPLD device is abstracted during initialization to convert the CPLD device at the hardware level into a virtual controller at the abstracted level, which realizes the use of a standard access process for a GPIO pin or a HWMON operation node to control the target virtual interface in the application layer, and realizes access to the hardware through conversion of the operation function, thereby decoupling the software and hardware and shielding the implementation details of the instruction conversion from the user of the application layer.

[0038] In some possible embodiments, the initialization of the CPLD device nodes also includes initialization and configuration of the data structure of each CPLD device node. Through a predefined CPLD device hierarchical architecture, an address mapping relationship from the virtual interface to the physical register is established to provide an address resolution basis for converting the service operation instruction into a register access command. When the Linux kernel calls the target operation function, the conversion of the instruction can be completed based on the above-mentioned CPLD device hierarchical architecture including the data structure of each CPLD device node, the hardware details are shielded from the application layer, and thus the software and hardware are decoupled.

[0039] Specifically, the data structure of the current CPLD device node is initialized and configured based on the attributes of the CPLD device node and the predefined CPLD device hierarchical architecture, and is stored in private data in the device driver layer according to the predefined CPLD device hierarchical architecture.

[0040] There can be more than one CPLD device in the server, and the functions are also different, such as motherboard CPLD, DC-SCM (Data Center - Server Compute Module) CPLD, hard disk backplane CPLD, fan plate CPLD, etc. For the CPLD devices used in different scenarios, the above-mentioned pre-defined CPLD device hierarchical architecture includes at least three layers, as shown in Figure 5 Each layer corresponds to a data structure of the layer, modular encapsulation of hardware functions, definition of the device tree in the Linux system, and encapsulation of the corresponding data structure in the driver code.

[0041] In some possible embodiments, as shown in Figure 6 The CPLD device hierarchical architecture further includes a middle layer CPLD sub-device.

[0042] Among the data structure initialization and configuration process of the CPLD device node in the above initialization process, when any CPLD device node is traversed, the following cases are included: When it is determined that the CPLD device node is a top layer CPLD device, as shown in Figure 7 The data structure initialization and configuration of the CPLD device node includes bus address, virtual controller identifier, and CPLD device identifier of the lower layer of the top layer CPLD device, etc. The data structure of the top layer CPLD device serves as the topmost layer in the abstract CPLD device hierarchical architecture, and each physical CPLD chip corresponds to a data structure of the top layer CPLD device. The core function thereof is to: realize binding with the hardware instance of the physical chip, establish a mapping relationship through the bus address; perform device-level resource unified management, including device number allocation and sub-device linked list maintenance; control the full life cycle of the device, and handle initialization and logout events of the device.

[0043] When it is determined that the CPLD device node is a bottom layer CPLD sub-device, as shown in Figure 8 The data structure initialization and configuration of the CPLD device node includes the function description identifier corresponding to the CPLD sub-device, the CPLD device pointer of the upper layer of the CPLD sub-device, and the creation and configuration of the corresponding function description based on the function of the CPLD sub-device; The data structure of the bottom CPLD sub-device is a core abstract layer of function implementation in the abstract CPLD device hierarchical architecture, each CPLD sub-device corresponds to a function module, and a group of specific virtual interfaces are configured, the core function of which is to indicate the required operation function set of the CPLD sub-device through a function description identifier, and to realize encapsulation and conversion of data types, and to establish a mapping relationship between the read original register data and the standard data format recognizable by the upper-layer subsystem.

[0044] The function description is the bottom layer of the CPLD device hierarchical architecture, as shown in the following table. Figure 9 The function description is the bottom layer of the CPLD device hierarchical architecture, as shown in the following table.

[0045] The function description is the bottom layer of the CPLD device hierarchical architecture, as shown in the following table.

[0046] In some possible embodiments, the following cases are further included: When it is determined that the CPLD device node is an intermediate layer CPLD sub-device, the data structure of the CPLD device node is initialized and configured, as shown in the following table. Figure 10 The data structure of the CPLD device node includes a CPLD device pointer of an upper layer of the CPLD sub-device, a CPLD sub-device linked list, and a CPLD device identifier of a lower layer of the CPLD sub-device. The layer is an intermediate layer in the abstract CPLD device hierarchical architecture, and is used for a logical function aggregation and routing layer. For a multi-function composite CPLD chip, the complex functions of a single CPLD are split into logically independent sub-units, function decoupling is realized, and a CPLD top device and a CPLD sub-device are connected to build a bidirectional lookup relationship, improve access efficiency, and allow dynamic loading or unloading of function modules during system operation, thereby enhancing system flexibility.

[0047] In some possible embodiments, if there is no CPLD sub-device, the CPLD device of a lower layer of the top CPLD device is a CPLD sub-device; if there is a CPLD sub-device, the CPLD device of a lower layer of the top CPLD device is a CPLD sub-device, and the CPLD device of a lower layer of the CPLD sub-device is a CPLD sub-device.

[0048] The layered abstract CPLD device hierarchy architecture design described above reduces the impact of hardware changes on upper-layer software, reduces repetitive development work, and enables the system to quickly adapt to the needs of multiple projects and multiple hardware platforms, thereby improving the system's flexibility and scalability.

[0049] The following describes a complete process for initializing a CPLD device. Taking bus protocols as an example, such as Figure 11 As shown, the CPLD device initialization process follows the standard Linux driver model. Based on a predefined abstract CPLD device hierarchical architecture, it implements hardware resource configuration and management, and the system loads and registers... Once the device is successfully matched, the driver executes the driver detection function, initiates the device initialization process, and uses a unified set of system calls to coordinate the initialization, configuration, and file read / write operations of each module. It also registers the corresponding abstract interfaces for each of its functional sub-devices (such as GPIO, HWMON, etc.) in the Linux kernel. During the initialization phase, all secondary and sub-device nodes are traversed, core data structures representing the logical structure of the device are created and configured, and a complete device abstract model is constructed. Then, the driver traverses all secondary and sub-device nodes, executes the initialization process for GPIO and hardware monitoring functions according to the abstract architecture, initializes and configures the virtual controller based on the configuration information, and registers it in the Linux kernel to establish virtual hardware pins that the application layer can recognize.

[0050] The driver integrates the abstracted hardware functions into the kernel standard subsystem framework by creating a complete virtual GPIO controller and virtual HWMON operation node file, thus completing the full mapping from hardware operation to system interface.

[0051] In some possible embodiments, the target operation function is called through the Linux kernel, and based on the data structure stored in the device driver layer in advance, the business operation instruction for the target virtual interface is converted into a register access command for the base address of the target register in the target CPLD device, and the register access command is sent to the target CPLD device via the bus.

[0052] Specifically, based on the data structure pre-stored in the device driver layer, the base address of the target register in the target CPLD device corresponding to the target virtual interface is determined, and the target CPLD device corresponding to the target CPLD device is determined. Bus address, in obtaining the target register base address and target After the bus address, the register access command for the target register base address of the target CPLD device can be converted and sent to the target CPLD device by the bus. Before reaching the target calling function, if the target virtual interface is a GPIO pin, the Linux kernel converts the target virtual interface identifier into a GPIO pin offset for the calling function to find.

[0053] Through the above process, the service operation instruction for the target virtual interface can be converted into a register access command for the target register base address of the target CPLD device, and sent to the target CPLD device, so as to complete the real operation on the hardware and realize the shielding of the hardware implementation details to the application layer.

[0054] In some possible embodiments, the target register base address corresponding to the target virtual interface in the target CPLD device is determined based on a data structure stored in advance in the device driver layer, and the target CPLD device corresponding to the target virtual interface is determined based on the target register base address. The bus address, for example, includes the following steps: Figure 12 As shown in the figure, the bus address includes the following steps: Step S1201: Obtain the pre-defined CPLD device hierarchical architecture stored in the private data of the device driver layer, find the target function description corresponding to the target virtual interface based on the target virtual interface and the function description of the bottom layer in the CPLD device hierarchical architecture in the private data; Step S1202: Find the data structure of the target CPLD sub-device based on the CPLD sub-device pointer of the upper layer in the target function description; Step S1203: Find the target register base address corresponding to the target virtual interface based on the data structure of the target CPLD sub-device, find the data structure of the target upper CPLD device according to the CPLD device pointer of the upper layer in the data structure, and obtain the target The bus address, wherein: When it is determined that the target upper CPLD device is a top CPLD device, the target bus address is obtained from the corresponding data structure. When it is determined that the target upper CPLD device is an intermediate CPLD sub-device, the data structure of the target upper CPLD device is found according to the CPLD device pointer of the upper layer in the data structure, until it is determined that the target upper CPLD device is a top CPLD device, and the target bus address is obtained from the corresponding data structure.

[0055] Since the data between the layers are related through pointers and identifiers when the data structure is designed, when the data of the corresponding layer is found, the data of other layers related to it can be found based on the pointers and identifiers. Therefore, the target register base address corresponding to the target virtual interface and the target bus address corresponding to the target CPLD device can be accurately found through the operation function. bus address.

[0056] By the above-mentioned CPLD management method, the CPLD is designed as a virtual controller, and the specific details of the CPLD device are shielded upwards through the virtual controller, thereby reducing the system call, reducing the software system overhead, and improving the real-time performance of the monitoring data acquisition. Moreover, the virtual controller is registered to a standard subsystem framework, and a unified interface is provided by the subsystem framework, so that the upper-layer software design is independent of the hardware, and the robustness and compatibility of the system are enhanced.

[0057] Next, a process of how to control the target virtual GPIO pin after the CPLD device is abstracted as a virtual GPIO controller is given, as shown in FIG. 6. Figure 13 For the virtual GPIO controller, the implementation details are shielded for the user, and the user layer sees the same hardware pin as the actual GPIO controller. The access to the virtual GPIO controller resource is completed by means of the general user layer operation library (libgpiod). First, the user layer operation library uses the standard interface provided by the GPIO subsystem to reach the operation function registered when the virtual GPIO controller is initialized, and carries the pin offset corresponding to the target virtual GPIO pin. According to the pre-defined CPLD device layer architecture, the data between the layers are related through pointers and identifiers. The target register base address corresponding to the target CPLD device and the target bus address corresponding to the target CPLD device are obtained, the register access command for the target register base address in the target CPLD device is converted, and the real operation on the hardware is completed. bus address.

[0058] Next, a process of how to control the target virtual GPIO pin after the CPLD device is abstracted as a virtual GPIO controller is given, as shown in FIG. 6. Figure 14As shown, the implementation details of the virtual HWMON operation node file are still hidden from the user. The user layer sees the same HWMON operation node file as other hardware monitoring systems, and uses read and write access to obtain and modify data. Through the user-level operation library, the standard interface provided by the HWMON subsystem is used to reach the operation functions registered during the initialization of the target virtual HWMON operation node file. According to the predefined CPLD device hierarchy architecture, the data between each level is interconnected through pointers and identifiers. The user then obtains the target register base address corresponding to the target CPLD device that needs to be operated and the target register base address corresponding to the target CPLD device. The bus address is translated into a register access command targeting the base address of the target register in the target CPLD device, thus completing the actual operation on the hardware.

[0059] Based on the same inventive concept, embodiments of this application propose a management device for a complex programmable logic device (CPLD), such as... Figure 15 As shown, it includes: The instruction generation module 1501 is used to generate business operation instructions for the target virtual interface at the application layer and send them to the kernel. The target virtual interface is a virtual interface of a virtual controller that is pre-registered in the kernel. The execution module 1502 is used to locate the target operation function registered by the virtual controller in the device driver layer based on the business operation instruction through the kernel, and call the target operation function of the device driver layer to execute: based on the mapping relationship between the virtual interface and the register base address in the CPLD device, the business operation instruction for the target virtual interface is converted into a register access command for the target register base address in the target CPLD device, and the register access command is sent to the target CPLD device via the bus protocol.

[0060] Based on the same inventive concept, embodiments of this application propose an electronic device, including at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform a CPLD management method as described in any of the first aspects of the above embodiments.

[0061] The following reference Figure 16 To describe an electronic device 160 according to this embodiment of the present application. Figure 16 The device 160 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0062] like Figure 16As shown, an electronic device 160 is in the form of a general-purpose electronic device. Components of an electronic device 160 can include, but are not limited to, at least one processor 161, at least one memory 162, and a bus 163 that connects different system components, including the memory 1602 and the processor 1601.

[0063] The bus 163 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures.

[0064] The memory 162 can include a read-only memory (ROM) 1623 in the form of flash memory, and / or a random access memory (RAM) 1621 and / or a cache memory 1622 in the form of a volatile memory.

[0065] The memory 162 can further include a program / utility 1625 having a set of program modules 1624, including but not limited to an operating system, one or more application programs, other program modules, and program data, each of which can include an implementation of a networking environment, or a subset thereof.

[0066] An electronic device 160 can also communicate with one or more external devices 164, such as a keyboard or a pointing device, through an input / output (I / O) interface 165. And an electronic device 160 can communicate with one or more devices that enable user interaction with an electronic device 160, and / or one or more devices that enable an electronic device 160 to communicate with one or more other electronic devices. Such communication can be through the I / O interface 165. Further, an electronic device 160 can communicate with one or more networks (such as a local area network (LAN), a wide area network (WAN), and / or the public network, such as the Internet) through a network adapter 166. As depicted, the network adapter 166 communicates with the other modules of an electronic device 160 through the bus 163. It should be appreciated that although not shown, other hardware and / or software modules could be used in conjunction with an electronic device 160. Such as, but not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.

[0067] Based on the same inventive concept, the embodiment of the present application provides a computer readable storage medium, which stores a computer program, the computer program comprises program instructions, and the program instructions, when executed by a computer, cause the computer to execute any of the CPLD management methods discussed above. Since the computer readable storage medium solves problems in the same principle as the CPLD management method, the implementation of the computer readable storage medium can be referred to the implementation of the method, and the repeated parts will not be described here.

[0068] The CPLD management method, device, equipment and readable storage medium in the embodiment of the present application design the CPLD as a virtual controller, and shield the specific details of the CPLD device through the virtual controller, so that the upper layer software design is independent of the hardware, thereby improving the performance, robustness and compatibility of the system.

[0069] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system or a computer program product. Therefore, the present application can be in the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware aspects. Moreover, the present application can be in the form of a computer program product implemented on one or more computer usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer usable program code.

[0070] The present application is described with reference to flowcharts and / or block diagrams according to the method, device (system) and computer program product of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of the flows and / or blocks in the flowcharts and / or block diagrams can be implemented by computer program instructions. These computer program instructions can be provided to a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to produce a machine, so that the instructions executed by the computer or other programmable data processing device produce a device that implements the functions specified in the flowcharts and / or block diagrams. Figure 1 The functions specified in one or more flows and / or blocks Figure 1 The device that implements the functions specified in one or more flows and / or blocks.

[0071] These computer program instructions can also be stored in a computer readable storage medium that can guide the computer or other programmable data processing device to work in a specific way, so that the instructions stored in the computer readable storage medium produce a product including instruction devices, which implement the functions specified in the flowcharts and / or block diagrams. Figure 1 The functions specified in one or more flows and / or blocks Figure 1 The device that implements the functions specified in one or more flows and / or blocks.

[0072] These computer program instructions can also be loaded into a computer or other programmable data processing devices, so that a series of user operation steps are performed on the computer or other programmable data processing devices to generate computer-implemented processes, thus the instructions executed on the computer or other programmable data processing devices provide the function of realizing the processes specified in the flowcharts Figure 1 one flow or multiple flows and / or the functions specified in the flowcharts Figure 1 one flow or multiple flows and / or the functions specified in the flowcharts

[0073] Obviously, those skilled in the art can make various modifications and variations to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalent technologies, the present application also intends to include these modifications and variations.

Claims

1. A method for managing a complex programmable logic device (CPLD), characterized in that, The method includes: The application layer generates business operation instructions for the target virtual interface and sends them to the kernel. The target virtual interface is a virtual interface of a virtual controller that has been pre-registered in the kernel. Based on the business operation instructions, the kernel locates the target operation function registered by the virtual controller in the device driver layer, and then calls and executes the target operation function in the device driver layer. Based on the mapping relationship between the virtual interface and the register base address in the CPLD device, the service operation instruction for the target virtual interface is converted into a register access command for the target register base address in the target CPLD device, and the register access command is sent to the target CPLD device via the bus protocol.

2. The method according to claim 1, characterized in that, The process of converting the service operation instruction for the target virtual interface into a register access command for the target register base address in the target CPLD device based on the mapping relationship between the virtual interface and the register base address in the CPLD device, and sending the register access command to the target CPLD device via the bus protocol, includes: Based on the data structure pre-stored in the device driver layer, the base address of the target register in the target CPLD device corresponding to the target virtual interface is determined, and the service operation instruction for the target virtual interface is converted into a register access command for the base address of the target register in the target CPLD device. Based on the data structure pre-stored in the device driver layer, the target corresponding to the target CPLD device is determined. Bus address, and based on the target The bus address transmits the register access command via The bus transmits the data to the target CPLD device.

3. The method according to claim 1 or 2, characterized in that, Before generating business operation instructions for the target virtual interface at the application layer, the method further includes: When the device driver layer traverses the CPLD device nodes based on the predefined CPLD device hierarchy architecture for initialization, it reads the configuration information of each CPLD device node and determines the virtual interface corresponding to each CPLD sub-device under each top-level CPLD device node based on the configuration information. A virtual controller is created for each top-level CPLD device node through the device driver layer. The virtual controller is configured and initialized according to the virtual interface so that the virtual controller can manage the virtual interface and predefined operation functions are configured into the virtual controller.

4. The method according to claim 3, characterized in that, The initialization process, which involves traversing CPLD device nodes based on a predefined CPLD device hierarchy architecture via the device driver layer, also includes: For each CPLD device node encountered during traversal, the data structure of the CPLD device node is initialized and configured based on its attributes and the predefined CPLD device hierarchy architecture, and then stored in the private data of the device driver layer according to the predefined CPLD device hierarchy architecture.

5. The method according to claim 4, characterized in that, The initialization and configuration of the data structure of the CPLD device node based on its attributes and a predefined CPLD device hierarchy architecture includes: When the CPLD device node is determined to be a top-level CPLD device, the data structure of the CPLD device node is initialized and configured, including... Bus address, virtual controller identifier, and the identifier of the CPLD device below the top-level CPLD device; When the CPLD device node is determined to be a lower-level CPLD sub-device, the data structure of the CPLD device node is initialized and configured, including the function description identifier corresponding to the CPLD sub-device, the CPLD device pointer above the CPLD sub-device, and the corresponding function description is created and configured based on the function of the CPLD sub-device. The functional description, which is the lowest level of the CPLD device hierarchy, includes the CPLD sub-device pointer above the functional description, at least one virtual interface, the register base address corresponding to the CPLD sub-device, and the length of the corresponding read / write data.

6. The method according to claim 5, characterized in that, The initialization and configuration of the data structure of the CPLD device node based on the attributes of the CPLD device node and the predefined CPLD device hierarchy architecture also includes: When the CPLD device node is determined to be an intermediate-layer CPLD sub-device, the data structure of the CPLD device node is initialized and configured, including the CPLD device pointer above the CPLD sub-device, the CPLD sub-device linked list, and the CPLD device identifier below the CPLD sub-device. If there is no CPLD sub-device, then the CPLD device below the top-level CPLD device is a CPLD sub-device; if there is a CPLD sub-device, then the CPLD device below the top-level CPLD device is a CPLD sub-device, and the CPLD device below the CPLD sub-device is a CPLD sub-device.

7. The method according to claim 5 or 6, characterized in that, The step of determining the target register base address in the target CPLD device corresponding to the target virtual interface based on the data structure pre-stored in the device driver layer includes: Obtain the predefined CPLD device hierarchy architecture stored in the private data of the device driver layer, and find the target function description of the corresponding target virtual interface based on the target virtual interface and the lowest functional description of the CPLD device hierarchy architecture in the private data. Based on the CPLD sub-device pointer in the target function description, find the data structure of the corresponding target CPLD sub-device; Based on the data structure of the target CPLD sub-device, the base address of the target register corresponding to the target virtual interface is found.

8. The method according to claim 7, characterized in that, The target CPLD device is determined based on the data structure pre-stored in the device driver layer. Bus address, including: Based on the data structure of the target CPLD sub-device, and according to the upper-level CPLD device pointer in the data structure, the data structure of the target upper-level CPLD device is located, and the target data structure is obtained from the corresponding data structure. Bus address, where: When the target upper-layer CPLD device is determined to be the top-level CPLD device, the target data in the corresponding data structure is obtained. Bus address; When the target upper-layer CPLD device is determined to be a middle-layer CPLD secondary device, the data structure of the target upper-layer CPLD device is located based on the upper-layer CPLD device pointer in the data structure, until the target upper-layer CPLD device is determined to be the top-layer CPLD device, and the target in the corresponding data structure is obtained. Bus address.

9. The method according to claim 1, characterized in that, The operational instructions include general input / output (GPIO) control instructions or hardware monitoring (HWMON) monitoring instructions.

10. A management device for a complex programmable logic device (CPLD), characterized in that, include: The instruction generation module is used to generate business operation instructions for the target virtual interface at the application layer and send them to the kernel. The target virtual interface is a virtual interface of a virtual controller that is pre-registered in the kernel. The execution module is used to locate the target operation function registered by the virtual controller in the device driver layer based on the business operation instructions through the kernel, and to call the target operation function in the device driver layer for execution: based on the mapping relationship between the virtual interface and the register base address in the CPLD device, the business operation instructions for the target virtual interface are converted into register access commands for the target register base address in the target CPLD device, and the register access commands are transmitted via... The bus transmits the data to the target CPLD device.

11. An electronic device, characterized in that, include: At least one processor; And a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the steps in a management method for a complex programmable logic device (CPLD) as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions for performing steps in a management method for a complex programmable logic device (CPLD) as described in any one of claims 1 to 9.

Images