Is FPGA + SoC the 'way of the future'

[mrpackethead]

While trying to research an IP stack to run on Microblaze ( FreeRTOS+TCP vs LWip ) it was suggested that 'the way of the future' is to use a FPGA/SOC ( such as a Zync ).
Even the entry level Zync has a considerable price penatly over a Artic7 or Spartan7, so if you dot' need big performacne is this really still the case?



https://forums.xilinx.com/t5/Embedded-Processor-System-Design/LWIP-vs-FreeRTOS-TCP-IP/m-p/903973#M42418

[Bassman59]

While trying to research an IP stack to run on Microblaze ( FreeRTOS+TCP vs LWip ) it was suggested that 'the way of the future' is to use a FPGA/SOC ( such as a Zync ).
Even the entry level Zync has a considerable price penatly over a Artic7 or Spartan7, so if you dot' need big performacne is this really still the case?

I suppose it all depends on the application, and how much FPGA you need against how much CPU you need.

[NorthGuy]

I don't think the price difference between Zynqs and comparable Artix'es is that big. But, there are no really small Zynqs and Zynq's PS uses lots of pins.

If you buy more fabric you can run multiple Microblazes. This uses more resources, but it's much better than RTOS.

If you need lots of parallel things, may be it's better done directly in fabric. All depends on your needs.

[mrpackethead]

lots of design considerations for an architecture!

[EugenioN]

While trying to research an IP stack to run on Microblaze ( FreeRTOS+TCP vs LWip ) it was suggested that 'the way of the future' is to use a FPGA/SOC ( such as a Zync ).
Even the entry level Zync has a considerable price penatly over a Artic7 or Spartan7, so if you dot' need big performacne is this really still the case?



https://forums.xilinx.com/t5/Embedded-Processor-System-Design/LWIP-vs-FreeRTOS-TCP-IP/m-p/903973#M42418

Some blend of SoC will be the future, for seriuos/industrial devices. No use in wasting time routing a bus from fpga to a cpu, and wasting space in pcb.

My question is: altera or xilinx?
Arm cores are the same, fpga fabric are (at a glance) the same. Developement tools are flavored Eclipse for both vendors.

I would say that Xilinx is a more common option, because discussions in forums always contains the word "zinq", and never "soc by altera". But this could also mean that xilinx has a poorer (professional) support or is more difficult to setup, so engineers need to ask to the general internet. May be just Xilinx named their soc with a fancy name, and Altera didn't.

Any experience?


Inviato dal mio ASUS_Z00AD utilizzando Tapatalk

[awallin]

can anyone comment on experiences with the arduino that combines uC with FPGA:
https://store.arduino.cc/arduino-vidor-4000
the FPGA looks like Intel Cyclone 10CL016

is that a viable starting platform for learning things before trying to learn a zynq-board??

[CM800]

can anyone comment on experiences with the arduino that combines uC with FPGA:
https://store.arduino.cc/arduino-vidor-4000
the FPGA looks like Intel Cyclone 10CL016

is that a viable starting platform for learning things before trying to learn a zynq-board??

IMHO that thing looks like a trainwreck.

it's basically an arduino with an FPGA that it can talk to, to do very specific things.

It looks quite limited in it's functionality.

I'd suggest getting an UPDuino and an Arduino or STM32, experiment with them together (SPI bus between the two)

[SiliconWizard]

I'd suggest getting an UPDuino and an Arduino or STM32, experiment with them together (SPI bus between the two)

+1. Or any kind of FPGA dev board connected to any kind of MCU dev board.

Unless you're really targetting an end-product or need a very high-performance bus between the MCU and the FPGA, using a SOC for learning FPGA+MCU interactions makes little sense IMO. You'll learn a lot more using separate boards and tools, especially if you're still learning.

[mrpackethead]

I'd suggest getting an UPDuino and an Arduino or STM32, experiment with them together (SPI bus between the two)

+1. Or any kind of FPGA dev board connected to any kind of MCU dev board.

Unless you're really targetting an end-product or need a very high-performance bus between the MCU and the FPGA, using a SOC for learning FPGA+MCU interactions makes little sense IMO. You'll learn a lot more using separate boards and tools, especially if you're still learning.

For what i'm doign, microblaze looks like it will more than cope with the processing.

[CM800]

