2008년 12월 29일 월요일

소프트 마이크로프로세서의 네 가지 라이선싱 모델

제어 설계

소프트 마이크로프로세서의 네 가지 라이선싱 모델

게재:2008년12월16일

Gordon Hands
Director of Strategic Marketing
Lattice Semiconductor Corp.

FPGA 설계자들은 점점 더 많은 디자인에 소프트 마이크로프로세서를 내장하고 있다. 이에 따라, FPGA 벤더들과 써드파티 IP 벤더들은 가장 최신 모델인 오픈소스를 비롯하여 여러 가지 방식의 라이선스를 갖는 다수의 소프트 마이크로프로세서를 개발해왔다.

설계자들은 보통 자신들의 소프트 마이크로프로세서를 위한 소프트웨어 코드 개발에 상당한 시간을 투자한다. 때문에 이들이 관련 라이선싱 모델들이 무엇을 의미하는 지 이해하는 것은 중요한 일이다.

어려운 결정

일단 소프트 마이크로프로세서를 구현하기로 결정되었으면 설계자들은 어떤 라이선싱 모델이 자신들의 요구에 가장 잘 맞는지를 결정해야 한다. FPGA 벤더들이 소프트 마이크로프로세서와 MCU에 이용하는 기본적인 라이선싱 모델에는 네 가지가 있다.

써드파티 IP 벤더들은 보통 IP 구매 모델을 이용한다. 여기서 이들이 취한 접근 방식을 논하지는 않겠지만 그 대부분은 FPGA 벤더들의 접근 방식과 유사하다.

모델 1: IP 구매─FPGA에 소프트 마이크로프로세서를 공급하는 전통적인 모델은 IP 구매이다. 이 모델은 네 가지 해결 과제들을 가져다준다.

· 마이크로프로세서 개발툴과 생성된 HDL 코드의 사용권에 비용을 지불해야 한다. 툴을 계속 사용한다든가 소프트웨어 유지 관리를 하는 경우 이 비용은 매년 들어가게 된다.

· 마이크로프로세서의 HDL 디스크립션은 보통 암호화되어있다. 이는 설계자가 이 구현물을 제한적으로만 최적화시킬 수 있도록 하며, 버그를 수정하기 위해서는 FPGA 벤더에 의존해야 한다.

· 마이크로프로세서를 지원하는 개발 자원들은 FPGA 벤더가 선택한 것으로 제한된다. 설계자가 아니라 벤더가 자원들의 우선순위를 정하게 된다.

· IP 구매 시의 라이선싱 조항으로 벤더의 FPGA 디바이스에 대한 구현이 제한된다. 이 마이크로프로세서에 대해 개발된 코드가 축적될수록 설계자가 다른 FPGA 벤더로 옮겨가기는 더 어려워진다.

· 설계자가 벤더를 전환하지 못함으로 인하여 벤더에게 경쟁 상의 이유로 압박을 가하지 못하게 된다. 이는 최종 제품이 고객들의 관심을 덜 끌게 만든다. 또한, 미래에 FPGA 벤더로부터 가격 상의 양보를 제한적으로만 받게 한다.

모델 2: 무료 레퍼런스 디자인─무료 레퍼런스 디자인 접근 방식은 IP 구매 모델과 관련된 두 가지 문제를 없애준다. 업프론트 비용이 없다는 것은 분명 매력적이다. 그리고 이러한 디자인들이 변함없이 소스 코드 포맷으로 제공됨으로 인해 이 디자인의 스트럭처에 접근할 수 있다.

하지만, FPGA 벤더가 이 디자인의 소유권을 갖기 때문에 이 디자인에 대한 추가적인 코드 개발의 인센티브가 없어진다. 마지막으로, IP 구매 방식에서와 같이 레퍼런스 디자인의 구현은 벤더의 디바이스 아키텍처로 제한된다.

모델 3: IP 암호화─IP 암호화는 IP 구매 방식의 몇 가지 문제를 해결하려는 새로운 시도이다. 이 모델에서 FPGA 설계툴들과 생성된 암호화 비트스트림을 이용한 디자인에 IP가 통합된다.

이 비트스트림을 이용하려면 미리 프로그램된 특수 FPGA를 복호화 키와 함께 표준 FPGA보다 비싼 값에 구매해야 한다. 이 접근 방식은 업프론트 비용을 없애주며, 표준 마이크로프로세서 아키텍처가 FPGA 내에 사용될 수 있게 해준다.

표준 아키텍처의 이러한 사용은 코드가 독립 칩과 ASIC 같은 다른 비 FPGA 솔루션에 구현될 수 있게 해준다. 하지만, 설계자들은 다시 한 벤더의 디바이스에 묶이게 된다. 코드를 눈으로 볼 수 없다는 문제와 벤더가 개발 우선순위를 정하게 된다는 문제는 이러한 접근 방식으로는 풀 수 없다.

모델 4: 오픈소스─오픈 소스 접근 방식은 다른 라이선싱 모델들과 관련된 고통스러운 문제들을 해결해 줄 것을 약속한다. 이것은 코드를 눈으로 볼 수 있게 해주어 설계자가 디자인의 기능을 이해할 수 있게 해주고, 자신들의 사용에 최적화시킬 수 있도록 한다.

이것은 설계자들이 코드를 수정할 수 있도록 융통성을 제공해 주며, 사용자들이 코드를 개선하여 더 넓은 개발 커뮤니티가 사용할 수 있도록 장려하는 IP 권리를 제공한다.

오픈 소스는 무료이며, 아마도 더 중요한 것은 이것이 어떠한 FPGA 아키텍처에도, 심지어는 ASIC 같은 비 FPGA 구현물에도 구현될 수 있게 해주는 이식성을 제공한다는 것일 것이다.

오픈소스 소프트웨어를 위한 GPL

오픈소스 운동은 소프트웨어 영역에서 시작되었다. 소프트웨어 영역에서는 많은 오픈소스 라이선싱 접근 방식들이 취해지고 있는데, 그 중 유명한 것 하나가 GNU General Public License (GPL)이다.

