2009년 12월 25일 금요일

Xilinx EDK 간단 사용기

회사에서 진행하는 프로젝트로 Xilinx Embedded Design Kit(Version 11)를 사용해서 MicroBlaze를 사용한 설계를 해 보았습니다.


Xilinx EDK는 Altera Quartus II에 있는 SOPC와 같은 tool로 Xilinx가 제공하는 MicroBlaze라는 32bit CPU와 여러가지 peripheral을 이용하여 CPU subsystem을 꾸밀 수 있게 해 주는 tool입니다. MicroBlaze뿐 아니라 Xilinx의 몇몇 FPGA에 들어 있는 PowerPC CPU를 이용하여 System을 꾸미는데도 사용하는 것 같습니다. EDK는 기본적으로 Platform Studio라고 하는 통합 환경이 있어서 그것을 통해서 hardware 구성을 하고, Software Development Kit이라는 tool을 이용하여 software를 build하는 구성을 가지고 있습니다.


사용하는 법은 "따라해 보세요" 스타일의 문서인 EDK Concepts, Tools, and Techniques만 읽으면 쉽게 익힐 수 있습니다. 좀더 살펴보기 위해서는 Embedded System Tools Reference ManualPlatform Specification Format이라는 문서를 읽으면 됩니다.


  • Platform Studio
Platform Studio는 Xilinx EDK의 통합환경입니다. 기본적으로 stand-alone 상태에서 하드웨어 구성, 합성, P&R을 모두 처리할 수 있도록 되어 있습니다만, ISE project navigator에서 디자인의 일부로 Xilinx EDK를 호출하여 사용할 수도 있도록 되어 있습니다.
Platform Studio는 기본적으로 Base System Build Wizard라는 것을 제공하여, Wizard 형식으로 묻는 내용만 넣으면 base system을 만들 수 있도록 되어 있습니다. Xilinx가 제공하는 reference board를 사용하는 경우에는 board 종류만 고르면 base system이 딱 하니 나옵니다. 사용자의 custom board를 사용하는 경우에도, Clock 주파수, CPU(MicroBlaze)를 1개 혹은 2개 넣을 건지 선택하고, MicroBlaze에서 사용할 RAM 크기 등을 지정하고, Xilinx에서 무료 혹은 유료로 제공하는 peripheral IP를 선택하면 base system을 만들 수 있습니다.


Base system을 만들고 나서도, Xilinx에서 제공하는 IP 및 사용자가 만든 IP를 추가하거나 변경 등을 할 수 있도록 되어 있습니다. Xilinx가 제공하는 IP는 꽤 다양한데 아래 링크에서 확인할 수 있습니다.
Xilinx EDK가 제공하는 IP list


Xilinx가 제공하는 IP는 대부분 configuration이 가능한 구조를 가집니다. 예를 들어 UART의 경우 baud rate를 바꾼다거나 하는 일을 할 수 있고, GPIO의 경우에는 외부에 연결된 I/O pin의 갯수 등을 바꿀 수 있습니다. VHDL의 generic을 이용하여 module(VHDL이니깐 entity라고 해야 겠죠)의 형태가 바뀔 수 있도록 되어 있습니다. 참고로 Xilinx가 제공하는 모든 IP는 verilog이 아니라 VHDL로 제공됩니다.


Base system으로도 완전한 CPU system이지만, 일반적으로는 사용자가 logic을 추가해야 나름 비싼 FPGA를 사용하는 의미가 있습니다. 사용자의 logic을 추가하지 않으면, 고가의 FPGA를 이용하여 단순한 32 bit MCU를 만든 것에 지나지 않기 때문입니다. 사용자의 logic이 CPU(MicroBlaze)를 이용하여 control할 수 있는 구조로 내장 되어야 가치 있는 설계가 될텐데, 이를 위해선 CPU및 각종 peripheral이 붙어 있는 BUS를 이해해야 합니다. Xilinx EDK는 기본적인 BUS로 IBM CoreConnect PLB(Processor Local Bus)를 사용하고 있는데 사용자가 PLB를 모두 이해해서 사용자 logic을 연결하기 위해서 시간이 많이 필요하게 됩니다. Xilinx EDK는 Create and Import Peripheral Wizard라는 것을 제공하여 그 시간을 단축시켜 줍니다. 이 Wizard는 PLB BUS master/BUS slave에 관련된 template 형태의 VHDL code를 생성해 주는데, 사용자는 이 code를 기본으로 하여 원하는 기능의 logic을 쉽게 붙일 수 있습니다. 참고로 사용자 logic은 verilog로 작성해도 무방합니다.


  • Software Development Kit
Eclipse 기반으로 작성된 Software IDE입니다. 기본적으로 Platform Studio에서 Export한 hardware description XML 파일을 이용하여 Platform이라 부르는 기본적인 library를 build하고 그 library를 이용하여 application을 작성할 수 있도록 되어 있습니다. Build한 application을 FPGA에 넣어야 하는데, 이를 위하서 Platform Studio에서 합성 결과인 bitfile에 application binary를 넣어서 새로운 bitfile을 만들어, JTAG Cable을 통해서 download하고 running/debugging할 수 있는 환경이 제공됩니다. JTAG Cable을 통해서 board와 연결되어 있으면 별도의 debugger 같은 것은 필요 없습니다.


나중에 기회가 되면 자세한 사용 방법을 설명하기로 하고, 사용하면서 몇가지 문제점들이 있었는데 그것만 밝혀 두도록 합니다.
  • 설치 문제
개발 PC에는 cygwin와 Eclipse CDT가 설치되어 있었는데, 그게 문제가 되었습니다. Xilinx SDK가 함께 설치된 make utility를 호출하지 않고, 기존에 PC에 설치된 cygwin의 make utility를 호출하여 software build에서 문제가 발생한 경우가 있었습니다. 아마도 PATH 환경 변수에 관련된 문제였을 것으로 추정하는데, Cygwin을 제거하니 문제없이 동작하였습니다. 그리고 Platform Studio에서 SDK를 띄울 수 있도록 되어 있는데, 기존에 설치된 Eclipse가 문제가 되었는지 잘 되지 않았습니다. SDK를 별도로 띄운 다음에 일일이 eclipse workspace의 경로를 잡아야 문제가 되지 않았습니다.


  • 사용상의 문제
Platform Studio의 GUI에서 INTC(Interrupt Controller)를 설계에 넣고, INTC에 여러 interrupt를 연결을 하려고 하면 이게 또 제대로 동작하지 않습니다. 자세한 에러 메시지라도 나오면 무언가 그것을 해결하려고 했을 텐데, 별 메시지도 없어서 어쩔 수 없이 GUI를 이용하지 않고 system을 기술하는 MHS 파일을 직접 편집해서 해결 했습니다.
또한, 어찌된 일인지 합성해 보면 INTC에 연결된 모든 signal이 unused라고 제거되는 경우가 있었는데, 이것도 project를 새로 만들어서 해결했는데 무슨 문제인지 파악할 수 없었습니다.


또, SDK에 NOR Flash를 programming할 수 있는 menu가 있는데, 이것이 제대로 동작을 하지 않았습니다.  Xilinx SDK는 기본적으로 AMD/Intel 스타일의 command를 사용하는 NOR Flash만을 지원하고, programming을 위한 file 형식은 elf와 srec(motorola-S)만 지원합니다. 사용한 Board에는 Numonyx(Intel과 ST의 합작 회사)의 8/16bit NOR Flash가 있었는데, srec 파일을 만들어서 programming 해 보았더니 무슨 문제인지 data가 write되기는 했는데 올바른 data가 write되지 않았습니다. 아마도 hardware 구성이나 뭔가가 잘못된 것 같은데, 확인할 방법은 없습니다. 하는 수 없이 nor flash write application을 만들어서 그것을 FPGA download한 후에 그 application을 수행하여 직접 write하는 방법을 써서 해결했습니다.


  • 문제라고 할 수는 없지만...
가장 거슬리는 점은 Xilinx IP와 연결된 거의 모든 signal이 vector인 경우 0부터 시작되는 vector라는 점입니다. 예를 들어 대부분의 vector signal은 다음과 같은 형태로 되어 있습니다.
signal Address : std_logic_vector(0 to C_ADDR_WIDTH-1);
위의 문법이 잘못되지는 않았지만, 문제로 삼을 만한 것은 Address(C_ADDR_WIDTH-1)이 LSB, Address(0)가 MSB가 된다는 점입니다. 우리나라 엔지니어만 그런지 모르지만, 보통의 엔지니어라면 address나 data 모두 0번 bit가 LSB라고 상식적으로 이해하고, std_logic_vector(C_ADDR_WIDTH-1 downto 0)의 형태로 쓰는데, Xilinx 엔지니어는 좀 사고 체계가 다른 것 같습니다. Create and Import Peripheral Wizard를 이용하여 생성한 PLB Bus Interface를 user logic에 붙일 때, 신경을 안쓰면 반대로 붙이는 경우가 생기게 됩니다. 또한 Xilinx가 제공하는 static memory controller IP 등의 외부 포트를 Board 위에 있는 SRAM/Flash를 연결할 때도 정말 신경을 써주지 않으면 실수할 수 밖에 없습니다.

또한, 대부분의 GUI기반의 tool이 가지는 특징이지만, EDK도 아주 일반적인 형태로 사용할 경우에는 상당히 편합니다만, 특별한 형태로 이용하고자 하거나 무언가 잘못될 경우, 그것을 위한 옵션이 어디에 있는지 찾기가 어렵습니다. 예를 들어 Create and Import Peripheral Wizard에서는 PLB Slave port를 여러개 가지고 있는 IP를 생성할 수 없도록 되어 있는 것으로 보이고, Interrupt signal을 추가하려고 하면 IP 내부에 눈으로 보기에도 복잡한 Interrupt control 관련 logic까지 한꺼번에 추가되는 것으로 보입니다. 그리고 실제로 일을 할 때, 설계를 점진적으로 IP를 추가하면서 진행하다 보니 경험한 것인데, 처음에는 FPGA 내부의 SRAM을 default로 사용하도록 application이 build되었는데, static memory controller를 추가하고 나니 static memory controller에 할당된 address를 default로 하여 application이 build 되도록 자동으로(?) 변경되었습니다. 그래서 link script를 손으로 변경하여 원래대로 바꾸었는데, 어떻게 변경할 수 있는 GUI tool에서는 찾을 수 없었습니다.


마지막으로 Platform Studio에서는 UNDO 기능을 제공해 주지 않습니다. 실수로 IP를 제거하거나 Configuration을 바꾸면 사용자가 다시 추가하거나 원래대로 돌려 놓는 작업을 스스로 해야 합니다.

2009년 12월 21일 월요일

FPGA 이야기 - 3

FPGA를 이용한 설계 방법, 특히 FPGA Vendor에서 제공하는 Design Software에 대해서 알아 봅니다.


  • FPGA를 이용한 설계 방법과 Design Software
사실 FPGA를 이용한 설계와 일반적인 standard cell library를 이용한 chip 설계는 크게 다르지 않습니다. 모든 design은 VHDL이나 verilog와 같은 HDL로 합성가능한 수준, 즉 RTL로 기술되어야 합니다. HDL의 검증은 기본적으로 simulation을 통해서 하게 되며, 그 검증이 끝나면 Synthesis와 P&R(Place&Route) 과정을 거치게 됩니다. chip 설계 였다면 P&R의 결과가 GDS 파일로 나오고 그것을 FAB에 보내서 반도체 die를 생산해야 겠지만, FPGA의 경우 P&R의 결과는 FPGA 내부를 configuration할 수 있는 bitstream이고, 그것을 FPGA에 download하면 FPGA가 동작하기 시작합니다.

모든 기능을 직접 HDL로 만들 수도 있지만, FPGA에서도 IP(Intelectual Property)라는 개념으로 FPGA Vendor나 3rd party 업체에서 설계하여 제공하는 block을 이용할 수 있습니다. FPGA Vendor에서 제공하는 간단한 IP를 제외하고는, 보통의 경우는 netlist 형태로 제공되는데, 당연히 license fee를 주고 사야 하고, 별도의 로얄티를 내야 하는 경우도 있습니다. 하지만 보통의 경우 비슷한 기능을 제공하는 ASIC용 IP에 비해서는 저렴한 편이고, 그런 IP를 이용하여 설계 시간을 단축할 수 있다면 충분히 이점이 있습니다.

