SoC FPGA Bring-up Options - Altera

1 downloads 160 Views 258KB Size Report
This Architecture Brief explains the advantages of multiple boot options and why it ... Possible disadvantages would be
Architecture Brief

SoC FPGA Bring-up Options Introduction The most common method to boot and configure SoC FPGAs is to boot the processor first and then have it configure the FPGA. However, there are cases where having other boot and configuration options may be beneficial. For example independent processor boot and FPGA configuration for the sake of speed, or configuring the FPGA first to secure the system and then boot the processor. Hence, the need for flexibility begins at the boot stage. This Architecture Brief explains the advantages of multiple boot options and why it is important to have a choice of boot and configuration modes. Key aspects of this paper are highlighted in an on-line video series, “Independence Day – CPU boot and FPGA configuration”, which can be found at www.altera.com/socarchitecture.

Multiple Options for Processor Boot and FPGA Configuration There are four options in SoC FPGAs for booting the processor and configuring the FPGA Figure 1.

Figure 1: SoC FPGA Processor Boot and FPGA Configuration Options

Processor boots first, then configures the FPGA

FPGA configures first, CPU boots through FPGA logic SOC Device

SOC Device FPGA

HPS CPU

QSPI /SPI

FPGA

PCle

MMC /SD

QSPI /SPI

NAND Flash

Passive Serial

Config Controller

CPU

Passive Parallel Boot ROM

Scratch RAM

Boot Source

Config Controller

HPS CPU

MMC /SD

Passive Serial Passive Parallel

QSPI /SPI

NAND Flash Config Controller

Boot ROM

Scratch RAM

Configuration Sources

SOC Device

FPGA

QSPI /SPI

Scratch RAM

FPGA configures first, CPU boots from FPGA memory

SOC Device PCle

Boot ROM

AXI

User Specified I/F

Independent processor boot and FPGA configuration (1)

HPS

PCle

(1)

FPGA

QSPI /SPI

Boot Code (RAM/ROM)

Passive Serial Passive Parallel

HPS CPU

Config Controller AXI

Boot ROM

On-chip RAM

All SoC FPGAs support the “CPU first” method (Figure 1, upper left), where the processor boots and then configures the FPGA under software control. This functions like a normal processor boot, except that the processor configures the FPGA as a large peripheral device. An advantage is that existing boot code may translate easily. Possible disadvantages would be if the system has configuration time constraints that will not tolerate a delay while the processor boots, or where there are advantageous functions the FPGA can perform while the processor is still booting. The second option (Figure 1, upper right) has the FPGA configure first and then boots the CPU through an interface in the FPGA logic. This interface could be a standard like PCIe, or a customer interface on the backplane to other proprietary channel. This use mode is common when a system wide controller is used to configure multiple FPGAs in the system. The third option (Figure 1, lower right) has the FPGA configure first and the CPU fetch its boot code from an initialized RAM inside the FPGA fabric. This allows the FPGA to examine and secure the system before allowing the processor to boot, or various other secure boot modes. The fourth option (Figure 1, lower left) is independent processor boot and FPGA configuration. The processor boots from one of its flash memory sources and, independently, the FPGA configures from one of its data sources. The FPGA subsystem can configure in as little as 13 ms, allowing the custom hardware to be up and running nearly immediately.

Table 1: Processor Boot and FPGA Configuration Options in SoC FPGAs Function/Feature

Altera SoC

Vendor B

CPU Boots First, CPU Configures FPGA

Yes

Yes

FPGA Configures First, CPU Boots from FPGA Memory

Yes

No

FPGA Configures First, CPU Boots through FPGA Fabric or Backplane

Yes

No

CPU Boots Independently and FPGA Configures Independently

Yes

No

Table 1 shows the boot modes supported by two SoC FPGA vendors. Currently, the Altera SoC FPGA is the only ARM Cortex-A9 processor-based SoC FPGA designed to support all four options.

Multiple Boot Images Many SoC developers prefer to store boot images in quad SPI Flash due to its inherently reliable NOR technology, relatively low cost, and minimal I/O requirements. In systems in which the processor configures the FPGA, the Flash boot image will contain both hardware and software including, for example, CPU boot code, operating system (OS)/real-time operating system (RTOS), application code and data, and FPGA configuration. Often multiple boot images are desired to support both the “normal” operating image, as well as a “factory” image used to recover the system should a Flash update fail. For example, if the system received a remote update and the Flash image failed to load properly, the system automatically reverts to a known good “factory” image and the update can be retried. Estimates for full boot images software requirements, and hardware images for small, medium, and large FPGA densities are provided in Table 2.

