RTL Engineer가 본 반도체 칩 개발 과정

Fabless 반도체 회사에서 일하는 RTL Engineer로 살펴본 반도체 칩 개발 과정을 정리해 봅니다.

• Specification and Planning

모든 Design이 그렇듯이 가장 중요한 과정으로 무엇을 어떻게 만들지 결정하는 과정입니다. 처음에는 추상적인 개념, 또는 chip이 사용될 system의 검토에서부터 출발합니다. 예를 들어 좀 철지난 이야기입니다만 Progressive Scan을 지원하는 DVD Player용 one-chip solution을 만든다는 정도로 시작합니다. 먼저 결정해야 하는 것은 chip이 담당해야 하는 기능과, chip 외부에 붙어서 동작하는 device는 무엇인지 입니다. chip 외부에 어떤 다른 device를 연결하느냐에 따라서 chip 내부에 들어가야 하는 interface가 달라지기 때문입니다.



그런 다음 chip 내부에서 해야 하는 기능을 나누어 block diagram 같은 것으로 형상화합니다. 각 block의 기능은 어떻게 되어야 하고 데이터는 어떻게 주고 받으며 등을 정합니다. 이 때, 실제로 design을 할 block과 회사 외부에서 IP(Intelectual Property : 지적 재산 정도로 번역) 형태로 사와야 하는 block을 결정합니다. 당연히 사오느냐 직접 개발하느냐는 개발기간이나 개발비 등을 고려하여 유리한 쪽으로 결정하게 됩니다.



이때 같이 고려해야 하는 것은 chip의 성능입니다. 당연히 specification을 만족해야 하므로, 전체 chip의 동작 clock 속도나 memory bandwidth 등을 고려해야 합니다. 소프트웨어로 동작하는 기능이 있다면 해당 software가 필요로 하는 CPU performance 등을 고려해야 합니다. 또한 chip의 power consumption 등의 다른 요소도 고려되어야 합니다.


Clock speed나 power consumption, 개발비, chip unit price 등의 정보를 이용하여 반도체 공정을 결정하게 됩니다. System에 사용될 때 package나 기타 다른 요소도 고려사항입니다.
또한 전체 개발 schedule을 잡고, Verification을 어떻게 진행할 지에 대한 계획도 세우게 됩니다.

• Design

Specification 과정에 정해진 block을 나누어 design을 하게 됩니다. 사실 반도체 설계가 그리 대단한 것은 아닙니다. HDL(Hardware Description Language)라고 하는 언어로 programming을 하면 됩니다. 주로 사용되는 HDL은 Verilog와 VHDL이 있는데, 학교에서는 VHDL을 주로 가르치고 업계에서는 Verilog을 주로 사용한다고들 합니다. HDL programming을 한 후에 synthesis 과정을 거치면 gate level netlist가 나오고 그것이 결국은 chip으로 바뀔 수 있는 것입니다. 다만 HDL로 작성된 모든 code가 synthesis 가능한 것이 아닙니다. 보통은 RTL(Register Transfer Level)이라고 하여 사용자가 flipflop(register)과 그 사이의 combinational logic을 잘 기술한 경우에만 synthesis 가능합니다. 즉, 매 clock cycle이 어떻게 동작되어야 하는지를 기술해야 합니다. 참고로 RTL 이라는 말은 HDL source code와 보통 구별 없이 사용합니다.


각 block의 design이 끝났으면 당연히 각 block과 외부 회사에서 사온 IP 등을 한꺼번에 모아서 전체 design을 만들어야 합니다. 역시 HDL을 이용하거나 schematic tool을 이용하여 연결을 하면 됩니다.

• RTL Verification

Design이 끝났으면 design이 올바로 되었는 지 검증을 해야 합니다. 대부분의 다른 설계도 마찬가지겠지만 검증은 반도체 칩 설계에서 가장 중요한 부분입니다. Software야 잘못되면 patch를 release한다거나 할 수 있지만 hardware가 잘못되면 chip을 다시 만들어야 합니다. 문제는 chip을 만드는 비용이 상당히 비싸기 때문에, 검증을 통해서 될 수 있으면 error가 없도록 만들어야 합니다.


