Cool in the Spotlight
QuickLogic Focuses on Low Power

QuickLogic knows who you are. They’re here to help. First you need to admit that you have a problem. Maybe you’re the one that just finished the second revision of your Mobile-Super-Franistan only to be told by the “marketing” people that the next version needs to be the “Wi-Fi enabled Mobile-Super-Franistan. (You know the marketing people, they’re the ones down the hall that don’t wear jeans and Land’s End shirts to work - the ones that put animation in their PowerPoint presentations until they found out it was geeky…)” Well, Wi-Fi shouldn’t be a problem, right? There are chipsets for that. However, in the last round of cost reduction, you decided to pull out the PCI and go with a proprietary bus. Now you need something to bridge the gap to the PCI interface on the Wi-Fi, buffer data, and not use any power at all, because you’re already near your power budget with the addition of the 802.11.

QuickLogic’s recently announced Eclipse II super-low-power antifuse FPGA family is another worthy attempt at changing the rules and the perceptions of FPGAs. While FPGAs have a reputation for being low-speed, high-power, volatile devices, Eclipse II has none of these properties. Eclipse II offers a density range that’s clearly in FPGA territory (ranging from about 50K to over 300K system-gates). It is non-volatile, very fast (over 300MHz 16-bit counter performance), and extremely low power, with 0.17µA standby current and impressively low dynamic power. In addition, Eclipse II has other FPGA-like features, such as embedded RAM, that clearly differentiate it from popular CPLD families.

QuickLogic took a careful look at the market and realized that there was a gaping hole in the area of high-capability FPGAs with ultra-low power consumption. Because of their high-power heritage, FPGAs have traditionally been barred from most applications that run on batteries, have power-supply limitations, or have trouble with heat dissipation. As a result, the only options left for many design teams were costly ASIC designs, low-density CPLDs with accompanying memory, or Rube Goldbergian arrangements of ASSPs and standard parts with bits of customized logic in PLDs and separate RAM.

As you may have heard, all low-power PLDs are not alike. Power consumption comes in a variety of styles and colors, and it is important to know your power profile when designing with a low-power technology. The most common bragging point for power-misers is standby current. Lots of CPLDs boast about their standby current because lots of designers use CPLDs to wait quietly in standby mode until the user decides to do something with the device, and then “wake up” the rest of the design (which often includes an FPGA) to go into active service. The lower the standby current, the longer the device can wait in standby mode without requiring a recharge. Standby current is measured when the device is not clocked and is generally a function of leakage and temperature. At smaller geometries and lower voltages, this leakage is more significant, so latest-generation devices can sometimes be worse than older ones.

Standby current is all well and good, but what happens if you have to actually do something? That's when two more “power” players enter the FPGA arena: power-up/configuration power, and dynamic power. Power-up/configuration power is the power consumed by an FPGA device as it resets and configures itself. Because SRAM-based FPGAs are volatile, they have to be reconfigured each time they are powered up. The configuration process creates a power spike that is often two or three times the normal operating current, so power supplies have to be designed to provide adequately for that spike.

Dynamic power is generally a function of operating frequency. For SRAM-based FPGAs, that can quickly amount to almost 1A at reasonable frequencies. Unless your idea of “battery-powered-application” is something with a Sears Die-Hard, most SRAM-FPGA devices are probably out of your power-range.

It’s not just battery life that drives power limitations, however. Many common standards such as USB, Cardbus, MiniPCI, and SDIO have a specification for maximum current draw for any device that connects to them. Sometimes, even AC-powered applications have power limitations as enclosures get tight with no cooling fan, or power supplies get strapped with large peak loads during startup sequences.

Eclipse II slides under these power limits like the little guy at a limbo contest. Because the device is non-volatile, there is no big configuration and power-up spike, and the antifuse-based fabric offers higher dynamic operating frequencies at lower power than can currently be achieved with SRAM-based technologies.

So, why doesn’t Eclipse II go any higher in density? It’s those darn marketing guys again. While the idea of a higher gate count device might be exciting, the target applications for the family are all well served at the current density range. If, as in our earlier example, you’re adding Wi-Fi to an existing application, you probably don’t want to redesign the whole thing. Eclipse has just the right feature set (gate count, memory, I/O) to support the needs of the mainstream customer without adding lots of costly area- and power-consuming capabilities that would run the devices (and yield) out of the high-volume cost range.

Where’s the downside in all this? Well, antifuse-based FPGAs are unique in their lack of reprogrammability. You burn them once, and they’re done. This means the usual FPGA development methodology won’t work quite as well. “Burn and learn” isn’t as appealing when you throw away a device with each iteration and you have issues with mounting on your prototyping board.

How do you compensate for this? First, antifuse vendors are acutely aware of the issue and have strong support programs in place to help ease the process. QuickLogic has a number of development programs aimed at reducing the risk of designing with antifuse devices, and most design teams use reprogrammability only for development purposes anyway. Second, you’ll want to modify your process to be a little more ASIC-like with a greater reliance on HDL simulation and fewer iterations in hardware. Third, you’ll want to leverage the handy QuickLogic re-usable sockets on the prototyping board with a handy PEZ-dispenser loaded with prototyping devices for your development use.

Once you’re past the one-time programmable hurdle, there are numerous benefits to the technology. Antifuse is harder to reverse-engineer than SRAM-based FPGAs, more immune to radiation, and faster at any given process node. Their non-volatile nature also means instant start-up with no configuration and single chip solutions rather than the multi-device set required for SRAM.

Recently, QuickLogic has upped the ante on low-power design, rolling out their new design tool suite with power analysis and optimization built in. The optimization software takes advantage of the clock tree architecture of the Eclipse II devices and uses power-driven physical synthesis techniques (similar to better known timing-driven physical synthesis) to minimize power consumption for any given design.

QuickLogic’s newly developed tools are easy to approach even for the novice designer, and, together with the Eclipse II architecture, they form a compelling solution for applications that demand low cost, extremely low power, and the schedule and flexibility benefits of a programmable logic-based solution.

Kevin Morris, FPGA and Programmable Logic Journal

April 13, 2004

[back to top]

Comments on this article? Send them to comments@fpgajournal.com