ACM, as you may recall, is a new form of digital integrated circuit based on the concept of a coarse-grained heterogeneous node-based architecture. Each node performs tasks at the level of complete algorithmic elements. For example, a single arithmetic node can be used to implement different variable width linear arithmetic functions such as a FIR filter, a Discrete Cosign Transform (DCT), a Fast Fourier Transform (FFT), and so forth. Such a node can also be used to implement variable width non-linear arithmetic functions such as ((1/sine A) x (1/x)) to the 13th power.

Similarly, a bit-manipulation node can be used to implement different (variable-width) bit-manipulation functions, such as a Linear Feedback Shift Register (LRSR), Walsh code generator, Gold code generator, or TCP/IP packet discriminator.

Depending on the task for which is intended, an ACM may contain anything from a single cluster of nodes to hundreds of clusters. A key point is that any part of the device - from a few small portions all the way up to the full chip - can be adapted blazingly fast (in many cases within a single clock cycle). This allows for a radical change in the way in which algorithms are implemented. As opposed to passing data from function to function, the data can remain resident in a node while the function of the node changes on a clock-by-clock basis.

It also means that, unlike an ASIC implementation in which algorithms are effectively "frozen in silicon," the ACM's ability to be adapted tens or hundreds of thousands of times a second means that only those portions of an algorithm that are actually being executed need to be resident in the device at any one time. This provides for tremendous reductions in silicon area and power consumption.

Figure 1 -- The ACM node-based architecture

SilverC and Silverware
SilverC representations can be designed (captured) and simulated much faster than the equivalent HDL representations (Verilog and VHDL) used for ASIC designs. Once a SilverC representation has been simulated and verified, it is compiled into an executable (binary) "Silverware" application. The ACM's on-chip operating system (OS) only loads whatever portions of a Silverware application that are required at any particular time, and multiple Silverware applications can be running concurrently on an ACM at any particular time.

Figure 2 - ACM applications are captured in SilverC

Figure 3 - ACM's on-chip OS loads Silverwear applications as required

Dataflow representations
For the purpose of these discussions, we will consider the term "dataflow" to refer to a representation -- either graphical or textual -- in which a design is represented as "modules" linked by "pipes" (Figure 4).

Figure 4 - A dataflow representation

In this context, a module is an algorithmic block containing one or more processes that manipulate data, while a pipe is a pathway that conveys data from module to module. Each module can have multiple input and output pipes, and each pipe can be used to drive multiple modules if required. Furthermore, each module is mapped onto a certain type of ACM node (the actual physical node won't be selected until the on-chip OS loads that module at run time).

SilverC preserves traditional C syntax and control structures, which makes it easy for C programmers and DSP designers to use and simplifies legacy C code conversion. SilverC also includes special "module," "pipe," and "process" keywords/extensions that facilitate dataflow representations and support parallel programming. Furthermore, SilverC provides special extensions for DSP programming, such as circular pointers for efficient use of DAG resources, fixed-width integer and fixed-point data types, support for saturated and non-saturated types, and so forth.

But wait, there's more
There are a variety of graphical tools available to aid engineers in capturing their designs. One such tool is Simulink from The MathWorks. This tool, which has a wide base of users, encourages dataflow oriented design and provides an excellent mapping to the ACM architecture.

Well, the lads and lasses at QuickSilver have been working furiously on integrating SilverC with Simulink. At the simplest level, you can use Simulink to describe the various blocks and the dataflow connections between them, and then automatically output a top-level "framework" of the design containing the module instantiations and the pipes connecting them together. In this case you would then go in to the framework to code the processes by hand.

Alternatively, QuickSilver has developed a library of SilverC modules that map onto existing Simulink blocks. This library includes widely-used DSP components, filters, encoders, decoders, and bit and word manipulators. These SilverC modules can be used for functional and cycle-accurate simulation, and they map directly onto the ACM's dynamic hardware resources.

As usual, there's a lot more to all of this than I have time to go into here, but you can always learn more by visiting QuickSilver's website. Also, there's the picoChip company in England who are working on a somewhat related coarse-grained concept based on arrays of processors. Not many details on these devices or their design tools have leaked out yet, but picoChip have promised to give me as many nitty-gritty details as I can handle when they are finally ready to leap onto center stage, at which time I will make a full report to you. 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.