Timing Report Analysis, CDC and RDC for SoC

From STA Reports to Two-Clock Design Signoff

VLSI Design · Timing Signoff · CDC & RDC Verification

Introduction

In Part 1 of this series, we introduced Static Timing Analysis (STA), the structure of a Synopsys Design Constraints (SDC) file, clock definitions, and the role of input and output delays. Those constraints establish the timing model used by synthesis and implementation tools.

This second part moves from writing constraints to interpreting their results. We will examine a sample setup timing report, outline a practical analysis procedure for a two-clock design, and explain why Clock Domain Crossing (CDC) and Reset Domain Crossing (RDC) verification are necessary alongside STA. This blog follows Part 1 in the LeadSoC series and can be read as a continuation of the constraint-generation workflow.

1. Reading a Static Timing Analysis Report

A typical STA report identifies the startpoint, endpoint, path type, launch and capture clocks, cell and net delays, data arrival time, data required time, and slack. Always confirm whether the report describes a maximum-delay setup check or a minimum-delay hold check.

The following simplified example represents a setup path within the SYS_CLK domain. Assume a 10 ns clock period, 0.2 ns setup uncertainty, a 0.1 ns setup requirement at the receiving register, and zero launch and capture clock latency.

The data arrival time is the sum of clock-to-Q, combinational cell delay, and interconnect delay:

The path passes setup timing because slack is positive. This is an illustrative report, not output from a particular EDA run. Actual reports can include clock latency, skew, propagated clocks, derating, on-chip variation, waveform effects, and additional timing adjustments.

2. What Negative Slack Tells the Designer

Suppose another path has a data arrival time of 10.2 ns and a required time of 9.7 ns. Its setup slack is −0.5 ns, so the data misses the required deadline by 0.5 ns.

Do not respond by changing a constraint simply to remove the violation. First identify the cause. Common causes include excessive logic depth, high fanout, slow cell choices, long interconnect, poor placement, an incorrectly modeled clock, or unfavorable clock skew. Depending on the root cause, a solution may involve logic restructuring, cell sizing, buffering, placement optimization, or a legitimate architectural change.

3. Understanding Hold Timing

Hold analysis checks whether new data arrives too soon after the capture edge. Suppose the minimum required data arrival is 0.25 ns and the actual minimum arrival is 0.15 ns:

This path has a 0.10 ns hold violation. Hold repair commonly adds delay cells or buffers, changes cell selection, or adjusts placement to increase minimum path delay. The repair must be checked against setup timing and other design requirements.

4. A Practical Procedure for a Two-Clock Design

Consider the example SoC from Part 1: SYS_CLK runs at 100 MHz and PERIPH_CLK at 50 MHz. The correct analysis procedure separates timing closure within each clock domain from the functional safety of crossings between domains.

Step 1 — Confirm Clock Definitions

Generate a clock report and check that both clocks, their periods, sources, and generated-clock relationships are correctly recognized. Missing or incorrectly modeled clocks can make the rest of the timing results incomplete.

report_clocks
check_timing

These are illustrative Synopsys-style commands; command options and report formats depend on the tool and version.

Step 2 — Review Constraint Coverage

Check for unconstrained input-to-register, register-to-output, register-to-register, and other relevant paths. A design is not fully timed merely because the report has no negative slack. Unconstrained paths may not be included in the checks the designer expects.

check_timing
report_timing -delay_type max
report_timing -delay_type min

Step 3 — Analyze Each Clock Domain

Review SYS_CLK paths and PERIPH_CLK paths separately. Examine worst negative slack (WNS), total negative slack (TNS), hold violations, the number of failing endpoints, clock skew, cell delay, net delay, and high-fanout nets. WNS identifies the worst reported setup slack; TNS helps indicate whether violations are isolated or widespread.

Step 4 — Check Interface Timing

Confirm that sensor input paths include the correct maximum and minimum input delays, and that output paths include the external receiver's timing requirements. Verify reference clocks, edge polarity, rise/fall differences, and all required operating modes. Source-synchronous interfaces or forwarded-clock interfaces may need more detailed constraints than the simple example.

Step 5 — Identify Clock Crossings

Identify paths that begin in one clock domain and end in another. Determine whether they are related synchronous clocks, asynchronous single-bit controls, pulses, multi-bit data transfers, handshakes, asynchronous FIFO paths, or reset-related interactions. Different clock names alone do not establish that the clocks are asynchronous.

If two clocks are genuinely independent, their relative edge timing cannot be assumed. A command such as set_clock_groups -asynchronous may be appropriate to prevent meaningless synchronous setup and hold comparisons between those groups. However, it also cuts timing analysis between them, so it must only be applied when justified by the clock architecture.

set_clock_groups -asynchronous \
  -group [get_clocks SYS_CLK] \
  -group [get_clocks PERIPH_CLK]

This exception does not make a crossing safe. It does not insert synchronizers, prevent metastability, validate a handshake, or prove that data cannot be lost.

Step 6 — Run CDC and RDC Analysis

Run dedicated CDC and RDC checks on the RTL or another representation supported by the verification tool. Review structural findings, synchronizer recognition, multi-bit data handling, reconvergence, reset sequencing, and any waivers. Repeat the analysis after relevant RTL or constraint changes.

5. Clock Domain Crossing

A Clock Domain Crossing occurs when a signal generated in one clock domain is sampled or used in another. If the clocks are asynchronous, the receiving register may sample the signal close to a transition and enter a metastable state. The objective is to reduce the probability that metastability propagates into functional logic to an acceptably low level.

