Is it important if XMOS is a MCU or something else?

[Interactive_Matter]

Here in the forum there is sometimes the discussion what XMOS is and what not. Even me started one of it to understand XMOS a bit better.

But yesterday I had a enlightening discussion with some friends. We discussed the advantages of XMOS versus FPGA and CDLP. I ended up beeing the XMOS fan boy, having problems to really get my point across why I like XMOS (mostly lack of knowledge about other technologies).

But during the discussion of FPGA and CDLP programming I realized the real advantage of XMOS:

Everything you can do with XMOS you can do it better (like in faster execution speed) with FPGA & CDLP.
Everything you can do with XMOS you can do better (like in easier implementation) with MCUs.

But with XMOS you can easily mix up those implementation (even though some CDLP have integrated processors). But most important: With XMOS it is hard to make mistakes which realy destroys your program. We discussed how you have to design and implement CDLP 'programs' to get it actually up and runnning and why your program can fail if you leave out parts (due to changed timing) and so on. Something completely unknown to me working with XMOS.

With XMOS you can sketch your idea and can implement it better and better. It is quite hard to implement it in a way it is not working at all. You do not have to follow certain practices to get success - even though there are some best practices to get real fast code. In the same time you are able to implement real fast code real fast. The implementation complexity is as high as the complexity of your requirements.

So XMOS is a good mix up between an MCU and something like an FPGA (at least you can implement real rea high performance behaviour). So it makes sense to implement real high quality XC code for real fast behaviour. It also makes sense to implement high level behaviour with more high level approaches (I do not mention C++/Objective C here to not provoke anybody).

Did I understand the XMOS at the end? What do you think?

[Heater]

Interactive_Matter,

Did I understand the XMOS at the end?

Why I do believe you did.

But a few comments of course:

Everything you can do with XMOS you can do it better (like in faster execution speed) with FPGA & CDLP.

I'm not sure I agree in general.

For sure if want to implement some large and super high speed "random logic" you will probably be looking to use an FPG as the XMOS may not have the raw horse power to implement it.

Now I don't know so much about the FPGA world but what I do notice is that there is a trend to implement a CPU core on FPGA projects and surround it by the custom high speed logic. Why does that happen? Presumably because there is a lot of logic that needs to be implemented that does not need the massive speed, is more easily implemented as software running on a CPU and is more flexible.

Putting a CPU on an FPGA soaks up logic units and then needs RAM/ROM some where and the required FPGA gets bigger and bigger.

Enter XMOS, we've already got CPU cores thank you and with the timers, clocked I/O etc may well be able to cope with your random logic implemented in software as well. At a much reduced cost to boot.

Everything you can do with XMOS you can do better (like in easier implementation) with MCUs.

I'm not sure I agree in general.

The chief thing here is timing determinism. In a traditional MCU there is only one CPU and all events have to be handle with interrupt routines. Well what happens when your application has to generate something in the nature of a video signal? In needs to be fast, it's working on the limit of your execution speed, in needs to feed that stream without glitching. But then, boom, you have some other events that need handling, there goes your video timing.

With the multiple threads and multiple cores of an XMOS these things can be handled with ease. You just have parallel stuff going on as you would in an FPGA but with the programming simplicity of an MCU.

Anyway, looking at modern MCU I see they come with a huge array of peripheral hardware on board, USB, SPI, UART etc etc. So your first issue is to select the device that has the right combination of peripheral blocks to satisfy your project requirements. If your requirements change you will be searching again for a different device.

Then all those peripheral blocks come with hundreds of registers through which they are configured. If you want to program "down to the metal" with no OS you will be studying the 2000 page manual for a year to figure out how to configure the peripherals and sort out which pins which is using.

Enter XMOS. We don't have any peripheral blocks thank you. If you find you need a UART or SPI or what just drop some code in there to do it.

P.S. I hope one day there is a huge library of such software peripheral objects available that can be mixed and matched for any given application.

[Interactive_Matter]

Interactive_Matter,

Did I understand the XMOS at the end?

Why I do believe you did.

You are right is was just a question to correct me in the points where you think I am wrong - what you did.

But a few comments of course:

Everything you can do with XMOS you can do it better (like in faster execution speed) with FPGA & CDLP.

I'm not sure I agree in general.

