Old XMOS Board - Page 1
Forum section: electronics / general

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 21, 2020, 11:05:38 pm
content: While rummaging through the closet in my lab, I came across some old XMOS hardware that's at least a decade old. Unfortunately, the board appears to be dead. Photo below.Finding this board has gotten me interested in trying to do some development with XMOS hardware again. What's the latest state of the art in XMOS dev kits? I know they've started to concentrate on the audio and voice markets, but I have no interest in either of those two areas. Would the xCORE-200 explorer kit be a good upgrade from my ancient board? Also, I noticed that they now have an XTAG3 debugger--is this a worthwhile upgrade from my XTAG2?

author: EverydayMuffin
author_rank: Regular Contributor
timestamp: August 22, 2020, 03:33:01 pm
content: The XS1-G4 is areallyold XMOS chip and looks like this is Engineering Samples RevA. The original xCore parts were as follows:XS1 G-Series (G = General - EOL'd in 2017)XS1 L-Series (L = Low power - compared to G-series)XS1 A-Series (A = Analog - adds DC-DCs + ADC)XS1 U-Series (U = USB - adds USB PHY)XS1 XA-series (XA = Xcore + Arm - EOL'd in 2016)The xCORE-200 Explorer Kit which comes with XE216-512-TQ128 on the board. This has 2MB of internal Flash. Overview of xCore-200 devices below.xCore-200 XL-Series (L = Low power - General)xCore-200 XU-Series (U = USB - adds USB PHY)xCore-200 XE-Series (E = Ethernet - adds Gigabit Ethernet and USB interface)I think it would be worth upgrading, the new kit would be adding at the very least more cores, internal flash, USB and Ethenet.The xCORE-200 explorer kit is the only "general purpose" XMOS kit at the moment, but I believe their newxcore.aikit will be out very soon.xcore.ai is a new extension of xCore-200 being released soon:https://www.xmos.com/xmos-announces-worlds-lowest-cost-most-flexible-ai-processor/

author: Berni
author_rank: Super Contributor
timestamp: August 22, 2020, 04:13:42 pm
content: Oh yeah these are very old indeed. Pretty much the first xmos chips.A lot has happened in that time and you probably want to go for the newer chips anyway. If nothing else due to having more memory. The fact that RAM is used for both code and data really eats up the 64KB in those old chips quickly.The problem these xmos chips have is that they are more of a solution that is searching for a problem. The architecture and what they do is pretty cool but they haven't really found any application where they are that much better than a generic moderm MCU. The USB audio stuff is just one thing that seamed to take off for them due to being one of the rare turnkey solutions for USB async audio.

author: EverydayMuffin
author_rank: Regular Contributor
timestamp: August 22, 2020, 04:29:25 pm
content: Quote from: Berni on August 22, 2020, 04:13:42 pmI think XMOS parts are a good fit for applications where FPGAs with DSP blocks would traditionally be used. Audio being the main one for sure.It will be interesting to see how well the new part does.

author: tggzzz
author_rank: Super Contributor
timestamp: August 22, 2020, 04:52:29 pm
content: Whether or not xCORE devices are worth learning and trying depends on your objectives.If you want to get a device on your CV that will fit HR-droids filters, there are better chips. OTOH, having xCORE on my CVwouldhave helped me get the best two jobs I had, because those employers were looking for people that pushed the boundaries, didn't accept the status quo, and tried things on their own because they liked the subject.If guaranteedby designtiming 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. Caveat: if your timing requirements are simple and/or the MCU is grossly underutilised, then traditional MCUs may be acceptable.I found I didn't spend much time on the boring bits, such as initialising the devices to do what I needed. The peripherals are well designed and integrated with the software, so initialising them was trivial. There were no unpleasant corner cases nor interactions nor errata; they just worked first time.If you want realtime programming to be fun again, or you want to change (for the better!) the way you think of implementations, then xCORE devices are the way to goAs to what to use? I'd look to see what DigiKey stocks.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 25, 2020, 10:30:26 pm
content: Quote from: tggzzz on August 22, 2020, 04:52:29 pmThis is strictly hobby for me. Having XMOS on my CV wouldn't gain me anything at this point in my career.QuoteYep, which is why I use FPGAs when I need guaranteed timing.QuoteGood to know.QuoteI'm looking for a change of pace (from MCUs and FPGAs), so XMOS seems like it fits the bill.QuoteI've ordered the xCORE-200 explorer kit, which seems like their only general-purpose board.

