The Editor Becomes the Control Plane: Keysight SOS Inside Visual Studio Code (VS Code) and the Rework Economy of Chip Design
Industrial organizations rarely lose capacity to a missing tool. They lose it at the seams between tools — the moment an engineer leaves one window to fetch a file, confirm a revision, or ask a colleague which version actually shipped to the fab. Electronics and semiconductor design teams have felt those seams more sharply than most, because their artifacts are now authored largely as text while their data infrastructure was built for directories and checklists. The move to place engineering data management inside the code editor is therefore not a convenience story. It is a workflow-consolidation story, and Keysight SOS arriving inside Visual Studio Code is one of the clearest signals that the industry is treating design history, revision control and traceability as production-system problems rather than IT housekeeping.
Background: the editor won the daily workflow first
Digital and mixed-signal engineering has quietly converged on text-based development. RTL, HDL, testbench code, Tcl scripts, constraint files and build automation are edited, diffed and reviewed in the same kind of workspace that software teams use. Stack Overflow's 2025 Developer Survey lists Visual Studio Code as the single most-used development environment, with more than 70% of surveyed respondents reporting regular use — a level of concentration that makes the editor the default control plane of engineering work, not an optional front end.
Against that backdrop, the architecture of many design organizations looks inconsistent. The repository, the license server, the simulation farm and the sign-off database still sit behind separate interfaces, so engineers hop between editors, command-line tools and standalone repositories to handle versions, collaboration and design history. That is precisely the gap Keysight SOS targets: bringing design data management into the VS Code workspace so the record of what changed, who approved it and which revision was verified travels with the file being edited.
Root cause: hardware design data does not behave like application source code
It is tempting to conclude that the software industry already solved this problem with Git, and that hardware teams simply need to copy the playbook. The mismatch is structural. Keysight's own engineering-data commentary on adapting Git for IC design notes that hardware data requirements and workflows differ fundamentally from software practice — libraries, schematics, layouts, simulation databases and binary netlists do not merge, diff or branch the way source files do. A repository tuned for plain-text commits can end up storing gigabytes of untracked simulation output while leaving the semantically meaningful unit — the design cell, the released revision, the sign-off record — invisible.
Read the embedded-data-management approach as a response to that structural mismatch rather than as a plug-in. A purpose-built IC and electronic design data management platform typically layers revision control, storage management and change traceability under the editor, and exposes those operations where the engineer is already working.
| Dimension | Generic text repository + manual scripts | Data management embedded in the editor |
|---|---|---|
| Unit of versioning | File / directory | Design cell, block, library element and its derived views |
| History quality | Commit messages, often incomplete for derived data | Linked change intent, owner, tool version and verification result |
| Large or binary artifacts | Awkward; growth forces pruning and mirror copies | Managed storage tiering handled by the platform |
| Sign-off and release | Manual checklists, email approvals, spreadsheet state | Gates enforced as part of the workspace action |
| Cross-site consistency | Snapshot exchange, drift between branches | Single governed view shared across locations |
| Reuse of proven IP | Copy-paste, uncertain revision lineage | Searchable, revision-anchored IP with known status |
Why traceability turned into a financial variable
Two data series explain the urgency. First, the Siemens EDA / Wilson Research Group 2026 Functional Verification Study reports that only 5% of IC and ASIC respondents achieved first-silicon success, down from 14.4% in 2024 — the continuing erosion of a metric that historically served as a proxy for process maturity. Second, the same research family has long shown how the schedule is split: in the 2020 study, design engineers averaged roughly 53% of their time on design activity and 47% on verification, which means most engineering labor is spent proving the design rather than creating it.
Overlay the money. McKinsey's semiconductor design and manufacturing analysis puts the total design cost of a 5 nm chip at about $540 million, versus roughly $175 million at 10 nm. When a program costs that much, a small improvement in revision confidence has outsized value: rework is no longer measured in engineering hours but in mask sets, foundry slots and missed product windows. Knowing exactly which revision of a block, constraint set or testbench produced a specific verification result is the cheapest insurance available to a design organization — and it is a records problem, not a compute problem.
Two reference patterns worth borrowing from
The open-source silicon movement provides the first pattern. OpenTitan, stewarded by the not-for-profit lowRISC, publishes its implementation, design verification collateral, full-chip tests and continuous-integration infrastructure in a public repository, and documents its use of GitHub Actions to declaratively describe test jobs. The lesson is methodological rather than licensing: hardware programs can run software-grade discipline — reviewable changes, automated gates, reproducible history — when the repository is treated as the authoritative record. Teams that already work this way are naturally receptive to a data-management layer that lives inside the same workspace, because it preserves the interaction model they trust.
The commercial pattern is the mirror image. Enterprise digital and mixed-signal shops keep their authoritative data in a governed platform, and the recent direction of travel has been to push operations toward the design environment instead of pulling engineers away from it — an approach documented in Keysight material spanning the IC design environment, EDA tool integrations and, now, a white paper on bringing design data management into the developer workflow for Visual Studio Code. For an industrial reader, the takeaway is the convergence of these two patterns: open silicon proved that repository-centric rigor works for hardware; governed data platforms are trying to make that rigor survivable at production scale.
Common misconceptions
- "It is only an interface change." Moving revision, history and release state into the editor changes the audit posture of the whole program. What gets recorded, and when, is a governance decision disguised as a user-experience one.
- "Our Git instance already covers this." Source control and design data management overlap but are not substitutes. Derived views, tool-version coupling and library semantics usually fall outside a plain-text repository's model.
- "Process discipline slows delivery." Manual sign-off rituals are what slow delivery. Automated gates attached to a checked-in change typically shorten the loop from problem report to verified fix.
- "This is an IT deployment, not an engineering program." Ownership split between IT and design is the most common failure mode: retention policy, access model and migration scope need engineering-process owners.
- "AI-assisted design makes data management optional." The opposite holds. Generated RTL, tuned parameters and model-driven flows multiply the number of candidate revisions per unit time, which raises the value of provenance and reproducibility.
Implementation path: a staged rollout for operations and engineering leadership
- Pick one reusable object, not one team. Choose an IP block or a constraint set that two or more projects consume. Reuse pressure exposes lineage problems that a single-project pilot hides.
- Baseline before migrating. Capture mean time from change request to checked-in verified revision, percentage of schedule spent on re-verification of already-validated blocks, and count of duplicate files circulating across sites. These three metrics decide whether the program is worth extending.
- Map the interaction, not the feature list. Document every command the pilot team currently runs outside the editor — checkout, compare, promote, tag, release — and confirm which of them become workspace actions. Anything left outside the workspace will still be done manually.
- Design the access and retention model early. Mixed digital and mixed-signal projects attract participants with different clearance levels, including suppliers. Define who can see which library, who can approve a release, and how long simulation data is kept.
- Wire the record to automation. Keep the repository or platform as the source of truth for CI, so a build, a regression run and a revision identifier are inseparable — the practice that open silicon projects normalized.
- Extend with training tied to onboarding. New engineers ramp fastest when the data workflow is identical to the editing workflow; make the workspace the first thing a new hire is taught, not a second system introduced in week three.
Risks and guardrails
Three risks deserve explicit management. Migration scope is the largest: partially migrated history creates two versions of the truth, which is worse than the disconnected starting point. Second, workflow drift between teams — one group promoting changes inside the editor, another still using shared directories — quietly reintroduces the seams the program was meant to close. Third, toolchain coupling: an embedded data-management layer that assumes one editor or one operating environment needs a documented fallback path for contractors, legacy servers and air-gapped projects. A staged rollout with a rollback checkpoint at each phase addresses all three.
Frequently asked questions
Is this relevant if we only design PCBs and don't run a chip program?
Yes, in a scaled-down form. The same failure modes appear in board-level work: multiple revisions of a schematic circulating between designers, an unclear relationship between a released netlist and the assembly package, and supplier handoffs built on file attachments. The unit of versioning differs; the governance problem does not.
Does putting data management in the editor remove command-line or scripted control?
It should not. Mature deployments expose the same operations through scripts and interfaces so regression automation and batch promotion keep working; the editor becomes the interactive surface, not the only access path. Confirming programmatic parity is a practical pilot acceptance test.
How much of this is about tooling versus process?
Most of the measured benefit in comparable programs comes from process artifacts — a single authoritative record, enforced gates, retrievable history — that any tooling choice can support or defeat. Budget for the process work first.
What is a realistic first milestone?
A closed loop on one shared object: change requested, revision created, verification linked, release approved, and the whole chain reconstructed later without asking anyone. That is achievable in a limited pilot window and is diagnostic of the wider rollout.
Trend judgment
The interesting reading of Keysight SOS appearing inside Visual Studio Code is not the product news but the boundary shift. Tool vendors are discovering that the scarce resource in engineering is not storage or even licenses — it is the continuity of context across a working day. Expect the next competitive line in electronic design infrastructure to be drawn around workflow consolidation: fewer handoffs, richer provenance, and release state enforced where the keystroke happens. For managers outside semiconductors, the transferable insight is blunt. Measure your organization by the number of window switches required to answer "which version is this?" and reduce that number; that metric predicts rework far better than any tooling budget.