Timing Closure Under Pressure on a 200 MHz Capture Path
A Kintex-7 FPGA must close timing at 200 MHz for an ADC capture path and also hosts a 100 MHz housekeeping bus driven by an external microcontroller. After a debug core (ILA) was added to chase a field issue, the implementation report shows worst negative slack of −1.8 ns and 312 failing endpoints, against 40 before the debug core. Four path groups account for almost all failures: (a) a DSP48 cascade into a 36-bit accumulator; (b) a 100 MHz configuration register feeding combinational logic that drives a 200 MHz state machine; (c) the asynchronous reset de-assertion net that spans both domains; (d) block-RAM output to a 200 MHz pipeline register. Both clocks are generated by the same MMCM, but a previous engineer had disabled the generated-clock relationships. A colleague proposes adding set_false_path from all 100 MHz registers, set_clock_groups -asynchronous between the two clocks, and set_multicycle_path 2 on the accumulator, so that the release build reports clean timing.
1. Evaluate the colleague's three constraint changes path by path. Which are legitimate engineering and which merely hide a defect?
Read the worked answer
The proposal is a mix: one constraint is defensible, two are not, and none of them fixes the underlying defect.
(a) DSP48 cascade → 36-bit accumulator. This is a genuine single-cycle synchronous path inside the 200 MHz domain. set_multicycle_path 2 claims the data has two cycles to arrive. That is only true if the accumulator has an enable that qualifies it every other cycle - and even then the constraint must be -setup 2 -hold 1 and tied to that enable. If the accumulator is enabled every cycle, the multicycle constraint describes a circuit that does not exist, and the design will pass at the fast corner and fail in silicon. Correct fix: pipeline the cascade output (register the DSP P output before accumulating), or split the accumulation into a partial-sum tree.
(b) 100 MHz register → combinational → 200 MHz state machine. This is a clock-domain-crossing structure as drawn, and a combinational path from one domain into another has no defined single-cycle relationship. Adding set_false_path would silence the report while leaving a circuit that can launch metastable data into the FSM. This is a design bug, not a constraint problem. The correct structure is a synchronizer (two flops with ASYNC_REG) for a single-bit level, or a handshake / async FIFO for a bus, followed by registered logic in the destination domain.
(c) Reset de-assertion. Never false-path the whole reset net. Asynchronous assertion with synchronous de-assertion per domain requires a reset synchronizer in each clock domain; only the assertion edge is genuinely asynchronous and may be exempted.
(d) BRAM output → 200 MHz register. A real path. Fix with the BRAM's optional output register or an extra pipeline stage, not a constraint.
The disabled generated-clock relationships are the real first step. Re-enable them so the two clocks are analysed correctly. If they come from one MMCM with a fixed phase, they are synchronous and must be timed together; set_clock_groups -asynchronous is factually wrong here and would hide every cross-domain path.
2. Sequence the work needed to get a trustworthy release build, including what to do about the ILA.
Read the worked answer
1. Establish a correct baseline first. Restore the MMCM generated-clock relationship and remove all existing false paths and multicycle constraints from the two clock domains, then re-run implementation. The failing-endpoint count will jump, and that is the honest number. Keep the 40-failure pre-ILA report as the reference point.
2. Fix the structural CDC in (b). Replace the combinational feed-through with a synchronizer for control bits, or a proper handshake / async FIFO for data, and constrain it with set_max_delay -datapath_only (or false-path from source to the first synchronizer flop only). Register the output of the synchronizer before it drives the FSM.
3. Fix (c) with reset synchronizers per domain, and constrain only the assertion edge. Verify the reset release is at least two destination clock edges before any logic leaves reset.
4. Retime (a) and (d). Both are pipeline-depth problems, not constraint problems. If the 200 MHz budget is genuinely tight after pipelining, consider whether the capture path needs the full rate or whether the 128-tap arithmetic can be parallelised at 100 MHz with a wider datapath - that trade is often cheaper than fighting for the last 1.8 ns.
5. Deal with the ILA separately. Debug cores consume routing and logic and should never gate a release build. Ship a release configuration with the ILA removed, and keep a debug build on a lower clock or with fewer probes. If the transient being chased only appears at line rate, use a small embedded logic analyser with a shallow capture on a dedicated clock and accept the area cost in a non-release build.
6. Gate on the sign-off report. Require a clean unconstrained-paths report and a CDC report with no unresolved crossings, and check timing at both slow and fast corners, not just the slow corner. A report that is clean because it is silent is not evidence.
3. The board is running at 200 MHz and you must decide whether to spend schedule on re-architecture or accept a lower system clock. What analysis drives that decision?
Read the worked answer
This is an engineering-economics judgement, so make the trade explicit in numbers.
What does 200 MHz buy? If the ADC sample rate forces 200 MHz on the capture path (for example, a 200 MSPS converter with a parallel DDR interface), then dropping to, say, 160 MHz reduces sustained capture throughput by 20% or forces a wider interface, which costs FPGA pins and board rework. If, on the other hand, 200 MHz was chosen for convenience while the converter can be clocked at 160 MSPS, the clock drop is nearly free.
What does re-architecture cost? Pipelining (a) and (d) is typically one to two days each, plus re-verification of the arithmetic. That is cheap compared with a board spin, and it also improves the fast-corner margin. Re-architecting the CDC in (b) is mandatory either way - you cannot schedule your way out of a metastability risk, only trade it for an unreliable product.
Quantify the risk of the −1.8 ns slack. Worst negative slack of −1.8 ns at 5 ns period is a 36% overrun on the failing paths. That is far outside the range where placement and seed variation will save you, so 'try another implementation run' is not a plan.
Decision: fund the pipelining and the CDC fix, keep 200 MHz, and hold the schedule only for the CDC rework, which is the item with real safety consequences. If after two implementation attempts the intra-domain paths still fail, then renegotiate the clock with the system owner using measured numbers, and document the throughput impact so the decision is made by the person who owns the requirement, not by the person under schedule pressure.