트랜지스터의 구조

 

 

면적은 게이트장에 비례하는 것으로 게이트를 짧게 하면 콘덴서의 용량이 줄어들고 결과적으로 구동 전류가 줄어드는 현상이 생긴다. 더 높은 K(비유 전율)을 가진 High-K 재료가 갑자기 발견되면 문제가 없겠지만 현재 40 가까운 값의 K도 10년 이상 연구를 거듭하여 가까스로 발견한 것이기 때문에 이를 넘는 재료의 발견은 그리 쉽지 않다.

 

이런 문제를 해결할 수 있도록 고안된 것이 3차원 트랜지스터다. 인텔은 "트라이게이트 트랜지스터"라고 부르는데 일반적으로는 핀펫(FinFET)이라 불리는 경우가 많다.

 

아이비 브릿지 발매 기념 이벤트에서 전시된 트라이 게이트 트랜지스터를 소개한 모형

 

 

원래 핀펫이라는 구조를 고안한 것은 히타치며 1989년에 IEDM이라는 학회에서 처음으로 이 구조를 제안했다.

 

참고로 당시는 핀펫이 아닌 DELTA라는 명칭이었다. DELTA란 "a fully DEpleted Lean channel TrAnsistor"에서 따왔다. 위의 논문 제목은 "Impact of the vertical SOI`DELTA'structure on planar device technology"며 원래는 SOI용 구조로서 생각된 것이다.

 

실제로 핀펫은 원리적으로 SOI와 궁합이 좋지만 SOI와 관련된 이야기는 다음에 설명하기로 한다.

이 DELTA의 영향으로 다양한 반도체 메이커나 파운드리가 3차원 구조의 트랜지스터로 눈을 돌리게 됐다. 1990년대 후반~2000년에 걸쳐 많은 업체가 3차원 구조 트랜지스터에 관심을 갖기 시작했다.

 

평면형 트랜지스터(왼쪽)과 트라이게이트 트랜지스터의 전류가 흐르는 경로 이미지. 노란 색이 전류를 나타낸다

 

 

인텔도 2002년의 IDF 기조 강연에서 트라이게이트 트랜지스터를 발표했다. 이 시기는 CPU 동작 주파수를 10 ~ 20GHz를 전망하던 시기며 이를 실현하기 위해서는 트랜지스터의 동작 주파수 자체는 더 고속으로 움직이지 않으면 안됐다. 

 

1개의 4출력 게이트는 NOP가 2개분(실제로는 5개지만 4개는 병렬로 나란히 있는 것으로 직렬 방향으로는 2개가 된다)이며 NOP는 1개의 트랜지스터로 구성된다(이것도 최저 2개지만 병렬이므로 레이턴시라는 관점에서는 1개 상당)이라고 합하면 20개의 트랜지스터가 직렬로 연결된 형태다.

 

만약 동작 클럭이 10GHz로 움직이려고 하면 트랜지스터 1개당 200GHz로 동작하지 않으면 않된다. FO4가 10이라는 것은 파이프 라인이 상당히 깊어진 구성으로, 반대로 FO4가 30정도에서도 10GHz 동작이 가능하도록 설계한 경우 트랜지스터는 600GHz에서 동작할 수 있는 것이 필요하다.

 

이러한 점을 감안하고 인텔은 1THz에서 동작하는 "테라헤르츠 트랜지스터"에 관한 기술 개발을 2001년 11월에 발표하고 있다.

 

테라헤르츠 트랜지스터의 구조와 장점

 

 

이 기사에도 있듯이 당시는 2007년에 20GHz 라는 무서운 구동 속도를 실현하는 것을 전망하여 1THz의 구동 성능은 필수였다.

 

설명을 다시 트라이게이트로 되돌리면 테라헤르츠 트랜지스터를 기존의 평면 구조로 구성하면 아무래도 어려운 요소가 있었는데 그것은 실리콘 층의 두께를 제어하는 문제다. 그 문제를 해결하는 것이 2002년 발표된 트라이게이트 트랜지스터 구조다.

 

