XC - The Future

[jonathan]

There is now a substantial body of users and an even bigger body of code written in XC. If I had to guess there's now probably more lines of XC written by people outside XMOS than inside.

This means that users have invested quite a bit in XC - time, effort, and in some cases money. And these users have learned to adapt to problems and idiosyncracies and changes to the language over time.

In my opinion, what is now needed though is to recognise that the language is really more of a tool for the XMOS users, customers and developers than it is for internal XMOS staff. That means that when considering language changes, additions, and development, these users should at the very least be informed and at best consulted about decisions on the future of the language well in advance.

This will mean:

1) Releasing the current roadmap for XC - showing bugs, features and plans for future development with some timescales. This will enable developers - customers - to feedback on what is important to them and also plan for future improvements to the language. In particular, any plans for typed channels or protocols, process mobility, relocatable, dynamically-loaded code and modules (a reserved word), are very important to members of this community, as recent discussions have shown.

2) Releasing the current implementation of XC - the compiler and tools - so that the community can develop, improve, and learn from the implementation and the language, as well as be equally invested in its future.

I'd be interested to see viewpoints on this from both inside and outside the company! This is just my opinion here... and I'd be delighted to be challenged.

Thanks for reading.

[jonathan]

An interesting blog response to the question has been posted here:

http://www.sububi.org/2010/06/23/xmos-xc/

The author assumed I was still at XMOS and credited the realisation to XMOS. Someone at XMOS was very quick to point out this inaccuracy. ;-) :lol:

It would be great to get some responses from XMOS guys here too? :D

[Jerry]

Jonathan,

Are you related to that "other" Mr. May at XMOS?

[bob32b]

This is an interesting idea but I don't think it goes far enough.

There are also more chips outside of XMOS than inside, so these too are platforms for XMOS users, customers, developers and of course entrepreneurs rather than just XMOS staff.

So how about this - XMOS should also release all of it's design files (including RTL) for the chip too into the public domain and allow the community to develop, improve, and learn from the architecture and implementation.

Who knows, XMOS's competitors may even like to get involved too!

[dave]

For some time we (XMOS) have been planning to open-source the XC tools (compiler etc). Further, XC is not intended to be a proprietary language. It could be targeted to other platforms, using a simple run-time to implement the concurrency features supported by the XCore instruction set. An alternative would be to run XC programs on a functional simulator of the XCore - I've had one of these for a while and it achieves around 100 simulated MIPS on a typical PC/laptop.

Given the above, it makes sense to create a forum to discuss XC language issues and enhancements. I'll give this some thought.

We are also in the process of tidying up a number of other licensing issues and most of our software and board designs will be covered by open-source licenses - where possible using the same license used for LLVM.

We don't have any plans to release the innermost details of the XMOS chips. However, it would probably make sense to have hardware designs for XMOS links to make it easy to design peripherals that connect to them.

[SpacedCowboy]

We don't have any plans to release the innermost details of the XMOS chips. However, it would probably make sense to have hardware designs for XMOS links to make it easy to design peripherals that connect to them.

So, Dave, if I wanted to go about writing a CPLD/FPGA Verilog XMOS link module, so I could offload some of the heavy lifting for a Discrete Cosine transform, say, [grin] nothing too specific here, no Siree [/grin], what have you got that's public that could help me get the protocol down.

I'm thinking of something as simple as a bidirectional FIFO <~> XMOS link, and handling the bytes-in = bytes-out by a-priori knowledge on both sides which can only comply.

(yes, I realise this is an old thread ;)

Simon

[Allein]

Hi,
This kind of discussions on whether using I/O mapped peripherals or Xlink connected peripherals and "servers" brings me back some 20 to 25 years ago, a the age of Transputers.
At that time, Inmos (the "ancestor" of XMOS, for the young ones) had Link I/O interface chips that we were using for simple interconnections to the outside world. We also developed CPLDs to that extent. The beauty in the interconnection of peripherals or "servers" through Links was the ease for software integration thanks to the channels. But throughput was quite always an issue.

Basically, Dave has mostly addressed all the issues we were facing at that time: XMOS XCores and XLinks have taken all the legacy of Transputers and brought it even further than what we were dreaming of at the time of T9000 death - at least for an industrial systems architect like myself; the supercomputing guys are certainly feeling left aside...

But the discussions (and new ones as well) are still open and valid:

1) Connecting a peripheral or "Server" service to an XCOre through the I/O Ports is still less obvious than the XLink interconnection way, both for hardware and for software integration.
2) The XLink interconnection is, with the currently available XLink bandwidth, a kind of dream. But without a standard XLink I/O chip or seasonned VHDL and FPGA skills, it's a not obvious task.
3) Although, to my eyes, the XLink interconnection of peripherals is complementary to the I/O Port implementation, isn't it a bit in contradiction with XMOS' marketing statements about "XCore Ports used for universal I/Os - no more FPGA needed", as eventually, the interconnection to an XLink requires an... FPGA... ;-)

I'm currently working (unfortunately having less time available than expected, I hope to have it available only by the end of the year) on a standard FPGA block for interconnecting a 5w XLink to the outside world, both in standard and in streaming modes.
This block is part of my "XLink non-volatile memory service board" project .

Dave: is there any interest from XMOS to booster such an XLink FPGA block by starting a collaboration on that topic ?

Best regards
Alain

[segher]

1) Connecting a peripheral or "Server" service to an XCOre through the I/O Ports is still less obvious than the XLink interconnection way, both for hardware and for software integration.

If you do not consider the thread doing the actual I/O, only the (channel!)
interface that other threads use to communicate to it, it is _the same_, but
with much higher bandwidth (if on the same chip, it is the maximum bandwidth
you can get anywhere on the chip -- more bandwidth than you have to memory!)

2) The XLink interconnection is, with the currently available XLink bandwidth, a kind of dream. But without a standard XLink I/O chip or seasonned VHDL and FPGA skills, it's a not obvious task.

Yeah, the current single-ended xlinks are pretty weak. Some serdes goodness
would be lovely.

Note that you can always "gang up" a few links to get more bandwidth (and that
doesn't even hurt latency).

3) Although, to my eyes, the XLink interconnection of peripherals is complementary to the I/O Port implementation, isn't it a bit in contradiction with XMOS' marketing statements about "XCore Ports used for universal I/Os - no more FPGA needed", as eventually, the interconnection to an XLink requires an... FPGA... ;-)

I don't see the contradiction: putting I/O on an xlink is not the usual
approach, you normally want to talk to peripherals that have a defined
interface already (which isn't xlink, but typically some busses with some
handshake signals and clocks and out-of-band signals). The "no more
FPGA needed" statement applies quite well for interfacing an xcore to
some I/O device in that way; with most other micros you would need
an FPGA in between to get any decent performance.

By the way, a very big disadvantage you get when you put I/O on the
far end of an xlink is that predictable (low) latencies go out the window.

Cheers,


Segher