What is Timing between nCEO and DCLK in a multi-device AS Configuration ?

[Altera_Forum]

Is there timing requirements between nCEO and DCLK when configuring two FPGA's from one EPCS device? 

 The master device (the first FPGA configured) operates in an AS configuration mode and once configured pulls down the nCEO output connected to the nCE pin of the next FPGA to be configured. The DCLK does runs continuously through the point where nCEO transitions to low.  The FPGA's are Cyclone III's.  The online documentation for configuring Cyclone III's discusses using the PS mode to configure multiple FPGA's in the context of using a MAX II or a processor. It states:  "After the first device completes configuration in a multi-device configuration chain, its nCEO pin drives low to activate the nCE pin of the second device, which  prompts the second device to begin configuration. The second device in the chain  begins configuration in one clock cycle."  Configuration begins in one clock cycle, it says, but is it OK to be off by a clock after nCEO goes low? DCLK to the second FPGA has a delay of 5.5 ns with respect to nCEO because DCLK is buffered before being routed to the second FPGA.  Does the bitstream have padding at the start of the second FPGA configuration and use a "Start" indication before clocking in the configuration bits? This would avoid issues with the nCEO/DCLK timing.  Currently my second FPGA is not configuring correctly and allowing Config_Done.

[Altera_Forum]

What are your MSEL settings? 

 The second device should not be in AS mode, but in PS mode.  Ah, but we've had this conversation before ...  http://www.alteraforum.com/forum/showthread.php?t=42710  The nCEO->nCE timing is not critical. The configuration file has a number of dummy bytes between configuration images, and they help account for any delays. I've never seen any issues; I have one design where I've cascaded four Stratix II FPGAs uses FPP mode, and another design where I've cascaded 10 FLEX10K devices uses PS mode.  Cheers, Dave

[Altera_Forum]

Yeah thanks. 

 Still have not solved my issue. I had the boards X-rayed and I got the 3rd board up and running, but they all have the same issue so I am assuming the IC's are likely alright. I put in for an Altera Service Request, but I have not yet gotten that deep insight I was hoping for.  I have not gotten to trying to readback the data in my EPCS yet.   Q1: What is the logic that produces Config_Done. Is it parity, is it a proper byte count, does the memory fuel gauge have to reach "full"?  Q2: How do I use the advanced setting in the "Convert Programming File Utility", particularly   1. Program Length Count Adjustment 2. Post-chain bitstream pad bytes 3. Bit-Slice padding value  I found a document that tells me what sort of situation these can be used but it did not say how to use them or specifically how they effect the bitstream.  Thank you to all who seek to answer Forum questions and youtubers that tell me how to repair my fridge and furnace.

[Altera_Forum]

--- Quote Start ---   Still have not solved my issue.   --- Quote End ---   Sorry to hear that.    --- Quote Start ---   I had the boards X-rayed and I got the 3rd board up and running, but they all have the same issue so I am assuming the IC's are likely alright.   --- Quote End ---   This statement is a little unclear. If you got a 3rd board "up and running", what did you change?  Can you "break" it, and then "fix" it?    --- Quote Start ---   I have not gotten to trying to readback the data in my EPCS yet.   --- Quote End ---   If you have a 3rd board "up and running", then that implies the EPCS image has been created ok.    --- Quote Start ---   Q1: What is the logic that produces Config_Done. Is it parity, is it a proper byte count, does the memory fuel gauge have to reach "full"?   --- Quote End ---   You'll never get info on this. Its Altera "secret sauce" :)    --- Quote Start ---   Q2: How do I use the advanced setting in the "Convert Programming File Utility", particularly   1. Program Length Count Adjustment 2. Post-chain bitstream pad bytes 3. Bit-Slice padding value   --- Quote End ---   I've never had to use any.  For my PS and FPP configuration images, I simple concatenate the .rbf files and program them into the devices, eg.,   puts " - Creating the configuration file data_power.bin" exec cat data1.rbf data2.rbf data3.rbf data4.rbf > data_power.bin   Cheers, Dave

[Altera_Forum]

Clarifications: 

 The 3rd Board was previously not available to test this FPGA configuration issue with because of a bad power regulator. The regulator was fixed and I am able to power the board and attempt to program the FPGA's on it. If it did not have the problems the other boards had I would have replaced the FPGA's on the first two boards.  I am about to concede to trying to configure the FPGA's from something other than the EPCS with pof's. I have an alternate set of DATA0, DCLK, nCE, etc. signals routed from another (well behaved) FPGA on the board. So I concatenate my two *.rbf's and clock these bytes in serially. So do you have a reference for the details of doing this ? Is the serial stream MSB first ? Do I need to do any byte swapping things?

[Altera_Forum]

