반도체 칩의 가격 구조

반도체 칩의 가격을 결정하는 요소가 무엇인지 생각해 봅니다.
모든 제품이 그렇듯이 돈의 문제가 나오면 개발비와 단가로 나눌 수 있습니다.

개발비 요소

 

• 인건비

사람이 하는 모든 일이 그렇든 칩 설계도 인건비가 상당부분을 차지합니다. 아무리 작은 칩을 개발한다고 하더라도, 적어도 1년 가까운 정도의 개발 기간이 필요합니다. 당연히 design이 커지면 더 많은 사람과 더 많은 기간이 필요하므로 인건비가 증가합니다.

 

• IP license fee

칩 내부에 들어가는 모든 것을 직접 설계한다면 문제가 없겠지만, 대부분은 그렇지 않고 IP(Intelectual Property)를 사와야 합니다. 우선 저 같은 RTL 엔지니어는 digital logic 만을 설계할 수 있는데, 칩 내부에 analog circuit이 들어가야 하면 어디선가 구해와야 합니다. 기본적으로 PLL(Phase Locked Loop)과 같은 간단한 것부터 audio/video 입출력을 담당하는 ADC/DAC 등이 필요합니다. 또한 쉽게 떠오르지는 않겠지만 speed가 빠른 device, 예를 들어 USB, Ethernet, SATA, HDMI, PCI Express 같은 경우는 PHY라고 불리우는 analog component가 있어야 합니다. 심지어 DDR2/DDR3 등의 빠른 memory를 붙이기 위해서 DLL(Delayed Locked Loop)과 같은 analog circuit이 필요합니다. 이런 기능의 내장을 원하면 당연히 해당 analog circuit를 analog IP를 파는 회사에서 사와야 합니다. 공정마다 analog circuit을 설계하는 방법이 다르므로, 특별한 analog IP는 시장에서 구할 수도 없어 경우에 따라서는 analog IP 회사에 개발 의뢰를 해서 만드는 수 밖에 없습니다. PLL 같은 경우는 비교적 싸겠지만 특별한 것들은 가격이 수십만 달러 단위가 되기도 합니다.

 

또한 digital block도 IP로 많이 삽니다. 예를 들어 ARM 프로세서를 내장하고 싶으면 ARM사에서 사는 수 밖에 없습니다. 프로세서는 digital logic으로 구성되므로 자료만 충분하면 거의 동일하게 만들 수도 있기는 합니다만 ARM사에서 걸어놓은 특허및 기타 권리를 피해서 만들기가 곤란합니다. 혹 그런 권리 침해없이 만들었다고 하더라도 "ARM"이 들어갔다고 이야기를 하면서 팔지 못하는데, 상표권 침해이기 때문입니다. 다른 CPU Architecture를 고르거나, CPU Architecture를 새로 만들어서 구현하면 어떻겠냐고 생각할 수도 있는데, chip을 실제로 사용할 system 회사의 software 엔지니어의 support 이슈가 발생됩니다. ARM만을 사용해 본 software engineer에게 다른 architecture의 CPU를 권하기 쉽지 않은데다가, 조금만 문제가 생겨도 불평을 할 것이 분명합니다. TI/Samsung/ST 등의 공룡 회사들이 자체 CPU를 만들어서 쓰지 않고, 그냥 ARM core를 license해서 쓰는데는 다 이유가 있습니다.
CPU를 제외하고, 다른 digital block 중에서도 개발하는 것 대비 사오는 것이 싸다면 IP 제공 업체에서 사오게 됩니다. UART와 같은 간단한 Peripheral 들도 모두 살 수 있고, 3D graphic accelerator나 MPEG/H.264 codec과 같은 아주 복잡하여, 직접 개발하면 개발 기간이 오래 걸릴만한 것도 IP 업체들이 제공해 줍니다. 심지어 Chip 내부를 연결하는 BUS, DRAM Controller 같은 것도 모두 살 수 있습니다. 가격은 복잡도에 따라 수천 달러 수준에서 부터 수백만 달러 수준까지 다양합니다. ARM926만 해도 십만 달러 단위인 것으로 알고 있습니다.

 

