Free Developement tools from XMOS

A short rummage around the Xcore site lead me to The XCore Open Source Project and the Xcore Github repo, which as an open source advocate, I found very encouraging.  I also noted the contributor's agreement  which goes beyond forking Github repos and allows developers to contribute more directly back to the company sources.  I see this as a sign that open source interest at Xcore is rather more substantial than the "throw code over the wall" kind of openness which is unfortunately common.

Which leads me to a couple of questions:

1. Is the impression I've gained above correct?
2. Are XMOS devices fully documented so that OSHW communities can develop around these devices and create their own complete toolchains to program them?

Question 2 relates to the uncomfortable situation we presently have with FPGA manufacturers, none of which provide complete programming information for their devices so that it has been impossible for the community to develop full toolchains for them.  This has effectively extinguished open source progress in that area.

If the answer is "Yes" to both questions then this is going to be of interest to many.

===

Addendum:  I had asked about unit availability earlier too, but the answer was right here at Farnell UK, 6 different devices all in stock!  Excellent!

Are XMOS devices fully documented so that OSHW communities can develop around these devices and create their own complete toolchains to program them?

We do have public documentation for enough stuff (architecture, ABI etc.) to create a toolchain. Have a look at the following projects for more details:

http://www.xcore.com/projects/gcc-xs1
http://www.xcore.com/projects/binutils-xs1

Contact seems to have dried up, although of course XMOS Support  might be simply busy, or investigating the question with the intention of giving a well-informed answer.  I hope that's the case.

Meanwhile ...

John Alexander wrote:

 

One advantage here is that at least one of their Toolchains was openly built around Open source tools.

Which toolchain is that?  I've been looking at the Xcore github repos and haven't found any XMOS toolchain sources yet.  The two mentioned toolchain projects (gcc-xs1 and binutils-xs1) appear to be one-person efforts and no files have been posted for either of them.  There are tons of application modules in Github, but they're generally written in XC --- is that compiler maintained as open source?

If not, then since XC has extensions not present in gcc, the point made by John applies to it.  Is all the functionality employed within the XC implementation documented, so that a fully-functional equivalent open source tool (assuming that XC is not) could be written from the documentation?

Hi,

The XMOS toolchains is built around various open source tools such as gdb, LLVM, eclipse, and binutils, and standard intermediate formats such as ELF and dwarf.

Source tarballs for the open source components are on <http://www.xmos.com/products/design-tools-source>.

Hope this helps,

Henk

Thanks for that link Henk, the previous toolchain used Eclipse asthe front end what are they using now??

Sorry haven't installed it yet thus the question!

Sorry but I also see you are using Open OCD which is great, however I do not see support for th XJTAG dongle mentioned in the supported devices column for  OpenOCD.

Has your work been pushed back into the main tree or kept here. It would be nice to use the supplied XJTAG for other stuff if we could ....bummer since 've just got another from Seeed

Henk Muller wrote:

 

The XMOS toolchains is built around various open source tools such as gdb, LLVM, eclipse, and binutils, and standard intermediate formats such as ELF and dwarf.

 

Source tarballs for the open source components are on <http://www.xmos.com/products/design-tools-source>.

That's excellent news Henk, many thanks for the information --- I'll examine them shortly to see what they contain.

Mostly I expect to find what the package names would suggest of course, but the point I'm trying to get answered is the one worded so clearly by John Beetem earlier, namely "vendors should document everything that's needed to use the chip functions for which customers buy the chip" --- the implied question being, "Is this so for XMOS?".

So as an example, if XC is not among the open source tools, then could the full functionality of XC be implemented in an open source tool based on released documentation, or does XC make use of XMOS funtionality or interfaces or protocols or registers etc etc which are not documented?  The question stems from the (hopefully obvious) point that even open source users buy chips to use all their functions.

The question in the context of XC was just an example.  It becomes entirely moot for XC if it turns out that XC is part of an open source package such as XDE, which appears to be another name for xTIMEcomposer which does contain an "xcc" which seems likely to be the XC compiler.  I'll have to check this, but indications seem very hopeful so far just from looking at names.

