Field programmable gate array (FPGA)-based file system, file management method, equipment and medium

Abstract

The invention relates to the technical field of data acquisition and storage, and discloses an FPGA-based file system, a file management method, equipment and a medium. The file system is constructed based on an FPGA internal hardware logic circuit and comprises control instruction analysis, file management, storage management and a register. The control instruction analysis module receives and analyzes an operation instruction of an external control end, and sends an analysis result to the file management module; the file management module is connected with the register and the storage management module, responds to the analyzed instruction, generates an internal operation instruction and issues the internal operation instruction; the register module is used for storing file metadata and executing related operations of the metadata; the storage management module divides a physical memory address space into storage blocks, maintains an idle resource pool to manage the storage blocks, and responds to an instruction to execute storage block operation. The file system is realized in an FPGA (Field Programmable Gate Array) through a customized hardware logic circuit, so that high-throughput, low-delay and high-reliability storage and management of mass data are realized.

Description

Technical Field

[0001] This application relates to the field of data acquisition and storage technology, and in particular to FPGA-based file systems, file management methods, devices and media. Background Technology

[0002] Field-Programmable Gate Arrays (FPGAs) are widely used in high-speed data acquisition and real-time signal processing due to their highly parallel processing capabilities and flexible customizability. In such scenarios, massive amounts of data need to be stored efficiently and reliably in non-volatile memory, and the data storage throughput, latency, and resource consumption directly affect the performance of the entire system.

[0003] The mainstream solution adopts a heterogeneous computing platform that integrates processors and FPGAs. The file system (such as FAT32, ext4) runs in software on the general-purpose processor of the processing system (PS). The FPG programmable logic (PL) is only responsible for data acquisition and preprocessing. The data needs to be transmitted to the PS via the internal bus, and the CPU executes the software code to complete the storage.

[0004] The inventors discovered that the above-mentioned solutions have at least the following problems: the serial processing characteristics of general-purpose processors and the software overhead such as operating system kernel calls and memory copying result in limited data storage throughput, which cannot unleash the potential of high-speed storage media; the long software processing path and many links result in high and fluctuating I / O operation latency; running a complete operating system and file system services requires a large amount of CPU computing resources and memory, which increases system power consumption and design complexity, making it difficult to meet the needs of high real-time and resource-constrained scenarios. Summary of the Invention

[0005] The purpose of this application is to provide a file system, file management method, device and medium based on FPGA, which aims to solve the technical problems of limited data storage speed, high and uncertain operation latency and large system resource consumption caused by the reliance on general processors and software file systems in high-speed data storage scenarios of FPGA applications.

[0006] To address the aforementioned problems, one or more embodiments of this specification provide an FPGA-based file system. The file system is implemented using internal hardware logic circuitry within the FPGA and includes: a control instruction parsing module, a file management module, a storage management module, and a register module. The control instruction parsing module receives and parses operation instructions from an external control terminal and sends the parsed instructions to the file management module. The operation instructions include one or any combination of delete, modify, and read. The file management module is connected to both the register module and the storage management module. The file management module is configured to generate internal operation instructions in response to the parsed operation instructions and send these internal operation instructions to both the register module and the storage management module. The register module applies metadata stored in the files and performs metadata operations in response to the internal operation instructions. The metadata includes at least the filename, file size, and the storage block number occupied by the file. The storage management module divides the address space of the physical memory into multiple storage blocks for storing files and maintains a free resource pool to store the storage blocks, performing storage block operations in response to the internal operation instructions.

[0007] This specification provides one or more embodiments of a file management method applied to a file management module in an FPGA-based file system as described above. The method includes: generating internal operation commands based on operation commands received and parsed by an external control terminal from a control command parsing module; and sending the internal operation commands to a register module and a storage management module for the register module and the storage management module to perform corresponding operations.

[0008] This specification provides one or more embodiments of a data acquisition device, the device including an FPGA chip and a non-volatile memory; the FPGA chip integrates an FPGA-based file system as described above; the non-volatile memory is connected to the FPGA chip and is directly controlled by the storage management module of the file system.

[0009] This specification provides one or more embodiments of a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the file management method described above.

[0010] Compared to related technologies, one or more embodiments of this application provide an FPGA-based file system. This file system is implemented using internal hardware logic circuits within the FPGA, thus directly eliminating dependence on general-purpose processors and processing systems. It avoids time-consuming operations such as kernel calls, interrupt handling, and process switching inherent in software file systems, eliminating core software redundancy that limits speed at the lowest level, and allowing data storage to directly rely on the parallel processing capabilities of the FPGA. The file system includes a control instruction parsing module, a file management module, a storage management module, and a register module. The file management module is communicatively connected to the control instruction parsing module, the register module, and the storage management module. Responding to operation instructions parsed by the control instruction parsing module, the file management module coordinates with the register module and the storage management module to establish a data transmission path between the external control terminal and the physical memory managed by the storage management module. This allows data to bypass the general-purpose processor and its cache for direct transmission, eliminating the need for repeated copying between the CPU and memory, significantly improving transmission efficiency. The storage management module divides the physical memory into fixed-size storage blocks. Compared to the disk sector management of a software file system, hardware-level block allocation or reclamation eliminates the need for CPU serial computation, effectively improving response speed. Hardware-based maintenance of the idle resource pool allows storage block allocation and reclamation to proceed without software-level defragmentation or path retrieval, enabling parallel processing of multiple storage requests. In summary, one or more embodiments provided in this specification propose a modular file system entirely based on FPGA hardware logic. This hardens all file system metadata management and storage block management into circuit logic, thereby solving the problems of insufficient data storage bandwidth, uncertain latency, and excessive system resource overhead caused by reliance on general-purpose processors and software file systems.