검증 방법으로는 가장 중요한 것은 simulation입니다. HDL은 hardware description 뿐 아니라 simulation을 위해서도 사용됩니다. 보통 test bench라고 불리우는 HDL programm을 작성하는데 쉽게 말하면 C 언어의 main 함수라고 생각하면 편합니다. 매 clock cycle 제대로 동작하는지 살펴보기 위해서 simulation vector라고 해서 input data를 만들어서 넣어주고 output data가 specification 대로 나오는지 살펴보는 program을 작성하게 됩니다. HDL을 simulation하기 위해서 별도의 simulation tool이 있는데 다음과 같은 것을 많이 사용합니다.


Cadence의 ncsim(ncverilog)
Mentor Graphics의 modelsim
Synopsys VCS


문제는 Simulation이 엄청 느리다는데 있습니다. Simulation tool은 HDL에서 기술된 모든 signal이 매 clock cycle 어떻게 변하는지 monitoring을 하기 때문입니다. OpenSPARC Internals이라는 책을 보면 OpenSPARC을 개발하는 데, OS인 Solaris가 booting하는데 까지 Synopsys VCS로 simulation을 할 경우 15.5년의 시간이 걸린다고 합니다. 물론 지금은 simulation tool을 돌리는 computer가 좀더 빨라졌을 것이므로 많이 줄었겠지만, Simulation하다가 에러를 발견하면 RTL을 수정하여 다시 simulation을 해 봐야 하므로, 감당할 만한 수준이 아닙니다.


보통의 경우 chip 전체를 simulation하기 전에, 각 block 별로 test bench를 만들어 simulation을 하여 검증하고, chip 전체의 simulation은 각 block이 잘 연결되었고 간단한 작업이 잘 동작하는지 정도에서 마무리 하게 됩니다. 가능한 모든 vector, 즉 input data에 대해서 simulation 한다거나 하는 일은 상당히 무리입니다.


chip 전체의 검증을 충분히 하기 위해서는 다른 방법이 필요한데, 우선 Emulator 혹은 hardware 가속기가 같은 것이 있는 것 같습니다. Simulation을 hardware를 이용하여 가속한다는 것인데 국내에서 이런 것을 사용하는 경우는 별로 보지 못했고, 사용해 본 바가 없어서 어떻게 동작을 하는지는 잘 모릅니다. 국내에서는 보통 FPGA(Field Programmable Gate Array)를 사용하여 prototype을 만들어서 검증을 하는 경우가 많습니다. 나중에 FPGA가 뭔지 이야기할 기회가 있겠지만, 간단히 말하면 FPGA는 RTL을 이용하여 그대로 원하는 기능의 chip을 만들어 볼 수 있는 prgrammable(configurable) chip입니다. 즉, RTL을 합성하여 FPGA에 download하면 RTL 대로 FPGA가 동작합니다. 그렇다면 "FPGA를 그냥 쓰지 chip은 왜 만들어?"라는 의문이 들 수 있는데 FPGA가 상당히 비싸고, analog가 기타 component는 포함시킬 수 없고, 반도체 공정에 따라서 다르지만 chip의 동작 속도보다 FPGA 동작 속도가 느린 경우가 많기 때문입니다. 즉, prototype으로 약간 느리게 동작하는 chip을 만들어 본다라고 생각하면 좋을 것 같습니다. FPGA 주변에 필요한 회로를 꾸미고, FPGA에 RTL을 합성하여 download하여 test system을 만든 후에, 전체 system이 잘 동작하는지 검증하게 됩니다. FPGA가 실제 chip 보다는 늦게 동작하기는 하지만 simulation에 비해서는 월등히 빠릅니다. OpenSPARC의 경우 FPGA에서 Solaris가 부팅하는데 걸리는 시간이 19분 정도라고 합니다. 15.5년데 19분이면 비교할 수 없는 수준이죠. 그렇지만 FPGA는 RTL을 합성하고 준비하는 시간이 좀 걸리고, Simulation의 경우 모든 signal의 매 clock cycle monitoring이 가능하지만 FPGA는 그렇지 않습니다. 전체 design 내부에 CPU가 있고, software의 개발이 필요하다면 FPGA Board에서는 어느 정도 software 개발이 이루어질 수 있습니다.


