Delivering Silicon Systems Through AI Disruption, Part 1: Writing the Score

Source: https://semiwiki.com/semiconductor-services/flow-accel/374405-delivering-silicon-systems-through-ai-disruption-part-1-writing-the-score/

Score: the written music for an orchestra, with every section’s part laid out on the same page so they play together. In this article, it’s your designed workflows.

총보(Score): 오케스트라를 위한 악보로, 모든 파트의 악보가 한 페이지에 정렬되어 함께 연주할 수 있도록 구성된 것입니다. 이 글에서 총보는 여러분이 설계한 워크플로를 의미합니다.

Is AI helping you hit your tape-out date, or putting it at risk? How would you know?

AI가 테이프아웃(Tape-out) 일정을 맞추는 데 도움을 주고 있나요, 아니면 오히려 일정을 위험에 빠뜨리고 있나요? 그것을 어떻게 알 수 있을까요?

Every Director I talk to is being asked to use AI to deliver faster, or better, or more efficiently, sometimes all three. And they’re still on the hook for the date they committed to. The tools are changing mid-program. Some tasks really are faster, but nobody can say yet whether the date is safer or at more risk.

제가 만나는 모든 디렉터들은 더 빠르거나, 더 우수하거나, 더 효율적으로(때로는 이 세 가지 모두를 충족하며) 결과를 내기 위해 AI를 사용하라는 요구를 받고 있습니다. 하지만 그들은 여전히 자신이 약속한 일정에 대한 책임을 지고 있습니다. 도구들은 프로젝트 진행 도중에 계속 바뀌고 있습니다. 어떤 작업은 실제로 더 빨라졌지만, 일정이 더 안전해졌는지 아니면 더 위험해졌는지 누구도 아직 장담하지 못합니다.

A leader I’ve worked with for years put the real question simply: where do I invest? In this program, or in the tools and flows for the next one?

수년간 함께 일해 온 한 리더는 본질적인 질문을 아주 단순하게 던졌습니다. "어디에 투자해야 하는가? 이 프로그램에 투자해야 하는가, 아니면 다음 프로그램을 위한 도구와 흐름에 투자해야 하는가?"

To invest in the right place, and to know it’s working, your workflows have to be designed, monitored, and improved as fast as your program is changing. Think of it as an orchestra. The score is your designed workflows. The conductor keeps everyone in time: the operating model that monitors and improves the work. This article is about the score. Part 2 is about the conductor.

올바른 곳에 투자하고 그것이 실제로 효과가 있는지 알기 위해서는, 여러분의 워크플로가 프로그램이 변화하는 속도만큼이나 빠르게 설계되고, 모니터링되며, 개선되어야 합니다. 이를 오케스트라에 비유해 봅시다. 총보는 여러분이 설계한 워크플로입니다. 지휘자는 모든 사람이 박자를 맞추도록 유지해 주는 주체, 즉 작업을 모니터링하고 개선하는 운영 모델(operating model)입니다. 이 글은 '총보'에 관한 이야기입니다. 2부는 '지휘자'에 관한 내용입니다.

Designing the work is harder than it sounds, because AI is changing it at three layers at once.

작업을 설계하는 것은 들리는 것보다 훨씬 어렵습니다. AI가 세 가지 레이어에서 동시에 작업을 바꾸고 있기 때문입니다.

Gene Kim and Steven Spear, in their book “Wiring the Winning Organization,” describe three layers in every organization. In silicon development, layer 1 is the technical work: circuits, RTL, firmware. Layer 2 is the tools: EDA, verification, debug, and their data. Layer 3 is the social circuitry: the hand-offs, reviews, and decisions that move work between people.

진 킴(Gene Kim)과 스티븐 스피어(Steven Spear)는 저서 《이기는 조직의 설계(Wiring the Winning Organization)》에서 모든 조직의 세 가지 레이어를 설명합니다. 반도체 개발에서 레이어 1은 기술적 작업(회로, RTL, 펌웨어)입니다. 레이어 2는 도구(EDA, 검증, 디버그 및 관련 데이터)입니다. 레이어 3은 사회적 회로망(social circuitry), 즉 사람과 사람 사이에서 작업을 이동시키는 핸드오프(인수인계), 검토, 의사결정입니다.

The three layers, adapted from Kim and Spear’s Wiring the Winning Organization

AI is showing up in all three, and a change in one lands on the others. For each layer, you need to know where to use AI, how to use it, and what it does to your date. That starts with understanding how the work is designed.

