Fast POR AS configuration of Cyclone 3

[Altera_Forum]

Hi There, 

 I'm working on a design that utilizes EP3C5E144I7 and EPCS4. I fabricated a board that uses active serial programming (fast POR) via in circuit byte blaster programming. I copied the programming circuit seen in the Cyclone III Device Handbook Volume 1 page 10-22. I'm able to successfully program the EPCS4 and verify its contents via the byte blaster. The FPGA, however, does not seem to get programmed. When I power up the board without the byte blaster connected I cannot get the FPGA to drive an output. Upon further investigation I see that the DCLK output of the FPGA is never driven to the EPCS4 part. My configuration voltage (which according to the handbook is my FPGA I/O voltage) is 3.3V. According to the device handbook I should be able to use fast POR configuration with 3.3V as the configuration voltage. I have MSEL0/2 = 2.5V (analog supply as suggested by the device handbook) and MSEL1 tied to ground. No pullups/pulldowns are in the path.  Any thoughts on why I can't get the FPGA configured? Thanks,  David

[Altera_Forum]

I should also mention that the FLASH_nCE pin on the FPGA is never high despite the internal 25k pull up...

[Altera_Forum]

Upon further inspection it looks like all the jtag pins on the cyclone were left floating. Is it possible that by not explicitly disabling the jtag circuitry that I'm unable to get the FPGA to properly configure itself from the EPCS4 using AS?

[Altera_Forum]

Altera recommends to connect unused JTAG input pins permanently to inactive levels (TCK to GND, TMS and TDI to VCCIO). Otherwise they should have sufficient low impedance pull-down and pull-up resistors. Particularly TCK without an 1K pull-down is known to be susceptible to interfering signals. However, if the pins are unconnected at the FPGA, I would expect that the FPGA internal resistors can keep them inactive. 

 I understand, that you have been programming the AS memory successfully, but there's no indication, that the FPGA is comming out of reset at all. So there may be other basic problems, e.g.  - missing or incorrect supply voltages - missing ground connection of exposed pad - missing pull-ups at configuration pins

[Altera_Forum]

Thanks for the prompt reply. After some minor cuts and jumpers I disabled JTAG and switched to standard POR. nCONFIG is permanently low (explains why I can program the EPCS, but not the FPGA) despite it being an input and despite a 10k pullup to 3.3V. There's no short to ground on it when power isn't applied. During reset is nCONFIG driven low? The datasheet states that it's an input so I'm having a tough time seeing how/why it's driven low. 

 After some inspection I discovered that my layout guy forgot about the ground slug on the bottom of the 144 pin package. The datasheet indicates that this is an electrical must. The layout is such that I was able to lift the FPGA, drill a hole (ugly I know) and attach the ground slug to the ground plane. Come monday I'll be able to test it. As a first reaction, does the lack of electrical connectivity on that ground slug seem like a reasonable explanation for the FPGA not leaving reset? Thanks,  D

[Altera_Forum]

--- Quote Start ---  Thanks for the prompt reply. After some minor cuts and jumpers I disabled JTAG and switched to standard POR. nCONFIG is permanently low (explains why I can program the EPCS, but not the FPGA) despite it being an input and despite a 10k pullup to 3.3V. There's no short to ground on it when power isn't applied. During reset is nCONFIG driven low? The datasheet states that it's an input so I'm having a tough time seeing how/why it's driven low.  After some inspection I discovered that my layout guy forgot about the ground slug on the bottom of the 144 pin package. The datasheet indicates that this is an electrical must. The layout is such that I was able to lift the FPGA, drill a hole (ugly I know) and attach the ground slug to the ground plane. Come monday I'll be able to test it. As a first reaction, does the lack of electrical connectivity on that ground slug seem like a reasonable explanation for the FPGA not leaving reset? Thanks,  D  --- Quote End ---    Yes. Failing to ground the pad on the 144 pin EQFP will cause it to fail to start.

[Altera_Forum]

Indeed. The jumper fixed everything (with fast POR and JTAG not explicitly disabled). Thanks a lot for the help!