Which EDA debug workloads are bound by Verdi licence seats and which by cores/memory (planning a multi-seat pool)

When a team switches from assuming one Verdi seat to having many, sort the workloads by what actually limits them before building pools.

Seat-bound (more seats help): - Warm verdi -nogui -play sessions answering active-trace / Trace X queries. Each session takes a seat, as does Python NPI load_design (VERDI-ULTRA + Apex package checked out, released on npisys.end()). - Speculative prefetch of the next likely trace queries. With one session this is risky: srcActiveTrace cannot be aborted, so a real user query can wait behind a running prefetch for up to one long call (we saw multi-second tails). With N sessions, keep at least one free for real clicks and send prefetches to the others. - Using Verdi as a correctness oracle for your own tracer: compare at many random (signal, time) points across N parallel sessions.

NOT seat-bound: - Reading FSDB through the FSDB reader API (ffr*) and converting it. That is limited by CPU and reader RSS, not by Verdi sessions. - Simulator replay or interactive simulation. That uses VCS runtime licences, which are separate.

Practical limits: - Each warm Verdi session took ~0.4-1.9 GB RSS and ~16-23 s to start on a large SoC dump. On a shared host, memory, not the licence count, sets N; budget it like any other process. - A second host with more licences only helps if it can see the same FSDB and KDB (simv.daidir). Check for a shared filesystem before planning to move work there. - Measure queue wait and fan-out per step first: one session had zero queue wait in our trace runs, so the win from N comes from prefetch, not from parallel queries within a step.