참고로 몇몇 FAB에서는 자체로 설계하여 가지고 있는 IP 등을 무료로 제공하기도 합니다. 물론 FAB NRE에 포함되어 있을지는 모르겠지만 말이죠.

 

• Design House Fee

Design House가 설계 회사를 대신해서 Backend(test logic insert와 P&R 등) engineering 서비스를 제공하고, 반도체 FAB, package 업체, chip test 업체를 대신 계약해서 관리해 주는 비용을 제공하게 됩니다. 보통 반도체 FAB에 주는 NRE를 Design House를 통해 전달하게 됩니다. 아래 설명할 FAB NRE를 제외하고는 나머지 것은 그렇게 많은 돈이 필요하지는 않습니다.

 

• FAB NRE

반도체 FAB에 주어야 하는 NRE(Non-Recuring Engineering) Charge가 있습니다. 대부분은 Mask라는 것을 만드는 데 드는 비용이라고 합니다. 반도체 공정에 대해서 자세히는 모르지만 metal layer와 polysilicon layer의 갯수에 따라서 가격이 다를 겁니다. 이것도 공정마다 다른데 엄청 비쌉니다. 0.13um 공정에서 보통 수십만불 합니다. 공정이 미세화될 수록 엄청 더 비싸지는데 45 nm 공정 같은 경우에는 얼마나 될지 조그만 회사에서는 견적서를 보내달라고 하기도 부담스럽습니다. 반도체 공정이 미세화되면 우선 동작 속도가 빨라지고, power 소모가 줄어드는 장점이 있습니다. 또한 미세 공정을 사용하는 것이 chip의 단가를 줄일 수 있는 경우가 있습니다. 따라서 chip의 스펙과 money 등의 여러가지 요소를 고려하여 공정을 선택해야 합니다.

 

이런 NRE가 부담이 되는 고객, 즉 반도체 설계 회사를 위해서 몇몇 FAB에서는 MPW(Multi-Project Wafer)라는 프로그램을 가지고 있습니다. 이 경우에는 Mask 비용을 여러 설계회사에서 나누어 내, 각 설계회사의 부담을 덜 수 있는데, FAB 입장에서는 NRE 측면에서는 크게 손해 보는 장사는 아닙니다. 대신 Wafer에 여러 회사의 die가 생산되므로 당연히 chip 생산 단가가 증가하게 됩니다. 따라서 대부분의 설계회사는 이런 MPW를 이용하여, test chip 수십 개 정도 생산해 보는 기회로 이용합니다. FAB NRE가 워낙 비싸므로 test chip이 잘 동작하는 것을 확인한 후, 나중에 다시 NRE를 내고 양산을 시켜 design fail로 인한 RISK를 감소키는 방법입니다.

 

• 기타

개발용 EDA tool의 값을 생각해 볼 수 있습니다. 디지털 칩을 개발한다고 하면 사실 손으로 transistor를 일일히 그리는 것이 아니라 verilog이나 VHDL 등의 language를 이용하여 일반 software를 만들 듯이 programming을 하게 됩니다. 그렇다면 Verilog/VHDL simulatior와 같은 tool은 검증을 위한 가장 기본적인 tool이 됩니다. 이런 tool도 역시 싸면 몇만불에서 부터 비싸면 수십만불까지 상당히 비싸고, 재미 있는 것이 유지 보수로 년간 받는 돈도 엄청납니다 . 다행히 국내에서는 ETRI 시스템 반도체 진흥센터라는 곳에서 작은 회사의 경우 이런 tool을 사용시간 기준으로 혹은 기간제로 적인 비용을 내고 쓸 수 있게 해주고 있습니다.

 