기부자가 자신의 작업을 인정받을 권리와 그 작업이 퍼블릭 도메인에 남아있도록 하는 것, 그리고 미래 사용자의 필요요건 간에 GPL이 취하고 있는 균형이 소프트웨어 개발 커뮤니티에서 이것이 인기있는 이유의 하나이다. 하지만 GPL은 궁극적으로 하드웨어에 구현될 IP에는 불완전한 라이선스이다.

구매자가 알아야 할 것들

FPGA 내에 임베딩되는 소프트 마이크로프로세서가 널리 유행함에 따라 설계자들은 라이선싱 조항에 세심한 주의를 기울일 필요가 있다. 이 기사에서는 네 가지 라이선싱 접근 방식을 살펴보았다. 그 중 오픈소스 접근 방식을 제외한 나머지는 향후 설계자들의 FPGA 디바이스 선택을 제한시켰다. 또한 이 접근 방식의 일부는 설계자가 코드에 접근하는 것을 제한함으로써 버그 수정을 IP 공급업체의 손에 맡길 수 밖에 없게 하고 있다.

소프트 마이크로프로세서의 오픈소스 라이선싱은 설계자에게 FPGA 아키텍처를 바꿀 융통성을 제공하고 그들이 필요로 하는 프로세서 아키텍처를 눈으로 볼 수 있게 해준다.

하지만, 오픈소스라 하더라도 라이선싱 세부 사항에 대해 세심한 주의가 필요하다. 이는 소프트웨어 영역에서 인기있는 많은 오픈소스 라이선스들이 하드웨어를 대상으로 하는 IP에 적용될 때는 심각한 문제들을 드리우는 경우도 있기 때문이다. 라이선스 없이 하드웨어를 배포해야 할 필요나 단일 하드웨어 구현물에 공개 코드와 고유 코드를 혼용해야 할 필요가 그러한 문제들에 포함된다.

LatticeMico32 IP 코어는 필요한 성능을 유지하면서도 최소의 디바이스 자원만을 소비한다.

LatticeMico32 IP 코어는 필요한 성능을 유지하면서도 최소의 디바이스 자원만을 소비한다.

<이번호 저널 2008년 12월 16일~31일>자에서 이 기사 및 다른 기사들도 찾아볼 수 있습니다.

본 기사는 에 있는 전자 엔지니어 기사에서 인쇄한 것입니다:
http://www.eetkorea.com/ART_8800556377_1134551_NT_aa234d5c.HTM

이전 기사로 | 전자 엔지니어

USB 기능이 마이크로컨트롤러 속으로 들어가다

임베디드 시스템

USB 기능이 마이크로컨트롤러 속으로 들어가다

게재:2008년07월01일

리차드 퀸넬

USB는 그 이름에 걸맞게 범용 MCU에서 표준 직렬 인터페이스로서 RS-232 버스를 밀어내고 있다. 더 많은 디바이스들이 이전 MCU의 종단 디바이스 인터페이스들을 늘리기 위하여 호스트와 On-the-Go (OTG) 기능을 통합함에 따라 통합 USB의 기능도 늘어나고 있다. 최근 발표된 제품들은 USB가 오토모티브, 산업, 초저전력 가전 제품 같은 어플리케이션들을 타깃으로 한 보다 특수한 디바이스에도 잠식해 들어가고 있음을 보여준다.

신선한 솔루션

올해 임베디드 시스템 컨퍼런스에서 소개된 제품들은 MCU 벤더들이 얼마나 열성적으로 USB를 받아들이고 있는 지에 대한 예증이다. 두 ARM 공급업체인 Atmel과 Luminary Micro는 자신들의 제품 패밀리에 첨단 USB 기능들을 추가해왔다. ARM-9 코어를 기반으로 한 Atmel SAM9R64 MCU는 USB의 고속 480Mbit/s 모드에서 동작하는 종단 디바이스 설계를 타깃으로 한다. ARM Cortex-M3 코어를 기반으로 한 Luminary Micro의 Stellaris 패밀리는 USB 기능을 포함하고 있는 20개의 멤버들을 추가했다. 이 중 많은 것들이 호스트 컨트롤러와 OTG 기능 모두를 제공하고 있다. 그런 기능들은 Microchip Technology사의 PIC32 패밀리 내의 새로운 멤버들과 Microchip의 새 PIC23FJ256GI 패밀리 내의 10여 개의 16비트 MCU들에서도 나타난다.

그림 1: USB 기능 내장한 MCU 고속 호스트 및 On-the-Go 지원 기능도 등장하고 있다.

그림 1: USB 기능 내장한 MCU 고속 호스트 및 On-the-Go 지원 기능도 등장하고 있다.

USB 기능을 현재까지는 실용적이지 않았던 어플리케이션 분야로 가지고 가는 것을 목표로 한 추가적인 제품들이 향후 수달 안으로 발표를 기다리고 있다. Texas Instruments의 MPS430 제품 마케팅 매니저 Kevin Belnap 씨는 TI가 초저전력 가전 영역을 해결하기 위해 빠른 시일 내로 제품들을 발표할 것이며, USB가 그 일부가 될 것이라고 밝혔다.

마찬가지로 Microchip사도 양산 가격이 1달러 밑으로 내려가는 초저가를 타깃으로 한, USB가 가능한 8비트 MCU 라인을 곧 내놓을 예정이다.

임베디드 컨트롤에서 USB의 역할은 계속 확대될 것으로 보인다.

USB 기능을 갖춘 일단의 MCU들을 공급하는 NEC Electronics America는 USB가 게임, 산업자동화, 빌딩 관리에 들어가는 것을 보고있다.

NEC 오토모티브 비즈니스 유닛의 마케팅 디렉터 David Stone 씨에 의하면 USB를 오토모티브 시장에 가져가는 것에 관한 관심도 증가하고 있다고 한다. “USB를 이용하여 소비자들이 USB 스틱으로부터 자신들의 오디오 파일들을 차량의 엔터테인먼트 시스템으로 다운로드 받도록 하는 데 대한 관심들이 있다”고 Stone 씨는 지적했다. “무선 USB를 이용하여 가정 내 서버에서 차고 안의 자동차로 비디오를 다운로드하고, 차량 내에서 그 비디오를 여러 장치에서 나누어 이용하도록 하는 것에 관한 논의도 시작되고 있다.”

드라이버

