Stack OverflowGetting started with FPGA programming
[+36] [5] Ethan Heilman
[2009-11-10 21:25:14]
[ books embedded fpga ]

I want to play around with FPGAs [1]. I'm looking for advice getting on started.

  1. Can anyone recommend good FPGA boards that I easily start programming for? How much should I look at spending?
  2. Can I avoid buying a FPGA board now, and just emulate the code I write? Are there portability issues between different boards?
  3. What languages are typically used to for FPGA development? What is each languages advantages/disadvantages? Many of the languages look C-like. Are there ways to just specify circuits of logic gates? Does it make sense to work at the gate level?
  4. What books have you read to learn how to develop for FPGA? Which ones are the good books?
  5. How quickly does FPGA knowledge become obsolete?
  6. What advice would you give to someone just starting out in this area? Any common pitfalls?
I used Xilinx when I first learned. VHDL was a great language to code with. - ServAce85
@ServAce85: And it still is! :) - Vlad Lazarenko
[+31] [2009-11-10 21:38:08] Carl Norum [ACCEPTED]
  1. Here is a list [1] of a bunch of available boards, both Altera and Xilinx. You're probably looking at spending in the $100-$500 range depending on how fancy an FPGA you want. Googling " fpga development board [2]" turned up a lot of options.

  2. Most development environments provide simulation capability, so you could use those to learn the language. Getting real device experience is good, though. As to portability between boards, the kind of things you're going to be doing while learning probably won't be pushing the envelope enough that it matters which device you have.

  3. The big ones are Verilog [3] and VHDL [4]. I prefer Verilog's more C-style syntax, your mileage may vary. Working directly at the gate level is certainly possible, but the whole point of HDL languages is to give you some abstraction on that stuff.

  4. I had this book [5] as a text for the Verilog class I took in college. It was good, Amazon may suggest some other good options.

  5. The general concepts of FPGA programming don't change much; the cababilities and features of the chips certainly do, however. As always, good fundamentals will take you a long way.

  6. Programming HDL to describe logic is not the same as writing code for a general purpose processor. Don't try to do a lot of complicated sequential logic.


(4) I suggest Verilog; VHDL in my experience is ADA-like. I've had atrocious times with Xilinx's IDE. Unless I rip it apart and do a pure command-line interface(doable), I don't want to touch Xilinx unless I have to. - Paul Nathan
[+16] [2009-12-13 18:28:18] mrkj

