cyclone IV configuration: VCCIO8 connection

[Altera_Forum]

I’m currently using an EP4CE6F17I8LN on a PCB in an AS configuration mode (EPCS4 PROM) and I’m experiencing some issues with its configuration (device stays in POR with nSTATUS low). In my circuit implementation, I’m not using any of the Bank8 I/Os, so I made the mistake of leaving the VCCIO8 unconnected. After reading carefully the datasheet, I realized that VCCIO8 should be connected, since it contains configuration pins… My question is: VCCIO connects to pins A1, C4 and C7. Can I get away (at least for prototyping purposes) with soldering a wire on pin A1 (easy access on the PCB) and leave C4 and C7 floating?

[Altera_Forum]

--- Quote Start ---  My question is: VCCIO connects to pins A1, C4 and C7. Can I get away (at least for prototyping purposes) with soldering a wire on pin A1 (easy access on the PCB) and leave C4 and C7 floating?  --- Quote End ---    I would expect that all VCCIO8 bond wires connect to the same power rail, and the reason for multiple pins is current handing and inductance reduction. Given the same problem as you, I would just try it.  I mean hey, you can't make things worse right? As it stands, the device will not power on, ever.  Cheers, Dave

[Altera_Forum]

Thanks Dave for your post. 

  Actually, following that philosophy (nothing to loose), the device did manage to boot a couple of times after connecting A1 and then the configuration failed (nSTATUS low again).   Given the measured impedance between A1, C4 and C7, those must be connected to the same rail, and given that no I/Os are connected to this bank in my design, I'm just wondering if the in-rush current at power-up is not too large to be handled by only one wire-bond.    Putting a 1000uF capacitance on that pin did not help (nor replacing the FPGA).   I know that not connecting VCCIO8 is probably not something anyone would do after reading carefully the datasheet, however I was just curious if anyone found his way around that issue...

[Altera_Forum]

--- Quote Start ---   I'm just wondering if the in-rush current at power-up is not too large to be handled by only one wire-bond.    --- Quote End ---  For debugging purposes, you can defeat the "All power rails must come up within xxx ms, and must rise monotonically" requirement by holding nCONFIG low during power-on. Then let it go high, and it should attempt configuration from that point.  Cheers, Dave

[Altera_Forum]

Holding nConfig low during power up does not make it come high afterwards.

[Altera_Forum]

--- Quote Start ---  Holding nConfig low during power up does not make it come high afterwards.  --- Quote End ---    nCONFIG is supposed to have a pull-up.  If you can hold it low using an on-board programmer, or just short it to ground, then power-up, then release nCONFIG, it should go high.  Cheers, Dave

[Altera_Forum]

I mean nstatus stays low after nConfig goes high...

[Altera_Forum]

--- Quote Start ---  I mean nstatus stays low after nConfig goes high...  --- Quote End ---    Look at the timing diagrams in this document:  http://www.ovro.caltech.edu/~dwh/carma_board/fpga_configuration.pdf  p4. nSTATUS should go high after nCONFIG comes high.  Probe around your board and make sure all the signals are in the correct state.  Do you have the JTAG connection wired up?  Cheers, Dave

[Altera_Forum]

I agree with Dave in expecting correct configuration with connecting only one VCCIO8 pin. I would rather expect additional circuit faults. It's just a matter of plausibility. The VCCIO thing clarifies, that you are not very familiar with FPGA hardware design. It's likely to have other hidden problems as well.

[Altera_Forum]

with the JTAG connected, the programmer software does not identify the FPGA device. 

 I'm not that familiar with FPGA hardware designs, specially with Cyclone IV, however I did design a couple of cyclone III based boards (schematic/placement/routing) without experiencing any of such configuration issues...

[Altera_Forum]

--- Quote Start ---  with the JTAG connected, the programmer software does not identify the FPGA device.   --- Quote End ---    Does this device have a power-pad (pad on the bottom of the IC) and did you connect it to ground? Several people have forgotten to do this, and the device will not work correctly.  Cheers, Dave

[Altera_Forum]

Dave: thanks again for your help.  

  I'm actually using the BGA package, which does not have such PAD.

[Altera_Forum]

--- Quote Start ---  Dave: thanks again for your help.    I'm actually using the BGA package, which does not have such PAD.  --- Quote End ---    Ok.  Can you probe each of the vias to the BGA balls? If you board has been designed well, then the bottom of each via will have had the solder mask removed so that you can stick a scope probe tip in each via.  Probe each of the supply voltages and confirm they are at the correct level.  Probe each of the JTAG pins and confirm they toggle when the JTAG tool is used to access them (Quartus has a JTAG debugger tool).  Check that the chip-enable input (nCE) is low, and check that the MSEL pins are asserted to an appropriate level.  The JTAG interface should work if the power is applied and the device JTAG chain is connected ok.  Cheers, Dave

[Altera_Forum]

after inspection, it turned out that the device was not soldered properly. After its replacement and careful inspection, the FPGA now boots properly. 

 Thank you both for your help.

[Altera_Forum]

Great! 

 Were you using X-ray equipment?  Its amazing how much detail you can see on a 'CT scan' of a BGA :)  Cheers, Dave