Overview

Xilinx® Spartan®-3 generation Field Programmable Gate Arrays (FPGAs) are highly
flexible, reprogrammable logic devices that leverage advanced CMOS manufacturing
technologies, similar to other industry-leading processors and processor peripherals. Like
processors and peripherals, Spartan-3 generation FPGAs are fully user programmable.
For FPGAs, the program is called a configuration bitstream, which defines the FPGA's
functionality. The bitstream loads into the FPGA at system power-up or upon demand by
the system.
The process whereby the defining data is loaded or programmed into the FPGA is called
configuration. Configuration is designed to be flexible to accommodate different
application needs and, wherever possible, to leverage existing system resources to
minimize system costs.
Similar to microprocessors, Spartan-3 generation FPGAs optionally load or boot
themselves automatically from an external nonvolatile memory device. Alternatively,
similar to microprocessor peripherals, Spartan-3 generation FPGAs can be downloaded
or programmed by an external “smart agent”, such as a microprocessor, DSP processor,
microcontroller, PC, or board tester. In either case, the configuration data path is either
serial to minimize pin requirements or byte-wide for maximum performance or for easier
interfaces to processors or to byte-wide Flash memory.
Similar to both processors and processor peripherals, Xilinx FPGAs can be
reprogrammed, in system, on demand, an unlimited number of times. After configuration,
the FPGA
configuration bitstream is stored in highly robust CMOS configuration latches (CCLs).
Although CCLs are reprogrammable like SRAM memory, CCLs are designed primarily
for
data integrity, not for performance. The data stored in CCLs is written only during
configuration and remains static unless changed by another configuration event.

1)Configuration methods
Design Considerations
Before starting a new FPGA design, spend a few minutes to consider which FPGA
configuration mode best matches your system requirements. Each configuration mode
dedicates certain FPGA pins and may borrow others. Similarly, the configuration mode
may place voltage restrictions on some FPGA I/O banks.

Will the FPGA load configuration data itself from external or internal memory
or will an external processor/microcontroller download configuration data?

Spartan-3 generation FPGAs are designed for maximum flexibility. The FPGA either
automatically loads itself with configuration data, like a processor, or alternatively,
another external intelligent device like a processor or microcontroller can download the
configuration data. It is your choice .
The self-loading FPGA configuration modes, generically called Master modes, are
available with either a serial or byte-wide data path as shown in Figure 1-1. The Master
modes leverage various types of nonvolatile memories to store the FPGA's configuration
information. In Master mode, the FPGA's configuration bitstream
typically resides in nonvolatile memory on the same board, generally external to the
FPGA. The FPGA internally generates a configuration clock signal called CCLK and the
FPGA controls the configuration process.
Spartan-3AN FPGAs optionally configure from internal In-System Flash (ISF) memory,
as shown in Figure 1-1c. In this mode, the configuration memory and the control and data
signals are inside the package. Spartan-3AN FPGAs also optionally support all the other
Spartan-3A FPGA configuration modes, as well.
The downloaded FPGA configuration modes, generically called Slave modes, are also
available with either a serial or byte-wide data path. In Slave mode, an external
“intelligent
agent” such as a processor, microcontroller, DSP processor, or tester downloads the
configuration image into the FPGA, as shown in Figure 1-2. The advantage of the Slave
configuration modes is that the FPGA bitstream can reside just about anywhere in the
overall system. The bitstream could reside in Flash, on board, along with the host
processor's code. It could reside on a hard disk. It could originate somewhere over a
network connection. The possibilities are nearly endless.

The Slave Parallel mode, also called SelectMAP mode in other FPGA architectures, is
essentially a simple byte-wide processor peripheral interface, including a chip-select
input and a read/write control input. The Slave Serial mode is extremely simple,
consisting only of a clock and serial data input.
The four-wire JTAG interface is common on many board testers and debugging
hardware.
In fact, the Xilinx programming cables for Spartan-3 generation FPGAs use
the JTAG interface for prototype download and debugging. Regardless of which
configuration mode is ultimately used in the application, it is best to also include a JTAG
configuration path for easy design development.

Does the application use a single FPGA or multiple FPGAs?

