Xmos in real-time protocol push with IP and hardware

By Chris Edwards |  No Comments  |  Posted: November 6, 2012
Topics/Categories: Blog - Embedded  |  Tags: , , , ,  | Organizations:

A subtle rebranding is underway at Xmos, one in which the architecture developed by Professor David May at the University of Bristol is going back to its roots as a microprocessor architecture designed specifically for real-time applications.

When Xmos first launched, its management pitched the Xcore as a direct replacement for hardware, something that could be used in place of an FPGA but which you programmed in regular C. But at its heart was a collection of microprocessor pipelines. The reason for the FPGA comparison was that the Xcore could be used as a compact state machine that could respond to I/O changes much more quickly than a regular microprocessor. But having shipped three different models since the company’s launch, the comparison now is with more traditional microcontrollers, albeit to continue the microprocessor’s 40-year encroachment on hardware territory – a trend that harks back to the Busicom calculator project that started it all.

The baseline part, said CEO Nigel Toon who joined the company earlier this year from Picochip following its acquisition by Mindspeed, is effectively “an eight-pack of microcontrollers”.

“Recently there has been a big expansion into industrial applications because of the real-time nature of the architecture,” said Toon. “We can build interfaces that you would not find in other microcontrollers, and support the growing requirement around functional safety.”

One of the things that Xmos has promoted is the idea of soft peripherals – down to the logical link level at least. This has been formalized now as a library of off-the-shelf modules that implement a variety of I/O and communications protocols. “You can take a USB interface and put that down into a design and make it part of the system,” said Toon.

Software vs hardware

These days you would be hard pressed to find a 32bit microcontroller family that didn’t have a USB interface somewhere. The advantage of having the software version is that it provides a way to pull more exotic interfaces into a real-time control application. So the portfolio of readymades includes protocols such as time-stamped Ethernet and Ethercat.

“With IP blocks we can react to the market much more quickly,” said Toon.

The other reason why the management at Xmos think it can break in the microcontroller market is that the multiprocessor nature of the core – implemented using a mixture of separate cores and simultaneous multithreading – makes it possible to host notionally independent functions on the same silicon without interfering with each other, such as motor control with communications.

Other companies such as Freescale Semiconductor have used multiple cores to deal with the same issue, primarily with digital signal controllers that mix a DSP for motor control with a general-purpose processor to handle internet traffic. The Xmos approach provides, in principle a larger mix of real-time protocols or more motor channels.

“So you can do a robot with a wireless interface,” claimed Toon. “We think there is a spot for our product, as a more responsive multicore microcontroller with the flexibility that you would otherwise find in an FPGA.”

Event-driven architecture

The main difference between a conventional processor and the Xmos architecture lies in the event-driven approach that May developed at the University of Bristol. Software written for almost all existing processors assume that there is at least one process with an active thread in the system that runs continually, often in an idle loop, spawning tasks that react to external events generally in response to interrupts. The interrupts themselves are asynchronous, but generally only trigger a rescheduling event in the core real-time operating system (RTOS) that causes the task charged with handling the event to move up the queue of processes waiting to be scheduled.

In the event-driven approach, a thread does not start to run until a change in conditions triggers it. From that point, the thread runs to completion. This has been done in software. The assumption that threads always run to completion once an event triggers their execution was part of an architecture developed by LiveDevices, now part of Etas, for its Pine real-time operating system and incorporated into the Osek kernel for automotive systems.

The single-shot approach to thread programming in the case of Pine allowed the use of a smaller software stack. For Xmos, the result is less wasted hardware activity and improved responsiveness for as many tasks as there are hardware threads. It is possible to get an RTOS to run on an Xmos thread to provide support for software multitasking, with the same caveats as

External logic changes on pins or values being written across a parallel port generally provide the stimulus needed to trigger thread execution. Threads can communicate with each other using a network of links that join the on-chip processors and extend off-chip to other Xmos devices.

Tools and kits

To make the architecture more accessible, Xmos has focused recently on building a new set of development tools, built around the Eclipse framework, and a set of off-the-shelf prototyping boards.

Co-founder and outbound-marketing manager at XMOS Ali Dixon said the Slicekits represent a “modular development kit. You plug different Slice cards into the core board. Customers can mix and match them.It’s very easy to create new Slice cards. Our partners are already designing some of their own. For a number of them it’s a way of monetizing their own developement effort”.

The SliceKit approach resembles that of Arduino Shields. Toon said the company is looking at the feasibility of supporting Arduino as well to capitalise on the growing base not just among hobbyists but industrial users. Some designers have already designed an Arduino core board, called the Xarduino for which the specifications are available online.

Toon said: “The idea of building an interposer into which you can plug Arduino Shields is quite possible.”

Toon said the company sees the off-the-shelf hardware as being an important part of growing a user base, using an approach that is not conventional for startups, where the usual tactic is to try to get designed into a few select high-volume projects before trying to expand the customer base.

“Previously Xmos was focused on a narrow set of markets. The number of applications that people are looking at is expanding,” said Toon. The hardware is important, he added, because “I think people want to have proof points. There are fewer and fewer people doing hardware designs and this provides a way of getting beyond the proof of concept stage”.

The support for low-volume projects and prototypes helps build up a user base similar to that created by Microchip for the PIC16 and Atmel for the AVR in previous years. “There is a growing community around Xmos,” Toon claimed.

Comments are closed.


Synopsys Cadence Design Systems Siemens EDA
View All Sponsors