Cyclone III AS configuration bizarreness

[Altera_Forum]

I am using a cyclone III (EP3C25F324C8N) with an EPCS16 configuration device. 

I am programming the configuration device through the FPGA with the serial flash loader. The problem is that the Cyclone III device will not configure itself from the EPCS16. It is stuck in an endless loop of retries UNTIL I MOMENTARILY SHORT THE nSTATUS PIN TO 3.3 VOLTS!!!! (...I discovered this by accident, no grounding the pin doesn't do it.)  As soon as I do that the device configures and runs my test program (blinks LEDs). I also tried driving it high momentarily with an 8051 to no avail.   Any ideas?   Thanks, Rob  UPDATE: It also configured when I touched CONF_DONE with a probe. Upon further investigation I found that adding a 100 pF capacitor from CONF_DONE to GND fixes this problem ...no idea why.

[Altera_Forum]

Not sure what your circuit looks like, but nSTATUS has to be pulled up to VCCIO (permanently) in order to enter configuration mode. Are you saying that you have to short the pull-up resistor to get the FPGA to configure? 

The recommended value for the pull-up is 10k for 3.3V VCCIO.

[Altera_Forum]

Yes. I have to short the pull-up resistor - briefly. I just tap it with a probe connected to 3.3V and it works great. 

 The resistor is a 10K to 3.3 V.

[Altera_Forum]

My guess is that the device is getting some sort of configuration error... either a bad check sum or something... and asserting nSTATUS low to report the error. When I touch the nSTATUS pin to 3.3V it is being seen (by a separate piece of logic in the FPGA) as indicating that configuration did not have an error so the FPGA goes ahead and enters user mode, even though nSTATUS returns to low. Anyway, I suspect that my problem may be in the .JIC file, not the hardware.  

 Anyone have any experience with this (especially the use of JIC files) ?  PS I am using Quartus V7.1

[Altera_Forum]

Is this a custom board or are you testing on a development kit? If it's a custom board, have you applied the MSEL pins workaround in the ciii errata sheet (http://altera.com/literature/ds/es_cyciii.pdf)? 

Wrong config scheme selected at startup can cause problems like yours.

[Altera_Forum]

It is a custom board.  

The MSEL pins are connected directly to either V3.3 (supplied by a high current bench supply) or GND.

[Altera_Forum]

Rob, 

Did you ever find the root of your problem?  I am experiencing a similar behaviour. It is on a custom board based with a Cyclone I, 1C20 device. I am using the CFI flash/CPLD-based configuration controller reference design. I, too, am having an intermittent configuration issue which disappears when probing with a standard 10X scope probe or a logic analyzer probe. The problem reappears when using a FET probe with <1pF capacitance.  I started a service request regarding this issue but have received no useful information.  Thanks, steve

[Altera_Forum]

Not really but here's the latest theory: Apparently there's some sort of race condition in the Cyclone 3's configuration circuitry. I mistakenly used 3.3V for the configuration voltages but the specification is for these signals (nStatus, COMF_DONE, nCONFIG, DATA1, DCLK, nCSO, ASD)) to be driven by (or pulled up to) a 2.5V standard. This may have contributed to the timing problem. 

 When I spin the board I'll fix the voltage AND add the capacitor; then, hopefully, I'll see what's what.

[Altera_Forum]

I've had a similar problem myself with an EPCS16 and Cyclone III. It wasn't configuring so I probed the DCLK pin with a scope and it configured. Then I found that touching the pin with a screwdriver was sufficient for it to configure and if the screwdriver was there on power up then it would also work. Very strange. 

 Anyway, I added a 100pF capacitor between the DCLK pin and GND and it has been fine since that.   If anyone can explain this behaviour to me then please do. I would like to understand what was going on, but it's nice to have resolved the problem even if more by luck than judgement :)

[Altera_Forum]

Hello, 

 I didn't yet experience these problems with AS configuration but I guess it could be due to a ringing DCLK. What's the distance between FPGA and EPCS and to the AS programming connector or any other devices connected to DCLK? Although the 100 pF may help, it seems something brute to me. A DCLK series resistor (~100 ohms) at the FPGA could be a more gentle way to abandon clock ringing, provided a regular digital ground (PCB power plane) exists for the circuit.  Regards,  Frank

[Altera_Forum]

Hi Frank, 

 Are you suggesting that ringing on DCLK could be being interpreted as extra clock edges?  There is 30mm between FPGA and EPCS - no other devices are connected to DCLK. There is a ground layer and a 3V3 layer on the PCB.   Adding a series resistor isn't as easy to implement in practice but I will give it a try. I suppose that if the scope is affecting the amount of ringing then it will be difficult to see the difference between a series R and the 100pF to GND accurately.   Thanks for your help.

[Altera_Forum]

I tried a 25R resistor between the FPGA and EPCS on the DCLK line. This doesn't fix the problem. The FPGA is back to not configuring until I touch the pin with probe/screwdriver. 

 Back to the magic 100pF I suppose.....  :)