참고로 ESL(Electronic System Level)이라고 하여 system C 등의 simulation이 빠른 다른 language를 이용하여 RTL design을 하기 전에 좀더 추상화된 model을 기술하는 design 방법론이 있습니다. 이 경우 각 block의 RTL design을 ESL과 같이 simulation 한다거나 하는 방법으로 검증을 한다고 합니다. 그리고 ESL의 simulation 속도가 매우 빠르므로 chip 내부에 CPU 등이 있어서 software 개발을 해야 한다면, ESL 상태에서 진행할 수도 있다는 장점이 있다고 합니다.

• Synthesis(합성)

당연히 RTL을 hardware로 바꾸기 위해서 synthesis 과정을 거치게 됩니다. 다른 회사의 tool도 있는 것 같은데 거의 절대적으로 Synopsys의 Design Compiler라는 tool을 많이 사용합니다. 각 FAB 공정마다 주는 design kit(library)와 사용자의 RTL, 그리고 timing constraint라고 하는 것을 입력해 주고 tool을 돌리면 gate level netlist가 나오게 됩니다. FAB에서 주는 design kit에는 합성에 사용될 gate 들의 내용(동작 및 속도 등)이 들어 있습니다. Software의 compile과 비유를 하면 반도체 공정마다 주는 design kit은 각 CPU 마다 존재하는 instruction set architecture라고 보면 되고 RTL은 C source code라고 생각하면 됩니다. C source code를 compile을 하게 되면 instruction sequence, 즉 기계어가 나오게 되는데 그것이 합성에서는 gate들의 연결로 결과가 나타나게 됩니다.


그렇다면 timing constraint는 뭐냐? timing constraint는 chip 내부에서 사용하는 clock들의 속도, chip의 input/output delay, 각 clock에 연동된 signal 사이의 관계 등을 나타내는 겁니다. Hardware는 단순히 올바른 동작만 해서는 안되고, 원하는 성능, 쉽게 표현하면 원하는 동작 주파수에 맞추어서 동작해야 합니다. 따라서 원하는 동작 clock을 synthesis tool에 알려주고, 그것이 만족되도록 합성을 진행하게 됩니다. Synthesis tool은 합성을 진행하며 사용자가 원하는 속도로 hardware가 동작이 가능하도록 최선을 다하고, 원하는 속도로 동작이 되고 나면 불필요한 부분이 없는지 검사하여 hardware의 사이즈를 줄이려고 노력합니다.


만약 합성의 결과 원하는 속도로 hardware가 동작하지 않는다는 결과가 나오면, 원인을 체크하고 tool을 다른 option 으로 다시 돌린다는 방법을 써서 맞추려고 노력하다가 정 안되면, 다시 RTL design으로 돌아가서 design을 새로 하게 됩니다. RTL에서 기술한 flipflop 사이의 combinational logic이 너무 복잡하기 때문에 생기는 경우가 많으므로 그런 부분을 고쳐서 다시 Verification 과정을 거쳐서 synthesis 과정으로 돌아오게 됩니다.


합성의 결과로 나오는 gate level netlist를 보통 pre (layout) netlist라고 부르고, Netlist의 형태는 verilog을 주로 사용합니다. verilog은 RTL 기술에도 사용되지만 gate level의 기술에도 사용될 수 있습니다. verilog이므로 verilog test bench를 이용하여 netlist를 simulation할 수도 있습니다. 이런 simulation을 보통 pre-sim이라고 부릅니다.


Tool이 합성을 잘 했는지는 또 어떻게 검증을 할 수 있을까요? Tool도 software이므로 버그가 항상 존재할 수 있고, test를 많이 진행하겠지만 가능한 모든 data에 대해서 test를 진행할 수는 없을 겁니다. 따라서 합성 결과로 나온 netlist가 올바른지 검증을 할 필요가 있습니다. 당연히 pre-sim을 통해서 확인이 가능합니다만, 역시 simulation도 모든 vector에 대해서 test를 진행할 수 없는 단점이 있습니다. 이것을 검증 하는 과정을 formal verification이라고 하는데 별도의 tool이 있습니다. 우리나라에서는 Synopsys의 Formality라는 tool을 많이 사용하고 있는 것 같습니다. Formal verfication tool은 HDL로 기술된 두 가지 design을 비교하여 동일한 기능을 가지고 있는지 검증하는 tool입니다. 합성 뿐 아니라 design의 형태를 변화시킨 각 단계에서 사용할 수 있습니다.

