2026년 11월 3일 화요일

[내칩강의2026/7주] 수업공지: 내 칩 MPW 공정 표준 셀 합성 및 제조도면 생성

[내칩강의2026/7주] 내 칩 MPW 공정 표준 셀 합성 및 제조도면 생성

이 강의의 목표는 '내 칩 제작 서비스'의 MPW에 지원[바로가기]하여 세상에서 유일한 내 칩을 가져보는 것입니다. 7주차 수업은 반도체 제조공장에 내 칩을 의뢰하기 위한 제조도면(레이아웃)을 만드는 과정을 살펴봅니다.

컴퓨팅 언어로 기술되어 시뮬레이션과 에뮬레이션으로 충분히 검증된 나의 아이디어를 이제 전용 칩(ASIC, Application Specific IC)으로 제작할 단계에 왔습니다. 우리가 칩 제작을 맞길 공장은 0.5um CMOS 공정을 갖춘 ETRI 특화 반도체 센터의 반도체 제조 시설입니다. 제조도면은 이 반도체 제조 시설에서 제공하는 도면 그리기 규칙(Design Rule)을 따라야 합니다. 이 규칙 문서[링크]에는 트랜지스터를 그리는 기하학적인 방법을 규정하고 있습니다. 하지만 무려 수천에 달하는 트랜지스터로 구성된 디지털 회로(예를 들어 '우주 침략자 게임')를 일일이 트랜지스터 하나하나 그릴수 없습니다.

디지털 회로의 제조도면 생성은 베릴로그 RTL을 합성하여 디지털 논리 소자들의 네트리스트(문서화된 회로도)를 가지고 시작합니다. 논리소자(각종 게이트와 플립플롭)들은 다수의 트랜지스터로 구성된 회로입니다. 이 작은 논리 소자 회로는 미리 라이브러리로 준비하여 디지털 디자인 킷으로 제공 합니다. 디지털 반도체 설계에서 합성 이후의 도면 생성의 과정은 자동화 되어 있습니다. 논리 소자들의 동작은 수학적으로 표현 할 수 있으므로 자동화가 가능 하지만 물리적 그리고 환경적 영향을 많이 받는 트랜지스터 조합의 회로는 자동화가 불가하다는 점도 기억해 둡시다.

이번주 수업에서 '우주 침략자'게임기 예제 중 Q.14[바로가기] 을 가지고 합성, 자동 표준셀 배치 배선 그리고 칩-탑 까지 함께 실시해볼 예정입니다. 아래의 문서를 미리 학습하시기 바랍니다.

    연구노트12: FIR PE의 GDS [바로가기]

이번주(7주차) 수업은 11월 5일(목요일)에 온-라인 줌 미팅 수업으로 진행 하겠습니다.

수업 공지:
- 11월 5일(목요일) 오후 9시에 온라-인 줌 회의로 실시합니다.
- 줌링크: https://snu-ac-kr.zoom.us/j/4984347294?pwd=0JVrMTnCscaN26KrkgjmAjVYh5LmV6.1
* 수업은 공개이므로 누구나 참여할 수 있습니다.


[내칩강의2026/6주] 지난주 까지 과제 되짚어 보기

[내칩강의2026/6주] 지난주 까지 과제 되짚어 보기

지난주까지 인공지능을 활용하여 비디오 게임기 "우주 침략자[링크]" 를 베릴로그 RTL로 작성하고 SystemC(C++) 테스트벤치를 작성하여 시스템 수준 검증과 FPGA를 동원하여 에뮬레이션 및 프로토 타이핑까지 실습해봤습니다. 코드는 인공지능이 작성해 주었고 이를 검증하기 위한 환경(테스트 벤치를 비롯하여 시뮬레이터, 에뮬레이터 빌드 스크립트 등)은 제공된 예제를 따라해 봤습니다. 그 과정에서 스스로 질문을 하고 해결책을 찾아보면서 디지털 반도체 설계 과정을 개략적으로 체득하는 중입니다. 학습 동료들의 학습 노트를 읽어보고 동료들은 어떤 생각을 하고 어떻게 공부하며 질문을 가지고 있는지 함께 돌아보시기 바랍니다.

1. 권효재의 5주차 학습노트[보기]
2. 김예원의 5주차 학습노트[보기]
3. 염재민의 5주차 학습노트[보기]
4. 이현서의 5주차 학습노트[보기]
5. 한찬희의 5주차 학습노트[보기]
6. 안준영의 5주차 학습노트[보기]
7. 김희창의 5/6주 학습노트[보기]
8. 안휘준의 5주차 학습노트[보기]
9. 이수빈의 5주차 학습노트[보기]