다수의 요소들이 MCU 커뮤니티 내에서 USB의 채택을 주도하고 있다. 그 한 가지가 임베디드 시스템을 위한 인터페이스 및 컨트롤 장치로서 PC 특히 랩탑의 사용이 늘어난 점이다. NEC의 다목적 MCU 전략 비즈니스 유닛의 시니어 엔지니어링 매니저인 Ray Shin 씨는 “어플리케이션이 PC에 연결되려면 USB를 가져야 한다. 랩탑은 더 이상 RS-232를 제공하지 않는다”고 말했다.

Belnap 씨도 이에 동의하면서 “컴퓨터들은 직렬 포트들을 떼어내고 있다. 그러므로 데이터 다운로드나 컨피규레이션을 위해 장비를 PC에 인터페이싱하려면 장비가 USB를 필요로 한다”고 말했다.

그러나 PC 인터페이스를 필요로 하지 않는 임베디드 어플리케이션들 조차도 USB를 채택하고 있다. Luminary Micro는 Stellaris 패밀리 멤버들을 발표하면서 산업 시장이 USB의 표준화된 커넥션과 핫스왑 기능 그리고 장치에 전원을 공급하는 능력에 흥미를 보이고 있다고 지적했다. CPU의 개입없이 DMA 인터페이스를 통해 메모리에 데이터를 보내는 USB 인터페이스의 능력은 마음을 끄는 또 다른 특징이다. 산업 시스템들은 이미 산업 시스템에 컨피규레이션 데이터를 다운로드하기 위해 플래시 메모리 스틱으로의 인터페이스로서 USB를 이용하고 있으며, PC의 이용없이 로그된 데이터를 되찾기 위해서도 이용하고 있다.

해결 과제들

USB 인터페이스의 속도와 유틸리티는 가격에 맞출 수 있지만 늘어난 설계 복잡성은 그렇지 않다. “USB는 꽤 복잡한 프로토콜”이라고 Belnap 씨는 말했다. “개발자들은 그것을 이용해 제 속도를 내게 하려면 제대로 된 툴들을 필요로 한다”면서 Belnap 씨는 MCU 벤더들은 소프트웨어, 툴, 레퍼런스 디자인들을 가지고 USB의 초보 사용자와 숙련된 사용자 모두의 필요를 해결해야 한다고 말했다.

그림 2: 보안 키 같은 다수의 새로운 어플리케이션들이 수요를 불러 일으키고 있다.

그림 2: 보안 키 같은 다수의 새로운 어플리케이션들이 수요를 불러 일으키고 있다.

Microchip의 고성능 MCU 담당 마케팅 매니저인 Terry West 씨는 이에 동의하면서, MCU에 USB를 추가하는 것은 소프트웨어에 큰 충격을 줄 수 있다고 지적했다. “USB 호스트 스택 자체 만으로도 100Kbyte 이상의 이진 코드”라고 West 씨는 부연 설명했다.

USB는 또한 초저전력 가전 제품 같은 새로운 어플리케이션 영역들을 위해 설계할 때도 어려움이 있는 것으로 드러났다. 이는 USB가 PC 환경을 위해 개발된 것이기 때문이다. “초저전력 시스템들은 보통 단일 AAA 배터리 또는 코인셀로 동작한다”고 Belnap 씨는 말했다. “그래서 이들은 USB 인터페이스보다 더 낮은 전압에서 가동된다. 그러한 부분을 해결해야 한다. 또한, USB 인터페이스는 배터리 수명을 보존하기 위해 접속되어 있지 않을 때에는 전력을 낮출 필요가 있다.”

다행히도, MCU 벤더들은 자신들의 온칩 USB 주변 장치들을 위해 드라이버, 클래스 드라이버, 호스트, 디바이스, OTG 기능용 스택들을 포함한 완전한 소프트웨어 지원을 제공함으로써 고객들을 위하여 소프트웨어 복잡성과 다른 설계 문제들을 해결하고 있다. 이 벤더는 NEC와 Microchip에서처럼 소프트웨어를 자체적으로 개발하거나 Luminary Micro의 Stellaris 패밀리를 위한 Express Logic의 USBX 지원처럼 제삼의 공급업체와 함께 일할 것이다.

“고객들은 항상 우리가 그들의 돈을 어떻게 절약할 수 있게 해줄 것인가를 묻는다”고 NEC의 Shin 씨는 말했다. “그래서 우리는 풀 솔루션을 제공해야 한다.” 일반적인 USB 벤더 지원에는 소프트웨어 소스 코드, 레퍼런스 디자인, 개발 보드 및 툴셋이 포함된다.

<이번호 저널 2008년 7월 1일~15일>자에서 이 기사 및 다른 기사들도 찾아볼 수 있습니다.

본 기사는 에 있는 전자 엔지니어 기사에서 인쇄한 것입니다:
http://www.eetkorea.com/ART_8800532019_839585_NT_5fc4a866.HTM 

이전 기사로 | 전자 엔지니어

2008년 12월 26일 금요일

Emailing: 스타일과 편리함을 잡다, HP 미니 1000

기사제목 : 스타일과 편리함을 잡다, HP 미니 1000
작성자 : 김달훈 객원기자 작성날짜 : 2008-12-11

미니 노트북이 필요하다고 여겨질 때, 필요와 용도를 꼼꼼하게 따져보면 크게 두 가지 경우로 나눌 수 있다. 우선은 작업 용도나 업무 특성상 가능하면 높은 사양을 갖추고 있으면서 휴대성도 뛰어난 미니 노트북이 필요한 경우다. 이럴 때는 부담이 되더라도 어쩔 수 없이 고급형 제품을 구입할 수밖에 없다.

반면에 높은 시스템 사양을 필요로 하는 작업을 별로 할 일이 없다면, 상대적으로 성능이나 기능이 떨어지더라도 휴대성 뛰어나고 저렴한 가격을 가진 저가나 보급형 미니 노트북이 안성맞춤이다. 무작정 고급형 제품만 고집하게 되는 욕심만 버린다면 넷북과 같은 미니 노트북도 나쁘지 않다는 얘기다.