For sure if want to implement some large and super high speed "random logic" you will probably be looking to use an FPG as the XMOS may not have the raw horse power to implement it.

Now I don't know so much about the FPGA world but what I do notice is that there is a trend to implement a CPU core on FPGA projects and surround it by the custom high speed logic. Why does that happen? Presumably because there is a lot of logic that needs to be implemented that does not need the massive speed, is more easily implemented as software running on a CPU and is more flexible.

Putting a CPU on an FPGA soaks up logic units and then needs RAM/ROM some where and the required FPGA gets bigger and bigger.

Enter XMOS, we've already got CPU cores thank you and with the timers, clocked I/O etc may well be able to cope with your random logic implemented in software as well. At a much reduced cost to boot.

Yes, that is what I wanted to say - FPGAs are much more common and if you go to real hard requirements they are better, since in the end they can do things faster.

With XMOS you cannot solve any problem but a lot of the problems out there. They are easier to program and it is much easier to get your problem solved. So FPGA solve 100% of the problems. But they are relativly hard to use and implementing a sultion is much more complicated than with XMOS. With XMOS you presumably can solve only 80-90% of the problems but much much easier.

Everything you can do with XMOS you can do better (like in easier implementation) with MCUs.

I'm not sure I agree in general.

The chief thing here is timing determinism. In a traditional MCU there is only one CPU and all events have to be handle with interrupt routines. Well what happens when your application has to generate something in the nature of a video signal? In needs to be fast, it's working on the limit of your execution speed, in needs to feed that stream without glitching. But then, boom, you have some other events that need handling, there goes your video timing.

With the multiple threads and multiple cores of an XMOS these things can be handled with ease. You just have parallel stuff going on as you would in an FPGA but with the programming simplicity of an MCU.

Anyway, looking at modern MCU I see they come with a huge array of peripheral hardware on board, USB, SPI, UART etc etc. So your first issue is to select the device that has the right combination of peripheral blocks to satisfy your project requirements. If your requirements change you will be searching again for a different device.

Then all those peripheral blocks come with hundreds of registers through which they are configured. If you want to program "down to the metal" with no OS you will be studying the 2000 page manual for a year to figure out how to configure the peripherals and sort out which pins which is using.

Enter XMOS. We don't have any peripheral blocks thank you. If you find you need a UART or SPI or what just drop some code in there to do it.

P.S. I hope one day there is a huge library of such software peripheral objects available that can be mixed and matched for any given application.

And additionally the parallelity makes many implementation much easier.

But an MCU may be considered as better since they need less external components and come in a wider variety (which is not really needed as pointed out by you - and with XMOS we can combine CPUs to get more pins, power or whatever).

The point that was important to me was that you can use XMOS both ways - as I putted it before - it would even make sense to port a linux micro kernel or something similar to XMOS to use wide spread, field proven software (e.g. file systems, network protocols and so on - or do you want to port a HTTP server to XC?).

[Folknology]

Great post here's my response to your points:

Here in the forum there is sometimes the discussion what XMOS is and what not. Even me started one of it to understand XMOS a bit better.

Thats partly becuase XS1 is a new kind of animal, it doesn't fit current market boxes, in fact IMHO it should create its own market.

But yesterday I had a enlightening discussion with some friends. We discussed the advantages of XMOS versus FPGA and CDLP. I ended up beeing the XMOS fan boy, having problems to really get my point across why I like XMOS (mostly lack of knowledge about other technologies).

This happens to many of us I think, we are all XS1 evangelists in many ways ;-)

But during the discussion of FPGA and CDLP programming I realized the real advantage of XMOS:

Everything you can do with XMOS you can do it better (like in faster execution speed) with FPGA & CDLP.
Everything you can do with XMOS you can do better (like in easier implementation) with MCUs.

True to an extent but be careful not to fall into the trap that XS1 is a jack of all trades.

Even though many things could operate faster in an FPGA, there are equally many that don't fit. Protocol stuff is often better suited to algorithmic expression than pure state and logic. For example consider implementing TCP/IP in VHDL it would be fast but completely unfathomable.

For low frequency GPIO then yes MCU offer greater convenience but for faster deterministic and or concurrent realtime applications MCUs and their interrupt model are the wrong architecture with the wrong tools, The XS1 and its tools however are architected and optimised for such tasks.

