Optimizing the use of an SPI Flash PROM in Microblaze-Based Embedded Systems

This paper aims to simplify FPGA designs that incorporate Embedded Software Systems using a soft core Processor. It describes a simple solution to reduce the need of multiple non-volatile memory devices by using one SPI (Serial Peripheral Interface) Flash PROM for FPGA configuration data, software code (Processor applications), and miscellaneous user data. We have thus developed a design based on a MicroBlaze soft processor implemented on a Xilinx Spartan-6 FPGA SP605 Evaluation Kit. The hardware architecture with SPI flash was designed using the Xilinx Platform Studio (XPS) and the software applications, including the bootloader, was developed with Xilinx Software Development Kit (SDK). ISE Design Tools prepared by Xilinx Company, is employed to create the files used to program flash memory which are SREC (S-record) file associated with software code, Hexadecimal file for user data, and bootloader file to configure the FPGA and allows software applications stored in flash memory to be executed when the system is powered on. Reading access to the SPI Flash memory is simplified by the use of Xilinx In-System Flash (ISF) library. Keywords—Microblaze; ISF; Bootloader; SREC; Configuration; Bitstream SPI Flash


I. INTRODUCTION
SRAM-FPGAs such as Spartan-6 from Xilinx are configured by loading application-specific configuration data (bitstream) into internal memory (CMOS Configuration Latches), then it must be reconfigured after it is powered down.Spartan-6 can configure itself from an external nonvolatile memory device or they can be configured by an external smart source, such as a DSP processor, or microcontroller.In the Master Mode configuration [1], the FPGA automatically loads itself with configuration data from an external SPI (Serial Peripheral Interface) Flash PROM as shown in figure 1.
On the other hand, many FPGA designs in space applications, automobiles, medical field and industrial control system, incorporate Embedded Software Systems using soft core Processor such as Microblaze and utilize external volatile memory to execute software code.This kind of system must also include a non-volatile memory to store the software code and small amounts of user data.
To simplify system design and reduce cost and consumption, we propose a Microblaze system that stores software code, user data, and configuration data in one SPI Flash device.The figure 2 shows the memory organization used to store multiple blocks of data in the SPI flash PROM:  The configuration section including the bitstream and the bootloader must be stored at address 0x0.
 The software application section can be anywhere in the SPI Flash based on the size of the bitsteam file.The software section start address will be usefull for the boot loader to work.
 The user data section is defined by a synchronization word followed by data.The synchronization word is used because the space memory between software application section and user data section is random.
Our work is based on the concepts described in documentation of Xilinx and Avnet, namely, how to create a Microblaze design with AXI (Advanced eXtensible Interface) system [2][3][4] and how to bootload a software application in BPI (Byte Peripheral Interface) configuration mode and SPI configuration mode [5]  Our contribution lies in:  Defining software flows for appending a PROM file with multiple software sections and one user data section with separate blocks of data for each application.
 Improving the use of Xilinx In-System Flash (ISF) library to read software data and user data from SPI Flash.

II. HARDWARE DESIGN
The MicroBlaze reference system is implemented on the Xilinx Spartan-6 FPGA SP605 Evaluation Kit using Xilinx Platform Studio (XPS) Tool Suite provided by the Embedded Development Kit (EDK) of Xilinx.The architecture shown in figure 3 is created using the Base System Builder (BSB) wizard within XPS and it is based on the AXI interconnect, which operates at 50 MHz.Our design includes the main following IPs cores:  DDR3 SDRAM interface (axi_s6_ddrx) operating at 600MHz.The on-board SDRAM will contain the application program chosen and copied from SPI Flash by bootloader.
 SPI Flash interface (axi_quad_spi) operating at 100MHz.The used Winbond SPI Flash memory W25Q64BV can run up to 80MHz in standard SPI mode, then we changed the C_SCK_RATIO parameter in AXI Quad SPI core to 2 as described in [7] (see figure 4).This will run SPI Flash at 50MHz.
 General Purpose Input Output (axi_gpio) operating at 50MHz and used to communicate with LEDs, DIP switches and Push Buttons.DIP switches will trigger the download and execution of one of the software codes stocked in SPI Flash memory.
 On-chip dual-port blocks RAM (BRAM) using to store the bootloader file.It is designed to be small not to exceed the BRAM limits.This hardware platform has been exported to SDK to be the basis of all software work.

