about the CONF_DONE in the PS configuration

--- Quote Start ---

Dear all, I am trying to configure the Cyclone III device using the Passive Serial mode. In the very beginning, I draw the nCONFIG low, and subsequently the Cyclone III draw the nSTATUS low....the question is: why CONF_DONE is always low from the very beginning? As to the configuration handbook, there should be a high-to-low transition for the CONF_DONE... why?

In addition, there is said to be a low-to-high transition for the CONF_DONE in the end of the configuration, I just want to know, how does the Cyclone device know the configuration is done ?

PS. MSEL is 0000, and the clock is 1M, and the file format is .hex.

--- Quote End ---

Look at the timing diagrams on page 4 in this document:

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

CONF_DONE is low at first power-on, since the FPGA has not been configured. Then the next time you configure it, CONF_DONE starts out high.

Cheers,

Dave

--- Quote Start ---

Thanks, Dave. There is said to be a low-to-high transition for the CONF_DONE in the end of the configuration, I just want to know, how does the Cyclone device know the configuration is done ? that is, how does the Cyclone device know the exact time that the configuration file (.hex) is sent out?

--- Quote End ---

Look at page 4, Figure 1, it shows you the timing parameters.

Look at the logic analyzer trace on p60. It shows CONF_DONE going high right after the last DCLK.

The Cyclone device will do the same thing (if its working properly).

Cheers,

Dave

--- Quote Start ---

Thanks again, Dave, did you ever try to configure FPGA using .rbf or .hex file ?

--- Quote End ---

Man, nobody ever reads my documents .... :)

Yes, I use .rbf files; see p29, and p63.

Cheers,

Dave

Dear Dave, thanks, your document is very detailed, but I still cannot find out the answer to my problem, currently, everything goes fine, except that when I send out all the configuration file in .hex format, the conf_done is still low...................

--- Quote Start ---

Man, nobody ever reads my documents .... :)

Yes, I use .rbf files; see p29, and p63.

Cheers,

Dave

--- Quote End ---

--- Quote Start ---

currently, everything goes fine, except that when I send out all the configuration file in .hex format, the conf_done is still low...................

--- Quote End ---

What does the nSTATUS pin do?

If it goes low, it indicates that the configuration file is 'bad'. This can happen if your PS controller has a logical error, or if there are reflections on the DCLK signal that cause the FPGA to be double clocked.

Have you checked with JTAG that the FPGA can be programmed correctly. Does the CONF_DONE signal assert?

Is this a BGA package, or a TQFP? Can you probe the pins directly?

Cheers,

Dave

Dave, thanks, JTAG can program well and the nSTATUＳ is high, there is no error at all.

The only problem is about the nCONF_DONE....

When I send the .hex configuration file to the FPGA, should I just send the "valid" data...or send the "valid" data as well as the length information and CRCs?

And how does the FPGA know the transmission is done and it's time to release the nCONF_DONE?

Also, there are many different file formats can be used to configure the FPGA, how does the FPGA know which format I am using？

Hope I can see the answers to such questions in your document soon !!!

--- Quote Start ---

Dave, thanks, JTAG can program well and the nSTATUＳ is high, there is no error at all.

--- Quote End ---

Ok, so its probably related to not sending enough DCLKs at the end of the configuration sequence. Try sending a few more DCLKS, eg., 8, 16, 32, or 64.

--- Quote Start ---

When I send the .hex configuration file to the FPGA, should I just send the "valid" data...or send the "valid" data as well as the length information and CRCs?

--- Quote End ---

I haven't used .hex files. Go and figure out the difference between a .hex file and .rbf. Is the .hex just an Intel .hex file? If so, then convert it to bytes and it should match the .rbf exactly. If the .hex file is missing some 0xFFs at the end, then there is your problem - the hex file is missing the extra DCLKs.

The "valid" data and CRCs in the .hex file are related to the ASCII representation of the data in that file, they are not related to FPGA configuration data, so do not send them to the FPGA.

--- Quote Start ---

And how does the FPGA know the transmission is done and it's time to release the nCONF_DONE?

--- Quote End ---

The binary data likely has CRCs checks. Since nSTATUS is not going low, the FPGA is happy with the data.

--- Quote Start ---

Also, there are many different file formats can be used to configure the FPGA, how does the FPGA know which format I am using？

--- Quote End ---

Bits are bits. The .hex file vs .rbf file should be merely a human readable format difference, not something the FPGA sees.

Cheers,

Dave