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.

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. 

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.