aboutsummaryrefslogtreecommitdiffstats
path: root/fpga/usrp2/opencores/spi_boot/README
diff options
context:
space:
mode:
authorMartin Braun <martin.braun@ettus.com>2020-01-23 16:10:22 -0800
committerMartin Braun <martin.braun@ettus.com>2020-01-28 09:35:36 -0800
commitbafa9d95453387814ef25e6b6256ba8db2df612f (patch)
tree39ba24b5b67072d354775272e687796bb511848d /fpga/usrp2/opencores/spi_boot/README
parent3075b981503002df3115d5f1d0b97d2619ba30f2 (diff)
downloaduhd-bafa9d95453387814ef25e6b6256ba8db2df612f.tar.gz
uhd-bafa9d95453387814ef25e6b6256ba8db2df612f.tar.bz2
uhd-bafa9d95453387814ef25e6b6256ba8db2df612f.zip
Merge FPGA repository back into UHD repository
The FPGA codebase was removed from the UHD repository in 2014 to reduce the size of the repository. However, over the last half-decade, the split between the repositories has proven more burdensome than it has been helpful. By merging the FPGA code back, it will be possible to create atomic commits that touch both FPGA and UHD codebases. Continuous integration testing is also simplified by merging the repositories, because it was previously difficult to automatically derive the correct UHD branch when testing a feature branch on the FPGA repository. This commit also updates the license files and paths therein. We are therefore merging the repositories again. Future development for FPGA code will happen in the same repository as the UHD host code and MPM code. == Original Codebase and Rebasing == The original FPGA repository will be hosted for the foreseeable future at its original local location: https://github.com/EttusResearch/fpga/ It can be used for bisecting, reference, and a more detailed history. The final commit from said repository to be merged here is 05003794e2da61cabf64dd278c45685a7abad7ec. This commit is tagged as v4.0.0.0-pre-uhd-merge. If you have changes in the FPGA repository that you want to rebase onto the UHD repository, simply run the following commands: - Create a directory to store patches (this should be an empty directory): mkdir ~/patches - Now make sure that your FPGA codebase is based on the same state as the code that was merged: cd src/fpga # Or wherever your FPGA code is stored git rebase v4.0.0.0-pre-uhd-merge Note: The rebase command may look slightly different depending on what exactly you're trying to rebase. - Create a patch set for your changes versus v4.0.0.0-pre-uhd-merge: git format-patch v4.0.0.0-pre-uhd-merge -o ~/patches Note: Make sure that only patches are stored in your output directory. It should otherwise be empty. Make sure that you picked the correct range of commits, and only commits you wanted to rebase were exported as patch files. - Go to the UHD repository and apply the patches: cd src/uhd # Or wherever your UHD repository is stored git am --directory fpga ~/patches/* rm -rf ~/patches # This is for cleanup == Contributors == The following people have contributed mainly to these files (this list is not complete): Co-authored-by: Alex Williams <alex.williams@ni.com> Co-authored-by: Andrej Rode <andrej.rode@ettus.com> Co-authored-by: Ashish Chaudhari <ashish@ettus.com> Co-authored-by: Ben Hilburn <ben.hilburn@ettus.com> Co-authored-by: Ciro Nishiguchi <ciro.nishiguchi@ni.com> Co-authored-by: Daniel Jepson <daniel.jepson@ni.com> Co-authored-by: Derek Kozel <derek.kozel@ettus.com> Co-authored-by: EJ Kreinar <ej@he360.com> Co-authored-by: Humberto Jimenez <humberto.jimenez@ni.com> Co-authored-by: Ian Buckley <ian.buckley@gmail.com> Co-authored-by: Jörg Hofrichter <joerg.hofrichter@ni.com> Co-authored-by: Jon Kiser <jon.kiser@ni.com> Co-authored-by: Josh Blum <josh@joshknows.com> Co-authored-by: Jonathon Pendlum <jonathan.pendlum@ettus.com> Co-authored-by: Martin Braun <martin.braun@ettus.com> Co-authored-by: Matt Ettus <matt@ettus.com> Co-authored-by: Michael West <michael.west@ettus.com> Co-authored-by: Moritz Fischer <moritz.fischer@ettus.com> Co-authored-by: Nick Foster <nick@ettus.com> Co-authored-by: Nicolas Cuervo <nicolas.cuervo@ettus.com> Co-authored-by: Paul Butler <paul.butler@ni.com> Co-authored-by: Paul David <paul.david@ettus.com> Co-authored-by: Ryan Marlow <ryan.marlow@ettus.com> Co-authored-by: Sugandha Gupta <sugandha.gupta@ettus.com> Co-authored-by: Sylvain Munaut <tnt@246tNt.com> Co-authored-by: Trung Tran <trung.tran@ettus.com> Co-authored-by: Vidush Vishwanath <vidush.vishwanath@ettus.com> Co-authored-by: Wade Fife <wade.fife@ettus.com>
Diffstat (limited to 'fpga/usrp2/opencores/spi_boot/README')
-rw-r--r--fpga/usrp2/opencores/spi_boot/README170
1 files changed, 170 insertions, 0 deletions
diff --git a/fpga/usrp2/opencores/spi_boot/README b/fpga/usrp2/opencores/spi_boot/README
new file mode 100644
index 000000000..926b35bff
--- /dev/null
+++ b/fpga/usrp2/opencores/spi_boot/README
@@ -0,0 +1,170 @@
+
+README for the spi_boot core
+============================
+Version: $Date: 2005/04/14 21:32:58 $
+
+
+Description
+-----------
+
+The SD/MMC Bootloader is a CPLD design that manages configuration and
+bootstrapping of FPGAs. It is able to retrieve the required data from
+SecureDigital (SD) cards or MultiMediaCards (MMC) and manages the FPGA
+configuration process. SD cards as well as MMCs are operated in SPI mode which
+is part of both standards thus eliminating the need for dedicated
+implementations. The SD/MMC Bootloader fits both. Beyond configuration, this
+core supports a bootstrapping strategy where multiple images are stored on one
+single memory card.
+For example consider a system completely based on SRAM. The bootloader
+provides the initial configuration data from the first image to the FPGA. This
+image contains a design which pulls the next image from the memory card and
+transfers this data to SRAM. In the third step the final FPGA design is loaded
+from the third image.
+These images are clustered in sets which can be selected by external switches
+for example. Several configuration sets can be stored on one memory card
+allowing you to provide a number of applications which are downloaded quickly
+to the FPGA.
+The schematic (rev. B) shows how the core can be used with an FPGA board. I
+use it to configure/boot the Xilinx Spartan IIe on BurchED's B5-X300
+board. SV2 fits the "SERIAL MODE" connector on this board but you will have to
+add a separate wire from R6 to attach INIT. Please check the proper use of the
+pull-up resistors for your specific board.
+
+
+Features
+--------
+
+* Configuration mode: configures SRAM based FPGAs via slave serial mode
+ (Xilinx and Altera)
+* Data mode: provides stored data over a simple synchronous serial interface
+* Broad compatability using SPI mode
+ + SecureDigital cards using dedicated initialization command
+ + MultiMediaCards (see below)
+* Operation triggerd by power-up or card insertion
+* Multiple configuration sets stored on on single memory card
+
+
+Compatability
+-------------
+
+These cards have been tested with the SD/MMC Bootloader:
+
+ * Hama 64 MB SD
+ * SanDisk 128 MB SD
+ * SanDisk 64 MB MMC
+ * Panasonic 32 MB SD
+
+Some MMC might fail with this core as not all cards support CMD18
+(READ_MULTIPLE_BLOCK). Please consult the data sheet of your specific
+model. In case your MMC does not implement CMD18 you might want to have a look
+at the FPGA MMC-Card Config project.
+
+
+Tools
+-----
+
+Downloading the configuration data to the card is a straight forward
+process. The images have to be written starting at dedicated locations. For
+the provided toplevel designs, these locations are multiples of 256 K. I.e. 0,
+0x40000, 0x80000 and so forth.
+
+dd (part of the GNU coreutils) serves this purpose:
+$ dd if=ram_loader.bin of=/dev/sdX bs=512
+$ dd if=pongrom_6.bin of=/dev/sdX bs=512 seek=512
+$ dd if=pacman.bin of=/dev/sdX bs=512 seek=1024
+
+The name of the device node depends on how the card reader is attached to the
+kernel. For Linux systems this is most often something like /dev/sdX with X
+ranging from a-z. Please note that it is essential to use the device without
+any trailing numbers as they refer to partitions leading to wrong offsets for
+data written to the card.
+All this works perfectly for my Spartan IIe device as this FPGA expects the
+configuration data as it is delivered from the card: Consecutive bytes each
+with its most significant bit first. Altera devices like the FLEX family are
+different here. They expect the bytes with least significant bit
+first. Therefore, the configuration data has to be swapped bitwise before it
+is written to the card.
+
+
+Verification
+------------
+
+The spi_boot core comes with a simple testbench that simulates an SD/MMC
+card. All four implementations of the core are verified there in parallel
+while transferring the data for several sets.
+You should normally not need to run the testbench. But in case you modified
+the VHDL code the testbench gives some hints if the design has been broken.
+
+
+Directory Structure
+-------------------
+
+The core's directory structure follows the proposal of OpenCores.org.
+
+spi_boot
+ |
+ \--+-- doc : Documentation
+ | |
+ | \-- src : Source files of documentation
+ |
+ +-- rtl
+ | |
+ | \-- vhdl : VHDL code containing the RTL description
+ | of the core.
+ |
+ +-- bench
+ | |
+ | \-- vhdl : VHDL testbench code.
+ |
+ \-- sim
+ |
+ \-- rtl_sim : Directory for running simulations.
+
+
+RAM Loader
+----------
+
+Directory rtl/vhdl/ram_loader contains the sample design which loads the next
+image from the card and stores its contents to external asynchronous
+RAM. After reading 64 KB it triggers a new configuration process for the final
+FPGA design.
+Refer to the code for the mechanisms involved.
+
+
+Compiling the VHDL Code
+-----------------------
+
+VHDL compilation and simulation tasks take place inside in sim/rtl_sim
+directory. The project setup supports only the GHDL simulator (see
+http://ghdl.free.fr).
+
+To compile the code simply type at the shell
+
+$ make
+
+This should result in a file called tb_behav_c0 which can be executed as any
+other executable.
+
+The basic simple sequence list can be found in COMPILE_LIST. This can be
+useful to quickly set up the analyze stage of any compiler or
+synthesizer. Especially when synthesizing the code, you want to skip the VHDL
+configurations in *-c.vhd and everything below the bench/ directory.
+
+
+References
+----------
+
+ * SanDisk SD Card Product Manual
+ http://www.sandisk.com/pdf/oem/ProdManualSDCardv1.9.pdf
+
+ * SanDisk MMC Product Manual
+ http://www.sandisk.com/pdf/oem/manual-rs-mmcv1.0.pdf
+
+ * Toshiba SD Card Specification
+ http://i.cmpnet.com/chipcenter/memory/images/prod055.pdf
+
+ * BurchED
+ http://burched.biz/
+
+ * FPGA MMC-Card Config project
+ http://www.opencores.org/projects.cgi/web/mmcfpgaconfig/overview