A storage system and method based on an FPGA-based EXFAT file system

Abstract

The application relates to an FPGA-based EXFAT file system storage system and method, and belongs to the technical field of data storage. The system comprises an FPGA master control board card serving as a master controller and an NVME SSD serving as a storage medium; the FPGA master control board card and the NVME SSD are inserted into a PCIE SWITCH adapter plate; wherein the FPGA master control board card is internally integrated with a MicroBlaze system, an NVME HA, an XDMA and a plurality of hardware function IPs; wherein the plurality of hardware function IPs comprise AXI4 protocol packaging IPs, DMA setting IPs, SQ generator IPs, file creation IPs, FAT table marking refreshing IPs, cluster bitmap marking refreshing IPs, SQ chain table IPs, command issuing IPs and data generator IPs. The system realizes a high-speed, low-delay, low-power-consumption and high-reliability EXFAT file system storage system.

Description

Technical Field

[0001] This invention belongs to the field of data storage technology, and in particular relates to a storage system and method based on the EXFAT file system of FPGA. Background Technology

[0002] A file system is a data structure used by the operating system to organize and manage files on storage devices such as SSDs and HDDs. Common file systems include FAT16, FAT32, NTFS, EXT4, and EXFAT, each with different application scenarios. The FAT family of file systems widely supports Windows and Linux operating systems, but cannot manage single files larger than 4GB. The NTFS file system supports large files, but it was originally designed for mechanical hard drives and cannot fully utilize its performance on NVMe SSDs, and its support under Linux is incomplete. The EXT4 file system offers excellent performance but primarily supports the Linux platform. In contrast, the EXFAT file system combines broad cross-platform support (Windows / Linux) with native support for large files and large-capacity storage media, making it ideal for modern high-speed storage devices such as NVMe SSDs.

[0003] Traditionally, the implementation of the EXFAT file system has primarily relied on a combination of CPU and software drivers, meaning that the EXFAT protocol is parsed and executed through software libraries within embedded systems or the Linux kernel. However, this approach suffers from slow processing speed, poor real-time performance, and high resource consumption. Therefore, how to better manage the EXFAT file system has become an urgent problem to be solved. Summary of the Invention

[0004] In view of the shortcomings of the prior art, the purpose of the invention is to provide a storage system based on the EXFAT file system of FPGA.

[0005] In a first aspect, the present invention proposes a storage system based on an FPGA-based EXFAT file system, comprising: an FPGA main control board as the main controller and an NVMe SSD as the storage medium; the FPGA main control board and the NVMe SSD are inserted into a PCIe switch adapter board; wherein the FPGA main control board integrates: a MicroBlaze system, NVMe HA, XDMA, and multiple hardware function IPs; wherein the MicroBlaze system is used to run a Linux system to execute high-level control logic; wherein the NVMe HA integrates an NVMe IO queue buffer to enable communication between the NVMe host and the NVMe SSD. The SSD's NVMe protocol communication includes multiple hardware function IPs: AXI4 protocol encapsulation IP, DMA setting IP, SQ generator IP, file creation IP, FAT table mark refresh IP, cluster bitmap mark refresh IP, SQ linked list IP, command issuance IP, and data generator IP. The AXI4 protocol encapsulation IP encapsulates the AXI4 protocol, enabling read / write access operations between relevant IPs within the FPGA and DDR4. The DMA setting IP establishes a DMA mapping between RAM data in the local IP module and a specified address in DDR4. The SQ generator IP generates corresponding SQs according to the NVMe HA manual and file system functions, sending them to the NVMe HA via the AXI-STREAM interface. The file creation IP creates a file based on a file creation algorithm upon receiving a file creation command. The FAT table mark refresh IP locally caches and updates the FAT table data in the NVMe SSD. The cluster bitmap mark refresh IP locally caches and updates the cluster bitmap data in the NVMe SSD. The SQ linked list IP stores the required PRPs within the SQ. The LIST is written to a specified address in memory; the command issuing IP is used by the software side to issue file system execution instructions to the logic side; the data generator IP is used to simulate data from external sensors, and the final simulated sensor data is recorded in NVMESSD in text file format; wherein, multiple hardware function IPs work together under the scheduling of the Linux system to jointly complete the formatting, file creation, file writing, file reading, file searching and file deletion operations of the EXFAT file system; wherein, the EXFAT file system includes user data and metadata.

[0006] A second aspect of this invention proposes a storage method for an FPGA-based EXFAT file system, comprising the following steps: After the system is powered on, the Linux system sends an EXFAT formatting command to the NVMe SSD to format the NVMe SSD; after formatting, the Linux side sends a formatting completion flag to the command sending IP; after the logic side reads the formatting completion flag from the command sending IP, the logic side uses the SQ generator IP to read the cluster bitmap data, FAT table data, and root directory data from the NVMe SSD into the cluster bitmap flag refresh IP, FAT table flag refresh IP, and file creation IP for local caching; the Linux system sends file operation commands to the corresponding hardware function IPs, wherein the file operation commands include formatting commands, file creation commands, file writing commands, file reading commands, file searching commands, and file deletion commands; the hardware function IPs, according to the EXFAT... The WIN32 specification calculates and updates cached metadata locally; the DMA setting IP sets DMA-related parameters and notifies the SQ generator via an interrupt, causing it to write the updated metadata into DDR4 memory in the set DMA format; the SQ generator IP concatenates the corresponding NVME command queue according to the write completion signal; NVMEHA sends the NVME command queue to the NVME SSD, causing the NVME SSD to move the updated metadata from the DDR4 memory to the specified sector.

[0007] A third aspect of the present invention provides an electronic device comprising: at least one processor; and a memory communicatively connected to said at least one processor; wherein the memory stores instructions executable by said at least one processor, said instructions being executed by said at least one processor to enable said at least one processor to perform the method described in any one of the second aspects of the present invention.

[0008] A fourth aspect of the present invention provides a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause the computer to perform the method described in any one of the second aspects of the present invention.

[0009] The beneficial effects of this invention are as follows: The FPGA-based EXFAT file system storage system described in this invention utilizes the FPGA's internal hardware function IPs (such as FAT table tag refresh IP, cluster bitmap tag refresh IP, file creation IP, etc.) to directly execute metadata operations (cluster allocation, FAT table update, directory entry calculation), replacing the traditional CPU's serial software processing. Hardware parallel computing capabilities improve the performance of the file system's core operations (formatting, creation, writing, etc.). By fully hardware-izing the core functions of the EXFAT file system, such as metadata management, command queue generation, and DMA control, and leveraging the parallel, low-latency, and reconfigurable characteristics of the FPGA, a storage system with higher speed, lower latency, lower power consumption, and higher reliability than traditional CPU-and-software combined solutions is achieved. Attached Figure Description

[0010] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts. It is obvious that the drawings described below are merely some embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings.

