FLASH FPGA configuration and data storage


#1

I’d like to use the flash on the XEM6001 for both FPGA configuration and general purpose non-volatile data storage. I’m able to use the OK FlashLoader for FPGA configuration without any problems. However, I’m having problems controlling the FLASH via my own HDL module.

The problem is that I can’t actually set the inputs to the FLASH. For example, I’ve tried tying the flash clock (FPGA pin M9) directly to one of the PLL clocks but when I measure the the clock signal on the flash chip with a scope it is constant high.

Is this somehow related to the MUX? Can anyone provide a description or circuit diagram of how the FLASH is connected to the MUX and/or FPGA? (I’ve tried asserting MUXSEL both high and low without success.) Or is there some other reason this doesn’t work?


#2

dleibran–

Your FPGA HDL should always tie MUXSEL=0. This is what our FlashLoader HDL does.

Are you sure you have your constraints setup properly? (check the Xilinx output pad.txt file)


#3

Pretty sure. Here is the line from the pad.txt file for my test HDL:

|M9 |flash_sck |IOB |IO_L29P_GCLK3_2 |OUTPUT |LVCMOS33 |2 |12 | | | | |LOCATED |NO |NONE |

Is it possible to get a copy of the HDL for your FlashLoader bitfile? That might help me figure out what I’m doing wrong.


#4

Or if you don’t want to give away the FlashLoader HDL, maybe just a copy of the ucf file?


#5

Here are the relevant bits from the xem6001.ucf file (in your Samples folder) that apply to the Flash:

#NET "spi_cs" LOC = "T3" | IOSTANDARD="LVCMOS33"; #NET "spi_clk" LOC = "M9" | IOSTANDARD="LVCMOS33"; #NET "spi_din" LOC = "R9" | IOSTANDARD="LVCMOS33"; #NET "spi_dout" LOC = "T9" | IOSTANDARD="LVCMOS33";Here are (the same – just a couple name changes) relevant bits from our FlashLoader sample:

NET "flash_s_n" LOC = "T3" | IOSTANDARD="LVCMOS33"; NET "flash_c" LOC = "M9" | IOSTANDARD="LVCMOS33"; NET "flash_d" LOC = "R9" | IOSTANDARD="LVCMOS33"; NET "flash_q" LOC = "T9" | IOSTANDARD="LVCMOS33";


#6

Hmm. That seems to be equivalent to mine:

NET “flash_scs” LOC = “T3” | IOSTANDARD=“LVCMOS33”;
NET “flash_sck” LOC = “M9” | IOSTANDARD=“LVCMOS33”;
NET “flash_sdo” LOC = “R9” | IOSTANDARD=“LVCMOS33”;
NET “flash_sdi” LOC = “T9” | IOSTANDARD=“LVCMOS33”;

Any other ideas?


#7

Have you copied the output to another pin and probed that? How about looking at FPGA editor to confirm things are being routed as you expect?


#8

Not really sure what you mean by look at the FPGA editor.

Here’s an example of something that doesn’t work:

The LEDs flash and I measure the proper slow_clk signal on the test_out pin (J4), but nothing shows up on the flash pins.

