07-17-2014 11:23 AM
Hi, I'm having a bit of trouble configuring my XC5VFX130T using the BPI up mode.
I'm using an UT8QNF8M8 64Mbit NOR Flash from Aeroflex, the data width configured to x16. Pin connections are as follows:
Flash_CE_N <--> FPGA AL14 (FCS_B) [Pulled up to 3.3V]
Flash_OE_N <--> FPGA AM13 (FOE_B) [Pulled up to 3.3V]
Flash_WE_N <--> FPGA AM28 (FWE_B) [Pulled up to 3.3V]
Flash_A21 <--> FPGA AL30 (A21)
Flash_A20 <--> FPGA AM29 (A20)
Flash_A19 <--> FPGA N25 (A19)
Flash_A2 <--> FPGA M29 (A2)
Flash_A1 <--> FPGA N13 (A1)
Flash_A0 <--> FPGA P13 (A0)
Flash_DQ15 <--> FPGA AN30 (D15)
Flash_DQ14 <--> FPGA AP30 (D14)
Flash_DQ1 <--> FPGA AK27 (D1)
Flash_DQ0 <--> FPGA AJ26 (D0)
Using iMPACT, I was able to generate a .MCS file from a .bit file that I have loaded successfully onto the FPGA through JTAG, the LED connected on the DONE pin lid up and the software in BRAM ran without a problem.
I also created an XPS project with a Microblaze, an UART, and an EMC flash core and wrote the software that read the .MCS file and load the data into the NOR flash. All bytes were verified using SDK, note that since the MCS file is addressing each byte, I had to swap the bytes before storing into the NOR flash. For example, in the MCS file, if the byte at address 0x00000030 is 0x99, and the byte at address 0x00000031 is 0x55, the data will be saved in the NOR flash at location 0x00000018 with DQ[15:0] being 0x5599.
I then turned off the power, disconnected the JTAG, set the M[2:0] to 010, and turned the power back on. I could see activities on the 3.3V line, as the current consumption fluctuates. The fluctation stops after a minute or so, and I take it to mean that the FPGA has finished reading from the NOR flash.
So here's the PROBLEM:
The LED that was connected to the DONE pin did not light up, and the software that ran when I used the JTAG did not start running, which would make sense, since the lack of assertion of the DONE pin probably means the FPGA did not complete its startup sequence.
The NOR flash can be read from immediately after power-on, according to its datasheet. But to rule out the race condition as the problem, I powered on the board and waited a reasonable amount of time to ensure all power-on sequences are complete, then I push the push-button that was connected to the PROGRAM_B pin. Again, I see the current fluctuation on the VCCIO line, but still, the DONE pin was never asserted after the fluctuation has stopped.
1. The iMPACT report for the MCS file generation
2. Partial MCS file (beginning and end)
3. Partial NOR flash data (beginning and end), address shifted (<< 1) for display and comparison with MCS
07-17-2014 03:48 PM
I'm looking at the MCS file. I understand that there might be some endian issues.
The Xilinx configuration sync word is 0xAA995566. Since you are using a 16-bit interface, then the Xilinx needs to see 0xAA99, 0x5566 for it to recognize the sync.
Looking at your MCS file, I see this: 995566AA
If I'm reading your problem description correctly, then wouldn't the device see 0x5599, 0xAA66?, or maybe it would be 0xAA66, 0x5599? Either way, I'm not see how the data stored in the flash like this yields the correct sync word being sent to the device.
Of course, if the sync word is scrambled, then so is the rest of the data.
07-17-2014 03:51 PM
correction, my above post was looking at the MCS.
Your flash data is
[0x00000030]: 0x5599 [0x00000032]: 0xAA66
The part should see it in this order, which isn't AA995566.
07-17-2014 03:57 PM
also, you are using BPI-UP. Do you have the CCLK terminated properly per UG191?
Is the done pin pulled up to Vcc? If your LED is fed to ground through a resistor, you may need to set the DRIVE_DONE setting in the device in the generate bitfile options of the ISE tools. If you're using EDK, then there is a command line option for this.
07-17-2014 04:05 PM
one final thought, i've never used a MCS file in a non-Xilinx device, not sure if that matters. When we program our non-Xilinx NVM, we use the .bin files, which don't jumble the data like the MCS.
07-17-2014 04:54 PM
Hi Dave, on page 23 of the V5 configuration guide, the sync word on D[15:0] in x16 mode is 0x5599 and 0xAA66. I think the sequence you mentioned are pre-bitswapping.
07-17-2014 04:58 PM
the CCLK pin was is not terminated on the board, since I'm doing asynchronous read, I didn't think it would be an issue. I'll try terminating the pin and set the drive_done option in bitgen. Although the same .bit file was loaded on the FPGA using iMPACT and the DONE pin was asserted. Would converting to MCS file get rid of that setting?
07-17-2014 05:02 PM
One reason we used the MCS was because EMC core in XPS swapped the bits by default, so we went with the format that would be the most convenient. EMC also swap the bits of the address, but the FPGA doesn't seem to do that at startup...