[0011] Figure 1 This is a schematic diagram of a storage system based on an FPGA-based EXFAT file system according to an embodiment of the present invention; Figure 2 This is a flowchart of a storage method for an FPGA-based EXFAT file system according to an embodiment of the present invention; Figure 3 This is a flowchart of a file creation method according to an embodiment of the present invention; Figure 4 This is a flowchart of a file writing method according to an embodiment of the present invention; Figure 5 This is a flowchart of a file reading method according to an embodiment of the present invention; Figure 6 A schematic diagram of the hardware configuration of the EXFAT file system; Figure 7 This is a structural block diagram of an electronic device according to an embodiment of the present invention.

[0012] Figure labels: 1. System power supply; 2. External fan cooling; 3. FPGA board download and debugging cable; 4. PCIe adapter board; 5. NVMe SSD; 6. FPGA board. Detailed Implementation

[0013] To enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. It should be understood that these descriptions are merely exemplary and are not intended to limit the scope of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0014] Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts disclosed in this invention.

[0015] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicating orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance. The terms "installed," "connected," and "linked" should be interpreted broadly; for example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal communication of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0016] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of methods and systems consistent with some aspects of the invention as detailed in the appended claims.

[0017] Currently, file systems are categorized into FAT16, FAT32, NTFS, EXT4, and EXFAT, each with different application scenarios. FAT supports Linux / Windows operating systems but not files larger than 4GB. NTFS supports Windows / Linux (Linux with 3party tools) and large-capacity data storage, but it's designed for mechanical hard drives and not suitable for NVMe SSDs. EXT4 only supports Linux and large-capacity data storage. EXFAT supports both Windows / Linux, large-capacity data storage, and NVMe SSDs. Considering these factors and our company's storage products, for creating a file system for large amounts of raw data on NVMe SSDs or for storing large amounts of high-speed data, we chose the EXFAT file system.

[0018] Secondly, for most NVME storage products on the market, the EXFAT file system is traditionally implemented using a CPU + software driver solution (EXFAT is parsed by a software library in the Linux kernel or embedded system). This results in certain defects in the file system management: (1) slow processing speed. ExFAT metadata operations (such as cluster allocation, directory traversal, and FAT table updates) involve a large amount of random I / O and non-contiguous memory access, and the design architecture of general-purpose processor CPUs is difficult to efficiently handle parallel tasks; (2) poor real-time performance. The software implementation relies on the operating system scheduling, which cannot meet the strict requirements of deterministic latency for industrial control, vehicle systems, etc.; (3) high resource consumption. The complex logic of ExFAT (such as log function and error recovery) requires a large amount of RAM / Flash resources, which is not friendly to low-power MCUs (such as ARM Cortex-M series).

[0019] Therefore, the present invention proposes a storage system, method and related device for an FPGA-based EXFAT file system. Specifically, the storage system, method and related device for an FPGA-based EXFAT file system according to embodiments of the present invention are described below with reference to the accompanying drawings.

[0020] Figure 1 This is a schematic diagram of a storage system based on an FPGA-based EXFAT file system according to an embodiment of the present invention. Figure 1 As shown, the storage system of the FPGA-based EXFAT file system includes: The FPGA main control board 110 serves as the main controller and the NVMe SSD 120 serves as the storage medium; the FPGA main control board 110 and the NVMe SSD 120 are inserted into the PCIe Switch adapter board 130.

[0021] The FPGA main control board 110 integrates the MicroBlaze system, NVME HA, XDMA, and multiple hardware function IPs.

[0022] The MicroBlaze system is used to run a Linux system to execute high-level control logic.

[0023] Among them, NVME HA integrates an NVME IO queue buffer to enable NVME protocol communication between the NVME host and the NVME SSD 120.

[0024] Among them, several hardware function IPs include: AXI4 protocol encapsulation IP, DMA setting IP, SQ generator IP, file creation IP, FAT table mark refresh IP, cluster bitmap mark refresh IP, SQ linked list IP, command issuance IP, and data generator IP.

[0025] Among them, the AXI4 protocol encapsulation IP is used to encapsulate the AXI4 protocol, enabling read and write access operations of the AXI4 protocol between the relevant IP inside the FPGA and DDR4.

[0026] The DMA setting IP is used to establish a DMA mapping relationship between RAM data in the local IP module and a specified address in DDR4.

[0027] The SQ generator IP is used to generate corresponding SQs according to the file system functions in the NVME HA manual and send them to NVME HA in the form of an AXI-STREAM interface.

[0028] The file creation IP is used to create a file based on the file creation algorithm when a file creation command is received.

[0029] The FAT table flag refresh IP is used for local caching and updating of FAT table data in the NVMe SSD 120.

[0030] Among them, the cluster bitmap marker refresh IP is used for local caching and updating of cluster bitmap data in the NVMe SSD 120; Among them, the SQ linked list IP is used to write the required PRP LIST in SQ to a specified address in memory.

[0031] Among them, the command-issuing IP is used by the software side to issue file system execution instructions to the logical side.

[0032] The data generator IP is used to simulate data from external sensors, and the simulated external sensor data is ultimately recorded into the NVMe SSD 120 in text file format.

[0033] Multiple hardware function IPs work together under the scheduling of the Linux system to complete the formatting, file creation, file writing, file reading, file searching and file deletion operations of the EXFAT file system.

[0034] The EXFAT file system includes user data and metadata.

[0035] In other words, multiple hardware functional IPs work collaboratively under the scheduling of the Linux system to complete the formatting, file creation, file writing, file reading, file searching, and file deletion operations of the EXFAT file system. The EXFAT file system includes user data and metadata, with the metadata including the boot sector DBR, FAT table, cluster bitmap, uppercase character conversion table, root directory, and user file directory entries.

[0036] In embodiments of the present invention, the cluster bitmap marker refresh IP (i.e., BITMAP_BRAM), FAT table marker refresh IP (i.e., FAT_BRAM), and file creation IP (i.e., CREATFILE_IP) all include local RAM (i.e., internal BRAM). After formatting the EXFAT file system, the cluster bitmap data, FAT table data, and root directory data in the NVMe SSD are read into the local RAM for caching by checking the formatting completion flag bit (i.e., EXFAT_FLAG_IP) in the command issuance IP. All subsequent file operations (such as cluster allocation, FAT table entry updates, and directory entry modifications) are performed directly in the local RAM. Only at the end of the operation is the updated data written back to DDR4 memory via DMA, and finally moved back to the flash memory by the NVMe SSD. This design significantly reduces random small data transfers on the PCIe bus, improving overall performance. By limiting the FAT table, cluster bitmap, and root directory data to be loaded into the FPGA's internal BRAM (local RAM) for caching, all subsequent updates are performed locally, with only the data being written back to DDR4 via DMA at the end of the operation. This significantly reduces the number of random PCIe accesses for small data volumes between the FPGA and the NVMe SSD, improving the efficiency of metadata updates.

[0037] In an embodiment of the present invention, the file creation IP includes: a RAM initialization unit, a file information extraction unit, a file creation command receiving unit, a file creation filename ASCII conversion unit, a filename HASH calculation unit, a directory entry checksum calculation unit, a directory entry concatenation unit, a dual-port RAM operation unit, and a file creation execution unit.

[0038] The ram initialization unit instantiates 4KB dual-port ram internally. It is mapped to the 4KB space in memory starting at address 0x7001C000 and the sector where the root directory of the NVMe SSD is located using a rolling design. After the formatting operation is performed, the local memory unit must be refreshed first, and then the memory and the sector where the root directory of the NVMe SSD are located will be updated.

