... | ... | @@ -71,25 +71,151 @@ In order to remotely reprogram a Xilinx FPGA using the |
|
|
|
|
|
-----
|
|
|
|
|
|
## Generating bitstreams for Xilinx FPGA reprogramming
|
|
|
|
|
|
This section gives guidelines on how to generate bitstreams to be used
|
|
|
in MultiBoot designs.
|
|
|
|
|
|
### General guidelines
|
|
|
|
|
|
First and foremost, **all bitstreams must have** the **-g
|
|
|
reset\_on\_error** flag set when generating the bitstream. Otherwise, in
|
|
|
case of an error in the MultiBoot bitstream, the reconfiguration logic
|
|
|
will not try to load the Golden bitstream.
|
|
|
|
|
|
Early in the design cycle, map your flash memory into three bitstreams:
|
|
|
|
|
|
* header bitstream **always** starts from **address 0** and is
|
|
|
*usually 68 bytes long**
|
|
|
|
|
|
* Golden bitstream usually starts from **address 0x44** (68 in hex),
|
|
|
if generated automatically (see below)
|
|
|
|
|
|
* if generated and changed manually, it should be set on a sector
|
|
|
boundary
|
|
|
|
|
|
* MultiBoot bitstream should be set after the Golden bitstream, on a
|
|
|
sector boundary
|
|
|
|
|
|
As an example, using the M25P32 flash chip to store the three bitstreams
|
|
|
for a Spartan-6 X6SLX45T. The M25P32 has 256-byte pages packed into
|
|
|
256-page sectors, and the X6SLX45T has a 1484472 bytes in the bitstream.
|
|
|
Considering the size of the bitstream, 5799 pages of memory would be
|
|
|
needed, or a total of 23 sectors
|
|
|
|
|
|
The following flash memory map can be used if the Golden bitstream is
|
|
|
automatically generated:
|
|
|
|
|
|
<table>
|
|
|
<tbody>
|
|
|
<tr class="odd">
|
|
|
<td align="center">* Address *</td>
|
|
|
<td align="center">* Bitstream *</td>
|
|
|
</tr>
|
|
|
<tr class="even">
|
|
|
<td align="center">0x000000</td>
|
|
|
<td align="center">Header</td>
|
|
|
</tr>
|
|
|
<tr class="odd">
|
|
|
<td align="center">0x000044</td>
|
|
|
<td align="center">Golden</td>
|
|
|
</tr>
|
|
|
<tr class="even">
|
|
|
<td align="center">0x170000</td>
|
|
|
<td align="center">MultiBoot</td>
|
|
|
</tr>
|
|
|
</tbody>
|
|
|
</table>
|
|
|
|
|
|
On the other hand, should it be desired to manually change the Golden
|
|
|
and Header bitstreams, the following address map can be selected:
|
|
|
|
|
|
<table>
|
|
|
<tbody>
|
|
|
<tr class="odd">
|
|
|
<td align="center">* Address *</td>
|
|
|
<td align="center">* Bitstream *</td>
|
|
|
</tr>
|
|
|
<tr class="even">
|
|
|
<td align="center">0x000000</td>
|
|
|
<td align="center">Header</td>
|
|
|
</tr>
|
|
|
<tr class="odd">
|
|
|
<td align="center">0x010000</td>
|
|
|
<td align="center">Golden</td>
|
|
|
</tr>
|
|
|
<tr class="even">
|
|
|
<td align="center">0x180000</td>
|
|
|
<td align="center">MultiBoot</td>
|
|
|
</tr>
|
|
|
</tbody>
|
|
|
</table>
|
|
|
|
|
|
### Generating the Golden bitstream
|
|
|
|
|
|
Some **bitgen** flags need to be set in order to automatically generate
|
|
|
the golden bitstream during design implementation:
|
|
|
|
|
|
- \-g next\_config\_register\_write Enable
|
|
|
- \-g next\_config\_reboot True
|
|
|
- \-g next\_config\_addr
|
|
|
0x<one byte flash read opcode><three bytes MultiBoot bitstream start address>
|
|
|
- \-g next\_config\_new\_mode Yes
|
|
|
- \-g next\_config\_boot\_mode 001 (to keep SPI master mode
|
|
|
programming)
|
|
|
- \-g golden\_config\_address
|
|
|
0x<one byte flash read opcode><three bytes Golden bitstream start address>
|
|
|
|
|
|
All this can be done from the GUI of Xilinx ISE:
|
|
|
|
|
|
- Right-click **Generate Programming File** in the ISE processes pane
|
|
|
- In the "General Options" tab, select **-g reset\_on\_error**
|
|
|
- In the **Configuration Options** tab:
|
|
|
- Tick "Place MultiBoot Settings into Bitstream"
|
|
|
- Set **-g next\_config\_reboot** to **Enable**
|
|
|
- Set **-g next\_config\_addr** to the MultiBoot bitstream address
|
|
|
- Tick **-g next\_config\_new\_mode**
|
|
|
- Set **-g next\_config\_boot\_mode** to **001**
|
|
|
- Click **OK**
|
|
|
|
|
|
### Generating the MultiBoot bitstream
|
|
|
|
|
|
There are no special constraints on generating the MultiBoot bitstream,
|
|
|
apart from setting the **-g reset\_on\_error** flag. This is done in one
|
|
|
of two ways:
|
|
|
|
|
|
- If running from command line, provide the flag to **bitgen**
|
|
|
- If running from the ISE GUI:
|
|
|
- Right-click **Generate Programming File** in the ISE processes
|
|
|
pane
|
|
|
- In the **General Options** tab, select **-g reset\_on\_error**
|
|
|
- Click **OK**
|
|
|
|
|
|
-----
|
|
|
|
|
|
## Design specification
|
|
|
|
|
|
Some intended features of the **xil\_multiboot** module are:
|
|
|
|
|
|
- modular design
|
|
|
- provide a Wishbone interface, with the potential possibility for
|
|
|
implementing different types of FPGA interconnect (Avalon, AXI,
|
|
|
etc.) to control it
|
|
|
- provide an interface to write to a Flash memory chip
|
|
|
- use the Xilinx ICAP primitive to control configuration logic of the
|
|
|
FPGA
|
|
|
- implement some registers (see [register
|
|
|
map](xil-multiboot#register-map)) for external control
|
|
|
- implement an FSM to control writing to Flash chip and send the IPROG
|
|
|
command to the FPGA
|
|
|
- FSM controlled by bits in multiboot registers
|
|
|
- start with control of Numonyx M25P Flash memories
|
|
|
- gradually migrate design to generic Flash memory (FSM to support
|
|
|
different page/sector size, etc.)
|
|
|
Some features of the **xil\_multiboot** module are:
|
|
|
|
|
|
- provides an interface (via [FAR](xil-multiboot#far) register) to
|
|
|
write FPGA bitstream data to an attached flash memory chip
|
|
|
- registers (see [register map](xil-multiboot#register-map))
|
|
|
accessible from software are used to control operation of the
|
|
|
module:
|
|
|
- writing the bitstream data to the flash chip
|
|
|
- issuing reprogramming command to the FPGA
|
|
|
- reading boot status register from FPGA configuration logic
|
|
|
- uses the Xilinx ICAP primitive to issue reprogramming of the FPGA
|
|
|
(IPROG command [\[1\]](/xil-multiboot#References))
|
|
|
- the FPGA then reconfigures itself from the attached flash
|
|
|
- implements an FSM to control writing to the flash chip and send the
|
|
|
IPROG command to the FPGA
|
|
|
- modular, easily modifiable design
|
|
|
- flash chip is controlled by software, so virtually any SPI flash
|
|
|
chip is supported
|
|
|
- Wishbone interface can easily be replaced by some other
|
|
|
interconnect (e.g., AXI) by implementing the **multiboot\_regs**
|
|
|
module
|
|
|
|
|
|
A block diagram of the **xil\_multiboot** module is shown below. It
|
|
|
consists of the following blocks:
|
... | ... | |