Linked by Thom Holwerda on Fri 21st Aug 2009 22:34 UTC
Hardware, Embedded Systems I've often wondered why computers - be it laptops or desktop - are so relatively monolithic. Wouldn't it make much more sense to have a whole cluster of very tiny individual computers, all with their own tiny processor, RAM, data storage, and serial ports, which power up when needed and are easily replaced when broken? Well, Liquidware thought so too, and came up with the Illuminato X Machina.
Permalink for comment 380106
To read all comments associated with this story, please click here.
nice
by transputer_guy on Sat 22nd Aug 2009 20:56 UTC
transputer_guy
Member since:
2005-07-08

Well I ought to say something since it is pretty familiar territory given my nic!


This project is clearly very similar to an array of TRAMs each populated with 1 T800 Transputer and some memory and I/O. The Transputer though made this easy, all the I/O channel interconnect was built in as was the DRAM controller. Here it has had to be reinvented. If the 1990 T9000 had worked properly, it should have performed at a similar level to this 70MHz ARM. Given another 20 years of development, a modern 2009 Transputer core at probably a GHz or more and we would have had some pretty interesting concurrent systems by now, but that was not to be.

The 4 edge connectors and the mechanical stability of a large plane of modules is going to be fragile, but for a half dozen modules should be okay for educational uses.

The choice of the ARM is interesting, it was designed about the same time as the Transputer but it went the embedded route where only 1 processor was usually needed. If the 70MHz ARM was replaced by a much faster clocked processor (ARM, Atom, MIPs etc), the PCB engineering with signals of several hundred MHz would be much harder. I didn't see any mention of DRAM on board?

Every module should include an FPGA for all it's interconnect duties, which can be programmed on the fly to handle most common I/O tasks. FPGAs esp the more expensive ones have very high performance Serdes links on them that are near SATA speeds, at least a few GBps per chip, but the engineering can be interesting. They also include enough LUT fabric to build a pretty decent processor along with custom hardware to suit. This suggests putting some of the end user application into 'soft' hardware instead of software if one can master that skill.

On a performance comparison with the Core Duo, it is pretty obvious a 70MHz ARM is a lame duck, not even dozens will compare and a large array will be mechanically unstable. However the ARM once powered real workstations, so that says something. A few ARMs should be enough to power a nice light BeOS like OS, no real need for glassy windows and other optical bling. One module could handle most everything except graphics, the rest could divide up the screen area although integrating the tiles to the video path would be interesting. Perhaps a GPU should sit on one of the modules.


OCCAM research still continues out of U.Kent and other places and the successors runs on modern processors, so it should be available for this board. OCCAM is not unlike a hardware description language where communicating processes model hardware blocks.


I stopped working on my Transputer design largely due to lack of interest in this sort of platform, perhaps I was wrong. In order to get some real performance it was necessary to go for a highly threaded/interleaved processor and memory design giving something like 40x 25mips per core with no effective memory latency for any of the 40 threads. A low end FPGA would have sufficed for the processor core but the memory interface requires 300-500MHz signals and therefore the faster FPGAs, something that was beyond my lab resources. Still the Transputer was all about fine grain concurrency, 1000 ops and switch to next task so a modern version would be even more threaded to hide memory latencies. The delivery would have been quite similar to this ARM board, more like a credit card sized TRAM holding 1 FPGA (transputer inside), a bank of RLDRAM chips and space for some other parts. One module would use spare FPGA resources to hold VGA/DVI interface, but graphics software would be distributed amongst the modules.

Still, I am happy to see anyone doing something similar with hardware again!