Move over SoCs, ASICs, ASSPs and FPGAs, there is a new acronym on the block: SDS. If the inventors deliver on the claims, then Software Designed Silicon will give consumer electronics designers the power and cost advantages of an SoC, the flexibility of an FPGA, and ease of design like nothing else. And if you have read the discussion of parallel processing by Iann Barron (READ IT HERE ), much of the approach will ring bells.
University Gate is a modern office block in the centre of the West of England city of Bristol, which bridges academe and the commercial world. On one side it faces a slightly grubby and bustling street, and on the other it links directly with the Computer Science Department building of Bristol University. Many of the companies that operate in University Gate are start-ups, and XMOS, the company behind Software Defined Silicon (SDS), is the epitome of university research passing into the commercial world, with David May, Professor of Computer Science, as the company’s CTO.
The basic idea of SDS is simple: define everything that you can for your system in software, including much that is traditionally implemented in hardware, and then run the result on an array of processors. Each task is a thread, and each processor executes a single thread, with no interrupts.
Much of the current debate about the difficulties of parallel processing arises because the multi-core hardware was designed by combining multiple instances of an existing processor architecture (for compatibility with legacy software) and only later trying to work out how to get the software to run on it. If, instead, you develop the processor, its compiler and the development environment together, all using the same model of parallelism, then the problems of programming a massively parallel array become a lot less. And while much software running on PCs is not inherently susceptible to parallelisation, much of what happens inside a piece of consumer electronics is inherently parallel.
That is why XMOS is targeting, not the traditional processor niche, but consumer electronics. The management team argues that the consumer electronics developer needs to create a product that is different from others in the same market sector. Getting that differentiation can be through several routes. The first is to use an SoC/ASIC, which is expensive, complex and time-consuming to develop, although volume costs mean individual devices are relatively cheap. The second route is to buy an ASSP, which will also, by definition, be in use by competitors, and add differentiation through software. Device costs are less but the software development can be difficult and expensive. A third route is to use an FPGA. Development and differentiation are all easier, but the unit cost can often rule this out for price-sensitive applications.
What XMOS is offering is a different route, which they claim will have a unit cost of around a dollar, be fast and efficient in design, and be flexible enough to meet any design requirement.
The silicon starting point is a small, event-driven, processor engine, the XCore. In use, May compares it to an athlete on the starting blocks: the starting gun goes off when an event occurs on a pin, and the XCore is instantly up and running. XCores communicate through XLinks, and, by integrating pin control within the XCore, the whole system, including interfaces, can be implemented in software. System resources for control processing, signal processing and I/O control can all be dynamically allocated, matching the processor to the task. In broad terms, a processor provides communications processing running at 200Mbps (Ethernet MAC and MII interface to Phy in software), signal processing running at approximately 7 MSPS (16-tap FIR), and control software running at 500 MIPS. Each XMOS SDS device will have multiple processors.
Ok, we now have a lot of computing power; how do we use it? The starting point is a simple integrated hardware/software development flow. Systems are built in C/C++ and XMOX C (XC), an extension to standard C that provides access to multithreading and I/O port control, making parallelism explicit. By choosing C, XMOS hopes to tap in to the huge base of experienced C users, and it also allows the use of legacy code for software stacks, etc. The development flow provides compilers for C/C++ or XC, a linker/assembler, and a soft IP library. It uses the GDB debugger with an Eclipse ICE, and a development board will be available.
The XCore and its related compiler are the fruits of academic research, guided by May, and around this has been assembled a strong team, with senior management bringing experience from semiconductor leaders such as ARM, Oxford Semiconductor, Lucent and Connexant. And, May points out, “A great bunch of young engineers.”
Although the prototype device is still in TSMC’s 90nm fab, XMOS has already been working with potential users — what CEO James Foster calls ‘teaching customers.’ They have implemented existing designs from ASICs and FPGAs on a simulated target device and given the approach a thorough workout.
The timetable is that in Q4 of this year the details of the architecture will be revealed, and beta versions of the tools will be available. The full launch will be in Q1 2008, with the first device family, the development tools and a library of soft IP all available.
Why is this important? It is clear that while Moore’s Law is making gates freely available, the tools for taking advantage of them are not keeping pace. May has previously said that software efficiency halves every eighteen months, (May’s Law) thus compensating for Moore’s law. And this fall in efficiency is also evident in the tools for designing silicon.
So, to take advantage of all these gates, we need a different approach. Parallelism holds out the possibility of being this, but the multicore approaches so far announced do not yet have the software tools in place that allow developers to take advantage of parallelism. Also, most multicore announcements are of replacement processors for computing applications, rather than controllers for embedded systems.
The SDS approach potentially allows developers of consumer electronics products to take advantage of parallelism with a relatively simple user interface, fast design cycle, and cheap silicon.