또, 각할 수 있는 비용으로는, test/verification을 위해서 FPGA prototype board를 비롯한 각종 board를 만드는 비용이 있을 수 있습니다. 또한, 칩에 올라갈 software 등의 개발비는 별도 입니다.

 

 

생산 단가 요소

• die size

당연히 die size가 중요한 요소입니다. 반도체 FAB은 기본적으로 NRE를 제외하고는 wafer 가공비를 wafer 한 장당 일정액씩 받습니다. 따라서 die 사이즈가 줄면 wafer 한장에 생산되는 chip의 갯수가 증가하므로 생산 단가가 줄어듭니다.
생산 단가를 줄이기 위해 설계시에 die size를 줄이기 위해서 노력을 많이 합니다. die size의 결정 요소는 크게 core의 크기와 pad의 갯수로 인해 결정됩니다. Core는 digital/analog 회로 부분을 말하는데 이것이 커지면 당연히 die size가 일정 수준이하로 줄지 않습니다. 이 경우를 보통 core limit이라고 부릅니다. Pad는 반도체 die와 package의 pin(또는 ball)로 연결되는 부분으로, 상당히 큰 크기를 가지고 있고 보통 die의 맨 바깥쪽 4면에 놓여집니다. 회로(core)의 크기는 작은데, 상대적으로 package로 연결될 signal이 많으면 core 주위에 4면에 필요한 pad를 모두 위치시킬 수 없습니다. 이런 경우 pad를 다 위치시킬 수 있는 사각형의 크기가 최소 die size가 되는데, 이것을 pad limit이라고 부릅니다. Pad는 chip이 실제 사용될 system에서 다른 chip과의 연결 등에 따라서 결정되기 때문에, 쉽게 줄이거나 할 수 있는 문제가 아니므로, 보통 RTL Engineer는 digital 회로 크기를 줄이는데 주력합니다. 즉, chip의 스펙을 만족시키되 될 수 있으면 적은 digital 회로 크기를 가지도록 설계하는 것입니다.

 

위의 인텔 Pentium4 Wafer라고 합니다. 사각형 형태로 구분된 것이 하나의 die.

• yield

wafer에 가공한 모든 die가 잘 동작할 수는 없습니다. 전체 die 중에 잘 동작하는 die의 비율을 보통 yield라고 합니다. 이 yield가 높아지면 당연히 생산 단가가 줄어듭니다. 보통 널리 알려진 FAB, 혹은 기술력이 있다고 알려진 FAB을 선호하는 이유는 이 yield 때문입니다. 보통 그렇게 유명한 FAB은 wafer 가공비를 더 비싸게 받는데도 yield가 높기 때문에 FAB에 비해 경쟁력이 있습니다.

 

• package cost

COB(Chip On Board)라고 die를 직접 PCB 위에 붙여서 system을 제조하는 경우도 있습니다만, 일반적으로는 die를 packaging 하여 system 제조 없체에 납품합니다. package cost는 우선 package의 종류(소재및 형태)에 따라서 결정되는데, 종류가 정말 많습니다. 일반적으로 작은 형태의 package일 수록 더 비싸다고 보면 됩니다. 예를 들면 일반적으로 BGA(Ball Grid Array)가 QFP(Quad Flat Package)보다 비쌉니다. BGA도 아래 그림 처럼 종류가 많고, 종류에 따라서 가격이 다릅니다.

다양한 종류의 BGA package

 

또 동일한 형태의 package에서 cost를 결정하는 요소는 pin(또는 ball)의 개수입니다. 당연히 pin이 많아지면 더 비싸집니다. 예를 들어 BGA package에 ball을 더 넣고 싶은데 package의 전체 면적은 줄이고 싶지 않은 경우, pitch(ball과 ball사이의 간격)를 줄일 수 밖에 없는데 그렇게 되면 비싸집니다. 따라서 pin의 갯수를 줄이기 위해서 동일한 pin이 configuration에 따라서 다른 기능을할수 있도록 설계하는 것이 일반적입니다. 소위 pin multiplexing이라고 하는데, 대부분의 MCU가 GPIO와 다른 기능을 multiplexing 합니다.

 

