Frontier

FPGAs and Your 'Right' to a Timing Constraint

In applications engineering we are often asked, “Why is my simple FPGA design not routing?” or “Why does my CPLD design have such a large timing score?” Sometimes we’ll also hear “PAR is taking forever, and then it fails!” In many cases, the solution is embarrassingly simple: “Create a timing constraint!”

Any fan of police shows can probably recite the rights that the police read to the suspect (known in America as “Miranda Rights”), which include “You have the right to an attorney. If you cannot afford an attorney, one will be appointed for you.” FPGA designers should be aware of similar advice: “You have the right to use a timing constraint. If you don’t provide one, a timing constraint will be provided for you.” With lawyers, sometimes you get what you pay for. So it is with FPGA Place-and-Route (PAR) software – in most situations it is better to provide your own reasonable constraint.

Users of large CPLDs and small FPGAs will sometimes cram lots of simple logic into the limited space available with no clocking constraint specification. The assumption is that because the clocking requirement is so slow (e.g. 32 kHz,) no timing constraint should be necessary. These users make the presumption that the PAR engine simply will route the clocking network, albeit with a very inefficient and slow structure. As counter-intuitive as this seems, nothing could be further from the truth. Why? Read on….

PAR algorithms require a timing constraint. Without a user-defined timing requirement, the mapping process generates its own timing estimate and passes this to the PAR process. Your simple design suddenly must meet a court-ordered 30 Mhz constraint! To compound the problem, as your FPGA or CPLD resources near their capacity (e.g. 85 to 90% and higher), there are fewer and fewer logic tricks and routing channels available to alleviate the timing pressure. In the end, you’re stuck with a design that doesn’t meet timing or doesn’t complete PAR, simply because you (unwittingly) directed the tool to use a clock definition that was more aggressive than it needed to be.

Constraints (‘Preferences’ in Lattice lingo) are contained in Lattice Preference Files (.lpf). These text files can be edited with any simple text editor. In addition, Lattice Design software (ispLEVER and Diamond) provides GUI editors to simplify preference specification.

Get out of jail free! Add a single timing constraint to your design.

Free Diamonds?

This week (June 28) Lattice released a new design and implementation software package called “Diamond.” Diamond features a complete modernization of the GUI, which means new and old customers will be able to design with our products more quickly, more efficiently and with better results.

For those familiar with designing using ispLEVER tools, making the upgrade to Diamond is easy; in fact,  you will find a number of the backend engines like MAP, PAR, and TRACE are based on those found in ispLEVER 8.1. The modern GUI features direct task navigation, centralized reports and summary, extensive cross-probing, and integrated NCD Editor and Programmer. The Diamond tool continues to bundle the popular third party tools Synopsys Synplify Pro and Aldec ActiveHDL.

Some of the new advanced features found in Diamond include Implementations and Strategies, integrated HDL checking, Run Manager, expanded TCL support, and expanded OS support. One of my favorite new features is the new Timing Analysis tool, which is much easier and faster to use. The new Timing Analysis view offers an easy to use graphical environment for navigating timing information. Click on a constraint and see the timing paths, detailed paths, and path Floorplan/Physical views instantly. Easy visual cues, such as coloring constraints that fail in red, provide instant feedback on your design. A key new benefit in Timing Analysis view is rapidly updated analysis when timing constraints are changed. You no longer have to re-implement your design to re-run a TRACE report. Instead, change a timing constraint, click update in Timing Analysis and your analysis report is run directly.

Videos of the new Timing Analysis in action can be found at:
http://www.latticesemi.com/products/designsoftware/diamond/videos/index.cfm

To get your free Diamond visit:
http://www.latticesemi.com/products/designsoftware/diamond/downloads.cfm

Analog For Nothing and Bits For Free: ADC’s Using LVDS Buffers

My apologies to Dire Straits.  However, their hit song “Money for Nothing” illustrates a tendency in common observers:  An expert can makes something which is difficult appear to be very easy.  Whether it be a rock star playing the guitar or a major leaguer fielding a sharp-hit ground ball, a ‘pro’ gets it done with minimum effort and maximum results.

Likewise and at first blush it may appear that measuring analog voltages with a digital device such as a CPLD or FPGA is difficult, if not impossible.  But by leveraging LVDS input buffers (present in larger MachXO CPLDs or most Lattice FPGA families) in conjunction with Sigma-Delta modulation, that which was once considered ‘difficult’ is made easy.  Maximum results are obtained with minimum effort – 8 to 12 analog-to-digital conversion bits are achieved for virtually ‘for nothing.’

How does this help you, the designer?  Say you have a small, cost-sensitive design with a small controller and Lattice CPLD.  You could install a dedicated power-supply supervisor device (at extra cost) to monitor the uC core voltage. Or…you route the supply voltage through a simple and inexpensive RC network to an LVDS capable input and directly measure the analog voltage input to an accuracy within millivolts.

To that point, Lattice has released a new reference design on our website, RD1066 – “Simple Sigma-Delta ADC.”  It is a high capability, parameterized Sigma-Delta convertor capable of producing thousands of samples per second at up to 10 bits of effective resolution.  At about 50 LUTS, multiple copies can be used to monitor multiple inputs - Multiple power rails, battery voltages, sensors or feedback controllers – with plenty of logic to spare for your application.

Now that, is an analog for (almost) nothing and bits for (almost) free.

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.