Where to start for an easy intro to FPGAs?

I've also wanted to learn FPGA programming but I've found it to be kinda hard as there doesn't seem to be an agreed on good way to learn how to program them. I've found many tutorials in the net that teach VHDL/Verilog, but I feel like they give examples, show results, but don't explain any further. In the end I feel like they teach HDL recipes more than teaching how the HDL actually gets synthesized into the logic design. There have been a lot of FPGA roadtests, but I've felt a bit intimidated to apply to a roadtest as I'm not sure I would be able to deliver it in-time. On the other side I've seen that most FPGA roadtesters appear to dodge the HDL completly, and stick to the visual programming languages or soft/hard CPU programming in their reviews.

I have also many questions about FPGAs, so I'll add a few myself in case any of the experts wants to answer them:

- There appear to be many different languages that can be used on FPGA, besides the HDL, what is each of the languages good for? When should I use one language in opposition to another one?

- When it comes to HDL, I've read that code could synthesise for one FPGA and not synthesise for another one, how hard is it to make HDL portable? Would programming in portable HDL make it inefficient to the point that its not worth the hassle?

- I keep reading that tools are very complex and all that, I don't really understand how a tool could make such a great difference when the HDL is not tool dependent (or is it?). Could someone elaborate on that? (as an analogy, learning a computer language is what is hard, switching between IDEs is quite straightforward as much as you keep the same language. Why is it so different with FPGAs?)

- What are FPGAs actually good at? What kind of tasks are FPGA the only good alternative? It appears to me that they are mostly good at I/O stuff (multiple or fast DACs, ADCs). I've seen some claims on FPGAs being good at some computational tasks, but I've also seen some others claiming that they are not that great anymore.

- How hard is it to debug them? I've read some claims about debugging timing issues being super hard and requiring an excessive amount of time and patience. Considering that time is money, one would leave the FPGAs as a last resort alternative, as it could increase the product development time considerably if it is that slow to program and debug them.

I've also wanted to learn FPGA programming but I've found it to be kinda hard as there doesn't seem to be an agreed on good way to learn how to program them. I've found many tutorials in the net that teach VHDL/Verilog, but I feel like they give examples, show results, but don't explain any further. In the end I feel like they teach HDL recipes more than teaching how the HDL actually gets synthesized into the logic design. There have been a lot of FPGA roadtests, but I've felt a bit intimidated to apply to a roadtest as I'm not sure I would be able to deliver it in-time. On the other side I've seen that most FPGA roadtesters appear to dodge the HDL completly, and stick to the visual programming languages or soft/hard CPU programming in their reviews.

I have also many questions about FPGAs, so I'll add a few myself in case any of the experts wants to answer them:

- There appear to be many different languages that can be used on FPGA, besides the HDL, what is each of the languages good for? When should I use one language in opposition to another one?

- When it comes to HDL, I've read that code could synthesise for one FPGA and not synthesise for another one, how hard is it to make HDL portable? Would programming in portable HDL make it inefficient to the point that its not worth the hassle?

- I keep reading that tools are very complex and all that, I don't really understand how a tool could make such a great difference when the HDL is not tool dependent (or is it?). Could someone elaborate on that? (as an analogy, learning a computer language is what is hard, switching between IDEs is quite straightforward as much as you keep the same language. Why is it so different with FPGAs?)

- What are FPGAs actually good at? What kind of tasks are FPGA the only good alternative? It appears to me that they are mostly good at I/O stuff (multiple or fast DACs, ADCs). I've seen some claims on FPGAs being good at some computational tasks, but I've also seen some others claiming that they are not that great anymore.

- How hard is it to debug them? I've read some claims about debugging timing issues being super hard and requiring an excessive amount of time and patience. Considering that time is money, one would leave the FPGAs as a last resort alternative, as it could increase the product development time considerably if it is that slow to program and debug them.

Some good questions neuromodulator. How to debug is a particularly good one. I assumed that just like building a physical circuit it would require exposing a test point of the circuit to a physical pin and using oscilloscope, logic analyser or LED.

Lots of interesting points - I'm off on a long weekend hol so not enough time to cover them all but I'll have a go.

There are two primary HDL (Hardware Definition Languages), Verilog and VHDL. They both come in different versions, there are fewer versions of VHDL than of Verilog. The latest versions of Verilog and VHDL both contain many features that synthesizers are unable to deal with. This is one reason why HDL "code" may be non-portable.

Once you start using an HDL to target an FPGA you may want to use the special features of the FPGA like on chip RAM blocks, PLLs, DDRAM interface hardware etc etc. These are all different for different FPGAs and once your project uses them it becomes specific to that FPGA type.

Many people use the FPGA vendors toolset including HDL editor, compiler, simulator,  synthesizer, timing checking, fitter, programmer and debugger.

As you move up the food chain you'll find more use of separate tools, I use Aldec HDL for design and simulation, this makes it a bit easier to port designs from one part to another but you still gut stuck with targeting features which are specific to different chips.

