Hi,
I'm using a EP4CE22F17I7 (this is my first BGA board) that doesn't want to configure.
Configuration scheme - AS
MSEL pins "010" with the high being 2.5 V. (The VCCIO is 3.3 V on all the banks.)
Config device - EPCS16
Here is an overview of the nConfig, nStatus, INIT_DONE and DCLK pins:
![]()
nStatus is released approx. 100 ms after POR as expected (when compared to my Cyclone 3 configuration probing).
As soon as nStatus goes high, DCLK has 8 clocks, skips one clock, then 9 clocks, skips 16 clocks, followed by 40 clocks. Then no clocks for approx. 33 us followed by approx. 95 bytes (19 us activity) before it is stopped. The configuration is aborted after 54 us.
What I find strange when comparing the timing waveforms to that of the configuration cycle, is that DCLK is high as soon as the device comes out of POR, i.e. when nConfig goes high, but goes low approx. 52 us before configuration can start.
Here is the probing waveforms of the configuration attempt:
![]()
Below is a close up of the point when configuration is halted. INIT_DONE goes low approx. 8 clocks before nStatus goes low with DCLK stopping after 5 clocks.
![]()
Altera's Debugging Configuration Problems (CF52011-2.3) states the following about the INIT_DONE pin:
To check if the FPGA has started accepting configuration data, you can monitor the INIT_DONE pin. The INIT_DONE pin is an optional pin and can be turned on in the Quartus II software through the Enable INIT_DONE output option. The INIT_DONE pin is an open-drain output and requires an external pull-up to VCC. Therefore, when nCONFIG is low and during the beginning of configuration, the INIT_DONE will be at a logic high level. After the option bit to enable the
INIT_DONE pin is programmed into the FPGA (during the first frame of configuration data), the INIT_DONE pin will go low. The transition of INIT_DONE from high to low signals that the FPGA has indeed begun configuration and started to accept configuration data. If the INIT_DONE pin remains high, the FPGA has not received the proper configuration file header to indicate the beginning of configuration data.
The USB-blaster is functioning fine. I can program the same blinking code onto a Cyclone 3 (previous project) which configures fine.
I've used Quartus II v11.0 Build 157 and now also installed Quartus II 64-bit v15.0.0 Build 145, but with no success.
In summary:
1. Why does DCLK go high after POR? Is this normal because I don't see this with the Cyclone 3 or indicative of an hardware issue?
2. From Altera's documentation I understand that the configuration is aborted when a data frame error is encountered. Below is a comparison of the DCLKS of the Cyclone III and Cyclone IV, so I don't think that the config data is clocked in wrongly due to a poor clock signal. What could cause a data frame error and is this the only reason why configuration would be halted?
DCLK for Cyclone III and Cyclone IV (the latter uses 3.3 V compared to the 3. 0 V):
![]()
Thanks.