So this second post would be a good place to explain where we are coming from with regard to moving OpenSource Hardware (OSH) forward, also see Open Hardware Production for a historical background/context. Obviously many folks working on many projects are all contributing to moving OSH forward, but my primary concern here is what started out as the Amino project but has expanded beyond this into more complex open hardware projects with significant performance requirements. The Arduino is a great example of successful OSH and it has opened up 8bit embedded development to the opensource world. Arduino represents an approachable platform for anyone with only modest programming knowledge to get a taste of what OSH can achieve. Amino began to see if that approach could take things to a much higher level, to bring much more within OSH reach, challenges not practical on 8Bit Microcontrollers.
Initially I and others envisaged the combination of microcontrollers (32 bit) being combined with FPGAs to provide a more powerful OSH development platform that could tackle Digital Signal Processing (DSP) applications like audio,video,voice,gesture,AI as well as opensource robotics and vision projects. In this model the stuff that has to be processed quickly is handled outside of the micro by the FPGA, opensource modules would be effectively loaded in suitable for the task : MACs,FFTs whatever. The trouble is FPGAs tend to be built around proprietary IP and tools, even though there are Open Cores and GCC based tools getting this stuff to play nicely together is very difficult. Add to this the complexities of HDLs, VHDL/Verilog,C/C++ models and simulators and pretty soon you need to be an expert to do anything useful. Even if one could modularize the FPGA parts integrating back into the development stream with the microcontroller codes add yet another moving target. I am not saying it is impossible to achieve the FPGA/Microcontroller marriage but doing so in an OpenSource manner is virtually impossible. One could also integrate the controller into the FPGA itself but often this modus operandi is again limited to IP rights and licensing issues.
That is when I figured that rather than using traditional Logic blocks within an FPGA, instead use super fast mutithreaded simple 32bit cores (or multicores) able to achieve results beyond microcontrollers and well into the FPGA applications bandwidth ranges. The theory goes like this ; rather than building VHDL rearrange the problem into a programming problem using more familiar programming languages like C/C++ with added concurrency constructs. In fact there are examples of this already within the FPGA world which are then translated back into logic blocks or HDLs. In this case however no translation is required, we assume that the ‘software chip’ has enough threads/cores in order to execute the concurrent code within the bandwidth envelope. It also makes simulation easier as one isn’t needing to convert into exotic HDLs and deal with widely varying latency/timing issues. One of the other advantages of this route would be the learning curve and the ease of use and entry for programmers as opposed to traditional electronic engineers. Another major advantage is that it could use proven opensource toolchain like GDB/GCC/Eclipse to provide a good overall OSH environment. What is more this model builds on the success of the Arduino where the software is the hardware approach that has proven so popular.
So is it possible to achieve this feat, is there such thing as a ‘soft chip’ that is capable of tackling at least modest DSP/FPGA applications? and can one build an opensource toolchain around it? What about the power requirements if its tens of watts then its not practical? Well the parallax propeller is an interesting candidate but fails on delivering an opensource toolchain. Its programming leaves a little to be desired along with its performance due to going the interpreted route, although incredible results are possible using its assembly language, its a good start but we can do better. We are in luck however as the XMOS XCore range of processors and development kits offer what I have enumerated and much more. It may also be useful to check out the heritage of XMOS and its founders, you will discover things like the Transputer and Occam, ideas before their time but perfect for our emergent issues and challenges. So this is no fly by night idea, many of the XMOS technologies and ideas have solid research and experimental application footing spanning a couple of decades.
More importantly XMOS have taken their lessons from INMOS and it’s Transputer/OCCAM and added much more to focus the technology for the current era. In case you haven’t heard, concurrency is the next programming language killer app, I’ve personally spent the last couple of years coming to terms with it using languages like Erlang. It is amazing how much easier concurrency is if a language has concurrency at it’s foundations and within it’s primitives. Languages like C/C++ make the transition exceptionally difficult and fraught with hidden dangers, liable to trip up even the most experienced developers and engineers. XMOS have tackled this by creating a language called XC (PDF), which looks a lot like C and will help in the initial learning curve for existing mirocontroller programmers (XCore also supports C/C++). XC however also has roots in Communicating Sequential Processes CSP and includes primitives that not only provide concurrency but also simplify event driven programming for hardware. Rather than having to come to terms with complexities of Interrupt Service Routines (ISRs) and the multiplexing of them using a Realtime operating system (RTOS) one can use an XC based event driven approach to solve concurrent hardware processing simply and logically. I would say it is almost natural in the way one uses events instead of the engineering abstract Interrupts found on traditional microcontrollers. As for the performance of the XCores themselves even the basic single core L1 chip (<$5 in quantities) zips a long delivering 400 MIPS across up to 8 concurrent threads, with further models such as the G4 (<$14 in quantities) containing 4 cores each with 8 threads per core or 1600MIPs in a 11×11 mill package that doesn’t need a heat sink!! And if thats not powerful enough for you you can build hypercubes of G4’s to rack up the proceessing power you require e.g the 25GIPS XMP-64!
As a bonus for hardware hackers, the XSI chips come with lots (I mean lashings) of I/O ports just like an FPGA only better!
But one of the key features about XCore (and XMOS) is their opensource friendly approach. I don’t mean just paying lip service, they actually developed XC around the opensource LLVM project which I have talked about before and where incidentally I first found out about XC. Not only that but XMOS are committed to a complete opensource toolchain including eclipse which makes it fit into OSH snuggly. Further more, initial conversations with folks at XMOS and within their communities, have shown that they are excited by the possibilities that OSH and XCore together can achieve in 2010 and beyond, I will have more on specifics later in separate posts.
A company with this pedigree, and such timely technology including good opensource tools and a community approach is just to good a chance to miss IMHO, we should take advantage of it and take the technology places others have only dreamed of until now.
In the next post (part 3) I will touch on Amino and how XCore can help deliver some of its goals, and perhaps paint a picture of how far we can take the idea..