[0039] The file information extraction unit extracts the starting cluster number and file size of the new file when executing the file creation command. This helps determine the starting sector location for data write-to-disk and the file size at which the data is written. Simultaneously, the data generator module, used for data verification, determines the number of files by dividing the total collected data by the size of a single file and compares this number with the number of files recorded in the NVMe SSD to check for consistency.

[0040] The file creation command receiving function unit internally instantiates the AXI-LITE interface to receive file creation command data sent from the MicroBlaze side.

[0041] The file creation ASCII conversion unit converts the filename. Since the EXFAT WIN32 specification's directory entry filename hash algorithm only supports uppercase ASICC, the user filename ASICC code is converted from lowercase to uppercase. Specifically, according to the ASCII table, the ASCII value of the lowercase English letter 'az' is 0x610x7A, and the ASCII value of the uppercase English letter 'AZ' is 0x410x5A, a difference of 0x20. When the byte corresponding to the input filename register is the ASCII value of a lowercase English letter, 0x20 is subtracted before being assigned to the converted filename register.

[0042] The filename hash calculation unit is used to calculate the hash value of the user's filename according to the EXFAT WIN32 specification. This involves converting the ASCII code of the user's filename from lowercase to uppercase and then expanding it before participating in the calculation. Specifically, before performing the calculation, this unit converts the ASCII code of the user's filename from lowercase to uppercase, expands it to 16 bits (each ASCII character corresponds to two bytes), and finally calculates the hash value based on the algorithm. Specifically, the ASICC value of the user-input filename is first expanded, because in the UPCASE, one ASICC value corresponds to two bytes in the hash calculation. Secondly, the ASICC value of the input user filename needs to be converted from lowercase to uppercase. This is because, according to the hash algorithm, the filenames involved in the calculation are mapped to UPCASE only supporting uppercase English letters in the ASICC value. Specifically, according to the ASICC table, the ASICC value for lowercase letters 'az' is 0x61-0x7A, and the ASICC value for uppercase letters 'AZ' is 0x41-0x5A, a difference of 0x20. Therefore, when the byte corresponding to the input filename register is a lowercase English letter in the ASICC value, 0x20 is subtracted, and the result is assigned to the converted filename ASICC register, expanded, and then output. In other cases, it is directly expanded and then output.

[0043] The directory entry checksum calculation unit is used to check and calculate the entire directory entry of the main directory entry and the subordinate directory entries of the file according to the EXFAT WIN32 specification. The number of subordinate directory entries changes with the length of the file name. This unit can dynamically adapt to different lengths and complete the checksum calculation based on the algorithm.

[0044] The directory entry concatenation unit is used to concatenate the calculated directory entries. This involves hardware-concatenating the calculated directory entries (including fields such as filename hash, checksum, file attributes, creation / modification time, starting cluster number, and file size) to form a 32-byte directory entry structure conforming to the EXFAT specification.

[0045] The dual-port RAM operation unit instantiates 4KB of dual-port RAM internally within the IP, with a read / write data width of 256 bits and a depth of 128. It is used to store EXFAT file system directory entries. After Linux completes the EXFAT file system formatting operation on the NVMe SSD, the initial root directory entry in the NVMe SSD is written to addresses 0-3 in the local IP RAM. Subsequent file creation directory entries are concatenated starting from address 4 and using a rolling design to establish a mapping relationship with the 4KB space in memory starting at address 0x7001C000 and the sector where the root directory is located in the NVMe SSD.

[0046] In the file creation execution unit, after the above logical functions are executed, the IP, upon receiving the file creation instruction, imports the 4KB directory entry in the RAM into the 4KB space starting at address 0x7001C000 in memory. At the same time, it sends a DMA interrupt to the SQ generator, which then writes the directory entry to the sector where the NVME SSD directory is located at the corresponding address in memory.

[0047] In embodiments of the present invention, the SQ generator IP is specifically used for: receiving a flag signal from the command issuing IP or a DMA completion signal from the DMA setting IP, and concatenating a read command queue or a write command queue; specifically including concatenating an EXFAT file system formatting SQ, a file creation SQ, and a file write SQ. The concatenated command queue is sent to the NVME HA via the AXI-STREAM interface to trigger the NVME SSD to perform data transfer. CQ information fed back by the NVME HA is received to determine when to concatenate the relevant SQ.

[0048] The flag signals include, but are not limited to, formatting completion flags and file creation trigger flags.

[0049] Based on the aforementioned flag signals and the current file operation type, a read command queue or a write command queue is constructed. The command queue contains information required by the NVME protocol, such as the opcode, namespace identifier, data block address, data length, and PRP entry.

[0050] This triggers the NVMe SSD to perform corresponding data transfer operations, such as reading data from DDR4 memory and writing it to the SSD, or reading data from the SSD and writing it to DDR4 memory.

[0051] The FPGA-based EXFAT file system storage system according to embodiments of the present invention utilizes the internal hardware function IPs of the FPGA (such as FAT table tag refresh IP, cluster bitmap tag refresh IP, file creation IP, etc.) to directly execute metadata operations (cluster allocation, FAT table update, directory entry calculation), replacing the traditional serial software processing of the CPU. Hardware parallel computing capabilities improve the performance of core file system operations (formatting, creation, writing, etc.). By fully hardware-izing the core functions of the EXFAT file system, such as metadata management, command queue generation, and DMA control, and leveraging the parallel, low-latency, and reconfigurable characteristics of the FPGA, a storage system with higher speed, lower latency, lower power consumption, and higher reliability than traditional CPU-and-software combined solutions is achieved.

[0052] Figure 2 This is a flowchart of a storage method for an FPGA-based EXFAT file system according to an embodiment of the present invention, as shown below. Figure 2As shown, the storage method of this FPGA-based EXFAT file system includes: After the S210 system is powered on, the Linux system sends an EXFAT formatting command to the NVMe SSD to format the NVMe SSD.

[0053] After S220 is formatted, the Linux side sends a formatting completion flag to the command sending IP.

[0054] In other words, after formatting is complete, the Linux side sends a formatting completion flag to the corresponding register of the command-sending IP address.

[0055] After the S230 logic side reads the command issuance IP formatting completion flag, it reads the corresponding parameters of the DBR sector into the SQ generator. The SQ generator IP then calculates the EXFAT file system data structure location information based on the read DBR sector parameters according to the EXFAT WIN32 specification and concatenates the corresponding function's read SQ. The cluster bitmap data, FAT table data, and root directory data in the NVME SSD are read into the cluster bitmap mark refresh IP, FAT table mark refresh IP, and file creation IP for local caching, respectively.

[0056] The S240 Linux system sends file operation commands to the corresponding hardware function IPs. These file operation commands include formatting commands, file creation commands, file writing commands, file reading commands, file searching commands, and file deletion commands.

[0057] The S250 hardware function IP calculates and updates cached metadata locally according to the EXFAT WIN32 specification.

