Welcome FPGA engineers to join the official WeChat technical group
Clickthe blue wordsto follow us at FPGA Home – the best and largest pure FPGA engineer community in China
Note: This article is a demand analysis and does not involve specific FPGA models or tools.
The reconfigurability of FPGAs brings high flexibility, so designs/products based on FPGAs often have needs for later updates/upgrades. However, the FPGA boards that need to be updated/upgraded may not be able to be upgraded on-site due to physical constraints. For example:
1. FPGA boards deployed in remote data centers cannot be accessed at any time for upgrades (the cost of traveling back and forth and restrictions on entering the data center).
2. FPGA boards deployed in relatively complex environments, such as wireless communication devices placed on communication towers, or equipment in customers’ hands that cannot be collected and upgraded by suppliers one by one.
3. FPGA upgrades have a significant impact on the system, making it inconvenient to upgrade at any time. For example, PCIE devices are monitored by the system bus, and arbitrary updates may cause the machine to restart, which is not allowed in some strictly regulated environments.
Thus, there is a demand for remote updates of FPGAs, which needs to meet the following constraints:
1. Remote upgrades can be conducted under certain conditions (such as available network for remote access), and they do not necessarily need to be fully automated, but full automation is more convenient;
2. The update process must not affect the system to prevent the system from mistakenly implementing protective measures (such as server restart);
Remote updates are generally divided into two parts: 1) data transmission; 2) update image;
There are many options for the data transmission part, such as transmitting data over the network. Usually, existing communication interfaces are used to implement this. If the FPGA board is deployed in a computer, the data can first be transmitted over the network to the computer, and then forwarded to the FPGA for image updates. The data transmission is mainly implemented by the host computer, so there are no strict requirements for the data transmission part. Typically, the focus of FPGA remote update design is on how to update the image.
The concept of updating the image has two completely different concepts that need to be clarified.
1. Update the FPGA configuration
This solution corresponds to downloading Xilinx’s bit files and Intel (Altera)’s sof files, updating the FPGA configuration, which takes immediate effect. The problem with this solution is that the original configuration of the FPGA will be cleared during the configuration process. At this point, the system may react incorrectly. For example, a PCIE device implemented using FPGA may fail due to reconfiguration, and some servers may trigger a restart upon detecting an abnormal PCIE device, causing an impact.
2. Update the Flash that stores the FPGA configuration image
This method targets the memory that stores the FPGA configuration (usually Flash).
During the Flash update process, certain measures are taken to ensure that the original design of the FPGA continues to work without impact, and it does not take effect immediately. The FPGA still uses the old image; after updating Flash, the FPGA is reconfigured at an appropriate time, and the updated image data will be sent to the FPGA for loading; the entire process is relatively controllable, thus minimizing the impact on the system.
Therefore, we can see that the demand for remote update solutions can be summarized into the following three points:
1. Utilize existing data channels to transmit data
2. Write the update data into the memory that stores the FPGA configuration information
3. During the Flash update process, do not affect the normal functionality of the FPGA
The first point has many optional solutions that need to be decided based on system requirements, so this article will not delve deeper into it. The focus will be on the latter two points.
FPGAs have multiple configuration/loading methods. They can roughly be divided into active and passive types. Active loading refers to the FPGA controlling the configuration process, while passive loading means the FPGA merely passively receives configuration data.
The most common passive configuration mode is JTAG downloading of bit files. In this mode, the device initiating the operation is the computer, the data path is JTAG, and the FPGA passively receives data to update its configuration as needed. How the host computer obtains the configuration data is very flexible; it may be generated by locally running EDA tools or obtained from network/USB storage devices.
Active configuration means the FPGA takes the lead during the configuration process, actively initiating read/write operations to Flash to obtain configuration information for configuration.
Using the burning operation of EDA tools as an example, let’s analyze the specific burning process.
In Vivado, bin files and mcs files can be used to burn Flash, while in Quartus, jic files can be used to update Flash. Typically, the complete process is:
1. The host computer actively initiates the configuration, and the FPGA passively receives data for reconfiguration, where the configuration mode is the passive configuration based on JTAG mentioned earlier. The result of this operation is that the FPGA is configured as a Flash reader/writer.
2. After the configuration is complete, the host computer begins to send/receive data to/from Flash, with the data channel being JTAG. After the FPGA receives the data via JTAG, it initiates read/write operations to Flash according to the needs, writing the necessary update data into Flash to complete the update. This process is the Flash update process, during which Flash is only controlled by the FPGA.
3. After Flash is updated, at an appropriate time, the FPGA is triggered to reconfigure (for example, by cycling power), and the FPGA will start the active configuration process, reading configuration data from Flash to complete loading.
This process of burning Flash is commonly referred to as indirect programming (indirect burning). Detailed descriptions can be found in the help files of Xilinx tools.
Indirect programming first configures the FPGA as a Flash read/write controller and then uses this controller to read/write Flash. Therefore, during the configuration process, you can see that the FPGA is successfully loaded first, and then subsequent Flash operations are performed. In Xilinx, this Flash read/write controller is saved in the installation path of the tool. In ISE, it is referred to as a cor file.
Vivado directly saves the bit files and provides three modes, differing in whether unused pins are in pull-up, pull-down, or high impedance states.
Intel (Altera) uses the jic file extension for this mode, which stands for JTAG Indirect Configuration File. The principle is exactly the same as that described above for Xilinx. In the Quartus Programmer interface, after adding a jic file, you can see a Factory default SFL image, which configures the FPGA as a Flash controller image.
When burning Flash, you can pay attention to the console log messages, where you can see that the read/write control of Flash is only performed after the first successful configuration. Specific operations for Xilinx and Intel (Altera) platforms will be analyzed in follow-up articles.
Depending on the configuration, it can also be divided into active updates and passive updates.
If it is a passive update, usually there will be an active device initiating the configuration process, commonly an MCU. This makes the configuration process relatively easy, as the data transmission, storage, and reading are handled by the master device. The entire update process can be updated as required, and then the FPGA can be reloaded at an appropriate time. The FPGA itself is almost completely isolated from the update process, making it easy to meet the requirements.
Active updates are relatively troublesome. Firstly, Flash may only have a data interface with the FPGA, meaning that the read/write operations for Flash can only be initiated from the FPGA. Secondly, since the FPGA needs to initiate the Flash update write operation, how it obtains the data is also a consideration. Referring to the previous description of the complete process for active configuration updating Flash, it can be seen that the FPGA needs a data channel (JTAG) to receive configuration data and to implement a Flash read/write controller to read/write Flash. After completing the Flash update, the next configuration trigger (power cycling) will actively initiate the read operation from Flash, loading the configuration data to complete the configuration.
Now, you should have some preliminary understanding of remote updates.
If conditions permit, using an MCU as the master control device for remote updates will simplify the solution significantly. Moreover, it allows for more operations via software (such as data verification). The typical reason for this choice is that there is already a master control MCU in the system, which can also take on the task of remote updates.
If the FPGA board uses an active configuration mode, since the read/write operations for Flash can only be implemented through the FPGA, and direct JTAG updates to the FPGA image may not meet the requirements (for example, it may not be possible to configure via JTAG every time power is cycled), then designing an active mode remote update solution becomes very important. At this point, even if there is an MCU or host computer in the system, since Flash can only be controlled by the FPGA, the MCU/host computer primarily serves as a data communication channel to send FPGA configuration data, while the steps to update Flash still need to be implemented by the FPGA.
It can be seen that if the update control is handed over to the MCU, the burden is significantly reduced. The requirements on the FPGA during the configuration process are also minimal, meaning that most of the work is completed by external devices (MCU), and the FPGA’s workload is minimal. Therefore, the focus of discussion is on the more challenging active update solutions that require more work from the FPGA. Based on this, the current design requirements have transformed into:
1. Utilize existing data channels to transmit data to the FPGA;
2. Write the update data into Flash through the FPGA;
3. During the Flash update process, do not affect the normal functionality of the FPGA;
1. Utilize existing data channels to transmit data to the FPGA;
Since there are many optional methods for data transmission, and any solution is a vast topic, it will not be described in detail here. The recommended approach is to control handshakes and write data to Flash one by one. The design focus is on the interaction handshake between data transmission and Flash read/write across clock domains.
Typically, the data transmission rate is higher than the Flash read/write rate, so using a buffer is advisable. However, this comes with two issues: firstly, the storage space may overflow, and secondly, the frequency of update operations is not high. Thus, reserving a large-capacity storage space for a low-frequency application is not cost-effective. Therefore, using interaction handshakes to manage the relatively slow update speed does not significantly impact the low-frequency Flash update operations, but it does require consideration of cross-clock interactions during the handshake process.
2. Write the update data into Flash through the FPGA
3. During the Flash update process, do not affect the normal functionality of the FPGA
These two requirements necessitate implementation by the FPGA, specifically the solution involves the FPGA starting read/write operations to Flash after receiving data, correctly writing the data into Flash. Regarding this, as it relates to specific FPGAs, follow-up articles will further analyze the Flash controllers and complete processes for Xilinx and Intel (Altera) platforms.
Through this comprehensive analysis, you should have a general understanding of what needs to be done for remote updates. Apart from the data paths which may vary depending on the system, the read/write control on the FPGA side is an inevitable requirement. Subsequent articles will provide a more detailed analysis of the FPGA’s internal Flash controller and the complete process.
Welcome communication engineers and FPGA engineers to follow our public account
The largest FPGA WeChat technical group in the country
Welcome everyone to join the national FPGA WeChat technical group. This group has tens of thousands of engineers, a group of engineers who love technology, where FPGA engineers help each other and share knowledge, creating a strong technical atmosphere!Hurry up and bring your friends to join!!
Just press and hold to join the FPGA national technical group
FPGA Home Component City
Advantageous component service, please scan the code to contact the group owner: Jin Juan Email: [email protected] Welcome to recommend to procurement
ACTEL, AD part of advantageous ordering (operating the whole series):
XILINX, ALTERA advantageous stock or ordering (operating the whole series):
(The above components are part of the models; for more models, please consult the group owner Jin Juan)
Service concept: FPGA Home Component City aims to facilitate engineers in quickly and conveniently purchasing components. After years of dedicated service, our customer service is spread across large listed companies, military research units, and small and medium-sized enterprises. Our greatest advantage is emphasizing the service-first concept and ensuring fast delivery and favorable prices!
Directly operated brands: Xilinx ALTERA ADI TI NXP ST E2V, and over a hundred other component brands, especially proficient in components subject to US embargo against China,we welcome engineer friends to recommend us to procurement or consult us directly!We will continue to provide the best service in the industry!
Official thanks from FPGA technology group brands: Xilinx, Intel (Altera), Microsemi (Actel), Lattice, Vantis, Quicklogic, Lucent, etc.