Presentation on theme: "System on Chip Configuring FPGAs. Firmware and the boot process Booting is a complex process for any system It requires some form of firmware to be available."— Presentation transcript:
System on Chip Configuring FPGAs
Firmware and the boot process Booting is a complex process for any system It requires some form of firmware to be available when the machine receives power The boot process has a number of possible problems –Memory controllers won’t be initialised The code has to be able to run in very small amount of RAM –Quite often can use the processor cache in the earliest phases –Devices won’t be enabled Network booting will require a configured NIC
Booting and Programmable Hardware As FPGAs are volatile devices - based on SRAM –This means that they must be initialised In a traditional architecture the FGPA must be enabled like any other device –Although it has to be configured first Devices can be re-configured In such a system the FPGA can’t be involved in the very early phase of booting –Unless it has an automatic configuration scheme Booting FPGAs has 2 phases –Initialisation Data is downloaded –Configuration The chip goes into a known (programmed) state
FPGA Configuration schemes Configuration SchemeTypical Use Configuration DeviceUse EPC EPROM device to auto configure Passive SerialUse either Microprocessor or vendor specific cable – i.e. byteblaster Passive Parallel SynchronousParallel synchronous microprocessor interface Passive Parallel AsynchronousParallel asynchronous microprocessor interface. Device treated as memory Passive Serial AsynchronousSerial asynchronous microprocessor interface. Joint Test Action Group (JTAG)Configuration through IEEE standard interface
FPGA Configuration schemes There are 2 general approaches, these are selected using the MSEL pin –Active The device requests configuration at boot time –Done using configuration device, used in soft systems –Only done at boot time. –Not very flexible for multiple device and error control can be a problem. –Passive The device is reprogrammed under the control of the microprocessor or external control Can be redone at any time during system uptime. Not all devices support all schemes –JTAG conformance may include test but not reprogramming. For newer, larger devices, parallel programming is preferred to speed up system boot times.
FPGA data files Devices have different sizes –THE FLEX 6K FPGA is 260,000 bits –The EPC devices have to match the device size There are lots of different formats and standards –Some files will have initialisation and configuration information embedded –The vendors expect you to use their download tools, this is not always possible or desirable.
Using configuration devices Is fast and convenient Requires no user intervention Can boot soft system this way Has to be wired up on system build Is not very flexible Limited error handling capabilities Difficult to reconfigure with configuration devices
Using cables Either using the proprietary cables or JTAG interface is really only done in a development environment –It is quite fiddly –It requires a host machine –Can take a long time However it can be done on a dead system!
Altera FLEX 6k configuration For Puppeteer –No configuration device –* Is in JTAG chain But device can only test Programming can be done via JTAG under control of StrongARM –Only some pins are connected Can only use Passive serial –AKA bitbanging Configuration SchemeTypical Use Configuration DeviceUse EPC EPROM device to auto configure Passive SerialUse either Microprocessor or vendor specific cable – i.e. byteblaster Passive Serial AsynchronousSerial asynchronous microprocessor interface. Joint Test Action Group (JTAG) * Configuration through IEEE standard interface
FPGA Passive Serial DATA nCONFIG DCLCK CONF_DONE nSTATUS INIT_DONE FLEX 6000 FPGAStrongArm SA1110 GPIO 17 GPIO 25 GPIO 18 GPIO 23 GPIO 1* CS* * GPIO 1 is used as a input pin for FPGA interrupt handling
FPGA problems Not all the pins are connected –nSTATUS and INIT_DONE, for example It is possible to proceed without them This requires just monitoring the CONF_DONE pin until it goes high, this will require long and inefficient delays Difficult to know if the download has been successful The format of the data is unknown –I am assuming that it is a raw binary file (.rbf) The current FPGA data appears to have a preamble and is 0x180 bytes longer than the current BSP suggests. The Altera documentation is not very forthcoming on file formats as it assumes you are using their tools to create and download the files. But it works :) !
StrongARM GPIO pins To use the GPIO pins we must program various registers Some are re-used later on so need resetting to a specific state We need to know where the data for the device is –It is in FLASH We have to write a program to do the reprogramming –What to do on failure?
.h file for FPGA configuration
Some addresses and constants –All are physical addresses At boot time the MMU is off The udelay function is from uboot A structure for the GPIO pin registers The GPIO pins we will use Some masks