[0058] In embodiments of the present invention, the hardware function IP performs hardware-level calculations and updates on cached metadata locally according to the EXFAT WIN32 specification. For example, the cluster bitmap marker refresh IP marks the occupancy status of free clusters in the local BRAM, the FAT table marker refresh IP updates the FAT table entries in the local BRAM, and the file creation IP calculates the file name hash and directory entry checksum, etc.

[0059] S260, DMA setting IP writes the updated metadata to DDR4 memory in the set DMA format.

[0060] In other words, the corresponding DMA setting IP initiates DMA transfer according to the set DMA parameters, and writes the updated metadata, such as the new cluster bitmap, the modified FAT table entries, and the newly created file directory entries, from the local RAM of each IP to the specified address in DDR4 memory.

[0061] S270, the SQ generator IP concatenates the corresponding NVME command queue according to the corresponding DMA interrupt signal.

[0062] In other words, the SQ generator IP splices the corresponding NVME command queue (i.e., write SQ) according to the DMA interrupt signal issued by the DMA setting IP.

[0063] S280, NVME HA sends the NVMe command queue to the NVME SSD, enabling the NVME SSD to move updated metadata from DDR4 memory to the specified sector.

[0064] In other words, NVMe HA sends the NVMe command queue to the NVMe SSD, causing the NVMe SSD to move the updated metadata from DDR4 memory to a specified sector of its flash media. This completes one file storage operation.

[0065] In this embodiment of the invention, since the formatting operation of the EXFAT file system does not have high speed requirements, and it is relatively complex to implement arbitrary capacity formatting by FPGA, the final solution is to implement it on the Linux side. The Linux kernel contains the EXFAT file system driver, which can be operated by command line only.

[0066] Figure 3 This is a flowchart of a file creation method according to an embodiment of the present invention, such as... Figure 3 As shown, the file creation methods include: S310, the file creation IP receives the filename and file attributes from the Linux system.

[0067] In other words, the file creation IP (i.e., CREATFILE_IP) receives the filename and file attributes from the Linux system, and performs ASICC conversion and expansion of the filename. For example, the filename is "test.txt" and the attribute is archive file.

[0068] S320, the file creation IP performs file name hash value calculation on the ASICC-converted and expanded file name according to the EXFAT WIN32 specification, and then performs verification and calculation on the entire directory entry.

[0069] In other words, the file creation IP calculates the hash value of the filename according to the EXFAT WIN32 specification, and performs a checksum calculation on the entire directory entry (i.e., the main directory entry + the subdirectory entries). For the specific calculation process, please refer to the filename hash calculation unit and directory entry checksum calculation unit in the above embodiment.

[0070] S330, the file creation IP will concatenate the calculated entire directory entry.

[0071] In other words, the file creation IP performs hardware concatenation of the calculated directory entry to form 32-byte directory entry data conforming to the EXFAT format.

[0072] S340, the cluster bitmap marker refreshes the IP marking of free clusters and updates the cached cluster bitmap locally. Finally, the marked free clusters are updated to the sector where the cluster bitmap is located in the NVMe SSD, and cluster numbers are assigned to newly created files.

[0073] In other words, after formatting, the cluster bitmap flag refresh IP reads the cluster bitmap sector data from the NVMe SSD into the local IP. After finding a free cluster number, such as FF 7F, it indicates that cluster 17 is free (because the cluster bitmap starts counting from cluster 2, this cluster is marked as occupied as FF FF, indicating that the starting cluster for new files is cluster 17). This updates the cluster bitmap in the local RAM. After the update is complete, the RAM interface signal is finally sent to the DMA setting module.

[0074] S350, DMA setting IP writes the updated root directory data and cluster bitmap data to DDR4 memory in the set DMA format.

[0075] In other words, the DMA setting IP (i.e., UIFDMA_DBUF) writes the updated root directory data (containing the directory entry of the new file) and the updated cluster bitmap data (the cluster number must correspond to the starting cluster in the new file directory entry 2) to a specified address in DDR4 memory.

[0076] The S360 SQ generator IP moves root directory data and cluster bitmap data from DDR4 memory to the NVMe SSD.

[0077] In other words, the SQ generator IP (i.e., SQ_GEN_AUTO) generates a write SQ, which moves the root directory data and cluster bitmap data in DDR4 memory to the root directory physical sector and cluster bitmap physical sector of the NVMe SSD. At this point, file creation is complete.

[0078] Let's take the file creation function of the EXFAT file system as an example to illustrate how the various IPs work together: Using software formatting of the EXFAT file system as an example, after the MB kernel starts, the Linux side formats the NVMe SSD (any capacity). After formatting, register 0 of EXFAT_FLAG_IP (i.e., the flag command issuance IP) is written to 1. FAT_BRAM (i.e., the FAT table mark refresh IP), BITMAP_BRAM (i.e., the cluster bitmap mark refresh IP), and CREATFILE_IP (i.e., the file creation IP), upon detecting this flag, refresh their internal RAM. After refreshing, the flag bits are ANDed (VECTOR LOGIC) and output to the SQ_GEN_AUTO (i.e., the SQ generator IP) module. This module generates an SQ based on this flag bit, setting the starting sector of the NVMe SSD (i.e., the DMA setting IP) to the given NVMe SSD. (This value is fixed for the SSD) Data is read into memory address 0x70000000. Based on this SQ, a CQ is generated. The SQ_GEN_AUTO module generates a read DBR flag request and sends it to the UIFDMA_DBUF IP. After the IP is encapsulated via the AXI4 protocol, UIFDMA reads the DBR BPB parameter area data from the NVMe SSD at memory address 0x70000000 into the local SQ_GEN_AUTO module. The SQ_GEN_AUTO module calculates the DBR BPB parameter area data according to the EXFAT WIN32 specification, determines the FAT table, cluster bitmap, and root directory sector in the EXFAT file system, and then sends the corresponding SQ to read the NVMe SSD. The corresponding data structures in the SSD are read into the specified memory address. For now, the FAT table address is set to 0x71002000, the cluster bitmap start address to 0x71004000, and the directory entry address to 0x7001C000. Similarly, based on the CQ returned by the corresponding SQ, the SQ_GEN_AUTO module generates a corresponding read request to the corresponding UIFDMA_DBUF IP. After being encapsulated by the corresponding AXI4 protocol, the UIFDMA reads the FAT table, cluster bitmap, and root directory data from memory into the local SQ_GEN_AUTO module and updates them to the corresponding FAT_BRAM (FAT table mark refresh IP), BITMAP_BRAM (cluster bitmap mark refresh IP), and CREATFILE_IP (file creation IP) via the write-to-RAM interface. When the user sends a file creation command, CREATFILE_IP internally calculates and concatenates the user file directory entry according to an algorithm. After concatenation, the internal read-to-RAM interface data (user data) is used as the write-to-UIFDMA_DBUF. The IP internal FIFO interface data, the AXI4 interface protocol enable signal enables the read FIFO interface, and the AXI4 interface output data is the read FIFO interface data.The UIFDMA_DBUF IP outputs AXI4 interface protocol data. After being encapsulated by the AXI4 protocol, the IP UIFDMA writes the user file directory entry to memory address 0x7001C000. Upon completion, it notifies the SQ_GEN_AUTO (i.e., the SQ generator IP) module to generate an SQ, sending the data at the directory entry address in memory to the sector containing the directory entry in the NVMe SSD. This completes the file creation operation.