Package에서 또 고려되어야 하는 경우가 있는데, MCP(Multi-Chip Package) 혹은 SIP(System In Package)라고 하여 여러 개의 die를 하나로 package하는 경우가 있습니다. 예를 들어 SDRAM이나 Flash를 MCU와 함께 하나의 package에 담는 경우도 있을 수 있고, 삼성에서 발표한 OneNAND라고 하여 NAND flash, SRAM 등이 하나의 package로 담는 경우도 있습니다. 이런 package는 또 매우 비쌉니다.
우선 설계시에 하나의 die로 설계하지 않는 이유는 반도체 공정이 다르기 때문인 경우가 많습니다. 예를 들어 Flash memory/SDRAM 등을 생산하는 반도체 공정과 일반적인 digital logic을 생산하는 반도체 공정이 다릅니다. 보통의 경우 Flash memory/SDRAM을 대량 생산하는 반도체 공정이 Digital logic 공정에 비해 좀더 미세하고, polysilicon/metal layer 등의 갯수등도 다릅니다.
MCP/SIP 등을 이용하는 것이 두 die를 따로 따로 package하여 system에서 연결하는 것 보다, 가격적으로 아주 매력적이지는 않다고 합니다. 그래도 MCP/SIP가 고려되는 이유는 휴대폰 등을 만드는 경우 system의 전체적인 크기를 줄이는데 많은 도움을 줄 수 있기 때문입니다.

 

• IP license royalty

설계할 때 IP 업체에 사왔던 IP 중에서 chip당 로얄티를 주어야 하는 것들이 있습니다. chip당 얼마씩 로얄티가 들어갑니다. 보통의 경우 license fee가 비싼 IP 들이 로얄티도 요구합니다. 즉 IP를 사용하기 위해서는 IP 회사에 설계할 때 많은 돈을 한꺼번에 내고, chip이 생산될 때 chip당 로얄티를 별도로 냅니다. 물론 계약 내용에 따라서 다를 수 있지만, ARM Core와 같은 애들이 로얄티도 받습니다. 

 

• chip test cost

모든 chip을 전수 테스트하여 test를 pass한 제품만 system 업체로 보내게 됩니다. system 업체에서 생산한 system도 test를 하겠지만 system test에서 fail하면 system 전체를 못쓰게 되므로 비용이 더 많이 발생합니다. 따라서 될 수 있으면 가격이 적은 상태, 즉 chip 상태에서 문제가 있는 애들을 걸러내야 합니다. 당연히 각각의 chip을 모두 개별 테스트하므로 생산 단가에 영향을 줍니다.


결론

예를 들어 90 nm 공정에서 빠르게 동작하는 ARM CPU 넣고, 몇가지 중요한 analog IP 등을 넣어서 chip을 개발하려면 인건비를 제외한 실비만 십억단위의 돈이 우습게 듭니다. 대신 chip이 아주 특별하지 않는 이상 chip 납품 단가는 비싸봐야 몇달러에서 $20 정도 됩니다. 따라서 왕창 팔지 않으면 개발비를 뽑을 수 없습니다. 하지만 연간 수백만개~수천만개 정도 팔리면 대박이 되므로, 칩 설계 분야는 규모의 경제가 지배하는 로또 동네입니다.

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의 운명입니다.

Multi-Core or SMT on Embedded ?

OpenSPARC T1/T2는 각각 32/64개의 thread를 동시에 수행할 수 있습니다. 한 두개도 아니고 이렇게 많은 thread 처리가 embedded 동네에서는 어떨까 생각해 봅니다.