[Altera_Forum]

Hello, 

 sorry for leading you in the wrong direction. 30 mm distance is effectively no distance for this kind of signals, with proper ground and supply, I can't see any reason your design may be responsible for. In this case, I think it's an Altera chip design problem related to Cyclone III or EPCS. One may be able to see it with active probes, but Altera should take care about.  Best regards,  Frank

[Altera_Forum]

I am also seeing a problem like this. 

 I'm using an EPCS64SI16N to configure a CycloneIII EP3C25F324C8NES (first device) and ArriaGX EP1AGX50DF780C6N (second device). The FPGAs are constantly reconfiguring. The CONF_DONE line goes high for about 350ns, then the nSTATUS transitions from high to low and the EPCS_nCS line transitions from low to high. 310ns after that the CONFIG_DONE line goes low again. Roughly 375ns after that the nCEO of the CycloneIII goes high. The nCONFIG line stays high throughout the process.   A small amount of capacitance (my scope probe is 8pF, same effect with a 20pF cap) added to the CONF_DONE line will cause a successful configuration.   The DCLK signal probed at the config device and ArriaGX looks good. 10K pullup resistors are on the nSTATUS, nCONFIG, and CONF_DONE lines. I'm not sure about adding a cap to the CONF_DONE line and then calling the problem fixed. Does anyone have any more ideas on this problem? Thanks.

[Altera_Forum]

I see that your CycloneIII is an engineering sample. So is the one I am using EP3C25E144C8NES. Perhaps this is a bug in the Cyclone III engineering samples?

[Altera_Forum]

You should file an SR with the Altera MySupport line. 

 I seem to recall something with the ES devices and voltage levels and / or where certain signals were connected to (Vccint vs. Vccio, etc).  File and SR.

[Altera_Forum]

Hi Folks, 

 I am seeing correct AS (.pof) and JTAG (.sof) configuration of my EPCS128 and EP3C16 devices respectivly. However .JIC configuration fails to fire up the system. The Altera programmer reports that all is well, but the Config-done pin is never released.  I have filed an SR with Altera as I suspect the .JIC is not being generated correctly.

[Altera_Forum]

I've been using a Cyclone III with a EPCS128. My JTAG port works fine for debug &etc and I can program the EPCS128 OK using a separate header connected to it as per data sheet. In the latter case the Cylone subsequently configures fine from the EPCS128 at power up. However, if I program the EPCS128 via the JTAG port using a JIC file, while programming apparently completes successfully, the Cylone won't subsequently initialise. So it may be that it's something to do with the JIC file?? 

 I'm presuming you've fitted the series resistor on the data pin of the serial memory? If not, this might explain why a bit of capacitance on the clock helps.  Regards  Andy

[Altera_Forum]

This configuration thing is highly annoying - hard to do a confident design for mass-production with tight schedules while this is unresolved. I had exactly the same situation with the probe/screwdriver on CONF_DONE & shorting nSTATUS high. When adding a large cap (>1000uF) on the 3.3V line, then that will not work anymore either. This will also be influenced by the reference used for the pullups and MSEL's, since the behaviour completely changed when I changed the reference used for MSEL from VCCA to VCCIO (3.3V). Athough the errata sheet also makes mention of this, it still didn't really help regardless of tying to VCCIO or VCCA.

[Altera_Forum]

I must confess, that I didn't experience any of the said problems with Cyclone III, apart from a case, where a customer connected VCCA to 1.2V by mistake (according to the Cyclone II use). Some reports are sounding really strange, e. g. the screwdriver thing. However, the manual discusses possible problem with non-monotonous VCCA rise and unsuitable connection of configuration pins. To my opinion, the issue may occur only when supplying VCCA by a separate SMPS. When supplying VCCA with a LDO from 3.3V as we did, this can't happen.

[Altera_Forum]

Could this be a problem just in Quartus 7.1. We are having a similar problem and we did find that for a small design just RTL (Cyclone III C25, Industrial samples) 

Quartus 8.0 works with and without the capacitance that people is talking about with and without compress programming file  Quartus 7.1 SP1 seems to work better with uncompress data streams (no idea why) and works with compress data stream when using the capacitance.  With a design which includes an embedded Nios running form embedded Memories it works in 8.0 and it doesn´t in 7.1.  That´s it mean that the .sof is different from the versions and it is just a matter of luck? Otherwise it something special when using Quartus 8.0 about loading from the EPCS? Could it be something depending on the streaming of the configuration file?