Four more GLS issues: diagnosing timing failures vs annotation problems, glitch suppression cancellation, pulse error warnings, and SDF delays not appearing in waveforms. Followed by the complete NTC warning reference table.
During simulation the tool reports a timing check violation. The message includes the check type, instance, simulation time, and file/line of the specify block entry:
Warning! Timing violation $setuphold<setup>( posedge CK:25 NS, negedge D:15330 PS, 10.09 : 10090 PS, 0.00 : 0 FS ); File: ./stdcell_lib.v, line = 9817 Scope: tb_top.dut.u_cpu.count_reg[0] Time: 25 NS
Reading the message: the setup check fired at 25 ns on count_reg[0]. Clock rose at 25 ns. Data D had a negative edge at 15.330 ns — only 9.67 ns before the clock edge, violating the 10.09 ns setup requirement.
Timing violation triage. CK rises at 25 ns; D transitions at 15.33 ns (9.67 ns before clock edge), violating the 10.09 ns setup requirement. Key question: does the waveform show the SDF-annotated delay? YES → genuine failure, report to backend for ECO. NO → annotation problem, search elaboration log for SDFNEP/SDFNET on the driving cell.
Note the clock edge time and data edge time. Calculate actual margin: clock_time − data_transition_time. Compare against the required setup from the message.
Add CK, D, Q and the driving cell output to the waveform viewer. Zoom to the violation time. Measure whether the delay matches the SDF-annotated value for that path.
Report to the backend team with the instance path, SDF delay value, and violation slack. They will investigate placement, routing, and buffer insertion and provide an ECO.
Search the elaboration log for SDFNEP or SDFNET on the driving cell. If found, the cell is using its specify block default (not the SDF value). Resolve the annotation mismatch as described in GLS-06, then re-run to confirm the violation disappears.
# Search elaboration log for a specific instance: grep -i "SDFNEP\|SDFNET" sdf_annotate.log | grep "count_reg" # Confirm what delay was actually annotated: grep "count_reg" timing_dump.txt # Look for: pdelay anno='y' (annotated) or anno='n' (not annotated)
Warning! Glitch suppression Scheduled event for delayed signal of net "DD" at time 6 FS was canceled!
Specific to NTC (Negative Timing Check) delayed signals. When a flip-flop has a negative setup or hold value in the SDF, the simulator generates internally delayed versions of clock and data signals (DD = delayed data) for timing check evaluation.
The cancellation happens when a new input event arrives while a previously scheduled output event is still pending. The new event supersedes the old one, cancelling the old scheduled output event. This occurs specifically when rise and fall delays for the NTC net are different — a rising transition is scheduled to complete at T₁ but a falling transition supersedes it before T₁, cancelling the rising event.
NTC glitch cancellation. D (blue) has a brief pulse 0→1→0. DD expected (green dashed) should rise 2 fs after D rises, then fall 4 fs after D falls. Because D falls before the rising event on DD resolves, the new falling input event cancels the scheduled rising output event. DD actual (red) never fully transitions — the warning reports this cancellation at 6 fs.
Add -ntc_verbose for detailed information about NTC delay calculations. Compare rise and fall delays to understand why they differ.
elaborate tb_top -sdf_cmd_file sdf_cmd_file -ntc_verbosePlace $monitor on the primary inputs driving the affected NTC net and on the DD signal itself. This lets you trace the sequence of events and compare input transition times against calculated delay values.
The -nontcglitch switch suppresses glitch events on NTC nets. Use when warnings are numerous and not indicating a real design problem.
elaborate tb_top -sdf_cmd_file sdf_cmd_file -nontcglitchWarning! Pulse flagged as an error, value = StE File: ./stdcell_lib.v, line = 35, pos = 6 Node: tb_top.dut.u_logic.g15.Z Time: 18754652 PS + 0
StE = Strength to Error — pulse below error threshold propagated as X. XtX = output stays at X throughout the pulse cycle.
When a pulse is narrower than the gate’s propagation delay, the inertial delay model rejects it. Two configurable thresholds control this:
With pulse_r=0 and pulse_e=100, every pulse shorter than 100% of the path delay generates this warning and an X on the output.
Three pulse handling zones. Zone 1 (green): below pulse_r — absorbed silently. Zone 2 (red): between pulse_r and pulse_e — output forced to X with warning. Zone 3 (blue): above pulse_e — propagates normally. With default pulse_r=0, pulse_e=100, every pulse narrower than the full path delay enters Zone 2.
# Maximum sensitivity (default): every sub-delay pulse flagged elaborate tb_top ... -pulse_r 0 -pulse_e 100 # Typical production: reject below 50%, flag 50-100% elaborate tb_top ... -pulse_r 50 -pulse_e 100 # Suppress all pulse error messages (not recommended for signoff): elaborate tb_top ... -pulse_r 100 -pulse_e 100
Use -epulse_no_msg to keep X-on-output behaviour but suppress the warning message from the log.
elaborate tb_top ... -epulse_no_msgAfter a successful SDF-annotated GLS run, probing a cell output in the waveform viewer shows it transitioning at the exact same time as its input — zero propagation delay — even though the SDF contains a non-zero delay for that arc.
Cause 1 — SDFNEP/SDFNET warnings on that specific path.
Check elaboration log for annotation warnings on the failing instance. If present, the SDF annotation failed silently — the specify block default (often 0) is being used. Fix: resolve annotation mismatch as in GLS-06.
Cause 2 — Pulse rejection absorbing the transition.
If the input pulse is narrower than the cell delay, inertial delay rejects it entirely. Set -pulse_r 0 -pulse_e 0 to force all pulses through, or widen the stimulus pulse.
Cause 3 — Timescale/precision mismatch (most common cause).
The SDF specifies delays in ps but simulation precision is ns. A 250 ps delay becomes 0.25 ns which rounds to 0 at 1 ns precision. The annotator reports success but the simulator rounds it to zero.
# Symptom: annotation log shows IOPATH A->Y = (250:310:420) # Waveform shows zero delay. Timescale is 1ns/1ns. # Fix: set precision fine enough for SDF delays: compile ... -timescale 1ns/1ps # 1ps precision -> 250ps representable compile ... -timescale 1ns/100fs # even finer if SDF delays in fs
Cause 4 — Module-level timescale overrides command-line timescale.
If a module has its own `timescale directive with coarser precision, that module’s instances use the coarser precision regardless of the command-line setting. Fix: use -override_precision.
compile ... -timescale 1ns/1ps -override_precisionCause 5 — Annotated delay is genuinely zero in the SDF.
Use -sdf_verbose and check if the log shows IOPATH A→Y = (0:0:0). If yes, the zero is coming from the SDF itself — report to the backend team for investigation.
Timescale precision mismatch. With 1ps precision (top), 250 ps stored correctly and visible in waveforms. With 1ns precision (bottom), 250 ps = 0.25 ns rounds to 0 — annotation reports success but delay is silently discarded. Always ensure simulation precision is at least as fine as the smallest SDF delay value.
NTC (Negative Timing Check) warnings arise when setup or hold values in the SDF or specify block contain negative numbers. Advanced-node standard cell libraries frequently include negative timing check values. The following table is the complete reference for NTC-related warnings:
| Mnemonic | Trigger condition | Effect | Resolution |
|---|---|---|---|
SDFNL2 | Sum of the two limits in $setuphold or $recrem is less than zero (e.g. setup=−6, hold=−4, sum=−10) | Negative limit set to zero. Iteration continues. | Confirm library characterisation is correct. If intentional, waive. |
SDFIND | Attempt to annotate a negative delay to a UDP primitive. UDPs cannot accept negative delays. | Value clamped to zero. | Verify library model. UDPs should not have negative path delays. |
NONTCTL | Sum of the two limits is negative. NTC algorithm cannot converge. | Simulation proceeds; limits adjusted. | Use -ntc_tolerance with a positive value to allow convergence. |
NTCTLER | The -ntc_tolerance value is not a valid positive number. | Tolerance ignored; default (0) used. | Correct the value: must be a positive time value with unit (e.g. 10ps). |
NGLIM2 | Both limits in $setuphold or $recrem are negative. | Both limits set to zero. | Investigate library. Both limits negative may indicate a characterisation error. |
NTCWID | NTC net has different rise and fall delays exceeding the limit of a $width check controlled by that net. | $width check may fire spuriously. | Check if the $width check is meaningful. Consider adding to tfile if spurious. |
NTCNNC | Convergence could not be achieved during NTC delay calculation. | Simulation continues with approximated values. | Use -ntc_tolerance. If persistent, investigate the specific $setuphold values. |
NTCDNG | Negative values on both reference and data limits for different edges — causes non-convergence. | Timing check limits zeroed; check may not fire correctly. | Report to library vendor. Different-edge negative values for both limits is a characterisation problem. |
NTCRLX | Non-convergence due to non-overlapping two-limit constraints. Limits relaxed by 2 precision units. | Limits slightly adjusted; simulation continues. | Usually benign. Verify relaxed limits do not change timing check outcome for critical paths. |
NTCELX | Same as NTCRLX but relaxation required exceeded a permissible percentage — limits changed significantly. | Large adjustment to limits; timing check reliability reduced. | Investigate. Large limit changes indicate inconsistent NTC values. Report to library vendor. |
NTCPAT | NTC delay is larger than some portion of an enclosing path delay. NTC delay may visibly affect output transition timing. | Output transitions may be delayed beyond path delay alone. | Verify the affected path is not on a critical timing arc. |
SDFNCAP | Source and destination for interconnect annotation are not hierarchically connected by a wire — unidirectional continuous assignment detected. | Port annotation placed at destination; source annotation skipped. | Review netlist connectivity. Usually benign for unidirectional assigns. |
SDFNSB | A module being annotated has no specify block. | Annotation silently fails for that module. | Add a specify block to the cell model, or confirm the cell genuinely has no timing (e.g. tie cell). |
In the final weeks before tape-out, GLS timing violations must be triaged with discipline. Every failing instance falls into one of three categories: genuine timing failure (backend ECO required), known acceptable violation (CDC, false path — tfile waiver with documentation required), or annotation artefact (investigation required before categorisation). The danger is misclassifying a genuine failure as an annotation artefact to avoid an ECO cycle. Any violation where the waveform correctly shows the SDF-annotated delay AND the actual slack is negative is a genuine failure — no exceptions. Verification leads should track the ratio of genuine failures to annotation artefacts — a high artefact rate indicates a library model or SDF quality problem.
Pulse-flagged-as-error warnings (Issue 7) are often the only simulation-time indicator of combinational glitches on control signals. A glitch on a clock enable or asynchronous reset shorter than the cell propagation delay will be rejected by inertial delay and appear as a pulse warning with X on the gate output. If that X reaches a flip-flop clock enable, it creates an X that propagates through the flip-flop and contaminates downstream logic. Teams doing formal glitch analysis should cross-check formal results against GLS pulse warnings — any path that formal declares glitch-free but GLS flags deserves investigation.
Negative timing check values are increasingly common in 7nm, 5nm, and 3nm standard cell libraries. A negative hold time (e.g. −20ps) means the cell allows data to change up to 20 ps before the clock edge and still latches correctly. This happens because at advanced nodes, cells are aggressively sized to reduce setup time and the hold margin is built into the cell’s internal timing. NTC warnings are a normal feature of advanced-node GLS. The key question is always: did the NTC algorithm converge (NTCNNC/NTCDNG absent or resolved)? If yes, timing checks are working correctly even though the underlying values are negative.