한국HP(www.hp.co.kr)의 미니(Mini) 1000은 이름에서도 짐작할 수 있듯이 작고 가벼운 미니 노트북이다. 좀 더 정확하게 태생을 분류하자면 간편하게 휴대하고 다니면서, 문서 작업이나 인터넷을 활용하는 데 초점을 맞춘 넷북(NetBook)이라고 할 수 있다.

10.2인치 크기의 와이드 액정 앞쪽에 유리를 덧댄 브라이트뷰(Bright View) 인피니티 디스플레이를 채용한 한국HP의 미니 1000. 인텔의 아톰 N270 프로세서를 탑재한 미니 노트북으로 크기는 작지만 풀사이즈 키보드의 92% 정도 크기를 가진 제법 널찍한 키보드를 채용한 것이 특징이다.(사진:www.hp.com)

미니 1000은 넷북 정도의 성능이면 만족할 수 있는 사람들 중에서도, 특히 문서 작업을 많이 하거나 블로그에 글을 부지런히 올려야 하는 까닭에 타이핑 작업을 많이 해야 하는 사람들이 눈여겨볼 만하다. 크기는 작지만 풀사이즈 키보드의 약 92%에 달하는 널찍한 키보드를 채용하고 있기 때문이다.

깔끔하면서 세련된 디자인이나 밝고 선명한 화면을 제공하는 디스플레이를 채용한 점도 돋보인다. 액정 앞쪽에 유리를 덧댄 브라이트뷰(Bright View) 인피니티 디스플레이는, 액정이 긁히는 것을 막아주고 보다 선명하고 깨끗한 화면을 볼 수 있도록 해준다는 것이 한국HP의 설명이다.

미니 1000의 화면 크기는 약 259mm(10.2인치)로 1,024×600 화소의 해상도를 제공한다. 디스플레이 위쪽에는 인스턴트 메신저나 인터넷 전화 서비스를 이용해, 화상 채팅이나 회의를 할 때 활용할 수 있는 웹캠이 내장되어 있다. 운영체제는 윈도 XP 홈 버전을 설치해서 판매한다.

그래픽 칩셋은 인텔의 GMA 950을 사용하며, 프로세서는 1.6GHz의 동작속도와 512KB의 L2 캐시를 내장한 인텔의 아톰 N270을 탑재했다. 메모리 용량은 최대 1GB까지 지원하며, 저장장치는 모델에 따라 8GB 또는 16GB의 SSD(Solid State Drive)나 60GB 용량의 하드디스크가 들어간다.

네트워크 연결 기능은 최대 100Mbps의 데이터 전송이 가능한 유선랜과 IEEE 802.11 b/g 규격의 무선랜을 지원한다. 블루투스 기능은 옵션으로 선택할 수 있다. 인터페이스로는 SD 메모리 카드 슬롯, 2개의 USB 단자, 헤드폰 및 마이크 단자, 확장 포트를 사용할 수 있다.

전원으로는 3셀의 리튬 폴리머 충전지를 사용하며, 한번 충전으로 약 3시간 30분 정도를 사용할 수 있다고 한다. 크기는 261.7×166.6×25.13mm, 무게는 SSD를 탑재했을 때 약 1.09kg이고 하드디스크 내장 모델의 경우는 약 1.11kg이다.

가격은 SSD 모델이 약 69만원, 하드디스크를 탑재한 제품은 약 79만원 전후가 될 것으로 보인다. 국내 출시 시기는 2009년 1월로 예정되어 있으며, 6셀의 대용량 배터리로 같은 시기에 출시할 계획이라고 한국HP는 밝혔다.

 
 

Emailing: 매혹적 디자인의 미니노트북, HP 미니 1000

기사제목 : 매혹적 디자인의 미니노트북, HP 미니 1000
작성자 : 한주엽 기자 작성날짜 : 2008-12-20

인텔 아톰 프로세서를 탑재한 저가형 미니노트북을 '넷북'이라 부른다. 인터넷 접속 및 오피스 프로그램 등 가벼운 작업 정도는 무리 없이 소화해내는, 이동성을 강조하면서도 상대적으로 가격 부담이 적은 노트북이 바로 넷북이다.

초창기 대만 PC 제조업체들이 넷북 바람을 일으키면서 국내 대기업은 물론이고 델 같은 글로벌 PC 업체도 이 시장에 뛰어들었다. HP도 최근 미니 1000이라는 시리즈명의 넷북을 국내 시장에 출시해놓은 상태다. 그 중 60GB 하드디스크를 탑재한 1001TU 모델을 만나봤다.


HP 미니 1001TU

■ 매혹적 자태를 뽐내다

10.2인치형의 액정을 단 HP 미니 1000은 같은 인치수의 다른 넷북과 비교하면 작고 가볍다.
HP는 인텔이 말하는 넷북 시장에는 다소 늦게 뛰어든 듯 하나 이미 2133이라는 미니노트북을 내놨던 이력이 있다. 비아 프로세서를 탑재했던 2133은 넷북이 나오기 전, 저가형 미니노트북 시장의 독보적인 존재였다.

인텔이 아톰 프로세서를 발표한 뒤 이를 탑재한 미니노트북, 넷북이 다수 출시되면서 빛이 바래긴 했으나 미니노트북이라는 범주에서 따져보면 HP가 후발주자라고 말하기는 힘들다. 게다가 2133의 경우 키보드와 액정의 배치에서 매우 효율적이면서도 이상적인 모습을 보여줬기 때문에 심장(프로세서 등)을 새로 이식한 미니 1000 시리즈는 더욱 관심을 얻고 있다.

이미 환율 등의 영향으로 대다수 넷북의 가격이 60~70만원대까지 올라가 있는 상태여서 넷북을 '저가형'이라고 부르기는 낯간지러운 면이 없지 않지만 미니 1000은 그 중에서도 매우 고급스러운, 매혹적인 자태를 뽐낸다. 검정색 광택 재질 안쪽으로 촘촘하게 그려져 있는 원형 패턴은, HP 제품군 중에서도 고급 홈 노트북에나 적용되는 상감 기법이 이 제품의 상판에 그대로 적용된 것이다.

