A method for updating prototype system firmware on FPGA platform

Abstract

The present invention discloses a method for updating prototype system firmware on an FPGA platform, comprising: S1, converting the binary firmware content to be updated into a format readable by a firmware storage module through a Linux command and embedding the format into the firmware storage module to generate a bitstream file; S2, loading the bitstream file into the FPGA platform; after resetting, first sending an instruction to read the chip device ID to the Flash chip, and receiving the device ID information output by the Flash chip; S3, sending an instruction to enable write enable to the Flash chip, followed by an instruction to erase the entire chip; and S4, reading data from the firmware storage module and burning it into the Flash chip. This method simplifies the steps for replacing the firmware content in the Flash chip of the FPGA prototype platform, eliminates the need for hardware equipment such as a professional Flash burner, eliminates the need to power off the FPGA platform, and eliminates the need to remove the Flash chip from the FPGA platform. This reduces the use loss of the FPGA prototype platform, significantly improves replacement efficiency, and meets the needs of batch firmware replacement for multiple FPGA prototype verification platforms.

Description

Technical Field

[0001] The present invention relates to the field of chip prototype verification, and in particular provides a method for conveniently updating firmware content in a Flash chip for an FPGA platform. Background Art

[0002] In the field of ASIC chip prototype verification, an FPGA platform is usually used to build a prototype system of the ASIC chip before tape-out, running the operating system and various system-level benchmark programs. The prototype system can usually be regarded as a simplified computer system, which runs in the FPGA platform in the form of a bitstream file, including most of the functional modules of the ASIC chip design, such as the processor core, interconnection bus, and peripheral interface. After the FPGA platform is reset and released, the prototype system needs to read the firmware program from the external non-volatile memory to perform hardware initialization and load the operating system. The firmware program is usually stored in the Flash chip connected to the FPGA platform. In the process of ASIC chip design and verification, with the update and iteration of the ASIC design code and the adaptation and update of the firmware program, there is a situation where the firmware program is frequently updated. For the Flash chip that stores the firmware program in the FPGA platform, the current conventional way to replace the firmware content in the Flash chip requires first turning off the power of the machine, removing the Flash chip and placing it in a dedicated burner to update the firmware content, and then putting the Flash chip back into the FPGA platform and fixing it. Finally, the FPGA platform is powered on again to run the prototype system with the updated firmware. The whole process is as follows: Figure 1 Because FPGA prototype verification machines are often placed in computer rooms and require complicated power-on and power-off procedures, replacing the Flash chip firmware is complex and time-consuming. Summary of the Invention

[0003] In view of the problems existing in the prior art, the purpose of the present invention is to provide a method for updating prototype system firmware on an FPGA platform, which can improve the efficiency of replacing the firmware content in the Flash chip of the FPGA prototype system.

[0004] To achieve the above object, the present invention provides a method for updating prototype system firmware on an FPGA platform, the method comprising the following steps:

[0005] S1. Convert the binary firmware content to be updated into a format readable by the firmware storage module using Linux commands and embed it into the firmware storage module. Use the EDA tool corresponding to the FPGA platform to synthesize and implement the Verilog HDL code and generate a bitstream file.

[0006] S2. Load the bitstream file into the FPGA platform. After the reset is completed, first send a command to the Flash chip to read the chip device ID, and receive the device ID information output by the Flash chip to check whether the device ID information is correct.

[0007] S3. Send a command to enable write to the Flash chip, and then send an erase command for the entire chip. During the erase process, the status register is continuously read to determine whether the chip has completed the erase operation.

[0008] S4. Finally, a write enable command is sent to the Flash chip, followed by a programming command. The programming content is obtained from the firmware storage module. During programming, the status register is continuously read to determine whether the chip has completed programming.

[0009] Furthermore, the FPGA includes a Flash controller module, a firmware storage module, and a TOP control module.

[0010] Furthermore, the FPGA platform includes a UART communication module, a Flash controller module, a firmware storage module and a TOP control module.