다른 시스템도 마찬가지겠지만 CPU의 성능은 latency와 throughput 두 가지로 나타낼 수 있습니다. latency는 어떤 하나의 일을 완료하는데 걸리는 시간이 얼마인가의 문제이고, throughput은 단일 시간안에 할 수 있는 일의 총 수는 얼마인가의 문제입니다. 이것은 어찌보면 서로 연관이 되어 있지만, 다른 의미를 가질 수 있습니다.

예를 들어 현재 시중에 팔리는 저가형 잉크젯 프린터를 보면 대략 분당 20장, 즉 20PPM의 성능을 가지고 있나 봅니다. 하지만 PC에서 프린트 버튼을 누르고 첫번째 페이지가 출력되어 나올 때까지 걸리는 시간은 3초(60초/20PPM) 보다는 보통 많이 걸리고 프린터의 종류마다 다릅니다. 첫번째 페이지가 나올때까지 걸리는 시간은 latency이고, PPM으로 나타나는 성능이 throughput입니다. 물론 20PPM 프린터 중에 가장 성능이 좋은 것은 첫번째 페이지가 3초만에 출력되는 것입니다. 첫번째 페이지가 1초에 출력된다면 그 프린터는 60PPM(분당 60페이지)이 가능할 것이므로 20PPM 프린터에서는 3초가 가장 좋은 수치입니다.

20PPM 프린터라고 하면 첫페이지를 포함해서 모든 페이지를 3초에 한장씩 프린트할 수 있도록 만들면 좋은데 그렇게 하지 않을까요? 당연히 여러가지 요소 때문에 그렇게 만들 수 없기 때문입니다. CPU도 마찬가지로 latency를 줄이는 일이 힘들어 졌습니다. CPU의 clock frequency를 증가시키더라도 Memory latency로 인해 성능 향상이 적고, Superscalar와 같은 ILP(Instruction Level Parallelism)방법을 더 많이 사용하더라도 instruction dependency로 인해 성능 향상 폭이 매우 적습니다. 따라서 throughput을 증가시키는 방향으로 SMT나 Multi-Core가 대두되고 있습니다. 현재 PC 동네에서도 Intel/AMD에서 나오는 CPU가 4개 Core를 가지고 있고, Intel i7의 경우에는 SMT(intel은 hyperthreading이라 부름)를 적용하여 8개의 thread가 동시에 수행됩니다. 현재 추세로는 core 갯수를 6개나 8개로 더 증가시킬 모양입니다.

OpenSPARC T1/T2는 latency를 줄이는 것은 거의 포기하고 throughput을 높이기 위해 극단적으로 설계된 CPU입니다. ILP라는 개념 자체를 아예 사용하지 않고 설계하였고, clock frequency도 비교적 낮은 편입니다. CPU core를 더 많이 넣기 위해서 core의 설계를 단순화하여 작게 만들려고 노력했습니다. 이런 접근 방법은 server 동네에서는 적절하다고 생각합니다. 예를 들어 web server로 사용한다고 하면, 수 많은 사용자가 web server에 접속을 합니다. 그리고 그 많은 사용자 사이의 dependency는 거의 없습니다. 따라서 사용자 마다(정확하게는 TCP/IP connection 마다) 별도의 thread나 process가 동작하면 되고, 그것이 여러개의 core에 나누어져 수행하면 됩니다. 당연이 여러 사용자를 위한 service가 동시에 동작하면 동시에 수행 가능한 thread가 많을 수록 execution time이 줄어듭니다. 빨리 동작하는, 즉 clock frequency가 매우 빠르고 ILP를 충분히 활용하는 단일 core CPU에 여러 사용자를 번갈아 서비스하는 것보다 유리할 가능성이 큽니다. 산술적으로 64배의 clock frequency로 동작하는 CPU core를 설계해야 동일한 성능을 기대할 수 있지만, memory latency 등을 고려하면 단일 core가 64배 빠른 clock frequeny를 가진다고 해도 64개의 thread가 동시에 동작하는 CPU보다 빠를 가능성은 매우 낮습니다.
또한 T1/T2는 hypervisor mode가 있어서 여러 개의 OS를 특정 CPU에 할당하여 동시에 수행할 수 있는 구조를 가집니다. Windows PC에서 VirtualBox나 VMWare 등을 사용해서 linux를 필요할 때만 사용하는 저로서는 이해하기 힘들지만, server 동네에서는 여러 개의 OS를 돌리면 장점이 많이 있나 봅니다. 수년 전에 ftp service는 FreeBSD에서 가장 빠르다는 뭐 benchmark를 본 적이 있는데, service 마다 다른 OS를 사용하는 것이 이득인 경우가 많이 있나 봅니다. 이렇게 여러개의 OS를 사용할 때도 CPU가 여러개 인 것이 매우 강점이고, service의 비중에 따라서 OS에 할당된 CPU 갯수를 조절하는 것도 가능하므로 상당히 유연합니다.

