A method and apparatus for reconfiguring the hardware abstraction layer based on a programmable logic platform

Abstract

This disclosure provides a hardware abstraction layer reconfiguration method and apparatus based on a programmable logic platform. It obtains the device type identifier by acquiring and decoding the GPIO pin level combinations of the expansion module, activates the corresponding peripheral sub-module in the unified peripheral IP logic module, performs driver mapping table lookup and initialization configuration on the target peripheral logic unit, and finally configures parameters through the AXI-Lite control bus and transmits data through the AXI-Stream data bus and AXI-DMA module. This disclosure achieves a complete closed-loop process of "plug and play, identify and drive, drive and use," solving the technical problems of traditional programmable logic platforms requiring manual driver configuration for module expansion and lacking a unified hardware abstraction mechanism. It provides an efficient, low-cost, and beginner-friendly solution for teaching.

Description

Technical Field

[0001] This disclosure relates to the fields of digital electronics and embedded systems, and in particular to a method and apparatus for reconstructing a hardware abstraction layer based on a programmable logic platform. Background Technology

[0002] With the development of embedded systems and programmable logic devices, the ZYNQ series SoC chips, as a hybrid platform integrating Advanced RISC Machines (ARM) processors and Field-Programmable Gate Array (FPGA) logic, have been widely used in university teaching, scientific research experiments, and edge computing. Especially in teaching scenarios, ZYNQ offers abundant input / output (IO) resources and flexible architecture combinations, making it an ideal choice for building low-threshold, programmable, and scalable experimental platforms.

[0003] Traditional ZYNQ-based teaching and experimental platforms are feature-rich, but module expansion requires manual driver configuration. Furthermore, students need to manually initialize and configure the modules in the code after inserting them, which increases the learning curve. The driver logic is also tightly coupled with the module hardware, resulting in poor code reusability. Summary of the Invention

[0004] This disclosure provides a method and apparatus for reconfiguring the hardware abstraction layer based on a programmable logic platform to solve the aforementioned problems in the prior art.

[0005] To achieve the above objectives, this disclosure provides a hardware abstraction layer reconfiguration method based on a programmable logic platform, including:

[0006] Obtain the general purpose input / output (GPIO) pin level combination of the expansion module, decode the GPIO pin level combination to obtain the device type identifier of the expansion module;

[0007] Based on the device type identifier, the corresponding peripheral sub-module is activated in the unified peripheral IP logic module to obtain the target peripheral logic unit in the enabled state.

[0008] The target peripheral logic unit is configured by looking up the driver mapping table and initializing it. The corresponding driver initialization function is called through the bare-metal dynamic driver framework to obtain an operable hardware abstraction layer interface.

[0009] Based on the aforementioned hardware abstraction layer interface, parameters are configured through the Advanced eXtensible Interface – Lite (AXI-Lite) control bus, and data is transmitted through the Advanced eXtensible Interface – Stream (AXI-Stream) data bus and the Advanced eXtensible Interface – Direct Memory Access (AXI-DMA) module to obtain the data interaction results between the processing system and the programmable logic.

[0010] In integrated circuit design, IP (Intellectual Property) refers to reusable, pre-designed functional modules (such as interface controllers and protocol processing units) that developers can directly call to reduce redundant design.

[0011] Optionally, the GPIO pin level combination is decoded to obtain the device type identifier of the expansion module, including: constructing an encoding mapping table of 8 device types based on the level state of the 3-bit GPIO pin, generating a correspondence between device type and identification code (ID); reading the GPIO pin level combination from the register, converting the read binary level combination into a decimal ID code, and obtaining the device type identifier of the expansion module.

[0012] Optionally, activating the corresponding peripheral sub-module in the unified peripheral IP logic module to obtain the target peripheral logic unit in the enabled state includes: generating a periph_id selection signal based on the device type identifier to obtain the enable control signal of the peripheral sub-module; performing logical allocation on the enable control signal to set the corresponding peripheral sub-module to the active state while keeping the other sub-modules in the idle state, thereby obtaining the target peripheral logic unit in the enabled state.

[0013] Optionally, the peripheral submodule includes an analog-to-digital converter (ADC) submodule, whose activation process includes: based on the ADC conversion start signal, controlling the ADC sampling timing through a finite state machine to generate an ADC conversion control state; switching the ADC conversion control state sequentially, executing an idle state, a conversion start state, a data preparation wait state, and a conversion result read state to obtain ADC acquisition data; based on the ADC acquisition data, performing clock domain conversion processing through asynchronous first-in-first-out (FIFO) to generate a cross-clock domain data buffer; encapsulating the cross-clock domain data buffer using the Advanced eXtensible Interface – Stream (AXI-Stream) protocol, formatting the FIFO output data according to the Advanced eXtensible Interface 4 – Stream (AXI4-Stream) protocol to obtain a standardized data stream output; and using the Advanced eXtensible Interface – Lightweight version (AXI-Stream) protocol... The configuration parameters of the Interface-Lite (AXI-Lite) interface are used to dynamically configure the ADC sampling rate and resolution to obtain the target peripheral logic unit in the enabled state.

[0014] Optionally, the peripheral submodule includes a High-Definition Multimedia Interface (HDMI) input submodule, whose activation process includes: based on the Transition Minimized Differential Signaling Input (TMDS) signal input, performing signal decoding processing through an Application-Specific Integrated Circuit (IC) to generate a decoded pixel data stream; performing pixel clock recovery on the pixel data stream, recovering the pixel clock from the TMDS clock using a phase-locked loop to obtain a synchronized pixel acquisition timing sequence; based on the pixel acquisition timing sequence, detecting line synchronization and frame synchronization signals through an internal state machine to generate a video frame boundary recognition signal; performing frame data acquisition control on the video frame boundary recognition signal, writing pixel-by-pixel data into a FIFO buffer in line synchronization after detecting the start of a new frame to obtain a frame data buffer; based on the frame data buffer, outputting the pixel stream according to a preset color depth and frame rate through an AXI-Stream interface to obtain the target peripheral logic unit in the enabled state.