[0011] Furthermore, the TOP control module is used to connect various internal modules and to instruct the Flash controller module, the UART communication module and the firmware storage module to perform different operations.

[0012] Furthermore, the firmware storage module is implemented through the internal resources of the FPGA, and the storage capacity is adjustable within the range of storage resources supported by the FPGA chip to be suitable for firmware of different file sizes.

[0013] Furthermore, the Flash controller module is used to perform different process operations on the Flash chip according to different instruction types transmitted by the TOP control module; including sending instructions, sending instructions-receiving data, sending instructions-sending address-receiving data and / or sending instructions-sending address-sending data.

[0014] Furthermore, the Flash controller module is used to implement all operation controls on the Flash chip, including: reading and writing registers, erasing, burning and / or reading storage contents.

[0015] Furthermore, the communication module is used to interact with the host computer.

[0016] Furthermore, after the firmware content is embedded into the firmware storage module, the bitstream file is compiled and generated through the EDA tool corresponding to the FPGA. After the bitstream file is loaded into the FPGA platform, the firmware update operation can be performed.

[0017] Furthermore, the method can be implemented on a variety of FPGA models that meet hardware resource requirements.

[0018] The beneficial effects of the present invention are as follows:

[0019] This method simplifies the steps for replacing the firmware content in the Flash chip of an FPGA prototype platform, significantly improves replacement efficiency, reduces the usage loss of the FPGA prototype platform, and can realize remote batch operations, reducing the time required to replace the firmware content of the FPGA prototype platform by more than 80%. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 This is a schematic diagram of the steps for updating the firmware content.

[0021] Figure 2 This is a schematic diagram of the steps for updating firmware content of the present invention;

[0022] Figure 3 It is a schematic diagram of the hardware architecture of the present invention;

[0023] Figure 4 It is a logic control flow chart of the present invention. DETAILED DESCRIPTION

[0024] The following will clearly and completely describe the technical solution of the present invention in conjunction with the accompanying drawings. Obviously, the embodiments described are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0025] In the description of the present invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicating orientations or positional relationships, are based on the orientations or positional relationships shown in the accompanying drawings and are intended solely to facilitate and simplify the description of the present invention. They are not intended to indicate or imply that the devices or components referred to must have, be constructed, or operate in a specific orientation, and therefore should not be construed as limitations on the present 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.

[0026] In the description of the present invention, it should be noted that, unless otherwise expressly specified or limited, the terms "mounted," "connected," and "connected" should be understood in a broad sense. For example, they may refer to fixed, detachable, or integral connections; mechanical or electrical connections; direct or indirect connections through an intermediate medium; and internal communication between two components. Those skilled in the art will understand the specific meanings of the above terms in the present invention based on specific circumstances.

[0027] The following combination Figure 2-Figure 4 The specific embodiments of the present invention are described in detail. It should be understood that the specific embodiments described herein are only used to illustrate and explain the present invention and are not used to limit the present invention.

[0028] The present invention provides a method for updating the firmware content in the Flash chip based on the FPGA bitstream file, without powering off the FPGA platform, removing the Flash chip, or using a dedicated Flash burner. The present invention can also replace the content in the Flash chip by generating and downloading the bitstream without the participation of a host computer, relying only on the original FPGA platform. The whole process is as follows: Figure 2 As there is no restriction on the use of a burner and a host computer, the present invention can also meet the demand for batch replacement of firmware on multiple FPGA prototype verification platforms.

[0029] The present invention provides a method for updating prototype system firmware on an FPGA platform, which can simplify the tedious steps of replacing Flash firmware content during FPGA prototype verification. The present invention is implemented through Verilog HDL code, such as Figure 3 As shown in the figure, the top layer of the FPGA platform is the TOP control module, which includes a firmware storage module, a UART communication module (optional), and a Flash controller module.