이 강의의 목표는 '내 칩 제작 서비스'의 MPW에 지원하여 세상에서 유일한 내 칩을 가져보는 것입니다.오는 7주차 수업은 반도체 제조공장에 내 칩을 의뢰하기 위한 제조도면(레이아웃)을 만드는 과정을 살펴보려고 합니다. 11월 5일(목요일)에 온-라인 줌 미팅 수업으로 진행 하겠습니다.

이제 과정의 중반을 넘긴 만큼 여러분 스스로 설계를 시작 하십시요. 제공한 예제에서 개선점을 찾아 '내 칩'으로 만들어도 좋습니다. 새로운 게임을 만들어도 좋습니다. 지난주 예제에서 봤던 수학적 알고리즘도 좋습니다. 알고리즘을 컴퓨팅 언어로 기술하고 이를 시뮬레이션과 에뮬레이션으로 검증하며 '내 칩'이 '남의 칩'과 어울려 동작하는 모습을 보여줄 수 있도록 준비하십시요. 자신의 아이디어를 가졌다면 인공지능을 포함하여 어떤 도구를 사용해도 좋습니다. 단, 반드시 검증되어야 합니다.

인공지능이 엔지니어를 대체할 것이라는 '예언'들을 흔히 합니다. 어쩌면 '현실'일지도 모릅니다. IEEE Spectrum Career Alert에 이런 글이 올라왔군요.

    "상사가 인공지능과 당신을 비교하면 어떻할래?"
    Convincing Your Boss an LLM Can't Replace You.

이에 대한 우리는 뭐라도 답할 준비가 있어야 겠지요. 원문을 읽어보시기 바랍니다.

----------------------------------------------------------------

Your Boss Built an App Over the Weekend (So Why Is Your Team So Slow?)

If you're an engineer, you may feel like your skills aren't commanding the premium they once did. Many engineers have faced layoffs or restructuring. But even for those of us who still have jobs, something corrosive is happening. You may have heard some version of this:

    "ChatGPT answered that in five seconds. Why can't you?"

Or,

    "I made this app in a weekend. Why is our team taking so long?"

I worked on a team where leadership said things like this directly to engineers. This was in 2024 and 2025, when the AI craze was in full swing and Claude and ChatGPT adoption was rising.

Demo-Driven Development

Generative AI (and the marketing behind it) gives people the illusion that the work is simpler than it is. A working demo hides complexity, and once someone has a website that works, they may decide they no longer need engineers, or start to distrust the ones they do have.

Some CEOs want to believe they can replace an engineering team with a few sexy prompts. Many companies also want them to believe this.

That website works great in the demo—under specific conditions and without users with thumbs for fingers. Then it has to plug into a system with millions of lines of old code, satisfy legal requirements, meet accessibility standards, and be delivered in a complex deployment process.

Thinking that writing code was the only bottleneck for deploying new software is like the Titanic seeing the tip of the iceberg and assuming there was nothing underneath it.

What you can do about it

Engineers have a very unique position in the AI space, because you have the capacity to understand how these models work much better than the average person. Use this to your advantage.

Learn how AI models work. If you can't already explain that LLMs are probabilistic, what tokens are, or why training data matters, spend a weekend fixing that. You don't need to become a full-blown AI researcher. A few fundamentals will put you ahead of most people making the AI decisions.

Teach upward. Turn that knowledge into teaching moments for the people who lead you. Explain the limits of these tools, and why a demo and a production system are different animals. It keeps people from truly believing that a notebook full of prompts can replace an engineering team.

Consider the criticism of today’s processes. Some of what we do has been treated as ceremony for too long. Be willing to say, "you know what, maybe you're right, this process is too slow for the speed we can work at now." Conceding that earns you the credibility to defend the steps that matter.

I still believe that speed at the cost of everything else is harmful—but that’s a topic for another time.

Find your voice. Engineers at the forefront of AI adoption need to push back and explain why we do things the way we do. Nobody else in the room is going to do it for us.

Don't chase (too many) shiny objects

Your goal, in my opinion, is to save your organization from buying into the hype so much that they chase the wrong thing. Our job, before and after AI, is building safe and useful products for human beings, and engineers are still best suited for that.

By Brian Jenney

-----------------------------------------------------------------
[인공지능 번역]

상사가 주말 동안 앱을 개발했는데 (그런데 왜 우리 팀은 이렇게 느린 걸까요?)

