Stratix III CLK Input Not Driving FPGA

[Altera_Forum]

I'm having a clock related issue with a Stratix III (EP3SL70F484) part on a custom PCB. The board is setup to feed a 1.8V 12MHz clock signal to the CLK0p pin on the FPGA. The clock signal originates from a 3.3V oscillator connected to a 1k resistor divider. Upon inspection on an oscilloscope, the signal appears to be a valid clock (right frequency, peak-to-peak voltage, the voltage undershoots a little, but I don't think it should not be enough to cause a problem). 

 I loaded some dummy VHDL to strobe some LEDs to make sure the FPGA was "seeing" the clock. After loading the SOF a number of times, I would say that it works about 10%-20% of the time. If I'm lucky and it works, it will keep working until I power the board down. If board has been off for some time, loading the same SOF does not cause the LEDs to strobe.  I've tried a number of things including replacing the 1k resistor divider with 470Ω resistors, changing the fitter settings (turned off auto global clock, which seemed to have positive results at first, but then showed the same issue), and adjusting the current settings for the IO pin. The VCCIO lines are connected to appropriate voltage levels.  One more interesting thing: the current draw of the board when the LEDs are not strobing is 1A. The current draw when they are strobing is 300mA (which is what I would have expected from the board in that state). I have not detected any short on the board, so there is no external reason for this to happen (I've literally seen the board work and then not work without touching the board or power connections, but just cycling the power and reprogramming).  I cannot figure out why the clock does not seem to drive the circuitry most of the time, and why the same SOF would work only sometimes, but not most of the time. Has anyone seen this behavior before, or have any ideas on how to fix it?

[Altera_Forum]

Are you sure the FPGA is getting configured? The board will likely draw more current with the FPGA not configured. 

 I would add a small signaltap instance to your design. If you can connect to the signaltap instance, you know your design is running and you can see if the clock is running or not.  Jake

[Altera_Forum]

Thanks for the reply! 

 I'm pretty sure the FPGA was getting configured, since the current draw would change markedly after programming. The LEDs connected to I/O lines were weakly pulled high before loading the SOF, but not afterwards.  I tried adding a signaltap instance to the dummy VHDL, but when I tried to acquire data, it would sit waiting for the clock. It would seem that internally, the clock signal is not getting through. But that does not explain why the LEDs would sometimes strobe in the past. I have not observed the LEDs to strobe after adding the signaltap interface, however.  Interestingly, after adding the signaltap interface, the current for the board after loading the SOF is always 400mA (previously it was 400mA when the LEDs strobed correctly, and ~1A when the LEDs did not strobe at all). Perhaps there is an optimization quirk/error in the fitter that was causing the exceptionally high current?  It feels like the problem changes as I try to debug it -- I'm completely stumped on this one.

[Altera_Forum]

Well the signaltap served it's purpose. It told us two things: 

1 - The FPGA is getting programmed. 2 - You have no clock.  Have you probed the via at the FPGA for the clock?

[Altera_Forum]

Yes, I probed the clock and it looks OK (12MHz, 1.7V Pk-Pk) although the signal is a bit overdamped (12ns rise/fall time, out of 83ns period) I wouldn't expect it not to work. The clock is generated by a 3.3V crystal controlled clock oscillator that is only connected to the FPGA through a resistor divider, as I mentioned before.

[Altera_Forum]

What did you configure the I/O standard to be for the pin in Quartus? 

 Jake

[Altera_Forum]

The I/O Standard is configured as 1.8V. But you got me thinking, so I checked the corresponding VCCIO lines and discovered that the 1.8V supply was not putting out 1.8V! (the power supply upstream is not normally enabled, and when it is enabled, does not supply enough voltage for the 1.8V digital supply). After fixing the issue with the power supply upstream, the power supply produces 1.8V and VCCIO now receives the proper voltage. Like magic, now the FPGA sees the clock, and my test program strobes the LEDs.  

 In an ideal design, all the circuitry for a given I/O bank would use the same supply as the VCCIO pins -- stepping down from a different voltage source added a whole other layer of complexity, especially when one supply is disabled, and the other is not. Oh well -- live and learn, I suppose.  Thanks jakobjones for all your help!