Table 2: Boot Image Size Requirements and Mapping to Quad SPI Devices Software Requirements User Space Code (MB)

Minimal 5

5

Substantial 5

50

50

50

Linux Kernel (MB)

3

3

3

5

5

5

Boot Code (MB)

0.5

0.5

0.5

0.5

0.5

0.5

FPGA Density

Small

Medium

Large

Small

Medium

Large

2.4

6.1

14.4

2.4

6.1

14.4

Single Image (MB)

11

15

23

58

62

70

Dual Image (MB)

22

29

46

116

123

140

Single Image (Quad SPI Devices)

1

1

1

1

1

1

Dual Image (Quad SPI Devices)

1

1

1

1

1

2

Single Image (Quad SPI Devices)

1

1

2

NA

NA

NA

Dual Image (Quad SPI Devices)

2

2

NA

NA

NA

NA

FPGA Hardware Image (MB) Total Storage Required

Altera SoC FGPA

Vendor B

Altera provides a quad SPI interface that supports up to a 4 GB address range, and up to four chip selects. Vendor B’s quad SPI supports a 16 MB address range with up to two chips selects, limiting total boot image size to 32 MB. The amount of available QSPI storage can be a significant factor when considering the space requirements of multiple Flash images containing, hardware, software, and data. Consider the storage requirements for hardware (FPGA configuration) and software (boot, OS and application code) shown above. The amounts vary based on the size of the FPGA, and the complexity of the software. The combined HW + SW storage space can range from 11MB to over 70MB depending on the FPGA design and software application. If you double the storage requirements to allow for multiple boot images the numbers get bigger still. Today, common QSPI devices come in sizes up to 1Gb (128 MB) of storage. Since the Altera SoC QSPI interface has no address limitation (can address up to 4GB), it requires up to 2 QSPI devices for two large Flash images. QSPI interfaces on competing devices have address limitations (some as low as 16MB) which require multiple QSPI devices to support medium sized Flash images. Multiple images, and large images may not be supported at all.

Conclusion

Want to Give it a Try?

For increased flexibility, Altera SoC FPGAs support multiple SoC bring-up options. Each requires different software and FPGA densities, and Altera SoC FPGAs are not limited in terms of size and number of boot images that can be handled.

Try it for yourself using the Altera Cyclone V SoC Development Kit (http://www.altera.com/products/ devkits/altera/kit-cyclone-v-soc.html) or one available from our partners (http://www.altera.com/products/ devkits/cyclone-index.jsp)

Altera Corporation

Altera European Headquarters

Altera Japan Ltd.

Altera International Ltd.

101 Innovation Drive San Jose, CA 95134 USA www.altera.com

Holmers Farm Way High Wycombe Buckinghamshire HP12 4XF United Kingdom Telephone: (44) 1494 602000

Shinjuku i-Land Tower 32F 6-5-1, Nishi-Shinjuku Shinjuku-ku, Tokyo 163-1332 Japan Telephone: (81) 3 3340 9480 www.altera.co.jp

Unit 11- 18, 9/F Millennium City 1, Tower 1 388 Kwun Tong Road Kwun Tong Kowloon, Hong Kong Telephone: (852) 2 945 7000 www.altera.com.cn

Copyright © 2014 Altera Corporation. All rights reserved. Altera, the stylized Altera logo, speciἀc device designations, and all other words and logos that are identified as trademarks and/or service marks are, unless noted otherwise, the trademarks and service marks of Altera Corporation in the U.S. and other countries. All other product or service names are the property of their respective holders. Altera products are protected under numerous U.S. and foreign patents and pending applications, mask work rights, and copyrights. Altera warrants performance of its semiconductor products to current specifications in accordance with Altera’s standard warranty, but reserves the right to make changes to any products and services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly agreed to in writing by Altera. Altera customers are advised to obtain the latest version of device specifications before relying on any published information and before placing orders for products or services. October 2014 ss-01233