[0015] Optionally, the peripheral submodule includes a camera submodule, whose activation process includes: configuring the camera sensor register based on the Inter-Integrated Circuit Bus Communication Protocol (I2C) to generate sensor operating parameter settings; initializing the sensor operating parameter settings by setting image resolution and frame rate parameters to obtain the sensor initialization state; controlling the image frame acquisition timing through a finite state machine based on vertical synchronization (VSYNC) and horizontal synchronization (HSYNC) signals to generate pixel data acquisition control signals; controlling the data writing of the pixel data acquisition control signals by writing each line of pixel data into a FIFO buffer during the valid period of the VSYNC signal to obtain an image frame data buffer; and outputting image data to the AXI-DMA module through the AXI-Stream interface based on the image frame data buffer to obtain the target peripheral logic unit in the enabled state.

[0016] Optionally, an operable hardware abstraction layer interface is obtained by calling the corresponding driver initialization function through the bare-metal dynamic driver framework, including: searching for a function pointer in the driver mapping table based on the device type identifier to obtain the address of the corresponding driver initialization function; calling the driver initialization function address to perform hardware initialization and parameter configuration of the corresponding peripheral to obtain the operable hardware abstraction layer interface.

[0017] Optionally, data transmission is performed through the AXI-DMA module to obtain the data interaction results between the processing system and the programmable logic, including: configuring high-speed data transfer based on the AXI-Stream data stream using the AXI-DMA controller to generate DMA transfer control parameters; writing the DMA transfer control parameters into registers, writing transfer information to the DMA Control Register (DMACR), source address register, and transfer length register to obtain DMA transfer start conditions; and based on the DMA transfer start conditions, transferring data from the programmable logic side to the double data rate (DDR) memory of the processing system (PS) through a high-performance AXI port to obtain the data interaction results between the processing system and the programmable logic.

[0018] Optionally, the Direct Memory Access (DMA) transfer process further includes cache management and interrupt handling: based on the memory data before the DMA transfer, the cache management interface is called to perform a data cache refresh operation to ensure physical memory data consistency; the DMA transfer completion status is detected, and a completion flag is set in the Status Register (DMASR) and an interrupt is generated to produce a transfer completion notification signal; based on the transfer completion notification signal, the DMA interrupt flag is cleared in the interrupt service routine and the cache area is invalidated to obtain the data interaction result between the processing system and the programmable logic.

[0019] This disclosure also provides a hardware abstraction layer reconfiguration device based on a programmable logic platform, including:

[0020] The device identification module is used to obtain the GPIO pin level combination of the expansion module, decode the GPIO pin level combination, and obtain the device type identifier of the expansion module.

[0021] The peripheral activation module is used to activate the corresponding peripheral sub-module in the unified peripheral IP logic module based on the device type identifier, so as to obtain the target peripheral logic unit in the enabled state.

[0022] The driver loading module is used to perform driver mapping table lookup and initialization configuration for the target peripheral logic unit, and to obtain an operable hardware abstraction layer interface by calling the corresponding driver initialization function through the bare-metal dynamic driver framework.

[0023] The data transmission module is used to configure parameters through the AXI-Lite control bus and transmit data through the AXI-Stream data bus and AXI-DMA module based on the hardware abstraction layer interface, so as to obtain the data interaction results between the processing system and the programmable logic.

[0024] Based on the above implementation plan, this disclosure can:

[0025] A module-level ID encoding mechanism is implemented, using multiple GPIO inputs to form independent ID codes, enabling module identification without communication protocol support. A unified packaged peripheral IP logic module is provided, integrating all supporting modules into a unified logic unit within the FPGA in a selectable activation manner, saving FPGA resources. The standard AXI communication protocol is adopted, with the control path using an AXI-Lite structure and the data path using an AXI-Stream structure. Data flow between the programmable logic block (PL) and the processing system (PS) is completed through an AXI-DMA module. A bare-metal dynamic driver framework is designed, eliminating the need for an embedded operating system; the driver loading logic is encapsulated in the startup code as a function mapping table. A packaged user interface is provided, allowing upper-layer users to call devices only through a unified function interface, without needing to understand the underlying registers and communication details, significantly reducing development difficulty. Attached Figure Description

[0026] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings used in the embodiments will be briefly described below. These drawings are incorporated in and constitute a part of this specification. They illustrate embodiments conforming to this disclosure and, together with the specification, serve to explain the technical solutions of this disclosure. It should be understood that the following drawings only show some embodiments of this disclosure and should not be considered as limiting the scope. Those skilled in the art can obtain other related drawings based on these drawings without creative effort.

[0027] Figure 1 This disclosure presents a flowchart of a hardware abstraction layer reconfiguration method based on a programmable logic platform;

[0028] Figure 2 This is a flowchart illustrating the device identification and driver loading mechanism in this disclosure;

[0029] Figure 3 This is a flowchart illustrating the process of activating the corresponding peripheral submodule in the unified peripheral IP logic module to obtain the target peripheral logic unit in an enabled state in this disclosure.

[0030] Figure 4 This is a schematic diagram of a hardware abstraction layer reconfiguration device based on a programmable logic platform provided in an embodiment of this disclosure. Detailed Implementation

[0031] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. The components of the embodiments of this disclosure described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this disclosure provided in the accompanying drawings is not intended to limit the scope of the claimed disclosure, but merely represents selected embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without inventive effort are within the scope of protection of this disclosure.

[0032] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0033] In this document, the term "and / or" merely describes a relationship, indicating that three relationships can exist. For example, A and / or B can represent three cases: A alone, A and B simultaneously, and B alone. Furthermore, the term "at least one" in this document means any combination of at least two of any one or more elements. For example, including at least one of A, B, and C can mean including any one or more elements selected from the set consisting of A, B, and C.

[0034] The present disclosure will be further described below with reference to the accompanying drawings and embodiments.

[0035] This disclosure proposes a teaching experiment platform architecture based on a hardware circuit identification mechanism, a unified reconfigurable driver system, and an AXI standard interface encapsulation. It realizes a complete closed-loop process of "plug and play, identify and drive, drive and use", providing an efficient, low-cost, and beginner-friendly solution for teaching.

[0036] like Figure 1 As shown, a hardware abstraction layer reconfiguration method based on a programmable logic platform includes the following steps:

[0037] S1: Obtain the GPIO pin level combination of the expansion module, decode the GPIO pin level combination to obtain the device type identifier of the expansion module;

