While working with Xilinx FPGA and Vivado design suite, you might come across many binary file formats. Most of them are the legacy formats, developed by Intel, Motorola and various other companies. These formats became defacto standard over time, although the eeproms made by Intel and Motorola are obsolete, and so the programmers.The .mcs, .rbt, and others are ASCII representations (ASCI 1 = 31H, and ASCII 0=30H) with headers, comments, etc. The .bin, .bit are binary files: all single bits, 1’s and zeros.
A .bin is used to program the part using an Impact programming cable (JTAG or parallel), and a .rbt is the file readback when doing verify Impact (also provide a .bin readback file which is not equal to the .bin file used to program the part!). The MCS file is a HEX file where two ASCII chars are used to represent each byte of data. And the binary file of course just contains just the raw byte stream, in sequence. So the MCS file seems less efficient because it takes 2 bytes to represent 1 byte. But it has a couple of advantages (1) It has a checksum at the end of each line for integrity. (2) Each line includes the address where the line should be located in memory. So for example, if an MCS file contains a few segments located far apart in address space, it can be small while the equivalent binary file might be huge because it would have a lot of 0x00 or 0xFFs to fill the space between segments.
Going Beyond the discussion of file format, one may be very familiar with the .bit file which can be directly loaded to FPGA using hardware manager. But its volatile. This means every time board is powered on, it’s like a clean slate you have to program again. Also if you are using SDK one more step is added i.e loading the elf file. Although this feature is handy for debugging purpose. you can update the code and reprogram it multiple time. When it comes to production this route can’t be followed. we require our program to be non-volatile. To do so we can load the program in flash memory using memory configuration file.
So let’s assume that our VHDL/Verilog code is ready and tested. Also if it requires micro-blaze coding, it has also been done and tested. And the development board you are using is also having a self configuring memory device. Now we can start by merging the two files, project.bit file, and project.elf file which can be easily located inside Implementation and SDK directories respectively. If soft code is not used in programming then first three steps can be omitted.
Step 1: Associate elf file.
Associating ELF created from SDK with bit file
Step 2: Re-run implementation
Step 3:Generate bit-stream
Step 4:Generate memory Configuration file
Memory configuration file generation setting
- Select the appropriate memory device based on the board used
- Locate the Bit file
- Set the output location and filename
- Select the programming method
- Check Write checksum and overwrite
- Apply and generate
Step 5: Program
Loading the MCS file
- Open Hardware manager
- Add Memory Configuration device
- Program and verify memory configuration device
Step 6: Remove JTAG cable
Step 7: Restart the board
Your program should load within a minute, indicated by done LED. Loading time may vary based on the programming method selected in Step 4, and size of your program. Now you are ready to deploy the FPGA in the field. Why not try it now.
Nice and informative article.