The tools have to do a great many things - the Aldec tool gives me a bunch of files in HDL that I know work OK in simulation, the vendor tool still has synthesize that into FPGA blocks, fit it into the FPGA, route it, check timing, and maybe re-route/fit many times.  The vendor tools also include stuff for helping you use the on chip features and joining together loads of different bits of IP (other peoples' HDL)  and managing the whole thing. A serious FPGA project will include hundreds of files.

In terms of what FPGAs can do:

AN FPGA is probably at least 10x less efficient in use of silicon than an ASIC. If you want an ASIC that can out compute a $2000 Xilinx FPGA expect to spend at least $100M getting it to production - if you only want less than 50,000 of them this doesn't work out fo you - even though the ASIC might only cost $100 each.  (These are very rough figures but you get the idea).

For big projects big FPGAs can massively out compute pretty much anything, they have thousands of DSP blocks that can all work at once.

For smaller projects - I'll give you some real  examples:

Glue together 4 different audio chips to talk to a piece of pro audio gear with a rather odd digital interface. A Lattice ICE40 chip costing £5, using a few mA of current was used to do this. It was also able to replace the tiny processor previously used for configuring the chips and can easily be tweaked if any of the audio chips is upgraded. No processor could handle 4 different protocols and talk to 5 chips using two different voltages.

Pre-process data from an 8 channel ADC generating 24 bit samples at an aggregate data rate of 1.92Ms/s. There are some DSPs that can just about talk to the ADC but none of them could handle the 128 bit wide data paths involved in the pre-processing. The DSP was a Cyclone 10.

Control 32 channels of 10 bit resolution PWM - this was a 1000 LUT ICE40 in a 100 pin TQFP package - very low power and cheap.

Debugging:

Simulation is the key - make sure everything works before it hits the hardware. Of course some things get missed and still don't work.

There are tools that try to embed some logic analysis in the FPGA but I've found them to be pretty much useless - the last project I tried to use them (Xilinx Vivado, Artix FPGA) whenever the debugging stuff was added the design wouldn't meet timing any more. I try to make sure that on a big project the FPGA has at least 16 pins on connectors exclusively for debugging. Then you can connect signals of interest to them and look with a logic analyzer. It's also a really good idea to add test connectors, series resistors or test pads (in descending order of preference) to on chip buses, so you can get access. On really fast stuff you can't do this - else it will stop working.

MK

Good questions.  I'd like to add my own comments to Michael Kellett's excellent points.

VHDL and Verilog do pretty much the same thing, so it's mostly a matter of how much you like typing.  VHDL is based on Ada and is wordy.  Verilog is based on C and is more concise.  I personally prefer Verilog since I like to fit a lot of logic onto a printed page.  Also, I don't have room to store VHDL source code listings.  Chacun a son goût.

I once heard a manager say he prefers his FPGA designers to use VHDL because it's so different from C.  He found that with Verilog some of his designers would write C-like code that did not synthesize well into FPGA logic.  By making them use VHDL, they realized they were designing hardware and not software.  I think this is rather silly, but then I've never been a successful manager.

Michael is correct about portability.  If you write generic VHDL/Verilog it's very portable, but as soon as you use special features of the FPGA it becomes non-portable.  Those special features are very useful for reducing the size of your design so it can fit into a cheaper part.  Companies typically choose one FPGA family and stick with it, so portability is not an issue.  As they say in Vermont during Mud Season: "Choose your ruts carefully."

FPGAs are particularly good at two things: very high performance computing and low-latency I/O.  A general-purpose CPU has to share one or a few cores for all computations whereas FPGAs can perform a huge number of computations in parallel and pass results directly between computing element instead of constantly transferring them to and from shared memory (or cache or registers).  On the other hand, a parallel GPU can often compete with or outperform and FPGA on many applications.

A general-purpose computer is typically bad at low-latency I/O, especially if it's running an operating system.  FPGAs can do bit-level I/O with precision timing.

FPGA debug is more difficult than software because you don't have "printf".  Most people recommend simulation, since it provides access to as many internal signals as you want.  Personally, I avoid simulation since most of my designs are either trivial or else require writing a complex "test bench" to generate stimuli and expected results.  My FPGAs often work in a complex software environment so it's much easier to have the actual hardware or a development board that can act as surrogate for the actual hardware.

As Michael said, include lots of extra test points.  Those are your "printfs": you can route internal signals to the test points and see what's going on inside the FPGA.

When I design FPGAs I do lots and lots of synthesis.  This is to make sure my design continues to fit inside a smaller, cheaper FPGA and that it meets timing.  Most of my designs have been Xilinx Spartan chips.  I annoy sales reps because I'm able to fit my designs in smaller Spartan chips instead of requiring large chips from more expensive families.

I'll often synthesize just part of the chip.  One of the annoyances of most FPGA synthesis tools is that you make a small change to your source code and it produces an unexpectedly large increase in logic.  Trying to track down why is difficult or impossible.  Sure, the tool may generate schematics for you, but they're pretty much useless for a large design.  By synthesizing frequently I can find which source code change caused the unexpected behavior and try to find a way around it.

Debugging timing issues isn't hard as long as you plan ahead and don't try to do more than the FPGA family can easily support.  If at all possible, only use one clock.  Signals crossing clock domains are a total pain and should be avoided at all costs.  Synthesize early to see if you're going to run into trouble.  You may need to pipeline the design, which is really hard to do later on but reasonable early in the design.  Most FPGA families have lots of extra flip-flops so pipelining is cheap.