실리콘 층의 두께를 제어하는 문제는 그 후 90nm 과정에서 표면화 된다. 이 때는 멋지게 두께 자체는 제어할 수 있었지만 그것에 따른 문제를 해결할 수는 없었다
게이트와 소스/드레인이 교차하는 부분의 그림

 

 

먼저 이 당시는 인텔 이외에도 많은 벤더가 3D 구조에 도전했다는 이야기는 말한 그대로지만, 실은 AMD는 이 발표의 2일 전에 더블 게이트 트랜지스터라고 하는 구조를 발표했다.

AMD는 인텔보다 위에 노출되는 부분을 줄이고 좌우만을 형성하는 구조다. 인텔은 더블 게이트보다 자사의 트라이 게이트 구조가 효율이 더 좋다고 설명했다.

 

트라이 게이트의 이점. 높이와 두께에 비례하여 트라이 게이트에서는 채널장이 많지만 더블 게이트는 두께 부분에 게이트가 없는 만큼 길이가 줄어든다는 것을 나타낸다.

 

 

구체적으로는 트라이 게이트의 경우는 두께를 비교적 크게 해도 동작하지만 더블 게이트는 얇게 하지 않으면 안 되는 것이 단점이라고 지적했다.

 

트라이 게이트의 구조. 그림은 비유며 높이와 두께가 동일할 필요는 없다. 요컨대 두께를 비교적 크게 잡는 것이 이득이라는 것 더블 게이트의 경우 두께를 얇게 하지 않으면 효과가 나쁘고, 얇게 만드는 것이 제조적으로 어려운 것이 흠

 

 

이야기를 다시 3D구조로 돌아오면 3D 구조 방식의 메리트는 복수의 FET 병렬 구조를 간단하게 만들기 쉽다 라는 점이 꼽힌다. 게이트가 공통이므로 다른 회로를 구성할 수는 없지만 반대로 많은 출력이 필요한 경우에는 특성이 가지런한 멀티 채널 드라이버 구성이 가능하다는 것이다.

 

3D 구조 방식의 장점. 높은 출력이 필요한 경우 일반적으로 트랜지스터를 병렬로 다수 늘어놓지만 3D 구조에서는 이것을 정리해 만들기가 쉽다

 

 

여기까지는 2002년 시점의 내용으로 트랜지스터도 어디까지나 실험실 레벨에서 제조에 성공했다는 이야기였다. 이를 실제 22나노 프로세스를 적용해 공개한 것은 2011년 5월 인텔이다.

 

이 때 인텔은 꽤 대대적으로 설명회를 진행했다. 개인적으로는 아래 영상의 3분 10초 이후를 보면 기존 평면형과 트라이 게이트의 차이를 가장 알기 쉽게 이해할 수 있다고 생각한다.

 

 

그런데 22나노 구현의 기본적인 부분은 지금까지와 다르지 않다. 베이스가 되는 것은 32나노 세대의 P1268이다. 이것은 HKMG와 파행 실리콘의 구성으로 게이트장은 18나노였다. P1268을 그대로 미세화하면 22나노 세대에서는 게이트장이 12나노 정도다.

 

22나노 세대는 게이트장이 12나노 정도. 본 기사의 처음에 게재한 트랜지스터의 구조 그림은 이 구조를 옆에서 본 형태

 

 

그런데 여기서 소스 ⇔ 드레인 사이를 3차원화 하면 게이트장 자체는 12나노에서 변하지 않으며 High-K막에서 보호된 절연 부분의 면적을 크게 하여 실질적인 면적을 늘릴 수 있다.

이 구조에서 동작 종료시 공핍층이라 불리는 영역이 거의 완전히 차단되는 것도 핀펫의 특징이다. 핀펫에서는 공핍층을 막는 것으로 보다 고속 동작이 가능하다. 실제로 수치로 나타낸 것이 아래 그래프.

 

게이트 전압과 흐르는 전류의 관계를 정리한 것

 

 

