This page is the first in a series of pages about timing.
The reward is peace of mind
The topic of timing, and timing constraints in particular, is a huge challenge to the FPGA designer. It's not just that timing is difficult to understand. The real challenge is to overcome the temptation to ignore this entire topic while working on an FPGA design, because everything works properly. It's all too easy to fall in the trap of being satisfied with the design when there is no visible problem.
It's not unusual to hear FPGA designers say that they are aware that their design is lacking with regards to timing, but the heck with that, the electronics works like a clockwork. And indeed, making sure that the timing is done properly may seem like a waste of time at that moment. A manager who is eager to continue developing new features is not likely to be happy about a couple of weeks with no apparent progress in the project. In fact, making a proper examination of the design's timing can discover problems that may be difficult to solve. To people from the side, this may look like inventing problems that don't exist, and then waste precious time solving them.
The truth is that many times, the strategy of ignoring timing pays off in the short term. But quite often, the lack of proper attention to this topic leads to the most annoying problems, and they tend to pop up in the most annoying moments. For example, the electronics may fail once in several hours during the final acceptance tests, maybe when the system is tested in the full temperature range. Or even worse than so: Complaints from customers begin to arrive several years after the product has been released. After a frantic effort to figure out the reason for these complaints, it turns out that the FPGAs in these products were manufactured in a different batch. So even though all FPGAs meet the requirements in the datasheet, differences in their silicon caused the new FPGAs to behave slightly differently.
FPGAs have earned themselves a bad reputation because of incidents of this sort. However when the timing is done properly, you can be quite sure that things of this kind don't happen. FPGAs are extremely reliable when the design has been done correctly.
So do yourself a favor, and take the time to learn the topic of timing, and then be sure to always make a full use of this knowledge. Doing this will save you the constant fear that something unexpected will happen to the design if you change anything. You will also save yourself the endless chase after bugs that appear and disappear. And more than anything, you'll get used to thinking about the FPGA as a dependable and rock-solid component.
The importance of timing constraints
The logic in an FPGA can work reliably only if the timing requirements are met on each and every sequential element in the logic design. To ensure this, all possible paths must be examined. Even with a simple logic design, it's impossible to make all these calculations by hand.
It's therefore the tools' duty to ensure that all timing requirements are met. For this to be possible, the tools must have received all information that is needed to make the necessary calculations. For example, the tools need to know the frequencies of all clocks as well as how external components behave regarding timing. This information is given to the tools with timing constraints, which usually consist of a text file that has a special syntax.
If the timing constraints are written incorrectly, or if they don't cover all necessary information, the tools have no way to ensure a reliable operation of the logic design. The tools rely on the information that is given to them in the timing constraints, so if this information is incorrect or partial, so are the timing calculations that the tools make. Poorly written timing constraints is a common reason for unreliable behavior of the FPGA.
So the unwritten agreement with the tools is like this: We tell the tools everything they need to know about the timing, and the tools make sure that there are no timing violations in the design.
But sometimes the tools fail to avoid timing violations. When this happens, there is a warning message from the tools that says so. This is just a warning and not an error, so the FPGA tools continue to create a bitstream file that can be loaded into the FPGA. It's therefore important to always verify that the tools confirm that the timing constraints have been achieved. This confirmation usually takes the form of a message like "All timing constraints are met".
But it's not only about timing constraints
The unwritten agreement between you and the FPGA software is actually even more extensive: You'll follow several rules on what the FPGA design should look like, and the tools make sure that the FPGA won't fail. But if you break the rules, the tools retaliate.
Getting the timing right is a significant part of these rules. And timing is not just a matter of writing timing constraints. There are three separate aspects to be aware of.
The first aspect is the logic design itself, i.e. the Verilog (or VHDL) code. There's of course the obvious requirement that the logic should be "fast" enough (or more precisely, the logic design should allow the clock to work at the desired frequency). On top of that, there are several other things to keep in mind:
- The fundamental rules for proper Verilog (or VHDL) must be followed, in particular the RTL paradigm. Otherwise, the tools will not be able to enforce the timing constraints on the logic that the synthesizer generates.
- Proper techniques are used when in clock domain crossings (more information here).
- The clocks must be organized to avoid confusion. In particular, it's important to avoid unintentional clock domains crossing.
The second aspect is to write timing constraints. Sometimes this part is really easy, and sometimes it requires careful work. It's a common mistake to copy timing constraints from a different design (in particular just one period constraint), and think that the work is done.
The third aspect is to generate and read the timing reports in order to ensure that the tools have fulfilled their purpose, so they guarantee that the design works reliably. This is the most difficult part, mainly because this task requires an understanding of the how the FPGA works inside: The timing reports are written in terms of the FPGA's smallest building blocks. It's therefore difficult to reach any useful conclusion from these reports without such understanding of the FPGA.
People usually read the timing reports in order to solve a problem, in particular when the tools fail to achieve the requirements in the timing constraints. The process of solving a problem like this is called timing closure. The most common problem is that a clock's frequency is too high for the logic design (one can likewise say that the logic is too slow for the clock).
As already mentioned, it's highly recommended to occasionally examine the FPGA design's timing, even when the timing constraints are achieved and everything works perfectly. This means in particular to check the timing reports, but also to verify that the timing constraints accurately reflect the logic's needs. The difficulty is that such a checkup isn't rewarding in the short term: This checkup requires time and effort, and ends with either no result, or the discovery of a problem. So if the checkup was fruitful, it actually means more work that solves a problem that nobody can see.
How these pages about timing are organized
These pages focus on the second and third aspects of the unwritten agreement between you and the FPGA tools: Writing timing constraints and reading the timing reports. These skills require theoretical knowledge as well as practical tools.
The practical aspects of timing constraints are relatively easy to learn. The difficult part is to understand their exact meaning and influence on the design. The next page in this series goes through the basic theoretical concepts. In the pages that follow, the discussion about theory continues with the help of several examples of timing reports. The whole story is in the small details of the timing analysis.
The two pages that follow the next page discuss the most important and most useful timing constraint: The period constraint. These two pages contain a detailed discussion about the timing reports because of their importance.
The next two pages discuss timing closure. It may be a bit early for this topic, but it explains the purpose of the topics to follow: Five pages about timing constraints (in the SDC syntax) that relate to the logic fabric. This is followed by two pages about I/O timing constraints.
The last page in this series is dedicated to the inspection of an existing design. There is nothing new in that page. Rather, it repeats the topics that have already been discussed. But this time, as a list of things to examine.
The topics are presented in an order that allows reading this series of pages from beginning to end. But all topics are related to each other, so there are a lot of references among the pages.
The best place to continue from here is the next page. It never hurts to look into the timing theory.