설계 방법에서 필요한 모든 것을 FPGA vendor가 제공해 주는 design software을 이용하여 처리할 수 있습니다. Xilinx에서는 ISE라는 software, Altera에서는 Quartus II라는 software를 제공해 줍니다. 재미 있는 것은 이 Design Software를 FPGA chip을 샀다고 해서 무료로 제공 받는 것이 아니고, 별도로 돈을 주고 사야 한다는 점입니다. Trial version이나 기능을 제한한 version 같은 경우는 무료로 download할 수 있지만, 모든 기능이 들어 있는 version은 정식으로 license해야 합니다. ASIC용 EDA software와 달리 엄청 비싸지는 않습니다.

  • Design Software가 제공하는 기본적인 기능
(a) Design 관리
프로젝트 단위의 설계 관리 기능이 있습니다. 일종의 software 개발시 IDE라고 보면 됩니다. 프로젝트는 사용할 FPGA 종류, design 내용, user constraint 등을 담고 있습니다. 당연히 각종 기능들을 쉽게 이용할 수 있게 되어 있고, 각 기능의 결과 report 파일 등을 쉽게 볼 수 있는 환경이 구축되어 있습니다.


(b) Design Helper
HDL 설계는 그냥 text editor를 이용하면 되지만, HDL 설계를 도와 줄 수 있는 기능들이 있습니다. 예를 들어 HDL module 사이의 연결을 쉽게 해 주는 schematic tool이 있고, state machine의 coding을 손쉽게 해 주는 tool 등이 있습니다. 참고로 이런것을 제공해 주는 3rd party tool도 매우 많은 편입니다. FPGA Advantage나 Active-HDL 등 유명한 tool이 많은데, 개인적으로는 그냥 text editor, 그 중에서 vi를 주로 이용해서 손으로 작성하는 것을 선호하는 편이라 사용해 본 적은 없습니다.


(c) Simulator
HDL Simulator가 각 software에는 들어 있는데, 예전에는 FPGA Vendor가 제공해 주는 simulator의 기능이 상당히 빈약하여 다른 일반적인 HDL Simulator를 이용하는 경우가 많았습니다. 요즘에는 좀 나아졌는지 모르지만, 주변의 엔지니어들은 여전히 FPGA Vendor에서 제공해 주는 simulator를 사용하지 않고, 일반적인 HDL simulator를 이용하는 경우가 많습니다.

(d) Synthesis와 P&R
당연히 synthesis를 해 주는 기능이 포함되어 있습니다. ASIC을 만들때 처럼 FAB에서 주는 standard cell library는 필요하지 않습니다. 프로젝트를 생성할 때 선택한 FPGA가 있으므로, 그 FPGA에 맞추어서 합성을 해 줍니다. P&R tool이 있어서 합성 결과를 P&R 해 주게 됩니다.
Synthesis와 P&R을 위해서는 ASIC 합성, P&R과 마찬가지로 timing constraint가 있어야 합니다. 설계에서 사용하는 clock의 주파수는 무엇인지, clock 간의 관계는 어떤지, input/output delay는 얼마인지에 대한 정보 등이 필요합니다. 이 정보를 이용하여 Synthesis나 P&R을 진행하고, 결과가 timing constraint에서 기술된 내용에 맞는지 검증할 수 있는 timing analyzing 기능도 포함되어 있습니다.


P&R을 수행하는데,  또 다른 중요한 요소는 FPGA pin assign 정보입니다. HDL은 단순히 input/output/inout 과 같은 형태의 port만을 가지므로, 해당 port가 실제 FPGA의 어떤 pin에 연결되어야 하는지에 대한 기술이 필요합니다. 이 pin assign 정보가 있어야 P&R tool이 해당 pin과 설계의 port를 연결해 주게 됩니다. 또한 FPGA는 pin은 programmable pullup/pulldown, programmable interface type(LVTTL/LVCMOS/SSTL 등)의 특성을 가지고 있으므로, 해당 부분도 같이 기술해 줍니다.


(e) In-System Programming
P&R이 모두 끝나면 Design Software는 FPGA programming을 위한 bitstream file을 생성하게 됩니다.  이 bitstream을 Board 위의 FPGA 또는 Program Memory에 download하면 FPGA가 설계한 대로 동작하게 됩니다. 이를 download할 수 있는 기능을 제공해 주는데, 각 Vendor에서 제공하는 JTAG Cable을 이용하여 PC와 Board를 연결하고 동작시켜주면 됩니다.


  • Design Software가 제공하는 부가적인 기능
위에서 언급한 기능만 있으면 설계에는 문제가 없지만, 설계및 debugging을 용이하게 하기 위해서 부가적인 기능을 제공합니다.


(a) IP 제공및 환경 제공
FPGA 내부의 LUT이 아닌 block, 예를 들어 SRAM, Multiplier, PLL 등을 쉽게 이용할 수 있는 기능을 제공합니다. 예를 들어 PLL을 사용하려고 하면, 우선 PLL의 module 이름을 파악하여 사용자가 직접 HDL code에 PLL module을 넣고, input/output port를 연결하여 사용할 수 있습니다. 하지만 FPGA 내부의 PLL은 다양한 기능을 수행할 수 있도록 되어 있어서, input/output port가 상당히 복잡합니다. 복잡하지 않다고 하더라도 PLL 관련 document를 꼼꼼하게 읽어가며 내용을 이해해야만 input port에 올바른 값을 넣고, 필요한 output port가 무엇인지 알 수 있습니다. 그래서 Design Software에서는 Wizard 형식으로 Software가 묻는 값을 사용자가 넣어주면, 알아서 그 PLL module과 주변 logic이 같이 HDL code로 생성되어서 나오도록 되어 있는 tool을 가지고 있습니다. 예를 들어 입력 주파수 27MHz에서 108MHz와 54MHz를 생성하고 싶다라고 알려주면 알아서 HDL code를 생성해 줍니다. 그리고 그 HDL code를 설계에 넣어서 사용하면 그만입니다. 마찬가지로 SRAM을 Asynchronous FIFO 형태로 사용하거나 하기를 원하면 마찬가지로 Wizard 형태로 FIFO의 width/depth 등을 넣으면 알아서 SRAM module과 관련 logic이 생성되어 HDL로 출력됩니다. 이런 기능이 Xilinx ISE에서는 Core Generator라는 이름으로, Altera Quartus II에서는 MegaWizard라는 이름으로 제공됩니다.


FPGA 내부의 block을 손쉽게 사용하는 것 뿐만 아니라, 각 Vendor가 제공하는 IP, 예를 들어 Memory Controller나 Ethernet Controller 등을 동일한 tool을 이용하여 사용자가 원하는 feature만 넣어서 만들 수 있습니다.


(b) On Chip Logic Analyzer 기능
FPGA 설계가 끝나서 보드에서 동작을 시키는데 문제가 있다면 어떻게 해야 할까요? 우선 HDL simulation을 통해서 문제가 없는지 살펴보는 것이 제일 좋은데, 일반적으로 simulation은 속도가 너무 느려서, 복잡한 검증이 사실상 어렵습니다. 또한 simulation vector가 실제 보드에서 벌어지고 있는 모든 것을 담아서 작성했다고 보기 어렵기 때문에, simulation을 통해서는 문제를 찾기 힘든 경우도 많이 있습니다. 예전에는 이런 경우 FPGA 설계를 바꾸어 monitoring을 하고 싶은 signal을 모두 FPGA pin으로 뺀 다음에, Board에서 해당 pin을 실제 Logic Analyzer에 물려서 원인을 찾는 방법을 사용할 수 밖에 없었습니다. 이런 방법은 Logic Analyzer라는 고가의 장비도 필요할 뿐더러, 설계를 바꾸어 signal을 밖으로 빼내야 하므로 상당히 불편했습니다.


이런 형태의 debugging을 손쉽게 해 주는 기능들이 Design Software에 포함되어 있습니다. FPGA 내부의 SRAM 등을 이용하여 monitoring하고 싶은 signal을 계속 저장하고 있다가, 특정 조건이 되면 JTAG Cable을 통해서 해당 내용을 읽어와서 해당 signal이 어떻게 변할 때 에러가 발생하는지 찾을 수 있도록 해 줍니다. Xilinx에서는 ChipScope라는 이름으로 Altera에서는 SignalTap II이라는 기능으로 제공하고 있는 것 같은 데, 두 가지 모두 개인적으로 사용해 본 적은 없습니다. 개인적으로는 비슷한 기능을 제공하는 Identify라는 프로그램을 사용해 본 적이 있는데, 에러를 찾는데 매우 편리합니다.


(c) Embedded CPU System Design Helper
Xilinx는 MicroBlaze, Altera는 Nios II 라고 하는 32bit CPU를 IP로 제공하여, 사용자가 설계에 활용할 수 있도록 해 주고 있습니다. CPU를 사용하게 되면 CPU의 Instruction과 Data를 저장할 memory controller가 필요하고, 또한 Debugging이나 Interconnection을 위한 다른 Peripheral(예를 들어 UART, Ethernet, USB 등)이 필요합니다. 또한 그런 block을 CPU와 연결할 수 있는 BUS가 필요해 집니다. 이런 IP를 FPGA Vendor가 제공해 주며, 연결및 구성을 손쉽게 해 주는 tool을 제공해 줍니다. Xilinx에서는 EDK의 Platform Studio, Altera에서는 SOPC Builder라는 tool을 제공해 줍니다.


또한 CPU를 사용하게 되면 필수적으로 CPU에서 동작시킬 Software를 작성해야 하는데, 그것을 위한 Compile/Debugging 등의 개발 환경도 제공해 줍니다.


(d) Digital Signal Processing 관련 tool
FPGA를 이용하는 Digital Signal Processing을 하는 경우가 많이 있습니다. FPGA Vendor에서는 DSP(Digital Signal Processor)를 사용하는 구현 보다, Cost/Power 면에서 이득이 있다고 많이 설득을 하는 기고문을 여러 곳에 올리고 있지만, 아무래도 Digital Signal Processing 동네에서 노는 사람들이 FPGA에 적응하기란 쉽지 않습니다.  그래서 그런지 matlab/simulink와 연동하여 hardware를 자동으로 만들어 주는 등의 support tool이 있습니다. 아무래도 주로 노는 동네가 시스템(CPU와 software를 포함한)쪽이라서 사용해볼 기회는 없었습니다.

  • 3rd party tool : Synplify
예전에는 FPGA Vendor가 제공하는 synthesis tool이 그다지 성능이 좋지 않았나 봅니다. 성능이란 합성 결과가 회로의 크기 및 동작 속도, 그리고 synthesis를 하는데 걸리는 시간이라고 볼 수 있습니다. 굳이 따지자면 지금도 FPGA Vendor가 제공하는 synthesis tool보다 EDA software만 만드는 회사의 tool이 더 좋을 수 밖에 없습니다. FPGA Vendor는 FPGA를 좋게 만들면 장사를 할 수 있지만, EDA software를 파는 회사 입장에서는 tool이 좋지 않다면 회사가 문을 닫아야 합니다. Xilinx FPGA 합성용 3rd party tool로 유명한 것은 Synplify와 LeonardSpectrum 이었습니다. 개인적으로 Synplify을 사용해 봤는데, Synplify는 Xilinx/Altera의 FPGA 모두를 지원합니다. Synthesis만 제공하므로 P&R은 FPGA Vendor tool을 이용해야 하는데, 그래도 사용하기 편리한 tool이었습니다. 참고로 Synplify는 FPGA Vendor의 software와 달리 가격이 상당히 비쌌는데, 작년초였나 ASIC EDA의 거두 synopsys에 인수되고 나서는 가격 조건이 어떻게 변했는지 알 수 없습니다.


Synplify가 좋은 점은 다음과 같습니다.
(1) HDL 합성
아무래도 합성의 성능이 더 좋은데, 예전에는 모르겠지만 현재는 엄청 차이가 나는 수준은 아닌 것 같습니다. 그래도 조금이라도 더 빠르고, 더 작게 합성해 준다면 언제나 좋은 겁니다. 그리고 Synplify는 HDL code 중에서 memory(RAM 혹은 ROM)의 파악을 잘 해서 그것을 FPGA SRAM으로 제대로 매핑해 줍니다. FPGA Vendor가 제공하는 synthesis는 이것을 잘못해서 SRAM으로 매핑할 수 있는 것을 Flipflop으로 모두 바꾸면서 정말 곤란한 결과를 주는 경우가 있습니다.