I'd suggest getting an UPDuino and an Arduino or STM32, experiment with them together (SPI bus between the two)

+1. Or any kind of FPGA dev board connected to any kind of MCU dev board.

Unless you're really targetting an end-product or need a very high-performance bus between the MCU and the FPGA, using a SOC for learning FPGA+MCU interactions makes little sense IMO. You'll learn a lot more using separate boards and tools, especially if you're still learning.

For what i'm doign, microblaze looks like it will more than cope with the processing.

This may or may not matter to you:

Icestorm takes literally seconds to compile and upload to your FPGA, even from a Linux VM like how I run it. Many of the toolchains from Xilinx and Altera are sweet-fucking-jezus slow. Multiple minutes to compile.
This makes it a lot easier to learn to code when you can fix errors / mistakes and try different ideas without the overhanging "Once I click compile I have to twiddle my thumbs for 10 minutes... and then it may not work."

[filssavi]

I'd suggest getting an UPDuino and an Arduino or STM32, experiment with them together (SPI bus between the two)

+1. Or any kind of FPGA dev board connected to any kind of MCU dev board.

Unless you're really targetting an end-product or need a very high-performance bus between the MCU and the FPGA, using a SOC for learning FPGA+MCU interactions makes little sense IMO. You'll learn a lot more using separate boards and tools, especially if you're still learning.

For what i'm doign, microblaze looks like it will more than cope with the processing.

This may or may not matter to you:

Icestorm takes literally seconds to compile and upload to your FPGA, even from a Linux VM like how I run it. Many of the toolchains from Xilinx and Altera are sweet-fucking-jezus slow. Multiple minutes to compile.
This makes it a lot easier to learn to code when you can fix errors / mistakes and try different ideas without the overhanging "Once I click compile I have to twiddle my thumbs for 10 minutes... and then it may not work."

Ice storm takes seconds if your code is obvious and small enough to easily fit in the fpga of choice (read no appreciable routing congestion present) violate one of the two assumptions and the tool will be as slow as vivado, quartus etc

10 minutes is also not very much at all. Doing place and route on box projects (I’m talking 100k to 1M Gates/logic blocks, so no lattice parts since they are far too small) can take multiple hours, even a full night

This is because place and route is a NP hard problem whose complexity grows exponentially (quite similar to The travelling salesman problem)

[NorthGuy]

This is because place and route is a NP hard problem whose complexity grows exponentially (quite similar to The travelling salesman problem)

FPGA project usually consists of autonomous modules which are sparsely connected together. Such modules can be worked on relatively independent of each other and processing can be put into different threads. Therefore the necessary synthesis/implementation time doesn't necessarily grow exponentially with the size of the project.

Vivado is slow because it is over-bloated.

[asmi]

Vivado is slow because it is over-bloated.

And now you're going to provide a demonstration of your own tool that does it faster, right?

[asmi]

This may or may not matter to you:

Icestorm takes literally seconds to compile and upload to your FPGA, even from a Linux VM like how I run it. Many of the toolchains from Xilinx and Altera are sweet-fucking-jezus slow. Multiple minutes to compile.
This makes it a lot easier to learn to code when you can fix errors / mistakes and try different ideas without the overhanging "Once I click compile I have to twiddle my thumbs for 10 minutes... and then it may not work."

It won't matter to him because it's irrelevant. If you have to run P&R often than you will need to learn how to use simulation tools. Once you do that you'll realize that P&R time doesn't really matter.
But even this is beside the point as the OP is obviously talking about C code for the Microblaze CPU, and it's compilation takes a second, and so is upload to the board as you don't need to reprogram FPGA to upload new code.

[NorthGuy]

Vivado is slow because it is over-bloated.

And now you're going to provide a demonstration of your own tool that does it faster, right?

I don't think anyone will. There's no demand for that.

[asmi]

I don't think anyone will. There's no demand for that.

Well then it's not bloated. Can't have it both ways.

[NorthGuy]

I don't think anyone will. There's no demand for that.

Well then it's not bloated. Can't have it both ways.

Why is that? Vivado performs relatively simple tasks, and it is nothing difficult in reverse-engineering bitstreams and developing efficient tools. But development takes time and money. Therefore, it is only possible if there is some demand. I don't understand why do you think that the lack of demand for such tools makes Vivado any less bloated.