Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
12 years ago

MAXII + PFL + CFI Flash word-programming format?

Another day, another problem!

My design uses the PFL in a MAXII to load either a user configuration or factory configuration from a P30 flash via FPP. When programming the flash via JTAG/MAXII/PFL both configurations work. If the user configuration is programmed, the FPGA will configure from the user configuration. If erasing the user configuration via JTAG/MAXII/PFL the Cyclone IV GX FPGA configures from the factory configuration. In short; the JTAG access to the flash works correctly. Each configuration design is designed to light up one of two LEDs on the Cyclone IV GX Dev Kit so I know which design is loaded (factory or user).

I'm also using the Cyclone IV GX to do field upgrade of the user configuration in flash. The idea is to download the user configuration update via PCI Express and reprogram the user configuration flash blocks via a flash controller that resides in the FPGA. I can correctly erase the blocks via the FPGA Flash Controller (blocks verified erased via JTAG as well as via boot to factory configuration afterwards). I can also correctly program the 16-bit words downloaded via PCI Express into flash via the Flash Controller. Programming 38 x 128 KB blocks take about 5 minutes.

The problem is that the FPGA will not configure from the user configuration if programmed by the fpga. I'm suspecting that i'm not using the correct file format. I have tried SOF and RBF with no luck. Compression is disabled both in QII and the PFL Megawizard. So, my simple question is:

Exactly how do i generate a programming file that I can word-program into flash?

I have seen some forum posts that discuss byte ordering but i'm unsure whether bytes in each word need to be swapped or even words within dword.

Thanks!

6 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Here's an easy way for you to figure this out yourself.

    1) Program the flash using the JTAG programmer

    2) Read the flash, eg., create a Qsys system with a flash controller.

    3) Compare the data you just read to the RBF file, or the RPD file.

    I've been testing flash programming with Cyclone IV E devices, eg., the BeMicro-SDK and the DE0-nano. The images read back from EPCS flash (SPI flash) match those in the .rpd file (taking into account that the bytes get bit-reversed). In your case, FPP shouldn't be bit-reversing, so your flash data should match your .rpd file. If they don't match, then read the PFL documentation, perhaps it adds some header information. In that case, just search a little further into the flash until you see a pattern that matches the .rpd file contents.

    To generate an .rpd file from a .sof file, I use the conversion tool in the GUI (File->Convert programming file), and convert .sof to .pof (selecting the appropriate flash target), and then convert that .pof to .rpd format.

    Cheers,

    Dave
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Thanks Dave. I will create some states to my FSM that reads the first word from flash to check the byte order. Creating QSYS is not 'easy' for me ;)

    What is the difference between RBF and RPD? I'm currently enabling RBF generation via the QII Device Settings dialog.

    In previous designs (Cyclone II) I could program via PS simply by shifting out the data byte by byte (LSB first, i think).

    Essentally, I want to know whether the PFL grabs the LSByte first when sending the first flash word to the FPGA.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    I will create some states to my FSM that reads the first word from flash to check the byte order. Creating QSYS is not 'easy' for me ;)

    --- Quote End ---

    Here's a tutorial to help ease the burden ...

    http://www.alterawiki.com/wiki/using_the_usb-blaster_as_an_sopc/qsys_avalon-mm_master_tutorial

    To access the flash you can use Altera's tristate bridge, or you can be lazy and just drive the flash with PIOs and then manually assert chip-select, output-enable, and then address, and read the data. This is a quick-and-dirty test, so that would be acceptable :)

    --- Quote Start ---

    What is the difference between RBF and RPD? I'm currently enabling RBF generation via the QII Device Settings dialog.

    --- Quote End ---

    I'm not sure. I used to generate RBF files for Stratix II devices. Generate both and look at them in a binary editor ... stick with RBF if that is what you have been using.

    --- Quote Start ---

    In previous designs (Cyclone II) I could program via PS simply by shifting out the data byte by byte (LSB first, i think).

    --- Quote End ---

    Yep, that is correct

    http://www.ovro.caltech.edu/~dwh/carma_board/fpga_configuration.pdf

    --- Quote Start ---

    Essentally, I want to know whether the PFL grabs the LSByte first when sending the first flash word to the FPGA.

    --- Quote End ---

    It should ... but PFL didn't meet my requirements, so I wrote my own per the doc I just linked to.

    Cheers,

    Dave
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Okay, i'm still stuck on this issue. Here's what i have accomplished today:

    1) I added states to my FSM that allow me to read out the 256 first DWORDs from the programmed flash.

    2) I programmed the flash via USB-Blaster/MAXII with a known good user configuration .pof file

    3) I then power-cycled the Cyclone IV GX Dev Kit and read out the first 256 flash words - data ended up in SignalTapII trace.

    4) I then compared the Signaltap data with the data in the RBF file.

    4) It turns out that the flash contained two initial 0001, 033c words before 16xFFFFs and the rest of the RBF data.

    So I, thinking that the 0001, 033c were magic numbers that the PFL put into flash when programming the data, modified by PC code to program the 0001, 033c before programming the RBF data. Unfortunately, the FPGA will not configured from the user configuration in flash.

    Could the initial 0001, 033c be a checksum or perhaps some length field? I will do more analysis of this tomorrow.

    It is quite frustrating that Altera has provided a PFL via FPP and even a Remote Update block that is supposed to facilitate FPGA upgrade/programming via FPGA but fails to actually document what needs to be programmed into flash. This is way too much trial and error for using supplied IP and tools...
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hi Dave,

    No, option bits are bits that are placed in a completely different range of the flash. The location of the option bits must be entered via the PFL MegaWizard and is then compiled into the PFL source code. When the PFL runs it will go read the option bits from flash (mine are located at address 0) to determine which flash configurations (0..7) are programmed and supposedly valid. Since I have already programmed both the user and factory configurations via JTAG/MAXII/PFL the option bits will contain an address+valid pair for the flash range 0 (blocks f to f+38) and flash range 1 (blocks u to u+39) where f and u are the base block numbers used for the factory and user configurations, respectively.

    FvM mentioned back in 2010 that the PFL puts a 4 byte header at the front of the data. This supposedly contains the PFL version required to read the data as well as the length of the configuration data: http://www.alteraforum.com/forum/showthread.php?t=22312 (http://www.alteraforum.com/forum/showthread.php?t=22312)

    Also, I just found this thread which exactly describes what I am seeing: http://www.alteraforum.com/forum/showthread.php?t=28657 (http://www.alteraforum.com/forum/showthread.php?t=28657)

    I will continue struggling with this tomorrow...

    /John.