Parallel Flash Loader issues

[Altera_Forum]

Hi all, 

 on a custom board we are using PFL (implemented in a MAX II device) to configure a single Stratix II GX device using FPP. The flash memory (S29GL064N) holds 2 firmware images, user and factory, programmed in page 0 (0x0000000) and in page 1 (0x00200000) respectively. The bitstreams are NOT compressed. The option bits are stored at address 0x003F0000. The user image can be programmed using JTAG or through the Stratix II GX FPGA. In this latter case the flash access is implemented as part of the custom FPGA firmware (i.e. not PFL) and uses a HEXOUT file which is converted from SOF.  When the flash memory is written using Quartus II programmer and a POF, the FPGA is configured properly with the user image. However, if the user image is updated through the FPGA the configuration failes.  This is what happens. Following power-up the PFL starts to load the configuration from the user area, but after a few miliseconds nStatus is pulled down and the PFL (as expected) reverts to the factory default. We verified that the user image is properly programmed into the flash by reading it back and comparing it with the HEXOUT file. Unfortunately, this verification could not be done using the Quartus programmer, because there seems to be a fixed 4-byte offset when the data is written by Quartus.  In order to debug this problem I made some measurements using an oscilloscope (screenshot available on request). Normally, for each flash address cycle there should be 2 DCLK cycles, because the flash data is 2-byte wide while the FPGA requires 1 byte (a la FPP). On the scope however I could see that the PFL uses a different scheme before the configuration fails: 8 DCLK cycles per address (i.e. 4 DCLK pulses per byte). As far as I could understand, this is required for compressed bitstreams. Actually, shortly before the failure happens the PFL switches between the 2 modes (compressed -> normal) making me even more puzzled. :confused:  Why would the PFL start the configuration in compressed mode ? If this is really the case, why would it suddenly switch to normal mode ?  Legend for attached file: yellow - nStatus green - FPGA DCLK purple - Flash A0 (address LSB)  BR

[Altera_Forum]

The 4 byte offset, you observed, is there, because the PFL image contains a 32 bit header with additional information, e.g. the PFL version and, if I remember right, also a compression mode flag. You can refer to the PFL sources to check for the details. Don't expect much explaining comments.

[Altera_Forum]

Thanks for your reply. Does this mean that I cannot use a HEXOUT file directly to update the flash content ? I will try to figure out what is in that header anyway. 

 By the way. There was a mistake in the original post. I meant that the bitstreams are NOT compressed.

[Altera_Forum]

--- Quote Start ---  Does this mean that I cannot use a HEXOUT file directly to update the flash content ?  --- Quote End ---  I think you can, if you know, what to write to the first four bytes.   --- Quote Start ---  I meant that the bitstreams are NOT compressed.  --- Quote End ---   I didn't think about the details of your post. Obviously, you don't manage to write an image identical to the Quartus programmer, and apparently, it has to do with compression (at least among other issues).

[Altera_Forum]

Ok, I think it is clear now. I will try to write back the original values of the 4 bytes (with or without the offset) and see what happens.

[Altera_Forum]

It did not work ... :( 

 So, what file/format should I use to program the flash without the Quartus II programmer, if HEXOUT is not compatible with PFL, and if POF format is not public ?

[Altera_Forum]

As you can see from the PFL source, the upper 16 header bits contain also an image length information. If it's not set accordingly, the configuration load must be expected to fail. This point is also involved with "know, what to write to the first bytes". I didn't yet try to write a PFL flash image by user code, so I can't tell you precisely where to find the respective information. But I'm sure you can get it, also other embedded configuration methods are able to retrieve an image size information.

[Altera_Forum]

I understand your "know, what to write to the first bytes" statement. However, I don't think this should mean that the user must figure out the details from the HDL source. Well, I kinda like this, but it is really time consuming. So, if someone knows a better information source (datasheet, application note etc.) I would really appreciate that. ;)

[Altera_Forum]

I reviewed my collected PFL docs. It seems like the basic information is given in AN386, possibly not as clear as desirable.

[Altera_Forum]

Once again, thank you for helping me on this. Rep++ ;)

[Altera_Forum]

Ok. AN386 does state that RBF is not supported (did not say anything about HEXOUT, but I think it is almost the same). I will ask our software engineer to implement flash programming with POF support. We shall see...

[Altera_Forum]

I was refering to V4.0 of the document, that said regarding *.rbf files: 

  --- Quote Start ---  RBF file can be generated for the flash device as well, and you can use your own programmer to program the flash with the data from the RBF file.  --- Quote End ---   I'm not sure which statement is actually correct.

[Altera_Forum]

Our software engineer has changed our customized flash programmer which can now handle POF inputs. Using the POF we have successfully reprogrammed the flash and the PFL seems to configure the FPGA properly. Thanks again for your help FvM.