Frontier

I/O Initialization: Beware of Shark Fins!

The default IO termination for many older Lattice devices is pull up. When the device is powering up/down, the IO will ramp up/down following the IO power supply. If the IO voltage is monitored using a scope it will look like a “shark fin.” In some cases this can cause a problem if other connected devices on the board reset or trigger from an active high signal.

Here are some workarounds:
-    Use a quick switch as a buffer between the IO and the other devices; the quick switch is powered-on only when all devices reach recommended voltage levels
-    Have a board reset controller, such as Lattice’s Power Manager II, hold the reset until all devices reach recommended voltage levels
-    Have a pull down resistor to GND such that (1 mA * resistor value) is significantly less than the input threshold voltage of the other devices on the board. The 1 mA value is the typical hot socketing leakage current (datasheet parameter Idk) that could pull up the output during a power up, and possibly during a power down

During normal operation (when devices reach recommended voltage levels) the pull mode for the IO can be changed using the ispLEVER Design Planner or the ispLEVER Classic Constraints Editor. Note that for most of our newer devices (like the ispMACH4000ZE and LatticeECP3) the default IO terminations are pull down.

Glitch Free for the New Year

This is a continuation from my previous blog WYSIWYG Does Not Apply for Input Noise. 

Once you have determined that input noise is causing malfunction in your logic, what are some ways to fix it?  If you have a situation where PCB changes would be painful, try this as one of the techniques that could help you deglitch your clock input:

The register implementation can be used to eliminate multiple clock transitions on both rising and falling edges of the clock. Just hold the registers in a reset state if the clock had unwanted multiple transitions close to each other.

May your New Year be glitch free.  Wishing you a safe and happy FPGA new year.

WYSIWYG Does Not Apply for Input Noise

We have recently run into an FPGA hardware debugging situation where WYSIWYG was not true, so I decided to write this blog post to help you save some hardware debugging time, if you are faced with a similar situation debugging your system with FPGAs.

Most of you who are familiar with hardware debugging can relate to situations where you have an unexpected output switching condition caused by a certain input, but when you put a scope probe to measure what might be causing the problem, the problem goes away. 

With slower process technologies, you may be able to detect a remnant of the input noise when you probe the input signal that might give you a clue.  In our particular case, the input noise was on the order of less than a 1ns wide pulse.  Unless you have access to a 20GHz sampling scope, you will not be able to capture this type of noise condition properly.  To further complicate things for us, this noise pulse was occurring in an approximately 20us timing window.   So we were looking for a 0.005% duration of a pulse in a timing window that we didn't know where it was occurring.

A few key points that you want to preserve in this type of debugging situation are:

1. Preserve the input condition (ie. you don't want to put any scope probe on the input signal) so that the output error condition is preserved.
2. You need to be able to trigger the error condition and be able to observe what the input is doing. 

How do you monitor the input without putting a scope probe on the input pin itself?  In our case, we were dealing with an FPGA, so we could take the suspected input signal, duplicate the node and internally route the signal out to an observable output pin.  Once we did that, we could clearly see that the input signal was causing the input translator to trip by way of the observable output pin.  We really never saw the actual input noise pulse that was causing the problem but we were able to prove that there was a noise condition on the input that caused the input buffer to detect a transition.

Although, we were dealing with 0.18 micron technology for our particular situation, the problem is not going to get easier with 90nm and 65nm devices, which are faster and require capabilities to detect even narrower input noise pulses.

Slow Inputs Acceptable For FPGA?

This is a common question I get when you have system requirements to drive relatively slow input signals into fast FPGA inputs.  "How can I prevent the inputs from causing output oscillation?"

The theory behind this FPGA input or any fast CMOS device input behavior is simple.  As the input rise time gets slower, the signal stays in the input transition point a longer period of time.  This combined with any signal noise associated with the transition causes the input translator to detect false transitions which in turn get translated to the output.  The end result usually is output oscillation.

You can effectively use an input series resistor with the FPGA's internal input bus-hold latches to improve the slow input ramp time tolerance.  It's been demonstrated in our lab that the input ramp time improves from hundreds of nanoseconds to microseconds. More details can be found in the technote posted on Lattice web site.