Agentrys hotchips 2
WP_Term Object
(
    [term_id] => 157
    [name] => EDA
    [slug] => eda
    [term_group] => 0
    [term_taxonomy_id] => 157
    [taxonomy] => category
    [description] => Electronic Design Automation
    [parent] => 0
    [count] => 4581
    [filter] => raw
    [cat_ID] => 157
    [category_count] => 4581
    [category_description] => Electronic Design Automation
    [cat_name] => EDA
    [category_nicename] => eda
    [category_parent] => 0
)

Semiconductor Engineering Has a State-Continuity Problem

Semiconductor Engineering Has a State-Continuity Problem
by Moh Kolb on 09-14-2026 at 8:00 am

Key takeaways

Semi eng state conti Problem sept11 semiwiki

Product realization depends not only on reaching the next engineering state, but on preserving the relationships between states from intent through qualification, release, and lifecycle learning.

Semiconductor development is usually described as a sequence of activities: architecture, design, fabrication, packaging, test, qualification, production, and release.

But a product is doing something more fundamental as it moves through that sequence.

It is changing engineering state.

What begins as intent becomes prediction. Prediction becomes physical hardware. Hardware becomes measured evidence. Evidence supports qualification. Qualification contributes to manufacturing confidence, yield, and release. Once the product enters production and the field, another state is created through lifecycle behavior and learning.

Each transition creates a new engineering state of the same product.

The difficult question is not simply whether each stage succeeds. It is whether continuity is preserved between the states.

From Stages to States

Traditional development flows are organized around stages because stages are easy to assign to teams, tools, and organizations. Design has its models. Manufacturing has process history. Metrology has measurements. Test has functional results. Reliability has qualification data. Yield has statistical outcomes.

Those domains can all work correctly and still leave a deeper engineering problem unresolved.

The product may arrive at a new state without preserving enough of the relationship to the state that came before it.

A qualified device, for example, is not simply a device that passed a reliability sequence. Its qualified state should remain connected to the design assumptions, predicted behavior, realized physical structure, manufacturing history, and measured evidence that produced the hardware under test.

Likewise, a yield result is more than a production percentage. It is evidence about whether an intended product state can be repeatedly realized across manufacturing variation.

This suggests a different way to think about product realization: not as a collection of completed stages, but as a progression through trustworthy engineering states.

Three Concepts: State Realization, State Continuity, and Engineering Continuity

Three related concepts help separate the problem.

State realization is the creation of the next trustworthy engineering state of the product.

State continuity is the preservation of the relationship between that state and the states that came before and after it.

Engineering continuity is the broader capability that maintains those relationships across the lifecycle.

These distinctions matter because traceability alone is not enough. Traceability can tell us which wafer, lot, assembly, revision, test record, or measurement belongs to a device. State continuity asks a harder question: does the engineering system preserve what those observations mean in relation to one another?

A Product Moves Through Multiple Engineering States

One useful abstraction is:

Intent State → Predicted State → Realized Physical State → Measured / Evidence State → Qualified State → Repeatable / Yield State → Released State → Lifecycle State

Each state answers a different question.

The intent state defines what the product is expected to do. The predicted state captures what models say should happen. The realized physical state is what was actually built. The measured or evidence state describes what can be established from inspection, metrology, test, and correlated observations. The qualified state captures what the product has demonstrated under reliability and stress. The repeatable or yield state asks whether the desired product state can be reproduced at manufacturing scale. The released state represents the evidence-supported decision that the product is ready for use. The lifecycle state reflects what the product becomes under real workloads, environments, aging, and field experience.

The product can change engineering state many times without changing identity. The challenge is to keep those states connected.

Qualification Should Connect Backward

Qualification is a particularly useful example.

Qualification is often treated as a downstream checkpoint: build the hardware, run the sequence, pass or fail.

But qualification should also preserve continuity backward.

If an intermittent failure appears during thermal cycling, the useful engineering question is not only whether the unit failed. The deeper question is whether the observed behavior can be connected back to the relevant physical state, process condition, material or interface history, measured geometry, predicted behavior, and original design assumption.

A failure that cannot be connected backward creates learning friction. A pass that cannot be connected backward also leaves uncertainty: the product survived, but do we understand why?

This changes qualification from an endpoint into another realized engineering state whose meaning depends on continuity with the states that produced it.

