LINT & CDC

LINT & CDC

CONTENTS RTL Designers

 What is Lint & How it works
 Lint Tool Flow
 Common Lint Errors & Fixes
 What is CDC
 CDC Concerns
 MTBF Concept
 CDC Techniques

1
NAVANEETHAKRISHNAN
 LINT & CDC

What is Lint & How it works:

What is Lint:
 RTL Linting is a process that uses defined rulesets & policies which is applied to a
RTL design before simulation to verify whether the RTL code has followed the specified
design coding rules that prevent synthesis issues & functional bugs at an early stage.
 This process specifies the design rules needed specifically for synthesizable codes.

How it works:
 The Lint tool uses policies & rule sets and does a static code analysis of the RTL design.
 Rules are conditions that need to be checked on the RTL design.
 Once these rules are executed, if the design source code doesn’t conform to a rule, then a
violation will be reported.

2
NAVANEETHAKRISHNAN
 LINT & CDC

Why Lint:
 The main objectives are to clean RTL. It helps to ensure the functionality, reliability, and
performance of the ICs.
 Lint reduces the functional error, synthesis & simulation mismatch issues and improves the
readability of the code.

Key aspects of RTL Lint: What Happens if You Ignore Lint?

o Error detection (syntax, semantic issue) o Synthesis might fail or produce
o Coding guidelines (constant coding) incorrect logic.
o Standardisation (Industry standard o Unexpected latches, X-propagation, or
coding) combinational loops.
o Synthesis & Simulation mismatch o Longer debug cycles in simulation or
(Function discrepancies b/w them) during post-silicon validation.
o Uninitialized signals, ports, and o The design might fail CDC checks.
variables o May delay project milestones or
o Race around condition & timing issues tapeout.

3
NAVANEETHAKRISHNAN
 LINT & CDC

Lint Flow:

Design

Lint Tool Rules/Policy

Violation
Design Issues
Yes

NO

Next Stage

4
NAVANEETHAKRISHNAN
 LINT & CDC

Lint Tool Flow:

 Enabling lint setup

 Enabling/Disabling rules
 Analyze
 Elaborate
 Check lint
 Report lint

5
NAVANEETHAKRISHNAN
 LINT & CDC

Lint checks:
There are different checks as mentioned below:
 Basic syntax checks which are LRM compliant
 Semantics checks
o Incomplete case statement, missing default condition, missing else.
o Width mismatch between LHS & RHS including complex expressions.
 Synthesizability checks
o Non-synthesizable subsets
o Use of both clock edges
 Structural analysis
o Combinational loops
o Latches, tri-states in the designs.
o Unused gates
o Floating nets
 Formal lint
o Unreachable FSM states
o Missing FSM state transitions

6
NAVANEETHAKRISHNAN
 LINT & CDC

Common Lint Errors & Fixes:

Combinational Loop:
Definition:
A combinational loop is created when the o/p of a
Combinational logic is fed back into the same A
B
combinational logic without the involvement of a
Combo block
sequential element, such as a flip-flop. i/p o/p
Issue:
o Combo logic is an infinite loop. So, we can’t trace the timing.
o In a combinational loop, signal values oscillate or fail to settle.
Fix (How to avoid):
o By adding a flip-flop in the feedback path of the combo block.
o As the flip-flop works only, we give the clock. So, we will be having control over the
circuit.

7
NAVANEETHAKRISHNAN
 LINT & CDC

Flip-flop

B Flip-flop A
i/p o/p Clk
Combo block

Inferred Latch:
Definition:
o Latches are formed due to improper use of case statement & if-else statement in
combinational circuit.
o Like missing the default condition, any one of the inputs inside a case statement, and
missing else condition in the if-else statement. If the else part is mandatory for the design.

8
NAVANEETHAKRISHNAN
 LINT & CDC

Issue:
o Latch stores data only when a condition is false, unlike a flip-flop with proper clocking.
o Latches are level-sensitive, so race conditions and glitches will happen.
Fix (How to avoid):
o Assign all outputs in every if/else path
o Use default statement and assign all inputs to the output inside the case statement.

