FPGA Design Rule Checking: Methods That Catch Errors Before They Hit Hardware
Design rule checking is the stage most FPGA developers skip or rush through, and it is exactly the stage that catches the bugs nobody wants to find during board bring-up. A missing constraint, an unconnected reset, a signal with no load — these things do not show up in simulation. They show up when your board does not boot, when your JTAG chain fails to initialize, or when a timing path that should have been clean suddenly fails at 85 degrees Celsius.
DRC is not optional. It is the last line of defense between your RTL and a working board. This article covers the methods that actually work in practice, not just the theory.
What Design Rule Checking Actually Covers in an FPGA Flow
DRC in the FPGA context is not a single check. It is a collection of independent verifications that each target a different class of error. Most teams run all of them, but the order and emphasis matter.
The first layer is structural DRC. This checks whether your design connects to the physical pins correctly. Are all top-level ports assigned to actual package pins? Are there any unconnected outputs? Are there inputs with no driver? These errors are embarrassing because they are completely preventable, yet they show up in almost every first revision of every board.
The second layer is timing DRC. This is where things get serious. The static timing analyzer checks every path in your design against the clock constraints you provided. If you forgot to constrain a clock, or if you constrained it to the wrong frequency, the tool will either report false violations or, worse, miss real ones.
The third layer is electrical DRC. This checks whether your I/O standards match the board hardware. If you assign an LVCMOS33 standard to a pin that is wired to an LVDS receiver, the tool will not catch it unless you run I/O rule checking. This is the kind of bug that fries chips.
Static Timing Analysis: The Core of FPGA DRC
Timing is where most FPGA designs live or die. A design that passes functional simulation can still fail timing by hundreds of picoseconds, and that failure will manifest as data corruption at speed.
Setting Up Clock Constraints the Right Way
The number one cause of timing DRC failures is not bad logic. It is missing or incorrect clock constraints. If you do not tell the tool what your clock frequency is, it cannot analyze timing. If you tell it the wrong frequency, it will either over-constrain or under-constrain your design, and both outcomes are bad.
Define every clock domain with a create_clock constraint. Specify the period, the waveform, and the uncertainty. For generated clocks, use create_generated_clock so the tool understands the relationship between the source and the derived clock. For false paths, mark them explicitly with set_false_path. Do not rely on the tool to guess which paths are irrelevant. It will not guess correctly.
Handling Multi-Corner Timing Analysis
A single timing run at typical process, voltage, and temperature conditions is not enough. FPGA designs must be checked at multiple corners: slow-slow (worst-case process, highest voltage, highest temperature) for setup timing, and fast-fast (best-case process, lowest voltage, lowest temperature) for hold timing.
Running multi-corner analysis triples or quadruples your compile time, but it catches the violations that only appear at extremes. A path that meets timing at room temperature may fail at 85 degrees. A path that meets setup may fail hold at low voltage. Skipping corners is a gamble, and the odds are against you.
I/O Rule Checking: The Most Neglected DRC Layer
I/O rule checking is the DRC layer that almost nobody thinks about until it is too late. Every FPGA pin has electrical rules: maximum drive strength, slew rate limits, input threshold voltages, and I/O standard compatibility. If you violate these, the chip may work in the lab and fail in the field.
Matching I/O Standards to Board Hardware
Every pin on your FPGA must be assigned an I/O standard that matches the external circuit. A pin driving an LVDS pair must use a differential I/O standard. A pin receiving a 1.8V CMOS signal must use an I/O standard with 1.8V thresholds. The tool will flag mismatches if you enable I/O rule checking. Do not disable this check.
The common mistake: assigning the wrong voltage standard to a bank. All pins in a bank share the same VCCO voltage. If you mix 3.3V and 1.8V standards in the same bank, the tool will either reject the design or, worse, accept it and you will damage the I/O cells when you power the board.
Checking for Unused Pins and Floating I/Os
Unused FPGA pins are not harmless. A floating input pin can pick up noise and toggle randomly, which increases power consumption and can couple into adjacent signals. Every unused pin should be assigned a defined state: either driven to a known value or configured as a pull-up or pull-down.
Most FPGA tools have a rule that flags any top-level port without a load. This catches outputs that you forgot to connect. But it does not catch inputs that you left unconnected. For those, you need to manually review the pin assignment report or enable a specific unused pin check.
Linting and Code-Level DRC: Catching Bugs Before Synthesis
Linting is DRC at the RTL level. It does not check timing or electrical rules. It checks whether your code follows synthesizable patterns and whether there are constructs that will cause synthesis to fail or behave unexpectedly.
RTL Linting Rules That Matter Most
The most critical lint rules are: no combinational loops, no incomplete sensitivity lists, no multiple drivers on a net, and no asynchronous resets that are not synchronized. These four categories account for the majority of synthesis failures that linting can catch.
A combinational loop is the worst offender. The synthesis tool will either refuse to process the design or will break the loop by inserting a latch, and neither outcome is what you want. Linting catches this before you even start synthesis.
The Difference Between Linting and Simulation
Simulation verifies functional correctness. Linting verifies structural correctness. A design can pass simulation with zero errors and still fail linting because of an incomplete case statement or an unconnected output. The two tools are complementary, not interchangeable.
Run linting on every commit, not just before release. The cost of fixing a lint error at commit time is minutes. The cost of fixing the same error after synthesis is hours, because the tool error messages point to generated netlist logic, not your source code.
Methodology: Building a DRC Flow That Actually Works
Having the right checks is not enough. You need a flow that runs them in the right order, with the right severity levels, and with clear pass/fail criteria.
Layered DRC with Escalating Severity
Structure your DRC flow in tiers. Tier one is linting: these are code-level checks that should never be ignored. Tier two is structural DRC: unconnected ports, missing constraints, I/O mismatches. Tier three is timing DRC: setup and hold violations.
Configure each tier with a severity level. Lint errors should block the build. Structural warnings should flag for review but not block. Timing violations above a defined threshold should block, while marginal violations should generate a report for the timing team to review.
This tiered approach prevents the common problem where a single lint warning buries 47 timing violations, and nobody reads the report because it is too long.
Automating DRC in Your CI Pipeline
Manual DRC runs are unreliable. Someone forgets, or they skip a check because they are in a hurry, and the bug ships to the board. Automate every DRC step in your continuous integration pipeline. Every push to the repository should trigger linting, synthesis, and timing analysis.
The CI server should fail the build if any tier-one check fails. It should generate a report for tier-two and tier-three checks and post the results to a dashboard. This way, DRC becomes a gate, not a suggestion.
Common DRC Failures and How to Fix Them Fast
Some DRC violations appear so often that they deserve their own section.
Unconstrained clocks. The fix is simple: add a create_clock constraint for every clock in your design. If the clock comes from an external source, constrain the input port. If it comes from an internal PLL, constrain the PLL output.
False path errors on asynchronous resets. Asynchronous reset deassertion is a real timing path, but it does not need to meet the same timing requirements as data paths. Mark it as a false path or use a multicycle path constraint.
I/O standard conflicts within a bank. Move the conflicting pins to a different bank, or change the I/O standard on one of them. There is no workaround. The VCCO voltage is fixed per bank.
Latch inference from incomplete case statements. Add a default branch to every case statement. Even if you think every case is covered, add the default. The synthesis tool does not know your intent. It only sees incomplete logic.
Critical warnings about high fanout nets. A net that drives 500 flip-flops creates routing congestion and timing problems. Buffer the net with a dedicated clock buffer or a fanout buffer cell. Do not ignore critical warnings. They are the tool telling you that something will fail.
ChipApex is a global distributor of electronic components: ICs, semiconductors, passives & interconnects. Source active & obsolete parts with wholesale pricing, fast RFQ response, and worldwide delivery.Official website address:chipapex.com
