Old XMOS Board

[Berni]

Yep almost every higher end USB audio thing that uses Async USB audio has one of these XMOS chips inside.

This ended up being pretty much the main seller for these chips, even tho it doesn't really make use of any of the "special sauce" that these chips are capable of. Pretty sure you could do the same with any other decently grunty MCU with USB HS device and I2S peripherals. But if you did that you would need to implement your driver from scratch while XMOS gives you a ready working driver, comes with datasheets and support and you can buy the chip in singles off DigiKey. Sort of becoming the "FTDI for USB audio"

The tech behind it is really cool but it has fairly limited practical real life uses.

[0db]

If guaranteed by design timing is important, then the real competition is FPGAs, not other MCUs. Why - because measuring performance and hoping you happen to have come across worst-case performance is not sufficient.

I am surprised that big projects like "LinuxCNC" are still a thing made with a "dumb" (just a latch with some resistors and optocouplers) parallel port driver attached to a common PC running a RTAI/RT-patched vanilla-kernel rather than a PC interfaced via Ethernet (EtherCAT? AFDX?) to a standalone "black-box" internally made with an FPGA (for the hard real time stuff) coupled with a MPU for the miscellaneous services (for instance storing the CAM file, interfacing the FPGA to the remote computer by running TCP/IP, etc).

The time deadline for a lot of mechanisms is about 1msec, and these things simply "work" without a solid feedback and assuming the deadline is 1msec which is "assumed" because someone has "measured" something on a DSO and found it respected in the worst case in a lab environment.

Worse still, since modern computers have clock frequencies above 1Ghz, then this somehow is assumed "enforcing" the assumption that "there is enough time" to respect the 1msec deadline on the /dev/lpt port. Which is theoretically wrong, although it's proven to work (at least for hobbyists).

At least with FPGAs there is a solid methodology enforcing discipline, and such discipline also includes the "formal verification" methodology for the all the involved HDL parts.

You can't have it with any DSP or CPU. So, if I was asked to design something, I would use FGPAs in this case, ... or ... XMOS? ... indeed I am surprised that XMOS has never been considered.

And that's the point: why not? 

[tggzzz]

While many things appear to work, many other have unreproducible failures.

Never underestimate human factors including things like not having been taught something, not knowing the possibility of black swan timings, only having a hammer an not having a screwdriver, not knowing or caring that better things exist, and being told to do it the way they have always done it.

[maginnovision]

Yep almost every higher end USB audio thing that uses Async USB audio has one of these XMOS chips inside.

This ended up being pretty much the main seller for these chips, even tho it doesn't really make use of any of the "special sauce" that these chips are capable of. Pretty sure you could do the same with any other decently grunty MCU with USB HS device and I2S peripherals. But if you did that you would need to implement your driver from scratch while XMOS gives you a ready working driver, comes with datasheets and support and you can buy the chip in singles off DigiKey. Sort of becoming the "FTDI for USB audio"

The tech behind it is really cool but it has fairly limited practical real life uses.

With XMOS everything is basically done already, you just add whatever UI type stuff you'd like. Same with their newer "Voice"(XVF I think) chips. They're essentially ready to go directional microphone chips. It's as close to plug and play as you get for uC's for these things.

[b_force]

Yep almost every higher end USB audio thing that uses Async USB audio has one of these XMOS chips inside.

This ended up being pretty much the main seller for these chips, even tho it doesn't really make use of any of the "special sauce" that these chips are capable of. Pretty sure you could do the same with any other decently grunty MCU with USB HS device and I2S peripherals. But if you did that you would need to implement your driver from scratch while XMOS gives you a ready working driver, comes with datasheets and support and you can buy the chip in singles off DigiKey. Sort of becoming the "FTDI for USB audio"

The tech behind it is really cool but it has fairly limited practical real life uses.

With XMOS everything is basically done already, you just add whatever UI type stuff you'd like. Same with their newer "Voice"(XVF I think) chips. They're essentially ready to go directional microphone chips. It's as close to plug and play as you get for uC's for these things.

I think that really depends how you look at this.

For me, a good example of plug and play, is Analog Device's DSP range with SigmaStudio.
Documentation is very clear, there are good and affordable dev boards as well as examples for the schematics as well as software.
So basically there is no custom programming involved, it's very intuitive and the support forum is being taken very serious (especially for company standards)

With XMOS it feels much more like a programmers hobby project (absolutely NO offence!).
And as a hardware engineer like me, it's feels a bit overly complicated to companies like C-Media (which unfortunately have poor support and documentation).
Pure personal speculation, but I get a very strong feeling that there are just a handful of companies/patents out there and they really want to keep their recipes secret.

Basically I just want a small chip with a bunch of i2s in/outputs that I can easily implement without any fussing with weird custom drivers.
This was possible with the USB1 devices like the TI PCM29xx series (and alike from c-media, Realtek etc), and I don't see any technical reason why this wouldn't be possible for newer USB audio interface IC's.

