Steve Leibson

TI Low-Power RF Workshop Covers Four RF Networking Protocols

Texas Instruments is conducting two low-power RF-networking workshops in the immediate future and if you’re working on anything connected with low power, RF, and networking, you might want to consider signing up. There is a 2-day workshop and a 4-day workshop. The workshops are designed for engineers working with TI’s four wireless networking protocols: SimpliciTI, TI-MAC, Zigbee and Z-Accel.  No prior experience is needed with ZigBee technology but you should have basic proficiency with C programming and understand how to use an Integrated Development Environment. All of the information revolves around TI’s MSP430 low-power microcontroller, no matter the RF protocol. The MSP430 is an ultra-low-power, 16-bit RISC mixed-signal processor offered by TI and finds use in a wide range of low power and portable applications.

The first 2 days of the TI Low-Power RF Networking workshop are self-contained and cover the SimpliciTI portion of the workshop agenda. Those attending the $995 2-day class will take home TI’s eZ430-RF2500 development kit. The $1595 4-day workshop adds the 802.15.4 networking protocols (TI-MAC, Zigbee, Z-Accel) and includes TI’s eZ430-RF2480 development kit.

The next workshop will take place in Waltham, MA on October 6, so there’s not much time to sign up. After that, there will be another chance to take the workshop on November 17 in Schaumburg, IL.

More details are here. Contact info:

Beth Rea

Sunnyvale, CA

(408) 543-5315

b-rea@ti.com

Kim Rutherford

Boston/Waltham, MA

(781) 895-9185

k-rutherford@ti.com

Use Sleep Mode for All It’s Worth to Cut Power Consumption

One way to cut power and energy consumption in processor-based systems is to put the processor to sleep. No work gets done when the processor is asleep so you need to wake it up once in a while so it can look around, check to see if anything needs service, and then put it to sleep. That’s what you need to do if some tasks are based on periodic service requirements. Things are easier if all tasks are interrupt-driven. Then all you need to do is let the interrupt-service routine (ISR) awaken the processor.

But let’s consider the case of a periodic time waking the processor for time-based task processing. Actually, let’s consider the case when there are several periodic tasks with different service periods. Often, the approach taken is to analyze the various service periods and then develop an interrupt clock tick that’s the smallest common interval of the various periods. This approach needlessly wastes power because many of the ISR activations will awaken the processor only to find no tasks to execute. Let’s look at why.

The problem arises when tasks do not have periods that are integer multiples of each other or when one or more tasks has multiple modes with different periods. For example, say that one task has a required periodicity of 30 msec and another task has a periodicity of 100 msec. The only way to handle both periods is to set the interrupt time to 10 msec. Then the first task can be executed on every third interrupt and the second task can be executed every 10 interrupts as shown in this sequence:

Interrupt 0: Service 30- and 100-msec task

Interrupt 1: No service

Interrupt 2: No service

Interrupt 3: Service 30-msec task

Interrupt 4: No service

Interrupt 5: No service

Interrupt 6: Service 30-msec task

Interrupt 7: No service

Interrupt 8: No service

Interrupt 9: Service 30-msec task

Interrupt 10: Service 100-msec task

Interrupt 11: No service

Interrupt 12: Service 30-msec task

Interrupt 13: No service

Interrupt 14: No service

Interrupt 15: Service 30-msec task

Interrupt 16: No service

Interrupt 17: No service

Interrupt 18: Service 30-msec task

Interrupt 19: No service

Interrupt 20: service 100-msec task

However, as you can see, out of every 10 timer interrupts, an average of more than five interrupts will result in no servicing because neither the 30-msec nor the 100-msec task needs to be executed. In other words, half of the interrupts that awaken the processor will result in a return to sleep mode with no useful work done but with excess energy consumed.

There’s a way to eliminate these unnecessary interrupts and to save the wasted power consumed by the unneeded ISRs using a little smarter code. Instead of using a fixed-period ISR timer, write the timer code to keep track of the time to the next needed interrupt by tracking the amount of time since each pending task was last executed in a software-updated register or memory counter.

For the above example, the main code would first service both the 30- and 100-msec tasks. Then, it would set the interrupt-timer interval for 30 msec (minus the amount of time needed to execute the 30-msec task). When the interrupt timer goes off, the code executes the 30-msec ISR and then reprograms the timer interrupt for another 30-msec period because that’s the next periodic task scheduled to be executed. The timer code must also deduct 30 msec from the period value it’s tracking for the 100-msec task, reducing that value to 70 msec.