[0038] In step S1, the system first reads the hardware identification signal of the expansion module through the GPIO interface. Specifically, after the expansion module is inserted into the ZYNQ7015 platform, the pre-configured ID pins on the module (fixed to high and low levels by pull-up and pull-down resistors) are connected to the GPIO[2:0] ports of the FPGA. The system obtains the level state of these pins by reading the value of the GPIO register, forming a 3-bit binary code. For example, when the read GPIO[2:0] value is "001", it indicates that the ADC acquisition module is connected; when the read value is "010", it indicates that the DAC output module is connected. This hardware-level ID encoding mechanism does not require communication protocol support and can achieve automatic module identification through a simple circuit, greatly reducing system complexity. The code implementation for reading GPIO values ​​is as follows:

[0039] uint8_t get_device_id(void){uint32_t gpio_val=XGpio_ReadReg(GPIO_BASE_ADDR,GPIO_DATA_OFFSET);return(uint8_t)(gpio_val&0x07); / / Only take the lower 3 bits as the device ID}

[0040] The system converts the read binary code into a decimal ID code, which serves as the device type identifier for the expansion module. This encoding method supports up to eight different types of peripheral modules (000-111), meeting the needs of most teaching scenarios. The entire recognition process is completed automatically upon system startup, requiring no user intervention and achieving a "plug and play" function.

[0041] S2: Based on the device type identifier, activate the corresponding peripheral sub-module in the unified peripheral IP logic module to obtain the target peripheral logic unit in the enabled state;

[0042] In step S2, the system activates the corresponding peripheral sub-module in the Unified Peripheral IP (UPIP) logic module inside the FPGA based on the device type identifier obtained in step S1. UPIP is one of the core components of this disclosure; it integrates various peripheral logics (such as ADC, DAC, HDMI, camera, etc.) into a unified IP core, controlling the enable state of each sub-module through selection signals. Specifically, the system converts the device type identifier into a periph_id selection signal and implements selective activation of the sub-module using the following Verilog code:

[0043]

[0044] This design activates only currently connected peripheral modules, keeping the rest idle, thus saving FPGA resources and reducing power consumption. For example, when an ADC module is detected, only the ADC submodule is activated, while other submodules (such as HDMI, cameras, etc.) are disabled. This resource reuse mechanism allows the system to support multiple peripheral types with limited FPGA resources, improving system flexibility and scalability. Once activated, the peripheral submodule enters an enabled state, ready to receive control commands and data transmission requests from the processing system.

[0045] S3: Perform driver mapping table lookup and initialization configuration on the target peripheral logic unit, and call the corresponding driver initialization function through the bare-metal dynamic driver framework to obtain an operable hardware abstraction layer interface;

[0046] In step S3, the system implements a bare-metal dynamic driver framework on the processor side (PS side) to automatically load and initialize the corresponding driver based on the device type identifier. This framework uses a function pointer mapping table to establish the correspondence between device IDs and driver initialization functions. The specific implementation is as follows:

[0047] / / Define the type of driver initialization function typedef void(driver_init_t)(void); / / Driver mapping table, index corresponding device ID driver_init_t driver_table[8]={NULL, / / ID=0, reserved init_adc, / / ID=1, ADC module driver initialization function init_dac, / / ID=2, DAC module driver initialization function init_hdmi, / / ID=3, HDMI module driver initialization function init_audio, / / ID=4, audio module driver initialization function init_cam_mono, / / ID=5, monocular camera module driver initialization function init_cam_dual, / / ID=6, binocular camera module driver initialization function NULL / / ID=7, reserved};

[0048] / / Driver autoloader function void auto_driver_loader(void) { / / Get device ID uint8_tid = get_device_id(); / / Check ID validity and call the corresponding initialization function if (id < 8 && driver_table[id] != NULL) { printf("Detected device ID: %d, initializing driver...\n", id); driver_tableid; / / Call the corresponding driver initialization function printf("Driver initialization completed.\n");} else { printf("Invalid device ID: %d or no driver available.\n", id);}

[0049] }

[0050] When the system starts, the `auto_driver_loader` function is called. It first obtains the device ID, then looks up the corresponding initialization function in the driver mapping table and executes that function to complete the driver initialization. Taking the ADC module as an example, the `init_adc` function performs the following operations: configuring the ADC's operating parameters (such as sampling rate, resolution, etc.), initializing the AXI-DMA channel, setting interrupt handlers, and registering the device operation interface. After initialization, the system obtains a set of standardized hardware abstraction layer interfaces. Upper-layer applications can access and control peripherals through these interfaces without needing to understand the underlying hardware details. This dynamic driver loading mechanism is one of the key innovations of this disclosure; it achieves "identification and driving simultaneously," greatly simplifying the system's usage process.

[0051] S4: Based on the hardware abstraction layer interface, parameters are configured through the AXI-Lite control bus and data is transmitted through the AXI-Stream data bus and the AXI-DMA module to obtain the data interaction results between the processing system and the programmable logic.

[0052] In step S4, the system employs a standard AXI bus architecture to implement communication and data transmission between the processing system (PS) and the programmable logic (PL). Specifically, the system uses the AXI-Lite bus for control information exchange and the AXI-Stream bus and AXI-DMA module for high-speed data transmission. AXI-Lite is a lightweight variant of the AXI protocol, suitable for low-bandwidth, address-mapped control interfaces. Through the AXI-Lite bus, the PS can access the control registers of the PL to configure the operating parameters of peripherals. For example, for an ADC module, the PS can configure parameters such as sampling rate, trigger mode, and data format through AXI-Lite; for an HDMI module, it can configure parameters such as resolution, color space, and synchronization mode. AXI-Stream is a data stream-oriented variant of the AXI protocol, suitable for high-bandwidth, continuous data transmission scenarios. Data acquired by peripherals (such as ADC sample values, video pixels, etc.) is output through the AXI-Stream interface, and then the AXI-DMA module moves this data to the DDR memory on the PS side. AXI-DMA is a dedicated data transfer module that supports efficient memory access and data transfer, enabling the movement of large amounts of data without CPU intervention. The following is a code example for configuring AXI-DMA:

[0053]

[0054]