[0011] According to one or more embodiments of this specification, the FPGA-based file system includes a file management module comprising a file deletion module: the file deletion module is configured to generate a deletion instruction in response to the parsed operation instruction, send the deletion instruction to the register module to obtain at least one storage block number corresponding to the file to be deleted, and send the at least one storage block number and the deletion instruction to the storage management module; the register module is configured to, in response to the deletion instruction, search for the metadata of the file to be deleted, extract at least one storage block number corresponding to the metadata of the file to be deleted, and send the at least one storage block number to the file deletion module; the storage management module is configured to, in response to the deletion instruction, place the storage block corresponding to the at least one storage block number into the idle resource pool.

[0012] According to one or more embodiments of this specification, the FPGA-based file system includes a file management module that further includes a file writing module. The file writing module is configured to generate a creation instruction in response to the parsed operation instruction, send the creation instruction to the register module to obtain the number of storage blocks required for the file to be created, and send the number of storage blocks and the creation instruction to the storage management module. The register module is configured to allocate new metadata storage space to the file to be created in response to the creation instruction, determine the number of storage blocks based on the size of the file to be created, and send the number of storage blocks to the file writing module. The storage management module is configured to pop the required number of storage blocks from the free resource pool according to the creation instruction, set the popped storage block sequence number, and store the file to be created based on the popped storage blocks. The file writing module is also configured to send the popped storage block sequence number to the register module, so that the register module can write the popped storage block sequence number into the metadata of the file to be created.

[0013] According to one or more embodiments of the FPGA-based file system provided in this specification, the file writing module is further configured to generate a modification instruction in response to the parsed operation instruction, and send the modification instruction to the register module to obtain at least one storage block number corresponding to the file to be modified, and send the modification instruction and the at least one storage block number to the storage management module to extract the file content stored in the corresponding storage block from the storage management module, and modify the obtained file content; the register module is further configured to determine the metadata of the file to be modified according to the modification instruction, extract at least one storage block number of the metadata of the file to be modified, and send the extracted at least one storage block number to the file writing module in sequence; the storage management module is further configured to extract the corresponding storage block according to the at least one storage block number, and send the stored file content to the file writing module.

[0014] According to one or more embodiments of this specification, the FPGA-based file system is implemented using registers or block random access memory (BRAM) within the FPGA and is used to support hardware parallel queries of the metadata. Attached Figure Description

[0015] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0016] Figure 1This is an exemplary block diagram of an FPGA-based file system according to some embodiments of this specification.

[0017] Figure 2 This is an exemplary flowchart of a file management method according to some embodiments of this specification.

[0018] Figure 3 This is an exemplary flowchart of the file creation and writing process according to some embodiments of this specification.

[0019] Figure 4 This is an exemplary flowchart of a file reading process according to some embodiments of this specification.

[0020] Figure 5 This is an exemplary flowchart of a file deletion process according to some embodiments of this specification.

[0021] Figure 6 This is an exemplary block diagram of a data acquisition device according to some embodiments of this specification. Detailed Implementation

[0022] To more clearly illustrate the technical solutions of the embodiments in this specification, the embodiments will be described in detail below with reference to the accompanying drawings. Obviously, the content described below are some examples or embodiments of this specification. For those skilled in the art, without creative effort, the technical solutions or means disclosed in this specification can be applied to other scenarios based on this technical content.

[0023] It should be understood that the terms "system," "device," "unit," and / or "module" used in this specification are a method of distinguishing different components, elements, parts, sections, or assemblies at different levels. However, if other terms can achieve the same purpose, they may be replaced by other expressions.

[0024] Unless otherwise specified, the technical terms used to describe components, elements, etc. in this specification are not singular but may include plural. Generally speaking, terms such as "comprising" or "including" only indicate that explicitly identified steps, elements, or components are included, and these steps, elements, and components do not constitute an exclusive list, as the described method or apparatus may also include other steps or components.

[0025] This specification uses flowcharts to illustrate the operational steps performed by the apparatus or system of related embodiments. However, unless otherwise specified, the order in which these steps are described should not be construed as a limitation on the order of execution. Those skilled in the art can adjust the order of these steps based on the knowledge and information conveyed by the embodiments in this specification. Such adjustments include, but are not limited to, reversing the order of steps, merging multiple steps, and splitting a step.

