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.

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.

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.