10.2인치형의 액정을 단 HP 미니 1000은 같은 인치수의 다른 넷북과 비교하면 작고 가볍다. 심지어 8.9인치형의 액정을 장착한 델 인스피론 미니 9와 크기나 무게가 비슷하다. 따져보면 HP 미니 1000이 델 인스피론 미니 9보다 가로 길이가 3cm 정도 길고 무게가 0.5g 정도 더 나가는 정도니까. 미니 1000의 무게는 하드디스크형이 1.11kg, SSD형이 1.09kg이다.

두께 역시 얇다. 액정을 접었을 때의 두께는 25mm 정도로 역시 같은 인치대의 넷북과 비교했을 때 7~15mm 가량 얇은 것이다. 넷북 중에서는 가장 얇은 수준이다. 
 

이 스피커. 예상 외로 소리가 매우 좋다. 넷북 중에서는 가장 좋은 소리를 낸다. 크기와 부피를 줄이기 위해 이어폰과 마이크 단자는 하나로 통합되어 있다. 같이 못쓴다는 얘기다. 그 옆에는 HP 노트북 전용 확장 포트가 보인다. D-SUB 단자로 외부 모니터를 연결하려면 별매품인 확장 케이블을 구입해서 여기 연결해야 한다.
제품 우측면에는 SD/MMC 카드 슬롯과 USB 포트가 보인다. 전원 및 무선랜 ON/OFF 레버가 전면에 달려 있다. 인디케이터는 전원 레더 우측에 달려 있는데 이를 보려면 고개를 왼쪽이나 오른쪽으로 꺾어서 봐야 한다.

■ 미니노트북의 선택 기준

이처럼 작은 크기를 가졌지만 화면을 보고 키보드 자판을 두드리는 일반적인 작업에는 전혀 불편함이 없다. 풀사이즈 키보드 대비 92%의 크기를 가진 널찍한 키보드와 선명한 액정 덕분이다.

액정은 끝까지 뒤로 젖혀지지 않는다. 젖혀지는 각이 좁아서 무릎 위에 놓고 화면을 보기가 쉽지 않다.

키보드의 경우 단순히 넓어서 좋다는 게 아니라 공간 활용을 멋지게 했다는 점에서 더욱 빛난다. 빈공간이 거의 없을 정도로 빼곡하게 들어찬, 그러면서도 각각의 키는 오목한 형태로 만들어 놓은 점, 자주 쓰는 시프트키와 백스페이스 키의 가로 길이를 늘려놨다는 점 덕분에 오타가 적고 장시간 사용해도 손의 피로가 덜하다.


빼곡하게 들어찬 이 키보드는 HP 미니 1000 시리즈의 가장 큰 장점이다. 특히 시프트 키 등 자주 쓰는 키는 키워놓고 오목한 형태로 만들어져 있어 장시간 사용해도 피로가 덜하다.
액정은 CCFL 대신 LED 백라이트를 채택하면서도 브라이트뷰 코팅과 주변 프레임이 없이 유리 코팅으로 마무리해서 선명함과 고급스러움이라는 두 가지 장점을 모두 살렸다.

넷북의 기대치, 단지 인터넷을 즐기고 문서 작업 정도는 무리 없이 해낼 수 있으면 그만인 넷북에서 이 정도 디자인과 이 정도 설계면 잘 만든 노트북이라고 말할 수 있을 것이다. 게다가 기대도 하지 않았던 외장 스피커에서 제법 깊고 풍부한 소리까지 들려주니 더욱 마음에 든다.

물론 아쉬운 점도 있다. 일단 액정을 최대한 젖힐 수 있는 각도가 좁아서 무릎 위에 놓고 쓰거나 책상이 낮은 곳에선 허리를 더욱 구부려야 선명한 화면을 볼 수 있다. 또 전용 확장 케이블이 있어야만 D-SUB 케이블을 통해 외장 모니터와 연결이 가능하다. 확장 케이블은 별매 품목인데 제품을 구입하고도 어딘가에 또 돈을 들어야 한다는 점이 누군가에게는 부담으로 다가올 수 있다.

3셀 배터리는 최소 전원 설정과 무선랜만 켜둔 상태에선 2시간 20~30분 가량을 버틴다. 6셀 배터리가 아쉽다면 내년 1월까지 기다려야 한다. 3셀 배터리를 장착한 것이 단점은 아니지만 6셀 배터리를 달고 나오는 경쟁 제품과 비교해본다면 보는 관점에 따라서 누군가에게는 아쉬운 점이 될 수도 있겠다.

키보드를 키우느라 아래쪽 터치패드의 버튼이 좌우측에 배치되어 있다. 불편함은 느껴지지 않는다.
팬 돌아가는 소리가 비교적 크게 나는 점은 단점이다. 특히 이렇게 팬이 돌아가고 있음에도 터치패드 주변, 그러니까 손목 닿는 부분에서 열이 올라오기 때문에 조금 오랜 시간 노트북을 쓰면 땀이 조금씩 흐른다. 하판 쪽은 더 많은 열이 발생하기 때문에 장시간 무릎 위에 놓고 쓴다면 불쾌한 감정을 느낄 수도 있겠다. 물론 액정 젖혀지는 각도 때문에 무릎 위에 올려놓고 쓰는 일은 적겠지만.

사실 따지고 보면 이런 불만이나 단점이 생기는 이유는 제품이 얇고 작게 만들어진 데 따른 것이다. 디자인 멋지고 작고 가벼워 이동성이 높으면서도 불편하지 않은 작업 환경을 제공하기 위해 필연적으로 따라오는 것들이랄까. 미니노트북의 기본이라고 말할 수도 있겠지만 이러한 기본을 제대로 지키지 못한 제품이 많다.

결론적으로 단점이나 불만 보다는 이 제품을 골라야 할 이유가 더 많다. 미니노트북을 고르려 한다면 이 제품을 눈여겨볼만 하다.

CPU 인텔 아톰 N270
메인보드 칩셋 인텔 945GSE 익스프레스
메모리 1GB DDR2 SDRAM
하드디스크 60GB PATA, 4,200rpm, 4.5cm(1.8인치)
광드라이브 ×
그래픽 인텔 GMA 950
사운드 HD 오디오
네트워크 유선랜 10/100 Mbps, 무선랜 802.11 a/b/g
USB USB 2.0 × 2
IEEE 1394 ×
디스플레이 25.9cm(10.2인치) 와이드 1,024×600
광출력 지원 ×
전원(배터리) 3셀 리튬이온
메모리리더 지원 SD, MMC
PCMCIA -
운영체제 윈도 XP 홈에디션
제공 소프트웨어 ×
크기 261.7×166.6×25.13mm
무게 1.11kg
기타 LED 백라이트 액정, 30만화소 웹캠, 블루투스
문의 한국HP(www.hp.co.kr)

 
 