[0030] Among them, the TOP control module is used to interconnect the internal modules and to instruct the Flash controller module to perform different operations on the external Flash chip, including reading and writing registers, erasing, burning, reading storage contents, etc.

[0031] The firmware storage module stores firmware content. It utilizes internal FPGA resources, and its storage capacity is adjustable within the memory resources supported by the FPGA chip. Firmware content can be converted into a file format recognizable by the firmware storage module using Linux commands and then embedded into the module.

[0032] The UART communication module can be set or not set as needed. It is used to interact with the host computer and can be used to output relevant status or information, including the Flash chip device ID, status register, and storage content. It can also be used to receive signals from the host computer, such as erase, burn, read ID, etc. After detecting the signal transmitted by the host computer, the TOP control module can send corresponding instructions to the Flash controller based on the signal content, realizing the interactive control of the Flash chip by the host computer.

[0033] The Flash controller module primarily interacts with external Flash chips, enabling control over the Flash chip's contents, including reading, writing, erasing, and status. Based on the different command types transmitted from the TOP control module, the Flash controller module can perform different operations on the Flash chip, including sending a command, sending a command and receiving data, sending a command and sending an address and receiving data, and sending a command and sending an address and sending data.

[0034] The method of the present invention comprises the following steps:

[0035] S1. Convert the binary firmware content into a format that can be read by the firmware storage module through Linux commands and embed it into the firmware storage module. Use the FPGA-compatible EDA tool to first synthesize the Verilog HDL code into a netlist, then perform layout and routing, and finally generate a bitstream file.

[0036] S2. Load the bitstream file into the FPGA platform. After the reset is completed, the Flash controller module sends a command to the Flash chip to read the chip device ID and receives the device ID information output by the Flash chip. The TOP control module executes the subsequent steps after verifying that the device ID information is correct.

[0037] S3: The Flash controller module then sends a write enable command to the Flash chip, and then sends an erase command for the entire chip. During the erase process, the status register is continuously read to determine whether the chip has completed the erase operation.

[0038] S4. Finally, the Flash controller module sends a write enable command to the Flash chip again, and then sends a burn command. The burned content is obtained from the firmware storage module. During the burning process, the status register is continuously read to determine whether the chip has completed the burning action.

[0039] Figure 3 The hardware structure of the embodiment of the present invention is shown. The embodiment of the present invention is implemented based on Xilinx platform FPGA. Figure 3 As shown, the embodiment of the present invention includes a UART communication module, a Flash controller module, a firmware storage module (BRAM), and a TOP control module. The embodiment of the present invention uses a communication module to communicate using the UART protocol, and the firmware storage module is implemented in the form of BRAM. BRAM is a type of storage resource in FPGA, which can load and store files in the coe format. After downloading the bitstream file generated by the embodiment of the present invention to the FPGA platform, the embodiment of the present invention controls the logic control flow of the Flash chip as shown below. Figure 4The present invention simulates the functions of erasing and programming Flash chips of a professional Flash programmer on an FPGA platform through pure Verilog HDL, thereby enabling the update of the firmware content in the Flash chip on the FPGA platform without powering off, removing the Flash chip, or relying on external devices such as a professional programmer.

[0040] The implementation of replacing firmware content provided by an embodiment of the present invention includes the following steps:

[0041] Step S1 includes:

[0042] S1.1: In the Linux environment, use the xxd and sed commands to convert the binary bin format firmware file into a coe format file that meets the requirements. Convert the original binary bin format firmware file ($1) into a coe format file ($1.coe). The specific commands are as follows:

[0043] 1.xxd -c 8 -p $1 2>&1 $1.coe / / Convert the binary firmware content into hexadecimal

[0044] 2.sed -i 's / \(.\)\(.\) / \1\2 / g' $1.coe / / Each two hexadecimal numbers are grouped together, with spaces inserted between each group

[0045] 3.sed -i '1imemory_initialization_vector=' $1.coe / / Insert the standard format prefix content of the coe file, indicating that the content after this sentence is the data content to be stored

