about the CONF_DONE in the PS configuration

[Altera_Forum]

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.   Thanks !

[Altera_Forum]

--- 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

[Altera_Forum]

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?

[Altera_Forum]

--- 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

[Altera_Forum]

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

[Altera_Forum]

--- 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

[Altera_Forum]

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 ---  

[Altera_Forum]

--- 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

[Altera_Forum]

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 !!!

[Altera_Forum]

JTAG can program well and when it's done, nCONF_DONE is high.

[Altera_Forum]

--- 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

[Altera_Forum]

Dave, thanks for your quick reply !!! May I send the .hex file and the .rbf file to your email box? There seems no difference, except there is no CRCs in the .rbf file.....

[Altera_Forum]

--- Quote Start ---  Dave, thanks for your quick reply !!! May I send the .hex file and the .rbf file to your email box? There seems no difference, except there is no CRCs in the .rbf file.....  --- Quote End ---    Yeah, thats fine. Send it to the email that is my forum name. Send the Quartus .qsf file too, since that'll have the device settings. Put the files in a zip file.  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  JTAG can program well and when it's done, nCONF_DONE is high.  --- Quote End ---    So what change did you make to get things working?  Cheers, Dave

[Altera_Forum]

Was this resolved? I am having the same issue where I am able to clock all of the data and NSTATUS stays high showing no errors but I never get the CONF_DONE going high at the end of the transfer. I am using an MPC8309 and programming a Cyclone III using PS. Does the file need to be built a certain way for passive serial? 

 Thanks Jordan

[Altera_Forum]

--- Quote Start ---   I am having the same issue where I am able to clock all of the data and NSTATUS stays high showing no errors but I never get the CONF_DONE going high at the end of the transfer. I am using an MPC8309 and programming a Cyclone III using PS. Does the file need to be built a certain way for passive serial?   --- Quote End ---   Are you serializing your bits correctly?  The MPC8309 is a big-endian PowerPC, perhaps you are reading 32-bits and sending out the 4 bytes in the wrong order?  Look at the bytes in the .rbf or .rpd file, and then knowing that they are shifted LSB-first, look at the serialized data on your DATA0 FPGA pin, or just look at your code.  Cheers, Dave

[Altera_Forum]

I currently have the .rbf file stored in flash. I am reading it a byte at a time and sending the LSB-first. for example: one byte in the file is 6A i am reading 6A and sending it in this order 01010110 (left bit first). Is this correct?

[Altera_Forum]

--- Quote Start ---  I currently have the .rbf file stored in flash. I am reading it a byte at a time and sending the LSB-first. for example: one byte in the file is 6A i am reading 6A and sending it in this order 01010110 (left bit first). Is this correct?  --- Quote End ---    The order of the bytes is still dependent on the processor. Use u-boot on the board and read the contents of the flash location, eg., lets say the flash was located at F800_0000h, then you can read 32 bytes using   => md.b f8000000 20 f8000000: 2f 0c 40 08 86 af 07 33 ff ff 7f 12 ff ff ff 02 /.@....3........ f8000010: 22 07 05 19 24 ff ff ff ff ff ff ff ff ff ff ff "...$...........   Now look at your .rbf file. Does the ordering of the bytes match?  If the bytes are reversed in pairs or quads, then it just indicates that the flash programmer read data into a big-endian word before programming it. You can either fix the programmer code, or write a program to flip the bytes in your .rbf file before passing that modified file to the programmer.  Cheers, Dave

[Altera_Forum]

Ok. I used the debug probe to read the flash two different ways. 

 Probe setup as little endian 0xfe50_0020 f7f7f76a f3f3f3f7 fbfaf3fb f9f9f1fa   Probe setup for big endian 0xfe50_0020 6af7f7f7 f7f3f3f3 fbf3fafb faf1f9f9   the same bytes when looking at the .rbf file in image attached.   so it looks fine big endian correct?  https://www.alteraforum.com/forum/attachment.php?attachmentid=7202

[Altera_Forum]

--- Quote Start ---   Probe setup as little endian 0xfe50_0020 f7f7f76a f3f3f3f7 fbfaf3fb f9f9f1fa   Probe setup for big endian 0xfe50_0020 6af7f7f7 f7f3f3f3 fbf3fafb faf1f9f9   --- Quote End ---    In both cases the bytes are; 6a f7 f7 f7 f7 f3 f3 f3 ... which matches your .rbf.  This at least confirms your bytes in flash appear to be correct. How are you PS programming? Using an SPI controller? Check the bit-ordering with a scope.  This document may give you some hints too ...  http://www.ovro.caltech.edu/~dwh/carma_board/fpga_configuration.pdf  Check the different control signal pulses match their expected timing.  Cheers, Dave

[Altera_Forum]

i am just using I/O, setting the DATA0 bit then triggering DCLK to latch it. very similar to the source code provided in the Altera application note: AN423: Configuring the MicroBlaster 

Passive Serial Software Driver. On my scope the data and clock pulses look good. The clock is latched longer then 7ns as the spec states. I check my NSTATUS line throughout the process and it stays high. In testing I was able to inject errors and see NSTATUS drop low to show an error. Is there a specific way Quartus should be setup to build a PS serial file for loading like this? if email is easier let me know. this is one of the remaining issues we are trying to solve so my client can finalize their next board design.  Thanks, Jordan