FEATURE STORY

임베디드 프로세서 산업동향

40 임베디드 시스템의 브레인 RISC 프로세서 재조명디지털 가전기기의 멀티미디어화와 모바일화가 급속히 진행되고 있는 가운데 PDA, 휴 폰, 가정용 게임기, 디지털카메라,

셋톱박스 등 다양한 유형의 첨단 제품 출시가 봇물을 이루고 있다. 임베디드 RISC 프로세서는 이러한 기기의 핵심 부품으

로서 고성능, 저전력, 저가격화가 동시에 요구된다. 따라서, 임베디드 시장을 선점하기 위한 고효율과 고성능을 동시에 만족

하는 아키텍처 개발에 관련업체들이 전력 투구하고 있다.

44 임베디드 프로세서의 르네상스전체 프로세서 시장에서 임베디드 프로세서가 차지하고 있는 시장 점유율은 얼마나 될 것인가? 과장된 표현이긴 하지만, 일

부 99% 이상이라는 사람도 있다. 여기서 필자는 이러한 수치의 진위를 따지기보다는 단지 과장돼 보이는 결과가 나온 배경

에 주목하고자 한다. 간단히 우리 주변을 둘러보자. 가정에 컴퓨터는 통상 한 내지는 많아야 3 정도. 즉, 한 가정에 인

텔이나 AMD의 마이크로프로세서가 많아야 3개라는 것이다. 반면, 임베디드 프로세서는 그 수를 가늠하기조차 쉽지 않다.

이제 그 임베디드 프로세서의 격전장으로 들어가보자.

: 윤범진 기자/bjyoon@techworld.co.kr

PRODUCT UPDATE

10 Parvus, 임베디드 이더넷 스위치

싸이프레스 코리아, USB 내장 호스트 컨트롤러

싸이네텍, Isolation feedback signal canceller

자일링스, 90nm FPGA 지원 ISE 5.2i 소프트웨어

내셔널 세미컨덕터, 고주파수 부스트 레귤레이터

애질런트 테크놀러지스, 실시간 네트워크 복구 솔루션

멘토 그래픽스, 차세 디자인 합성 툴 PrecisionTM Synthesis

마이크로칩, 500mA 동기식 벅 DC-DC 컨버터

STMicroelectronics, 8-bit 임베디드 플래시 마이크로컨트롤러

엘텍인스트루먼트, 윈도우 기반 데이터 획득 시스템

TI 코리아, 모바일용 배터리 연료 게이지 IC

NI, PXI 플랫폼용 주파수 소스

아나로그디바이스, 휴 전화용 RF 전력증폭기

텍트로닉스, 자동 비디오 신호 분석기

아기어 시스템스, 802.11a/b/g 지원 멀티모드 칩셋

세이코 엡손, 건전지 누액 책용 전압 검출기 IC

IR 코리아, 120W 출력 DC-DC 컨버터

AROUND THE EMBEDDED

24 임베디드 프로세서 신흥세력 급부상- Configurable 프로세서로 틈새시장 공략 강화

31 멀티서비스프로세서업체 BRECIS, 국내 상륙- 보안기능 강화된 IEEE 802.11a/b/g 응 프로세서 거 발표

32 임베디드 소프트웨어 날개를 달다- 임베디드 S/W 산업협의회 본격 활동

Real-Time

Real-Time

Real-Time

e-Magazinewww.embeddedworld.co.kr

더 이상Digital Divide는없어야합니다.

더 많은 정보 수요자에게

더 알찬 정보를

더 저렴한 가격에 제공하고자 최선을

다하겠습니다.

경제적인 부담 없이

가장 빠른 시간에 받아보실 수 있는

Embedded World의 Online판

e-Magazine을 클릭 하세요.

33 임베디드 S/W 산업 협의회 창립 기념 세미나- 표준화 기술 선점, 시장 활성화 한 목소리

THE COMPANY

ATIONAL INSTRUMENTS

51 모델링에서 생산까지 전공정으로 확장

TECHNICAL FEATURE

52 소프트웨어 분석∙설계 도구, UML(하)- UML에서 사용되는 다이어그램

58 SystemC 기반의 TLM을 이용한 하드웨어/소프트웨어 초기 동시 디자인

64 Velos를 예제로 한 RTOS INSIDE ①- 개괄 및 쓰레드 관리

72 임베디드 시스템 엔지니어를 위한 리눅스 커널 분석 ②- Makefile 분석

Firmware Application

76 마이크로프로세스 응용 엔지니어를 위한 ANSI C ④- 함수/전처리기

92 Qt/Embedded를 이용한 임베디드 리눅스 프로그래밍 ②- Qt/Embedded 프로그래밍 1

SPECIAL CORNER

104 한국형 모바일 표준 플랫폼 WIPI Programming ③- UI Component를 이용한 GUI Programming

PRODUCT FEATURE

124 기능 설정이 가능한 프로세서 코어- 텐실리카의 Xtensa

Xtensa 프로세서는 자체 기능 설정 및 확장, 회로 합성이 가능한 프로세서 코어로서 임베디드 시스템온칩(SoC)에 적용하

려는 응용 프로그램을 위해 설계된 마이크로프로세서 아키텍처이다. Xtensa 프로세서는 처음부터 기능 설정이 가능하도록

창안되었기 때문에 설계자들이 직접 적당한 작업을 해서 목표 SoC에 맞게 응용 프로그램을 설계할 수 있도록 되어 있는

것이 특징이다.

130 SysProbe를 이용한 SoC 인터커넥트 성능 분석- STi5517 SoC의 Static SysProbe 사용예

시스템온칩(SoC)이 복잡해지면서 원하는 성능의 인터커넥트를 디자인하는 것이 쉽지 않은 일이 되었다. 이 에서는 인터

커넥트 성능을 평가하는 데 이용할 수 있는 툴과 방법론을 알아본다. 현재 여기에 이용할 수 있는 솔루션이 시중에 나와 있

지 않은 실정이다. 이러한 용도로 이용할 수 있도록 STMicroelectronics가 개발한 툴 및 방법론이 SysProbe이다.

OTHERS

6 EDITOR COMMENT

8 COMING EVENTS

135 New Literature & Books

Volum NO.4 April 2003

임베디드 관련 세계최고 권위

테크월드 / 전시사업부Tel : 02)835-2100 / FAX : 02)835-2166

임베디드시스템개발자를위한세계최고의박람회

SAMSUNG, ARM, MICROSOFT, MOTOROLA 등세계임베디드산업을선도하는업체들 거참가.

�참관단 모집

�카탈로그 홍보관 참여 업체 모집

�“Embedded World” 문판 잡지 광고 모집

해외전시사업부 담당:윤지완실장

Tel : 02)753-0011 / Fax : 02)773-1320 www.dongyangtour.com

Dong Yang

MMore 16, 17page

6

EDITOR COMMENT

미국과 이라크 간의 긴장이 일촉즉발의 전쟁 분위기로 치닫고 있다. 혹시 이 이 나갔을 시점에는

화염에 휩싸인 바그다드를 보게 될 지도 모른다. 이 순간 세계의 관심은 죽느냐 사느냐 하는 생사의 갈

림길에 직면해 있는 다수 이라크 국민들의 처지보다는 미-이라크 전쟁이 세계 경제에 미칠 향과

자국의 경제적 득실에 더 쏠려있다. 선과 악에 한 미국의 자의적인 기준이 어느 덧 보편적 기준으로

묵인되고 있는 듯한 느낌마저 든다. 어찌되었든 우리는 임박한 미국과 이라크 간의 전쟁을 앞두고 우리

경제에 독이 될 것인지, 아니면 약이 될 것인지 생각해 보지 않을 수 없는 상황이다. 당장은 침체된 세

계 경기의 회복을 지연시킬 것이라는 데는 견해가 일치하는 듯하다. 하지만, 결과적으로는 세계 경제를

견인할 것이란 의견이 지배적이다. 여기에는 세계 경제가 위기를 통해 더욱 견실해졌다는 경험적 학습

논리가 작용하고 있다. 1929년 공항의 여파로부터 탈출의 단초를 제공한 사건이 역설적이게도 제2차

세계 전이었다. 또한 미국은 1960년 베트남 특수를 통해 미국경제 역사상 최장의 호황을 누렸다.

우리나라도 베트남전의 수혜국이었음을 인정하지 않을 수 없다. 가장 최근의 사건인 90년 걸프전쟁

은 미국 경제를 10년에 걸친 장기호황의 초석을 마련해 준 미국의‘성전(盛戰)’이었다. 이러한 사실을

통해 미국은 이번에도 치 한 계산 하에 미-이라크 전쟁을 감행할 가능성이 높다. 문제는 급박하게 돌

아가는 국제사회의 흐름 속에서 우리도 자유로울 수 없다는 것이다.

우리의‘위기관리 능력’에 한 평가는 체로 회의적이다. 따라서, 미-이라크 전쟁에 따른 철저한

응이 없다면 사태의 심각성은 문제 그 이상의 문제로 표출될 가능성이 높다. 이제 막 국정업무를 시

작한 노무현정권의 위기관리 능력이 이번 미-이라크 전쟁을 통해 평가받게 되겠지만, 우리 국민들의

자세도 이제는 달라져야 한다. 과거와 같이 우리 경제가 어려울 때마다 우연하게 찾아왔던 외환경의

호재가 이번에도 찾아오겠지 하는 안일한 생각은 버려야 한다. 우리는 최악의 시나리오까지 상정하여

미-이라크 전쟁을 역으로 활용할 수 있어야 할 것이다.

필자는 우리 경제적 현실 앞에서 인류의 보편적 가치에 한 물음에 아무런 답변도 하지 못했다. 미-

이라크 전쟁은 무고한 생명의 희생을 담보로 한다. 그럼에도 불구하고 전쟁을 통해 이해득실을 따지고

기회요인을 찾아야 한다는 냉엄한 현실 앞에 한없이 초라함을 느낀다. 누구에게나 하나 뿐인 생명은 소

중한 것이다. 자신의 이득을 취하기 위해 다른 사람의 생명을 무참하게 취하는 것은 용서받지 못할 일

이다. <윤범진>

경제의 빨간불, 생명의 빨간불

8

COMING EVENTS

Windows CE 임베디드 시스템

개발 및 구현기술

강 사: 이봉석 표(하제소프트)

교육일정: 2003년 4월 7일�11일

시 간: 09:30�17:30

장 소: 과학 기술 정보 연구소 연수실

인 원: 30명

수 강 료: 44만원

▶강좌내용

▶수강 신청: 02-2636-0301

홈페이지 http://www.stii.co.kr

CDMA(DS-SS) 통신 시스템 기술 및 적용사례

강 사: 과학기술정보연구소 전문위원

교육일정: 2003년 4월 17일�19일

시 간: 09:00�18:00

장 소: 과학 기술 정보 연구소 연수실

인 원: 30명

수 강 료: 22만원

▶강좌내용

▶수강 신청: 02-2636-0301

홈페이지 http://www.stii.co.kr

S/W 프로세스 개선을 위한

프로세스 리엔지니어링 전문가[한국생산성본부]

교육일정: 2003년 4월 15일�5월 24일

시 간: 매주 화,목(18:30�21:30), 2/4주 토(09:30�

16:30)/ 총 50시간

장 소: 광화문 소재 한국생산성본부

인 원: 34명

수 강 료: 76만원

▶강좌내용

CMM Introduction

S/W 프로젝트 관리

소프트웨어 품질관리

S/W Measurement & Function Point Analysis

S/W Inspection, Testing

S/W Configuration Management

6시그마를 활용한 프로세스 개선

S/W 프로세스 리엔지니어링(CMM도입 및 프로세스 개선

을 위한 가이드라인)

▶수강 신청: 02-724-1216

이메일 tyoh@kpc.or.kr

홈페이지 http://www.kpccisa.net

국제 표면실장 및 인쇄회로기판 생산기자재전

주 최: ㄜ전자신문사, Reed Exhibitions

주 관: 뉴세스

장 소: COEX 서양홀

기 간: 2003년 4월 8일�4월 10일(10:00�17:00)

전시품목: SMT, PCB, 전자부품 등 전자산업 관련 생산기

자재 및 검사기/COEX

입 장 료: 3,000원

전화문의: 02-555-7153

이메일 siyun@kfairs.com

홈페이지 http://www.smtpcb.org

1 일차 Windows CE Target 보드 구조 및 기능분석

Windows CE 일반

2 일차 Platform Builder 4.x

디바이스 드라이버 일반

3 일차 Native 디바이스 드라이버 작성

4 일차 스트림 인터페이스 디바이스 드라이버 작성

5 일차 기타 디바이스 드라이버 작성

1 일차역확산 통신 시스템 일반 및 기술동향

동기(Synchronization)기술

2 일차CODE GENERATION

CODING & MODULATION/DEMODULATION 기술

3 일차이동통신 시스템의 CDMA 적용기술

역확산통신을 이용한 시스템 개발사례

10

PRODUCT UPDATE

Parvus

임베디드 이더넷 스위치제품문의: (801)483-1533

Parvus Corporation(www.

parvus.com)은 자사의 10/100 이더

넷 스위칭 허브가 임베디드 네트워크

제어 및 데이터 획득 애플리케이션에

해 보다 광범위한 어레이를 수용하

기 위해 4개의 다른 컨피규레이션을

이용할 수 있게 되었다고 발표했다.

이 고성능 5포트 네트워크 스위치

는 10BaseT 또는 100BaseTX 이더

넷 접속으로 임베디드 컴퓨팅 장치를

5개까지 연결할 수 있으며, 가격은

100+개 주문 시 개당 134달러이다.

3.550″×3.775″크기의 10/100

이더넷 스위칭 허브는 PC/104 기반

시스템을 위한 두 가지 컨피규레이션

과 어떤 임베디드 컴퓨터 환경(Com-

pact PCI, VME, PMC, ETX, DIMM

-PC, ISA 등)과도 동작하도록 디자

인된 2개의 추가 모델을 제공한다.

이더넷 접속은 온보드 RJ-45 잭 또

는 직각 몰렉스(Molex) 커넥터로 연

결된다.

이 임베디드 이더넷 스위치의 각

버전은 5개의 auto-configurable

10/100 트랜시버 포트 및 독립적인

고속 이더넷 MAC(media access

controller) 뿐만 아니라 auto-

인터페이스 엔진(SIE), 구성 가능한

I/O 블록 등을 포함하며 주로 모바일

장비가 아닌 셋톱박스, 액세스 포인

트 등에 적용할 수 있다.

모바일 장비용으로 개발된 EZ-

OTG는 EZ-Host의 기능 외에도 시

리얼 인터페이스 엔진 당 1개의 포트

를 가진 2개의 USB SIE와 파워-부

스트 회로를 포함하고 있다. 특히, 이

칩은 휴 형 제품간의 플러그-앤-플

레이(PnP) 접속을 가능케 한다.

두 제품군 모두 애플리케이션을 맞

출 수 있게 하는 16KB RAM과 멀티

플 CPU 인터페이스, USB 프로세싱

부분을 처리하기 위한 온보드 BIOS

를 포함하고 있다.

현재 구입 가능한 EZ-Host와

EZ-OTG는 각각 100핀 TQFP와 48

볼 FBGA로 판매된다.

싸이네텍

Isolation feedbacksignal canceller제품문의: (02)2659-1316

싸이네텍(www.cynetec.co.kr)은

이동통신중계기 내의 간섭파를 직접

제거하는「Isolation feedback

signal canceller」를 발표했다.

이 제품은 CDMA, FDMA, TDMA

방식의 이동통신환경에서 중계기 설

치 시 문제가 되는 음 지역을 획기

적으로 줄일 수 있고 isolation 확보

를 위한 안테나 설치에 따른 제약을

줄일 수 있어 비용을 절감할 수 있다.

이 제품은 중계기 내 수신부에 들어

오는 directed feedback 신호와

multi-path fading에 의한 다중반사

MDI-MDIX 네트워크 구성과 함께

IEEE 802.3 및 IEEE 802.3u와 호

환성을 제공한다. 또한 확장 온도 범

위(-40℃ ~ +85℃) 내에서 동작하며

백프레셔(Backpressure)와 pause

frame flow control 설계를 포함하

는 모든 데이터 트래픽 환경을 위한

논-블록킹(non-blocking) 스위칭

성능을 제공한다.

2개의 PC/104 모델은 PC/104 버

스까지 전력을 연결하기 위해 표준

104핀/소켓 헤더를 포함한다. 또 다

른 2개의 임베디드 스위치 모델은

PC/104 헤더가 필요 없고 외부 전력

을 연결하기 위해 2핀 몰렉스 커넥터

를 포함한다.

싸이프레스 코리아

USB 내장 호스트 컨트롤러제품문의: (02)562-7005

싸이프레스 코리아(www.cypress.

com)는 호스트 컴퓨터 없이 임베디

드 애플리케이션 제품을 서로 연결할

수 있는 USB 내장 호스트 컨트롤러

인「EZ-Host(CY7C67300)」과「EZ

-OTG(CY7C67200)」을 발표했다.

EZ-Host는 16비트 RISC 마이크

로컨트롤러와 시리얼 인터페이스 엔

진 당 2개의 포트로 각각 개별적으로

구성할 수 있는 2개의 USB 시리얼

12

PRODUCT UPDATE

이번에 선보인 「LM2731」과

「LM2733」은 디지털카메라, 휴 전

화, PCMCIA, USB 주변장치, DSL

모뎀 등이 필요로 하는 0.8 cm2 이

하의 PCB 역에서 3W 스텝업 컨버

터를 구현한다.

LM2731은 22V, 1.5A 스위치를 갖

고 있으며 낮은 출력 전압을 위해 최

적화되어 있다. 특히 이 칩은 가변 주

파수 솔루션이 일으킬 수 있는 가청

노이즈, 전기적 노이즈 문제를 원하지

않는 휴 기기에 필요한 전원을 제공

한다. LM2733은 40V, 1A 스위치를

가지고 있으며 높은 출력을 위해 최적

화 되어 있다. 두 제품 모두 2.7V에서

14V 입력으로 동작하며 외장 부품이

최소화되어 높은 파워 도를 제공한

다. LM2731/LM2733 부스트 레귤레

이터는 현재 공급 가능하다.

애질런트 테크놀러지스

실시간 네트워크 복구 솔루션제품문의: (02)2004-5403

애질런트 테크놀러지스(www.agil

ent.com)는 서비스 공급자와 기업

네트워크 운 자들이 LAN, WAN 기

술과 관련해 음성, 모바일, 데이터 등

주요 애플리케이션을 테스트하고 실

시간으로 네트워크 장애를 해결할 수

있는 애질런트 네트워크 트러블슈팅

ISE5.2i는 경쟁 제품에 비해 디자

인 성능이 20% 가량 우수하고 로직

활용도는 15% 높으며 설계 비용은

50% 적게 들기 때문에 전반적으로

시스템 비용을 크게 절감해 준다고

회사측은 밝혔다. 또한 차세 멀티

기가비트 시리얼 I/O 트랜시버 및 저

가형 90nm FPGA를 디자인할 수 있

도록 지원한다.

칩스코프 프로 5.2i 실시간 검증용

소프트웨어는 ISE 프로젝트 네비게이

터와 잘 통합되어 검증 코어를 간편하

게 선택 및 삽입하고 신호모니터 포인

트를 정의하며, 전체 디자인 흐름에 실

시간 디버그 플래닝 기능을 추가할 수

있게 해준다. 또 설계자들은 새 버추얼

I/O 코어를 사용해 DIP 스위치와 버

튼 셋팅을 시뮬레이션 할 수 있다. 또

한 IBA(Integrated Bus Analyzer)

코어는 임베디드 PowerPC 405 프로

세서 기반의 Virtex-II Pro FPGA 상

에서 IBM CoreConnect PLB(Proce-

ssor Local Bus)와 OPB(on-chip

peripheral bus)를 지원할 수 있게 되

었다. ISE와 칩스코프 프로 솔루션의

가격은 각각 695달러 이상이며, 기존

고객들은 즉시 업그레이드를 제공받

을 수 있다.

내셔널 세미컨덕터

고주파수 부스트 레귤레이터제품문의: (02)3771-6900

내셔널 세미컨덕터(www.national.

com)는 600kHz 및 1.6MHz 스위칭

주파수에서 동작하는 SOT23 5핀 패

키지의 부스트 레귤레이터 2종을 발

표했다.

신호를 모듈 내의 RF 역에서 수신

하는 동시에 DSP 블록에서 원 신호와

비교 분석하여 송신신호에 간섭으로

동작하는 신호를 판별하여 직접 제거

한다. 따라서, 기지국 및 이동체에서

송출된 원 신호원을 잡음성분 없이 재

전송이 가능하다. 또한 신호처리를 담

당하는 DSP 블록은 시스템에 따라 항

시 재프로그램 할 수 있으므로 다양한

이동통신 시스템에 유연하게 처할

수 있다고 회사측은 밝혔다.

주요특징

▲ Isolation 보장에 따른 중계기

설치 유연성 확보

▲ 선형성 보장에 따른 안정된 재

전송가능

▲ Donor안테나와 Coverage안테

나 사이의 directed feedback

신호 제거

▲ 다중 반사파에 의한 multi-

path Fading 효과 억제

▲ 사용방식에 따른 Programma-

ble한 특성(TDMA, FDMA

CDMA 등)

▲ 기존의 RF 중계기의 Isolation

문제 해결

자일링스

90nm FPGA 지원ISE 5.2i 소프트웨어제품문의: (02)761-4277

자일링스(www.xilinx.com)는 디

자인 툴인 ISE(Integrated Software

Environment) 5.2i 최신 버전과 함

께 실시간 검증용 툴인 칩스코프 프로

(ChipScope Pro) 5.2i를 발표했다.

14

PRODUCT UPDATE

디자인 성능을 제공해 디자인 성능을

최 한 높일 수 있다.

마이크로칩

500mA 동기식 벅DC-DC 컨버터제품문의: (02)554-7200

마이크로칩 테크놀로지(www.

microchip.com)가 배터리 혹은 버

스 전압을 시스템 요건에 맞게 보다

효과적으로 변환시킬 수 있는 컨버터

를 내놨다.

신제품 MCP1601은 다양한 입출력

조건에서 작동할 수 있는 500mA,

DC/DC 동기식 스텝다운 컨버터로

이동전화기, PDA, 디지털 카메라,

USB 지원 디바이스 등 다양한 제품

에 사용된다. 3가지 모드로 동작하며

주어진 입출력 조건에서 최 한의 효

율 곡선을 지원할 수 있도록 세 모드

간 자동 전환이 가능하다.

세가지 동작모드는 통상적인 부하

조건이 중간 혹은 그 이상인 경우

PWM(pulse width modulation),

확장 시간에서 부하조건이 가볍거나

아예 없는 경우 PFM(pulse freque-

ncy modulation), 입력이 출력전압

에 근접할 경우 LDO(low-drop-

out mode) 이다.

MCP1601 DC/DC 컨버터는 변환기

회로를 보호하기 위해 UVLO(under

-voltage lockout), 과열, 과전류 같

은 안전기능을 포함하고 있다.

STMicroelectronics

8-bit 임베디드 플래시마이크로컨트롤러제품문의: (02)588-9030

STMicroelectronics(이하 ST)는

이번에 ST7Lite1과 ST7FLite2 제품

을 출시했다.

이 제품은 확장된 저가형의 고집적

8비트 임베디드 플래시 마이크로컨트

롤러로 ST7Lite 제품군의 성능을 기

반으로 설계되었다. ST의 특허 기술

인 확장형 플래시(Extended Flash)

기술을 기반으로 하 다.

제품은 ST7Lite 시리즈의 특징은

읽기/쓰기 방지 기능을 포함한 플래

시 프로그램 메모리뿐 아니라 고집적

고정 1MHz 1% RC 오실레이터, 저

전압 감지(LVD : Low Voltage

Detection) 기능을 갖춘 고집적 리셋

회로 및 변환 시간이 3.5μs인 7채널

10-bit ADC 기능이 제공된다.

또한, 소프트웨어 제어를 이용해 프

로세싱 전력비에 한 전력소모 모드

를 선택할 수 있도록, 1μA의 전력이

소모되는 HALT 모드와 15μA 전력이

소모되는“HALT에서의 자동 웨이크

업(Wake Up)”모드 등 총 5개의 저

전력 모드가 있다.

이 시리즈의 첫 제품인 ST7FLite0

은 16핀 패키지에 1.5Kbytes 플래시

메모리를 내장한 제품으로 현재 양산

되고 있으며, ST는 빠른 시일 내에

센터(NTC)를 출시했다.

이 NTC는 장애 분리와 해결 성능

이 개선되었고 네트워크 엔지니어들

이 단일 중앙 지역에서 장애 해결 접

속을 하도록 함으로써 새로운 서비스

를 수행할 때 소요되는 시간을 단축

한다. 또한 자세한 트러블슈팅 정보

를 제공하기 위해 지난해 1월에 출시

한 애질런트 네트워크 애널라이저 제

품과 사용이 가능하다.

멘토 그래픽스

차세 디자인 합성 툴PrecisionTM Synthesis 제품문의: (02)551-3434

반도체자동화설계툴(EDA) 업체인

멘토그래픽스(www.mentorkr.

com)는 최근 자사의 차세 디자인

합성 툴 제품군을 발표했다.

이들 제품은 Precision RTL

Synthesis, Precision Physical

Synthesis, Precision C Synthesis

의 합성 제품으로 구성됐다.

Precision 제품군은 프로그래머블

로직 디바이스(PLD) 및 차세

FPSoC 디바이스의 기능을 극 화,

고성능의 디자인 성능을 보장해 준

다. 초기 디자인 설계에서부터 검증,

시스템 통합, 그리고 IP(Intel-

lectual Property) 코어에 이르기까

지 광범위한 스펙트럼을 제공해준다.

또한 사용자 편의를 고려한 쉬운

유저 인터페이스와 디자인 플로, 만

족스러운 디자인 결과, 진보적인 디

자인 분석 특징 등을 갖춤으로써 디

자인 합성 환경을 구성한다.

특히, FPGA 디자인을 위한 향상된

18

PRODUCT UPDATE

저가형 메모리와 새로운 패키지 크기

를 갖춘 제품을 선보여 ST7Lite 마이

크로컨트롤러 제품군을 지속적으로

확장시킬 계획에 있다.

엘텍인스트루먼트

윈도우 기반 데이터 획득시스템제품문의: (032)577-7555

R&D에서 생산까지 측정 검사 시스

템 및 소프트웨어 개발 전문업체인 엘

텍인스트루먼트(www.ltech.co.kr)

는 윈도우 환경에서 운 되는 데이터

획득 시스템(제품명 WinDAQ) 및 무

료 소프트웨어를 출시했다.

이번에 발표한「WinDAQ」는 채널

확장이 용이해 카드를 추가하여 시스

템을 구성하기만 하면 WinDAQ 소프

트웨어의 모든 기능을 사용할 수 있다.

이 제품은 110kHz 샘플링 속도(최

3MHz)/16채널(최 128채널), 12

비트 분해능(최 16비트), ±0.6�±

10까지 입력 선택 가능, 16개의 BNC

커넥터 등을 특징으로 한다. 또한 37

핀 D-SUB 커넥터로 스크류 터미널

보드를 사용할 수 있으며, 온도∙소

음∙하중 등 다양한 종류의 신호조건

모듈을 포함하고 있다. 이외에도 마

우스 없이 조작할 수 있도록 15인치

TFT-LCD 터치 모니터를 옵션으로

선택할 수 있으며 인터넷 연결이 가능

하다.

bqJunior는 배터리 방전율과 온도

변화에 따른 잔여 배터리 용량 및 동

작시간을 보상하는 기능과 데이터 셋

연산을 수행하므로 호스트 프로세서

에서 별도의 코드를 개발할 필요를 없

애준다. 또한 데이터 셋 정보를 TI의

OMAP1510이나 OMAP5910 애플리

케이션 프로세서에 전달하기 위한 통

신 포트(HDQ 프로토콜)를 탑재하고

있다.

소모전류가 100mA 이하인 bqJu-

nior는 현재 샘플 공급되고 있으며

양산은 오는 2사분기로 예정되어 있

다. 패키지는 8핀 TSSOP나 QFN

(3mm×4mm)를 사용한다.

NI

PXI 플랫폼용 주파수 소스제품문의: (02)3451-3433

NI(www.ni.com/korea)는 PXI

모듈형 제품군에 고 주파수 사인 및

클록 출력을 생성할 수 있는 제품을

추가했다.

이번에 소개한 NI PXI-5404

100MHz 주파수 소스는 1.07μHz의

분해능과 ±0.2dB의 사인 레벨 정확

도에서 최 100MHz로 사인 및 클록

출력을 동시에 생성할 수 있다. 이 제

품의 유연한 클록 출력 레벨은 TTL과

확장성이 뛰어난 WinDAQ는 최

5개까지 멀티보드를 지원하며, 실제

하드웨어에 응되는 물리채널에 연

결되는 가상채널로 하나의 물리채널

로부터 얻어진 데이터를 여러 개의 가

상채널을 통해 다양한 형태로 표현이

가능하다. 그래프는 타임 그래프 20

개, X-Y 그래프 5개까지 각각 추가

할 수 있다. WinDAQ를 통해 획득한

데이터는 원하는 채널 데이터만

WinDAQ 파일이나 Excel 및 Text

파일로 저장할 수 있으며 그래프 인쇄

도 가능하다.

이윤원 사장은“WinDAQ는 복잡하

지 않은 기능으로 작업 속도가 빠르고

필요한 기능만 구현하여 저렴한 가격

에 공급할 수 있게 되었다”면서“사용

자층의 확보와 기능 보완을 위한 현장

의 목소리를 듣기 위해 소프트웨어를 1

년간 무료로 공급할 것”이라고 말했다.

TI 코리아

모바일용 배터리 연료게이지 IC 제품문의: (02)551-2836

TI 코리아(www.ti.com)는 2.5/3G

모바일 핸드셋과 PDA의 잔여 배터리

용량 및 남아 있는 시스템 동작시간을

계산할 수 있는 프로세서를 탑재한 배

터리 연료 게이지 IC(모델명 bq2700x,

bqJunior)를 발표했다.

이 제품은 단일 셀 리튬이온 및 리

튬 폴리머 배터리팩에 사용되는 완전

통합형 IC로, 배터리의 충방전 전류

를 옵셋이 작은 VFC(Voltage-to-

Frequency Converter)를 이용하여

1% 이내의 오차로 측정한다.

20

PRODUCT UPDATE

CMOS 기술 모두에 응한다.

PXI-5404 주파수 소스는 사인 진

폭을 1Vpp�2Vpp 범위로 조절할 수

있고 12비트 수직 분해능을 가지고

있으며, 위상고정루프(PLL)를 통해

PXI 시스템이나 고속 디지타이저와

같은 장치에 동기화 시킬 수 있다.

이 제품은 IVI 호환 기기 드라이버

인 NI-FGEN이 함께 제공된다. 따

라서 NI-FGEN 소프트웨어에서 사

용할 수 있게 된 시뮬레이션 모드를

사용하여 테스트 및 설계 엔지니어

는 시스템에 NI PXI-5404 하드웨

어 없이도 애플리케이션을 자유롭게

개발하고 프로토타입을 제작할 수

있다.

아나로그디바이스

휴 전화용 RF 전력증폭기제품문의: (02)554-3301

아나로그디바이스 코리아(www.

analog.com)는 4 역 GSM(E-

GSM, GSM-850, DCS, PCS)과

GPRS 표준을 지원하는 RF 전력증폭

기(PA) 모듈인 X-PA™의 새 모델을

출시했다.

이번에 출시한「ADL5551」은 낮은

출력 수준에서도 효율성이 높은 폐쇄

루프 출력 전력 제어 기능이 통합돼

기존의 개방루프 전압 전류 감지 방식

에 비해 20% 이상 배터리 전력을 줄

다. 또한 가변부하(VSWR)가 나쁜

상황에서도 우수한 특수흡수율(SAR)

과 향상된 전화기 성능을 구현할 수

있도록 지원한다. 이밖에도 단 하나

의 램프 프로필로 모든 전력 수준의

GSM 마스크 규격을 충족시킨다. 최

신 GaAs HBT PA 공정기술이 채택

된 이 제품은 각 역별로 단 하나의

교정점만 필요하기 때문에 시장출시

시기를 앞당기고 제조비용을 낮출 수

있다.

ADL5551은 2.9�4.5V 전원에서

동작하며 10mm×10mm×1.4mm

LCC 패키지로 현재 양산되고 있다.

텍트로닉스

자동 비디오 신호 분석기제품문의: (02)528-0719

텍트로닉스(www.tektronix.com)

는 완전 자동화된 HD(High Defini-

tion)용 비디오 신호 분석기를 출시했다.

이번에 출시한「Tektronix VM50

00HD」는 업계 표준 비디오 파라미터

를 활용하여 1080i, 720p, 480p,

SXGA 등의 형식에서 빠르고 반복 가

능한 비디오 측정이 가능하다.

특히 VM5000HD는 한 번의 단추

조작만으로 8가지의 특정 테스트 범

주에서 10초 이내에 100가지의 서로

다른 파라미터 측정이 가능하다. 또

한 개발팀, 생산 라인, 소비자 테스트

시설 등을 망라해서 통일된 단일 표

준 측정 도구로 활용할 수 있어 테스

트 방법을 간소화하고 표준화할 수

있다.

이 제품은 색상 막 , 멀티버스트,

스윕 및 기타 5가지의 신호 형식을 포

함하는 표준화된 테스트 신호의 생성

을 위해 고유한 HD 매트릭스 테스트

신호 세트를 제공하기 때문에 Y/Pb/

Pr 및 RGB 색상 역에서 테스트할

수 있다. 또한 DVD와 CD-ROM이

조합된 상황에서도 사용할 수 있는

VM5000HD는 압축 여부와 관계없

이 사용할 수 있다.

VM5000HD는 다양한 포맷으로

기준 신호를 제공하기 때문에 이 신호

세트는 모든 기기 조작상의 문제 또는

입력 테스트 신호의 품질에 한 의문

에서 발생하는 우려 등을 제거했다.

게다가 신호 세트를 사용할 경우 시그

널 제너레이터를 선택하는 문제에 있

어서 단히 유연성 있게 선택할 수

있다.

아기어 시스템스

802.11a/b/g 지원멀티모드 칩셋제품문의: (02)767-1808

아기어 시스템스(www.agere.com)

는 IEEE 802.11a/b/g 표준을 모두 지

원하고 구성부품수도 기존 제품의 절

반에 불과해 보드 사이즈와 비용을 크

게 줄인 무선랜 웨이브랜(WaveLAN)

22

PRODUCT UPDATE

칩셋 솔루션을 발표했다.

이번에 발표한 칩셋 솔루션은 듀얼

밴드 RF 트랜시버(WL54040), 멀티

모드 MAC(WL60040), 멀티모드 베

이스밴드 프로세서(WL64040),

SiGe 기반의 듀얼밴드 전력증폭기

(WL54240) 등 4개 칩으로 제공된

다. 이와 함께 아기어는 평가보드, 참

조 설계, 펌웨어, 소프트웨어 드라이

버, 인증 유틸리티, 제조 테스트 소프

트웨어 등을 지원한다.

WL54040은 0.25㎛ BiCMOS 기

술로 제조되며 5GHz와 2.4GHz

역에서 작동하고 802.11g 드래프트

표준까지 지원한다. 이 칩은 디바이

스가 OFDM용 Low-IF와 CCK용 다

이렉트다운 변환 사이의 자동적 스위

칭을 가능케 하여 시스템 성능을 개선

한다.

0.2㎛ CMOS 기술로 제조된

WL60040은 칩셋용 액세스 컨트롤

러와 데이터 관리 기능을 제공한다.

이것은 802.11a/b를 비롯해 드래프

트 g와 h 표준에 모두 호환되며, 보안

과 서비스 질을 위한 드래프트

802.11i와 e 표준도 지원한다.

WL64040은 0.13㎛ CMOS 기술

로 제조된 것으로, OFDM과 CCK 모

듈레이션용 신호 처리 기능을 포함하

고 있으며, 아기어의 특허기술인 안

테나 설치를 지원한다.

WL54240은 2.4와 5GHz 역과

온칩 전력 검전기용 아날로그 전력 컨

트롤을 포함한다.

아기어는 2사분기부터 실리콘 샘플

을 공급할 계획이다.

세이코 엡손

건전지 누액 책용전압 검출기 IC 제품문의: (02)784-6027

세이코 엡손 (주)한국지점(www.

epson-device.co.kr)은 동작전압 범

위 이하에서도 건전지의 누액 책을 보

증하는 저소비 전류 검출기(detector)

인「S1F77600」을 출시했다.

이 제품은 검출전압 이하에서 출력

이 강제적으로 고 임피던스(High

Impedance)가 되어 시스템을 정지

시키는 것으로, 누액으로 연결되는

과방전을 방지할 수 있다. S1F77600

은 건전지 직렬 2셀을 전원으로 하는

모바일 제품에 적합하다.

현재 샘플 및 양산 공급되고 있는

이 제품은 ▲동작전압 0.8�5.5V ▲

검출전압 1.2�1.6V(마스크 옵션) ▲

검출전압 정 도 ±3.5%(+25℃) ▲

히스테리시스 폭 0.2�1.0V(마스크

옵션) ▲소비전류 5.0μAMax. ▲출력

형태 P-ch/N-ch 오픈 드레인(마스

크 옵션) ▲ 패키지 SOT89-3핀 등을

특징으로 한다.

IR 코리아

120W 출력 DC-DC 컨버터제품문의: (02)858-8773

인터내셔날 렉티파이어 코리아

(www.irf.com)는 신뢰성이 강화된

DSCC SMD 인증의 120W 출력

DC-DC 컨버터 2종을 출시했다.

이 제품군은 열악한 동작환경과 극

한의 온도범위에서 사용할 수 있도록

설계되었으며, 소형∙경량화를 중요시

하는 신규 플랫폼 설계에 적합하다.

이번에 출시한「AFL12005S」컨버

터는 5V 출력시 동급 타사 제품 비

약 25% 많은 전력을 전달하여 최

80%의 효율을 제공하며, 「AFL12003

R3S」컨버터는 3.3V 출력시 최

72%의 효율을 제공한다고 회사측은

설명했다.

이 제품은 최근 시장수요에 따라 전

류 스트레스 공유와 최 80W/in2의

고전력 도를 갖는 병렬동작이 특징이

다. 표준 단일 출력 컨버터의 전압범위

는 3.3V에서 28V이며 표준 듀얼 출력

전압은 ±5V, ±12V, ±15V이다.

AROUND THE EMBEDDED

24

국내 범용 임베디드 RISC 프로세서

시장의 리더로 등극한 ARM (www.

arm.com)의 입지를 흔들 수 있는 도전

자들의 움직임이 심상치 않다. 미국 실

리콘 밸리의 벤처로 출범하여 최근 몇

년 사이에 50개 혹은 100개 이상의 고

객 기반을 확보하고 이제 한국, 만,

일본을 비롯한 아시아 시장으로 눈을

돌리기 시작한 텐실리카(Tensilica,

www.tensilica.com)와 ARC(ARC

International, www.ARC.com)가 그

주인공. 최근 미국 몬태나에서 열린 로

벌 프레스(Global Press) 주관『Elec-

tronics Summit 2003』에 패널리스트

로 참석한 ARC사와 텐실리카사 CEO의

얼굴에서 비장함을 엿볼 수 있었다.

이들 회사의 강점은 범용 임베디드 프

로세서를 보완, 체할 수 있는 appli-

cation specific configurability를 무

기로 IP, RTOS, 디버거 등의 공급자

수를 줄임으로써 타임투마켓을 단축할

수 있다는 것. 말하자면 지금까지 고객

사가 SoC 칩을 설계하기 위해서는 IP

를 여러 벤더에게서 구매하고 RTOS,

컴파일러, 디버거 또한 다른 벤더에게

서 따로따로 구매해야만 했던 반면

ARC와 텐실리카는 고객이 직접 원하는

로 코어 칩을 설계할 수 있는 기술과

소프트웨어 개발 툴 등을 단일 패키지로

제공, 벤더 수를 줄일 수 있다는 것. 고

객이 코어 칩 설계 단계에서 용도에 따

라 선택할 수 있는 Configurability를

무기로 ARC와 텐실리카 같은 벤처기업

이 주목을 받는 것은 그만큼 다양한 칩

설계 활동, 빨라진 개발 라이프사이클,

application-specific extension 등

을 요구하는 최근 기술 추세와 무관하

지 않다.

텐실리카의 베이스 프로세스의 경우

는 RISC도 아니고 CISC도 아니면서

두 개의 장점만 취한 하이브리드 구조

로 되어있다. 즉, 단일 베이스 아키텍처

상에서 CISC의 장점인 다양한 레이어

구축(variable layer construction)이

가능하고 RISC의 강점인 코드 사이즈

도 줄일 수 있다. 애플리케이션에 따라

RISC 특징만 나타나기도 하고 CISC의

특징만 나타나기도 한다. 유저의 사용

용도에 따라 구조를 커스터마이즈 할 수

있다는 얘기. 텐실리카의 크리스 로웬

(Chris Rowen) 사장(사진 1)은“RISC

냐 CISC냐 하는 선택의 틀을 깨고 둘의

강점만을 살리면서도 사용자가 필요한

로 프로세서를 선택할 수 있는 유연성

을 제공한다”고 설명한다.

한편, 짧은 기간에 Configurable

SoC 플랫폼 기술의 다크호스로 등장

한 ARC의 상 우위는 가장 광범위한

최종 제품(end-product) 카테고리에

적용될 수 있는 기술군을 갖추고 있다

는 데 있다. 1996년에 국에서 설립

된 ARC사는 user-customizable

32-bit RISC/DSP 프로세서를 중심

으로 통합 개발 툴, 주변장치, RTOS,

시스템 소프트웨어 등 풀 패키지를 제

공하고 있다. 이 회사는 이처럼 임베디

드와 SoC 시장에 필요한 전 제품을 원

스톱 쇼핑으로 제공함으로써 궁극적으

로 고객사의 타임투마켓을 향상시킬

수 있음을 역설한다.

ARC사의 마이크 굴레트(Mike

Gulett) 사장(사진 2)은“ARM과의 경

쟁은 ARC가 이미 진입해 있는 광범위

한 기술군 중에서 일부분만을 차지한

다”면서“ARC의 경우 ARM과 달리

디자인 기준의 라이선스를 적용하기

때문에 상 적으로 적은 라이선스 비

용 부담으로 싱 칩 혹은 멀티플 칩

설계를 선택할 수 있다”고 말했다. 즉,

ARM의 범용 프로세서 라이선스 계약

처럼 몇 백만 달러를 주고 시작하는 초

기 부담을 줄일 수 있다는 얘기. 이어

굴레트 사장은“고객들은 다섯 개까지

칩 디자인을 선택할 수 있으며 칩 설계

단계에서 고객이 스스로 설계 내용을

원하는 로 변경할 수 있다. 또한 고객

이 선택한 확장가능성(extensibility)

실현 및 기술의 프로세스를 이용할 수

있다”고 강조했다.

반면, 1997년 설립 이후 Confi-

gurable 마이크로프로세서 부문 선두

주자로 떠오르고 있는 텐실리카의 크리

스 로웬 사장은 ARM사와의 경쟁관계

보다는‘보완 관계’로서 ARM 주도의

시장에서 새로운 틈새시장의 리더로

자리매김 할 것임을 역설했다. 예컨

멀티미디어 제품이나 소비 제품의 경

Configurable 프로세서로 틈새시장 공략 강화

임베디드 프로세서

신흥세력 급부상

『Electronics Summit 2003』보고서

: 안미 기자/amy1216@chollian.net

AROUND THE EMBEDDED

26

우 상위 레벨에 한 개의 하이-레벨 컨

트롤러가 있고 그 밑에 많은 데이터 인

텐시브 서브 시스템이 있게 마련인데,

시스템 컨트롤의 경우는 그 로 ARM

프로세서를 쓰고 그외 이미지 프로세

싱이나 오디오 프로세싱 패키지 처리

또는 encryption 등은 텐실리카를 쓸

수 있다고 로웬 사장은 말했다. 특히,

ARM 프로세서 성능의 역을 벗어난

데이터 인텐시브(Data intensive)

역에서 텐실리카 기술이 더욱 빛날 수

있다고 한다. 이 경우 ARM 프로세서

보다 텐실리카 프로세서가 수 십 배의

속도를 낼 수 있다고 한다.

한편, ARC사의 마이크 굴레트 사장

은“각종 디지털 가전 제품의 디자인

활동이 가장 활발하게 이루어지고 있는

아시아 시장에서 ARC 임베디드 코어

기술의 성장잠재성을 보고 있다”면서

“이미 120여 개의 라이선시를 확보한

상태이며 50여 개의 기존 고객들이 만

족한 클라이언트(happy client)로, 이

들이 더 다양한 기술군을 추가 구매함

에 따라 건당 계약 규모가 초기단계보

다 훨씬 더 커지고 있다”고 말했다.

ARC는 현재 국내에서 하이닉스

(Hynix, www.hynix.com)와 이-엠

디티(e-MDT, www.e-mdt.co.kr)를

고객 및 파트너로 확보하고 초기 시장

확보전에 돌입했다. ARC의 국내

R&D 파트너인 이-엠디티의 김태경

과장은“ARC의 경우, 유저의 마음

로 기능에 따라 DSP를 넣기도 하고 범

용 기능을 넣기도 하는 등 유연성이 있

기 때문에 ARC 기술의 적용 시장은

휴 용 기기로부터 네트워크까지 다양

하다”고 말했다. 또한 파운드리 관련해

서도 어느 팹을 쓰든 관계없는 Fab-

independence가 강점이라고 주장했

다. 특히 ARM9의 경우는 삼성처럼 큰

파운드리를 제외하고 재정문제로 아직

라이선스를 못한 팹이 많은 것을 감안

하면 ARC는 팹 선택의 유연성을 제공

한다는 것. 그는 현재 국내의 경우

학, R&D 센터, RISC연구소 등에서

ARC의 기술에 관심을 보이고 있다고

말했다.

텐실리카의 경우, 작년 9월 한국전자

통신연구원(ETRI, www.etri.re.kr)이

무선 멀티미디어 SoC 디자인을 위한 기

술 라이선스를 국내 최초로 체결했으며

에찌소프트(EdgeSoft, www.edge-

soft.co.kr)가 국내 판매 리점으로서

반도체 및 전자 업체를 상으로 시장을

개척중이다. 그러나, 국내 부분 업체

가 이미 ARM 아니면 StrongARM으로

선택이 제한된 만큼 아직 텐실리카에

해 잘 모르고 있는 것이 걸림돌.

이에 해, 에찌소프트의 권순준 사

장은“한국에서 텐실리카의 인지도는

일본과 만에 비해 매우 낮은 편이다.

사실 국내 기업에게 첫 번째 카피를 판

매하기가 힘들지 한 번 나가기 시작하면

그 다음 수주는 계속 이어질 것”이라고

낙관했다. 말하자면 ARM 칩은 고객사

들이 슈퍼마켓에 가듯이 찾아가서 구입

하지만 텐실리카나 ARC의 기술은 이들

업체들이 먼저 고객사를 찾아가서 새로

운 개념을 설명하고 설득해야 하는 것.

텐실리카가 바라보고 있는 시장은

표준 반도체 양산라인에 들어가는 프

로세서 기술이 아니라 Application-

specific nature를 충분히 활용할 수

있는 SoC 칩 설계 시장이다. 즉, 핸드

폰∙스토리지∙네트워크 스위치 개발

등에 텐실리카 기술의 경쟁력이 있다

고 크리스 로웬 사장은 보고 있다.

텐실리카의 경우, ARM과 비슷한 라

이선스와 로열티 부분으로 나누어지지

만 그 계산방법은 고객의 선택여지가

더 많다. 텐실리카가 제공하는 주요 라

이선스 선택은 두 가지. 하나는 칩 디자

인 팀이 다양한 프로세서를 1년의 트라

이얼(trial) 기간 동안 얼마든지 시험 사

용해 볼 권리를 가질 수 있다. 이 경우

1년의 트라이얼 기간이 지난 후 실제로

configuration을 위한 기술과 소프트

웨어 개발 환경이 제공된다. 이후 어떤

제품을 생산하든지 간에 그 아키텍처에

사진 1. Chris Rowen 텐실리카 사장 겸 CEO 사진 2. Mike Gulett ARC사 CEO

AROUND THE EMBEDDED

30

한‘Perpetual right’를 갖게 된다.

두 번째는 다양한 제품군을 보유한 고객

사라면 time-based 라이선스를 선택하

기도 한다. 예를 들어, 이 기간동안 20

개의 다른 제품군을 위한 20개의 다른

아키텍처를 사용할 수 있는‘perpetual

right’를 갖게 된다.

한국 시장에서 텐실리카의 타깃은 우

선 디지털 TV, 차량 컨트롤 시스템,

MPEG4 개발업체 등으로 잡고 있다.

일단, 이 칩을 쓰면 성능을 최고 100배

까지 향상시킬 수 있다고 에찌소프트의

권 사장은 주장했다. 크리스 로웬 사장

은 한마디로 역폭과 효율성 사이에

‘Collision course’가 많이 일어나는 제

품일수록 텐실리카의 programmabi-

lity의 강점이 가장 빛날 수 있다고 강조

했다. 이어 그는 이러한 Configurable

프로세서가 가져온 가장 큰 변화로 하

드웨어와 소프트웨어 간의 coveri-

fication이 가능해졌다는 점을 들었다.

종래의 SoC 방법을 보면 설계 공정 초

기 단계에서 low-performance, big-

complexity 성능은 소프트웨어쪽으로

배치되고 high-performance, low-

complexity task는 하드웨어쪽으로

배치된 후 하드웨어팀과 소프트웨어팀

이 각각 블록 디자인을 했다. 그후 공정

후반부가 되서야 두 팀이 각각의 하드

웨어와 소프트웨어 모델을 갖고 와서

두 개의 sub-system 간에 인터페이스

가 잘 되는지 확인했다. 그러나 텐실리

카의 경우는 이러한 종래 방법에 커다

란 변화를 가져왔다.

우선, 텐실리카의 Configurable 프

로세서는 하드웨어와 소프트웨어 간에

훨씬 더 유연성 있는 연속성을 제공한

다. 왜냐하면, 이제 복잡한 태스크도

프로세서에서 수행될 수 있기 때문이다.

말하자면 프로세서가 훨씬 더 큰 역할을

수행할 수 있기 때문에 하드웨어에서는

가장 간단한 태스크만 해도 된다. 복잡

성을 지닌 다른 태스크는 프로세서에서

효율적으로 수행할 수 있기 때문이다.

결국 소프트웨어 환경 내에서 훨씬 더

많은 일들을 할 수 있다. 즉, 하드웨어

시뮬레이터 신에 소프트웨어 디버거

를 쓸 수 있다는 말이고, 시스템 태스크

를 해결하기 위해 프로세서 시뮬레이터

가 서로 함께 작용할 수 있다는 것.

양사의 제품 전략은 부분 SoC 설

계 엔지니어들에게 매력적인 제안이

다. 사용자가 시스템에 적합하도록 변

형해서 사용할 수 있는 Configurable

프로세서의 유연성은 여러 측면에서

장점이 될 수 있다. 그러나 그에 따른

문제점도 간과할 수 없는 게 현실.

ARM과의 직접적인 경쟁구도를 피력

하지 않은 것은 바로 이러한 현실 인식

에 기인하지 않았나 싶다. 단순히 국내

시장만을 놓고 본다면, 우선 ARM의

시장 장악력을 떠올릴 수 있다. 생소한

기술에 한 국내 엔지니어들의 지나

친 배타성은 업사원들 사이에 공공

연한 사실로 회자되곤 한다. 하지만,

무엇보다도 도입에 걸림돌이 되는 것은

Configurable 프로세서를 자유자재로

취급할 수 있는 전문인력의 부족과 기

업 단위에서의 성공 스토리가 아직 국

내에서 보고되지 않았다는 점이다. 그

럼에도 불구하고 시 적 추세를 감안해

보면 텐실리카와 ARC의 접근 방식을

평가절하 할 수는 없을 것이다.

BRIEFS

인텔

무선기술 통합‘센트리노’발표

인텔코리아( 표 김명찬, www.intel.

com/kr)는 프로세서(코드명 배니아스)

와 칩셋(코드명 몬타나라GM), 무선랜

(코드명 칼렉시코) 기술을 통합한 차세

모바일 프로세서인 「센트리노

(Centrino)」를 지난 3월 12일 전격 공

개했다.

이 센트리노 기술은 802.11b 무선

표준을 지원해 무선랜 환경에서 노트북

PC를 사용할 수 있고 노트북PC의 배

터리 사용시간을 5시간 이상 증가시켰

다. 또 센트리노의 발열량이 적어 최소

1인치 이상 얇고 가벼운 노트북PC의

제작이 가능하다고 회사측은 밝혔다.

프로세서의 성능은 웹마크의 시험결

과 1.2GHz급 펜티엄Ⅲ-M에 비해

59%의 성능향상을 보 고 2.4GHz급

펜티엄4-M에 비해서는 13% 정도 높은

성능을 나타냈다.

인텔은 센트리노의 판매가격을 1000

개 구입시 동작속도에 따라 개당 292�

720(1.3�1.6GHz)달러로 책정했다.

한편, 이번 센트리노 발표에 맞춰 인

텔은 세계 11개국 시장에서 3억 달러의

비용을 들여 적인 마케팅 캠페인을

전개하는 등 상당한 의욕을 내보 다.

31Embedded World

미국 광 역 멀티서비스프로세서

(MSP) 업체인 Brecis Communicati-

ons Corp.가 국내시장 공략에 나섰다.

Brecis(www.brecis.com)는 지난

3월 세웅정보통신( 표 장우진, www.

sewoongi.com)과 협력 관계를 맺고

고성능 라우터, 무선 액세스 포인트,

VPN, 보안 어플라이언스, VoIP 게이

트웨이 등을 생산하는 국내 장비 제조

업체들을 상으로 적극적인 제품

업 및 기술지원을 발표했다.

이번에 신제품 발표 차 방한한 조지

알렉시(George Alexy) 사장(사진)은

Point Topic사의 자료를 인용, “전세계

광 역 시장은 현재도 크지만 앞으로도

성장할 가능성이 더 있다”면서“한국은

세계에서 1인당 광 역 가입률이 제일

높기 때문에 Brecis의 전략적인 시장이

다”라고 밝혔다. 아울러 그는“비용

비 효율성이 뛰어난 아키텍처가 특징인

MSP가 한국에서 이미 10개가 넘는 디

자인 성공을 획득한 것에 해 기쁘게

생각한다”면서 이번에 발표한 제품에

한 기 또한 숨기지 않았다.

Brecis가 새롭게 선보인 MSP는 서

비스 품질(QoS) 및 보안 기능을 강화

한 IEEE 802.11a/b/g 응의 프로세

서로써 지난 3월 17일 공식 발표됐다.

이번에 발표된 야심작 MSP2100은

무선 LAN에 응한 라우터와 액세스

포인트 등의 네트워크 장비를 상으

로 하며, 보안이 강화되어 IPsec에 준

거한 AES(advanced encryption

standard)나 DES(data encryption

standard), MD5(message digest

algorithm 5), SHA1(secure Hash

algorithm 1) 등의 암호처리용 엔진을

내장하고 있다. 이외에 동작 주파수

33MHz, 버스 폭 32비트의 PCI 인터

페이스(Ver 2.1 및 Ver 2.2에 준거), 3

개의 10M/100M 이더넷 MAC 등을

갖추고 있다(그림 1 참조).

이와 함께, Brecis는 MSP2100에서

암호처리용 엔진을 제거한 MSP2007과

무선통신 기능을 제거해 이더넷 라우터

상으로 기능을 제한한「MSP2005」도

발표했다. 이 멀티서비스 프로세서는

각각 두 개의 10M/100M 이더넷 MAC,

두 개의 UART, 256MB의 SDRAM 및

32MB의 플래시메모리 컨트롤러 등을

갖추고 있다. 세 제품은 모두 Brecis사

의 자체 특허 기술인 4.25Gbps 내부

멀티서비스 버스(SM Bus)를 갖추고

있으며 CPU 코어는 MIPS32 4Km

(170MHz 동작)을 채용했다. 코어 전

압은 1.8V, I/O 전압은 3.3V, 소비전력

은 1.3W이다. 패키지는 276핀 BGA.

현재 MSP2007은 양산되고 있으며

MSP2005와 MSP2100은 샘플 출시

중이다. Brecis사는 이들 제품에

VxWorks 및 Linux에 응한 평가 킷

(평가 보드, MAC과 802.11 드라이버

등의 소프트웨어)도 제공한다.

한편, Infonetics와 Allied Business

Intelligence, NDP 등이 조사한 MSP

시장 예측 자료에 따르면 해마다 39%의

시장 증가율을 기록하며 올해 3억

2,000만 달러에서 오는 2004년까지 5

억 달러 이상 성장할 전망이다.

Brecis Communications사는 어떤

회사인가?

Brecis Communications사는 팹리

스 반도체 메이커로서 시스템온칩

(SoC) 및 이와 관련된 소프트웨어, 서

비스를 제공하고 있다. 주요 고객은 라

우터, 액세스 포인트, VPN(Virtual

Private Network) 등의 제조업체나

서비스 프로바이더이다. Brecis는 증가

하는 MSP 수요량을 지원하기 위해 올

해 2000만 달러를 조성했으며, 주요 거

래처로는 Corega, Ericsson, Omron,

Yamaha 등이 포함되어 있다.

보안기능 강화된 IEEE 802.11a/b/g 응

프로세서 거 발표

: 윤범진 기자/bjyoon@techworld.co.kr

멀티서비스 프로세서 업체

BRECIS, 국내 상륙

그림 1. MSP2100 멀티서비스프로세서 블록 다이어그램

802.11

External Local Bus

PCI 10/100 MAC

10/100 MAC

10/100 MAC

2-Wire

SPI/MPI

GPIO

UART

Memory Controller

Security Engine

High PerformanceMIPS32 4Km

USB

Console

SDRAM

WAN

LAN

DMZ

Flash

Serial

I/O

4.25

Gbp

s M

ulti-

Ser

vice

Bus

(MS B

us)

AROUND THE EMBEDDED

32

“우리가 차세 경쟁력을 확보하기

위해서는 임베디드 소프트웨어(S/W)를

선점해야 한다”

임형규 회장(임베디드소프트웨어산

업협의회)은 지난 2월에 있었던 협의회

창립총회에서 임베디드 S/W가 IT(정보

산업)의 주도권를 잡는데 결정적인 역

할을 할 것이라고 강조했다.

임베디드 S/W는 휴 폰, 디지털 TV

에서 첨단 무기에 이르기까지 다양한 장

비에 내장되어 제품의 부가가치를 결정

하는 핵심기술로 Post-PC 시 에 성장

가능성이 매우 높은 신산업 분야로 등장

했다. 세계적인 통신 인프라와 제조업

기반을 보유하고 있는 우리의 강점을 임

베디드 S/W 기술과 접목한다면 새로운

수출 전략 상품을 발굴할 수 있는 좋은

기회라고 보고 있다. 2002년 임베디드

S/W 세계시장 규모가 200억 달러 고

2007년에는 493억 달러로, 매년 20%

의 성장률이 이를 뒷받침 해주고 있다.

국내시장도 2002년에 5조6천억원 이상

으로 추정되어 폭발적인 시장규모가 형

성될 것으로 예상하고 있다.

임 회장은“임베디드 S/W는 전문가

를 제외하고는 일반인에게는 아주 낯선

개념이지만 최근 관심이 높아지고 있는

유비쿼터스의 기초산업이자 핵심산업”

이라며“하지만 현재 국내 자체기술이

취약해 해외의존도가 높다”고 지적했

다. 이에 협의회는 민간부분 중심으로

활동하면서 앞으로 정부와 업계간의 협

력관계를 조율해 나갈 방침이다.

이에 따라 관련업체 중심의 임베디드

S/W 산업협의회는 산∙학∙연간의 공

조체계를 구축하고 표준화, 핵심기술개

발, 제품 개발을 연계한 산업육성을 추

진하게 된다. 이에 앞서 정보통신부도

임베디드 S/W 산업을 차세 수출전

략 산업으로 중점 육성하기 위해서 앞

으로 5년 동안 모두 800억원을 쏟아부

을 계획이라고 밝혔다. 이를 위해 임베

디드 S/W 플랫폼 기술 개발과 표준화

를 추진할「임베디드 S/W 기술센터」를

설립하고 서울시와 함께 서울 상암동에

마련될 스마트타운에 지능형 가로등 등

임베디드 S/W 플랫폼을 적용한 세계

최초의 유비쿼터스 코리아 시범사업도

추진할 계획이다. 임베디드 S/W는 그

활용 분야가 일상 생활 및 전 산업분야

로 확 되어 국가차원의 집중적인 육성

책이 시급하기 때문이다.

산업협의회의 올 사업계획은 임베디

드 S/W 표준 플랫폼 규격제정 및 기술

지원과 국제 협력추진, 시범사업, 홍보

및 마케팅 지원, 전문인력 양성 등으로

나눠 볼 수 있다. 이 중 핵심은 역시 임

베디드 S/W 표준 플랫폼 제정과 전문

인력 양성에 한 부분이다. 협의회는

표준화 분과를 통해 업계 요구사항이

반 된 표준 플랫폼 표준규격 작성에

심혈을 기울이고 있다. 다양한 임베디

드 시스템에 공통으로 탑재돼 최적으로

성능을 지원할 수 있도록 하는 플랫폼

기술을 개발하고 표준화를 추진해야 하

기 때문이다. 협의회는 설문조사를 통

해 업계의 의견을 반 할 계획이다.

임베디드 S/W 전문인력 양성도 중요

한 문제이다. 협의회 관계자는“임베디

드 S/W 전문인력 양성 및 원활한 지원

을 위해 임베디드 S/W 교육프로그램

을 개발하고 전문강좌 개설, 회원사를

상 로 전문인력 인턴제도를 추진할

것”이라고 밝혔다. 협의회는 회원사 중

심의 전문 인력 수요예측 조사도 벌일

계획이다. 인력양성에 한 중요성은

이용태 전경련 정보통신위원회 회장의

말에서도 뚜렷하게 나타난다. 이 회장

은“앞으로 5년 이내에는 단순한 하드

웨어 생산조직은 중국으로 옮겨 갈 것”

이라며“지식산업을 하기 위해서는 세

계로 나가는 산업을 육성해야 하는데,

이에 임베디드 S/W 산업에 필요한 전

문인력을 준비하기 위해서 5만명을 5

년간 집중 양성해야 한다”고 말했다.

오길록 ETRI 원장의 말처럼“임베

디드 S/W 산업는 매우 스마트한 제품

의 핵심기술이면서 오늘의 현실에서는

가장 취약한 분야”이다. 하지만 출발

선상에 선 임베디드 S/W 산업협의회

가 구심점이 되고 정부지원이 뒤따른

다면‘가장 강력하고 풍부한 분야’가

될 수 있는 날도 멀지 않을 것이다.

임베디드 S/W 산업협의회 활동 개시

표준 플랫폼 제정, 전문인력 양성 중점

임베디드 소프트웨어

날개를 달다

33Embedded World

임베디드소프트웨어산업협의회는 창

립총회 기념세미나를 통해 임베디드 소

프트웨어(S/W)에 한 다양한 분석과

응용분야를 검토했다. 이번 세미나에서

는 임베디드 S/W의 국내외 기술동향

에서부터 임베디드 S/W 표준화, 그리

고 삼성전자를 비롯한 주요 참여사들의

사업계획 및 협력방안 등이 논의 됐다.

특히 의료기기, IMT2000 단말기, 항

공전자, 첨단 도로시스템, DMC, 센서

네트워크에서의 임베디드 S/W 활용을

점검했다.

가장 먼저 발표자로 나선 삼성전자

채종원 수석연구원(소프트웨어센터)은

「임베디드 밸류 체인과 비즈 협력모

델」이라는 주제를 통해“임베디드

S/W 플랫폼 솔루션은 임베디드 시스

템 시장이 증가하고 임베디드 시스템

의 S/W 비중이 증가하면서 필요성이

생겼다”고 배경을 설명했다. 이에“종

래의 O/S 중심에서 다양한 멀티미디어

및 애플리케이션으로 확 되고 소프트

웨어가 복잡해지며 품질관리비용 등의

원가가 상승하고 있기 때문에 소프트

웨어 재활용 등을 위한 공용 소프트웨

어 플랫폼 개발요구가 증 되고 있다”

고 밝혔다.

오픈 소스 소프트웨어 솔루션에

한 요구도 증가하고 있다. 소프트웨어

재활용이 가능하고 공동체에 의해 유

지되는 공용 소프트웨어 플랫폼을 보

유할 필요성이 생기면 특정 업체에

한 기술 종속성도 탈피하게 된다는 것.

오픈 소스 소프트웨어인 리눅스의 경

우, 높은 완성도와 다양성을 바탕으로

서버/데스크톱 시장이 확 되고 있는

것이 좋은 예라고 지적했다.

채종원 연구원은“다른 기업들도

RTOS 적용 제품에 주력하고 있는 가운

데 솔루션 부족을 느끼고 있어 부분

임베디드 리눅스(Embedded Linux)를

검토하는 단계에 있다. 임베디드 리눅

스의 네트워킹, 멀티미디어 지원 기능

에 한 제품 적용 가능성을 심각하게

검토하고 있다”고 덧붙 다.

임베디드 리눅스의 장점은 전세계

개발자들로 구성된 강력한 개발자 커

뮤니티를 보유하고 있다는 것과 다양

한 소프트웨어 컴포넌트의 활용, 선택

가능성, 공동개발, 신기술의 접목이 쉽

다는 것이다. 반면 단점은 실제 제품

적용을 위한 기능 및 완성도가 떨어지

고 특허에 관한 법적문제, 개발환경,

제품기술지원이 부족하다는 점을 들었

다. 채연구원의 말처럼‘90%는 쓸 수

있는데 나머지 10%가 안돼 완성된 부

분이 없다’는 것이다.

그는“Embedded, Everywhere를

위해 준배해야 할 것은 오픈 소스 소프

트웨어를 이용한 임베디드 시스템 시

장에 공동으로 응해야 한다”며“이

슈별 공동 응 및 분야별 전문화를 위

해 플랫폼 표준화, 전문인력 양성, 정

부차원의 시장 활성화 및 기술 축적이

필요하다”고 강조했다.

「Embedded S/W 해외 기술동향」을

주제로 발표한 건국 학교 김문회 교수

는 주요 국가들의 기술동향을 소개했다.

임베디드 시스템 개발에서 핵심기반

기술에 치중하고 있는 미국은 특정 응

용기술을 개발하는 개별사들에 기반기

술을 중점 지원하고 있다. 현재는 메이

저 기업들이 임베디드 시스템을 강조하

면서 개발이 진행되고 있다. 미국과학

재단(NSF)에서도 전기∙전자에서부터

환경∙생태에 이르기까지 관심을 갖고

지켜보고 있으며 외국인에게도 연구비

를 지원할 정도로 임베디드 S/W 기술

개발에 적극적이다. NSF는 임베디드

네트워크 센싱 센터를 설립, 향후 10년

간 4,000만 달러를 지원하여 자연환

경, 빌딩, 교통, 의료공학 등에 필요한

물리적, 화학적 센서와 관련된 임베디

드 소프트웨어를 개발하고 있다.

미 국방고등연구계획청(DARPA)도

2002년 R&D 예산 22억 달러 중 약 1억

6,000만 달러를 NEST 등 임베디드

S/W 개발에 투자하고 있다. 김 교수는

“DARPA 같은 경우, 기술도 산업체에 이

전해 활용하고 있고 미국기업인 United

Tech-nology 같은 경우 엘리베이터에

서 에어콘, 헬리콥터에 이르기까지 임베

디드 소프트웨어의 중요성을 인정, 모든

것을 임베디드와 관련해 개발하고 있다”

고 말했다.

유럽연합(EU)도 네트워크 임베디드

시스템, Dynamic resources alloca-

표준화 기술 선점, 시장 활성화 한 목소리

의료기기, IMT2000 단말기, 항공전자 등 다양

임베디드 S/W 산업협의회

창립 기념 세미나

AROUND THE EMBEDDED

34

tion techniques 등에서 전략적으로

개발에 박차를 가하고 있다.

유럽 EUREKA(European Rese-

arch Coordination Agency), ITEA

(Information Technology for Euro-

pean Advancement)는 생활환경의

지능화를 모토로 홈∙오피스∙교통∙

환경분야의 서비스를 고도화하기 위한

기술 개발을 추진하고 있는데, 1999년

부터 8년간 32억 유로를 투입하고 있

다. IST도 미래 정보통신 사회 구축을

위한 네트워크 임베디드 시스템, 분산

실시간 제어시스템, 차세 DSP, 적응

형 시스템 S/W 등을 개발 중에 있고.

2003년부터 4년간 5.4억 유로를 투입

할 계획이다. 김교수는“ITEA는 2010

년경에는 필요한 소프트웨어의 양과 생

산되는 소프트웨어의 차이가 크게 벌어

질 것이라고 전망했다”며“갈수록 인력

양성의 부담이 커질 것”이라고 말했다.

일본도 1984년 미래 컴퓨터 사회에

사용될 고도의 기능을 갖춘 실시간 운

체 제 (Real-time Operating

System) 규격 개발을 위한 시스템에

관한 TRON이라는 프로젝트를 진행해

왔으며, 1990년 4월 동경에서 TRON

인텔리전트 주택 파일럿 하우스를 공

개하여 인간 중심의 생활공간 모델을

제시했다. 현재는 ITRON 프로젝트만

이 살아남아 임베디드 시스템에 사용

되는 RTOS 표준을 제정하고 있다. 또

한 멕시코나 인도네시아, 동남아시아

몇 개국도 국가적인 차원에서 임베디

드 시스템 프로그램을 진행하고 있는

상황이다.

김교수는“결론적으로 임베디드 소

프트웨어 연구활동은 보다 더 활발하

게 이뤄져야 하고 당장 시급한 것은 표

준 플랫폼을 정해야 한다는 것이다. 나

아가서 우리나라의 표준이 국제 표준

이 되도록 해야한다”며“이를 위해선

인력양성을 해야 한다. 소프트웨어의

노하우가 사람을 키우는 것에서 나오

고 여기에서 무한한 부가가치가 형성

된다는 점을 알아야 한다”고 인력양성

의 중요성을 강조했다.

한국전자통신연구원(ETRI) 김흥남

팀장(컴퓨터소프트웨어연구소)은「임

베디드 소프트웨어 기술 개발 추진 계

획」이란 주제발표에서 임베디드 소프

트웨어는 어떤 것(things)을 스마트하

게 만드는 것이라고 정의했다. 예를 들

어 휴 폰에 쓰이는 임베디드 소프트

웨어는 경량화/최적화, 네트워크 지

원, 저전력화, 멀티미디어 지원, 고신

뢰성을 구현함으로써 멀티미디어 메세

징, 무선인터넷, 무선 게임, VOD,

LBS, M-커머스, 상전화 등의 스마

트 서비스를 가능하게 만드는 것이다.

2001년 세계 마이크로프로세서 생

산량의 97%가 컴퓨터 이외의 기기에

사용되고 있다는 현실은 임베디드 소

프트웨어의 무궁무진한 시장을 변하

는 것이다. 임베디드 소프트웨어는 스

마트 홈, 스마트 시티즌, 스마트 타운

으로 활용 추세가 갈수록 넓어지고 있

다. 처음부터 모든 것을 다 구현할 수

없기 때문에 규모별로 처음에는 나노

임베디드 S/W 플랫폼에서 마이크로

임베디드 S/W 플랫폼으로, 마지막 표

준형 임베디드 S/W 플랫폼으로 나눠

서 진행해야 한다.

임베디드 S/W 시장동향에서 김팀장

은“임베디드 리눅스 OS를 기반으로

브라우저 베이직, 미들웨어, 멀티미디

어 위에 개발도구를 얹는 패키지 형태

로 제공될 것이다. 이렇게 되면 각 분

야에 알맞는 형태로 최적화하게 된다.

이제 임베디드 시스템의 네트워크 기

능과 멀티미디어 기술을 포함하는 임

베디드 S/W 플랫폼 기술이 중요하게

두됐다”고 말했다.

미국 버클리 학에서 진행하고 있

는 TinyOS는 나노 플랫폼에 해당하는

것으로 센스 기능을 탑재해 지진예측,

오염 등의 다양한 분야에 활용할 수 있

는 임베디드 기술이다. 한 예로 임베디

드 시스템과 네트워크 시스템, 센서 기

능이 합쳐지면 건물 균열 등의 징후를

휴 폰으로 알 수가 있다.

HP CoolTown은 유무선 통신 네트

임베디드 소프트웨어 연구활동은 보다 더 활발하게 이뤄져야 하고 당장 시급한 것은 표준 플랫폼을 정해야 하는 것이다.

워크 기술과 웹기반의 정보통신 기술

을 기반으로 하는 미래의 도시 모델을

제시하고 있다. 마이크로소프트 Easy

Living은 물리적 공간세계와 가상적

공간세계를 결합하여 인간에게 가장

쉬운 삶의 공간창조를 목적으로 하고

있다. MS 닷넷(.net)은 인터넷 환경에

서 보편적으로 사용하게 될 웹서비스

개발환경을 제공한다.

IBM은 무선기기, 차량, 홈 어플라이

언스 등에 컴퓨팅 파워를 내장시켜 언

제, 어디서나 데이터를 교환하고 관리

하는 기술을 개발하고 있다. 모바일 솔

루션, 서비스 프레임워크, PDA, 스마

트폰, 홈 엔터테인먼트 등에 활용되는

임베디드 솔루선을 제공한다.

김팀장은“다양한 규모의 임베디드

시스템을 지원할 수 있는 임베디드

S/W 표준 플랫폼 기술을 개발할 계획”

이라며“우리의 경쟁상 로 WinCE,

TinyOS 등이 있는데 이들은 상호 호환

성이 없다는 것이 단점이다. 우리가 개

발하는 것은 임베디드 리눅스를 기반으

로 나노, 마이크로, 표준형 임베디드

S/W가 서로 디바이스 됐기 때문에 소

프트웨어간에 재활용과 활용분야가 넓

어진다. 이것이 바로 외국 제품과 가장

큰 차이”라고 주장했다. 한편, 임베디드

S/W의 플랫폼 세부기술로는 임베디드

OS 기술, 컴퓨팅 미들웨어 기술, 멀티

미디어 기술, 임베디드 S/W 통합 개발

환경기술 등이 있다.

김팀장은 임베디드 S/W 기술 개발을

추진하고 임베디드 S/W 플랫폼을 국가

표준화함으로써 임베디드 S/W 핵심기

술 확보, 개발 기술의 SmarTown 적용

을 통한 파급효과 확 , 해외기술의 국

내시장 잠식 방지, 유비쿼터스 시 의

로벌 IT 리더십 등을 확보할 수 있다

고 강조했다.

35Embedded World

임베디드소프트웨어산업협의회 웹사이트 오픈

www.kesic.org

www.kesic.or.kr

임베디드소프트웨어산업협의회는 4월초

에 웹사이트를 오픈할 예정이다.

회원간 정보 교류 및 임베디드 산업의

정보 제공을 위해 개설되는 웹사이트의

도메인은 www.kesic.org 와 www.

kesic.or.kr 로 확정됐다.

앞으로 홈페이지에서는 협의회의 일반

현황에 한 정보제공과 각종 사업안내,

기술자료 및 조사자료를 제공하게 된다.

특히 각 분과별, 워크그룹별 커뮤니티

기능을 강화하고 최신동향 자료를 올릴

계획이다.

최신 기술동향 한 눈에최신 기술동향 한 눈에

‘임베디드 S/W 세계 2 강국을 향해’

정보통신부는 임베디드 S/W 산업을 차세 수

출전략 산업으로 육성하기 위해 핵심기술 개발과 표

준화, 시범서비스 구축, 전문인력 양성 분야에 800

억원을 투입한다고 밝혔다. 이를 위해 정통부는

ETRI 산하에 임베디드 S/W 기술센터를 설립하고 2

월에는 임베디드 S/W산업 협의회를 탄생시켰다. 이

러한 가운데 일부에서는 부처 중복투자와 표준화 논

란이 일어나고 있다. 이에 한 정통부의 입장을 들

어봤다.

임베디드 S/W 표준화는 어떻게 진행되는가

정부는 어디까지나 국가적인 측면에서 중복투자를

막고 개발자와 사용자 편의를 위해서 표준화를 추진

하는 것이다. 다수가 사용하는 표준화로 소수의 피해

업체가 있을 수 있지만, 그것도 업체 스스로가 정하

는 것이지 정부가 강요하는 것은 아니다. 정부정책도

업체 중심의 표준화를 만드는데 목적을 두고 있다.

임베디드 S/W 산업협의회의 역할은

2월에 출범한 임베디드 S/W 산업협의회는 분과

중심으로 사업을 추진해 나가되 다시한번 전문가의

의견을 수렴해 나갈 것이다. 중소기업들의 제품을

내수에서 처리하지 못하기 때문에 어려움이 많은 것

이 현실이다. 이에 정부는 협의회를 제도적으로 지

원해 나갈 방침이다. 협의회를 삼성과 LG같은 기

업 중심으로 만든 이유 중의 하나가 이런 중소기업

을 위한 것이기도 하다. 기업에서 중소기업의 제

품을 쓴다면 내수가 살아날 것이다.

다른 부처간의 중복 투자 얘기도 많이 나오는데

다른 부처와는 이미 여러 채널을 통해 협의해 오

고 있다. 임베디드 S/W 산업정책을 1년 이상 준비

해온 정보통신부는 기술센터와 협의회를 만드는 등

기반을 마련했다. 하지만 임베디드 S/W 산업에서

돈버는 업체는 아직 없는 상황이다. 앞으로 많은 업

체들이 시장을 확 해 나갈 수 있도록 풍토를 만들

어 나가야 할 것이다.

정부의 임베디드 S/W 산업추진 방향은

정부가 시장에 개입하려고 정책을 추진하는 것은

아니다. 정부는 시장이 실패했을 경우에나 개입하기

때문에 적극적으로 나서지 않고 기업을 위한 터전을

마련하는 것이다. 또한 불공정 사례를 막고 제도적

인 계도를 하는 것이다. 정부는 앞으로 공공분야에

서 서비스를 창출해 나갈 것이며 ITS와 같은 정보화

사업에 연계하는 S/W 산업도 추진할 방침이다.

INTERVIEWINTERVIEW “업체중심의 표준화 추진”김 문사무관 (정보통신부 소프트웨어진흥과)

AROUND THE EMBEDDED

36

BRIEFS

LynuxWorks

새로운 ELC 규격 채용

임베디드 소프트웨어 전문업체인

LynuxWorks(www.lynuxworks.com)

는 임베디드 리눅스 컨소시엄(ELC)이 선

보이는 ELCPS(ELC Platform Specifi-

cation)를 지원할 계획이라고 최근 발표

했다. 이로써 LynuxWorks는 실시간

(real-time)과 임베디드 리눅스 운 체

제 전반에 걸쳐 동일한 표준 Linux API

를 제공하는 최초의 업체가 될 것으로

기 하고 있다.

ELCPS는 Linux Standards

Base(LSB) 1.2, IEEE POSIX 1003.1-

2001과 Single UNIX Specification

v3을 포함, 업계에서 가장 폭 넓게 사용

되는 리눅스와 UNIX 표준을 이끌어내고

있다. 임베디드 리눅스 애플리케이션의

API 표준화는 다양한 리눅스 운 체제

배포판의 호환을 가능케 해주고, 핸드헬

드 장치, 셋톱박스, 인터넷 접속 장치와

같은 애플리케이션에 한 자사 임베디

드 솔루션에 한 안을 제공하게 된다.

임베디드 애플리케이션용 리눅스에

한 흐름에 부응하기 위하여 구성된 ELC

는 거 한 임베디드 컴퓨터 시장에서의

리눅스 채용을 지향한다. ELC는 GNU/

Linux 운 체제의 Open Source code

base에 참여를 희망하는 개발자 개인에

게 무료로 멤버십을 제공하고 있다.

한편, 제이텍 시스템(www.jtagsys.

com)은 LynuxWorks의 국내 리점으

로서 LynuxWorks의 BlueCat과

LynxOS, BlueCatRT의 판매 및 기술지

원을 담당하고 있다.

신플리시티

FPGA 물리적 합성 QoR 개선 및

새 디바이스 지원 추가

신플리시티(www.synplicity.com)는

FPGA 설계를 위한 물리적 합성 솔루션

인 「앰플리파이 피지컬 옵티마이저

(Amplify Physical Optimizer)」에 자사

의 멀티포인트(MultiPoint™) 기술과 인터

렉티브 타이밍 분석 기능을 확 , SOPC

(system-on-a-programmable -

chip) 솔루션 제작 시 성능향상 및 작업

시간을 보다 단축할 수 있게 되었다고

발표했다.

또한, 알테라의 고성능 Stratix, 3.125

Gbps 트랜시버를 통합한 StratixGX 및

저가의 Cyclone FPGA를 지원하게 되

었으며, 자일링스의 Virtex II-Pro의 지

원을 한층 강화했다.

신플리시티의 제프 개리슨(Jeff

Garrison) FPGA 제품 마케팅이사는

“앰플리파이를 이용하면 동시 배치와 최

적화 수행 시 전통적인 로직 합성 솔루

션 비 평균 20% 이상 성능을 향상시

킬 수 있어, 저속 등급 디바이스로 설계

를 옮기고 용량 애플리케이션을 위해 수

만 달러를 절약할 수 있다”면서“알테라,

자일링스와 지속적으로 긴 하게 협조하

여 신플리시티의 물리적 합성 솔루션과

그들의 새로운 디바이스 간의 플로를 최

적화 해나갈 것”이라고 말했다.

한편, 신플리시티는 ASIC 프로토타이

핑 프로세스를 용이하게 하고 QoR을 향

상시키기 위해 검증 합성 소프트웨어인

「Certify」를 강화했다. 새롭게 선보인

Certify 새 버전은 향상된 ASIC 검증 성

능을 제공, gated-clock 리포팅 및 소

스 코드에서의 파티셔닝 등을 비롯하여

디자이너들에게 프로토타이핑 프로세스

에 한 가시성을 증 시켰다. 또한, 신

플리시티는 알테라의 고성능 Stratix 디

바이스 및 리눅스 지원을 비롯하여 새로

운 타이밍 엔진과 타이밍 분석 기능을

추가했다.

인피니언

100Mbps 속도 구현 VDSL 칩셋 발표

인피니언 테크놀러지스(www.infineon.

com)는 이더넷 오버 VDSL과 ATM 오버

VDSL을 포함한 고속 VDSL 애플리케이

션을 위한 QAM 방식의 4밴드 VDSL 칩

셋을 발표했다.

이번에 발표한「VDSL5100」은 일심

전화선에서 70Mbps 다운스트림

/40Mbps 업스트림의 비 칭 데이터 속

도 및 50/50Mbps 칭 데이터 속도를

발휘한다. 또한 소프트웨어 프로그래머블

기능은 범용 라인 카드 디자인을 지원하

도록 설계되어 있고 장비 제조업체가

CPE(고객 내장비)뿐 아니라 스위치 및

DSLAM 라인카드에서 지역별 밴드 플랜

(Band Plan)의 요구조건과 다양한 전송

프로토콜을 지원할 수 있는 단일 구성을

가능케 한다.

동일 칩셋 상에서 IP 및 ATM 트래픽

을 동시에 지원하는 VDSL5100은 밴드

0를 포함한 모든 VDSL 주파수에서 유

연한 밴드 할당과 PSD 정형화 기능을

제공해 4킬로미터 이상의 거리까지

VDSL 서비스를 확장할 수 있도록

ADSL 주파수를 활용한다.

37Embedded World

BRIEFS

VDSL5100의 샘플은 5월부터 이용

가능하며 량생산 가격은 15달러이다.

이카노스

ADSL/VDSL 통합 칩셋 시연

ADSL과 VDSL을 통합한 단일 칩셋이

등장했다.

이카노스 커뮤니케이션스(www.

ikanos.com)는 세계 최초로 단일 통합

ADSL/VDSL-DMT 칩셋을 활용한

ADSL-DMT 트래픽을 선보 다.

이 광 역 액세스 컨센트레이터용

SmartLeap™ 통합 A/VDSL 단일 칩셋

은 DMT 라인코딩을 사용하여 VDSL과

ADSL을 동시에 지원할 수 있으며, 써드

파티 ADSL-DMT CPE와 상호작동이

가능하기 때문에 통신사업자들은 VDSL,

ADSL, ADSL+, ADSL2 등을 공급할 수

있다. 또한 장비업체들은 MFE(Metro

Fiber Extension), MxU(Multi-

Tenant/Multi-Dwelling Unit),

CO/RT(Central Office/Remote

Terminal) 시장을 위한 종단간(end-

to-end) 솔루션을 개발하는 한편 제품

화에 걸리는 시간과 개발, 생산, 재고비

용을 절감할 수 있다.

인피니온

소니- 비자와스마트카드표준플랫폼개발

인피니언 테크놀러지스(www.infine

on.com)는 비자 인터내셔널, 소니와 공

동으로 비자 스마트 직불/신용(VDSC)

거래 및 펠리카(FeliCa)에 기반한 비접

촉 애플리케이션을 지원하는 단일 칩

로벌플랫폼 멀티-애플리케이션 칩을 개

발할 계획이라고 밝혔다.

비자의 기존 EMV 호환 스마트카드

와 함께 이번에 새롭게 개발될 칩은

ISO 7816 접촉 인터페이스를 통한 지

불 서비스를 지원하며, ISO 14443 타

입 A와 타입 B 인터페이스 그리고 소

니의 비접촉 스마트카드 기술인 펠리카

에 이르는 비접촉 애플리케이션을 지원

할 예정이다.

비자는 올해 안에 개발될 칩을 자사의

비자 스마트카드 프로그램과 통합하고

펠리카 기반 교통, 로열티 및 전자지갑

애플리케이션을 비자 지불 카드에서 쉽

게 구현할 수 있도록 할 계획이다.

현재 신용 및 직불 카드 표준인 EMV

에 기반한 접촉식 스마트카드는 6,000

만개 이상 발행되었으며, 펠리카 운 시

스템을 탑재한 3,500만개의 비접촉 카

드는 홍콩, 싱가포르와 일본 등에서 사용

되고 있다.

마이크로소프트

‘한국마이크로소프트’로사명변경

마이크로소프트가「한국마이크로소프트」

라는 새로운 이름으로 옷을 갈아입었다.

한국마이크로소프트는 공식 명칭을 변

경하면서 회사 문명도 기존 MSCH

(Microsoft-CH)에서 Microsoft Korea

로 바꾼다고 밝혔다. 이에 따라, 앞으로

한국마이크로소프트의 모든 공문서와

내외 공식명칭에 한국마이크로소프트라

는 이름으로 등재되며 보도 및 기타 공

식, 비공식 행사에도 모두 개명된 이름이

적용되게 된다.

바이텍스-삼성SDI

차세 OLED 디스플레이

개발 협력

미국의 바이텍스 시스템즈(Vitex

Systems, www.vitexsys.com)와 삼성

SDI(www.samsungsdi.co.kr)가 무선

기기 시장을 겨냥해 손을 맞잡았다.

차세 디스플레이 생산을 위해 상호

협력 관계를 체결한 삼성SDI는 바이텍스

의 배릭스(Barix™) 박막 코팅 솔루션과

함께 배리어 엔지니어링 프로그램

(Barrier Engineering Program)의 기

술 개발 활동 및 특화된 디자인에 해

투자와 지원을 아끼지 않을 계획이다. 또

한 삼성은 풀컬러 능동구동형(active

matrix) OLED의 캡슐화를 위해 바이텍

스의 배릭스 박막 코팅 솔루션 기술을

도입키로 했다. 이로써 삼성은 무선 기기

OEM에게 매우 얇고 가벼운 차세

OLED 디스플레이를 공급할 수 있을 것

으로 기 하고 있다.

바이텍스가 개발한 박막 기술은 별도

의 벌크 없이도 습기와 산소층을 생성시

킴으로써 유리판과 같은 보호막 효과를

제공할 수 있으며, 바이텍스의 배릭스 캡

슐화 기술은 디스플레이 제조업체들이

여분의 유리나 접착식 금속 캔 없이도

유리 기판에서 OLED 재료 위에 바로 박

막 코팅을 침전시킬 수 있도록 해준다.

TI 코리아

초소형 배터리 충전기 IC 발표

TI 코리아(www.ti.com)는 USB 포트

나 AC 어댑터를 통해 PDA, 휴 전화,

AROUND THE EMBEDDED

38

BRIEFS

디지털카메라 등을 충전시킬 수 있는 단

일 셀 리튬이온/리튬폴리머 배터리 충전

기 IC를 발표했다.

이번에 발표한 bqTINY II 계열의 IC

는 내부에 자동 전원선택 기능, 전력

FET(1A), 전류 센서, 고정 의 전류/전

압 정류기능, 충전상태 표시 기능 등을

모두 탑재했다. 또한 역저지 보호기술을

탑재하여 DC 전원이 없는 경우 전류누

설을 방지토록 설계되어 있다. 이 제품

은 배터리 셀 제조업체들이 요구하는 프

리차지 컨디셔닝 단계, 정전류 단계, 정

정전압 단계의 3단계로 배터리를 충

전한다.

bqTINY II IC는 현재 양산되고 있으

며 10핀, 3mm×3mm 크기의 QFN 패

키지로 제공된다.

아기어

무선 전력증폭기 시장 진출

아기어 시스템스(www.agere.com)는

2세 , 2.5세 및 3세 (3G)까지 이동

통신기지국 장비에 사용할 수 있는 무선

전력증폭기(PA)를 출시함으로써 이 시장

진출을 공식 선언했다.

이번에 출시한 전력증폭기 트랜지스터

는 RF 전력 트랜지스터 기술을 사용함으

로써 경쟁사 비 길이를 30% 정도 짧

게, 두께는 50%나 얇게 설계했으며 동

작온도도 10 내지 15%로 낮추었다고 회

사측은 밝혔다. 이로써 기지국은 무선 안

테나 타워를 제외하면 크기를 여행가방

정도로 줄일 수 있고 그 위치도 변경할

수 있다고 주장했다.

아기어의 트랜지스터 기술은 크기가

보통 인간의 머리카락 절반에 해당하는

초극세 실리콘 웨이퍼를 제작할 시 발생

되는 칩 내 결함을 제거하는데 성공했다.

또한 두께가 두꺼운 칩은 얇은 칩처럼

열을 전달하지 않는 특성으로 인해 온도

가 더 따뜻한 경향이 있다. 이에 따라,

아기어는 웨이퍼 크기를 저가의 비용으

로 독점 제작했으며, 칩을 얇게 만드는

기법(chip thinning)을 개발하여 타사

설비 사용 시 발생하는 칩 결함을 해소

했다.

이외에도 아기어의 트랜지스터 기술은

현재 특허 출원중인 저 저항의 고 도

전기 커넥션을 사용해서 저항이 낮은 특

성과 와류 용량성 모두를 구비한 트랜지

스터를 제작할 수 있었다.

아기어는 현재 트랜지스터를 샘플 공

급하고 있으며 올해 3분기 안으로 제품

을 공급할 계획이다.

인텔

제온 프로세서 3GHz 돌파

인텔코리아( 표 김명찬, www.intel.

com/kr)는 지난 3월 10일 3GHz가 넘

는 듀얼 프로세서 서버 및 워크스테이션

용 인텔 제온 프로세서 출시를 발표했다.

또한 전세계 9,000개 이상의 회사가 이

프로세서에 기반한 부품이나 시스템을

판매하고 있다고 주장했다.

인텔 제온 프로세서 3.06GHz는

512KB L2 캐시와 533MHz의 시스템

버스를, 3GHz는 512KB L2 캐시와

400MHz의 시스템 버스를 각각 내장하

고 있다.

인텔 제온 프로세서 3.06GHz는 지난

해 11월에 출하된 E7501 또는 E7505

칩셋용의 기존 시스템과, 3GHz는

E7500 또는 860 칩셋용의 기존 시스템

과 각각 호환 가능하다.

현재 인텔은 제온 프로세서 3.06GHz

와 3GHz의 1,000개 단위 당 구매가격

을 722달러, 658달러로 각각 책정했다.

자일링스

단일 채널에서10Gbps

시리얼 기술 구현

자일링스는 최근 단일 채널에서

10Gbps 속도로 시리얼 기술을 시연하

는데 성공했다. 이로써 자일링스는 표준

CMOS 로직 공정을 사용해 10Gbps 기

술을 선보인 첫 번째 PLD 업체가 되었

다. NRZ(Non-Return to Zero) 시그널

링을 바탕으로 한 이 신기술은 주요 칩

투칩(chip-to-chip), 칩투모듈(chip-

to-module), 시리얼 백플레인 애플리케

이션을 지원한다.

전문가들은 시리얼 I/O로의 추세가 거

스를 수 없는 업계의 흐름이라는 데 동

의한다. 병렬 I/O 설계는 1Gbps 이상의

속도에서 이미 물리적 한계에 도달했다.

시리얼 I/O 기반의 설계는 고성능을 보

장해줄 뿐 아니라 필요한 디바이스 핀

수, 보드면적 요건, PCB 레이어 수가

적고, PCB 배치가 보다 용이하며, 커넥

터 수도 적게 들기 때문에 병렬 구현에

비해 비용 절감효과가 뛰어난 편이다.

또 EMI가 적고 노이즈 면역성이 강한

장점이 있다. 자일링스는 올해 공급할

자사 제품에 10Gbps 기술을 채택할 계

획이다.

임베디드 프로세서 산업동향

FEATURE STORY

40

44

임베디드 시스템의 브레인RISC 프로세서 재조명

디지털 가전기기의 멀티미디어화와 모바일화가 급속히 진행되고 있는 가운데 PDA, 휴 폰, 가정용 게임기, 디

지털카메라, 셋톱박스 등 다양한 유형의 첨단 제품 출시가 봇물을 이루고 있다. 임베디드 RISC 프로세서는 이

러한 기기의 핵심 부품으로서 고성능, 저전력, 저가격화가 동시에 요구된다. 따라서, 임베디드 시장을 선점하

기 위한 고효율과 고성능을 동시에 만족하는 아키텍처 개발에 관련업체들이 전력 투구하고 있다.

임베디드 프로세서의 르네상스

전체 프로세서 시장에서 임베디드 프로세서가 차지하고 있는 시장 점유율은 얼마나 될 것인가? 과장된 표현이

긴 하지만, 일부 99% 이상이라는 사람도 있다. 여기서 필자는 이러한 수치의 진위를 따지기보다는 단지 과장

돼 보이는 결과가 나온 배경에 주목하고자 한다. 간단히 우리 주변을 둘러보자. 가정에 컴퓨터는 통상 한 내

지는 많아야 3 정도. 즉, 한 가정에 인텔이나 AMD의 마이크로프로세서가 많아야 3개라는 것이다. 반면, 임베

디드 프로세서는 그 수를 가늠하기조차 쉽지 않다. 이제 그 임베디드 프로세서의 격전장으로 들어가보자.

40

FEATURE STORY

1969년 인텔이 세계 최초의 4비트

마이크로프로세서 4004를 발표한 이

래 반도체 칩의 미세화와 아키텍처, 논

리회로 방식, 설계기술의 진보에 힘입

어 마이크로프로세서의 기능과 성능은

크게 향상되었고, 그 응용분야와 더불

어 눈부신 발전을 거듭해 왔다. 4004

이후, 1970년 에는 8비트 마이크로프

로세서로서 인텔의 8080과 모토로라

의 6800이 16비트 아키텍처인 8086,

68000으로 각각 발전했다. 8비트, 16

비트 마이크로프로세서는 현재도 제어

용 마이크로 컴퓨터로서 폭넓게 사용

되고 있으며 큰 시장을 형성하고 있다

(그림 1 참조).

1980년 에 들어서면서 PC와 워크

스테이션이 등장하 고, 성능 중심의

마이크로프로세서가 사용되기 시작했

다. 현재에 이르기까지 마이크로프로

세서의 속도는 벤더들의 마케팅 전략

에서 가장 중요한 위치를 차지하고 있

다. 실제로 1985년 16MHz의 80836

에서 1990년 25MHz 80486, 1992년

200MHz Alpha 21064, 1994년 300

MHz Alpha 21164, 1998년 600MHz

Alpha 21264, 2001년 1.5GHz 펜티

엄4 등을 거치면서 동작 주파수는 꾸

준히 증가해왔다. PC용 마이크로프로

세서는 기존 제품과의 바이너리 호환

을 중시하기 때문에 CISC 아키텍처를

계속해서 이용하고 있다. 한편 워크스

테이션에서는 RISC 아키텍처의 마이

크로프로세서를 사용하고 있다. RISC

는 복잡한 CISC 방식과 달리 명령어

길이를 고정하고 필요한 최소한의 명

령만을 지원한다는 개념으로 하드웨어

의 단순화를 통하여 동작 주파수의 향

상과 하드웨어량의 절감을 추구하고

있다. 그러나 시장에서는 두 방식 모두

성능향상을 위해서 복잡한 명령과 병

렬 실행을 추구한 마이크로 아키텍처

를 도입하고, 고성능이지만 소비전력

과 가격이 다 같이 높은 마이크로프로

세서를 계속해서 개발하고 있다.

이러한 상황에서 마침내 1990년

들어 기존의 제어용 마이크로 컴퓨터

와 워크스테이션/PC용 마이크로프로

세서와는 다른 임베디드 RISC 프로세

서가 등장하게 되었다. 예컨 ARM사

의 ARM, 모토로라의 M-Core, 히다

치제작소의 SH, NEC의 V8xx, 미쓰

비시의 M32R 등이 그것이다. 또한 워

크스테이션용 아키텍처 던 MIPS,

PowerPC도 경쟁에 합류했다. 이러한

새로운 유형의 마이크로프로세서는 가

전기기의 디지털화와 모바일화, 네트

워크 기기의 발전 등과 맞물려 큰 시장

으로 성장하여 2000년에 연간 5억

4,000만개를 돌파했다(그림 2 참조).

90년 초까지 가전 제품 등을 제어

하는데 사용된 제어용 마이크로 컴퓨

터는 1MIPS 정도의 성능을 지닌 제품

으로 가격이 가장 중시되었다. 반면,

워크스테이션과 PC에 사용되는 마이

크로프로세서는 1990년 초반에 이

미 50MIPS 정도로 훨씬 높은 성능의

것이 사용되었다. 하지만 소비전력이

수 W에 이르고 가격 또한 수 백만 원

을 상회했다. 이러한 상황에서 전자수

첩, 가정용 팩시 리, 고성능 프린터,

가정용 게임기 등과 같은 기기의 디지

털화가 본격화되면서 기존의 마이크로

컴퓨터와 워크스테이션/PC용 마이크

그림 1. 마이크로프로세서의 변천

4004 4bit

8bit

16bit

32bit

Z80 6809

Z8000

z80000 68020

68040

68030

68000

6800

8008

8080

8085

8086

808880186

80286

80386

80486 80860

Pentium

인텔 RISC 자일로그 모토로라

41Embedded World

로프로세서 사이를 메우는 마이크로프

로세서가 필요해졌다. 이러한 요구에

부응하기 위해서 1990년 에 들어

RISC 아키텍처를 기반으로 한 임베디

드용 마이크로프로세서가 등장하게 되

었다. 임베디드 RISC 프로세서는 기존

의 제어용과 워크스테이션/PC용의 마

이크로프로세서에서는 실현 불가능했

던 가격, 소비전력, 성능의 새로운

역을 수용했다. 따라서, 임베디드

RISC 프로세서는 저가격, 저소비 전

력, 고성능의 요구를 동시에 만족시키

는 방향으로 개발되고 있다.

임베디드 RISC 프로세서는 응용분

야가 주로 가전기기이기 때문에 가격

문제가 크게 두된다. 반도체 칩 비용

은 면적에 따라서 결정되기 때문에 면

적 효율이 좋은 아키텍처와 방식의 개

발이 요구된다. 저가격화를 위해서는

반도체 패키지 등의 실장 비용을 줄일

필요가 있으며 저소비 전력화도 요구

된다. 특히, 긴 배터리 사용시간이 필

요한 휴 기기에 사용하기 위해서 저

소비 전력화는 반드시 고려되어야 할

사항이다.

한편 오디오, 화상, 그래픽스 등

용량의 멀티미디어 데이터를 처리하기

위한 고성능화도 요구된다. 가전기기

의 디지털화가 붐을 타기 시작한 90년

중반부터 이러한 요구가 특히 고조

되었다. 예를 들면, PDA로 인터넷에

액세스하기 위해 모뎀 처리를 마이크

로프로세서가 수행할 필요가 생겼다.

디지털스틸카메라에서는 정지화상

(JPEG)의 압축과 신장을 단시간에 수

행하기 위한 성능이 요구되었다. 가정

용 게임기에서는 3차원 그래픽의 고정

세화와 객체의 자연스러운 움직임을

표현하기 위해 고속의 부동소수점 연

산이 필요했다. 또한 멀티미디어 처리

에 관해서는 종래의 워크스테이션과

PC용 마이크로프로세서를 능가하는

성능이 요구되기도 한다.

워크스테이션용 RISC의 명령어 세

트는 32비트 고정 길이를 기본으로 하

는 반면, 임베디드 용도에서는 프로그

램 사이즈를 가능한 작게 해야 하기 때

문에 명령어 길이가 재검토되고 있다.

예를 들어 SH의 명령어 포맷의 경우

명령어의 길이를 종래의 32비트에서

16비트 고정으로 하고 있다. 따라서 기

존의 RISC에서는 3 연산수 방식이었던

것을 2 연산수 방식으로 하거나, 지정

할 수 있는 레지스터의 개수를 줄이거

나 해서 즉치(immediate)와 디스플레

이스먼트 필드의 압축을 실행하고 있

다. 이로써 성능면의 단점은 발생하지

만 프로그램 사이즈는 기존의 RISC에

비해 30�40%의 절감이 가능해졌다.

또 다른 접근법으로서는 V8xx와 같

이 16비트와 32비트의 2종 명령어 길

이의 가변길이 명령어 세트로 하는 방

법, ARM7/9 Thumb와 같이 32비트

길이의 명령어 세트에 16비트 길이의

명령어 세트를 추가해서 서브 루틴 단

위로 전환하는 방법, PowerPC에서 이

루어지고 있듯이 32비트 고정길이 명

령의 프로그램을 압축해서 메모리에

보관하고 실행시에 하드웨어에서 늘리

는 방법이 있다.

첫 번째 방법은 향후 수퍼스칼라 등에

서 복수 명령의 동시 실행을 구현할 때

에 명령 컷아웃과 명령 디코드 논리의

복잡성이 지적되고 있다. 두 번째 방법

에서는 가능한 한 작은 추가 하드웨어와

적은 성능 오버헤드로 16비트 명령을

32비트 명령으로 매핑할 수 있도록 16

비트 명령어 체계를 정의하는 것이 중요

해진다. 세 번째는 명령 신장시 성능적

인 오버헤드가 걸릴 가능성이 있다.

한편, 비용 측면에서는 프로그램 사

이즈를 작게 하고 프로그램용 메모리

의 용량을 줄임으로써 비용을 낮출 수

있다. 특히 프로그램용 ROM, 플래시

메모리, SRAM을 단일 칩 상에 내장하

는 경우에는 큰 비용절감 효과를 기

할 수 있다.

멀티미디어 처리를 비한 명령 확장

최근의 디지털 기기에서는 오디오,

화상, 그래픽 등의 멀티미디어 데이터

를 처리하는 일이 많아졌다. 이에 임베

디드 RISC에서도 이러한 데이터를 효

율적으로 고속 처리하는 것이 요구되

그림 2. 임베디드 RISC 프로세서의 연간출하량

600

500

400

300

200

100

01996 1997 1998 1999 2000

연간

출하

량(백

만개

)

42

FEATURE STORY

고 있다. 따라서 MAC(Multiply and

Accumulate) 명령, 벡터 연산 명령,

SIMD(Single Instruction Multiple

Data) 방식, DSP 아키텍처의 집적 등

멀티미디어 처리에 비한 명령어 세

트의 확장이 이루어지고 있다. 모두 1

사이클 당 연산량을 늘려서 MOPS 값

을 향상시키려는 노력이다.

RISC를 임베디드 시장에 도입할 때

에 추가되는 표적인 명령은 정수계의

MAC 명령이다. 이 명령은 신호처리와

멀티미디어 처리의 고속화에 도움이 되

며 구현도 비교적 단순하기 때문에

부분의 명령어 세트에서 정의되고 있

다. 예를 들면, SH에서는 16×16+64

⇒64비트 및 32×32+64⇒64비트의

정수계 MAC 명령이 정의되고 있다.

SIMD 방식은 워크스테이션과 PC용

프로세서에서 앞서 도입되었다. 예를

들면, x86, Alpha, SPARC 등에서 멀

티미디어 처리용의 확장으로서 MMX

(Multimedia Extensions), MVI

(Motion Video Instructions), VIS

(Visual Instruction Set)가 정의되어

있다. 이 방식은 임베디드 RISC에서도

구현의 용이성과 그 효과측면에서 적극

채용되고 있다. 화상과 오디오 등의 데

이터를 표현하는 경우 8비트와 16비트

정도의 정 도로 충분한 경우가 많다.

SIMD 연산에서는 8비트, 16비트,

32비트의 부호 부가/부호 생략 정수

데이터를 32비트 혹은 64비트의 레지

스터에 격납해서 취급하는 것이 보통

이며, 각 데이터에 해 산술 논리 연

산 명령과 시프트 명령이 정의된다.

SIMD에서는 레지스터의 폭이 클수록

연산의 다중도가 증가해 가기 때문에

향후에도 레지스터 폭이 확장될 것으

로 전망되며, 이에 수반하여 폭이 넓은

(128비트와 256비트 등) 데이터의 로

드 스토어 명령도 정의될 것이다.

멀티미디어 처리에 한 별도의 접근

으로는 DSP 아키텍처를 통합하는 방법

도 있다. 이 프로세서는 통상의 RISC

코어 외에 멀티미디어 처리용 컴포넌트

를 포함하고 있는 DSP 코어, 데이터 저

장용 메모리를 포함하고 있다(그림 3).

지난 1992년에 임베디드 시장에 도

입되기 시작한 RISC 프로세서의 성능

은 15�20MIPS 다. 그후 해마다 2

배이상의 성능 향상을 달성하며 현재

1,000MIPS를 넘어섰다. 이처럼 높은

성능이 임베디드 프로세서에 필요한가

하는 의문이 생길 지 모르지만, 화상

데이터의 압축 등을 소프트웨어로 처

리하려고 하면 현재 가장 상위의 성능

으로도 불충분한 것이 얼마든지 존재

한다. 때문에 성능 향상을 위한 노력은

계속될 것이다.

고성능화는 동작 주파수의 향상과

명령 실행 사이클 수의 저감에 의해 실

현된다. 임베디드 RISC에서는 저가격

과 저소비 전력을 만족시킨 후에 고성

능화를 실현하는 것이 일반적인 접근

법으로 인식되어 있다. 이것이 성능을

중시하는 워크스테이션과 PC용 마이

크로프로세서의 개발 방향과 크게 다

른 점이다.

최근의 임베디드 RISC 프로세서는

비교적 낮은 동작 주파수와 소비전력

을 필요로 하는 제어용보다는 상위에

존재하며 비교적 높은 동작 주파수와

많은 소비전력을 요구하는 워크스테이

션 및 PC용보다는 하위에 위치한다(그

림 4 참조). PC용 마이크로프로세서는

1�1.5GHz의 것이 개발되어 있지만

소비 전력은 55�75W 정도이다. 임베

디드 RISC에서도 인텔이 800MHz의

그림 3. 임베디드 아키텍처의 변천

마이크로

마이크로

마크로

MPU

MCU

과거

DSP

MPU

코어

MPU

현재 미래

임베디드 용도로 사용되는 기능DSP

ROM 마이크로 ROM/FLASH

특정용도의 블록

ROM/FLASH/DRAM

특정용도의

빌딩 블록

표준 주변장치 특정 주문형

표준 주변장치

표준 주변장치

43Embedded World

엑스스케일(Xscale)을 개발, 주파수는

PC용의 절반까지 달성했지만 소비 전

력은 900mW로 압도적으로 작다. 또

한 주파수가 1GHz급에서 소비 전력이

1�2W 정도의 임베디드 RISC의 개발

도 진행되고 있다.

임베디드 RISC의 명령 실행 사이클

수의 저감 기술은 워크스테이션/PC용

프로세서와 공통되는 점이 많다. 수퍼

스칼라 기술은 임베디드 RISC 프로세

서 i960에서 처음 채용되었다. 이 기술

은 PC와 워크스테이션에서의 경우 순

차적으로(in-order) 두 개의 명령을

동시 처리하는 것에서 현재는 비순차

적으로(out-of-order) 여덟 개의 명

령을 동시 처리하도록 확장되었지만,

임베디드 시장에서는 순차적으로 두

개의 명령을 동시 처리하는 데 그치고

있다. 이것은 다중 명령의 동시 실행

혹은 비순차 제어에 의한 성능 향상의

효과와, 여기에 소요되는 설계 비용(설

계 복잡도)과 제조 비용(칩 면적과 소

비 전력) 증가분과의 균형으로 결정된

다. 임베디드 시장에서는 단순한 성능

지표 이상으로 이 성능 가격비가 중시

되고 있다.

멀티미디어 처리의 고속화에서는

MIPS 값과 함께 연산 성능인 MOPS

(maga operations per second) 값을

높일 필요가 있다. MAC 명령, 벡터 연

산 명령, SIMD 방식, DSP 통합 등의

멀티미디어용으로 확장된 다중 연산

명령을 높은 동작 주파수에서 실행함

으로써 MOPS/MFLOPS 값을 향상시

키고 있다.

실제 멀티미디어 처리에서는 메인 메

모리에 보관된 다중의 데이터를 프로세

서 내부에 로드해서 연산을 실행하고

결과를 저장하는 처리를 반복하는 일이

많다. 때문에 높은 연산 성능에 적합한

데이터 전송 성능도 갖출 필요가 있다.

이에 최근의 임베디드 RISC에서는 고

속 전송이 가능한 SDRAM, DDR

SDRAM, RDRAM으로 직접 연결되는

인터페이스를 통해 0.8�3.2GBps의

높은 스루풋을 달성하는 것도 있다.

고성능화와 더불어 휴 기기용 임베

디드 RISC 프로세서의 저소비 전력화

도 중요성이 높아지면서 개발에 있어

서 가장 고려해야 할 사항이다. 따라서

아키텍처, 논리 회로 방식, 프로세스의

각 계층에서 각각의 파라미터를 작게

억제하는 기술이 개발되고 있다. 또한

휴 용 기기에서는 스탠바이 전류가

문제가 되는 일도 있기 때문에 트랜지

스터의 기판에 역바이어스를 가해서

누설 전류를 한 자릿수 이상 저감하는

기술도 실용화되고 있다.

현재 최첨단의 임베디드 RISC 프로

세서에서는 0.18마이크론 공정 기술이

주로 사용되고 있다. 전원 전압은 1.5

�1.0V 정도까지 내려갔다. 그러나 계

속해서 고성능화가 추진되면서 소비

전력이 큰 문제로 두되고 있다. 수

기가헤르츠를 넘는 동작 주파수로 동

작시키면서 소비 전력을 낮게 억제할

수 있을 것인가, 서브 임계 누설 전류

와 게이트 누설 전류의 증 에 어떻게

처할 것인가, 하는 문제는 엔지니어

들에게 항상 던져지는 과제이다. 이를

해결하기 위해서는 임베디드 RISC 프

로세서의 응용 시스템을 잘 파악하면

서 소프트웨어, 아키텍처, 논리 회로

측면에서 다각적인 검토가 필요하다.

향후 수 년 간 이와 관련하여 새로운

기술을 창출하는 시기가 될 것으로 전

망된다.

그림 4. 소비 전력과 동작 주파수의 상황

1,000

100

10

0.01 0.1 1 10 100

소비 전력(W)

WS/PC용

제어용

임베디드 RISC

프로세서

동작

주파

수(M

Hz)

그 동안「COVER STORY」로 소개되었

던 기사를 이 달부터「FEATURE STORY」

로 변경함을 알립니다. 표지 디자인에 한

독자들의 다양한 의견을 수렴한 결과, 추상

적인 개념 전달을 지양하고 보다 구체적인

메시지를 전달하자는 데 의견이 모아졌습

니다. 따라서, 이 달부터 구체적인 임베디

드 시스템을 선정하여 표지 전면에 내세움

으로써 모두가 공감할 수 있도록 하고자 합

니다. 이에 부득이「COVER STORY」란 타

이틀 신에「FEATURE STORY」를 쓰게

됨을 널리 양지해 주시기 바랍니다.

알림알림

전기밥솥, 전자레인지, 냉장고, 비디

오, 오디오, DVD, TV 등등.

일반 가정에서 임베디드 프로세서가

존재할 만한 상을 언뜻 떠올려 보건

, 략 20가지가 넘는 가전 제품이

떠오른다. 이것만으로도 우리는 부지

불식간에 임베디드 프로세서의 혜택을

누리고 있음을 알 수 있다.

임베디드 프로세서를 일반적으로

‘Non-PC’ 상 프로세서라고 한다.

앞서 언급한 바와 같이 일반 가정에서

흔히 경험할 수 있는 PC 이외의 제품

들이 부분 임베디드 프로세서를 내

장하고 있다. 이러한 이유로, 개 임

베디드 프로세서라 하면 성능이 떨어

지는 프로세서를 떠올리기 쉽다. 그러

나, 꼭 그렇지만은 않다. 예를 들면 카

네비게이션, 셋톱박스, 라우터 등에 인

텔 펜티엄 4 수준은 아니지만 고성능

의 임베디드 프로세서가 탑재되고 있

다. 또한 최근의 컬러레이저프린터나

업무용 복사기의 경우 2GHz급 펜티엄

4의 처리 성능을 자랑하는 프로세서가

탑재되고 있다.

PC용 마이크로프로세서보다 임베디

드 프로세서가 시장에서 판매되는 수

량과 금액측면에서 월등히 앞선다는

사실은 분명해졌다. 지난 99년도에 발

표된 두 프로세서 판매량을 조사한 자

료에 따르면, 32비트 컴퓨터(워크스테

이션, 매킨토시, PC)용 마이크로프로

세서가 1억 개 안팎인데 비해 임베디드

용은 3억5,000만 개에 가까운 수량이

판매됐다. 이 수치는 현재 더욱 벌어져

있는 상태. 마이크로프로세서(MPU)와

마이크로컨트롤러(MCU)를 포함한

2000년도 임베디드 프로세서의 월평

균 판매량과 매출의 경우 5000만 개에

25억 달러를 각각 기록했다(참고로, 여

기서 MCU는 MPU나 DSP에 플래시

메모리 등을 내장한 것을 가리킨다. 최

근 들어 시스템온칩이라 하여 마이크

로프로세서 코어에 메모리와 주변장치

를 통합한 칩이 거 양산되고 있는데,

이러한 제품은 마이크로컨트롤러로 분

류하는 것이 일반적이다).

최근 주목할 만한 사실은 임베디드

프로세서도 과거와 달리 비트 수 변화

FEATURE STORY

44

전체 프로세서 시장에서 임베디드 프로세서가

차지하고 있는 시장 점유율은 얼마나 될 것인

가? 과장된 표현이긴 하지만, 일부 99% 이상이

라는 사람도 있다. 여기서 필자는 이러한 수치

의 진위를 따지기보다는 단지 과장돼 보이는 결

과가 나온 배경에 주목하고자 한다. 간단히 우

리 주변을 둘러보자. 가정에 컴퓨터는 통상 한

내지는 많아야 3 정도. 즉, 한 가정에 인텔

이나 AMD의 마이크로프로세서가 많아야 3개

라는 것이다. 반면, 임베디드 프로세서는 그 수

를 가늠하기조차 쉽지 않다. 이제 그 임베디드

프로세서의 격전장으로 들어가보자.

: 윤범진 기자/bjyoon@techworld.co.kr

임베디드 프로세서의

르네상스

임베디드 프로세서 산업동향 ②

가 급속히 진행되고 있다는 점이다. 불

과 3, 4년 전까지만 해도 출하량이 가

장 많은 임베디드 프로세서는 8비트

다. 이어 4비트와 16비트가 뒤를 이었

고 32비트는 상당히 적은 양이 출하되

었다. 그러나 매출은 32비트가 압도적

으로 많았다는 사실이 흥미롭다. 결과

적으로 임베디드 프로세서 업체들은

너나 할 것 없이 32비트에 주력, 이제

는 32비트가 50% 가까운 시장 점유율

을 기록하고 있다. 이어 16비트가 30%

로 뒤를 잇고 8비트는 략 16%에 머

물고 있다. 이러한 사실은 본지에서 실

시한 설문조사에서도 확인됐다.

이렇게 시장 판도가 바뀌면서 관련

업계에서는 어떤 변화가 벌어지고 있

을까? 전통적으로 32비트 임베디드 프

로세서 시장에서 모토로라의 68K계열

코어가 상당한 시장 장악력을 가지고

있었다. 즉, 모토로라를 선두로 MIPS

Technologies와 ARM사가 그 뒤를

쫓는 형국이었다. 그러나 1999년도에

시장은 지각변동을 일으켰다. ARM

사의‘반란’이 그것이다. ARM사는 모

토로라와 MIPS Technologies를

어내고 단숨에 두 단계를 뛰어올라 1위

로 등극했다. ARM사의 극적인 반전을

도운 것은 1998년 노키아가 출시한

GSM 모델인 Nokia 6110 셀룰러 폰

이라는 주장이 정설로 되어 있다. 즉,

셀룰러 폰 시장에서 시장 점유율을 확

장하기 위해 고심하고 있던 TI가 자사

의 DSP 코어와 통합하기 위해 ARM

프로세서 코어를 채택하고 이 칩을 셀

룰러 폰 시장의 거 기업인 노키아가

선택함에 따라 이 칩은 하나의 유행처

럼 확산되었다. 이를 계기로 ARM은

2000년도에 57.8%에 이어 2001년도

에는 76.8%의 시장 점유율을 기록했

다(그림 1 참조).

그러나, 한 가지 주목할 만한 사실을

간과해서는 안된다. 시장 점유율이 아

닌 점유율 증감 상태를 보면 2000년도

까지 급성장하던 ARM이 갑작스럽게

증감폭이 둔화된 반면 x86과 PowerPC

가 꾸준한 증가세를 보 다는 점이다.

이는 다시 한번 시장이 재조정 국면으로

접어들고 있음을 암시하는 것이다.

지금도 임베디드 프로세서 시장에서

막강한 세를 자랑하는 회사는 ARM사

이다. 저전력 소모를 요구하는 모바일

시장에서 ARM사의 지위는 독보적이

다. 이동전화기 시장에서 ARM의 시장

점유율은 70%를 상회한다. 모바일 시

장만큼은 모토로라도 자사의 M-Core

신 ARM 프로세서 코어를 채용해

DragonBall 제품을 개발할 정도다.

이밖에도 모바일 시장에서는 인텔도

예외 일 수 없다.

ARM은 지금까지 라이선스를 받은

업체 수에서 여타 경쟁사와의 격차를

크게 벌어놓은 상태다. 물론 선적량과

매출 부문에서도 경쟁사들을 크게 압

도하고 있다(그림 2). 현재까지 발표된

프로세서 중 가장 로엔드 제품인

ARM7은 가격과 전력소모에 민감한

모바일, 컨수머 애플리케이션에 최적

화된 32비트 RISC 마이크로프로세서

로서 ARM의 인기몰이를 주도하고 있

다. ARM7(V4T 아키텍처 기반)은

130MIPS(Dhrystone2.1) 정도의 성

능과 Thumb라는 16비트 명령어 세트

를 결합한 제품이다.

ARM9은 파이프라인 구조를 4단계

에서 5단계로 한 것 외에 단일 32비트

AMBA 버스 인터페이스와 Thumb 16

비트 명령어 세트가 추가됐으며, 동작

속도는 최 300MIPS 정도(Dhrys-

tone 2.1, 0.13마이크론 공정에서).

ARM10은 아키텍처(V5T) 상으로도

크게 바뀌어 파이프라인 구조가 5단계

에서 6단계로 향상되었으며 벡터 프로

세서와 DSP 명령어 세트, SIMD 연산

등의 외부 프로세서를 지원하는 것 외

에 Jazelle이라고 하는 Java를 고속으

로 처리할 수 있는 명령 등을 지원하는

45Embedded World

그림 1. 32비트 임베디드 프로세서별 출하량 추이 (자료: In-Stat/MDR)

68KARM

MIPS

SuperHx86PowerPC

1998 1999 2000 2001

Milio

ns o

f Uni

ts

450

400

350

300

250

200

150

100

50

0

46

FEATURE STORY

것이 특징이다. 처리 성능도 430+

Dhrystone 2.1 MIPS로 향상되었다.

지난해 10월에 발표된 ARM11에서는

멀티 프로세서와 부동소수점 연산을

지원하고 파이프라인 자체도 8단계로

늘었다. 또한 0.13마이크론 공정 기술

을 적용한 경우, 335�400MHz로 동

작하고 1.2MIPS/MHz 정도의 성능 범

위를 나타내고 있어 ARM의 입장에서

상당히 의욕을 가지고 있는 프로세서

이다.

최근 ARM사를 둘러싼 주변 기상도

를 살펴보건 이상 기류가 감지되고

있다. 즉, 다른 아키텍처와의 점유율

경쟁이 아니라, 같은 아키텍처끼리 경

쟁하는 상황이 벌어지고 있다. ARM

아키텍처의 시장 점유율이 상당히 크

기 때문에 전혀 예상치 못할 상황은 아

니다.

먼저, 본론으로 들어가기 전에 ARM

사의 제품 판매 형태에 해서 알아둘

필요가 있다. ARM은 표적인 펩리스

(fabless) 업체로 직접 칩을 제조하여

판매하지 않고 일종의 설계도를 판매

한다. 따라서 ARM으로부터 라이선스

를 받았다는 것은 ARM7이나 ARM9

의 설계도를 구입했다는 것이며, 계약

조건에 따라 라이선스 고객은 칩의 제

조와 판매를 할 수 있게 된다. 일반적

으로 라이선스 고객은 설계도를 살 때

도면값을 지불하며 칩을 제조하여 판

매할 때도 로열티를 지불해야 한다.

설계도는 크게 2종류가 존재한다.

일반적으로 하드 코어(Hard Core)와

소프트 코어(Soft Core)라고 부르며,

전자는 회로의 마스크를 그 로 사는

것이다. 이에 해 후자는 설계의 지침

서로 마스크를 위한 설계도라고 하는

것이 적절한 표현일 것이다. 하드 코어

를 구입할 경우, 마스크로 제공되기 때

문에 회로 변경을 한다는 것은 단히

어려운 일이다. 예를 들면, 파운드리

전문업체인 TSMC의 ARM7 마스크와

UMC의 ARM7 마스크는 당연히 다를

수밖에 없어 제조사를 바꾸는 것은 곤

란하다. 따라서, 요즘은 소프트 코어를

구입하는 것이 일반적인 추세이다.

지난해 10월말 기준으로 아키텍처별

라이선스 수는 ARM7 61건, ARM9

46건, SecurCore 6건, ARM10 5건으

로 나타났다. 이 결과에서 여전히 로엔

드 제품을 제조하는 곳이 많음을 알

수 있다. 그 이유 중 하나는 ARM 프

로세서의 수요를 고려할 경우에 단순

히 이러한 로엔드 제품의 수요가 많기

때문이라고 생각할 수 있지만, 사실은

라이선스 비용도 적지 않은 향을 미

친다.

ARM의 라이선싱 전략은 이미 라이

선스 계약이 이루어진 프로세서 코어

를 다른 제품에 사용할 때에도 단지 로

열티만으로 한정하는 것이었다. 이러

한 정책 하에서 IC 제조업체들은 같은

프로세서 코어를 사용해서 다양한 제

품을 만들 수 있었다. 로열티는 수입에

따라 결정되므로 사실상 IC 제품을 팔

지 못하더라도 로열티에 한 부담은

없는 것이다(이럴 경우, 다양한 개발

툴 업체들은 울상). 그러나 ARM7,

ARM9, ARM10을 개별적으로 구입해

야 하는 번거로움과 성능이 올라갈수

록 커지는 라이선스 비용 부담은 여전

했다.

이에 해 2001년부터 ARM은

‘Subscription deals’이라고 하는 포

괄적인 라이선스 정책을 도입, IC 제조

업체가 일단 라이선스 계약자로 계약

을 체결하면 한정된 기간 동안 어떠한

ARM 프로세서 코어라도 사용이 가능

하게 했다. ARM의 이런 노력이 있었

지만, 여전히 ARM7과 ARM9의 수요

가 많은 것으로 나타났다.

ARM사가 새로 진출하려는 시장의

관점에서 ARM7/ARM9는 반드시 높

은 성능이라고 말하기는 어렵다. 따라

그림 2. 각 아키텍처의 라이선스를 받고 있는 클라이언트 수의 비교

ARM

ARC Intl

MIPS

Tensillca

SuperH

PowerPC

80

70

60

50

40

30

20

10

0

서 낮은 성능의 프로세서에 한 수요

는 계속해서 낮아질 것이고, 그렇게 되

면 부가 기능을 추가해도 별 반응을 얻

기가 사실상 어렵게 된다.

예를 들면, 커넥선트의 CX82100 프

로세서는 ARM9 코어에 이더넷 MAC

2개와 USB 컨트롤러를 집적한 정보기

기(IA) 상 제품이다. 최 168MHz

로 동작할 수 있지만 부분의 제품은

140MHz 정도로 이용됐으며 158MIPS

정도의 성능을 나타냈다. 이 프로세서

는 2001년 발표 당시 광 역 라우터

에 인기가 있었다. 체로 30Mbps�

40Mbps 정도의 라우팅 성능을 가지

고 있어서 ADSL이나 케이블모뎀

상에는 충분하다고 판단되었기 때문

이다.

하지만, 2002년부터 이 시장은 타사

제품의 진출로 판매가 둔화되기 시작

했다. 또한 일부 시장은 더욱 높은 성

능을 요구하게 되어 이러한 시장에는

도저히 CX82100으로는 응할 수 없

었다. 일단 커넥선트는 부가가치 전략

으로서 CX82100에 xDSL을 겨냥한

회로를 추가한 CX82110을 발표했지만

시장의 반응은 기 에 미치지 못하고

있다는 평이다.

현재 ARM사는 명령어 세트에서 하

향적인 호환성을 유지하기 위해서 자

사의 아키텍처를 위한 명령어 세트를

엄격하게 관리하고 있다. 그리고 임베

디드 시장에서 변화하는 애플리케이션

에 응하기 위해 꾸준히 아키텍처를

확장해왔다. 이와 함께 ARM은 칩 성

능이 증가함에 따라 더욱 커지는 개발

비 부담을 줄이기 위해 인텔, 모토로라

와 ARM 아키텍처를 공동으로 개발하

는 협약을 체결했다. 바로‘아키텍처

라이선스’가 그것이다. 소프트 코어/

하드 코어보다도 발전된 수준의 이 라

이선스는 회로가 아닌 명령어 세트 수

준의 라이선스가 되는 것이다.

예컨 , 인텔이 ARM사로부터 인수

한 StrongARM이나 이후 인텔이 개발

한 Xscale이 있다. StrongARM은

ARM V4, Xscale은 ARM V5에 각각

호환성이 있지만 완전한 호환은 아니

다. 예를 들면, Xscale에는 Wireless

MMX라는 SIMD 연산 명령이 추가되

었지만, 이것은 ARM10의 SIMD 연산

명령과 아무런 호환성이 없다. 따라서

ARM 진 내의 아키텍처 다툼으로 비

화될 가능성도 배제할 수 없다. 예를

들면, Windows CE는 폭넓은 아키텍

처를 지원하지만 PocketPC 2002가

지원하는 것은 StrongARM 호환 제품

이며 같은 ARM계열 프로세서라도

ARM10에서는 PocketPC 2002가 동

작하지 않는다.

유사한 아키텍처 라이선스를 TI도

받았다. 이를 기반으로 TI는 ARM 코

어+DSP 제품을 개발, 판매하고 있다.

OMAP(Open Multimedia Applica-

tion Platform)이라고 하는 모바일 기

기 상 멀티미디어 프로세서는

ARM9 기반의 코어이지만, 실제로 기

능 확장이 되고 있어 ARM9과 100%

호환되지 않는다. TI는 ARM10/11을

기반으로 역시 독자적으로 확장한 제

품을 계속해서 발표해 나갈 계획이므

로 간극은 더욱 더 벌어질 가능성이 크

다. 이러한 상황은 인텔도 마찬가지이

다. 인텔의 Xscale을 기반으로 한 휴

전화 상 제품인 PXA210/250과도

호환성이 없다.

결과적으로, 그동안 ARM의 텃밭이

라고 할 수 있었던 휴 전화기 시장 내

에서 ARM 프로세서, 인텔의 Xscale,

TI의 ARM 코어 내장 DSP가 맹렬한

쟁탈전을 피하기는 어려울 전망이다.

또 한편으로는 전혀 다른 문제가

ARM사의 숙제로 남아 있다. 바로 성

능면에서의 약점이다. ARM11에서 동

작 속도는 500MHz에 달하고 성능도

1000MIPS를 초과하게 되었지만, 원

래의 코어는 성능보다는 효율을 우선

한 설계이기 때문에 고성능 시장 개척

은 걸음마 단계라고 할 수 있다. 게다

가 실제의 성능이라고 하면 ARM 아키

텍처는 경쟁사에 비해 열세에 있다. 앞

서 광 역 라우터에 해 언급했지만,

최근의 90Mbps급의 광 역 라우터는

부분 미국 브레시스(Brecis Com-

munications Corp)사의 MPS2000

을 사용하고 있다는 사실은 흥미로운

일이다. MSP2000은 MIPS Techno-

logies의 MIPS32 4Km 코어를 내장

하고 180MHz 정도로 동작한다.

MIPS32 4Km의 경우, 200MHz 구동

으로 240MIPS, 즉 1.2MIPS/MHz이

므로 180MHz 구동이라면 216MIPS

가 된다.

따라서 CX82100의 158MIPS와 그

렇게 성능의 차이가 있는 것은 아니지

만 실제의 스루풋은 90Mbps 이상으

로 배 이상의 성능차가 있다고 할 수

있다. 최근 신제품 발표차 방한한 브레

시스사의 George Alexy 사장도

“ARM 코어는 파워 효율이 좋은 반면

코어 성능은 우리가 원하는 수준을 만

족시키지 못하고 있다”고 일축했다.

47Embedded World

48

FEATURE STORY

최근 IA 기기는 모두 고성능화가 진

행되고 있어 그 부하는 상당히 높아지

고 있다. 예를 들면, 카 네비게이션이나

셋톱박스 등 앞으로 성장 가능성이 큰

시장에서 현재의 ARM 프로세서의 인

지도는 낮다. 따라서 신속하게 ARM10

이상, 실제 ARM11 이상의 프로세서가

투입되는 것이 정석이지만 아직은

ARM7이나 ARM9를 더 선호하는 분

위기다. 이러한 이유로 올해 ARM사는

코어 출하량에 관계없이 시장 점유율은

다소 내려갈 수 있다는 분석이 제기되

고 있다. 이는 경쟁업체들이 차지하고

있는 고성능 임베디드 시장의 규모가

점차 커지고 있기 때문이다.

임베디드 프로세서 업계의 2인자 자

리에 있는 MIPS Technologies의 비

즈니스 모델은 ARM과 같이 칩이 아닌

IP를 판매하는 형태다. 라이선스 형태

도 하드 코어/소프트 코어에 의한 프로

세서 코어 및 아키텍처를 라이선스로

제공하고 있다.

MIPS Technologies의 기술이 사용

되는 분야는 ARM과 달리 비교적 첨단

제품이 많다. 표적으로 MIPS Tech-

nologies의 MIPS 아키텍처는 셋톱박

스에서 막강한 향력을 행사하고 있

다. 이밖에도 컬러레이저프린터(62%),

라우터(55%), 비디오게임 콘솔(63%)

시장에서 시장 점유율 1위를 달리고 있

다. 반면 ARM은 디지털 셋톱박스 시

장에서 단지 6%의 점유율을 가지고 있

을 뿐이다(그림 3). 또한 스마트카드

시장에서 MIPS Technologies의 점

유율은 상당히 높은 편이다. 스마트카

드 분야는 앞으로 IC카드가 더욱 보급

될 전망이므로 MIPS Technolo-

gies의 로열티 수입은 더욱 늘어날 전

망이다. 이외에도 가전기기로서 비교

적 호조를 보이는 액정 프로젝터에도

MIPS가 많이 채용되고 있다.

MIPS 아키텍처는 ARM과 상당히

조적인 양상을 보이고 있다. ARM은

아키텍처 라이선스를 가지고 있는 기

업에서 호환성이 없어 문제가 되고 있

지만, MIPS는 초기부터 이러한 문제

를 감수하고 있었다. 예를 들면, PS2

의 메인 CPU인 이모션 엔진(emotion

engine)은 MIPS64를 기반으로 하면

서도 데이터 폭을 128비트로 하는 등

의 독자적인 확장이 추가돼 MIPS64와

호환성이 있다고 하기 어려운 상황이

다. 그런데 재미있는 것은 의외로 호환

성이 없다는 것이 문제가 되지 않고 있

다는 사실이다. 복수의 MIPS 라이선

스 고객이 독자적으로 확장한 MIPS

코어를 가지고 동일 시장에서 경쟁하

는 상황이 부분 발생하지 않고 있는

것이다.

굳이 말하면 네트워크 프로세서 분

야에서는 많은 벤더가 MIPS 코어

(MIPS64 20Kc급)를 이용한 독자 제

품을 공급하고 있지만, 이 제품이 사용

되어지는 시장은 특정용도 상이다.

따라서, 처음부터 호환성을 고려할 필

요가 없었기 때문에 결과적으로 부

분 문제가 없는 상태다(각 라우터 제조

업체가 자사 전용의 코어를 만들고 있

는 상태에 가깝다).

올해 MIPS Technologies가 새 코

어를 발표할 계획은 공개되지 않았다.

어쨌든 공정을 슈링크 하는 것만으로

도 간단히 높은 동작 속도의 프로세서

를 이용할 수 있다. 네트워크 프로세서

상에는 1GHz로 동작하는 제품(브로

드콤의 SB-1 코어)도 있기 때문에, 굳

이 새로운 코어를 투입하지 않아도 성

능면에서의 헤드룸은 충분하다고 보는

듯하다. 오히려 라이선스 고객에 의한

로엔드 상 시장으로의 재진입이 주요

관심을 끌고 있다. 예를 들면, AMD는

Alchemy 프로세서를 PDA 시장에 진

입시키기 위해 시기를 조율하고 있으

그림 3. 디지털 셋톱박스 시장 점유율

Other 1%

Micro

SPARK

17%SH

11%

ST Micro

22%

Power PC

11%

ARM6%

MIPS 31%

X86 1%

(자료: MIPS)

며, 휴 전화기 및 스마트카드 시장에

참여를 고려하고 있는 벤더도 있다.

일찍이 임베디드 프로세서 시장에서

최 세력을 자랑하던 제품이 모토로

라의 68000계열 프로세서다. 68000/

68020/68030의 각 마이크로프로세서

코어와 이것을 기반으로 한 SoC는 많

은 분야에 이용돼 왔다. 예를 들면,

DragonBall이라고 하는 68000계열

프로세서에 주변회로를 탑재한 칩은

이 후 DragonBall EZ/VZ/SZ로 발전

했다. 또한 68000 기반으로 통신 제어

계에 필요한 회로를 통합한 QUICC

(Quad Integrated Communication

Controller)라는 칩도 라우터 등에 폭

넓게 이용되고 있다.

이외에도 68000 기반으로는 성능

향상에 무리가 있다는 판단 하에 이

68000 명령의 서브세트를 처리할 수

있는 ColdFire라고 하는 RISC 엔진을

개발했다. ColdFire 계열은 이후 V2

ColdFire로부터 시작하여 파이프라인

구조를 확장한 V3 ColdFire, 제한된

수퍼스칼라를 탑재한 V4 ColdFire,

완전한 수퍼스칼라를 탑재한 V5

ColdFire까지 발표가 되었다. 다음에

출시될 V6 ColdFire에서는 슈퍼 파이

프라인이 도입될 예정이다. ColdFire

는 여전히 68K계열로 맥을 잇고 있다.

반면, DragonBall의 경우 68K계열을

계승하고 있는 DragonBall SZ와 거

의 같은 시기에 ARM9 코어를 내장한

DragonBall MX1이 발표된 이후

DragonBall은 68K 계열이 아닌

ARM계열 프로세서로 완전히 변신했

다. 또한 통신시장을 상으로 CPU를

PowerPC로 교체한 PowerQUICC도

발표되어 순조롭게 제품 출시가 이루

어지고 있다. 현재 PowerQUICC Ⅲ

까지 소개된 상태다(그림 4).

체로 모토로라는 가지고 있는

CPU 코어의 수가 단히 많다. 지금

까지 언급한 68K/ColdFire/ARM/

PowerPC 이외에도 모토로라는 M-

Core라는 또 다른 RISC 코어를 임베

디드 상으로 발표했다. 이러한 상황

에서 사실 어느 것에 포커스를 하고 있

는 지 파악하기 쉽지 않다. 략 로엔

드는 ColdFire, 미들레인지는 ARM,

하이엔드는 PowerPC로 전체적인 틀

을 짜고 있는 듯하다.

PowerPC 아키텍처는 원래 IBM의

Power 프로세서의 서브세트로서 탄생

했다. 이 프로세서의 보급에 결정적인

계기가 된 것은 매킨토시에 채용된 이후

부터다. PowerPC 자체는 단지 매킨토

시 뿐만 아니라 일찍부터 임베디드 프로

세서 상 제품에 도입되었다. 그 최초

의 제품이 된 것은 PPC401. 이후 클록

속도를 높여 성능을 개선한 PPC403 시

리즈와 내부 파이프라인을 고성능화한

PPC405, 그리고 매킨토시 컴퓨터와 고

성능을 필요로 하는 소형 장비를 겨냥한

49Embedded World

그림 4. 모토로라의 임베디드 프로세서 진화

DragonBallMX1

68000 68010

68302 68360 PowerQUICC

68K 계열

PowerPC 계열

ColdFire 계열

ARM 계열

PowerQUICCⅡ

PowerQUICCⅢ

68020 68030 68040 68060

DragonBall DragonBallEZ

DragonBallVZ

DragonBallSZ

ColdFire V2 ColdFire V3 ColdFire V4 ColdFire V5 ColdFire

DragonBallMX2

50

FEATURE STORY

PPC750의 파이프라인 구조를 도입한

PPC440 등이 존재한다.

특히, 지난 99년에 처음 발표되어 이

듬해 출시된 PPC440(PPC440GP)의 경

우, 0.18마이크론 공정에서 1000MIPS

＠555MHz의 상당히 높은 성능을 가

지고 있다. 이후 등장한 PPC440GX는

0.13마이크론 공정에서 1334MIPS@

667MHz의 성능을 나타내 MIPS64와

등한 성능을 자랑한다. 또 PowerPC

의 경우, 매킨토시 컴퓨터를 상으로

한 PPC603이 임베디드 프로세서로서

싱 보드컴퓨터(SBC)에 일부 적용되

고 있다.

그동안 큰 변화가 없었던 PowerPC

진 에 최근 변화의 조짐이 감지되고

있다. 우선, IBM과 모토로라 사이의

묘한 긴장 관계가 조성되고 있다.

PPC440은 모토로라의 PowerQUICC

Ⅲ를 상회하는 사양으로, 통신 제어 분

야에서 접전이 예상된다. 이에 해 모

토로라는 e500이라는 새로운 코어가

준비돼 있다. 2001년 10월에 처음 소

개된 이 코어는 AltiVec을 탑재한 것으

로 임베디드 상 최고속 PowerPC의

자리를 PPC440GX로부터 탈환하려는

모토로라의 야심작이라 할 수 있다.

모토로라의 AltiVec 기술은 단일 칩

솔루션에서 고 역폭 데이터 처리와

알고리즘-집중적인 계산들을 동시에

다루는 한편 첨단기술의 범용 처리 성

능을 제공함으로써 PowerPC 마이크

로프로세서들의 능력을 확장한다. 고

성능 벡터 병렬 처리 아키텍처의 추가

는 많은 데이터 항목들이 병렬로 동시

에 처리되는 것을 허용한다.

IBM은 최근 파격적인 발표로 임베

디드 프로세서 시장에 신선한 충격을

던져주고 있다. PPC400 시리즈 코어

를 써드파티에 라이선스하기 위한

‘Open PowerPC’프로그램을 발표한

것이다. IBM은 라이선스 고객이

PowerPC 코어에 새로운 기능을 추가

하거나 변경할 수 있도록 허용하는 한

편 상당히 공격적인 마케팅 전략을 암

시하고 있다. 더욱이 고객의 파운드리

선택의 유연성을 제공하기 위해 현재

외부 파운드리 인증 과정을 진행중인

것으로 알려졌다.

또한 케이던스, 시놉시스 등의 EDA

툴 업체들과 제휴를 체결해 이들이 설

계와 관련한 컨설팅을 제공하고 새로

운 설계 툴을 제공토록 했다.

IBM은 라이선스 상 프로세서를

PPC400 시리즈 코어로만 제한시킬

방침이지만, 향후 확 여부에 귀추가

자못 주목된다.

■참고문헌

[1] http://www.arm.com

[2] http://www.mips.com

[3] http://www.intel.com

[4] http://www.conexant.com

[5] http://www.ti.com

[6] http://www.brecis.com

[7] http://e-www.motorola.com

[8] http://www-3.ibm.com/chips/products/

powerpc/

[9] http://www.instat.com

[10] http://www.mdronline.com

[11] 월간 전자부품, 2001년 10월호

미국임베디드전자기술박람회 4월개최

본사전시참가및참관단모집

임베디드 관련 세계 최 박람회인『샌프란시스코 임베디드 전자기술 박람회 2003(Embedded Systems Conferences 2003 San Francisco: 이하

ESC)』개최된다.

오는 4월 22일부터 26일까지 5일간 미국 샌프란시스코 모스콘 컨벤션 센터(Moscone Convention Center)에서 열리는 ESC 2003은 임베디드 관련 전

문 박람회로서 매년 전세계를 순회하면서 개최된다.

올해로 15회째를 맞이하는 ESC는 샌프란시스코를 시작으로 보스턴, 뮌헨, 중국 등에서 개최 될 예정이며 전시 참가업체, 관람객 등 전시 규모에서 가장 큰

박람회로 이번 샌프란시스코에서 열리는 박람회에는 임베디드 관련 370여개 업체가 참가할 예정이다.

특히, 연초에 개최되는『ESC 샌프란시스코 2003』은 올해 임베디드 산업의 동향을 파악할 수 있는 절호의 기회로 인식되어 관련업체 및 단체들의 많은 참

가가 예상되며 컨퍼런스와 전시회로 나뉘어 보다 다양한 정보를 제공한다.

한편, 이번 전시회에 부스 참가 예정인 (주)테크월드에서는 전시 참관단을 모집한다. 참관단은 박람회 참관 후 라스베가스를 거쳐 세계 최 인공댐인 ’후버

댐’, 인공 호수인 미드호, 불의 계곡 등을 관광할 예정이다.

일정 문의:

(주) 테크월드 전시 사업부: (02) 835-2100

(주)동양국제관광 해외 전시사업부: (02) 753-0011

51Embedded World

“강력한 컴퓨터 기반 계측 솔루션을 만

들기 위해서는 소프트웨어의 유연성과 모

듈식 고성능 하드웨어 기술의 결합이 중

요하다. 이러한 접근방식을 통해 지속적

으로 성능이 향상되고 있는 PC 뿐만 아

니라 임베디드 시스템까지 개별 필요성을

만족시키는 계측 및 자동화 솔루션을 실

현할 수 있다”

NI의 Stefano Concezzi 이사는 그래

픽한 프로그램 언어인 LabVIEW가 임베

디드 시스템에도 중요한 역할을 할 것이

라며 이같이 말했다.

NI 발표 자료에 따르면, LabVIEW는

모듈 방식과 계층적 구조를 통해 기존 프

로그래밍에 비해 4배에서 최고 10배이상

짧은 시간에 시스템을 프로토타이핑, 설

계, 수정할 수 있다. 또한 LabVIEW 코

드를 다른 애플리케이션에서 쉽고 빠르

게 재사용할 수 있다. 이러한 장점으로

인해 LabVIEW 애플리케이션은 자동차,

통신, 항공, 반도체, 전자제품 설계 및

생산, 공정 제어 등을 포함하여 다양한

분야에서 구현되고 있다. 1986년으로 거

슬러 올라가는 LabVIEW의 역사는 지금

까지 6.1 버전에 이르고 있다(그림 1).

Stefano Concezzi 이사는 LabVIEW가

시장에서 성공할 수 있었던 이유로, 현장

의 요구와 변화를 읽고 환경을 계속해서

업그레이드했기 때문이라고 자평했다.

NI는 이번 KOFA 2003에 참가,

LabVIEW 6.1을 기반으로 소음 및 진동

을 측정하는 소프트웨어 모듈, 다접점 제

어를 위한 소프트웨어 모듈(LabVIEW

DSC) 데모를 선보 다. 또한 이 자리에서

Stefano Concezzi 이사는 LabVIEW 6.1

차기 버전에 한 자세한 일정과 내용에

한 언급은 회피했지만, 차기 버전의 한

지원에 한 긍정적인 답변을 내놨다.

끝으로, 그는“앞으로 LabVIEW를 센

서 제어까지 할 수 있게 발전시킬 계획이

다. 세세한 부품까지 확 해 나가 제품

모델링에서 생산까지 전체 공정을 관할

하게 될 것이다. 다음 버전에도 쉬운 것

을 더 쉽게 만드는 것에 주안점을 둬 엔

지니어들도 쓸 수 있는 도구로 자리잡길

바란다”면서 실력 있는 사용자가 많은 한

국에서 새 버전을 먼저 소개하고 싶다는

뜻을 밝혔다.

모델링에서 생산까지전공정으로확장

컴퓨터 기반 측정분야에서 26년 전부터 가상계

측(Virtual Instrument) 개념을 주창하며 측정

및 자동화 분야의 혁신을 이끌어온 내쇼날인스

트루먼트(NI, www.ni.com). 이 회사의

Stefano Concezzi 국제 마케팅 이사(사진)는

지난 3월4일부터 7일까지 삼성동 코엑스에서

개최된「제14회 한국국제공장자동화종합전

(KOFA)」을 통해 NI의 비전과 아이디어를 소개

했다.

: 윤범진 기자/bjyoon@techworld.co.kr

NATIONAL INSTRUMENTS

NI에서는 실시간(real-time) 솔루션을 개발할 수 있는 통합된 하드웨어 및 소프트웨어 제품을

제공한다. LabVIEW, LabVIEW Rael-Time 모듈 및 RT 시리즈 하드웨어를 사용하여 다양한 맞

춤형과 내장형 및 실시간 솔루션을 개발할 수 있다.

LabVIEW의 그래픽 개발환경을 사용하면 애플리케이션을 신속하게 개발한 다음 LabVIEW

Real-Time 모듈을 사용하여 실시간 성능을 보장하기 위한 전용 RT 시리즈 하드웨어 장치에 이

애플리케이션을 다운로드할 수 있다. RT 시리즈 플러그인 DAQ 장치를 사용하여 표준 데스크톱

컴퓨터에 내장된 실시간 구성요소를 만들거나, RT 시리즈 PXI를 사용하여 고성능 실시간 시스템

을 구성하거나, RT 시리즈 FieldPoint를 사용하여 지능형 분산 I/O 시스템을 구성할 수 있다.

NI의 실시간 솔루션 개발 지원

그림 1. LabVIEW의 변천

THE COMPANY

52

TECHNICAL FEATURE

지난 호에서는 UML의 기본적인 개념과 다양한 용도로 많이 사용되는 클래스 다이어그램에 한 내용으로 UML에 한 소개를 시작했었다. 이번 호

에는 UML에서 사용되는 나머지 다이어그램들에 해 다루어 보도록 하자.

: 김태현/(주)아이엠아이티 기술연구소

thkim@imit.co.kr

UML에서 사용되는 다이어그램

소프트웨어 분석∙설계 도구,

UML(하)

지난 호에서 언급한 바와 같이 UML의 다이어그램은 크

게 세 가지로 나뉘는데, 시스템의 구조적인 형태를 기술하

는 구조적 관점의 다이어그램(Structural Diagram), 시스

템의 동적인 행위를 기술하는 행위 관점의 다이어그램

(Behavioral Diagram), 모델의 전체적인 구조를 관리 해주

는 모델 관리 다이어그램(Model Management Diagram)

이 그것이다.

구조적 관점의 다이어그램(Structural Diagram)을 이용

하여 모델링하는 것은 시스템 내부의 객체(Object)와 그들

의 구분자(Classifier), 관계(Relationship), 어트리뷰트

(Attribute), 오퍼레이션(Operation) 등의 구조를 중심으

로 바라본 뷰(View)를 작성하는 것이다. 이렇게 작성된 다

이어그램들은 UML이 지향하는 바와 같이 그림 형태의 그

래프(Graph)로 나타나게 된다.

구조적 관점의 다이어그램에는 클래스 다이어그램(Class

Diagram)과 오브젝트 다이어그램(Object Diagram)으로

구분 가능한 정적 구조 다이어그램(Static Structure

Diagram), 컴포넌트 다이어그램(Component Diagram)과

디플로이먼트 다이어그램(Deployment Diagram)으로 구

분이 가능한 구현 다이어그램(Implementation Diagram)

이 있다.

Static Structure Diagrams

정적 구조 다이어그램(Static Structure Diagram)은 구

분자 요소들이 정적인 관계에 의해 연결되어 나타나는 그래

프 형태로 표현한다. 정적 구조 다이어그램으로 구분될 수

있는 다이어그램은 앞에서 밝힌 바와 같이 클래스 다이어그

램과 오브젝트 다이어그램이 있는데, UML과 연관 있는

부분의 CASE(Computer Aided Software Engineering)

도구들은 오브젝트 다이어그램을 지원할 때 클래스 다이어

그램을 통하여 지원하고 있다. 정적 구조 다이어그램은 지

난 호를 참조하도록 하자.

Implementation Diagram

구현 다이어그램(Implementation Diagram)은 소스 코

드 구조와 실행 환경 구조 등의 모델에 한 구현을 그래프

형태로 표현한다. 구현 다이어그램의 종류로는 컴포넌트 다

이어그램과 디플로이먼트 다이어그램이 있다.

컴포넌트 다이어그램은 소프트웨어 컴포넌트 사이의 구성

TECHNICAL FEATURE

53Embedded World

과 의존도를 보여준다. 컴포넌트 다이어그램은 일반적으로

소스코드를 모델링 할 필요가 있을 때, 실행되고 배포될 소

프트웨어가 완전한 상태에서 동작할 수 있게 컴포넌트들이

조립될 수 있도록 모델링 할 때, 물리적인 데이터베이스 모

델링 혹은 각종 부가적인 파일∙문서에 한 모델링이 필요

할 때, 어떤 상황에도 실행 시스템이 조금 더 버틸 수 있게

작동하는 것이 요구될 때 작성한다.

컴포넌트 다이어그램을 작성할 때는 각 다이어그램이 한

가지 초점에만 맞추어서 작성될 필요가 있다. 그리고 나타

나는 인터페이스가 명확하고, 꼭 필요한 인터페이스만 나타

나게 작성하는 것이 좋다.

디플로이먼트 다이어그램은 실행 요소와 소프트웨어 컴포

넌트, 그리고 프로세스(Process)들과 맞춰서 동작하는 객체

(Object)들의 구성(Configuration)으로, 실행 처리능력을

가지는 노드(Node)와 그 노드에 존재하는 컴포넌트로 보여

준다.

디플로이먼트 다이어그램은 일반적으로 특정한 하드웨어

에 소프트웨어를 내장하는 시스템을 모델링하기 위한 경우

나, 클라이언트(Client)/서버(Server)를 포함한 분산 시스

템의 물리적 소프트웨어 컴포넌트의 분산을 고려할 필요가

있을 때 작성한다.

표 1. Structural Diagram 핵심 요소들

요소

Class

Interface

Component

Node

설명

동일한 어트리뷰트, 오퍼레이션, 메소

드(method), 관계, 의미를 가지는 객체

의 기본형

여러 가지 오퍼레이션들의 묶음으로

클래스나 컴포넌트를 포함한 각 요소

의 서비스를 명세화

물리적이고, 교체 가능한 시스템의 부

분으로 인터페이스(interface)들을 나타

내고, 구현

시스템이 실행될 때, 존재하는 메모리

와 처리능력을 갖는 물리적인 객체

표기법

표 2. Structural Diagram 핵심 관계들

그림 1. Static Structure Diagram 예제

Graphic

Draw *

0..1

Rectangle

draw

Ellipse

draw

Text

draw

Canvas

draw

그림 2. Component Diagram 예제

Model

INodeI Observer

ModelListener

ModelObserver

표기법요소

Association

Aggregation,

Composition

Generalization

Dependency

설명

둘 혹은 그 이상의 구분자들 사이에서

그들의 인스턴스(instance)가 연결되어

있음을 나타내는 관계

연관(association)의 특수한 형태로서

전체-부분을 나타내는 관계. 일반적인

예로 자동차-엔진 관계를 들 수 있다.

더 일반적인 요소와 더 특수화된 요소

사이의 관계. 일반적인 예로 동물-인간

의 관계를 들 수 있다.

하나의 모델링 요소에게 변경이 일어나

면, 그 요소를 사용하는 다른 요소에게

향이 가해지는 것을 나타내는 관계

행위 관점의 다이어그램(Behavioral Diagram)을 이용하

여 모델링하는 것은, 여러 가지 관점에서 시스템의 동작형태

를 캡쳐하여 시스템이 어떻게 결과를 취득하는 것인지를 관찰

할 수 있다. 행위 관점의 다이어그램에는 사용자의 행위를 취

득하여 시스템을 분석하는 유스케이스 다이어그램(Usecase

Diagram), 그리고 콜래보레이션 다이어그램 (Collaboration

Diagram)과 같이 시간과 구조에 의해 분류가 가능한 인터액

션 다이어그램(Interaction Diagram), 상태 머신(State

Machine)을 나타내는 스테이트챠트 다이어그램(Statechart

Diagram), 워크플로(Workflow) 등을 기술하는 액티비티 다

이어그램(Activity Diagram) 등으로 구분된다.

Usecase Diagram

유스케이스 다이어그램(Usecase Diagram)은 사용자의

행위나 사용자가 원하는 목적을 알아내기 위해 사용한다.

또한, 유스케이스(Usecase)를 이용하여 사용자들에게 시스

템을 의미 있는 업무로 구분해 주므로 많은 유스케이스 기반

의 방법론에서 전체의 뷰(혹은 다이어그램 모델)를 하나의

관점으로 일치시켜주는 역할을 한다.

Interaction Diagrams

인터액션(Interaction)은 인스턴스 사이에서 오퍼레이션

그림 4. Usecase Diagram 예제

54

TECHNICAL FEATURE

그림 3. Deployment Diagram 예제

Scheduler

SchedaulerDB

Planner

SchedulerServer

IArrangment

ClientPC

표 3. Usecase Diagram 핵심 요소들

요소

Usecase

Actor

설명

시스템의 사용자가 상호작용 하는 시스

템에서수행가능한행위(Action)들의집합

유스케이스와 상호작용 할 때, 유스케

이스 사용자들이 맡는 역할. 일반적으

로 사람이지만, 다른 하드웨어 장비 혹

은 시스템이 행위자(actor) 역할을 맡는

경우도 존재함

표기법

표 4. Usecase Diagram 핵심 관계들

요소

Association

Generalization

Extends

Include

설명

행위자(actor)가 유스케이스에 참여하

거나, 사용하는 걸 나타내는 관계

더 일반적인 요소와 더 특수화된 요소

사이의 관계

어떤 유스케이스와 그 유스케이스를

확장한 유스케이스가 있을 때, 이를

나타내어 주는 관계. 지정된 지점에서

다른 유스케이스의 행위를 확장하여

실행한다.

어떤 유스케이스가 다른 유스케이스

의 행위를 명시적으로 수용하는 관계

표기법

Telephone Catalog

Customer

Salesperson

Shipping Clerk

Supervisor

Check

status

Place

order

Fill orders

Establish

Credit

55Embedded World

실행, 인스턴스 생성, 삭제 등 어떤 목적을 달성하기 위해서

교환되는 메시지(message)들로 구성된 행동이다. 이러한

메시지가 전달되면, 그 이후 후속적인 행동이 이어진다. 인

터액션 다이어그램은 이러한 인터액션에 의한 메시지의 흐

름을 모델링하는 것이다. 인터액션 다이어그램을 모델링하

는 방법은 일반적으로 두 가지가 있는데, 시간에 따라 각 메

시지 순서를 강조해 분석하는 것과 객체의 구조적인 관점에

서 어떤 순서로 메시지가 전달되는지를 분석하는 방법이 있

다. 시간의 순서를 강조해서 분석하는 것으로는 시퀀스 다

이어그램(Sequence Diagram)이 있고, 객체의 구조적인

관점에서 인터액션을 모델링하는 다이어그램으로는 콜래보

레이션 다이어그램(Collaboration Diagram)이 있다.

Statechart Diagram

스테이트챠트 다이어그램(Statechart Diagram)은 일반

적으로 이벤트에 의해 활성화되는 객체나, 클래스의 인스턴

스, 유스케이스의 상태에 따른 변화, 전체 시스템에 관한 행

동을 모델링하는 것에 사용된다. 또한, 스테이트챠트 다이

어그램은 스테이트 머신(State Machine)을 나타내며, 하나

의 스테이트(State)에서 다른 스테이트로의 제어흐름을 중

요시 한다. 이러한 스테이트의 전환(transition)은 특정한

이벤트에 의해서 발생하게 된다. 스테이트가 전환될 때에는

그에 상응하는 동작을 기술 할 수 있는데, 이로 인하여 각

행동을 나타낼 수 있다. UML의 스테이트챠트 다이어그램

은 동작의 전환 중에 첨부되어 나타나는 Mealy 스테이트

머신(Machine)과 각 동작들이 상태에 첨부되어 있는 Moor

머신 양쪽을 모두 표현할 수 있다.

Activity Diagram

UML 2.0은 스테이트챠트 다이어그램과 연관성이 없어질

예정이지만, 현재 표준인 UML 1.4의 액티비티 다이어그램

(Activity Diagram)은 부분의 스테이트가 액션 스테이트

(Action State)이고, 일반적으로 이러한 스테이트의 활동이

완료되면, 다음 스테이트로 전환이 이루어지는 것은 스테이

트챠트 다이어그램의 특수한 경우라고 볼 수 있다. 하지만,

사용 용도에 있어서는 스테이트챠트 다이어그램과 아주 다

르게 나타나는데, 부분의 경우 액티비티 다이어그램은 객

체 혹은 데이터의 흐름을 모델링하는 경우나, 비즈니스 프

표 5. Interaction Diagram 핵심 요소들

표 6. Interaction Diagram 핵심 관계들

요소

Instance

Action

Stimulus

Operation

Signal

설명

추상적인 개념(타입)의 구체적인 실제

형태로서 메시지가 오면 사용할 수 있

는 오퍼레이션들의 집합을 가지며, 오

퍼레이션들이 실행되었을 때 향을 저

장할 수 있는 요소. 일반적으로 클래스

의 인스턴스(instance)인 객체와 동일

실행되는 구문

인스턴스들 간의 통신 수단

동작에 향을 가하며, 인스턴스로부터

요청 받을 수 있는 서비스의 선언

인스턴스 간에 주고받는 비동기적인 자

극(stimulus)을 나타내는 것

표기법

요소

Link

Attribute Link

설명

인스턴스들 간의 연결

인스턴스의 어트리뷰트 값을 저장

표기법

그림 5. Interaction Diagram 예제(Sequence Diagram)

getValue price

getName

teller : Order : Article

56

TECHNICAL FEATURE

로세스가 이루어지는 것을 나타내는 모델을 작성할 때에 워

크플로우(workflow)를 나타내는데 자주 사용된다.

모델 관리(Model Management) 요소들은 다른 여러 가

지 요소들을 특정한 관점 혹은 이유로 묶어주어, 사용자가

쉽게 관리할 수 있게 하거나 특정한 관점으로 시스템을 바라

볼 수 있게 돕는다.

Package

패키지(Package)는 여러 가지 종류의 모델 요소를 묶는

요소이다. 패키지는 또한 자바 언어의 패키지와 마찬가지

로, 포함하는 여러 요소들의 네임스페이스(Namespace)로

동작할 수 있다.

패키지가 포함하는 요소들은 Public, Protected,

Private 등의 가시성(visibility)으로 패키지 외부에 공개할

지를 표현할 수 있다. 패키지를 사용하는 가장 일반적인 목

적은 비슷한 습성을 가진 요소들을 공동으로 관리하거나,

연관된 요소들을 합쳐서 설명할 필요가 있을 때 이를 묶어서

표현하는 것에 있다. 이외에도, 전체적인 관점에서 모델 요

소들에 해 바라보기가 필요한 경우나, 또는 큰 모델을 이

용하여 조직화할 경우, 네임스페이스를 분리하고 싶을 경우

에 패키지를 사용한다.

표 7. Statechart Diagram 핵심 요소들

요소

State

Signal

설명

객체의 생명주기 동안 동작하는 조건,

상황 등의 상태로서 어떤 이벤트(event)

에 의해 활성화되며, 다른 이벤트를 기

다리거나 활동을 수행한다.

비동기적인 자극으로 어떤 동작이나

스테이트 전환(transition)을 촉발한다.

표기법

표 8. Statechart Diagram 핵심 관계들

요소

Transition

설명

두 스테이트(state)간의 관계로서, 전 스

테이트에 있던 객체가 어떤 동작을 수

행 한 후에 특정 조건이 만족되었을 때,

다음 스테이트로 전환되는 것

표기법

그림 6. Statechart Diagram

Wait

checkConn/CheckBuffering

Receiving

Processing

Online dataBegin

dataEnd

ready

offline

표 9. Statechart Diagram 핵심 요소들

요소

Action State

Call State

Swimlane

설명

일반적으로 하나의 진입 액션과 상

황에 맞는 전환이 하나만 존재하는

스테이트

진입 액션으로 호출 액션(Call Action)

만을 가지는 액션 스테이트

스테이트들을 책임에 의하여 체계화

하는 것

표기법

그림 7. Activity Diagram

Tum on

Machine

Brew

Coffee

Pour

Coffee

Tum on

light

goes out

coffeePot

57Embedded World

Subsystem

시스템은 모델링을 하기 위한 전체의 구조와 실체이다. 서

브시스템(Subsystem)은 단어의 의미 그 로 하부 시스템

으로서, 갖가지 요소로 복잡하게 얽힌 시스템을 상호 독립

적이고, 이해하기 쉬운 부분들로 분해하여 나타내는 것이

다. 이러한 분해는 각각의 목적성에 의해 구분하여 작성할

수 있다.

서브시스템은 Operations, Specification Elements,

Realization Elements의 세 부분으로 구분하여 표현되는

데, Operations는 좌측 상단 부분에, Specification

Elements는 좌측 하단 부분에, Realization Elements는

우측 부분에 나타낸다. 각 부분은 서브시스템 상에 꼭 나타

나야 할 필요는 없다.

Model

모델(Model)은 시스템을 특정한 목적으로 바라본 다음 그

것을 기록한 것이다. 일반적으로 모델은 다이어그램에 거의

나타나지 않으며, 다이어그램은 모델의 문서역할을 한다.

모델은 보통 서로 다른 관계자들에게 그 목적에 맞는 모델링

결과를 보여줄 필요가 있을 때나 어떤 특정한 면을 부각하

여, 시스템을 바라볼 때 사용된다.

지금까지 UML의 각 다이어그램에 해 간단하게 살펴보

았다. 분량의 문제로 이번 호의 내용이 UML 다이어그램에

한 너무나 단편적인 지식의 나열이나 소개로 그친 것 같아

아쉬운 생각을 금할 길 없다. “어떻게”에 해당하는 정보를

담으려 했으나, 지면 관계상“왜”에 해당하는 정보만을 제공

할 수 밖에 없었다.

UML 각 요소의 의미나 문법에 해 더 알고 싶다면

OMG의 UML 페이지(http://www.omg.org/ uml)에서

찾을 수 있는 UML 1.4 Specification 문서를 찾아보길 바

란다. 3장의 UML Notation Guide는 UML 문법의 기본이

다. UML 내부에 해 깊은 이해를 원하는 독자는 2장의

UML Semantics를 연구하면 UML 전체에 한 깊은 이해

가 가능할 것이다.

UML 자체가 가지는 이점은 한정적이다. UML의 진정한

힘은 방법론과 연계되었을 때 발휘된다. 만약 여러분이

UML을 처음 접하거나, UML에 익숙하지 않다면, 방법론을

배워나가면서 UML을 병행해서 배워나가는 것을 추천하고

싶다. 부디 UML, 방법론, 실무, 이 모든 것을 함께 엮어 더

발전적인 소프트웨어를 설계, 개발 할 수 있기를 바라면

을 마친다.

■참고도서

∙“UML Distilled”(2nd Edition), Kendall Scott, Martin Fowler, Addison-

Wesley, 1999(번역서 존재)

∙“The Unified Modeling Language User Guide”, Grady Booch, Ivar

Jacobson, James rumbaugh, Addison-Wesley, 1998(번역서 존재)

∙“UML Components : A Simple Process for Specifying Component-

Based Software”, John Cheesman, John Daniels, Addison-Wesley,

2000(번역서 존재)

∙“Use Case Driven Object Modeling with UML A Practical Approach”,

Doug Rosenberg, Kendall Scott, Addison-Wesley, 1999(번역서 존재)

표 10. Package

요소

Package

설명

여러 가지 모델 요소들을 묶는 역할

표기법

표 11. Subsystem

요소

Subsystem

설명

시스템을 상호 독립적이고, 이해하기

쉬운 부분들로 분해하여 각종 요소를

묶어서 나타내는 것으로, 그 중 일부는

내부 다른 요소들의 행동명세를 제공

표기법

표 12. Model

요소

Model

설명

시스템을 특정한 목적으로 바라본 다

음 그것을 기록한 것

표기법

58

TECHNICAL FEATURE

SoC 디자인을 개발하는 시스템 설계자들은 아키텍처를 평가하고 하드웨어 및 소프트웨어를 동시에 검증할 수 있는 일관된 방법론 부재로 설계상의

한계에 이르고 있다. SystemC 2.0은 상위 레벨의 추상화에서 하드웨어 시스템 컴포넌트 모델인 트랜잭션층 모델(TLM)을 편리하게 개발할 수 있도

록 한다. SystemC는 모듈 기반이므로 기존에 개발된 컴포넌트를 다른 시스템에 재사용 할 수 있다. 이 에서는 이러한 개념들에 해 살펴보고,

SoC TLM 플랫폼 사례를 설명하고자 한다.

: Rohit Jindal, Srikant Reddy Modugula, Kshitiz Jain

ST마이크로일렉트로닉스 India R&D

SystemC 기반의 TLM을 이용한

하드웨어/소프트웨어 초기 동시 디자인

SoC 디자인을 개발하는 시스템 설계자들은 아키텍처를

평가하고 하드웨어 및 소프트웨어를 동시에 검증할 수 있는

일관된 방법론 부재로 설계상의 한계에 이르고 있다. 디자

인 작업 후반에 디자인을 변경하기 위해 제품의 출시 시간이

지연되는 문제를 방지하기 위해서는 디자인 작업 초기에 평

가 및 검증이 이루어져야 한다. SystemC 2.0은 상위 레벨

의 추상화에서 하드웨어 시스템 컴포넌트 모델인 트랜잭션

층 모델(TLM)을 편리하게 개발할 수 있도록 한다. 시스템

설계자들은 TLM 모델을 신속하게 개발할 수 있으며, 시스

템의 초기 기능적 사양이 결정되기만 하면 실행 가능한 하드

웨어 블록 사양을 곧바로 얻을 수 있다.

TLM을 신속하게 시뮬레이션 할 수 있으므로 하드웨어 종

속적인 애플리케이션 소프트웨어를 신속하게 개발하고 검증

할 수 있다. 이 모델들은 타이밍 사양을 통합할 수 있기 때

문에 성능 예측 및 아키텍처 검증이 가능하다.

SystemC는 모듈 기반이므로 기존에 개발된 컴포넌트를

다른 시스템에 재사용 할 수 있다. 이 에서는 이러한 개념

들에 해 살펴보고, SoC TLM 플랫폼 사례를 설명하고자

한다.

시스템온칩(SoC)은 프로세서, 타이머, 인터럽트 컨트롤

러, 버스, 메모리, 임베디드 소프트웨어 등 다수의 컴포넌트

로 구성된다. SoC는 하나의 완전한 시스템으로서, 몇 년 전

이라면 보드에 조립했겠지만 현재는 반도체 기술의 발달로

모든 요소를 단일 회로에 집적할 수 있다. 레이아웃 디자인

과 검증 플로에 한 기존의 RTL은 수백만 게이트급의 시

스템에 적합하지 않은 것으로 드러났다. 이들 시스템에서

실행되는 임베디드 소프트웨어가 갈수록 복잡해지기 때문이

다. ST마이크로일렉트로닉스는 레이아웃 플로에 한 RTL

이 구체화되기 전에 디자인 및 검증을 실시하는 방법을 집중

시켜 설계 플로를 확장시키고 있다. 이것을 시스템-투-

RTL 플로라고 한다.

시스템은 다양한 레벨 추상화로 모델링 할 수 있다. 여기

서 사용되는 전문용어는 논문마다 약간씩 다를 수 있지만 확

실하게 구분되는 개념들은 같다. 이 에서 말하는 마이크

로 아키텍처 레벨 추상화는 매우 낮은 레벨에서 사이클 및

시스템 동작을 검증할 수 있는 모든 핀 및 신호에 한 기술

을 포함한 사이클의 정확한 모델을 의미한다. 아키텍처 레

벨 추상화는 이보다 덜 구체적이지만 구현에 따라 달라질 수

있다. 이것은 코드를 실행하고 디버그 하기 위해 추상화 단

계에서 만들어지는 프로세서의 명령어를 이용할 수 있는 소

프트웨어 개발자들에게 유용하다. 마지막으로 기능 레벨 추

상화는 상세한 구현에 크게 신경 쓰지 않고 시스템의 기능적

동작을 포착할 수 있다. 이 모델은 일반적으로 아키텍처에

종속적이지 않다.

TECHNICAL FEATURE

59Embedded World

시스템온칩을 위한 ST의 확장 플로는 트랜잭션 레벨 모

델링이라는 개념을 제시한다. 이 모델은 구체적이지 않으며

RTL 모델과 같은 마이크로 아키텍처와도 관계가 없다. 오

히려 이 모델은 아키텍처 레벨 추상화에 해당된다. 이것은

상위 레벨 디자인 프로세스의 자연스러운 확장인데, 그 이

유는 SoC 디자인이 실질적으로 트랜잭션층에서 이루어지

기 때문이다. 시스템 설계자는 핀과 주소 버스의 관계부터

생각하지 않는다. 이들은 데이터 유형이나 데이터가 저장되

는 장소와 같은 데이터 플로 사양을 맵핑하는 것부터 시작

한다.

SoC 분야에서 트랜잭션이라는 용어는 여러 가지 뜻으로

이용된다. 이 에서 트랜잭션이라는 용어는 모델링하고 시

뮬레이션된 시스템의 두 컴포넌트 사이에 데이터 또는 이벤

트가 교환되는 것을 의미한다. 여기서는 이러한 교환이 일

어나도록 하는 프로토콜에 해 다루지 않기 때문에 마이크

로 아키텍처를 검증하지 않는다. 데이터 트랜잭션은 단일

단어, 연속적 단어, 또는 데이터가 버스를 통해 시스템 컴포

넌트간에 전송되는 복잡한 데이터 구조일 수 있다. 예를 들

면 DMA 마스터가 메모리에서 데이터를 읽어오라고 요청할

수 있다.

이를 위해 DMA 마스터는 데이터를 읽을 메모리 주소를

지정하는 읽기 트랜잭션을 실행시킨다. 또 다른 예로서 임

베디드 소프트웨어가 DMA 컨트롤러 레지스터에 데이터를

쓰기 위해 쓰기 트랜잭션을 실행시킬 수 있다. 이벤트 트랜

잭션은 동기화를 모델링함으로써 SoC 모델이 정확하게 동

작하는지 확인한다. 컴포넌트간의 인터럽트가 이벤트 트랜

잭션의 한 예로 고려될 수 있다.

트랜잭션층 모델링에서 중요한 요소는 임베디드 소프트

웨어(eSW)이다. 부분의 SoC는 하나 이상의 프로그래머

블 프로세서를 포함하기 때문에 SoC에서 소프트웨어는 반

드시 필요한 요소이다. TLM 모델은 SoC 개발주기 초기에

개발된 모델을 고속으로 시뮬레이션 할 수 있기 때문에

eSW 개발이 간편하다. 이 작업을 위해 필요한 속도는 완제

품 시뮬레이션 시간의 1/1000�1/100 정도로 다양하다. 이

는 초당 최소 100k 버스 트랜잭션 시뮬레이션 속도에 해당

된다. 이 속도는 TLM 모델에서는 가능하지만, 훨씬 느린

경향이 있는 상세 RTL 모델에서는 불가능하다. TLM 모델

은 아키텍처 사양이 구체화되자마자 곧바로, 또는 시간 소

모적인 RTL 코드 개발이 시작되기 전에라도 구축될 수 있

다. 이것은 많은 시간이 소요되는 eSW 개발 작업을 RTL

개발 이후가 아니라 RTL 개발과 동시에 진행할 수 있다는

의미이다.

하위 레벨 소프트웨어 개발과 같은 하드웨어 구현과 접

한 작업들은 여전히 RTL 모델이 완성되기를 기다려야 하지

만, 이 기법을 이용함으로써 경우에 따라서는 개발주기를

최고 수개월까지 절약할 수 있을 것이다. 한 예로 ST마이크

로일렉트로닉스의 MPEG4 IVT 팀은 상위 레벨 네트리스트

(netlist)가 완성되기 6개월 전에 eSW 개발에 TLM 모델을

이용할 수 있었다.

언타임드(untimed) TLM 모델은 물리적 시간이나 지속

개념이 없는 이벤트의 순서를 지정하는 기능을 포함하고 있

어 eSW 개발자들에게 유용한 일차적인 분석 토 를 제공한

다. 시스템 설계자는 타임드(timed) TLM 모델에 더욱 관심

이 많으며, 이 모델을 이용해 아키텍처를 검증할 수 있다.

어떤 이는 RTL에서의 사이클 정확도 모델이 더 정확한 분

석이 가능하다고 주장할 수 있다. 하지만, 이 생각은 부분적

으로만 옳은 것이다. 이러한 사이클 정확도 모델은 TLM 모

델 개발에 필요한 것보다 훨씬 많은 시간을 필요로 하기 때

문이다. 예를 들어 HW/SW 간의 상쇄(trade-off) 현상을

검사한다든지 할 때, 상세 모델은 TLM 모델에 비해 변경이

어렵다. 아키텍처를 검증하기 위해 TLM 모델을 이용하는

것에 해서는 아직 연구 중이다. 아키텍처 검증을 위해 상

위 레벨의 TLM 모델 개발자들에게 모델링 가이드라인을 제

공하는 핵심적인 사안들은 시스템 설계자들이 채택하기 전

에 좀 더 고찰되어야 한다.

ST마이크로일렉트로닉스의 시스템 아키텍처 그룹(CR&D)

이 실시한 실험에서[1] 복잡한 듀얼 프로세서 SoC 플랫폼을

60

TECHNICAL FEATURE

TLM 및 RTL 레벨에서 비교한 결과, TLM 모델이 RTL

SoC 시뮬레이션에서 나타난 트랜잭션에 비해 부분의 지

수에서(인터럽트 지연시간, 버스 활용 등) 오류가 15% 적은

것으로 나타났다. 이것은 다른 SoC 모델을 이용해 새롭고

추가적인 비교 작업을 위한 기본으로 이미 사용되고 있는 놀

라운 결과이다. 이 비교를 통해 타임드 TLM 레벨에서의 결

정이 사이클 정확도 레퍼런스 RTL 플랫폼 레벨에서도 유용

할 수 있다는 것을 제시함으로써 RTL 개발자와 설계 엔지

니어들에게 확신을 줄 수 있을 것이다.

위에서 설명한 방법 로라면 SoC 라이프사이클은 3개의

추상화 레벨에서 하나씩 최소한 3개 모델이 필요하다. SoC

의 기능은 아키텍처에 종속되지 않기 때문에 기능 모델은 제

품 사양의 초기 단계에서 시작할 수 있다. SoC 아키텍처 사

양이 결정되면 RTL 코드 개발 및 SoC TLM 모델 작업을

시작한다. TLM 모델은 상세 RTL 모델에 비해 훨씬 더 짧

은 시간 안에 개발할 수 있다. 따라서 첫 번째 아키텍처 사

양이 배포되면 거의 곧바로 eSW 개발 및 아키텍처 검증을

시작할 수 있다. 소프트웨어 및 아키텍처 팀이 SoC TLM 모

델을 작업하는 동안, RTL 개발 작업은 SoC RTL 플랫폼을

완성시킨다.

이 단계에서 하위 레벨 소프트웨어 개발 및 검증과 같은

하드웨어 구현에 종속된 작업을 시작할 수 있다. 이들 작업

은 표준 ASIC 디자인 플로를 이용해 합성 및 백엔드 구현

작업과 동시에 수행할 수 있다. 최초의 하드웨어 에뮬레이

터 보드가 완성되었을 때까지 eSW가 개발되고 완벽하게 검

증되었기 때문에 첫 번째 실리콘 제품의 성공 가능성이 높아

진다. 이 플로에서 주의를 기울여야 하는 한 가지 문제는,

동일한 시스템의 기능, 아키텍처, 마이크로 아키텍처 등 3개

의 관점에서 일관성을 유지하는 것이다. 모든 관점에서 동

일한 시스템의 테스트 벡터를 이용해 예상한 기능과 일치하

는지 확인함으로써 문제를 해결할 수 있다.

ST마이크로일렉트로닉스는 트랜잭션 레벨 모델링을 위해

SystemC 2.0을 이용했다. SystemC는 전적으로 시스템

레벨 모델링을 위한 C++ 라이브러리이다. C++의 모든 장

점을 제공하며, 객체 지향 디자인 언어로서 데이터 캡슐화

및 일반 프로그래밍 개념을 최 한 반 했다. SystemC 2.0

은 트랜잭션을 교환할 일차적인 채널을 정의하지만, 사용자

가 각각의 디자인 조건에 따라 보다 상위 레벨의 SystemC

채널을 정의할 수 있도록 했다.

TLM 플랫폼에서의 통신은 프리미티브 채널을 이용해 제

공되고 동기화는 이벤트를 기반으로 이루어진다. ST는 [3]

에 제시된 조건에 따라 채널을 개발했다. 이 통신 채널은

eSW 개발을 위한 고속 시뮬레이션 조건을 충족했다. 프로

세스 동기화 및 통신 개선 작업을 위해 필요한 빌딩 블록은

(사용자정의) 인터페이스, 포트 및 채널이다. 인터페이스는

일련의 방법을 정의할 뿐이지 이들 방법을 구현하지는 않는

다. 이 인터페이스는 구현 사양을 예측하지 않기 위해 데이

터를 갖추지 않은 순수한 가상 객체이다. 채널은 하나 이상

의 인터페이스를 구현한다.

포트는 모듈을 작동시켜 그 프로세스가 채널 인터페이스

를 액세스할 수 있도록 한다. 포트는 인터페이스 유형에

따라 정의되기 때문에 포트는 그 인터페이스 유형을 구현

하는 채널하고만 이용할 수 있다. 인터페이스를 이용하면

채널의 인터페이스 방법을 호출하는 인터페이스 방법 호

출[3]이라고 하는 기법이 가능하다. 인터페이스 방법은 채

널에서 구현되지만 호출자(프로세스) 맥락에서 실행된다.

인터페이스 방법의 한 예로 FIFO의 읽기 중단 방법을 들

수 있다. 이 인터페이스 방법을 호출하면 이용할 수 있는

데이터가 충분하지 않을 때 호출자(프로세스)를 중지시킬

수 있다.

ST가 개발한 채널은 다음과 같은 특징을 갖는다.

∙ 마스터/슬레이브 지향 트랜잭션: 마스터가 트랜잭션을

지시하면(읽기 또는 쓰기 동작) 슬레이브가 이를 실행

한다.

∙ 다중 마스터/다중 슬레이브 지원: 중재 가능한 복수의

마스터가 지원되므로 성능을 확장하기가 용이하다.

∙ 등록 기능: 마스터가 등록을 할 수 있고 특수한 교환을

위해 플랫폼의 슬레이브에 관한 정보를 얻을 수 있다.

∙ 이벤트에 의한 동기화: 임시적 스케쥴 정책이 구현되는

61Embedded World

것을 방지함으로써 플랫폼 확장성을 향상시킨다.

∙ 디코딩은 슬레이브 측에서 이루어진다.

∙ 채널 중재 정책은 채널에서 제공한 라우팅 기능을 이용

하는 사용자 정의 시스템 모듈에 의해 제어된다. 따라

서 완벽한 tac 채널은 아비터+라우터이다.

ST의 시스템 아키텍처 그룹(CR&D)이 개발한 SoC TLM

플랫폼을 살펴본다. 이 TLM 플랫폼은 ARM의 Micro-

pack/PWP SoC의 일부분이다. 이 플랫폼은 시스템 레벨의

트랜잭션을 처리할 수 있도록 SystemC 2.0을 이용해 C++

로 작성된 것이다.

이를 위해 우선 ST에서 시스템 디자인 요건을 분석한 후,

IP TLM 모델링 엔지니어에게 하위 레벨(읽기, 쓰기 등) 프

리미티브를 제공하는 상위 레벨의 SystemC 통신 채널을

개발했다.

PWP TLM 플랫폼의 IP 블록 소스 코드는 다른 플랫폼을

도출할 수 있는 사례로 이용되었다. 무료 공개소스

SystemC 2.0 커널과 GNU 컴파일러 및 디버거만으로 이

와 같은 TLM IP를 개발할 수 있었다.

이 플랫폼은 다음과 같이 구성된다.

∙ 타이머와 2개의 계수기(PWP 기능 사양 준수)

∙ 인터럽트 컨트롤러(PWP 기능 사양 준수)

∙ 메모리

∙ WS 키보드에서의 입력을 포착하는 UART

∙ IP 간에 량 데이터를 전송하는 DMA

∙ 출력을 표시하는 LCD

∙ 컴퓨터 기능 실행 및 인터럽트를 처리하는 트래픽 제너

레이터

제너레이터에는 벽돌쌓기 게임용 C 애플리케이션이 들어

있다. 이 제너레이터는 UART를 실행해 워크스테이션 키보

드의 핵심 스트로크를 포착하고 LCDC를 실행해 LCD에 표

시한다(여기서 LCD는 xterm이다). 다른 주변장치도 벽돌

쌓기 게임에 맞게 설정된다(그림 1 참조).

채널은 다음과 같이 설명된다.

typedef tac_seq tac_channel;

tac_channel<DATA_TYPE>

tac_channel_inst("TAC_CHANNEL");

typedef은 tac_channel 포인트를 사용자 정의의 구현

채널로 만드는데 사용된다(아비터+라우터).

각 블록을 SystemC로 모델링하고, 메인 함수에서 기술

하고, 채널에 연결한다.

MEMORY = new

memory("MEMORY",MEMSPACESIZE,MEMBASE);

MEMORY->slave_port(tac_channel_inst);

TIMER = new timer

("TIMER",TIMERSPACESIZE,TIMERBASE);

TIMER->slave_port(tac_channel_inst);

TIMER->int_timer1(int_timer1);

그림 1. 제너레이터를 이용한 PWP 플랫폼

GNU xterm

VIC

WDT TIMER

ARM 1 AHB

ARM 0 AHB

LCD AHBDMA 1 AHB(periph)

DMA 2 AHB(Memory)

EXPANSION AHB

RTC UART

WS Keyboard

TACCHANNEL

LCDC DMA

Generator

MEM MEM

62

TECHNICAL FEATURE

TIMER->int_timer2(int_timer2);

ITC = new itc

("ITC",INTSPACESIZE,INTBASE);

ITC->slave_port(tac_channel_inst);

ITC->int_timer1(int_timer1);

ITC->int_timer2(int_timer2);

ITC->nIRQ(nIRQ);

GENE = new

generator("GENERATOR",0,MEMBASE,true);

GENE->nIRQ(nIRQ);

GENE->master_port(tac_channel_inst);

마찬가지로 다른 IP를 연결할 수 있다. 다음은 트래픽 제

너레이터 코드(벽돌쌓기 게임)에서 추출한 쓰기 및 읽기 프

리미티브의 처리 예이다.

░타이머 구성(쓰기 동작):

master_port.write(TIMER1LOAD,701);

master_port.write(TIMER1CONTROL,TIMER_ENA

BLED |

TIMER_PERIODIC_MODE | TIMER_PRESCALE_16);

master_port.write(TIMER2LOAD,500);

master_port.write(TIMER2CONTROL,TIMER_ENA

BLED |

TIMER_PERIODIC_MODE |

TIMER_PRESCALE_256);

░ 메모리에서 데이터 블록 읽기

master_port.read(addr,verif_mem,BLOCK_SIZE);

░ 인터럽트 처리(추가 스레드가 인터럽트 관리):

if ( IRQ_Handled ) {

wait(IRQ_End);

}

그림 2는 xterm 화면의 출력을 보여준다. 화살표를 이용

해 게임을 할 수 있다.

위에 설명한 플랫폼 버전에서 제너레이터 모듈이 플랫폼

컴포넌트를 조정하는 명령을 포함하고 있다. 후속 버전에서

는 이 제너레이터를 ARM ISS에서 실행되는 eSW로 교체

했다(그림 3). 이들 버전에서는 eSW가 플랫폼을 조정한다.

여기서 제너레이터를 사용한 것은 시스템에서 일어나는 트

랜잭션을 쉽게 설명하기 위해서이다. 제너레이터는 ISS에

서 실행되는 eSW의 기능을 복제할 수 있으며 시스템의 나

머지 부분에 해 동일한 인터페이스를 제공할 수 있다. 따

라서 eSW 및 ISS 신 제너레이터를 이용해 나머지 시스템

컴포넌트를 검증 및 검사할 수 있다.

eSW를 디버그 할 때는 ISS 디버거를 이용할 수 있다. 또

한 채널에 트랜잭션을 기록하는 기능이 있으며, Signalscan

(Cadence사의 파형 뷰어)을 이용해 이 기록을 볼 수 있다.

PWP 플랫폼의 경우는, 모든 전송이 단일 단어일 뿐 아

니라 인터럽트 프로세싱 시간에 한 시뮬레이션 속도가

플랫폼 버전에 따라 초당 120�170K 버스 트랜잭션이다.

일부 트랜잭션이 단일 단어 전송이 아니라 블록 전송인 경

우에는 초당 수백만 버스 트랜잭션의 속도를 나타냈다

(ISS를 마스터로 이용하는 플랫폼 버전은 이 속도가 제한

될 수 있다). 벤치마크 결과는 450MHz 속도 및 256MB

RAM의 SUN Ultra 10 워크스테이션에서 측정한 결과와

일치한다.

그림 2. xterm에서 PWP의 사례 출력

63Embedded World

비용을 절약하고 개발 시간을 단축하기 위해서는 기존에

개발된 컴포넌트의 재사용이 필수적이다. 기존에는 거의 최

종 구현 단계에 이른 컴포넌트를 재사용하는 것이 효과적인

것으로 나타났다. 하지만, 이 단계의 컴포넌트를 재사용하

는 것이 언제나 효과적인 것은 아니다. 이 단계에서 사양을

조금만 바꾸더라도 구현이 달라지고 많은 재모델링 작업이

필요할 수 있기 때문이다. 하지만 추상화 수준을 높이면 디

자인 차이를 줄일 수 있어 보다 상위 레벨의 추상화를 공유

할 수 있고 최소의 재작업으로 최종적인 구현 작업을 달성할

수 있다. 이것이 상위 레벨에서 하드웨어 및 소프트웨어 구

현 라이브러리를 구축하는 첫 단계이며, 이렇게 함으로써

라이브러리가 여러 플랫폼에 걸쳐 안정적일 수 있다.

물론 기술의 변화에 따라 물리적 구현을 반 할 하위 레벨

추상화를 포함해 다중 레벨 라이브러리 역시 중요하다. 그

렇지만 보다 상위 레벨(시스템-RTL 플로우)에서의 재사용

이 중요하다는 것을 무시해서는 안된다. 다수의 시스템 설

계 엔지니어들이 아직까지 재사용 가능한 상위 레벨의 시스

템 라이브러리 개념을 채택하지 않고 있다. 임베디드 시스

템이 갈수록 복잡해지는 상황에서 이 문제를 해결하기 위해

서는 어떤 형태로든 디자인을 재사용해야 한다는 점을 인식

해야 할 것이다.

시스템 설계자와 임베디드 소프트웨어 개발자들은 자신들

의 디자인 플로에 트랜잭션 레벨 모델링(TLM)을 도입하기

시작했다. TLM은 초기 단계에서 아키텍처를 검증하고 eSW

를 개발해야 하는 이들의 조건을 충족시킨다.

SystemC 2.0은 TLM 모델링을 지원하며 TLM 보급을 위

한 언어로 자리잡고 있다. 하지만 아키텍처 검증 방법론을

형식화시켜야 하며, 상호호환성을 높이기 위해서는 공통된

모델링 가이드라인을 채택해야 하는 문제가 있다. 앞으로 몇

년 후에는 SoC 콘텐츠의 부분이 사전에 디자인될 것으로

예상된다. 만약 그렇게 된다면 아키텍처의 다수 요소가 사

전에 결정되는 방향으로 플랫폼이 변화할 것이다. SystemC

를 이용한 모듈러 방식은 시스템 컴포넌트 라이브러리를 개

발하고 다양한 플랫폼에 이를 재사용할 수 있도록 하므로

SoC 품질을 떨어뜨리지 않으며 제품의 출시 시간을 단축할

수 있다.

■참고문헌

[1] A. Clouard, G. Mastrorocco, F. Carbognani, A. Perrin, F, Ghenassia.

"Towards Bridging the Precision Gap between SoC Transactional

and Cycle Accurate Levels", DATE 2002

[2] A. Ferrari and A. Sangiovanni-Vincentelli, System Design.

"Traditional Concepts and New Paradigms". Proceedings of the

1999 Int. Conf. On Comp. Des, Oct 1999, Austin

[3] "Functional Specification for SystemC 2.0", Version 2.0-P, 0ct 2001

[4] Frank Vahid, Tony Givargis. "Embedded System Design: A Unified

Hardware /Software Introduction". John Wiley & Sons, Inc

그림 3. ISS를 이용한 PWP 플랫폼

ADS xterm

VIC

WDT TIMER

ARM 1 AHB

ARM 0 AHB

LCD AHBDMA 1 AHB(periph)

DMA 2 AHB(Memory)

EXPANSION AHB

RTC UART

WS Keyboard

TACCHANNEL

LCDC DMA

ISS

MEM MEM

64

TECHNICAL FEATURE

내장형 소프트웨어의 중심인 실시간 운 체제(Real-Time Operating System)의 내부 구조를 국내 상용 실시간 운 체제인

Velos(www.velos.co.kr)를 예로 하여 알아본다. 실시간 운 체제를 탐구하기 위한 첫 시간으로 실시간 시스템과 실시간 운 체제가 무엇인지에

해서 살펴보고, RTOS의 기본이 되는 쓰레드의 관리에 해서 알아보자.

: 홍차연 주임연구원/한국MDS 기술연구소

chayeon@hkmds.com

Velos를 예제로 한

RTOS INSIDE①

실시간 시스템의 정의를 알아보기 앞서 실시간(real-time)이라는 단어에 해

서 살펴보자. 실시간 인터넷 방송, 실시간 항공권 예약, 실시간 번역, 실시간 증권

정보 등 많은 분야에서‘실시간’이라는 단어가 사용된다. 실시간이란, 주어진 요

청이 주어진 데드라인 안에 처리됨을 의미한다. 예를 들어, 항공권 실시간 예약

시스템은 고객 예약 요청에 해서 주어진 데드라인 안에 예약을 완료하는 시스

템을 의미한다. 여기에서 데드라인은 사용자가 주관적이고 암묵적으로 정한 매우

짧은 시간이다. 그래서 항공권 예약 요청이 사용자가 정한 데드라인을 넘어서 처

리되면 그 시스템은 실시간 항공권 예약 시스템이 아닌 것이다. 같은 의미에서 컴

퓨터 공학에 실시간 시스템이란 시스템 위에서 수행되고 있는 각 태스크의 데드

라인을 만족시켜주는 시스템이다. 각 태스크는 우선순위 기반으로 수행되며 우선

순위가 높은 태스크일수록 우선적으로 데드라인이 만족된다. 이를 위해서 우선순

위가 높은 태스크는 우선순위가 낮은 태스크를 선점하여 우선적으로 수행할 수

있어야 한다. 이 에서는 실시간 시스템을 컴퓨터 공학에서 말하는 실시간 시스

템으로 한정하도록 한다.

실시간 시스템은 데드라인 불만족으로 초래하는 결과의 위험성에 따라 경성 실

시간 시스템(hard real-time system)과 연성 실시간 시스템(soft real-time

system)으로 구분한다. 주어진 일이 데드라인 안에 완료되지 않아 인명이나 금전

적인 피해 등의 심각한 결과를 초래하면 경성 실시간 시스템이라 한다. 항공기 제

어와 핵발전소 제어가 여기에 속한다. 반면, 주어진 일이 데드라인 안에 완료되지

TECHNICAL FEATURE

개괄 및 쓰레드 관리

연재순서

1회 개괄 및 쓰레드 관리

2회 스케줄링 기법

3회 쓰레드간의 동기화 및 통신

4회 인터럽트 처리

5회 동적 메모리 관리 기법

6회 클록, 타이머, 시그널

65Embedded World

않아도 큰 피해를 주지 않는 시스템을 연성 실시간 시스템이

라 한다. 멀티미디어 응용 프로그램 등이 여기에 속한다. 경

성 실시간 시스템인 핵발전소와 항공기의 실시간 제어가 실

패하면 방사능 유출 및 항공기 추락 등의 엄청난 피해를 초

래할 수 있다.

그러나 연성 실시간 시스템인 MPEG 비디오나 MP3 플

레이어는 실시간 제어가 실패하더라도 보고 듣기에 다소 불

편할 뿐 큰 피해를 주지 않는다. 경성 실시간 시스템과 연성

실시간 시스템을 구분하는 기준은 다소 주관적이다. 만일

MPEG 시스템의 실시간 만족에 의해서 회사의 사활이 걸렸

다면 MPEG 시스템도 경성 실시간 시스템으로 구분할 수

있다. 즉, 경성 및 연성 실시간 시스템의 구분은 주어진 일

의 주관적인 중요도에 따라서 구분된다.

실시간 시스템에서 태스크는 주기적으로 수행될 수 있고

비주기적으로 수행될 수 있다. 이러한 주기성과 비주기성에

의해서 주어진 일에 한 시간 제약 요소들이 정해진다. 주

기적인 일은 주기, 개방시간(release time), 데드라인, 수행

시간, 슬랙(slack) 등이 시간 제약 요소가 된다. 반면 비주기

적인 일은 시작 시간(start time), 수행 시간, 데드라인만이

시간 제약 요소가 된다. 그림 1과 2는 주기 및 비주기적인

태스크의 시간 제약 요소를 보여준다.

실시간 운 체제는 말 그 로 실시간 시스템을 운 하는 소

프트웨어 시스템이다. 실시간 운 체제의 역할은 크게 두 가

지이다. 일반 운 체제처럼 응용 프로그램을 위해 하드웨어를

추상화한 API를 제공하는 역할과 시스템 내의 자원(CPU,

Memory, I/O 장치 등)을 효율적으로 관리하여 시스템 내에

있는 태스크들의 데드라인을 만족시켜 주는 역할이 그것이다.

구체적으로 실시간 운 체제는 다음을 만족해야 한다.

∙ 우선순위 기반 선점형 멀티태스킹

→ 우선순위가 높은 태스크가 실시간 제약을 만족시키

기 위해서 보다 우선순위가 낮은 태스크를 선점하여

시스템 자원을 먼저 획득할 수 있어야 한다.

∙ 실시간 제약 만족

그림 1. 주기 태스크의 실시간 제약 요소

deadline

release time computation time slackt

period

그림 2. 비주기 태스크의 실시간 제약 요소

Computation time

tt

deadline

66

TECHNICAL FEATURE

→ 모든 태스크는 자신의 데드라인 안에 수행을 완료하

여야 한다.

∙ 고장감내(fault tolerances)

→ 시스템이 이상이 생겨도 모든 태스크의 실시간 제약

은 만족되어야 한다.

∙ 효율적인 시스템 자원 관리

→ 시스템 자원을 효율적으로 관리하여 각 태스크들의

실시간 제약을 만족해야 한다.

∙ 빠른 문맥 교환 시간

→ 문맥 교환 시간은 시간 제약 요소에 속하지 않으므

로 off-line에서 시간 분석을 할 때 고려하지 않는

다. 그러므로 문맥 교환 시간은 짧으면 짧을수록 시

간 분석 로 실제로 시스템에서 태스크들은 스케줄

링 될 것이다.

∙ 작은 크기

→ RTOS의 크기가 작으면 메모리 등의 자원이 태스크

에 더 많이 할당하게 한다. 또한 RTOS의 복잡도가

작아져 RTOS의 이식성(portability) 및 확장성이

좋아진다.

∙ 빠른 외부 인터럽트 응답시간

→ 외부 인터럽트는 하드웨어 수준에서 제공해주기 때

문에 다른 태스크에 비해서 우선순위가 가장 높다.

그러나 인터럽트가 하는 일의 내용은 다른 태스크의

내용보다 우선순위가 낮을 수 있다. 예를 들어, 보통

네트워크 인터럽트 핸들러는 현재 수행 중인 태스크

에 상관없이 도착한 패킷을 프로토콜 처리한다. 도

착한 패킷은 수행 중이었던 태스크보다 우선순위가

낮은 태스크의 것일 수 있다. 즉, 우선순위가 낮은

태스크 때문에 우선순위가 높은 태스크가 실시간 제

약을 보장받지 못 할 수 있음을 의미한다. 이를 우선

순위 역전 현상이라고 한다. 이 현상을 방지하기 위

해서 외부 인터럽트 응답시간은 작으면 좋다.

∙ 최소의 인터럽트 불능 기간

→ 태스크 간의 문맥 교환은 인터럽트에 의해서 발생되

므로 인터럽트 불능 기간은 짧으면 좋다.

∙ API

→ 응용 프로그램 프로그래머가 쉽게 응용 프로그램을

작성할 수 있도록 API를 제공해야 한다. 표준 API를

제공하면 더 효율적으로 프로그램을 작성할 수 있다.

이러한 RTOS에는 Windriver사의 VxWorks, Green

Hills의 ThreadX, QNX사의 QNX, 한국MDS의 Velos 등

이 있다. 다음 장에서 Velos를 예로 들어 실시간 운 체제

의 내부구조에 해서 살펴보도록 한다.

Velos의 내부구조를 살펴보기에 앞서 Velos 실시간 운

체제에 해서 간단히 알아보자. Velos는 내장형 시스템 응

용(embedded system applications)을 위한 실시간 운

체제이다. 내장형 시스템은 CPU 속도, 메모리, 전력소비,

입출력 장치 등 다양한 시스템 자원의 제약이 있다. 따라서

시스템마다 다양한 구성을 요구한다. Velos는 이러한 내장

형 시스템을 구성하여 수행하는데 최적의 성능을 보일 수 있

도록 설계되었다. Velos의 주요 특징은 다음과 같다.

∙ 라이브러리 커널

∙ POSIX 1003.13 PSE51 minimal real-time

system profile 제공

∙ 다중 쓰레딩(multi-threading)

∙ 실시간 스케줄링 지원

∙ 동적 프로그램 로딩 지원

∙ TCP/IP 네트워크 프로토콜 스택 지원

그림 3은 Velos의 커널 구조를 보여준다. Velos는 라이

브러리 커널로 응용 프로그램 소스 및 각종 라이브러리와 함

께 링크되어 하나의 이미지로 메모리에 적재(loading)된다.

따라서 Velos의 각 시스템은 컴파일 시에 시스템 구성에 따

라 추가 및 제거가 가능하다. 사용자는 시스템 구성에 필요

한 최소한의 구성요소만을 링크하여 시스템을 구성할 수 있

다. Velos의 자세한 특징에 해서는 본지 3월호 기사「국

내 독자 기술의 POSIX 기반 실시간 운 체제」(118~123 페

이지)를 참조하기 바란다.

실시간 시스템은 여러 개의 태스크(task)를 수행한다

67Embedded World

(multi-tasking). 효과적인 다중 태스크(multi-tasking)

실행 환경을 보장하기 위해 실시간 운 체제는 실시간 스케

줄러를 사용해 우선순위와 제약조건을 만족시키는 방향으로

태스크를 스케줄링한다. 이러한 일반적인 실시간 태스크는

Velos에서 쓰레드와 응된다.

Velos의 쓰레드는 각자의 레지스터 문맥과 스택을 가지

고 수행된다. 그러나 동일한 주소공간 내에서 수행되기 때

문에 다른 쓰레드와 주소공간을 공유하게 된다. Velos의 쓰

레드는 다음과 같이 크게 두 종류로 나뉜다.

∙ pthread: IEEE 1003.1c 표준에서 정의한 쓰레드 관

리 및 동기화에 한 인터페이스를 제공하며 우선순위

기반 선점형 스케줄링 및 라운드 로빈 스케줄링을 지원

한다.

∙ real-time thread: pthread를 확장 지원하여 주기적

쓰레드를 위한 주기, 데드라인, 위상을 정의한다. 또한

데드라인 처리기 설정 기능 및 시간 장벽 등에 의한 동

기화를 추가로 지원한다.

본 장에서는 이러한 Velos 쓰레드의 관리에 해서 설명

한다.

Velos 쓰레드 상태

Velos에서 쓰레드는 수행되면서 그림 4의 상태 천이도에

따라 상태 천이한다. 각 상태에 따라 쓰레드는 특정 큐에 속

해 있거나 어떤 큐에도 속해 있지 않게 된다. 모든 쓰레드는

START에서 생성되어 READY 상태로 된 후 여러 상태 전

이를 거친 후 TERMINATED 상태에서 끝나게 된다. 표 1

은 Velos 쓰레드의 상태를 전이하는 함수이다.

쓰레드 제어 블록

각 쓰레드는 쓰레드 제어 블록(Thread Control Block:

TCB)에 의해 관리된다. 쓰레드 제어 블록은 쓰레드의 상태

정보 및 문맥 정보를 비롯하여 스케줄링 정보 등 쓰레드의

관리에 필요한 다양한 정보를 가지고 있다.

쓰레드는 생성되면서 TCB 하나를 할당받게 되고 초기화

된 후에 특정 큐에 들어가게 된다(거의 부분 ready 큐로

들어간다). 쓰레드는 큐 안에서 이중 연결 리스트로 연결되

며 TCB는 이를 위해서 두 개의 리스트를 위한 포인터가 있

다. 이 중 하나는 allthread 큐 안에서 TCB끼리 연결되며

다른 하나는 ready 큐나 sleep 큐 안에서 TCB끼리 연결된

그림 3. Velos 라이브러리 커널

응용 프로그램

응용 프로그램

Velos

라이브러리 커널

라이브러리

동적 로딩

정적 로딩

POSIX API

thread manager

bootinterrupt

servicescheduler

memory

allocator

device

drivers

Socket API Win32 API

Embedded real-time applications

hardware

protocol stack window system

이벤트 사용자 함수

schedule/preempt/yield sleep/wakeup 이벤트와 동시에 발생

Sleep 쓰레드를 블록시키는 함수

Wakeup 블록된 쓰레드를 깨워주는 함수

Yield thread_yield( )

Exit Pthread_exit( )

Suspend thread_suspend( )

Resume thread_continue( )

표 1. Velos 쓰레드 상태 전이 함수

68

TECHNICAL FEATURE

다. 이 두 가지 큐에 해서는 쓰레드 큐 관리 부분에서 자

세하게 설명한다.

리스트 포인터 이후의 TCB 필드는 각각 Velos가 쓰레드

스케줄링 및 관리에 필요한 각종 정보를 저장한다.

쓰레드 우선순위

Velos에서의 각 쓰레드는 고정 우선순위를 가진다. 어느

순간에 Velos는 READY 상태에 놓여 있는 쓰레드 중에서

가장 높은 우선순위의 쓰레드를 선택하여 수행시킨다. 쓰레

드의 우선순위는 생성시에 지정해 줄 수도 있으며 사용자에

의해 쓰레드 수행 중에 바꿀 수 있다. 또한 우선순위 계승

프로토콜에 의해서도 우선순위는 바뀌게 된다. 우선순위는

TCB에서 두 가지 필드로 유지된다.

∙ sched_priority: 이 값은 사용자가 쓰레드의 생성 시

나 수행 중에 제공되는 인터페이스를 통해서 고정적으

로 할당해 주는 값이다.

∙ iprio: 우선순위 계승 프로토콜에 의해서 변하는 값이

다. 사용자가 직접 바꿀 수 없으며 이 값이 실제 쓰레

드의 우선순위를 결정하는데 사용된다.

Velos의 쓰레드는 0�255 사이의 값을 우선순위로 가질

수 있다. 우선순위는 POSIX 규약에 따라 큰 값이 높은 우선

순위가 되어 0이 가장 낮은 우선순위이고 255가 가장 높은

우선순위이다. 이 중 사용자 쓰레드는 POSIX에서 정의된

PTHREAD_MAX_PRIORITY(245)와 Velos에서 정의한

THREAD_MIN_PRIORITY(1) 사이의 값을 가질 수 있다.

나머지 우선순위 값들은 시스템 쓰레드에 의해서 할당되어

있으며, 이 값을 사용할 경우 커널이 올바르게 수행되지 않

을 수 있다.

Thread Queue Management

Velos에서 쓰레드는 특정 상태에 있을 때 특정 큐에 속해

있게 된다. Velos에서 쓰레드 큐는 크게 3가지가 있다.

∙ all thread queue: 모든 생성된 쓰레드를 관리하는 큐

이다. 쓰레드의 TCB는 상태에 관계없이 생성과 동시

에 본 큐에 속하게 된다. TCB들은 allthread를 헤더

로 TCB의 all_prev와 all_next 필드에 의해 일반 큐

와는 따로 리스트를 만들게 된다. 주로 쓰레드의 모니

터링이나 기타 통계 용도로 사용된다.

∙ ready queue: READY 상태에 있는 쓰레드를 관리하

는 큐이다.

∙ sleep queue: 쓰레드가 BLOCK 상태에 있을 때 속해

있는 큐이다. Sleep queue는 mutex나 condition

variable과 같은 동기화 객체에 포함되거나 블로킹

I/O의 지원 등에서 사용된다.

본 절에서는 ready queue와 sleep queue의 구체적인

구조에 하여 살펴보도록 한다.

11.. RReeaaddyy 큐큐

Velos에는 READY 상태에 있는 쓰레드들을 우선순위별

그림 4. Velos 쓰레드 상태 천이도

RUNNINGsuspend

schedule

START

exit

sleep

resumesuspendresumesuspend

wakeup

Preemptyield

TERMINATED

BLOCKREADY

SUSPENDEDBLOCK

SUSPEND

그림 5. Velos 쓰레드 ready 큐

TCB

thread q t thread ready q [256]

TCB

255

254

253

252

1

0

TCB

TCB

TCB TCB

69Embedded World

로 리스트로 관리한다. 이를 위해 커널은 각 우선순위별로

리스트 헤더를 갖는다. 그림 5는 Velos에서의 ready 큐 구

조를 보여준다.

Ready 큐에 사용되는 우선순위는 TCB의 iprio 값을 사

용한다. 같은 우선순위의 READY 상태의 TCB들은 TCB의

prev, next 필드에 의해 연결된다. thread_ready_q[]는

thread_q_t의 array로 256 각 레벨의 리스트 헤더이다.

Velos는 고정 우선순위 스케줄링을 지원한다. 따라서 스케

줄러는 새로운 쓰레드를 선택할 때 ready 큐에서 가장 높은

우선순위의 쓰레드를 선택해야 한다. 가장 높은 우선순위의

쓰레드를 선택하기 위해 ready 큐의 각 array를 높은 우선

순위부터 하나씩 뒤지게 되면 최 256번의 루프를 돌아야

한다. 그런데 ready 큐에서 가장 높은 우선순위의 쓰레드를

선택하는 동작은 빈번하게 발생하므로 단순히 array를 뒤

지게 되면 심각한 성능상의 문제를 야기한다. Velos에서는

이를 위해 ready 큐와 별도로 비트맵(bitmap)을 유지하여

빠르게 가장 높은 우선순위 쓰레드를 찾을 수 있게 한다. 어

떤 우선순위의 ready 큐에 기하고 있는 쓰레드가 있게 되

면 해당 비트를‘1’로 하고 없으면‘0’으로 한다.

이 비트맵을 통해서 가장 높은 우선순위의 쓰레드를 찾을

때 첫 단계로부터 시작하여 가장 높은 위치에 세팅된 비트를

찾아가면 된다. 이는 사전에서 특정한 단어를 찾는 방법과

유사하다. 사전에서 단어를 찾을 때 사전 첫 장부터 한 장씩

찾지 않고 그 단어가 있음직한 부분부터 사전을 열고 점점

구체적으로 찾아간다. Velos도 4등분된 256개의 우선순위

의 비트맵으로부터 3단계에 걸쳐서 가장 높은 우선순위의

쓰레드를 찾아낸다(그림 6 참조).

22.. SSlleeeepp 큐큐

쓰레드가 특정 이벤트를 기다리기 위해서는 ready 큐에

서 제외되고 sleep 큐에 들어가게 된다. 이 때 쓰레드의 상

태는 BLOCK 상태에 놓이게 된다. 그림 7은 sleep 큐에 의

한 리스트 구조를 보여준다.

Sleep 큐는 각 동기화 객체(mutex. semaphore 등)마다

유지하게 된다. 어떤 동기화 객체의 이벤트를 기다리는 모든

쓰레드의 TCB는 해당 동기화 객체가 제공하는 sleep 큐에

이중 연결 리스트 형태로 속하게 된다. Sleep 큐에 새로운

TCB가 들어갈 때는 우선순위 순서나 FIFO 순서에 의해 들

어간다. 우선순위 순서로 sleep 큐에 들어갈 때는 리스트 전

체를 찾아가야 한다. 따라서, 한 동기화 객체에 기다리고 있

는 쓰레드가 많게 되면 성능 저하의 원인이 될 수 있다.

sleep 큐의 prev와 next 필드는 이중 연결 리스트의 헤더에

해당하는 것으로 TCB prev, next 포인터에 의해 연결된다.

쓰레드 초기화

쓰레드의 초기화는 다음과 같은 과정으로 진행된다.

① allthread 큐의 초기화

그림 6. Velos의 3단계 우선순위 비트맵 관리

256bit (32byte)

8bit(256) 우선순위

X

X

Y

Y

Y

Z

Z

Z

70

TECHNICAL FEATURE

② ready 큐의 초기화

③ TCB free 리스트의 초기화

④ main 쓰레드의 생성

⑤ idle 쓰레드의 생성

①�③의 과정은 리스트 헤더를 초기화하는 과정으로 각

헤더의 포인터를 해당 구조에 맞게 초기값으로 설정한다.

Main 쓰레드의 생성은 현재 수행중인 코드를 쓰레드가 수

행중인 것으로 인식되도록 한다. 따라서 현재 문맥에 맞는

TCB를 생성하고 현재 수행중인 쓰레드를 가리키는

thread_running 값을 Main 쓰레드의 TCB로 세팅하게

된다.

반면 idle 쓰레드는 현재 Main 쓰레드가 수행되고 있는

환경이므로 일반적인 쓰레드 생성 함수에 의해 만들게 된

다. 이 경우 idle 쓰레드는 Main 쓰레드 보다 우선순위가

낮기 때문에 스케줄링이 발생하지 않는다.

쓰레드 생성

쓰레드 시스템의 초기화 이후 쓰레드는 다음 두 API에 의

해 생성된다.

∙ pthread_create(): pthread 생성 함수이다. 쓰레드로

생성할 함수 및 생성시 필요한 속성들을 인자로 갖는다.

∙ thread_create(): Velos에서 확장한 실시간 쓰레드를

생성한다. pthread의 생성시 필요한 인자에 추가로 주

기와 릴리즈 시간, 데드라인과 데드라인 miss 핸들러

등의 실시간 제약에 한 정보가 인자에 추가된다.

쓰레드는 생성과 동시에 스케줄링에 참여하게 된다. 만

약 생성되는 쓰레드가 현재의 쓰레드보다 우선순위가 높다

면 현재 쓰레드의 문맥은 저장되고 새로 생성된 쓰레드가

수행되게 된다. 쓰레드의 생성시에는 다음과 같은 과정을

거친다.

① TCB 할당

② 쓰레드 속성의 초기화 및 설정

③ 스택의 할당

④ 초기 문맥의 저장

⑤ TCB 초기화

⑥ 스케줄링 파라미터 설정(우선순위, 주기, 릴리즈 시간,

데드라인)

⑦ 데드라인 miss 핸들러의 생성

⑧ all thread 큐에 삽입

⑨ ready 큐에 삽입

Velos에서 TCB는 미리 할당해 놓은 TCB free pool에서

꺼내어 할당된다. 만약 TCB free pool이 비게 되면 32개의

TCB를 새로 할당하여 free pool에 넣어지게 된다. 쓰레드의

스택은 사용자가 지정하지 않을 경우 malloc()에 의해 heap

에서 할당되고 쓰레드의 종료 시 반환된다. 과정 ④에서 초

기문맥은 커널 내의 set_regs()에 의해 생성되며 이는 CPU

에 종속적인 코드로 문맥은 CPU에 따라 다르게 정의된다.

과정 ⑦의 데드라인 miss 핸들러는 일반 쓰레드와 똑같이

생성된다. 그러나 PTHREAD_MAX_PRIO+1의 우선순위로

다른 일반 쓰레드보다 항상 높은 우선순위에서 수행된다.

그림 7. Velos sleep 큐

sleep_q_t

TCB TCB TCB

synchronization object

쓰레드 종료

쓰레드를 정상적으로 종료시키기 위해서는 다음 함수를

사용해야 한다.

∙ pthread_exit(): 호출한 쓰레드를 종료시키는 함수이

다. 호출한 쓰레드는 즉시 종료된다.

∙ pthread_cancel(): 인자로 주어진 쓰레드를 종료시키

는 함수이다. 인자로 주어진 쓰레드는 즉시 수행이 종

료되지 않고 취소 가능 지점(cancellation point)에

왔을 때 종료된다.

∙ pthread_kill(): 인자로 주어진 쓰레드에 시그널을 주

어서 종료시키는 함수이다. 쓰레드를 종료시키기 위해

서는 쓰레드에 SIGKILL 시그널을 주어야 한다.

SIGKILL 시그널을 받은 쓰레드는 다음에 수행될 때

바로 종료된다.

쓰레드는 pthread_exit() 함수를 호출하여 자신을 종료시

킬 수 있다. 또한 pthread_cancel()과 pthread_kill() 함수

를 호출하여 다른 쓰레드를 종료시킬 수 있다.

쓰레드를 구성하는 함수가 리턴하게 되면 pthread_exit()

함수가 자동적으로 호출된다. 따라서 명시적으로 종료 함수

를 호출하지 않아도 리턴 시에 쓰레드 종료에 필요한 작업이

수행된다.

쓰레드 종료 시에는 쓰레드가 동적으로 할당한 메모리나

열어놓은 파일, 잠김 상태의 뮤텍스 등을 처리하고 종료해

야 한다. 그렇게 하지 않으면 쓰레드 생성과 종료를 반복할

때 더 이상 사용하지 않는 자원이 할당된 상태로 계속 남아

자원의 낭비가 발생할 것이고, 다른 쓰레드가 이를 사용하

지 못하게 된다.

Velos에서는 쓰레드가 종료할 때 잠그고 있는 뮤텍스들

이 자동으로 풀린다. 그러나 수행 중에 할당한 메모리나 열

어놓은 파일은 쓰레드가 종료하더라도 자동으로 반환되지

않는다. 따라서 쓰레드를 종료시키기 전에 명시적으로 위의

자원을 반환하도록 하거나, pthread의 정화 처리함수

(cleanup handler function)에 반환하는 함수를 등록해야

한다. pthread 정화 처리함수에 해서는 Velos 프로그래

밍 레퍼런스를 참조하면 된다.

Pthread에서 쓰레드가 종료된 후의 상태를 다음 두 가지

로 구분할 수 있다.

∙ 연결가능(joinable) 상태: 쓰레드가 종료된 후에도 종

료 시점의 쓰레드 상태가 계속 보관되어 다른 쓰레드가

이를 참조할 수 있다.

∙ 분리(detached) 상태: 쓰레드가 종료된 후에 쓰레드의

상태를 유지하기 위한 메모리 역이 모두 시스템에 반

환된다.

쓰레드를 기본 속성으로 생성했을 경우, 종료 후의 상태는

연결 가능 상태이다. 따라서 만약 종료된 쓰레드의 상태를 참

조할 다른 쓰레드가 존재하지 않는다면, 메모리가 불필요하

게 낭비될 것이다. 종료된 쓰레드의 정보를 유지하길 원하지

않는다면 다음 함수를 사용하여 종료 상태를 설정해야 한다.

∙ pthread_join(): 종료를 기다리고 있는 쓰레드를 인자

로 사용한다. 해당 쓰레드가 종료되면 쓰레드 종료 코

드를 얻어오고, 종료된 쓰레드의 상태를 유지하기 위한

메모리 역을 반환한다.

∙ pthread_detach(): 쓰레드 종료 상태를 분리 상태로

설정하는 함수이다.

∙ pthread_attr_setdetachstate(): 쓰레드를 생성할 때

종료 상태를 설정하는 함수이다.

지금까지 실시간 시스템과 실시간 운 체제가 무엇인지에

해서 알아보고 국내 상용 실시간 운 체제인 Velos의 쓰

레드 관리에 해서 살펴보았다. Velos는 쓰레드의 상태를

6개로 정의하여 사용자로 하여금 쓰레드 기반 응용 프로그

램 개발 시 유연성을 주고 여러 개의 리스트를 유지하여 스

케줄링을 보다 빠르게 한다. 또한 빠른 쓰레드 문맥 전환을

위해서 ready 큐로부터 우선순위가 가장 높은 쓰레드를 3

단계 비트맵을 사용하여 찾는다.

다음에는 Velos의 스케줄링 기법에 해서 설명하려고

한다. 이번 호에서 설명한 Velos의 쓰레드 관리를 바탕으로

설명되기 때문에 이번 호를 참조하면서 읽으면 이해하기 쉬

울 것으로 생각된다.

71Embedded World

72

TECHNICAL FEATURE

필자는 리눅스를 공부하면서 처음엔 소스 코드를 찾아 스케줄링부터 보고 다음

엔 시스템 콜을 보고하는 식으로 접근했다. 그러나 실제 임베디드 시스템에 적용

하는 데는 그런 단계가 먼저 필요한 것이 아니라 커널 이미지가 어떻게 구성됐으

며 부팅 과정에서 어떤 식으로 실행되고, 어떤 절차를 거쳐 리눅스란 OS를 구성

하는가가 먼저 필요하단 것을 느꼈다.

이런 생각은 자연스럽게 커널을 만들 때 어떤 식으로 커널이 만들어지는 지를

알고 있어야만, 다른 임베디드 시스템에 커널을 만들어 넣을 때도 쉽게 접근할 수

있다는 생각을 갖게 되었다.

이 장에선 커널 이미지 파일의 구조와 Makefile을 통해 커널이 만들어지는 과

정을 추적해 본다.

i386 계열의 PC를 중심으로 부팅 과정을 알아본다. 임베디드 시스템에선 PC와

는 다른 부팅 과정이 필요하다. 하지만 PC에서의 부팅 과정을 이해한 후엔 훨씬

접근이 쉬울 것이다. 또 체적인 큰 항목들은 PC와 임베디드 시스템이 동일하기

때문에 좋은 예가 될 것이다.

PC의 전원을 처음 넣으면 CPU는 ROM에서 BIOS 코드를 읽어 실행하기 시작

한다. 처음 코드는 PC의 기본적인 초기화를 할 것이고, 이어서 각종 HW의 초기

화를 실행할 것이다.

기본 초기화가 끝나면 VGA를 통해 화면이 보이기 시작할 것이고 RAM 체크,

임베디드 시스템 엔지니어를 위한

리눅스 커널 분석②Makefile 분석

지난 호엔 리눅스의 일반적인 내용과 설치 및 테스트를 다루어 보았다. 이번부터 본격적인 커널 분석에 들어간다. 이번 내용을 읽기 전에 되도록

GNU Make의 매뉴얼을 읽어보던가 아니면 그에 상응하는(적어도 Makefile에 사용되는 키워드가 어떤 의미인지는 알 수 있을 정도의 문서) 것을 읽

어보고 시작하기 바란다.

: 남상규/(주)메디슨 초음파 연구소 선임연구원

halite@medison.com

연재순서

1회 리눅스 커널 컴파일하기

2회 Makefile 분석

3회 크로스 컴파일러 만들기

4회 ARM 리눅스

5회 리눅스 커널 부팅

6회 디바이스 드라이버

HDD 인식, PnP 세팅 등을 실행한다. 여기까지가 넓은 의

미에서의 HW 초기화라고 봐야 할 것이다.

모든 초기화와 세팅이 끝난 후에는 기본적인 HW인 플로

피나 하드디스크가 사용 가능한 상태가 된다. 이제 BIOS는

부팅 가능한 순서가 지정된 디바이스를 찾아 부팅을 시도한

다. 부팅이 가능하면, 그 디바이스의 첫 512바이트를 읽어

실행한다.

실행시, 하드디스크의 첫 섹터를 MBR(Master Boot

Record)이라 부르고 이 섹터만이 부팅에 사용된다. 하드디

스크가 여러 개 있더라도 정해진 첫 드라이브의 MBR만이

사용된다. 이 섹터는 로더 프로그램과 파티션 테이블 정보

를 담고 있다. 로더는 일반적으로 부트 섹터를 읽어 부트한

다. 실제로 MBR과 부트 섹터는 MBR이 파티션 정보를 담

고 있다는 것을 제외하고는 기능적인 차이가 없다.

mbr의 첫 446바이트(0×1BE)는 로더 프로그램이고, 그

뒤 64바이트는 파티션 테이블 정보를 담고 있다. 마지막 2

바이트는 매직 넘버를 갖고 있고 이 숫자는 이 섹터가 진짜

부트 섹터인지 판별할 때 사용된다.

그림 1에서 보듯이 처음 읽혀지는 코드의 크기는 512바이

트이므로 충분하다고는 볼 수 없을 것이다. 그러므로 이 작

은 용량엔 실제 코드를 읽어 실행하도록 하는 기능만을 넣는

것이 보통이다. 나머지는 해당 OS 파티션의 부트 섹터에 기

록된다.

여기까지가 일반적인 PC의 부팅과정이다. 이제부터는 어

떤 OS가 깔렸는지에 따라 부팅이 달라지게 된다. lilo와 같

은 부트 로더가 실행되어 원하는 OS를 부트한다.

여기서는 리눅스에 해 다루므로 BIOS에 의해 처음 읽

혀 실행되는 것이 LILO(혹은 GRUB)가 될 것이다. lilo를

설치시, LILO는 MBR에 자신을 위한 로더를 기록해 부팅할

때 LILO가 실행되도록 할 것이다. lILO의 첫 스테이지 부

트 섹터는 여러 다른 곳에서 LILO의 나머지 부분을 읽어들

인다.

다음은 필자의 lilo.conf로 lilo를 실행하면 install에 지

정된 /boot/boot.b가 MBR에 써진다. boot.b는 lilo의 첫

스테이지와 두 번째 스테이지가 묶여진 file로 첫 스테이지

는 부트 섹터에 기록되도록 512바이트이고 두 번째 스테이

지는 그 나머지 부분이다.

실제로 필자의 컴퓨터 boot.b는 4566바이트로 앞 512바

이트가 첫 번째 스테이지, 나머지 부분인 4054바이트가 두

번째 스테이지가 된다.

그러나 /boot/boot.b를 hexedit와 같은 것으로 보면 앞

부분에 있어야 할 중요한 정보들이 비어 있는 것을 알 수 있

다. 이것은 lilo를 실행해 MBR에 boot.b를 등록할 때 정보

가 채워지게 된다.

일단, bios가 mbr을 읽어 LILO를 기동하면 LILO는

lilo.conf를 사용해 등록된 메뉴를 갖고 사용자의 입력에 따

라 해당 OS를 시작하게 된다. 필자의 lilo.conf에 의하면 선

택 가능한 OS는“linux”로, 커널 이미지는 /boot/bzImage

73Embedded World

그림 1. mbr의 구조

Program code

Partition table

Magic number (0xAA55)

0x000

0x1BE

0x1FE

prompt

timeout=50

default=linux

boot=/dev/hda

map=/boot/map

install=/boot/boot.b

lba32

vga=0x030a

image=/boot/bzImage-2.4.16

label=linux

initrd=/boot/initrd-2.4.16.img

read-only

root=/dev/hda1

append="mem=nopentium hdd=ide-scsi"

74

TECHNICAL FEATURE

-2.4.16임을 알 수 있다. 즉, LILO는 사용자가“linux”를

선택했을 때 /boot/bzImage-2.4.16을 읽어들이고 실행해

주는 역할을 한다.

부팅에 관한 좀더 자세한 정보는 LILO의 README를 참

조하기 바란다.

이미 커널을 컴파일 해본 사람은 최종 커널 이미지 파일이

압축되어 있단 것을 알 수 있을 것이다(zImage, bzImage

등에서 z가 의미하는 것은 gzip으로 압축됐단 것이다). 이제

LILO가 메모리에 커널을 읽어올리고 실행하기까지의 과정

을 살펴볼 것이다.

이에 앞서 커널 이미지 파일의 구조에 해 먼저 알아본

다. 구조를 알아야 LILO가 커널을 어떤 식으로 부팅하게 해

주는지 이해가 빠를 것이다.

zImage와 bzImage는 같은 구조이다. 단지 메모리에 올

려지는 위치나 동작 방식이 약간 차이가 있기 때문에, 이것

이 고려된 각각에 맞는 코드가 사용될 뿐이다.

그림 2에서 회색 부분이 진짜 리눅스 커널이고 압축되어

있는 상태다. 여기에 압축을 풀어주기 위한‘head + misc’

가 앞부분에 붙어 있고, 다시 이 한 덩어리의 이미지에 메모

리가 올려진 커널의 압축이 제 로 풀리도록 미리 준비하는

“setup”과 부팅할 때 사용되는“bootsect”가 붙어 최종 커

널 이미지 파일을 만든다.

bbootsect나 bsetup의 앞에 붙은 b는 bzImage의 앞에

붙은 b와 같은 의미로“big kernel”을 의미한다. bbootsect

는 플로피로 부팅될 때 즉, 부트 로더가 없이 커널이 직접 읽

혀져 부팅될 때 필요한 부트 섹터다. lilo에 의해 부팅되는 경

우는 필요없는 부분이다.

커널의 부팅

lilo에 의해 부팅이 시작되면 LILO는 bzImage를 하드디

스크에서 읽어 메모리에 올려놓고 LILO에 의한 부팅일 경

우 필요없는 bbootsect를 건너 뛴 bsetup에서부터 실행되

도록 해준다. LILO의 역할은 bsetup에 실행권을 넘겨주는

데까지다.

실행된 bsetup은 메모리 세팅을 마치고 압축된 커널 이

미지의 압축을 풀기 위한 코드로 실행을 옮긴다. “head +

misc”로 표시된 부분이고, 이곳이 실행되면 piggy.o는 압

축이 풀려 실행 가능한 리눅스 커널이 메모리에 존재하게 된

다. 압축이 풀릴 때 화면에“Uncompressing Linux...”란

메시지가 출력된다.

그러나 압축이 풀렸다고 해서 바로 커널을 실행하는 것은

아니고 메모리 낭비를 막기 위한 정리를 한번 다시 하고 나

서 커널이 실행된다. 압축이 풀리면 처음 LILO에 의해 읽혀

진 커널 이미지는 필요없게 된다. 그러므로 이 부분을 내버

려두면 그만큼 메모리 낭비이므로 압축 풀린 커널 이미지를

옮겨와 되도록 많은 메모리를 사용하도록 한 후에 커널을 실

행해 준다. 커널이 실행되기 시작하면“ok, booting the

kernel.”이 출력되고 커널에 의한 출력이 화면에 나타나게

된다.

zimage와 bzImage의 차이

zimage와 bzImage는 무슨 차이가 있을까? 필자는 처음

에 z와 b의 의미 때문에 gzip으로 압축하거나 아니면 bzip2

로 압축한 것의 차이인 줄 알았지만, 압축은 gzip으로 같고

단지 z는 압축했단 의미고 b는‘big kernel’이란 뜻인걸 알

았다. 왜 이렇게 나눠졌는가?

이미 앞장에서 언급했던 것처럼 커널의 크기가 너무 커서

압축 후에도 일정 크기를 넘어가면 zImage 신 bzImage

그림 2. bzImge의 구조

bbootsect

bsetup

head + misc

piggy.o

를 사용해야한다고 했는데 이유는 다음과 같다.

PC가 처음 만들어질 때 OS로 도스가 사용됐고, 이 때

MS의 유명한 분이 640KB면 충분하다고 했던 소릴 들은 적

이 있다. 처음 PC가 만들어질 때의 CPU는 8086으로 16bit

CPU 다.

이 프로세서가 지원하는 최 의 메모리는 1MB 기 때문

에 모든 어드레스 스페이스가 1MB 내로 제한됐다. 그러므

로 램을 640KB 사용하고 나머지 역에는 MGA, VGA와

같은 다른 디바이스를 할당해 줬다.

문제는 여기서 시작되는데, AT 시절의 PC 기본 구조는

현재까지도 계속 유지되고 있기 때문에 PC가 처음 부팅되

면 하위 1MB만을 사용한다고 생각하면 된다. 보호모드라고

알고 있는 386 이상의 CPU가 가진 기능을 사용하지 않고

리얼모드란 8086 호환 모드를 사용하기 때문인데, 이는 OS

가 보호모드를 사용할 상태를 만들고 전환하기 전까지는 계

속 리얼모드로 남아있기 때문이다.

리눅스 커널의 크기가 커서 커널을 읽어들이는 프로그램

크기나 시스템에서 사용되는 약간의 메모리를 제외한 나머

지 램의 빈 공간에 읽어들이지 못하면 하위 1MB가 아니라

그 이상의 연속된 메모리에 커널을 읽어 들이고 압축을 푸

는 등의 일을 해야할 것이다. 반 로 남은 용량에 커널이

들어갈 수 있다면 당연히 읽어들이고 압축을 풀면 끝날 것

이다.

이렇게 메모리에 처음 적재되고 압축이 풀리고 하는 절차

와 위치가 다르기 때문에 zImage와 bzImage로 나뉜 것이

고, 커널 이미지 파일의 앞부분 bootsect와 setup이 각각

맞는 것으로 합쳐지게 된다. 그리고 bzimage의 경우, 하위

1M는 사용하지 못하는데 리눅스에선 그렇다!

컴파일 단계에서 make zImage 했을 경우“System is

too big. Try using bzImage or modules.”라고 에러가

난다면 더 많은 부분을 module로 만들거나 bzImage를 사

용해야한다.

bzimage가 만들어지는 과정을 살펴보고, 이를 따라가면

서 Makefile의 자세한 내용을 알아본다. 정확한 것은 다음

달에 다시 설명할 것이다.

시작은 물론 $(topDIR)/Makefile로부터 시작한다.

커널 makefile은 몇 부분으로 나눌 수 있다.

1. 기본 정보 정의

2. 커널 설정

3. 커널 소스 의존성 만들기

4. 모듈 만들기

5. 커널 실행 파일 만들기

6. 모듈 설치하기

각 부분이 명확하게 구분되는 것은 아니지만 make의 동

작을 이해하는 사람이라면 충 구분을 지어 이해할 수 있을

것이다. 구분은 커널을 컴파일 하는 절차에 따라 나눈 것으

로 이해하면 쉬울 것이다. 일반적으로 많이 쓰이지 않는 부

분은 넘어가고 중요한 부분만을 자세히 이해하자.

시작에 앞서 사용되는 Makefile들을 설명해 놓는다. 이

것들을 참조로 추적해나가므로 시작하기에 앞서 한번쯤 훑

어보는 것도 좋을 것이다.

$(topDIR)/Makefile

makefile에 한 분석은 본지에 생략되었다. 이 내용은

웹사이트‘www.embeddedworld.co.kr’에서 자료실을 참

조하기 바란다.

75Embedded World

76

TECHNICAL FEATURE

필자는 실험실에서 있었던 경험을 바탕으로 미숙하지만 기초를 튼튼히 하고자 하는 엔지니어에게, 특히 하드웨어와 소프트웨어를 함께 해야 하는

시 적 요구를 반 하는 펌웨어 엔지니어를 위해 이 을 쓰게 되었다. 여기서 실험 상이 된 MPU는 8051을 주로 기준으로 하 고 i196과 Z80,

HC08 등의 마이크로프로세서도 참고했다. C 컴파일러는 독일 KEIL사의 u-Vision2와 IAR 그리고 Tasking, RAD51R, Paradigm C++를 이용하여

검증과 실험을 했으며, 경우에 따라서는 회로도와 부품에 한 설명으로 펌웨어 엔지니어가 적은 노력으로 따라 올 수 있도록 힘썼다. 혹시 내용 중

에 필자의 불찰로 틀린 부분이나 더 좋은 기법이 있는 독자는 시 적인 공감을 하기 위해 이메일로 보내주기 바란다.

: 김형태/(주)쥬피텍기술연구소 책임연구원

conan@jupitech.co.kr

함수/전처리기

마이크로프로세스 응용

엔지니어를 위한 ANSI C④

Firmware Application

함수를 사용한 프로그램은 그렇지 않은 프로그램에 비해 이해하기 쉽고 디버깅

과 유지 보수 및 관리가 비교적 편하다고 할 수 있다. 프로그램에서 함수가 호출

되면 함수로 제어가 넘어 간 후에 함수를 수행하고 나서는 호출한 바로 다음의 문

장부터 실행하게 된다. 함수는 개발자가 만드는 것도 있지만, 컴파일러를 제공하

는 입장에서 미리 정의한 뒤에 사용하는 라이브러리도 있다. 라이브러리는 표준

과 비표준으로 나누는데, 함수에 한 사항은 컴파일러 공급사에서 제공해 주는

부록을 참고하면 된다. 그리고 라이브러리에 등록되지 않은 자작하는 함수를 사

용하기 위해서는 먼저 라이브러리에 없는 이름으로 함수를 정의하여 만들면 된

다. 등록되어 있는 C 함수를 사용하기 위해서는 관련된 헤드파일을 전처리기에

등록해야 한다. 본 장에서는 함수를 학습함으로, 함수를 사용하여 프로그램하며

전달인수나 리턴값이 있는 함수도 만들 수 있고 활용할 수 있어야 한다. 그리고

함수를 이용하여 Interrupt를 호출하고 return 하는 루틴과 stack의 개념도 추

가적으로 익히게 될 것이다

함수(Function)

문법

[리턴 데이터형] 함수이름 (데이터형 인수1, 데이터형 인수2, 데이터형 인수3....){

연재순서

1. ANSI C 소개

2. 상수, 변수, 데이터형

3. 연산자와 표현식

4. 제어문(Control Statement)

5. 배열

6. 구조체(Structure)

7. 함수(Function)

8. 전처리기(Preprocessor)

9. Point 기초

10. Point 적용

TECHNICAL FEATURE

77Embedded World

함수는 프로그램 내에서 특별한 일을 수행하는 코드의 집

합이라 정의할 수 있다. 함수는 컴파일러에 기본적으로 있

는 것을 사용할 수도 있고 사용자가 직접 함수를 정의하여

사용할 수도 있는데, C 언어의 엄청난 강점이기도 하다. 그

동안 어셈블리 언어로 개발을 해왔던 엔지니어가 C 언어로

전환하게 되면 이해가 잘 안되는 부분이 바로 함수이기도 하

다. 함수는 BASIC 언어에서‘GOSUB’와 같은 항목에 해당

한다. 함수를 이해하는 방법은 전달인수와 리턴값 그리고

함수 이름에 해 정의하는 방법을 터득하면 된다. 그리고

함수는 다음에서 자세히 나오지만 프로토타입 선언과 연관

되어 정의되고 호출하는 방법을 알면 된다. C 언어에서의

함수는 사실 코드(Code)에 해당한다. 심플한 함수의 작성은

공간적으로 이해하기 쉽게 만들고 코드의 크기도 줄이는 효

과가 있다. 따라서 마이컴이 해야 할 일은 올바른 알고리즘

으로 함수를 잘 구현해야 한다.

함수를 정의하고 사용할 때는 다음의 규칙이 있다.

1. 함수의 이름은 한눈에 기능을 알 수 있도록 의미 있게

사용한다.

2. 함수를 정의할 때 이름 뒤에는 괄호가 있는데 인수가

있을 경우는 해당 데이터형 인수와 이름을 넣고, 그렇

지 않을 경우는‘void’를 사용하여 인수가 없음을 알

린다. 함수를 호출할 때 괄호를 생략할 수는 없다.

3. 함수는 { } 사이에 Application 프로그램을 넣는다.

4. 함수의 마지막 줄에는 return을 포함시켜 호출한 함수

로 전달값을 전달해 주고, 없을 경우는 생략이 가능하

다. 좀더 친절하게 리턴값이 없을 경우는‘return;’만

사용해도 된다.

5. 내부함수(시스템 제공)는 사용하기 전에 해당 함수의

원형이 선언된 헤더파일을 #include 문에 의해 선언해

주어야만 사용이 가능하다.

6. 함수의 호출은 해당 함수의 이름과 괄호를 명기함으로

써 이루어진다.

함수 문법에서 제시해 주는 것은 우선 리턴(Return) 되는

데이터형, 함수이름, 함수의 전달인수 그리고 함수의 내용

으로 구성되어 있다. 리턴 되는 값이 없거나 데이터형을 받

아들이지 않는다고 하면‘void’로 신한다. 그 로 두어

데이터형이 생략된다면 default(기본 값)는 컴파일러마다

다르지만 부분 int로 되어 있다. 그래서 전달 인수와 리턴

값이 없는 main 함수를 다음과 같이 선언해야 한다.

void main(void) //①

void main(unsigned char) //② 예: dos>test ‘B’

①은 평상시에 많이 보와 왔을 것이고 ②는 PC에서 운

되던 컴파일러에서 볼 수 있던 것이다. 예를 들어 전달인수

가‘A’,‘B’경우가 다르게 처리되는 프로그램이라면 프롬

프트(Prompt) 상에서 실행파일(여기서는 test.exe)의 이름

과 함께 전달 인수를 넣어주어야 한다. 아마, Turbo C나 볼

랜드 C에서 구현한 PC 프로그램에서 보았을 것이다. 사실

②는 firmware에서 사용할 기회가 적다.

함수의 특징으로는 다음과 같은 사항이 있다.

1. Function은 이름, 형식 그리고 값을 가지고 있다.

2. void 키워드는 함수를 위해서 만들어진 단어이다.

3. 자신의 함수를 또 호출할 수 있는 재귀를 허용한다.

4. 리턴값이 있는 함수를 리턴값이 없는 것처럼 이용할 때

void를 사용한다.

변수선언;

실행문1;

실행문2;

return 표현식;

}

보기

void test_function (void){ // 함수 원형 선언

unsigned int value;

value=0;

value = P1 << 8;

value |= P2;

}

main(){

while(2000){

test_function(); // 선언된 함수 사용

}

}

78

TECHNICAL FEATURE

함수를 main( )이 시작되기 전에 처음 선언하는 것을 함

수 원형 선언이라고 한다. 이때 리턴값이 없다면‘void’라

고 하고, 마찬가지로 함수에서 전달인수가 없을 때도

‘void’를 사용하여 함수의 구조를 친절히 알려 줄 필요가

있다. 그러나 전달인수가 없어‘void’를 생략할 수는 없다.

리턴의 데이터형과는 다르게 default로 정의되는 것이 아

니기 때문이다.

선언된 뒤에 함수를 이용하기 위해서는 어떻게 해야 할

까? 선언된 함수 원형이 리턴값과 전달인수가 없는 함수일

경우는 다음과 같이 사용하면 된다. 이때 호출함수의 괄호

안에는‘void’라는 키워드를 넣어줄 필요가 없다. main( )

함수나 다른 함수에서 함수를 호출해서 사용하게 되면 호출

된 함수는 실행하고 난 다음 호출된 행의 다음 행으로 처리

를 넘기게 된다. 참고적으로 ANSI C 이전의 C(Classic C

라고 한다)에서는 전달 인수가 없더라도‘void’라고 표기하

지 않고 괄호를 그 로 두었다.

void port_test(void){ //Classic C에서는 void port_test(){

P3=0xFF;

}

void main(void){

port_test();

P3=0;

}

다음과 같이 전달 인수에서 연산과 조건을 취할 수도 있다.

void gmZx_SetCoastWindow(void){

gmZx_WriteWord(CLAMP_END_hi, gmZx_ReadWord(IFM_VS_PULSE_hi)+3);

gmZx_WriteWord(CLAMP_START_hi, gmZx_ReadWord(IFM_VS_PERIOD_hi)-3);

}// 함수의 끝

Bool gmZx_DetermineSyncType(void){ // return 값은 bit와 같다.

unsigned char regByte;

gmZx_ForceBackground();

gmZx_EnableDSS();

regByte = gmZx_GetHVsyncStatus();

if(!regByte)

return TRUE; // Sync Type is DSS

gmZx_EnableCSync();

regByte = gmZx_GetVsyncStatus();

if(regByte) {

gmZx_EnableSOG();

regByte = gmZx_ReadByte(IFM_STATUS);

gmZx_WriteByte(IFM_STATUS, regByte);

regByte = gmZx_GetVsyncStatus();

if(regByte) {

gmZx_WriteByte(CSYNC_CONTROL, (regByte | 0x03)); // 함수 내에서 연산

regByte = gmZx_ReadByte(ADC_CONTROL);

gmZx_WriteByte(ADC_CONTROL, (regByte | 0x04));

return FALSE;

}

}

gmZx_SetCoastWindow();

전달인수와 Return 없는 함수

문법

void 함수이름 (void){

변수선언;

실행문1;

실행문2;

}

보기

void test_function (void){ // 함수 원형 선언

unsigned int value=0;

value=(unsigned int)P1; // 괄호를 이용하여 Data Type 변경

if(!value) return; // Value 값이‘0’이면 하위는 의미 없다.

value +=10; // value=10+value;

P2= (char)(value&0x00FF); // P2로 다시 형 변환 해서 출력

}

main(){

while(2000){

test_function(); // 선언된 함수 사용

}

}

79Embedded World

return TRUE;

} // 함수의 끝

선언된 함수 원형이 unsigned char의 전달 인수가 있을

경우라면 다음과 같이 사용하면 된다. 함수를 호출해서 사

용할 때는 전달인수의 변수 Type을 동일하게 맞추어 주어

야 한다. 함수 원형을 선언할 때 괄호 안에 있는 전달인수의

데이터형 변수이름은 원한다면 없어도 된다. 즉, 아래의 보

기를 변형해서 void port_test(unsigned char)라고 해도

좋지만 이렇게 원형을 선언하면 어떤 변수를 사용한다는 정

보에 해서는 전혀 알 수가 없다.

void port_test(unsigned char port_pass){

P3=port_pass;

}

void main(void){

unsigned char pass_test;

pass_test=0x0F;

port_test(pass_test); //’port_test(0x0F);’와 동일하다.

}

함수가 리턴값을 가진다는 의미는 함수를 종료 할 때

‘return’을 이용해서 값을 전달한다는 것인데, 리턴은 값을

가짐으로 리턴값이라고 한다. 그래서 리턴 다음에‘( )’를 묶

어 표현하는데 사실 없어도 프로그램에는 지장을 주지 않는

다. ‘return’은 함수에서 강력한 종료문이므로 함수의 어느

곳에 있든지‘return( );’을 만나면 호출 측으로 돌아간다.

리턴 함수를 호출해서 사용할 때는 리턴변수 Type을 동일

하게 맞추어 주어야 하는 것은 당연하다. 선언된 함수 원형

이 전달 인수가 없고 unsigned char의 리턴만 있을 경우라

면 다음과 같이 사용하면 된다.

unsigned char port_read(void){

return (P3 & 0x11); //비트 연산 처리 후 리턴

}

void main(void){

if(port_read()){

// 함수의 리턴값이 참일 경우 Application Program은 여기에

}// end if(port_read())

}

리턴값만 있는 함수

문법

[데이터형] 함수이름 (void){

변수선언;

실행문1;

실행문2;

return 표현식;

}

보기

unsigned char test_function (void){

return(~P1&0xF0);

}

main(){

while(2000){

P2=test_function(); // 선언된 함수 사용

}

}

전달인수만 있는 함수

문법

[void] 함수이름 (데이터형 인수1, 데이터형 인수2, 데이터형 인수3....){

변수선언;

실행문1;

실행문2;

}

보기

void test_function (char key_value){

char value;

value = ~P1; // 들어온 입력값에 NOT를 취함

P2=value & key_value; // (value AND 전달인수)

}

main(){

while(2000){

test_function(0XAB); // 선언된 함수 사용

}

}

80

TECHNICAL FEATURE

선언된 함수 원형이 리턴값 int와 unsigned char의 전달

인수가 있을 경우라면 다음과 같이 사용하면 된다. 리턴값

이나 전달인수의 변수 Type을 동일하게 맞추어 주어야 하

는 것은 당연하다.

int port_test(unsigned char port_out){

int pass;

P3=port_out;

pass=(int) P2; // chart를 int로 변환

return P2; // Port 2의 값을 읽고 return 해준다.

}

main(){

unsigned char pass_test;

int bit_operate;

pass_test=0x0F;

bit_operate=port_test(pass_test);

(void)port_test(pass_test); // ① 리턴값 무시

bit_operate|=0xAA; // bit_operate=bit_operate U 0xAA(1010 1010)와 동

일하다.

}

리턴값이 있는 함수를 사용할 때 함수를 호출하고 나서 굳

이 return 값을 사용하고 싶지 않다면 ①번처럼‘void’를

이용하여 선택적(리턴 값 무시)으로 할 수도 있다.

보기 1과 2은 같은 프로그램인데, 보기 2는 함수를 프로

토타입 선언한 것의 예이다. 함수의 프로토타입 선언은 개

발자에게는 다소 귀찮은 일이기도 하지만 프로그램의 알고

리즘이 복잡하고 길어질수록, 해결해야하는 블록이 많아질

수록 함수가 늘어남으로 궁극적으로 관리가 쉽고 에러 발견

및 오류 방지에 효과가 크다. 그리고 반드시 프로토타입으

함수의 프로토타입 선언

보기 1

#include <stdio.h>

void test_function (void){ // Prototype 선언을 특별히 하지 않음

// Application Program

}

main(){

for(;;){ // 무한루프

test_function(); // 함수 호출

}// end for

}

보기 2

#include <stdio.h>

void test_function (void); // 프로토타입 선언

main(){

for(;;){

test_function(); // 함수 호출

}// end for

}

void test_function (void){

// Application Program

}

알알고고 나나면면 간간단단

Classic C에서의 함수

C 언어가 ANSI로 통합되기 전에는 다음과 같이 함수를 구현했다. 조

금은 어색해 보기이지만 펌웨어에서 사용하는 컴파일러는 별다른 언급이

없다면 아래의 문법도 소화해낸다. 하지만, 컴파일이 된다고 문제가 없는

것이 아님으로 아래와 같은 고전의 방법으로 구현한 함수가 프로그램 상

에 있다면 컴파일 후에 어셈블리 수준에서 반드시 확인 작업을 할 필요가

있다.

[데이터형] 함수이름 (인수1, 인수2, 인수3....)

// 여기까지는 ANSI와 동일

데이터형 인수1; // 데이터형을 인수 List에서 선언하지 않는다.

데이터형 인수2;

데이터형 인수3;

{

변수선언;

실행문1;

실행문2;

return 표현식;

}

81Embedded World

로 선언해야 하는 것이 있는데 리턴 되는 값이 정수형이 아

닌 경우(float일 때)는 반드시 프로토타입으로 함수를 선언

해야 한다. 함수를 프로토타입 하는 것은 함수 정의문의 첫

라인을 main( ) 함수가 오기 전에 기술 한 후 마지막에‘;’

를 붙임으로써 간단하게 할 수 있다.

#include <conio.h>

#include <stdio.h>

float pcompute(int x, float y); // 프로토타입 선언

void main(void){

int x=10;

float y=20.45, ret_v;

clrscr(); // 화면 Clear

ret_v=pcompute(x,y); // 연산후 저장

printf(“x+y is %.2f”,ret_v);

printf(“Correct Answer is %.2f\n”,x+y);

getch(); // 의미 없음

return(0); // 의미 없음

}

float pcompute(int x,float y){ // 프로토타입 선언된 함수를 정의한다.

float r_v;

r_v=x+y;

return(r_v);

}

ANSI C에는 변수를 저장하는 기억 Class(Storage

Class)가 4가지 있는데, 변수가 선언될 때 다음과 같은 특징

을 가진다.

auto unsigned int t1;

static unsigned int t2;

extern unsigned int t3;

register unsigned int t4;

aauuttoo::

기억장소의 지정 없이 선언된 지역 변수는 Default로

auto가 되며 변수는 함수에 들어갈 때 자동적으로 할당된

다. 변수는 함수 또는 블록이 실행될 때 유효함으로 그 이외

에는 존재할 수 없고 지역변수라고 생각하면 된다. 일반적

으로 함수를 정의하는 Class이다. 컴파일러마다 약간씩 다

르긴 하나 컴파일러 옵션에서 보통‘Code Optimization’

으로 표현되고 관련항목이 있다. 해당되는 항목을 선택하면

(보통 여러 개의 항목으로 구성되어 있다) 소스 프로그램을

컴파일 할 때 auto 변수는 컴파일러의 정해진 규칙에 의해

메모리 역에 적절히 배치된다.

Class

auto

extern

static

omitted

알알고고 나나면면 간간단단

함수와 인터럽트

컴파일러 부분은 인터럽트 처리를 위한 함수 표현 양식을 특별히 제

공해 주는데 인터럽트 처리도 사실 알고 보면 함수와 같다. 단, 함수의 처

리 종료 어셈블리는‘ret’이고 인터럽트는‘iret’코드인 것이 다르다. 인

터럽트 종료 키워드나 표현법이 ANSI의 표준이 아니어도 상관없다. 이유

는 컴파일러를 공급하는 회사의 매뉴얼에 틀린 부분이나 특별한 표기 부

분이 반드시 기록되어 있기 때문이다. 마이크로프로세스의 내부에 인터럽

트 발생이 감지되면 마이컴은 현재의 하던 일을 멈추고 미리정해진 인터

럽트(사전에 프로그래머가 정할 수도 있음)로 분기하게 된다. 이때 분기를

담당하는 레지스터가 PC(Program Count)인데, 그냥 다음 명령을 가지

고 올 주소로 옮기는 것이 아니고 현재의 중요한 변수값이나 레지스터 값

을 다른 안전한 곳에 피시킨 다음 인터럽트 처리로 분기하게 된다. 안

전한 곳으로 피할 때 사용하는 어셈블리 키워드가‘PUSH’이고 반 로

인터럽트를 처리하고 다시 복귀할 때의 키워드가‘POP’으로 되어 있다.

PUSH 할 때는 마이크로프로세스의 성능과 컴파일러의 능력에 따라 어떤

것을 피하는지가 틀리므로 민감한 Firmware를 만들고자 할 경우는 어

셈블리 코드로 확인이 필요하다. 인터럽트를 처리 한 뒤에‘POP’을 마친

뒤‘iret’를 만나면 인터럽트로 분기하기 전의 코드로 다시 오게 된다. 함

수는 인터럽트 처리와 다른 것이 처리종료에서‘ret’를 사용하는 것 이외

에 레지스터 내용을 안전하게 옮기는‘PUSH’, ‘POP’루틴이 없다.

82

TECHNICAL FEATURE

rreeggiisstteerr::

auto 변수와 동일하게 함수나 블록이 실행될 때 유효하지

만 컴파일러는 마이크로프로세스의 내부레지스터에 할당하

게 된다. Register Class로 정의하면 부분의 컴파일러는

변수를 레지스터에서 실행하게 함으로 보다 빠른 입출력 효

과를 기 할 수 있으나 시스템 자원이 충분한지를 먼저 점검

한 후에 행해져야 한다.

마이크로프로세스의 개념에서는 전원이 인가되지 않으면

레지스터의 값이 소거되는 휘발성 메모리로 되어 있고 외부

메모리에 비해 액세스 시간이 빠른 D F/F로 되어 있다. 참

고적으로 8051은 외부 메모리를 지정할 때 Multiplex I/O

를 가지고 있어 동일한 포트에서 어드레스 버스가 먼저 나가

고 이어서 데이터버스가 출력되는 구조를 가지고 있음으로

내부 메모리를 사용할 때보다 외부 메모리를 사용할 때 6배

이상의 시간이 더 걸리게 된다.

eexxtteerrnn::

프로그램이 외부 변수를 초기화하지 않으면 자동적으로

컴파일러에 의해 0으로 초기화된다. ‘extern’키워드는 모

듈 내에 없는 함수를 호출할 경우 기억 클래스에‘extern’

이라고 지정해 주어야 함수를 참조한다.

ssttaattiicc::

지역변수로 사용되어 함수나 블록이 소멸되어도 그 값을

유지한다. static을 키워드로 사용하지 않을 경우는 당연히

함수나 블록이 소멸될 때 같이 소멸된다. static을 사용할

때 변수가 초기화 되어 있지 않으면 데이터인 경우는 컴파일

될 때 0으로 초기화된다.

표 1은 CQ 출판사의‘트랜지스터 기술’잡지에 나온 기

억 클래스를 요약한 도표이다.

a 변수는 함수 A만 사용할 수 있고, bb는 함수 F만 사용

할 수 있다. b는 함수 B만 사용할 수 있지만 함수 B가 실행

종료되더라도 변수 b 값은 소멸되지 않고 프로그램 전체에

서 남게 된다. 상 적으로 a는 함수 A가 실행종료되면 같이

소멸된다. FILE2.c에서 사용되는 y는 FILE1.c에서 정의되

어 있는 동일한 변수를 사용한다.

C 언어는 반복적으로 함수를 호출할 수 있는데, 자기 자

신을 호출하는 것과 같은 기능도 수행할 수 있다. 하지만 마

이크로프로세스에서 사용하기 위해서는 각별한 주의가 요구

된다. 이유는 주어진 스택의 양과 마이컴의 내부 메모리가

한정되어 있기 때문에 많은 리소스가 있는 PC 환경과는 차

이가 있기 때문이다. 재귀호출에 의한 동작은 가급적 피하

되 부득이하게 프로그램을 작성하고자 할 경우는 재귀호출

되는 함수의 하단에는 검사 조건을 두고 또 무한정의 재귀를

방지하기 위해서 감소 단계를 두어야 한다.

재귀호출(Recursive Function)

보기

main(){

int sum;

main();

}

클래스이름

auto

register

extern

static

함수내 정의

생략가능

사용가능

사용가능

사용가능

모듈내 정의

사용가능

불가능

사용가능

생략가능

모듈 이외로부터 참조

참조불가

참조불가

가능

필요할 경우 참조가능

기억 역

스택, 데이터

레지스터

데이터

데이터

표 1. C의 기억 클래스

FILE1.C

char y;

A(){

char a;

.....

}

B(){

static char b;

.....

}

C(){

.....

}

main(){....}

FILE2.C

// 모듈

extern char y;

D(){

.....

}

E(){

.....

}

F(){

char bb;

.....

}

/*************************************************************************

Purpose : Recursive Function Test

*************************************************************************/

#include <stdio.h> // I/O에 관련된 Prototype 선언

#include <string.h> // String, Buffer에 관련된 헤드파일(Head File)

#include <std51.h> // SFR Register Include, made by conan

// value define

#define uchar unsigned char

#define uint unsigned int

// for Communication

// 14.7456MHz, SMOD=1, // 256-(2^MOD/32*12*(14.7456MHz)̂ -1 * went bps))

#define BPS_14_19200 252

#define BPS_14_9600 248 // same SMOD=0

// 11.0592MHz, SMOD=1, // 256-(2^MOD/32*12*(11.0592MHz)̂ -1 * went bps))

#define BPS_11_19200 253

#define BPS_11_9600 250 // same SMOD=0

/****************************************/

/* function prototype */

/****************************************/

// Utility

void init_serial(void); // 9600bps

int sum(int num);

/****************************************/

/* variables declarations */

/****************************************/

//int sum(int);

void main(void){

int sum(int);

int result;

init_serial(); // 9600bps

result=sum(5);

printf(“sum=%d\n”,result);

}

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

// ======================== Utility routine ===============

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

void init_serial(void){ // 9600bps

ES=1; // Enable Serial Interrupt

PS=1; // Serial Port Priority High

SCON = 0x50; // Mode=1, REN=1

PCON |= 0x80; // SMOD=1

TMOD |= 0x20; // Timer1 Mode=2, 8 Bit Auto_reload Timer

TH1 = BPS_11_9600; // Time Value

TR1 = 1; // Run Timer 1

TI = 1;

RI = 0; // initial TI & RI

EA=1; // All Interrupt Enable

}

int sum(int num){

if(num>1) return num + sum(num-1);

else return 1;

}

또 다음과 같은 예에서는 자신의 함수를 불러 연속해서 곱

셈을 취하고‘1’이 될 때까지 반복하는 루틴이다. Z80 에뮬

레이터(Emulator) 장비 Isystem.com사의 예제에서 가지

고 온 샘플이다.

#include “main.h”

#include “CPUTest.h”

void CPU_Init() {

++iCounter;

}

void CPU_Pointers(){

++iCounter;

}

int Factorial(int i){

83Embedded World

84

TECHNICAL FEATURE

if (i==1)

return i;

return Factorial(i-1)*i;

}

void CPU_Recursion() {

int x=0;

++x;

x=Factorial(5);// 5!=120

++x;

++iCounter;

}

Preprocessor라고 하는 선행 처리기 혹은 全(전)처리기

는 C를 더욱 유용하게 하는데 이용한다. 보통 긴 문장의 처

리를 단순화하는데 이용하기도 하고 컴파일러의 상황을 변

화시켜 다양한 Target 환경에서의 컴파일을 만들 때도 사

용한다. 전처리기에서 사용하는 명령어들은 프로그램이 문

장에 맞게 해석되기 전에 여러 가지 정의 및 변화를 사전에

알려주는 사전 처리기라고 할 수 있다.

이 장은 다음 사항에 해 학습할 수 있다.

#include

#define

#if

#ifdef

#undef

#pragma

#line

#error

Preprocessor는 C 언어를 이용한 프로그램을 작성할 때

긴 문으로 되어 있는 처리를 단순화하거나 Firmware 설계

에서 다반사로 사용하는 숫자를 의미 있게 만들 때 사용한

다. 선행처리기는 전처리기라고 하는데 Pre-processor라

는 문을 번역해서 사용함으로 그렇게 불린다.

Preprocessor는‘#’으로 시작해서 행이 마칠 때까지의

문장으로 구성되며 지시어의 끝에‘;’를 붙이지 않는 구조로

되어 있다. 한 행이 마칠 때까지 전처리 문장을 만들 수 없

다면‘╲’를 사용하여 컴파일러에게 줄 바꿈이 되더라도 연

속적으로 되어있다고 알려 주면 된다.

전처리기(Preprocessor)

문법

#단어

종류

#include는 관련 파일을 포함할 수 있도록 해 준다.

#define은 상수를 정의할 때 사용하고 매크로라고 한다.

#ifdef, #ifndef 등은 컴파일러에게 조건을 주어 선택적으로 이용할 수 있

도록 해 준다.

#pragma는 컴파일러마다 가지고 있는 특정한 명령이다.

#error 컴파일러가 만들어 내는 에러 메시지

알알고고 나나면면 간간단단

C언어로의 함수 개발과 모듈의 이해

C 언어를 이용하여 프로그램을 만들 때 함수의 집합인 프로그램을 하

나의 파일(*.c)로 처리하는 것은 효율이 떨어진다. Firmware 엔지니어마

다 나름 로의 기술이 있고 자신 있는 부분이 있으므로 프로그램의 동작

과 기능으로 세분화하여 따로 개발한 후 한곳에 모으는 것이 바람직하다.

이때 이 파일의 단위를 모듈(Module)이라고 한다. 여러 엔지니어가 각각

의 모듈을 맡아 개발할 경우는 변수의 처리방법과 함수의 정의 Form, 약

속 등의 세부적인 사항에 해 사전에 논의가 있어야 우왕좌왕하지 않는

다. 모듈은 다음과 같은 형식으로 되어 있다.

#include “외부 또는 내부파일”

extern function; // 외부 모듈의 함수와 변수 지정

모듈로 공유하는 변수 정의;

모듈 내에서 사용하는 변수, 함수 정의;

함수 선언{}

C 언어로 작성한 프로그램을 컴파일하고 포팅하면 가장 먼저 실행하

는 함수가 main() 함수이며 main()은 Start Up 코드로부터 최초로 호출

되는 함수이기도 하다.

#include <stdio.h> // I/O에 관련된 Prototype 선언

#include <string.h> // String, Buffer에 관련된 헤드파일(Head File)

#include <intrins.h> // _nop_(); 사용하기 위함

// value define

#define uchar unsigned char

# define uint unsigned int // ANSI C에서는 # 다음에 공백을 두어도 된다.

// Utility

#define NOP _nop_()

#define STRING “ Target Board ╲

Test Program *”// 상단의 줄에 연속되어 있다.

#define ON 1

#define OFF 0

#define NO 0

#include는 다른 파일의 내용을 현재의 프로그램으로 끌

어들일 때 사용한다. 전처리기 키워드 뒤에‘< >’나‘“ ”’를

이용해서 파일의 위치를 지정하는데 꺾쇠를 이용하여 표현

했을 경우는 헤드파일 등의 첨부파일이 컴파일러가 지정한

경로에 존재한다. 보통은‘include’혹은‘inc’경로에서

먼저 파일이 있는지를 검색한다. 그러나 큰따옴표는 파일의

위치가 default 경로에 있지 않고 별도의 정해진 위치에 있

음을 나타낸다. 개발자들은 이런 경우 자신이 자작하거나

원래의 시스템에 정해진 경로가 아닐 경우를 알려 주기 위해

서 사용하기도 한다. 그래서“”를 User Include라고 한다.

다음의 경우는 어떻게 컴파일러가 파일을 참조할까?

#include “project.h”

우선 컴파일러 전처리기는 Source가 있는 경로에서 먼저

찾고, 없다면 시스템에서 정해진 경로에서 탐색하게 된다.

다음의 경우도 헤드파일을 불러 올 수 있다.

#define header_file “c:╲ansi_c╲project╲hardtype.h”

//#define header_file <c:╲ansi_c╲project╲hardtype.h> 위와 같다.

헤드파일은 부분 내부에서 또 다른 헤드파일을 불러오

기도 하는 혼용의 방법을 쓴다. 사실 이렇게 되면 파일에 파

일을 또 참조하게 됨으로 분석하거나 이해하기가 곤란해질

지도 모르지만 관련 Job으로 구분하게 되면 작성하기가 쉬

워질 것이다. 남의 것을 이해해서 만드는 것보다 자신이 만

드는 것이 낫다고 하는 사건이 이래서 생기지 않았나 하는

생각이다. 이미 정리된 헤드파일을 적절하게 해석해서 이용

할 수 있는 것도 기술이다. 마이크로프로세스 종류만큼이나

다양한 컴파일러들은 저마다 마이컴의 레지스터나 메모리에

관련된 사항을 미리 정해 놓았기 때문에 이를 잘 활용하는

것은 절반은 공짜로 프로그램 해 놓은 것이나 진배없다. 예

를 들어, 표준 함수가 들어 있는 8비트 프로세스의 컴파일러

stdio.h 파일에는 다음과 같은 사항들이 이미 정의되어 있

음으로 전처리기에서 별도로 정의하는 수고를 덜 수 있다.

#define EOF (-1)

#define NULL ((void *) 0)

#define _SIZE_T

typedef unsigned int size_t;

extern char _getkey (void);

extern char getchar (void);

extern char ungetchar (char);

extern char putchar (char);

extern int printf (const char *, ...);

extern int sprintf (char *, const char *, ...);

extern int vprintf (const char *, char *);

Source File Inclusion

문법

#include <표준파일이름.h>

#include “경로╲파일이름”

보기

#include <stdio.h>

#include <math.h>

#include “c:╲project╲hardware.h”

void main(void){

}

85Embedded World

86

TECHNICAL FEATURE

extern int vsprintf (char *, const char *, char *);

extern char *gets (char *, int n);

extern int scanf (const char *, ...);

extern int sscanf (char *, const char *, ...);

extern int puts (const char *);

매크로 정의는 다수의 문자나 자주 변경이 발생하는 길이

가 긴 상수 또는 복잡한 수식을 간단한 식별자로 처리할 때

사용한다. 매크로는 C 프로그램을 유용하며 윤기 있고 다소

융통성 있게 바꾸는 역할을 하기도 하는데 Firmware에서

보통 외부 I/O를 제어하는 경우가 많은 것을 고려할 때 상수

로 되어 있는 그들의 제어값이 의미 있는 문장으로 바꿈으로

이해하기 편하고 수정을 용이하게 만든다. 그리고 긴 문장을

짧게 표현할 수 있게 하도록 해 주고 값의 변동이 자주 발생

하는 내용을 신속하게 처리해서 Porting 할 수 있게 한다.

#define Power_OFF 0xAAFF

#define은 정의하고자 하는 문자를 띄어쓰기 없이 먼저

쓰고 바꾸고자 하는 문장을 띄어쓰기 없이 표기하면 된다.

단어의 구분은 물론 띄어쓰기로 하며 개수는 상관없다.

#define은 식별문, 치환문이라고 하는데 매크로 정의는 문

을 구분하는데 띄어쓰기를 이용함으로 주의가 필요하다. 매

크로는 보기에서 보여준 것처럼 컴파일에서 문장을 치환문

으로 그 로 바꾸어 줌으로 함수나 변수와 혼동될 소지가 다

분하다. 그래서 일반적으로 프로그램머가 프로그램 한 것을

보면 부분 문자로 되어있다는 것을 알 수 있다. #define

에 의해서 정의가 되었다면 #undef를 이용하여 이미 정의된

매크로를 취소할 수도 있다.

#define ON 0x0F

#define OFF 0

void main(void){

unsigned char led_power, motor_power;

led_power=ON;

motor_power=OFF;

#undef ON

#undef OFF

#define ON 0 // 반드시 #undef를 사용하여 정의를 취소하지 않아도 된다.

#define OFF 0xF0

led_power=ON;

motor_power=OFF;

}

매크로를 정의할 때는 상수나 문장을 식별문으로 바꾸어

줌으로 변수 혹은 함수와 구분되기 위해서 보통 문자로 정

의하고 의미 있는 문장으로 하는 것이 상식이다. 한번 정의

한 매크로 문장은‘#undef’(undefine) 문장을 만날 때까지

유효하고 소스 프로그램 내에서도 물론 정의가 가능하다.

그러나 다음의 키워드는 사전 정의된 매크로임으로 #undef

를 사용하여 취소해서는 안된다.

Macro Replacement

문법

#define 식별문 치환문

#undef 식별문

보기

#define ON 1

#define OFF 0

P1_1=ON;

P1_2=OFF;

#undef ON

#undef OFF

#define ON 0x0

#define OFF 0xFF

P0=ON;

P1=OFF;

Macro 이름

_DATE_

_FILE_

_STDC_

_LINE_

_TIME_

설 명

mm dd yyyy의 자리수로 년, 월, 일의 컴파일 날짜 생성

컴파일 되는 파일 이름 생성

ANSI C일 경우 매크로가 정의되어 상수 1을 생성

컴파일 되는 소스파일의 행 번호를 나타낸다.

hh:mm:ss의 자리수로 컴파일 시작을 시:분:초로 생성

또 다음과 같이 여러 Parameter들도 정의가 가능하다.

이어지는 두 개의 예 중에서 처음 것은 두 개의 값 중에서

큰 값을 건네주는 것이고, 뒤의 예는 두 개의 숫자를 검사

해서 홀수와 짝수를 식별하여 짝수이면‘0’을 건네주는

매크로인데 좀 복잡하지만 이해하는데는 그만 이라고 생

각한다.

#define ODD 1

#define EVEN 0

#define MAX_VALUE(a,b) ((a) > (b) ? (a) : (b))

#define EVEN_ODD(number) ((number % 2) ==1) ? (ODD) : (EVEN)

전처리기를 이용해서 매크로를 정의하면 코드의 효율적

인 측면도 이득을 보게 되는데 함수가 변수를 전달할 때의

시간이 같은 조건을 매크로로 정의했을 때보다 더 걸린다.

보다 정확히 말하면 코드 길이가 짧게 되는 이점이 있다.

그러나 좋은 것이라도 과용하거나 잘못된 사용은 안하는

것만 못할 때가 있다. 매크로 정의를 잘 사용하면 코드 사

이즈도 줄이고 일반함수가 매개 변수를 함수에 전달하는

시간이 요구되지 않으므로 실행 속도의 증가를 가져온다는

이점도 있다.

#define outportb(address,value) (*((unsigned char *)(address))=(value))

#define inportb(address) *((unsigned char *)(address))

위의 매크로를 함수로 정의했다면 다음과 같을 것이다.

void outportb(address,value){

(unsigned char *)address=value;

}

unsigned char inportb(address){ // 의미를 두기 위해 Return 값을 임의로 줌

return((unsigned char *)address);

}

그러나 매크로를 정의할 때는 매크로 이름 사이에 공백이

있어서는 안되고 혼돈과 정확한 동작을 위해서 매크로 확장

전체와 각 인수들을 괄호(‘()’)를 사용하여 묶어주어야 한

다. 그렇지 않으면 다음의 예제에서처럼 예기치 않은 결과

를 초래한다.

#include <stdio.h>

#include <conio.h>

#define SQUARE(x) x*x

void main() {

int a, b=20, c=19, d;

clrscr();

a=SQUARE(b);

d=SQUARE(c+1); // 어떻게 연산될까?

printf(“a is %d, d is %d”,a,d); // 출력 값을 예상하자.

getch();

return(0);

}

매크로는 똑같은 과정을 함수로도 정의 가능하지만 서로

는 엄연히 다르다. 매크로는 함수처럼 리턴값의 자료형을

정의해 둘 필요도 없고 함수보다 처리가 빠른 장점이 있지만

따로 컴파일 할 수가 없는 단점이 있다. 다음의 예제는 USB

를 제어하는 프로그램의 일부이다. 다른 엔지니어가 작성한

프로그램은 나의 좋은 스승이다.

//----------------------------------------------------------------

// Contents: Firmware frameworks task dispatcher and device request

parser source.

// Copyright (c) 1997 AnchorChips, Inc. All rights reserved

//----------------------------------------------------------------

#include “ezusb.h”

#include “ezregs.h”

//----------------------------------------------------------------

// Random Macros

//----------------------------------------------------------------

#define min(a,b) (((a)<(b))?(a):(b))

#define max(a,b) (((a)>(b))?(a):(b))

//----------------------------------------------------------------

// Constants

//----------------------------------------------------------------

#define DELAY_COUNT 0x9248*8L // Delay for 8 sec at 24㎒ , 4 sec at 48

87Embedded World

88

TECHNICAL FEATURE

#ifdef, #if, #ifndef는 조건부 컴파일을 위해서 사용되고

#else는 조건이 아닐 경우 체할 때 사용한다. #endif는

조건문의 끝을 나타낼 때 표시하며 조건문은 #if~로 시작한

다. 조건 연산자를 생각나게 하는 연산자 전처리기를 해석

할 때는 #ifdef로 시작해서 #endif로 끝난다고 생각하면 된

다. #undef는 매크로가 정의되어 있을 때 가장 최근에 정의

된 매크로 정의를 취소할 때 사용된다. 전처리기에서 실행

하는 조건부 컴파일의 입력은 부분 옵션으로 Make 파일

을 만들 때 Batch 파일에 옵션으로 넣어 주기도 하는데, 현

재의 개발용 컴파일러들은 윈도우 환경이 많음으로 간단히

옵션 윈도우 화면에서 입력하는 경우가 다반사이다.

다음의 예제는 마이크로프로세스와 Web 사이를 어렵지

않게 연계시켜 주는 미국 emWare사의 프로그램에서 가져

온 헤드파일의 일부이다.

// Copyright 1998-1999 emWare, Inc.

#ifndef _APP_H_

#define _APP_H_ // 정의되지 않았으면 정의한다.

#define EM_MICRO_DEVICE

#define EM_ADDR_ENDIAN 0x0

#define EM_VENDOR 0x0L

#ifndef EM_DEVICE

#define EM_DEVICE 0x0L

#endif // 두 번째 if문의 마지막

#define EM_NVS_OFFSET 0x0

#define EM_NVS_SIZE 0x0

#define EM_ADDR_SIZE 0x2

#define EM_STR_TYPE 0x0

#define EM_VAT_COUNT 3

#define EM_VARINDEX_dis_img 0

#define EM_VARINDEX_dis_com 1

extern BYTE dis_img[];

extern BYTE dis_com;

#endif // 첫 번째 if문의 마지막

다음의 RAM 테스트 프로그램을 분석해 보자. 조건문과 배열 그리고 함수가 있다.

#ifdef TestNVRAM // 전처리기 선언, 컴파일의 옵션에서 TestNVRAM 단어를 기입

했을 경우 실행

unsigned char code testdata1[] = {0,1,2,3,4,5,6,7,8};// 배열 정의

unsigned char code testdata2[] = {0xaa,0x55,0xaa,0x55,0xaa,0x55,0xaa,0x55};

unsigned char code testdata3[] = {0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff};

unsigned char code testdata4[] = {0x55,0xaa,0x55,0xaa,0x55,0xaa,0x55,0xaa};

unsigned char xdata testrslts[8]; // 외부 RAM 메모리 xdata 역에 부호 없는 1

바이트 정의

void NVRAM_Test(void){

WORD address; // unsigned int

BYTE I; // unsigned char

for (address = 0; address < 1024; address += 8) // address 변수는 8씩 증가

NVRam_WriteStructure(address, testdata1, 8);

for (address = 0; address < 1024; address += 8){ // 어드레스 1K 까지

NVRam_ReadStructure(address, testrslts, 8);

for (i = 0; i < 8; i++) {

if (testrslts[i] != testdata1[i])

msg(“NVRAM test error 1 ╲n”);

}

}

for (address = 0; address < 1024; address += 8)

NVRam_WriteStructure(address, testdata2, 8);

for (address = 0; address < 1024; address += 8) {

Conditional Compilation

문법

#ifdef 식별단어

#if 식별단어

#elif 식별단어

#else 식별단어

#ifndef 식별단어

#undef 식별단어

#endif

보기

void main(void){

#ifdef DEBUG

PORT=0xFF;

#endif

}

NVRam_ReadStructure(address, testrslts,8);

for (i = 0; i < 8; i++)

{

if (testrslts[i] != testdata2[i])

msg(“NVRAM test error 2╲n”);

}

}

for (address = 0; address < 1024; address += 8)

NVRam_WriteStructure(address, testdata3,8);

for (address = 0; address < 1024; address += 8) {

NVRam_ReadStructure(address, testrslts,8);

for (i = 0; i < 8; i++) {

if (testrslts[i] != testdata3[i])

msg(“NVRAM test error 3╲n”);

}

}

for (address = 0; address < 1024; address += 8)

NVRam_WriteStructure(address, testdata4,8);

for (address = 0; address < 1024; address += 8) {

NVRam_ReadStructure(address, testrslts,8);

for (i = 0; i < 8; i++) {

if (testrslts[i] != testdata4[i])

msg(“NVRAM test error 4╲n”);

}

}

}

#endif // 전처리기에서 마무리는 반드시 잊지 말자.

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

다음과 같은 문장은 헤드파일에서 중복을 피하기 위해 사용하기도 하는 사항임으로 꼭

알아두자.

#ifndef _APP_H_

#define _APP_H_ // 정의되지 않았으면 정의한다.

// 필요한 헤드파일 선언, 이미 정의된 다른 헤드 파일에 있어도 중복 설정 에러가 발

생하지 않는다.

#endif

다음의 문구는 서로 다른 컴파일러에서 Type의 혼돈을 최소화하기 위해 사용한다.

#ifdef BYTE // 정의되어 있다면

#undef BYTE // 정의를 취소하고

#endif

typedef unsigned char BYTE; // 8 bit quantity 다시 설정

#ifdef WORD

#undef WORD

#endif

typedef unsigned short WORD; // 16 bit quantity 다시 설정

컴파일러마다 다르게 준비되어 있는 Pragma 명령어를

이용하여 컴파일러에게 특별한 지시가 가능하다. 프라그마

명령어는 컴파일러가 가지고 있는 고유의 실행문임으로 사

용하고자 할 경우는 매뉴얼을 참고해야 실수가 없다.

#pragma COPYRIGHT “This Program is HP”

#pragma VERSIONID “Hello Firmware”

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

void test(void){

#pragma asm

MOV A, RSEG3

ANL A, #01111111b

MOV RSEG3, A

MOV A, RSEG4

ANL A, #01111111b

MOV RSEG, A

MOV RTM100, #5

#pragma endasm

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

Pragma Directive

문법

#pragma 지시단어 명령어

보기

#pragma OPTIMIZE ON

#pragma OPTIMAZE OFF

89Embedded World

90

TECHNICAL FEATURE

#error 명령어는 진단메시지를 컴파일러에게 생성하게 할

때 이용하며 에러가 발생함으로 컴파일러는 실행도중 멈추게

된다. 다음의 파일은 모토로라 컴파일러인 Metrowerks사의

Codewarrior의 예제를 불러온 것이다.

void TERMIO_Init(void) {

#if TEST_TERM

SCI.BAUD = 0x30; /* baud rate 9600 at 8 MHz */

SCI.SCCR2 = 0x0C; /* 8 bit, TE and RE set */

SCI.SCSR |= 0x80; /* output buffer empty */

#elif defined(__HC12__)

#if 0

SCI.SCxBDL = 52; /* baud rate 9600 at 8 MHz */

#else

SCI.SCxBDL = 1; /* for the simulator */

#endif

SCI.SCxCR2 = 0x0C; /* 8 bit, TE and RE set */

#elif (defined(__HC16__) || defined(__M68K__))

SCI.SCCR0 = 55; /**** Select baud rate 9600 */

SCI.SCCR1 = 0x000C; /**** 8 bit, TE and RE set */

#elif defined(__H8_500__)

SCI.SMR = 8; /* 00001000: 8 bits per character, no parity, 2 stop bit, */

SCI.BRR = 32; /* Baud rate 9600 */

SCI.SCR = 0x30; /* 00110000: disable Tx and Rx interrupt */

#elif defined(__XA__)

SCI.S0CON = 0x12; /* UART0 mode 0 (shift register): Baud rate = osc / 16 */

SCI.S0STAT = 0x00; /* NB: XA SFRs IO simulation simulates only this mode. */

#else

#error “unknown architecture”// 에러일 경우 메시지를 출력

#endif

}

Error Direction

문법

#error 처리문

보기

#error "Not Found"

원 고 모 집

월간 Embedded World의 편집 방향을 빛내 줄 참신한

원고를 기다립니다.

아직 소개되지 않은 최신 임베디드 시스템 기술자료나

제품정보, 그리고 현장 경험을 바탕으로 작성된 테마

원고를 환 합니다.

모 집 분 야

- 임베디드 프로세서 설계 및 응용

- 임베디드 엔지니어를 위한 Java의 기초와 응용

- UML 및 C(C++/SystemC) 언어를 이용한 SoC 설계

- Real-Time OS 분석 및 설계

- 무선 LAN 설계기술

- 임베디드 시스템의 IPv6 응과 실장방법

많은 사람과 임베디드 시스템 설계 경험을 함께

나누고자 하는 시 정신이 투철한 분이면 누구나

필자로 모십니다.

채택된 원고에 한해서는 소정의 고료를 드립니다.

(주)테크월드 서울시 등포구 림3동 682-2호

Tel: (02)835-2100 Fax: (02)835-2166

접 수 처 : 월간 Embedded World 취재부

The Community Magazine for Embedded Systems Industry Real-Time

UBIQUITOUSUBIQUITOUS

(주)테크월드 서울시 등포구 림3동 682-2 http://www.embeddedworld.co.kr광 고 문 의: TEL 02-835-2100 FAX 02-835-2166

92

TECHNICAL FEATURE

Qt/Embedded를 이용한

임베디드 리눅스 프로그래밍②Qt/Embedded 프로그래밍 1

지난 달에는 전반적인 임베디드 리눅스 프로그래밍과 실제 Qt/Embedded 프로그램 개발에 필요한 환경설정, 그리고 Hello World 프로그래밍까지

학습했다. 이번부터 3회에 걸쳐 실제 Qt/Embedded 프로그래밍에 관해서 다루도록 하겠다.

: 이연조/yunjodan@hotmail.com

현재 시중에 나와 있는 Qt/Embedded 프로그래밍 서적은 단지 몇 권이 있을

뿐이다. 다른 프로그래밍 관련 서적에 비하면 상당히 부족한 편이다. 게다가 인터

넷에 올라와 있는 것들도 역시 부족한 편이다. 어찌 되었든 개발자로서는 책으로

기초를 배울 수 있겠지만, 결국은 개발문서를 참조해서 개발에 임해야 한다.

Qt/Embedded 개발문서는 HTML 형식으로 만들어져 있다. 그러므로 네스케

이프(Netscape) 나 컹커러(Konqueror) 등 같은 웹브라우저 프로그램을 이용해

서 보면 된다. 개발문서의 위치 경로는 아래와 같다.

$QTDIR/doc/html/

여기에는 수많은 파일들이 있을 것이다. Index.html 파일이 있을 것이므로 이

것을 먼저 보면 된다. 그리고 트롤테크 홈페이지(www.trolltech.com)으로 가면

인터넷으로도 개발문서를 참조할 수 있을 것이다.

Qt/Embedded 클래스의 모음을 보고 알파벳순으로 보고 싶다면‘Alphabetical

Class List’를 선택해서 보자. 개발자들이 이 페이지를 전반적으로 가장 많이 사용

하지 않을까 싶다.

그리고 각 클래스의 상속구조를 보고 싶다면‘Inheritance Hierachy’를 선택

하면 된다. 전반적인 Qt/Embedded 클래스의 상속구조를 볼 수 있을 것이다. 특

히 QWidget 클래스와 그것을 상속받은 클래스를 한번 살펴보도록 한다.

QWidget에 관련돼서 가장 많이 사용되므로 꼭 알아두도록 한다.

Qt/Embedded 클래스를 기능별로 그룹을 지어서 모아놓은 페이지도 있다. 이

연재순서

1회 Qt/Embedded와 개발환경

2회 Qt/Embedded 프로그래밍 1

3회 Qt/Embedded 프로그래밍 2

4회 Qt/Embedded 프로그래밍 2

5회 임베디드 DB 프로그래밍

6회 Qt/Embedded 최적화와 타깃으로 포팅

93Embedded World

것은‘Structure Overview’를 클릭하면 볼 수 있을 것이다.

Qt/Embedded 프로그래밍에서 가장 중요한 것 중 하나

가 위젯을 다루는 것이다. 여기서 위젯을 프로그램에 넣는

것을 해보자. 실행된 화면은그림 2와 같다.

그럼 소스를 보자.

#include <qpushbutton.h>

QPushButton* bt1;

이번에는 QPushbutton이라는 클래스가 새로 보일 것이다.

이 QPushButton은 가장 많이 사용되는 GUI의 구성요소인

버튼으로 사용자가 누르고 뗄 수 있다. QPushButton은 텍스

트 또는 QPixmap을 이용한 이미지를 표현할 수 있다. 우리가

일반적으로 사용하는 버튼의 경우, Qt/Embedded에서는

QPushbutton이라는 클래스를 사용한다.

bt1 = new QPushButton(“Push button”, this);

int main(int argc, char **argv)

{

QApplication app(argc, argv);

MyWidget mw;

app.setMainWidget(&mw);

mw.resize(150, 100);

mw.show();

return app.exec();

}

#include <qapplication.h>

#include <qwidget.h>

#include <qpushbutton.h>

class MyWidget : public QWidget

{

public:

MyWidget();

private:

QPushButton* bt1;

};

MyWidget::MyWidget()

{

setCaption(“Hello World”);

bt1 = new QPushButton(“Push button”, this);

bt1->setGeometry(20, 20, 80, 40);

}

그림 1. 컹커러에서 개발문서를 표시한 화면 그림 2. 간단한 위젯 예제 화면

94

TECHNICAL FEATURE

부모위젯으로 this를 설정한 후“Push button”이라는

이름의 버튼을 생성한다. 이때 버튼 객체인 bt1은

MyWidget 클래스의 멤버 변수인데 생성자 내에서의 지역

변수로 사용해도 상관이 없다. 여기서 bt1을 제거하는 루틴

을 넣을 필요는 없다. 자동으로 제거가 되기 때문이다.

Qt/Embedded에서는 해당 위젯의 부모위젯이 제거될 때

자동적으로 그 해당 위젯도 같이 제거된다. 그러므로 모든

위젯은 힙(Heap) 역에서 생성되어야 한다. 좀더 쉽게 말

하면 위젯을 생성할 때 new를 이용해서 생성하라는 것이

다. 하여튼 이것만 지킨다면 자식위젯(Child Widget)을 제

거해야 하는 코드를 넣을 필요가 없으므로 소스구조가 간단

해지고 개발하기도 편해질 것이다.

시그널(signals)과 슬롯(slots)의 개념은 Qt/Embedded

프로그래밍에 있어서 매우 중요한 요소이다. 운 체제인

Windows나 MacOS, X-Windows에서의 프로그래밍은

일반적으로 이벤트 또는 메시지 처리를 한다. 그것과 거의

동일한 개념으로 보아도 좋을 것이다. 오히려 기존의 운

체제에서 하던 이벤트 처리 프로그래밍이나 메시지 처리보

다 훨씬 쉽게 사용을 할 수 있다.

기존의 프로그래밍에서의 이벤트처리는 콜백함수

(callback function)를 사용해서 많이 했는데, 이것은 함수

등록시 잘못된 인수형을 받도록 해놓았다든지 그런 실수가

생겼을 때 예상치 못했던 문제를 발생시킨다. 왜냐하면 컴

파일러가 사전에 이런 문제를 막아줄 수 없기 때문이다.

또는 Windows 프로그래밍 개발에 많이 사용하는

MFC(Microsoft Foundation Class)의 경우는 메시지 맵

이라는 것을 사용한다. 참고로 Windows에서는 이벤트를

메시지(Message)라고 부른다. 어쨌든 메시지 맵은 메시지

를 처리하기 위해 매크로를 사용하는 방법으로, 특정한 메

시지를 파생된 클래스의 멤버 함수에 응시켜서 처리를 하

는 것이다. 이것 역시 데이터형의 안정성을 보장하지는 못

한다.

이것의 안으로 Qt/Embedded에서는 시그널과 슬롯이

란 개념을 내놓았다. 모든 Qt/Embedded 클래스들(정확히

말하면 QObject 클래스를 상속받은 클래스) 시그널과 슬롯

을 가질 수 있다. 어떠한 위젯이 자신의 내부상태가 변경이

되었다면 시그널을 발생시킨다. 그리고 필요한 곳에서 슬롯

으로 시그널을 받으면 그만이다. 어떠한 오브젝트 이든지 자

신과 관계된 것만 중요시하면 된다. 이러한 Qt/Embedded

의 시그널과 슬롯 메커니즘으로 컴포넌트 프로그래밍으로

이끌어 줄 것이다. 좀더 알게 되면 느낄 수 있겠지만 배우는

것도 쉽고 사용하기도 매우 편하다.

참고로 Qt/Embedded의 시그널과 유닉스의 시그널과는

아무런 상관이 없으므로 헷갈리지 말길 바란다.

시그널과 슬롯 예제

실제로 예제를 통해서 시그널과 슬롯에 관해서 알아보도

록 하자. 두 개의 버튼(Show, Hide)을 클릭 하면 그림 3의

라벨을 보이도록, 또는 안보이도록 하는 프로그램을 만들어

보자. 화면은그림 3과 같다.

소스를 보고 분석을 해보자.

#include <qapplication.h>

#include <qwidget.h>

#include <qlabel.h>

#include <qpushbutton.h>

class MyWidget : public QWidget

{

public:

MyWidget();

private:

QPushButton* bt1;

QPushButton* bt2;

QLabel* lb1;

};

MyWidget::MyWidget()

{

setCaption(“Signal & Slot”);

bt1 = new QPushButton(“Show”, this);

bt1->setGeometry(10, 20, 40, 20);

bt2 = new QPushButton(“Hide”, this);

bt2->setGeometry(60, 20, 40, 20);

95Embedded World

프로그램을 직접 실행시켜서 버튼을 누를 때마다 라벨이

보여졌다가 안보 다가 하는지를 확인해 보자.

#include <qlabel.h>

이번 프로그램에는 QLabel이라는 위젯이 사용되었다. 그

래서 그에 해당하는 헤더 파일을 포함시킨다. QLabel은 아

주 간단한 GUI 구성요소로서 텍스트나 이미지 정보를 화면

에 표시하는 역할을 한다.

bt1 = new QPushButton(“Show”, this);

bt1->setGeometry(10, 20, 40, 20);

bt2 = new QPushButton(“Hide”, this);

bt2->setGeometry(60, 20, 40, 20);

bt1, bt2 두 개의 버튼을 생성했다.

lb1 = new QLabel(this);

lb1->setText(“This is Label ��”);

lb1->setGeometry(20, 60, 120, 20);

앞에서 언급했듯이 라벨 위젯은 텍스트나 이미지를 화면

에 표시할 수 있다고 했다. 여기서는 텍스트를 표시하도록

setText() 함수를 사용했다.

connect(bt1, SIGNAL(clicked()), lb1, SLOT(show()));

connect(bt2, SIGNAL(clicked()), lb1, SLOT(hide()));

여기서 가장 중요한 것은 connect() 함수이다. 버튼이 클

릭이 될 경우 clicked()라는 시그널을 발생시킨다. 그리고

이것을 lb1 객체의 show(), hide() 슬롯함수에 연결하는 것

을 선언한 것이다. 지금 Qt/Embedded 개발문서를 열어서

QPushButton 클래스를 보자. clicked()라는 시그널이 있

는가? 이 clicked()라는 시그널은 버튼이 클릭되었을 때 발

생한다.

bt1 버튼이 클릭되었을 때는 라벨의 show() 슬롯을 호출

하도록 하고, bt2 버튼이 클릭되었을 때는 라벨의 hide() 슬

롯을 호출하도록 했다. QLabel 문서를 보면 show()와

hide() 슬롯을 찾을 수 없을 것이다. 왜 그럴까? 이유는

QLabel은 QWidget을 상속받은 클래스이다. 이 show()와

hide() 슬롯은 QWidget에 정의가 되어 있는 것이므로

QLabel에서도 사용을 할 수 있는 것이다. 물론 버튼이나 기

타 위젯도 마찬가지이다.

이 show() 슬롯은 호출하면 해당 위젯을 보이도록 해준

다. 반 로 hide()는 해당 위젯을 안보이게 해준다.

lb1 = new QLabel(this);

lb1->setText(“This is Label ~~”);

lb1->setGeometry(20, 60, 120, 20);

connect(bt1, SIGNAL(clicked()), lb1, SLOT(show()));

connect(bt2, SIGNAL(clicked()), lb1, SLOT(hide()));

}

int main(int argc, char **argv)

{

QApplication app(argc, argv);

MyWidget mw;

app.setMainWidget(&mw);

mw.resize(150, 100);

mw.show();

return app.exec();

}그림 3. 시그널과 슬롯 예제

96

TECHNICAL FEATURE

사용자 정의 시그널과 슬롯

이번에는 사용자 정의 시그널과 슬롯을 만들어 보자. 그림

4는 실행된 화면이다. 버튼을 클릭할 때마다 화면에

‘Signal & Slot ���’이라는 문자열을 화면에 계속해서

출력하는 프로그램이다.

이번에는 이전처럼 하나의 소스 파일이 아니고 main() 함

수와 MyWidget 클래스의 파일들을 분리시켰다. 이렇게 한

이유는 뒤에 moc라는 것 때문에 일부러 분리를 해놓은 것

이다. moc는 뒤에서 설명하겠다.

그럼 소스를 보자.

<mywidget.h>

<mywidget.h>

#include <qpainter.h>

#include “mywidget.h”

MyWidget::MyWidget()

{

setCaption(“Signal & Slot”);

m_nCount = 0;

bt1 = new QPushButton(“Button”, this);

bt1->setGeometry(10, 20, 80, 20);

connect(bt1, SIGNAL(clicked()), this, SLOT(slotClicked()));

}

void MyWidget::paintEvent( QPaintEvent *)

{

QPainter painter(this);

for (int i = 0; i < m_nCount; i++)

{

painter.drawText(10, 60 + (i * 20), “Signal & Slot ~~~”);

}

}

void MyWidget::slotClicked()

{

m_nCount++;

repaint();

}

protected slots:

void slotClicked();

protected:

void paintEvent( QPaintEvent *);

int m_nCount;

};

#endif // MYWIDGET_H

#ifndef MYWIDGET_H

#define MYWIDGET_H

#include <qwidget.h>

#include <qpushbutton.h>

class MyWidget : public QWidget

{

Q_OBJECT

public:

MyWidget();

private:

QPushButton* bt1;

그림 4. 사용자 정의 시그널과 슬롯 화면

97Embedded World

<main.cpp>

이번 프로그램은 프로그램 소스 파일이 3개이므로, 프로

젝트 파일을 만들자. 그리고 이것을 가지고 Makefile을 만

들고 컴파일을 하자.

실행을 해서 확인을 해본다. 버튼을 누르면 뭔가 작동되는

것이 있는지 알아보자. 잘 된다면 ls 명령으로 파일리스트를

확인해 보자.

Makefile

main.cpp

main.o

moc_mywidget.cpp

moc_mywidget.o

mywidget.cpp

mywidget.h

mywidget.o

signalslot*

signalslot.pro

본인도 모르게 생성된 파일이 있다. moc_mywidget.cpp

이란 파일이다. moc_mywidget.o는 오브젝트 파일이므로

moc_mywidget.cpp 파일을 컴파일 해서 나온 파일임이 분

명하다. 이것은 사용자 정의 시그널과 슬롯을 정의하게 되

면 생기는 파일로 뒤에 moc에 관한 설명에서 좀더 자세히

다룰 테니 그냥 그렇다고 생각하고 넘어가자.

혹시 컴파일이 제 로 되지 않는다면 $QTDIR/bin 디렉

토리 안에 moc라는 파일이 있는지 알아보자. 그 파일이 있

어도 문제가 있다면 moc에 관한 설명을 본 후에 문제점을

찾아보자.

그럼 소스를 분석하자.

class MyWidget : public QWidget

{

Q_OBJECT

시그널 또는 슬롯을 갖는 모든 클래스는 자신의 클래스 안

에 비공개로 Q_OBJECT를 기술해야 한다. 일반적으로는

클래스 선언 맨 앞에 위치시킨다. 이것을 기술하지 않으면

시그널과 슬롯 처리가 제 로 되지 않을 것이다. 의심이 간

다면 Q_OBJECT를 빼고 컴파일 해서 확인해 보도록 한다.

나중에라도 혹시 시그널과 슬롯이 제 로 작동하지 않는다

면 이 부분을 꼭 확인해 보도록 한다.

protected slots:

void slotClicked();

슬롯 함수의 선언은 위와 같이 한다. 슬롯 함수도 C++ 문

법과 같이 함수의 공개범위를 public, protected, private

을 설정할 수 있다.

m_nCount = 0;

m_nCount의 초기값을 0으로 한다.

# ls

# progen main.cpp mywidget.h mywidget.cpp -o signalslot.pro

# tmake singalslot.pro -o Makefile

# make

#include <qapplication.h>

#include “mywidget.h”

int main(int argc, char **argv)

{

QApplication app(argc, argv);

MyWidget mw;

app.setMainWidget(&mw);

mw.resize(150, 250);

mw.show();

return app.exec();

}

98

TECHNICAL FEATURE

connect(bt1, SIGNAL(clicked()), this, SLOT(slotClicked()));

버튼이 클릭되어서 clicked() 시그널이 발생하면 우리가

만든 slotClicked() 슬롯으로 연결시킨다.

void MyWidget::paintEvent( QPaintEvent *)

{

QPainter painter(this);

for (int i = 0; i < m_nCount; i++)

{

painter.drawText(10, 60 + (i * 20), “Signal & Slot ~~~”);

}

}

카운트의 개수에 맞게‘Signal & Slot���’문자열을

화면에 출력한다.

void MyWidget::slotClicked()

{

m_nCount++;

repaint();

}

이것은 우리가 만든 slotClicked() 슬롯 함수이다. 함수를

정의하고 사용하는 것은 일반적인 함수와 다른 것이 없다.

여기서는 카운트를 증가시키고 repaint()라는 함수를 호출

해서 화면을 다시 그리기를 요청한다.

moc란?

앞에서 몇 번 moc라는 것을 언급한 적이 있다. 여기서는

moc에 해 알아보자.

신 한 가지 앞서서 말하고 싶은 것은 tmake를 사용해

서 Makefile을 만드는 경우는 moc에 관해서 신경을 쓰지

않아도 좋다. 이제부터 나올 내용들은 tmake로 Makefile

을 만들면서 자동으로 해결이 되기 때문이다. 좀더 구조적

으로 알고 싶거나 moc와 관련해서 프로그램의 컴파일이 잘

안된다면 아래의 내용을 보도록 한다.

사용자 정의 시그널과 슬롯을 정의할 경우에는 단순히 컴

파일만 해선 제 로 프로그램이 동작하지 않을 것이다. 반드

시 Qt/Embedded에서 제공하는 메타 객체 컴파일러(Meta

Object Compiler)로 클래스 정의가 있는 파일을 컴파일 해

야 한다. 여기서의 메타 객체 컴파일러가 moc인 것이다.

그래서 위의 예제에서의 moc_mywidet.cpp는 아래와 같

이 하면 moc가 만든 메타 오브젝트 코드가 생성된다.

제 로 moc가 실행이 되지 않는다면 $QTDIR/bin에

moc가 있는지 확인하고 그에 맞게 PATH도 확인한다.

이렇게 만들어진 메타 오브젝트 코드를 가지고 최종 프로

그램과 연결을 하게 된다.

그러면 실제로 tmake로 만든 Makefile로 컴파일을 했을

경우에 moc를 가지고 메타 오브젝트 코드를 만드는지 확인

해보자. 세심히 잘 보기 바란다. 컴파일 내용 중 가운데쯤에

아래와 같은 내용이 있는지 확인한다.

여기서 moc가 메타 오브젝트 코드를 만들어낸 것이다.

그리고 이 파일을 g++로 컴파일 했다. 마지막으로 봐야 할

것은 맨 마지막 라인에 아래와 같은 것이 있는지 확인한다.

g++ -o signalslot main.o mywidget.o moc_mywidget.o -L/..../lib -lqte

여기서 지금까지 컴파일해서 만들어낸 오브젝트 파일(.o)

를 연결해서 최종 프로그램을 만들어내는 것이다. 그러므로

tmake를 사용하게 되면 특별히 moc에 관련되어서 신경 쓸

것은 없을 것이다. 보통은 어떤 방식으로 만들어지는 지를

알고 있으면 될 것이다.

# moc mywidget.h -o moc_mywidget.cpp

# moc -o moc_mywidget.cpp mywidget.h

99Embedded World

가끔씩 새로 정의한 시그널과 슬롯의 루틴이 프로그램에

서 제 로 동작하지 않는 경우가 있다. 첫 번째로 확인해 볼

것은 시그널과 슬롯 서로의 인자가 맞는지를 확인해 보자.

그래도 안된다면 make clean 명령으로 기존의 moc로 만

들어낸 파일을 모두 지운 후, 다시 컴파일 하기 바란다. 거

의 부분의 경우는 이 2가지 방법을 사용하면 제 로 동작

할 것이다.

시그널과 슬롯 연결 끊기

프로그램이 동작 중에 기존에 연결된 시그널과 슬롯의 연

결을 잠시 또는 원히 끊을 경우도 발생한다. 일반적으로

시그널과 슬롯의 연결을 끊을 때는 disconnect() 함수를 사

용한다. 아래는 사용 예이다.

disconnect(this, SIGNAL(sigChangeCaption(int)),

this, SLOT(slotChangeCaption(int)));

connect()를 할 때와 다른 것이 전혀 없다. 아래와 같이

사용할 수도 있다.

disconnect(this, SIGNAL(sigChangeCaption(int)));

하지만 이런 방식은 명시적이지 않아서 혼란을 가져올 수

있으므로 앞의 코드에서 나온 로 하는 것이 좋다.

그리고 잠시 동안만 시그널과 슬롯의 연결을 막아줄 수도

있다. blockSignals()라는 함수를 사용하면 된다. 아래는

사용 예이다.

pushbutton->blockSignals(true);

:

:

pushbutton->blockSignals(false);

이렇게 하면 중간에 푸시버튼에 어떤 변화가 생겨도 시그

널이 생기지 않으므로 무언가 원하는 것을 할 수 있을 것이

다. 이 blockSignals() 함수는 QPushbutton이나

QWidget 클래스의 개발문서를 찾아봐도 나오지 않을 것이

다. 이것은 모든 Qt 클래스의 기반 클래스인 QObject의 멤

버 함수이다.

실제로 어느 정도 Qt/Embedded 프로그래밍에 익숙해지

면, 개발 시에 가장 많이 참조하는 것은 개발문서일 것이다.

그리고 개발문서에서도 위젯의 함수에 관해서 가장 많이 찾

아보게 될 것이다. 하지만 많은 위젯과 거기에 해당하는 수

십 개의 함수들까지 사용법을 외울 필요는 없을 것이다. Qt

라이브러리는 구조가 어느 정도 체계화되어 있기 때문에 어

느 정도의 감이 오면 충 처음 보는 위젯이라 할지라도 거

부감이 없이 사용법을 금방 익힐 수 있을 것이다.

그러므로 모든 위젯의 사용법을 자세히 알려고 하기보다

는 전반적인 사용 방법을 익혀두도록 하자. 일단 각 위젯의

특성을 알고, 자주 사용하는 함수를 위주로 배워 나가자. 그

런 후에 특수한 기능이 필요할 때 개발문서에서 함수들을 찾

아보도록 하자.

표 1은 사용 빈도가 높은 위젯을 간단하게 설명했고 알파

위젯 설명 그룹

QButtonGroup 버튼을 그룹으로 관리 배치 위젯

QCheckBox 여러 항목 중에 다중 선택이 가능 버튼 위젯

QComboBox 여러 항목중에서 하나만 선택이 가능 선택 위젯

QDial 값의 범위내에서 수치값을 입력받음 범위 입력 위젯

QGroupBox 위젯을 그룹으로 표시 배치 위젯

QLabel 텍스트나 이미지를 표시 화면 표시 위젯

QLCDNumber LCD 형태의 숫자를 표시 화면 표시 위젯

QLineEdit 단일 라인 텍스트 입력 에디터 에디트 위젯

QListBox 단일 컬럼의 항목 리스트 선택 위젯

QListView 여러 컬럼과 트리 항목 리스트 리스트 뷰

QMultiLineEdit 여러 라인 텍스트 입력 에디터 에디트 위젯

QPopupMenu 팝업 메뉴 팜업 메뉴

QProgressBar 진행 상태를 표시 프로그레스바

QPushButton 일반적인 버튼 버튼

QRadioButton 여러 항목 중에 하나만 선택이 가능한 버튼 버튼

QSlider 값의 범위내에서 수치값을 입력받음 범위 입력 위젯

QSpinBox 값의 범위내에서 수치값을 입력받음 범위 입력 위젯

QSplitter 두 개의 위젯의 역을 분리 배치 위젯

QWidgetStack 자식 위젯 중에서 하나만을 보여줌 배치 위젯

표 1. 사용 빈도가 높은 위젯의 설명

100

TECHNICAL FEATURE

벳순으로 정리했다. 임베디드 환경에서 가장 많이 사용되는

위젯을 고른다면 푸시버튼, 콤보박스, 에디트 위젯을 꼽을

수 있다. 이중 푸시버튼은 앞에서 다룬 관계로 콤보박스와

에디트 위젯에 해서만 알아보자.

콤보 박스

콤보 박스(Combo box)는 Qt/Embedded에서 QCombo

Box 클래스로 표시된다. 콤보 박스는 체크 박스나 라디오

버튼처럼 여러 항목을 화면에 표시하고, 사용자가 원하는

것을 선택할 수 있도록 해주는 위젯이다. 이 위젯의 큰 특징

으로는 화면에 차지하는 공간이 작다는 것이다. 예제를 실

행한 화면은그림 5와 같다.

아래는 프로그램의 소스이다.

<main.cpp>

<mywidget.h>

<mywidget.cpp>

#include <qpixmap.h>#include “mywidget.h”

MyWidget::MyWidget(){

QPixmap pm1(“book1.xpm”);QPixmap pm2(“book2.xpm”);QPixmap pm3(“book3.xpm”);QPixmap pm4(“book4.xpm”);

resize(150, 70);

cb1 = new QComboBox(true, this);cb1->setGeometry(20, 20, 100, 25);

cb1->insertItem(pm1, “item 1”);cb1->insertItem(pm2, “item 2”);cb1->insertItem(pm3, “item 3”);cb1->insertItem(pm4, “item 4”);

connect(cb1, SIGNAL(activated(int)), this, SLOT (slotActivated(int)));}

void MyWidget::slotActivated(int index){

QString str;

str = tr(“%1”).arg(index);setCaption(“item :”+ str);

}

#ifndef MYWIDGET_H

#define MYWIDGET_H

#include <qwidget.h>

#include <qcombobox.h>

class MyWidget : public QWidget

{

Q_OBJECT

public:

MyWidget();

private slots:

void slotActivated(int);

private:

QComboBox* cb1;

};

#endif // MYWIDGET_H

#include <qapplication.h>#include “mywidget.h”

int main(int argc, char **argv){

QApplication app(argc, argv);MyWidget mw;

app.setMainWidget(&mw);mw.show();

return app.exec();}

그림 5. 콤보박스 예제 화면

<combobox.pro>

#include <qpixmap.h>

QPixmap 클래스를 사용하므로 헤더를 불러들 다.

QPixmap pm1(“book1.xpm”);

‘book1.xpm’이란 이름을 가진 이미지 파일을 읽어 들

여서 QPixmap 개체를 생성한다. xpm 파일은 X-윈도우

의 그래픽 파일로서 윈도우의 bmp 파일을 떠올리면 될

것이다.

cb1 = new QComboBox(true, this);

콤보박스를 생성했다. 생성자의 첫 번째 인자는 읽기쓰기

모드의 콤보박스인지의 유무를 설정하는 것이다. 여기서는

읽기 전용 모드의 콤보박스를 생성했다. 여기서의 읽기쓰기

모드나 읽기 전용 모드라는 것은 콤보박스의 버튼 옆에 선택

된 항목이 표시된 곳의 상태를 말하는 것이다.

cb1->insertItem(pm1, “item 1”);

생성한 픽스맵과 텍스트를 콤보박스의 항목으로 추가한

다. 이 예제의 실행화면에서 볼 수 있듯이 콤보박스의 항목

으로 이미지와 텍스트가 동시에 나오는 것을 구현하는 것은

정말 쉽다.

connect(cb1, SIGNAL(activated(int)), this, SLOT(slotActivated(int)));

activated() 시그널을 slotActivated() 슬롯함수로 연결

했다. 여기서 int 형의 인자는 선택한 항목의 인덱스이다.

void MyWidget::slotActivated(int index)

{

QString str;

str = tr(“%1”).arg(index);

setCaption(“item :”+ str);

}

선택한 항목을 캡션에 표시한다. tr()과 arg()를 이용해서

sprintf() 같은 함수처럼 사용을 하 다. 실제로 QString

클래스를 보면 멤버함수로 sprintf()를 제공한다. 기존의 도

스 프로그래밍이나 유닉스, 리눅스 프로그래머들은

sprinf() 함수가 더 친근할 텐데, 위와 같이 사용하는 이유

는 국제화 처리 쪽에서 설명하기로 하겠다.

에디트 위젯

에디트 위젯은 Qt/Embedded에서 QLineEdit 클래스와

QMultiLineEdit 클래스로 2가지 있다.

한 라인의 문자 입력을 받기 위한, 여러 라인의 문자 입력

을 받기 위한 위젯이다. 여기서는 라인 에디트 위젯만 보도

록 하자.

라인 에디트 예제가 실행된 화면은 그림 6과 같다. 그리고

소스는 아래에 있다.

TEMPLATE = app

CONFIG = qt warn_on release

HEADERS = mywidget.h

SOURCES = main.cpp mywidget.cpp

INTERFACES =

101Embedded World

그림 6. 라인 에디트 예제 화면

102

TECHNICAL FEATURE

<main.cpp>

<mywidget.h>

<mywidget.cpp>

<lineedit.pro>

#include <qlineedit.h>

라인에디트를 사용하기 위해서 헤더를 포함시켰다.

edit1 = new QLineEdit(this);

edit1->setGeometry(10, 10, 130, 20);

라인에디트를 생성했다.

bt1 = new QPushButton(“get text”, this);

bt1->setGeometry(30, 40, 80, 20);

라인에디트 위젯을 제어하기 위한 버튼들을 생성했다.

TEMPLATE = appCONFIG = qt warn_on releaseHEADERS = mywidget.hSOURCES = main.cpp mywidget.cppINTERFACES =

bt1->setGeometry(30, 40, 80, 20);bt2 = new QPushButton(“select all”, this);bt2->setGeometry(30, 70, 80, 20);bt3 = new QPushButton(“clear”, this);bt3->setGeometry(30, 100, 80, 20);

connect(bt1, SIGNAL(clicked()), this, SLOT(slotGetText()));connect(bt2, SIGNAL(clicked()), this, SLOT(slotSelectAll()));connect(bt3, SIGNAL(clicked()), this, SLOT(slotClear()));

}

void MyWidget::slotGetText(){

QString str = edit1->text();

setCaption(str);}

void MyWidget::slotSelectAll(){

edit1->selectAll();}

void MyWidget::slotClear(){

edit1->clear();}

#include "mywidget.h"

MyWidget::MyWidget(){

resize(150, 130);

edit1 = new QLineEdit(this);edit1->setGeometry(10, 10, 130, 20);

bt1 = new QPushButton("get text", this);

#ifndef MYWIDGET_H#define MYWIDGET_H

#include <qwidget.h>#include <qpushbutton.h>#include <qlineedit.h>

class MyWidget : public QWidget{

Q_OBJECTpublic:

MyWidget();private slots:

void slotGetText();void slotSelectAll();void slotClear();

private:QLineEdit* edit1;QPushButton* bt1;QPushButton* bt2;QPushButton* bt3;

};

#endif // MYWIDGET_H

#include <qapplication.h>

#include “mywidget.h”

int main(int argc, char **argv)

{

QApplication app(argc, argv);

MyWidget mw;

app.setMainWidget(&mw);

mw.show();

return app.exec();

}

connect(bt1, SIGNAL(clicked()), this, SLOT(slotGetText()));

각 버튼에 해당하는 슬롯함수를 연결했다.

void MyWidget::slotGetText()

{

QString str = edit1->text();

setCaption(str);

}

첫 번째 버튼을 누르면 연결되는 슬롯함수로, 현재 라인에

디트에 있는 스트링을 캡션으로 설정한다.

void MyWidget::slotSelectAll()

{

edit1->selectAll();

}

두 번째 버튼을 누르면 연결되는 슬롯함수로, 현재 라인에

디트에 있는 스트링을 모두 선택해서 반전시킨다.

void MyWidget::slotClear()

{

edit1->clear();

}

세 번째 버튼을 누르면 연결되는 슬롯함수로, 현재 라인에

디트에 있는 스트링을 모두 지운다.

이번 회에는 Qt/Embedded 프로그래밍에서의 기초적인

위젯들과 시그널 및 슬롯에 관해서 알아보았다. 다음 회는

좀더 자세한 Qt/Embedded 프로그래밍에 관해 다루도록

하겠다.

■참고문헌

임베디드 리눅스 프로그래밍, 이연조 저, PC BOOK

Teach Yourself Qt Programming in 24 Hours, Danniel Solin, SAMS

또다른 세상, 색다른 경험시간과 장소를 초월해

항상 최고의 서비스를 약속합니다.

The leading edge e-Magazine

여러분의

방문을

환 합니다.

http://www.embeddedworld.co.kr

디지털시 의 미디어 동반자 (주)테크월드

서울시 등포구 림3동 682-2

Tel:82-2-835-2100∙Fax:82-2-835-2166

e-mail:webmaster@embeddedworld.co.kr

104

UI Component를 이용한 GUI Programming

TECHNICAL FEATURE

한국형 모바일 표준 플랫폼

WIPI Programming③

SPECIAL CORNER

인터페이스(interface)란 일반적으로 다른 사람과 의사 소통하는 것을 의미한

다. 특히 우리가 흔히 개인용 컴퓨터 등에서‘사용자 인터페이스’라는 말을 쓸 때

는 사용자가 컴퓨터 프로그램을 운용하기 위한 각종 명령을 내리고 결과를 받게

되는 커뮤니케이션 방식을 의미한다.

과거 윈도우가 개발되기 전에는 컴퓨터나 프로그램이 제공하는 운 체계의 명

령어가 주요 사용자 인터페이스 장치가 됐다. 윈도우 개발 이후에는 사용자에게

그림을 이용한 의사소통 방법을 제공하는 그래픽 사용자 인터페이스(GUI:

Graphical User Interface)가 일반화됐다. GUI는 보통 인간 환경공학적으로

보다 만족스럽고 사용자 편의를 더 강조한 인터페이스로 평가된다.

Java의 AWT(Abstract Window Toolkit), Swing이나 Visual C++, Visual

Basic 등과 같은 언어를 이용하면 프로그래머가 손쉽게 GUI 기반 애플리케이션

을 작성할 수 있다. 또한 해당 언어에서는 Class 레벨로 GUI를 구성하는 요소들

을 제공하여, 개발자로 하여금 빠르게 개발할 수 있도록 지원한다. 기존 J2ME의

MIDlet에서는 High Level API가 이 부분을 미약하게 나마 지원한다. Java의

J2ME에서는 디바이스에 한 상 적인 제약성 때문에 Java의 AWT를 적용하

지 않고, 디바이스 환경에 맞게 새롭게 구성을 하 다. 하지만, J2ME의

CLDC/MIDP를 적용하는 SKT의 SK-VM이나 LGT의 midp에서는 국내 모바일

콘텐츠 특성상 게임 분야로의 개발이 워낙 특화되어 있어 GUI의 구성을 위해 지

원하는 High Level API를 거의 사용하지 않는다. 왜냐하면, 틀에 박힌 UI

Component들은 특화되고 독창적인 콘텐츠를 만들기엔 너무나도 역부족이 기

때문이다. 또한 Drawing 작업 자체가 불가능했기 때문에, 게임 콘텐츠 제작 시

GUI는 보통 인간 환경공학적으로 보다 만족스럽고 사용자 편의를 더 강조한 인터페이스로 평가된다. WIPI에서는 기존의 MIDlet의 문제점을 보완,

개선하여 MIDlet에 비해 상 적으로 성능이 우수한 UI Component들을 제공한다. 이번에는 WIPI에서 UI Component를 이용한 GUI 프로그래밍

을 소개한다.

: 김봉섭/안양 경실련∙Hitel 정보교육원 Mobile 전임수석연구원

kenshi@itkorea.or.kr

연재순서

2003. 2. 1. WIPI의 개요

2. WIPI 개발환경 구축 및

Jlet Programming

Pattern

3. Card를 이용한 Graphics

Programming 1

2003. 3. 4. Card를 이용한 Graphics

Programming 2

2003. 4. 5. UI Component를 이용한

GUI Programming

2003. 5. 6. File I/O 및 DataBase

Programming

2003. 6. 7. Network Programing

2003. 7. 8. MultiMedia/System

Programing

에는 적합하지 않았다. 결국 국내에서는 MIDlet의 AIP 중

High Level API는 천덕꾸러기가 된 것이다.

WIPI에서는 기존의 MIDlet의 문제점을 보완/개선하여

MIDlet에 비해 상 적으로 성능이 우수한 UI Component

들을 제공한다. 다음은 UI Component의 특징이다.

▶ UI 컴포넌트를 화면에 보여주기 위해서 맨 상단에는

ShellComponent를 사용해야 한다.

▶ ShellComponent 상에서 연결된 Card Class를 구하

여 Drawing 작업을 할 수 있다. 즉, MIDlet과는 달리

UI Component 상에서도 드로잉 작업을 할 수 있다.

▶ Multi Layer를 지원한다.

▶ Multipack UI와 같은 아이콘 중심의 메뉴나 리스트

메뉴 버튼 메뉴들을 생성할 수 있다.

▶ 프로그램 작성 스타일이 AWT와 유사하여 상당히 빠르

게 개발할 수 있다.

▶ UI Component의 크기, 색상, 위치 등을 직접 지정할

수가 있어 독창적인 UI를 작성할 수 있다.

이외에도 상당히 향상된 기능들을 맛볼 수 있다. 이제 천

천히 WIPI UI Component를 이용한 GUI 프로그램의 세

계로 들어가 보도록 하자.

그림 1은 WIPI Jlet UI Component 관련 API 상속도를

보여주고 있다.

105Embedded World

그림 1. UI Component API 상속도

Package org.kwis.msp.lwc(WIPI UI Component)

다른 Component를

포함할 수 있는 최상위

Component

최상위 Component

ContainerComponent(from iwc)

ShellComponent(from iwc) FormComponent(from iwc)

ListComponent(from iwc)

TextComponent(from iwc)

TextFieldComponent(from iwc)

LabelComponent(from iwc)

ListItemComponent(from iwc)

CheckboxComponent(from iwc)

ImageComponent(from iwc)

ComboComponent(from iwc)

TickerComponent(from iwc)

ButtonComponent(from iwc)

ScrollbarComponent(from iwc)

DateFieldComponent(from iwc)

ProgressComponent(from iwc)

CommandBarComponent(from iwc)

DialogComponent(from iwc)

TextBoxComponent(from iwc)

AnnunciatorComponent(from iwc)

Card와 연결을 해준다.

UI에서는 반드시 존재해야

만 LCD 상에 UI가 보인다.

Component(from iwc)

106

TECHNICAL FEATURE

Component

최상위에 있는 Component Class는 모든 Component들이

가지고 있는 공통된 속성과 메서드를 정의하고 있다. 컴포넌트

는 위치와 크기 정보를 가지며, 사용자의 입력을 받아서 적절한

행동을 하는 클래스이다. 화면에 보여지는 모든 UI 컴포넌트들

은 이 클래스를 상속받아서 구현해야 한다. Component 클래

스를 상속받은 자식 클래스들의 상위 부모 컴포넌트 상에서의

위치 및 폭과 넓이를 가지며, 배경색과 컴포넌트의 특성(입력

가능인지, 입력 포커스 등)을 가진다. 그러나 경우에 따라서는

상위 컴포넌트에 의해서 그 크기가 결정된다. Component 클

래스는 항상 상위 부모가 있어야 하지만, 상위 부모가 없어도

되는 Component가 있는데 그것이 ShellComponent이다. 결

론적으로 화면에 적어도 하나 이상의 ShellComponent가 있

어야 Component가 화면에 보이게 된다. 즉, 맨 마지막 상위

컴포넌트는 무조건 ShellComponent가 되어야 한다.

표 1은 정렬 조합 규칙이다. 해당 Component는 표와 같

은 정렬 조합 조건에 의해 조절할 수 있다.

ContainerComponent

ContainerComponent는 다른 컴포넌트의 상위 부모 컴

포넌트가 될 수 있는 컴포넌트들의 최상위 컴포넌트이다.

자식 컴포넌트의 위치와 크기를 결정해 주며, 포커스 관리

를 해준다. 컴포넌트는 addComponent 메서드로 자식 컴

포넌트로 등록할 수 있으며, removeComponent 메서드로

삭제할 수 있다. 컴포넌트는 상위 부모 컴포넌트가 있으며,

그 맨 상위 부모 컴포넌트가 ShellComponent이며 show

함수로 보여질 때 화면에 나타나게 된다.

ShellComponent

Card와의 연결을 해주며, 제목과 명령 입력 컴포넌트와

작업 컴포넌트를 가진다. UI 컴포넌트를 화면에 보여주기

위해서 맨 상단에는 이 컴포넌트를 사용해야 한다. Shell

Component는 addComponent 메서드를 통해서 하나의

작업 컴포넌트만을 추가해 가질 수 있다. 이 컴포넌트는

lcdui의 Card에 연결하여 카드로부터 들어오는 이벤트를

해당 컴포넌트에게 전달해 주는 역할을 담당한다. 화면에

타이틀과 프레임을 보여준다. 코드 1은 ShelloComponent

를 이용하여 UI를 구성하는 코드이다.

코드 1을 실행시키면 두 개의 ShellComponent가 생성되

어서 각각 ShellComponent가 속한 Card에 드로잉 되어서

Display 상에 올라가게 된다. ①번은 ShellCompoent를 생

성하는 부분이다. ShellCompoent는 Card와 연결하는 컴

포넌트라고 위에서 설명하 다. 그러나 코드 어디에서도

ShellComponent를 화면에 보이기 위해서 Card를 만든 흔

적이 없다. 즉, ShellComponent가 생성이 되면, 내부적으

로 ProxyCard를 생성하여 UI Component들을 그려내는

것이다. 멀티 카드가 지원되는 WIPI에서 UI Component

간의 다중 레이어 구현은 당연한 것이다. 즉, 화면상에

Component가 10개면 ProxyCard도 10개가 생성된다.

ProxyCard는 Card를 상속받았다. ②번은 실제적으로 UI

Component가 그려진 Card를 Display 상에 올리는 작업이

다. 즉, ②번이 수행되면 해당 UI Component가 현재

Display 상에 보이게 되고 현재 Layer 중 최상위(화면에 보

이는 관점)에 올라가게 되어 사용자의 이벤트를 받게 된다.

ShellComponent는 제목을 가질 수 있는데, ③번은 문자열

로 제목을 설정하는 부분이고, ⑤번은 LabelCompo- nent

로 제목을 설정하는 부분으로그림 2와그림 3을 보면 차이

점을 알 수 있다.

결과 화면을 보고 제목을 문자열로 처리할 때와 Label

Component로 처리할 때의 차이점을 독자들은 알 것이다.

문자열로 제목을 설정하면, 설정된 색에 의해 제목이 작업

컴포넌트와 구분이 된다. 하지만, LabelComponent로 제목

을 설정하면 ④번에 설정된 색상과 동일하게 적용되어 구분

없이 제목이 설정된다. 그리고, 두 개의 ShelloComponent

가 두 개의 Layer를 구성하여 보여지고 있다. 이 코드는 단

말기 상의 1번키와 2번키를 누르면 화면이 서로 전환되게 작

성되었는데, 키 이벤트를 처리하기 위해 투명한 Card를 마

지막에 최상위 Layer로 설정하 다. 표 1. Component의 정렬 조합 상수표

구분

왼쪽 방향

오른쪽 방향

중앙 방향

위쪽 방향

아래쪽 방향

중앙 방향

수형 방향 상수

LAYOUT_LEFT

LAYOUT_RIGHT

LAYOUT_HCENTER

수직 방향 상수

LAYOUT_TOP

LAYOUT_BOTTOM

LAYOUT_VCENTER

예외 상황 조합

LAYOUT_LEFT│LAYOUT_RIGHT

LAYOUT_LEFT│LAYOUT_HCENTER

LAYOUT_RIGHT│LAYOUT_HCENTER

LAYOUT_TOP│LAYOUT_BOTTOM

LAYOUT_TOP│LAYOUT_VCENTER

LAYOUT_BOTTOM│LAYOUT_VCENTER

107Embedded World

코드 1. ShellComponent를 이용한 간단한 예제

/*★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

ShellCompoent를 이용한 GUI Programming

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

*/

import org.kwis.msp.lcdui.*;

import org.kwis.msp.lwc.*;

public class ShellComTest extends Jlet {

EventQueue eq;

Display bigLcd;

ShellComponent sc;

ShellComponent sc2;

Box box;

LabelComponent titleCom1, titleCom2;

public ShellComTest()

{

dataInit();

}

public void dataInit()

{

eq = getEventQueue();

bigLcd = Display.getDefaultDisplay();

box = new Box(this);

titleCom1 = new LabelComponent(“첫번째 화면”, “/icon/4.png”);

titleCom2 = new LabelComponent(“두번째 화면”, “/icon/5.png”);

}

public void startApp(String args [])

{

firstScreen();

bigLcd.pushCard(box);

}

public void resumeApp(){}

public void pauseApp(){}

public void destroyApp(boolean b){}

public void firstScreen()

{

if(sc == null && sc2 == null)

{

sc = new ShellComponent(false); -------------------------- ①

sc2 = new ShellComponent(10, 30,100, 80, true);

sc.show(); //----------------------- ②

sc2.show();

}

sc.setTitle(“첫번재 화면”); //------------------------------ ③

sc.setBackground(0x0003ff00); ---------------------------- ④

sc2.setTitle(titleCom2); //-------------------------- ⑤

sc2.setBackground(0x0004DAFA);

displayInfo(sc);

displayInfo(sc2);

}

public void secondScreen()

{

108

TECHNICAL FEATURE

DialogComponent

다양한 형태의 다이얼로그 박스를 지원하기 위해서 만들

어진 컴포넌트이다. 즉, 사용자에게 화창을 제공해 주는

Component이다. 기본적으로 DialogComponent는 타이

틀 역과 데이터 역, 버튼 역으로 구성되어 있다.

▶타이틀 역: 다이얼로그 박스의 타이틀이 존재하는 경

우 타이틀을 출력해 주는 역

▶데이터 역: 사용자에 의해서 추가된 여러 형태의 컴포

넌트를 출력해 주는 역. 오직 한 개의 Component만

을 추가시킬 수 있다. 만약 여러 개의 Component를

DialogComponent 데이터 역에 추가하고 싶다면,

ContainerComponent를 이용하여 추가시킨다. 마치

Java의 AWT의 Panel Object 위에 다양한

Component를 추가하여 올리듯이 사용한다. WIPI에서

는 주로 FormComponent를 사용한다.

▶버튼 역: 각 타입에 따라 사용되는 버튼을 출력해 주

는 역. 기본적으로 3개의 타입을 지원한다.

- TYPE_OK: 확인기능을 제공

- TYPE_OK_CANCEL: 확인과 취소기능을 제공

- TYPE_NONE: 일정 시간동안 화면에 데이터를 출력해

주는 기능을 제공

다음코드 2는 DialogComponent의 예제이다.

코드 1. ShellComponent를 이용한 간단한 예제

sc.setTitle(titleCom1);

sc.setBackground(0x0004DAFA);

sc2.setTitle(“두번재 화면”);

sc2.setBackground(0x0003ff00);

}

public void displayInfo(ShellComponent sh)

{

System.out.println(“X 좌표 : “+sh.getX()+”Y 좌표 : “+sh.getY());

if(sh.isShown())

{

System.out.println(“ShellComponent 정보 : \n”+sh.toString());

}

}

class Box extends Card{

ShellComTest jlet;

public Box(ShellComTest jlet){

super(true);

this.jlet = jlet;

}

public void paint(Graphics g){}

public boolean keyNotify(int type, int chr)

{

if(type == jlet.eq.KEY_PRESSED)

{

int action = jlet.bigLcd.getGameAction(chr);

if(chr == jlet.eq.KEY_NUM1)

jlet.firstScreen();

else if(chr == jlet.eq.KEY_NUM2)

jlet.secondScreen();

return true;

}

return false;

}

}

}

109Embedded World

그림 2. 코드 1 수행 화면 그림 3. 코드 1 수행 후 2번키를 누른 후 화면

코드 2. DialogComponent를 이용한 간단한 예제

/*★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

DialogComponent의 다양한 모습을 테스트한 GUI Programming

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

*/

import org.kwis.msp.lcdui.*;

import org.kwis.msp.lwc.*;

public class DialogComTest extends Jlet {

public void startApp(String args [])

{

ShellComponent sc = new ShellComponent();

sc.setTitle(new LabelComponent(“ 다이얼로그 테스트”));

sc.show();

DialogComponent dc = new DialogComponent(DialogComponent.TYPE_OK); --- ①

if(dc.doModal() == dc.DLG_OK) ---------------- ②

System.out.println(“버튼 역 : OK형 다이얼로그”);

sc.repaint(); ---------------- ③

DialogComponent dc2 = new DialogComponent(DialogComponent.TYPE_OK_CANCEL); --------- ④

if(dc2.doModal() == dc2.DLG_CANCEL || dc2.doModal() == dc2.DLG_OK)

System.out.println(“버튼 역 : OK_CANCEL 다이얼로그”);

sc.repaint();

DialogComponent dc3 = new DialogComponent(DialogComponent.TYPE_NONE); --------- ⑤

if(dc3.doModal() == dc3.DLG_TIMEOUT)

System.out.println(“버튼 역 : TIMEOUT 다이얼로그”);

sc.repaint();

DialogComponent dc4 = new DialogComponent(null,”OK형”,DialogComponent.TYPE_OK); ⑥

if(dc4.doModal() == dc4.DLG_OK)

110

TECHNICAL FEATURE

코드 2. DialogComponent를 이용한 간단한 예제

System.out.println(“타이틀, 버튼 역 : OK형 다이얼로그”);

sc.repaint();

DialogComponent dc5 = new DialogComponent(new LabelComponent(“레이블이 붙었네”),

“컴퍼넌트 붙은형”, DialogComponent.TYPE_OK_CANCEL); ------- ⑦

if(dc5.doModal() == dc5.DLG_CANCEL)

System.out.println(“타이틀, 테이터, 버튼 역 : OK_CANCEL 다이얼로그”);

sc.repaint();

DialogComponent dc6 = new DialogComponent(new TextFieldComponent(“전화번호”,

TextFieldComponent.CONSTRAINT_ANY), “타이머형에다 텍스트필드를 추가했다”,

DialogComponent.TYPE_NONE);

dc6.setTimeout(5000);---------- ⑧

if(dc6.doModal() == dc6.DLG_TIMEOUT)

System.out.println(“타이틀, 테이터, 버튼 역 : TIMEOUT 다이얼로그”);

sc.repaint();

DialogComponent dc7 = new DialogComponent(new LabelComponent(“가장 완성적인것”), “

타이틀명이다.”, DialogComponent.TYPE_OK_CANCEL, 30, 30, 80, 80); --------- ⑨

dc7.setButtonString(dc7.OK_BUTTON,”확인”); --------- ⑩

dc7.setButtonString(dc7.CANCEL_BUTTON,”캔슬”);

if(dc7.doModal() == dc7.DLG_CANCEL || dc7.doModal() == dc7.DLG_OK)

{

int key = dc7.getActionState();

if(key == dc7.DLG_OK)

{

System.out.println(“확인을 눌 다”);

}

else if(key == dc7.DLG_CANCEL)

{

System.out.println(“캔슬을 눌 다”);

}

}

sc.repaint();

FormComponent fc = new FormComponent();

DialogComponent dlg = new DialogComponent(fc, “폼에 올리기”

,DialogComponent.TYPE_OK_CANCEL);

TextFieldComponent tf = new TextFieldComponent(“폼을 이용해 다르게 구성”,

TextFieldComponent.CONSTRAINT_ANY);

fc.addComponent(new LabelComponent(“다양하게 구성하기”)); ------- ⑪

fc.addComponent(tf);

(dlg.doModal() == dlg.DLG_OK){

System.out.println(“멀티 레이터, 입력값 : “ + tf.getString());

}

}

public void pauseApp(){}

public void resumeApp(){}

public void destroyApp(boolean b){}

}

그림 4에서 그림 11까지는 코드 2를 실행했을 시 보여지

는 8개의 DialogComponent를 결과로 보여주고 있다.

①번 부분을 보면 가장 기본적인 OK형 DialogComponent

Object를 만들고 있다. ①번 자체로는 화면상에 다이얼로그

창이 보이지 않는다. ②번 부분에 doModal()를 수행해야만,

화면상에 보이게 된다. ③번에서 ShellComponent를

repaint()함으로써 다음 다이얼로그 창을 그려낼 수 있다. 그

림 4는 첫 번째 OK형 다이얼로그 컴포넌트를 보여주고 있다.

그림 5는 OK_CANCEL형 다이얼로그 컴포넌트를 보여준다.

코드로는 ④번 라인이 해당된다. 그림 6은 ⑤번 라인에 해당

111Embedded World

그림 4. OK 버튼형 그림 5. OK_CANCEL 버튼형

그림 6. TIMEOUT 버튼형 그림 7. 타이틀, OK 버튼형

그림 8. 타이틀, 데이터, OK_CANCEL 버튼형 그림 9. 타이틀, 데이터, TIMEOU 버튼형

112

TECHNICAL FEATURE

되는 부분으로써, 기본적으로 버튼이 없고, 별도의 설정이

없으면 3초 후에 다이얼로그 창이 닫힌다. 그림 7은 ⑥번 부

분이 수행된 것으로 단순하게, 제목이 붙은 경우이다. 그림

8은 ⑦번이 수행된 결과이다. 기본적으로 타이틀과 데이터,

버튼이 모두 포함된 다이얼로그 컴포넌트이다. 그림 9번은

다이얼로그의 3가지 역이 모두 포함된 경우인데, 버튼이

다만 TIMEOUT형이어서 버튼이 없는 것이다. ⑧번에 보이

듯이 종료 시간을 지정할 수도 있다. 그림 10을 보면 다이얼

로그의 위치가 조금 다르다는 것을 알 수 있다. 그것은 ⑨번

에서 보듯이 좌표와 크기를 지정해서 다이얼로그를 만들었

기 때문이다. 또한 ⑩번을 보면 버튼의 레이블을 변경한 것

을 볼 수 있다. 그림 11은 데이터 부분에 FormComponent

를 사용하여 멀티 레이어를 구현한 방식이다. FormCom-

ponent는 ContainerComponent를 상속받음으로 해서 다

른 컴포넌트들을 여러 개 포함할 수 있다.

TickerComponent

문자열과 이미지로 구성되어 우측에서 좌측으로 움직이는

컴포넌트이다. 좌측으로 이동하여 문자열의 끝이 좌측으로

사라지면 다시 문자열의 처음부터 우측에서 보여지게 되어

동일한 방향으로 이동을 계속한다. TickerComponent의

넓이 값은 TickerComponent를 추가한 Container Com-

ponent의 넓이 값과 같다. 높이는 이미지가 문자의 한 줄

높이보다 작은 경우 한 줄 높이 값을 가지며, 이미지의 높이

가 더 큰 경우 이미지 높이 값을 가지게 된다. 즉, 어떤 크기

의 데이터를 포함시켰는가에 따라 크기가 달라진다. 움직이

는 속도는 milleseconds 단위로 setDelay(int) 메서드를 사

용하여 변경할 수 있다. 기본으로 설정된 값은 DEFAULT

_DELAY이다. TickerComponent에서는 움직임을 제어할

수 있는 기능을 제공하는데, 움직임 상태는 setTicker

State(boolean) 메서드를 사용하여 제어할 수 있다. true

값이 지정되면 움직이고, false 값이 지정되면 움직임을 멈

추게 된다.

ButtonComponent

버튼 컴포넌트는 "select" 키가 눌렸다 떼어졌을 때 자신

에게 등록된 ActionListener를 호출한다. 이때 등록된

ActionListener에서 구현된 action() 메서드에 의해 이벤

트가 처리된다. 버튼은 문자열과 이미지 두 개로 구성된다.

ActoinListener는 오직 ButtonComponent와 List-

Component에만 등록될 수 있다.

코드 3을 수행하면그림 12와 같은 결과 화면을 볼 수 있

다. ①번은 ButtonComponent를 생성하는 부분이다. 문자

열과 이미지를 포함시켜서 버튼을 컴포넌트를 만들 수 있

다. 이 버튼 컴포넌트에 발생되는 이벤트를 감지하기 위해

②번처럼 ActionListener를 등록하 다. 또한, ⑥번에서

이벤트를 처리하게 하여서, ⑦번과 같이 두 개의 Ticker 컴

포넌트가 번갈아 가면서 작동되게 하 다. ③번을 보면

TickerComponent를 생성하는 부분이다. 문자열과 이미지

를 포함할 수 있다. ④번을 보면 티커 컴포넌트의 속도를 지

정할 수 있다. ⑤번은 FormComponent에 해당 컴포넌트

들을 추가시키는 부분이다. 앞에서 설명했듯이 다른 여러

컴포넌트들을 추가시킬 수 있는 컴포넌트이다.

그림 10. 그림 8번에 좌표, 크기 지정 그림 11. 데이터 역을 다중 레이어 적용

113Embedded World

코드 3. TickerComponent를 이용한 간단한 예제

/*★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

TickerComponent를 이용한 GUI Programming★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

*/import org.kwis.msp.lcdui.*;import org.kwis.msp.lwc.*;

public class TickerComTest extends Jlet implements ActionListener{Image img, startIm, stopIm;ButtonComponent start, stop;TickerComponent tc, tc2;public TickerComTest(){

try{

img = Image.createImage(“/icon/char.bmp”);startIm = Image.createImage(“/icon/1.png”);stopIm = Image.createImage(“/icon/2.png”);

}catch(Exception e){}start = new ButtonComponent(“시작”, startIm); -------- ①stop = new ButtonComponent(“스톱”, stopIm);start.setActionListener(this, null); ------------- ②stop.setActionListener(this, null);

}public void startApp(String args []){

ShellComponent sc = new ShellComponent();FormComponent fc = new FormComponent();tc = new TickerComponent(“티커 테스트1...”,img); --------- ③tc2 = new TickerComponent(“티커 테스트2...”,img);tc.setDelay(50); -------------------------- ④fc.addComponent(tc); ------------ ⑤fc.addComponent(tc2);fc.addComponent(start);fc.addComponent(stop);sc.addComponent(fc);sc.show();

}public void action(Component cmp, Object o) ------------ ⑥{

if(cmp == start){

tc.setTickerState(true); ----------- ⑦tc2.setTickerState(false);

}else if(cmp == stop){

tc.setTickerState(false);tc2.setTickerState(true);

}}public void pauseApo(){}public void destroyApp(){}public void destroyApp(boolean b){}

}

114

TECHNICAL FEATURE

ProgressComponent

ProgressComponent는 진행 상태 등을 나타내기 위해

사용하는 콤포넌트이다. Interactive(상호작용), None-

Interactive(상호 불작용) 두 가지 모드가 있으며 객체 생성

시에 결정한다. Interactive의 경우 사용자의 키 입력을 받

아 setStep에서 정의된 값만큼 증가 혹은 감소하게 된다.

NoneInteractive 모드에서는 사용자의 입력은 받지 않으

며 setValue에 의해 값이 변경된다.

코드 4를 수행한 결과는그림 13에서 보는 것과 같다. ①그림 12. TickerComponent 테스트

코드 4. ProgressComponent를 이용한 간단한 예제

/*★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

ProgressComponent를 이용한 GUI Programming

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

*/

import org.kwis.msp.lcdui.*;

import org.kwis.msp.lwc.*;

public class ProgressComTest extends Jlet{

public void startApp(String args [])

{

ShellComponent sc = new ShellComponent();

FormComponent fc = new FormComponent();

ProgressComponent pc = new ProgressComponent(true, 10); --- ①

ProgressComponent pc1 = new ProgressComponent(false, 100); -- ②

pc1.setMargin(20, 10); ------------ ③

fc.addComponent(new LabelComponent(“상호작용 OK!!”));

fc.addComponent(pc);

fc.addComponent(new LabelComponent(“상호작용 NO!!”));

fc.addComponent(pc1);

sc.addComponent(fc);

sc.show();

for(int i=0; i<=100; i++){

try{

Thread.sleep(50);

}catch(Exception e ){}

pc1.setValue(i); ----------- ④

sc.repaint();

sc.serviceRepaints() ;

}

}

public void destroyApp(boolean b){}

}

번은 상호작용성 ProgressComponent이고, ②번은 상호

작용성이 없는 ProgressComponent이다. 즉, ①번으로 생

성된 컴포넌트는 사용자의 키 이벤트에 의해 값이 조절된

다. 하지만, ②번의 경우는 프로그램에 의해 ④번 경우처럼

값이 설정되어야 값이 증가, 감소된다. ③번은 컴포넌트의

상하 여백을 설정한다.

DateFieldComponent

DateFieldComponent는 날짜와 시간을 보여주는 필드

를 화면에 표시해 주고, 이 값을 수정할 수 있는 컴포넌트이

다. DateFieldComponent를 생성할 때 지정한 모드에 관

계없이 시스템에 설정된 기본 TimeZone과 Date를 사용하

여 현재 시간과 날짜로 초기화된 데이터를 갖게 된다.

코드 5를 수행하면 그림 14처럼 시간을 설정하고 편집할

수 있는 화면을 볼 수 있을 것이다. 시간이나 날짜는 내부적

으로 long 타임의 값으로 관리된다. 일반적으로 그냥 봤을

땐 그 값이 무슨 년도에 어떤 월, 일, 시, 분, 초인지 전혀 알

수가 없다. 그래서, Date나 Calender라는 객체를 이용해서

시간을 관리하는데, 이 DateFieldComponent 컴포넌트는

그 작업을 비주얼하게 처리할 수 있다. 손쉽게 시간을 설정

하고 그 시간을 가지고 있는 Date 객체를 얻어 낼 수 있는

것이다. 그림 15는 포커스가 [TIME]에 설정되어 있을 때,

115Embedded World

그림 13. ProgressComponent 테스트

코드 5. DateFieldComponent를 이용한 간단한 예제

/*★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

DateFieldComponent를 이용한 GUI Programming

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

*/

import org.kwis.msp.lcdui.*;

import org.kwis.msp.lwc.*;

public class DateFieldComTest extends Jlet{

public void startApp(String args [])

{

ShellComponent sc = new ShellComponent();

FormComponent fc = new FormComponent();

DateFieldComponent dfc = new DateFieldComponent(DateFieldComponent.MODE_TIME);

DateFieldComponent dfc1 = new DateFieldComponent(DateFieldComponent.MODE_DATE);

DateFieldComponent dfc2 = new DateFieldComponent(DateFieldComponent.MODE_TIME_DATE);

fc.addComponent(dfc);

fc.addComponent(dfc1);

fc.addComponent(dfc2);

sc.addComponent(fc);

sc.show();

System.out.println(“시간값 : “+dfc2.getStringValue(DateFieldComponent.MODE_TIME_DATE));

}

public void destroyApp(boolean b){}

}

116

TECHNICAL FEATURE

SELECT 키를 누를 때, 나타나는 화면이다. 그림 16은 포

커서가 [DATE] 일 때, SELECT를 키를 누를 때, 나타나는

화면이다.

ListComponent

ListComponent는 FormComponent를 상속하여 구현

된 클래스이다. 이 컴포넌트는 오직 ListItemComponent

만을 추가할 수 있다. 또한 그 순서에 따라 각 아이템들이

화면에 출력된다. ListItemComponent는 3가지 타입이 있

다. 현재 포커스를 받고 있는 아이템이 선택된 상태와 같게

되는 타입인 SELECT_IMPLICIT, 여러 아이템을 선택할

수 있는 SELECT_MULTIPLE, 한 아이템만 선택할 수 있

는 SELECT_EXCLUSIVE이다.

이때 SELECT_MULTIPLE, SELECT_EXCLUSIVE

의 경우에는 포커스를 가지는 아이템과 선택된 아이템이

반드시 일치하지는 않는다. 다음과 같은 이벤트를 감지할

수 있다.

▶ ActionListener: SELECT 키 입력에 의해서 선택, 번

호에 해당 위치에 한 숫자키 입력을 받은 경우

▶ ChangeListener: 방향키 입력에 의해 선택된 아이템

이 변경된 경우

코드 6은 ListComponent을 테스트하는 예제이다. 그림

17에서 상단에 라디오 버튼 리스트를 살펴보면, 두 개의 아

이템 중 하나를 선택하게 되어 있다. 기본적으로 두 번째 항

목에 선택되어 있는데, 이는 ③번 코드에 의해 설정된 것이

다. ②번은 ListComponent에 포함되는 ListItemCompo-

nent이다. 이는 이미지와 문자열을 포함한다. 그림 17 중간

에 있는 포커스 리스트는 코드 상에 ④번에 의해 생성된 객

체를 의미한다. 즉, 포커스에 의해 아이템을 선택할 수 있는

리스트이다. ⑤번 설정에 의해 포커스 리스트라는 부분은

그림 14. DateFieldComponent 테스트

그림 16. 날짜 설정 화면

그림 15. 시간 설정 화면

그림 17. ListComponent 실행 화면 1

117Embedded World

코드 6. ListComponent 테스트 예제

/*★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

ListComponent를 이용한 GUI Programming

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

*/

import org.kwis.msp.lcdui.*;

import org.kwis.msp.lwc.*;

public class ListComTest extends Jlet implements ActionListener, ChangeListener{

Image startIm, stopIm;

ListComponent lc, lc2, lc3;

ListItemComponent item3, item4;

public ListComTest()

{

try{

startIm = Image.createImage(“/icon/1.png”);

stopIm = Image.createImage(“/icon/2.png”);

}catch(Exception e){}

}

public void startApp(String args [])

{

ShellComponent sc = new ShellComponent();

FormComponent fc = new FormComponent();

lc = new ListComponent(ListComponent.SELECT_EXCLUSIVE); -- ①

ListItemComponent item = new ListItemComponent(“첫번째”, startIm); --------- ②

ListItemComponent item2 = new ListItemComponent(“두번째”, stopIm);

item2.setState(true); -------------- ③

lc.addComponent(item);

lc.addComponent(item2);

lc.setActionListener(this, null);

fc.addComponent(new LabelComponent(“라디오 버튼 리스트”));

fc.addComponent(lc);

lc2 = new ListComponent(ListComponent.SELECT_IMPLICIT); --- ④

item3 = new ListItemComponent(“세번째”, startIm);

item4 = new ListItemComponent(“네번째”, stopIm);

item4.setState(true);

lc2.controlNumber(false); ---------- ⑤

lc2.addComponent(item3);

lc2.addComponent(item4);

lc2.setChangeListener(this, null);

fc.addComponent(new LabelComponent(“포커스 리스트”));

fc.addComponent(lc2);

lc3 = new ListComponent(ListComponent.SELECT_MULTIPLE); -- ⑥

ListItemComponent item5 = new ListItemComponent(“다섯번째”, startIm);

ListItemComponent item6 = new ListItemComponent(“여섯번째”, stopIm);

lc3.select(item6); --------- ⑦

lc3.controlNumber(false);

lc3.addComponent(item5);

lc3.addComponent(item6);

lc3.setChangeListener(this, null);

fc.addComponent(new LabelComponent(“멀티 선택 리스트”));

118

TECHNICAL FEATURE

아이템 앞에 번호가 없다. ⑥번은 여러 개의 아이템을 선택

할 수 있는 리스트로 사용자는 여러 개의 아이템을 선택할

수 있다. ⑦번은 기본적으로 선택되는 아이템을 지정하는

부분이다.

CheckboxGroup

CheckboxGroup은 여러 개의 CheckboxComponent들

을 엮어 그룹 된 라디오 버튼처럼 움직이게 할 수 있다. 만

약, 단독으로 CheckboxComponent를 FormComponent

에 추가시킨다면, 이는 체크 박스와 같은 여러 개의 아이템

을 선택할 수 있는 리스트로 설정된다.

①번을 살펴보면 CheckboxComponent를 이용하여 아

이템을 직접 생성하고 있다. 그리고, CheckboxGroup에

소속시킴으로 해서 그림 19와 같은 라디오 버튼 리스트를

만들었다. 그러나, CheckbpxGroup에 포함시키지 않는 경

우에는 그림 19에 중간에서 보듯이 체크 박스 형식으로 설

정된다. 리스트를 구성하는 또 다른 방법이다.

ComboComponent

ComboComponent는 팝업 메뉴 기능을 제공한다.

코드 6. ListComponent 테스트 예제

fc.addComponent(lc3);

sc.addComponent(fc);

sc.show();

}

public void destroyApp(boolean b){}

public void action(Component cmp, Object o)

{

if((ListComponent)cmp == lc)

System.out.println(lc.getString(lc.getSelectedIndex()));

}

public void changed(Component cmp, Object o)

{

if((ListItemComponent)cmp == item3)

System.out.println(lc2.getString(lc2.getSelectedIndex()));

else if((ListItemComponent)cmp == item4)

System.out.println(lc2.getString(lc2.getSelectedIndex()));

}

}

그림 18. ListComponent 실행 화면 2 그림 19. CheckboxGroup 실행 결과

ComboComponent는 팝업 메뉴 항목 중 선택된 항목을 보

여주는 역과 팝업 메뉴의 리스트를 보여주는 역으로 나

뉘어져 있다.

선택항목을 보여주는 화면에서 SELECT키 입력 시 팝업

메뉴 리스트가 보여지며, 이 중 어떤 항목을 선택하면 팝업

메뉴 리스트는 화면에서 제거되고 새로운 선택 항목만이 보

여지게 된다. ComboComponent에서는 선택항목의 변경

을 감시할 수 있는 ChangeListener를 등록하여 사용할 수

있다. 팝업 메뉴에서 새로운 항목을 선택 시 Change

Listener의 changed 메서드를 호출하여서 이벤트를 처리

하게 된다.

그림 20은 코드 8이 수행된 결과 화면이다. ①번은

ComboComponent 객체를 생성하는 부분이다. 이 컴포넌

트는 해당 이벤트를 ChangeListener가 감지하고,

changed()가 처리한다. ②번에서 보듯이 ChangeListener

를 등록할 때 두 번째 인자 값으로 객체를 설정할 수 있는

데, 여기서는 Data라는 객체를 설정하 고, 이를 통해 이벤

트 발생시 유용하게 ⑥번처럼 사용할 수 있다 ③번은

ComboComponent에 해당 문자열을 설정한 것이다. ④번

은 최초 ComboComponent가 화면에 나타날 때 선택되어

질 메뉴를 설정한다. ⑤번은 사용자가 특정 메뉴를 선택하

여 그림 21번처럼 화면상에 나타날 때, 선택한 항목의 인덱

스를 얻어온다.

CommandBarComponent

Command 컴포넌트들을 등록된 하나 이상의 커맨드를

바 형태로 구성한다. 화면에 현재 화면에 사용자가 내릴 수

있는 명령어를 보여주며, 사용자로부터 명령을 선택받는다.

이 컴포넌트를 이용하면 KTF의 멀티팩 서비스의 기본 관리

자 프로그램과 동일한 형태의 UI를 얻어 낼 수 있다.

119Embedded World

코드 7. CheckboxGroup 테스트 예제

/*★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

CheckboxGroup를 이용한 GUI Programming

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

*/

import org.kwis.msp.lcdui.*;

import org.kwis.msp.lwc.*;

public class CheckboxGroupTest extends Jlet{

public void startApp(String args []){

ShellComponent sc = new ShellComponent();

FormComponent fc = new FormComponent();

CheckboxGroup cbg = new CheckboxGroup();

CheckboxComponent cbc = new CheckboxComponent(“첫번째”, null, cbg); --------- ①

CheckboxComponent cbc2 = new CheckboxComponent(“두번째”, null, cbg);

CheckboxComponent cbc3 = new CheckboxComponent(“세번째”, null);

CheckboxComponent cbc4 = new CheckboxComponent(“네번째”, null);

fc.addComponent(new LabelComponent(“라디오 버튼 리스트”));

fc.addComponent(cbc);

fc.addComponent(cbc2);

fc.addComponent(new LabelComponent(“체크 박스 리스트”));

fc.addComponent(cbc3);

fc.addComponent(cbc4);

cbg.select(cbc2); ----------- ②

sc.addComponent(fc);

sc.show();

}

public void destroyApp(boolean b){}

}

120

TECHNICAL FEATURE

코드 8. ComboComponent 테스트 예제

/*★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

ComboComponent를 이용한 GUI Programming★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

*/import org.kwis.msp.lcdui.*;import org.kwis.msp.lwc.*;public class PopUp extends Jlet implements ChangeListener{

ShellComponent sc;FormComponent fc;ComboComponent cc, cc2;Data data = new Data();public void startApp(String args []){

sc = new ShellComponent(10,10,100,100);fc = new FormComponent();cc = new ComboComponent(); ----------- ①cc.setChangeListener(this, data); ---------- ②cc.append(data.item); --------------- ③cc.append(data.item1);cc.append(data.item2);cc.append(data.item3);cc.select(3); ------------ ④fc.addComponent(cc);sc.setTitle(“팜업 윈도우”);sc.addComponent(fc);sc.show();

}public void destroyApp(boolean b){}public void changed(Component cmp, Object o){

Data da = (Data)o;ComboComponent cbc = (ComboComponent)cmp;int num = cbc.getSelectedIndex(); ---------- ⑤String s = cbc.getString();if(s.equals(da.item)) ----------- ⑥

System.out.println(“새파일 선택”);else if(s.equals(da.item1))

System.out.println(“추가 선택”);else if(s.equals(da.item2))

System.out.println(“삭제 선택”);else if(s.equals(da.item3))

System.out.println(“종료 선택”);if(num == 0)

System.out.println(“새파일 선택”);else if(num == 1)

System.out.println(“추가 선택”);else if(num == 2)

System.out.println(“삭제 선택”);else if(num == 3)

System.out.println(“종료 선택”);

}class Data {

String item = “새파일”;String item1 = “추가”;String item2 = “삭제”;String item3 = “종료”;

}}

121Embedded World

그림 20. 선택항목 보여주는 화면 그림 21. 팝업 메뉴 리스트를 보여주는 항목

/*★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

CommandBarComponent를 이용한 GUI Programming

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

*/

import org.kwis.msp.lcdui.*;

import org.kwis.msp.lwc.*;

public class CommandBarComTest extends Jlet implements CommandListener, ImageObserver{

Image icon [] = new Image[8];

Command com [] = new Command[8];

String str [] = {

“ITKOREA”, “오렌지로드”,”포토앨범”,”바람의검심”,”안양경실련”,”GTO”,”WIPI PRO”,”JLET”};

String action [] ={“A”,”B”,”C”,”D”,”E”,”F”,”G”,”H”};

String s= “임시액션”;

CommandBarComponent cbc;

ImageComponent ic;

Image back = Image.createImage(128,93); -------- ①

Graphics g = back.getGraphics();

Image screenShot;

public CommandBarComTest()

{

cbc = new CommandBarComponent();

cbc.setCommandListener(this, s);

try

{

for(int i=0; i<8; I++)

{

icon[i] = Image.createImage(“/icon/”+(i+1)+”.png”);

코드 9. CommandBarComponent 테스트 예제

122

TECHNICAL FEATURE

코드 9. CommandBarComponent 테스트 예제

com[i] = new Command(str[i], icon[i], icon[7],action[i]); ------ ②

cbc.addCommand(com[i]); -------- ③

}

screenShot = Image.createImage(“/icon/ani.gif”);

}catch(Exception e){}

g.drawImage(screenShot, 0, 0, g.TOP|g.LEFT);

}

public void startApp(String args [])

{

ShellComponent sh = new ShellComponent();

FormComponent fc = new FormComponent();

ic = new ImageComponent(back); ---------- ④

sh.addComponent(fc);

fc.addComponent(new LabelComponent(“커맨트 사용 메뉴”));

fc.addComponent(ic);

fc.addComponent(cbc);

sh.show();

screenShot.play(this); -------- ⑤

}

public void commandAction(Command c, int type, Object obj)

{

if(c == com[0])

System.out.println(“ITKOREA!!”);

if(type == FOCUS_CHANGE)

System.out.println(“포커스 변경”);

screenShot.stop();

screenShot.play(this);

System.gc();

else

System.out.println(“선택”);

if((String)obj == action[0]) --------- ⑥

System.out.println(“A -> ITKOREA를 선택했네요..”);

}

public void destroyApp(boolean b){}

public void notify(Image img, int status) -------- ⑦

{

g.drawImage(screenShot, 0, 0, g.TOP|g.LEFT);

ic.repaint(); ------------ ⑧

}

}

Command

사용자가 내릴 수 있는 명령을 지시하는 클래스이다. 사용

자가 UI 컴포넌트 상에서 사용하고자 하는 커맨드를 정의한

다. 커맨드는 문자열과 이미지로 표현하며 CommandBar

Component에 에 등록하여 사용한다. 이미지의 크기는 20

×20 Pixel이어야 한다.

그림 22는 코드 9를 수행한 화면이다. 현재 화면에서는

느낄 수 없겠지만, 실제 상단부에 존재하는 이미지는 GIF

Animation 파일로 현재 애니메이션이 진행 중에 있다. 이

전의 MIDlet에서는 png 파일만을 지원하고 있고, SK-VM

에서만 자체 포맷인 LBM을 사용했었다. 물론, 국내에서 캐

릭터, 포토 등 모든 핸드폰 기반 애니메이션 분야에서 독점

적인 체계를 구축하고 있는 네오엠텔사의 SIS가 모든 VM

플랫폼 및 바이너리 진 에서 OEM 방식으로 지원되고 있

다. 그 중 SIS를 가장 잘 지원하는 API를 보유한 플랫폼은

SK-VM이다. WIPI에서는 PNG 뿐만 아니라, brew에서

지원하듯이 BMP도 지원하고, 유일하게 GIF Animation도

지원한다. 물론, 실제 서비스가 진행되면 GIF는 라이선스

문제 때문에 아마도 png나 bmp, 그리고 SIS의 지원을 조

심스레 점쳐본다. 코드 9에서는 애니메이션의 구현을 위해

①번에 보듯이 ImagekBuffer를 생성하여 이 위에 GIF를

그렸다. 그리고 ④번에 보듯이 ImageComponent를 생성

하면서 이미지 버퍼를 추가시켰다. ②번에서는 Command

를 객체를 생성하는 부분으로써, 스트링과 아이콘 형태의

이미지를 포함시켰다. 마지막 인자는 Command 생성 시

Object를 추가시키고 있는데, 여기서는 ⑥번에서 보듯이 이

벤트 처리 시에 사용하 다. 이것 뿐만 아니라, Command

를 통해 데이터를 전달하는 의미로 유용하게 사용할 수 있

다. ③번은 CommandComponent 위에 Command를 추

가시키는 부분이다. 여기서 사용하는 GIF는 애니메이션 포

맷이므로 분명 애니메이션을 진행시켜야 할 것이다. 이 부

분을 구현한 부분이 ⑤번 부분이다. 이미지의 움직임을 시

작한다.

Animation이 진행되는 동안 ImageObserver에

animation 진행 상황을 ImageObserver의 notify()함수

를 호출함으로써 알려준다. 오직 Animation인 파일에만

향을 미친다. 매번 새로운 프레임을 만들 때마다 gif 파일을

decode하기 때문에 이 함수는 상당히 많은 연산시간을 요

구한다. 또한 animation 이미지를 위해서 내부에 이미지

원본 내용을 그 로 저장하고 있기 때문에 메모리를 상당히

소모한다. 이 함수를 호출하고 나서 stop 함수를 꼭 호출해

야 한다. ⑦번은 Animation 진행 사항을 ImageObserver

에게 알려 주는 기능을 담당한다. ⑧번에 repaint() 메서드

를 이용하여 화면을 갱신하게 된다.

이번 달에는 UI Component에 해 알아보았다. 이외에

도 다루지 않는 UI Component Class들이 있다. 이 Class

들은 독자들이 직접 API Docs 파일을 살펴보면서 충분히

프로그램화 할 수 있을 것이다.

123Embedded World

그림 22. 아이콘 기반 리스트 화면

124

PRODUCT FEATURE

텐실리카(Tensilica)사의 Xtensa 프

로세서는 기존의 다른 임베디드 프로세

서 코어와 크게 다르다. 이 프로세서는

기존의 SoC 설계 방법을 완전히 바꾸어

놓았다. Xtensa 기술을 사용하여 시스

템 설계자는 미리 정의된 설계 요소들

을 선택/설정할 수 있고, 기존의 다른

제품에 비해 월등히 빠른 속도로 기능

수행할 수 있도록 새로 고안된 명령어

들과 하드웨어 실행 유닛을 사용함으로

써 응용 프로그램에 최적화된 프로세서

를 제작할 수 있다. Xtensa 프로세서

생성기는 또한 각 프로세서 설정에

해 운 체제 지원을 포함한 최적의 소

프트웨어 환경을 자동적으로 만든다.

SoC 디자인은 보다 향상된 성능과

적은 비용, 작은 크기의 메인보드, 적

은 전력소모를 통한 긴 배터리 수명 등

을 가능케 한다. 그러나 이 같은 설계

는 종종 블록간의 통합과 설계 검증,

하드웨어/소프트웨어 일체 개발 및 반

도체의 호환 등에 있어 해결하기 어려

운 심각한 문제를 야기하기도 한다. 종

래 임베디드 SoC 설계자들은 워크스

테이션급 아키텍처에나 사용되는 자체

설정이 불가능한 프로세서 코어를 가

지고 솔루션을 개발할 수밖에 없었다.

이에 비해, Xtensa는 다른 시스템 블

록들과 빠르게 연동되고 오늘날 요구

되는 용량, 고성능 임베디드 응용 프

기능 설정이 가능한 프로세서 코어텐실리카- Xtensa

Xtensa 프로세서는 자체 기능 설정 및 확장, 회로 합성이 가능한 프로세서 코어로서 임베디드 시스템온칩(SoC)에 적용하려는 응용 프로그램을

위해 설계된 마이크로프로세서 아키텍처이다. Xtensa 프로세서는 처음부터 기능 설정이 가능하도록 창안되었기 때문에 설계자들이 직접 적당

한 작업을 해서 목표 SoC에 맞게 응용 프로그램을 설계할 수 있도록 되어 있는 것이 특징이다.

: (주)에찌소프트/www.edgesoft.co.kr

그림 1. Xtensa 아키텍처는 여러 가지 기능 설정이 가능한 블록들로 구성되어 있다. CONFIGURABLE FUNCTION

블록들은 시스템 설계자가 파라미터 값을 줄 수 있는 부분들이다. OPTIONAL FUNCTION 블록들은 특정 응용 프로

그램들의 기능 가속화를 위한 부분이며, OPTIONAL AND CONFIGURABLE 블록들은 주변기기를 포함한 응용 프

로그램들에 적절히 짜 맞도록 선택할 수 있는 부분들이다. ADVANCED DESIGNER-DEFINED FUNCTIONS 블록은

주어진 SoC 설계에 한 특정 알고리즘을 가속화하기 위해 설계자가 프로세서에 추가하는 하드웨어 실행 유닛과 레

지스터들이다. Base Instruction Set 아키텍처는 모든 설정에 공통이다.

Xtensa Architecture

TRACE Port

JTAG Tap Control

On Chip Debug

Align and Decode

Designer-Defined

Register Files

Designer-Defined

Execution Units

Instruction

Fetch/PC

Unit

MM

U

ITLB

MM

U

DTL

B

Pro

cess

or C

ontro

ls

InstructionCache

Instruction ROM

Instruction RAM

Data Cache

Data

Load/Stor

e Unit

Data ROM

Data RAM

Xtensa Local Memory Interface

Register File

ALU

MAC 16

MUL 16

MUL 32

FPU

Vectra DSP

Write Buffer(4 to 32 entries)

XtensaProcessor

Interface(PIF)

External Interface

Interrupt Control

Timers 0 to n

Exception Support

Base ISA Feature

Configurable Function

Optional Function

Optional & Configurable

Advanced Designer- Defined Functions

Data Address Watch 0 to n

Instruction Address Watch 0 to n

125Embedded World

로그램 처리에 적합하도록 자체 설정

이 가능한 마이크로프로세서 코어를

제공한다. Xtensa 코어는 특히 디지털

가전, 네트워킹, 사무자동화(OA) 및

무선통신의 임베디드 SoC 응용 프로

그램들에 적합하도록 설계되었다.

Xtensa 32비트 아키텍처는 임베디

드 설계에 최적화된 간결한 명령어 세

트를 선보이고 있다. 아키텍처의 기본

으로는 32비트 ALU와 최고 64개의

범용 레지스터, 6개의 특수 목적 레지

스터 및 향상된 16비트 및 24비트(32

비트가 아닌) RISC 명령어 엔코딩을

포함해, 80개의 기본 명령어 등으로

이루어져 있다. Xtensa 프로세서 아

키텍처의 기술은 설계자가 코드 사이

즈를 크게 축소하여 코드의 도를 높

이고 전력 소모를 크게 개선할 수 있게

해준다. 이것은 고집적 SoC ASIC의

비용 절감을 위해 꼭 필요하다.

Xtensa 코어의 16비트 및 24비트

인코딩은 또한 여러 가지의 비교 및 분

기 명령, 오버헤드가 없는 루프 명령,

기억정보 이동 및 필드추출 동작을 포

함하는 비트 조작 명령과 같은 강력한

분기 명령들을 제공한다.

응용 소프트웨어를 살펴서 마이크로

프로세서 코어를 설정하고 새로 고안된

명령어를 작성하여 최적화된 성능을 구

현하는데 까지 모두 수 시간이면 끝마

칠 수 있다. Xtensa 프로세서 생성기는

설계자가 특정 응용 프로그램에 잘 동작

하는 임베디드 프로세서를 신속하고 정

확하게 제작하는데 사용한다. 즉, 실제

로 프로세서의 제작 공정에 들어가기 전

에, 시스템 설계자들은 프로세서 생성

기로부터 얻어진 실시간 결과치를 가지

고 프로세서의 집적도, 속도, 소모전력,

코드 도 등을 요구 상황에 맞게 취사

선택할 수 있도록 다양한 아키텍처들에

해 시험해 볼 수 있다는 것이다.

Xtensa 프로세서 생성기는 웹 화면

상에서 직접 사용할 수 있게 되어 있

다. 따라서 시스템 설계자, 하드웨어

또는 소프트웨어 개발자들은 그것을

통해 명령어 설정 옵션, 메모리의 구

조, 인접 블록 및 응용 프로그램에 필

요한 외부 인터페이스 등을 지정할 수

있고, 또한 텐실리카 명령어 확장(TIE)

언어를 사용하여 더 많은 데이터 유형

들과 명령 및 실행 유닛을 설계할 수

있다. 그렇게 해서, Xtensa 프로세서

생성기는 완벽하게 회로가 합성이 되

는 하드웨어 디자인과 잘 정리된 소프

트웨어 환경을 단 수 시간만에 만들게

된다(그림 2 참조).

이 하드웨어 디자인은 SoC 디자인

의 다른 부분과 직접 연결될 수 있을

만큼 완벽하고 어떠한 반도체 공정에

그림 2. 기능을 미리 설정할 수 있는 Xtensa 프로세서 코어는 하드웨어 및 소프트웨어의 유용한 결과물들과 함께 여

러 가지 지원 도구 등을 제공하여 응용 프로그램에 최적화된 임베디드 SoC를 만들 수 있게 한다. 즉, Xtensa 솔루션

은 다음과 같은 기능들을 제공한다:

회로 합성이 가능한 RTL 레벨 디자인, 필요한 모든 소프트웨어 개발 도구, 회로 합성/스캔/P&R 스크립트, 최근에 만

들어진 업계 표준의 셀 라이브러리 및 메모리 블록, 게이트 레벨 및 RTL 레벨의 시뮬레이션/기능 검증, 버스의 기능

모델, 정확한 명령어 세트 시뮬레이션 모델, RTL 레벨의 코어 테스트 벤치, 광범위한 교육 등이다.

The Xtensa Processor Solution

ProcessorConfiguration

Inputs

TIE: Designer-Defined

Instructions

Xtensa Processor Generator

Processor Generator Outputs

Executable

ApplicationSource Code

Compile

Profile UsingISS

Develop NewExtensions orChoose NewConfiguration

Software Tools

ProcessorOptimizationLoop

Xtensa C/C++Compiler(XCC)

C SoftwareLibraries

OSKit OperatingSystem Overlay

HardwareSystem Modeling/Design

Methodology Support

Bus Functional Model

XT2000 Emulation Kit

EDAScripts

RTL

To Fab

Synthesis

BlockPlace &Route

Verification

ChipIntegration

Co-verificationTools

SoftwareDevelopment

InstructionSet

Simulator

XTMP:System

SimulationEnvironment

Gnu SoftwareToolkit(Compiler,

Assembler, Linker,Debugger, Profiler)

126

PRODUCT FEATURE

도 수정없이 그 로 사용할 수 있어 궁

극적으로 크게 비용절감을 할 수 있다.

그리고, 소프트웨어 결과물에 해서

는 프로파일러와 다양한 시뮬레이션

모델, 지원되는 RTOS를 사용하여 소

프트웨어 개발, 시스템 레벨의 시뮬레

이션 및 검증을 즉각 수행할 수 있다.

신속한 자체 기능 설정을 갖는 Xtensa

프로세서 생성기는 다음과 같은 선택

사양을 제공한다.

░ 실행 유닛 및 ISA 선택사양

▶ 32 또는 16비트 Multiplier

▶ DSP 엔진

→ 단일 16비트 MAC

→ SIMD 벡트라 DSP 엔진

▶ 부동소수점 처리장치

░ 인터페이스 선택사양

▶ 프로세서 인터페이스 폭:

32/64/128비트

▶ Big-Endian/Little-Endian

Byte ordering

▶ On-Chip Debug

▶ Trace Port

▶ XLMI 고속 로컬 인터페이스

▶ 최고 32비트 인터럽트

░ 메모리 서브시스템

▶ 메모리 관리 선택사양

▶ 로컬 데이터 및 명령어 캐시

→ 최고 4-웨이 세트 조합

→ 최고 32KB

→ Write-back 및 Write-

through 캐시

▶ 데이터, 명령어를 위한 별도의

RAM, ROM 역

░ 설계 지원

▶ 명령어 세트 시뮬레이터 및

Xtensa 모델링 프로토콜

▶ 버스 기능 모델

▶ ATI의 Nucleus, Wind River

Systems의 VxWorks, Monta

Vista의 HardHat Linux를 위

한 RTOS 지원 패키지

TIE 언어는 더욱 많은 새로운 명령

어와 레지스터 및 실행 유닛을 표현하

여 자동적으로 Xtensa 프로세서에 그

기능을 추가할 수 있다. TIE는 Verilog

와 유사한 언어로 명령어, 피연산 함

수, 인코딩 및 기타 기능 동작 등을 표

현하는데 사용된다. TIE 파일들은

Xtensa 프로세서 생성기에 입력되고

프로세서 생성기는 자동으로 해당 버

전의 Xtensa 프로세서와 필요한 소프

트웨어 도구를 만들며, 이 도구는 다시

더 나은 새로운 TIE를 만드는데 사용

되게 하고 있다.

TIE를 사용한 프로그램 최적화는 우

선, 응용 소프트웨어의 '급소'(응용 프

로그램에서 가장 동작이 민감한 부분)

를 가려내면서부터 시작한다. 설계자는

실행 프로파일러를 통해 응용 프로그램

의 설계 효율성을 분석할 수 있고 소프

트웨어의 성능을 향상시키기 위해 TIE

를 설계의 어느 부분에 사용할 지 시험

할 수 있으며, 이 일련의 프로세서 생성

과정을 반복하여서 새로운 명령어와

TIE에 의해 꾸며진 하드웨어가 가장

잘 된 프로세서를 얻을 수 있다. 보통,

병렬처리와 기타 기술들을 잘 활용하고

또 TIE 명령어를 사용하는 경우 10배,

100배 또는 그보다 훨씬 높은 성능 향

상을 가져올 수 있다(그림 3 참조).

C- 코드로 짜여진 명령어 또한 내부

기능 call로 사용할 수 있으며 Xtensa

컴파일러는 이것을 자동으로 최적의

스케줄링된 어셈블리 코드로 만들게

된다.그림 3. 설계자 정의 명령은 시스템 성능향상에 큰 향을 준다.

Xtensa Accelerates Compute-Intensive Applications

JPEG(cameras)

W-CDMA(wireless base station)

Lifting/Wavelet Transform(JPEG2000)

FIR Filter(telecom)

H.263 Codec

IP Packet Forwarding/Routing

DES Encryption(IPSEC, SSH)

MPEG4 QCIF

Turbo Coding(MaxLogMap)

Motion Estimation(video)

GSM Viterbi Decoding(butterfly)

Improvement -vs- General-Purpose 32-bit and 64-bit RISC cores

ARM9/MIPS32class equivalent

Base + 7500 gates

Base + 4000gates

Base + 40000gates

Base + 4000gatesBase + 45000

gates

Base + 6000gates

Base + 4500gates

Base + 178000gates

Base + 65000gatesBase + 30000

gates

Base + 11000gates

ARM10/MIPS64class equivalent

2x 3x 4x 6x 8x 10x 50x 100x 250x

Exam

ple

App

licat

ions

Xtensa 소프트웨어 개발환경은 업

계 표준의 GNU 도구들, C/C++ 컴파

일러(gcc), 어셈블러, 링커 및 디버거

(gdb)로 구성되어 있는데 텐실리카는

이 도구들을 Xtensa 명령어 세트 아키

텍처에 맞게 최적화 하 고 더욱이 회

사의 전용 기술을 사용하여 특정 하드

웨어 설정에 따른 다양한 종류의 명령

어 패키지를 만들었다.

또, 쉬운 오류 수정을 위해서 데이

터 디스플레이 디버거(DDD)를 통해

사용자 인터페이스(GUI)를 제공하고

있다.

Xtensa 소프트웨어 개발 환경은 프

로세서의 하드웨어 설계와 똑같은 데

이터베이스로부터 만들어진다. 이는

설계의 정확성과 일관성을 보다 확실

하게 보장해 주어 설계자가 하드웨어

와 정확히 조율되어 있는 컴파일러, 링

커, 어셈블러, 디버거들을 사용할 수

있게 한다. 이 일련의 소프트웨어 도구

는 또한 자동으로 갱신되고 최적화되

어서 하드웨어 생성에 사용했던 설계

자 정의 명령어들을 그 로 적용할 수

있다.

Tensilica는 표준 GNU 도구 외에

선택사양으로 Xtensa C/C++ 컴파일

러(XCC)를 제공한다. XCC는 gcc에

비하여 평균 20%에서 40%까지의 성

능향상을 가져온다. XCC는 벡트라

DSP 엔진에 해서 C 코드의 자동 벡

터화를 제공한다. Xtensa의 표준

GNU 기반의 소프트웨어 개발 도구에

서처럼 XCC는 프로세서의 하드웨어

설계와 똑같은 데이터베이스로부터 만

들어져 설계의 정확성을 기할 수 있게

한다.

Xtensa 운 체제 킷은 Accelerated

Technology사의 Nucleus PLUS와

Wind River Systems사의 Tornado

for VxWorks와 같은 상업적으로 시

장을 주도하고 있는 실시간 운 체제

및 그 개발 환경을 지원하는 패키지이

다. 이 운 체제 킷은 설계자 정의 명

령어들을 포함한 아키텍처의 모든 설

정된 기능들이 표준 RTOS 런타임 환

경에 의해 완벽히 지원되는 것을 보장

한다. 더욱이, Mentor Graphics사의

Seamless 하드웨어/소프트웨어 일체

검증용 소프트웨어나 XRAY 오류 검

증용 소프트웨어와 같이 현재 시장을

주도하는 주요 소프트웨어 업체들이

Xtensa 코어를 위한 다양한 개발 환경

및 디버거를 제공하고 있음은 설계자

에게 큰 신뢰를 준다.

그림 4. 복수의 프로세서 시스템을 위한 Xtensa 모델링 프로토콜(XTMP) 시뮬레이션 환경

Application SpecificLogic(RTL)

XtensaCore 1

XtensaCore 2

XtensaCore 3 System

RAM

RAM ROM

Bridge

A B C

Peripherals

XTMP Environment

Xtensa Technology Enables Multiple Processor SoCs

...etc...int XTMP_main(int argc,char **argv){

xtensa_params p;XTMP_core core1, core2, core3;XTMP_router router;XTMP_memory sysrom1, sysrom2,

sysram1, sysram2;XTMP_memory shared_mem;XTMP_procId pid;XTMP_lock lock;

............etc..............sysrom1 = XTMP_memoryNew( "sysrom1",

p, 0, 131072);XTMP_setReadOnly(sysrom1, 1);

sysram1 = XTMP_memoryNew( "sysram1",p, 0, 0x10000000...etc...

D

127Embedded World

128

PRODUCT FEATURE

Xtensa 명령어 세트 시뮬레이터

(ISS)는 두 개 이상 복수의 프로세서에

서도 사용이 가능한 명령어 세트 시뮬

레이터로서 설계자의 시스템 API에서

호출된다. 이는 두 개 이상 복수의 ISS

가 다른 시스템 구성요소와 함께

C/C++ 환경에 구현될 수 있어 서브시

스템 레벨의 정확한 시뮬레이션과 분

석을 할 수 있다는 것을 의미한다.

Xtensa 모델링 프로토콜(XTMP)은

Xtensa 프로세서의 서브시스템 모델

링과 시뮬레이션을 위한 환경인데, 하

나 또는 그 이상의 Xtensa 프로세서와

여러 가지 메모리 및 구성 블록들에

한 신속한 시스템 레벨 시뮬레이션을

가능케 해준다.

Xtensa ISS와 XTMP를 사용해서,

설계자들은 복수의, 서로 다른 Xtensa

프로세서로 구성된 완벽한 SoC 서브

시스템 구성과 시뮬레이션을 신속히

수행할 수 있다(그림 4 참조).

텐실리카는 설계자의 SoC 검증을

보조하기 위한 일련의 강력한 검증 도

구를 제공한다. Xtensa 인터페이스의

임베디드 RTL 검사/감시기로부터 하

드웨어/소프트웨어의 일체 기능 검증

을 위한 자동화 버스 기능 모델 구축,

TIE 확장 언어의 기능 검증을 위한 스

크립트 지원에 이르기까지 텐실리카는

여러분의 검증 스타일에 적합한 다양

한 기능들을 제공하고 있다.

XT2000 에뮬레이션 킷은 특정

Xtensa 프로세서 설정을 에뮬레이트

하기 위해 프로그램 로직 디바이스로

꾸며진 저가의 종합 개발 보드이다. 이

에뮬레이션 킷으로 개발자는 여러 가

지 프로세서 설정값을 입해 보면서

소프트웨어 개발에 착수할 수 있으며,

설계 초기 단계에서 오류 검증을 할 수

있기 때문에 설계자 정의 명령어를 포

함한 새로운 프로세서 설정과 에뮬레

그림 5. 벡트라 엔진의 벡터/SIMD 아키텍처는 효율성과 성능을 위해 최적화되어 있다.

Vectra DSP Engine Block Diagram

Store Saturation

Data RAM/Cache/ROM

Alignment Registers

Load Expansion

Vector Registers

Dual Shift/Select

SelectRegs

ScalarRegs

B B B B

A A A A A

C C CD

EE

X

A A A

Dual ALUAdd/Sub

표 1. Xtensa 프로세서를 위한 벡트라 DSP 엔진들

Vectra DSP Engine Configurations

Vectra Vectra Vectra Vectra VectraV1620-8 V1620-4 V1616-8 V0810-8 V3224-4

Elements per8 4 8 8 4

vector A

Memory width of 16 16 16 8 32

each element B

Register width of20 20 16 10 24

each element C

Number of 4 2 4 4 2

MAC units D

Multiplier and Multiplicand 16×16 16×16 16×16 8×8 24×24width E

이션, 그리고 오류 검증을 단 수 시간

안에 끝마칠 수 있다.

벡트라 엔진은 SoC 설계 통합 솔루

션에서 핵심적인 설계 블록이다. 이를

통해 임베디드 제어, 프로토콜, 시그널

및 이미지 프로세싱과 같은 응용 프로

그램에서 설계에 필요한 각각의 주요

요소들을 단일 프로세서 아키텍처로

신속히 구현할 수 있음이 처음으로 가

능해졌다.

이 벡트라 엔진이 포함된 Xtensa 통

합 아키텍처는 또한 소프트웨어 개발,

시뮬레이션 및 RTOS 환경을 위한 공

통된 기반을 확실히 보장하며 8비트,

16비트, 24비트 등 다양한 고정소수점

SIMD 설정을 통해서 세계 최고 수준

의 데이터 작업 처리능력을 제공한다

(표 1, 그림 5 참조).

129Embedded World

기능 요약

Xtensa 프로세서는 임베디드 SoC 개발을 위한 완벽하고도 강력한 도구들과 기본 블록들을 제공한다.▶ Xtensa 프로세서 생성기

→ RTL 레벨 하드웨어 디자인과 관련 소프트웨어 개발 도구의 신속한 자동 생성▶ 텐실리카 명령어 확장(TIE) 언어

→ 설계가 용이하고 프로세서의 기본 아키텍처에 자동통합되는 설계자 정의 명령어▶ 응용 프로그램에 따라 선택할 수 있는 기본 블록

→ Multipliers, 16비트 MAC, FPU 및 SIMD 벡트라 DSP 엔진 블록▶ 메모리 관리 기능

→ 메모리 역 보호→ Virtual-to-physical address translation 맵핑을 갖는 메모리 역 보호→ Translation Look Aside Buffers(TLBs)를 갖는 메모리 관리 유닛(MMU)

▶ 설정 가능 인터페이스→ 프로세서 인터페이스(PIF) 폭: 32/64/128비트→ 선택사양 고속 Xtensa 로컬 메모리 인터페이스(XLMI)→ XLMI와 데이터 RAM에 한 내부 방향 PIF 요청 기능

▶ 복수의 프로세서 개발 및 오류 검증 기능→ 복수의 프로세서를 위한, C/C++ 호출 가능 명령어 세트 시뮬레이터(ISS)→ 시스템 모델링 기능: ISS를 위한 XTMP 시뮬레이션 소프트웨어 환경→ 복수의 프로세서를 위한 On-Chip Debug 기능

▶ 소프트웨어 개발 도구→ GNU C/C++ 소프트웨어 개발 도구 세트→ 고성능 Xtensa C 컴파일러(XCC)→ 수 시간 안에 만들 수 있는 최적의 Xtensa 코어와 소프트웨어 개발 도구

▶ 강력한 EDA 환경 지원→ 회로 합성 및 P&R 지원

▶ 검증 지원→ Xtensa 코어와 설계자 정의 TIE의 종합적 검증

▶ 시뮬레이션 모델→ 설정된 프로세서 코어의 기능을 검증할 수 있는 정확한 모델 세트

▶ 실시간 운 체제 지원을 위한 킷→ Accelerated Technology사의 Nucleus→ Wind River Systems사의 VxWorks→ Monta Vista사의 HardHat Linux

성능 요약

▶ 프로세서 아키텍z처: 5단계 파이프라인, 고성능, 32비트 RISC▶ 명령어 세트: 간결한 16비트 및 24비트 인코딩을 갖춘 Xtensa ISA(모드 전환은 불가능)▶ 클록 속도: 0.13㎛ 공정에서 350MHz

0.18㎛ 공정에서 200MHz▶ 성능: 텐실리카 사용자의 경우, TIE를 이용, Xtensa 프로세서를 확장함으로써 5배, 10배, 심지어 100배 이상의 성능 향상을 기록한 바 있다.▶ 크기: 약 25,000 게이트 - 기본 프로세서

최저 18,000 게이트 - 태스크 엔진 설정시▶ 전력: 1.0V, 0.13㎛ 공정에서 0.1mW/MHz

1.8V, 0.18㎛ 공정에서 0.4mW/MHz

클록 속도, 전력, 크기 및 성능은 설정 내용과 적용 기술의 선택에 따라 달라질 수 있다.

130

PRODUCT FEATURE

SysProbe는 인터커넥트 신호를 트랜잭션층으로 가져온

다. 이들 트랜잭션을 이용해 역폭, 지연시간, 버스 활용

등의 각 성능 요소를 분석할 수 있다. 이 정보는 표준적인

데이터베이스에 저장되며, 디자이너가 질의문을 간편하게

구축 및 실행하여 통계 정보를 그래픽으로 표시할 수 있다.

이 정보를 이용함으로써 성능 효율을 위해 인터커넥트를 어

떻게 조정해야 할지 결정할 수 있다.

모든 인터커넥트는 initiator(트랜잭션 개시)와 target(이

트랜잭션 해소)를 연결한다. 성능 분석에 이용되는

initiator와 target은 BFM(Bus Functional Model)이다.

initiator BFM을 모델링하여 worst-case 트래픽을 생성

할 수 있다. target BFM을 worst-case 응답을 이용해 모

델링한다. 그 다음 SysProbe를 이용해 이 initiator와

target 인터페이스의 성능을 분석한다. 이 성능 분석 정보

를 이용해 시스템 아키텍처에 관한 유용한 정보를 얻을 수

있다.

인터커넥트는 트랜잭션을 target으로 전달하기 위한 채널

을 제공한다. 인터커넥트 성능 분석에 새롭게 이용할 수 있

는 방법론이 SysProbe이다. SysProbe는 시스템에서 실행

된 시뮬레이션에서 인터커넥트 신호를 추출하고, 읽기/쓰기

트랜잭션 형태의 신호에 해 높은 수준의 뷰를 제공한다.

이들 트랜잭션이 동작 유형(읽기/쓰기), 트랜잭션 주소,

전송 바이트 수 등의 속성과 함께 인터커넥트의 적절한 지연

시간, 역폭 등의 성능 정보를 제공한다. 인터커넥트를 통

해 트랜잭션을 전달할 때는 지연시간, 역폭, 우선순위 등

의 알고리즘에 기반한다. 이들 파라미터를 바꾸는 방법으로

인터커넥트의 동작을 변경하여 시스템 성능을 향상시킬 수

있다. 이러한 결정을 할 때 SysProbe를 이용할 수 있다.

SysProbe는 매우 효율적인 방법으로 인터커넥트를 모델링

한다.

SoC와 관련해 트랜잭션이란 용어는 여러 가지 뜻으로 쓰

인다. 여기서는 어떤 시스템의 두 컴포넌트가 인터페이스를

통해 데이터 또는 이벤트를 교환하는 것을 말한다. 인터페

이스는 디자인의 인터페이스 프로토콜 규정에 따라 디자인

안에서 데이터를 옮기는 일련의 핀을 의미한다. 트랜잭션은

메모리 읽기처럼 간단한 것일 수도 있고, 전체 구조화 패킷

SysProbe를 이용한

SoC 인터커넥트 성능 분석STi5517 SoC의 Static SysProbe 사용예

시스템온칩(SoC)이 복잡해지면서 원하는 성능의 인터커넥트를 디자인하는 것이 쉽지 않은 일이 되었다. 이 에서는 인터커넥트 성능을 평가하는

데 이용할 수 있는 툴과 방법론을 알아본다. 현재 여기에 이용할 수 있는 솔루션이 시중에 나와 있지 않은 실정이다. 이러한 용도로 이용할 수 있도록

STMicroelectronics가 개발한 툴 및 방법론이 SysProbe이다.

: Sudhanshu Chadha, Kalyana Chakarvarthy, Rohit Jindal, Srikant Reddy Modugula

ST마이크로일렉트로닉스, Noida, India

을 전송하는 것처럼 복잡한 것일 수도 있다.

SysProbe는 하나의 구성된 툴셋으로서, initiator에서 특

정 슬레이브로 전달되는 트랜잭션을 식별하고 인터커넥트 지

연시간, 인터커넥트 활용, 인터커넥트 중재, 기타 성능 지표

를 포함해 시스템 성능 수치를 분석한다. ST SysProbe에는

Dynamic SysProbe와 Static SysProbe의 두 유형이 있다.

Dynamic SysProbe

Dynamic SysProbe는 시스템 RTL에 TVM(트랜잭션 검

증 모델)을 삽입하여 만든 것으로, RTL 디자인에서 C++

FSM(Finite State Machine)으로 신호를 추출한다. 그러

면 FSM이 버스 프로토콜에 따라 트랜잭션층에 신호를 기

록한다. Dynamic SysProbe(그림 1)는 C++ 공개 소스 툴

셋 TestBuilder를 이용해 설계했으며, Signalscan 웨이브

뷰어의 새로운 트랜잭션 기능을 활용한다.

Static SysProbe

Static SysProbe(그림 2)는 VCD(Value Change

Dump) 파일이라고 하는 시뮬레이션 파일을 후처리해 이용

한다. 이 파일에서 C++ FSM으로 신호가 추출된다. 그러면

이 FSM이 시뮬레이션 데이터베이스 인터페이스(SDI2) 라

이브러리를 이용해 트랜잭션층에 트랜잭션 형태로 신호를

기록한다. SDI는 C++ 인터페이스로, 시뮬레이션에서

SST2 데이터베이스 파일로 트랜잭션을 기록할 수 있게 하

며, 이 파일을 Signalscan에서 볼 수 있다. Static

SysProbe를 이용하면 SoC 디자인을 수정할 필요가 없다.

테스트벤치에 PLI/VPI 호출을 추가할 필요가 없으며, 디자

인 소스 파일을 변경하지 않고 디자인의 어느 부분에나 삽입

할 수 있다.

이 에서는 Static SysProbe에 해서만 논하고자 한다.

SysProbe의 특징으로 우선, 시간 X축의 도표로 트랜잭

션을 그래픽적으로 볼 수 있다는 점을 들 수 있다(그림 3).

SST2 데이터베이스 형태로 저장되는 이들 트랜잭션을 이용

하면 신호를 검사하지 않고도 시스템을 이해할 수 있다.

SysProbe는 트랜잭션 형태의 높은 추상화 수준으로 시스템

을 설명한다. 트랜잭션 익스플로러(TxE)(그림 4)는 Tcl로

분석 스크립트를 작성하는 데 유용하며, 시뮬레이션 동안

인지되고 기록된 트랜잭션을 검사한다. 이들 스크립트 또는

질의문을 이용해 SST2 데이터베이스에 해 통계를 계산하

고, 이렇게 함으로써 이전의 복잡한 문제에 해 이해할 수

있다. 예를 들면 이들 스크립트는 특정 슬레이브의 총 트랜

잭션 수, 최 /최소/평균 지연시간, 총 읽기/쓰기 수, 버스

활용, 현재 시뮬레이션의 스루풋 및 효율 등을 계산할 수 있

다. 이들 질의문은 또 간트도표, 파이도표, 스캐터플롯 등으

131Embedded World

그림 1. Dynamic SysProbe의 블록 다이어그램

Probes in C++

HDL simulator And

TestBuilder

DB queries in Tcl

Transactions Viewer

Trans.

Database

Trans.

Analyzer

그림 2. Static SysProbe의 블록 다이어그램

VCD file

C++ Static Probes

And SDI2 library

DB queries in Tcl

Transactions

Viewer(Signalscan)

Trans. Database

SST2

Trans.

Analyzer(TxE)

132

PRODUCT FEATURE

로 표시되어 다양한 질의문 효과를 한 도표/플롯으로 볼 수

있고, 모든 인터페이스는 사용자가 확장할 수 있다. 예를 들

면 모든 마스터의 총 동작 수를 막 그래프로 볼 수 있다.

그러므로 SysProbe를 이용해 성능을 분석할 수 있다.

SysProbe는 원인 트랜잭션과 결과 트랜잭션을 연결할 수

있다. 예를 들어, 요청 트랜잭션과 응답 트랜잭션의 두 트랜

잭션이 있다고 하자. 이 경우 SysProbe가 응답 트랜잭션을

원인 트랜잭션인 요청 트랜잭션과 연결할 수 있다(그림 3).

SysProbe는 플랫폼에 무관하므로 이 인터커넥트가 이용된

어느 플랫폼에나 이용할 수 있다.

표 1은 Dynamic SysProbe와 Static SysProbe의 각각

의 특징을 보여준다.

STi5517 SoC 아키텍처

이 SoC는 일련의 target으로 트랜잭션을 개시하는 일련

의 initiator로 구성된다. ST 버스 인터커넥트가 ST20이나

DMA 같은 initiator에서 SDRAM 등의 target으로 트랜잭

션을 전달할 채널을 제공한다. SysProbe를 이용해 성능을

분석하기 위해서는 각 initiator로부터의 트래픽과 target으

로부터의 응답을 모델링한다. initiator로부터의 트래픽 모델

링에 해서는 뒤에서 예를 설명하고 있다.

트래픽을 모델링할 initiator가 블록 이동 DMA라고 하자.

그리고 이 DMA가 디코딩한 비디오 화면을 메모리에서 디지털

인코더로 옮기고, 디지털 인코더는 디코딩 화면을 PAL 방식으

로 인코딩한다고 하자. 라인당 화소는 720픽셀이고, 화면당 라

인은 520라인이고, 프레임당 화면은 25화면이다. Y:Cb:Cr은

4:2:0(Luma Chroma 비율)이다. 다시 말해, 루마 픽셀과

비교해 크로마 픽셀이 절반이다. 그러면 총 픽셀 수는 720 +

360 = 1080이다. 각 픽셀을 한 바이트로 표현한다면 데이터 읽

기의 총 역폭은 1080*520*25 = 14.04Mbps이다. DMA 데

이터 버스 폭이 1바이트라면 데이터 읽기에 필요한 트랜잭션

수는 14.04/2 = 초당 7.02M 트랜잭션이다. 쓰기에도 동일한

수의 트랜잭션이 필요하다. 그러므로 읽기 쓰기 비율이 1:1

일 때 필요한 총 역폭은 14.04M 트랜잭션이다.

DMA가 4워드 FIFO(1워드는 2바이트)를 이용한다면 DMA

가 4개 병렬 읽기와 4개 병렬 쓰기를 수행할 수 있다. 만족스

러운 시스템 성능을 달성하기 위해서는 한 화면에 해당하는 데

이터(1080*520 = 561.6KB)를 단일화면 시간(1/25 = 40ms)

안에 전송해야 한다.

target으로부터의 응답은 목적 디자인에 따라 달라진다.

target으로 접근하기 위한 한 액세스가 SDRAM에 한 인

그림 3. Diagram showing some Signals of interconnect and the linking of

Transactions in SignalScan

그림 4. Analysis request and result table in TxE

}apply {

fiber "*/SSTconv1.dsn: :Cell_Operation_conv.END_Operation_cell_conv1" {trans_type "STBUS" {if {[attribute "Latency"] == "1"} {

accept}

Cell_Operation_conv1.END_Operation_cell_conv1 none STBUS 1 18

Cell_Operation_conv1.END_Operation_cell_conv1 none STBUS 2 90

Cell_Operation_conv1.END_Operation_cell_conv1 none STBUS 3 39

fiber signal trans_type Latency Items

Browse Execute Apply

표 1. Distinguishing features between Dynamic SysProbe and Static SysProbe

S.No

1.

2.

3.

4.

Dynamic SysProbe

The test bench needs to be modified to

include few lines of code requiring the

recompilation of design source.

No need to do post processing of the VCD

files

The transaction can be seen in real time

during the simulation

The TxE scripts can be launched during the

simulation

Static SysProbe

No need to modify the test bench and no

need of recompilation of design source.

It requires post processing of VCD files, which

are less optimized than SST2 binary files.

The transaction can be seen only after the

simulation.

The TxE scripts can be seen after the

simulation.

터페이스라면 SDRAM 모델을 이용해 SDRAM 컨트롤러

모듈을 기술하는 것이 좀더 정확하다. 하지만 성능 분석 초

기 단계에서는 SDRAM 컨트롤러를 이용 못할 수 있다. 이

경우에는 target의 동작 모델을 기술하고 이 target 모델의

worst-case 응답을 모델링하는 방법을 이용할 수 있다.

worst-case 응답은 다음과 같이 모델링 할 수 있다.

SDRAM의 CAS(Column Access Select) 지연시간이 4

SDRAM 클록이라 하자. SDRAM 데이터 폭은 16비트이고,

버스트 길이는 2워드이고, SDRAM 컨트롤러 데이터 버스

폭은 32비트(2워드)이다. (설명의 편의를 위해) SDRAM 클

록과 인터커넥트 클록이 동일하다고 하자. 이러한 경우라면

target의 지연시간이 6(CAS 지연시간의 4사이클 + 32비트

워드의 2사이클) 클록이다. 재 타이밍을 위해 2개 클록 사이

클을 추가한다면 총 지연시간은 8 클록 사이클이 된다.

initiator의 모델링한 트래픽과 target의 응답을 이용해 시

뮬레이션을 실행한다. 다음에서 설명하는 바와 같이, 실시

한 시뮬레이션에 해 SysProbe를 실행해 성능을 분석해

보았다.

STi5517 SoC의 Static SysProbe 사용예

이 SoC에 SysProbe를 사용하는 가장 주된 목적은 지연

시간이나 역폭 같은 파라미터를 변경해 인터커넥트의 성

능을 향상시키는 것이다.

이 SoC 디자인에는 패킷 트랜잭션과 셀 트랜잭션의 2개

트랜잭션 유형이 이용된다. 한 패킷에 여러 개의 셀 트랜잭

션이 포함된다.

133Embedded World

그림 5. Diagram showing STi5517 SoC with SysProbe plugged on the initiators

C201

VIDEO

MMDSP

SMI

AUD

DACs

SDRAM

SDRAM

ROW FLASH

SRAMPERIF

MPEG INT

MPB LMCB

EMI4 Pedlogic

FECS

PTI

OSD

ClockGen

TSin0

Tsin1

IFetch

OFetch

SDRAM

TSout

TS Sub

STB

US O

MEG

A2

Inte

rcon

nect

CD

-FIF

Os

SU

B

DENC

TAP+TAPlink+RID

1) initiator 이름

2) target 이름

3) 트랜잭션 유형 - 읽기/쓰기

4) 트랜잭션의 시작 주소

셀 트랜잭션에는 다음과 같은 속성이 기록된다.

1) initiator 이름

2) target 이름

3) 트랜잭션 주소

4) 읽기 또는 쓰기 데이터

5) 버스 폭

6) 지연시간 - 마스터가 준비되지 않았을 때 지연 + 버스

중재로 인한 지연 + taget이 준비되지 않았을 때의 지

연을 합한 총 지연시간

7) 최 /최소/평균 지연시간

8) 연속 트랜잭션 - 이 파라미터를 이용해 패킷 트랜잭션에

얼마나 많은 셀이 포함됐는 지 알 수 있다.

9) FIFO 깊이 - 기중인 큐의 수를 알 수 있다.

initiator의 성능 분석

DMA initiator에 한 여러 시뮬레이션에서 SysProbe

의 역폭 파라미터를 보면 역폭이 10MB/s라는 것을 알

수 있었다. 이는 일부 애플리케이션을 위한 14.04MB/s보다

낮았다. DMA는 SDRAM에서 로컬 메모리 인터페이스

(LMI)로 데이터를 읽어들이고, 이를 다시 LMI의 다른 위치

에 기록하므로 어쩔 수 없이 지연시간을 야기했다. DMA가

제공하는 데이터가 중요하고, 그러므로 이 데이터를 지연할

수 없으므로 DMA에 높은 우선순위를 부여해야 했다.

하지만 DMA에 높은 우선순위를 부여하면 c200 등의 다

른 initiator가 리게 된다. 이것이 프로세서의 성능에

향을 미쳤다. 그러므로 중요 initiator로 프로그래밍하는

DMA에는 지연시간 기반 중재가 적절했다. 이렇게 하자

DMA에 접근하기가 쉽고 프로세서에 해서는 일정한 액세

스를 유지할 수 있었다.

SoC의 성능을 분석한 결과, 일부 애플리케이션에서는 LMI

에 단일 SDRAM을 이용하는 것이 적절치 않은 것으로 나타났

다. 예를 들어, 모뎀 소프트웨어나 g729 디코딩 같은 애플리케

이션은 크기가 커서 ST20 프로세서의 캐시 메모리에 들어가

지 않았다. 그러므로 상당 양의 캐시가 소실되었다. 따라서

LMI를 액세스할 때 지연시간이 길어 이들 애플리케이션에 필

요한 성능을 달성하기가 어렵다. 그러므로 캐시 소실이 큰 애

플리케이션에는 외부 메모리 인터페이스(EMI)에 추가적인

SDRAM이 필요하다.

아키텍처 분석

SDRAM으로부터의 target 응답도 재모델링 했다. taget

이 응답하는 데 적절한 총 지연시간은 총 8 클록 사이클로

계산되었다. 분석결과 지연시간이 너무 높았다. 그래서 메

모리 뱅크의 구성을 변경하자 지연시간이 8 클록 사이클에

가까워졌다. 지연시간 파라미터를 면 히 검토해 메모리 뱅

크에 가장 적절하고 가능한 구성을 선택하자 taget 응답이

향상되었다. 쓰기 트랜잭션 역시 쓰기 응답 시간이 향상되

고 지연시간이 줄어든 것으로 나타났다.

이 SoC에 SysProbe를 이용함으로써 인터커넥트 성능을

향상시킬 수 있었고, 어느 정도 아키텍처를 분석하는 데 유

용했다. SysProbe의 트랜잭션을 검토하고 성능 지표를 분

석해서 인터커넥트 파라미터를 변경하자 시스템 성능이 향

상되었다. SoC에 각각의 주변장치 구성을 이용해 분석한 결

과, 일부 구성의 성능 지표는 적절치 않은 것으로 나타났다.

그러므로 디자이너는 SysProbe를 이용함으로써 가장 적절

한 구성을 선택할 수 있었다.

■참고문헌

[1] Testbuilder open-source website: www.test-builder.net

[2] Cadence Simulation Database Interface (SDI2) library: SDI is a C++

interface that provides interface calls to record transactions into an

SST2 simulation database or a text file.

[3] Transactional Explorer tool (TxE) - Tool to create scripts in Tcl

that enable analysis of transactions of SST2 Database

[4] A. Clouard, G. Mastrorocco, F. Carbognani, A. Perrin, F,

Ghenassia. "Towards Bridging the Precision Gap between SoC

Transactional and Cycle Accurate Levels", DATE 2002

134

PRODUCT FEATURE

APPLIED MICROSOFT .NET

FRAMEWORK PROGRAMMING

이 책은 Microsoft .NET Frame-

work 개발을 성공하기 위해 필요한

전문가 가이드로써, ASP. NET 웹

폼, XML 웹 서비스 애플리케이션,

Windows 폼 애플리케이션, 툴, 형 등

을 보다 쉽게 설명한다. 특히 데이터

추상화, 상속, 다형성과 같은 객체 지

향 프로그래밍 개념을 이해하고 있는 이에게 가장 적합한

지침서이다. 이 책을 통해 Common Language Runtime

에 한 모든 것을 알아보고, 강력한 기능을 활용하여 애플

리케이션이나 컴포넌트를 빌드, 패키징, 배포하는 방법을

공부한다. 또한, .NET Framework의 확장 가능한 형 시

스템을 심도 있게 설명하고, 런타임이 어떻게 형의 동작을

관리하는 지를 살펴본다. 사실, 이 책은 C#에 초점을 맞추

어 설명하고 있지만 .NET Framework를 상으로 하는

모든 프로그래밍 언어에 적용되는 개념을 소개한다.

주요 내용: .NET Framework 아키텍처/애플리케이션 및 형의

빌드, 패키징, 배포, 관리/공유 어셈블리의 빌드 및 배포/형 멤버

와 접근성/열거형과 비트 플래그/인터페이스/사용자 지정 특성/자

동 메모리 관리/AppDomain과 리플렉션 등

저자: Jeffrey Richter/정보문화사/669페이지/25,000원

EMBEDDED LINUX 이론과 실습

현 는 정보화 사회에 발맞춰 임베디드 시스템의 근간이

되는 CPU와 개방형 소프트웨어 기술의 발전으로, 많은 임

베디드 시스템 기반의 연구와 개발이 이루어지고 있는 상황

에 있다. 그 동안 쉽게 접근하기 어려웠던, 임베디드 리눅스

시스템 개발에 관한 가장 기초적인 이론과 이해를 풀어서 설

명한다. 특히, 이론과 실습을 병행하여 초보자도 혼자서 쉽

게 공부할 수 있도록 하 다.

주요 내용: 기본적인 임베디드 리눅스 시스템에 한 이해/커널과

파일 시스템, 디바이스 드라이버에 한 소개/프로세스 통신, 웹

서버 포팅과 Qt/Embedded 응용 프로그램 소개

저자: 박동선, 신 석, 주수종/홍릉과학출판사/316페이지/11,000원

또다른 세상, 색다른 경험시간과 장소를 초월해

항상 최고의 서비스를 약속합니다.

The leading edge e-Magazine

여러분의

방문을

환 합니다.

http://www.embeddedworld.co.kr

디지털시 의 미디어 동반자 (주)테크월드

서울시 등포구 림3동 682-2

Tel:82-2-835-2100∙Fax:82-2-835-2166

e-mail:webmaster@embeddedworld.co.kr

NEW LITERATURE & BOOK

리눅스 커널의 이해

리눅스 프로그래밍 기술이 날로 정

교해지면서, 이 분야의 미래에 해 밝

게 전망되고 있다. 이 책을 읽고 나면,

리눅스의 성능을 최고로 끌어올리는

조건이 무엇인지 이해할 수 있다. 또한

프로세스 스케줄링과 파일 접근 그리

고 다양한 환경에서 메모리를 관리하

는 동안 시스템 반응을 향상시켜 달라는 요구를 만족시킬 방

법도 알 수 있다.

이 책에서는 각 주제를 설명할 때 그것이 왜 중요한지 설

명하고, 커널 동작을 유닉스 프로그래머와 사용자에게 익

숙한 시스템 콜이나 유틸리티와 연관지어 이야기한다. 커

널의 근본 원리가 쉽게 변하지 않는 점을 감안할 때, 이 책

은 다른 운 체제의 작동 원리나 구조를 파악하는 데도 도

움이 될 것이다.

주요 내용 : 파일 버퍼링과 프로세스 스와핑, DMA를 비롯한

메모리 관리/프로세스 생성과 스케줄링/커널 내 동기화/프로세스

간 통신(IPC) 등

저자: Daniel P. Bovet, Marco Cesati/한빛미디어/859페이지/35,000원

CODE COMPLETE

소프트웨어 컨스트럭션(코드구축)과

소프트웨어 개발 과정의 중요한 부분

에 한 백과 사전적 처방을 담고 있

다. 여기에는 약 500개의 예제 코드와

아키텍처, 설계방법, 모듈과 루틴 품질

등을 평가하기 위해 즉석에서 사용할

수 있는 체크리스트가 포함되어 있다.

이 책은 파스칼 C, C++, Ada, Basic, Fortran, COBOL,

기타 절차적 언어 등, 사용하는 언어에 관계없이 적용할 수

있는 기술들을 설명한다.

주요 내용 : 루틴의 작성 단계/고급 루틴의 특성/컨스트럭션에

서의 고급 설계/배치와 스타일/컨스트럭션 관리/코드 조정 전략,

기법 등

저자: Steve Mcconnell/높이깊이출판사/1,164페이지/29,000원

LITERATURE

Embedded World Editoral Mission

Embedded World는 임베디드 시스템 제품의 기술적 분석과

독자에게 임베디드시스템의 개발, 전개, 관리를 돕기 위한 기술 및

시장정보를 제공합니다.

Embedded World는 독자들이 임베디드 시스템을 이해하고 실

제 프로젝트에 직접 적용할 수 있도록 임베디드 하드웨어 시스템,

소프트웨어 시스템, 개발환경 및 애플리케이션 등에 관한 포괄적

인 정보를 제공하는데 초점을 맞추고 있습니다.

정기구독문의

Tel:82-2-835-2100∙Fax:82-2-835-2166

담당:우미정

Real-TReal-Timeime

Real-Time

Real-Time

창간을 준비하며Embedded World로의 초

Around the Embedded

ETC KOREA, 임베디드 시스템 전문 행사로 자리 굳혀

Technical Feature경쟁력 있는 임베디드시스템설계

임베디드운 체제의 특징과 선정

반도체 시장의‘골드러시’SoC

기술의 조건과 과제Embedded C++이란 무엇인가?

비판적 입장에서의 이해Product Feature저가형 플래시기반 8비트 MCU

Nitron 68HC908QT/QY

창간예비호 November 2002Real-Time

Real-Time

Real-Time

COVER STORY“임베디드 시스템, 전자산업

‘정복자’로 급부상한다”

Embedded Technology 2002 현장보고

일본 요코하마발 임베디드 열풍“거세다”

TECHNICAL FEATURE

임베디드 실시간 JAVA 활용마이크로프로세스 응용 엔지니어를 위한 ANSI C

FPGA 온칩 디버그의 진화FPGA 토확장“성역은 없다”PRODUCT FEATURE

실시간 OS Qplus와 통합개발환경 EstoBUSINESS ADVICE

“SoC, 멀리보고 크게 생각하는 사람만이 할 수 있다”

Vol. 1 January 2003창간호

136

April 2003

광고문의 T.835-2100 F.835-2166

발행처 (주)테크월드 서울시 등포구 림3동 682-2

발행일매월 20일

인쇄처뉴우성인쇄(주)

등록 No.문화 라 09190

등록일자 2002년 10월 5일

정가 8,000원

Real-Time Embedded World는 한국간행물윤리위원회의 도서잡지 윤리강령 및

잡지 윤리실천요강을 준수합니다.

본지에 실린 과 사진, 그림은 별도 저작권자가 명기되어 있지 않은 경우“Real-

Time Embedded World가 그 저작권자이므로 무단사용 및 복제를 금합니다.

만드는 사람들

발행인 박한식 hspark@techworld.co.kr

총괄이사 성 화 yhsung@techworld.co.kr

편집부 편집장 / 윤범진 bjyoon@techworld.co.kr

기자 / 최찬용 cco@techworld.co.kr

기자 / 손 규 ursoqt@techworld.co.kr

통합마케팅사업부 차장 / 이 훈 yhlee@techworld.co.kr

차장 / 김홍석 hskim@techworld.co.kr

차장 / 조중경 chris@techworld.co.kr

리 / 조용진 yjcho@techworld.co.kr

리 / 유봉길 bkyoo@techworld.co.kr

이중호 jholee@techworld.co.kr

김원선 wskim@techworld.co.kr

김완규 wgkim@techworld.co.kr

국제/컨벤션사업부 이사 / 유승목 ysmok@techworld.co.kr

제작 이사 / 최성용 sychoi@techworld.co.kr

디자인실 실장 / 소연주 cocomo2000@techworld.co.kr

주임 / 신혜옥 hos@techworld.co.kr

이지현 wbb79@techworld.co.kr

정민애 mint@techworld.co.kr

오 주 wood@techworld.co.kr

박 은 pyeun@techworld.co.kr

인터넷사업부 팀장 / 가순필 kaka2001@techworld.co.kr

황규인 kins92@techworld.co.kr

독자서비스 우미정 mjwoo729@techworld.co.kr

AD INDEXADVERTISER PAGE NO. E-MAIL FAX NO. WEBSITE

Aijisystem 1, 2, 3, 21 openice@aijisystem.com 82 31 223 6613 www.aijisystem.com

COSMO Inc. 27 jhcho@cosmo.re.kr 82 42 538 2804 www.cosmo.co.kr

Cynetec 15 wjkim@cynetec.co.kr 82 2 2659 1317 www.cynetec.co.kr

Dongyung Int’̀l Travel Service INC. 5, 16, 17 webmaster@expowel.com 82 2 773 1320 www.dongyangtour.com

ESC/SF 2003 Cover1, 17 www.esconline.com/sf

Hasom IT 13 info@hasom.com 82 2 701 6496 www.hasom.com

Hnabitsoft 19 epdf@hanbitsoft.co.kr www.hanbitsoft.co.kr

HUINC CO., Ltd. 7 sales@huins.com 82 2 575 2777 www.huins.com

Meritech CO., Ltd. 9 meritech@meritech.co.kr 82 31 377 8209 www.meritech.co.kr

NI Cover 2 infokorea@ni.com 82 2 596 7455 www.nik.co.kr

Tektronix E Cover 2 jonp@tek.com 82 2 528 0740 www.tektronix.com

TNMTech CO., Ltd 28, 29 info@tnmtech.co.kr 82 2 6678 0121 www.tnmtech.co.kr

Twintech Instrument Cover 3 twint@hitel.net 82 2 3424 6486 www.twintech21.co.kr

Vitals system Cover4, 11 webmaster@vitals.co.kr 82 31 205 0872 www.vitals.co.kr

Real-Time

Real-Time

2003년 3월 20일 /통권 4호 /2002년 10월 05일 등록번호 라-09190호 /발행처: (주)테크월드 서울시 등포구 림3동 682-2호 TEL:835-2100(代) 가격:8000원

임베디드월드, 전자신문사, 임베디드소프트웨어산업협의회