Starting FPGAs

Learning FPGAs has been on my "TODO" list for a while.

Many years ago I had the opportunity to work on a new project that involved embedded Linux and FPGAs. As the "Linux software person" I worked entirely on the Linux software. But I had the good fortune to work with some brilliant FPGA people. I was blown away. It was amazing to sit down with these people and say "I could really use a register that works like <this>" and a couple hours later be emailed a new bitfile, load it in, and find a register that did exactly as I wanted! Brand new, custom designed hardware... on a whim! The development of the product progressed hand-in-hand in this way, and it was a very successful endeavour!

It didn't take long, however, for me to wish that I could work both sides of the coin: I can do the Linux stuff (user-space apps, device drivers, creating images, etc) but it would be great to also be able to "play" with the FPGA side as well. Although I wasn't able to find the time to learn FPGAs back then, I did make sure to ask lots of questions of these experts while I was around them. The two most basic questions that quickly come up are: What hardware (vendor) should I use? Should I learn VHDL or verilog (or something else)?

What I found interesting about their answers is that they readily admitted that their choice of vendor and language today was based entirely on whatever technology they were taught at university. It's not about vendor lock-in per se, it's about the tendency to learn a tool, becoming proficient at it, then developing a reluctance to want to build the same proficiency in another tool (or language) for no apparent gain. The same things can be done, roughly, in both languages. The capabilities of the hardware from the various vendors is, roughly, on par. There is no clear winner in either category (or so is my understanding).

At this point I have no idea how proficient (or not) I might become in actually developing my own projects. My point, for now, is to know enough to be able to play with existing things I find (e.g. OpenCores). For my purposes, in terms of VHDL vs verilog, I see lots of interesting projects that are done using both; both languages seem to be equally popular. Ideally it would be nice to have some familiarity of both. There are also a couple projects that try to bring things like C or Python to the world of digital development. Those might be interesting to explore as well.

My thoughts regarding hardware are similar to how I feel about HDLs. I would rather become somewhat knowledgeable on a bunch of them rather than to be good at only one. Also, since I do all my development work on a Linux machine, one thing that will be important for me is how well the development workflow of the various vendors supports Linux. How easy (or hard) is it to develop for vendor A's product in Linux (including getting the result into real hardware) versus vendor B, C, or D?


FPGAs have always been an interesting and fascinating technology. Coupling them with Linux in an embedded environment, I think, is an amazing partnership. Linux is great, and real-time Linux is amazing. But, let's face it, nobody can realistically promise absolute strict timing as long as a software scheduler is involved. When done well, using an FPGA can cover those things that absolutely need very strict timings. FPGAs also provide a decent place to "hide" the magic sauce of your project. Also, with good profiling, it's possible to find those processing-intensive parts of your design and potentially move them out to hardware.

I think FPGA companies have sold as many FPGAs to EEs as they're going to. Their next wave is going to come from software developers :-)