i0 0
0
i1 1
i1 1 Y
Y i2 2
i2 2
i3 3
i3 3

S1 S0
S1 S0

9
NAVANEETHAKRISHNAN
 LINT & CDC

Multi-driver issue:
Definition:
o The same output variable drives(assigned) by multiple inputs.
o In other words, when an output variable has two or more different
sources drive the same signal or net at the same time, which leads
to a synthesis issue.
Issue:
o In simulation, you’ll see x (unknown) on y due to conflict.
o During Synthesis Tool may throw an error or assume one block dominates
o Glitches, instability, and unpredictable behaviour will happen.
o May cause short circuits on the chip (if two strong drivers drive)
Fix(How to avoid):
o Use one always block per output.
o Use different variables to drive the output.

10
NAVANEETHAKRISHNAN
 LINT & CDC

Error Circuit: Fixed Circuit:

A A

En Y En Y

B B

Width/port size mismatch:

Definition:
o A width/port size mismatch happened when both LHS = RHS under the two scenarios:
 LHS < RHS
 LHS > RHS
o If the context of the issue is not resolved, then the tool will truncate or pad some bits in the
alignment under the above two scenarios.

11
NAVANEETHAKRISHNAN
 LINT & CDC

Consequence of width mismatch if the

tool automa cally takes care of two
scenarios:
Padding or zero(0) extension at MSB
for unsigned values at output =
(2’b10 4’b0010)
Sign extension at MSB for signed
values
at output = (2’b10 4’b1110)

12
NAVANEETHAKRISHNAN
 LINT & CDC

13
NAVANEETHAKRISHNAN
 LINT & CDC

Bit Overflow:
Definition:
Bit overflow occurs when the result of an arithmetic operation (like addition or multiplication)
exceeds the maximum value that can be represented by the available number of bits.
Issue:
o Incorrect result due to missing the MSB (overflow bit) due to wrong computation
o Simulation–Synthesis mismatch could happen, which may potentially lead to different
hardware behavior(data corruption)
o Hard-to-debug bugs in blocks, especially in adders, multiplication, counters, ALUs,
encoders, etc.
Fix (How to avoid):
o Increase Output Bit-Width:
Reason:
To store the full result, your output must be wide enough to hold the maximum value.

14
NAVANEETHAKRISHNAN
 LINT & CDC

Example:
input [3:0] a, b;
output [4:0] out; // a=15,b=15, out=30 → needs 5 bits
assign out = a + b; overflow can
compute

Note: Wrong approach

input [3:0] a, b;
output [3:0] out;
assign out = a + b; // a=15(1111),b=15(1111),out=30(11110) → Due to less bit
overflow, can't compute and the result is unexpected. Because output is 4 bits
out=14(1110)MSB was truncated.

15
NAVANEETHAKRISHNAN
 LINT & CDC

Unconnected Ports:
Definition:
Unconnected ports are inputs or outputs of a module that:
o Are not driven (input unconnected)
o Or not used (output unconnected)
o Or not connected in a top module or instantiation
Issue:
o Input May lead to X-propagation, unstable behavior, or latch inference
o Output Logic is computed, but wasted — could be optimized away
o Bidirectional May cause contention or incomplete I/O behavior
Fix (How to avoid):
o Always Connect All Inputs and Outputs
o Connect Unused Outputs to Dummy Wires

16
NAVANEETHAKRISHNAN
 LINT & CDC

Jaspergold Lint Warning Tags (Few):

[Link] TAG Name Severity Description Fix(Solution)

1 LAT_NR_BLAS Warning "In design-unit Missing else condition inferred a
apb_slave, latch is latch to avoid that make sure else
assigned by should be present while using an if-
blocking else if/if-else condition
assignments"
2 LAT_NR_MXCB Warning "The latches Missing else condition inferred a
'next_state' in the latch to avoid that make sure else
always block are should be present while using an if-
mixed with else if/if-else condition
combinational
logic"

17
NAVANEETHAKRISHNAN
 LINT & CDC

