Running Verdi's X-tracing headless (srcActiveTrace walk vs tfgTrX batch): load cost, accuracy and memory pitfalls

I benchmarked Verdi W-2024.09 X-root-cause tracing in batch mode (verdi -nogui -play script.tcl) on a large synthetic RISC-V SoC FSDB with KDB. Two approaches. (1) A manual walk the way an engineer does it: srcActiveTrace (add -range when only some bus bits are X), read the fan-in values at the active time with srcGetCurrentValue, find when each one's X began with nWave's wvGetSearchPrevTime, follow the earliest, and stop at no X input, a declaration (Verdi's answer for a never-written reg), the testbench, or a loop. (2) The built-in Temporal Flow View X trace: it does work headless, as tfgSetupTFV then tfgBehaviorAnalysis then tfgTrX ... -batchOutput <file> -causeCnt 1 -noBBox. Findings: the session load before the first answer was 13.6-18.8 s per launch, which dominates short traces; TFV setup adds about 2.5 s once per session; per-step trace calls are usually under 1 s. Because each step depends on the last, extra licences only help through speculative prefetch of the next step's fan-in leaves. The built-in tfgTrX was correct on simple flop/reset cases, but reported a false 'black box output' on a deep pipeline. On a PC/jump path it ran 11+ minutes at 100% CPU and 9.7 GB RSS; with -maxLev 20 it still hit a 5 GB guard after about 190 s. Always run it under a memory guard on shared hosts. The manual srcActiveTrace walk was the most accurate of the methods tested. Also tie the remote session's lifetime to an idle timeout: a dropped client left Novas holding the licence seat.