--- Quote Start ---   Clarifications:  The 3rd Board was previously not available to test this FPGA configuration issue with because of a bad power regulator. The regulator was fixed and I am able to power the board and attempt to program the FPGA's on it. If it did not have the problems the other boards had I would have replaced the FPGA's on the first two boards.   --- Quote End ---   Ok, I see.  Its still not clear from this brief discussion what works and what does not. If you can program the FPGAs via JTAG, then that would indicate the issue is related to EPCS configuration.  If some boards work and others do not, then it implies either a timing or waveform (signal integrity) issue.    --- Quote Start ---   I am about to concede to trying to configure the FPGA's from something other than the EPCS with pof's. I have an alternate set of DATA0, DCLK, nCE, etc. signals routed from another (well behaved) FPGA on the board. So I concatenate my two *.rbf's and clock these bytes in serially. So do you have a reference for the details of doing this ? Is the serial stream MSB first ? Do I need to do any byte swapping things?  --- Quote End ---    The Handbook for the device has pretty good details on what is required. PS data is serialized LSB-to-MSB. This doc has some notes:  http://www.ovro.caltech.edu/~dwh/carma_board/fpga_configuration.pdf  Cheers, Dave

[Altera_Forum]

Thanks again. All three of my boards behave the same way. I will focus on the EPCS configuration.

[Altera_Forum]

Not sure I can add much here, as we're doing a single Cyc III device design, and we're using AS Mode. But we see similar timing issues (or lack thereof) in that we come out of Reset phase with nCONFIG and nSTATUS having gone High, but we never see nCS/nCSO transition to select the EPCS and we never see DCLK out of the FPGA. So, we're slogging around with that problem....looking at whether the voltages on the MSEL lines are appropriate, and whether we're putting the Cyc III into the mode that we think it's in. 

 The point I wanted to make is that the more recent version of Cyc III documentation (2012) doesn't contain some of the signaling protocol information that we found on an earlier version of a document (2008); I thought I'd share that link, just in case it didn't turn up in any of your web searching.  http://cp3.irmp.ucl.ac.be/upload/wg_hardware/epcsx  This version of a document on EPCS devices has opcodes and signal timing specific to communication between FPGA and EPCS devices that we didn't see in mose recent documentation.  Hope this helps. cheers, jim

[Altera_Forum]

Thanks Jim. I will certainly have a look at the document you referenced.  

 I might be able to help with your problem, if I am understanding it correctly.  You have one Cyc III being programmed AS from an EPCS device, and you do not see the nCS line transition, yes? I would not expect the nCS line to transition I would have it pulled to GND through a 10K Ohm resistor. Some diagrams show it tied directly to GND, but I see the pull down resistor in the diagrams explaining  the arrangement that uses a 10 pin programming cable to program the EPCS.  http://www.altera.com/literature/hb/cyc3/cyc3_ciii51016.pdf  Excuse me if I am misunderstanding your issue.  I have had some mystery with when I program the EPCS with my programming cable as to whether I need to remove the programming cable to allow the FPGA configuration to start. Sometimes I can leave it in. Sometimes I have to disconnect it (?).

[Altera_Forum]

--- Quote Start ---   I have had some mystery with when I program the EPCS with my programming cable as to whether I need to remove the programming cable to allow the FPGA configuration to start. Sometimes I can leave it in. Sometimes I have to disconnect it (?).  --- Quote End ---    The AS header has nCONFIG and nCE pins. When AS programming starts, the USB-Blaster takes nCONFIG low and nCE high, which resets the FPGA, and tri-states the EPCS bus so the cable can drive the EPCS pins to program it. The USB-Blaster then leaves nCE high. Ideally it would drive nCE low at the end of programming, but that is not always what happens, eg., under Linux its different than under Windows.  Cheers, Dave

[Altera_Forum]

The problem has been resolved. My expensive PCB layout tool was not supposed to let me cross my signals, but some how it did. DATA0 and DCLK on the FPGA that would not configure were swapped on the PCB but not on the schematic. Its over. I can get on with the project and my life again.

[Altera_Forum]

--- Quote Start ---  The problem has been resolved. My expensive PCB layout tool was not supposed to let me cross my signals, but some how it did. DATA0 and DCLK on the FPGA that would not configure were swapped on the PCB but not on the schematic. Its over. I can get on with the project and my life again.  --- Quote End ---    Can you elaborate on this a little more.  I have PCB tools from Mentor and Cadence, and have never seen this issue (other than a user-mistake in the schematic).  Can you check that when you netlist the schematic design, and import that netlist into your PCB design that you get no net changes? It sounds more like a case that the error was fixed in the schematic after the PCB was built. Though if you were the designer of both the schematic and PCB, and you do not recall doing that, then we'll have to think of another hypothesis :)  I'm glad to hear you resolved the issue, however, the cause still sounds a little scary ...   Cheers, Dave