AI는 이 세 가지 레이어 모두에 나타나고 있으며, 한 레이어에서의 변화는 다른 레이어에 고스란히 영향을 미칩니다. 각 레이어별로 어디에 AI를 사용해야 할지, 어떻게 사용해야 할지, 그리고 그것이 일정에 어떤 영향을 미치는지 알아야 합니다. 이는 작업이 어떻게 설계되어 있는지 이해하는 것에서 시작됩니다.

Layer 1: The Technical Work

This is where most of the AI excitement is. At TSMC’s ecosystem forum in September, TSMC claimed its new AI Design Kit boosts digital design productivity three to five times, and analog/RF up to six. Teams are drafting RTL and firmware from specs faster than ever.

대부분의 AI 관련 기대감이 집중되는 곳이 바로 여기입니다. 9월에 열린 TSMC 에코시스템 포럼에서 TSMC는 자사의 새로운 AI 디자인 키트가 디지털 설계 생산성을 3~5배, 아날로그/RF는 최대 6배까지 향상시킨다고 주장했습니다. 팀들은 그 어느 때보다 빠르게 사양서로부터 RTL과 펌웨어를 초안 작성하고 있습니다.

It works best on blocks you understand well: node migrations, derivatives of something you’ve already built, and code you can check against a clear spec. The teams getting real value write the spec and the tests first. The AI proposes. The engineer decides. Harden what you’ve proven, and keep flexibility where the design is new.

이 방식은 잘 이해하고 있는 블록들, 즉 노드 마이그레이션, 이미 구축한 것의 파생형, 명확한 사양에 대해 검증할 수 있는 코드에서 가장 잘 작동합니다. 진정한 가치를 얻고 있는 팀들은 사양서와 테스트를 먼저 작성합니다. AI가 제안을 하고, 엔지니어가 결정합니다. 검증된 부분은 하드닝(Harden)하고, 새로운 설계 부문에서는 유연성을 유지합니다.

What it does to your date depends on what happens next. A block that’s done early lands on someone’s desk early. More RTL means more to verify. More firmware means more to integrate. Speed in layer 1 becomes load in layers 2 and 3.

이것이 일정에 미치는 영향은 다음에 무슨 일이 일어나느냐에 달려 있습니다. 일찍 끝난 블록은 일찍 누군가의 책상 위에 도달하게 됩니다. 더 많은 RTL은 더 많은 검증을 의미합니다. 더 많은 펌웨어는 더 많은 통합을 의미합니다. 레이어 1에서의 속도는 레이어 2와 3에서의 부하가 됩니다.

Layer 2: The Tools

Verification is where most teams started, and that makes sense. It eats about half the schedule. The 2026 Wilson Research Group study found 83% of teams using AI in verification, mostly for debug, test generation, and coverage. Only 9% have it integrated across the whole flow. The top barrier wasn’t cost. It was fitting AI into the tools and flows teams already have.

검증은 대부분의 팀이 시작한 분야이며, 이는 지극히 당연합니다. 검증은 전체 일정의 약 절반을 차지하기 때문입니다. 2026년 윌슨 연구 그룹(Wilson Research Group)의 연구에 따르면, 팀의 83%가 검증에 AI를 사용하고 있으며 주로 디버그, 테스트 생성, 커버리지에 활용하고 있습니다. 전체 플로우에 걸쳐 AI가 통합된 경우는 단 9%에 불과합니다. 가장 큰 장벽은 비용이 아니었습니다. AI를 팀이 이미 보유하고 있는 도구와 플로우에 맞추는 것이었습니다.

In my last SemiWiki piece, I asked how much of that half is really verification, and how much is the work around it. AI is speeding up the steps. It isn’t touching the waits between them: the regression queue waiting on licenses and compute, the triage meeting, the fix waiting on a designer. Treat regression, triage, debug, fix, and rerun as one flow, and size it for the volume layer 1 is about to send you.

지난 세미위키 기사에서 저는 그 절반의 시간 중 실제로 검증에 소요되는 시간은 얼마이며, 그 주변의 주변부 작업에 소요되는 시간은 얼마인지 질문했습니다. AI는 각각의 단계를 가속화하고 있지만, 단계 사이의 대기 시간(라이선스와 컴퓨팅을 기다리는 회귀(regression) 큐, 트리아지 미팅, 설계자의 수정을 기다리는 시간)은 건드리지 못하고 있습니다. 회귀, 트리아지, 디버그, 수정, 재실행을 하나의 플로우로 취급하고, 레이어 1이 여러분에게 곧 보낼 볼륨에 맞춰 그 규모를 산정해야 합니다.

