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.

WISHBONE Connectivity: Power without the Overhead

One of the most common questions that programmable logic designers face today is how to connect unique, disparate modules in their system.  That is to say, “Block A needs to talk to block B and vice versa. What bus should I choose?”  There are a plethora of choices that the designer can choose from, but what most designers really need is a proven, simple-to-connect bus interface without the overhead of many proprietary bus interfaces.  Enter WISHBONE.

In case you’ve not heard of WISHBONE, it’s a popular, open source hardware interface that is promoted by the OpenCores project (http://www.opencores.org).  Being open source offers several advantages for programmable logic designs:

Open source designs:  The OpenCores project is the web’s main proponent of the WISHBONE architecture.  In addition to its role as WISHBONE advocacy, the OpenCores website offers many grass-roots built RTL modules that are available for users in both Verilog and VHDL, many of which are of course, WISHBONE ready.  This means that a designer can attach their own WISHBONE design to one or several of these OpenCores designs, saving development time on both core functionality and bus connectivity.

Flexibility: Perhaps the most subtle advantage of WISHBONE is its flexibility.  Unlike most bus system, WISHBONE can be implemented as any one major bus types including hierarchical, point-to-point, or many-to-many.  In addition, a WISHBONE bus can be multi-master or single master and can be 8, 16, 32, or 64 bits wide.  The net effect of this flexibility is that WISHBONE is appropriate for programmable logic designs of almost any complexity.

Proven:  The WISHBONE interface is a well-defined standard, has been around for more than six years and has been implemented in hundreds, if not thousands of systems.  If you want a flexible, but low-risk bus architecture, WISHBONE fits the bill.

The Price: As stated on the Opencores website: “The WISHBONE standard is not copyrighted, and is in the public domain. It may be freely copied and distributed by any means. Furthermore, it may be used for the design and production of integrated circuit components without royalties or other financial obligations.”

Lattice and WISHBONE:

Lattice believes in the WISHBONE credo and has several resources for Lattice users:

LatticeMico32:  This is Lattice’s own 32-bit “soft” microprocessor.  It has a native WISHBONE interface and is free with an open IP core licensing agreement.  The power of the LatticeMico32 lies not only in the flexibility of the core itself (it’s synthesizable), but also that it can be connected to any WISHBONE peripherals including open source cores or your own, custom logic.

Reference Designs: Lattice offers several freely downloadable WISHBONE reference designs as a starting point for user designs.  These reference designs come complete with documentation, RTL, and testbenches.  WISHBONE modules include an I2C bus master, a SPI controller, and a LatticeMico8 WISHBONE adapter.  Again, since they are WISHBONE, these reference designs can be combined with OpenCores designs or a LatticeMico32.

System Examples:  Our successful MachXO Mini Evaluation Board comes with a native demo (“Mini SoC Demo”) that illustrates the WISHBONE bus in a working system. This demo includes our 8 bit LatticeMico8 soft processor, a UART, an I2C master, and a SPI memory controller, all connected on a WISHBONE bus.  A Lattice user can examine the WISHBONE bus connectivity by downloading the RTL and documentation for this demo at our MachXO Mini Development Kit website. At this website, find the “Demo Applications” button under “MachXO Mini Development Kit Resources” at the bottom of the page.  You can also view a video of the demo or experiment with it yourself by purchasing the board from the MachXO Mini Development Kit website.

System Power Management: Risk versus Integration

Board design engineers are faced with a dilemma for each new microprocessor based system design that they encounter: how to integrate more processor power management function with the least amount of risk. How can we implement voltage monitoring, reset generation and watchdog timers while as few components as possible, while at the same time, keeping a shorter development cycle?

Rather than taking a traditional approach to assessing the tradeoffs, I’d suggest that we need to carefully consider the two most critical definitions:  What does “integration” mean and what does “risk” mean?

In board development discussions, integration usually means reducing the number of components on your board by bringing as much function as possible into as few components as possible.   Likewise, risk is commonly associated with the complexity of the board that you are bringing to market.

I propose that the most accurate definitions of risk and integration imply both a physical aspect and a process aspect.  That is to say, risk can be quantified not only from the physical complexity of a board, but also with the complexity of the process that brings the board to market.  In the same way, integration can mean not only a reduced BOM (bill of materials) but also a simplified development process.

Whether risk and integration complement each other or not depends on how they are combined.  Higher levels of power management integration can bring more risk if the new solution is unproven.  On the other hand, higher levels of integration can actually reduce risk if new parts actually simplify the processes that are required to bring the board to market. The right balance is achieved when we can find new power management solutions that not only increases integration, but also reduce the risk.

The mission of the ProcessorPM POWR605 is to do just this.  That is, to reduce complexity and risk not only in terms of the physical board itself, but also in the process that brings it to market.   The ProcessorPM reduces the physical complexity of a processor power solution by bringing voltage monitoring, processor reset and watchdog timer functionality all under one roof.  Higher integration and a reduced BOM translate into lower risk.

The ProcessorPM comes with a tested and pre-programmed, factory configuration. The factory configuration integrates voltage monitoring for 5V, 3.3V, 2.5V and 1.8V supply monitoring with a CPU reset and watchdog timer interrupt output generation.  Although the user can change the programming, there is no need to do so if the default functionality suits their needs.  All they need to do is include ProcessorPM into their schematics and select the appropriate strap values to set watchdog delays and reset pulse stretching.   This simplifies the development flow and reduces risk by eliminating the need to develop and test a new configuration.

Integration and risk will continue to be factors in the ever advancing pace of microprocessor based systems.  The savvy engineer will continue to look for ways to optimize both for their system power management.