[0079] The EXFAT file system includes user data and metadata. For NVMe SSDs, the data written to the disk can be called user data or raw data, which does not contain any file system and is not recognized by the Windows operating system. Metadata refers to information such as the boot sector DBR, FAT table, cluster bitmap, uppercase character conversion table, and root directory. The operation and creation of the EXFAT file system ultimately utilizes the FPGA to establish a certain association between the aforementioned metadata and the large amount of raw data in the NVMe SSD using the EXFAT WIN32 specification. (For example, filename, extension, attributes, creation / modification time, and file size all belong to the user file directory entry part and are considered metadata).

[0080] Specifically, A) After the system powers on, the Linux side initiates a read command to read the starting sector data of the NVMe SSD and determine the NVMe SSD file system status. The data stream is: EXFAT_FLAG_IP-SQ_GEN_AUTO-NVME HA-XDMA-MIG, which completes the storage of the starting physical sector data of the NVMe SSD into address 0x70000000 in DDR4. Then, SQ_GEN_AUTO-UIFDMA_DBUF(R_DBR)-UIFDMA-MIG reads the DBR starting sector address data from DDR4 into the SQ_GEN_AUTO module to determine the file system status of the NVMe SSD. If it is an EXFAT file system, it determines the corresponding address of the internal data structure of the file system; if it is not an EXFAT file system, it initiates a formatting command. B. For non-Exfat file system Linux systems, the boot formatting command writes the corresponding register flags after formatting. The file creation IP, cluster bitmap marker refresh IP, and FAT table marker refresh IP modules refresh the internal RAM after detecting the flag. After refreshing, the output signals are ANDed and output to the SQ_GEN_AUTO module. C. The SQ_GEN_AUTO module performs the following actions internally: c1: Concatenate and read SQ (source: DBR start sector in NVMESSD, destination: memory address 0x70000000). c2: Based on the CQ returned by the DBR SQ, a flag is generated to start the DMA setting IP UIFDMA_DBUF IP. After setting the DMA parameters internally, the IP is encapsulated via the AXI4 protocol and sent to memory. Data at address 0x70000000 in memory is read into the local module. In this module, the location of the remaining data structures of the EXFAT file system in the NVME SSD is determined according to the BPB parameter of the DBR start sector in the NVME SSD. File creation mainly involves the sector where the root directory is located (calculated according to the algorithm) and the sector where the cluster bitmap is located (directly read from the address in the DBR start sector). The data flow is the same as in A. D: After determining the sector where the cluster bitmap is located, similar to c, the data of the sector where the BITMAP is located in the NVME SSD is read into the specified address in DDR4 and finally written into the internal RAM of the cluster bitmap flag refresh IP module. After determining the sector where the root directory is located, similar to C, the data of the sector where the root directory is located in the NVME SSD is read into the specified address in DDR4 and finally written into the internal RAM of the file creation IP module.E. The Linux side sends a file creation command to the file creation IP module, and simultaneously starts the cluster bitmap marking and refreshing IP module. This module internally determines the availability of free clusters, further marks clusters based on the newly created file, and then writes the updated cluster bitmap to the cluster bitmap address in DDR4 via the DMA setting module UIFDMA_DBUF and the AXI4 protocol encapsulation module UIFDMA. (It should be noted that creating a new folder is different from creating a new file. According to the EXFAT WIN32 specification, when creating a new folder, its cluster number and size can be specified—usually one cluster. However, when creating a new file, the starting cluster number and file size of the directory entry are both 0, and will be updated in real time according to the size of the file. Currently, it has been implemented to specify the starting cluster and file size of the newly created text file, and will be improved later.) The file creation IP module internally calculates the relevant parameters of the user file directory entry according to the EXFAT WIN32 specification. After the calculation is completed, the user file directory entry is concatenated. After concatenation, the user file directory entry is concatenated into the original directory entry in the NVMe SSD in RAM, and then the newly created file directory is written to the specified address in memory via DMA setting IP. F. After the data of the cluster bitmap UIFDMA module and the root directory UIFDMA module are written into DDR4, a completion signal is sent to the SQ generator IP module. This module further concatenates the corresponding SQ to enable the NVMe SSD to move the cluster bitmap and root directory address data from DDR4 to the specified sector in the NVMe SSD via XDMA, thus completing the file creation operation.

[0081] If, after completing operation A above, it is determined that the file system is an EXFAT file system (the location of the internal data structure of the EXFAT file system has been determined), the process for creating a new file should be as follows: A1, the LINUX side sends a file creation command to the file creation IP and starts the cluster bitmap marker refresh module, and then repeats steps E and F above.

[0082] In embodiments of the present invention, file deletion is the inverse operation of file creation. Specifically, after the system receives a file deletion command, the file creation IP (CREATFILE_IP) locates the directory entry of the file to be deleted and marks it as "deleted" (usually by changing the first byte of the directory entry to 0xE5). Simultaneously, the cluster bitmap mark refresh IP (i.e., BITMAP_BRAM) marks all clusters occupied by the file as free in the local cluster bitmap, and the FAT table mark refresh IP (i.e., FAT_BRAM) clears the corresponding FAT table entries. Finally, the updated cluster bitmap, FAT table, and root directory data are written back to the NVMe SSD via the DMA setting IP and SQ generator IP.

[0083] Figure 4 This is a flowchart of a file writing method according to an embodiment of the present invention, such as... Figure 4 As shown, the file writing methods include: S410, the data generator IP generates data to be written and writes it to DDR4 memory.

[0084] In an embodiment of the invention, the data generator IP (i.e., DAT_GEN) generates data to be written (e.g., 128KB of test data) and writes the data to a specified address in the DDR4 memory (e.g., 0x6000_0000) via the AXI-Full Master interface. In practical applications, high-speed data can also be directly written to DDR4 via an external sensor interface.

[0085] S420, the file creation IP determines whether the amount of data in DDR4 memory exceeds the size of the entire cluster.

[0086] In other words, the file creation IP (CREATFILE_IP) determines whether the amount of data in DDR4 memory exceeds the size of a cluster, where the cluster size is determined by the BPB parameter in the DBR, for example, 128KB per cluster.

[0087] S430: If the data volume is less than or equal to one cluster, the cluster bitmap marking refresh IP searches for a free cluster and marks it in the local cache. The file creation IP updates the starting cluster number and file size in the directory entry. Finally, the marked free cluster is updated to the sector where the cluster bitmap is located in the NVMe SSD, and the updated directory entry is rewritten to the sector where the NVMe SSD directory entry is located.

[0088] In an embodiment of the present invention, if the data volume is less than or equal to one cluster, the Cluster Bitmap Marking Refresh IP (i.e., BITMAP_BRAM) searches for a free cluster in its local cache (for example, if the cluster bitmap is read as FF 7F - indicating that cluster 17 is free - FF FF - and then marks cluster 17) and marks the cluster as occupied in the local cache; the File Creation IP updates the directory entry of the corresponding file in its internal RAM, updates the starting cluster number to the found free cluster number (if it is a new file) or increments the file size (if it is an append write), and recalculates the directory entry checksum; subsequently, the updated cluster bitmap data and directory entry data are written to DDR4 by the DMA Setting IP, and then transported to the NVMe SSD by the SQ Generator IP.