(2) Timing Constraint 작성이 편리함
FPGA Vendor의 software를 사용할 경우 timing constaint를 작성하려면, 문법이 좀 복잡하다고 할까 아무튼 문서좀 보고 연구좀 해야 합니다. 하지만 Synplify는 timing constraint 작성이 간단하고, contraint를 작성하기 위해서 봐야 하는 문서가 쉬운 편입니다. Synplify는 P&R을 위해서 FPGA Vendor별 contraint를 자동으로 생성해 주기 때문에 복잡한 것들을 배우지 않아도 됩니다.


(3) Identify를 이용할 수 있음
Identify는 Synplify와 별도로 구매해야 하는 tool인데 On Chip Logic Analyzer 기능을 제공합니다. ChipScope와 SignalTap II을 써보지 않아서 비교할 수는 없지만, Identify는 정말 사용하기 편리합니다. 설계 내용중에 signal을 latch할 clock하고, monitoring하고 싶은 signal 들, 그리고 triggering signal(error나 monitoring을 위한 조건을 위한 signal)을 지정하고 합성 누르면 알아서 monitoring을 위한 logic을 넣어서 합성해 줍니다. 그 다음에 Board에 JTAG cable 연결하고, bitstream download한 다음에 triggering 조건을 써 주면, FPGA의 동작중에 해당 조건이 만족되면 그 시점 전후로 하여 실제 FPGA에서 probe된 signal들의 waveform을 dump해 줍니다.

2009년 12월 12일 토요일

삼성전자, 파운드리 사업 육성하겠다?

이번주에 삼성전자에서 대한 재미 있는 소식이 났습니다.


삼성전자, "파운드리 사업 육성하겠다."
삼성전자 "반도체 파운드리, 신성장 동력으로 육성"


삼성전자는 매출 기준으로 세계 반도체 업계 2위인 회사입니다. 또한 DRAM 업계에서는 부동의 1위입니다. 그런데 파운드리(foundry) 사업도 주력 사업으로 키우겠다는 기사입니다. 해당 발언을 한 주인공이 "파운드리사업팀 상무"이고, 구체적인 투자 계획이 발표되지 않았으므로 얼마나 노력하겠다는 것인지 확실하지는 않습니다. 단지 TSMC와 필적할만큼 규모를 키우겠다는 장기적인 목표만 드러나 있습니다.


이 기사에 대해서 다음과 같은 상반된 두 개의 의견이 EETimes에 올랐습니다.
Opinion: Samsung misses foundry boat
Counterpoint: Samsung's foundry challenge will succeed


부정적인 의견은 삼성전자의 구체적인 계획을 알 수 없고, foundry 사업이 경기에 완전히 둔감한 편이 아니므로, 단순히 FAB을 늘리는 것만으로는 별로 성공 가능성이 없다는 것입니다. 긍정적인 의견은 삼성이 이제까지 보여온 과거를 보면 충분히 성공 가능성이 있다는 것입니다.


==========================================
Foundry 사업


FAB이 없는 반도체 설계 회사들, 보통 Fabless semiconductor company라고 부르는 회사의 설계 내용을 대신 생산해 주는 사업입니다. 대부분은 Wafer 가공만을 해 주며, Wafer당 일정 금액만을 받고, Package및 Test 등은 다른 회사들이 담당합니다. Foundry 회사는 크게 Pure-foundry라고 하여 자체 생산 제품 없이 위탁 생산만으로 회사를 경영하는 업체와 IDM(Integrated Device Manufacturer)라고 하여 자체 생산 제품(반도체 칩)도 있고, 위탁 생산도 해 주는 업체로 나눌 수 있습니다. Pure-foundry 업체로는 TSMC, UMC, Chartered, SMIC 등이 유명하고, IDM으로는 IBM, Fujitsu 등이 유명합니다. 국내에서는 동부하이텍이 pure-foundry 업체이고, 삼성전자는 IDM에 속합니다. Foundry 업계 1위는 TSMC이고, pure-foundry 업체들이 시장을 주도하고 있습니다.
IDM보다 pure-foundry가 고객, 즉 fabless semiconductor company 입장에서 좋은 이유는 IDM은 경쟁 회사가 될 수 있는데 비해, pure-foundry는 경쟁사가 아니라는 점입니다.
==========================================


삼성전자가 TSMC와 비슷한 규모로 foundry 사업을 키운다는 것은 어려운 일입니다.


  • 공정기술
삼성전자가 DRAM 업계 1위를 지키고 있는 것은 반도체 공정 개발에 투자를 계속 해왔기 때문입니다. 즉, DRAM을 생산하는 반도체 공정 개발에서는 삼성전자가 최고의 기술력을 가지고 있다고 볼 수 있습니다. 하지만 DRAM을 생산하는 반도체 공정과 LSI(Large Scale IC)를 생산하는 공정에는 차이가 많이 있다고 합니다. 학교에서 배울 때는 DRAM의 경우 metal보다 polysilicon을 많이 사용하고, 일반적인 LSI는 metal layer를 많이 사용한다고 했는데 아직까지 맞는지는 확실하지 않습니다. 아무튼 삼성전자는 LSI를 생산하는 반도체 공정에서 최고의 기술력을 가지고 있다고 볼 수 없습니다.


물론 현재 삼성 LSI 공정이 형편없는 수준은 아닙니다. 기본적으로 삼성 System LSI 팀이 직접 설계하는 칩들을 생산하고 있습니다. 예를 들어 현재 국내에서 각광 받고 있는 애플 아이폰에 들어 있는 application processor인 S5PC100이 65nm 공정에서 생산되고 있습니다. 그 외로 65 nm 공정에서는 여러 종류의 chip들이 생산되고 있는 것으로 알려져 있으므로 65nm 공정은 큰 문제가 없어 보입니다. 그리고 45 nm 공정은 어디까지 되어 있는지 알려져 있지 않습니다. 당연히 45 nm에서 1GHz ARM Coretex-A8을 개발했다고 발표를 했으므로 45 nm 공정이 동작은 할텐데 수율이 일정 수준까지 올라왔는지는 알려져 있지 않습니다. TSMC도 얼마전에 40 nm 공정에서 수율 문제가 있어 생산을 의뢰한 nVidia와 ATI가 곤란을 겪고 있다는 루머가 있었는데 수율 안정화는 공정 기술에서 가장 중요한 요소입니다. 또, 시장에서는 삼성의 90 nm 공정에 문제가 있다고 알려져 있는데, 사실이라면 90 nm 공정도 개선할 필요가 있습니다. 모든 LSI가 최신 공정을 사용하는 것은 아니기 때문입니다.

LSI를 생산하는 반도체 공정 부분에서 세계 최고의 기술력을 가지고 있는 회사는 Intel입니다. 물론 Intel이 low-power 공정이나 RF 공정이 강하지 않겠지만, 적어도 미세 공정의 개발에서는 계속 앞서나가고 있습니다. 하지만 Intel은 foundry 사업을 하지 않습니다. 그 다음에 기술력이 좋은 회사를 꼽으라면 TSMC 정도가 될 것 같습니다. 다행인 것은 삼성전자는 IBM, Chartered와 함께 IBM Common Platform Aliance의 일원으로 반도체 공정 개발을 함께 하고 있는 점입니다. 돈 많이 드니까 같이 하자 정도로 이해할 수 있습니다. IBM도 예전부터 반도체 공정에 강자였으므로 믿음직한 편입니다. TSMC도 IBM 출신의 엔지니어들이 모여서 만든 회사라고 하던데 확인한 바는 없습니다.


  • 시장 상황
얼마전에 FPGA Vendor인 Xilinx가 최신 버젼의 FPGA인 Spartan-6와 Virtex-6를 삼성전자의 45nm/40nm 공정을 이용하여 개발했다고 발표하고, 기사를 보니 Qualcomm도 삼성에서 위탁 생산을 하고 있는가 봅니다. 우선 이름 있는 customer를 잡았다고 볼 수 있습니다. 하지만 사실 경제 상황이 좋지 않아서 foundry도 상태가 좋지 않습니다. 중국이 밀고 있는 SMIC와 같은 회사는 계속 적자를 기록하고 있고, Chartered도 계속 적자를 기록하다 Globalfoundries와 합병하기로 했습니다. Globalfoundries는 PC CPU 시장의 AMD가 반도체 공정 개발에 들어가는 투자 비용을 감당할 수 없어, FAB 부분만 분사한 후 아부다비 투자회사에 팔아서 생긴 회사입니다. Chartered와 합병을 하여, 단순히 생산 용량만으로는 Pure-foundry 2위 업체인 UMC도 넘어서는 큰 회사가 되었습니다. 당연히 AMD에서 주는 일감만으로는 이익을 내기는 곤란하고, TSMC를 따라잡는다는 목표아래 반도체 회사들을 돌아다니며 세일즈를 하고 있는 것으로 알려져 있습니다.


  • Eco-System
삼성전자가 TSMC보다 엄청 떨어지는 부분이 이 부분입니다. Fabless 반도체 회사의 입장에서 보면 RTL을 합성하여 결과를 낼 때는 foundry 업체에서 standard cell library를 제공해 주므로 대부분 거기서 거기라고 보입니다. 하지만 IP를 구매해야 할 경우 차이가 많습니다. 우선 Analog IP를 보면, TSMC가 시장을 주도하다 보니 Analog IP 업체에서 제공하는 IP가 TSMC 공정을 타겟으로 개발되는 경우가 많습니다. 심지어 Digital IP의 경우도 TSMC 65 nm 공정에서 XXX MHz로 동작한다 뭐 이런식으로 설명되어 있고, TSMC에서 netlist나 hardcore 형태로 이용할 수 있게 하는 등, TSMC를 기준으로 생각합니다. 그만큼 TSMC를 찾는 고객이 많다는 것이 강점입니다.


  • 삼성전자의 최대 강점 : 돈
영화 바닐라스카이에서는 영화의 주제와는 전혀 다르지만, 다음과 같은 대사가 나옵니다.
"What is the answer to 99 out of 100 questions? Money."

돈, 즉 투자를 얼마나 하느냐가 중요하고, 삼성전자는 많은 현금을 쌓아 두고 있습니다. foundry 사업을 TSMC와 대등한 수준으로 끌어올리기 위해서는 다음과 같은 부분에 투자가 이루어져야 합니다.


(1) 공정 기술 개발 및 FAB 확충
미세 공정을 계속 개발하고 TSMC와 대등한 수준의 수율로 생산을 할 수 있어야 합니다. 당연히 Wafer 가공비및 NRE는 TSMC와 경쟁이 될 만큼 되어야 겠습니다. 그리고 FAB의 용량도 증설해야 합니다. 외부에서 많이 들어오는 일감을 제때 처리할 수 있을 만큼 되어야 하므로, 사업이 확장되는 것에 맞추어 FAB을 많이 늘려야 합니다. FAB 하나를 만드는데 2~3조원 든다고 하는데 돈이 문제입니다. 그리고 일반적인 공정 뿐 아니라, RF공정이나 Flash 공정도 필요하다면 만들어야 합니다.


(2) Eco-System 강화
사실 삼성전자 입장에서는 Xilinx, Qualcomm 등의 큰 업체만을 주요 고객으로 공략하는 것이 편하고 수익률도 좋습니다. 큰 업체가 요구하는 Analog IP가 있으면 삼성전자의 엔지니어들이 직접 개발해 주거나 외주 개발 시키면 됩니다. 하지만 그런식으로는 Eco-System을 갖출 수 없습니다. 작은 Fabless 회사도 고객으로 잘 받아 주어야 합니다. 외국 반도체 회사는 모르겠지만, 국내에서는 삼성전자 FAB에서 들어가기 어렵다고 알려져 있습니다. 기본적으로 생산 이력을 따지고, 얼마나 많이 양산할 지 꼼꼼히 따져서, 어느 기준이 되지 않으면 돈(NRE)을 낸다고해도 삼성전자 FAB을 이용할 수 없다고 합니다. 또한 삼성전자에는 MPW(Multi-Project Wafer, 혹은 Shuttle program)가 없다고 알려져 있는데, 이것도 바꿀 필요가 있습니다.
위에서 언급한 대로 큰 업체를 주요 고객으로 공략하여 많이 양산될 제품만 받아서 생산하는 것이 이익률을 극대화할 수 있습니다만, 많은 회사가 다양한 종류의 chip을 생산할 수 있도록 해 주는 것이 Eco-System을 강화할 수 있습니다.

  • Answer to remained 1 question

