Skip to content

dwelch67/xmos_samples

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

27 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

The folks at xmos.com have a very cool processor core that they are
selling in a number of combinations and packages.

I am guessing they are targeting the cpld and small fpga world as well
as the microcontroller world.

Unlike the traditional processor, one program counter, walk through
the code, interrupt and change the pc if you want to execute a different
thread of code, etc.  This core has 8 threads and it looks like each
core has its own set of registers (sharing the same program/memory
space).  Although you could argue it is like memory mapped I/O the
ports and timers are not accessed in the traditional way, unlike a
traditional processor where these peripherals are outside the core
of the processor living behind address decoders on the memory bus, the
peripherals here are built into the core.  They dont have peripheral
specific instructions, the instructions are generic in the sense that
the data value determines what you are asking it to do, similar to
loads and stores on a generic memory bus, but in this case not as
generic.

The cores and their peripherals are very tightly coupled.  The xcore
is clocked at 400 or 500 Mhz, but that doesnt mean all 8 cores/threads
are running at that rate.  It appears that only one thread gets to
execute per clock cycle, but if there is more than one core running
then they take turns, even with that I dont think a single core runs
at 500MHz, will have to investigate more, I think there is a max per
core/thread speed.  The peripherals are available to all of the threads
but it appears that onec a thread has claimed a peripheral then others
cant/shouldnt use it.  They should allocate their own.  I dont yet
know how many of each type of peripheral there are.  There are only
a couple of peripheral types though, ports and timers.  There are no
uarts, no spi controllers, etc.  You have to implement all of those
things in software.  Not to worry, this architecture is designed for
that.  It is as if they have built an rtos into hardware for you, you
really dont want to implement an OS on top of this architecture.  It is
built right into the design that for example you set a timer to time
out and instead of having to setup interrupt service routines and
parse out who created the interrupt, etc you simply execute a single
instruction that says "I want to sleep until the timer times out", and
then your program wakes up and runs along.  Same goes for I/O ports.  And
since this is a multicore processor there are core to core communication
paths built into the design so you can also go to sleep until some
other core pokes you with something.  And you can also fairly easily
set up event monitoring which has the flavor of an interrupt handler
except that you dont have a common entry point, it is kind of like the
new ARM cores with dozens to hundreds of individual interrupt vectors
in this case you simply setup a handler for every item you want to
wake you up and you wake up directly at the beginning of that handler.

So it is like a cpld or fpga in that respect that you have this generic
set of building blocks and even the simple things like a uart you have
to build you dont have any of those in hardware.  They provide a nice
simulator that outputs in two ways one is a textual listing of basically
every clock cycle of the xcore, what instruction, what registers and
their values which core ran that cycle, etc.  They also provide output
with waveforms, vcd format, that you can use gtkwave or your favorite
waveform viewer.  Very much like developing with vhdl or verilog for
a cpld or fpga.  You can carefully tune the timing of the I/O.

So they have this xcore I think they call it, what I am calling an xcore
is this logic blob with 8 internal cores tightly coupled with timer and
gpio port peripherals.  I dont know exactly what the edge looks like
(does it have a memory bus?), but the generic xcore does have a fixed
number of I/O ports which when they package this into silicon they can
do some fun things like for example put more than one xcore on one chip
with those cores tied together using external communication paths that
work the same or similar to the internal core to core communications.
if you look at some of their early demos, they can go so far as to take
multiple chips and connect external communication paths so that you can
gang up mutiple xcores by using multiple chips.  All by design.  So you
have this somewhat polished xcore, that they wrap with some real-ish
peripherals like a usb controller or an ADC and I dont yet know what
else (DAC?).  One of the early ones I tried the I/O ports were overlapped
on pins such that you could access say 4 I/O pins as either a single
4 bit port, or as 4 individual ports, and that external to the xcore
(but within the chip) the overlap was managed with some priority such
that say the single line port access had priority over the 4 like port.

So far their development tools are good, including a flash programmer
that so far "just works".  Usually with other microcontroller vendors
their flash programmer is troublesome at best, they rely on third party
tools, etc.  Even when these other vendors make their own boards I
often struggle to find a good set of tools.  XMOS so far has delivered,
will see if that changes.

Because this isnt a single threaded processor, and because it is
apparently designed to be event driven they have made their own extensions
to the C programming language.  I call it XC, I dont know if that is
what they call it.  Their compiler is a modified gnu gcc compiler called
xcc.  They have added constructs to allow you to define parallel tasks
for example, basically you are dictating that you want these things to
run on their own cores independently.  They also added operands and
data types to tie directly to their timers and ports and communication
channels so that in C (XC) you can have a line of code that basically
dictates the instruction that causes that core to hang/wait until an
event.

Their tool suite is a free download, well it may cost you an email
addressi/registration.  You get the tools and the simulator, so you can
start playing with this thing now, you dont have to buy anything to
see if you love it or hate it.  I am attempting to put together a
suite of example programs that are targetted at the simulator and then
similar examples targetted at a board or boards you might be interested
in buying.  I like the concept in general and am definitely a fan,
I am also trying to learn the xcore at the instruction set level, which
means the internals since a lot of it has to do with what values to feed
what instructions to get things to happen.  The xcc compiler does all
of this for you and actually I have learned most things from disassembling
the xcc compiled code then looking up the instructions in their manuals.
There are some gurus hanging out at xcore.com as well that have been
quite helpful.  So I plan to have both assembly (xas) and xc language
(xcc) examples for each of the targets.  As usual, dont expect me to
use their IDE/GUI, I will stick with the command line tools.

I consider this instruction set to be advanced, even this XC programming
language, if you have an interest in this assembly language you should
try some other processor first (try my lsasim or thumbulator repo), or
if you want to learn C there are very many resources for that, one
you might try is https://c.learncodethehardway.org/.

I do not work for xmos in any way shape or form, I just happen to like
this core and want to see them succeed.  Perhaps if lucky I can convice
the folks I do work for to try one of these in one of our designs and/or
build something of my own on the side that uses an xmos device.  For
now I am quite pleased just using the simulator and the eval boards
that I have purchased.

I am very happy to see that they now offer a $15 board that you can,
in theory, mate up with a Raspberry Pi, but you dont have to, it works
just fine as is.  I think this is a big step in the right direction
for XMOS (a sub $100 eval platform, even better sub $20).  I hope it
will help draw more hobbyists the folks that just want to make a cool
robot or something and buy arduinos now can mate a Raspberry Pi plus
an XMOS startKIT and have something for about the same price that is
literally an order of magnitude more horsepower.  It also makes the
Raspberry Pi significantly more usable for such projects.  If nothing
else I can hopefully provide simple, working, examples that along with
XMOS code, hold someones hand down the road to making a library set
for folks wanting to just make robots and stuff (vs my desire to just
learn how the chips work).

This repo is under construction, but you may want to start in the
simulator directory even if you have hardware, and then try the other
directories.

Note, this error is expected when using the Makefiles to generate waveforms

xsim: error: C51188: maximum cycles reached (4000)
make: *** [thread_hand2.vcd] Error 1

xsim --max-cycles 4000 -t myprog.xe

About

Some of my xmos sample programs

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published