엔지니어라면 자신의 기술이 예전만큼 가치를 인정받지 못한다고 느낄 수도 있습니다. 많은 엔지니어들이 해고 나 구조 조정을 경험했습니다. 하지만 아직 직장을 유지하고 있는 사람들조차도 뭔가 좋지 않은 일이 벌어지고 있다는 것을 느끼고 있을 겁니다. 아마 이런 이야기를 들어보셨을 겁니다.

    "ChatGPT는 5초 만에 답했어요. 당신은 왜 못하죠?"

또는
    "나는 이 앱을 주말에 만들었는데, 우리 팀은 왜 이렇게 오래 걸리는 거죠?"

저는 리더십 팀에서 엔지니어들에게 이런 말을 직접적으로 하는 팀에서 일했습니다. 때는 AI 열풍이 한창이던 2024년과 2025년이었고, Claude와 ChatGPT의 사용이 급증하던 시기였습니다.

데모 기반 개발 방식,

생성형 AI(그리고 그 마케팅 전략)는 사람들에게 실제 작업보다 훨씬 간단하다는 착각을 불러일으킵니다. 작동하는 데모는 복잡성을 감추고, 일단 웹사이트가 제대로 작동하기 시작하면 엔지니어가 더 이상 필요 없다고 생각하거나 기존 엔지니어들을 불신하기 시작할 수도 있습니다.

일부 CEO들은 몇 가지 매력적인 프롬프트로 엔지니어링 팀을 대체할 수 있다고 믿고 싶어합니다. 그리고 많은 회사들도 그들이 그렇게 믿기를 바랍니다.

해당 웹사이트는 데모 환경에서는 특정 조건 하에서, 그리고 엄지손가락이 없는 사용자라면 훌륭하게 작동합니다. 하지만 실제로는 수백만 줄의 오래된 코드로 이루어진 시스템에 통합되어야 하고, 법적 요구 사항을 충족해야 하며, 접근성 표준을 준수하고, 복잡한 배포 프로세스를 거쳐 제공되어야 합니다.

새로운 소프트웨어 배포에 있어 코드 작성만이 유일한 병목 현상이라고 생각하는 것은 타이타닉호가 빙산의 일각만 보고 그 아래에는 아무것도 없다고 생각하는 것과 같습니다.

어떻게 해야 할까요?

엔지니어는 인공지능 분야에서 매우 특별한 위치에 있습니다. 일반인보다 이러한 모델의 작동 방식을 훨씬 더 잘 이해할 수 있기 때문입니다. 이 점을 활용하세요 .

AI 모델이 어떻게 작동하는지 배우세요 . LLM이 확률적이라는 것, 토큰이 무엇인지, 학습 데이터가 왜 중요한지 설명할 수 없다면 주말을 투자해서라도 이 부분을 보완하세요. 꼭 전문적인 AI 연구원이 될 필요는 없습니다. 몇 가지 기본 사항만 이해해도 AI 관련 의사 결정을 내리는 대부분의 사람들보다 앞서 나갈 수 있습니다.

상사에게 가르치세요 . 그 지식을 활용하여 당신을 이끄는 사람들에게 가르침을 주세요. 이러한 도구의 한계를 설명하고, 데모 시스템과 실제 운영 시스템이 왜 다른지 알려주세요. 이렇게 하면 노트에 적어둔 메모가 엔지니어링 팀을 대체할 수 있다고 사람들이 믿지 않도록 할 수 있습니다.

오늘날의 업무 절차에 대한 비판을 생각해 보세요 . 우리가 하는 일 중 일부는 너무 오랫동안 형식적인 절차로만 여겨져 왔습니다. "맞아요, 어쩌면 당신 말이 맞을지도 몰라요. 이 절차는 우리가 지금 일할 수 있는 속도에 비해 너무 느립니다."라고 기꺼이 말할 줄 알아야 합니다. 그런 점을 인정하는 순간, 중요한 절차들을 옹호할 수 있는 신뢰를 얻게 됩니다.

저는 여전히 다른 모든 것을 희생하면서까지 속도를 추구하는 것은 해롭다고 생각하지만, 그건 나중에 다시 이야기해 볼 주제입니다.

자신의 목소리를 찾으세요 . AI 도입의 최전선에 있는 엔지니어들은 왜 우리가 이런 방식으로 일을 하는지 설명하고 반박해야 합니다. 회의실에 있는 누구도 우리 대신 그 일을 해줄 수 없습니다.

(너무 많은) 반짝이는 것들을 쫓지 마세요.

제 생각에 여러분의 목표는 조직이 과대광고에 현혹되어 잘못된 것을 쫓지 않도록 막는 것입니다. 인공지능 이전이든 이후든 우리의 임무는 인간을 위한 안전하고 유용한 제품을 만드는 것이며, 엔지니어는 여전히 그 일을 가장 잘 해낼 수 있는 사람들입니다.