[전시] 퐁피두센터 특별전 (서울시립미술관)

12/25 크리스마스를 기념(?)해서...

잘은 모르지만, 이런 그림들 보러 일부러 돈내서 프랑스로 가는사람들도 있다던데 난 운좋게도 여기 서울에서 유명한 작품들을 편하게 감상할수가 있었다...  그것도 혼자 쓸쓸하게가 아니라...^^

몇몇 기억에 남는 작품은,

- 호앙 미로 作品, <어둠 속의 사람과 새>, 그림 크기로만도 사람을 압도하는 뭔가가 있었던...

 C8A3BED3B9CCB7CE_winjs

- 지우제페 페노네 作品, <그늘을 들이마시다.>, 설치 미술 작품이었는데, 월계수입에서 뿜어져 나오던 향기가 참 좋았던... 작가가 2001년 프랑스 아비뇽에서 딴 잎사귀들이래나 뭐래나...

23_winjs

<그늘을 들이마시다.> 작품 개요 약간...^^

지우제페페노네/1947~
1999~2000 월계수잎 철망/ 200개, 황금 브론즈/ 가로 11m, 세로 7m, 높이 3.5m

<네가지크기의 철망>
117*78*7cm
100*78*7cm
78*78*7cm
50*78*7cm

<페 모양의 황금브론즈> 60*72*38cm

- 블라디미르 두보사르스키 &  알렉산더 비노그라도프 作品, <풀밭 위의 점심식사>, 원래 풀밭 위의 점심식사를 그렸던것은 그 시대를 풍자하려고 했다던데 이 그림은 풍자적인 느낌보다는 그냥 보기만해도 재미가 있더라는...

41_winjs

나머지 본 전시에 관한 아주 훌륭한 article은 아래 link를 참조하면 됨...

아래는 그날 휴대폰으로 찍은 사진 몇컷...^^;;;

P081225001P081225016P081225015

P081225022P081225004

P081225007

마지막 사진이 젤 맘에 드네...ㅋㅋㅋ 내 목도리 들고있는 손이 참 예쁘다...^^

How to interface FPGAs to microcontrollers

July 30, 2008

How to interface FPGAs to microcontrollers

Neither standard product microcontrollers nor FPGAs were developed to communicate with each other efficiently, so interfacing the two can be a challenge.

By Rocendo Bracamontes Del Toro, Atmel

As many as half of all embedded designs have an FPGA next to a microcontroller. The FPGA can be used to implement anything from glue logic, to custom IP, to accelerators for computationally intensive algorithms. By taking on some of the processing tasks, FPGAs help to improve system performance, thereby freeing up the MCU from cycle-intensive tasks. FPGAs also provide excellent performance characteristics and lots of flexibility to accommodate changing standards.

There are two basic implementations of MCU-plus-FPGA designs: putting a soft MCU core into the FPGA logic structure or using a standard product MCU with a discrete FPGA. Putting a soft core into the FPGA can be effective, but it can also be an expensive and power-hungry way to implement a microcontroller when compared to a standard product. This is especially true when using a 32-bit ARM-based core. As a result, only about one-third of FPGA-plus-MCU designs are implemented with an MCU core inside the FPGA logic. The remaining two-thirds consist of a standard product microcontroller next to a discrete FPGA.

Neither standard product microcontrollers nor FPGAs were developed to communicate with each other efficiently. They even use different languages. Thus, interfacing the two can be a challenge. FPGAs do not have any dedicated logic that communicates with microcontrollers. This logic module must be designed from scratch. Second, the communication between the microcontroller and FPGA is asynchronous. Special care is needed to resynchronize the MCU to the FPGA clock domain. Finally, there is an issue of bottlenecks, both at the interface and on the MCU bus. Transferring information between the MCU and the FPGA usually requires cycles on the MCU bus and usually ties up the resource (PIO or EBI) used to effect the transfer. Care must be taken to avoid bottlenecks with external SRAM or Flash and on the MCU bus.

There are basically three hardware options for interfacing the FPGA to the MCU: programmable I/O (PIO); external bus interface (EBI), if available; and, finally, a dedicated interface between built into the MCU between the advanced high-speed bus (AHB) and the FPGA. Which approach to use depends on the end application and the desired result.

PIO Interface
Interfacing the MCU to the FPGA via the PIO is relatively simple for simple data transfers, consisting of the transfer of 32 bits of address, 32 bits of data, and some control signals for control. This requires a 32-bit PIO and an additional 2-bits on another PIO (Fig 1).


1. PIO interface to FPGA.
(Click this image to view a larger, more detailed version)

For a transfer of data to the FPGA, the direction of the bidirectional buffers in the PIO must be set to output. The software algorithm that transfers data to the FPGA is as follows:

PIO_DATA = ADDRESS; // Pass the address to write
PIO_CTROL = START | WR; // Send start of address cycle
PIO_CTROL = CLEAR; // Clear PIO ctrl, this ends the address cycle
PIO_DATA = DATA; // Set data to transfer
PIO_CTROL = START; // Data is ready in PIO
PIO_CTROL = CLEAR; // This ends the data cycle

Reading from the FPGA is similar. Again, the direction of the buffer on the PIO must first be set to output and then change directions to input to read the data from the FPGA, the following code is executed:

PIO_DATA = ADDRESS; // Set the address to read
PIO_CTROL = START | RD; // Send start of address cycle
PIO_CTROL = CLEAR; // Clear PIO ctrl, this ends the address cycle
PIO_DATA_DIR = INPUT; // Set PIO-Data direction as input to receive the data
DELAY(WAIT_FOR_FPGA); // wait for the FPGA to send the data
DATA_FROM_FPGA = *PIO_DATA; // Read data from FPGA

