Multi Microcontroller design.

[thm_w]

Yet strangely, I have very similar goals. One of my goals is also to be able to depend on very common, second-sourceable, popular parts and take them to their limits. Minimizing BOM line count and BOM cost, making the MCU do whatever it can. Implement a DC/DC controller with software to save a $2 DC/DC controller IC when the MCU is there anyway for other tasks. For microcontroller cores, I default to ARM very much thank you, but that's only for highly practical reasons.

Second sourceable outside the of the MCU itself right?

[Siwastaja]

Second sourceable outside the of the MCU itself right?

No, I mean, if the shit really hits fan so that an STM32 Cortex-M7 MCU isn't available (which is, of course, quite remote possibility, given the designer has done due diligence and not picked a NRND STM32 part), it isn't disastrous for the project to change to an NXP Cortex-M7 part instead. There will be minor PCB layout changes, and maybe 1-5% of the codebase (for a typical say 10000 LoC embedded project) changes, but it's far from a complete redo of the project. This is because many things keep the same, including the ARM core and all software development tools. The MCU peripherals are different, but often not that much different (again, similar design philosophy is seen in most ARM microcontrollers), and for the more complex peripherals, you had them hopefully abstracted behind low-level drivers. You write some low-level peripheral access parts again.

As a contrast, if the design relies on the XCORE philosophy, there is no competition, which seems good for their business, but you have no options but to redesign from scratch if, for any reason, XCORE becomes unusable. Not that this is a high probability, just sayin'.

What I really want to see is the XCORE philosophy becoming a more standard way of thinking. This includes harsh competition. As long as it's a special snowflake, I'm only interested when I absolutely must use it and have no other options. I think many designers think the same way, and see the appeal of getting the job done using the most industry-standard ways available.

[tggzzz]

As a contrast, if the design relies on the XCORE philosophy, there is no competition, which seems good for their business, but you have no options but to redesign from scratch if, for any reason, XCORE becomes unusable. Not that this is a high probability, just sayin'.

What I really want to see is the XCORE philosophy becoming a more standard way of thinking. This includes harsh competition. As long as it's a special snowflake, I'm only interested when I absolutely must use it and have no other options. I think many designers think the same way, and see the appeal of getting the job done using the most industry-standard ways available.

Yes indeed, except I also want to see improvements in the multicore programming arena.

The main theoretical abstraction underlying Occam/Transputer and cC/xCORE is Hoare's CSP from the mid 70s. Some of those concepts appear in other places, e.g. Go and Rust both use CSP/xC style channels for comms.

[klmbk]

A somewhat related question, though at its core it might be more of an analog question:

Suppose I want to drive multiple DAC chips over RS-485, with one twisted pair (or differential pair trace) per DAC chip coming out of a bigger MCU or CPU, the sample data is packetized and is unpacked and buffered on the receiving end by a small MCUs before the DAC, and clocked out of the MCUs into the DACs by the DAC clock (shared among all DACs.)

Suppose that data synchronization just works all perfect, but optimizing for EMI is very important. Question is, should I care about synchronizing the main clocks of the small MCUs around the DACs instead of just letting them run freely on their own internal clocks? Would that be of any benefit for EMI?

[Siwastaja]

Suppose that data synchronization just works all perfect, but optimizing for EMI is very important. Question is, should I care about synchronizing the main clocks of the small MCUs around the DACs instead of just letting them run freely on their own internal clocks? Would that be of any benefit for EMI?

Free-running should yield better EMI performance, because now the clocks (and the related power supply spikes, and synchronous DAC output updates) and their harmonics are at a bit different frequencies (spread spectrum), and thus, the peaks are lower. And the peaks are being measured at the lab.

However, in theory, you could get unlucky and they might all accidentally run at close enough frequencies, in sync, so that the peaks are there after all. Syncing them to begin with would make the result more consistent between units and environmental variations.

Running all those clock lines, though, would be a huge possible source of extra radiation.

[SiliconWizard]

Running all those clock lines, though, would be a huge possible source of extra radiation.

Yeah. If you need that for sync reasons, well, that's one thing. But that sure could be only worse as far as EMI is concerned.

[tggzzz]

