Mannerisms

That involved XMOS having to come up with something which was both low-cost and easy to programme.

Why is there a need for SDS?

Because consumer electronics companies have lost the means by which they can innovate. That's because the traditional ways of implementing chip-based features, ASIC and ASSP, have become too expensive, too rigid, too standardised, or too difficult.

"The consumer electronics indfustry is asking: 'How do I get some flexibility back into my system to allow me to differentiate my products and allow me to innovate in the field and in the products I'm bringing to the market How do we add features that are not on the reference design?'" says Noel Hurley, vice president of marketing at XMOS.

Of course, ASIC, ASSP are the usual ways of delivering features, but the cost of ASIC and ASSP has gone up to huge levels - $20m, $30m even $50m. This means designers have to target a design at a wide market. That means standardisation, and standardisation kills innovation.

The other traditional way to add features is FPGA. "FPGA vendors have been trying to get into consumer electronics", says Hurley, "but they have a high unit cost, and haven't been able to offer the right functionality at the right price points to get into high volume consumer."

So, while FPGAs get into consumer electronics at the prototyping stage, when it gets to high volume manufacturing they haven't got the right economic structure.

"That's where we're looking at our technology to fill that gap", says Hurley, "to allow consumer electronics companies a level of configurability, programmability and flexibility in their systems which they can afford without blowing their cost budgets."

XMOS has decided that they have to deliver their chips at price points between $1 to $10 if they want to win designs which will then allow a customer to take their product designs all the way to manufacture without having to do re-spins.

So that's where XMOS sees the need for this new class of products which it calls software defined silicon (SDS). SDS devices define the functionality and capability of silicon entirely in software.

"Consumer electronics customers want to look at tasks and functions, like Ethernet and UARTs, and they have built up teams of software engineers who understand C", says Hurley, "very few understand RTL. They're not semiconductor guys. They're engineering teams set up to write software in C."

"It makes more sense in today's world to target the technology using embedded software than it does to use RTL", continues Hurley, "so, to define SDS: We're using processors to implement what were traditionally hardware tasks, as well as software tasks, on a processor using an embedded software development flow. Today's processors haven't been targeted at that problem and so, as a result, they're not very good at it."

What does an SDS look like?

"People haven't looked at implementing communications interfaces in software, running in real-time, and that's the technology we've developed. So our technology is an events-driven processor engine", says Hurley.

An events-driven processor is one that is capable, when an event occurs, of executing software immediately, and then terminating, and waiting for the next event. The events are things like a pin changing state.

"So we've taken a very responsive, fast, deterministic, real-time processor engine, and we've integrated into that very tight pin control", says Hurley, "and we've developed a core-to-core communications interface. So now we can build arrays of cores that can control pins."

"Whereas, in a traditional ASSP, you might have a processor hanging off a bus, and there's blocks of hardware that talk to the outside world, in our world all of that is software, software implementing what is run on the processor in terms of software stacks, and also software doing the UART, the Ethernet, the MII interface, the USB interface - that's all software", says Hurley.

Once it becomes all software, the development environment becomes a single, unified development environment. All the hardware is software, and you're using a single language, in a single development environment, to create your system.

So, the XMOS processor is a multi-threaded processor engine, which can handle eight threads, with the I/O control capability tightly integrated into the core.

From the silicon cost point of view, XMOS is using processors, which are silicon efficient, and RAM, which is the most silicon efficient structure. By using processors and RAM, it gains big cost advantages.

"That only works if you have a processor which can respond to real-time events on the pins", says Hurley.

SDS can run Ethernet MAC and the MII interface in software at 200Mbps, it has DSP capability and control capability

"The development freedom the customer has is incredible because the customer can choose how to partition that capability", says Hurley, "fwhat's really powerful is that a customer has a budget of processor cycles, he can choose how to spend that budget on real-time tasks such as interfaces, DSP, and control, and, more importantly, he is then able to dynamically alter that so, when they're doing multiple products (typically consumer companies have a general platform supporting 20 or 30 products) he can choose to say: 'I don't want a UART in this design, but I do want to run an MP3 decoder. So I will remove the UART piece of code, and I will re-purpose those processing cycles into my DSP capability. I don't believe anything in the market today can offer that level of capability to a customer."

What are the tools for SDS?

It's a standard embedded software development flow starting with C/C++ source, compile, link, assemble and de-bug using standard industry development tools.

XMOS has added extensions to C. "C doesn't understand our port structure, it doesn't understand about multi-threading and parallelism" says Hurley, "so we developed a language called XC which is 99 per cent C, with a few extensions to allow a programmer control over the threading behaviour and the I/O port control. From XC it goes through the compiler, there's no hand-coding, this is a high-level language very much like C."

XMOS claims that it takes engineers who know C 'a day or two' to get up to speed on XC.

"It's a simplistic approach to programming", says Hurley, "there's a lot of talk in the industry about the complexity of multi-processing and multi-threading, but what we're trying to do is implement what were traditionally hardware blocks . And hardware is naturally parallel. They are distinct blocks with communications channels between them"

Each thread has a guaranteed minimum performance. No dynamic load balancing is required, and IP integration is possible without interoperability problems.