An Interview with Russell Merrick, author of Getting Started with FPGAs

There are a ton of resources for FPGA design on the internet today, but few are as widely circulated as It's a wealth of great info on HDL syntax, FPGA design, and self-guided FPGA design tutorials. After many years of running Nandland, Russell Merrick, the longtime author, has decided to commit his work on FPGAs to the printed page. His first book, Getting Started with FPGAs, is being published by Penguin Random House on November 21st. We posed a few questions to Russell about his new book, his work on FPGAs, and what he thinks early career folks can do to give themselves an edge in the job market. You can preorder the book on Amazon or from No Starch Press!

You've been blogging about FPGAs at for many years now. What inspired you to write a book on FPGA design?

One thing I've realized is that everyone learns in different ways. Some people prefer watching videos, others like in-person teaching, and others get the best experience with a book. People have been asking me to write a book for years. But it took an email from Nathan, my editor at No Starch Press (the company publishing Getting Started with FPGAs), to get me to seriously consider it. No Starch Press has been wanting to write a book about FPGAs for years, but never found the right author for it. Nathan convinced me that it was something I could handle, and it was the right time for me, personally. A lot of big things occur because of the right person at the right time, and that's what happened here. 

Who is this book for? Who would benefit most from reading your book on FPGA design?

The book is really for anyone who is looking to better understand FPGAs. If you have no experience at all, or you've done several FPGA designs, you'll get value from the book. The most interesting part of FPGA design to me is how it forces you to think of programming in parallel vs. serial. Once you really understand this, you'll see other opportunities in other programming languages where these same parallel programming concepts can apply. Multi-threading becomes much less intimidating, you pay more attention to your interfaces, and you see old problems in a new light. 

Did you have a goal in writing a book? Do you have any hopes for how it might be used differently than your work on Nandland?

I had a goal to write the book in 4 months. I thought that was a reasonable timeline. I had a lot of content that I could leverage, spruce up a bit, and make a book. Easy, right? How wrong I was. The whole process took over 2 years. The level of detail and thoroughness between a quick blog post on a website and a chapter of a book is night and day difference. I do think that the book has a higher quality of writing than the website. I'm going to start to bring some of that higher quality back to and my YouTube videos now.

What do you believe are the most challenging aspects of FPGA design today?

The design tools are still a big challenge to work with. Multi-gigabyte tools that are completely overwhelming, especially for beginners. That's why I chose to work with the Lattice iCE FPGAs, they are easy to develop with. Additionally, there is an open-source project (IceStorm) which opens up new ways to work with these FPGAs. "Getting Started with FPGAs" recommends using an iCE40 FPGA, so the reader isn't overwhelmed with the tools and can focus on learning about the FPGA itself, as well as the programming languages VHDL and Verilog.

Is the book more focused on theoretical concepts, or practical applications?

I remember taking a calculus class in high school. We were taught all about Riemann sums for weeks, which is how to approximate integrals using a finite sum. I remember being very confused by it. Then the teacher told the class that nobody needs to actually use Riemann sums, we can just use integrals. I felt like we wasted time on the theoretical analysis, when we could have been applying practical uses that whole time. I carry that attitude to this day, so the book is very much practical. If you want to go learn about theory, you can (and probably should) do that, but only after the practical applications are well understood. Doing it the other way always felt backward to me.

What key takeaways do you hope engineers or students will gain from your book?

Engineering is about understanding what tools you have available to you, where each one excels, and where there are drawbacks. There are many ways to solve an engineering challenge, and using an FPGA is just one of them. I hope that anyone who reads the book will have a solid understanding of FPGAs, so they know when they're appropriate to use for their own projects. The book has many projects in both VHDL and Verilog, so you'll be able to also understand what each language looks like and choose the one that you prefer for your own work. 

Which chapter or topic was your favorite to delve into? Why did you enjoy that one in particular?

Perhaps surprisingly, the Appendix was pretty fun to write. It's titled, "Tips for a Career in FPGA Engineering" and describes how to create a good resume, prepare for an interview, and negotiate for a job. I actually dug up my old resume from when I graduated college and was applying for my first job. I put it in the book; it wasn't a very good resume. I explained why that was the case and created a new resume for past-Russell. I think a lot of young engineers will get value from this appendix, and it was fun for me personally to revisit this time in my life.

What's something new about FPGA design that you learned while writing the book?

That's a good question. One thing that sticks out is the technical name for a flip-flop. The name flip-flop is widely accepted in literature and documentation for the fundamental FPGA building block that stores state. But the technical term is a "clocked D latch." And in my research there was even some debate about that term as well. It was interesting to me that the name for one of the two basic building blocks for FPGAs (the other being the LUT) isn't entirely accurate or agreed upon. I think there's also a larger lesson here about not getting too wrapped up in semantics.

What impact do you hope your book will have in the FPGA design community?

I hope that the FPGA community sees the book as welcoming and approachable. I think that there's some pretty high barriers to entry for digital design. Hopefully as a community we can become more open and easy to work with.  

It's a little soon to be asking, but do you expect any updated editions or follow-up volumes at some point in the future?

Nothing planned today, but we shall see how the book is received. There's nothing more motivating to me than positive feedback, so go buy the book and let me know if you enjoy it. If I get enough notes of appreciation, I might write another one!

FPGA design is a pretty niche topic. How have you made it accessible to newcomers while also being in-depth for seasoned professionals?

I try to explain 80-90% of a topic, highlight what's important, and make a note about any gotchas. The last 10-20% of a topic usually requires another 50% of content to explain and is overwhelming for beginners. My goal is to make you understand enough to get a very solid footing, but not confuse the reader. 

As a specific example, if I'm explaining a concept like SerDes, which I have a chapter on in my book, I explain the importance of using an encoding scheme. I make it very clear for the reader why it's necessary to encode your data when sending high speed serial data (like USB, HDMI, Ethernet, etc). I give one example of an outdated but simple encoding scheme (Manchester). I then state that there are more modern encoding schemes such as 8B/10B. If the reader needs to use 8B/10B, they will find tons of information online about specifics of that. So overall, my goal is to build a great foundation of understanding for the reader.

What advice would you give to young engineers or students venturing into FPGA design?

There's a lot of advice I could give, but one thing that stands out is testing. Get comfortable with creating unit tests for your FPGA designs and you'll save yourself so much pain in the debug phase of the design. This is true for all software development, but even more true for FPGA designs. In embedded design, working with C, or using Python, you can set breakpoints, print text to the console, to help debug your problems. But you can't do any of that when you're debugging your FPGA. All you have is your testbench, so you need to spend more time making great tests otherwise you'll have strange bugs that haunt you when you program your device. 

What would you recommend as a "next text" for folks who finish your book and want more?

I would recommend that readers beef up their simulation and testing capabilities (see previous question). With that goal in mind, I recommend getting better at SystemVerilog. SystemVerilog is a superset of Verilog, which means it has everything that Verilog has and more. It's great for building better testbenches, which is something I highly recommend for more advanced FPGA design.

Russell Merrick is an embedded systems engineer, the founder of, and the author of "Getting Started with FPGAs", which will be published by Penguin Random House on November 21, 2023!

About Us exists to match HDL engineers with the jobs of their dreams. We offer one service only: just vetted FPGA and RTL roles from reputable employers. More about us here!


  1. 2023