A somewhat related question, though at its core it might be more of an analog question:

Suppose I want to drive multiple DAC chips over RS-485, with one twisted pair (or differential pair trace) per DAC chip coming out of a bigger MCU or CPU, the sample data is packetized and is unpacked and buffered on the receiving end by a small MCUs before the DAC, and clocked out of the MCUs into the DACs by the DAC clock (shared among all DACs.)

Suppose that data synchronization just works all perfect, but optimizing for EMI is very important. Question is, should I care about synchronizing the main clocks of the small MCUs around the DACs instead of just letting them run freely on their own internal clocks? Would that be of any benefit for EMI?

You should consider starting a thread about that. Benefits:

• it won't be buried and a "distraction" in this thread
• more people will see it, so you have a better chance of getting a solid answer
• other people can find it in the future, either by browsing or searching

What's not to like about that

I would suggest this subforum: https://www.eevblog.com/forum/projects/ but EMI/EMC might be found in https://www.eevblog.com/forum/rf-microwave/ Have a look and make your choice - but
don't double post in both places!

[SiliconWizard]

As a contrast, if the design relies on the XCORE philosophy, there is no competition, which seems good for their business, but you have no options but to redesign from scratch if, for any reason, XCORE becomes unusable. Not that this is a high probability, just sayin'.

Yes, that was also my point which I already stated a while ago... and one of the main reasons I never used xCore in any project so far.

That's a shame though, as the architecture makes writing real-time software easier, and MUCH easier to validate IMO. That sure would be interesting to see similar architectures appearing in more common MCUs/CPUs. As said above, it's not that much that you can write cycle-accurate software (although it can be a benefit in some cases, in which you may otherwise have to take an hybrid MCU-FPGA approach, or FPGA only with a soft core), but most of all that you can write provably correct software (at least timing-wise.)

[tggzzz]

That's a shame though, as the architecture makes writing real-time software easier, and MUCH easier to validate IMO. That sure would be interesting to see similar architectures appearing in more common MCUs/CPUs. As said above, it's not that much that you can write cycle-accurate software (although it can be a benefit in some cases, in which you may otherwise have to take an hybrid MCU-FPGA approach, or FPGA only with a soft core), but most of all that you can write provably correct software (at least timing-wise.)

Yes indeed. Propagation of the concepts and improvement of the concepts will benefit all.

For that to happen people have to realise that C + single-core MCU was fine in the 80s[1], but is creaking at the seams now and definitely won't be sufficient in the future. They need to realise that there are already alternatives that are better in some respects.

Knowing what one tool can do better often alert you to the deficiencies of other tools.

[1] when returning to this area after a quarter of a century, I was horrified at how little fundamentally new things I needed to learn. Smaller, cheaper, faster != new and different

[SiliconWizard]

Yeah, no breakthrough really. Yes parts (and dev tools) are cheaper, have more memory, are faster (sometimes hugely), and draw less power. That's not too shabby, but those are more incremental changes than true innovations.

[nctnico]

As a contrast, if the design relies on the XCORE philosophy, there is no competition, which seems good for their business, but you have no options but to redesign from scratch if, for any reason, XCORE becomes unusable. Not that this is a high probability, just sayin'.

Yes, that was also my point which I already stated a while ago... and one of the main reasons I never used xCore in any project so far.

That's a shame though, as the architecture makes writing real-time software easier, and MUCH easier to validate IMO. That sure would be interesting to see similar architectures appearing in more common MCUs/CPUs. As said above, it's not that much that you can write cycle-accurate software (although it can be a benefit in some cases, in which you may otherwise have to take an hybrid MCU-FPGA approach, or FPGA only with a soft core), but most of all that you can write provably correct software (at least timing-wise.)

There are many multi-core microcontrollers on the market today. Also SoCs tend to come with hardware virtualisation and microcontrollers built in nowadays. That way you can physically seperate generic and hard realtime tasks. At some point throwing more processors at a task even becomes counter productive because you also have to prove the system as a whole meets the realtime & safety requirements.

[tggzzz]

Yeah, no breakthrough really. Yes parts (and dev tools) are cheaper, have more memory, are faster (sometimes hugely), and draw less power. That's not too shabby, but those are more incremental changes than true innovations.