John's question becomes irrelevant for any tool that is already open source, only applying to those which aren't.

"John's question becomes irrelevant for any tool that is already open source, only applying to those which aren't."

I assume that's John Beetham's question ?

Yep, sorry, name clash, which I thought the context would have kept clear but I guess it didn't.

John Beetem wrote in post #14:

 

My general philosophy towards ICs is that vendors should document everything that's needed to use the chip functions for which customers buy the chip.  It's fine to have hidden test modes not used by customers.  I'm willing to live with hidden bit-stream encryption provided that customers can choose not to encrypt and bypass that logic.

The implied question for any new device being considered as a target by open source developers is whether this level of documentation exists, or whether some closed vendor tools are able to do things beyond the potential of open source because they exercise undocumented features of devices or interfaces, or require secret information such as encryption keys.

It doesn't apply to vendor tools that are already open source since there is usually no need to re-implement them, and even if reimplementation is felt necessary then the open sources are themselves a form of partial documentation.

Hi John (Alexander),

THe IDE is based on eclipse, and there are of course command-line-tools.

Re openOCD I have to disappoint you: we have moved beyond that. We mostly use the XTAG2 debugger which is customisable in software. The good news is that both the hardware design and source code are on-line (https://github.com/xcore/proj_xtag2). As it loads its firmware through a USB-bootloader we can load it with any firmware. The loading process is also on-line on <https://www.xmos.com/en/download/public/Dynamic-code-loader-for-XTAG2.pdf>. This is possibly not for the faint hearted and definitely not part of a gentle introduction to XMOS.

Cheers

Henk

Hi Morgaine

Mostly I expect to find what the package names would suggest of course, but the point I'm trying to get answered is the one worded so clearly by John Beetem earlier, namely "vendors should document everything that's needed to use the chip functions for which customers buy the chip" --- the implied question being, "Is this so for XMOS?".

I fully agree with the spirit of that statement; but there are practical limitations that any company (or individual, or university) will hit. For example, resources are always limited, even in mega companies, and one will first document those parts that the majority of the customers need; or it could be that a company has bought some IP that it is not allowed to release publicly.

For XMOS - we sell silicon and are keen on people to use it in anyway they see fit. The combination of (a) the architecture manual and (b) the system manual should enable anybody to write a compiler, or any piece of assembly code; using any of the datasheets you should be able to write yourself a loader, and configure the chip to the same extent that our tools do. The JTAG debugging interface has (at present) no user-facing documentation, but it is not kept secret, all source code that uses it is on-line in the github repo listed in the previous post.

Cheers,

Henk

Henk Muller wrote:

 

using any of the datasheets you should be able to write yourself a loader, and configure the chip to the same extent that our tools do. The JTAG debugging interface has (at present) no user-facing documentation, but it is not kept secret, all source code that uses it is on-line in the github repo listed in the previous post.

That's excellent to hear, Henk!

Most open source users are entirely reasonable people, and realize that documenting things takes time.  The most important element might be simply the intent of the company, since no amount of time will remedy the situation when the intent is to deliberately restrict the possibilities of open source in order to make money from official tools or because the company is ill-disposed towards openness (there are examples of both).

From what you describe, any such worries would not be well founded here  It sounds to me like this is a product line and a company well worth supporting.

Which makes me happy, coming from the days of the transputer and appreciating the legacy.

Henk Muller wrote:

 

using any of the datasheets you should be able to write yourself a loader, and configure the chip to the same extent that our tools do. The JTAG debugging interface has (at present) no user-facing documentation, but it is not kept secret, all source code that uses it is on-line in the github repo listed in the previous post.

That's excellent to hear, Henk!

Most open source users are entirely reasonable people, and realize that documenting things takes time.  The most important element might be simply the intent of the company, since no amount of time will remedy the situation when the intent is to deliberately restrict the possibilities of open source in order to make money from official tools or because the company is ill-disposed towards openness (there are examples of both).

From what you describe, any such worries would not be well founded here  It sounds to me like this is a product line and a company well worth supporting.

Which makes me happy, coming from the days of the transputer and appreciating the legacy.