MCU with FPGA vs. SoC FPGA

[coppice]

68040: 1990 ~1,200,000 transistors.

Quite a jump with a very different implementation. The first pass of the 68040 was brilliant, but mismanagement meant they struggled to crank it to more than 40MHz, while the 80486 went 25MHz to 33MHz to 66MHz to 100MHz, and greatly outperformed it.

I never worked with 68040, the closest thing to ever touching a 040 is when I replaced the 68LC040 CPU on my Apple LC475 with a 68060 via a Smartsocket + complete ROM-hacking as the 060 misses some instructions that need to be emulated in software, and, even when it never throws an exception for unimplemented opcode, I found the floating point unit of a 68060 FULL (with MMU and FPU) is of several orders of magnitude slower than the FPU on a Pentium1!

On the contrary, however, the integer unit of a 68060@100Mhz is 3x faster than a Pentium1@100Mhz.

That's why on the CyberStorm060 (CPU accelerator for Amiga2000, 3000, 4000) was used to massively process "fixedpoint" instead of "floatingpoint", and why my customers' VME industrial embroidery machine controllers, based on a pair of 060 CPUs @100Mhz in SMP configuration, use a pair of SHARK DSP units, attached to a cross bar matrix, for floating point calculations.

I vaguely know that the problem was with the implementation - Intel and AMD were heavily using pipelined FPUs for their 5th generation of x86 32bit CPUs, while Motorola must have reused a non-pipelined floating point unit for the 060 ...

... but I have no idea of the reason 

I was surprised they ever finished the 68060. Motorola was so committed to Power PC at that point, even though their strategy for it was brain dead. Floating point performance wasn't amazing on any chip at that time. People had problems deciding how much of their transistor budget to commit to the FPU, as they were mostly judged on integer performance. Intel and AMD performance was crippled by emulating an 8087. x86 floating point performance didn't start to take off until SSE was introduced.

[glenenglish]

I would suggest a fabric (soft)  microcontroller over a SoC UNLESS you really really need the horsepower.

The SoC is an order of magnitude more complex to learn and use compared to a Microblaze  or RISC-V etc.

like 10x the documentation at least.... I would spend my whole life learning everything about Xilinx MPSoC, but Microblaze is a cinch

But, if you need MIPS, there is no substitute for the hard processor (dual core at 800 MHz executing at 2 DMIPS/ MHZ per core with 128 bit wide buses)  versus a 200 MHz core and 32 bit bus and 1 DMIP/MHz.   Programming the fabric processor is easier also, instead of the whole boot sequence etc stuff. Depends on your use case.....

glen.
Xilinx Alliance Partner.

[gnuarm]

I would suggest a fabric (soft)  microcontroller over a SoC UNLESS you really really need the horsepower.

The SoC is an order of magnitude more complex to learn and use compared to a Microblaze  or RISC-V etc.

like 10x the documentation at least.... I would spend my whole life learning everything about Xilinx MPSoC, but Microblaze is a cinch

But, if you need MIPS, there is no substitute for the hard processor (dual core at 800 MHz executing at 2 DMIPS/ MHZ per core with 128 bit wide buses)  versus a 200 MHz core and 32 bit bus and 1 DMIP/MHz.   Programming the fabric processor is easier also, instead of the whole boot sequence etc stuff. Depends on your use case.....

glen.
Xilinx Alliance Partner.

Interesting perspective.  I like the assertion that it is much more complex to learn to use a "SoC" than to build your own SoC in the FPGA.  How does that work exactly???

[tggzzz]

I would suggest a fabric (soft)  microcontroller over a SoC UNLESS you really really need the horsepower.

The SoC is an order of magnitude more complex to learn and use compared to a Microblaze  or RISC-V etc.

like 10x the documentation at least.... I would spend my whole life learning everything about Xilinx MPSoC, but Microblaze is a cinch

But, if you need MIPS, there is no substitute for the hard processor (dual core at 800 MHz executing at 2 DMIPS/ MHZ per core with 128 bit wide buses)  versus a 200 MHz core and 32 bit bus and 1 DMIP/MHz.   Programming the fabric processor is easier also, instead of the whole boot sequence etc stuff. Depends on your use case.....

glen.
Xilinx Alliance Partner.

Interesting perspective.  I like the assertion that it is much more complex to learn to use a "SoC" than to build your own SoC in the FPGA.  How does that work exactly???

A combination of

• more complex CPU
  
  • longer datasheet, more errata and more possibility of surprises
  • more possibility of surprises when using C without realising what C avoids guaranteeing