[0089] S440, if the data volume is greater than one cluster, the cluster bitmap marker refresh IP searches for contiguous or non-contiguous clusters, and if the clusters are not contiguous, the FAT table marker refresh IP is triggered to update the FAT table data in the local cache.

[0090] In embodiments of the present invention, if the data volume is greater than one cluster, the Cluster Bitmap Mark Refresh IP searches for contiguous or non-contiguous free clusters. If the next free cluster is contiguous with the current cluster in terms of physical address, there is no need to update the FAT table; if the next free cluster is not contiguous with the current cluster, the FAT table mark refresh IP (i.e., FAT_BRAM) is triggered to update the FAT table entries in the local cache, pointing the FAT entry of the current cluster to the next cluster, and setting the FAT entry of the last cluster as the end-of-file marker; the file creation IP updates the starting cluster number and file size in the directory entries according to all allocated clusters.

[0091] S450, DMA setting IP writes the updated cluster bitmap data, FAT table data, and directory entry data to DDR4 memory in the set DMA format.

[0092] The S460 SQ generator IP moves cluster bitmap data, FAT table data, and directory entry data from DDR4 memory to the NVMe SSD.

[0093] Specifically, the FPGA internal file writing module (currently, the data written to the file system is first generated by the FPGA's internal DATA_GEN (128KB)) performs the following file writing process: a) After the system powers on, the Linux side initiates a read command. According to the above functional module description, the logic side reads the data structure at the specified location in the NVME SSD into the internal RAM of the file creation IP module (root directory), cluster bitmap marking refresh IP module (cluster bitmap), and FAT table marking refresh IP module, while simultaneously performing local backup marking. b) The DATA_GEN data generator is started, and 128KB of data is written to the specified address in DDR4 through the AXI_FULL_MASTER interface. The data volume is then sent to the file creation IP module. This module compares the data volume with the entire cluster size to determine if it exceeds one cluster size. The result is then sent to the cluster bitmap marking and refreshing IP module. Upon receiving this data, if the data is less than one cluster size, the BITMAP_MARK_IP module marks the found free cluster number and sends it to the CREATFILE_IP module (for recalculating the checksum) and the SQ generator IP module (for concatenating the write data SQ). The file creation IP module updates the directory entry with the marked free cluster number and the file size to be written, recalculates the directory entry checksum, and then rewrites it to the newly created file address in the root directory of DDR4 via DMA setting IP (W_GML) + UIFDMA. Simultaneously, the updated cluster bitmap is written to the corresponding address in the DDR4 cluster bitmap via DMA setting IP (W_BITMAP) + UIFDMA. c. Trigger the SQ generator IP module. This module constructs an SQ based on the cluster number of the file to be written and the data address in DDR4 (currently tentatively set to 0x7100_0000) to move the data in DDR4, and moves the directory entry to the NVMe SSD based on the SQ created in the previous file. This completes the writing of a file with less than one cluster of data.

[0094] When the data exceeds the size of a cluster, after the cluster bitmap marking and refreshing IP module completes marking a cluster (data already occupies a cluster), the BITMAP_MARK_IP module still needs to find the next writable cluster. If the next cluster is contiguous with the current cluster, this module outputs data that does not modify the FAT table information to the FAT table marking and refreshing IP module, meaning there is no need to update the FAT table data structure in the NVMe SSD. Afterwards, it marks free clusters until the data is complete and then updates the cluster bitmap to the specified address in DDR4 via DMA setting IP (W_BITMAP) + UIFDMA. The file creation IP module performs the same operation, simultaneously triggering the SQ generator IP module to move the directory entries, cluster bitmap, and data to the specified sector of the NVMe SSD. If the next cluster is not contiguous with the current cluster, the cluster bitmap marking and refreshing IP module outputs data that needs to modify the FAT table information to the FAT table marking and refreshing IP module. Upon receiving this information, this module updates the FAT table entries and finally synchronizes them to the specified address in the DDR4 FAT table. Then, the same process is executed to move the cluster bitmap, root directory, and data to the specified sector in the NVMe SSD.

[0095] Figure 5 This is a flowchart of a file reading method according to an embodiment of the present invention, such as... Figure 4 As shown, file reading methods include: S510, find the starting cluster number of the file through the directory entry.

[0096] In an embodiment of the present invention, 1) when a user or operating system needs to access a file, the system first locates the directory where the file is located. 2) In the data area of ​​the directory, the system searches for (or locates) a directory entry named report.txt. 3) Once the directory entry report.txt is found, the system reads three important pieces of information from it: file size (how many bytes of data the file contains), starting cluster number (the number of the first cluster on the disk where the file data is stored. This cluster number is the starting point for searching the file data), and file fragmentation flag.

[0097] S520 uses file fragmentation flags to determine whether files are contiguous.

[0098] In an embodiment of the present invention, 1) the number of complete clusters theoretically required for the file is calculated based on the file size. 2) The starting cluster number (StartCluster) is obtained. 3) The status of the N consecutive clusters (N equals the number of clusters required by the file) starting from the starting cluster number StartCluster is checked in the FAT table. 4) If these N clusters are consecutive in the FAT table (i.e., FAT[StartCluster] = StartCluster+1, FAT[StartCluster+1] = StartCluster+2, ..., FAT[StartCluster+N-1] = file end marker), and these N clusters are also consecutive on the physical disk (this is usually implied by the continuity of FAT table entries, but physical continuity also needs to be combined with cluster mapping), then the file is stored contiguously. 5) If the above conditions are not met (for example, FAT[StartCluster] does not point to StartCluster+1, but to another non-adjacent cluster number), then the file must be non-contiguous (fragmented).

[0099] S530: If the files are consecutive, they can be read directly in sequence according to the starting cluster number.

[0100] In an embodiment of the present invention, 1) the physical sector address of the starting cluster on the disk is calculated based on the starting cluster number StartCluster (this requires knowing the starting sector of the data area and the number of sectors per cluster). 2) The total number of sectors to be read is calculated based on the file size. 3) The disk drive controller (SSD) can then read all the required sector data sequentially, starting from the sector corresponding to the starting cluster, all at once.

[0101] S540: If the files are not contiguous, the cluster number of the next data item needs to be found based on the FAT table.

[0102] In an embodiment of the present invention, 1) the system reads the data of the first cluster starting from the starting cluster number StartCluster obtained from the directory entry. 2) After reading, the system searches the FAT table and finds the entry with the index StartCluster. 3) The value of this FAT entry (NextCluster) indicates the cluster number of the next data cluster of the file. 4) The system calculates the physical sector address of the cluster based on the cluster number (NextCluster) and then reads the data of that cluster. 5) After reading, the system searches the FAT table again and finds the entry with the index NextCluster, obtaining the next cluster number NextCluster2. 6) This process is repeated (read cluster -> search FAT -> obtain next cluster number -> read cluster...) until the value of the read FAT entry is a file end marker (such as 0xFFFF for FAT16), indicating that this is the last cluster of the file.

