At our launch event last week, someone from a major silicon company said something that stuck with me:
“I had narrowed my PLM decision down to Siemens or Dassault — but your comment about Glide being the first PLM built from the bottom up for semiconductor was intriguing.”
Let me explain what I meant. Because this isn’t about replacing PLM. It’s about something more structural.
Semiconductor Is Not Mechanical Engineering with Chips
Most legacy PLM systems were born in:
They are optimized for structured BOM hierarchies, change orders, document control, and governance. Modern silicon engineering is different. It is not a linear BOM problem. It is a distributed dependency graph.
What does that mean?
It means that in modern SoC design, every major element — IP blocks, firmware, verification suites, requirements, safety cases, derivative SKUs — is interconnected. A change in one place does not stay in one place. It propagates across reused IP instances, across programs, and across lifecycle stages.
A modern SoC — especially in organizations operating at a global scale — includes:
The complexity isn’t in a single tool. It exists between tools. That becomes a visibility constraint. Each tool sees its slice of the world. No system natively sees the full web of relationships across them. When a dependency changes, the impact is not automatically visible across domains. At scale, that becomes a structural blind spot.
A Scenario That Will Feel Familiar
A typical Silicon organization looks something like this:
Now imagine that one reused piece of IP, let's say a SerDes IP block, is updated to address a late-calibration edge case.
The team:
Everything is technically correct. Version control is pristine. Audit trail exists. Governance is satisfied. But here’s the real question:
How long does it take to see the full downstream impact?
Not locally. Across programs. Across all reused instances. Across verification environments. Across the schedules. Across safety trace links.
What Actually Happens in Most Organizations
The repo knows what changed. Jira knows why. Jama knows the requirement. Verification tools know the regressions. But no system shows the relationship graph that answers:
So, impact analysis becomes reconstruction. Someone pulls the repository history. Someone cross-references Jira. Someone messages a senior engineer. Someone builds a spreadsheet. It works in the sense that teams eventually piece together the answer. But it doesn’t scale. It relies on human coordination across tools. And human-assembled systems do not scale linearly with IP reuse in modern SOC designs.
What “Built Bottom-Up for Semiconductor” Actually Means
When I said Glide was built bottom-up for semiconductor, I did not mean “better workflow UI.” I meant the data model starts from:
Not from BOM governance. Not from document routing. Not from enterprise standardization. Glide assumes:
It sits above Perforce, Jira, Jama, and design repositories — without replacing them. That is a fundamentally different architectural starting point than mechanical PLM.
Why This Matters at Enterprise Silicon Scale
At a small scale, engineers can hold impact in their heads. At enterprise scale:
Under those conditions, a late change is rarely isolated. It is amplified. And amplification without visibility becomes schedule risk. The objective is not better planning. It is the execution truth derived from the existing infrastructure.
The Only Question That Matters
When something changes late in one of your programs, how long does it take to confidently understand the full downstream impact — and where does that information come from?
If the answer is:
That gap isn’t a Perforce problem. It isn’t a Jira problem. It isn’t a PLM problem. It’s a cross-domain visibility problem for execution.
The Watchtower Perspective
Across the semiconductor stack, three forces are converging:
Fragmentation used to be inefficient. Now it is economically material. The organizations that win will not reduce complexity. They will instrument it.
Final Thought
When I said Glide was “the first PLM built bottom-up for semiconductor,”
What I meant was:
Not BOM governance. Not workflow routing. Not enterprise consolidation. Glide was designed for the reality inside silicon programs — not adjacent industries. If that’s intriguing, then the next conversation isn’t about PLM selection. It’s about whether execution visibility at scale is already solved — or still reconstructed manually.
Learn more about Glide here: Glide Systems
Subscribe to our blog series here: AI TechSales Blog AKA The Watchtower Brief