author: b_force
author_rank: Super Contributor
timestamp: August 25, 2020, 10:39:26 pm
content: From an audio point of view, the latest state is that it's really difficult and pricey to get a licence for working drivers.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 25, 2020, 11:00:34 pm
content: Quote from: b_force on August 25, 2020, 10:39:26 pmI don't care about that. Since this is just a hobby for me, I write all my own code and don't rely on vendor libraries or drivers.

author: tggzzz
author_rank: Super Contributor
timestamp: August 25, 2020, 11:23:25 pm
content: Quote from: Sal Ammoniac on August 25, 2020, 10:30:26 pmSounds like you are going to have fun - which is the main point of lifeYou can get guaranteed timing with XMOS. For example I used it to count the transitions in two 62.5Mb/s datastreams (plus front panel plus USB comms). The xTimeComposer was able to examine the optimised binaries and define that there was sufficient time to do that.The "XMOS Programming Guide" is excellent, as is "Introduction to XS1 Ports", and then there is the reference stuff.The main point is to get used to "thinking parallel" at the right granularity, and thinking in CSP. I prefer to use the conventional synchronous message passing for the forward-flow data, and the asynchronous variant for reverse flow and/or control information. But I'm sure you will evolve your own style.

author: Bassman59
author_rank: Super Contributor
timestamp: August 26, 2020, 03:47:15 am
content: Quote from: b_force on August 25, 2020, 10:39:26 pmWindows 10finallyadded support for USB Audio Class 2.0, more than ten years after macOS and Linux did so. So I don't think you need to pay for the Thesycon drivers any more.

author: Berni
author_rank: Super Contributor
timestamp: August 26, 2020, 05:03:10 am
content: Quote from: Bassman59 on August 26, 2020, 03:47:15 amOh nice. That one was about time.Its really the way USB sound cards should have been designed in the first place.

author: b_force
author_rank: Super Contributor
timestamp: August 26, 2020, 11:50:57 am
content: Quote from: Bassman59 on August 26, 2020, 03:47:15 amSince when is this?Because just only a couple of years ago this was really a MAJOR issue getting USB 2 audio interfaces working.Especially at higher samplerates and bitrates.These licenses were easily 20k in total and somethines like 2k per year per license or something.(I forgot the exact numbers).I haven been looking for ages for a solution to develop something myself, but these costs were just way to steep.

