git.gag.com Git - debian/gnuradio/blob - usrp2/fpga/opencores/spi_boot/README

   1
   2 README for the spi_boot core
   3 ============================
   4 Version: $Date: 2005/04/14 21:32:58 $
   5
   6
   7 Description
   8 -----------
   9
  10 The SD/MMC Bootloader is a CPLD design that manages configuration and
  11 bootstrapping of FPGAs. It is able to retrieve the required data from
  12 SecureDigital (SD) cards or MultiMediaCards (MMC) and manages the FPGA
  13 configuration process. SD cards as well as MMCs are operated in SPI mode which
  14 is part of both standards thus eliminating the need for dedicated
  15 implementations. The SD/MMC Bootloader fits both. Beyond configuration, this
  16 core supports a bootstrapping strategy where multiple images are stored on one
  17 single memory card.
  18 For example consider a system completely based on SRAM. The bootloader
  19 provides the initial configuration data from the first image to the FPGA. This
  20 image contains a design which pulls the next image from the memory card and
  21 transfers this data to SRAM. In the third step the final FPGA design is loaded
  22 from the third image.
  23 These images are clustered in sets which can be selected by external switches
  24 for example. Several configuration sets can be stored on one memory card
  25 allowing you to provide a number of applications which are downloaded quickly
  26 to the FPGA.
  27 The schematic (rev. B) shows how the core can be used with an FPGA board. I
  28 use it to configure/boot the Xilinx Spartan IIe on BurchED's B5-X300
  29 board. SV2 fits the "SERIAL MODE" connector on this board but you will have to
  30 add a separate wire from R6 to attach INIT. Please check the proper use of the
  31 pull-up resistors for your specific board.
  32
  33
  34 Features
  35 --------
  36
  37 * Configuration mode: configures SRAM based FPGAs via slave serial mode
  38   (Xilinx and Altera)
  39 * Data mode: provides stored data over a simple synchronous serial interface
  40 * Broad compatability using SPI mode
  41     + SecureDigital cards using dedicated initialization command
  42     + MultiMediaCards (see below)
  43 * Operation triggerd by power-up or card insertion
  44 * Multiple configuration sets stored on on single memory card
  45
  46
  47 Compatability
  48 -------------
  49
  50 These cards have been tested with the SD/MMC Bootloader:
  51
  52   * Hama 64 MB SD
  53   * SanDisk 128 MB SD
  54   * SanDisk 64 MB MMC
  55   * Panasonic 32 MB SD
  56
  57 Some MMC might fail with this core as not all cards support CMD18
  58 (READ_MULTIPLE_BLOCK). Please consult the data sheet of your specific
  59 model. In case your MMC does not implement CMD18 you might want to have a look
  60 at the FPGA MMC-Card Config project.
  61
  62
  63 Tools
  64 -----
  65
  66 Downloading the configuration data to the card is a straight forward
  67 process. The images have to be written starting at dedicated locations. For
  68 the provided toplevel designs, these locations are multiples of 256 K. I.e. 0,
  69 0x40000, 0x80000 and so forth.
  70
  71 dd (part of the GNU coreutils) serves this purpose:
  72 $ dd if=ram_loader.bin of=/dev/sdX bs=512
  73 $ dd if=pongrom_6.bin of=/dev/sdX bs=512 seek=512
  74 $ dd if=pacman.bin of=/dev/sdX bs=512 seek=1024
  75
  76 The name of the device node depends on how the card reader is attached to the
  77 kernel. For Linux systems this is most often something like /dev/sdX with X
  78 ranging from a-z. Please note that it is essential to use the device without
  79 any trailing numbers as they refer to partitions leading to wrong offsets for
  80 data written to the card.
  81 All this works perfectly for my Spartan IIe device as this FPGA expects the
  82 configuration data as it is delivered from the card: Consecutive bytes each
  83 with its most significant bit first. Altera devices like the FLEX family are
  84 different here. They expect the bytes with least significant bit
  85 first. Therefore, the configuration data has to be swapped bitwise before it
  86 is written to the card.
  87
  88
  89 Verification
  90 ------------
  91
  92 The spi_boot core comes with a simple testbench that simulates an SD/MMC
  93 card. All four implementations of the core are verified there in parallel
  94 while transferring the data for several sets.
  95 You should normally not need to run the testbench. But in case you modified
  96 the VHDL code the testbench gives some hints if the design has been broken.
  97
  98
  99 Directory Structure
 100 -------------------
 101
 102 The core's directory structure follows the proposal of OpenCores.org.
 103
 104 spi_boot
 105  |
 106  \--+-- doc                 : Documentation
 107     |    |
 108     |    \-- src            : Source files of documentation
 109     |
 110     +-- rtl
 111     |    |
 112     |    \-- vhdl           : VHDL code containing the RTL description
 113     |                         of the core.
 114     |
 115     +-- bench
 116     |    |
 117     |    \-- vhdl           : VHDL testbench code.
 118     |
 119     \-- sim
 120          |
 121          \-- rtl_sim        : Directory for running simulations.
 122
 123
 124 RAM Loader
 125 ----------
 126
 127 Directory rtl/vhdl/ram_loader contains the sample design which loads the next
 128 image from the card and stores its contents to external asynchronous
 129 RAM. After reading 64 KB it triggers a new configuration process for the final
 130 FPGA design.
 131 Refer to the code for the mechanisms involved.
 132
 133
 134 Compiling the VHDL Code
 135 -----------------------
 136
 137 VHDL compilation and simulation tasks take place inside in sim/rtl_sim
 138 directory. The project setup supports only the GHDL simulator (see
 139 http://ghdl.free.fr).
 140
 141 To compile the code simply type at the shell
 142
 143 $ make
 144
 145 This should result in a file called tb_behav_c0 which can be executed as any
 146 other executable.
 147
 148 The basic simple sequence list can be found in COMPILE_LIST. This can be
 149 useful to quickly set up the analyze stage of any compiler or
 150 synthesizer. Especially when synthesizing the code, you want to skip the VHDL
 151 configurations in *-c.vhd and everything below the bench/ directory.
 152
 153
 154 References
 155 ----------
 156
 157   * SanDisk SD Card Product Manual
 158     http://www.sandisk.com/pdf/oem/ProdManualSDCardv1.9.pdf
 159
 160   * SanDisk MMC Product Manual
 161     http://www.sandisk.com/pdf/oem/manual-rs-mmcv1.0.pdf
 162
 163   * Toshiba SD Card Specification
 164     http://i.cmpnet.com/chipcenter/memory/images/prod055.pdf
 165
 166   * BurchED
 167     http://burched.biz/
 168
 169   * FPGA MMC-Card Config project
 170     http://www.opencores.org/projects.cgi/web/mmcfpgaconfig/overview