The IP Blast Radius Problem in Modern Silicon

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:

• Aerospace
• Automotive
• Heavy manufacturing

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:

• Reused IP across multiple concurrent programs
• Chiplet / multi-die partitioning
• FPGA → ASIC migrations
• Firmware tightly coupled to RTL
• Pre-silicon, emulation, virtual prototyping, post-silicon debug
• Safety, export, and security trace overlays

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:

• Multiple version control environments
• Global engineering sites
• 10,000+ engineers
• Thousands of internal and third-party IP blocks
• Parallel programs in different execution phases

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:

• Commits the change in Perforce
• Logs the issue in Jira
• Updates the firmware
• Adjusts timing constraints
• Pushed updated verification collateral

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:

• Which active programs instantiate this exact IP revision?
• Which derivative SKUs are affected?
• Which regression suites are now invalid?
• Which signoff assumptions must be revisited?
• Which milestones are exposed?

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:

• IP instantiation relationships
• Change propagation across reuse graphs
• Verification impact amplification
• Cross-tool execution trace

Not from BOM governance. Not from document routing. Not from enterprise standardization. Glide assumes:

• SCM hygiene already exists
• Perforce is not the problem
• Engineers do not need more process
• The bottleneck is cross-domain visibility

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:

• IP is reused across multiple product lines
• FPGA and ASIC programs overlap
• Chiplet architectures multiply dependency paths
• Verification cycles dominate program time
• Schedule compression reduces slack
• Safety and security overlays increase traceability demands

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:

• “One system shows it automatically” — then you’re already there
• “It takes coordination across tools and people” — that is the gap

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:

1. IP reuse is accelerating
2. Tool fragmentation is increasing
3. Change velocity is rising under AI-assisted design flows

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:

• Start with the IP graph
• Start with change propagation
• Start with verification impact visibility
• Start with a cross-tool execution trace

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