[tggzzz]

With XMOS it feels much more like a programmers hobby project (absolutely NO offence!).

What makes you feel that?

I ask because the software fundamentals have a solid basis in theory (CSP) developed >40 years ago.

Most software, OTOH, is based on a series of hacks that don't have obvious failure modes.

As the inventor of CSP an QuickSort (And NULL!), as well as other fundamentals put it...
“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.

[0db]

the software fundamentals have a solid basis in theory (CSP) developed >40 years ago.

I speculate withing 10 years nobody will ever say something similar because things will be so massively parallel that having a solid basis in theory will be mandatory rather than optional like we are used to see nowadays.

[Sal Ammoniac]

I speculate withing 10 years nobody will ever say something similar because things will be so massively parallel that having a solid basis in theory will be mandatory rather than optional like we are used to see nowadays.

People have been predicting that things would be massively parallel in ten years for the last 60 years now.

[b_force]

With XMOS it feels much more like a programmers hobby project (absolutely NO offence!).

What makes you feel that?

I ask because the software fundamentals have a solid basis in theory (CSP) developed >40 years ago.

Most software, OTOH, is based on a series of hacks that don't have obvious failure modes.

As the inventor of CSP an QuickSort (And NULL!), as well as other fundamentals put it...
“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.

That makes me feel from a user point of perspective, I am an hardware engineer not a full-time software developer.
So I am not talking about software "fundamentals". (I don't even understand why you come up with these fundamentals, obviously they are solid?) 
Just how easy it is for me to implement some kind of hardware solution.

Have you ever worked with Sigma and Shark DSP's?

[0db]

People have been predicting that things would be massively parallel in ten years for the last 60 years now.

Just 10 years ago the deep learning was as powerful as it's nowadays. That's because nowadays we already have massively parallel devices. The Fujitsu AFX64 is a good "small" new example. It has "just" 84-core 64-bit ARM processors, while the old Epiphany-V/1024 had "only" 1024-core 64-bit RISC processors.

This stuff was simply impossible/too difficult/too expensive with the previous level of technology.

Besides, the "reduce(1-p)" part in the Amdahl's law seems to have been given more consideration since 2014. That means six years ago we silently entered in the new Era with more (paid) researching on Functional Programmings and such stuff.

[tggzzz]

I speculate withing 10 years nobody will ever say something similar because things will be so massively parallel that having a solid basis in theory will be mandatory rather than optional like we are used to see nowadays.

People have been predicting that things would be massively parallel in ten years for the last 60 years now.

Partly correct, but the need was disguised by the brute force improvements due to semiconductor scaling processes , popularly known as Moore's Law.

That has run out of steam, so people will have to use their imagination rather than a cheque book and waiting!

Except for the commercially important class of "embarrassingly parallel" problems, Amdahl's Law will always be valid.

[tggzzz]

With XMOS it feels much more like a programmers hobby project (absolutely NO offence!).

What makes you feel that?

I ask because the software fundamentals have a solid basis in theory (CSP) developed >40 years ago.

Most software, OTOH, is based on a series of hacks that don't have obvious failure modes.

As the inventor of CSP an QuickSort (And NULL!), as well as other fundamentals put it...
“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.

That makes me feel from a user point of perspective, I am an hardware engineer not a full-time software developer.
So I am not talking about software "fundamentals". (I don't even understand why you come up with these fundamentals, obviously they are solid?) 
Just how easy it is for me to implement some kind of hardware solution.

Have you ever worked with Sigma and Shark DSP's?

Parallel hardware is relatively easy, and has been since the 70s.  That's especially true for special cases such as DSP.

Parallel software is difficult, partly because the application domains are more awkward, and partly because the software isn't available. Example: as late as 2004 Hans Boehm had to point out to people that you cannot write threading libraries in C! That might have changed with the latest standard, a few decades too late.

Having hardware multicore multiprocessing integrated with parallel processing language has been achieved by XMOS, not elsewhere.

Summary hardware people think parallelism in software is easy. It isn't. Look at theItanium for a very expensive example of that.

[Leo Bodnar]

XMOS is a good example of how a company with 65 employees (22 executives and 16 board members) can't be bothered to fix their DNS so that their website that hosts their support forum, all the documentation links in their pdfs and all the kiddie "cloud" stuff in their IDE is available for most of the world.  I can't get onto it for a week now.
And, no, their HQ office phone number is not getting answered either.

Leo

I received the xCORE-200 explorer kit I ordered and it works a treat. Even with both tiles running full-blast, it only gets up to 83F. The XMOS chip on my old board got up to 170F and was too hot to touch.

Are there any forums where people discuss xCore programming? Active ones, hopefully...

[Sal Ammoniac]

XMOS is a good example of how a company with 65 employees (22 executives and 16 board members)

Are you kidding? 1/3 of XMOS's employees are executives? How can that work, and how can that be sustainable? 

can't be bothered to fix their DNS so that their website that hosts their support forum, all the documentation links in their pdfs and all the kiddie "cloud" stuff in their IDE is available for most of the world.  I can't get onto it for a week now.

You're right--their site is down. If it's really been down for a week, that's inexcusable and makes me wonder if the company is still viable. Perhaps this has something to do with Covid-19? But I doubt it, as IT people can easily work remotely.

EDIT: Try xmos.ai -- that site is up and seems to contain all of the content of xmos.com. Perhaps when they added the .ai domain they forgot to keep the DNS entries for the .com domain.

[tggzzz]

Formal company information is https://beta.companieshouse.gov.uk/company/05494985/filing-history

[Sal Ammoniac]

Formal company information is https://beta.companieshouse.gov.uk/company/05494985/filing-history

Interesting reading some of that. I didn't know Xilinx had such a big investment in XMOS.

[tggzzz]

Formal company information is https://beta.companieshouse.gov.uk/company/05494985/filing-history

Interesting reading some of that. I didn't know Xilinx had such a big investment in XMOS.

Yes. I have a lot of respect for xilinx; they aren't fools!  I was acquainted with Wim Roelendts when he was at HP, and I respected him.

There can, of course, be multiple reasons for one company to invest in another.

[Leo Bodnar]

XMOS chips are, basically, multitasking softcore MCUs running on what must have started as [Xilinx?] FPGA and ended up as ASIC.
Their lowest level "assembly" instructions include "Get thread ID" or "allocate a resource." Assembler might also rearrange the instructions when it feels like it.

Unfortunately, their documentation is one of the worst - written in an awkward language and avoiding a lot of finer details.
I can get a lot of it from xcom.ai but all in-document links from existing documentation refer back to xcom.com
Leo

[maginnovision]

I keep waiting for a new process and possibly a 1GHz clock instead of the current 500(or 600 for the new XVF). I also wanted them to switch to 100% scaling so 1 thread could get every single one of 500M cycles a second, then 250, 166, 125... They said it's not going to happen though. Typically the only good reason to write assembly for these things is bug workarounds, implementing interrupts which they don't have support for in C, and optimizing for dual issue instructions because support through compiler is incredibly poor.

I don't know that they started on a xilinx since they're basically the reincarnation of the transputer. Possible though. xmos.com forwards me to xmos.ai. They've ALWAYS had issues with documentation links regardless of their website. Some stuff is on github, some on the website, some is best found through the eclipse client and sometimes the best way to find what you're looking for is talk to someone.

[Leo Bodnar]

I also wanted them to switch to 100% scaling so 1 thread could get every single one of 500M cycles a second, then 250, 166, 125...

I did not manage to get around instruction cycle jitter even with one-two threads. Coming from deterministic programming in assembly all my life, it makes you think differently.

I am slightly worried that they are always chasing a new buzzword and slightly matured products are dropped off quite regularly.
Leo

[tggzzz]

XMOS chips are, basically, multitasking softcore MCUs running on what must have started as [Xilinx?] FPGA and ended up as ASIC.
Their lowest level "assembly" instructions include "Get thread ID" or "allocate a resource." Assembler might also rearrange the instructions when it feels like it.

Unfortunately, their documentation is one of the worst - written in an awkward language and avoiding a lot of finer details.
I can get a lot of it from xcom.ai but all in-document links from existing documentation refer back to xcom.com
Leo

The key advantage is not the hardware (although the io structures are very neat powerful and simple like an FPGA), but is the software and its integration with the hardware.

Of course for somebody who programming==C it will be a struggle. But parallel programming in C has always been more of a struggle, starting in the K&R days when it was explicit that it was outside the scope of the language.

I found the documentation to be superb, some of the best I've seen. In a "kick the tyres" project I was stunned at how fast I was up and running and getting the results I expected.

[tggzzz]

I also wanted them to switch to 100% scaling so 1 thread could get every single one of 500M cycles a second, then 250, 166, 125...

I did not manage to get around instruction cycle jitter even with one-two threads. Coming from deterministic programming in assembly all my life, it makes you think differently.

I had zero problems provided I used the timers in each io port.

I am slightly worried that they are always chasing a new buzzword and slightly matured products are dropped off quite regularly.
Leo

That causes me a little concern too.

[Berni]

I keep waiting for a new process and possibly a 1GHz clock instead of the current 500(or 600 for the new XVF). I also wanted them to switch to 100% scaling so 1 thread could get every single one of 500M cycles a second, then 250, 166, 125... They said it's not going to happen though. Typically the only good reason to write assembly for these things is bug workarounds, implementing interrupts which they don't have support for in C, and optimizing for dual issue instructions because support through compiler is incredibly poor.

The CPU probably runs its internal pipeline in 4 major stages. So it takes 4 clock cycles to get one instruction trough it, but since each stage uses a separate part of the CPU logic you can send 4 instructions trough it one after the other and they end up executed one after the other to make it appear like its 1 clock cycle per instruction. So getting 1 thread to use all of the CPU cycles is likely impossible without completely redesigning the CPU.

These days they market the chips are "8 core" chips, they switched to this misleading naming convention with the release of the 2nd or 3rd generation chips(Not sure how they count generations). Its still actually a 1 core chip with 'hyperthreading' that gives it 8 threads(As they used to call it in the 1st gen). The approach to it is pretty much the same as Intels x86 hyperthreading, its just a single cpu with multiple sets of internal registers so that it can quickly switch over between multiple sets of state. Tho Intel mostly uses it to give the CPU something to do when one thread hits a cache miss or needs some busy shared resource. The XMOS chips just upped the thread count and added a special thread communication system.

What i mostly found annoying on XMOS is the lack of classical peripherals. Yes sure that's kinda the point behind this flexible IO, but its anoying to have to sacrifice an entire thread just for bitbanging something simple like SPI.

[Leo Bodnar]

The key advantage is not the hardware (although the io structures are very neat powerful and simple like an FPGA), but is the software and its integration with the hardware.

Yes, outstanding selling points of XMOS are their easy-to-use abstractions of multitasking and fast inter-IC networking.  Hardware is nothing to rave about.

They got massive initial boost by being almost the only company who had half-decent USB Audio 2.0 stack and usable Windows driver available - until Microsoft caught up, 10 years later with own half-working bodge (they still license UAC2.0 driver from Thesycon who wrote it for XMOS.) Similar to FTDI and USB-CDC situation.  I attribute their current market success to this twist of fate. USB Audio does not really need parallel multitasking or transputer network to work.  It was just a bit of good luck.

Notice how XMOS almost abandoned the market that made them - there is no support for USB Audio 3.0 for 4 years running.  They put all their efforts into chasing Alexa-like voice speakers for awhile.  Now it's all about AI.

Leo

[tggzzz]

I keep waiting for a new process and possibly a 1GHz clock instead of the current 500(or 600 for the new XVF). I also wanted them to switch to 100% scaling so 1 thread could get every single one of 500M cycles a second, then 250, 166, 125... They said it's not going to happen though. Typically the only good reason to write assembly for these things is bug workarounds, implementing interrupts which they don't have support for in C, and optimizing for dual issue instructions because support through compiler is incredibly poor.

The CPU probably runs its internal pipeline in 4 major stages. So it takes 4 clock cycles to get one instruction trough it, but since each stage uses a separate part of the CPU logic you can send 4 instructions trough it one after the other and they end up executed one after the other to make it appear like its 1 clock cycle per instruction. So getting 1 thread to use all of the CPU cycles is likely impossible without completely redesigning the CPU.

These days they market the chips are "8 core" chips, they switched to this misleading naming convention with the release of the 2nd or 3rd generation chips(Not sure how they count generations). Its still actually a 1 core chip with 'hyperthreading' that gives it 8 threads(As they used to call it in the 1st gen). The approach to it is pretty much the same as Intels x86 hyperthreading, its just a single cpu with multiple sets of internal registers so that it can quickly switch over between multiple sets of state. Tho Intel mostly uses it to give the CPU something to do when one thread hits a cache miss or needs some busy shared resource. The XMOS chips just upped the thread count and added a special thread communication system.

What i mostly found annoying on XMOS is the lack of classical peripherals. Yes sure that's kinda the point behind this flexible IO, but its anoying to have to sacrifice an entire thread just for bitbanging something simple like SPI.

Each core gets a 2ns slice to do its instruction (100MHz*5, not eight!). That feels sufficient to execute the instruction without significant pipelining - see suns Niagara chips for server-level equivalents.

Yes, in hardware terms is just SMT on steroids, but the point is that they made novel and good use of that to guarantee performance - similar to Suns Niagara chips for servers. Intel's hypertherading merely ups performance if the wind is in the right direction, and the HPC brigade normally disable it because it degrades their performance!

Using one core per I/o channel seems wasteful, but avoids the use of interrupts and guarantees hard realtime performance. That is conceptually like FPGAs and is fine provided you don't run out of cores.

You can have the software automagically multiplex multiple processes onto a single core, provided you stick to a simple and non-onrous coding style. Basically it just combines all the setups into one block and all the select statements into a single select. In terms of performance, that the same as a single core processor with coroutines or cooperative threads with yield().

I'd use that technique for non-critical io such as spi.

That you can implement 100Mb/s Ethernet links in software is noteworthy. Whether it is more sensible to use one of the variants with an Ethernet controller is a separate question