Intel/AMD에서도 PC용으로 T1/T2와 같이 latency는 어느 정도 포기하고 throughput을 극닥적으로 높인 processor를 설계하는 것은 어떨까요? PC에는 이런 접근이 적합하지 않습니다. PC는 사용자와의 Interface 요소가 많은 부분을 차지하고 있으므로 latency도 매우 중요합니다. 인터넷 서핑중에 web Page가 늦게 화면에 표시될 때 그 기다림은 사용자를 답답하게 합니다. 일반적인 PC 사용자는 여러 개의 web page가 한꺼번에 빨리 열리는 것을 바라지 않고, 자신이 보고 싶은 하나의 page가 빨리 열리기를 바랍니다. 또한 PC의 주용도중 하나로 볼수 있는 game에서도 latency가 매우 중요합니다. 여를 들어 game을 하는데 keyboard나 mouse의 반응이 3초 후에 일어난다고 가정하면, game이 말이 되지 않겠죠. 따라서 PC에서 사용되는 CPU는 latency를 줄이는 것을 기본으로 해야 합니다. 물론 그게 한계를 맞았기 때문에 core를 여러개 넣고 있습니다.

PC에서 multi-core CPU가 도입되면서, multithread programming이 각광을 받고 있습니다. 당연히 windows thread library나 pthread library 등을 직접 사용하는 방법이 있고, OpenMP나 Intel Thread Building Block과 같은 tool/library 등을 사용할 수도 있습니다. PC에서는 이런 방법을 통해서 달성하고 싶은 것은 server의 경우에서 처럼 여러개의 program을 동시에 수행하여 throughput을 올리는 것이 아니라, 특정 프로그램의 execution time을 줄이는 것입니다. PC의 경우 서버와 달리 동일한 작업을 동시에 여러 개 수행하는 경우는 별로 없으므로, 결국은 latency를 줄이기 위해서 노력한다고 할 수 있습니다. 하나의 일을 여러 thread로 나누어 동시에 수행하므로써, 일의 수행을 위해서 소요되는 latency를 줄이는 것이 목표입니다. thread로 나누게 되면 thread 사이의 dependency가 생기게 됩니다. 예를 들어 특정 thread의 작업 결과를 다른 thread가 처리를 하게 되면 앞 thread의 작업이 끝났는지 check하고 뒤 thread가 동작하도록 해야 합니다. 이런 것을 thread synchronization이라고 하는데, thread를 만들고 synchronization을 하는데는 별도의 performance가 요구됩니다. 여러개의 thread로 나누어 동시에 수행하도록 할 때는 될 수 있으면 thread간의 dependency가 없도록 해야 하는데, dependency가 많을 경우 여러개의 thread로 나누는 것이 나누지 않는 것 보다 성능이 더 떨어질 수도 있습니다. 이렇게 multithread programming을 통해 latency를 줄이는 방법은 상당히 골치 아픈 일입니다. T1/T2의 Server 동네에서 TCP/IP connection 별로 core에 돌릴 각각의 작업이 자동으로 나누어지는 반면 multithread programming을 통해 latency를 줄이는 것은 상당히 어렵습니다.