author: Bassman59
author_rank: Super Contributor
timestamp: August 28, 2020, 04:51:57 pm
content: Quote from: b_force on August 26, 2020, 11:50:57 amActually,about three years ago(though I don't use Windows for audio at all so this is just of academic interest for me). But yeah, there is no reason why it took Microsoft TEN FUCKING YEARS to support a standard USB class definition, one which was adopted by the other two major operating systems almost immediately.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 28, 2020, 11:24:29 pm
content: 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...

author: EverydayMuffin
author_rank: Regular Contributor
timestamp: August 28, 2020, 11:41:25 pm
content: Quote from: Sal Ammoniac on August 28, 2020, 11:24:29 pmCheck out XCore Exchange:https://www.xcore.com/

author: maginnovision
author_rank: Super Contributor
timestamp: August 29, 2020, 08:12:38 pm
content: I don't think there are any good ACTIVE forums. The xcore ones are ok but it's usually new people asking the same old questions over and over so not too many people respond(with useful information). I'm not typically asking questions though I just check in to see if I can answer any interesting questions that nobody else had.

author: tggzzz
author_rank: Super Contributor
timestamp: August 29, 2020, 09:28:51 pm
content: Quote from: maginnovision on August 29, 2020, 08:12:38 pmI found I didn't need to use the forums very much. In my experience the core hardware, software, and toolset worked as expected from the blissfully short documentation. They "just did what they said on the tin" - which is unusual for complex microprocessors and software. Overall that gobsmacked me, in a good wayCaveat: I did not have to use any major libraries, except the debugging ones.

author: maginnovision
author_rank: Super Contributor
timestamp: August 29, 2020, 10:45:36 pm
content: Early on I found multiple compiler bugs and massive library issues I helped them fix, and this is for the newer tools. Libraries usually got fixed the very next version(as expected when you give them the fix). Compiler bugs though... The compiler is rough, imo, and still has multiple bugs and issues with some of the tools Xc gives you.

author: tggzzz
author_rank: Super Contributor
timestamp: August 30, 2020, 07:12:18 am
content: Quote from: maginnovision on August 29, 2020, 10:45:36 pmWhat do you mean by "early on"? 2009?Can you give us a clue as to the kind of bugs and how they were visible. URL pointers are fine.

author: maginnovision
author_rank: Super Contributor
timestamp: August 30, 2020, 03:07:00 pm
content: There are no URL's as I was working with their teams over email. I'm talking from ~2014-2018, maybe 2019(just checked and last installed version of tools is 14.3.3 but most used is 14.2.4). I've stopped updating the tools to avoid new issues as the projects are quite large and it's not worth the time to fix everything that breaks, especially when we've already got work arounds built-in. Almost all of the issues were with things like notifications, direct data transfers between cores across tiles, library issues for protocols causing them not to function properly in MOST cases(violating actual specifications), issues with ordering selects, combining threads on cores, manual assignment of cores on tiles. Typically compiler issues kill the linker, sometimes it is the linker. They usually didn't fix the issues, they wouldn't add errata to tools release notes. They did fix a couple, but mostly not. If you report the bug they'll say thanks and if someone has given one they'll tell you a workaround. I may be forgetting some things but it's not important. If you don't run into the issues it doesn't affect you.I'm not trying to badmouth them I like using their chips but I always hear there are no problems and I know it's not true. It's my go to for any chip where multiple threads makes things easy or I need guaranteed timing(never used arm cortex-r parts though). I already know the workarounds and I'm pretty good about figuring out where things are going wrong and creating a new one. They have been pushing further and further away from the problematic areas of their tools in the way they market the chips and to whom they market them.I can say some of their guys are pretty good though. When I asked Henk Muller to update the fixed point library to include another trig function it didn't take him to long to add it and it worked well for me. The individuals there are mostly pretty good people.

author: tggzzz
author_rank: Super Contributor
timestamp: August 30, 2020, 03:18:18 pm
content: Useful counterpoints; thanks.The "if you don't run into the issues it doesn't affect you" coupled with "I haven't seen that happen therefore there is no problem" syndrome should never be underestimated!

author: Berni
author_rank: Super Contributor
timestamp: August 31, 2020, 05:14:10 am
content: Yep i also ran into some bugs in the compiler before. Usually the bugs happened in connection to the xcore features like the special IO or core communication. This sometimes made it difficult to hunt down because i was not sure if im just not using it right or if it is actually a bug.I don't really use these xmos chips anymore. Most of the things i do are just fine with a regular MCU, especially with how powerful the new ARM Cortex based MCUs are getting. If the thing is too weird or fast for a MCU then a FPGA takes care of it.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: September 01, 2020, 12:17:19 am
content: Quote from: Berni on August 31, 2020, 05:14:10 amThat's pretty much my conclusion too. XMOS is a solution looking for a problem, IMO.

author: b_force
author_rank: Super Contributor
timestamp: September 02, 2020, 11:38:04 am
content: Well, unfortunately, there aren't many alternatives either.C-Media looks promising on paper, but their support, technical help and even simple communication is horrible.Basically non-exciting, unless you pull out a wallet to order at least 5000 pcs or so.

author: nudge
author_rank: Contributor
timestamp: September 13, 2020, 10:31:03 pm
content: I see XMOS turning up more and more in consumer/prosumer audio interfaces like from Focusrite and MOTU, most likely because they can throw in a chip and get class complaint usb audio up and running.

author: Berni
author_rank: Super Contributor
timestamp: September 14, 2020, 05:18:59 am
content: 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.

author: 0db
author_rank: Frequent Contributor
timestamp: September 14, 2020, 09:56:35 am
content: Quote from: tggzzz on August 22, 2020, 04:52:29 pmI 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?

author: tggzzz
author_rank: Super Contributor
timestamp: September 14, 2020, 11:11:55 am
content: 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.

author: maginnovision
author_rank: Super Contributor
timestamp: September 14, 2020, 04:01:27 pm
content: Quote from: Berni on September 14, 2020, 05:18:59 amWith 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.

author: b_force
author_rank: Super Contributor
timestamp: September 17, 2020, 02:11:26 pm
content: Quote from: maginnovision on September 14, 2020, 04:01:27 pmI 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.

author: tggzzz
author_rank: Super Contributor
timestamp: September 17, 2020, 02:25:57 pm
content: Quote from: b_force on September 17, 2020, 02:11:26 pmWhat 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.

author: 0db
author_rank: Frequent Contributor
timestamp: September 17, 2020, 08:12:30 pm
content: Quote from: tggzzz on September 17, 2020, 02:25:57 pmI 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.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: September 17, 2020, 08:34:02 pm
content: Quote from: 0db on September 17, 2020, 08:12:30 pmPeople have been predicting that things would be massively parallel in ten years for the last 60 years now.

author: b_force
author_rank: Super Contributor
timestamp: September 17, 2020, 10:13:15 pm
content: Quote from: tggzzz on September 17, 2020, 02:25:57 pmThat 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?

author: 0db
author_rank: Frequent Contributor
timestamp: September 17, 2020, 10:46:36 pm
content: Quote from: Sal Ammoniac on September 17, 2020, 08:34:02 pmJust 10 years ago the deep learning was as powerful as it's nowadays. That's because nowadays we already have massively parallel devices. TheFujitsu AFX64is a good "small" new example. It has "just" 84-core 64-bit ARM processors, while the oldEpiphany-V/1024had "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.

author: tggzzz
author_rank: Super Contributor
timestamp: September 18, 2020, 08:36:19 am
content: Quote from: Sal Ammoniac on September 17, 2020, 08:34:02 pmPartly 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.

author: tggzzz
author_rank: Super Contributor
timestamp: September 18, 2020, 08:44:12 am
content: Quote from: b_force on September 17, 2020, 10:13:15 pmParallel 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.

author: Leo Bodnar
author_rank: Frequent Contributor
timestamp: September 18, 2020, 01:56:34 pm
content: 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.LeoQuote from: Sal Ammoniac on August 28, 2020, 11:24:29 pm

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: September 18, 2020, 04:17:10 pm
content: Quote from: Leo Bodnar on September 18, 2020, 01:56:34 pmAre you kidding? 1/3 of XMOS's employees are executives? How can that work, and how can that be sustainable?QuoteYou'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.

author: tggzzz
author_rank: Super Contributor
timestamp: September 18, 2020, 04:43:26 pm
content: Formal company information ishttps://beta.companieshouse.gov.uk/company/05494985/filing-history

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: September 18, 2020, 05:06:49 pm
content: Quote from: tggzzz on September 18, 2020, 04:43:26 pmInteresting reading some of that. I didn't know Xilinx had such a big investment in XMOS.

author: tggzzz
author_rank: Super Contributor
timestamp: September 18, 2020, 05:12:51 pm
content: Quote from: Sal Ammoniac on September 18, 2020, 05:06:49 pmYes. 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.

author: Leo Bodnar
author_rank: Frequent Contributor
timestamp: September 18, 2020, 08:40:24 pm
content: 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.comLeo

author: maginnovision
author_rank: Super Contributor
timestamp: September 19, 2020, 03:17:04 am
content: 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.

author: Leo Bodnar
author_rank: Frequent Contributor
timestamp: September 19, 2020, 08:33:52 am
content: Quote from: maginnovision on September 19, 2020, 03:17:04 amI 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

author: tggzzz
author_rank: Super Contributor
timestamp: September 19, 2020, 09:23:10 am
content: Quote from: Leo Bodnar on September 18, 2020, 08:40:24 pmThe key advantage is not the hardware (although the io structures are very neat powerful and simple like an FPGA), but is thesoftware 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.

author: tggzzz
author_rank: Super Contributor
timestamp: September 19, 2020, 09:27:31 am
content: Quote from: Leo Bodnar on September 19, 2020, 08:33:52 amI had zero problems provided I used the timers in each io port.QuoteThat causes me a little concern too.

author: Berni
author_rank: Super Contributor
timestamp: September 19, 2020, 09:51:56 am
content: Quote from: maginnovision on September 19, 2020, 03:17:04 amThe 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.

author: Leo Bodnar
author_rank: Frequent Contributor
timestamp: September 19, 2020, 10:33:21 am
content: Quote from: tggzzz on September 19, 2020, 09:23:10 amYes, 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

author: tggzzz
author_rank: Super Contributor
timestamp: September 19, 2020, 11:29:50 am
content: Quote from: Berni on September 19, 2020, 09:51:56 amEach 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 toguaranteeperformance - 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

author: tggzzz
author_rank: Super Contributor
timestamp: September 19, 2020, 11:34:12 am
content: Quote from: Leo Bodnar on September 19, 2020, 10:33:21 amIt is entirely unsurprising that a small startup creates general purpose technology and then focusses on whoever finds a specific niche for it.Ditto for pivoting to another area where they feel they could have a significant unique advantage.It is unclear to me whether they are abandoning the core xC ecosystem, or whether it is still there under a veneer of libraries.

author: Leo Bodnar
author_rank: Frequent Contributor
timestamp: September 19, 2020, 11:40:52 am
content: Quote from: tggzzz on September 19, 2020, 11:34:12 amAnecdotally, one of their top brass privately commented that they are committed to keeping xCORE-200 line for the next 10 years but I don't trust anybody in this industry - especially executives. And 10 years is nothing for a good, successful product.If you mean xC as in development tool, I fully expect somebody will replace it with an interactive IDE where you drag jelly bean coloured blocks strung together with animated pipes.Leo

author: tggzzz
author_rank: Super Contributor
timestamp: September 19, 2020, 12:52:50 pm
content: Quote from: Leo Bodnar on September 19, 2020, 11:40:52 amSnort!Has software by pictures ever been successful? Yes pictures can be OK as a top level block diagram, e.g. FSMs, but for the nitty gritty tests and actions text is normally better.Yes, people have created drag-and-drool Lego stuff, but then it is used by people that cannot program in any language

author: nfmax
author_rank: Super Contributor
timestamp: September 19, 2020, 04:21:41 pm
content: Quote from: tggzzz on September 19, 2020, 12:52:50 pmYes: look at Node-RED (https://nodered.org/) for an example. It doesn't try to do everything (though it can) but the paradigm of messages flowing through pipelines of nodes, each performing a specific operation, is fruitful.

author: Berni
author_rank: Super Contributor
timestamp: September 19, 2020, 04:52:28 pm
content: Quote from: tggzzz on September 19, 2020, 12:52:50 pmSuccessful graphical programing languages? Yep there are quite a few actually.For example:-LabView: the license costs a few grand per year or a few tens of grand for a permanent license and a lot of people use it (Tho its mostly academic and research type of stuff)-Matlabs Simulink: Also very expensive, yet still popular (tho mostly because its free for academic)-Shader programing: Every major piece of software dealing with high end graphics has some form of graphical node based shader language, Be it artistic 3D moderling such as Blender or popular game engines such as Unity, UnrealEngine, Godot..etc-Animation state machines: Also used in 3D software and game engines for automating animation transitions-UnrealEngine Blueprints: Used as the primary way of programing in one of the biggest game engines on the market. Behind the scenes its just getting translated back to C++ (And can use user written C++ functions) but the workflow puts the blueprint workflow in the spotlight as the primary way of doing things.-Industrial PLCs: Every PLC vendor out there has a graphical language of some sort. Essentially all of them supporting ladder diagrams, but some also have more data flow based block diagrams.-NodeRed: As mentioned above, it is a reasonably well known browser based scripting engine, fits well into the IOT stuff.I don't always like these graphical programing things, but they are out there and they are indeed popular too.

author: tggzzz
author_rank: Super Contributor
timestamp: September 20, 2020, 08:51:38 am
content: Quote from: nfmax on September 19, 2020, 04:21:41 pmAt a very quick look, it looks like it is graphical at the level of FSM languages. It is graphical in terms of top level blocks, but all the useful stuff is done in a range of other text based languages.I'm not sure how you would do fundamental operations like multiplexing (nodes have only one input) nor iteration.

author: tggzzz
author_rank: Super Contributor
timestamp: September 20, 2020, 09:06:49 am
content: Quote from: Berni on September 19, 2020, 04:52:28 pmIs Minecraft a graphical programming language? I've heard it is Turing completeI had forgotten about PLC ladder logic, never having used them. Can they express unbounded iteration? ISTR there being some unpleasant hacks to sort-of enable advanced concepts like subroutines.I've used some of the simulation languages, and they are top level block diagrams where the processing is done in C/C++. To me that is syntactic sugar like FSM diagramming languages. Nobody thinks Harel Statecharts are a programming language.It looks like you are right about LabView. It had changed a lot since I first glanced at it decades ago. I suspect HP's VEE is similar.I'm completely unfamiliar with gaming environments, and it will stay that way

author: Berni
author_rank: Super Contributor
timestamp: September 20, 2020, 11:19:57 am
content: Quote from: tggzzz on September 20, 2020, 09:06:49 amI never said that these graphical programing languages are actually any good. I hate most of them in at least some way.None the less they are languages that are sold for prices of a decent used car and/or have user bases counting into the millions. So id argue that they do count as being "successful languages", so apparently there are a lot of people out there that do like them.Those PLC ladder diagrams are particularly high up my hate list. They have hacky ways of making them do all sorts of things due to allowing a sort of "assembler instruction inlining". That makes it into even more of a horrible unreadable mess, but again pretty much every industrial automation technician knows them and many among them use it to program stuff.Minecrafts redstone mechanic could indeed be seen as a primitive graphical HDL language. But lets be honest when have you ever seen a fully graphically based HDL that actually was useful and productive? (AltiumDesigners FPGA tools was pretty close actually until new management came along shitcanned the feature)That being said some of the languages on my list i actually see being more productive versus classical coding. For example Matlab Simulink does make sense in visualizing how signals flow from one thing to the next since it is tailored to work very much like signal processing. I also see shader graphs as a sensible language for programming GPUs since those things tend to have a very signal processing like structure (like simulink) and so a node graph is clearer than just passing things in chains from function to function. Combine that with the typical say Blender(or other <insert other artistic 3D tool>) user that might just be a visual effects artist working on a movie CGI render, so they have no idea what coding even is, nor anyone on the team that knows it (like perhaps a game development studio might have)

author: Leo Bodnar
author_rank: Frequent Contributor
timestamp: September 20, 2020, 12:42:14 pm
content: All languages have their place but a lot of them are raving solutions looking for a problem that is easily solved without them.You can probably use classical ballet to propose to a swan but it's not too useful to explain your car mechanic what's wrong with the gearbox.Leo

author: nfmax
author_rank: Super Contributor
timestamp: September 20, 2020, 07:15:27 pm
content: Quote from: tggzzz on September 20, 2020, 08:51:38 amMultiplexing - just wire your multiple message-sourcing nodes to the processing node input. Each message is handled independently. If you want to combine a message from node 'A' with one from node 'B', then you may be able to use a special-purpose aggregator node, e.g.https://flows.nodered.org/node/node-red-contrib-msg-aggregator. Otherwise you could write some Javascript yourself (in a function node) and remember messages using context variables.Iteration is generally implicit. The processing flow repeats for each new input message, so the implicit unbounded iterator is the underlying NodeJS event loop. If you want something to happen at regular intervals, start a flow with an inject node or similar, set to the required time interval. Where appropriate, some nodes have internal bounded iterators: they may generate one message for each line of a text file, or for each row of a database query result.You can write any sort of loop you like in a function node, but beware it will block the event loop while it executes.

author: tggzzz
author_rank: Super Contributor
timestamp: September 20, 2020, 08:30:16 pm
content: Quote from: Berni on September 20, 2020, 11:19:57 amI find it hard to argue with that(I ought to declare that I became beguiled by the possibilities of graphical programming back in 1985 after playing with the first Macs. I even tried to find a way of creating a product which could have ended up like Vizio or perhaps LabView, but I couldn't find a way to finance it. Oh wellI've continued to keep an eye out for graphical languages since then, with little success)Certainly some problems are inherently dataflow oriented, and those ought to map well onto "schematics". By "schematics" I mean top-level blocks connected by wires along which signals flow.I'm trying to remember which comms simulation system I looked at >25 years ago. It might have been Comdisco or Matlab. In the end it was faster for me to simply code up my problems without the learning curve associated with the Big Tools.I do remember that any "interesting" special purpose algorithms relevant to your problem domain had to be coded as C functions inside a wrapper/block. Conceptually obvious, but sensibly indicating that graphics were the wrong tool. The LabView technique seems too low level for all but simple automation (shades of COBOL's "add a to b giving c"!)PLC ladder diagrams are a good example of a hammer; excellent at theirspecialisedjob, but bloody awkward when you need a screwdriver. Most languages of all types end up becoming foul messes over the decades.In the early 90s I watched a team try to automate going from SDL specifications to code. They spent far too much time farting around with the pretty pixels in C++, when they could easily have accomplished that task in Smalltalk. The nice pretty pixels were also annotated with the usual foul C++ required to implement the actions and event processing.

author: Berni
author_rank: Super Contributor
timestamp: September 21, 2020, 08:23:12 am
content: Yeah a lot of times graphical programing-ish solutions are shoehorned into solutions that they don't fit into.One of the places it does fit into in my opinion however is HDL stuff, but again as a hybrid graphical thing. I would never want to program a FPGA with 100% graphical schematics, but writing blocks of HDL code in the usual stuff like Verilog/VHDL and then connecting those blocks together on a schematic would be nice. The top level file in most FPGA designs tends to be just a bunch of modules that are connected together in various ways with perhaps a gentle sprinkling of logic (like a NOT gate to flip a signal or some OR to join a bus together). Looking at this as a schematic makes more sense than reading trough the code. You can instantly see what blocks connects to what else in what way rather than hunting down a signal name trough the code.Yes i know this already exists in all the FPGA tools of the major vendors, but the UI is so horrendously bad that it negates any benifit. They all have some of the worst 90s UI design that takes way to many clicks to do things in the most ununtuitive ways possible. As a result i rather just write code instead, then if i want to see it graphically (because i forgot how an old design is done, or i want to sanity check my code) then i just compile it and open the synthesis results in the schematic view. But i could totally see myself using the schematic entry for the top level design file if i could simply drag *.v files into the schematic, have them appear as a block, easily rearrange the pins by just dragging them around and then connect pins with one click at each end. It would allow me to arrange my top level design in 2D in a nice way, better than just 1D code line numbers can. This way you get the strengths of a schematic to clearly show connections between things at a glance, but keeping the coding for the parts its more suited for like describing long windy algorithms with many branches and loops.Sorry for taking things a bit off topic.But yeah multithreaded programming is indeed difficult, but some graphical language is probably not the solution to making it easy.

author: tggzzz
author_rank: Super Contributor
timestamp: September 21, 2020, 11:08:06 am
content: Again we are in violent agreement.The top level HDL argument can also be applied to some enterprise-level software, which is multiple blobs (e.g. micro services) glued together.Ditto telecoms systems, where the blobs are usually defined in terms of FSMs, and implemented as FSMs in whatever language and environment is convenient.Choose whatever programming patterns match the specification patterns, so that the correspondence between the two is clear and simple.