virtuoso-bridge-lite: An SSH Bridge That Lets LLM Agents Drive Cadence Virtuoso

The gap between an LLM agent and a running Virtuoso session

Cadence Virtuoso is controlled through SKILL, a Lisp-like language evaluated inside the CIW. An LLM agent cannot type into a CIW window, and it cannot hold an interactive session open across tool calls. The README frames the project as infrastructure for Agentic Analog and Mixed-Signal Design, where LLM agents drive Virtuoso instances locally or remotely. The problem it addresses is transport and lifecycle: getting a command from a Python process or an agent into a live Virtuoso session, and getting results back, without a human copy-pasting SKILL into the CIW. The intended audience is engineers who already have Virtuoso running and want automated or agent-driven flows across schematic, layout, Maestro and Spectre. It is not a Virtuoso replacement and it does not ship a simulator. The README is explicit that SKILL execution and Spectre simulation are independent: you can run Spectre without the SKILL bridge, and use the SKILL bridge without Spectre.

How the bridge reaches Virtuoso: tunnels, roles and a daemon

The architecture is a tunnel plus a daemon. The `virtuoso-bridge start` command starts a tunnel and prints the `load(...)` line you paste into the CIW, which loads the daemon side. `virtuoso-bridge status` reports tunnel, Virtuoso daemon and Spectre availability in one place. Hosts are described by roles rather than a single address. `VB_REMOTE_HOST` is the simple one-host setting, but installations that split GUI from compute can set `VB_GUI_HOST`, `VB_DEPLOY_HOST`, `VB_DAEMON_HOST` and `VB_SPECTRE_HOST` separately. The README notes that defaults are deployment equal to GUI and Spectre equal to the legacy or daemon host, and that a shared jump host is suppressed automatically when the target itself is the jump host. Status reads a daemon identity file written from the CIW banner, so it can detect a daemon and tunnel host mismatch even when the TCP endpoint looks wrong. That detail matters: a bridge that only checks whether a port answers would report healthy while commands land on the wrong machine. For SSH concurrency the README states that OpenSSH ControlMaster is not usable with every Windows SSH build, so a Paramiko backend exists behind `uv pip install -e '.[ssh]'` with `VB_SSH_BACKEND=paramiko` and `VB_SSH_MAX_SESSIONS=10`.

Getting it running: init, start, status and the env file trap

The README gives a concrete quick start. Clone the repository, create a virtual environment with `uv venv .venv`, activate it, then `uv pip install -e .`. Configuration lives in `~/.virtuoso-bridge/.env`, created by `virtuoso-bridge init user@host`, optionally with a jump host via `-J user@jump-host`. Running `virtuoso-bridge init` with no arguments produces an empty template for you to edit `VB_REMOTE_HOST` yourself. Then `virtuoso-bridge start` brings up the tunnel and prints the CIW `load(...)` line, and `virtuoso-bridge status` checks the three moving parts. On Windows PowerShell the activation line becomes `.\.venv\Scripts\Activate.ps1`. One behaviour deserves attention before you embed the bridge in a long-lived process. Python entry points discover the nearest parent `.env` containing a bridge host role or `VB_LOCAL_PORT` and load it with `override=True`, which the README says can change a long-lived process from local to remote mode. The documented remedy is to pin the file explicitly with `set_runtime_env_file("/path/to/virtuoso-bridge.env")` from `virtuoso_bridge.env` before constructing a client. If you skip that call, environment discovery can silently redirect your commands to a different host than the one you intended.

Bootstrap is deliberately narrow, and that is the right call

For an opt-in X11 bootstrap the README describes a two-step sequence. First list candidate windows with `virtuoso-bridge list-windows --top-level --json`, then inject only the generated setup command with `virtuoso-bridge bootstrap --window 0x3000012`. The command refuses windows not identified as a CIW and does not accept arbitrary SKILL text. That restriction is a real design choice, not a limitation to work around. A bootstrap that accepted free-form SKILL would be a remote code execution surface pointed at a licensed EDA tool; constraining it to a generated setup command and a verified CIW window reduces the blast radius. The README also notes that if the daemon is not loaded yet, the normal manual `load(...)` remains valid. So the bootstrap is a convenience layer over a path that already works by hand, and you can ignore it entirely if you are willing to paste the load line yourself. What the material does not describe is what happens when the window list is empty or the CIW is minimised, so treat the bootstrap as best-effort rather than the only route in.

