1. Introduction
SoPC is a kind of embedded system that based on the field programmable gate arrays (FPGA). It has many merits, such as the rich hardware resource, flexible function, as well as the low project cost, and thus, it is widely used in automation, power electronics, and microwave [
1,
2,
3,
4]. Nevertheless, in some occasions, such as the satellite borne equipment, underwater equipment, and core printed circuit boards that are located in the cumbersome electromagnetism shields, connection via the download cable between the SoPC and computer is infeasible. It brings about great trouble when the equipment breaks down or new function is wanted. Thus, the maintainability and flexibility of the system are reduced. Therefore, remote system update (RSU) for programmable devices via the communication system has become a research hotspot [
5,
6,
7,
8].
Up to now, there have been a lot of successful cases of RSU for micro control units (MCU) [
9,
10,
11], digital signal processers (DSP) [
11,
12,
13], FPGA/SoPC [
13,
14,
15,
16,
17], as well as advanced RISC machines (ARM) [
18]. Besides, the communication channels in those researches include General Packet Radio Service (GPRS), Bluetooth, Peripheral Component Interconnect (PCI), Ethernet, RS-422, as well as CAN bus. Moreover, defending the configuration image from any kind of attacks is another important research item [
19,
20], especially for the wireless RSU. Furthermore, minimizing the new configuration image and memory occupation are of great importance when the system power dissipation limit is critical [
21].
Nevertheless, most researchers chose to erase the total configuration device and then write a new configuration image in the RSU process. Once any accident occurs in the RSU process, SoPC will never start up for there is no practicable configuration image in the configuration devices. In order to fix this problem, some research makes use of several hardware or software configuration files. One acts as a baseline that is not allowed to be modified, while others act as updates [
22,
23,
24]. A controller switches among them. If the update is not effective, the baseline will provide the basic function so as to keep the system working. However, there are few studies trying to update the whole SoPC configuration image with hardware and software in a single process.
In terms of the industry field control systems, CAN has the advantages in such aspects as message integrity, transmission distance, as well as interface cost. In [
12,
17], there’s a root board receiving new configuration image at first, which then sends it to other boards through another bus. This topology makes the system complex. Besides, a CAN data frame only contains eight bytes, but the medium scale SoPC configuration image is more than one megabyte (MB). Therefore, it takes the mass frames to send the total image. In order to reduce the risk of communication failure, [
12] checks every data frame. It is no doubt that this will cost a lot of time when dealing with a large configuration image, which leads to the prolix and inconvenient application in the RSU process.
In terms of the RSU scheme that is planned in this article, the EPCS device contains two integrated SoPC configuration images. One is the application mode image for the expected functions. The other is the factory mode image, which updates the application mode image remotely and acts as the baseline. The dedicated RSU circuit that is provided by Altera will choose from the above two images for the purpose of loading. Even if the RSU process goes wrong, the system can roll back to the factory mode and request a new RSU process.
Both the factory mode image and application mode image own an embedded CAN controller intellectual property core (IP). Therefore, every node can receive RSU frames independently. Since the entire system adopts a single CAN bus, the system topology is succinct, easy to use, and suitable for the field distributed control system. In order to adapt to the various mission demands, CAN application layer protocol is optimized by dividing the identifiers and data field into several segments and every segment is entrusted with definite meaning. Besides, in order to give considerations to both sides of communication reality and efficiency, the data check of a new image is applied whenever the data buffer of an EPCS block is full, and also, the writing operation to the EPCS devices must be executed to the entire block.
An integrated SoPC configuration images includes a hardware part that is tightly followed by the software part. They are aligned to the same reference address, which is 0x00 by default. It leads to an address dislocation to the software part of the application mode image, because the application mode image is actually aligned to its header, and at the same time, the RSU dedicated circuit can merely correct the reference address for the hardware part. Therefore, an advanced boot loader is designed to specify where the software part of the application mode image locates, making the whole application mode image operational.
Experiments have been performed so as to verify the practicability of the RSU scheme by means of using a target SoPC with the factory mode image that is stored in EPCS device. A new application mode image with the experiment phenomenon that is different from the factory mode image is sent through CAN, and then saved in the EPCS device following the factory mode image. After triggering a reconfiguration, phenomenon of the new application mode image will take place. As a result, the application mode image has been updated.
2. Materials and Methods
2.1. Overall Design of RSU
Generally speaking, RSU is a process, in which the operator will send a new configuration image through some communication systems to the target, and trigger the reconfiguration of the target by means of using the new configuration image, as demonstrated in
Figure 1.
The proposed RSU scheme is made up of a host computer (upper computer, UC), a USB-CAN hub, an onboard CAN transceiver, a target SoPC (lower computer, LC) working in active serial (AS) programming mode, a piece of electrically erasable read-only memory (E
2PROM), a piece of onboard synchronous dynamic random-access memory (SDRAM), as well as the EPCS device. The connection among them is demonstrated in
Figure 2.
The target SoPC is based on the Nios II embedded softcore processor, and connected with the RSU dedicated circuit, which can be activated in Quartus II and other peripheral controller IPs so as to operate the corresponding peripherals. The EPCS device stores the factory mode and the application mode configuration image. Besides, the RSU dedicated circuit handles the whole configuration process of SoPC.E2PROM stores some parameters for RSU, such as FnAy that indicates whether to load application mode, Add_APP that represents the location of application mode configuration image and WD_TO that indicates RSU watchdog timer time out value. Moreover, the application programs and data run in the SDRAM. UC will first convert the SoPC hardware configuration file (*.sof) and software configuration file (*.elf) into the EPCS programming files (*.flash), and then merges them into a complete SoPC configuration image. After that, the UC will transmit the new application mode image by means of the USB-CAN hub.
The process of switching and loading configuration images is demonstrated in
Figure 3.
To begin with, SoPC automatically loads the factory mode after POR, and the RSU dedicated circuit sends the condition that triggers FPGA into a reconfiguration process if it exits. Then, SoPC reads parameters FnAy, Add_APP, and WD_TO from E2PROM. If FnAy is active, SoPC will begin to load the application mode image from the address of Add_APP, and set the watchdog timer time-out value as WD_TO, otherwise SoPC will stay in the factory mode to perform the RSU process. When SoPC enters RSU process, it should complete updating the application mode image and then trigger the reconfiguration to load it. If any error happens during the reconfiguration process, RSU dedicated circuit will force SoPC to load the factory mode image, and then record the condition that triggers the reconfiguration.
In this scheme, factory mode serves as a refresher and a safe. LC can always enter an exact and active state, and notice the UC when an error is detected. As a result, system reliability is improved. Because all nodes that need RSU are connected together by a single CAN bus, this scheme takes full advantage of the existing resources and suits distributed field control system.
2.2. Optimization of CAN Application Layer Protocol
RSU process makes use of the CAN 2.0B extended data frame, including 29-bit identifier (ID0 ~ID28) and eight-byte data field. In order to make full use of them, ID is classified into seven segments, as demonstrated in
Table 1.
Digital ‘0’ of S0 refers to a frame from the UC, and digital ‘1’ of S0 means a message from a LC. Because digital ‘0’ presents a dominant bit and digital ‘0’ presents a recessive bit, and frames from UC is more important, UC has the higher transmit priority in accordance with the CAN arbitration scheme. If S1 is digital ‘0’, all the nodes should accept this frame, or only the specified nodes should do this. The number of UC is 0, and numbers of LCs increase progressively from 1. S5 indicates the message type, assigning 9 as RSU control messages and 10 as RSU data messages. The remaining IDs are reserved.
In the RSU data frames, the whole eight bytes of data field are pieces of the new SoPC configuration image. In terms of the RSU control frames, the higher four bytes of the data field represent the control type (RSU_CT), and the lower four bytes reveal the control message (RSU_CM). Moreover, RSU_CT and RSU_CM put to use so as to fulfill the shaking hands between UC and LC, configuration parameter transfer, data check, as well as the EPCS device burning command. In conclusion, the definition of RSU_CT between UC and LC is similar, as described in
Table 2. While the definition of RSU_CM is different between UC and LC, as shown in
Table 3.
In order to make full use of the CAN bus, the baud rate is set as 500 kilo bps and the bit timing set is in line with the CAN 2.0B standard strictly. In order to improve the communication efficiency, a hardware filter that is based on IDs is enabled. Thus, every LC only accepts messages from the UC, and UC accepts all messages. The hardware interruption of receiving is enabled, and the message handling program works in the interruption mode. As a result, RSU process does not occupy the core system resource all the time, and also, Nios II can take care of other affairs.
2.3. Flow of Transmitting a Configuration Image
Software for both UC and LC is designed in the style of C/C++. The flow of the RSU process is demonstrated in
Figure 4.
As mentioned above, SoPC enters the factory mode after POR, then UC and LC execute shaking hands by a FRR so as to ensure that the communication is OK. If the handshake check passes, UC stars to transfer the Add_APP by a FAA or quits the RSU process directly and warns the operator through the UC interface. In case LC receives a FAA successfully, it should store the parameter into E2PROM, and then read it back so as to check if data in E2PROM is the same as received. If it is, LC replies FAA OK and UC starts to send the new application configuration image. Otherwise, LC replies FAA failure and UC quits the RSU process so as to warn the operator.
In the configuration image transfer sub-process, UC loads 64 kB to its transmit buffer once, assuming the size of a block is 64 kB. If the remaining data is less than 64 kB, the hexadecimal digit F is used to fill the blanks in the last CAN frame’s data field, because the binary digit 1 is the initial state of EPCS device. Before transmission, UC has to check whether the integrated image has been transmitted by checking the internal pointer of the configuration image. If the transmission is not done, UC will employ the extended data frame to send the current data in buffer. Even if the CAN hardware employs the cyclic redundancy check to enhance its ability of detecting bit errors, it cannot avoid the arbitration error. Therefore, every frame that LC receives is dependable, but it is uncertain whether LC receives all frames or not. In order to handle this risk, whenever a block of data has been sent to LC, a data check will take place by FDC. As a tradeoff between reliability and efficiency, the sum check is applied. Every byte of data filed is regarded as an integer, and the sum of those eight integers is calculated. Furthermore, the total sum occupies four bytes.
Whenever UC sends a FDC, LC has to verify whether the results of data that checks from UC is the same as the results that calculates by itself. If the results match with each other, LC replies to UC that the data check is OK, then UC will continue to send the next block. Otherwise, LC replies to UC that the data check is failed, then UC will send this block again. When the total configuration image is sent, UC will send a FSF so as to inform LC, and execute the last data check. As discussed above, if LC replies to UC that the data check is failed, then UC will send those data again. Besides, if LC replies UC that the last data check is OK, LC will start to write all the data into the E2PROM. When E2PROM writing operation is done, LC will send a FWF so as to notice the operator. As a result, LC will trigger itself to reconfigure from the specified address by means of using the configuration image that is just received.
In terms of the flow, SoPC configuration image which is usually several MB is divided into some parts in the denomination of 64 kB. Even if there is any problem during the communication, it only costs sending a block again instead of sending the total configuration image. Therefore, the risk and cost of transmission error is reduced. Besides, it also indicates that the smaller block size can bring less risk and cost of the transmission error on the condition of enough capacity.
2.4. Design of the Advanced Boot Loader
When a SoPC configuration process begins, the RSU dedicated circuit provides the address where hardware part locates (Add_H), and also, the boot loader calculates the address where software part lies (Add_S) using the equation:
In Formula (1), Lenth_H is the length of hardware part, which is stored in the header of the hardware part. After POR, Add_H is initialized as 0x00 where the hardware part of the factory mode image locates exactly [
25]. In a reconfiguration process, Add_H is in #4 register of RSU dedicated circuit interface (
Table 4). As a result, the default boot loader works for the factory mode image, but unfortunately, it leads to the reference address error for the software part of the application mode image. Therefore, an advanced boot loader should be employed so as to specify where the software part of the application mode image locates. Besides, the flow of design and packaging of the advanced boot loader is demonstrated in
Figure 5.
Qsys is a part of Quartus II design suit. Once the reset vector of Nios II is set to an on-chip memory, Quartus II will look for a hexadecimal-coded file (*.hex) with the same name as that of the on-chip memory. That hexadecimal-coded file contains programs for copying the software part of a configuration image. That is to say, the hexadecimal-coded file is the advanced boot loader.
To begin with, an on-chip memory that is no less than 16 kB should be added to the SoPC, and Nios II reset vector should be set to it in Qsys. Therefore, Quartus II will look for a hexadecimal-coded file (*.hex), which indicates where to carry the code of software part with the same name as the on-chip memory.
As a result, a new project working in Nios II EDS should be built by using the boot loader templates that are downloaded from the Altera company website. The address of software codes, the size of the EPCS device, as well as the size of the memory should be checked in the project. Besides, a hexadecimal-coded file and the advanced boot loader will arise in this project. After putting the hexadecimal-coded file into the working path of Qsys, the compilation in Quartus II results in the generation of the new FPGA device configuration file, with the advanced boot loader for the software part.
Because the advanced boot loader performs the version check by an additional header in the software part, a script named make_flash_image_script.sh is used to pack the software part with the combination of the version information into a binary-coded file (*.bin). Ultimately, a script named bin2flash is used to generate the FLASH programming file from that binary-coded file, so as to form the software part of the application mode image.
2.5. RSU Dedicated Circuit Operation Programs
In terms of the Quartus II 15.0 and later version, the Avalon-MM style interface for RSU dedicated circuit is available. It can realize the corresponding functions by means of modifying its internal registers. The registers of the RSU dedicated circuit interface for the Cyclone IV series devices are described in
Table 4 [
22].
Register #0 indicates which mode now the state machine is in. 0x00 means that now state machine is in the factory mode, and 0x01 refers to the application mode. Besides, register #0 can be read only. Register #1 is used to force the device to pull up the CONF_DONE signal a bit earlier before the total hardware configuration file is copied. Also, register #1 may be useful when there are multi-devices in a configuration network. Register #1 stores the overflow value of the watchdog timer, which can be disabled by writing the binary digit ‘0’ so as to register #3. Register #4 indicates where to load the application mode image. Moreover, writing the binary digit ‘0’ to register #5 enables the internal oscillator. Once the reconfiguration takes place, register #6 will record the reason that triggers FPGA. If one wants to reset the watchdog timer’s counter, write digit ‘1’ to register #7. Furthermore, writing the binary digit ‘1’ to register #8 will trigger SoPC to perform the reconfiguration immediately. Once the watchdog timer is active, it will check whether FPGA is still in control or not by monitoring the internal feedback signal.
According to Nios II EDS, writing and reading operations to the registers that have mentioned above can be achieved by the application programming interfaces (API). Specifically, the functions prototypes are IOWR (base, offset, data) and IORD (base, offset) [
26].
2.6. EPCS Device Operation Programs
EPCS is a flash based device, and Nios II EDS provides API access to it. Function prototypes are alt_flash_open_dev() for purpose of opening the EPCS devices, alt_flash_close_dev() for closing the EPCS device, alt_erase_flash_block() for erasing the EPCS device, alt_write_flash() for writing the EPCS device, as well as alt_read_flash() for reading the EPCS device [
26]. Flow of writing the EPCS device is demonstrated in
Figure 6.
After the EPCS device is opened, the specific block should be erased so as to clear the residual data. In order to ensure that the data has been written correctly, data in the specific block will be read back after the finishing of the writing operation. Data read from the specific block matching data in the receive buffer means the writing operation is succeeded otherwise the writing operation to this block should be performed again. After the total content in the receive buffer has been written into EPCS device, EPCS device will be closed and the receive buffer will be clear.