Peter Jansen | PhD Candidate | Cognitive Science Laboratory
PIC Cluster

I have always been enchanted with computational problems that can be spread across more than one processor. The implementations, as the number of processors becomes large, generally have a beauty and elegance to them necessitated by the structure of the problem, structure of the computational topology, and the flow of information within that architecture defined by a given problem. The PIC Cluster is a fun project to introduce myself to "building my own supercomputer", starting with a simple network topology and array of capable, inexpensive, and easily prototypable microcontrollers.

The prototype PIC cluster board can be seen below. It features sockets for up to 10 dsPIC30F3012 microcontrollers designed for digital signal processing. Each of these dsPICs is capable of running at 30 MIPS, and features 24k of program space, 2k of RAM, a hardware multiplier, and a built-in IC communications interface. Each dsPIC has its own reset button, and the top dsPIC sockets include an LED connected to one of the dsPIC's I/O pins.

The board also features an Imsys SNAP Module, which is a very small linux system that also provides 10/100mbit ethernet, serial, IC, and SD/MMC card interfaces. Other features of the board include two selectable clock speeds, an ICD2 connector for programming, and a series of DIP switches to hold any combination of the dsPICs in reset (and to select a single dsPIC to program).

the prototype
PIC cluster board


Theory of Operation:

One of the central goals of this project was to create a fun, interesting, and tractable first project in do-it-yourself cluster construction. In this light the design of the network topology was chosen to be an extremely simple bus type, where interprocessor communications are handled by a single shared data line. While a bus topology is much simpler to implement than some other types (such as an n-dimensional hypercube), the trade off is in speed at any given time only two processors can communicate with each other. For certain types of problems that heavily rely on interprocessor communication (such as distributed implementations of neural networks), this would be a critical performance bottleneck. However, there exists a subset of parallel problems that have relatively low interprocessor communications for which this type of architecture is particularly suited. These problems generally take the form of a host sending data units to a given processor that can be computed without any additional information, and that processor works on the data unit until finished. Once finished, the results are returned to the host and another data unit is retrieved. Examples of this class of problems include computing large primes, or large grid-computing projects such as SETI@Home.

Similar to this grid computing model, the prototype board is envisioned to use the SNAP Module as a host to serve data packets over the to IC bus to the individual dsPICs. Each dsPIC would then communicate the result back to the SNAP, which then stores the data internally in flash memory or externally on the SD card. The SNAP also happens to include a web server, so the progress and results could easily be accessed remotely.


Progress:

The board is complete!
  • There are some issues with reading the SD card, which may be due to power fluctuations (SD cards are very sensitive to power issues). This isn't a big issue as the SNAP has 2MB of internal flash, and in the extreme case data could be stored externally over a network.
  • The software is in development currently at the blinky light stage.