[0026] As can be seen from the background technology in this specification, current mainstream solutions suffer from insufficient data storage bandwidth, uncertain latency, and excessive system resource overhead due to their reliance on general-purpose processors and software file systems.

[0027] To address the aforementioned technical issues, this application proposes an FPGA-based file system (hereinafter referred to as "file system"). This file system is implemented based on the internal hardware logic circuit of the FPGA. Its core function is to implement the core management functions of the file system in the FPGA through customized hardware logic circuits, thereby achieving high throughput, low latency, and high reliability storage and management of massive amounts of data.

[0028] Figure 1 This is an exemplary block diagram of an FPGA-based file system according to some embodiments of this specification. Figure 1 As shown, the system adopts a modular design, mainly comprising a control instruction parsing module, a file management module, a storage management module, and a register module. The file management module communicates with the control instruction parsing module, register module, and storage management module. Through customized hardware logic, the core functions of the file system, such as instruction parsing, metadata management, and storage scheduling, are directly completed in the FPGA. This fundamentally bypasses the software overhead of serial processing by general-purpose processors and operating system kernel calls, providing a hardware foundation for achieving high-throughput, low-latency, and high-reliability storage and management of massive amounts of data.

[0029] The control instruction parsing module receives and parses operation instructions from an external control terminal, and sends the parsed instructions to the file management module. These operation instructions include one or any combination of delete, modify, and read. Specifically, the control instruction module is configured as a designated interface for communication between the file system and an external control terminal (e.g., a host computer). Its core function is to receive operation instructions from the external control terminal, parse the received instructions to identify the instruction type and operation target, and distribute the corresponding control instructions to the file system based on the parsing results. This module communicates with the external system according to a preset custom communication protocol, ensuring efficient instruction transmission. The range of operation instructions it processes covers one or more of delete, modify, and read operations, with the modify operation corresponding to the file renaming function, fully covering the core operation requirements of creation, reading, deletion, and renaming. This module also translates and converts received heterogeneous external instructions into standardized operation commands with a unified internal format, avoiding format confusion issues in downstream modules and laying the foundation for a hierarchical processing architecture within the system.

[0030] The file management module is connected to both the register module and the storage management module. It is configured to generate internal operation instructions in response to the parsed operation commands and send these instructions to both modules. Specifically, the file management module, as the core scheduling hub of the system, integrates all functions for creating, modifying, reading, and deleting files, enabling command response, internal scheduling, and collaborative execution. This module is directly connected to both the register module and the storage management module, forming a direct hardware link between commands, metadata, and storage, without going through a software intermediary layer. Its core function is to respond to the parsing results of the control command parsing module, generating internal operation instructions adapted for metadata operations in the register module and storage block operations in the storage management module, enabling a single command to trigger the collaborative work of the two core modules. For example, when receiving a file creation instruction, this module generates a metadata allocation instruction and sends it to the register module, and simultaneously generates a storage block request instruction and sends it to the storage management module; when receiving a file read instruction, this module generates a metadata retrieval instruction to obtain the storage block number, and generates a storage block read instruction to read data from the physical memory; when receiving a file delete instruction, this module generates a metadata clear instruction and a storage block reclamation instruction.

[0031] The register module, which stores file metadata, performs metadata operations in response to internal operation instructions. This metadata includes at least the filename, file size, and the storage block number occupied by the file. Specifically, the register module, as the hardware carrier for storing file metadata, is implemented using the high-speed storage resources within the FPGA. The metadata stored in this module includes at least the filename, file size, and the storage block number occupied by the file. It responds to internal instructions from the file management module to perform metadata query, allocation, update, and clear operations, and supports fast parallel queries, providing high-speed support for efficient file retrieval and significantly reducing the target file location time.

[0032] The storage management module is used to divide the address space of the physical memory into multiple storage blocks for storing files, maintain a free resource pool to store the storage blocks, and execute storage block operations in response to internal operation instructions. Specifically, as the core module directly connected to the physical memory, the storage management module is responsible for the partitioning, scheduling, and maintenance of storage resources. This module divides the address space of the physical memory into multiple fixed-size storage blocks to achieve standardized management of storage resources, maintains a FIFO-based hardware queue to dynamically manage the sequence number of free storage blocks, ensures the efficiency of storage block allocation and reclamation, and executes storage block allocation, reading, and reclamation operations in response to internal instructions from the file management module. All actions are executed in real time by hardware logic, without software scheduling delay.

[0033] One or more embodiments of this application propose a modular file system that is fully implemented based on FPGA hardware logic. The metadata management and storage block management of the file system are all hardened into circuit logic, avoiding the software overhead of the prior art, and achieving the goals of high throughput, low latency and low resource consumption through module collaboration.