III. SOFTWARE APPLICATIONS AND THEIR FLASH IMAGES
The software applications consist of two C projects based on the Peripheral test application template provided in Software Development Kit (SDK).The template will be customized as follows:  For both applications, we used the same Board Support Package (BSP) after having added and configured the ISF library as shown in figure 5 and described in [8].
 The difference between the two applications lies in the messages sent via UART and the blinking of LEDs.
 The linker script of each application project was updated to allow them to be executed from DDR3 SDRAM memory.
 In each application, we used a set of functions to handle the interaction with the corresponding block of user data.This part will be detailed in section 5 of this paper.www.ijacsa.thesai.orgThen, we create a flash image of each application project that we can store in SPI Flash, and we chose the S-record (SREC) file format.This is the most flexible format since it consists of ASCII character strings, specially formatted for loading software data into memory.This format also allows using the bootloader application template provided in SDK.mb-objcopy command is used to generate a SREC file from the (executable file) ELF of each application as follows: mb-objcopy -O srec Application.elfApplication.srec

IV. THE BOOTLOADER FILE
The hardware bitstream including the bootloader is stored in SPI Flash memory and used to configure the Spartan-6 FPGA.After the FPGA configuration, the processor starts executing the bootloader that will select and copies the executable software from a pre-determined location in SPI Flash to DDR3 SDRAM (Depending on the condition of the DIP switches).
Based on the Spartan-6 Configuration User Guide [1], bitstream file of the used Spartan-6 LX45T has a size of 11,939,296 bits (1458 KB).The Winbond SPI Flash contains 2048 x 4KB sectors, then the bit file will use the first 365 sectors of the flash and the software data sections can be stored from the 366th sector (from the @ 0x16E000).SDK provides a bootloader template which is used for parallel NOR Flash memory.Based on Xilinx documentation [8] and Avnet tutorial [6], we modified this template to read from SPI Flash using the Xilinx In-System Flash (ISF) library.The SPI drivers can be used in polled mode or interrupted mode if interruption was enabled in the AXI Quad SPI core.
In order to create the bitstream file including configuration data and the bootloader executable file (ELF), the following steps are adopted:  We modified bootloader.c, the main source file in project, with the initialization of SPI device and ISF library, and the update of Flash memory reads with ISF Read commands.
 We updated the flash memory offsets for the stored SREC applications in the blconfig.hfile (figure 6).
 The linker script was updated to allow the boot loader to be executed from FPGA BRAMs.Finally, we generate the configuration file with the embedded bootloader by running the data2mem application in command line mode.This command provides the facility to iterate new block RAM data into a bit file without the need to rerun Xilinx implementation tools.In conjunction with a new ELF file and the Block RAM Memory Map (BMM) file, data2mem command (described in [9]) updates the block RAM initialization in a BIT file image and outputs a new bit file.This facility is invoked as follows : data2mem -bm my.bmm -bd code.elf-bt my.bit -o b new.bitAnother possibility is to run the download step in SDK.The program operation (see figure 7) will generate the new bit file (download.bit)even if the board is not connected.

V. THE USER DATA FILE
One flash image will be used to regroup the two user data blocks corresponding to the applications, and we chose the hexadecimal (HEX) format.It contains only data (without addressing) in hexadecimal format.It will not be checked by the check sum as it is not really part of the bitstream file or SREC file, and we may do whatever we wish.
We used a hex editor (the shareware HexEdit [10]) to populate the data.hexfile with respect for the following specific requirements as shown in figure 8:  Every data line must be 16 bytes long.
 Every data number must be represented in hex.
 Put synchronization word (4Bytes) at the start of each user data block.In the example of figure 8, we used the synchronization word 0xD1AFBFCF for the first user data block and 0XD2AFBFCF for the second.
 Each block of data must be 8 bytes long.To use blocks of data with variable size, we can add immediately after the synchronization word, a word which indicates the size of the block followed by the data.This word will be recovered by the software application to set up the reading data routine.www.ijacsa.thesai.orgThe use of the synchronization words allows storing user data file anywhere in the SPI Flash after the software section, and also allows each application to identify its block of user data.Indeed, the software reads through the SPI Flash 1 Byte at a time until it finds a 32-bit word matching the data synchronization word.Once the data synchronization word is found, the software recovers the Start Address of user data block and the first 8 bytes following the synchronization word.The size of 8 bytes is given by way of example and can be modified depending on the application requirements.

