A bit of an eye opener
Of course, you're probably saying to yourself (somewhat sooner than usual, even for this column) "The boy's a fool - nothing will perform faster than a dedicated ASIC," but as usual there's a lot more to the story than meets the eye. In fact, there are so many aspects to this tale that I hardly know where to begin.

So let's start with the fact that a product like a software defined radio (SDR) wireless handset typically contains a mixture of ASIC, DSP, and RISC microprocessor material. In order to reduce size and power, these will probably be implemented as a number of cores in a system-on-chip (SoC).

The RISC material appears in the form of a general-purpose microprocessor providing high-level, non-compute-intensive control functions --and games (grin). The DSP material is used because it's way faster than the general-purpose micro, and its software can be developed way faster than an ASIC can be designed. The ASIC material is reserved for the most compute-intensive, mission critical functions only, because ASICs have two big problems: they take a lot of time and money to develop, and any algorithms they contains are effectively "frozen in silicon." This latter point is a bit of a downer in the wireless world where standards can change faster than you can say "I love this standard... Oh #$%%^&!"

What QuickSilver demonstrated was a single piece of silicon performing compute-intensive elements of both WCDMA and CDMA2000. These are two of the more hairy wireless baseband protocols, and it's almost unheard of for a single piece of silicon to do both. Furthermore, the functions that were tested are invariably implemented using fixed-function silicon (FFS) in the form of ASIC material, but the ACM implemented these functions in software, and this software outperformed the ASIC by 3x. Well, you can tickle my toes with a mallet if this isn't exciting news.

Spatial and temporal segmentation (SATS)
I just can't help myself from talking a little about the technology because this is so cool, but it's also necessary to have a high-level understanding as to what an ACM does and how it does it in order to understand the implications with respect to life, the universe, and EDA.

The ACM is a new type of digital IC whose architecture is designed to allow dynamic software algorithms to be directly mapped into dynamic hardware resources on-the-fly, resulting in the most efficient use of hardware in terms of cost, size (silicon real estate), speed, and power consumption. One of the most important aspects of the ACM is its ability to have its architecture change on demand tens or hundreds of thousands of times per second, while consuming very little power. This distinguishes the ACM from any other IC implementation technology, because it can perform spatial and temporal segmentation (SATS).

SATS is the process of rapidly adapting the ACM's dynamic hardware resources to perform the various portions of an algorithm in different "segments" of time and in different locations on the ACM. As a simple example, consider that some operations on a wireless phone are modal, which means they only need to be performed some of the time. The four main modes are Acquisition (Search), Idle, Traffic (Receive) and Traffic (Transmit).

Figure 1 -- Some of the operations on a wireless phone are modal

The Acquisition mode refers to locating the nearest base station. When in Idle mode, the wireless phone keeps track of the base station it's hooked up to and monitors the paging channel, looking for a signal that says "Wake up because a call is being initiated." The Traffic mode has two variations: Receiving and Transmitting (although you may think the widgets inside a phone are performing both tasks simultaneously, the reality is that, inside the digital chip, the processors are often sequencing back and forth between the transmit and receive functions).

In the case of a wireless phone based on conventional IC technologies, each of these baseband processing functions requires its own DSP or ASIC (or some area on a common ASIC). This means that even when a function isn't being used, it still occupies silicon real estate and consumes power. In turn, this affects decisions made by the design engineers. For example, when in Acquisition mode, you can increase the number of "Searcher" functions to speed things up, but each function requires ASIC material real estate. This causes engineers to limit the number of search functions they use -- hence the fact that it can take your cell phone a seemingly endless time to locate the nearest base station when you first power it on.

By comparison, a next-generation ACM-based wireless phone only requires a single ACM that can be adapted on-the-fly to perform each baseband function as required. For example, when in Acquisition mode, the ACM would be adapted to perform only acquisition; during Transmit mode the ACM would be adapted to the transmit functions ... and so forth. This means that at any point in time, only the function that is required would be resident in the ACM and consuming resources. More importantly, it also means that when the phone is in Acquisition mode, for example, all of the ACM's resources can be configured as searchers, which means that you can use many more searchers can you could afford to support in ASIC material, which means that the ACM can out-perform the ASIC for this type of real-world function.