The above algorithms are for a basic transfer, a more sophisticated algorithm is necessary to establish a proper communication between the ARM microcontroller and the FPGA. Special care is necessary to ensure the acknowledgment of data, e.g. no data has been lost due to speed or wait cycles on each side.

The access time is calculated as the sum of:

TAccess-PIO = t1 + address phase + t2 + data phase

Using the GCC compiler with maximum optimizations, the system takes approximately 55 AHB cycles to perform the write operation to the FPGA (Fig 2).


2. PIO write to FPGA.
(Click this image to view a larger, more detailed version)

Assuming t2 (wait for FPGA response ready) is also around 25 AHB cycles, the system takes approximately 85 AHB cycles for a read operation from FPGA (Fig 3).


3. PIO read from FPGA.
(Click this image to view a larger, more detailed version)

The interface from the MCU itself is fairly simple and straight forward. However, special logic must be implemented in the FPGA to decode all the traffic generated by the PIO. In the majority of cases, the traffic from the microcontroller is completely asynchronous. As a result, the FPGA must be able to oversample the control signals from the microcontroller; otherwise the FPGA will miss the time window and the traffic will not arrive at the final destination inside the FPGA.

Since the processor is the one in charge of keeping the PIO busy, there is an overhead of processing time. While the CPU is engaged in data transfers, it cannot do anything else. Thus, this solution has the potential to bog down system processing. DMA is not possible using a PIO interface, so the software programmer must limit data bandwidth to allow for other communication with the MCU. For example, if there is a routine that demands 100% of the processors cycles running concurrently with a serial (SPI, USART or TWI) transfer to or from the FPGA, then one of these two processes must wait. If the data going to or coming from the FPGA is not buffered on time, it will probably be overrun by the next byte/word of data. In essence, the embedded processor becomes a glorified data mover.

Interfacing through the External Bus Interface (EIB)
Many 32-bit microcontrollers have an external bus interface (EBI) module, which is designed to transfer data between external devices and the memory controllers on ARM-based devices. These external memory controllers are capable of handling several types of external memory and peripheral devices, such as SRAM, PROM, EPROM, EEPROM, flash, and SDRAM.

The EBI can also be used to interface to FPGAs as long as the FPGA can handle the predefined memory interfaces. Using the static memory interface (SRAM) on the EBI is preferable for FPGA communication because it is simple and most designers are familiar with it. As with the PIO interface, the FPGA will have to include a module that understands the SRAM timing and is able to produce a response back to the microcontroller (Fig 4).


4. EBI-SMC interface.
(Click this image to view a larger, more detailed version)

Fig 5 shows the standard read timing for the EBI using the SMC memory interface, while Fig 6 shows the standard write cycle.


5. EBI-SMC read cycle.
(Click this image to view a larger, more detailed version)


6. EBI-SMC write cycle.
(Click this image to view a larger, more detailed version)

Note: These timing waveforms are the default for SMC specification. All parameters shown are programmable based on the speed of the external device.

An EBI interface is faster than PIO because the EBI has its own I/O in place and most of the signals are parallel. However, if the external device is slow or introduces wait states, the EBI's speed advantage could be compromised.

Like the PIO interface, the EBI interface must be driven by the processor or another AHB master. Thus, the achievable bandwidth on the EBI is also dependent on software and depends on how much processor time is available to it. Certainly there could be a bandwidth limitation. This again potentially limits the embedded processor in carrying out other system functions that it was designed to do.

Using a dedicated FPGA interface on the MCU
ARM7-based microcontrollers are available with a special interface that allows the FPGA to directly access to the MCU's internal AHB bus with DMA access via two AHB masters and four AHB slaves. One extra AHB slave may be used to re-map the ROM using an external ZBT RAM through the FPGA with a programmable ROM re-map feature at startup.

The interface also gives the FPGA access to fourteen advanced peripheral bus (APB) slaves, two DMA full duplex channels, up to thirteen priority encoded interrupts (IRQs), two non-encoded IRQs for DMA transfers and 32-bits of shared programmable I/Os. The FPGA interface accesses the AHB through the pre-defined masters and slaves on the microcontroller (Fig 7).


7. MCU with dedicated FPGA interface.
(Click this image to view a larger, more detailed version)

The FPGA interface is based on several serializers that encode and decode all the traffic between the microcontroller and the FPGA. In order to have a proper communication and synchronization between both devices, the following requirements must be in place:

  • The FPGA must be capable of handling skew clock balancing and latency cancellation. In the Xilinx FPGA families, the usage of DCM's (Digital Clock Manager) is mandatory to handle all the latency cancellation and required clocks generation. Altera devices require the use of PLL's. The FPGA must also provide the configuration modes and reset to the microcontroller's built-in interface. It must provide the serial communication clock to the microcontroller, which may have a frequency of up to 100 MHz for commercial range devices. The ratio between the internal ARM7 clock and the serial clock should be in the order of 0.8 or lower (ARM Clk / Serial Clk).
  • The FPGA-interface is based on a set of modules that encode and decode the internal AHB transactions. The encoded/decoded data is transferred through MPIO's using dedicated serializers for each master and slave. Due to the large number of bits to be transferred, a single transfer will take several AHB-Bus clock cycles. The specific number of clock cycles depends on the ratio between the AHB-Clock in ARM7, the serial clock, and the AHB-clock in the FPGA. Since the AHB-clock on the microcontroller is independent from the AHB-clock in the FPGA, the FPGA and microcontroller can run at different frequencies. Even masters or slaves inside the FPGA can run at different frequencies.
  • Each serializer block on the microcontroller and FPGA has a complementary finite state machine (FSM) that understands and talks to the AHB bus. Thus, the interface can handle simultaneous transfers from either side eliminating the common bottle neck seen in others interface topologies such as EBI or PIO.

Microcontrollers with a direct FPGA interface also have DMA channels on nearly every peripheral, with several DMA channels dedicated to the FPGA interface. The DMAs are supported by a multi-channel peripheral DMA controller (PDC) that off-loads from the CPU the job of transferring data between the FPGA, the peripherals and the memories as in the other two methods. This avoids the bandwidth limitations of a conventional ARM7, which can be completely monopolized by data transfers at a data rate of only 4 Mega bits per second (Mbps).

