Skip to question
asic.fyi
DesignVerificationSystemVerilogFirmwareArchitectureInterviews
asic.fyi/Interview questions/Constrain Gray-Bus Delay and Skew Without Masking the Checks

Hardware interview practice

Constrain Gray-Bus Delay and Skew Without Masking the Checks

HardClock and Reset DomainsSystemVerilog

A 4-bit Gray counter is launched by a 250 MHz source clock and sampled by the first stage of a two-flop synchronizer in an unrelated 200 MHz domain. Ordinary crossings between the two domains must be cut, but the Gray launch-to-first-stage paths must remain visible to static timing so implementation can bound their delay and inter-bit skew. Write selective false-path, datapath-delay, and bus-skew constraints, then decide whether each reported Gray path set passes.

Try it in the question bankReason first. Then compare.

Keep this exact question selected while you check your answer and review the full solution.

Practice this question →
Starting point

Question code

src_clk period: 4.000 ns; dst_clk period: 5.000 ns
Gray launch pins: g_tx_reg[3:0]/Q
Gray capture pins: g_sync1_reg[3:0]/D
Tcl collections supplied: $ordinary_s2d_D and $ordinary_d2s_D
$ordinary_s2d_D excludes g_sync1_reg[3:0]/D
Delay and skew limits are both one src_clk period: 4.000 ns
Reviewed example

Work through one case

Input
Case 1: First-stage arrivals [1.0, 2.0, 3.8, 4.0] ns pass the skew check because 4.0-1.0 = 3.0 ns, and every datapath delay
Case 2: Scenario: Arrivals [0.4, 1.0, 1.5, 4.6] ns fail bus skew because 4.6-0.4 = 4.2 ns.
Case 3: Arrivals [0.2, 0.4, 0.5, 4.1] ns
Expected output
Case 1: Is at most 4.0 ns.
Case 2: Expected behavior: Arrivals [0.4, 1.0, 1.5, 4.6] ns fail bus skew because 4.6-0.4 = 4.2 ns.
Case 3: Have 3.9 ns of skew, which passes the 4.0 ns skew limit, but fail maximum datapath delay because the last bit takes 4.1 ns; passing skew does not rescue that path.

The shown result follows by applying this rule: The answer cuts only the supplied ordinary crossing endpoints and leaves the Gray launch-to-sync1 paths active for separate `-datapath_only` maximum-delay and bus-skew checks at 4.000 ns. The cases also demonstrate this requirement: Keep the two synchronizer stages recognizable to CDC and implementation tools; the constraint does not make a binary bus safe and is valid here only because consecutive transmitted Gray values differ in one bit.

What to cover

Requirements

  1. Cut ordinary unrelated-clock crossings selectively, for example with `set_false_path -from [get_clocks src_clk] -to $ordinary_s2d_D` and the reverse-direction equivalent to `$ordinary_d2s_D`. Do not apply a broad asynchronous clock-group or clock-to-clock false path that also covers the Gray launch-to-sync1 paths.
  2. Apply `set_max_delay 4.000 -datapath_only` from all four launch Q pins to all four first-stage D pins.
  3. Apply `set_bus_skew 4.000` across the same launch and first-stage capture collections. Bus skew is maximum arrival minus minimum arrival for the analyzed transfer.
  4. Keep the two synchronizer stages recognizable to CDC and implementation tools; the constraint does not make a binary bus safe and is valid here only because consecutive transmitted Gray values differ in one bit.
Continue practicing

Related questions

Clock and Reset DomainsSeparate related-clock timing from asynchronous CDC→Clock and Reset DomainsSize a synchronizer from an MTBF target→Clock and Reset DomainsImplement a four-phase CDC event handshake→
asic.fyi · Learn silicon end to end.info@asic.fyi