[0046] 4.sed -i '1imemory_initialization_radix=16' $1.coe / / Insert the standard format prefix content of the coe file to indicate that the data is stored in hexadecimal form

[0047] 5.sed -i '$a ;' $1.coe / / Insert a semicolon at the end of the last line to indicate the end of the data

[0048] S1.2: Use a Tcl script in Vivado, an EDA tool on the Xilinx platform, to configure the firmware storage module of this embodiment of the present invention to have an 8-bit data width and a 640,000-bit depth. This allows for storing firmware files up to 625 KB in size. Import the $1.coe file obtained in S1.1 into the firmware storage module. Then, import the TOP control module, UART communication module, Flash controller module, and firmware storage module into Vivado for logic synthesis, place-and-route, and bitstream generation.

[0049] Step S2 includes:

[0050] S2.1: Download the bitstream file to the FPGA prototype verification platform. After resetting, the embodiment of the present invention first enters the workflow of confirming the Flash chip device ID. The Flash controller module communicates with the Flash chip according to the SPI protocol and first sends a command to the Flash chip to read the Flash chip device ID.

[0051] S2.2: The device ID information transmitted back by the Flash chip is temporarily stored in the register of the TOP control module. After the Flash chip transmission is completed, the TOP control module outputs the device ID information in the register to the host computer through the UART communication module.

[0052] Step S3 includes:

[0053] S3.1: If the Flash chip device ID is correct, the host computer sends a command to enable programming. The UART communication module feeds the programming command back to the TOP control module, which then begins the erase process. The Flash controller module sends a command to enable write capability to the Flash chip, followed by an entire chip erase command.

[0054] S3.2: The embodiment of the present invention then continues to send instructions to the Flash chip to read the Flash chip status register. The TOP control module uses the status register information fed back by the Flash chip to determine whether the Flash chip is erased. When the erasure is complete, the UART communication module outputs an erase completion prompt through the UART serial port.

[0055] Step S4 includes:

[0056] S4.1: The TOP control module enters the programming process. Programming is performed in pages, with each page programming 256 bytes of data. The Flash controller module first sends a write enable command to the Flash chip, followed by a programming command. After sending the programming command, it sends the page starting address for programming. It then sequentially retrieves 256 bytes of data from the BRAM firmware storage module and sends them to the Flash chip.

[0057] S4.2: After the 256-byte data transmission is completed, the Flash controller module will enter the state of reading the status register and continue to determine whether the Flash chip has completed the burning operation of this page based on the read status register information.

[0058] S4.3: After detecting that the Flash chip has completed programming of one page, the Flash controller module will repeat steps S4.1 and S4.2 to program the next page. During the entire programming process, the starting address of the programming page and the address of the data obtained in the BRAM firmware storage module are incremented.

[0059] S4.4: When the page address to be programmed reaches the designated page address and the programming of the page is completed, the UART communication module outputs a programming completion signal, and the overall steps of the embodiment of the present invention are completed.

[0060] Throughout this specification, reference to terms such as "embodiment" and "example" indicates that a specific feature, structure, material, or characteristic described in conjunction with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the schematic representations of these terms do not necessarily refer to the same embodiment or example. Furthermore, those skilled in the art may combine or integrate different embodiments or examples described in this specification, as well as features therein, without creating any inconsistency.

[0061] Although the above content has shown and described the embodiments of the present invention, it can be understood that the above embodiments are exemplary and cannot be understood as limitations of the present invention. Ordinary technicians in this field can perform update operations such as changes, modifications, replacements and variations on the above embodiments within the scope of the present invention.

Claims

