For years, we’ve talked about how FPGAs have the potential to accelerate digital signal processing (DSP) algorithms, producing higher performance with lower cost and lower power consumption than traditional DSP processors*. Whoa! Did you see that – the asterisk at the end of that claim? It’s true, though. Using the parallel computing capability of a typical DSP-enabled FPGA (one with hardware multipliers, MACs, or DSP accelerators) you can get tens to hundreds of times the throughput of a DSP processor running the same algorithm in compiled C code*. Hey! There it was again!
That little asterisk, it turns out, is probably worth hundreds of millions of dollars per year in silicon revenue. The footnote that always links to that asterisk says something like “FPGA-based DSP is tens to hundreds of times more difficult to design and implement than processor-based DSP.” Ouch.
Don’t believe it? Have a race. Take two DSP experts and ask them each to implement the same complex algorithm, one with a DSP and one using an FPGA. Don’t do some wussy FFT or FIR filter, either. We all did those in grade school. Pick something with a little substance and complexity to it. What you’ll probably find is that the software-based DSP dude will be in the latter stages of debug and performance tuning while the FPGA fan is still trying to download, install and license the web-based toolkit from an FPGA vendor, completing lesson two of the online VHDL tutorial, and trying to understand what “logic synthesis” means. Is that anything like a compiler? What exactly are false and multi-cycle paths to a software-trained DSP designer, anyway?
A typical scene might play out something like this:
Industry: “Hey, nice job on that last DSP design.”
DSP Designer: “Thank you. It only took me four days.”
Industry: “I know, and a fine piece of work it is! But, how would you like it if your next design could run a hundred times faster?”
DSP Designer: “Wow, that would be awesome!”
Industry: “It’s simple; you can put it in hardware in an FPGA. First you learn VHDL. Don’t panic, it’s just another programming language. Then you design a microarchitect…”
Whooshing sound. Door slams offstage. Doppler-shifted, receding, fading cry in the distance “Aaaaaaaaaaa”
Industry: “Hey are you still there?”
DSP Designer: “…”
Industry: “Hello?… Come back! I have hundreds of millions of dollars of excellent silicon to sell you!”
When Xilinx acquires AccelChip, they’re not just adding another EDA company to their stable. They’re securing a lynchpin in their long-term DSP strategy. To understand why, let’s imagine a Venn diagram. On the left (Group A) are the people doing DSP design in Matlab. Group A is very large indeed. Lots of happy MathWorks customers are developing DSP algorithms. On the right (Group B) are the people designing FPGAs. Group B is also very large, although probably somewhat smaller than Group A. Xilinx and Altera each boast tens of thousands of active designers. In the middle, of course, is the intersection, A∩B. These are the people taking those Matlab-designed algorithms into FPGA hardware. A∩B is much, much smaller than either A or B. It’s filled with the few hearty souls who didn’t run from the room in the auditions for our mini-drama above.
AccelChip’s business plan has always been to sit in the center of A∩B, attracting people from the left side into the middle. They want to erase that pesky asterisk by providing a safe, secure passage of that algorithm from Matlab into something that can be used in an FPGA without requiring the DSP designer to face the full horror of hardware implementation. They have a proven, technically sound solution that has rapidly evolved in quality and robustness over the past few years.
The problem at AccelChip has always been one of scale and business model. Regarding scale: on the left (in Group A), we have the Mathworks gigantic global sales and support operation; on the right, similarly huge sales and support infrastructures handle the large FPGA vendors. Connecting the two, and attempting to push a river through a garden hose, AccelChip’s startup-sized sales and service channel was working to support the miserly migratory traffic.
The business model challenge was similarly intractable. AccelChip, as a standalone company, was hoping to earn their keep by deriving revenue exclusively from design software and IP. Both the MathWorks and the FPGA customer bases are accustomed to wide distribution and subsidized software offerings, where the cost of developing complex software tools has been amortized over hundreds of thousands of customers or offset by substantial silicon revenues. Neither customer base was excited about paying the true premium price required for a company like AccelChip to maintain a profitable business around a small-distribution, complex software tool.
As a part of Xilinx, however, both of AccelChip’s former Achilles’ heels disappear simultaneously. Jumping aboard the Xilinx juggernaut, AccelChip’s products will likely benefit from the huge, well-distributed and well-respected Xilinx channel. Also, by joining a company where software isn’t required to pay its own way in revenues, AccelChip’s wares can affordably reach a much larger target audience.
For Xilinx, AccelChip represents a key link to the industry’s largest source of DSP design data – Matlab. By paving the path from Matlab to FPGA with something smoother than HDL-based design, Xilinx has an opportunity to supercharge the stream of DSP designs flowing into FPGAs. Furthermore, by acquiring exclusive control of that tool chain, they deprive rival FPGA companies from taking advantage of that same route. Acquisition of AccelChip is simultaneously an offensive and a defensive tactic.
At the same time, the number of suppliers that the typical Matlab-to-FPGA customer has to deal with is reduced. If you already own Matlab, it’s a lot easier to talk your boss into letting you get Xilinx’s latest DSP development kit than it is to justify that same kit in addition to a relatively expensive software tool from a startup company. In addition, you now won’t have to choose from a purely IP-based Matlab -> Simulink -> FPGA flow and a Matlab -> Synthesis -> FPGA flow. Xilinx’s new solution will clearly support both models.
Fewer suppliers, broader support, potentially lower prices, and an easier path to hardware all mean lower barriers to adoption of FPGAs (and more specifically, Xilinx FPGAs) for DSP designers. While it’s far too early to estimate the impact on the industry, improving the road for DSP designers driving into FPGA territory is bound to be a good thing for programmable logic.