But with XMOS you can easily mix up those implementation (even though some CDLP have integrated processors). But most important: With XMOS it is hard to make mistakes which realy destroys your program. We discussed how you have to design and implement CDLP 'programs' to get it actually up and runnning and why your program can fail if you leave out parts (due to changed timing) and so on. Something completely unknown to me working with XMOS.

Being able to mix and match in this way excludes the market to MCUs, but FPGA with built in processors can tackle this market. However the XS1 has an Agile advantage here, one can quickly and simply change code and see its effects in very short cycles, with the FPGA the cycles can become very long. Do not underestimate how important this is becoming with time to market requirements being squeezed constantly. Not just because you can build something quicker, rather because you can experiment and fail quicker!

With XMOS you can sketch your idea and can implement it better and better. It is quite hard to implement it in a way it is not working at all. You do not have to follow certain practices to get success - even though there are some best practices to get real fast code. In the same time you are able to implement real fast code real fast. The implementation complexity is as high as the complexity of your requirements.

Yes this is true but there are still gotchas within the XS1 architecture and or implementation that can trip you up. You also have to familiarise yourself with a a new development language and some new tools, this presents a quite large learning curve. Its also a big objection for the majority, whoes default stance is "stick with what they know".

So XMOS is a good mix up between an MCU and something like an FPGA (at least you can implement real rea high performance behaviour). So it makes sense to implement real high quality XC code for real fast behaviour. It also makes sense to implement high level behaviour with more high level approaches (I do not mention C++/Objective C here to not provoke anybody).

There are also more unique advantages to the XS1 architecture that you haven't covered but my reply is already long enough!

Did I understand the XMOS at the end? What do you think?

Sure you did and the more you apply it the more you will see other benefits as well as pitfalls ;-)

regards
Al

[jonathan]

Of course, what would be wonderful would be for people at XMOS - of all levels - to engage in this discussion.

[rubberneck]

It seems to matter to some people! Not sure why the reaction is so emotional. I have never seen community members on propellor or pic forums get emotive on how a company positions its product... What's the problem?

[Vaati]

Rubberneck, are you on the parallax forums as well? ;)

I think that at Parallax, the company is deeply involved in what the community is doing, and vice versa.

The one problem I have with XMOS chips (along with many other mcus, fpgas, etc) is that the programming devices tend to be too far above my budget; in this case, the same cost as the development board. [see: xk-1 board and xtag-2] This is one of my main reasons I have never looked into PIC mcus, because the programmer for them is too expensive compared to the chips themselves. Since I am not really into electronics to get an awesome idea and mass produce it, investing in a programmer isn't the best idea.

As far as the capabilities of XMOS chips, I have yet to find out. I'll just bide my time on these forums until I get 512 activity points to get an XK-1, or eventually win one of the parcels. ;)

[Folknology]

Hi rubberneck

It seems to matter to some people! Not sure why the reaction is so emotional. I have never seen community members on propellor or pic forums get emotive on how a company positions its product... What's the problem?

I am not a member of the propellor forum and have not used the products so I could not comment on those, but I would guess that perhaps the community and company positions are more aligned and hence there is less emotional friction.

regards
Al

[Folknology]

To perhaps unpack that a little:

It seems to matter to some people! Not sure why the reaction is so emotional. I have never seen community members on propellor or pic forums get emotive on how a company positions its product... What's the problem?

I am not a member of the propellor forum and have not used the products so I could not comment on those, but I would guess that perhaps the community and company positions are more aligned and hence there is less emotional friction

.

Although I am not sure why it happens, it often appears that Xmos separate community and customers, this can in some ways create an emotional divide which could be at least part of the source of an emotional discord.

Perhaps the MCU positioning for example arises from the customer side rather than the community which might think differently.

What does everyone else think?

regards
Al

[Interactive_Matter]

To perhaps unpack that a little:

Perhaps the MCU positioning for example arises from the customer side rather than the community which might think differently.

Don't know. I always assumed that the MCU positioning comes from the chimeric nature of the XMOS. It is no MCU in the classical sense, it is no FPGA in the classical sense and nearly everybody forgot what a transpurt is.

My personal opinion is that it is nearly everything of the above - there are high speed logic parts and traditional MCU parts. But this point of view is perhaps not helping the marketing.