[0103] In an embodiment of the present invention, the file search method includes: the Linux system distributing the filename and path to be searched; the file creation IP is located in the root directory data cached locally, and the directory entry of the target file is quickly located by comparing the filename hash and verifying the directory entry; if found, information such as file attributes, starting cluster number, and file size is returned; if not found, a search failure flag is returned.

[0104] Before performing file creation, file writing, and other operations, it is necessary to determine the location of the EXFAT file system data structure in the NVMe SSD (such as the starting sector of the FAT table, the starting sector of the cluster bitmap, the starting cluster number of the root directory, etc.). In one embodiment of the present invention, the location information of the EXFAT file system data structure is calculated, wherein: after the Linux system formats the NVMe SSD, it sets the formatting completion flag bit of the IP command, triggering the SQ generator IP to generate a DBR read command queue and send it to the NVMe HA. The SQ execution reads the DBR starting sector data of the NVMe SSD into the DDR4 memory at address 0x7000_0000; the SQ generator IP reads the DBR starting sector data in the DDR4 memory into the SQ generator IP through the DMA setting IP based on the CQ information fed back by the DBR read SQ; the SQ generator IP parses the DBR starting sector data and determines the location information of the EXFAT file system data structure in the NVMe SSD according to the EXFAT WIN32 algorithm. The data structure location information includes the starting sector of the FAT table, the starting sector of the cluster bitmap, and the starting sector of the root directory.

[0105] The BPB parameters include, but are not limited to, the number of bytes per sector, the number of sectors per cluster, the number of reserved sectors, the number of FAT tables, and the number of sectors occupied by the FAT tables. In other words, the SQ generator IP parses the DBR start sector data, extracts the BPB parameters, and determines the location information of key data structures in the NVMe SSD's EXFAT file system, such as the start sector of the FAT table, the start sector of the cluster bitmap, and the start cluster number of the root directory, according to the calculation formula in the EXFAT WIN32 specification. This information is stored in internal registers for subsequent file operations.

[0106] Based on the above scheme, the following is achieved: (1) As a reconfigurable hardware, FPGA's parallel computing, low latency, and flexible customization characteristics are highly compatible with the high performance requirements of ExFAT. Its powerful parallel processing capability matches the complex operations of ExFAT, such as the core operations of ExFAT (such as FAT table reading and writing, directory tree traversal, and cluster bitmap management). (2) Low latency and determinism meet the real-time requirements. For operations on storage media, FPGA can directly connect to storage media (such as NAND Flash and UFS controllers) through hardware direct connection architecture (bypassing the operating system kernel) and customized bus protocols (such as AXI4-Stream and CHI), avoiding the context switching overhead of the software stack and achieving deterministic low latency (typical value <10μs). (3) Customization requirements, adapting to diverse storage interfaces and scenarios, with the following advantages: interface adaptation (such as USB 3.2 Gen2x2, PCIe 4.0, UFS 3.1); function tailoring, retaining core functions (such as cluster allocation, directory management) and eliminating redundant modules (such as log function) according to requirements, reducing resource consumption; algorithm acceleration, integrating dedicated hardware accelerators (such as CRC32 check, AES encryption, ECC error correction) to improve data processing efficiency; high reliability, improving the fault tolerance of the storage system through redundant design (such as dual FAT table mirroring, hot standby cluster management) or self-healing logic (such as bad block replacement strategy). (4) Low power consumption and cost optimization, balancing performance and energy efficiency. For battery-powered devices (such as drones, portable medical devices), power consumption is a key indicator. The hardware-level low power consumption design of FPGA (such as dynamic voltage frequency adjustment DVFS, gated clock) can dynamically adjust resource usage for typical ExFAT workloads (such as low power mode when idle, burst high performance during read and write), which is more energy efficient than general SoC (always running a complete operating system). Furthermore, for small-batch customized scenarios (such as storage modules for industrial equipment), the development cost (NRE) of FPGA is lower than that of ASIC, and it supports rapid iteration.

[0107] According to the FPGA-based EXFAT file system storage method of the present invention, key steps such as format completion flag triggering, local metadata caching, hardware-based file creation and writing operations (including filename hash calculation, directory entry checksum calculation, data volume judgment, continuous / non-contiguous cluster allocation and FAT table linkage update), and DBR parsing to obtain data structure location are all executed in the FPGA hardware logic. The DMA setting IP and SQ generator IP are used to automatically complete the data transfer between DDR4 and NVME SSD, thereby achieving deep offloading of the CPU and parallel acceleration of metadata operations, significantly improving the overall throughput of file creation, writing, reading, searching and deletion. At the same time, by bypassing the operating system software stack through hardware direct connection architecture, microsecond-level deterministic low latency is achieved, and system power consumption and CPU resource consumption are greatly reduced.

[0108] In one embodiment of the present invention, Figure 6 This is a schematic diagram of the hardware configuration of the EXFAT file system, including system power supply 1 (using 12V DC), external fan cooling 2 (the VU+ series FPGA manual specifies that external heat dissipation should be used), FPGA board download and debugging cable 3 (through which the PC can monitor the internal data of the FPGA and the internal data of the NVMe SSD), PCIe adapter board 4 (used to connect the master end (FPGA board) and the controlled end (NVMe SSD) of the file system), NVMe SSD 5 (also the controlled end, where the file system will ultimately be built), and FPGA board 6 (the master control board, with the core controller being a VU23P device, on which the hardware circuitry of the file system is built).

[0109] According to one aspect of the present invention, an electronic device is provided.

[0110] Figure 7 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present invention. Figure 7 As shown, an electronic device may include one or more ( Figure 7 Only one is shown in the image. A processor 102 (which may include, but is not limited to, a microprocessor unit (MPU) or a programmable logic device (PLD)) and a memory 104 for storing data are also shown. In one exemplary embodiment, the electronic device may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 7 The structure shown is for illustrative purposes only and does not limit the structure of the terminal device described above. For example, the terminal device may also include components that are more... Figure 7The more or fewer components shown, or having the same Figure 7 Equivalent functions or ratios shown Figure 7 The functions shown have more different configurations.

[0111] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the storage method of the FPGA-based EXFAT file system in this embodiment of the invention. The processor 102 executes various functional applications and data processing by running the computer programs stored in the memory 104, thereby implementing the above-described method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to terminal devices via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0112] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the switching device. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0113] This invention proposes a non-transitory computer-readable storage medium storing computer instructions, which are used to cause the computer to execute a storage method based on an FPGA-based EXFAT file system.

[0114] The applicant of this invention has provided a detailed description of the embodiments of the invention in conjunction with the accompanying drawings. However, those skilled in the art should understand that the above embodiments are merely preferred embodiments of the invention. The detailed description is only intended to help readers better understand the spirit of the invention and is not intended to limit the scope of protection of the invention. On the contrary, any improvements or modifications made based on the inventive spirit of the invention should fall within the scope of protection of the invention.

[0115] Furthermore, the functional units in the various embodiments of the present invention can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0116] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of the present invention have been shown and described above, it is to be understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present invention.