[0034] To implement the entire file deletion process, in some embodiments, the file management module further includes a file deletion module: the file deletion module is used to generate a deletion instruction in response to the parsed operation instruction, send the deletion instruction to the register module to obtain at least one storage block number corresponding to the file to be deleted, and send the at least one storage block number and the deletion instruction to the storage management module; the register module is used to respond to the deletion instruction, search for the metadata of the file to be deleted, extract at least one storage block number corresponding to the metadata of the file to be deleted, and send the at least one storage block number to the file deletion module; the storage management module is used to respond to the deletion instruction to place the storage block corresponding to the at least one storage block number into the idle resource pool.

[0035] In one example, the deletion instruction is generated by the file control instruction parsing module after parsing external instructions (such as the "delete file" command from the host machine). It follows a system-defined hardware communication protocol with a uniform and fixed format. For example, it includes core fields such as "instruction type (delete)" and "target file identifier (such as the hardware code corresponding to the filename)," ensuring that the register module can quickly locate the target file and the storage management module can accurately execute the storage block reclamation operation, meeting the design requirements of "pipeline processing." During the deletion process, the flow of deletion instructions and storage block sequence data is executed only within a closed-loop path formed by the file deletion module, register module, and storage management module. This process runs independently of the general-purpose processor and operating system, avoiding high-overhead steps such as system calls, memory copies, and disk seeks in software deletion operations, thus ensuring millisecond-level low latency. The register module relies on the FPGA's internal high-speed storage resources (registers or BRAM) and supports fast parallel queries. Compared to the "reading metadata from disk and retrieving" method in software file systems, hardware-based metadata lookup and retrieval speeds are improved to the microsecond level, a key support for the efficient completion of deletion operations. The storage management module places storage blocks into the free resource pool. The free resource pool is essentially a hardware-based storage resource management platform (such as a FIFO hardware queue). Storage block reclamation does not require software-level defragmentation or path marking; it simply uses hardware logic to "push" the storage block number into the free list, ensuring rapid allocation when subsequent files are created.

[0036] In some embodiments, the file management module further includes a file writing module; the file writing module is configured to generate a creation instruction in response to the parsed operation instruction, send the creation instruction to the register module to obtain the number of storage blocks required for the file to be created, and send the number of storage blocks and the creation instruction to the storage management module; the register module is configured to allocate new metadata storage space to the file to be created in response to the creation instruction, determine the number of storage blocks according to the size of the file to be created, and send the number of storage blocks to the file writing module; the storage management module is configured to pop the required number of storage blocks from the free resource pool according to the creation instruction, set the popped storage block sequence number, and store the file to be created based on the popped storage blocks; the file writing module is further configured to send the popped storage block sequence number to the register module, so that the register module can write the popped storage block sequence number into the metadata of the file to be created.

[0037] In one example, the write file module is essentially a hardware-based scheduling unit that implements creation and write operations. The core of this write file module lies in separating and independently implementing the file creation function and data write scheduling logic contained in the conventional file creation / modification module. Its core functions are twofold: first, as an instruction relay hub, it receives parsed external instructions and generates standardized creation instructions, which are then distributed to the register module and the memory management module; second, as a data flow hub, it transmits the number of memory blocks and their sequence numbers, ensuring information synchronization between the register module and the memory management module. Figure 3 The entire process is implemented through FPGA hardware logic, eliminating the need to execute software code and thus removing the system overhead caused by process switching and memory copying. The creation instructions here are binary encoded signals or high / low level combinations that the FPGA hardware module can directly recognize, distinct from software-level function calls or system commands. Its core components include an instruction type identifier to clearly identify the creation operation, distinguishing it from read or delete instructions; core information about the file to be created, such as the hardware code corresponding to the filename and file size data; and optional verification information for hardware-level verification of instruction integrity to achieve high reliability. This design eliminates the need for CPU decoding and operating system intermediaries, supporting direct recognition and response between modules. The register module, as the metadata storage carrier, directly allocates metadata space for new files and simultaneously calculates the required number of storage blocks based on the file size and a preset storage block size (e.g., 1KB) (e.g., 4 storage blocks for a 3.2KB file). This calculation is implemented by FPGA hardware circuitry logic (such as division and rounding up), requiring no software computation, and the calculation time is negligible, ensuring low latency. The idle resource pool is a FIFO-based hardware queue. In practical applications, after receiving the creation command and the number of storage blocks, the storage management module extracts the corresponding number of storage block numbers from the queue in FIFO order through hardware logic. This eliminates the need for software to search for free space, resulting in extremely fast allocation. This solution fully leverages the parallel processing capabilities of the FPGA, avoiding the multi-stage delays in software file systems where free space is queried and marked as occupied, thus releasing the performance of the high-speed storage medium. The storage block number write-back metadata is synchronously updated in hardware to ensure data consistency. The flow path is from the storage management module through the file writing module to the register module. The core significance of this operation is writing the allocated storage block number into the new file metadata, ensuring that subsequent file readings can quickly locate the storage block through the metadata and that file deletions can accurately reclaim the storage block, forming a crucial link in the closed-loop file operation. Reliability is ensured because the write-back operation is executed synchronously by the hardware module, without software caching or disk writing stages. Even sudden power outages or system crashes will not cause inconsistencies between the metadata and the storage block state, achieving the beneficial effect of enhanced reliability.