[0055] During data transmission, the system also implements cache management and interrupt handling mechanisms to ensure the reliability and efficiency of data transmission. Before DMA transmission begins, the system calls the `Xil_DCacheFlushRange` function to flush the cache, ensuring that data in the CPU cache is written back to DDR memory. After DMA transmission is complete, the system uses an interrupt mechanism to detect the transmission status and calls the `Xil_DCacheInvalidateRange` function to invalidate the cache, ensuring that the CPU can read the latest DMA transmission data. In this way, the system achieves efficient data interaction between the PS and PL, providing a reliable data processing foundation for upper-layer applications. The entire data transmission process is transparent to the user; upper-layer applications only need to call standardized interface functions (such as `adc_read()`, `hdmi_get_frame()`, etc.) to obtain peripheral data without needing to understand the underlying bus protocol and data transmission details, greatly reducing development difficulty.

[0056] like Figure 2 As shown, in step S1, the GPIO pin level combination is decoded to obtain the device type identifier of the expansion module, specifically including:

[0057] S1.1: Based on the level states of 3-bit GPIO pins, construct an encoding mapping table for 8 device types and generate the correspondence between device types and ID codes;

[0058] S1.2: Read the GPIO pin level combination from the register, convert the read binary level combination into a decimal ID code, and obtain the device type identifier of the expansion module.

[0059] In step S1.1, the system designs a set of ID identification pins (such as GPIO[2:0]) and assigns a unique level combination to each module. Specifically, the system assigns a unique ID code to each peripheral module. For example, as shown in Table 1, the GPIO level combination corresponding to the ADC acquisition module is "001", corresponding to decimal ID code 1; the GPIO level combination corresponding to the DAC output module is "010", corresponding to decimal ID code 2; the GPIO level combination corresponding to the HDMI video input is "011", corresponding to decimal ID code 3; the GPIO level combination corresponding to the audio input / output module is "100", corresponding to decimal ID code 4; the GPIO level combination corresponding to the monocular camera module is "101", corresponding to decimal ID code 5; and the GPIO level combination corresponding to the binocular camera module is "110", corresponding to decimal ID code 6. This encoding method supports up to 8 different types of peripheral modules, meeting the needs of most teaching scenarios.

[0060] Table 1

[0061]

[0062] In step S1.2, after the FPGA is powered on, the PS-side software reads the GPIO register value to determine the type of the currently inserted module. Specifically, the system reads the GPIO register value, obtains the level state of GPIO[2:0], and then converts the binary level combination into a decimal ID code to obtain the device type identifier of the expansion module. This method requires no communication protocol support and can complete module identification through simple hardware circuitry (pull-up and pull-down resistors), greatly reducing system complexity and the learning curve.

[0063] like Figure 3 As shown, in step S2, the corresponding peripheral sub-module is activated in the unified peripheral IP logic module to obtain the target peripheral logic unit in the enabled state, specifically including:

[0064] S2.1: Based on the device type identifier, generate a periph_id selection signal to obtain the enable control signal for the peripheral submodule;

[0065] S2.2: Logically allocate the enable control signal, set the corresponding peripheral sub-module to the active state while keeping the other sub-modules in the idle state, and obtain the target peripheral logic unit in the enabled state.

[0066] In step S2.1, the system converts the device type identifier (decimal ID code) obtained in step S1 into a 3-bit binary periph_id selection signal. This signal is used to control the enable state of each submodule in the unified peripheral IP logic module. For example, when an ADC module (ID=1) is detected, the periph_id signal is "001"; when a DAC module (ID=2) is detected, the periph_id signal is "010". This method enables dynamic selection of peripheral submodules, allowing the system to automatically adjust its operating mode according to the type of module actually inserted.

[0067] In step S2.2, all module logic is uniformly encapsulated in `unified_peripheral_ip.v`, and the sub-module is enabled based on the `periph_id` signal. The specific implementation code is as follows: `assign enable_adc = (periph_id == 3'b001)`;