그렇다면 Embedded 동네에서는 어떨까요?


Embedded 동네에서는 Server와 같은 상황이 벌어지는 곳이 그렇게 많지 않습니다. Network packet processing과 같은 경우 말고는 그다지 생각나는 영역이 없습니다. 따라서 T1/T2와 같은 엄청난 multi-core 또는 SMT를 사용하는 경우는 극히 적습니다. 하지만 역시 CPU Core IP를 제공하는 ARM/MIPS 등에서 SMT나 Multicore가 꾸준히 나오고 있습니다. 동일한 core를 여러개 연결하는 것을 보통 SMP(Symmetric Multi-Processing), 좀 더 정확하게는 homogenous multi-core라고 하는데 ARM에서 제공하는 ARM11MPCore, 그리고 얼마전에 발표한 Coretex A9 과 같은 것이 그 예입니다. MIPS에서도 core 하나로 5개의 thread를 지원하는 MIPS32 34K와 core당 2개의 thread를 지원하고 core를 4개까지 연결할 수 있는 MIPS32 1004K를 제공하고 있습니다.

또한 TI OMAP과 같은 processor는 ARM+DSP multi-core를 사용하고 있는 경우가 있습니다. 이렇게 다른 architecture를 가지는 core를 연결한 것을 AMP(Asymmetric Multi-Processing), 정확하게는 heterogenous multi-core라고 합니다. ARM과 같은 general purpose CPU에 OS/UI 등의 program을 수행하고, DSP에서는 계산량이 많은 작업을 수행하는 방법입니다. Sony의 게임기 Playstation 3에 사용되고 있는 Cell Broadband Engine은 Power Architecture CPU 하나와 SPE라고 하는 floating point 연산을 주로 처리하는 core가 8개 들어있습니다. Cell과 비슷한 approach로, ziilabs라는 회사에서 금년에 출시한 processor는 독특하게도 ARM9 dual core에 processing elements라고 불리우는 core 24개를 내장하고 있습니다.

이렇게 Embedded 동네에서도 multi-core나 SMT가 개발되는 이유는 우선 CPU의 performance 요구량이 더 커졌기 때문입니다. 특별히 multimedia application은 많은 성능이 요구됩니다. 또한 Embedded 동네는 Server나 PC에 비해서 Power 소모량의 제약이 더 심하기 때문에 clock frequency를 높이거나 ILP를 많이 활용하여 성능을 높이려고 시도하는 것이 더 어렵기 때문입니다. 하지만 당분간은 T1/T2급의 엄청난 숫자의 multi-threading을 일반적인 embedded 시장에서 볼 수는 없을 겁니다.Embedded 동네는 특성은 좀더 높은 성능이 아니라, application에 딱 맞는 성능을 요구합니다. 필요 없이 자원(당연히 돈, power 등)을 낭비하는 것을 지양하는 것입니다. 따라서 성능의 요구량이 많지 않은 application에서는 multi-core는 고사하고 여전히 8bit/16bit MCU가 많이 사용되고, 그런 application이 존재하는 한 없어지지 않을 겁니다.



==
참고로 homogenous multi-core의 경우, 즉 동일한 CPU core를 여러개 사용하는 system이라도 꼭 SMP(symmetric multi processing)일 필요는 없습니다. 각 CPU 별로 별도의 OS를 동작시키고 CPU 사이에는 별도로 interrupt 등으로 message를 주고 받는 구조를 취할 수 있습니다. 일반적으로 SMP라고 하면 단일 OS에서 모든 core에 서로 task를 scheduling을 통해서 동작시키는 것을 말합니다.


==
관련 사이트
ARM

MIPS

IBM Cell Boradband Engine Resource Center

Ziilabs