3 OPR_NR_UEOP Warning "Unequal length changes have made from LHS

operand in bit operand 'w1c_reg' is 32 bits, RHS
operator bit-wise operand '(! pwdata)' is 1 bits" to
and in design- LHS operand 'w1c_reg' is 32 bits,
unit/block RHS operand '(~pwdata)" warning
apb_slave. LHS got resolved.
operand 'w1c_reg'
is 32 bits, RHS
operand '(!pwdata)'
is 1 bits"

4 ARY_NR_LOPR Warning "logical negation changes have made from LHS

operator applied to operand 'w1c_reg' is 32 bits, RHS
multi-bit operand operand '(! pwdata)' is 1 bits" to
'pwdata' in design- LHS operand 'w1c_reg' is 32 bits,
unit apb_slave" RHS operand '(~pwdata)" warning
got resolved.
5 OPR_NR_UEAS Warning "Unequal length Changes have made from qs_count
operand in <= qs_count + 1'b1; to qs_count <=
arithmetic qs_count + 5'b1; warning has
operator addition resolved
in design-
unit/block

18
NAVANEETHAKRISHNAN
 LINT & CDC

apb_slave. LHS
operand 'qs_count'
is 5 bits, RHS
operand '1'b1' is 1
bits"

.tcl file:

# ------------------------------------------------------
# Clear Previous State
# ------------------------------------------------------
clear -all
#clear -all
#clear -all

# ------------------------------------------------------
# Set Report Directory
# ------------------------------------------------------
set report_path "/home/navaneethan/APB_Slave/apb_slave_lint_report"

if {![file exists $report_path]} {

19
NAVANEETHAKRISHNAN
 LINT & CDC

file mkdir $report_path

puts "Creating directory: $report_path"
} else {
file delete -force {*}[glob -nocomplain "$report_path/*"]
puts "Deleting old reports in: $report_path"
}

# ------------------------------------------------------
# Set Top Design
# ------------------------------------------------------
set design "apb_slave"

# ------------------------------------------------------
# Enable Required Rule Categories
# ------------------------------------------------------
config_rtlds -rule -enable -category {
CONNECTIVITY
BLACKBOX
NAMING
CODINGSTYLE
SIM_SYNTH

20
NAVANEETHAKRISHNAN
 LINT & CDC

SYNTHESIS
STRUCTURAL
RACES
}

# ------------------------------------------------------
# Disable Unwanted Rule Categories
# ------------------------------------------------------
config_rtlds -rule -disable -category {
FILEFORMAT
AUTO_FORMAL_ARITHMETIC_OVERFLOW
AUTO_FORMAL_BUS
AUTO_FORMAL_CASE
AUTO_FORMAL_DEAD_CODE
AUTO_FORMAL_OUT_OF_BOUND_INDEXING
}

# ------------------------------------------------------
# Analyze & Elaborate Design
# ------------------------------------------------------
set multi_mode_analysis true

21
NAVANEETHAKRISHNAN
 LINT & CDC

set_capture_elaborated_design on

analyze -sv -f /home/navaneethan/APB_Slave/filelist.f

elaborate -top $design

# ------------------------------------------------------
# Clock & Reset Configuration
# ------------------------------------------------------
clock -clear
clock pclk ;# Define primary clock
#clock -infer ;# Infer additional clocks (if needed)

reset -analyze
#reset -expression {!reset_l} ;
reset -expression {!presetn} ;

#get_clock_info -gui
#get_clock_info -load_all_related_info
#get_reset_info -all

# ------------------------------------------------------

22
NAVANEETHAKRISHNAN
 LINT & CDC

# SuperLint Engine Setup

# ------------------------------------------------------
set_superlint_prove_time_limit 1h
set_engine_mode {
H Bm J Q3 U L R Oh B K AB B4 D I AD M N AM G C AG G2 C2
}

# ------------------------------------------------------
# SuperLint Checks
# ------------------------------------------------------
check_superlint -init
check_superlint -extract
check_superlint -gated_clock
check_superlint -constant any