Layer 3: The Social Circuitry

We design every path a signal takes on a chip. We time it, margin it, and test it. Almost nobody designs the path a decision takes between two teams: RTL to verification, hardware to firmware, design to validation.

우리는 칩 위에서 신호가 지나가는 모든 경로를 설계합니다. 타이밍을 맞추고, 마진을 두고, 테스트를 거칩니다. 하지만 두 팀 사이에서 의사결정이 이동하는 경로(RTL에서 검증으로, 하드웨어에서 펌웨어로, 설계에서 밸리데이션으로)를 설계하는 사람은 거의 없습니다.

That’s where the speed from layers 1 and 2 goes to wait. It lands on the same few senior engineers who have to judge whether the output is right. Microsoft’s 2026 Work Trend Index says it plainly: “the more agents execute, the higher the stakes around human evaluation.”

레이어 1과 2에서 얻은 속도가 가서 멈추는 곳이 바로 여기입니다. 이 속도는 결과물이 올바른지 판단해야 하는 소수의 시니어 엔지니어들에게 부담으로 작용합니다. 마이크로소프트의 2026년 업무 트렌드 지수(Work Trend Index)는 이를 명확히 지적합니다. "에이전트가 실행하는 작업이 많아질수록, 인간의 평가가 갖는 중요성은 더욱 커집니다."

AI can help here too. Some teams are building review agents that carry their standards, security rules, and lessons from past bugs, and check the work in real time instead of weeks later. But that only works if someone designed the hand-off first: what gets passed, what signal says it’s ready, and who decides.

AI는 이 부문에서도 도움을 줄 수 있습니다. 일부 팀은 자체적인 표준, 보안 규칙, 과거 버그로부터 얻은 교훈을 담은 검토(review) 에이전트를 구축하여, 몇 주가 지난 뒤가 아니라 실시간으로 작업을 검토하도록 하고 있습니다. 하지만 이는 누군가가 핸드오프를 먼저 설계한 경우에만 작동합니다. 즉, 무엇이 전달되는지, 준비되었다는 신호는 무엇인지, 누가 결정하는지가 설계되어 있어야 합니다.

The System of Work

I’ve seen this before. Leaders added engineers to the team that looked like the bottleneck. That team got faster. The work still waited, just somewhere else.

저는 이런 광경을 전에도 본 적이 있습니다. 리더들은 병목 현상처럼 보이는 팀에 엔지니어를 더 투입했습니다. 그 팀은 더 빨라졌습니다. 하지만 작업은 여전히 정체되었고, 단지 다른 곳에서 막힐 뿐이었습니다.

Every engineer knows why. Amdahl’s law: speeding up part of a job can only help as much as the rest of the job allows.