브라이언 제니 지음

[내칩강의2026/6주] 수업 공지: HLS(High Level Synthesis)

[내칩강의2026/6주] 수업 공지: HLS(High Level Synthesis)

지난 몇주동안 인공지능과 대화하며 비디오 게임기를 베릴로그 RTL로 설계해 봤습니다.

SystemC를 활용한 시스템 수준 테스트벤치를 익혔고 FPGA 로 에뮬레이션 검증도 해봤습니다. 이제 코-시뮬레이션(Co-Simulation)과 코-에뮬레이션(Co-Emulation)을 이해하고 반도체 설계에서 검증의 중요성도 알게 되었을 것입니다. 안다는 것에 머물지 않고 자신의 견해를 자신있게 피력할 수 있어야 합니다. 우리가 학습 과제를 (에세이)글을 작성하는 목적 이기도 합니다.

이번주에는 '게임기'에서 잠시 벗어나 HLS라고 하는 '고위 합성' 설계 방법론을 접해볼 것입니다.

HLS(High Level Synthesys)는 높은 추상화 수준 언어로 기술한 알고리즘을 디지털 반도체로 구현하는 설계 방법론입니다. 시스템 수준 C++언어에서 RTL 베릴로그로 합성합니다. 수많은 알고리즘(디지털 신호처리, 인공지능 등)들이 그동안 고성능 CPU에서 실행되어 오다가 한계(어떤 한계일까요?)에 이르자 하드웨어로 실현하고자 하는 요구가 높아졌습니다. 하지만 추상화 수준의 장벽이 너무 높아 이 과정은 설계자의 경험과 능력에 크게 좌우되어 왔습니다. 자동화 도구는 꿈으로 여겨질 정도 였고 많은 연구가 진행되어 실제로 고가의 자동화 도구들이 등장했습니다. 그동안의 HLS 와 상용 도구들은 아래 링크의 논문을 통해 살펴볼 수 있습니다.

    Towards Automatic High-Level Code Deployment on Reconfigurable Platforms: A Survey of High-Level Synthesis Tools and Toolchains, IEEE Access, Vol.8,2020,
    https://ieeexplore.ieee.org/abstract/document/9195872

그리고 아래 링크의 글을 참조하십시요. Xilinx의 Vitis-HLS 의 튜토리얼 가이드 문서를 정리하였습니다. 2021년도 문서임을 감안 하십시요.

    고위합성 튜토리얼(High-Level Synthesis Tutorial),
    https://hls-goodkook.blogspot.com/2021/08/ug871-xilinx-high-level-synthesis.html

인공지능은 이 꿈의 설계 방법론을 현실화 합니다. 이번주 학습에서 C/C++ 언어로 작성된 알고리즘을 인공지능이 어떻게 베릴로그 RTL 로 합성해 내는지 공부합니다. 가벼운 마음(C++를 쉽게 다룰 수 있으니까!)으로 HLS 예제를 살펴볼 것입니다. 간단한 '시계' 예제부터 조금 복잡한 FIR 필터를 다뤄 보겠습니다. 예제는 디지인 킷에 올려 놓았습니다. C++ 언어로 작성된 알고리즘과 이를 RTL 로 합성(인공지능을 통한 변환)한 후 시뮬레이션을 비교해 보십시요. 인공지능과 대화를 통해 C++ 를 제시하고 이를 RTL 로 변환하도록 지시하여 얻은 베릴로그 RTL을 
시뮬레이션하기 위한 SystemC 테스트벤치 그리고 코-에뮬레이션 검증까지 포함되어 있습니다. 인공지능인 신통하긴 하지만 완벽하지는 않습니다. 신통함에 머물지 않고 검증해야 한다는 자세를 견지하십시오.