[0068] assign enable_dac=(periph_id==3'b010);

[0069] assign enable_hdmi=(periph_id==3'b011);

[0070] assign enable_audio=(periph_id==3'b100);

[0071] assign enable_camm=(periph_id==3'b101);

[0072] assign enable_camd=(periph_id==3'b110);

[0073] / / Only activate the logic for the current device; keep the rest idle.

[0074] In this way, the system only activates the logic of the currently active device, while the rest remain idle, thus saving FPGA resources. When the ADC module is detected, the system sets periph_id to "001", at which point the enable_adc signal is high and other enable signals are low, thereby activating the ADC submodule while other submodules remain idle. This design ensures efficient utilization of FPGA resources, simplifies the system architecture, and improves system maintainability and scalability.

[0075] Within the unified peripheral IP logic module, different peripheral submodules have different activation processes. The activation processes of several typical peripheral submodules are detailed below:

[0076] S2.3: When the peripheral submodule is an ADC submodule, its activation process includes:

[0077] S2.3.1: Based on the ADC conversion start signal, the ADC sampling timing is controlled by a finite state machine to generate the ADC conversion control state;

[0078] S2.3.2: Switch the ADC conversion control state in sequence, executing the idle state, the start conversion state, the data preparation waiting state, and the conversion result reading state to obtain the ADC acquisition data;

[0079] S2.3.3: Based on the data acquired by the ADC, clock domain conversion processing is performed through asynchronous FIFO to generate a cross-clock domain data buffer;

[0080] S2.3.4: Encapsulate the cross-clock domain data buffer using the AXI-Stream protocol, format the FIFO output data according to the AXI4-Stream protocol, and obtain a standardized data stream output;

[0081] S2.3.5: Based on the configuration parameters of the AXI-Lite interface, the ADC sampling rate and resolution are dynamically configured to obtain the target peripheral logic unit in the enabled state.

[0082] In step S2.3.1, the system receives an ADC conversion start signal from the PS terminal, which triggers the ADC sampling state machine to start working. The sampling state machine is a finite state machine structure used to control the sampling timing of the ADC, ensuring that the ADC completes data conversion under the correct timing.

[0083] In step S2.3.2, the ADC state machine sequentially goes through the states of "Idle," "Start Conversion," "Waiting for Data Preparation," and "Read Conversion Result." In the Idle state, the state machine waits for a conversion start signal; upon receiving the start signal, it enters the Start Conversion state and sends a start conversion command to the ADC; then it enters the Waiting for Data Preparation state, waiting for the ADC to complete the data conversion; finally, it enters the Read Conversion Result state, reading the ADC-acquired data through the parallel interface. This state machine design ensures the reliability and stability of the ADC sampling process.

[0084] In step S2.3.3, the read ADC data is first written to an asynchronous FIFO to bridge the ADC sampling clock domain and the AXI-Stream bus clock domain. The asynchronous FIFO is implemented using a dual-port RAM, with one end clocked by the ADC conversion clock and the other by the AXI-Stream clock, thus resolving data hazards caused by clock domain switching. This design ensures reliable data transmission between different clock domains and avoids data loss or errors due to clock asynchrony.

[0085] In step S2.3.4, the FIFO output is connected to the AXI-Stream interface, and the data stream is sent to the AXIDMA module for transmission according to the AXI4-Stream protocol. The AXI4-Stream protocol is a high-efficiency data stream transmission protocol suitable for continuous data stream transmission scenarios, such as ADC sampling data. By formatting the ADC data according to the AXI4-Stream protocol, the system can achieve standardized data transmission, improving the system's interoperability and scalability.

[0086] In step S2.3.5, the ADC sampling rate, resolution, and other parameters are configured via the AXI-Lite interface to support flexible sampling control. AXI-Lite is a lightweight AXI bus protocol suitable for low-bandwidth, address-mapped control interfaces. Through the AXI-Lite interface, the PS can dynamically configure the ADC's operating parameters, such as sampling rate and resolution, thereby achieving flexible control over the ADC's operating mode.

[0087] S2.4: When the peripheral submodule is an HDMI input submodule, its activation process includes:

[0088] S2.4.1: Based on the TMDS signal input, the signal is decoded by a dedicated IC to generate the decoded pixel data stream;

[0089] S2.4.2: Perform pixel clock recovery on the pixel data stream, and use a phase-locked loop to recover the pixel clock from the TMDS clock to obtain a synchronized pixel acquisition timing sequence;

[0090] S2.4.3: Based on the pixel acquisition timing, the line synchronization and frame synchronization signals are detected by the internal state machine to generate a video frame boundary recognition signal;

[0091] S2.4.4: Perform frame data acquisition control on the video frame boundary identification signal. After detecting the start of a new frame, write the pixel-by-pixel data into the FIFO buffer line by line to obtain the frame data buffer.

[0092] S2.4.5: Based on the frame data buffer, the pixel stream is output according to the preset color depth and frame rate through the AXI-Stream interface to obtain the target peripheral logic unit in the enabled state.

[0093] In step S2.4.1, the HDMI input submodule uses an HDMI receiver with a dedicated IC to decode the Transition Minimized Differential Signaling (TMDS) signal. TMDS is a signal transmission technology used in HDMI; decoding with a dedicated IC allows the extraction of pixel data streams from the TMDS signal. This simplifies the complexity of HDMI signal processing, allowing students to focus on subsequent data processing steps.

[0094] In step S2.4.2, the pixel clock is recovered from the TMDS clock via a phase-locked loop (PLL) for pixel data acquisition timing control. A PLL is a circuit capable of extracting clock information from an input signal. Through the PLL, the system can recover the pixel clock from the TMDS clock, ensuring that the pixel data acquisition remains synchronized with the input signal. This clock recovery mechanism is a key technology in video signal processing, ensuring the accuracy and stability of video data acquisition.

[0095] In step S2.4.3, the internal state machine detects line synchronization and frame synchronization signals to define the start and end of video frames. Horizontal Synchronization (HSYNC) and Vertical Synchronization (VSYNC) signals are important control signals in video signals, used to identify the start and end of a line or frame. By detecting these synchronization signals, the system can accurately identify the boundaries of video frames, providing a basis for subsequent frame data acquisition.

[0096] In step S2.4.4, after detecting the start of a new frame, the system enters the acquisition state and writes pixel-by-pixel data into the FIFO buffer synchronously line by line. One end of the FIFO is driven by the recovered pixel clock (for writing pixel data), and the other end is driven by the AXI-Stream clock (for reading data and outputting it to the AXIDMA). This dual-clock FIFO design solves the synchronization problem between the pixel clock domain and the AXI bus clock domain, ensuring reliable transmission of video data between different clock domains.

[0097] In step S2.4.5, the pixel stream output by AXI-Stream is sent to the AXIDMA module for processing according to the preset color depth and frame rate. Through the AXI-Lite register configuration, parameters such as the input video resolution, sampling clock multiplier, and pixel format can be set to adapt to different HDMI video modes. This flexible configuration mechanism enables the system to support multiple video formats, improving the system's versatility and adaptability.

[0098] S2.5: When the peripheral submodule is a camera submodule, its activation process includes:

[0099] S2.5.1: Based on the I2C bus communication protocol, configure the camera sensor registers and generate sensor operating parameter settings;

[0100] S2.5.2: Initialize the sensor operating parameter settings by setting the image resolution and frame rate parameters to obtain the sensor initialization state;

[0101] S2.5.3: Based on the VSYNC and HSYNC synchronization signals, the image frame acquisition timing is controlled by a finite state machine to generate pixel data acquisition control signals;

[0102] S2.5.4: Perform data writing control on the pixel data acquisition control signal, and write each row of pixel data into the FIFO buffer during the valid period of the VSYNC signal to obtain the image frame data buffer;

[0103] S2.5.5: Based on the image frame data buffer, the image data is output to the AXI-DMA module through the AXI-Stream interface to obtain the target peripheral logic unit in the enabled state.

[0104] In step S2.5.1, the camera submodule configures the camera sensor register via the I2C bus. I2C is a commonly used two-wire serial communication protocol suitable for short-distance, low-speed communication between devices. Through the I2C bus, the system can configure various parameters of the camera sensor, such as exposure time, gain, and white balance, thereby controlling the camera's operating state. This configuration method simplifies the complexity of camera control, enabling students to quickly learn how to use the camera module.

[0105] In step S2.5.2, the system initializes the sensor by setting operating parameters such as image resolution and frame rate. These parameters directly affect the output image quality and data volume of the camera. By setting these parameters appropriately, the system can achieve a balance between image quality and data processing burden, meeting the needs of different application scenarios.

[0106] In step S2.5.3, the acquisition logic is controlled by a finite state machine, which starts and stops image frame acquisition by monitoring frame synchronization (VSYNC) and line synchronization (HSYNC) signals. This synchronization mechanism ensures the accuracy and integrity of image data acquisition, avoiding data loss or misalignment. The state machine controls the acquisition timing of pixel data based on changes in the synchronization signals, generating pixel data acquisition control signals to guide subsequent data writing operations.

[0107] In step S2.5.4, during the valid period of the VSYNC signal, the camera pixel clock drives the pixel data input and writes each line of pixel data into the FIFO buffer. One end of the FIFO is clocked by the camera pixel clock, and the other end is clocked by the AXI-Stream clock to enable data transmission across clock domains. This dual-clock FIFO design solves the synchronization problem between the camera pixel clock domain and the AXI bus clock domain, ensuring reliable transmission of image data between different clock domains.

[0108] In step S2.5.5, after acquiring one frame of image, the FIFO sends the image data to the AXIDMA module via the AXI-Stream interface, which then transfers the data to the PS-side DDR memory for subsequent processing. This AXI-Stream-based data transmission method achieves efficient image data transfer, meeting the needs of real-time image processing. Through the AXI-Lite interface, the system can also dynamically adjust the camera's operating parameters, such as resolution and frame rate, improving the system's flexibility and adaptability.

[0109] In step S3, the corresponding driver initialization function is called through the bare-metal dynamic driver framework to obtain an operable hardware abstraction layer interface, specifically including:

[0110] S3.1: Based on the device type identifier, perform a function pointer lookup in the driver mapping table to obtain the address of the corresponding driver initialization function;

[0111] S3.2: Call the driver initialization function address to perform hardware initialization and parameter configuration of the corresponding peripheral device, and obtain the operable hardware abstraction layer interface.

[0112] In step S3.1, the system sets up the following structure in the bare-metal code for function mapping:

[0113]

[0114] This function pointer array structure establishes a mapping between device IDs and driver initialization functions, enabling the system to automatically locate the corresponding driver initialization function based on the device type identifier. This design simplifies driver management complexity and improves system maintainability and scalability. When a new device type needs to be added, only the corresponding initialization function needs to be added to the function pointer array; no other code modification is required.

[0115] In step S3.2, the dynamic identification and calling process in the main function is as follows:

[0116]

[0117] In this way, the system can automatically call the corresponding driver initialization function based on the device type identifier, eliminating the need for manual driver configuration and greatly simplifying the development process. For example, when an ADC module (ID=1) is detected, the system will automatically call the init_adc function to complete the ADC hardware initialization and parameter configuration. This dynamic driver loading mechanism is one of the core innovations of this disclosure, achieving the function of "plug and play, identify and drive," which greatly reduces the learning threshold for students.

[0118] In step S4, data is transferred through the AXI-DMA module to obtain the data interaction results between the processing system and the programmable logic, specifically including:

[0119] S4.1: Based on the AXI-Stream data stream, high-speed data transfer configuration is performed through the AXI-DMA controller to generate DMA transfer control parameters;

[0120] S4.2: Write the DMA transfer control parameters to the registers, write the transfer information to the DMACR, source address register and transfer length register to obtain the DMA transfer start conditions;

[0121] S4.3: Based on the DMA transfer start condition, the data on the programmable logic side is transferred to the PS-side DDR memory through the high-performance AXI port to obtain the data interaction result between the processing system and the programmable logic.

[0122] In step S4.1, the system adopts the standard AXI bus architecture for control and data transmission design. The AXI-Stream interface is used for high-speed data stream transmission (suitable for continuous sampling devices such as audio, video, and ADC), while the AXIDMA module is used to achieve high-speed data transfer between the PL and PSDDR. In this design, the AXIDMA is configured in simple mode (DirectRegister mode) and the MM2S channel is enabled for high-speed data transfer from programmable logic to memory. This AXI bus-based design implements a standardized data transmission interface, improving system interoperability and scalability.

[0123] In step S4.2, the processing system writes information such as the source address, destination address, and data length to the DMA control registers (DMACR, source address register, and transfer length register) through the AXI-Lite interface, and sets the start flag to trigger DMA transfer. The configuration of these registers determines the specific parameters of DMA transfer, such as the data source address, destination address, and transfer length. By configuring these parameters properly, the system can achieve efficient data transfer.

[0124] In step S4.3, the AXIDMA controller receives data from the PL side according to the AXI4-Stream protocol and writes the data to the PSDDR memory using the high-performance AXI port. To address the issue of asynchronous clocking between the PL data acquisition clock and the PS AXI clock, an AXI-Stream FIFO is configured before each data stream to perform clock domain conversion. This design ensures the reliability of data transmission between different clock domains and avoids data loss or errors due to clock asynchrony.

[0125] Example code is as follows:

[0126] void init_dma_transfer(UINTPTR buf, u32 len) { / / Start AXIDMA transfer (MM2S mode) XAxiDma_SimpleTransfer(&AxiDma, buf, len, XAXIDMA_DEVICE_TO_DMA);}

[0127] S4.4: The DMA transfer process also includes buffer management and interrupt handling:

[0128] S4.4.1: Based on the memory data before DMA transfer, call the cache management interface to perform a data cache refresh operation to ensure physical memory data consistency;

[0129] S4.4.2: Detect the DMA transfer completion status, set the completion flag in the status register DMASR and generate an interrupt to generate a transfer completion notification signal;

[0130] S4.4.3: Based on the transmission completion notification signal, clear the DMA interrupt flag and invalidate the cache area in the interrupt service routine to obtain the data interaction result between the processing system and the programmable logic.

[0131] In step S4.4.1, the cache management interface (Xil_DCacheFlushRange) needs to be called to flush the relevant memory cache before DMA transfer to ensure that data in the processor cache is written back to physical memory. This cache management mechanism solves the cache consistency problem and ensures the accuracy and integrity of DMA transfer data. In multi-core processor systems, cache consistency is an important issue. Through a reasonable cache management strategy, the system can avoid data errors caused by cache inconsistency.

[0132] In step S4.4.2, after the transfer is completed, the DMA sets the completion flag in the status register DMASR and generates an interrupt. This interrupt mechanism enables the system to promptly detect the completion of the DMA transfer, thus allowing for subsequent data processing. By detecting the status register, the system can accurately determine the status of the DMA transfer, such as completion or error, providing a basis for subsequent error handling.

[0133] In step S4.4.3, the PS-side interrupt service routine clears the DMA interrupt flag by calling XAxiDma_IntrClear and invalidates the corresponding cache region using Xil_DCacheInvalidateRange, ensuring that the CPU reads the latest DMA transfer data. This cache invalidation operation ensures that the processor can read the latest DMA transfer data from memory, rather than old data in the cache, thus guaranteeing data accuracy and timeliness.

[0134] Example code is as follows:

[0135]

[0136]

[0137] like Figure 4 As shown in the figure, an embodiment of the present disclosure provides a hardware abstraction layer reconfiguration device based on a programmable logic platform, comprising:

[0138] Device identification module 41 is used to obtain the GPIO pin level combination of the expansion module, decode the GPIO pin level combination, and obtain the device type identifier of the expansion module;

[0139] Peripheral activation module 42 is used to activate the corresponding peripheral sub-module in the unified peripheral IP logic module based on the device type identifier, so as to obtain the target peripheral logic unit in the enabled state.

[0140] The driver loading module 43 is used to perform driver mapping table lookup and initialization configuration on the target peripheral logic unit, and to call the corresponding driver initialization function through the bare-metal dynamic driver framework to obtain an operable hardware abstraction layer interface.

[0141] The data transmission module 44 is used to configure parameters through the AXI-Lite control bus and transmit data through the AXI-Stream data bus and the AXI-DMA module based on the hardware abstraction layer interface, so as to obtain the data interaction results between the processing system and the programmable logic.

[0142] In this embodiment, the device is implemented based on the Xilinx ZYNQ7015 chip, which integrates an ARM processor and FPGA programmable logic, suitable for the teaching and experimental needs of university students. This device enables a complete closed-loop process of "plug and play, identify and drive, drive and use," providing an efficient, low-cost, and beginner-friendly solution for teaching.

[0143] The device identification module reads the GPIO register values ​​to obtain the level status of GPIO[2:0], then converts the binary level combination into a decimal ID code to obtain the device type identifier of the expansion module. The peripheral activation module generates a periph_id selection signal based on the device type identifier, sets the corresponding peripheral submodule to the active state while keeping the other submodules idle. The driver loading module searches for the corresponding driver initialization function in the driver mapping table based on the device type identifier and executes the function call to complete hardware initialization and parameter configuration. The data transmission module configures parameters through the AXI-Lite control bus and achieves high-speed data transmission between the processing system and the programmable logic through the AXI-Stream data bus and the AXI-DMA module.

[0144] For details on the implementation of each of the above modules, please refer to the explanation in the aforementioned methods section, which will not be repeated here.

[0145] The above description is merely a preferred embodiment of this disclosure and is not intended to limit this disclosure. Various modifications and variations can be made to this disclosure by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the protection scope of this disclosure.

[0146] This disclosure also provides a computer device including a processor and a memory. The memory stores machine-readable instructions executable by the processor. The processor executes the machine-readable instructions stored in the memory. When the machine-readable instructions are executed by the processor, the processor performs the steps of the hardware abstraction layer refactoring method based on a programmable logic platform described above.

[0147] The aforementioned storage includes main memory and external storage; the main memory, also known as internal memory, is used to temporarily store the processing data in the processor, as well as the data exchanged with external storage such as hard disks. The processor exchanges data with external storage through main memory.

[0148] This disclosure also provides a computer-readable storage medium storing a computer program. When a processor executes the program, it performs the steps of the hardware abstraction layer refactoring method based on a programmable logic platform as described in the above-described method embodiments. The storage medium can be either volatile or non-volatile computer-readable storage.

[0149] Furthermore, this disclosure also provides a computer program product storing a computer program. When the computer program is run by a processor, it executes the steps of the hardware abstraction layer reconfiguration method based on a programmable logic platform provided in any of the above embodiments of this disclosure. For details, please refer to the above method embodiments, which will not be repeated here.

[0150] The aforementioned computer program product can be implemented through hardware, software, or a combination thereof. In one optional embodiment, the computer program product is specifically embodied in a computer storage medium, which can be a volatile or non-volatile computer-readable storage medium. In another optional embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0151] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the devices and apparatuses described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. In the several embodiments provided in this disclosure, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection may be through some communication interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

[0152] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0153] In addition, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0154] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0155] Finally, it should be noted that the above-described embodiments are merely specific implementations of this disclosure, used to illustrate the technical solutions of this disclosure, and not to limit it. The protection scope of this disclosure is not limited thereto. Although this disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this disclosure; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this disclosure, and should all be covered within the protection scope of this disclosure. Therefore, the protection scope of this disclosure should be determined by the protection scope of the claims.

Claims

1. A method for reconfiguring the hardware abstraction layer based on a programmable logic platform, characterized in that, include: Obtain the general purpose input / output (GPIO) pin level combination of the expansion module, decode the GPIO pin level combination to obtain the device type identifier of the expansion module; Based on the device type identifier, the corresponding peripheral sub-module is activated in the unified peripheral IP logic module to obtain the target peripheral logic unit in the enabled state. The target peripheral logic unit is configured by looking up the driver mapping table and initializing it. The corresponding driver initialization function is called through the bare-metal dynamic driver framework to obtain an operable hardware abstraction layer interface. Specifically, based on the device type identifier, a function pointer is looked up in the driver mapping table to obtain the address of the corresponding driver initialization function. The driver initialization function address is called to execute the hardware initialization and parameter configuration of the corresponding peripheral to obtain the operable hardware abstraction layer interface. Based on the aforementioned hardware abstraction layer interface, parameters are configured through the AXI-Lite control bus (Advanced Extensible Interface - Lightweight Version), and data is transmitted through the AXI-Stream data bus (Advanced Extensible Interface - Stream Interface) and the AXI-DMA module (Advanced Extensible Interface - Direct Memory Access) to obtain the data interaction results between the processing system and the programmable logic. Specifically, based on the AXI-Stream data stream, high-speed data transfer is configured through the AXI-DMA controller to generate DMA transfer control parameters. The DMA transfer control parameters are then written to registers, and transfer information is written to the DMA control register DMACR, the source address register, and the transfer length register to obtain the DMA transfer start conditions. Based on the DMA transfer start conditions, the data from the programmable logic side is transferred to the double data rate DDR memory on the PS side of the processing system through the high-performance advanced scalable interface AXI port, thereby obtaining the data interaction results between the processing system and the programmable logic.

2. The method according to claim 1, characterized in that, The GPIO pin level combination is decoded to obtain the device type identifier of the expansion module, including: Based on the level states of three GPIO pins, an encoding mapping table for various device types is constructed to generate the correspondence between device type and ID code; The GPIO pin level combination is read from the register, and the read binary level combination is converted into a decimal ID code to obtain the device type identifier of the expansion module.

3. The method according to claim 1, characterized in that, Activating the corresponding peripheral submodule in the unified peripheral IP logic module yields the target peripheral logic unit in the enabled state, including: Based on the device type identifier, a peripheral identifier (periph_id) selection signal is generated to obtain the enable control signal for the peripheral submodule; The enable control signal is logically assigned to set the corresponding peripheral submodule to the active state, while keeping the remaining submodules in the idle state, thus obtaining the target peripheral logic unit in the enabled state.

4. The method according to claim 3, characterized in that, The peripheral submodule includes an analog-to-digital converter (ADC) submodule. Setting the peripheral submodule to an active state includes: Based on the ADC conversion start signal, the ADC sampling timing is controlled by a finite state machine to generate the ADC conversion control state; The ADC conversion control state is switched sequentially, executing idle state, conversion start state, data preparation wait state, and conversion result read state to obtain ADC acquisition data. Based on the data acquired by the ADC, clock domain conversion is performed through an asynchronous first-in-first-out (FIFO) to generate a cross-clock domain data buffer. The cross-clock domain data buffer is encapsulated using the AXI-Stream protocol, and the FIFO output data is formatted according to the AXI4-Stream protocol to obtain a standardized data stream output. Based on the configuration parameters of the AXI-Lite interface, the ADC sampling rate and resolution are dynamically configured to obtain the target peripheral logic unit in the enabled state.

5. The method according to claim 3, characterized in that, The peripheral submodule includes an HDMI input submodule. Setting the peripheral submodule to an active state includes: Based on the input of the minimized transmission differential signal TMDS signal, the signal is decoded by a dedicated IC to generate the decoded pixel data stream; Pixel clock recovery is performed on the pixel data stream. The pixel clock is recovered from the TMDS clock using a phase-locked loop to obtain a synchronized pixel acquisition timing sequence. Based on the pixel acquisition timing, the line synchronization and frame synchronization signals are detected by the internal state machine to generate video frame boundary recognition signals; The video frame boundary identification signal is subjected to frame data acquisition control. After a new frame is detected, pixel-by-pixel data is synchronously written to the FIFO buffer line by line to obtain the frame data buffer. Based on the frame data buffer, the pixel stream is output according to the preset color depth and frame rate through the AXI-Stream interface to obtain the target peripheral logic unit in the enabled state.

6. The method according to claim 3, characterized in that, The peripheral submodule includes a camera submodule. Setting the peripheral submodule to an active state includes: Based on the I2C communication protocol between integrated circuits, the camera sensor register is configured to generate sensor operating parameter settings; The sensor's operating parameters are initialized by setting the image resolution and frame rate parameters to obtain the sensor's initialization state. Based on the vertical synchronization signal VSYNC and the horizontal synchronization signal HSYNC, a finite state machine is used to control the image frame acquisition timing and generate pixel data acquisition control signals. The pixel data acquisition control signal is controlled to write data. During the period when the VSYNC signal is valid, each row of pixel data is written to the FIFO buffer to obtain the image frame data buffer. Based on the image frame data buffer, the image data is output to the AXI-DMA module through the AXI-Stream interface to obtain the target peripheral logic unit in the enabled state.

7. The method according to claim 1, characterized in that, The DMA transfer process also includes buffer management and interrupt handling: Based on the memory data before DMA transfer, the cache management interface is called to perform a data cache refresh operation, thereby ensuring the consistency of physical memory data. The DMA transfer completion status is detected, the completion flag is set in the status register DMASR and an interrupt is generated, and a transfer completion notification signal is generated. Based on the transmission completion notification signal, the DMA interrupt flag is cleared and the cache area is invalidated in the interrupt service routine to obtain the data interaction result between the processing system and the programmable logic.

8. A hardware abstraction layer reconfiguration device based on a programmable logic platform, characterized in that, include: The device identification module is used to obtain the GPIO pin level combination of the expansion module, decode the GPIO pin level combination, and obtain the device type identifier of the expansion module. The peripheral activation module is used to activate the corresponding peripheral sub-module in the unified peripheral IP logic module based on the device type identifier, so as to obtain the target peripheral logic unit in the enabled state. The driver loading module is used to perform driver mapping table lookup and initialization configuration on the target peripheral logic unit, and to call the corresponding driver initialization function through the bare-metal dynamic driver framework to obtain an operable hardware abstraction layer interface; specifically, it is used to perform function pointer lookup in the driver mapping table based on the device type identifier to obtain the address of the corresponding driver initialization function; and to call the driver initialization function address to execute the hardware initialization and parameter configuration of the corresponding peripheral to obtain the operable hardware abstraction layer interface. The data transmission module is used to configure parameters via the AXI-Lite control bus based on the hardware abstraction layer interface, and to transmit data via the AXI-Stream data bus and the AXI-DMA module to obtain the data interaction results between the processing system and the programmable logic; specifically, it is used to configure high-speed data transfer via the AXI-DMA controller based on the AXI-Stream data stream to generate DMA transfer control parameters; and to write the DMA transfer control parameters into registers, writing transfer information to the DMA control register DMACR, the source address register, and the transfer length register to obtain the DMA transfer start conditions. Based on the DMA transfer start conditions, the data from the programmable logic side is transferred to the double data rate DDR memory on the PS side of the processing system through the high-performance advanced scalable interface AXI port, thereby obtaining the data interaction results between the processing system and the programmable logic.

Images