At the next timer interrupt, the timer code again schedules a 30-msec period and deducts another 30 msec from the 100-msec counter, leaving 40 msec. After another 30-msec interval, there’s 10 msec left before the 100-msec task needs to be executed, so the timer code sets the next timer-interrupt interval to 10 msec (minus the time needed to execute the 30-msec ISR). Finally, 10 msec later, the processor awakes, executes the 100-msec task, and subtracts 10 msec from the 30-msec task’s counter leaving 20 msec. So the timer code sets the next interrupt for 20 msec (the time remaining until the 30-msec task should be executed). And so the process continues.

Using this scheme and a simple set of tracking counters for the various tasks to be executed, a real-time kernal can minimize periodic interrupts to just those that are actually required and can thus keep the processor asleep more of the time. For battery-powered applications, this technique can provide substantial power savings and a resultant improvement in battery life.

This blog entry is based on the article “Improving energy efficiency in ultra-low power devices” written by Raúl Martín Rello.

Could A Low-Power Middle Ground Between ASICs/SOCs and FPGAs Help You?

You can’t always get what you want,
But if you try sometime,
You’ll find,
You get what you need.

Those lyrics from a song from the Rolling Stones describes the situation with ASICs/SOCs and FPGAs. For low power, you want an ASIC or SOC. However, there are huge obstacles to using an ASIC or SOC. First, you need a team that knows how to design custom silicon or you need to rent one—which is expensive. If you have your own design team, you should be prepared to drop a million dollars or so on design tools and another million or so on NRE charges. Also be prepared for a 6-18 month design cycle, lots of painstaking verification, and the risk of at least one silicon respin due to design errors or spec changes. High risk indeed.

On the other hand, there are FPGAs. The NRE cost is zilch. The design tools are low-cost or no-cost. There’s no physical chip design required, hence a lot less verification. In short, it’s much easier to design a system based on FPGAs than on SOCs or ASICs, but there’s a price to pay: higher unit cost, less performance, and higher power consumption. All three figures of merit are 10-20x out of whack for FPGAs versus ASICs/SOCs. In addition, you’ll not get the same maximum gate count in an FPGA, not by a long shot.

So if you need an ASIC or SOC, then you need one. If not, and if an FPGA’s part cost, power consumption, and/or performance aren’t where your design needs to be, there is a middle ground. In the recent past, this middle-ground component has been called a “structured ASIC.” That’s become a tarnished name. In the distant past, the name for a similar sort of device might be called a “gate array.” Today, eASIC calls it a “new ASIC.”

What’s a “new ASIC”? If it’s an eASIC Nextreme or Nextreme2, then it’s a predesigned field-of-LUTs device with a preconfigured routing fabric on the metal layers. The only unconfigured layer is the via 6 layer. Standard Nextreme wafers are processed to metal layer 6 and stored. When a design is sent in, the via 6 and metal 7 and 8 layers are added. Depending on how fast the part needs to be made, the via 6 layer is customized using either direct-write e-beam or a standard lithographic mask and then the standard metal 7 and 8 layers are added on top.

So, what do you get from this technology? You get a zero-NRE, FPGA-like device that has much higher silicon density than an FPGA because there are no switches or configuration RAM cells in the routing fabric—just fast, tiny layer-6 configuration vias. Consequently, you get a chip that can clock faster than an FPGA—250 MHz (typical) for a 90nm Nextreme New ASIC and 500 MHz (typical) for a 45nm Nextreme2 “new ASIC.” You get a device that operates at lower power than an FPGA and you get a device that offers more gates/chip at lower component costs (but not as low as for an ASIC/SOC). You also get a chip that’s easier to design than an ASIC/SOC and one that can be delivered in as little as 4 weeks. Design-tool cost is lower than for ASICs/SOCs as well because eASIC offers a specialized, Nextreme-specific version of Magma’s design tools for as little as $8k per seat.

What are Nextreme parts used for? I asked Jasbinder (Jazz) Bhoot, eASIC’s VP of Worldwide Marketing, that question. His answer was both interesting and a bit surprising:

• Cell phone microprojectors (where cost and power dissipation are critical)
• Other microprojectors
• Medical devices such as ultrasound imagers where power is not so much of a problem but device cooling is a big problem
• Portable medical devices that run on batteries
• Wired networking products where Nextreme parts are consolidating several FPGA designs into one chip with much lower power consumption

FPGAs as ASSP/Microcontroller Helpers – When ASICs and SOCs Won’t Do

