The future of "FPGA only" chips compared to SoC and its impact on FPGA engineers

Where to start ?

A small (by volume) sector of the FPGA market may well move to using Zynq like FPGAs.

But never all of it.

Most applications don't need or want Linux or any other big operating system in their application.

Estimates vary but even a small Linux involves millions of lines of code. This code is never free. It requires mangement and maintenance, it will contain many bugs ( because of its size).

The Zynq ARM proccessors are large "application" type parts, for a great many applications smaller ARM (or other) cores are much more suitable.

A bunch of new players are moving into the field with sub $10 FPGAs developed with simple tools (sometimes even open source), my prediction is that these parts will easily outstrip the big SOC style FPGAs both in volume of shipments and number of design-ins.

There are a few SOC type FPGA s around with small micros inside - Gowin have one with and ARM Cortex 3 and a 4k LUT FPGA, and it's cheap.. I think Microchip have some Cortex 3/4 based SOCs too but the pricing hasn't been convincing.

On to the inhernent advantages of not putting your processor inside the FPGA:

1)  you get to choose the processor you want

2) the cost will be lower

3) the power can be much less (in sleep mode the processor will use little power and the FPGA will be off)

4) you don't need your FPGA people to do Linux or your software people to do hardware.

5) you have more options of suppliers of both FPGA and processor

MK

Hi,

Regarding "growing need to understand the basics of embedded Linux (and some low level software) "

this is a completely different skill-set to FPGA development, and in fact a completely different skill-set for most software developers too. Take a look at what resources there are for Linux driver development for instance, which is more likely to be required than not, for working with SoCs that integrate an applications processor, compared to designs with a separate processor using standards-based interfaces such as Ethernet or SPI. You'll find that it's a specialist thing - not all software developers have worked on Linux drivers, and you can probably count on one hand the number of textbooks on the subject.

As a result, I can only conclude that Zync development really needs teams with enough employees for those separate skills, unless the design uses standard interfaces in which case it may as well be a separate applications processor. It feels unreasonable to expect an FPGA engineer to start Linux driver development, unless Xilinx and other manufacturers lend a hand and provide that training.

Maybe I'm wrong - would love to hear from others.

I think that the toolset and the way the boundaries between the fpga fabric and processors are set up in Zynq (the only one I have experience with), allow for separate Software and FPGA IP development teams. 

Both sides need to know the interface mechanisms and -designs. And the fabric-with-processor integrator will have to understand the mechanisms very well.
Given the nature of the interfaces, and the fact that for Xilinx this is done in Vivado, I see this integrator as an FPGA designer role. Not an IT role.

In the end, for the software and IP designers, it doesn't make too much difference if the processor(s) sit on the silicon or housed in another chip.

Hi Jan,

I mean it's not a situation where the FPGA developer can be expected to pick this up, i.e. regarding the comment

"As  FPGA engineers, there is a growing need to understand the basics of embedded Linux (and some low level software)" - it would require a team effort, more than one person, not the same FPGA engineer. As you say, the tools allow for the separation of roles.

I think it only doesn't make a difference if the processor is separate or on-chip, if standard interfaces are used, in which case I cannot see much benefit of the on-chip integration, because I thought the point of having the integrated processor was that you could get great performance gains through tight integration, i.e. effectively making your own integrated peripherals in VHDL, with perhaps multi-Gigabit levels of throughput since you can parallel things. If the interface is (say) SPI or Ethernet, then it may as well be on a separated FPGA and processor.

Otherwise, driver development is needed, which would require a type of software developer who has experience with that, which is quite a niche skill, and the typical FPGA developer most certainly won't have experience with that.

shabaz said:

I thought the point of having the integrated processor was that you could get great performance gains through tight integration, i.e. effectively making your own integrated peripherals in VHDL, with perhaps multi-Gigabit levels of throughput since you can parallel things

there are definitely advantages. In case of the Zynq:

- 64 direct on-silicon data signals between fabric and ARM

- memory mapped access to fabric, with DMA support (double DMA: you can stream from ARM to a fabric DSP design and stream back relying on the DMA engine both ways)

- synced clocks

- more!

I've used some of those when working with michaelkellett's memory block. What I was trying to say is that you still write traditional RTL on the fabric. And traditional Linux interface constructs like writing to a memory register, a memory range, or a single gio pin ...

The main issue wasn't the new silicon in the 7-series by itself. 

It was the need to get developers onto Vivado.

The old tool set was becoming unmaintainable, and was not going to be able to support Zynq or other SOC+FPGA designs.

Nor could it support more advanced development with functional C-HDL, or better library management.

FPGA designers can choose to ignore the software/firmware side of the project for the most part.  The only point of coordination is the specification of the hardware register addresses that the CPU(s) will interface to the Fabric. And what those registers do.  

I think the software developer is going to have the larger burden of understanding the hardware layer well enough to write drivers for the chosen OS environment whether it be bare metal, linux, Python, Arduino, or even Lua.  At least for SoC+FPGA work, software engineers are going to have an easier time adapting than pure EE designers developing good product solutions. 

It is not just custom interfaces to external hardware.  The tools were designed to allow critical paths in software systems to be accelerated in the fabric. The whole point of the C-HDL is to make it easier for a software engineer to convert a proven software function into HDL where it will execute much faster. 

As far as a personal journey.  I have been tinkering with FPGA tech for a long time.  Until about 2017 I didn't find it compelling enough to try to design with it.

Since then I have been learning the tool chains and libraries (open and proprietary) to gain enough confidence to build something salable by the time the semiconductor market recovers.

I think it is becoming easier for one person, or small team with a strong software background, and good basics in electronics to make a competent contribution as the FPGA becomes a more ubiquitous component in small embedded systems.

Hi michaelkellett , Very interesting and valid points. So as far as security of the underlying system is involved, having Linux provides a potential backdoor if it is not properly secured. With respect to ARM processors on Zynq, I am always used to seeing the A9 and A53 processors for the Ultrascale MPSoCs. Were you mentioning only "Gowin" as part of the new players or would be interested to know the other players in the sub $10 FPGA market. With respect to the inherent advantages of not not putting a processor inside FPGA: I accept with most of your points. With respect to choosing the processor I want. Until the RISC-V revolution in the past years, as a naive FPGA developer, my only option was Microblaze. I am not sure if there was much options beyond Microblaze. For 4), I will repily to shabaz  post.