EPCS4 data format?

[Altera_Forum]

I have an EPCS4 on a board with a Cyclone II. I'm using the pof file to load the EPCS4 and that all works fine. I have a processor on the board which then goes to read the EPCS4 to save it on an SD Card. 

 I'm reading the data out of the EPCS4, MSB first as described in Chapter 4 of the Configuration Handbook. Each of the bytes appears to be a bit-reversed copy of the bytes in the file. Does that mean if I want to copy the contents of a pof or hexout file into the EPCS4, that I should write the bits LSB first so they end up going in backwards so to speak? Can anyone offer an explanation for this observation or point to an explicit statement in the documentation that this might be required?

[Altera_Forum]

The bitreversal requirement comes from the fact, that FPGA configuration bitstream has to be LSB first, which is opposite to SPI and serial flash standard bit sequence. Altera has the SRunner software tool for embedded EPCS programming, you can consult the source code to find out programming details.

[Altera_Forum]

No need to consult th SRunner software. I've encountered this situation before, but I just could not put my finger on the definitive statement.  

 Thanks for clearing that up.   To sumarize: 

1. In writing from a file (pof or hexout) to an EPCS4 I should send the data from the file to the EPCS4 LSB first. 
2. In reading data from the EPCS4 I will receive it LSB first assuming it was written according to item 1 above. To rewite this data to a standard file (pof or hexout) I will need to either reverse the bits if shifting from right to left, or equivalently shift them from left to right during byte assembly.

I think that just about covers it.

[Altera_Forum]

Sounds correct. You need a standard SPI bit order, when sending the serial flash commands and addresses and an inverted (LSB first) bit order when writing or reading the configuration data from/to a file.

[Altera_Forum]

Thanks, it was far more efficient to use the forum than to go rooting around in the pdf jungle not knowing where to look for what I needed. 

 So far I have: Write Enable, Write Disable, Read Status, Read bytes, and Read Silicon Id working. I have no doubt the the remaining 5 commands will be working today and I'll be off to other things.   Thanks again for you help.

[Altera_Forum]

Just a short update. I managed to leave the status register of the EPCS4 with the Block Protect Bits set to 001 which protects sector 7 and leaves sectors 0-6 unprotected. The Cyclone II part that I am using only requires 4 sectors (1.9 MBits of the 4 MBits available). Even so the ByteBlaster and the programming software obviously rely on a ChipErase Command which failed. Since I did not ask the programmer to "Verify", I was at a loss to explaining why things were not working. Using the processor interface it was clear that programming was not working. I used the Write Status Register command to reset the block protect bits back to zero and all was resolved. 

 Two lessons here: 

1. Always put things back the way you found them. 
2. Trust (the programmer), but verify the result.

Once burned, twice chastened

[Altera_Forum]

I found that QII 9.1sp1 only erases the sectors that it needs for .jic file programming. 

 QII 9.0sp2 used to issue a bulk erase command.

[Altera_Forum]

That is useful information. I will check the version I am using, it might not be the latest and greatest. Once a design is started I'm quite reticent about changing tools in the middle of a development, especially if things are working and there are straightforward explanations for observed behavior.