Scope

This FAQ covers reset distribution and reset release methodology. Guidance differs by device family and software release. Part A applies to Diamond-based devices; Part B applies to Nexus-based devices. Where this document differs from earlier material, follow the guidance applicable to your device family, software release, and design requirement.

Quick Answers

1. Lowest routing-resource usage: use GSR.
2. Recovery and Removal Timing Analysis: use LSR.
3. Deterministic, verifiable reset release: use a hybrid reset — asynchronous assertion, synchronous de-assertion. GSR cannot provide this.
4. Nexus-based devices: hybrid reset is the default. Use GSR only with a specific, documented motivation.

Terminology

• GSR — Global Set/Reset. Dedicated global reset resource, not routed through general routing.
• LSR — Local Set/Reset. Reset routed as ordinary control logic.
• STA — Static timing analysis. TRACE is the Diamond timing analysis tool referenced in the case reports.
• Recovery and removal — the setup and hold analogues for an asynchronous reset relative to the clock edge.

---

Part A — Diamond-Based Devices

1. What is the tradeoff between GSR and LSR?

• GSR uses the dedicated global reset resource and gives the largest reduction in routing usage. The benefit is greatest for high-fanout asynchronous resets. The reset path is not timed.
• LSR is routed through general routing and is included in timing analysis, at the cost of higher routing usage.

In designs above approximately 90 percent utilisation, moving reset from GSR or primary routing onto general routing has been observed to risk a routing shortage and failure to place and route. Evaluate the mitigations in item 3 before accepting a general-routing implementation.

2. Why is recovery and removal timing not analysed with GSR?

When a reset is placed on GSR, Diamond does not check recovery and removal timing for that path. Nets attached to GSR carry no timing-arc information, so violations on those paths go unreported. Where this timing must be analysed, use LSR.

LSR reset paths are analysed because the following arcs are documented in TRACE:

• LSRREC_SET — LSR recovery setup
• LSR_SET — LSR setup
• LSR_HLD — LSR hold

3. Can reset be distributed on the primary clock network?

Yes. Assign the reset to a primary clock line using the USE PRIMARY NET preference in Spreadsheet View. The primary clock line then carries reset distribution in place of local routing, which can relieve congestion in constrained designs.

For high-utilisation designs:

• Distribute only the synchronised reset release on low-skew resources.
• Keep the asynchronous assertion off the primary network.
• Confirm after the change that recovery and removal timing is still analysed.
• Confirm reset polarity behaviour, with attention to the end-of-configuration condition in item 4.

Part B — Nexus-Based Devices

5. Why is GSR not recommended on Nexus devices?

• GSR is untimed. No timing-arc information exists, so GSR-attached nets are excluded from timing analysis and negative slack can go undetected.
• Reveal interaction. GSR is asserted briefly during Reveal Analyzer initialisation, which can pulse GSR-attached signals low and interrupt the behaviour under observation.

On some architectures, HDL signal initialisation uses the same start-up mechanism as GSR and may share these characteristics. Verify device-specific behaviour in the applicable user guide.

6. What is the recommended hybrid reset?

A hybrid reset combines asynchronous assertion with synchronous de-assertion. The asynchronous path ensures that when the reset source becomes active, every register is forced into its reset state immediately, without waiting for a clock edge — important when the clock may not yet be running or stable. The synchronous release ensures that when the reset source is removed, the internal fabric leaves the reset state on a defined clock edge, so all registers exit reset in the same cycle and metastability at release is contained.

The mechanism is a two-stage register chain clocked by the destination clock, with the reset source tied to the asynchronous reset input of both stages:

1. module reset_sync (
2.      input wire clk_i,
3.      input wire rst_n_i, // asynchronous source, active low
4.      output wire rst_o // synchronised, active high
5. );
6.      reg [1:0] sync_q;
7.      always @(posedge clk_i or negedge rst_n_i) begin
8.           if (!rst_n_i)
9.               sync_q <= 2'b00; // asynchronous assertion
10.           else
11.                sync_q <= {sync_q[0], 1'b1}; // synchronous release
12.      end
13.      assign rst_o = ~sync_q[1];
14. endmodule
    

How it works: When rst_n_i goes low, both flip-flops clear immediately and rst_o asserts, independent of the clock. When rst_n_i returns high, a constant 1 shifts through the two stages, so rst_o deasserts two clock edges later — aligned to clk_i. The two stages allow any metastability on the release edge to resolve before the reset reaches the fabric.

Design considerations:

• Polarity — input is active-low, internal reset active-high; invert to match your convention.
• Per-domain — instantiate one synchroniser per clock domain; do not share across asynchronous domains.
• Fanout — the synchroniser output drives the design's reset network, so Part A routing/fanout considerations still apply.
• Power-up — the source must hold reset low through power ramp and configuration so the first release edge occurs only in a known state.
  

7. Which synthesis strategy settings should be verified?

Where a hybrid or local reset is intended, review the tool options so the reset is not remapped onto GSR against the HDL intent.

• Force GSR — when enabled, routes all reset signals to GSR regardless of HDL intent. Disable. 
• Infer GSR (Map Design) — may substitute GSR where a reset drives many registers. 

Behaviour can change across releases. Validate against the specific tool version and device family, and confirm the result in the post-synthesis netlist rather than relying on the setting alone.

8. Can deterministic reset release be guaranteed?

Only with a synchronised release. GSR de-assertion is not synchronised to the user clock, and GSR pulses during the configuration wake-up sequence, so the exit-from-reset cycle is non-deterministic relative to the system clock. A synchronised release, as in item 6, provides a deterministic transition that can be constrained in the timing-closure flow.

General design practice (not case-specific). As a standard STA step, constrain the asynchronous assertion path into the first synchroniser stage as a false path for setup, and confirm the synchroniser output is analysed on the destination clock.

---

Summary

Requirement	Approach	Timing analysed	Routing cost
Lowest routing usage	GSR	No	Lowest
Recovery and removal coverage	LSR	Yes	Higher
Congestion relief above ~90% utilisation	Primary clock net, or synchronised release only on low-skew resources	Verify after change	Moderate
Deterministic reset release	Hybrid, synchronised release	Yes	Moderate