[0038] In some embodiments, the file writing module is further configured to generate a modification instruction in response to the parsed operation instruction, and send the modification instruction to the register module to obtain at least one storage block number corresponding to the file to be modified, and send the modification instruction and the at least one storage block number to the storage management module to extract the file content stored in the corresponding storage block from the storage management module, and modify the obtained file content; the register module is further configured to determine the metadata of the file to be modified according to the modification instruction, extract at least one storage block number of the metadata of the file to be modified, and send the extracted at least one storage block number to the file writing module in sequence; the storage management module is further configured to extract the corresponding storage block according to the at least one storage block number, and send the stored file content to the file writing module.

[0039] Specifically, the modification instruction is consistent with the creation and deletion instructions mentioned earlier. It is a binary encoded signal that the FPGA hardware module can directly recognize. Its core includes an instruction type identifier, which is used to clarify the content modification operation, distinguishing it from renaming or reading instructions, a unique identifier of the file to be modified (such as the hardware code corresponding to the file name, which allows the register module to quickly locate metadata), and optional modification range information (such as modifying the starting address and length to reduce invalid data reads and writes). This design does not require CPU decoding and operating system relay, realizing direct response between modules, thereby ensuring the low latency of the modification operation. In this embodiment, an external control terminal (such as the upper unit) sends a "modify file content" instruction, which is parsed into a unified format internal operation instruction by the file control instruction parsing module. The write file module receives the instruction, generates a hardware-based "modification instruction," and sends it to the register module. The register module responds by locating the metadata of the file to be modified through hardware parallel query, extracts all storage block numbers, and sends them to the write file module in sequence. The write file module forwards the modification instruction and storage block numbers to the storage management module. The storage management module responds by reading the file content of the corresponding storage block sequentially according to the storage block number through hardware read logic and sending it to the write file module. The write file module performs modification operations such as replacement, insertion, or deletion on the received file content through hardware logic. In the implicit process, the write file module sends the modified file content to the storage management module according to the original storage block number, and the storage management module writes it back to the corresponding storage block. Each module feeds back "modification complete" through hardware signals.

[0040] In some embodiments, the file management module further includes a file reading module; the file reading module is configured to generate a read instruction in response to the parsed operation instruction, and send the read instruction to the register module to extract at least one storage block number corresponding to the file to be read, and send the at least one storage block number to the storage management module to extract the file content stored in the corresponding storage block from the storage management module; the register module is configured to determine the metadata of the file to be read according to the read instruction, and extract at least one storage block number corresponding to the metadata of the file to be read. For example, an external control terminal (such as the host computer) sends a "read file" command, which is parsed into a unified format internal operation command by the file control command parsing module. The file reading module receives the command, generates a hardware-based "read command," and sends it to the register module. The register module responds by locating the metadata of the file to be read through hardware parallel query, extracts all corresponding storage block numbers, and sends them to the file reading module. The file reading module forwards the storage block number to the storage management module and initiates a read request. The storage management module responds by reading the file content of the corresponding storage block sequentially according to the storage block number through hardware read logic, and sends it to the file reading module in sequence or directly uploads it to the external control terminal. The file reading module feeds back the file content to the external control terminal in sequence. Each module feeds back "read complete" through hardware signals, and the entire reading process ends.

[0041] In some embodiments, the register module is implemented using registers or block random access memory within the FPGA and is used to support hardware-parallel queries of the metadata. Specifically, the register module, acting as the system's "metadatabase," is implemented using high-speed storage resources within the FPGA (such as registers or BRAM). It stores the metadata of all files, with each file's metadata entry including: filename, creation time, file size, and a list of storage block numbers occupied by its content. This module supports fast parallel queries and is fundamental to achieving efficient file retrieval.

[0042] In one or more of the above embodiments, a file system fully implemented based on FPGA hardware logic is proposed, which hardens all metadata management and storage block management of the file system into circuit logic, thereby solving the problems of insufficient data storage bandwidth, uncertain latency, and excessive system resource overhead caused by relying on general-purpose processors and software file systems.

[0043] It is worth mentioning that all modules involved in this embodiment are logical modules. In practical applications, a logical unit can be a physical unit, a part of a physical unit, or a combination of multiple physical units. Furthermore, to highlight the innovative aspects of this application, this embodiment does not introduce units that are not closely related to solving the technical problem proposed in this application; however, this does not mean that other units are absent from this embodiment.

