This page is the second in a series of five pages about becoming a professional FPGA designer. On this page, I'll go through the different theoretical topics I think every FPGA designer should master, and also attempt to explain why I believe each one is important.
Logic Theory
Knowing the theory is not a luxury. It's the foundation on which everything else is built, even if it doesn't always feel that way while you're fighting with a development tool that refuses to cooperate or when the electronics seem to have their own way.
An FPGA engineer needs to be able to envision how the Verilog he writes is implemented as logic elements. Not in full detail, but well enough to tell which parts will slow down the design and limit the clock frequency, and which parts are going to gobble up a lot of logic resources. This is crucial, for example, for knowing when a task needs to be pipelined by adding registers. Pipelining usually complicates the design, but it's often the only way to reach the required speed. Other important design decisions rely on this ability.
It's also crucial for following what the synthesizer has done, and why. For example, knowing what the synthesizer tends to optimize away allows you to write Verilog code that is both readable and efficient. If you don't know what the synthesizer will do with your code, you're writing blindly.
So what topics are relevant? I suggest starting with this checklist. I'm not implying it covers everything.
- Gates (AND, OR, XOR, etc.), flip-flops, ROMs/RAMs, LUTs and muxes. These are the basic building blocks of everything, used in datasheets, user guides and when the tools convey what they've done. Not complicated, and you'll be lost without this.
- Combinatorial vs. sequential logic, and the principles of synchronous design. These are central concepts in every logic design.
- State machines. Understand how those diagrams turn into Verilog code, and have a good feel for how state machines work. Almost always, when logic behaves like software in the sense that it does something sequential that depends on input signals, there's a state machine behind it.
- Boolean algebra. Things like x && (y || z) = x && y || x && z, and De Morgan's law: !(x && y) = !x || !y. These are often used to simplify code. It's like knowing the basics of algebra.
- Fixed-point arithmetic, two's complement, overflow and saturation. How addition and subtraction are implemented. Understand the issue with the carry's propagation delay. A superficial look into how a multiplier is implemented is also recommended. Arithmetic operations are everywhere in a logic design, and you need to know how these behave exactly, how many resources these operations take up, and to what extent they slow down your design.
Logic paradigms and techniques
Besides knowing pure logic theory, there are a few topics required to write code that works reliably and efficiently, and behaves the same in hardware as it does in simulation. This is almost a given in the software world, but FPGA designers live in a different territory. Every FPGA designer must have these topics in mind, all the time.
The RTL paradigm, Register Transfer Level, is the central idea. In short, it means that everything that stores a value changes that value only in response to a clock edge. An asynchronous reset can be the one carefully controlled exception. Once you internalize this way of thinking, you have a good chance of getting it right.
Reset is a topic of its own. Synchronous versus asynchronous resets, and reset synchronization, are things you need to sort out in every design you work on. If you don't, your design will work fine most of the time, with sporadic hiccups every now and then. You will have a working system to deliver, but you won't be able to release it because of these sporadic failures. Your project will become increasingly late, and you will have no idea what's wrong. Poor resetting is not what comes to mind in these situations. You really want to understand this topic in depth. There's a short series of pages on this topic on this site.
Closely related is the question of clock enables versus gated clocks. These are in essence two different techniques for making the logic design not run on every clock cycle. The FPGA has dedicated resources for clock gating, but doing it wrong is a fine way to create mysterious problems. The safe habit is to use clock enables in your logic, but if you want to take advantage of the lower effective clock rate to relax the timing constraints, you may run into trouble as well.
State machine encoding deserves a mention too. Binary, one-hot and Gray encoding all have their place, and the choice has implications for both speed and resource usage. The tools will often choose for you, but you should know what the options mean. In particular, one-hot coding is excellent for large state machines. But if the state machine isn't reset properly, this coding can make it do things that are impossible according to the Verilog code. It looks like witchcraft inside the FPGA or a bug in the synthesizer, but no, it's one-hot coding and a poorly applied reset.
And finally, pipelining. It's not just a technique, it's a way of thinking. Adding a register is trivial, but the fact that the data processing spans several clock cycles creates a whole host of possible issues. For example, what should the receiver of this data do before the first pieces of valid data have arrived? What happens if input data doesn't arrive continuously, and the pipeline needs to freeze temporarily? How is that done without a single clock enable with a huge fan-out to all logic elements in the processing chain?
Every scenario requires a different kind of pipeline design, and each has its own challenges and quirks.
Digital design
As mentioned above, an FPGA designer needs to envision how Verilog ends up as logic elements in the FPGA. Let's take a concrete example.
Suppose I write a plain "assign x = a + b;" in Verilog. How is that adder implemented? Does this particular FPGA use special tricks to implement an adder? Does it use a dedicated hard block, a DSP block, for example? And if it does, how much does that help if the adder's result is a register rather than a wire? What happens if I add three numbers, as in "assign x = a + b + c;"? Does the FPGA have any shortcut for adding three numbers? The answer is most likely no, so this will be implemented as something like (a + b) + c. Two logic operations in cascade can slow down the design considerably. But how does it work on your specific FPGA?
Being aware of what resources are available in the specific FPGA you're targeting is important. It shapes the way you write Verilog, so that the synthesizer can create fast and efficient logic. The synthesizer isn't a magician that solves any problem you throw at it. If you write Verilog wisely and know its limitations, you get a design that consumes few resources, uses relatively little power, and works at a high clock frequency. That comes with experience, and digital design knowledge speeds up the process of gaining this kind of wisdom.
In practice, we're usually forced to look into the logic implementation inside the FPGA only when solving timing closure problems, because there's a need to understand why the result was slow or took too many resources. So we go through the small details of the logic implementation, one by one, looking for a waste of time or resources. But it's also a good idea to analyze the results voluntarily every now and then, just to gain more knowledge, or to verify that nothing crazy has happened. This pays off in the long term.
Know your FPGA
Another aspect of envisioning how Verilog turns into logic elements relates to the basic logic resources. That means knowing the building blocks of the FPGA, and knowing what they're good for.
First, the structure of an FPGA itself: The basic elements, the CLBs, and the slices of your FPGA. When writing Verilog code, it's a huge advantage if you can envision how these elements are used to implement the required logic. This way, you can tell if what you're writing may become the bottleneck in the design's timing closure, or if this code snippet will never bother you again.
Most FPGAs are structured in more or less the same way. All of them have a way to efficiently implement arithmetic adders, multiplexers, demultiplexers, and so on, because these functions are used a lot. For example, many FPGAs have multipliers as a hard block, allowing operations like "assign x = a * b;" to run at a fast clock frequency.
But the exact features of these multipliers may differ. On some FPGAs, the operands of these multiplier blocks are 18-bit signed integers. So a multiplication with operands of this width or less will run at a much higher clock frequency than if one of the operands is 19 bits wide. That's another example of why it's important to know the FPGA's logic blocks: A single extra bit can reduce the clock frequency considerably. Note that for a different FPGA family, it can be a completely different game with other operand widths.
Routing resources matter too. The logic elements are only half the story; the wires between them are the other half. Quite often, a design can't reach its clock frequency because the wiring gets congested and therefore slow. This is something to think about if you intend to use your FPGA at near 100% of its logic capacity, and have a lot of wide data buses in your design. Some routing resources ("wires") in the FPGA are fast, others are slower. When the fast ones run out, the entire design slows down.
You should also understand FIFOs and BRAMs. These are the memory resources inside the FPGA, and you'll use them constantly, both for storing and buffering data and for crossing between clock domains. Knowing how to work with a FIFO is bread and butter. There's a series of pages on this website on this topic.
Clocking resources are their own little universe: PLLs, clock buffers, and the global and regional clock networks. The PLL is the component that turns an incoming clock into the clocks your logic actually needs. It multiplies and divides frequencies, and allows phase shifting as well. It's also important to know which clocks are phase aligned and which ones are not. For example, suppose a PLL emits two clocks, and one has twice the frequency of the other: Is it safe for a register clocked by the first clock to sample the output of a register clocked by the second clock? It usually is, but it depends on whether these two clocks are phase aligned. But you must know how to check that this is indeed the case. There's a page on this site discussing this topic.
Next, we have the I/O block resources. In designs that involve high-speed I/O signals, such as DDR and SERDES, you need to understand what the I/O blocks can do for you, and how they allow I/O at data rates much higher than your design's clock frequency. They can also be configured to assist with impedance matching by adding a termination and other low-level electronic functions.
And if you need data rates above one gigabit per second, Multi-Gigabit Transceivers (MGTs) are for you. This is a relatively advanced and complicated topic, and not something for beginners, unless it's required for a specific project. There's a series of pages on this website about that topic too.
And one last and somewhat boring topic: Configuration memory and bitstream loading. After you're done designing, you don't want to load the bitstream into the FPGA from the computer every time. So the FPGA can load it by itself from flash memory. Or from an SD card. Or a separate component on the board can push the bitstream into the FPGA, a solution often chosen when there is a separate processor on the board.
There's nothing fun about the techniques for loading the FPGA, but if you're working in a small team, you'll be responsible for this too. And there are often requirements on how soon the FPGA will be up and running after the board has been powered on. That will be for you to figure out.
Another reason to be aware of this topic is that the FPGA is often loaded automatically from flash memory when it powers up, particularly on evaluation boards. To make it even more tricky, FPGA boards often have more than one possible memory source to load the bitstream from. Very long debugging sessions happen when people aren't aware that an old version of their project is loaded into the FPGA: Whatever changes they make in the design, the FPGA behaves the same, because they update the wrong flash memory every time.
Timing
First, a short word about what timing is (in the context of a logic design). To make a long story short, every digital signal inside and outside the FPGA must be electrically stable during specific time spans, usually in relation to clock edges. Otherwise, the logic's behavior becomes unpredictable. The development tools ensure that these timing requirements are satisfied wherever needed. But in order for this to happen, we must give these tools specific information, and do so very accurately. In addition, the logic design must also be made in a way that allows the tools to meet the timing requirements. This is what timing is about in a nutshell.
Timing is possibly the most difficult part of being an FPGA designer. It's also the most important domain to really master and implement properly. Unfortunately, it's quite easy to neglect this topic and still get a design that works fairly well, or maybe just good enough to make it look like you're almost done. Everything works fine, but there seem to be supernatural forces in the FPGA that cause sudden failures when there is a full moon. I call this mindset "black magic mode", and there's a separate page about it.
On a good day, an FPGA design written without timing in mind can be fixed easily by adding a few timing constraints. Sometimes almost everything needs to be done from scratch, because when the correct timing requirements are enforced, the development tools can't make it work at the required clock frequency. So the Verilog code itself needs to be refactored.
And on a really bad day, the PCB needs to be partly redesigned, because it's impossible to ensure that all physical signals on the board have a stable voltage within the time slots they have to be stable. A proper timing analysis before the PCB was signed off for production would have revealed that, but if that was neglected, the hardware may not be up for the job.
But if you do the timing carefully and correctly, the FPGA is the most reliable component in the world. A lot of FPGA designers are afraid to make the slightest change in the design, afraid every time a new batch of FPGA chips is used in production. Crazy cooling is applied, because horrors if the FPGA gets a bit warm. I say: Be sure to do the timing right, and forget about all worries.
Do you need to master this perfectly from day one? I would actually say yes. In principle, I would agree that if you're in a team of FPGA designers, and only one is really good at timing, that's enough. Be that one FPGA designer, for one simple reason: Odds are that nobody else will.
There is quite a long series of pages about timing on this website, so it's a bit pointless to elaborate on the topics here. So here's just a brief list of topics I think every FPGA designer should be comfortable with:
- Propagation delay, tsu and thold
- Writing timing constraints: Period constraints, unrelated clocks, timing exceptions, false paths, etc.
- Reading timing reports: Setup, hold, slack, clock domain interaction, critical paths.
- Four-corner timing analysis
- Clock frequency and jitter, and jitter's implications for timing closure, loss of lock, poor signal sampling, jitter propagation in PLLs (degradation of MGTs due to jitter, if you have such components in your design).
- Clocking resources: The clock buffer, the clock distribution tree, clock skew, how the PLL compensates for the clock tree's delay etc.
- Clock domain crossing. There is a series of pages specifically on this topic.
Electronics
The FPGA is an electronic device, and FPGA design is a field of expertise within Electrical Engineering. And it's the kind of electrical engineering dealing with schematics and datasheets, voltages and currents, signal integrity and impedance matching. This is the knowledge every PCB designer must have, and an FPGA designer's life is significantly easier if he has this kind of knowledge too.
It's common that the FPGA designer is assigned to ensure that the FPGA interfaces correctly with the other components on the board. In fact, it's not rare that PCB designers connect everything they can to the FPGA in order to absolve themselves of the responsibility for making these components work. The FPGA designer is therefore often required to have a profound understanding of how components interface with each other on a PCB. It's often the FPGA engineer who needs to point out possible signal integrity issues that need to be addressed on wires that switch at high frequencies.
When a new PCB is being designed, the team's FPGA designer is usually required to approve the design, i.e. to check that the connections to the FPGA are correct. Not all of the FPGA pins are adequate for all purposes, and sometimes it's required, or significantly better, that certain connections belong to a particular group ("bank") of the FPGA pins. These are things the FPGA designer must master, or at least have a solid opinion about.
It's not rare that FPGA designers are former PCB designers. The path from board design to FPGA design is a natural one, and those who have walked it have a distinct advantage. Even if the PCB designer is responsible and designs a perfectly good board, the FPGA designer still needs to understand the challenges with high-speed signals on a PCB, in order to configure the FPGA's I/O blocks properly.
As I've mentioned earlier, not all FPGA engineers work directly with electronics. Some are limited to developing internal logic, what I called "processing logic", and sometimes companies hire an engineer just to do simulation and verification. But most of us do work with electronics directly, and in that case, some related knowledge is required.
It starts with the absolute basics: Voltage, current, resistors and Ohm's law. This is how digital signals move from one component to another. It's also a good idea to understand capacitance and how a capacitor is charged and discharged. This allows you to understand how current and capacitance influence switching speeds and power consumption.
You should be able to read schematics: ICs, modules, inductors, voltage supplies, digital and analog ground. MOSFETs and bipolar transistors also appear sometimes, and you should at least recognize them. It doesn't hurt to get an idea of how a MOSFET transistor behaves.
You will also spend a lot of time reading datasheets. The most difficult and important part is to translate timing specifications in the datasheet into timing constraints and/or a suitable I/O design on the FPGA. Board skew is something you may need to take into account in your I/O timing.
But you will also be responsible for making sense of the voltage and current specifications in the datasheet, and configuring the FPGA's respective I/O block with the correct voltage standard: Single-ended and differential interfaces, LVCMOS, SSTL, LVDS, and so on.
Do all FPGA designers really do this properly? The answer is no. It's quite common to see designs that shouldn't work at all because of their electronic mishaps, and yet they seem to work perfectly. It's not rare that one component's output pin feeds the other component's input pin with a voltage that is above the absolute maximum rating. It's a huge mistake, of course, and the component receiving the excessive voltage can in principle burn out at any time, according to the datasheet. And yet, everything works forever and ever. Until it suddenly breaks, and clever people find silly excuses for why that happened.
I'll also add a short list of topics that are definitely the responsibility of the PCB designer. But when this person is less than excellent, it helps if the FPGA engineer understands something about them too:
- Power supplies and voltage regulators.
- Clock oscillators, reference clocks, and jitter.
- Signal integrity: Impedance matching and terminations, reflections, crosstalk, EMI.
- Thermal considerations.
So what does an FPGA designer really need to know from all of this? What is crucial from the beginning? It's actually hard for me to tell. The better team you have around you, the less electronics you need to know. But I would say that any FPGA designer should be able to read schematics and be able to understand what is connected to the FPGA, and more or less understand why it's connected in that specific way.
This concludes the second page in this series. The next page moves on to practical skills, in the same spirit as above.1