Foundry 사업은 제조업이 아니라 서비스업이라고 볼 수 있습니다. 고객의 만족감을 올리고, 불만을 줄여야 합니다. 그런데 삼성전자는 pure-foundry가 아닌 IDM 형태이므로, IDM foundry의 한계를 가지고 있습니다. 즉, 고객이 경쟁자가 되는 경우가 있습니다. 삼성전자의 다른 부문, 예를 들어 System LSI 사업부에서 설계한 chip이 foundry의 고객사의 chip과 경쟁 관계를 가질 수 있습니다. 이것은 고객 입장에서는 참 곤란한 문제입니다. 사실 삼성전자 foundry 입장에서는 고객에게 적절한 가격의 견적서를 보내려면, 고객이 1년에 몇장의 wafer를 생산할 지 알려 주어야 하고, 삼성전자 입장에서는 고객이 제시한 물량이 맞는지 가늠해보기 위해서 생산할 chip의 application 등의 정보를 고객에게 요구하게 됩니다. 고객 입장에서는 많은 것을 삼성전자에게 공개해야 합니다. 고객 입장에서 더욱 꺼림직한 것은 chip의 생산 단가를 삼성전자가 정확하게 알게 된다는 점입니다. 고객사의 chip과 삼성전자의 chip이 경쟁관계를 가지고 있고, 삼성전자의 chip 경쟁 우위에 있다면, 공개된 정보탓이라고 고객이 생각할 수 있는 충분한 소지가 있습니다. 이것을 해결하지 않으면 많은 고객을 끌어 모으기 힘들겁니다.

Foundry 사업부는 다른 사업부와 관계 없이 독립적으로 운영된다고 고객을 설득한다고 해도 믿어 줄까요? 삼성전자에서 chip을 만들 경우 삼성 FAB을 사용하지 않으면 어떨까요? 실제로 삼성전자 내부에서 설계하는 모든 chip이 삼성 FAB을 사용하지는 않습니다만, 다른 FAB을 사용하도록 원칙을 정해 놓으면, 모양새도 우습고, 고객의 입장에서는 크게 달라지는 것이 없다고 생각할 가능성이 큽니다.

결국은 될 수 있으면 고객과 경쟁을 하지 않도록 해야 합니다. 그렇다면 매출이 가파르게 상승세를 이루고 있는 System LSI 사업부를 foundry 사업을 위해서 정리하면 어떨까요? 그것만으로 된다면 할 수도 있겠지만, 삼성전자는 반도체 회사가 아니라 종합 전자회사라서 시스템에서 필요한 칩을 만들 필요가 있다는 점입니다. 예를 들어 몇년전에 나온 HDTV 화질 계선용 DNie chip 같은 경우, 회사 외부에 팔기 위해서 만든 칩이 아닙니다.

삼성전자가 당분간 따라올 수 없는 기술적 경지에 있는 메이져 회사들을 대상으로, TSMC보다 더 좋은 조건을 제시하는 것이 유일한 방법이 아닐까요? 예를 들어 삼성전자가 FPGA를 만들고 싶어도, 당분간은 따라갈 수 없는 Xilinx가 좋은 예가 될 수 있겠습니다. 하지만 이런 소극적인 방법으로는 TSMC만큼 커지는 것은 불가능할 것 같습니다.

적절한 해답이 떠오르지 않습니다.


삼성전자가 어떻게 투자를 진행하고, 어떻게 고객들을 관리하게 될 지 두고 볼 일입니다.

2009년 12월 9일 수요일

FPGA 이야기 - 2

FPGA 내부 구조및 종류에 대해서 살펴 봅니다.


  • FPGA의 내부 구조
- LUT(Look Up Table)
FPGA는 Gate Array와 달리 NAND/NOR Gate는 사용하지 않고, 대신 4~6 input LUT를 사용하여 combinational logic을 구성합니다. LUT이란 그냥 memory라고 생각하면 됩니다. Address에 input을 가하면 memory 내부의 내용이 output으로 나오면서 그것이 logic이 됩니다. memory 내부의 내용을 바꾸어 다양한 combinational logic을 구현할 수 있습니다. 당연히 sequential logic을 설계할 수 있어야 하므로 LUT의 끝에는 flipflop이 달려 있어서 이용할 수 있습니다. 기본적으로 LUT를 여러 개 넣은 것을 한 단위로 하여 Vendor별로 Slice니 ALM이니 하는 것으로 부르고 그것의 배열이 FPGA를 이루고 있습니다.


- Programmable Interconnect
LUT들 사이의 연결을 해야 완전한 logic이 됩니다. 이 연결도 당연히 programmable합니다. 일반적으로 FPGA 설계가 chip으로 구현하는 것보다 느린 이유는 이 Interconnect 부분에서 많은 delay가 있기 때문입니다. 될 수 있으면 routing을 잘 하여 interconnect의 delay를 줄여야 빨리 동작하는 설계가 됩니다.


- Programmable I/O
FPGA와 다른 chip들이 interface해야 하므로, FPGA I/O pin도 여러 종류의 interface 표준을 지원합니다. 예를 들어 LVTTL/LVCMOS과 같은 간단한 interface뿐 아니라,  DDR/DDR2 SDRAM에서 사용하는 SSTL과 같은 것도 지원하고, LVDS와 같은 differential interface도 가능합니다. FPGA에 있는 pin들이 지원하는 interface에 따라 나누어져 있는 형태가 아니고, 모든 pin을 interface에 따라 달리 사용할 수 있도록 되어 있습니다. 물론 VCC/GND는 제외하고, IO의 전압에 따라서 약간의 제한이 존재하기는 합니다.


- Memory
LUT/flipflop 만으로도 모든 digital logic(combinational/sequential)을 구현할 수 있지만, FPGA에는 SRAM 형태의 block memory도 들어 있습니다. LUT끝에 있는 flipflop으로도 data를 저장할 수 있지만, 그렇게 사용하게 되면 LUT가 낭비되고, routing이 복잡해 지므로 효율적이지 않기 때문입니다. SRAM은 보통 buffering을 위해서 FIFO 형태로 사용하게 되는 경우가 많습니다.

- Adder/Multiplier
연산을 위한 Adder/Multiplier 등도 별도로 들어 있습니다. 역시 LUT로도 구현이 가능하지만 전용 block을 가지고 있는 편이 timing/die area/power 등의 면에서 유리하기 때문입니다. Adder/Multiplier를 이용할 경우, 기존에 DSP(Digital Signal Processor)가 많이 이용되는 영역 - 당연히 Digital Signal Processing 분야 - 에서도 FPGA를 이용한 구현이 더 유리하다는 많은 글들이 올라오고 있습니다. 당연히 FPGA 회사에서 홍보성으로 퍼뜨리는 글일테지만 완전히 거짓은 아닐 것으로 판단됩니다. 다만 기존의 DSP Software를 하는 engineer는 FPGA를 이용한 설계에 적응을 쉽게 할 수 없겠지만 말이죠.


- Clock 생성 관련 PLL 등
PLL 등의 block이 포함되어 있어서 FPGA 내부에 다양한 형태의 clock을 공급해 주게 됩니다. 해당 PLL이 어떻게 동작해야 하는지도 당연히 programmable 합니다.


- High Speed Serial I/O
Gbps(Giga-bit/sec)급을 지원하는 Serial I/O도 포함되어 있는 경우가 있습니다. 당장 PC에서 사용하는 PCI-Express, SATA와 같은 것을 FPGA에서 지원하려면 High Speed Serial I/O가 있어야 합니다. 또한 많은 분야(주로 Video/Broadcast 부분)에서 Gbps급 I/O를 사용하고 있어서 FPGA에서도 지원하고 있습니다.


- CPU
내부의 ARM이나 PowerPC 등의 CPU가 포함된 FPGA도 있습니다. 사실 System에서 FPGA 사용을 검토하는 가장 큰 이유는 매우 많은 연산을 처리해야 하는데 그것을 일반적인 CPU 혹은 DSP가 감당할 수 없을 때입니다. FPGA로 많지만 간단한 연산을 처리하도록 하고, 나머지 복잡하지만 자주 처리할 필요가 없는 부분은 여전히 CPU로 하는 것이 일반적입니다. 아무래도 CPU에 Software를 얹는 방법이 hardware 설계 보다 쉽기 때문에, 복잡하지만 peformance가 많이 필요하지 않은 일은 software로 구현하는 편이 유리합니다. 결국, FPGA로 System을 구성하더라도 별도로 CPU가 필요한 경우가 많은데, 그 때 사용하라고 ARM/PowerPC 등의 CPU를 FPGA에 넣는 경우가 있습니다. 하지만 요즘은 FPGA Vender에서 LUT로 비교적 빠른 CPU를 구현해서 넣는 방법을 제공하여, ARM/PowerPC가 들어 있는 FPGA의 용도는 좀 애매해진 구석이 없지 않습니다.


- 기타
그 외로 Ethernet MAC, PCI Express controller, DRAM Controller등이 내장된 FPGA도 있습니다. 심지어 몇가지 Analog Circuit이 들어 있는 FPGA도 있는데, 일반적으로 Analog Circuit은 application에 따라서 요구하는 specification이 매우 다양하기 때문에, Analog Curcuit이 들어 있는 FPGA는 대중적이지는 않습니다.


  • FPGA 종류
LUT가 memory라고 했는데, 일반적으로 저렴하면서 빠른 memory는 SRAM입니다. 따라서 매우 빠른 동작 속도를 가지는 FPGA의 경우 SRAM을 기반으로 하는 경우가 많습니다. 하지만 SRAM의 경우 전원이 없으면 data를 잃어버리는 단점이 있습니다. SRAM 기반의 FPGA의 경우에는 전원이 인가되면, SRAM 내용을 채워야 동작이 되는데, 그것을 위한 방법은 여러가지가 있습니다. 가장 간단한 방법은 각 FPGA Vendor에서 제공하는 program memory chip을 사용하는 것입니다. program memory chip은 non-volatile 형태로 전원이 없어도 내용이 유지됩니다. FPGA에 전원이 인가되면 program memory chip에서 data를 읽어서 자신을 programming(보통은 configuration이라 부름)하고난 후에 동작을 시작합니다. FPGA Vendor가 제공하는 program memory chip도 아주 많이 팔리지 않으므로 그다지 저렴하지 않습니다. 저렴하게 팔리는 SPI Flash와 같은 chip을 이용해서 configuration할 수 있는 FPGA도 있습니다. 또 다른 방법으로 외부의 CPU나 다른 logic이 FPGA에 program 내용을 download해 주는 방법이 있습니다. 마지막으로 JTAG을 이용한 configuration 방법이 있습니다. 보통 PC와 cable로 JTAG 연결을 하여 configuration하는 방법인데, 개발 중에 많이 사용합니다. 각 FPGA Vendor별로 전용 JTAG cable을 제공해 주고, 그것은 Vendor의 design software를 이용하여 동작시킵니다. 참고로 program memory chip도 보통의 경우 JTAG을 이용하여 program하게 됩니다.

Flash Memory를 기반으로 동작하는 FPGA도 있습니다. Flash 기반이므로 당연히 SRAM 기반 FPGA보다 비쌉니다. 두가지 형태가 있는데, 하나는 FPGA 내부는 SRAM 기반으로 하되 program memory chip 기능을 가지는 flash가 내장된 형태가 있고, 나머지 하나는 그냥 Flash 기반으로 FPGA가 동작하는 경우가 있습니다. Flash 기반이므로 당연히 전원이 없을 때도 data를 잃어버리지 않으므로 별도의 외부 장치가 없어도 동작하는데는 지장이 없습니다. FPGA 내부의 flash는 보통 JTAG을 이용하여 programming합니다.


Actel에서만 나오는것 같은데 anti-fuse라는 방식의 FPGA가 있습니다. FPGA 내부가 fuse의 array와 같이 되어 있고, 강한 전류를 흘려, 특정 fuse를 끊어 내는 방식으로 FPGA를 programming한다고 합니다. 당연히 별도의 program memory chip을 필요로 하지 않습니다만, FPGA를 한번 programming하면 다시 programming하는 것은 불가능하다는 단점이 있습니다. 대신 이 anti-fuse 방식의 FPGA가 매우 빠른 동작을 한다고 알려져 있었는데, 사용해 본 경험이 없어서 현 시점에서도 빠르다고 확신할 수는 없습니다.


  • CPLD와의 차이