VI. PROGRAMMING THE SPI FLASH DEVICE
To program the memory, we have to generate an MCS file (Intel MCS-86 Hexadecimal Format) from the bitstream with boatloader (downoald.bit),the SREC flash images (First_application.srecand Second_application.srec), and the user data file (data.hex).
The MCS file contains ASCII strings that define the storage address and data file.It can be created by the PROMGen command [11] or the iMPACT software.The figure 9 summarize the software flow for creating a MCS file.
We chose iMPACT because it provides a graphical, stepby-step approach.The following steps are followed to create our PROM file: 1) Launch the iMPACT GUI and create a new project with Prepare a PROM file option.
2) In the PROM File Formatter dialog box (figure 10) :  Step1 : select Configure Single FPGA under SPI Flash in Storage Device type.


Step 2 : select 64M and click on the Add Storage Device button.The choice depends on the on board SPI Flash memory.


Step 3 : select a file name, directory location, and Yes for Add Non-Configuration Data Files pull-down.

3) In the next dialog boxes :
 Add one device file by browsing to the your_hw_platform directory and selecting the download.bitfile.
 Add the first data file First_application.srec by indicating the start address 0x170000 (must be greater then 0x16E000). Add the second data file Second_application.srec by indicating the start address 0x180000 (depends on the size of the first data file).
 Add the third data file data.hexanywhere after the second datafile.11, double-click Generate File to create the MCS file : boot_soft_data.mcs.

4) After validating the dialog box Data File Assignment shown in figure
To detect the Spartan-6 FPGA of SP605 Evaluation Kit and program the on board SPI Flash memory, the following steps are followed :  Connect the PC to the USB JTAG connector on the SP605 board, set the mode pins for SPI Flash (M0=1, M1=0), and turn the board power on (see figure 12).

VII. RESULTS AND DISCUSSIONS
A serial terminal program, such as Tera Term or Hyper Terminal, must be set to view the output of the bootloader and the test applications.Make sure before starting the test that, the SPI mode is set, the DIP switches is set at 0x0001 (see figure 13) to run the first application test or 0x1000 to run the second application test.
Press the PROG button (see figure 12) every time we want to re-configure the FPGA.The figure 14 shows running results of the boot loader :   Successful achievement of this work will encourage us to use an SPI Flash memory as mass memory of our on-board computer (for nano-satellite) that will take an SRAM-FPGA as central processor.The embedded platform can be enriched by proposing a fallback and multiboot technique to create a multiple embedded designed systems (multiple configuration sections), always by using a single SPI Flash memory.

Fig. 9 .
Fig. 9. Software flow for creating a MCS file.

Fig. 11 .
Fig. 11.Data File Assignment dialog Box. In iMPACT interface, double-click on the Boundary Scan flow, right-click on the Boundary Scan windows, and select Initialize Chain. Right-click on the Xilinx device detected, and select Add SPI/BPI Device.Browse to directory location selected later in the PROM File Formatter dialog box, and select the generated MCS file. In the Select Attached SPI/BPI dialogue box, select the on board SPI Flash memory (W25Q64BV/CV). To start the programming with the generated MCS file (boot_soft_data.mcs),right-click on the Flash device and select Program.

Fig. 13 .
Fig. 13.DIP switches setting for First application test. After the FPGA configuration, the bootloader downloads one of the test applications in DDR3 SDRAM memory (depending of DIP switches state).The execution of each test application includes peripheral tests, LEDs blinking, and recovery of the specific user data.The start address of application data section and user data block is recovered and printed.If the DIP switches setting differ from 0x0001 and 0x1000 values, a message is printing to indicate no SREC file to load.

Fig. 14 .
Fig. 14.Terminal Window showing test runningVIII.CONCLUSION AND FUTUR WORKSThis paper demonstrates a method concerning the optimization of the SPI flash memory in FPGA designs that incorporate Embedded Software Systems using Microblaze.It is simple to implement and can be used in any embedded system with limited memory resources. [6].