구체적으로 32나노(P1268)와 22나노 및 P1270(22나노의 테스트 게이트)를 비교했을 경우, 같은 동작 전압이면 게이트 지연을 18~37% 절감할 수 있고, 반대로 같은 정도의 지연이면 동작 전압을 0.2V 절감할 수 있다.

 

1V를 0.8V로 줄이면 소비 전력은 전압의 2제곱에 비례하기 때문에 그것만으로 0.6배 정도 된다. 이것이 더 개발되면서 동작시 소비 전력이 50% 절감된다

 

 

이 트라이 게이트 트랜지스터는 22나노부터 인텔만 사용하고 있는 기본적인 구성이다. 인텔은 22나노 세대에서 크게 4종류의 프로세스를 제공하고 있으며 트랜지스터만 봐도 HP(High Performance)/SP(Standard Performance/Power)/UP(Low Power)의 3종류가 제공된다.

 

인텔은 22나노 세대에서 크게 4종류의 프로세스를 제공했다. 주된 차이는 배선층 밀도지만 물론 밖으로도 많은 차이는 있다

 

인텔은 세부적인 부분을 말하지 않지만 현재 핀펫의 구조 자체를 크게 바꾸지 않고 14나노 세대에도 계속 제공해 나간다. 

 

기존에는 채널장을 세세하게 조정하고 특성을 바꿀 수 있었지만(왼쪽), 핀펫 세대에서는 불가능하다 인텔 이외의 파운드리들은 채널장을 바꿀 수 없기에 특성을 조정한다

 

 

보도 - http://ascii.jp

반응형
Posted by 랩터 인터내셔널

Chris Evans
09.28.2009
www.nextreme.co.kr
 

 

데이터센터 통합과 비용절감은 엔터프라이즈 데이터 스토리지 환경에서 가상서버 기술의 지속적인 도입을 가져왔다.  주요 벤더 Microsoft, VMWARE, Xen들 모두 DAS와  NAS 그리고 SAN을 사용할 수 있도록 지원하고 있다. 이 글은 가상 환경에서 어떤 데이터 스토리지 기술이 적합한가를 결정하는 방법을 제공한다.

 

Direct-attached storage

 

DAS 스토리지는 여러가지 형태로 도입될 수 있다; 서버 섀시에 직접 붙어 있는 디스크, 또는 서버의 내부 버스에 SCSI/SAS 카드로 직접 연결된   외장 스토리지 엔클로져. DAS에 대한 장단점은 아래와 같다.

  • DAS는 NAS나 SAN보다 더 저렴하다. 서버내에 직접 연결된다면, 비용은 하드 드라이브 구입하는 것처럼 간단할 수 있다. 최근 최대 용량은 2TB이다.
  • DAS는 공유가 되지 않는다. DAS는 그것이 연결된 서버에서만 사용된다. 이런 이유로 다른 서버 와 쉽게 공유될 수 없다. 특히 서버섀시안에 직접 연결되어 있는 하드 드라이브라면.  이런 제한된 공유는 스토리지가 공유되지 않으면 동작하지 않는 VMware의 VMotion같은 특성을 통해 자체복원을 제공하기 위해  물리적인 서버들이 스토리지로 클러스터 되어 있는  매우 큰 가상 서버 환경에서 심각한 약점일 수 있다.
  • DAS는 확장성이 없다. 확장성은 서버부분으로 제한된다. 첫째, 엔클로져 자체는 보통 크기에  제한적일 것이고 그러므로 스토리지 용량이 제한적인다. 둘째, 서버내 연결성은 SCSI나 SAS 카드를 장착할 수 있는 확장슬롯 수에  의해 제한된다. 
  • DAS는 NAS나 SAN 솔루션의 성능을 갖지 못한다. 성능은 높은 스루풋 가상서버 환경에서 제공하는데 중요한 요소이다.
  •  DAS는 원격 복제나 스냅샷같은 진보된 기능을 제공하지 못한다. 이 기능들이 있으면 좋을 지모르지만 가상서버환경에서 불 필요할 수 도 있다.