• different tooling for interconnecting the logic with CPU
• optionally having an RTOS or full-blown operating system in the CPU
• tying all the radically different development tools together in a coherent whole

That can be mitigated by better tooling and libraries, but the underlying issues persist.

[gnuarm]

I would suggest a fabric (soft)  microcontroller over a SoC UNLESS you really really need the horsepower.

The SoC is an order of magnitude more complex to learn and use compared to a Microblaze  or RISC-V etc.

like 10x the documentation at least.... I would spend my whole life learning everything about Xilinx MPSoC, but Microblaze is a cinch

But, if you need MIPS, there is no substitute for the hard processor (dual core at 800 MHz executing at 2 DMIPS/ MHZ per core with 128 bit wide buses)  versus a 200 MHz core and 32 bit bus and 1 DMIP/MHz.   Programming the fabric processor is easier also, instead of the whole boot sequence etc stuff. Depends on your use case.....

glen.
Xilinx Alliance Partner.

Interesting perspective.  I like the assertion that it is much more complex to learn to use a "SoC" than to build your own SoC in the FPGA.  How does that work exactly???

A combination of

• more complex CPU
  

A RISC-V is more complex than a RISC-V???

• longer datasheet, more errata and more possibility of surprises
• more possibility of surprises when using C without realising what C avoids guaranteeing

You seem to be reaching pretty far for this one.

[/li]
[li]different tooling for interconnecting the logic with CPU[/li][/list]

"Tooling"  Yes, a huge reach.

• optionally having an RTOS or full-blown operating system in the CPU

Sorry... is that a plus or a minus???

• tying all the radically different development tools together in a coherent whole

Wow!  Yes, you are really working to prove your case.

That can be mitigated by better tooling and libraries, but the underlying issues persist.

If you say so.

[dietert1]

Many years ago i designed a digital audio project on a Spartan50AN. It included a picoblaze for running the user interface with a LCD display and two rotary encoders, IR receiver and UART. The SPDIF receiver was a helper chip to implement input MUX and the PLL and upsample to 96 KHz. Then i implemented a minimual DSP for a stereo crossover, as far as i remember running at 50 MHz. The channel program implementing various filters needed to run twice within the ~ 10 usec sample interval. The filter coefficients could be configured on the fly and the device had a multichannel audio DAC to implement analog audio outputs.
Implementing this required some months. The picoblaze embedded processor was IP provided by Xilinx, including the assembler. Some years later the same application was implemented with a Kinetis MCU instead of the FPGA. Arm Cortex M4 was strong enough to implement the DSP stuff. Of course the FPU helped a lot for filter configuration.

I would recommend learning Zynq. It will take some months, but not your whole life.

Regards, Dieter

Edit: At the time it wasn't a microblaze but a picoblaze.

[nctnico]

I would suggest a fabric (soft)  microcontroller over a SoC UNLESS you really really need the horsepower.

The SoC is an order of magnitude more complex to learn and use compared to a Microblaze  or RISC-V etc.

like 10x the documentation at least.... I would spend my whole life learning everything about Xilinx MPSoC, but Microblaze is a cinch

A really hard no to that. A SoC comes with libraries / OS / SDK that allows to implement a system quickly. Just take a look how much functionality there is in a Linux distribution. You'd be a fool to discard that. Using an FPGA only adds complexity by needing to create a logic design that you can buy off-the-shelve. I have a decent number of SoC designs under my belt and none of them required reading a significant portion of the documentation because the software is already provided by the vendor.

[Berni]

But all that stuff the SoC comes with is only useful if you actually need it.

Yes if you have to do things that are a solved problem in Linux like networking, scriptability, media encode/decode ..etc then a SoC is an obvius choice. You slap on the linux image they give you and you are up and running.

But if you need just a more microcontroller level of functionality then it makes no sense to have a built in SoC. In those cases you are not gaining any useful functionality from having Linux running on it. You can have some serial peripherals and GPIO just as well in bare metal C++, and if you want multipthreading, slap on a RTOS (that you usually also get ready made for these premade soft cores). It boots within a millisecond too and you get tighter control over timing.

Not to mention that FPGAs with SoCs built in tend to be a fair bit more expensive than just a generic one.

Also the thing with making people not deeply familiar with linux use embedded linux is that you will get a lot of hacky ways of making linux do things, since they don't have the knowledge to do it properly. As a result you get products that take 1 minute to boot and sometimes randomly break, or need a reboot for some reason. I seen some horrifically bad implementations of embedded linux even from even big companies (Like Philips smart TVs, they are mess)

