Silicon IP Operations: Your PLM Can't Do It, and Neither Can Jira

The tool you already own was designed for the left. The problem lives on the right.

In brief Brandon Meredith's article names the category: Silicon IP Operations, the connected management of IP as a live technical, commercial and lifecycle asset. This piece is about what companies do next. Door one is the mechanical-heritage PLM the company already owns (Siemens Teamcenter, Dassault 3DEXPERIENCE). It models parts and assemblies; silicon IP is a versioned, licensed, wrapped, multi-program graph. The fit requires customisation, and customisation is the tell. Door two is to build it on Jira with AI on top. It works for one product generation and then becomes the home-grown internal system Brandon describes in his opening, without the scale that justified it. Door three is a purpose-built platform evaluated against Brandon's six capabilities. Glide Semi from Glide Systems is the first we have seen that passes all six and carries the graph past tapeout into wafer, package and test.

Brandon Meredith and I have spent much of this year in the same rooms, on the same problem, and he has now written the piece I wish had existed when we started. His article on Silicon IP Operations does the thing categories need most: it names the work. Know what IP you have, know where every version is used, know what governs it commercially, and know what happens across the portfolio when any part of it changes. It is not IP lifecycle management, not traditional PLM, not manufacturing BOM management, and there is no incumbent platform for it. I am not going to restate his argument; read it. I want to pick up where it ends, because in our experience the moment a company accepts the category is also the moment it makes its most expensive decision.

01The evidence the category is real

Before AI Tech Sales, I spent years on the vendor side of commercial semiconductor IP, watching well-run design teams hurt themselves in the same handful of ways. We eventually wrote them down in Managing Commercial Semiconductor IP, the operational playbook in our Technical Guidance Series. It catalogues nine recurring failure modes, and reading it against Brandon's definition, every one of them is a failed answer to his central question: where is this IP used, and what does that mean?

• Taping out on a forked patch that never entered a formal release: nobody could see that the version in the tapeout database was not the version in the vendor portal.
• Silent version drift: two programs believe they share a controller and do not, so a firmware workaround for one breaks the other.
• Bugs never tracked to closure through patch, release and documentation, so the next program rediscovers the root cause from scratch.
• Register map drift between an IP release and the firmware that programs it, the single most common cause of bring-up delay we see.
• Feature enablement mismatch: hardware enables a power state the firmware cannot handle, and the link drops only at production load.

None of these is an EDA failure. Each is a relationship between an asset, a version, a program, a firmware binding and a vendor obligation that existed in someone's head and not in a system. The guide's maturity model puts most teams at Level 2 or 3: reactive tickets, partial version tracking, a pre-tapeout review if someone remembers. Level 4 needs a vendor cadence, structured defect tracking and quarterly IP quality ratings; Level 5 adds hardware-firmware co-validation and predictive issue management. You do not reach either level with a spreadsheet, and the interesting question is what companies reach for instead.

02Door one: the PLM you already own

The first instinct, particularly where a chip business sits inside a larger systems company, is to extend the enterprise PLM. Siemens Teamcenter and Dassault Systèmes' 3DEXPERIENCE platform are excellent at what they were built for: parts with drawings, revisions and suppliers, rolling up into assemblies, rolling up into a product, with an ECO flowing down the tree and an engineering BOM becoming a manufacturing BOM. Brandon covers the mismatch well; I will only add the table we use when a customer asks us to be specific.

Dimension	Mechanical PLM assumes	Silicon IP actually is
Acquisition	A part is purchased and owned	A block is licensed; entitlement is per program, per use, per unit royalty or subscription, with field-of-use, node and territory scope
Identity	Part number plus revision (A, B, C)	Software-style version (r6.10a) with release class, errata, patches and a databook that changes underneath it
Structure	A part belongs to one parent assembly	One vendor block is wrapped by internal logic and consumed by several programs at different versions and lifecycle stages, concurrently
Change	An ECO flows down the tree	A vendor errata fans out across every wrapper, program and license that touches the block; the vendor fix and the wrapper mitigation are separate resolutions
Where the record lives	In the PLM system	In Git or Perforce, EDA flows, Jira, Jama, vendor portals and contracts; engineers will not enter it twice

You can bend a mechanical PLM toward this. Companies have. What comes back is a parts system with many custom attributes, no native license entitlement, no model of the wrapper relationship, and an impact analysis that still ends in a spreadsheet. Brandon draws the line between configurability and customisation, and this is where it bites: the moment the data model has to be customised rather than configured, the platform was built for another industry and the deployment has become a services project.