[0044] To enable the various modules of the aforementioned file system to work collaboratively to complete complex tasks, this embodiment presents a file management method tailored to a specific application scenario. All operations of this file management method are collaboratively completed by the FPGA hardware modules, eliminating the need to run any operating system or software file system, consume CPU computing resources, or allocate memory for loading software components such as the OS kernel and file cache. This fundamentally reduces the system's demand on CPU and memory. Furthermore, this file management method focuses on the core functions of instruction translation, command distribution, and process linkage, avoiding unnecessary services such as process management, network protocol stacks, and graphical interfaces in the software system, maintaining a lightweight hardware logic design. Simultaneously, the FPGA-based hardware modules offer significant power consumption advantages over general-purpose processors running a complete operating system, resulting in a substantial reduction in overall system power consumption. Moreover, it eliminates the need to address complex issues such as software and hardware compatibility adaptation and operating system kernel optimization, effectively reducing system design complexity.

[0045] Figure 2 An exemplary flowchart of a file management method according to some embodiments of this specification. In one example... Figure 2 The process shown can be executed by the file management module of the FPGA-based file system described above, and the process may include the following steps.

[0046] Step 210: Generate internal operation commands based on the operation commands received and parsed by the control command parsing module from the external control terminal.

[0047] The "internal operation commands" are essentially standardized control signals that the FPGA hardware can directly recognize, and their signal format is compatible with the "custom communication protocol." These "internal operation commands" are not software-level function calls or code instructions, but rather binary encoded signals or combinations of high and low levels generated in real-time by the hardware logic circuitry of the file management module. Specifically, they possess a unified standardized format, including core fields such as operation type identifier, target file identifier, and operation parameters, allowing the register module and memory management module to directly recognize them without format conversion. The commands are generated by the hardware logic circuitry without involving software compilation or interpretation, with generation time in the microsecond range to meet low latency requirements. Furthermore, dedicated commands are generated for different operation types; for example, the create command includes parameters for the number of memory blocks requested, and the delete command includes a memory block reclamation identifier, ensuring that downstream modules can accurately execute the corresponding operations.

[0048] Step 220: Send the internal operation commands to the register module and the memory management module for them to execute the corresponding operations.

[0049] The file management module is directly connected to the register module and storage management module via the FPGA's internal hardware bus, requiring no CPU or operating system intervention. Command transmission bypasses software-level delays such as memory buffering and bus arbitration, resulting in negligible transmission time. Regarding command execution coordination, internal operation commands trigger the register module to perform operations such as allocating, querying, updating, or clearing metadata. This relies on high-speed storage resources such as the FPGA's internal BRAM or registers, achieving operation times in the microsecond range. Simultaneously, it triggers the storage management module to perform operations such as allocating, reading, reclaiming, or scheduling storage blocks. This module is based on hardware logic for storage block partitioning and idle resource pool management, resulting in a response speed far exceeding that of software file system storage scheduling. In special cases, such as renaming operations, the internal operation commands sent by the file management module only need to be distributed to the register module to update metadata, without requiring additional operations from the storage management module, demonstrating the flexibility of command distribution.

[0050] like Figure 3 As shown, Figure 3This is an exemplary flowchart illustrating the file creation and writing process according to some embodiments of this specification. Specifically, the entire process is completed using the internal hardware logic of the FPGA, without software or CPU intervention. The process begins with an external control terminal sending a file creation command via a custom protocol, containing key information such as the file name and file size, serving as the entry point for the file system to interact with the external system. In the command parsing stage, the file control command parsing module receives the external command, parses it into a creation task in a unified internal system format, and sends it to the file writing module. This parsing process is completed by the FPGA hardware logic, without software decoding overhead. In the metadata initialization stage, the file writing module allocates metadata entries for the new file in the register module, which serves as the metadata database within the FPGA and is implemented using BRAM or registers. In the storage space verification stage, the hardware logic determines whether there are sufficient free storage blocks, calculates the required number based on the file size and the preset storage block size, and if insufficient, directly returns a creation failure signal to the outside and terminates the process; if sufficient, it proceeds to the next step. This check logic is embedded in the hardware circuitry, without any software-level resource retrieval delay. During the data writing phase, information such as filename, file size, and allocated storage block list are written to the metadata entries of the register module, completing the initialization of metadata. The data writing phase also involves writing externally acquired data to be stored into the physical storage blocks corresponding to the allocated storage block list. The storage management module performs hardware-based write operations, directly writing data to the physical storage blocks without memory copying or operating system scheduling overhead. If the process is successful at the end, a creation success signal is returned to the external control terminal; if space is insufficient, a creation failure signal is returned. This feedback is completed by hardware signals with a fixed latency in the microsecond range. The entire process forms a completely hardware-based closed loop, relying on the collaborative efforts of internal FPGA modules without CPU or operating system involvement. This demonstrates low latency advantages (all steps are executed by hardware logic, without software-level process switching or memory copying), high reliability advantages (hardware-based metadata management and storage block allocation avoid data inconsistencies caused by software crashes), and high throughput advantages (data writing directly connects to physical storage blocks, fully releasing the performance of high-speed storage media).