Most Spartan-3 generation FPGA applications use a single FPGA. However, some
applications require multiple FPGAs for increased logic density or I/O. Obviously, each
FPGA in a multi-FPGA design could have its own separate configuration source.
However, using a configuration daisy-chain, multiple FPGAs share a single configuration
source.
Daisy-chaining reduces system costs and simplifies programming and logistics.
The most common style is a serial daisy chain, illustrated in Figure 1-3a.
Generally, the first device in the chain may use any one of the configuration modes,
except JTAG mode. When the first device finishes loading its configuration bitstream, it
passes data to the downstream FPGAs via its DOUT serial data output pin.
The JTAG interface also supports multi-FPGA configuration as shown in Figure 1-3b,
The TDO serial data output is connected to the TDI serial data input of the next
device in the chain. The mode select input, TMS, and the clock input, TCK, are common
to all devices in the JTAG chain. The TDO serial data output of the last device in the
chain feeds back to the JTAG connector.
Lastly, Figure 1-3c shows a parallel daisy chain. All of the FPGA connections are
common, except for the chip select inputs, which are unique per FPGA.
.
Will the FPGA or FPGAs be loaded with a single
configuration image or loaded with multiple images?
In most FPGA applications, the FPGA is loaded only when the system is powered on.
However, some applications reload the FPGA multiple times while the system is
operating, with different FPGA bitstreams for different functions. For example, the
FPGA
may be loaded with one bitstream to implement a power-on self-test, followed by a
second bitstream with the final application. In many test equipment applications, the
FPGA is loaded with different bitstreams to execute hardware-assisted tests. In this way,
one smaller FPGA can implement the equivalent functionality of a larger ASIC or gate
array device.
The downloaded or Slave configuration modes easily support reloading the FPGA with
multiple images. However, this is also possible on Spartan-3E and Spartan-3A/3AN/3A
DSP FPGAs using the MultiBoot feature

Bitstream Format
The typical FPGA user does not need a bit-level understanding of the configuration
stream. However, for the purpose of understanding configuration options and for
debugging, an overview of the bitstream format is helpful.
Synchronization Word
Embedded at the beginning of an FPGA configuration bitstream is a special
synchronization word. The synchronization word alerts the FPGA to upcoming
configuration data and aligns the configuration data with the internal configuration logic.
Any data on the configuration input pins prior to synchronization is ignored. Because the
synchronization word is automatically added by the Xilinx bitstream generation software,
this step is transparent in most applications.
Array ID
Next the array ID is embedded in the bitstream so that the FPGA can check that it
matches its internal array ID. This prevents the FPGA from mistakenly attempting to load
configuration data intended for a different FPGA array. For example, the array ID check
prevents an XC3S1000 from being configured with an XC3S200 bitstream.
Data Frames
Next is the internal configuration memory, partitioned into segments called "data
frames."
The Spartan-3 generation configuration memory can be visualized as a rectangular array
of bits. The bits are grouped into vertical frames that are one-bit wide and extend from
the top of the array to the bottom. A frame is the atomic unit of configuration. It is the
smallest portion of the configuration memory that can be written to or read from. The
number and size of frames varies with device size. The total number of configuration bits
for a particular device is calculated by multiplying the number of frames by the number
of bits per frame, and then adding the total number of bits needed to perform the
configuration register writes.
CRC
Next is the Cyclic Redundancy Check (CRC) value. As the configuration data frames are
loaded, the FPGA calculates a CRC value. After the configuration data frames are loaded,
the configuration bitstream issues a Check CRC instruction to the FPGA. If the CRC
value calculated by the FPGA does not match the expected CRC value in the bitstream,
then the FPGA pulls INIT_B Low and aborts configuration.
Reconfiguration and MultiBoot
Overview
Because Spartan®-3 generation FPGAs are reprogrammable, in the system, some
applications reload the FPGA with one or more bitstream images during normal
operation.
In this way, a single, smaller FPGA, reprogrammed multiple times, replaces a much
larger and more expensive ASIC or FPGA programmed just once.
There are a variety of methods to reprogram the FPGA during normal operation. The
downloaded configuration modes inherently provide this
capability. Via an external “intelligent agent” such as a processor, microcontroller,
computer, or tester, an FPGA can be reprogrammed numerous times. The downloaded
modes are available on all Spartan-3 generation FPGA families.
The Spartan-3E and Spartan-3A/3AN/3A DSP FPGA families introduce a new
capability, called MultiBoot, that allows the FPGA to selectively reprogram and reload
its bitstream from an attached external memory.
The MultiBoot feature allows the FPGA application to load two or more FPGA
bitstreams under the control of the FPGA application. The FPGA application triggers a
MultiBoot operation, causing the FPGA to reconfigure from a different configuration
bitstream.
There are differences between MultiBoot on Spartan-3E and Spartan-3A/3AN/3A DSP
FPGAs.
Once a MultiBoot operation is triggered, the FPGA restarts its configuration process as
usual. The INIT_B pin pulses Low while the FPGA clears its configuration memory and
the
DONE output remains Low until the MultiBoot operation successfully completes.
Spartan-3E MultiBoot
After the FPGA configures itself using BPI mode from one end of the parallel Flash
PROM, then the FPGA can trigger a MultiBoot event and reconfigure itself from the
opposite end of the parallel Flash PROM. MultiBoot is only available when using BPI
mode and only for applications using a single Spartan-3E FPGA. MultiBoot does not
support multi-FPGA configuration daisy chains.
By default, the MultiBoot feature is disabled. To use MultiBoot in an application, the
FPGA design must first include a STARTUP_SPARTAN3E design primitive.
To trigger a MultiBoot event, assert a Low pulse lasting at least 300 ns on the MultiBoot
Trigger (MBT) input to the primitive. When the MBT signal returns High after the Low
pulse, the FPGA automatically reconfigures from the opposite end of the parallel Flash
memory.
Figure 14-1 illustrates a simple MultiBoot design example. At power up, the FPGA loads
itself from the attached parallel Flash PROM. In this specific example, the M0 mode pin
is Low so the FPGA configures starting at Flash address 0 and increments through the
PROM memory locations. After the FPGA completes configuration, this example FPGA
application performs a board-level or system test using FPGA logic. If the test is
successful, the FPGA then triggers a MultiBoot event, causing the FPGA to reconfigure
from the opposite end of the Flash PROM memory, in this case starting at address
0xFFFF. The FPGA actually starts at address 0xF_FFFF but the upper four address
bits, A[23:20], are not connected to the PROM in this example. The FPGA addresses the
second configuration image, which in this example contains the FPGA application for
normal operation.
Similarly, the second FPGA application could trigger another MultiBoot event at any
time to reload the diagnostics design from address 0, and so on.

