Application Selector Example
The Nios® II Embedded Evaluation Kit, Cyclone® III Edition application selector is a useful utility that allows you to quickly choose, load, and run different applications on the Embedded Evaluation Kit board without needing to connect the board to a computer. Applications are stored using a File Allocation Table file system on a secure digital (SD) card attached to the board and retrieved at load-time. The application selector not only loads new software to the Nios II CPU, but also new hardware to the FPGA. An application consists of both a hardware image and a software image.
In addition to the pre-packaged applications that come with the Nios II Embedded Evaluation Kit, Cyclone III Edition, you can easily convert your own applications to be loadable by the application selector.
Where to Get the Application Selector Example
The Application Selector example is included with the Nios II Embedded Evaluation Kit, Cyclone III Edition, and can also be downloaded from the Altera website. Download the Application Selector Example (.zip) file.
Running the Application Selector
Starting the Utility—To start the application selector, connect power to the Nios II Embedded Evaluation Kit, Cyclone III Edition, and switch on the power (SW1). If the board is already powered, reset the board by pressing the RECONFIGURE button. You may have to press twice to properly reset the board.
The application selector boots from flash memory and a short splash screen appears while the application selector searches for applications on the SD card. After that, the main menu appears and a list of loadable applications are displayed.
When the main menu appears, you see a scrollable list of numbered application names. These are the applications that were found on the SD card and are now available to load. You can highlight any of the applications by touching them. If there are more than five applications on the SD card, you can scroll through the list by touching the scroll-up and scroll-down buttons on the right-hand side of the screen.
Viewing Information About an Application—To get more information about a particular application shown in the selector, highlight the application by touching it on the touch screen, then touch the Show Info button. A scrollable text window appears showing the additional information available (if any) for the application you highlighted. To return to the main menu, touch the OK button.
Loading and Running an Application—When you’ve decided which application you want to load, highlight the name of the application by touching it, then touch the Load button on the touch screen. The application begins loading and a small window is displayed showing the progress of the load. The loading process may take between 2 and 30 seconds, depending on the size of the application and whether it was previously cached in on-board flash memory.
Application Selector Details
SD Card Directory Structure—The application selector uses the SD card purely for the purpose of storing applications. The SD card must be formatted with the File Allocation Table16 file system, and can be any capacity up to 2 Gbytes. Long file names are supported. All loadable applications on the SD Card must be located in a top-level directory named Altera_EEK_Applications.
Under the Altera_EEK_Applications directory, each application is located in its own subdirectory. The name of that subdirectory is important because the selector utility uses that name as the title of the application when displaying it in the main menu. Name the subdirectory as the title you would like shown for your application in the application selector menu. The subdirectory names can be anything, as long as they adhere to the File Allocation Table16 file system long file-name rules. Spaces are permitted.
Application Files—Each loadable application consists of two flash files and an optional text file, all stored on an SD card.
One flash file represents the software portion of the example and must be derived from an .elf file. This flash file can be named anything you like, the only restriction being that the name must end with _sw.flash.
The other flash file represents the hardware portion of the example and must be derived from a .sof file. This file can be named anything you like, the only restriction being that the name must end with _hw.flash.
The optional text file contains additional information about the application. In the application selector utility, touching the Show Info button while your application is highlighted brings up a window showing the text contained in this file. The text can be multiple paragraphs, but should not be excessive in length since the application selector was not designed to scroll through large amounts of text. The name of this text file must be info.txt, or the application selector will not recognize it.
CFI Flash—The application selector uses Common Flash Interface (CFI) flash memory to store hardware images, software images, the application boot code, and a flash image catalog.
- Hardware images—The application selector hardware image is permanently stored in flash memory at offset 0x20000.
Hardware images for the applications being loaded are written to flash memory at load time to an offset between 0x280000 and 0xA00000. The exact location depends on caching. Refer to the Hardware Image Caching section for more details.
- Software images—CFI flash memory stores the software images of both the application selector utility itself as well as software images of applications being loaded. All software images used by the application selector contain a boot copier, which is pre-pended by the elf2flash utility during file conversion process. The boot copier copies the software code to RAM before running it.
The application selector software image is permanently located in flash memory at offset 0x100000.
Software images for the applications being loaded are written to flash memory at load time to offset 0x180000. Software images must be smaller than 1 Mbyte, or they will overwrite the application hardware images located at offset 0x280000.
- Application boot code—All applications that are loaded by the application selector must contain a Nios II embedded processor whose reset address is set to CFI flash memory at offset 0x0. For this reason, a generic bit of boot code is permanently programmed at offset 0x0 in the CFI flash memory. This boot code is very small and only performs the following functions:
- Flushes the Nios II instruction cache
- Flushes the Nios II instruction pipeline
- Branches to offset 0x180000
Offset 0x180000 is where the application software image is located after being loaded by the application selector. When the FPGA is reconfigured, the Nios II processor executes the boot code at offset 0x0, which branches to the pre-pended boot copier of the actual application software image stored at offset 0x180000, which then copies the application to RAM and then runs the application.
- Flash image catalog—The CFI flash memory holds up to 10 of the most recently loaded application hardware images to speed the load times of applications, which are loaded often. To keep track of which hardware images are currently stored in flash memory, a flash image catalog is kept in CFI flash memory at offset 0x8000. The implementation details of this catalog are described in the section of this document titled “Hardware Image Caching”.
Remote Update—The application selector relies heavily on the remote update feature of the Cyclone III FPGA family. The remote update feature allows the Nios II processor, or any other logic in the FPGA, to force the FPGA to reconfigure from a specific location in a parallel flash memory, such as CFI. The application selector is able to reconfigure itself with a new hardware image by using the Nios II processor to read the hardware image from the SD card, program it to some location in CFI flash memory and then, by using the remote update feature, force the FPGA to reconfigure from that location.
Hardware Image Caching—Copying data from the SD card to flash memory is somewhat slow due to both the write-speed of the flash memory device, and the read-speed from the SD card in serial peripheral interface (SPI) mode. However, since the remote update feature allows you to reconfigure the FPGA from anywhere in flash memory, the application selector takes advantage by persistently holding (caching) a certain number of frequently used application hardware images in flash memory to avoid having to copy them from the SD card every time the application is loaded.
The application selector utility can cache up to 10 application hardware images in CFI flash memory. When you choose an application to load from the SD card using the application selector, the application selector first scans through its catalog of hardware images currently cached in flash to see if any of them match the hardware image being requested. If one of them matches, the application selector simply reconfigures from the offset of that image instead of having to first copy the image from the SD card to flash memory. This significantly reduces the load time.
Caching the hardware images requires the application selector to be able to determine if an image in CFI flash memory is the same as the one being requested on the SD card. Reading both images in their entirety to compare their contents takes a significant amount of time and outweighs the benefit received from caching in the first place. So, to determine whether or not a hardware image in flash memory matches a hardware image on the SD card, a 32-bit timestamp value is used as a tag. During the file conversion process, the sof2flash utility inserts a 32-bit timestamp in the hardware image's .flash file as an S0-type record on the first line of the file (the .flash file format is .srec). When the application selector is about to load a hardware image, it inspects the .flash file on the SD card. If the .flash file contains an S0 record on its first line that contains a 32-bit ASCII-encoded number, it is considered to be a valid timestamp tag.
The application selector then scans the flash image catalog for entries which contain a matching timestamp value. If a matching timestamp value is found in the catalog, it means the hardware image about to be loaded is already located in flash memory, and can be used to directly reconfigure the FPGA with no copying necessary. For details on the flash image catalog, refer to the section below titled "Flash Image Catalog".
Flash Image Catalog—The flash image catalog is a simple database that keeps track of what application hardware images are currently stored (cached) in flash memory. The flash image catalog is located in sector 1 of the flash memory at offset 0x8000, and is 0x8000 bytes long.
The catalog mechanism uses a scheme referred to as "Zero = Spent, 'F' = Available" (ZSFA). This scheme avoids erasing entire memory sectors when only a few words need to be written to the flash memory. Using ZSFA, a word in the flash memory that is 0x0 is considered "spent" and cannot be used to store data. A word that is 0xFFFFFFFF is "available" since it is in its erased state. Every other value is considered a valid entry in the catalog.
With ZSFA, whenever a catalog entry needs to be read, the sector is scanned from its lowest address until the first 0xFFFFFFFF value is encountered. Every non-zero value encountered along the way is a valid catalog entry. When a catalog entry needs to be written, the sector is scanned until the first 0xFFFFFFFF value is found, and the new catalog entry is written to that offset.
To erase a catalog entry, you scan for it in the sector, and then write 0x0 to it to mark it as "spent." The sector(s) containing the ZSFA catalog only need to be erased once there are no more “available” data entry spots.
For the application selector, each flash catalog entry consists of two sequential 32-bit words. The first word is the 32-bit timestamp value of a hardware image currently in flash. The second word is the 32-bit flash offset of the image itself. Entries are always created and erased as whole units, two words at a time.
The cache works by storing the most recently loaded hardware images in fixed slots in flash memory. The ZSFA flash image catalog holds the timestamp value and image offset of each hardware image stored in one of those slots. When it's time to load a new hardware image, the application selector compares the timestamp found in the hardware image on the SD card to all the timestamps stored in the ZSFA flash image catalog. If any of them match, it skips copying the hardware image from the SD card since the image is already in flash memory. Instead, it simply reconfigures from the offset of the hardware image in flash memory who's tag is contained the same timestamp. If none of the catalog entries match the timestamp, the hardware image is copied from the SD card into flash memory, and then that hardware image's timestamp is recorded in the flash image catalog.
|
Literature
> 