Back in 1981 I was cross-compiling C on a Unix box to run via an in-circuit emulator in a 8-bit processor. Fast forward 35 years, and I found myself doing exactly the same.

The only difference is that in 1981 the Unix box was the size of an American fridge, the Unix was a Microsoft product(!), and the setup would have cost a couple of year salary. Now it costs a couple of hours salary and fits on a desk.

Since there was no change, it didn't take me long to get up to speed

Mind you, even with the XMOS setup, that only took one day before I was running my software against external inputs, and it was working as expected at full rate. Stunningly easy.

By comparison, programming an atmega328 at the bare silicon level took much longer to get right, even though there were no fundamental surprises for me.

Basically with the atmega328 you have to fiddle with lots of bitmasks and registers, and all those are coupled/merged together in whatever way was convenient for the silicon guys. OTOH the xCORE experience is three easy orthorgonal statements to define a port's width, type (clocked, strobed, SERDES etc), clock rate. Job done

[nctnico]

Basically with the atmega328 you have to fiddle with lots of bitmasks and registers, and all those are coupled/merged together in whatever way was convenient for the silicon guys. OTOH the xCORE experience is three easy orthorgonal statements to define a port's width, type (clocked, strobed, SERDES etc), clock rate. Job done

But now you are comparing the typical low end Atmel crap to a properly engineered chip. This has nothing to do with using one or multiple cores. 

[ehughes]

I always try to keep things in a single CPU if I can.  This project does not sound like it would benefit from multiple CPUs    I found that I need something super tight,   software is the wrong place to solve the problem.    My observation over the years is that the majortity of problems that are considered "hard real time" or "timing critical" really aren't once you figure out what really matters. 

There are a couple projects where we have a verify dedicated function that is programmed into a small MCU and is used across many designs.     The firmware is locked down and we can essentially treat it as a fixed function chip.     You usually don't know you need this until you have reused it several times.   

Usually I go in this order:

1.  Try to get a peripheral or a combination of them to solve the problem.
2.  Find some sort of discrete solution that solves the problem.
3.  Use an FPGA/CPLD

I evaluated XMOS several times.  The architecture is academically interesting but burning CPU cycles to bitbang everything was over the top.  I know they added some hard peripherals in later series but just power consumption was over the top to solve pretty simple problems.    I have not found a case where a critical timing problem wouldn't be better solved with an FPGA, FPGA+CPU ,  or some combination with dedicated logic.

I personally like the idea of using standard languages and tools (Verilog, etc) to design critical logic.    It is so much easier to write 100% covereage tests.

I think they carved out a niche in Audio which seemed like an OK fit.    The only argument of an XMOS might be cost but that never is anywhere near the top of priorities when you have a timing critical application.      Your engineering/test/compliance costs dwarf chip cost is most cases.     

[SiliconWizard]

As a contrast, if the design relies on the XCORE philosophy, there is no competition, which seems good for their business, but you have no options but to redesign from scratch if, for any reason, XCORE becomes unusable. Not that this is a high probability, just sayin'.

Yes, that was also my point which I already stated a while ago... and one of the main reasons I never used xCore in any project so far.

That's a shame though, as the architecture makes writing real-time software easier, and MUCH easier to validate IMO. That sure would be interesting to see similar architectures appearing in more common MCUs/CPUs. As said above, it's not that much that you can write cycle-accurate software (although it can be a benefit in some cases, in which you may otherwise have to take an hybrid MCU-FPGA approach, or FPGA only with a soft core), but most of all that you can write provably correct software (at least timing-wise.)

There are many multi-core microcontrollers on the market today. Also SoCs tend to come with hardware virtualisation and microcontrollers built in nowadays. That way you can physically seperate generic and hard realtime tasks. At some point throwing more processors at a task even becomes counter productive because you also have to prove the system as a whole meets the realtime & safety requirements.

I think you just missed the point we were just discussing above (with xCore as an example). Or maybe I missed the point you were just trying to make here.
Multi-core MCUs are just traditional architectured MCUs with a bunch of classic cores, and yes, properly using them comes with difficulties and limitations, and that's where alternative multi-core architectures could come in handy.

