One of the best management lessons I ever learned came from a CEO who frequently said:
“You need rules so you can have exceptions.”
At first, it sounds contradictory. In reality, it’s a practical principle that applies to almost every engineering discipline.
Without clearly defined rules, teams waste time debating standards, reviewing subjective decisions, and interpreting requirements differently. On the other hand, rigidly enforcing every rule without considering real-world circumstances can create unnecessary work, increase costs, and slow development.
Successful engineering organizations find the balance between consistency and flexibility. The same principle applies directly to RTL linting and design signoff.
Why RTL Linting Matters
RTL linting remains one of the most effective and widely adopted verification technologies available today. Long before simulation begins or synthesis is run, linting provides designers with immediate feedback on coding issues, structural problems, and potential implementation risks.
By analyzing RTL statically, lint tools can identify issues such as:
- Coding style violations
- Simulation versus synthesis mismatches
- Clock Domain Crossing (CDC) issues
- Reset Domain Crossing (RDC) issues
- Improper clock and reset implementations
- Finite State Machine (FSM) problems
- Latch inference
- Unconnected or undriven signals
- Naming convention violations
- Constraint-related issues
Because static analysis does not require test vectors, these checks can be performed quickly and repeatedly throughout development. The result is cleaner RTL entering simulation, synthesis, place-and-route, and timing closure.
The earlier defects are identified, the less expensive they are to fix.
The Challenge: Not Every Rule Fits Every Design
Despite its value, linting often receives criticism for generating too many warnings or false positives. In reality, the issue is rarely the lint engine itself. The challenge is usually a lack of clearly defined design standards.
Every organization has unique requirements. Some teams standardize on:
- Positive-edge or negative-edge clocking
- Synchronous or asynchronous resets
- Big-endian or little-endian conventions
- Specific naming conventions
- Approved design architecture
- Company-specific coding guidelines
Without agreed-upon standards, designers receive inconsistent feedback and signoff becomes subjective.
This is why successful lint deployments begin with a well-defined rule package.
Building a Rule Package
A rule package is simply a curated collection of checks that reflects an organization’s design methodology and quality objectives.
Industry standards such as STARC, DO-254, and aerospace-specific methodologies provide useful starting points. However, most organizations eventually customize these rule sets to reflect their own design practices, regulatory requirements, and product architectures.
For example, aerospace and defense projects often require additional checks focused on reliability, traceability, and long-term maintainability. Organizations such as the European Space Agency (ESA) have developed specialized rule packages that address requirements including:
- FSM unreachable states
- Complete reset coverage
- CDC correctness
- Latch prevention
- Hard-coded constraint detection
- Unconnected signals
- Incomplete sensitivity lists
- Register implementation requirements
The goal is to establish a consistent definition of what constitutes high-quality RTL.
The Importance of Exceptions
Once standards are established, designers can evaluate results with confidence.
This is where exceptions or waivers become essential. No matter how comprehensive a rule set becomes, real-world designs will always contain situations where a violation is technically correct, architecturally required, or unavoidable due to external constraints.
- Third-party IP may not follow internal naming conventions.
- Legacy blocks may implement structures that are known and accepted.
Certain timing behaviors may be fully understood by the design team but difficult for static analysis to evaluate correctly. Treating every violation as equally important creates noise and wastes engineering effort. Instead, mature verification flows distinguish between issues that must be corrected before signoff, and issues that are understood, documented, and intentionally accepted
Every waiver should include clear justification explaining why the exception exists and why it does not represent unacceptable risk. This documentation becomes invaluable during design reviews, audits, certification efforts, and final signoff discussions.
Measuring Progress Toward Signoff
Effective signoff is more than a single pass/fail report. Engineering teams need visibility into how quality evolves throughout the project lifecycle. Tracking trends in errors, warnings, and waivers across multiple analysis runs helps teams determine whether the design is converging toward signoff readiness or accumulating technical debt.
Project managers gain visibility into verification progress. Design leads gain confidence in design quality. Verification teams gain a repeatable, auditable process for demonstrating readiness. Most importantly, organizations create a common framework for discussing risk.
Better RTL Starts with Better Standards
RTL defects originate from many sources: evolving requirements, aggressive schedules, process gaps, design complexity, and simple human error. Static RTL signoff cannot eliminate every bug. What it can do is establish a disciplined framework that identifies issues earlier, enforces consistent engineering practices, and documents acceptable exceptions.
That brings us back to the original lesson: You need rules so you can have exceptions. Without rules, signoff becomes subjective. Without exceptions, signoff becomes impractical. The most successful design teams understand that quality comes from balancing both.
By combining comprehensive RTL analysis with disciplined waiver management, engineering organizations can reduce risk, improve productivity, and accelerate the path from RTL development to final signoff.
To learn how Blue Pearl Solutions helps FPGA teams implement advanced RTL signoff methodologies, request a demonstration of the Visual Verification Suite+.