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

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.

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 ...

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. 

Hi shabaz  and Jan Cumps,  both of your views strike a chord with me as I have been on both sides of the boat. So I can share some of my experience. 

In the past, I have worked on on the FPGA design side and I had a specialist software team with specialized knowledge to do the embedded linux. There is huge interest and  support for using opensource toolchain from the embedded software team and they don't like proprietary and closed tool chains as they wanted their build tools to support multiple vendors. So the initial development (for board bring up) turnaround between the firmware and software team was not as fast as I expected. I tinkered with petalinux for fun and provided them with some basefiles that they can build upon. I gradually started to interface with the embedded software team and learned quite a lot. As part of the process (being an FPGA engineer),  the embedded linux learning curve was steep from my end but I enjoyed the process. But certainly believed some structured learning and guidance would have been a lot more productive  beyond the support offered from the forums. 

In my current role, I do both the FPGA and the embedded Linux. There is a software team but they are not specialists in the embedded domain as shabaz suggested as it is indeed a different skillset. I have gradually gained some useful knowledge on doing embedded linux stuff (but by no means can claim as a specialist). But I have shipped complete products (FPGA + Embedded linux), so it is doable and a lot more faster when you have done it a few times. So, I believe Jan Cumps  views on the Integrator being an FPGA designer might be the way to go. But not sure if fellow FPGA engineers would have the time, interest and roles that are flexible to provide such options. 

This is a classic discussion about Generalist Vs Specialist. I believe there is pros and cons on both sides. So it is ultimately for the individual to decide.

Resources from Bootlin and books like embedded Linux primer have been of great help in this journey. My appreciation for embedded Linux has increased many folds after seeing the support and initiatives from the embedded community.