CPLD(Complex Programmable Logic Device)라고 하여 FPGA와 비슷한 애가 있습니다. CPLD도 일반적인 digital logic을 구현하는데 사용됩니다. 각 FPGA Vendor들도 CPLD를 생산하는데, Xilinx는 CoolRunner, Altera는 Max라고 부르는 CPLD product line를 가지고 있습니다. FPGA와는 다른 내부 구조를 가지고 있다고 하는데 자세한 것은 알지 못하고, 사용하는 사람의 입장에서 보면 다음과 같은 차이가 있습니다.
우선 CPLD로 구현할 수 있는 logic의 규모가 FPGA에 비해서 상대적으로 매우 작습니다. 또한 FPGA에는 있는 SRAM, Adder/Multipler, 복잡한 I/O, 여러가지 hardwired logic이 CPLD에서는 제공되지 않습니다. 따라서 CPLD는 glue logic이나 비교적 간단한 sequential logic 같은 것을 만들 때 사용하면 적당합니다.
CPLD는 FPGA 보다 가격이 매우 싼 편입니다. 그리고 보통은 flash 기반이라서 FPGA 처럼 외부에 program memory chip과 같은 device가 필요가 없고, 일반적으로 필요한 supply voltage의 갯수도 적습니다. 따라서 시스템 BOM cost가 민감한 부분에서도 사용될 수 있습니다. 그리고 CPLD가 FPGA보다는 power 소모가 적으므로 power에 민감한 시스템에서도 사용을 고려해 볼 수 있습니다.

2009년 12월 5일 토요일

FPGA 이야기 - 1

요즘은 회사에서 FPGA 시스템을 설계 하고 있습니다. Chip 만드는 일이 많아야 좋은데, 경기가 좋지 않은지라 chip 만드려고 하는 회사가 별로 없는 것 같습니다.

FPGA에 대해서 살펴봅니다.

FPGA는 Field Programmable Gate Array의 약자입니다. Field Programmable이란 말 그대로 현장에서 프로그래밍이 가능하다는 뜻입니다. 즉, 현장에서 프로그래밍 가능한 Gate Array라고 할 수 있는데, 우선 Gate Array가 무엇인지 알아 봅니다.

  • Gate Array
Gate Array를 이용한 설계는 선사시대의 설계 방법론이라고 할 수 있습니다. 저는 해 본 적이 없고, 아마도 단시일내에 Gate Array를 이용한 설계를 할 일은 없을 것 같습니다. 직접 경험한 바가 아니므로 추측으로 설명을 하자면 다음과 같습니다.

Gate Array는 말 그대로 (digital logic) Gate가 silicon wafer 위에 일정하게 Array 형태를 이루어 분포되어 있는 상태(?) 를 말합니다. 아마도 NAND Gate 혹은 NOR Gate하고 Flipflop이 아마도 Array를 이루고 있을 겁니다. NAND(혹은 NOR) Gate의 연결 만으로 모든 combinational logic을 설계할 수 있으므로 설계자는 단순히 Gate 사이를 metal로 연결을 하여 설계를 완료합니다. 이런 설계 방법론이 대두된 이유는 digital logic IC 설계의 FAB NRE charge가 비싸기 때문입니다.(이것은 선사시대나 지금이나 마찬가지인가 봅니다.) FAB NRE는 대부분은 mask를 만들기 위해서 들어갑니다. Wafer 위에 N형 반도체, P형 반도체, Oxide, Polysilicon, Metal 등을 올리기 위해서는 수십장의 mask를 만들어야 합니다. 하지만 Gate가 모두 놓여진 상태에서 metal 만 연결하기 위해서는 mask가 많이 필요하지 않고, 그에 따라 NRE가 상당히 줄어듭니다.
Gate만 놓여 있는 Wafer를 만들어서 비교적 싼 가격에 공급하는 회사가 있다면, 설계자 입장에서 비교적 싼 가격에 그 Wafer를 사고, metal 연결에 대해서만 NRE를 내고 chip을 생산할 수 있게 됩니다. Gate Array를 이용하는 설계가 많으면 많을 수록 Gate Array Wafer가 많이 팔리게 되므로 Wafer의 가격이 낮아져서 더 많은 설계에 이용되는 선순환이 이루어질 수 있습니다. 반대로 Gate Array를 이용하는 설계가 별로 없다면, Gate Array Wafer가 별로 안팔려 가격이 상승하고, 그로 인해 더욱 Gate Array를 이용한 설계가 줄어드는 악순환이 반복될 수 있습니다. Gate Array가 선사시대의 설계 방법론이 되었고, 그렇다는 것은 그런 선순환보다는 악순환이 발생했다는 의미입니다. 무엇이 문제였을까요?

Gate Array 설계 방법을 쓰면 사용하지 못하는 Gate가 생길 가능성이 큽니다. 또한, NAND(혹은 NOR) Gate 만으로 logic을 설계하면 당연히 서로 다른 gate를 모두 이용하여 설계하는 방법보다 transisitor 갯수(즉 die area)면에서 불리합니다. 결국 die area가 늘어나서 chip 단가가 상승하고, power 소모도 더 많이 할 수 밖에 없습니다.
die area는 그렇다 치고 timing을 맞추는데, 즉 높은 동작 주파수를 달성하는데 어려움이 따를 것 같습니다. Gate의 input이 제한되어 있으므로, combinational logic이 여러 단계를 더 거쳐야할 필요가 있습니다. 그리고 회로에 따라서 metal을 이용하여 routing 하는 것에 또 다른 timing 문제를 발생시킵니다. 예를 들어 combinational logic 출력은 flipflop에 연결하려고 봤더니 flipflop이 먼 곳(가까운 곳에 있는 flipflop은 모두 다른 output을 연결해서 없다고 가정)에 있으면 느려질 수 밖에 없겠습니다. 그리고 보통 일반적인 반도체 설계의 경우 fan-out에 따라서 동일한 동작을 하는 gate가 여러 종류가 있어서 timing을 이용하여 최적화 하게 되는데, Gate Array에서는 그렇게 하기 곤란합니다.
더욱 큰 문제는 chip 내부에 analog 회로를 넣으려고 해도 방법이 없습니다. Analog 회로는 둘째치고 커다란 SRAM을 넣는 것도 참 곤란합니다.

Gate Array 설계 방법론의 다른 문제는 Risk및 비용(NRE)가 줄어들기는 하되 없어지지 않는다는 점입니다. 매우 많이 팔릴만한 chip의 경우 NRE와 Risk를 모두 감수하고 full custom으로 설계하는 것이 chip의 단가를 낮출 수 있어서 유리하고, 매우 소량 팔리는 chip의 경우에는 아래 설명할 FPGA를 이용하는 것이 유리합니다. Gate Array 설계 방법은 그 사이에 끼어 있는 형태인데, 그 사이의 시장이 별로 없었거나 개척하지 못했다는 것이 가장 큰 문제였을 겁니다.

현재 제한된 영역에서는 명맥을 유지하고 있기는 한가 봅니다. ATMEL에서 제공하는 CAP이라는 애가 있는데, Gate Array 인지는 확실하지 않지만, metal programmable한 영역이 일부 들어 있는 ARM chip을 생산해 주는 것으로 보입니다. 사용자는 metal programmable한 영역에 목적에 맞는 특별한 peripheral을 만들어 chip의 나머지인 ARM CPU 및 peripheral과 연동하여 사용할 수 있는 형태로 보입니다.

  • FPGA 란?
FPGA는 위에서 언급한 대로 Field Programmable Gate Array의 약자인데, 한마디로 정의 하면 사용자가 원하는 digital logic을 programming(혹은 configuration)통해 구현할 수 있는 chip입니다. Gate Array 설계 방법론이 metal layer를 설계하여 FAB에서 비교적 싼 chip을 생산하는 방법인 반면, FPGA 설계 방법은 그냥 FPGA 회사에서 나오는 FPGA chip을 board에 실장해 놓고 programming을 하여 사용하는 방법입니다.

FPGA는 NAND/NOR와 같은 단순한 gate를 사용하지 않고, LUT(Look-Up Table)을 이용하여 combinational logic을 구성하고, LUT의 끝에는 flipflop이 있어 sequential logic을 구현할 수 있도록 되어 있습니다. LUT가 chip 안에 Array 형태로 많이 들어있고, LUT 사이의 연결도 programming할 수 있고, chip의 I/O도 사용자가 어느 정도 정할 수 있습니다. 따라서 FPGA로는 모든 digital logic을 구현할 수 있고, interface도 자유로와 다른 chip과의 연결을 쉽게 할 수 있습니다.

FPGA도 Gate Array 방법과 비슷한 단점을 가집니다. 우선 FPGA chip 자체가 상당히 비쌉니다. 물론 내부에 들어 있는 LUT의 갯수에 따라서 가격은 많이 달라지기는 하지만 싸면 수십불에서 비싸면 수천불(Altera Stratix IV는 9천불이 넘는 애들이 있음)까지나 하는 상당히 고가의 chip입니다. 그리고 timing도 일반적인 chip 설계에 비해서 좋을 수 없습니다. 또한 일반적으로 Analog 회로는 들어가 있지 않습니다.

하지만 Gate Array 설계 방법론에 있었던 NRE와 같은 것은 전혀 없습니다. 따라서 Risk가 거의 없다고 봐야 합니다. 또한 설계를 FAB에 보내 chip을 생산하는 것이 아니고, 검증 및 디버깅도 상대적으로 쉽기 때문에 개발 기간이 짧다는 장점이 있습니다.

  • FPGA Vendor
FPGA 시장에는 Xilinx와 Altera라는 두 회사가 막강한데 그 중에 Xilinx가 부동의 1위 자리를 지키고 있습니다. 두 회사가 약 80% 정도의 시장 점유율을 가지고 있다고 합니다. FPGA 뿐 아니라 CPLD(Complex Programmable Logic Device)를 포함한 시장 점유율에서도 비슷한 양상으로 나타나고 있습니다. 그외로 작은 애들이 있는데 actel, lattice 등이 있고, 신생 기업도 여럿 있습니다.

FPGA 시장은 사실 진입하여 성공하기 매우 힘듭니다. 우선 FPGA chip 자체를 잘 만드는 것은 당연하고, FPGA 설계를 위한 Design Software 등을 잘 갖추어야 합니다. 또한 FPGA에서 사용할 수 있는 각종 IP와 design example을 제공해 주어야 하고, 또한 third party 회사들과의 eco-system이 갖추어져야 합니다. 이 모든 것을 완비한다고 하더라도, 대부분의 엔지니어가 새로운 것을 배우는 것을 주저하기 때문에 시장 저항이 있을 수 밖에 없습니다. 따라서 당분간은 Xilinx와 Altera, 두 회사가 계속 시장을 주도할 것으로 보입니다.

저도 Xilinx/Altera의 FPGA를 모두 써 보기는 했으나, 주로 Xilinx에서 나온 제품을 많이 사용하기 때문에 Xilinx의 chip, software가 매우 익숙합니다.

  • FPGA의 응용 분야
FPGA는 Digital 영역 어디에서도 자유롭게 다른 chip과 연결하여 사용할 수 있습니다. 하지만 FPGA가 매우 비싼 만큼 어느 정도 제약이 있습니다.
시스템 회사가 제품을 만들 때는 우선 시장에서 구할 수 있는 비교적 저렴한 chip을 이용하여 구현할 수 있는 것을 모두 구현하는 것이 좋습니다. 하지만 그렇지 못한 경우가 있을 수 있는데, 대부분은 매우 빠른 interface를 가지고 있거나 매우 연산이 많이 필요한 경우로 볼 수 있습니다. 그렇다면 해당 기능을 수행하는 chip을 직접 만들거나 FPGA를 고려할 수 있습니다. 해당 제품이 매우 많이 팔린다면, chip을 직접 만드는 데 필요한 개발비용이 크게 부담이 아니므로 chip을 만드는 편이 좋겠지만, 그렇지 않은 경우에는 FPGA가 정답입니다. 즉, 제품의 시장 규모가 작은 편이라면 FPGA를 사용하는 것이 가격적으로 이득입니다.
시장 규모가 작은 시스템이면서 FPGA가 사용될 수 있을만큼 고가의 시스템은 사실 매우 많습니다. 예를 들어 산업용 시스템이나, 항공, 의료 관련 시스템 등이 쉽게 떠오를 수 있습니다. 보잉이 비행기를 만들어봐야 1년에 몇 대나 만들겠습니까? 참고로 Xilinx 사이트에서는 다음과 같은 응용 분야를 내세우고 있고, Altera가 내세우는 분야와 크게 차이가 없습니다.

- Aerospace/Defense
- Automotive
- Broadcast
- Consumer
- Data process/Storage
- Industrial/Scientific/Medical
- Wired
- Wireless