Carl's response was excellent and definitely warrants reading before mine. Having said that:

  1. Before buying a board, I would recommend considering two points carefully:

    1. Which vendor are you tying yourself to? Are you happy with their tools? This may not be such a big deal if you're putting up $50 for that Avnet board, but if you're shelling out $2k for an ML605 board, you should probably try out Xilinx's tools first. All major vendors offer free versions of their tools online: Xilinx [1], Altera [2], Lattice [3], Actel [4]
    2. What sort of applications do you want to hack at and what sort of peripheral support do they need? Do you want DDR RAM or SRAM? VGA or component video? Do you want a character LCD or a video LCD or neither? AC'97 audio? Do you want Ethernet and, if so, do you care if it's 10/100 or gigabit? Do you want PCI or PCI-E? How about USB?

      If, for example, your goal is to use FPGAs to accelerate some application running on a host PC, you need to consider how you'll get data to and from the FPGA, including what sort of bandwidth and latency characteristics you'd like, and what sort of software support you can expect on the host PC side. There's a great-looking module from Opal Kelley [5] that addresses the host-to-FPGA issue.

    In short, you don't want to shell out a bunch of money to get stuck with a board that doesn't really meet your expectations. If your goal is simply to experience what it's like to design for an FPGA, the cheapest possible board (i.e., the $50 Avnet Spartan board) is probably your best bet.

  2. Again, I would absolutely recommend downloading the vendors' free tools and working through some tutorials before buying a board.

    If you're interested in learning VHDL and/or Verilog independent of the FPGA domain, there are open source simulators for each: Icarus [6] and Alliance [7]. There's also a free version of ModelSim [8]. I'm not aware of a free option that supports mixed-language simulation.

    Regarding portability between boards, I tend to disagree with Carl insofar as I think portability can be a big issue. Moving between vendors introduces a lot of problems, ranging from the nuisance of unfamiliar tools to the headache of incompatible or nonexistent IP. Switching boards could mean different, incompatible peripheral chips (e.g., moving from a board with DDR to a board with DDR2 will require a new memory controller). The concepts you learn will definitely be portable; large parts of your designs may also be portable; the integrated system, however, will not be.

    The largest barriers will exist when switching between vendors: keep in mind that the FPGA industry is a well-established oligopoly and the leading vendors have a vested interest in preventing their clients from moving to the competition.

  3. On the language front, I also prefer Verilog, mostly because it's more succinct. I've been told that Verilog is more common in North America whereas VHDL is more common in Europe. VHDL also seems to be favoured in defense (possible due to its similarities to Ada). When you're reading about Verilog and VHDL, try to keep in mind that they are event-driven simulation languages that are being used for synthesis -- that is, large portions of the language are only meaningful for simulation and are inefficient or impossible to synthesize.

    I agree with Carl that working schematically at the gate level, while possible, will quickly reveal itself to be tedious and inefficient.

    There are higher-level languages for hardware design, but none are all that widely accepted. Wikipedia has good links on the C to HDL [9] side and on general-purpose HDLs [10] (like Confluence, Lava, BlueSpec, and so on). There are also MATLAB to HDL tools, like Xilinx's System Generator for DSP [11].

  4. While there are plenty of decent books on HDL programming, I've honestly never seen a good book on FPGA development. I personally think you'll find better information in vendor tutorials and on blogs. Course notes on university websites may also be useful.

    It's often been said that the best way to learn to code well is by reading good code; to that end, take a look at the code for vendor IP and dig around the more successful-looking projects on OpenCores [12].

    Be sure to read the HDL coding guidelines from vendors, and make an effort to read and understand all the warnings and errors generated during synthesis, mapping, placement, and routing. I would also strongly recommend skimming the architecture manual for whatever device you're designing for. Make an effort to understand the synthesis flow and the way in which your HDL maps to the FPGA architecture.

    A good example of this is: why is a ripple-carry adder faster on an FPGA than a carry-lookahead adder? The carry chain is so significantly faster than general-purpose routing. Always bear in mind that FPGAs and ASICs are decidedly different beasts.

  5. I agree with Carl completely here. Not only do the devices change frequently, but so do the design tools and methodologies. Fundamentals will either remain unchanged or provide a basis upon which you can build an understanding of the motivation for the latest tool or architectural quirk.
  6. I think I've alluded to common pitfalls above, but to summarize:
    1. The more you understand the architecture you're targeting and the techniques used to translate your HDL, the better you'll be able to target that architecture, leveraging its strengths and avoiding its weaknesses. FPGAs are 'discrete' and 'non-linear', so the difference between playing to their strengths and getting mired in their weaknesses can be very significant.
    2. Think carefully about the vendor and its tools when buying a board. The price of an FPGA encompasses a lot more than the silicon; it's also IP and tools, and moreover, the latter are probably more significant and valuable than the former.
    3. This isn't alluded to above, but think carefully about simulation and testing when you're designing for FPGAs. Because synthesis is so time-consuming, you don't want it to be part of your debugging loop. Besides, debugging on the device is vastly more difficult than debugging in a simulator. I'm sure 90% of FPGA development can be done without a development board, so if you're interested in getting into it, just download the tools and dive in.

Edit: Added a link to Actel's tools; the one Actel board I'm aware of is the OpenRISC development kit [13] from ORSoC.


[+4] [2009-11-11 15:56:05] dwelch

avnet has a nice spartan3a board for $50.

[+4] [2009-11-11 18:42:24] starblue

I liked the Cyclone II FPGA Starter Development Kit [1] from Altera (I got it in March 2008, don't know if it is still available). It comes with tutorials for both Verilog and VHDL and has some simple I/O to play with, as well as standard 2x40 connectors which are easy to interface with.


[+2] [2009-11-10 21:34:58] monksy

Warning: I have not done very much FPGA development.

A good starting point would be programming a microcontroller. Typically these have a shallow-er learning curve than FPGAs do.

If I'm not mistaken FPGAs do not become obsolete as fast as consumer grade hardware. FPGAs are very specialized and new FPGA models are not released as frequently.

I would imagine that many FPGAs provide a simulator to code for them. Try writting for embedded OSes. I've heard a few FPGAs use VxWorks.

(9) Programming a microcontroller is the same as writing any other computer program. There are of course some gotchas with interrupts and setting up a C environment at the beginning of execution. I don't think microcontroller programming has much of a bearing on learning to program and use an FPGA though. - Carl Norum
(2) Its not... you don't get the same features, the same debugger, or output as that you would with desktop computers. You have a lot less space, and a lot less processing ability. - monksy
(2) I dunno, JTAG is pretty good these days; I get a lot more visibility into embedded projects with a good JTAG/ICE and debugger application than I would with command line gdb for example. I think they both run a pretty wide spectrum. Regardless, what I'm really trying to say is that there is a much bigger relationship between writing a C program on my favourite OS and programming a microcontroller than there is between either of those and HDL/FPGA programming. - Carl Norum
(3) I don't think this answer deserves a downvote, necessarily. +1 for @steven. - Carl Norum
(1) My point was that it is a stepping stone, its not an actual subsitution. The OP is a beginner. For a person, safely assuming, that has learned a desktop/server language to go to embedded development is a big step. - monksy
(1) JTAG is good, but it is not at all similar to debugging with or with Netbeans. My suggestion was reducing the learning curve by learning about embedded systems before completely jumping into FPGAs. - monksy