Semiconductor Engineering Has a State-Continuity Problem
Source: https://semiwiki.com/eda/373472-semiconductor-engineering-has-a-state-continuity-problem/
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.
전통적인 개발 프로세스는 팀, 도구, 조직별로 역할을 할당하기 쉽기 때문에 단계(stage) 중심으로 조직되어 있습니다. 설계에는 모델이 있고, 제조에는 공정 이력이 있습니다. 계측에는 측정값이 있고, 테스트에는 기능적 결과가 있습니다. 신뢰성에는 검증 데이터가 있고, 수율에는 통계적 결과가 존재합니다.
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.
이 문제를 명확히 구분하는 데 도움이 되는 세 가지 연관된 개념이 있습니다.
- 상태 구현(State realization)은 제품의 다음 단계에 해당하는 신뢰할 수 있는 엔지니어링 상태를 창조하는 것입니다.
- 상태 연속성(State continuity)은 해당 상태와 그 이전 및 이후 상태들 사이의 관계를 유지하는 것입니다.
- 엔지니어링 연속성(Engineering continuity)은 라이프사이클 전반에 걸쳐 이러한 관계들을 유지할 수 있는 더 광범위한 역량을 의미합니다.
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?
이러한 구분이 중요한 이유는 '추적성(traceability)'만으로는 충분하지 않기 때문입니다. 추적성은 특정 디바이스가 어떤 웨이퍼, 랏, 어셈블리, 리비전, 테스트 기록, 혹은 측정값에 속하는지 알려줄 수 있습니다. 하지만 상태 연속성은 더 까다로운 질문을 던집니다. 즉, 엔지니어링 시스템이 그러한 관측값들이 서로 어떤 연관성을 가지는지 그 의미를 제대로 보존하고 있는가 하는 점입니다.
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
유용한 추상화 개념 중 하나는 다음과 같습니다:
의도 상태(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.
검증은 특히나 유용한 예시입니다. 검증은 종종 하드웨어를 제작하고, 테스트 시퀀스를 실행한 뒤 통과 여부를 판정하는 하류(downstream) 단계의 관문 정도로 취급되곤 합니다. 하지만 검증은 과거와의 연속성도 함께 유지해야 합니다.
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.
예를 들어 열 순환(thermal cycling) 테스트 도중 간헐적인 고장이 발생했을 때, 유용한 엔지니어링적 질문은 단순히 해당 유닛이 불합격했는가 여부가 아닙니다. 더 깊이 파고들어야 할 질문은, 관측된 이상 행동을 관련 물리적 상태, 공정 조건, 소재 및 인터페이스 이력, 측정된 기하학적 구조, 예측된 동작, 그리고 최초의 설계 가정과 다시 연결하여 설명할 수 있는가 하는 점입니다.
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.
과거로 추적하여 연결할 수 없는 고장은 학습의 마찰을 유발합니다. 마찬가지로, 원인과 연결되지 않은 채 그냥 통과(pass)한 결과 역시 불확실성을 남깁니다. 제품이 살아남긴 했으나, 왜 살아남았는지 우리가 과연 제대로 이해하고 있는가 하는 점입니다. 이는 검증을 단순히 끝나는 종착점이 아니라, 그것을 만들어낸 이전 상태들과의 연속성에 의미가 존속되는 또 하나의 실현된 엔지니어링 상태로 탈바꿈시킵니다.
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.
수율(Yield) 역시 동일한 관점으로 다뤄져야 합니다. 수율은 대개 제조 지표로 요약되곤 합니다. 그러나 더 깊은 차원에서 수율은 제조 공정의 물리적 분포 전반에 걸쳐 의도된 제품 상태가 반복적으로 재현될 수 있는지를 묻는 지표입니다.
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.
높은 초도 수율(first-pass yield)은 설계 의도, 물리적 구현, 공정 역량, 그리고 테스트 기준이 서로 수렴하고 있음을 나타낼 수 있습니다. 반대로 낮거나 불안정한 수율은 이러한 관계 중 하나 이상이 충분히 통제되고 있지 않음을 시사합니다. 이러한 관점에서 볼 때, 수율은 단순한 제조 공정의 산출물이 아닙니다. 그것은 상태 구현의 반복 가능성에 대한 증거입니다.
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.
열 탈출(thermal excursion), 링크 마진 표류(link-margin drift), 광학적 성능 저하(optical degradation), 간헐적 전력 이상, 혹은 신뢰성 시그니처 등의 현상은 관련 설계 리비전, 빌드 당시의 구조, 제조 이력, 측정된 증거, 그리고 검증 상태와 연계될 수 있을 때 훨씬 더 큰 엔지니어링적 가치를 지니게 됩니다. 그러한 연속성이 없다면 필드 데이터는 또 하나의 고립된 데이터셋에 불과하게 됩니다. 하지만 연속성이 뒷받침된다면, 이는 라이프사이클 엔지니어링의 핵심 증거로 탈바꿈합니다.
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.
반도체 엔지니어링에는 데이터가 부족하지 않습니다. EDA(전자 설계 자동화) 시스템은 설계 및 시뮬레이션 데이터를 생성합니다. 제조 시스템은 공정 실행 기록을 남깁니다. 장비 시스템은 조건과 이벤트를 포착합니다. 검사 및 계측 시스템은 이미지와 측정값을 생성합니다. 테스트 시스템은 전기적, 광학적, 기능적 결과를 산출합니다. 신뢰성 시스템은 스트레스 및 고장 데이터를 생성합니다. 수율 시스템은 집단 수준의 결과물을 만들어냅니다.
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.
시스템이 더욱 이종화됨에 따라 이 문제는 한층 더 중요해집니다. AI 패키지는 연산 칩렛, HBM(고대역폭 메모리), I/O, 전력 공급, 광학 엔진, 고성능 서브스트레이트(기판), 복잡한 열 구조, 그리고 다양한 조립 기술을 결합할 수 있습니다. 각 영역은 저마다의 모델, 공정 조건, 물리적 편차, 측정 방식, 그리고 검증 의존성을 수반합니다.
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.
이는 더 광범위한 개념, 즉 지속적인 상태 구현(continuous state realization)으로 이어집니다. 지속적인 상태 구현이란 모든 엔지니어링 단계가 시간상으로 끊김 없이 연속해서 작동한다는 의미가 아닙니다. 이는 제품이 각 상태를 의미 있게 만들어주는 관계를 잃지 않고, 하나의 신뢰할 수 있는 엔지니어링 상태에서 다음 상태로 원활하게 진화해 나갈 수 있어야 함을 뜻합니다.
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.
이를 통해 다음과 같은 더 강력한 발전 과정을 구축할 수 있습니다:
의도 → 예측 → 구현된 물리적 상태 → 증거 → 검증 → 반복 가능성 → 출시 → 라이프사이클 학습
여기서 핵심 단어는 '순서(sequence)'가 아니라 '연속성(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.
AI 하드웨어가 더욱 이종화되고, 물리적으로 복잡해지며, 설계 주기가 빨라짐에 따라, 이러한 연속성을 보존하는 것은 반도체 라이프사이클에서 가장 중요한 엔지니어링 역량 중 하나가 될 것입니다.
The product may change state many times. Its engineering continuity should not break when it does.
제품은 상태를 수없이 바꿀 수 있습니다. 하지만 그 과정에서 엔지니어링 연속성만큼은 결코 끊어져서는 안 됩니다.