FPGA vendor 입장에서는 돈이 잘 안되겠지만, 우리 회사에서는 chip prototype을 위해서 FPGA를 사용하기도 합니다. chip을 FAB에 넣기 전에 FPGA를 이용하여 기능을 구현한 다음, 그것을 실제로 돌려 보는 겁니다. 물론 원하는 동작 clock에 비해 늦게 동작을 하지만 simulation이나 기타 다른 방법에 비해 월등히 빠르게 동작합니다. Chip의 설계를 FPGA를 이용하여 검증하는 경우가 꽤나 많이 있습니다.



====
관련 링크
====

Atmel은 FPGA도 만들고, CAP설계를 돕기 위해 ARM subsytem과 FPGA가 같이 들어 있는 chip도 제공함




2009년 10월 31일 토요일

반도체 칩의 가격 구조

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

개발비 요소

 
  • 인건비
사람이 하는 모든 일이 그렇든 칩 설계도 인건비가 상당부분을 차지합니다. 아무리 작은 칩을 개발한다고 하더라도, 적어도 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 정도 됩니다. 따라서 왕창 팔지 않으면 개발비를 뽑을 수 없습니다. 하지만 연간 수백만개~수천만개 정도 팔리면 대박이 되므로, 칩 설계 분야는 규모의 경제가 지배하는 로또 동네입니다.

2009년 10월 11일 일요일

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

2009년 10월 6일 화요일

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

2009년 9월 26일 토요일

OpenSPARC Internals - 2

이번에는 OpenSPARC T2에 대해서 알아볼 차례입니다.

  • 전체적인 구성
T2의 전체적인 구성은 T1과 큰 차이를 보이지는 않습니다. 8 개의 core가 crossbar bus로 8개의 bank로 나누어진 L2 Cache에 연결된 형태를 가지고 있습니다. L2 Cache는 총 4MB이고 16-way set associavity를 가진다고 합니다. L2 cache의 2개의 bank 마다 하나씩 memory controller가 연결되는데 Fully Buffered DIMM을 사용하도록 변경하였습니다.


T1과 다른 점은 우선 공유 FPU가 없어지고, FPU는  각 Core에 들어가게 됩니다. 그리고 10 Gbps Ethernet MAC 2 port와 PCI Express가 내장된 형태를 가지고 있습니다.

  • Core 내부
T1에 비해 Core의 내부가 상당히 많이 변경되었습니다. T2은 Integer Execution Unit 2개와, Float Point Unit 1개, Load Store Unit 1개로 구성됩니다. 기본적으로 8개의 thread를 동시에 exeuction 할 수 있습니다. 8개의 thread를 2개의 group으로 나누어 4개의 thread 중에 하나를 골라 instruction을 issue합니다. 2개의 group이므로 2개의 instruction을 issue할 수 있는 구조를 가지고 있습니다. Integer Execution Unit이 2 개이므로 2개의 integer instruction 조합, 1개의 integer instruction+1개의 floating point insturction, 1 개의 integer instruction + 1 개의 load/store, 1개의 load/store + 1개의 floating point instruction을 issue할 수 있습니다. floating point unit에서 integer multiply와 divide를 처리하므로 그것은 좀 예외적으로 처리됩니다.

Integer pipeline도 8 stage로 변경되어  Fetch/Cache/Pick/Decode/Execute(ALU)/Memory/Bypass/Writeback 순서로 되어 있습니다. Pick Stage가 T1에 있었던 Switch stage에 해당하고, Bypass stage는 Load/Store Unit의 latency가 더 크므로 그것을 보상하기 위해서 들어 있다고 합니다.

16KB 8-way set associative Instruction cache를 가지고 있고, 8KB 4-way set associative write through data cache를 가지고 있습니다. 모두 physically tagged virtually indexed cache로 보입니다. 64 entry fully associative IITLB와 128 entry fully associative DTLB를 따로 가지고 있고, T1과는 다르게 hardware tablewalk를 지원하는 것으로 보입니다.

  • 동작 주파수 및 크기
UltraSPARC T2(코드명 Niagara II)로 발표되었을 당시(2007년)에 65 nm 공정을 사용하고 die size는 342mm^2로 알려졌습니다. 65 nm 공정으로 이동했고, L2 Cache의 크기가 큰 폭으로 증가하지 않았는데도 die area는 크게 줄지 않은 것으로 보아, FPU를 내장한 것이 큰 영향을 주었을 것으로 보입니다. 동작 주파수는 1.4 GHz입니다.

  • 의미
당연히 T1에 비해서 성능 향상이 이루어졌습니다. 우선 64 thread를 지원한다는 강점이 가장 크고, floating point 연산도 8개의 core에서 따로 수행할 수 있으므로 매우 빨라졌습니다. Clock frequency도 높아졌고, 다른 feature(L2 Cache의 size 등)도 좋아졌으므로 single thread performance도 어느 정도 향상되었다고 합니다. T2가 발표될 당시 SPEC 벤치마크에서 integer/floating point 연산 throughput에서 1등을 하였다고 하는데, 상당한 성능을 자랑했던 것으로 보입니다. 당연히 single thread의 performance는 다른 processor에 비해 느렸겠지만 throughput에서는 성능을 낼 수 있는 구조였으므로 가능했겠습니다.

Server에 집중할 거라면 굳이 FPU를 내장해서 Core 사이즈를 늘리지 말고, Core 갯수를 늘리거나 L2 Cache를 늘려서 integer 성능을 더 끌어올리는 방법이 어땠나 싶습니다. 어짜피 FLOPs로 판단하는 슈퍼컴퓨터 동네에서 IBM의 Power 시리즈를 누르기는 힘들었을 텐데 말이죠.

2009년 9월 16일 수요일

OpenSPARC Internals - 1

OpenSPARC에서 공개한 프로세서는 OpenSPARC T1과 OpenSPARC T2 두 종류입니다. 우선 OpenSPARC T1에 대해서 살펴 봅니다.

OpenSPARC T1은 기본적으로 8개의 64bit SPARC core가 내장되고 각 core 별로 4개의 thread를 동시에 실행할 수 있습니다. 따라서 총 32개의 thread(task)를 동시에 실행할 수 있는 구조를 가지고 있습니다.


  • 전체적인 구성

8개의 Core가 Unified Level 2 Cache를 공유하는 형태를 가집니다. L2 Cache는 4개의 bank로 나누어 관리됩니다. 각 Core가 동시에 L2 Cache에 data를 요청하는 경우를 줄이기 위해서 core가 요청하는 address에 따라서 L2 Cache의 4개의 bank 중에 하나가 선택되고 각 bank는 독립적으로 동작합니다. 각 Core와 L2 Cache의 4개의 bank는 on-chip crossbar bus로 연결됩니다. Level 2 Cache는 총 3MB의 12-way set associativity를 가진다고 합니다. DDR2 SDRAM Controller게 CPU에 직접 연결되는데, L2 Cache의 각 bank 마다 하나씩의 DDR2 SDRAM Controller가 연결됩니다.


재미 있는 것은 FPU(Floatingpoint Processing Unit)은 chip 전체에 하나만 있고, 8개의 core가 공유하여 사용합니다.


  • Core 내부

Core 내부는 정말 단순한 구조를 가집니다. 단, 하나의 integer pipeline만 존재하고 기본적으로 single issue입니다. pipeline의 구성은 Fetch/Switch(Thread Select)/Decode/Execute/Memory/Writeback의 6단계인데 Switch를 제외하면 전형적인 5 stage pipeline과 동일합니다(Load/Store Unit은 약간 더 긴 stage를 가진다고 합니다). Switch Stage가 바로 여러개의 thread를 돌릴 수 있게 해 주는 부분입니다. 이 부분의 동작 역시 아주 단순합니다. 4개의 thread에서 각각 읽어온 instruction 4개를 round-robin 형태로 하나씩 뽑아서 pipeline에 issue하는 형태를 가집니다. 단, 특정 thread가 cache miss 등으로 인해 pipeline stall이 발생하거나 latency가 긴 instruction(branch, multiply, load, divide)을 수행하는 경우에 해당 thread의 instruction issue를 멈추고 나머지 thread에서만 issue를 수행하다가 해당 thread의 pipeline stall 조건이 없어지면 다시 그 thread에서도 instruction issue를 수행합니다.


16KB의 Level 1 Instruction cache가 있는데 4개의 thread가 공유하고, 4-way set associative하고 32byte의 cache line size를 가집니다. 4개의 thread가 공유해야 하므로 physically indexed, physically tagged의 형태를 가집니다. 즉, virtual address가 아니라 physical address로 cache를 access한다는 말입니다.


8KB의 Level 1 Data cache를 가지고 있는데, 역시 4개의 thread가 공유하고 4-way set associative하고 16byte의 cache line size를 가집니다. L1 Instruction cache와 마찬가지로 physical address로 access하고 있는 것으로 보입니다. 기본적으로 write-through 형태를 가지고 별도로 각 thread별로 8개의 entry를 가지는 store buffer가 있어서 memory write를 buffering하게 됩니다.


당연히 Intruction TLB와 Data TLB를 각각 따로 사용하고 있고, 64 entry fully associative로 구성되고 4개의 thread가 공유하는 형태를 가집니다.


Branch instruction이 issue 되었을 때 해당 thread의 issue를 멈추는 것으로 보아 복잡한 branch predication은 수행하지 않는 것으로 보입니다.


4개의 thread를 처리할 수 있도록 추가된 하드웨어는 Swtich stage와, 각 thread별로 가지게 되는  PC, instruction buffer, register file, store buffer 정도가 됩니다. 물론 SPARC은 register window라고 하는 독특한 형태의 register file을 사용하므로, 각 thread별 register file의 추가가 어느 정도는 큰 hardware 크기 증가가 일어나기는 합니다만 단순히 multi-core를 통한 thread 늘리기에 비해서는 당연히 큰 증가가 아닐 겁니다.




  • 동작 주파수 및 크기
OpenSPARC T1에 대한 자료는 찾을 수 없고, UltraSPARC T1의 경우 90nm 공정에서 1.2GHz로 동작하는 것으로 알려져 있습니다. 그 때 size는 340 mm^2이다.



  • 의미


우선 T1의 경우 FPU를 8개의 core가 나누어 써야 하므로 scientific calculation이 많은 application에서는 성능이 제대로 나올 수 없습니다. 즉, IBM의 Power 시리즈 처럼 FLOPs로 성능이 측정되는 Super Computer 동네에서는 전혀 쓰일 가능성이 없습니다.


또한, 수행 시간, 즉 latency로 측정할 수 있는 단일 thread의 성능을 높이기 위해서 설계된 processor가 아닙니다. 우선 pipeline이 깊지 않아서 clock frequency가 높지 않습니다. core 하나가 4개의 thread를 round robin issue하는 형태이므로, core에서 4개의 thread가 동시에 동작한다면 1개의 thread를 돌릴 때에 비해 최악의 경우 1/4의 성능을 낼 수 밖에 없는 구조를 가집니다. 따라서 수행 시간이 중요한 system에서는 좋은 성능을 발휘할 수 없습니다. 예를 들어 chip 설계를 위한 EDA tool 등의 경우에도 좋은 성능을 기대할 수 없습니다.



4개의 thread를 round robin으로 issue하는 것이 가지는 의미는, 특정 thread가 cache miss와 같은 pipeline stall이 발생하였을 때에도, 다른 thread의 instruction이 issue가 일어날 수 있으므로 그로 인한 pipeline utilization 증가입니다.


Database와 같은 Server application의 경우에는 cache miss가 일반적인 다른 application에 비해 더 많이 발생한다고 합니다. 이런 cache miss가 많이 발생하고, latency 보다는 throughput이 중요한 system의 경우에서 의미를 가진다고 볼 수 있습니다. 수행 시간, FLOPs 가 의미를 가지는 것이 아니라 TPS(transaction per second)가 의미를 가지는 동네에서 성능을 발휘할 수 있겠습니다.


2009년 9월 6일 일요일

OpenSPARC Internals - 0

사실 OpenSPARC에 대해서 비교적 오래전부터 관심을 가지고 있었지만, 자료를 다운로드 받거나 하면 가입을 해야 하기에 좀 꺼려했습니다. 외국 사이트 가입은 그래도 이것 저것 많이 묻지 않아서 어느 정도 참을 만 하지만 워낙 그런 것들을 싫어하여 꼭 필요하지 않은 사이트면 가입을 하지 않는 결벽증이 있다고나 할까요? 사실 Source Code를 살펴보고 이렇게 하는 것은 아무래도 좀 시간이 걸리는 일이라서 시간적 여유가 있을 때까지는 미뤄둔다는 생각이 있었습니다. 그런데 얼마전에 다시 사이트에 방문해 보니 작년 말에 OpenSPARC Internals 이라는 책이 나왔는데, 국내에서 구하기도 어렵고, 사이트에 가입을 하면 PDF 형태로 책을 공개해 주어서 큰 맘 먹고 가입했습니다. 물론 PDF를 다운로드 받아서 훑어 보았습니다.