5.1 Single-Bit Control Signals

For a slowly changing single-bit control, a two-register synchronizer is a common solution. The first register samples the asynchronous signal; the second samples the first register's output on a later destination-clock edge, providing additional resolution time.

always_ff @(posedge periph_clk or negedge rst_n) begin
  if (!rst_n) begin
    sync_ff1 <= 1'b0;
    sync_ff2 <= 1'b0;
  end else begin
    sync_ff1 <= async_control;
    sync_ff2 <= sync_ff1;
  end
end
assign control_sync = sync_ff2;

This example assumes an asynchronous active-low reset. Reset release must also be handled correctly. Use the target library's recommended synchronizer cells or attributes where applicable, and preserve sufficient resolution time between stages. A two-register synchronizer is not suitable for every signal: a narrow pulse may be missed, and it does not ensure coherent transfer of a multi-bit bus.

5.2 Multi-Bit Data Crossings

Passing each bit of a bus through independent two-register synchronizers is generally not sufficient. Bits can settle on different destination cycles, producing a combination that never existed in the source domain.

• Handshake-based transfer: The source holds data stable while a request is synchronized. The destination captures data according to the protocol and returns an acknowledgement. The source retains the data until the transfer completes.
• Asynchronous FIFO: Data is written with one clock and read with another. Pointer synchronization and full/empty logic manage the crossing.
• Gray-coded counters or pointers: Only one bit changes between consecutive values, reducing the risk of inconsistent sampling. Physical implementation may also require constraints to control inter-bit skew.

The right method depends on throughput, latency, data width, transfer direction, and whether transactions can arrive back-to-back.

5.3 CDC Verification Workflow

A CDC tool should identify clock domains, find crossings, classify their structures, and flag patterns that may be unsafe. Engineers then review single-bit synchronizers, pulse-transfer mechanisms, handshakes, FIFO pointer logic, multi-bit data stability, and reconvergence. Findings must be assessed against design intent; a waiver should have a clear technical justification.

6. Reset Domain Crossing

Reset Domain Crossing (RDC) concerns interactions between logic elements with different reset sources, reset timing, or reset-release behavior. RDC is distinct from CDC: even registers on the same clock can have an RDC problem if their reset release is not coordinated.

For example, one register may leave reset while another register supplying its control signal remains in reset. The first register may then observe an invalid or unexpected transition. Releasing an asynchronous reset near a clock edge can also violate recovery or removal requirements.

6.1 Asynchronous Assertion and Synchronous Deassertion

A common strategy is to assert reset asynchronously when immediate reset behavior is required, then deassert it synchronously within each destination clock domain. This reduces the risk of uncontrolled reset release, but the reset architecture must still account for library requirements, reset-tree design, recovery/removal checks, and subsystem sequencing.

always_ff @(posedge periph_clk or negedge arst_n) begin
  if (!arst_n) begin
    rst_sync_ff1 <= 1'b0;
    rst_sync_ff2 <= 1'b0;
  end else begin
    rst_sync_ff1 <= 1'b1;
    rst_sync_ff2 <= rst_sync_ff1;
  end
end
assign periph_rst_n = rst_sync_ff2;

Here, arst_n is an asynchronous active-low reset. The destination reset is released after the required destination-clock edges instead of directly following the asynchronous deassertion. Actual implementation must follow the reset methodology for the target design.

6.2 Practical RDC Checks

• Check interactions between registers with different reset sources during assertion and release.
• Confirm that asynchronous resets are released appropriately in each clock domain.
• Check reset synchronizers, reset distribution, and reset sequencing between dependent blocks.
• Verify that data and control signals do not become active before the receiving logic is ready.
• Cover relevant modes such as partial reset, warm reset, and power-domain transitions where applicable.

7. How STA, CDC and RDC Complement One Another

A design can pass one check and fail another. An asynchronous clock-group constraint can remove invalid cross-clock setup comparisons from STA, but CDC analysis must still verify the crossing architecture. Similarly, a structurally correct synchronizer does not prove that a handshake cannot lose transactions or that internal synchronous paths meet timing.

8. Recommended Signoff Checklist

• All primary and generated clocks are correctly defined.
• Clock periods, waveforms, uncertainty, and relationships match the system specification.
• Relevant input and output ports have appropriate maximum and minimum delays.
• Input transitions and output loads reflect the intended interface assumptions.
• Setup and hold reports have been reviewed for required timing scenarios.
• Unconstrained paths and ignored paths have been investigated.
• False paths, multicycle paths, and asynchronous clock groups are technically justified.
• CDC analysis is complete and unsafe crossings are resolved or justified.
• RDC analysis is complete and reset-related issues are resolved.
• Timing is rechecked after relevant synthesis and physical implementation changes.

Conclusion — From Constraints to Reliable Signoff

Timing-constraint generation translates system requirements into a model that synthesis, implementation, and timing-analysis tools can use. A disciplined STA review examines path coverage, arrival and required times, setup and hold behavior, clock skew, and the root causes of violations — not just the worst slack value.

For multi-clock SoCs, CDC and RDC verification are equally important because they address risks that conventional synchronous timing analysis cannot prove away. The combination of well-generated constraints, systematic STA analysis, and dedicated CDC/RDC verification provides a stronger foundation for reliable, high-performance SoC implementation.

Timing closure is not merely a matter of eliminating negative slack. It is a process of validating the timing model, understanding the circuit's real operating environment, and ensuring that clock and reset boundaries are architected and verified correctly.