[tggzzz]

But all that stuff the SoC comes with is only useful if you actually need it.

Yes if you have to do things that are a solved problem in Linux like networking, scriptability, media encode/decode ..etc then a SoC is an obvius choice. You slap on the linux image they give you and you are up and running.

But if you need just a more microcontroller level of functionality then it makes no sense to have a built in SoC. In those cases you are not gaining any useful functionality from having Linux running on it. You can have some serial peripherals and GPIO just as well in bare metal C++, and if you want multipthreading, slap on a RTOS (that you usually also get ready made for these premade soft cores). It boots within a millisecond too and you get tighter control over timing.

Not to mention that FPGAs with SoCs built in tend to be a fair bit more expensive than just a generic one.

Also the thing with making people not deeply familiar with linux use embedded linux is that you will get a lot of hacky ways of making linux do things, since they don't have the knowledge to do it properly. As a result you get products that take 1 minute to boot and sometimes randomly break, or need a reboot for some reason. I seen some horrifically bad implementations of embedded linux even from even big companies (Like Philips smart TVs, they are mess)

Very true, especially the comment about inexperience/ignorance leading to hacky ways of making Linux do something.

That, of course, is true in other fields; see too many examples in https://thedailywtf.com/

At a place where I once worked, someone had the job of getting a datastream from one Unix box to another. The obvious solution would be based on TCP, sockets, and two tiny processes. But they  knew SQL, so they wrote the data to a database, and the database(?) on the other box polled it occasionally.

[nctnico]

But all that stuff the SoC comes with is only useful if you actually need it.

Yes if you have to do things that are a solved problem in Linux like networking, scriptability, media encode/decode ..etc then a SoC is an obvius choice. You slap on the linux image they give you and you are up and running.

But if you need just a more microcontroller level of functionality then it makes no sense to have a built in SoC. In those cases you are not gaining any useful functionality from having Linux running on it. You can have some serial peripherals and GPIO just as well in bare metal C++, and if you want multipthreading, slap on a RTOS (that you usually also get ready made for these premade soft cores). It boots within a millisecond too and you get tighter control over timing.

You are making the exact same argument:  use an off-the-shelve CPU + peripherals plus an existing OS / driver package as an eco-system. In the end using FreeRTOS requires knowledge as well.

An FPGA + CPU (either softcore or as IP block) only serves one niche: the one where you need to process a lot of data coming from a source that isn't supported by generic peripherals.

[Berni]

True that depends on what RTOS you end up using.

The kind of RTOS i was talking about is more the FreeRTOS kind where the whole thing is basically just a glorified multithreading library for C , rather than being an actual os where you have the os manages drivers,services, filesystems..etc. Sure you still need to know how to use something like FreeRTOS in order to make it work, but it is something you can figure out in an afternoon of reading the documentation.

When it comes to the big boy RTOSes with all that OS stuff included, they are more of a niche. If you are using one you usually have some good  specific reason for using it. Those are indeed complex beasts.

Personally i am more of a fan of using an external MCU rather than a softcore, but some might prefer the later.

[tggzzz]

True that depends on what RTOS you end up using.

The kind of RTOS i was talking about is more the FreeRTOS kind where the whole thing is basically just a glorified multithreading library for C , rather than being an actual os where you have the os manages drivers,services, filesystems..etc. Sure you still need to know how to use something like FreeRTOS in order to make it work, but it is something you can figure out in an afternoon of reading the documentation.

When it comes to the big boy RTOSes with all that OS stuff included, they are more of a niche. If you are using one you usually have some good  specific reason for using it. Those are indeed complex beasts.

Personally i am more of a fan of using an external MCU rather than a softcore, but some might prefer the later.

I'm always concerned about the availability and quality of the peripheral libraries, particularly for more complex peripherals such as ethernet or USB.

Personally I am more of a fan of MCUs where the toolsets guarantee system performance/timing. I too like a simple RTOSs, preferably one implemented in silicon.

[nctnico]

True that depends on what RTOS you end up using.

The kind of RTOS i was talking about is more the FreeRTOS kind where the whole thing is basically just a glorified multithreading library for C , rather than being an actual os where you have the os manages drivers,services, filesystems..etc. Sure you still need to know how to use something like FreeRTOS in order to make it work, but it is something you can figure out in an afternoon of reading the documentation.

When it comes to the big boy RTOSes with all that OS stuff included, they are more of a niche. If you are using one you usually have some good  specific reason for using it. Those are indeed complex beasts.

