TL;DR: There has been a real shortage of senior FPGA designers since about 1995. The talent pool is people who started learning programmable logic as kids in the 1970's, and there were never that many of us to begin with. Companies that try to substitute that experience with junior engineers or AI-assisted tooling tend to end up bringing the project to somebody like us anyway — but only after a lot of money has already been spent. This is an honest look at why the shortage exists, why "clean sheet" FPGA work is so much more pleasant than "cleanup" FPGA work, and why most companies are better off renting senior FPGA expertise than hiring it.
At Focus Embedded, we see two kinds of FPGA projects. There's the kind where a customer brings us a clean sheet of paper and we get to design the thing properly from the start. And there's the kind where somebody else has already tried, failed, and called us in to clean up the mess. Both pay well. Only one is enjoyable.
As somebody who's been doing this since I was eleven years old and motivated, frankly, by money, I will happily take either kind of job. But if I were doing nothing but cleanup work, I'd be rich and miserable. So this article is partly an explanation of why the shortage of senior FPGA designers exists, and partly an argument for bringing somebody in early — before the architecture is frozen and before the wrong device family has been ordered in quantity.
A bit of history, because it matters
Sixty years ago there was no formal methodology for designing programmable logic. The "space race" changed that. Both the US and the Soviet Union realized that the room-sized computers of the day were too big to launch, and that for control tasks they needed something smaller, simpler, and lighter.
The Soviets put their effort into engine control for the N1 rocket, which had thirty engines that needed to be coordinated. The technology of the day wasn't up to it, and after an N1 exploded on the ground and destroyed the launch facility, they gave up. The Americans took the dumb approach: five very large engines on the Saturn V that needed much less coordination, and a separate effort to miniaturize the computer. To do that, they backed a startup called "Intel" that claimed it could shrink computer parts. And they took the first crude steps to design what were then called algorithmic state machines — ASM's, basically stripped-down computer processors. ASM's are the direct ancestors of every PLD, CPLD, FPGA, and microprocessor in use today. (A microprocessor is just a highly complex ASM with enough brains to execute instructions out of memory. Which is why a lot of people now build "soft core" microprocessors inside the fabric of FPGA's.)
By the mid-1970's, these chips were starting to show up at the local Radio Shack store. That's where I first encountered them as a kid, at eleven years old, buying books for $1.25 each with the money I made mowing lawns and shoveling snow. I did a lot of the experimenting in the basement of the house I grew up in, and like a lot of people at the time, I did a lot of it wrong, because we were all just learning together.
By the 1980's, when I was at the university, a real mathematical formalism and a logical methodology had appeared, because the systems had gotten too big to fly by the seat of your pants. The first Programmable Logic Devices were on the market, and simple languages had been developed to describe how they were to be wired internally. I caught the very first wave of people learning to write in those languages — the languages that would let an early PC reduce the source code to a "fuse map" that a programming device could load into a chip. It was a bit like watching a C program get compiled to assembly and then to a binary. The very best C coders had once written ones and zeroes by hand, learned assembly, and then learned C. And the best programmable logic designers had done much the same thing, starting at the transistor level and working up.
I mention all of this because it explains the shortage.
Why transistor-level thinking still matters in 2026
If you want a circuit that runs at ludicrously fast speed, I can still design you one by hand. More importantly, even when I'm writing in a modern HDL like VHDL or SystemVerilog, in the back of my head I'm thinking about how the code reduces to things at the transistor level. That's what makes the difference between code that simulates and code that actually closes timing on real silicon.
Designers who can't hold that picture in their heads write things that simulate beautifully and then fail synthesis, or pass synthesis and then fail timing, or pass timing and then mysteriously glitch in production. The gap between code that runs and code that runs fast and reliably is where most failed FPGA projects die. And it's where most of our cleanup work originates.
Since about 1995, demand for FPGA design has exploded while the pool of people who learned this from the ground up has stayed almost flat. The chip vendors have responded by developing AI systems and increasingly large IP libraries to cover for the lack of knowledge among many of the people that companies hire when they have no other choice. Those tools help. They don't replace somebody who knows why a particular structure won't route, or why a clock-domain crossing will eventually bite you.
Clean sheet vs cleanup
Clean-sheet FPGA design
This is the work I want. A customer brings us a problem early, before the architecture is locked, before the wrong device family has been chosen, and before somebody has committed to a clocking scheme that won't close timing. We make the right calls up front, the design comes together cleanly, and the customer ends up with hardware that works the first time and stays working. The work is hard, but it's rewarding, and as a matter of history that's the kind of FPGA work that has always paid the best.
FPGA cleanup work
This is the other half of the business. A customer has hired somebody — an internal team, a low-cost contractor, or a vendor that oversold — and gotten back a design that doesn't meet timing, doesn't fit the device, doesn't behave on real hardware, or all three. By the time we're called, the schedule is gone, half the budget is spent, and a good chunk of the original architecture has to be thrown out. We've also had cases where somebody comes to us and says, "We'd like you to design a BSP for this board we built," and we have to say, "Here are all the things you left out of the FPGA in ways that make a proper BSP impossible." Delivering that message never makes you popular. So we do this work — it still pays well — but we do it carefully, and not always with much enthusiasm.
The lesson, if there is one, is this: get somebody experienced involved before the board has been fabricated, not after.
When do you actually need a senior FPGA designer?
Not every embedded project needs one. You probably do if your project involves:
- High-speed serial interfaces (PCIe, multi-gigabit transceivers, custom SerDes)
- DSP-heavy signal processing that can't keep up on a CPU or GPU
- A soft-core CPU running inside the FPGA fabric
- Hard real-time control with sub-microsecond response requirements
- Mixed clock domains, especially across high-speed I/O standards
- Safety-critical or aerospace work where timing margin is non-negotiable
If none of those applies, an FPGA may well be overkill, and a microcontroller plus a small CPLD will do the job for a fraction of the cost. Part of what we do, in the early conversations with a customer, is figure out whether they need us at all — and we'd rather tell them honestly that they don't, than take their money for a design they don't need.
Rent vs hire: the economics
A senior FPGA designer is expensive to hire full-time and hard to keep busy. Most product companies don't have a continuous pipeline of FPGA work. They have one critical project a year, or one every two years, surrounded by long stretches where that engineer would be doing things below their pay grade. And really good FPGA designers, in my experience, do not stay long in roles where they're underutilized.
The model that works for most of our customers is straightforward: keep your embedded software and PCB people on staff, and rent specialist FPGA expertise for the projects that actually need it. You pay top dollar for a few months instead of a six-figure salary plus benefits for somebody who's underutilized eleven months out of twelve.
That is, more or less, the model Focus Embedded is built on. A handful of customers who understand how scarce this skill is bring us their hardest FPGA work first and pay accordingly. Others find us only after a project has gone sideways. Either way the work gets done by somebody who started at the transistor level and never stopped thinking that way, even when the language on the screen is SystemVerilog.
How to engage us
If you're starting a project that needs FPGA work and you don't have a senior FPGA designer on staff, the cheapest moment to bring us in is before the architecture is frozen. Get the device family, clocking strategy, and partitioning right the first time and the rest of the project costs less. A short paid architecture review is usually enough to save a lot of money downstream.
If you're already past that point and something isn't working, we do cleanup work too. Just expect us to be honest about what has to change.
Contact Focus Embedded about your FPGA project →
Frequently Asked Questions
Q: How do I know if my project actually needs an FPGA rather than a microcontroller?
If your signal-processing, latency, or parallel-I/O requirements can't be met by a modern microcontroller or SoC, then you probably need an FPGA. If they can, you don't. A short paid architecture review with a senior FPGA designer, before you commit, is usually worth what it costs.
Q: What does it cost to clean up a failed FPGA project?
Honestly, it depends on how much of the original architecture survives review. Sometimes timing problems can be fixed with retiming and pipeline adjustments and a few weeks of work. Sometimes the chosen device family is wrong and the design has to be redone from the bottom up. A short paid review answers the question quickly, and we'll tell you straight which case you're in.
Q: Can AI-assisted FPGA design tools replace a senior designer?
For routine designs and standard IP integration, the modern tools are very capable, and they've gotten dramatically better over the last few years. For high-speed, mixed-clock, or DSP-heavy work, they accelerate an experienced designer's output but they don't replace the judgment that determines whether a design will actually close timing or behave in production.
Q: Do you work with Xilinx/AMD, Intel/Altera, Lattice, and Microchip FPGAs?
Yes — all of them. Picking the right device family is part of the architecture decision, and it ought to be driven by what the project needs, not by which vendor somebody has a preferred relationship with.
Q: Do you do BSP and firmware work as well as the FPGA design?
Yes. Most embedded projects need at least two of FPGA design, board support package, and embedded firmware, and we coordinate them so that the interfaces between the fabric and the software actually work the first time. (BSP work in isolation can be tricky — see the comment above about being honest with customers about gaps in their board designs.)