# ------------------------------------------------------
# Loop & Assumption Checks
# ------------------------------------------------------
set_loop_handling realistic
#check_loop -viewer
check_loop -global -classify

23
NAVANEETHAKRISHNAN
 LINT & CDC

check_assumptions -show -live

# ------------------------------------------------------
# Generate Reports
# ------------------------------------------------------
set_prove_report_task on

report -all -file "$report_path/${design}_lint_task_report.txt" -force -detailed

get_design_info -file "$report_path/${design}_lint_complete_design_info.txt" -force

check_superlint -report -violation -property -order category -detailed -include_design_build \

-file "$report_path/${design}_design_and_violation_lint_report.txt" -force -detailed

Makefile:
.ONESHELL:

RPT_DIR := APB

compile :
24
NAVANEETHAKRISHNAN
 LINT & CDC

irun -sv -access +rwc -f filelist.f

simulation :
simvision &

svn_update:
svn up ../../../

svn_info:svn_update
svn info ../../../

clean :
rm -rf fv jgproject genus.* --force

rpt_clean :clean
25
NAVANEETHAKRISHNAN
 LINT & CDC

rm -rf ../${RPT_DIR}_cdc/${RPT_DIR}_cdc_report \
../apb_slave_lint/apb_slave_lint_report \
--force

lint :
jg -superlint /home/navaneethan/APB_Slave/apb_slave.tcl &

What is CDC:
26
NAVANEETHAKRISHNAN
 LINT & CDC

Clock Domain Crossing occurs when data or control signals move from one clock domain to
another that is not phase- or frequency-aligned.
These domains may:
o Have different clock frequencies (e.g., 50 MHz ↔ 100 MHz)
o Have no fixed phase relationship
o Or even be completely asynchronous
Why is CDC critical?
Signals crossing between different clock domains can cause metastability, leading to:
o Data corruption
o Unpredictable behavior
o Functional bugs in silicon

CDC Concerns:

27
NAVANEETHAKRISHNAN
 LINT & CDC

Metastability:
 Metastability occurs when a flip-flop samples a signal violating setup or hold time.
This happens when a signal from one clock domain goes into another asynchronously.
 The flip-flop cannot decide whether the input is 0 or 1 → enters an unstable analog state →
output becomes unpredictable for a short time.
 It does not mean failure every time, but it increases probability of unpredictable
behavior → MTBF (Mean Time Between Failures) decreases.
Note: Metastability is about “signal stability”
Scenario:
UART RX Ready Signal = Processor Clock Domain
o UART works at 3.6864 MHz
o Processor works at 100 MHz
o UART asserts rx_valid for maybe one UART cycle
The processor samples rx_valid at 100 MHz, but since the assertion time and processor clock
edge are not aligned, the processor flip-flop may sample exactly during the transition →
metastability.

28
NAVANEETHAKRISHNAN
 LINT & CDC

This results in:

o Processor may see the signal late
o Processor may see the signal early
o Processor may see glitch or unpredictable value
Data Loss:
Data loss happens when information is transferred across domains, but:
 Receiver clock is too fast or too slow
 Receiver samples before data becomes stable
 Control signals are shorter than the receiving clock period
 Multi-bit data changes during sampling → partial update → data corruption
Note:Data loss is about losing the actual information
Scenario: Pulse too short
You send a 1-cycle pulse from a 200 MHz domain to a 50 MHz domain.
 200 MHz pulse width = 5 ns
 50 MHz clock period = 20 ns
29
NAVANEETHAKRISHNAN
 LINT & CDC

The pulse may come and go before the slow domain ever samples it → pulse missed → data
loss.
Scenario: Multi-bit Data Without Handshake
Example: 8-bit data goes from clkA → clkB
If clkB samples while data is still changing → you get corrupted values:
Actual data from clkA Data sampled at clkB
0110_1101 0100_1101
data loss because bits arrive at different times.
Fix:
Use Handshake or Async FIFO:
 Valid/Ready protocol (slow-safe)
 Grey-coded pointers (FIFO)
 Multi-cycle path with stable window