Yield Is a State-Realization Signal

Yield deserves the same treatment.

Yield is usually summarized as a manufacturing metric. But at a deeper level, yield asks whether the intended product state can be repeatedly recreated across the physical distribution of manufacturing.

A high first-pass yield can indicate that design intent, physical realization, process capability, and test criteria are converging. A low or unstable yield suggests that one or more of those relationships is not sufficiently controlled.

Seen this way, yield is not merely the output of manufacturing. It is evidence about the repeatability of state realization.

Lifecycle Learning Must Reconnect to the Product That Shipped

The same issue appears after release.

Field data can be extremely valuable, but only if the learning can reconnect to the engineering state of the product that entered the field.

A thermal excursion, link-margin drift, optical degradation, intermittent power behavior, or reliability signature has far more engineering value when it can be related to the relevant design revision, as-built structure, manufacturing history, measured evidence, and qualification state.

Without that continuity, field data becomes another isolated dataset. With continuity, it becomes lifecycle engineering evidence.

This Is Not a Data-Volume Problem

Semiconductor engineering does not lack data.

EDA systems generate design and simulation data. Manufacturing systems record process execution. Equipment systems capture conditions and events. Inspection and metrology systems generate images and measurements. Test systems produce electrical, optical, and functional results. Reliability systems generate stress and failure data. Yield systems produce population-level outcomes.

The challenge is not simply to collect more of it.

The challenge is to preserve the engineering relationships between states as the product changes.

A temperature measurement, for example, is not automatically useful because it exists in a database. Its engineering meaning becomes much stronger when it remains connected to the predicted thermal state, the realized package geometry, the material and interface condition, the workload, the measurement uncertainty, and the later reliability behavior.

That is state continuity.

Why Heterogeneous Integration Makes the Problem Harder

The problem becomes more important as systems become more heterogeneous.

An AI package may combine compute chiplets, HBM, I/O, power delivery, optical engines, advanced substrates, complex thermal structures, and multiple assembly technologies. Each domain introduces its own models, process conditions, physical variations, measurements, and qualification dependencies.

The product therefore accumulates more engineering states and more state transitions.

Local optimization is no longer enough. A design state that is electrically valid but physically difficult to realize, a manufactured state that cannot be adequately characterized, or a qualified state that cannot be connected back to its physical cause can all interrupt product convergence.

The more complex the physical stack becomes, the more important engineering continuity becomes.

Toward Continuous State Realization

This leads to a broader idea: continuous state realization.

Continuous state realization does not mean every engineering stage operates continuously in time. It means the product should be able to progress from one trustworthy engineering state to the next without losing the relationships that make those states meaningful.

That creates a stronger progression:

Intent → Prediction → Realized Physical State → Evidence → Qualification → Repeatability → Release → Lifecycle Learning

The key word is not sequence. It is continuity.

Each state should be supported by evidence. Each state should remain related to the assumptions and physical conditions that produced it. Each transition should carry forward the engineering knowledge required to interpret the next one.

The Broader Engineering Question

This changes the question semiconductor organizations should ask.

Not only: Did design finish? Did manufacturing complete? Did the unit pass test? Did qualification pass? Did yield reach target?

But also:

Did the next engineering state preserve its relationship to the previous one?

Can qualification behavior connect backward to the realized physical state?

Can yield connect backward to the design and manufacturing conditions that produced the distribution?

Can field behavior reconnect to the state of the product that was actually released?

Can new learning change the next product state rather than remaining trapped in the stage that generated it?

Closing

Product realization is not a collection of successful stages.

It is a progression through trustworthy engineering states whose relationships remain intact.

State realization creates the next trustworthy engineering state.

State continuity preserves its relationship to previous and subsequent states.

Engineering continuity maintains those relationships across the lifecycle.

As AI hardware becomes more heterogeneous, more physically complex, and faster to design, preserving that continuity may become one of the most important engineering capabilities in the semiconductor lifecycle.

The product may change state many times.

Its engineering continuity should not break when it does.

Also Read:

When Design Gets Faster, the Bottleneck Moves Through the Physical Stack

The Fab Is Not the Finish Line

Temperature Does Not Only Age Hardware — It Moves the System

 

Share this post via:

Comments

There are no comments yet.

You must register or log in to view/post comments.