In such cases you typically end up with BSD style OSses like QNX and so on. Still FreeRTOS has enough pitfalls to get yourself sucked into. Especially where it comes to (IP) networking.

[jars121]

Quick update on this thread from me (the OP).

I've spent the last few weeks diving into this topic a bit further. I have an application in mind which I'd like to use as an introduction to FPGAs, for which I'll also need a software component. I'm currently leaning towards a Zynq SoC, as I can build (using existing IP where possible) the data path in hardware, and use one of the Cortex A9 cores to implement the control/configuration path with FreeRTOS. I don't have an immediate need for the second Cortex A9 core, but the option of implementing an SMP FreeRTOS configuration across both cores, or a Linux OS on the second core at some point in the future is quite appealing.

The possible pitfall I have with the above at the moment is the implementation of certain protocols/interfaces in PL, namely CAN (2.0B and ideally FD) and possibly RS-232/RS-485 and Ethernet, as I'd likely have to try my luck with open source IP cores (e.g. OpenCores.org) where native Xilinx cores aren't available. I could easily implement these in software, but then I'd have some of the data path in PL and some in PS which isn't exactly what I'm after.

I think I need to get a Zynq development board and make a start one way or the other!

[Berni]

Low speed peripherals like UART or CAN are easy to implement in the FPGA since they are so slow that no fancy tricks or special care is needed to make them run fast enough on any modern FPGA.

Things like Ethernet get more complicated since they go into high speed territory, you need a fast way to get data in/out of memory, and you need to interface to a TCP/IP stack on the CPU, so you want something that you have drivers for.

But in general you can usually fairly easily stick open source IPs into your FPGA as long as the bus they use as the interface is somewhat similar, sometimes you might have to write bus adapters to adapt your memory bus to it. Other times you might have issues if the IPs use any vendor specific blocks inside them. Those might need some porting.

[jars121]

Nobody has mentioned LiteX yet? https://github.com/enjoy-digital/litex

It's funny you mention that, I was actually reading about LiteX yesterday. I haven't gone into any detail with it just yet so am not really sure what it has to offer, but at face value it looks quite interesting.

[betocool]

Litex has a steep learning curve, from my experience with it. I do like it, mind, but you pretty much write your hardware in Python to convert to verilog and then use the FPGA's IDE to compile. It's tricky sometimes to get hold of good information, but the Litex discord channel is pretty helpful.

I've done a few simple things on Litex, super easy to build a SoC from scratch, but when you start looking under the hood, it's a rabbit hole.

My 2c's.

Cheers,

Alberto

[SiliconWizard]

Probably already mentioned, but a soft core on FPGA will never remotely reach the processing power of a dedicated hardware core made on a similar process node, while drawing a LOT more power for a given frequency.
OTOH, a soft core will save you the hassle of having an external bus between a FPGA and external CPU, and that's where hybrid FPGAs (FPGA fabric + hard CPU core on the same chip) can be useful if you need the processing power and don't want to deal with an external high-speed bus.

So only your specific requirements can tell whether a soft core, a hybrid FPGA or a FPGA + external CPU is a proper fit.

[jars121]

Probably already mentioned, but a soft core on FPGA will never remotely reach the processing power of a dedicated hardware core made on a similar process node, while drawing a LOT more power for a given frequency.
OTOH, a soft core will save you the hassle of having an external bus between a FPGA and external CPU, and that's where hybrid FPGAs (FPGA fabric + hard CPU core on the same chip) can be useful if you need the processing power and don't want to deal with an external high-speed bus.

So only your specific requirements can tell whether a soft core, a hybrid FPGA or a FPGA + external CPU is a proper fit.

Thank you, this is pretty much exactly what I've surmised from my research over the last couple of weeks. I've successfully implemented a heterogenous multiprocessor design in the past, but as you've identified, the external high-speed bus between the two processors quickly became a bottleneck. The 32/64-bit wide AXI interfaces built directly into the fabric between the FPGA and the hard core, while not without some complexity, certainly resolves any throughput/bottlenecking issues.

[asmi]

Probably already mentioned, but a soft core on FPGA will never remotely reach the processing power of a dedicated hardware core made on a similar process node, while drawing a LOT more power for a given frequency.
OTOH, a soft core will save you the hassle of having an external bus between a FPGA and external CPU, and that's where hybrid FPGAs (FPGA fabric + hard CPU core on the same chip) can be useful if you need the processing power and don't want to deal with an external high-speed bus.

