FPGA :how relevant is HDL based development??

[rakeshm55]

I have worked with FPGAs using HDL based coding methods. Especially to develop IP cores that interacts with hardware. Off-late I have been out of touch with FPGA technology.  How relevant is HDL based development technique today. What are the changes happening in FPGA development ecosystem??.

I get a feeling after seeing the toolsets xilinx comes up like AXI baseed IP cores, HLS, SDSoC, Sys Gen etc HDL base methods are outdated and new mechanisms have evolved. It looks as if I am new to FPGA technologies. What are the methodologies adopted by the industry so that HDL based development can be phased off??

 I understand that huge resources are available with FPGA and inorder to utilize this capacity new means of interacting with device needs to be adopted trading efficiency. What is the current trend in terms of tools used ?? Which skill set is in demand among FPGA engineers. What technologies drives it (Like SDR, AIs, 5G etc)??

[SiliconWizard]

I get a feeling after seeing the toolsets xilinx comes up like AXI baseed IP cores, HLS, SDSoC, Sys Gen etc HDL base methods are outdated and new mechanisms evolve.

Rest assured, they aren't.

[FenTiger]

These high level tools are intended to help newcomers get started. They won't do much good when something goes wrong at a lower level; HDL skills will remain important for debugging tricky problems, and for getting the absolute best performance.

Some of the newcomers will learn HDL in due time; others will hire people with more experience.

[asmi]

These high level tools are intended to help newcomers get started.

I think the main goal is to reduce TTM by having enough raw power in a silicone to overcome these tools' reduced efficiency. And it makes total sense economically if the product is not going to be a high volume seller, and the smaller the volume the more economical they are. Even if these tools are much less efficient than a good HDL designer, they are free, unlike that designer's time, which costs a lot of money. Even if I would need to buy Artix-100 FPGA instead of A15, that would still only be a couple hundred bucks of price difference, which is not enough for any serious designer to even start a discussion. A side effect for FPGA vendors is that they get to move higher end SKUs with higher margins.

[FenTiger]

That makes sense too.

I think we're both right.

[rakeshm55]

With huge resources available with FPGA I guess TTM is more important than efficiency... Given the variety of tools in FPGA/SoC what are the tools one should get familiar with.... Where to begin ??

[fourfathom]

Even if I would need to buy Artix-100 FPGA instead of A15, that would still only be a couple hundred bucks of price difference, which is not enough for any serious designer to even start a discussion.

What products are you designing? I guarantee you that many serious designers absolutely need to be concerned about a couple hundred buck cost difference.

As for fpga IP cores, you typically surround them with your own HDL design.

[laugensalm]

Very controversial topic. Also depends much on developer's background (HW or SW engineer).
The TTM aspect with the HLS kind of prototyping is quickly void, when other constraints get into play. It's like the good old LabVIEW approach: Get a prototype quickly up and running, and get the "Wow!" effect from a customer, but run into dangers of 'write-only' coding, which will make maintenance expensive.
Once you're optimizing for the market (customer/industrial), you might run into other constraints (cost/power optimization). Might force you to swap FPGA vendor, even.
What I've learnt in the past 10 years of doing FPGA stuff with focus on SW approaches: stick with the working known-good as reference you can always trust.
When you can debug against the known-good, you are way faster with debugging and getting a stable product out. I ended up being very productive with MyHDL, despite its quirks, simply due to the excellent test benching and co-simulation features that Python offers.
Classical example image compression: Model your idea using your favorite DSP toolbox the functional way. Translate the model stepwise into hardware elements (and start to see cycle accurateness). Constantly verify against software (do not break stuff). Eventually, emit the entire pipeline as VHDL or Verilog. If you still introduced a bug, your 'known good' simulator will show you in the bare HDL. MyHDL outputs pretty sensible HDL, so it's not totally unreadable, like some of the Xilinx CoreGen outputs you might be used to.

[SiliconWizard]

With huge resources available with FPGA I guess TTM is more important than efficiency...

That's a reasoning you can't hold in general, it will all depend on all the constraints, and of course will hold only when the development costs overweigh the parts cost, which in turn all depends on your market and the number of products you'll sell...

Those tools are more aimed at the large FPGAs, which tend to still be pretty expensive. Wasting resources on CPU-based designs these days is common as this has become very low cost, but on FPGAs, not so much. If you have to go for a much larger FPGA to leverage those new tools, this sometimes can mean the cost of the part will be 2x, 3x or more what it could have been if used more efficiently. Then beyond cost, there's also the question of power consumption. Wasting resources using large FPGAs can mean much higher power consumption...

I for one think those "new" approaches are mainly useful for the typical case of designing "accelerators", basically translating software algorithms so they can run very efficiently (in terms of processing power) on FPGAs. Sure this use case is an increasing market for FPGAs, but still far from being the only one.

Finally, as I say on a regular basis, there's life beyond FPGAs for HDLs. If you have to design an IC or port an FPGA-based design to an ASIC. If you're using those vendor-locked FPGA tools, there's a big chance your design won't be reusable in the least, either for just switching to a different FPGA vendor, or for porting it to an ASIC. Those tools lock you in.

As a corollary, that also means that as an engineer, skills you acquire using those tools will be much less "portable" than mastering general-purpose HDLs.