What the bridge does not solve

The dependency list is short and unforgiving. Remote mode needs SSH access, a running Virtuoso and a `load(...)` executed in the CIW. Local mode still needs a running Virtuoso plus `VB_REMOTE_HOST=localhost`. The Spectre path needs `spectre` on PATH or `VB_CADENCE_CSHRC` set. None of that is bundled, and none of it can be faked. The README also warns that `VB_REMOTE_SCRATCH_ROOT` must be readable from both the CIW and the daemon host, noting that `/tmp` is often isolated. If your site mounts scratch differently on the two hosts, the bridge will not paper over it. The Paramiko backend is opt-in for a reason: it exists because ControlMaster is not usable with every Windows SSH build, which means single-connection multiplexing on those builds is a known weak point unless you install the extra. Finally, the material describes no licence server handling, no Virtuoso version matrix and no statement about which Cadence releases are supported. If your Virtuoso is older or newer than what the maintainers run, you are on your own until you test it. This is the wrong tool for anyone without a Cadence licence, and it is overkill for a single manual simulation you could run from the CIW in a few minutes.

Compared with writing your own SKILL and Python glue

The obvious alternative is a homegrown setup: an SSH tunnel, a small Python client that writes SKILL to a file, and a CIW-side daemon you write yourself. That approach gives you total control and no dependency on this project's env-file discovery, role model or CLI. It also means you own the daemon protocol, the reconnect logic, the host-role handling and the diagnostics. The difference in approach is where the complexity sits. A homegrown bridge typically starts as a single host and a single session, then grows ad hoc handling for a second server or a split GUI and compute layout. virtuoso-bridge-lite encodes those cases up front: named host roles, a daemon identity file for mismatch detection, an opt-in Paramiko backend for multi-session multiplexing, and a `status` command that reports all three subsystems. The trade is that you inherit its configuration model, including the `.env` discovery behaviour and the role defaults, and you debug its abstractions when something does not connect. For a one-host, one-session script the homegrown route is less machinery. For parallel simulations across servers and accounts, which the README lists as a supported use, the role model is the part you would otherwise have to build.

Maintenance, licence and what to verify before you commit

The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence with no copyleft obligation, though it offers no patent grant, and nothing here constitutes legal advice; check with your own counsel if patent exposure matters to your organisation. Maintenance cost is dominated by the parts you do not control. The bridge sits between an LLM agent, an SSH transport and a Cadence installation, so a Virtuoso upgrade, an SSH build change or a host reconfiguration can break it independently of the bridge code. The repository shows a v0.8.0 release titled Scoped Spectre pools and hardened transports, which suggests transport reliability has been an active area. The material does not give a support window, a compatibility table or a deprecation policy, so pin the version you validate and re-run `virtuoso-bridge status` after any change to the host roles or the SSH backend. The first thing to verify is not a feature: it is whether `status` correctly distinguishes your tunnel, your daemon and your Spectre binary on your actual machines.

Editorial conclusion

Adopt virtuoso-bridge-lite if you already run Cadence Virtuoso, have SSH access to the design host, and want an agent or script to drive SKILL, Maestro and Spectre without writing a custom transport. Skip it if you have no Virtuoso licence, no CIW to load the daemon into, or if your workflow is a one-off manual simulation, because the bridge adds a tunnel and a daemon you would still have to keep alive. Before committing, run virtuoso-bridge init, start and status against your real host and confirm the status output resolves the tunnel, the daemon identity file and Spectre availability; if the daemon host differs from the GUI host, verify the VB_GUI_HOST, VB_DAEMON_HOST and VB_REMOTE_SCRATCH_ROOT roles against your own layout first.

Official sources

1. Arcadia-1/virtuoso-bridge-lite on GitHub
2. License: MIT
3. Project website
4. README
5. Releases