feature article
Subscribe Now

Software Defined Silicon

The Route to Consumer Electronics?

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.

Leave a Reply

featured blogs
Sep 26, 2022
Most engineers are of the view that all mesh generators use an underlying geometry that is discrete in nature, but in fact, Fidelity Pointwise can import and mesh both analytic and discrete geometry. Analytic geometry defines curves and surfaces with mathematical functions. T...
Sep 22, 2022
On Monday 26 September 2022, Earth and Jupiter will be only 365 million miles apart, which is around half of their worst-case separation....
Sep 22, 2022
Learn how to design safe and stylish interior and exterior automotive lighting systems with a look at important lighting categories and lighting design tools. The post How to Design Safe, Appealing, Functional Automotive Lighting Systems appeared first on From Silicon To Sof...

featured video

Embracing Photonics and Fiber Optics in Aerospace and Defense Applications

Sponsored by Synopsys

We sat down with Jigesh Patel, Technical Marketing Manager of Photonic Solutions at Synopsys, to learn the challenges and benefits of using photonics in Aerospace and Defense systems.

Read the Interview online

featured paper

Algorithm Verification with FPGAs and ASICs

Sponsored by MathWorks

Developing new FPGA and ASIC designs involves implementing new algorithms, which presents challenges for verification for algorithm developers, hardware designers, and verification engineers. This eBook explores different aspects of hardware design verification and how you can use MATLAB and Simulink to reduce development effort and improve the quality of end products.

Click here to read more

featured chalk talk

Battery Management System Overview

Sponsored by Infineon

Effective battery management for electric vehicles is a critical design element faced by engineers today. In this episode of Chalk Talk, Amelia Dalton chats with Marco Castellanos from Infineon about the key functions of battery management for electric vehicles, the role that cell balancing, voltage measurement and temperature measurement play in battery management ICs, and how wireless battery management using bluetooth low energy can help you tackle a variety of battery management challenges for your next design.

Click here for more information about Infineon Battery Management ICs