DAS 스토리지가 NAS나 SAN보다 더 좋은 솔루션일 때는 언제인가? 확실한 것은 비용이다. DAS는 가장 좋은 가격을 제공한다. 가상환경에서  원격복제나 높은 성능, 확장성이 필요하지 않다면 DAS를 고려할 수 있다.  단 하나의 물리적인 서버만 사용한다면  내부 레이드카드를 사용하는 DAS가 가장 좋은 솔루션일 수 있다.

 

Network-attached storage

 

NAS는  TCP/IP 연결을 통해 가상서버에 연결성을 제공한다. 그리고 스토리지 억세스는  파일레벨로 제공된다. NAS의 장단점은:

  • NAS는 공유가 된다. NAS는 여러  ESX 도입에 의해 공유될 수 있다. 이것은 클러스터된 가상환경과 VMotion같은 특성을 사용할 때 유용하다.
  • NAS는 용량과 성능에서 확장할 수 있다. 큰 가상환경에서 성능은 큰 이슈가 된다. 작은 수의 LUN에 I/O의 집중은 병목현상을 일으킬 가능성이 있다. 이것은 NAS의 진보된 기능이다.
  • NAS는 신-프로비저닝, 리플리케이션과 스냅샷같은 진보된 기능을 제공한다. 많은 가상환경에서 이 기능들은 부분적으로 유용하다. 신-프로지져닝은  가상 호스트들에게 제공되는 실 스토리지의 양을 제한하기위해 사용될 수 있다. 스냅샷은 가상머신 이미지들을 데이터 백업을 위해 캡쳐되거나  여러 가상 이미지가 하나의 "골드-마스터"이미지로 부터 만들어질 수 있는 클론을 위해 사용될수 있게 한다. 신-프로지져닝과 스냅샷의 조합은 매우 작은 스토리지 비용으로 수많은 가상 머신을 만들 기회를 제공한다. 이것은  개발이나 온-디맨드 환경에 대해 극히 효과적인 프로지져닝 방법이다.
  • NAS는 서버로부터 스토리지 관리를 분리한다. 이것은 가상머신 이미지가 파일 시스템으로서 관리될 수 있다는 뜻이다.
  • NAS는 비용이 많이 들 수 있다.  비용에도 불구하고, 시장에서 NAS장비의 범위는 몇개의 디스크만 사용한 작은 것부터 수 페타바이트 하드웨어 구성까지 극히 넓다. 

 

 

Storage area networks in a virtual environment

 

SAN은  파이버채널이나 iSCSI 프로토콜을 사용하여 가상서버에 연결성을 제공한다. SAN의 장단점은 아래와 같다.

  • SAN스토리지는 공유가 된다. 여러 가상 서버 하드웨어장비간에 쉽게 공유될 수 있다. 이것은 클러스터된 가상서버 환경에서 중요하다.
  • SAN은 용량과 성능에서 확장성이 높다. 매우 많은 가상 서버 도입시 확장성은 극히 중요하다. 그리고 SAN의 대 전제는 높은 확장성 제공이다.
  • SAN스토리지는 실시간 복제를 제공한다. 실시간 복제는 대체적으로 NAS에서는 사용할 수 업없다. 그리고 많은 환경에서 이것은 재해 복구 정책에 대해 요구되는 핵심일 수 있다.
  • SAN환경은 매우 탄력적이다. SAN환경은 이중 패브릭, HBA 그리고 고가용성의 스토리지 어레이로 잘 갖추어 진다.

어떤 타입의 스토리지가  환경에 더 적합한가?

모든 사람은 그들의 가상환경에 대해 서로 다른 필요한 것과 요구사항을 가지고 있다. 만약 비용이 이슈이고 가상환경이 작으며 데이터 리플리케이션같은 진보된 기능을 요구하지 않는다면 DAS를 선택하고,  대형 가상환경이라면 NAS나 SAN을 선택한다. 만일  많은 수의 가상호스트를 만든다면 NAS가 더 좋은 선택이고 더 높은 가용성과 확장성을 요구한다면 SAN이 더 좋다. 어떤 플랫폼을 선택하든지 미래에는 IT를 도입시 가상서버가 주요부분을 차지할 것이다.

 