• Backend(test logic 과 Place&Route)

이 부분은 보통은 RTL Engineer가 담당하지 않고 별도의 전문 engineer가 담당하게 됩니다. Fabless 설계 회사에서 RTL design을 했다면 보통 backend 업체의 engineer에게 맡기는 부분입니다. 사실 synthesis 과정도 backend 업체에서 진행하도록 계약을 할 수 있습니다만, 그렇게 되면 RTL code를 회사 외부인 backend 업체에 전달해 주어야 하므로 그다지 선호되지는 않습니다. RTL code 대신 합성이 끝난 netlist를 backend 업체에 전달하게 되는데, netlist는 software로 보면 assembly level 쯤으로 보면 되는데, 전체 design을 분석하여 버그를 잡는다거나 새로운 기능을 추가한다거나 하는 것이 RTL code에 비해 매우 어렵습니다.


Backend 업체는 Fabless 반도체 설계 회사를 대신하여, FAB, Package 업체, Chip Test 업체 등과 계약을 대신 해주는 업체로 이해하면 쉽습니다. 보통의 경우 특정 FAB 회사의 대리점 처럼 운영되는 경우가 많습니다. 또한 Fabless 설계 회사가 쉽게 하지 않은 뒷단(backend) engineering service도 제공합니다. 물론 fabless 설계 회사가 크고 많은 chip을 설계한다고 하면 backend processing을 담당하는 engineer를 뽑아서 그 일을 맡기는 경우도 있지만, 작은 설계 회사는 그것이 쉽지 않으므로 backend 업체가 제공하는 service를 이용합니다.


Backend 업체에 합성된 netlist를 전달하면 backend 업체는 Memory BIST, SCAN 등의 test logic을 넣게 됩니다. 이러한 test logic은 chip이 생산된 후에 chip이 올바로 동작하는 지 검증하기 위한 가장 기본적인 것으로, 원래의 netlist의 동작은 그대로 유지하면서 test mode에서만 동작하는 logic입니다. 이와 같은 logic을 넣은 후에 그 logic의 chip test vector를 만들게 됩니다. chip이 나오면 chip의 특정 pin에 test 장비를 물려서 data를 넣고, 다른 pin에서 출력 data를 뽑아서 원하는 결과가 나왔는지 검사를 하게 되는데, 입력 data와 올바른 출력 data를 만들어 두어야 합니다.


test logic 관련 일이 끝나면 이제는 Place&Route(줄여서 P&R, 혹은 layout) 차례입니다. Netlist는 gate 들이 어떻게 연결되었는지 나타내 주는 것 뿐이므로 그것을 반도체 die 위에 어떻게 배치(Place)할 지와 gate 간의 연결을 해 주는 wire을 어떻게 놓을지(Route)를 결정하는 과정이 바로 P&R 과정입니다. 당연히 사람이 손으로 할 수는 없고 tool을 이용하게 됩니다. P&R 을 하면서 혹은 그 후에는 FAB에서 권장하는 rule을 모두 맞추었는지 체크하거나 하는 과정을 거치는데 자세한 내용은 알지 못합니다.