Without doubt, an ASIC or SOC is the way to create systems with the lowest power dissipation. However, many other factors can mitigate the advantages of custom system silicon. Those factors include a critical and looming market window, a lack of funds for the resulting ASIC/SOC NRE charges and design-tool costs, a design team that simply lacks experience with chip design, or inadequate projected sales volumes to justify the time and expense of ASIC/SOC design. In such circumstances, the design team will usually try to find an ASSP (application-specific standard product) or an off-the-shelf microcontroller that closely meets the design specs and will then fill the inevitable functional gaps with software or firmware.

But what if that’s not possible? What if there is no such ASSP or microcontroller? What if software can’t fill the gap? Then the only choice is to get the hardware as close as possible and then plug the gap with additional circuitry. But extra circuitry brings added disadvantages. First, it adds to the BOM, assembly, and unit-test costs. Second, it consumes space on the circuit board and in applications that are really short on room (such as mobile phone handsets) it consumes additional cubic millimeters that probably cannot be spared. Finally, it consumes added power.

Enter the FPGA vendors, who would have you believe that one of their components can save the day by adding huge numbers of “system gates” at low cost. You can get both large gate counts and low price from FPGAs, but rarely at the same time. Further, FPGAs with large gate counts have large accompanying power-consumption specs. That’s because the major FPGA vendors have pursued performance over all other characteristics and their static- and dynamic-power consumption specs reflect that chase. As FPGAs have become IC process-technology drivers, they have continued to push lithography limits using performance-tuned process parameters. The resulting FPGAs make the most of process speed at the cost of dynamic current consumption and high leakage.

However, if all you’re doing with the FPGA is making relatively simple additions to an ASSP or microcontroller, you may need an FPGA tuned for a different design approach. That’s the philosophy behind SiliconBlue Technology’s iCE65 FPGAs, which employ a low-leakage, albeit slower version of TSMC’s 65nm process to produce low-cost FPGAs (on the order of a buck or two) with microwatt power requirements at moderate gate capacities (a few thousand 4-input LUTs). These small, low-power FPGAs are designed to be ASSP/Microcontroller helpers. They’re designed to allow the needed customization while relegating most of a system to a well-optimized standard chip or chip set.

What can you use such devices for? I asked that of Denny Steele, SiliconBlue’s Director of Marketing and Applications. Here’s the list he reeled off the top of his head:

• An interrupt queue for a GUI-driven application to reduce the frequency that software must bring a host processor out of sleep mode thus minimizing processor power consumption
• A port multiplexer to add an extra SD memory card to an ASSP with only one storage port
• A buffered port switch to allow host and application processors to share storage media such as an SD card
• An interface adapter that allows an existing LCD interface port to communicate with a different sort of display—such as an ePaper or eInk display that has radically different timing requirements
• A parallel-to-serial or serial-to-parallel converter to mate one type of display interface to the other
• An display-format converter so that an ASSP/microcontroller designed for one display size can more easily control displays of other sizes
• A cafeteria of virtual, configurable legacy interfaces that aren’t all needed for any one design but are needed over the full usage spectrum for the final hardware design

Of course, these are just a few of the application ideas for an ASSP/microcontroller helper in the form of an FPGA. Significantly, the FPGA system-augmentation design path can help when product life cycles are quite short, as they are for mobile phone handsets in the developed world (as it so happens, outside of the US in the case of cellular telephony). In such markets, product life cycles are measured in months and design teams may be creating three or four designs per year.

An FPGA-augmented design based on standard handset chip sets comes in quite handy in such situations because the FPGA can be used to add features that end-users notice such as enhanced display resolution, touch screens, extra SD or SIM cards, and so on. Such desirable features prompt customers to unsheathe their credit cards. One board-level design with FPGA augmentation can accommodate more than one product design and more than one product generation without requiring a BOM change. That’s a real competitive advantage in today’s quick-turn world of consumer electronics.

Consequently, this is the world for which SiliconBlue optimized its iCE65 FPGA. The device is tiny—as small as 3×4 mm—to fit in small, handheld consumer products. A 4000-LUT iCE65 device draws a mere 15 microamps at 1V when running at 32 KHz, the standard heartbeat of a mobile phone handset in standby mode. That’s slow enough to use very little power but fast enough to catch an event that merits waking the host processor. Of course, the FPGA can run much faster, with higher resulting dynamic power consumption.

Are these low-cost, low-power, small-size optimizations enough to create a niche for SiliconBlue in the fiercely competitive FPGA market? “We’re betting the farm that customers will want to do this” replied Steele.