Cyclone II + NIOS design crashes with high IO pin drive strength

[Altera_Forum]

I have a commercial design for a Cyclone II FPGA which communicates with an external SDRAM chip. 

The FPGA contains a NIOS system designed in QSys, that run's its 'C' code from the external SDRAM.  When originally laid out on a 2-layer PCB this worked fine, but when the same schematic was re-laid out for a 4-layer PCB, the FPGA design didn't work on it any more.   (The middle two PCB layers under the digital circuitry are both ground planes) (All the IO pins use VCCIO = 3.3V signalling levels. The IO pins used the default drive strength of 24mA.) (The FPGA is fed by a 48MHz oscillator which goes into an ALTPLL to produce a 64MHz internal NIOS system clock and a -54 degree phase-shifted 64MHz clock which goes off-chip to the SDRAM)   The symptoms were that when the code was run from Eclipse, the the JTAG debug would stop responding and would return a stream of 0xFF characters shortly after the FPGA entered user mode.  Bizarrely, I can make this 4-layer PCB design work by reducing the IO drive strength of all the FPGA IO pins to the minimum! (4mA)  My question is, what is the underlying problem that would cause these symptoms, and why would reducing the IO drive strength appear to fix the problem?

[Altera_Forum]

Higher I/O strength = fast edge transitions = more coupling to other traces and higher current requirements from the power supply. 

 It sounds like you have a layout issue on your new board, eg., traces routed too close to each other, or a clock missing a termination resistor.  If the problem occurs with the JTAG interface, take a look at those signals with a scope. Perhaps there is a clock-like signal routed nearby that is coupling onto the JTAG signals.  If the FPGA package is a TQFP, do the VCC pins have decoupling capacitors on the same side of the PCB as the FPGA, i.e., right next to the power pins?  Cheers, Dave

[Altera_Forum]

The JTAG signal routing looks reasonable. Yes, it is a TQFP package.  

Each VCCIO pin has its own adjacent 0.1uF capacitor on the same PCB side as the FPGA.  The clock to the SDRAM from the FPGA has a 68R series terminating resistor adjacent to the FPGA, then the track goes off to the SDRAM. (The data tracks are 8mil (0.208mm), so I calculate the microstrip track impedance to be 87R)  The 3.3V is well decoupled on the board by a 1000uF electrolytic, numerous 10uF tantalums and innumerable (0603) 0.1uF ceramic caps. However, the 3.3V regulator is not on the PCB; the 3.3V it is supplied from an external SMPS, and it enters the board via a MURATA - BNX002-01 - DC FILTER. Ref: http://search.murata.co.jp/ceramy/image/img/pdf/eng/l0117bnx00.pdf As you can see from this datasheet this filter goes between the PCBs the ground-plane and the 3.3V plane, and the external SMPS's 3.3V and ground. I don't know if this is relevant to the problem or not? Could this PSU arrangement and/or the input filter be contributing to ground bounce, transient voltage sag, or some other electrical ailment?  NB: I didn't do the PCB design I am just debugging it for a client.