DSP designers tap-dancing in the streets?
But what does all of this have to do with EDA? Well, although it has many potential implications, I think that in the immediate future QuickSilver's ACM technology is going to be of particular interest to DSP designers (and if you aren't careful I'll tell you why). Until very recently, the typical DSP design flow was as follows... First, use a tool/environment like SPW from Cadence or the MATLAB/Simulink products from MathWorks to represent the design as a hierarchical block diagram of the major functions. Each of the lower-level blocks contains an algorithmic representation of that function (these algorithmic representations may come from pre-defined libraries, as third-party IP, or be homegrown).

The DSP designers perform algorithmic design and analysis at this high level, then start partitioning the design and migrating it down into C code or assembly language. Designers of these embedded applications are therefore intimately familiar with a design process that features compilers, debuggers, emulators, and so forth.

But many modern wireless algorithms are bringing DSPs to their knees, which is forcing some high-end DSP designers to enter wildly unfamiliar territory ("Beware, here be dragons!"). I'm referring to the increasing trend for DSP designs to start at the traditional high level (SPW, MATLAB/Simulink) in order to perform the initial algorithmic design and analysis, but to then plunge down into an ASIC implementation flow to obtain the desired performance. This requires the DSP designer to migrate the design down into Verilog or VHDL (as opposed to C code or assembly language), and to then enter the morass we call EDA (synthesis, simulation, layout). You can only imagine their sad little faces when they experience this brave new world for the very first time.

One recent move to make this transition somewhat easier is demonstrated by the FPGA folks, who are providing tools like the Xilinx System Generator for DSPs from Xilink and DSP Builder from Altera. Both of these solutions feature a MATLAB/Simulink front-end that automatically generates traditional HDL. However, although its functions can be modified, reconfiguring an FPGA consumes excessive amounts of power (compared to an ACM) and cannot be performed quickly enough to satisfy the requirements of emerging 3G and future 4G wireless products.

More importantly, the ACM design flow is almost identical to the traditional DSP design flow, which makes the transition very comfortable for DSP designers. Once again, you commence by capturing and analyzing the design at the algorithmic level using a MATLAB/Simulink front end. At this stage you haven't made any implementation commitments, so you still have the choice of going the traditional C/assembly route, the Verilog/VHDL ASIC/FPGA route, or the ACM route. In the case of the ACM, the design is partitioned and translated into a C-type language, which is subsequently compiled into an application binary known as SilverWare.

The ACM includes a real-time multi-tasking kernel that handles the assignment of resources on-the-fly without the designer having to worry about anything except specifying the relative priorities of different portions of each algorithm. Thus, you might be using a lot of searcher functions on your wireless handset while in Acquisition mode, and then decide to play an MP3 file while you're waiting, in which case the kernel would re-allocate the ACM's resources accordingly (multiple Silverware applications and portions thereof can be executed concurrently).

Of course there's way more to all of this than I can talk about here, not the least of which is that ACMs will come equipped with a complete compiler, debugger, emulator, etc. environment that will be deep in the comfort zone of the traditional DSP designer. Also, the fact that the ACM environment will support the co-simulation of ACMs with ASICs and FPGAs using SystemC as the simulation environment, and ...unfortunately my time (and word count) has been exhausted for the nonce (you can always meander over to www.quicksilvertech.com for more details).

In the meantime, this is another innovative new development that receives an official "Cool Beans" from me. Until next time, have a good one!

Clive (Max) Maxfield is president of Techbites Interactive, a marketing consultancy firm specializing in high-tech. Author of Bebop to the Boolean Boogie (An Unconventional Guide to Electronics) and co-author of EDA: Where Electronics Begins, Max was once referred to as a "semiconductor design expert" by someone famous who wasn't prompted, coerced, or remunerated in any way.