OSH a way forward Pt.3 – XCore & Amino Fusion

So in part 2 ‘OpenSoftChip’ OpenSource Hardware (OSH) a way forward I provided some details on XCore from XMOS and expanded on why the approach beats Microcontroller (MCU) + FPGA for DSP like applications. In part 3 here I would like to cover XCore as a primary candidate for the Amino project, so lets remind ourselves of that projects initial aims:

  1. Modularisation – A modular topology enables common components to be snapped together using composition, allowing focus on just the custom features of a given project or task, it also reduces complexity and leads to faster project turnaround.

  2. Standardisation – In order to have modulisation and composition as well as reuse, standardisation is required via opensoource implementations made available for testing, production, modification and experimentation.

  3. Digitisation – Opensource software is perfectly digital it’s reproduction is as simple as copying bits, hardware isn’t so simple, but the more of it that can be digitally expressed and rendered the easier its reproduction and the more accessible it becomes to a larger audience.

  4. Reuse – Being able to reuse as much hardware and software as possible reduces consumption and is more environmentally friendly. Common modules or components can be assembled at reduced cost minimising overlap, they can be reused time and time again for experimentation and prototyping. Hacking culture often seeks to reuse, mashup and redefine items for use elsewhere, design should embrace this modern form of cultural reuse.

it may also be useful to refer to the historical framing of this from the Open Hardware Production post.

Lets tackle these with XCore at the center of Amino and perhaps makes some comparisons vs MCU/FPGA along the way.


Ports & Expansion

Originally to provide modularisation we extended the shield concept into a bus with ports. The MCU+logic would provide simple 8 bit busses for expansion. Although this was an improvement on the shield concept, by enabling multiple hardware modules to be used together, limited MCU pin numbers combined with hardwired functions made this an exercise in juggling and resulted in significant compromises. Using XMOS XS1 series soft chips provides significantly more I/O pins and ports which are dynamically reconfigurable, these are closer to an FPGA than a MCU. This flexibility enables an Amino development board to have many I/O ports which can take on multiple personalities/functions as dictated by the add on module hardware and a corresponding software driver*. Its worth noting that we are only using and defining digital I/O with the new designs, analog is added via modules to provide maximum flexibility.

Ports – Response & Control

In addition to the I/O modularity, we also get solutions to some of the more complex issues. Dealing with I/O in a timely manner using MCUs requires the use of interrupts which tend to be limited on MCUs, often logic is added to provide flexible port I/O response and management of interrupts. With XCore’s event driven I/O architecture these problems are eliminated completely and become part of the software and the module itself.

Ports – Special functions

Unlike MCU which use dedicated pins for special functions such as SPI,I2C etc.. XCore defines the pin functionally in software itself as a driver. Thus such functionality can be loaded at runtime according to the module requirements. This may seem counter intuitive at first compared to dedicated hardware blocks within an MCU. But it means you can have any number of pins dedicated to any number of functions rather than being limited to what’s hardwired on the MCU. For instance my application and its modules could require lost of SPI channels or UARTS, XCore can handle these requirements by dynamically loading the functions as required.

Ports – Dynamic Adaption

Even though I have not worked out where such an idea could be used in practice, an XCore could effectively change its pin functions during runtime to adapt to hot swappable modules or even complex modules that actually change there own functionality at runtime. This is an area that would be worth examining in the near future to take Amino to a completely new paradigm.


The physical pins will likely be grouped into 4/8 or 16 bit segments to provide standard pinouts and polarisation, logic will likely be at 3.3/3.6 volts to accommodate a wider range of modern peripherals not capable of 5v operation. The rest of the standardisation is defined by the software drivers and a simple XML configuration file. In addition to the regular Port expansions there will also be Link expansions to enable units to be interconnected to deliver arrays for more complex computing requirements. Debugging would be achieved using JTAG like schemes which may also be available on board via a USB interface. The programming environment will use a standardised toolchain and all hardware and software will be opensourced (there may initially be some limitations until all of the new toolchain pieces are completed). Because of the software nature of the standardisation an Amino board can be updated in the field to support any changes and or patches to the standards. Standards will be governed by full opensource implementations, these will act as de-facto standards and anyone can reproduce them in an opensource manner. This is key to any potential opensource distributed production tenets and as such will be encouraged to enable development and innovation across the Amino project. I am also looking at what can be included in the standard for testing using loopback and maybe even virtual instrumentation. Here standardisation enables replication to a given operational specification, important for opensource distributed production.


Here we are again playing to OSH strong points as illustrated by Arduino. In this case however we take it even further, with the digits controlling much more at a much lower level and with a much greater capacity for programming. Because such a large part of Amino using XCore is digits it is easily replicated and shared. In fact building a large opensource code base is the primary task for Amino’s success and is the number 1 focus right now. It will also allow new participants to build on the ‘shoulders of giants’ and lean on the wealth of the commons.


A great deal of XCore Amino fusion is really just software, reuse of bits is trivial, so much so that it could actually be reusable at runtime which is an interesting concept. Also because of its greater modularity and more flexible core its uses multiply. Thus it can be plucked out of one project or design and placed straight into another. I am also tempted by a lego like composition that enables projects to be completed with multiple units increasing reuse even further.

Moving Forward

So the combination of XCore and Amino aims fuse together nicely, what’s more the XCore blows the other candidates away when it comes to the key tenets of the project and thats why we don’t have the MCU + FPGA deliverables, there really isn’t any point. Instead I am focusing my time on developing the software architecture and standards alongside several XCore based boards in Fast, Faster and ‘To infinity and beyond..’ flavours. At this point I am developing using existing hardware development kits from XMOS themselves, and will have the software operating on several of these first. Plus I will also be making sure it runs on a stamp like board, possibly Omer’s Stamp board in the very near future.

As usual if you are interested in Amino or XCore let me know, if you want to help there is plenty to tuck into. Obviously we will be chewing the fat around the board and software designs as we post here so please contribute and let us know your thoughts.

At some point I would like to add a part 4 to OSH a way forward concentrating on ‘infinity and beyond..’ and where that could take us, but right now I am still gathering thoughts around how that will function and how it can be managed and how we could use composition to solve more complex projects, so watch this space.

*Note I use the term ‘Driver’ here but really it is a simple software module that can be dynamically loaded, driver is a little overkill but conjures up the basic idea.

OSH a way forward Pt.2


4 thoughts on “OSH a way forward Pt.3 – XCore & Amino Fusion

  1. Hi Mika

    I am finalising the first Amino dev board alpha right now and presenting later this week to folk at OSHUG (http://oshug.org) alongside David May from Xmos so bear with me. I hope to get new documentation up starting next week and also an architecture followed by roadmap post or two throughout May. I will be seeking as much feedback from folks like yourself who are likely to be early shapers of Amino development.


    1. HI Mika

      The OSHUG event went well last night, for a first event it had a good turn and great people. David covered Xmos and I covered Amino the idea, stack and the first board which we are finalising now Amino Alpha which I have just posted about https://folknologylabs.wordpress.com/2010/04/30/amino-alpha/ take a look and let me know your thoughts.

      More post coming shortly to explain the stack and architecture.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s