Case Retrospective: What Integrating Keysight SOS Into Visual Studio Code (VS Code) Reveals About Fragmented Engineering Workflows

Read this the way you would read a post-mortem rather than a product note. The system under review is not a chip and not an IDE — it is the path a design asset travels from a keystroke to a signed-off, versioned cell. The defect being examined is workflow fragmentation, and the fix being examined is the decision to move design data management out of a side console and into the workspace engineers already have open. Keysight SOS enters the story as the management layer, Visual Studio Code enters as the surface people actually touch all day, and the shorthand most teams type, VS Code, is exactly why the integration is cheap enough to be worth measuring.

Baseline: one engineer, three disconnected systems

Before the change, the typical digital or mixed-signal engineering desk looks like this: source in one window, a terminal for repository commands in a second, and a front-end for libraries, shelves or promote operations in a third. Versions, collaboration and design history are all real capabilities, but they are scattered across three interaction points, so the engineer pays for them with attention instead of with clicks.

The symptoms recur in almost every retrospective of this kind of setup:

• Check-in happens late, in a terminal, after the reasoning that produced the edit has already left working memory — so commit messages describe files, not intent.
• A reviewer can read a diff but cannot see the lineage: which workspace, which promotion, which review produced the version on screen.
• Verification assets (test benches, scripts, constraints) are versioned more casually than RTL, because they sit in the awkward zone between "code" and "tool output".
• New hires spend their first weeks learning where data lives rather than learning the design.
• Large generated artifacts either bloat the repository or get excluded entirely, which pushes them outside history.

The uncomfortable conclusion from that list is that the tooling is not weak — the seam between tools is the weak point. That reframing is what makes the next step logical rather than cosmetic.

Why the editor became the control plane

There is a simple adoption argument for putting management operations where the work is. Visual Studio Code is not a niche choice for these teams; it is the default. In the Stack Overflow 2024 Developer Survey, more than 65,000 respondents answered in May 2024, and the editor was reported in use by 73.6% of developers, more than double the share of its nearest desktop-IDE peer. The 2025 edition put that figure at 75.9%, still first among IDEs and text editors. Hardware description languages, RTL source, build and regression scripts, and verification assets are now routinely authored in that same environment, on a workspace that is extensible by design.

So the interesting engineering question is not "should we add a plugin" but "which capability is missing: management functions, or the entry point to them?" For teams working with RTL, HDL and verification code, the functions already exist inside Keysight SOS; what was missing was the ability to reach them without leaving the editor.

What "embedded" means at the extension layer

Two technical facts make this kind of integration legitimate rather than decorative.

First, VS Code ships a documented Source Control API intended to let any version-control system present itself through the editor's built-in source-control UI — the same staging, diff, group and status model that the bundled Git extension uses (Microsoft, "Source Control API", code.visualstudio.com/api/extension-guides/scm-provider). An SCM-agnostic API surface means a hardware design repository can appear with first-class affordances instead of a bespoke panel bolted onto the sidebar.

Second, the vendor ships an actual companion extension for the VS Code workspace rather than a link that opens another window; Keysight documents the pattern in its "Design Data Management Inside VS Code With Keysight SOS" post and in the white paper "Bringing Design Data Management into the Developer Workflow". The stated aim in the source material is to accelerate digital and mixed-signal engineering by keeping workflow, versioning and history together — which, for a software-development reader, is best understood as removing hand-offs, not as adding features.

Reproducing the migration: a seven-step sequence

1. Inventory asset classes before touching tools. Split the tree into hand-written text (RTL, HDL, scripts, constraints), generated artifacts (netlists, reports, bitstreams, waveforms) and IP/library metadata. The management model differs per class; pretending it does not is the most common early mistake.
2. Pick one pilot library with a live but low-risk schedule. A verification block or a peripheral IP is a better pilot than the top-level SoC. Define the exit criteria in advance: review turnaround, revert count, and time from "edit done" to "version recorded".
3. Push the workspace configuration, not individual installations. Declare the extension in the repository's recommendations file so every clone of the project gets the same toolset, and pin settings in workspace configuration. This is the step that turns a personal preference into a team standard.
4. Map lifecycle states onto editor affordances. Draft, in review, approved, promoted, released — each state needs a visible status in the file view. If a state cannot be represented in the UI, it will not be respected in practice.
5. Keep the command line as the contract. Any operation available in the editor must also be available headless, so regression jobs and CI gates keep working. An integration that only exists in the GUI splits your automation surface.
6. Gate promotion on evidence, not memory. Bind review status and simulation results to the promote action so a version cannot advance without its checks attached. This is where traceability stops being documentation and becomes enforcement.
7. Instrument before you celebrate. Log switches away from the editor, queue times for reviews, and the share of check-ins that happen the same day as the edit. Compare against the pre-pilot baseline from step 2.

Three operating models, side by side

Dimension	Repository tooling only, driven from a terminal	Management console outside the editor	Management surfaced inside VS Code (Keysight SOS pattern)
Where the version action happens	A separate shell session	A separate application window	In the same workspace as the edit
Attention cost	High: leaves the file and the reasoning context	High: two UI models to hold in mind	Reduced: versioning reuses the editor's source-control model
Large generated binaries	Poor fit; Git stores deltas of text, so binaries balloon repository size (Perforce, "Version Control for Binary Files")	Designed for EDA artifacts	Inherits the EDA-aware layer rather than raw Git semantics
Visibility of design history	Commit log only, intent stripped	Rich, but opened on demand	History travels with the file being read
Review and promote gates	Manual, convention-based	Enforced inside the console	Enforced at the point of editing
Multi-site IP sharing	Mirror/clone discipline	Central platform	Central platform, familiar access path
Onboarding a new engineer	Two systems first, design later	Two systems first, design later	One interface to learn
Best suited to	Small, text-only, single-team projects	Formal release management with dedicated admins	Digital and mixed-signal teams whose daily surface is a code editor

