RE: XMOS devices

[J.B.W.Webber <J.B.W.Webber@xxxxxxxxxx>]

Thanks indeed Peter, for pointing me to XMOS.

There has been some discussion re using XMOS chips as the outer ring of processors, to handle I/O as it happens, rather than having to prioritises.
So I thought I would summarise my experiences over the last few days.

On Wednesday I finally had time to have a proper look at the XMOS site, and decided to download their compiler suite - based on Eclipse (like the Altera NiosII suite but customised significantly differently).
The example Flashing-LED example appeared to compile, and it was then quick to create, build and simulate a hello-world program.

So I ordered an XC-1A module from RS - Â73 + VAT - came on Thursday evening. This has 4 cores and 1/4Mb ram.
Flashing-LED and hello world ran on a core fine, and it was quick to change the LED flash rate.

That is where things slowed down. My main wish regarding the XMOS and NiosII devices is to port Apl generated code to them - Apl and Maple are between them my main tools of thought. 

In the 80s I was hand-translating Apl to Basic and 6800 assembler, in the 90s to LabVIEW, and at the moment I am having to do it to VHDL. The aim is to make use of Tim Budd's aplc APl to c translator, which in the 1990s I ported to SGIs and the Dec Alpha, as well as the lowly Atari TT. This has the advantage that in the 19980s/1990s I also added a minimum set of multi-tasking / multi-processor facilities (Julian Timestamp, pipe, spawn, and detailed I/O control) which I believe give it some of the capacity to form multiprocessing nodes  :
	http://home.earthlink.net/~swsirlin/aplcc.html	
	http://www.lab-tools.com/instrumentation/html/dod22.html 
	A Pipe has two ends. Using APL in a multiprocess/multiprocessor environment. A proposal for a flexible 	but easy to use syntax. J.B. Webber. Apl Quad Quote 20, 1, 1-2, Sept 1989. 	http://doi.acm.org/10.1145/379199.379200   
	(The proposal and implementation of a software mechanism now used by IBM.) 

The XMOS Eclipse set-up has a graphical Makefile, but not all of it seems to work as one would expect, and there is some other magic one has to do - it is described in the documents, but I will put a blog up with the
details, or ask if you are stuck. What I have not got to work (which seems to work on the NiosII setup) is run an external script (./configure) to configure the aplc Apl to C compiler for this processor and compiler suite. However the main need is to compile the aplc run-time library, about 50 .c and .h files, some (LAPACK heavyweight maths package) themselves translated from the Fortran. 

I regret to say that to get this to compile I have had to turn off all the multi-tasking facilities, but for the moment simple code does run. I will have to dig and see what the problem is, because when I look at the library files, it all seems to be there. I am not entirely surprised, I am porting Unix code.

Anyway, for a very short test, of summing a vector :
Apl running in MicroApl's AplX :
      V â â 9
      â â V
1 2 3 4 5 6 7 8 9
      S â +/V
      â â S
45

XMOS :
Translated to c and compiled and running on a single core of the XC-1A module :
1 2 3 4 5 6 7 8 9
 45

I tried a larger test : "ulam.apl", being a simple (overly-simple) 5 function apl demo program, that generates a list of primes and then proceeds to show them as a pattern (the pattern probably says more about the human desire to find patterns). This compiled fine, but was 1/3 too large for a single core.
My interest in compiling this was anyway to use it as a distributed example. 

For an example of the sort of thing I want to get working in aplc on the XMOS devices, and also on the NiosII using a core with floating point, see some of the hand-coded VHDL examples :
	http://www.lab-tools.com/instrumentation/#FPGA_Modular_Firmware_Skeleton 

So my next tasks are to find why I am having to turn off the communications in the XMOS compilation, and get them working again, and also to try and persuade the NiosII compiler suite to load a -l aplc library.
Then I can work on having multiple aplc programs interacting. 
Then I will look at real-world interactions using the XMOS devices.
Cheers,
	Beau


-----Original Message-----
From: P.H.Welch [mailto:P.H.Welch@xxxxxxxxxx] 
Sent: 27 September 2012 18:58
To: J.B.W.Webber; occam-com@xxxxxxxxxx; rick.beton@xxxxxxxxx
Subject: RE: Occam-Tau - the natural successor to Occam-Pi


Hi Beau,

> However for my sins these days I spend quite a bit of my time writing 
> VHDL for the FPGA based instrumentation I design for my experiments.
> And I keep looking at the concept of the multiple soft processors with 
> fast interconnection links that can fit on these chips.
> 
> Is there any possibility of any of these Occam related parallel 
> languages  being of use for sitting inside / generating code for these 
> soft processors, on a reasonable time-scale ?

Take a look at:

  http://www.xmos.com/

This was founded by David May (chief architect for the transputer and occam) and others a few years ago.  They are targetting (I think) customers with needs exactly like those you describe.  Their XC language is a specialised derivative from occam and their chips seem designed as FPGA replacements:
soft hardware re-programmable in an occam-like manner with very sleek hardware support for concurrency (up to 32 processes anyway).

Cheers,

Peter.