어떤 일이든 마찬가지 겠지만, 일에는 “목적”과 “목표”가 있고, “제약조건”이 있기 마련이다. Mobile SoC (System on a Chip) 기획에서도 마찬가지 인듯 하다.

이게 시장의 요구사항이다.

• BGM
• 12M JPEG Capture
• Full HD Encoding
• TV-Out Preview with HDMI
• 3D UI

이 모든게 동시에 가능해야 한다.

즉, 배경음악을 들으면서, Full HD 동영상을 찍고 실시간으로 TV 에서 프리뷰하면서, 중간에 맘에 드는 장면은 JPEG 정지영상으로 남겨 놓는다는 의미이다. 이 모든 것들을 조작하기 위한 UI는 3D 로 되어야 한다는 것이다. 이 괴물은 어떤 디바이스일까? 스마트폰? MID? 모르겠다. 어쨌건 구현 가능성을 따져 봐야 한다.

구현가능성은 다음 두 가지로 따져 볼 수 있다.

• 기술을 너무 앞서 나가는가? (현존하는 기술로 풀 수 없는가?)
• 구현할 수 있는 기술은 존재하지만, 내가/우리가 가지고 있지 않은가? (개발원가가 높아지겠지만, 라이센스-인 하면 구현 불가능하지 않다.)

SoC 에서 성능적으로 가장 문제가 되는 부분은 2가지다.

• CPU MIPS
• Bus

주) MIPS Million Instruction Per Second, MHz 라고 쓰는 것이 정확하지만 산업에서는 1 MHz=1 MIPS 로 그냥 사용한다.

전류 소모가 요구사항에 안들어간 것이 다행이다. Mobile 용 배터리 800mAh x 3.7V = (대략) 3,000mWH. 모르긴 해도 30분도 못 버틸 것이다.

JPEG, Encoding, 3D 등은 모두 전용 Hardware 로 돌리기 때문에 CPU 에 큰 부담이 없다. Software Audio Codec 을 쓰는 BGM 을 위한 약간의 MIPS, Application/UI 등의 Software 로 처리해야 하는 부분이 차지하는 MIPS, System 의 안정적 동작을 위한 10% 정도의 System Idle 을 포함하여 CPU Clock Speed 를 결정할 수 있다.

일반적인 Video Encoding Process 는 Motion Estimation, Motion Vector 계산, 양자화 순으로 진행된다. CPU 및 Memory 와 가장 많은 Bandwidth 를 차지하는 것이 Motion Estimation 이다. 왜냐하면, 영상의 x 축 앞뒤 30pixel, y 축 앞뒤 30pixel 을 모두 예측하고 그 정보를 CPU 또는 Memory 와 주고 받아야 하기 때문이다.

D1 (720*480) 기준 인코딩 과정에서 Motion Estimation 에만 필요한 Bandwidth는 40~60Mbps. 계산해 보자.

• Full HD: 1920x1080=2,073,600
• D1: 720*480=345,600
• Full HD/D1 = 6배

주) Screen Resolution http://commons.wikimedia.org/wiki/File:Vector_Video_Standards2.svg

딱, 6배다. 계산상으로는 240~360Mbps. 게다가, 1080p Display Unit 에서 40Mbps@D1x6배 정도의 Bandwidth 가 필요하니, 총 합이 480~720Mbps. 내가 확인할 수 있는 정보는 이 정도까지이다. 3D 나 HDMI 출력 등에 필요한 Bandwidth 는 확인된 바가 없다.

인코딩만, 그것도 상위 Application 을 제외한 코덱만 이 정도라면…현존하는 기술로는 힘들다는 얘기인가? 모르겠다. 현재 Mobile 에서 사용하는 Bus 는 100~200MHz @ x32bit 정도. 계산하면, 3200~6400Mbps.

PC(x86) Domain 에서는 1333MHz Bus 같은 것들이 있지만, ARM World 에서는 그렇게 제약조건 (시스템 자원) 이 너그럽지 않다.

그러면, 두가지 결정이 남는다.

• (어떻게든) 시장에서 요구하는 제품을 만들어 볼 것인가?
• (특정 시장이나 고객의 요구사항을 잊어 버리고) 우리가 만들 수 있는 제품을 만들 것인가?