반응형
Posted by 랩터 인터내셔널

 

 

 

- 크기 : 바이트 (실제값 설명)
* Ethernet header : 14

    - 목적지 MAC 주소 : 6
    - 출발지 MAC 주소 : 6
    - 타입 : 2 (0x0800=이더넷)
    - 데이터 : 46~1500 (IP Header + TCP 헤더 + TCP 데이터 )
    - Checksum(CRC) : 4

 

//===========================================================
* IP Header

pak-2-ipv4_packet_header.jpg

    - 버전 : 4bits (4 = IPv4, 12=IPv6)
    - 헤더 길이, IHL(Internet Header Length) : 4bits
        - 4바이트 단위, 5 = (5 x 4 = 20bytes )
    - Type of Service(TOS) : 1 (0, 전송우선순위 등의 정보)
    - 전체 길이 : 2 ('이더넷 헤더'를 제외한 전체 패킷의 길이, 최대길이=2^16=65536)
    - ID : 2 ( 패킷 ID, 단편화시 활용)
    - Flags : 2 (단편화관련 정보)
        - 예비: 1bit ( 항상 0 )
        - DF  : 1bit ( 0 = 단편화되었음, 1 = 단편화되지 않았음 )
        - MF  : 1bit ( 0 = 마지막 단편화 데이타, 1 = 단편화 데이타 더 있음 )
        - Fragment offset : 13bits ( 원래 데이타에서의 offset )
    - TTL(Time to Live) : 1 (차후 경유할수 있는 라우터 수의 한계)
    - Protocol : 1 (6=TCP, 0x11=UDP, 0x01=ICMP)
        http://en.wikipedia.org/wiki/List_of_IP_protocol_numbers
    - Checksum : 2 (헤더의 에러 체크용)
    - 출발지 IP 주소 : 4
    - 목적지 IP 주소 : 4
    - 옵션 : 0 ~40

 

//===========================================================

* TCP Header

pak-3-tcp_header.png

    - 출발지 포트 번호 : 2
    - 도착지 포트 번호 : 2
    - Sequence number(순번) : 4 (전송된 순서)
    - ACK (Acknowledge Number) : 4 (다음 수신 예상 순번)
    - 데이터 위치,(헤더 길이(HLEN)) : 4bits (TCP 실제 데이터 위치 계산에 쓰임)
        - 4바이트 단위, 5 = (5 x 4 = 20bytes )
    - 예비 : 4bits ( 항상 0)
        - 예비 : 3bits
        - NS (1 bit) – ECN-nonce concealment protection
    - Code bits : 1 (8 bits)
        - CWR (Congestion Window Reduced)
        - ECE (ECN-Echo) :
        - URG( Urgent ) : 긴급 메시지를 전송
        - ACK( Acknowledgement ) : 수신 양호 표시
        - PSH( Requests PUSH ) : 버퍼링된 자료 푸쉬용
        - RST( Reset connection ) : 호스트는 즉시 연결을 끊음
        - SYN( Sync sequence numbers ) :  sequence 번호 동기화
        - FIN( sender finished ) : 테스트를 거쳐서 연결을 끊음

    - Window Size: 2 (TCP 흐름제어를 위해 상대편에게 자신의 버퍼 크기를 지속적으로 통보)
    - Checksum : 2
    - Urgent pointer : 2 (URG 필드에 의한, 긴급 데이터가 시작되는 위치 정보)
    - Option : 0~40
    - 실제 데이터


출처 - http://codens.info/767

//===========================================================

//참고

IP Header : http://www.joinc.co.kr/modules/moniwiki/wiki.php/Site/TCP_IP/IP_Header
TCP Header : http://www.joinc.co.kr/modules/moniwiki/wiki.php/Site/TCP_IP/TCP_Header#s-2.2
http://www.zytrax.com/tech/protocols/tcp.html

반응형
Posted by 랩터 인터내셔널