[0051] Figure 4 This is an exemplary flowchart illustrating a file reading process according to some embodiments of this specification. In some embodiments, the method specifically involves sending a read instruction to the register module, which determines the metadata of the file to be read and obtains at least one storage block number of the file to be read; and reading the file to be read from the physical memory based on the at least one storage block number. Figure 4In this FPGA-based file system, the entire file reading process is collaboratively completed by the FPGA's internal hardware modules. The process begins with an external control terminal sending a file reading command, containing the target filename, serving as the external interaction entry point for the file system. During the command parsing and task distribution phase, the file control command parsing module receives and parses the external command, converting it into a unified internal format for reading tasks and distributing it to the file reading module. This parsing process is completed by the FPGA hardware logic, eliminating software decoding overhead. In the metadata retrieval and file existence verification phase, the file reading module retrieves the corresponding metadata from the register module based on the filename. If the file does not exist, it directly returns a "file not found" error signal and terminates the process. If the file exists, it proceeds to the next step. This register module, acting as the FPGA's internal metadata database, is implemented using BRAM or registers, enabling fast parallel metadata lookup with a retrieval time in the microsecond range. The storage block number list acquisition phase extracts the physical storage block number list occupied by the target file from the metadata. This list provides the location basis for subsequent data reading. Finally, in the read command generation and distribution phase, the file reading module converts the storage block number list into a hardware-based read command. The command is sent to the storage management module. This read command can directly drive the storage management module without software conversion. In the hardware-based storage block data reading stage, the storage management module directly reads the data of the corresponding storage block from the physical memory according to the storage block number and returns it to the file reading module. This reading process has no software overhead such as operating system scheduling or memory copying, and the speed is only limited by the bandwidth of the storage medium. In the data upload and read completion verification stage, the file reading module uploads the read data stream to the external control terminal in sequence and verifies whether the entire file data has been read. If it is not read, the steps of reading the storage block and uploading data are repeated. When it is read, the subsequent steps are entered. This sequential read and upload mechanism ensures the consistency of the file content order. At the end of the process, if the reading is completed, a read operation completion signal is returned to the external control terminal. If the file does not exist, a file not found error signal is returned. This feedback is completed by hardware signals with a fixed latency in the microsecond range. The entire process relies on the direct connection of the FPGA module and the execution of hardware logic, completely avoiding the latency of operating system scheduling, disk seek or memory buffering in the software file system, realizing high throughput, low latency and predictable file reading, and fully achieving the design goals.

[0052] Figure 5 This is an exemplary flowchart illustrating a file deletion process according to some embodiments of this specification. Figure 5As shown, the hardware execution of the file deletion process in the FPGA-based file system is completed collaboratively by the internal hardware modules of the FPGA without software or CPU intervention. The core implementation involves a closed-loop operation of memory block reclamation and metadata clearing. The process begins with a file deletion command containing the target filename sent by an external control unit (such as the upper-level unit). This command serves as the external interaction entry point for the file system, entering the control command parsing module. The file control command parsing module receives and parses the external command, converting it into a deletion task in a unified internal format and sending it to the file deletion module. This process is completed by the FPGA hardware logic without software decoding overhead. The file deletion module retrieves the corresponding metadata in the register module based on the target filename to determine the file's existence. If the file does not exist, it directly returns a file not found error signal and terminates the process; if the file exists, it proceeds to the next step. The register module, acting as the FPGA's internal metadata database (implemented through BRAM or registers), enables microsecond-level retrieval through its hardware parallel query logic. Subsequently, the file deletion module extracts a list of all physical memory block numbers occupied by the target file from its metadata, providing a basis for subsequent reclamation. The list of storage block numbers is sent to the storage management module, which reclaims the corresponding numbers to the list of free storage blocks (such as a FIFO hardware queue), making them reusable resources. This reclamation operation is executed by the hardware logic of the storage management module, avoiding the overhead of software-level defragmentation and path marking. The file deletion module simultaneously sends instructions to the register module to clear the metadata entries corresponding to the target file to release storage space, ensuring that deleted files are not mistakenly retrieved later, in line with the high reliability design goal. At the end of the process, feedback is sent to the external control terminal based on the operation result: a success signal is returned when deletion is successful, and a file not found error signal is returned when the file does not exist. The feedback process is completed by hardware signals, with a fixed and microsecond-level latency. The entire process is executed by direct connection between the FPGA module and the hardware logic, forming a hardware-based resource reclamation closed loop. While achieving efficient recycling of storage resources, it completely avoids the latency of deletion marking and the time-consuming defragmentation of the software file system, perfectly achieving the design goals of high resource efficiency, low latency, and high reliability.

[0053] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this patent. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this patent.

[0054] Another embodiment of this application relates to a data acquisition device, such as... Figure 6As shown, the device includes an FPGA chip and a non-volatile memory; the FPGA chip integrates an FPGA-based file system as described above; the non-volatile memory is connected to the FPGA chip and is directly controlled by the storage management module of the file system.