P&R이 끝난 결과는 사실 반도체 die에 놓여질 material(n형 반도체, p형 반도체, polysilicon, metal 등)이 차지하고 있는 영역을 표시한 data(보통 그림으로 표시)이고 그것을 FAB에 전달하면 됩니다. 보통 이것을 GDS 파일이라고 부르는데 PCB artwork의 결과인 거버(Gerber) 파일과 동일한 개념으로 보면 됩니다. P&R을 마치고 나면 마지막 검증 과정이 남아 있습니다. P&R의 결과를 다시 netlist로 뽑는데 그것을 post (layout) netlist라고 부릅니다. post netlist는 pre netlist와는 약간 다른데, 가장 큰 다른 점은 wire의 delay까지 modeling되어 있다는 것입니다.(실제로는 netlist file이 아니라 sdf 파일 형태로 제공됨) 예를 들어 두 gate 간의 연결에서 Place 결과 두 gate의 거리가 멀어서 긴 metal wire를 이용하여 연결이 되었다면, 신호가 그 wire를 지나는데 delay가 생기게 됩니다. 이런 modeling이 가능한 것이 post netlist입니다. post netlist가 나오면 STA(Static Timing Analysis)라고 설계자가 원하는 timing(clock 주파수나, delay 등)이 제대로 맞는 지 검증합니다. 이 검증은 backend engineer 또는 RTL engineer가 진행할 수 있습니다. 또한 RTL Engineer는 post netlist를 가지고 simulation을 다시 진행하게 되는데 이것을 보통 post sim이라고 부릅니다. RTL verfication을 위한 RTL simulation에 비해 post sim의 simulation 속도는 수십 혹은 수백배 느립니다. 그것은 gate level로 떨어뜨리기 위해서 더 많은 signal이 사용되고 gate의 delay와 wire의 delay가 modeling 되어 있기 때문입니다. 따라서 꼭 필요한 vector만 써서 검증을 진행합니다. 이 과정중에 bug이 발견되면 bug을 netlist에서 약간 수정하면 된다고 하면 netlist에 약간의 gate를 넣고 빼는 일을 하는데 이것을 ECO(Engineering Change Order)라고 부릅니다. netlist level에서 수정이 불가능하면 다시 RTL 수정 등으로 돌아가서 모든 과정을 다시 거치게 됩니다.
모든 검증이 끝나면 sign-off라고 해서 backend 업체가 들고온 검증 결과 내용에 말그대로 사인을 하면 tape-out이라고 하여 design이 FAB으로 넘어가게 됩니다. FAB IN이라고 부르기도 하는데 RTL Engineer로서 모든 일을 마무리한 셈이므로 아주 기쁜 일입니다. 하지만 더 이상 design을 고칠 방법은 전혀 없으므로, 심각한 bug가 발견된다면 회사에 사표라도 낼 준비해야 할 지도 모릅니다. 모든 것이 끝났다는 완전히 홀가분한 느낌을 가질 수는 없습니다.

• FAB OUT and Chip Test

FAB에서 수주에 걸쳐서 반도체 die 제조가 모두 끝나면 package 업체로 넘어가 packaging을 하게 됩니다. package를 마치면 test 업체에서 chip이 올바르게 구현되었는지 지 검증을 한 후에 chip이 다시 RTL Engineer에게 도착합니다. test 업체에서 하는 test는 scan test라고 하여 P&R 전에 넣은 test logic을 이용하는 것도 있고, function test라고 하는 것도 있습니다. function test는 RTL Engineer가 simulation한 내용을 가지고 chip의 pin으로 입력 data를 공급하고 pin으로 나오는 출력 값이 올바른지 검사하는 겁니다. 이 test를 위해서 RTL Engineer는 simulation vector를 test 업체에 제공해야 합니다.


Chip이 도착하면 evaluation board 위에 붙이고, software 등을 개발하여 reference system을 완성합니다. Reference system 위에서 모든 기능이 올바로 동작하는 지 검증하고 system 업체로 chip을 납품하면 끝이 납니다. chip에서 bug이 발견되면 software를 수정하여 빗겨갈 방법을 찾을 수 있는데, 그렇게 할 수 없는 경우에는 bug의 원인 분석을한 후 다시 모든 과정을 거쳐서 FAB에 갔다 와야 합니다. 이것을 보통 respin이라고 하는데, 당연히 시간과 돈이 엄청 깨지게 됩니다.
사질 reference system 위에 붙여서 대부분의 기능 test가 통과된다고 하더라도, 실제 field에 나가면 다양한 application 상황에서 이상한 문제가 생길 가능성이 많이 있습니다. System 업체에서 설계된 chip으로 system 양산을 많이 할 때까지는 마음을 졸일 수 밖에 없는 것이 RTL Engineer의 운명입니다.