So only your specific requirements can tell whether a soft core, a hybrid FPGA or a FPGA + external CPU is a proper fit.

The problem with hybrid solution is that very few modern SoCs have high-speed communication channel which can be used to talk to FPGA. The best you can find is PCIE 2.0 x1 which would be good for year 2010, but not for 2023. And even that is usually available only on higher-end SKU which are loaded with bazillion of peripherals, most of which are going to be useless for many designs. Even the brand new RaspPi 5 SoC only has a single PCIE2 line!

[Berni]

Yeah id say USB 3.0 is the only commonly available high speed interface on modern SoCs, But that thing brings a lot of extra baggage when all you want to do is send a bunch of raw data across. FTDI does make some high performance USB 3.0 to parallel bus chips, letting a more pedestrian FPGA with no fancy pants SERDES talk fast.

But yeah even PCIe is slow compared to the speed you can get in monolithic FPGA+SoC chips. Not only do you get the whole AXI bus across, they will often also give you a dedicated bus to the DDR memory controller, so the FPGA fabric can directly access memory at sizable GB/s speeds.

[asmi]

Yeah id say USB 3.0 is the only commonly available high speed interface on modern SoCs, But that thing brings a lot of extra baggage when all you want to do is send a bunch of raw data across. FTDI does make some high performance USB 3.0 to parallel bus chips, letting a more pedestrian FPGA with no fancy pants SERDES talk fast.

Those FT60x chips eat a lot of IO pins, which can be a problem for smaller FPGA as they tend to have less IO as well. Also it requires a software layer to be implemented on top of it to facilitate the actual communication, and you pretty much have to use Linux because rolling out your own USB 3 stack is just not realistic. In that sense PCIE link is far superior as it provides a direct path straight to host's memory if endpoint supports bus mastering, so it's as close to having AXI interface as it can be, and it's usually not that complicated to get PCIE going even in bare-metal mode because PCIE fundamentally by design is little more than a DMA engine. Another big advantage of PCIE is that it's only two differential pairs per lane, so MUCH easier to route than a typical parallel bus. The only problem is, like I said, pathetic obsolete PCIE IPs which SoC vendors use that only supports a single lane of PCIE 2.0. I would be much more happy with x4 link, as even low-end Artix-7 chips have at least a full quad of transceivers, so there is no reason not to implement x4 link if it were to be supported by the host side. There is a bit of a catch here as PCIE 2.0 requires using at least speed grade 2 devices, but in practice it's usually not that big of a deal as long as you actually remember to manifest SG2 SKU in a BOM.

[Tation]

In my experience (I must admit, based on products now obsolete), FPGAs including hard cores are (were?) buggy as hell, sometimes simply unusable. Thus I think a safer path is going thru any of the available soft cores (MicroBlaze, NiosII/V, LatticeMico —didn't use this one—,…). Or use and external MCU, provided that you can locate a fast enough I/O channel between MCU and FPGA.

Regards.

[asmi]

In my experience (I must admit, based on products now obsolete), FPGAs including hard cores are (were?) buggy as hell, sometimes simply unusable. Thus I think a safer path is going thru any of the available soft cores (MicroBlaze, NiosII/V, LatticeMico —didn't use this one—,…). Or use and external MCU, provided that you can locate a fast enough I/O channel between MCU and FPGA.

Regards.

Never heard of anyone having troubles with silicon bugs of Zynq 7000 platform. Softcores, on the other hand, can be very buggy. For example, see my thread about Microblaze 64 bit. It feels like a beta version at best. 32 bit version is very stable though, never had any problems with it.

[SiliconWizard]

In my experience (I must admit, based on products now obsolete), FPGAs including hard cores are (were?) buggy as hell, sometimes simply unusable. Thus I think a safer path is going thru any of the available soft cores (MicroBlaze, NiosII/V, LatticeMico —didn't use this one—,…). Or use and external MCU, provided that you can locate a fast enough I/O channel between MCU and FPGA.

Regards.

Never heard of anyone having troubles with silicon bugs of Zynq 7000 platform. Softcores, on the other hand, can be very buggy. For example, see my thread about Microblaze 64 bit. It feels like a beta version at best. 32 bit version is very stable though, never had any problems with it.

Indeed.
Almost every entry-level (and even many higher-level) scope these days uses a Zynq, for instance. That's probably because these are so buggy.

Anyway, the soft vs hard core question, as I mentioned earlier, makes usually no sense for the use cases where you really need a hard core anyway, no need to repeat why.