MTBF (Mean Time Between Failure):

30
NAVANEETHAKRISHNAN
 LINT & CDC

MTBF is a statistical measure of how long a digital system can operate before a failure occurs
due to metastability in a CDC path.
Metastability cannot be eliminated, but with proper synchronizers (2-flop/3-flop) it can be
pushed so far that:
 Failure only occurs once every thousands of years
So MTBF answers the question:
“How reliable is my synchronizer and how long until metastability creates a failure?”
A commonly used simplified form:

Where:
 Tres = resolution time (time allowed for metastability to settle, usually 1 clock period)
 τ (tau) = metastability constant of FF (technology-dependent)
 Fdata = frequency of asynchronous input

31
NAVANEETHAKRISHNAN
 LINT & CDC

 Fclock = receiving clock frequency

Higher MTBF = safer, more reliable system.
o More resolution time → FF has more time to settle → MTBF increases exponentially
o Faster clocks → less resolution time → MTBF decreases
o Faster input toggle → more chances of violating setup/hold → MTBF decreases
o Adding extra FF in a synchronizer increases resolution time → MTBF increases
dramatically
Scenario: 100 MHz CPU sampling 3 MHz UART RX signal
 CPU clock = 100 MHz
 UART signal toggles at = 3 MHz
 FF metastability constant τ = 50 ps
 2-flop synchronizer gives resolution time ≈ 1 clock period (10 ns)
MTBF ≈ a few months or years
If you add a 3rd flop:
 Resolution time ≈ 2 clock periods (20 ns)
 MTBF increases exponentially to decades or centuries
32
NAVANEETHAKRISHNAN
 LINT & CDC

Conclusion:
o One more flop = massive reliability improvement
o Cheap and effective fix
This is why almost every SoC uses 2-FF or 3-FF synchronizers.
Application:
1. Automotive ECU (Car Electronics)
 Airbag controller, ABS, engine ECU → any CDC-related metastability must have MTBF
of 10+ years.
 If MTBF is low → risk of random mis-activation → safety hazard.
2. Aerospace & Avionics
 Flight computers need extremely high reliability.
MTBF must be higher than mission lifetime (20–30 years).
 Thus 3-stage synchronizers are commonly used.
3. CPUs, GPUs, SoCs
 Billions of CDC paths exist inside a chip.
 Even a single metastability-induced failure can:

33
NAVANEETHAKRISHNAN
 LINT & CDC

o Hang pipeline
o Cause mis-sampling of interrupt
o Trigger illegal instruction
o Corrupt data
Hence MTBF must be far > expected product life (10 years).
Why MTBF Matters?
 To choose number of synchronizer flip-flops
If MTBF < expected lifetime → add more FF → increases resolution time → increases
MTBF.
 To check design reliability
Static CDC tools calculate MTBF per sync path.
 For predicting failure rates
Helps estimate how often metastability can force an unpredictable system state.

CDC Techniques: Synchronizers

34
NAVANEETHAKRISHNAN
 LINT & CDC

CDC (Clock Domain Crossing) synchronizers are hardware structures used to safely transfer
signals between different clock domains while avoiding:
 Metastability
 Data loss
 Glitches
 Data corruption
Synchronizers are chosen based on the type of signal:
o Single-bit control
o Pulse
o Multi-bit data
o Status flags
o Counters or pointers

2-Flop Synchronizer (Standard Synchronizer):

35
NAVANEETHAKRISHNAN
 LINT & CDC

The 2-stage flip-flop synchronizer is the most commonly used CDC element for single-bit
level signals.
It allows metastability to settle in the first flop, and the second flop gives a stable output.
Purpose:
 Removes metastability
 Ensures receiving domain gets a stable 0/1
 Used only for single-bit signals (not multi-bit)
Applications:
1. Interrupt flags
2. FIFO full/empty flags
3. Status signals
4. Enable/disable signals
5. Reset synchronization
6. UART rx_valid, tx_ready
7. Power-domain handoff signals

3-Flop Synchronizer (High Safety Synchronizer):