By off-loading this task from the CPU, the PDC can achieve a 12 Mbps data rate with 85% of the CPU's cycles available for processing. Multiple DMA channels are dedicated to the FPGA interface to connect multiple application-specific peripherals and interfaces to the PDC, without any intervention from the microcontroller. Using the dedicated DMA channels in the PDC frees the ARM processor to focus on processor heavy tasks and increases overall system performance and data bandwidth (Fig 8).


8. ARM7 to FPGA interface.
(Click this image to view a larger, more detailed version)

The serializer module handles all the AHB and serial communications. It consists of a finite state machine (FSM) and a shifter. The finite state machine understands and talks to the AHB. When a master initiates a transfer (read/write operation) the FSM introduces wait states using HREADY to comply with the AHB protocol. The number of introduced wait cycles is automatically handled by the FSM based directly on the ratio between the AHB clocks and the serial clock. The smaller the ratio is, the fewer the number of introduced wait cycles.

The FSM controls the shifter, which handles all the data shifting (serializing) between the microcontroller and the FPGA, transferring data at two bits per cycle. If the serial clock rate is set at 100 MHz, the shifter transfers 200 Mbps.

The serializer modules that handle the masters A/B, slaves-A/B and slaves C/D are programmable at reset time through the "modes" module in the FPGA to maximize the number of available I/O. The designer can choose to use all 10 I/O lines for a single serial configuration, in which case the serial module will handle only one AHB interface. For example, if the user wants to use only AHB master A, the serial module handling the masters should be configured as a "serial single configuration". This configuration will improve the number of bits transferred between shifters, thereby speeding up the transactions between the microcontroller and FPGA (Fig 9).


9. Serial single configuration.
(Click this image to view a larger, more detailed version)

The other option is to configure the serial module to handle two AHB interfaces in "serial dual configuration", in which the 10 I/O lines are shared between the two AHB (masters/slaves). In this case, the data transfer rate between the microcontroller and FPGA is lower, but the data bandwidth is higher because two AHB interfaces are enabled. The dual configuration re-uses half of the dedicated I/O for another AHB interface (Fig 10).


10. Serial dual configuration.
(Click this image to view a larger, more detailed version)

FPGA interface logic
When implementing an FPGA interface through the EBI or PIOs, the engineer must write the RTL code that allows the FPGA to communicate with the MCU. Vendors of MCUs with a direct FPGA interface provide all the RTL needed to establish proper encoding and decoding communication with appropriate constraints for each specific FPGA vendor. This logic module produces a reset and provides the different modes under reset conditions. The RTL provided by the vendor lets the user decide what functionality to choose. By default all mode bits are zeroes (Table 1).


Table 1. Mode bits.

A vendor-supplied template can be used to instantiate the AHB masters and slaves to the FPGA interface. Specific examples are provided. In the FPGA template, a module called "Custom MP" requires the least amount of effort to integrate AHB/APB peripherals. The usage of this template gives the designer the option of migrating the two-chip MCU-plus-FPGA implementation to a single-chip customizable microcontroller with virtually no extra engineering effort since the logic in the FPGA will have been proven in the system.

The external ZBT-RAM and NVM/SDRAM/SRAM are optional, based on applications and system requirements.

Designers also may add non-AHB logic to the FPGA, providing the flexibility to add other functions unrelated to the AHB bus.

As mentioned before, the transfer speed depends from the ratio between all clocks related to the communication between the microcontroller and the FPGA and whether it is in single or dual serial mode.

In single configuration mode, it takes four AHB-Clock cycles to transfer all the AHB information for a single-AHB interface from the microcontroller to the FPGA and vice versa (Fig 11). In dual configuration mode, it takes eight AHB-Clock cycles to transfer all the AHB information for a dual AHB interface from the microcontroller to the FPGA and vice versa.


11. Timing for read/write transfers with direct FPGA interface.
(Click this image to view a larger, more detailed version)

The timing related to a transfer happening between the ARM7 MCU and the FPGA is as follows:

  • t1: Time for a standard 2 cycles AHB
  • t2: Time to transfer the request to FPGA (4 cycles single AHB interface, 8 cycles dual AHB interface)
  • t3: Time for FPGA-Peripheral response
  • t4: Time to transfer response back to CAP7E (4 cycles single AHB interface, 8 cycles dual AHB interface)
  • t5: Time to read back the response/data from FPGA to the internal CAP7E AHB bus
  • t6: Time for introduced wait cycles

The following formula is used to approximate the access time, from the ARM to the peripherals in the FPGA:

Taccess = t1+ t2 + t3 + t4 + t5

Note: t1 and t5 are AHB cycles that could be ignored for comparison to PIO and EBI timings.

Conclusion
In situations where the data rate is low, such as a dot matrix LCD, an interface the MCU to the FPGA through the PIO or the EBI is sufficient. However, a high data rate between the FPGA and the MCU, or between some other peripheral and the memories, could monopolize CPU cycles and create bottlenecks on the peripherals. For example, a TFT LCD graphics color will require substantial amount of data to be transferred from the frame buffer to the LCD that would most likely completely overwhelm both the CPU and the EBI. This kind of application will perform better with direct interface from the MCU to the FPGA, while allows the LCD data to be transferred over the DMA, keeping the processor free for processing and the EBI free for other data transfers, such as the main application software running from flash, or in the case of the TFT LCD the usage of SDRAM for single or multiple frame buffers.

In addition, the logic defined in the FPGA on the AHB appears to the MCU as if it "inside" the MCU. This makes migration to a customizable microcontroller an easy future design path.

Development time is also shorter with a direct FPGA interface because the interface is already defined inside the microcontroller and the logic module for the FPGA is provided by the MCU vendor. The designer does not need to write any interface RTL. A microcontroller with a dedicated FPGA interface is likely to improve overall system performance and ease of design.

Rocendo Bracamontes del Toro received his bachelor's degree in electrical engineering from Tecnologico Cd. Guzman, Jalisco Mexico in 1997 and his master's degree in computer and electrical engineering from John Hopkins University, Baltimore, Maryland in 2003.

Rocendo can be contacted at

rocendo.bracamontes@atmel.com.

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

출처: http://www.pldesignline.com/howto/209900533