모든 엔지니어는 그 이유를 알고 있습니다. 암달의 법칙(Amdahl's law)에 따르면, 작업의 일부를 가속화하는 것은 나머지 작업이 허용하는 한도까지만 효과를 낼 수 있습니다.

Say AI makes three quarters of your work twice as fast, and the rest doesn’t change. The whole job gets 1.6 times faster, not 2. The part you didn’t touch goes from a quarter of your schedule to 40 percent of it.

AI가 작업의 4분의 3을 두 배 더 빠르게 만들고 나머지는 전혀 바뀌지 않는다고 가정해 봅시다. 전체 작업은 2배가 아니라 1.6배 빨라집니다. 건드리지 않은 부분은 일정의 4분의 1에서 40퍼센트로 비중이 커지게 됩니다.

And the constraint can sit in any layer. Fix it in one, and it moves to the next.

그리고 제약 요인은 어느 레이어에든 존재할 수 있습니다. 한쪽에서 해결하면, 제약은 다음 레이어로 이동합니다.

Writing the Score

Your score is your designed workflows, owned at every level, the way you’d design a chip: blocks, subsystems, the SoC. Most teams don’t have one. Microsoft found that even among the most advanced AI users, only about a quarter have their hand-offs and quality standards documented and repeatable across the organization.

여러분의 총보는 칩을 설계하는 방식(블록, 서브시스템, SoC)과 마찬가지로 모든 수준에서 소유권을 갖는 설계된 워크플로입니다. 대부분의 팀은 이러한 총보를 가지고 있지 않습니다. 마이크로소프트의 조사에 따르면, 가장 앞선 AI 사용자들 사이에서도 조직 전체에 걸쳐 핸드오프와 품질 표준이 문서화되어 있고 반복 가능하게 갖춰진 경우는 약 4분의 1에 불과합니다.

You don’t need a transformation program to start. Pick one workflow that aligns with a bigger problem you are trying to solve, like delivering faster or scaling operations.

1. Define the problem and the outcome. Which date are you trying to pull in, and by how much?
2. Understand the work. Map the roles, hand-offs, and sequence of activities around the problem, including the tools and the data that moves between them. The map will surface the issues and show which to fix first as the dependencies become clear. Baseline what you plan to improve so you can measure it.
3. Redesign the work with AI. Redesign it end to end, within and between all three layers.

시작하기 위해 거대한 전환 프로그램이 필요할 필요는 없습니다. 더 빠르게 제품을 출시하거나 운영을 확장하려는 등, 해결하고자 하는 더 큰 문제와 일치하는 워크플로 하나를 선택하십시오.

1. 문제와 결과 정의하기: 어떤 일정을 얼마나 앞당기려 하는가?
2. 작업 이해하기: 해당 문제를 중심으로 역할, 핸드오프, 활동 순서(그 사이를 오가는 도구와 데이터 포함)를 매핑합니다. 이 맵은 문제점을 표면화하고, 의존성이 명확해짐에 따라 어떤 것을 먼저 수정해야 할지 보여줄 것입니다. 개선하려는 대상을 측정할 수 있도록 기준선(baseline)을 설정하십시오.
3. AI로 작업 재설계하기: 세 가지 레이어 내부와 그 사이를 아우르는 엔드투엔드로 작업을 재설계합니다.

That’s how my post-silicon team started when we were three weeks late on a five-week schedule. We mapped the work, found where the time was going, and redesigned it. Validation cycle time came down by half, and we hit the five-week date for the next ten steppings.

이것이 바로 제 포스트 실리콘 팀이 5주 일정에서 3주나 지연되었을 때 시작한 방식입니다. 우리는 작업을 매핑하고, 시간이 어디로 새고 있는지 찾아내어 재설계했습니다. 밸리데이션 사이클 타임이 절반으로 줄어들었고, 그 다음 10번의 스테핑(stepping)에서 모두 5주 일정을 맞출 수 있었습니다.

Close

Everyone is getting the same AI tools. The teams that keep their commitments through this disruption will be the ones with a score and a conductor.

모든 사람이 똑같은 AI 도구를 사용하고 있습니다. 이러한 혼란 속에서도 약속을 지켜내는 팀은 총보와 지휘자를 갖춘 팀일 것입니다.

A score on its own doesn’t play. In Part 2, I’ll get into the conductor: the operating model that monitors the work while it’s happening, gives every workflow an owner, and connects them from the block to the program to the portfolio.

총보만으로는 연주할 수 없습니다. 2부에서는 작업이 진행되는 동안 이를 모니터링하고, 모든 워크플로에 오너(소유자)를 지정하며, 블록에서 프로그램, 포트폴리오로 연결해 주는 운영 모델인 지휘자에 대해 다루겠습니다.

BIO

Joel Jorgensen founded FlowAccel, helping silicon systems engineering leaders deliver on roadmap commitments and scale development organizations. During 25 years at Intel, he spent 15 years in analog design and architecture for non-volatile memory technologies, earning two patents and co-authoring two IEEE ISSCC papers. He also served as an NPI Chair in manufacturing and later led efforts to expand the use of Steven Spear’s High Velocity Edge methodology beyond Intel’s SSD organization, including bringing Spear in to work directly with Intel engineering leadership.

조엘 요르겐센(Joel Jorgensen)은 FlowAccel을 설립하여 실리콘 시스템 엔지니어링 리더들이 로드맵 약속을 이행하고 개발 조직을 확장할 수 있도록 돕고 있습니다. 인텔에서 25년 동안 재직하며 비휘발성 메모리 기술을 위한 아날로그 설계 및 아키텍처 분야에 15년간 종사했고, 2개의 특허를 취득했으며 2편의 IEEE ISSCC 논문을 공동 집필했습니다. 또한 제조 부문의 NPI 의장을 역임했으며, 이후 스티븐 스피어(Steven Spear)의 '하이 벨로시티 엣지(High Velocity Edge)' 방법론의 적용 범위를 인텔의 SSD 조직 외의 부문으로 확장하는 노력을 이끌었고, 스피어가 인텔 엔지니어링 리더십과 직접 협력하도록 주도했습니다.