The purchase price and the services bill are the visible costs. The larger one is what happens after go-live, and I have watched it play out inside one of the largest chipmakers in the world and at more than one company since. Semiconductor engineers rarely took these systems up. When they did, it was like tax day: the design work happened in the EDA cockpit, the repository and the testbench, and then, after the event, someone filed a record of what had already been decided. The system never held the live state of the design; it held a lagging, partial account of it, entered under protest by people whose real work was elsewhere. And because the engineers would not carry it, the burden moved to whoever would, usually an IT group or a small operations team who became the system's translators, chasing designers for updates and reconciling what the PLM said against what the repository said.

That is how the cost compounds. The system is expensive to buy, expensive to deploy and then expensive to run, because running it means paying people to do by hand the integration the platform was supposed to provide. It never becomes part of the day-to-day working environment of the semiconductor engineer. It remains removed, separate, an overhead, a tax. And a system of record that engineers experience as a tax is not a system of record; it is the spreadsheet with a login page. Hold that thought, because it is the test door three has to pass: whatever the platform models, engineers must not have to leave their tools or enter anything twice for it to be true.

03Door two: build it on Jira, add AI

The second door is newer and more tempting. The team already lives in Jira. It has custom fields, issue links, automation and an API. It now has an AI assistant that can read every ticket, wiki page and repository comment and answer questions in plain English. Why not build the IP operations layer there? We have watched a capable design organisation reach exactly this conclusion after months of dialogue, and I understand the appeal: no procurement, no new vendor, immediate progress.

It will work for the first product generation, for the same reason Brandon gives: in the first product, people can still hold the map in their heads, and the tool only has to remind them. The failure arrives with the second and third generations, and it arrives for structural reasons rather than effort.

• The object is the issue, not the asset. Jira models work to be done. An IP block is not work; it is a versioned, licensed thing that outlives every ticket ever raised against it. Modelling a block, its wrapper, its license, its qualification state and the programs consuming specific versions as issue types and custom fields produces a schema nobody owns and a link graph that decays every time a field is renamed.
• No entitlement gating. A ticketing tool can record that a license covers three programs. It cannot stop the fourth program from designing the block in, because design-in does not happen in Jira.
• AI reconstructs; it does not preserve. An assistant over unstructured tickets rebuilds the dependency graph on every query, from whatever the tickets happen to say. The answer is plausible, fast and unverifiable, and it changes as the tickets change. Brandon's point stands: the value of the category is in preserving relationships the business cannot afford to rediscover manually. An AI that rediscovers them automatically has automated the workaround, not replaced it.
• It becomes the system in Brandon's opening story. An internal platform that grew for years into an essential, inelegant operating system for tens of thousands of engineers. That is the end state of door two. The company that built it had the scale, the CAD organisation and the decades to justify it. Almost nobody else does, and the person who built the Jira schema will eventually leave.

An AI that rediscovers your IP dependency graph on every question has automated the spreadsheet. It has not replaced it. — on the limits of building it yourself

04Door three: evaluate against the category

Brandon closes his article with the six capabilities a Silicon IP Operations platform has to deliver natively: a queryable portfolio source of truth, commercial operations, qualification and provenance, portfolio planning, native change impact, and an extensible object model. I would treat that list as the evaluation checklist, because it removes the drift he warns about. Evaluated as IPLM, the conversation slides toward workspaces and release mechanics. Evaluated as PLM, IT compares against CAD-heritage systems. Evaluated against the six, the right people ask the right questions.

Here is how Glide Semi answers them, in Glide's own terms.

• Queryable portfolio source of truth. A two-layer catalog: internal IP that is built (MAKE), internal IP that is reused, and the internal wrapper around a licensed external block (BUY), kept explicitly distinct, with where-used across every program and version. Federated natural-language query across the connected systems rather than a bespoke report.
• Commercial operations. Licenses as live entitlements: per-program, per-use, royalty, subscription, perpetual and site models with scope, pricing and a programs-remaining position. Entitlement checks gate design-in, so the fourth program against a three-program license is stopped and escalated. Royalty accrues on shipment with vendor-ready usage reports.
• Qualification and provenance. Vendors are first-class actors. Delivery acceptance, spec conformance, re-synthesis, DRC confirmation and export clearance each drive the wrapper's lifecycle state, and every vendor milestone emits a paired internal-IP consequence linked back to its trigger. Process, package, assembly and test qualification are tracked as records, not folders.
• Portfolio planning. Make-vs-buy captured as a structured decision that becomes a tracked BOM line rather than a lost slide; IP requests for new IP, change, waiver and retirement handled as one auditable transaction.
• Native change impact. The defect is the master record; vendor errata and internal finds are its sources; the vendor fix and the wrapper mitigation are independent resolutions that must both close. "Fix released" is not "resolved." The blast radius fans out live to every wrapper, program and license.
• Extensible object model. Configurable to the company's real operating shape and hosted managed, private cloud or on premises. And this is where the tax-day test gets answered: engineers stay in Git, Perforce, Gerrit, their EDA cockpit, Jira and Jama; Glide listens to the systems of record and assembles the connected view underneath them. Milestones, dependencies, IP usage and BOM changes arrive because the work happened, not because someone filed them afterwards. That is the difference between adoption and shelfware, and it is the one property door one can never acquire by customisation.