The table is deliberately qualitative. Vendor material for this integration does not publish a before/after cycle-time number, and inventing one would be the worst service you could do to your own baseline measurement.

Reading the results: what plausibly moved

The result the source material does claim is structural: keeping workflow, versioning and collaboration history in one place, and using that to accelerate digital and mixed-signal engineering. For a delivery-oriented reader, the mechanism behind that claim is interruption cost. Work by Gloria Mark at UC Irvine on interrupted work found that the resumption penalty after an attention shift is on the order of 23 minutes for the affected task — a figure repeated across HCI literature on task interruption. If a check-in ritual drags an engineer out of a deep-read session on a netlist or a test bench, the ritual is not free even when it takes 30 seconds.

Two second-order effects matter for software teams running hardware-adjacent work:

• Commit quality improves when intent is still in memory. Versioning that happens at the moment of edit produces records a reviewer can actually interpret months later.
• The verification set gains standing. Once scripts and test benches sit in the same governed view as RTL, they inherit review and promotion discipline instead of drifting as "tooling".

Five misconceptions that stall adoption

• "Plain Git is enough for everything in the tree." Keysight's own engineering blog on this topic, "Optimizing IC Design Data Management: Git-R-Don't for Hardware Design", argues why a Git-shaped workflow struggles with IC-specific requirements; the broader industry point about binary-heavy repositories is well documented. Use Git semantics for text, EDA-aware management for design data, and don't force one to do the other's job.
• "An extension is just a shortcut." If the extension is a launcher, you have added a third tool. The requirement is that status, diff, history and promotion behave like first-class workspace objects.
• "The GUI replaces automation." It should not. Anything a reviewer can do by clicking must stay reachable from scripts, or your regression pipeline forks into two realities.
• "Migration is a one-time project." It is a policy change about when data may move between states; that policy needs an owner, or the old terminal habits return within a quarter.
• "Traceability is for auditors." In practice it is what lets you bisect a failure to a specific design decision instead of a specific file.

Action checklist for the next two sprints

1. Measure your current baseline: median time from edit to recorded version, and count of tool switches per check-in.
2. Classify every file type in one library as text, generated artifact, or IP metadata.
3. Adopt the editor-side entry point for that library via shared workspace recommendations, not personal installs.
4. Define the lifecycle states your team will enforce, and bind one gate — review, or simulation pass — to promotion.
5. Keep a headless path for every operation; add it to CI.
6. Re-measure after one release cycle and compare against step 1 before expanding scope.

FAQ

Is this only relevant to hardware teams, or to software delivery generally?

The pattern is general even though the case is specific: any team whose authoritative data lives behind a separate console loses time to context switching. What is hardware-specific is the artifact mix — huge generated binaries, EDA-aware lifecycle rules, IP reuse — which is exactly why a repository model alone does not carry it.

Why keep everything in Visual Studio Code instead of building a better console?

Because adoption is a function of where attention already is. The 2025 Stack Overflow survey reading of 75.9% editor usage means the console has to be opened, whereas the workspace is already open. The management layer supplies the capability; the editor supplies the traffic.

What does the Keysight SOS + VS Code pairing change day to day?

Nothing in the data model changes for the engineer; the access path does. Versioning, review state and design history are reached from the same window used to write RTL, HDL and verification scripts, which is the mechanism behind the stated goal of accelerating digital and mixed-signal engineering.

Should we retire Git?

No. Keep Git where its text-delta model is a strength — scripts, documentation, software-side IP — and put design data behind a management layer that understands EDA artifacts and lifecycle. The failure mode is a single tool asked to do both jobs.

How do we prove the integration paid for itself?

With your own numbers, not published ones: elapsed time from edit to version, share of same-day check-ins, review turnaround, revert/bisect cost, and onboarding time for a new engineer on the pilot library. Since no public before/after study exists for this specific pairing, an internal baseline is the only honest evidence.

Sources referenced beyond the original report

• Stack Overflow Developer Survey 2024 and 2025 editions (editor/IDE usage shares; 65,000+ respondents in May 2024) — stackoverflow.co.
• Microsoft, "Source Control API" extension guide — code.visualstudio.com/api/extension-guides/scm-provider.
• Keysight, "Design Data Management Inside VS Code With Keysight SOS" (blog) and the white paper "Bringing Design Data Management into the Developer Workflow" — keysight.com.
• Keysight, "Optimizing IC Design Data Management: Git-R-Don't for Hardware Design", 10 April 2024 — keysight.com.
• Perforce, "Version Control for Binary Files", on repository growth with large binaries — perforce.com.
• Gloria Mark, UC Irvine human–computer interaction research on interrupted work and resumption cost — ucsurfer.ics.uci.edu.

Filed by James Hartley for the SoftwareDevelopment desk at ItInsightsWorld (IT Insights). Corrections and practitioner stories: contact@itinsights.com.