소프트웨어에서는 프로그래밍 언어로 작성된 함수를 호출 하므로써 실행되지만 RTL은 '클럭'이라는 아주 특별한 시간 관리 체계에 따라 수행 됩니다. 클럭은 하드웨어의 병렬성(동시성)에 맞춰 순차적 알고리즘을 처리할 수 있게 해줍니다. 소프트웨어에서는 함수를 호출하고 되돌려 주는 값을 반환 받는 것으로 종료됩니다. 하지만 늘 작동중인(클럭은 쉬지 않으므로) 하드웨어는 어느 시점에 입력을 주고 계산을 시작하여 유효한 값을 출력하는지 알기위해 별도의 표시가 필요합니다. 이를 핸드쉐이크(hand-shake) 또는 '인터페이스 절차' 라고 합니다. 예제 '시계'는 클럭을 받아 이를 시-분-초로 세며 값을 표시합니다. 시계의 동작은 출력을 외부에서 읽었는지 상관 하지 않습니다. '시계'라는 장치의 알고리즘이 그렇기 때문입니다. 이에 반해 알고리즘의 복잡도와 구현(C++ 언어에서 하드웨어로 옮긴)한 방법(병렬 혹은 순차)에 따라 사용할 클력의 갯수가 달라지는 '디지털 필터' 예제는 입력을 주는 순간 계산을 개시하고 유효한 결과 값을 낼 때까지 기다려 다음 입력을 주어야 합니다. '필터'가 출력한 값을 놓쳐서도 않됩니다. 구현하려는 하드웨어의 성격(사양)에 따라 데이터를 주고받는 절차가 달라 질 수 있으니 '인터페이스'도 매우 중요한 설계 요소 입니다.

대면 수업은 하던대로 금요일 1시 강의실에서, 비대면 수강생들은 자습으로 HLS 예제를 수행하시기 바랍니다. 예제 디렉토리에 제미니와 대화 내용을 올려 놓았으니 참고 하십시요. 과제는 월요일에 게시됩니다.

2026년 10월 25일 일요일

국내 시스템 반도체 설계 교육과정의 문제점을 AI와 대화해봤다.

국내 시스템 반도체 설계 교육과정의 문제점을 AI(구글 제미니)와 대화해봤다.

[주] 인공지능의 대답은 다분히 질문자의 성향을 따르는 경향이 있습니다. 

Q1. 국내 시스템 반도체 설계 교육과정의 문제점 [링크]

Q2. 반도체 설계교육의 문제점과 해결방안 [링크]

Q3. 오픈-소스 EDA 툴과 내 칩 제작 서비스의 MPW는 반도체 설계교육의 문제점에 대한 대안이 될 수 있다.[링크]

Q4. 오픈소스 EDA를 활용한 구체적인 대학 교육 커리큘럼 사례[링크]

Q5. 반도체 설계 교육의 문제점으로 지적되는 고가의 설계툴과 공정비용을 들고 있다. 오픈-소스 설계 툴과 내 칩 제작 서비스 MPW등으로 이에 대안이 있음에도 문제점을 해결하지 못하고 있다. 사실 반도체 설계 교육의 방법상 난점은 해결되었으나 정작 무엇을 가르칠지 고민하고 있는가? 전문 교원의 부족은 단기간에 해소할 수 있는가?[링크]
Q6. 오픈-소스 EDA 툴과 내 칩 제작 서비스의 MPW는 반도체 설계교육의 문제점에 대한 대안이 될 수 있다. 국내 대학에 커리큘럼으로 도입된 사례가 있는가?[링크]
Q7. 반도체 설계가 메이커의 일환이 될 수 있을까?[링크]
Q8. 국내 반도체 인력 교육은 소자, 공정에 치우쳐 있다. 설계와 동떨어져 있다고 본다[링크]. 이유를 분석해 보자[링크].
Q9. 오픈-소스 설계 툴과 내 칩 제작 서비스로 반도체 설계 교육의 장벽에 어느정도 넘을 수 있게 되었다. 학생들의 입장에서 흥미 유발을 위한 방안으로 바이브 코딩으로 비디오 게임기를 베릴로그 RTL 로 설계하고 SystemC 로 시스템 수준 검증 환경을 구축하며 FPGA로 에뮬레이션 검증, 내 칩 제작 서비스로 칩제작까지 제공하면 실제적인 교육과정이 될 수 있다고 본다[링크].
Q10. 한국의 반도체 설계 교육의 심각성을 인지하고 있으면서 왜 해소하려하지 않는가?[링크]
Q11. 한국내 각종 반도체 설계 관련 경진대회의 주제들을 보면 특정 분야에 집중되어 있다. 학생들의 설계라기 보다 지도교수의 과제 일환인 것으로 보인다. 반도체 설계 인력에 효과가 있다고 볼 수 있는가?[링크]
Q12. 국내 반도체 설계 분야의 취업 문이 너무나 좁다. 해외로 나가는 편이 좋을까? 해외의 반도체 설계 분야 취업 기회에 대해 알려달라[링크]
Q13. 국내 반도체 회사들에서 설계인력을 확충 한다지만 실제 창의적 설계업무를 하고 있을까? [링크]
Q14, 국내 대학의 반도체 계약학과는 설계 교육을 강화하고 있는가? 즉시 현장 투입이라고 하지만 현장은 창의적 설계 보다는 제조시설에 가깝다.[링크]