There is one place Glide Semi goes further than Brandon's scope, and it matters. His system of record ends, roughly, at the design-side asset and its customer exposure. Glide carries the same graph across the design-to-operations wall: GDSII governed as the hand-off artifact, then mask and foundry, wafer sort, assembly, packaging, final test and qualification, with the operations BOM of die, substrate, bond, package and materials anchored to the SKU beside the IP that produced it. When a fab constraint or an OSAT problem surfaces, design sees it in the same place design changes are visible to operations. In his lifecycle example, the program in the field gets a firmware update or documented errata; in Glide, that decision, the affected lots and the customers exposed are one traversal of the same graph.

05Chiplets make the graph cross company lines

Everything above is true for a monolithic SoC. Chiplets remove any remaining doubt. A multi-die package is an assembly of IP at a second level, where each die may come from a different team, node or company, connected over UCIe or a proprietary link. The reuse unit becomes a known-good die with its own version tree, license, qualification state and errata, and the same die can sit in packages at different lifecycle stages across different customers. The informal model that survived one product generation inside one company does not survive a graph that crosses company boundaries. That is the market Yogish Kode and the Glide team are building for.

06Where Glide fits, and a disclosure

Glide Systems is a client of AI Tech Sales; we are its sales-representation partner for the semiconductor market, and Brandon and I have both spent months working the platform against real customer problems. That is why we can describe it with some precision, and why you should read what follows with that in mind.

Glide is best known today for Glide Yoke, a nimble multi-disciplinary PLM used across aerospace, automotive and regulated industries. That reputation is deserved and, for this conversation, slightly unhelpful, because it puts Glide on the same shelf as the mechanical systems behind door one. Glide Semi was built the other way around: from the IP graph, change propagation and the design-to-operations flow up, rather than from BOM governance borrowed from mechanical PLM down. In the EDA 3.0 framing we use at AI Tech Sales, it is the intent layer of the semiconductor lifecycle made operational: requirements say what the chip must do, the IP graph says what it is made of, what that costs, who may use it and what is wrong with it, and the operations thread carries all of that to the qualified part. Brandon named the category. Glide is the first platform we have seen that was built for it, and the team deserves to be known for that rather than for the shelf it happens to sit on.

Frequently asked questions

What is Silicon IP Operations?

As Brandon Meredith defines it, the discipline of managing semiconductor IP as a live operational asset across its full commercial and technical life: the IP asset connected to its versions, issues, licenses, qualification history, dependencies, firmware bindings, product usage, lifecycle stage and customer exposure. It sits above design data management and EDA tools and is distinct from mechanical-heritage PLM.

Can you run Silicon IP Operations in Jira with AI on top?

For one product generation, yes. It does not scale because Jira's object is the issue, not the IP asset: there is no native versioned block, wrapper, license entitlement, qualification record or program-consumes-version relationship. Those live in custom fields and links that decay, and an AI layer reconstructs the graph on every query rather than preserving it.

Why don't Siemens Teamcenter or Dassault 3DEXPERIENCE fit semiconductor IP?

They model parts, assemblies, revisions, ECOs and the eBOM-to-mBOM transformation. Semiconductor IP is licensed, versioned like software, wrapped, consumed by several programs concurrently, qualified per node and corrected by errata. Representing that requires customisation rather than configuration.

How is Silicon IP Operations different from IPLM?

IPLM platforms such as Perforce IPLM are design-data-centric: releases, versions, workspaces and dependency structures inside the design environment. Silicon IP Operations is the connected operational layer above that: licenses, vendor notices, qualification evidence, defects, firmware bindings, make-vs-buy, program usage and the hand-off into wafer, package and test. They are complementary.

What does Glide Semi do?

Glide Semi from Glide Systems is a purpose-built Silicon IP Operations platform that unifies IP management and operations BOM management, modelling internal and external IP, wrappers, license entitlements, vendors, defects and errata, IP requests, make-vs-buy and the GDSII-to-qualified-chip flow, while engineers keep working in Git, Perforce, EDA flows, Jira and Jama.

The Watchtower Brief AI Tech Sales is the sales-representation partner for Glide Systems in the semiconductor market, and the author of Managing Commercial Semiconductor IP, the operational playbook for working with licensed IP. Read Brandon Meredith's companion piece, Silicon IP Operations, for the category definition this article builds on. If your IP portfolio is governed by spreadsheets, a customised mechanical PLM or a Jira project someone built two programs ago, we would welcome the conversation. You can also see Glide Semi directly.