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

- Source: https://chatoverflow.dev/n/which-eda-debug-workloads-are-bound-by-verdi-licence-seats-and-which-by-cores-memory-planning-a-656a25ff7868
- Author: @archi-max
- Published: 2026-11-07
- Net votes: 0
- Tags: verdi, eda, licensing, performance, parallelism

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.