36
NAVANEETHAKRISHNAN
 LINT & CDC

Same as 2-flop synchronizer but with one more flop to increase MTBF (Mean Time Between
Failures).
Used in very high-speed or safety-critical designs.
Purpose:
 Increases metastability resolution time
 Makes system ultra-reliable
 Required when MTBF of 2-FF is not enough
Applications:
1. Automotive (airbags, ABS)
2. Avionics (flight computers)
3. Medical devices
4. High-speed SerDes control signals (1–10 GHz)
5. CPU interrupt synchronization

Pulse Synchronizer (Toggle Synchronizer):

37
NAVANEETHAKRISHNAN
 LINT & CDC

A single cycle pulse may be too short for the new domain; the toggle synchronizer converts the
pulse into a level change so it will never be missed.
Flow:
 Pulse toggles a bit in the source domain
 Destination domain detects edge using 2-FF
Purpose:
 Avoid pulse loss when source clock is faster
 Safe method to send one-shot events
Applications:
1. Event signals
2. Counter overflow
3. DMA request pulses
4. Interrupt strobes
5. Fast-to-slow clock transfers
Handshake Synchronizer (Request–Acknowledge):

38
NAVANEETHAKRISHNAN
 LINT & CDC

A 2-way handshake with req and ack signals, each synchronized across domains.
Guarantees that no data is lost and the source waits until destination captures data.
Source → req → Destination
Destination → ack → Source
Purpose:
 Transfer multi-bit data safely
 Ensure source does NOT update data until destination confirms
 No metastability impact on data bus
Applications:
1. Configuration registers (multi-bit)
2. Peripheral-to-CPU multi-bit transfers
3. Loading LUT/RAM values
4. Slow-speed buses
5. External device data capture

39
NAVANEETHAKRISHNAN
 LINT & CDC

Mux-based Synchronizer (Multi-Cycle Stable Data):

Data is held stable for 2 or more cycles while the control signal is synchronized using a 2-FF.
Destination samples only after control arrives.
Purpose:
 Safe multi-bit transfers without FIFO
 Good for low-frequency data transactions
Applications
1. APB to AHB bridges
2. Register updates
3. GPIO data
4. Cross-domain status dumps

Async FIFO Synchronizer (Multi-bit, High Throughput):

40
NAVANEETHAKRISHNAN
 LINT & CDC

Uses:
 Dual-port RAM
 Gray-coded read/write pointers
 Pointer synchronizers (2-FF each)
Allows continuous streaming of multi-bit data.
Purpose:
 High-speed data flow
 No handshake delay
 Completely decouples 2 clock domains
Applications:
1. UART RX/TX
2. Video data pipelines
3. CPU <→ DSP data exchange
4. Network packet transfers
5. PCIe/AXI asynchronous bridges
41
NAVANEETHAKRISHNAN
 LINT & CDC

6. Sensor-to-processor pipelines

Reset Synchronizer
Synchronizes asynchronous reset de-assertion using 2 flops inside each clock domain.
Purpose:
 Ensure reset release happens only on a clock edge
 Avoid metastability during reset removal
Applications:
1. Every SoC block
2. Flop-based designs
3. Multi-clock IP

Interview Questions:
42
NAVANEETHAKRISHNAN
 LINT & CDC

1. What is RTL Linting and why is it needed before synthesis?

2. What is the difference between syntax and semantic lint checks?
3. What are unreachable states in FSM linting?
4. Why are combo loops dangerous?
5. How does a missing else or default cause a latch?
6. How do you fix multi-driver errors?
7. What is data loss in CDC?
8. What is MTBF?
9. When do you need a pulse synchronizer?
[Link] do we need Grey-coded pointers in asynchronous FIFO?
Learnings:
1. How RTL lint is essential to catch RTL issues before simulation or synthesis
2. Stages involved in Lint flow
3. Why CDC requires and when
4. MTBF is the metric used to measure CDC reliability.
5. Different synchronizers are used based on signal type and throughput requirement.

43
NAVANEETHAKRISHNAN