Where to begin? There's a new Altera based development kit (dev-kit) sitting on my desk,. and I've never used an Altera FPGA before. There's a lot to learn.

Fortunately I've started from scratch before many times. There's a process that can be followed to get up to speed, and this blog post will outline that process. While I'm applying it to my new FPGA kit, it can be adapted to anything.

Surveying the Field

The first step is to get a big picture of what's needed. My goal is to be able to design and test hardware using the new board; basically doing the same as before with a new dev-kit. So, what do I need to know? Here's my quick list:

  • How to upload designs to the new development board
  • How to use Altera's FPGA software (for design, compiling, debugging, etc.)
  • How to use the dev-kit's various devices (e.g., the I/O pins, clocks, audio codec, HDMI output)

What resources will I need to learn these things? In brief:

  • The dev-kit's manual, examples, and any other resources (here for the Cyclone 5 starter kit)
  • Altera's design software (link)
    IMPORTANT: Make sure that you download the free version. I accidentally downloaded the standard version, and had to redo everything (or spend at least $2995 USD to buy a license)

It's important not to get bogged down in detail at this stage. At the beginning you don't know everything that you'll need to know, nor do you have all the skills or resources. That's perfectly fine. What's most important is that you believe you're able to learn and acquire everything that's needed.

Getting Your Feet Wet (a.k.a., Experimenting)

Maybe you're someone who likes to read manuals first. Me, I like to play a little, try stuff out, and get an intuitive feel for them. I'll also flick through the documentation to get the gist, focusing on what I think will be important.

So, the first thing I did with the FPGA dev-kit was plug it in and let the default design run (as described on the quick-start card). This confirmed that the hardware worked. Next, I flicked through the manual, had a look through the "System CD," and installed Quartus (Altera's design software). I also tried running the Control Panel, but couldn't get it working; more about that later.

This step involves looking at a bit more detail, but not too much. It's about getting an intuitive feel for what's up ahead. Sometimes this will uncover more things for the to-do list. Other times everything will appear straightforward. Both are fine.

Overcoming Obstacles

Sooner or later you're going to encounter an obstacle, a roadblock; something that stops you dead in your tracks. As mentioned above, the Control Panel software didn't work for me which was rather frustrating.

The best approach depends on the obstacle. Sometimes it's best to "keep bashing the obstacle until it's gone." This method served me well with initial issues such as downloading the wrong version of Quartus. I basically kept looking at the issue (e.g., no valid license) until I discovered my mistake.

The Control Panel failure was different. After several hours trying various things to no avail, I employed a different obstacle countermeasure: working around the problem. Using the Control Panel wasn't essential, so I ditched it in favour of trying out the other demo projects. Those projects worked well, allowing me to learn basic tasks such as compiling a design and uploading it to the FPGA. No Control Panel needed. I love finding ways around obstacles.

Perseverence, creativity and lateral thinking are key tools against obstacles. Perseverence is about not giving up, while creativity and lateral thinking help find better/easier solutions.

First Proof of Concept

With a bit of play and research done, the next step is building a "proof of concept." I'm not at this stage yet because the early obstacles took up more time than expected. The idea is fairly simple though: prove that something you're unsure about is possible.

What to choose? There's no one-size-fits-all answer, so here's a rule-of-thumb: look for what you're most uncertain about (i.e., your "riskiest assumptions"). The goal is to quickly eliminate the biggest questions. Figuring those out first will pay dividends in the long term. If you do lots of easy things first and then discover that one of your "risky assumptions" was wrong, then all that work would have been for nothing. That's wasteful, and no fun at all.

For the dev-kit, the biggest question right now is "how do I create and upload my own design?" So the next step is to take the LED flasher from a previous tutorial and port it over to the new dev-kit.

Here are a few proof-of-concept's for other projects I've done:

  • Radeon HD Driver:
    • Greatest uncertainty: Can I get the graphics card to display something?
    • Proof of concept: A test program that sets up a framebuffer and displays an image
  • Warp3D Driver:
    • Greatest uncertainty: Getting a basic driver working
    • Proof of concept: A skeleton driver that does nothing other than detect the hardware (and not crash)
  • Warp3D Nova:
    • Greatest uncertainty: Can I write a shader compiler in an acceptable time-frame and cost?
    • Proof of concept: A test program with a minimal shader compiler that renders a bunch of rotating cubes

Incremental Learning and Development

After the first proof-of-concept comes a cycle of incremental learning:

  • Analyse results
  • Adjust the to-do list based on the next big question (or riskiest assumption)
  • Perform the next task on the to-do list

It's a cycle of learning and adjustment. Try to keep the cycles short so that you quickly know if you're going off track. Each cycle brings you closer to the end-goal, and eliminates your current big question. Items on the to-do list should be small enough to be manageable, but not so small that your to-do list looks like an intimidating mammoth.

Conclusion

The process outlined above is how I take on new tasks with a lot to learn and a lot of uncertainty. In brief, the steps are:

  • Surveying: getting a big overview of what needs to be learnt, and what resources will likely be needed
  • Experimenting: getting an intuitive feel for what's up ahead
  • Proof of concept: proving that what's most uncertain is possible (eliminating the biggest question or riskiest assumption)
  • Incremental learning and development: a cycle of analysing results, adjusting the to-do list, and effectively doing more proof-of-concepts until the end goal is reached

This article has been pretty light on actual FPGA content. That'll come after I've had a chance to do that first proof of concept.

Further Reading

The process above is based on ideas from Eric Ries' book "The Lean Startup" (link). While I unconsciously followed a similar process before reading it, the book helps clarify the process. The Lean Startup itself draws on ideas from lean manufacturing; see Jeffrey Liker's "The Toyota Way" (link). These books are worth a read even though they each focus on a specific niche (startup and manufacturing). The concepts can be adapted for use elsewhere.