Two trends I didnít see

Every magazine and blog that covers DSP, FPGAs, and related EDA technologies issues a credible tech trends forecast. Guys like John Blyler at Chip Design, Rich Nass at Embedded Systems Programming, Kevin Morris at FPGA Journal, and even our very own contributing editor Will Strauss of Forward Concepts are all smarter than me. So why risk my reputation by offering the same old predictions you’ve read elsewhere?  Instead, let me reveal two trends I wanted to see over the last 12 months but didn’t. Each of these could have huge ramifications on the entire industry, if I could only will them into existence. Maybe next year.

FPGAs in cell phones I know I’ll get a nasty-gram from a reader telling me about some FPGA that’s already installed in a cell phone design, but I’m referring to a Virtex II Pro-like device slimmed down in price and power. This would enable replacing the ASSP every handset manufacturer relies on for the DSP front end. Even though TI’s OMAP and IBM’s Power architecture are perfect platforms from which to start a custom design, nirvana will be cheap and reconfigurable FPGAs that would enable true over-the-air programming not just of the firmware and SIM functions like today, but of the entire handset’s radio and user interface.

Think about this for a minute. In the U.S., handset sales are primarily driven by the carriers. Although you can conceivably buy a network-compatible handset for, say, Verizon and then have it begrudgingly activated by the carrier – friends have told me this is such a hassle it’s not worth it. And companies like Sprint and Cingular don’t make much money off the handset – they want your recurring monthly revenue and the add-ons like ringtones and picture messages. Getting locked into a 2-year contract irritates consumers (but protects the carrier’s subsidies on equipment), and come on - the next handset you buy is rarely that much better than the previous one. So now brown (excuse me, chocolate ) is the trendy color? But the guts are similar.

They aren’t getting much smaller anymore nor is the battery life increasing exponentially. Instead, the next handset usually offers newer features – plus the usual trendy case color. Wouldn’t it be better to keep a handset longer but upgrade the feature set? Software defined radios (SDR) would keep the RF portion “fresh”, while an FPGA-based subsystem could allow a complete handset reconfiguration. With so much IP available for FPGAs – from better audio codecs than MP3 such as Ogg, to H.264 video – using an FPGA in a cell phone’s a no-brainer.

Alas, for now all that performance, density, and I/O comes at the expense of, well, power and expense. Xilinx swears they’re not eyeing this market, but some of their Spartan-3 announcements and feature enhancements make me wonder. And Lattice is feverishly working their way up-market with their ECP2M family and recent LatticeMico32 architecture. Lattice might move up faster than Xilinx can move down. Optimizing SWAP (size, weight and power) in cheaper FPGAs would reverberate across the entire embedded market, not just cell phones.

Still too darned complex DSP relies on complex math – and I do mean I and Q. But unlike running code on microprocessors, where the software engineer doesn’t have to worry about race conditions, silicon fan out, or gated clocks, why the heck do DSP designers need to worry about hardware-level issues?  I mean, FFTs , FIRs, and twiddle factors are complex enough. But designing with DSPs – despite the best efforts of companies like The MathWorks (Simulink and MATLAB) - tools only solve a piece of the bigger system problem.  And the new trend towards Electronic System Level (ESL) design at least steps back a bit to look at the bigger picture, but it’s usually narrowly focused on sub-system details such as a single device.

To me, this is all still too micro. Editor John Blyler of Chip Design did a great job of summing up ESL’s complexities in his June/July 2006 issue. But that’s just it: it’s still too complex. I had hoped that 2006 would start to move the industry away from “coding at the metal” while being forced to deal with the nuances of transistors and floorplanning. Think about it – when you use Windows programs are you expected to know how to write them? Need you modify the registry just to get Excel to calculate a large spreadsheet?

We need much higher level system-level tools that mask the details of the silicon as well as the details of DSP’s mathematical constructs. For me, I’d be happy with a bunch of Eclipse-like open source tools that designers “drag and drop” together to help create, simulate, and validate systems. Alas, I don’t see much movement in that direction yet since the industry’s mired down in the details of ESL, DSO, and other anthills.  Fixing this problem might take some of the mystery out of designing embedded signal processing systems – by hiding the details only experts need to worry about.