05-19-2011 10:17 AM
I'm unsing a minimodule plus with V5FXT70 FPGA and an 32MB Flash on board.
Now I try to get my FPGA configuration (.bit File) and PPC Software (.elf File) into that same flash.
As far as I understood the theory, I need to
1) include a bootloader into the .bit file which then loads the PPC code from the flash into the SDRAM.
2) then I need to convince the tools to program the .bit file and the Software (.elf file converted to SREC file) into the flash.
Now where do I get that bootloader from? The "Program Flash" Dialog of the 13.1 SDK does not offer the "generate bootloader" option which I saw in the EDK 11 manuals.
Then there is the question how to get the .bit AND the .elf into that same Flash:
When I try to create an MCS with Impact 13.1 from the .bit file and the .SREC file (added as data file), impact always crashes (with no error message, just crashes utterly).
When I program the .bit into the flash using Impact, the FPGA configures itself correctly from the flash after a reboot.
But when I then write the .elf into the flash with the SDK (specifying an offset of 0x200000 which should be large enough to not overwrite the .bit), the .bit still gets somehow destroyed, at least the FPGA does not configure itself anymore after a reboot.
What am I doing wrong here?
Any hints would be highly appreciated!
Solved! Go to Solution.
05-19-2011 10:55 AM
1) Please take a look at the V5FX70T MMP "Embedded Example Design" on our web site, which includes a bootloader design. To download the design. please go to the www.em.avnet.com/virtex5mini web site and click on the "Support Files & Downloads" (in the lower left hand corner of the page).
2) The Flash address A23 and A24 on this module are configurable, so that you can either drive them with the FPGA RS0/RS1 liines or the FPGA A22/A23. Please install a jumper on pins 2-3 of the JP1 and JP2 so that the Flash address A23/A24 are driven by the FPGA A22/A23 pins.
3) The offset 0x200000 is not enough, this would allow only 16Mb for the FPGA configuration data and the V5FX70T device has over 27Mb of configuration data.
4) Make sure in iMPACT to select "BPI Flash > Configure Single FPGA" in the Step 1 of the PROM File Formatter.
05-20-2011 10:47 AM
Thanks a lot for this very valuable information!
0x200000 indeed was not enough offset, but 0x400000 is, as the V5FXT70 has 3.3MB of configuration data (according to Xilinx UG191, and that's also the size of the .bit files).
I still didnt get Impact to combine the .bit and the .elf, but that wasn't necessary in the end as I used Impact only to program the .bit file, and had SDK convert the .elf to an SREC and write it to offset 0x400000 of the flash.
Finally I got everything up and running, and I would suggest to add to the otherwise very good manual of the example the hint that the download.bit created by SDK during the "Program FPGA" process described on p.18 can be flashed into the FPGA using Impact to get a fully self-contained (JTAG and SystemACE independent) solution.
One question remains:
With jumpers JP2 and JP3 installed on 2-3, I disable the multiboot capability for the FPGA and with that at the same time the error fallback which I would like to use.
Now I am not sure how I can use multiboot and still also boot the PPC from the flash.
From the schematics of the MMP I can see, that for some reason A23 and A24 of the flash are connected via the jumpers to either A22 and A23 or the RSI pins of the FPGA, (while A24 of the FPGA is connected to A0 of the flash).
If I understand the BPI_RSI logic correctly, that means that the RSI pins add 0x200000 0x400000 or 0x600000 to the flash address, allowing the device to boot from 0xFC000000, 0xFC200000, 0xFC400000 or 0xFC600000 (with 0xFC000000 being the flash base address).
Am I mistaken if I assume that this means I can use only one fourth of the remaining flash, as e.g. 0xFD0, 0xFD2, 0xFD4 etc. would address the same physical space in the flash (as A22 and A23 of the FPGA are not connected to the flash)?
Can you give me any information on how this scheme is meant to be used?
Thank you very much,
05-20-2011 12:02 PM
You are welcome.
The Flash on the MMP can be used in x8 or x16 mode using the Flash BYTE# signal (we used the Flash in the x16 mode). Since the Flash is used in x16 mode, the A0 of the Flash device becomes unused, hence, the Flash A1-A24 will address 16MB of address space (16MB x 16-bits will give you 32MB of Flash). So, in the x16 mode, the FPGA A0-A23 is connected to the Flash A1-A24.
The Flash A23/A24 can be driven by the FPGA A22/A23 or the FPGA RS0/RS1 via jumpers. These jumpers are used for iMPACT programming purposes only. During the Flash programming, iMPACT is not capable of driving the RS0/RS1 lines, so, during programming Flash A23/A24 must be driven by the FPGA A22/A23 (via the jumpers) so that iMPACT can correctly program the Flash device. Once the Flash is programmed, you can move the jumpers so that FPGA RS0/RS1 lines drive the Flash A23/A24 lines. This will allow you to use the multi-boot functionality of the V5FXT device.
So, the RS0/RS1 signals, divide the 32MB of Flash into 4 8MB sections, which means, the FPGA configuration in BPI mode can start at address 0MB, 8MB, 16MB, or 24MB. Within each 8MB, you can still use the unused Flash for user data. So, user data space will be 24MB + (8MB - FPGA Config data).
Regarding the FPGA A24 being connected to the Flash A0, since FPGA A24 is not used for the Flash interface (we only use FPGA A0-A23 for the Flash interface), the FPGA A24 simply becomes a general-purpose I/O, which we are using to drive the Flash A0 line in case a user wants to interface to the Flash using the x8 mode.
05-23-2011 05:04 AM
thank you for the explanation, things are clearer now, but I still don't understand how I can use 24MB for user data: if the top 2 adress lines are controlled by the RS lines, how can I ever access adresses outside the currently selected 8MB block?
And then there is a new question: is it possible to use the Flash in x8 mode? And how would I do that?
I read in the Virtex-5 configuration user guide that bitstream encryption is not available with x16 mode.
05-23-2011 05:24 AM
The RS lines drive the Flash A23/A24 address lines during the configuration only. After configuration, the RS lines become general-purpose I/O, so that you can drive them to any state you want in your Flash interface.
You can use the Flash in the x8 mode by driving the Flash BYTE# signal low. Please keep in mind that the Flash on the module can only be used in the x8 mode after configuration as the Flash on this module is wired for the BPI x16 mode (FPGA A0 is connected to the Flash A1, etc).
05-23-2011 08:09 AM
So that means I cannot use bitstream encryption with this module, because the Virtex-5 only supports encryption with x8 mode during configuration. Too bad.
But thank you for all the explanations!
05-27-2011 05:15 PM
First, I want to thank both of you for these questions and answers. I was also having trouble getting both the program and FPGA configuation loaded into the Flash. (The bootloader documentation does not include the program offset).
So there no way to encypt the conifguration file? I had assumed that encryption was supported since the V5 mini-module provides a pin connection to the VBAT line. This seems like a (serious) design flaw. Unlike a development board, these mini-modules are intended to be part of shipping products. The ablility to encrypt the FPGA configuration is key.
05-27-2011 06:31 PM
The mini module plus is designed to support PCIe applications via using the V5 GTX transceiver along with the V5 integrated PCIe hard IP. In PCIe applications, an End-Point device, such as a board that utilizes the mini module plus must be ready for the Host PCIe enumeration in 100ms after power has been applied to the system and the system reset (motherboard reset) has been removed (this time is 200ms for motherboards that use ATX power supply). This means, the FPGA on the mini module plus must be configured and ready in 100ms/200ms.
In order to achieve the configuration time for PCIe applications, we had to use a x16 BPI interface (x8 does not meet the configuration time for PCIe applications, 100ms or 200ms). So, we could only meet one objective, either meet the configuration time for PCIe or support encryption. The PCIe configuration time most definitely had the higher priority.
With that said, it may not be a idea to open a web case on the Xilinx web site and ask Xilinx why encryption is not supported for x16 configuration memory interface.
05-27-2011 11:04 PM
Thanks for the quick reply. Your design choice makes sense given the PCIe priority. I migrated to this device from the Virtex-4 mini-module so I assumed that the encryption would still be supported. I should have been more diligent with my evaluation. Thanks again for your help and I'll ask Xilinx if there are any work-arounds.