[0117] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the embodiments of the present invention, and are not intended to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications 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 the present invention. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the protection scope of the present invention.

Claims

1. A storage system based on an FPGA-based EXFAT file system, characterized in that, include: The FPGA main control board serves as the main controller, and the NVMe SSD serves as the storage medium; The FPGA main control board and the NVMe SSD are inserted into the PCIe switch adapter board; The FPGA main control board integrates the MicroBlaze system, NVME HA, XDMA, and multiple hardware function IPs. The MicroBlaze system is used to run a Linux system to execute high-level control logic. The NVME HA integrates an NVME IO queue buffer to enable NVME protocol communication between the NVME host and the NVME SSD. Among them, multiple hardware function IPs include: AXI4 protocol encapsulation IP, DMA setting IP, SQ generator IP, file creation IP, FAT table mark refresh IP, cluster bitmap mark refresh IP, SQ linked list IP, command issuance IP, and data generator IP; The AXI4 protocol encapsulation IP is used to encapsulate the AXI4 protocol, enabling read and write access operations between the relevant IP inside the FPGA and DDR4 using the AXI4 protocol. The DMA setting IP is used to establish a DMA mapping relationship between RAM data in the local IP module and a specified address in DDR4; The SQ generator IP is used to generate corresponding SQs according to the file system functions in accordance with the NVME HA manual, and send them to the NVME HA in the form of an AXI-STREAM interface; The file creation IP is used to create a file based on a file creation algorithm when a file creation command is received. The FAT table flag refresh IP is used for local caching and updating of the FAT table data in the NVMe SSD; The cluster bitmap marker refresh IP is used for local caching and updating of cluster bitmap data in the NVMe SSD; The SQ linked list IP is used to write the required PRP LIST in SQ to a specified address in memory; The command is issued via IP address, which is used by the software side to issue file system execution instructions to the logical side. The data generator IP is used to simulate data from external sensors, and the simulated external sensor data is ultimately recorded into the NVMe SSD in text file format. Among them, multiple hardware function IPs work together under the scheduling of the Linux system to jointly complete the formatting, file creation, file writing, file reading, file searching and file deletion operations of the EXFAT file system; The EXFAT file system includes user data and metadata.

2. The storage system based on the FPGA-based EXFAT file system according to claim 1, characterized in that, The cluster bitmap marker refresh IP, the FAT table marker refresh IP, and the file creation IP all contain local RAM, which is used to read the cluster bitmap data, FAT table data, and root directory data in the NVME SSD into the local RAM for caching after the EXFAT file system is formatted, via the command issuing IP.

3. The storage system based on the FPGA-based EXFAT file system according to claim 1, characterized in that, The file creates IP addresses including: The file creation filename ASCII conversion unit is used to convert the user filename ASICC code from lowercase to uppercase. The filename hash calculation unit is used to calculate the hash value of the user filename according to the EXFAT WIN32 specification. The ASCII code of the user filename is converted from lowercase to uppercase and then expanded before being used in the calculation. The directory entry verification and calculation unit is used to verify and calculate the entire directory entry of the main directory entry and the subordinate directory entries of the file according to the EXFAT WIN32 specification. The directory entry splicing unit is used to splice the calculated entire directory entry.

4. The storage system based on the FPGA-based EXFAT file system according to claim 1, characterized in that, The SQ generator IP is specifically used for: Receive the flag signal of the command issued by the IP or the DMA completion signal issued by the DMA setting IP, and concatenate the read command queue or the write command queue; The concatenated command queue is sent to the NVME HA through the AXI-STREAM interface to trigger the NVMESSD to perform data transfer. Receive CQ information from NVME HA to determine when to stitch together the relevant SQ.

5. A storage method for an FPGA-based EXFAT file system, applied to the storage system of the FPGA-based EXFAT file system as described in any one of claims 1 to 4, characterized in that, Includes the following steps: After the system powers on, the Linux system sends an EXFAT formatting command to the NVMe SSD to format the NVMe SSD; After formatting is complete, the Linux side sends a formatting completion flag to the command sending IP address; After the logical side reads the command issuance IP formatting completion flag, the logical side uses the SQ generator IP to read the cluster bitmap data, FAT table data and root directory data in the NVME SSD into the cluster bitmap mark refresh IP, FAT table mark refresh IP and file creation IP respectively for local caching; The Linux system sends file operation commands to the corresponding hardware function IPs. These file operation commands include formatting commands, file creation commands, file writing commands, file reading commands, file searching commands, and file deletion commands. The hardware function IP calculates and updates the cached metadata locally according to the EXFAT WIN32 specification; The DMA setting IP will write the updated metadata to DDR4 memory in the set DMA format; The SQ generator IP concatenates the corresponding NVME command queue according to the write completion signal; NVME HA sends the NVMe command queue to the NVME SSD, causing the NVME SSD to move the updated metadata from the DDR4 memory to the specified sector.

6. The storage method for the FPGA-based EXFAT file system according to claim 5, wherein the file creation operation includes: The file creation IP receives the filename and file attributes issued by the Linux system; The file creation IP pair calculates the HASH value of the filename according to the EXFAT WIN32 specification, and performs verification and calculation on the entire directory entry; The file creation IP will be constructed by concatenating the calculated entire directory entry; The cluster bitmap marker refreshes the IP marker for idle clusters and updates the cached cluster bitmap locally; The DMA setting IP writes the updated root directory data and cluster bitmap data into the DDR4 memory in the set DMA format; The SQ generator IP moves the root directory data and cluster bitmap data in the DDR4 memory to the NVMe SSD.

7. The storage method of the FPGA-based EXFAT file system according to claim 5, wherein the file write operation includes: The data generator IP generates data to be written and writes it to the DDR4 memory; The file creation IP determines whether the amount of data in the DDR4 memory exceeds the size of the entire cluster; If the data volume is less than or equal to one cluster, the cluster bitmap marker refresh IP finds an idle cluster and marks it in the local cache, and the file creation IP updates the starting cluster number and file size in the directory entry; If the amount of data is greater than one cluster, the cluster bitmap marker refresh IP searches for consecutive or non-consecutive clusters, and if the clusters are not consecutive, the FAT table marker refresh IP is triggered to update the FAT table data in the local cache. The DMA setting IP writes the updated cluster bitmap data, FAT table data, and directory entry data into the DDR4 memory in the set DMA format; The SQ generator IP moves the cluster bitmap data, the FAT table data, and the directory entry data from the DDR4 memory to the NVME SSD.

8. The storage method for the FPGA-based EXFAT file system according to claim 5 further includes: Calculate the location information of the EXFAT file system data structures, where: After the Linux system completes the formatting of the NVME SSD, it sends a command to set the IP formatting completion flag, triggering the SQ generator to generate a read command queue. NVME HA reads the DBR start sector data of the NVME SSD into the DDR4 memory at the starting address 0x7000_0000; The SQ generator IP reads the DBR start sector data from the DDR4 memory into the SQ generator IP based on the DBR read SQ feedback CQ information and through the DMA setting IP. The SQ generator IP parses the DBR starting sector data and determines the location information of the EXFAT file system data structure in the NVME SSD according to the EXFAT WIN32 algorithm.

Images