In another potential application, the initial design loaded into the FPGA image contains a
“golden” or “fail-safe” configuration image, which then communicates with the outside
world and checks for a newer FPGA configuration image. If there is a new configuration
revision and the new image verifies as good, the “golden” configuration triggers a
MultiBoot event to load the new image.
When a MultiBoot event is triggered, the FPGA then again drives its configuration pins.
However, the FPGA does not assert the PROG_B pin. The system design must ensure
that no other device drives on these same pins during the reconfiguration process. The
FPGA’s DONE, LDC[2:0], or HDC pins can can be used to temporarily disable any
conflicting drivers during reconfiguration.
Asserting the PROG_B pin Low overrides the MultiBoot feature and forces the FPGA to
reconfigure starting from the end of memory defined by the mode pins.

Spartan-3A/3AN/3A DSP MultiBoot

Starting with the Spartan-3A FPGA family, MultiBoot is expanded and
enhanced to provide additional flexibility and capabilities.
Spartan-3A/3AN/3A DSP MultiBoot supports multiple FPGA bitstream
images beyond just the two images supported on Spartan-3E FPGAs.
The maximum number of FPGA images supported is limited either by the
size of the configuration PROM or the total number of address bits.
> BPI mode supports up to 26 address bits, which addresses up to 64M bytes
or 512M bits.
>SPI mode supports up to 24 address bits, which addressees up to 16M bytes
or 128M bits.
> A Spartan-3A/3AN/3A DSP bitstream, depending on device logic density,
ranges between approximately 0.5M to 11.5M bits per FPGA.
Spartan-3A/3AN/3A DSP FPGAs can MultiBoot between different
configuration modes. For example, the FPGA can initially configure from
parallel Flash using BPI mode, then MultiBoot to a configuration image
stored in SPI serial Flash using Master SPI mode.
The initial configuration image is always located at address 0, regardless
of configuration mode.
Subsequent MultiBoot images can be located anywhere in memory,
aligned to a byte location, with some restrictions.
> If the FPGA is set to wait for the Digital Clock Managers (DCMs) to lock
before finishing configuration, then there must be sufficient padding
between images to allow for this time. The padded region can contain data,
but it cannot contain a valid configuration synchronization word.
> Individual bitstream images may be aligned to a sector or page boundary
within the attached Flash memory device.
A built-in configuration watchdog timer prevents a MultiBoot operation
from “hanging” on an invalid FPGA configuration image.
> If no synchronization word is detected within the watchdog time-out
period, the FPGA automatically returns to and reloads the default, initial
configuration image.

SEE the figure below---

2)Reconfiguration types
a) ON-THE- FLY RECONFIGURATION

b) PARTIAL RECONFIGURATION

c) EXTERNALLY-VISIBLE INTERNAL STATE RECONFIGURATION

a) Without resetting the FPGA, simply by blocking the global clock(GCLK)

To some parts of FPGA, we can change(reconfigure) in the mean time, that part of
the blocked FPGA.

b) keeping any fixed logic unchanged we can change(reconfigure) the variable logic
whenever required simply by blocking the configuration clock(CCLK) to the fixed-
logic part.

c) It’s a type of MULTIBOOTING done by simply having a record of which bit-

stream is currently running and a way of choosing the next bit-stream number .