[CODE]`include “timescale.v”

module FlashTest2(
input wire [7:0] hi_in,
output wire [1:0] hi_out,
inout wire [15:0] hi_inout,
output wire hi_muxsel,

input  wire 		 clk,
output wire [7:0]  led,
input  wire [3:0]  button,

output wire 		 flash_scs,
output wire 		 flash_sck,
output wire 		 flash_sdo,
input  wire 		 flash_sdi,

output wire        test_out

);

///////////////////////////////////////////////////////////////////////////////
// Test the flash pins
assign hi_muxsel = 1’b0; // this always needs to be set to 1’b0 for the OK interface to work

reg [23:0] clk_counter;
wire slow_clk;

always @(posedge clk) begin
clk_counter ;[/CODE]


#9

Sorry… I’m out of ideas at this point. FPGA Editor is a Xilinx product and is part of the ISE tools.

This may be a silly question, but… Are you sure you’re probing the right device and are you sure you’re probing reliably?


#10

Turns out not so silly after all. I was probing the EEPROM instead of the FLASH. I’ve got it working now. Thanks.


#11

I am just starting to look into loading the XEM6001 FPGA from the on-board flash. Would you care to share any HDL examples that are compatible with the FlashLoader C++ example? It appears that you first have to have some HDL that supports programming the flash with the data coming in through a PipeIn (x80) and going out on the six pins marked “spi” in the .ucf file… So once you have a compatible .bit file (which also ties MUXSEL low), you load it over the USB as usual, then the FPGA can accept the data from flashloader.exe and put it in the flash, after which you move the switch on the XEM6001 over to the PROM position and cycle the power so that the FPGA loads from the PROM?

Any guidance would be appreciated.


#12

Okay, sorry, I found the flashloader.bit that is appropriate for the XEM6001 on the downloads page:
http://www.opalkelly.com/download/20111007-FP40-XEM6001.zip
.

To summarize the process for anyone who is interested:
flashloader.exe is installed with the Opal Kelly SDK: typically C:\Program Files\Opal Kelly\FrontPanelUSB\Samples\FlashLoader
Device specific flashloader.bit is available on the Opal Kelly downloads page. For the XEM6001 it is here:
http://www.opalkelly.com/download/20111007-FP40-XEM6001.zip
.

To program the flash on the XEM6001 you need to:

  1. position the switch on the XEM6001 in the USB position
  2. load flashloader.bit into the FPGA using FrontPanel (or whatever program you normally use)
  3. Close FrontPanel (or other application used) so that the handle to the XEM is freed up.
  4. Put flashloader.exe, flashloader.bit, okFrontPanel.dll, and your_design.bit file in the same directory on your computer
  5. open up a command window and run “flashloader your_design.bit” from the command line in that directory
    your_design.bit is now loaded in the PROM
  6. move the switch on the XEM6001 to the PROM position
  7. cycle the power (unplug the USB cable and plug it back in)
    your_design.bit is now loaded in the FPGA and the PROM

The only problem I have is I can’t re-program the flash witout physically moving the switch to the USB position. Although you appear to be able to load a new .bit file into the FPGA over the USB, it seems that at the end of the programming process, the FPGA re-loads the .bit file from the flash… so you can’t keep flashloader.bit in the FPGA long enough to load a different .bit file into the flash.

If anyone would like to share some insight as to what is going on inside flashloader.bit, I’d love to know.
Thanks.


#13

Flashloader.bit is just a simple HDL configuration that lets us shovel data from the PC (using the flashloader application) to a SPI flash device. There’s no magic here – just copy bytes to flash. The Flash datasheet explains exactly how to write data to a SPI flash device.


#14

Magic or no depends on your perspective. I think there may be a little more to it than that… In any case, having a specific example would be of great assistance. Without incorporating that functionality into my HDL, there does not seem to be a way to make the XEM6001 firmware field upgradeable without having physical access to the USB/PROM switch. Can you post the HDL source? Can I buy it?


#15

I am working on a project for the 6010-LX150 board.

I was going to ask if anyone had tried using the flash to bootload a micro into the ram but then I realized the bit file is 4MB on its own without the elf files, the flash is 32Mbit or 4MB it just wont fit

Any suggestions.


#16

I’ve taken a look a the SPI Flash config interface, it appears there is only one on the chip, and its not accessable on the headers. One drastic option would be to take the 32Mbit flash off the board and replace it (not necessarily directly on board) with a larger one.

any thoughts


#17

Possibly the following parts might fit directly on the board
Digikey #
MX25L25635E2N-12G
W25Q128FVEIG-ND


#18

Are you building an add-on board? If so, we would recommend adding this device to your board. It would only consume a handful of pins.

Alternatively, our XEM6310-LX150 is the new USB 3.0 device that is footprint compatible with the XEM6010. It includes two 128Mib Flash devices.


#19

Sure I could put it on my board, however there are no connections to the SPI config interface. Spartan 6 has only one Serial Flash interface whcih is bootable. The only way would be to change the chip.

From what I see in the 6310 user manual, the Flash connected to the FPGA is not connected to the boot interface (can you confirm?)
The other flash is connected to the usb controller.

So does the usb controller load the bit file?


#20

I have used as under and it works, lipsense Flash
NET “flash_s_n” LOC = “T3” | IOSTANDARD=“LVCMOS33”;
NET “flash_c” LOC = “M9” | IOSTANDARD=“LVCMOS33”;
NET “flash_d” LOC = “R9” | IOSTANDARD=“LVCMOS33”;
NET “flash_q” LOC = “T9” | IOSTANDARD=“LVCMOS33”;