Yup.
Effectively there are no interrupts in xCORE processors: you simply dedicate a core to an i/o port and (if necessary) it sleeps until the input has arrived. The language has primitives indicating the clock cycle on which output will occur, or capturing the clock cycle on which input did occur.
To a useful approximation inter-core comms is the same as i/o: messages to/from other cores are identical to "messages" to/from i/o ports.
I'm far from being an expert in xCORE or xC, but it just worked as I wanted it to work, as stated in the documentation and as I would expect it to work. Stunningly pain-free, unlike other MCUs with their strange i/o config registers etc
For some application areas, that sounds really good. It reminds me of the Propeller processors (by Parallax), at least in the concept of having many cores, for easy/good embedded use.
Exactly.
Multicore hardware is trivial; multiprocessor languages and software always have been (and continue to be) the big problem. Hence I found Propellor to be uninteresting, and didn't bother to build anything with it.
A key point about xCORE/xC is the tight integration of hardware and software, just like Transputer and Occam. David May has been involved in all of that. In addition Transputer/Occam and xCORE/xC have solid theoretical roots in CSP.
You should probably inform the British Intelligence service whoever they are as this sounds like industrial espionage! I am appalled that you are even thinking of this and discussing it in a forum where EE enthusiasts gather to solve each others' problems and teach/help in the process. Unless you are a Chinese national floating the idea to gather what kind of response you could get, you should be scared. Just my opinion.
Exactly.
Multicore hardware is trivial; multiprocessor languages and software always have been (and continue to be) the big problem. Hence I found Propellor to be uninteresting, and didn't bother to build anything with it.
A key point about xCORE/xC is the tight integration of hardware and software, just like Transputer and Occam. David May has been involved in all of that. In addition Transputer/Occam and xCORE/xC have solid theoretical roots in CSP.
The thing is. Just like with mcu's bigger brothers, desktop processors. The laws of Physics, such as the speed of light (which the speed of electricity presumably (Physics can get complicated) relates to, as well as other parameters), and other practical limits, such as capacitance of real life components.
Effectively making exceeding 5 GHz (exact limit debatable, maybe 6 or 7 GHz, would be a better figure here, so please take this value as approximate), without spending huge amounts of money, needing crazy amounts of power, and almost impractical cooling solutions. Ever harder.
I wouldn't want to give it a hard limit. yes you can do 5.1 GHz, and 5.2 GHz etc.
But, we are reaching the practical limits, of existing production technologies (we are at around 7nm as regards production/ and existing sales, but 5nm is coming and probably smaller still).
So, going parallel. Seems to be the logical (excuse the pun) way forward.
That is what AMD are doing with their newer ranges of Ryzen processors. With an amazing 64 core desktop/workstation cpu (hugely expensive though (around £4K, for the top one), but worth it, if you need the horse power, such as high end content creators). Even 128 cores, by going for a pair of server cpus.
Also, graphics processors, have also gone this route. Depending on how you count them, with potentially, tens of thousands of processors (and/or threads).
So, microcontrollers in embedded systems, are going to need to go the same way, sooner or later.
Because of the potential power savings, of running a large number of cores at lower frequencies. That can also be another reason, as some embedded systems can't produce much heat (fan not allowed, impracticable and/or too unreliable), and may need to use little power, because of needing to run off batteries.
Someone seems to have stolen your thread.
https://www.ukbusinessforums.co.uk/threads/great-idea-for-chinese-importation-business.404674/
The fundamental limits are the speed of light (i.e. latency) and heat generation. We are pushing both: compare the heat flux with that in a kettle or nuclear reactor, and the time it takes a signal to get across a chip (worse: to another chiplet) with the clock period.
The AMD/intel chips (and SMP big iron) all rely on cache coherency. The messages associated with cache coherency protocols become a limiting factor: too many messages, too long latency.
There are a few techniques for not requiring cache coherency, e.g. CSP and descendents, or MapReduce etc. We need more techniques.
Cores: 2,414,592
Bicurico might be thinking of this thread which is only testimony of the drive, willpower and long term vision of treez.
The fundamental limits are the speed of light (i.e. latency) and heat generation. We are pushing both: compare the heat flux with that in a kettle or nuclear reactor, and the time it takes a signal to get across a chip (worse: to another chiplet) with the clock period.
The AMD/intel chips (and SMP big iron) all rely on cache coherency. The messages associated with cache coherency protocols become a limiting factor: too many messages, too long latency.
There are a few techniques for not requiring cache coherency, e.g. CSP and descendents, or MapReduce etc. We need more techniques.
The fundamental limits are the speed of light (i.e. latency) and heat generation. We are pushing both: compare the heat flux with that in a kettle or nuclear reactor, and the time it takes a signal to get across a chip (worse: to another chiplet) with the clock period.The speed of light is fundamental, but the heat generation we face is only a limit of current technology. The fundamental heat limits are far lower. Maybe we'll get there. Maybe we won't.
The AMD/intel chips (and SMP big iron) all rely on cache coherency. The messages associated with cache coherency protocols become a limiting factor: too many messages, too long latency.
There are a few techniques for not requiring cache coherency, e.g. CSP and descendents, or MapReduce etc. We need more techniques.People have been saying this since 2 CPUs were first applied to a single problem, and the results so far have generally been poor. We certainly need to keep working hard on this, but I wouldn't plan my future around the expectation of massive improvements.
The fundamental limits are the speed of light (i.e. latency) and heat generation. We are pushing both: compare the heat flux with that in a kettle or nuclear reactor, and the time it takes a signal to get across a chip (worse: to another chiplet) with the clock period.The speed of light is fundamental, but the heat generation we face is only a limit of current technology. The fundamental heat limits are far lower. Maybe we'll get there. Maybe we won't.If you are thinking of the energy-information equivalence, then I agree. Beyond that, my statement about heat generation is at the very least a good approximation
The fundamental limits are the speed of light (i.e. latency) and heat generation. We are pushing both: compare the heat flux with that in a kettle or nuclear reactor, and the time it takes a signal to get across a chip (worse: to another chiplet) with the clock period.The speed of light is fundamental, but the heat generation we face is only a limit of current technology. The fundamental heat limits are far lower. Maybe we'll get there. Maybe we won't.If you are thinking of the energy-information equivalence, then I agree. Beyond that, my statement about heat generation is at the very least a good approximationVacuum tubes took huge power. TTL took less. NMOS took less. CMOS took less. The power limitations we see right now are a result of the technology we currently use, and that has seen several dramatic changes, and a whole lot of refinement. Your comment really assumes the electronics industry has reached the end of the road. I find that idea too depressing to accept without reason.
Can you get fine PWM granularity (e.g. 0.1ns) with XMOS xCores (external parts are fine)? Looks like regular PWM goes down to 10ns/core, which is kinda slow. Actual PWM frequency is much lower, below 2 MHz.
...while the merit of the original post in this thread is debatable, I still think it is very impolite to hijack a thread the way you do. ...
People Who Say It Cannot Be Done Should Not Interrupt Those Who Are Doing It