사실 OpenSPARC을 살펴 봐야 겠다고 생각한 것은 superscalar processor의 설계에 대해서 잘 모르고 있고, superscalar에 SMT까지 적용한 processor에 관심이 있었기 때문입니다. 하지만 재미 있는 것은 OpenSPARC은 superscalar processor가 아니었습니다.

OpenSPARC에 대해서 말하기에 앞서서 일반적인 processor 설계상 성능을 높이는 방법에 대해서 정리해 볼 필요가 있을 것 같습니다.


- clock frequency 높이기

대부분의 32bit/64bit CPU는 pipeline을 이용하여 이론적으로는 1 clock cycle에 1개의 instruction을 수행할 수 있도록 되어 있습니다. 성능을 높이는 가장 간단한 방법을 clock의 frequency를 높이는 방법입니다. 즉, 1 clock cycle에 처리하는 명령어는 1개로 동일하지만 1 clock cycle이 줄면, 즉 clock frequency가 높아지면 당연히 단위 시간당 처리하는 instruction의 갯수가 증가합니다.

clock frequency를 높이는 가장 단순한 방법은 사용하는 반도체 공정의 개선입니다. 물론 반도체 FAB을 운용하는 사람 입장에서는 FAB의 공정 개선이 상당히 어려운 문제입니다만 processor 설계하는 사람 입장에서는 그것은 "내 알 바 아니다."입니다. 반도체 공정이 0.13 um -> 90 nm -> 65 nm -> 45 nm까지 높아지면서 transistor의 동작 속도는 증가 하므로 clock frequency가 높아지게 됩니다.

Architecture, 정확하게는 micro architecture 상에서 clock frequency를 높이는 방법은 pipeline의 깊이를 깊게 가져가는 방법이 있습니다. 예를 들어 5 stage pipeline에서 7 stage pipeline으로 늘리게 되면 pipeline register(flipflop) 사이에 해야 하는 일, 즉 combinational path가 줄어들므로 clock frequency를 높일 수 있습니다. 하지만 이 경우에는 약간의 부작용이 생깁니다. 기본적으로 pipeline은 control hazard에 취약한데 그것이 pipeline이 깊어지면 더 문제가 되어 그것을 대응할 필요가 있습니다.
Control hazard는 branch instruction 수행에 관계된 문제입니다. Conditional branch(분기) instruction이 들어온 경우, 해당 branch가 조건이 true가 되어 분기가 일어날지, false가 되어 분기가 일어나지 않을지 결정하는데는 pipeline 상에 몇 clock cycle이 필요합니다. 그 사이까지 branch를 뒤따르는 instruction의 수행을 멈추거나 해야 하는데, 이것을 좀 완화하기 위해서 branch prediction(분기 예측)을 사용합니다. 가장 간단한 방법은 branch가 일어나지 않는다고 가정하고 뒤따르는 instruction을 계속 pipeline에 밀어넣은 후에, branch의 조건이 true가 되어 분기가 일어나야 하는 경우 pipeline상에 뒤따르던 instruction을 모두 무효화합니다. 이런 것을 pipline이 bubble로 채워진 상태라고 하는데 이런 것이 pipeline의 효율을 저하시킵니다. pipeline이 깊어지면 당연히 이런 비효율성이 늘어날 가능성이 크고 이를 위해서 좀더 정교한 branch prediction이 필요합니다. conditional branch의 경우 재미 있는 것은, branch가 실제로 분기할 가능성이 더 높다는 점입니다. 이것은 실행되는 branch의 상당수는 loop과 관계가 있기 때문입니다. 또 재미 있는 것은 conditional branch로 인해 분기가 일어났다면 다음에 그 branch instruction을 수행할 때 또 분기할 가능성이 높다는 점입니다. 이것도 역시 loop과 관계가 깊습니다. 따라서 branch가 과거에 분기 했느냐, 아니냐 등의 history를 저장하고 있는 table을 hardware가 가지고 있고 그 table에 따라 branch prediction을 하는 방법을 많이 사용합니다.

물론 pipeline 깊어지면 기타 data hazard를 회피하기 위해서 사용하는 forwarding 등의 방법도 마찬가지로 복잡해지거나 pipeline stall이 증가할 수 있습니다.

- ILP(Instruction Level Parallelism)

1 clock cycle에 하나의 instruction(operation)만 수행하라는 법은 없습니다. 1 clock cycle에 여러개의 operation을 동시에 수행하는 CPU를 만들어도 문제가 되지 않습니다. 이런 방법을 Instruction Level Parallelism이라고 부릅니다.
동시에 여러개의 operation을 수행할 수 있도록 CPU를 만들어야 하므로, operation을 수행하는 Execution Unit(ALU:Arithmetic Logic Unit 이나 Load Store Unit 등)을 여러개 넣어서 그것을 매 clock cycle 충분히 활용하다록 만드는 것입니다. 이런 접근 방법에는 크게 두 가지가 있습니다.

(a) VLIW(Very Long Instruction Word)
VLIW는 단순하게 생각했을 때 여러개의 operation을 하나의 긴 instruction에 넣고 일반적인 CPU가 하듯이 instruction을 매 clock cycle 실행할 수 있도록 하는 방법입니다. 예를 들어 다음과 같은 일반적인 CPU에서 사용하는 instruction sequence를 생각해 봅니다.
instruction 0 : add r0, r1, r2    ; r0 <= r1+r2
instruction 1 : sub r3, r4, r5    ; r3 <= r4+r5

VLIW CPU는 다음과 같은 instruction 하나를 이용할 수 있습니다.

instruction 0 : add r0, r1, r2 || sub r3, r4, r5

instruction 중간에 있는 "||"의 의미는 동시에 수행한다는 의미를 지니고, 위의 예는 instruction 하나에 addition과 subtraction을 동시에 처리하게 됩니다. 당연히 위의 경우에는 CPU 내부에 ALU가 두 개 있어야 합니다. 보통 Instruction을 execution unit에 넣는 일을 issue라고 표현하는데 위의 예제는 dual issue VLIW라고 표현할 수 있습니다. 동일한 clock cycle을 사용하고 매 clock cycle 마다 하나의 instruction을 issue할 수 있다고 하면 두 배의 성능이 날 수 있습니다.
위의 예제처럼 operation의 순서를 정렬하거나 순서를 바꾸는 일을 보통 instruction scheduling이라고 하고, VLIW의 경우 compiler가 compile할 때 scheduling을 통해 operation이 동시에 수행 가능하도록 instruction을 생성하게 됩니다.
문제는 이 instruction scheduling이 정말 어려워서 Compiler가 효율적으로 하지 못하고, 경우에 따라서는 scheduling이 전혀 안될 수도 있습니다. 예를 들어 위의 code sequence가 아래와 같이 조금만 변경되어도 data dependency로 인해 동시에 수행할 수 없습니다.

instruction 0 : add r0, r1, r2
instruction 1 : sub r3, r0, r4

add의 결과를 sub가 사용하기 때문에 동시에 수행할수 없습니다. 따라서 VLIW로 바꾸게 되어도 다음과 같이 변경해야 합니다.

instruction 0 : add r0, r1, r2 || nop
instruction 1 : sub r3, r0, r4 || nop

nop(no operation)이 추가된 instruction 두 개로 바뀌었습니다. 이 경우에는 성능 향상이 있을 수 없습니다.
Compiler를 만드는 동네에서는 Basic Block이라고 하여 operation sequence를 나누는 가장 작은 단위가 있습니다. Block의 끝은 branch이고, Block의 시작이 아닌 중간으로는 branch를 통한 진입이 되지 않는 가장 큰 operation sequence를 Basic Block이라고 합니다.즉 Basic Block 내부에서는 operation의 순서를 마음대로 바꾸어도 프로그램 동작에서는 전혀 이상이 없습니다. 문제는 대부분의 프로그램의 경우 compile을 할 때, 이 basic block 내부에 있는 operation의 갯수가 매우 작아서 instruction scheduling의 여지가 별로 없다는 것입니다.
이렇게 instruction scheduling이 잘 되지 않는 경우 nop(no operation)을 많이 사용할 수 밖에 없고, 그렇게 되면 code size가 증가하게 됩니다. code size가 증가한다는 것은 embedded system의 경우는 memory를 더 많이 요구한다는 것이고, 그 뿐 아니라 instruction cache의 효율성이 떨어진다는 것이므로 그로 인해 성능저하가 올 수 있습니다. 따라서 대부분의 경우는 nop이 적은 bit로 coding 될 수 있도록 instruction encoding을 하게 되는데 이 경우에는 또 instruction decoding 과정이 복잡해지는 단점이 생기게 됩니다.

또 VLIW로의 접근은 동일한 ISA(Instruction Set Architecture)를 기반으로 성능을 확장하는 것이 아닌 새로운 ISA를 정의하는 것입니다. 일반적으로 binary 하위 호환성이 있을 수 없습니다.
일반적인(?) CPU 시장에서 VLIW가 사용된 예가 있는데 그것이 바로 Intel과 HP가 공동으로 설계한 Itanium(IA-64, x86-64가 아님) 64bit Processor입니다. Intel과 HP는 VLIW라는 말을 사용하지 않고 EPIC(Explicit Parallel Instruction Computing)이라는 용어를 사용했는데 기본 개념은 비슷합니다. 90년대말 Itanium이 한창 개발될 때만 해도, Intel이 개발하는 첫번째 64bit processor로 성능이 매우 우수할 것으로 각광을 받으며 Server 업계를 평정할 것으로 예상했습니다만, 결과는 그다지 좋지 않았습니다. 역시 x86 binary 호환성이 문제가 되었다고들 합니다. 그사이 경쟁자들도 성능이 좋은 64bit CPU를 개발했고, x86 조차 AMD가 내놓은 Opteron으로 64bit에 진입했으므로 지금은 더욱 설자리가 줄었다고 해야겠습니다. 아직까지 명맥은 유지하고 있는 것으로 보아 적어도 특정 몇몇 분야에서는 성능이 괜찮은지도 모르겠습니다.
여러가지 이유로 인해 VLIW는 DSP(Digital Signal Processor)에 많이 사용됩니다. 일반적으로 팔리는 DSP 뿐 아니라, 여러 회사가 자체 VLIW CPU를 만들어 video processing 등에 사용하는 경우가 많습니다. 일반적으로 팔리는 VLIW DSP중에 대표적인 TI C64x+ 같은 경우 8개의 operation을 동시에 처리할 수 있는 8 issue VLIW processor입니다. DSP의 경우는 기본적으로 compiler를 많이 사용하지 않고 일명 손파일러, 즉 assembly coding을 주로 사용하게 됩니다. 적어도 성능이 많이 요구되는 core routine은 손파일러를 동원하게 됩니다. 손파일러를 사용하는 경우에는 여러개의 operation을 동시에 수행가능하도록 사람이 scheduling을 잘 하면 성능이 높게 나올 수 있습니다. 이 때는 보통 loop unroll이나 software pipeline 등의 방법을 이용하여 operation이 동시에 수행되는데 유리하도록 변경하는 과정을 거치게 됩니다. loop unroll 등은 compiler 등에서도 수행하고 있는데 숙련된 프로그래머의 손파일러가 역시 성능이 좋습니다.

(b) superscalar

VLIW가 instruction scheduling을 compile할 때 했다면 superscalar는 scheduling을 run time에 CPU가 직접하는 방법입니다. CPU가 다음에 수행할 하나의 instruction만 바라보고 있는 것이 아니라 여러개의 instruction을 큐에 담아서 살펴보고 있다가, 동시에 수행가능한 instruction을 찾아서 한꺼번에 issue하게 됩니다. 당연히 execution unit이 여러개 있고, 동시에 issue 될 수 있는 instruction의 갯수가 4 라면 4 way superscalar 라고 부릅니다.