[tggzzz]

I evaluated XMOS several times.  The architecture is academically interesting but burning CPU cycles to bitbang everything was over the top. 

You don't bitbang everything. The port options include all the standard classes (except for UART) up to and including 250Mb/s SERDES.

I know they added some hard peripherals in later series but just power consumption was over the top to solve pretty simple problems.

You don't waste power. If a core is waiting to do something, it sleeps and doesn't use any power. Waiting includes waiting for any/all of a message, i/o, timeout or until a particular input is == or != a specified value. The latter allows "idle signals" to be ignored.

I have not found a case where a critical timing problem wouldn't be better solved with an FPGA, FPGA+CPU ,  or some combination with dedicated logic.

The FPGA plus tightly coupled CPU (e.g. the Zynq devices) are powerful and sufficient in many cases. The development ecosystem and toolset has a very steep learning curve, much more so than the XMOS toolset.

If timing was only a hardware issue, I would completely agree.

In hard realtime systems the issue is proving the hardware+software system timing constraints are met. That is much more difficult, and XMOS is the only game in town there. No, "suck-t-and-see-and-hope measurements" aren't sufficient.

Within some obvious limitiations, the XMOS ecosystem is also the best story w.r.t. multicore/multasking systems.

[nctnico]

As a contrast, if the design relies on the XCORE philosophy, there is no competition, which seems good for their business, but you have no options but to redesign from scratch if, for any reason, XCORE becomes unusable. Not that this is a high probability, just sayin'.

Yes, that was also my point which I already stated a while ago... and one of the main reasons I never used xCore in any project so far.

That's a shame though, as the architecture makes writing real-time software easier, and MUCH easier to validate IMO. That sure would be interesting to see similar architectures appearing in more common MCUs/CPUs. As said above, it's not that much that you can write cycle-accurate software (although it can be a benefit in some cases, in which you may otherwise have to take an hybrid MCU-FPGA approach, or FPGA only with a soft core), but most of all that you can write provably correct software (at least timing-wise.)

There are many multi-core microcontrollers on the market today. Also SoCs tend to come with hardware virtualisation and microcontrollers built in nowadays. That way you can physically seperate generic and hard realtime tasks. At some point throwing more processors at a task even becomes counter productive because you also have to prove the system as a whole meets the realtime & safety requirements.

I think you just missed the point we were just discussing above (with xCore as an example). Or maybe I missed the point you were just trying to make here.
Multi-core MCUs are just traditional architectured MCUs with a bunch of classic cores, and yes, properly using them comes with difficulties and limitations, and that's where alternative multi-core architectures could come in handy.

I was responding to your statement writing real-time software easier, and MUCH easier to validate IMO.. On one hand having isolated tasks seems easier but also those isolated tasks will need to work together. If you have 20 cores (just a number) executing 20 different tasks then it will be difficult to make sure these tasks are executed in the right order. Alternatively if you use a scheduler which executes each task in a fixed order then it is much easier to prove that the tasks don't interfere in an unpredictable way. Just to outline a black & white situation without any timing requirements.

I have quite a few multi-processor projects under my belt and getting & keeping the processes to execute in the correct order is much harder then it looks at first sight. Dealing with error situations  and recovering is the hardest part.

This make me wonder that if I where to use a multi-core system with many (>10) cores I might want to aim for executing a single task in parallel.

[tggzzz]

I have quite a few multi-processor projects under my belt and getting & keeping the processes to execute in the correct order is much harder then it looks at first sight. Dealing with error situations  and recovering is the hardest part.

Yes, it isn't easy - even though it looks easy until you try it!

This make me wonder that if I where to use a multi-core system with many (>10) cores I might want to aim for executing a single task in parallel.

I'm unconvinced that would make anything easier. Different or transformed, yes - but that's not necessarily easier.

One theoretical advantage of CSP is that it has a decent mathematical pedigree, and that it can be analysed mathematically. Whether that translates into a practical advantage is a different matter.

Of course there's nothing preventing multiple CSP processes being multiplexed onto a single control flow a.k.a. thread. Hence my comment "not necessarily easier".