Last bits of config. bitstream are ignored in Passive Serial Configuration

[Altera_Forum]

Hello, 

i am trying to configure Cyclone III (EP3C25E144C8) fpga via Passive Serial configuration method. I send all bitstream data to the fpga, but as you see on the image below, last 9 (or 10) bits of the bitstream are ignored by the fpga and fpga releases Config Done pin, and then releases init done pin. My simple application (blinking a LED) works OK. But why is the fpga ignoring last bits? is this normal? Thanks..  http://c1109.hizliresim.com/11/9/7/7857.jpg

[Altera_Forum]

Why bother if it works? It could probably be a checksum or something not very critical. If CRC fails, Your config_done will go low again.

[Altera_Forum]

This is a small, test application. It can work. But I am planning to use nearly all logic cells with full performance. So i wonder if those last bits effect the bitstream or not..

[Altera_Forum]

I would say it is checksum.

[Altera_Forum]

Thanks.. 

I remembered that CRC check feature was OFF. I thought that maybe these bits are CheckSum and they are ignored because this feature is OFF. So i switched it ON, then configured the bitstream again. But result is the same. As zoomed on the new screen shot below. I think that if these bits are CRC bits, then fpga would first check these bits and then decide if there is a CRC error or not. And release the config done pin according to the result. Any other ideas?  http://c1109.hizliresim.com/11/9/7/10429.jpg

[Altera_Forum]

Those are simply padding bits being transmitted by the host until it receives the CONFIG_DONE signal, or until detects an error condition. 

If you take a look to data line, you see a sequence of 0xFF bytes. This is usually done because some devices need extra clocks for startup timing. The 'substantial' bitstream required for fpga configuration has actually finished a few bytes before you see CONFIG_DONE going high.

[Altera_Forum]

--- Quote Start ---  Those are simply padding bits being transmitted by the host until it receives the CONFIG_DONE signal, or until detects an error condition. If you take a look to data line, you see a sequence of 0xFF bytes. This is usually done because some devices nuse extra clocks for startup timing  --- Quote End ---    I don't use a host device. I use a MCU for reading the bitstream from a spi flash memory and programming the fpga. I see that last bits exist in the .rbf file and also in the .hexout file.   Also, on the PS configuration datasheet, it is written that 2 more DCLK pulses are needed after Config Done pin is High to enter Initialization Mode.  I will add these 2 more clk pulses but now it seems that is is not needed..  Do you mean that last FF bytes are dummy bytes for sending blank clock pulses?

[Altera_Forum]

--- Quote Start ---  I don't use a host device. I use a MCU for reading the bitstream from a spi flash memory and programming the fpga.   --- Quote End ---   That's exactly what I meant with 'host'    --- Quote Start ---   I see that last bits exist in the .rbf file and also in the .hexout file.    --- Quote End ---   This is a common practice. Configuration files are generated with pad bits, so that the programming device doesn't need to bother to add them.    --- Quote Start ---   Also, on the PS configuration datasheet, it is written that 2 more DCLK pulses are needed after Config Done pin is High to enter Initialization Mode.   --- Quote End ---   I don't think those are really needed for CIII. From config_done to user mode (when init_done goes high), the startup sequence is driven by the internal clock, 3185 cycles required.