1. A method for updating prototype system firmware on an FPGA platform, characterized in that: The method comprises the following steps: S1. Convert the binary firmware content to be updated into a format readable by the firmware storage module through Linux commands and embed it into the firmware storage module. Use the EDA tool corresponding to the FPGA platform to synthesize and implement the Verilog HDL code and generate a bitstream file. S2. Load the bitstream file into the FPGA platform. After the reset is completed, first send a command to the Flash chip to read the chip device ID, and receive the device ID information output by the Flash chip to check whether the device ID information is correct. S3. Send a command to enable write to the Flash chip, and then send an erase command for the entire chip. During the erase process, the status register is continuously read to determine whether the chip has completed the erase operation. S4. Finally, a write enable command is sent to the Flash chip, followed by a programming command. The programming content is obtained from the firmware storage module. During programming, the status register is continuously read to determine whether the chip has completed programming. Step S1 includes: S1.1: In the Linux environment, use the xxd and sed commands to convert the binary bin format firmware file into a coe format file that meets the requirements. Convert the original binary bin format firmware file $1 into a coe format file $1.coe. The specific commands are as follows: 1) xxd -c 8 -p $1 2>&1 $1.coe / / Convert the binary firmware content into hexadecimal; 2) sed -i 's / \(.\)\(.\) / \1\2 / g' $1.coe / / Every two hexadecimal numbers form a group, and a space is inserted between each group; 3) sed -i '1imemory_initialization_vector=' $1.coe / / Insert the standard format prefix content of the coe file, indicating that the content after this sentence is the data content to be stored; 4) sed -i '1imemory_initialization_radix=16' $1.coe / / Insert the standard format prefix content of the coe file to indicate that the data is stored in hexadecimal form; 5) sed -i '$a ;' $1.coe / / Insert a semicolon at the end of the last line to indicate the end of the data content; S1.2: Use a Tcl script to set the firmware storage module to 8-bit data width and 640,000-bit depth using the Xilinx EDA tool Vivado. The firmware storage module stores files within 625 KB in size. Import the $1.coe file obtained in step S1.1 into the firmware storage module. Then, import the TOP control module, UART communication module, Flash controller module, and firmware storage module into the Vivado tool for logic synthesis, layout, and routing, and generate a bitstream file.

2. The method for updating prototype system firmware on an FPGA platform according to claim 1, wherein: FPGA includes Flash controller module, firmware storage module and TOP control module.

3. The method for updating prototype system firmware on an FPGA platform according to claim 1, wherein: The FPGA platform includes a UART communication module, a Flash controller module, a firmware storage module and a TOP control module.

4. The method for updating prototype system firmware on an FPGA platform according to claim 2 or 3, characterized in that: The TOP control module is used to connect the internal modules and to instruct the Flash controller module, UART communication module and firmware storage module to perform different operations.

5. The method for updating prototype system firmware on an FPGA platform according to claim 2 or 3, characterized in that: The firmware storage module is implemented through the internal resources of the FPGA, and the storage capacity can be adjusted within the range of storage resources supported by the FPGA chip to adapt to firmware of different file sizes.

6. The method for updating prototype system firmware on an FPGA platform according to claim 2 or 3, characterized in that: The Flash controller module is used to perform different process operations on the Flash chip according to different instruction types transmitted by the TOP control module; It includes sending instructions, sending instructions-receiving data, sending instructions-sending address-receiving data and / or sending instructions-sending address-sending data.

7. The method for updating prototype system firmware on an FPGA platform according to claim 6, wherein: The Flash controller module is used to implement all operations of the Flash chip, including reading and writing registers, erasing, burning and / or reading storage contents.

8. The method for updating prototype system firmware on an FPGA platform according to claim 3, wherein: The communication module is used to interact with the host computer.

9. The method for updating prototype system firmware on an FPGA platform according to claim 7, wherein: After the firmware content is embedded in the firmware storage module, the bitstream file is compiled and generated through the EDA tool corresponding to the FPGA. After the bitstream file is loaded into the FPGA platform, the firmware update operation is performed.

10. The method for updating prototype system firmware on an FPGA platform according to any one of claims 1 to 3, characterized in that: The method is implemented on various FPGA models that meet hardware resource requirements.

Images