FPGA Workflow

A project log for FPGA Bootcamp #1

Learn FPGA Design from the ground up with Verilog

al-williamsAl Williams 06/21/2018 at 23:000 Comments

Exactly how you "program" the actual FPGA hardware depends on which chip and vendor you are using. In the bootcamp where we actually program the IceStick, you'll see more details about exactly how to do it. However, most FPGA "builds" follow a very similar flow and you might find it interesting to know what that is.

If you think about a conventional C program, your workflow looks like this:
  1. Compile C code to object code
  2. Link object code and libraries to executable
  3. Debug executable using simulation
  4. Prepare executable for downloading
  5. Send executable to target system
  6. Debug executable on target system

The details vary, but a generic FPGA workflow looks like this:

  1. Synthesize Verilog into low-level constructs
  2. Simulate/test/debug system behavior
  3. Map low-level constructs to specific device blocks
  4. Place and route blocks -- this means to plan which blocks go where and exactly how to interconnect them
  5. High-fidelity simulate/test/debug on actual device-specific configuration
  6. Program configuration to FPGA or configuration device
  7. In circuit test/debug, if necessary

Some vendors use different terms for things like blocks or place and route, but the ideas are universal.

You might wonder why you would test and debug at three different stages. The simulation in step 2 is like we are doing in this bootcamp. You deal with the source code, things work pretty fast, and you can catch logic errors in your design.

What you can't catch is problems caused by how things are set up on the chip. Maybe this signal arrives just a little too late and causes an error. The device-specific simulation in step 5 can catch that. But it is generally a lot more data to process and model so the simulations take more time and memory. On a big design it can also be costly to have to go fix source code and then re synthesize. So you try to catch your logic errors in the second step.

Of course, nothing works exactly like it does in simulation so sometimes you have to debug on the chip. Modern chips have tools to help you see inside them just like modern CPUs have on chip debugging support. But it is still harder and more time consuming.