기본적으로 in-order issue 방법이 있는데 이 경우에는 instruction의 순서에 맞추어 issue가 됩니다. 4 way superscalar의 경우라면 4 개의 instruction을 동시에 살펴봐서 앞에서 부터 문제가 없는한 많은 instruction을 동시에 issue하는 방법을 사용합니다. 순서대로 issue를 하게 되면 data dependency 등으로 인해, 여러개의 instruction을 동시에 issue할 수 없는 가능성이 커지게 됩니다.이것을 극복하기 위해서 out-of-order issue를 사용하기도 합니다.이 경우에는 issue할 수 있는 instruction의 갯수보다 더 많은 instruction을 살펴봐서 그 중에 dependency가 없는 것을 무조건 골라서 issue를 합니다. out-of-order issue의 경우에는 instruction의 순서대로 실행되지 않을 수 있습니다. 그런데 software 개발자 입장에서는 instruction이 순서대로 수행된다고 가정하고 프로그램을 만들었기 때문에 그것을 유지해 주어야 합니다. 그렇게 하기 위해서 pipeline의 끝에서 execution이 끝난 instruction이 적어도 프로그래머가 보기에 순서대로 수행되었다고 느낄 수 있게 끔 순서를 맞추는 과정이 필요합니다. 예를 들어 register 등의 update는 instruction의 순서에 맞추어 일어나도록 하는 과정이 있어야 프로그래머가 의도한 대로 프로그램이 수행된다고 느끼게 됩니다.

VLIW에 비해 superscalar가 가지는 장점은 우선 ISA의 변화가 없이 구현 가능하기 때문에 호환성을 유지해 줄 수 있다는 점입니다. 또한 성능적으로는 scheduling이 run-time이 일어나므로 schedule 되어 동시에 수행할 수 있는 가능성이 커집니다. VLIW는 basic block이라는 단위에서만 schedule을 할 수 밖에 없는데, superscalar의 경우 branch prediction 등을 통해 branch 후에 수행할 instruction 도 큐에 넣고 execution을 하는 방법 등을 통해 효율성을 높일 수 있습니다.

당연히 단점이 존재하는데, VLIW processor에 비해 hardware가 훨씬 복잡해 질 수 밖에 없습니다. CPU 내부에는 instruction que와 scheduling을 위해 instruction간 dependency를 detect할 수 있는 hardware가 존재해야 하므로 복잡도가 많이 증가합니다. 그러한 복잡도는 clock frequency를 높이는데 제약으로 작용할 가능성이 큽니다. 뿐만 아니라 out-of-order issue의 경우 exception 같은 event 상황을 대처하기가 어렵기 때문에 이것을 해결하기 위해서도 hardware가 상당히 더 들어가야 합니다.

Embedded processor로 많이 사용되는 ARM도 Coretex-A8이라는 core부터는 dual in-order issue superscalar 구조를 가지고 있습니다. embedded processor이므로 power budget이 desktop CPU나 server CPU에 비해 적으므로 상대적으로 간단하게 만들기 위해서 dual in-order issue 구조를 가지도록 하지 않았나 싶습니다.

참고로 superscalar processor에서도 프로그램을 compile할 때 compiler가 어느 정도의 instruction scheduling을 하게 됩니다. CPU가 동시에 수행하기 쉽도록 instruction scheduling을 해 주는데 당연히 VLIW 만큼 큰 제약을 가지지는 않습니다. 또한 VLIW processor용 compiler의 경우에는 speculation execution이라고 하여 basic block 단위를 넘는 instruction scheduling을 시도하는 경우도 있는 것으로 알고 있습니다.


- TLP(Thread Level Parallelism)

Pipeline을 더 깊게 만들어서 clock frequency를 아무리 높인다고 하더라도 pipeline의 data hazard나 control hazard 등으로 인해 효율성의 증가를 꾀하기 힘듭니다. 더욱 큰 문제는 cache miss로 인해 memory에서 data를 read하는데 걸리는 latency는 clock frequency가 증가하면 상대적으로 더 커지게 되는 문제가 있습니다. 또한 Clock frequency가 높아지면 그에 따른 power 소모가 증가하여 문제가 됩니다. Superscalar를 통한 ILP 접근 방법도 Instruction간의 dependency와 cache miss 등으로 인해 execution unit을 아무리 많이 넣어도 그에 따른 성능 향상을 기대하기 힘든 수준까지 도달한 것으로 보입니다. 이것을 극복하기 위해서 TLP(Thread Level Parallelism)이라는 별로 참신하지는 않지만 새로운 개념이 등장하였습니다.

대부분의 시스템이 multi-tasking OS를 기반으로 하고 있으므로 task를 동시에 여러개 돌릴 수 있도록 하는 것이 TLP의 핵심입니다. 당연히 단일 task(thread)가 동작하는데 걸리는 시간은 줄지 않습니다. 다만 여러개의 thread가 동시에 동작할 수 있으므로 전체적인 throughput이 향상이 됩니다. TLP도 역시 두 가지 approach가 있습니다.

(a) multi-core

정말 단순한 방법인데 CPU Core 여러개를 단일 chip에 넣는 것입니다. 서버에서는 CPU를 여러개 system에 넣어서 성능을 높이는 방법이 일반화 되어 있고, 반도체 공정이 미세화되면서 die area의 여유가 더 생겼기 때문에 가능한 일입니다. 제가 집에서 사용하는 PC도 AMD에서 만든 dual core CPU를 사용하고 있습니다. OS가 알아서 dual core에 적절히 task를 나누어 돌려 줍니다. 물론 dual core를 모두 활용할 필요가 없는 경우에는 성능 향상을 기대할 수 없습니다.

사실 단순히 CPU Core만 여러개 넣는다고 해서 multi-core가 되지 않습니다. Cache coherence 문제가 있기 때문입니다. CPU Core 마다 적어도 Level 1 Cache는 따로 가지는 것이 일반적입니다. 문제는 각 Core에 들어 있는 Cache에 동일한 address에 해당하는 memory 내용이 들어 있을 수 있는데, 이 내용이 Core 마다 다르면 커다란 문제가 생기게 됩니다. 특정 core가 memory write를 수행했는데 그것이 cache hit였고, 해당 memory 영역이 다른 core의 cache에 이미 존재하면 두 core 사이에 cache, 즉 memory의 내용이 달라지는 문제가 생깁니다. 이것을 해결하기 위해서 보통은 cache snooping이라는 방법을 사용해야 합니다. snoop이라는 영어 단어는 "기웃거리다"라는 뜻이라고 합니다. Cache snooping 방법은 다른 core의 cache update를 기웃거리며 살펴보고 그것을 통해서 cache를 스스로 update하는 방법입니다. 직접 구현해 본 바가 없어서 아주 구체적인 방법은 모르겠습니다.

(b) SMT(Simultaneous Multi-Threading)

SMT는 단일 CPU core에서 multi-threading을 구현하는 방법입니다. SMT는 크게 두 가지 문제를 해결하기 위해서 등장했습니다.

첫번째 memory latency 문제입니다. 기본적으로 CPU가 cache miss일 때 memory에서 data를 cache로 load해야 하는데 이 때 걸리는 시간이 매우 길다는 문제가 있습니다. 시스템의 main memory로 주로 사용되는 SDRAM(DDR, DDR1, DDR2 포함)은 latency가 매우 큰 memory입니다. SDRAM을 read하기 위해서는 row activation을 수행하고, RAS-to-CAS delay 후에 read command를 보내고 다시 CAS latency 만큼 기다려야 data가 나오게 됩니다. read 후에 다음의 read 사이에 또 precharge라는 것을 해야 하고 그것 또한 latency를 가지는데, 그것을 제외해도 상당한 latency를 가지고 있습니다. 예를 들어 삼성전자에서 나오는 일반적인 DDR2-800(pin당 800 Mbps 전송) SDRAM의 경우 RAS-to-CAS delay가 6 clock cycle(400MHz 기준), CAS Latency가 6 clock cycle(400MHz 기준) 정도입니다. 만약 CPU가 2GHz로 동작한다면 400MHz 기준 12 clock cycle이 2GHz에서는 60 clock cycle이 됩니다. 더욱 문제를 어렵게 하는 것은 SDRAM에서 data를 read/write하는 것이 CPU만이 아니라는 점입니다. 다른 peripheral이 SDRAM에 data를 read/write하고 있는 중이라면 훨씬 더 오래 걸립니다. CPU가 data를 요청했는데 cache miss 때문에 SDRAM에서 data를 읽어와야 한다면 그 사이 CPU는 더 이상 instruction을 수행하지 못하고 기다려야 하고 그에 따른 performance loss가 일어납니다.

Cache miss를 인해 CPU가 instruction을 수행할 수 없는 경우, thread를 바꾸어 다른 thread의 instruction을 그 기간 동안 처리한다면 CPU 성능의 낭비를 줄일 수 있습니다. 그런데 Cache miss가 났을 때, 그것을 OS에 알리고 OS가 thread(task) switching을 하게 한다면 배보다 배꼽이 더 크게 됩니다. OS가 task switching을 하기 위해서는 많은 instruction을 수행해야 하므로 cache miss를 처리하는 시간 보다 task switching을 하는데 걸리는 시간이 더 크기 때문입니다. 따라서 CPU 내부에 여러개의 thread context(PC, register, Virtual Address 관련 부분)을 모두 가지고 있다가 cache miss의 경우 hardware적으로 thread context를 전환하도록 해야 합니다.

두번째는 superscalar processor의 경우 instruction dependency 문제로 인해 instruction level parallelism을 충분히 활용할 수 없는 문제입니다.
아주 특수한 instruction을 제외하고는 서로 다른 thread의 instruction들 사이에는 dependency가 전혀 없습니다. 따라서 여러개의 thread에서 수행해야 하는 instruction을 동시에 보고 있으면 instruction dependency로 인해 issue를 못하게 될 확률이 줄어들게 됩니다. Intel은 이 방법을 활용하며 이름을 "Hyper Threading"이라고 하였습니다. 기억에 따르면 Pentium4 중 Code명 Northwood 부터 도입 되었는데, Core 시리즈(Core, Core2Duo, Core2Quad 등)에서 그 기능을 뺐다가 최근에 나온 i7부터 다시 도입되었습니다. Intel은 Core당 2개의 thread를 동시에 수행하는 구조를 가지고 있습니다. i7의 경우 Core가 4개이므로 총 8개의 thread를 동시에 실행할 수 있습니다.

SMT가 multi-core에 비해 지니는 장점은 하드웨어 추가가 적다는 점입니다. thread 갯수를 늘리기 위해서 multi-core는 thread 갯수에 정확하게 비례하는 hardware 추가가 필요하지만 SMT는 그렇지 않습니다. 하드웨어가 더 가져야 하는 것은 thread별로 context data(PC, General Purpose Register, Virtual Address 관련 부분 등) 정도만 있으면 되고, control logic이 약간 더 복잡해 지는 수준입니다. 나머지 부분, 즉 exeuction unit, cache 등은 thread 모두가 공유하는 구조를 가집니다. 대신 SMT를 통한 multi-thread는 multi-core 방법에 비해 성능 개선 폭이 작을 가능성이 큽니다. 즉, hardware 투입 대비 효율이 좋은 것이지 더 좋은 성능을 보증하지는 않습니다.

SMT와 multi-core는 서로 배제되는 방법이 아니기 때문에, Intel의 i7처럼 동시에 두 기술을 사용할 수도 있습니다.


SIMD(Single Instruction Multiple Data)를 빼 놓을 뻔 했습니다. SIMD를 통한 성능 향상은 위에서 언급한 방법과는 전혀 다릅니다. CPU에서 video나 audio 처리를 해야 하는 경우가 많아졌는데, 예를 들어 video 처리의 경우 8bit 혹은 16bit 단위의 data를 주로 사용합니다. 32bit CPU는 32bit Adder가 들어 있고 1 clock cycle에 32bit adding을 처리할 수 있습니다. 그런데 일반적인 프로그램에서 8bit(unsigned char) adding을 4번 하면, 32bit adder를 사용하더라도 4 clock cycle이 걸립니다. 재미 있는 것은 이미 32bit adder는 8bit adder 4개로 이루어져 있는 셈인데, 8bit adding 4번을 한번에 32bit adder로 처리할 수 있도록 하드웨어를 바꾸는 것은 매우 쉽습니다. 따라서 이렇게 하드웨어를 변경하고, 기존의 일반 add instruction 과는 다른 instruction을 추가하면 8bit adding 4번을 1 clock cycle에 처리할 수 있게 됩니다. 이런 방법을 사용한 대표적인 예는 Intel MMX/MMXEXT/SSE 등입니다. 예를 들어 Intel MMX의 경우 64 bit integer data를 하나의 instruction으로 처리합니다. 64bit integer data는 32bit integer 두개, 16bit integer 4개, 혹은 8bit integer 8개의 형태가 될 수 있습니다. x86을 제외한 다른 architecture에도 VIS니 Altivec이니 하는 SIMD instruction이 있습니다.

이번 글도 너무 길어져서 OpenSPARC에 관한 이야기는 다음으로 미루어야 겠습니다.