[0055] Another embodiment of this application relates to a computer-readable storage medium storing a computer program. When executed by a computer program processor, the program implements the method embodiments described above.

[0056] That is, those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0057] Those skilled in the art will understand that the above embodiments are specific implementations of this application, and in practical applications, various changes can be made in form and detail without departing from the spirit and scope of this application.

Claims

1. A file system based on FPGA, characterized in that, The file system is implemented based on the internal hardware logic circuitry of the FPGA. The file system includes: a control instruction parsing module, a file management module, a storage management module, and a register module; wherein, The control instruction parsing module is used to receive and parse operation instructions from an external control terminal, and send the parsed operation instructions to the file management module. The operation instructions include one or any combination of delete, modify and read. The file management module is connected to the register module and the storage management module respectively. The file management module is configured to generate internal operation instructions in response to the parsed operation instructions, and send the internal operation instructions to the register module and the storage management module. The register module applies the metadata of the stored file and performs metadata operations in response to the internal operation instructions. The metadata includes at least the file name, file size, and the storage block number occupied by the file. The storage management module is used to divide the address space of the physical memory into multiple storage blocks for storing files, maintain a free resource pool to store the storage blocks, and execute storage block operations in response to the internal operation instructions.

2. The FPGA-based file system according to claim 1, characterized in that, The file management module includes a file deletion module: The file deletion module is used to generate a deletion instruction in response to the parsed operation instruction, send the deletion instruction to the register module to obtain at least one storage block number corresponding to the file to be deleted, and send the at least one storage block number and the deletion instruction to the storage management module. The register module is used to respond to the deletion command, find the metadata of the file to be deleted, extract at least one storage block number corresponding to the metadata of the file to be deleted, and send the at least one storage block number to the file deletion module. The storage management module is used to, in response to the deletion command, place the storage block corresponding to the at least one storage block number into the idle resource pool.

3. The FPGA-based file system according to claim 1, characterized in that, The file management module also includes a file writing module; The file writing module is used to generate a creation instruction in response to the parsed operation instruction, send the creation instruction to the register module to obtain the number of storage blocks required for the file to be created, and send the number of storage blocks and the creation instruction to the storage management module; The register module is used to allocate new metadata storage space to the file to be created in response to the creation instruction, and to determine the number of storage blocks according to the size of the file to be created and send the number of storage blocks to the file writing module. The storage management module is used to pop the required number of storage blocks from the idle resource pool according to the creation instruction, set the popped storage block sequence number, and store the file to be created based on the popped storage blocks; The file writing module is also used to send the popped storage block number to the register module, so that the register module can write the popped storage block number into the metadata of the file to be created.

4. The FPGA-based file system according to claim 3, characterized in that, The file writing module is further configured to generate a modification instruction in response to the parsed operation instruction, and send the modification instruction to the register module to obtain at least one storage block number corresponding to the file to be modified, and send the modification instruction and the at least one storage block number to the storage management module to extract the file content stored in the corresponding storage block from the storage management module, and modify the obtained file content; The register module is also used to determine the metadata of the file to be modified according to the modification instruction, extract at least one storage block number of the metadata of the file to be modified, and send the extracted at least one storage block number to the write file module in sequence. The storage management module is further configured to extract the corresponding numbered storage block according to the at least one storage block number, and send the stored file content to the write file module.

5. The FPGA-based file system according to claim 1, characterized in that, The file management module also includes a file reading module; The file reading module is used to generate a reading instruction in response to the parsed operation instruction, and send the reading instruction to the register module to extract at least one storage block number corresponding to the file to be read, and send the at least one storage block number to the storage management module to extract the file content stored in the corresponding storage block from the storage management module; The register module is used to determine the metadata of the file to be read according to the read instruction, and extract at least one storage block number corresponding to the metadata of the file to be read.

6. The FPGA-based file system according to claim 1, characterized in that, The register module is implemented using registers or block random access memory within the FPGA and is used to support hardware parallel queries of the metadata.

7. A file management method, characterized in that, The method, applied to a file management module in an FPGA-based file system as described in any one of claims 1-5, comprises: Based on the operation instructions received and parsed by the control instruction parsing module from the external control terminal, internal operation commands are generated. The internal operation commands are sent to the register module and the storage management module, so that the register module and the storage management module can perform the corresponding operations.

8. The file management method according to claim 7, characterized in that, When the operation instruction is a file read operation, the method further includes: A read instruction is sent to the register module, which determines the metadata of the file to be read and obtains at least one storage block number of the file to be read. The file to be read is read from the physical memory according to the at least one storage block number.

9. A data acquisition device, characterized in that, The device includes an FPGA chip and non-volatile memory; The FPGA chip integrates an FPGA-based file system as described in any one of claims 1 to 6; The non-volatile memory is connected to the FPGA chip and is directly controlled by the storage management module of the file system.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program processor executes, it implements the file management method as described in any one of claims 7 to 8.

Images