XMOS's New Batch: xCORE-200 !

Hi John,

This is how xCORE could be perceived (I don’t know if this is totally correct, but it is how I imagine it); this is a single “tile” in XMOS terminology, also known as a physical core by some people, also known as 8 cores or 8 logical cores by XMOS:

Basically, I see up to 8 register sets, and they are cycled through, one set at a time, at 500MHz. This would correspond to 8 threads of operation.

If the scheduler thinks that one of the threads is sleeping, then that register set is skipped usually with no penalty (but see later).

At each tick of the 500MHz clock, something can be pushed onto the CPU (4 or 5 stage pipeline depending on if it is original xCORE or xCORE-200 respectively – for the rest of this discussion I’ll assume a 5-stage pipeline), and they shuffle through on the 500MHz ticks until the instruction has been totally processed through the pipeline. So, as long as there are threads awake then they can always fill up the pipeline and keep the MIPS value up. If less than 5 threads are awake, then there are unfilled gaps in the pipeline. So, for any number of awake threads between 1 and 5, it can be guaranteed that they will get instructions processed every 5 ticks of the 500MHz clock.

If there are more than 5 threads, then they will processed more infrequently (just a typical round robin fashion, skipping any threads that are sleeping). A minimum guarantee can be provided of course – proportional to the number of threads. XMOS have a diagram (from this nice PDF) which shows task or thread instructions rippling through the pipeline against time (time on x-axis, pipeline can be imagined to be vertical, instructions rippling from top to bottom).

So, it can be seen that the dispatching function and pipeline is kept straightforward. However the scheduler is very advanced from what I can tell. It can be programmed to read external signals at defined times (e.g. at 10ns from now) – and it will wake a thread to process it. Similarly it is possible to store events like setting a pin high in 20ns from now. This is great for software defined low-layer protocols, where you might want to read or write a bit at an exact time. It means there is no need to have dedicated hardware for peripherals like UART for example. As many UARTs as desired can be instantiated in software.

The other thing (shown in blue X’s because I’m not entirely sure how they are implemented at a hardware level) is the xCONNECT functionality which is used for implementing inter-process communication (IPC). It works between threads, and also across tiles or off-chip too. The physical implementation is nicely hidden in the programming environment and instead you get access to POSIX-style high-level features like the select statement to sleep and wait for an event that could come across the xCONNECT or from a timed event that was scheduled as an example.

For the 16-core chips, there are two tiles, and xCONNECT is used to communicate between them. Similarly for the 32-core chips, there are 4 tiles.

The explanation above works for the original xCORE chips with 4-stage pipeline too. With the xCORE-200 however, there are some advanced modifications. For example, there are two pipelines per tile. It is possible to feed them both simultaneously in a single clock cycle.This therefore provides 1000 MIPS per tile with that 500MHz clock. It is also possible to process 64-bits of data simultaneously. The scheduling now includes prioritization. The instruction set has increased. So, there are significant differences and there is a need to rethink the conceptual diagram above to incorporate these new additions (If the diagram above is useful then I’ll try to work on it further to incorporate the new xCORE-200 features).

The programming language is C, but with some extensions, e.g. to make use of the timed I/O and the ability to use the channels for example. Whoever devised it clearly loved operating systems theory, because they did it using a similar philosophy. I think of it as a hardware-based OS, since the scheduling of threads is something that a (software) kernel would normally implement, and the IPC looks familiar but uses the underlying xCONNECT hardware transparently to the user. (For these reasons I think you would probably really enjoy using it ; ) We really should work on creating a small open source dev-board!).

Anyway, apologies for the long explanation, I know you’re already quite familiar with a lot of the stuff mentioned and only needed the specifics for XMOS, but others may not be, so hopefully the longer explanation helps others too. Writing it also helped me get it clear in my head too.

Add to that a message passing system between the cores asynchronous in nature.

As is usual with XMOS, it's difficult to understand what "16 cores" or "32 cores" really means.  As I understand it, the xCORE-200 has one or more physical cores (what you'd normally think of as a "processor") and time-multiplexes 8 logical cores on each one.  Each logical core runs an independent task and has independent processor registers.  This is rather nice, because the independent tasks don't have to deal with register interlocks like you do in a high-performance pipelined single processor which makes the implementation a lot simpler and more efficient.  So that 2000 MIPS from 16 cores is really two 1000 MIPS processors with enough registers to run 16 interleaved tasks.

All this interleaving must be handled by software and XMOS provides a suite of tools for that.  In addition, my understanding is that the architecture is open so people can write their own general-purpose tools or specialized tools for a limited problem domain.  This looks like a lot of fun and I'm hoping to check it out some day.

Please feel free to correct my misconceptions.

Hi John,

I hope they do come out with a low-cost board, otherwise it would be good to create an open source board design and gerber files so we can build our own using the TQFP package versions.

The xCORE-200 16-core variants (2000MIPS) are available in TQFP package with built-in Flash and SRAM, which is really great and should reduce the BoM greatly.

Let us know when they come out with a cheap development board.