A lot of the work we do at XMOS is about “real-time programming” and it is worth stepping back to think about what this actually means. Generally, real-time programming is programming a system where some of the actions of the system must meet specific deadlines. These deadlines may be internal or external to the system. Often, such systems are split into “soft” or “hard” real-time. Hard real-time systems will have a catastrophic failure if a deadline is missed, whereas soft real-time systems have quality degradation if a deadline is missed, but the systems can at least carry on working.
The critical property when dealing with real-time systems is response time. The response time of a system is simply how long it takes to respond to an external stimulus. It is something we think about a lot at XMOS.
There is a popular children’s game that typifies response time. It is sometimes known as “red hands” or “slaps”, but goes by other names in different parts of the world. It involves two people placing their hands in front of them, palms together as if in prayer. The players point their hands forwards and touch the tips of the fingers with each other.
The game has a “slapper” and an “avoider”. The aim for the slapper is to break contact and slap the avoider’s hands as hard as possible. The avoider needs to move their hands out of the way before they are slapped - if they do this successfully then the avoider becomes the slapper and get their chance at revenge.
This game is a great example of a real-time system and a need for a good response time. The slapper provides the external stimulus, and the avoider is the real-time system that must respond. Similarly, in electronic hard real-time systems, sometimes you need to be able to respond quickly or really feel that pain.
As mentioned before, response time is something we think about a lot at XMOS and is something that we want to measure and keep track of. The question arises then of how we accurately test this property? How do we know which systems and architectures help us avoid the pain?
To gauge this property, we run specialist response time benchmarks. They work by having a test device providing a number of input signals to the device under test. The device under test is programmed to respond with an output signal change as fast as possible. The best system for doing this is pure hardware, either an ASIC or FPGA, but we are interested in software systems.
The graph in Figure 1 shows the worst case response times for these systems for different numbers of input signals. Figure 2 shows details of the different architectures we tested. As you can see, response times vary from a couple of hundred nanoseconds to about ten microseconds. The XMOS system is consistently faster than the other systems and also scales better as the number of inputs increase.
Figure 1: Worst case response times.
Why do XMOS devices respond so much faster than other microprocessors? The simple answer is that our chips are designed with this property specifically in mind and the whole architecture is geared towards it. What can a good response time be used for? Well, anything where taking too long to respond would either cause the system to miss some information or cause the external world to give up on the systems response. This can happen in many areas including motor control, human-computer interaction, and networking. At XMOS, we use the good response time of our chips to implement high-speed digital communication protocols. These often have very tight response time specifications that need to be adhered to or the protocol breaks down and information is missed - a hard real-time system with some serious “pain” associated with it. The deadlines on these protocols are often so tight that traditionally they are not implemented in software at all. A good response time means that we can implement in software, applications that previously were hardware only.
A full report on the benchmarking method described here along with the results can be found in the white paper “Benchmark Methods to Analyze Embedded Processors and Systems” which you can get from the XMOS website.
Architecture
System Details
ARM
BlueBoard LPC1768-H, LPC1768FBD100
ARM Cortex-M3
Keil uVision 4.21, FreeRTOS 7.0.1
PIC
dsPICDEM Starter Board V2, dsPIC33FJ256
MPLAB v8.80, FreeRTOS 7.0.1
XMOS
XMOS XC-1A, XS1-G4
XMOS Development Tools 11.2.2
Figure 2: Systems tested.
