확장성, 효율성, 프로그래밍 능력은 가전제품에서 cell 프로세서를 사용하기 위한 본질적인 이유다. real-time 자원 스케줄러 프로세서 코어를 가상화하고, 시스템 레벨에서 real-time 요구가 있는 애플리케이션을 안전하게 한다.
이 특징들은 플랫폼 콘트롤 리소스 사용과 cell 프로세서에서 실행하는 전원관리 특징을 돕는다.

오늘날, 디지털 미디어 애플리케이션은 소비자 시장에서 뜨거운 이슈 중에 하나다. 이 애플리케이션을 위해서는 가전제품은 3 가지 요건을 만족시켜야 한다. 품질, 유연성, 낮은 전력소비가 그것이다. 저장용량과 네트워크 대역폭의 증가로서 비디오와 오디오의 화질 역시 향상되었다. 고화질의 비디오와 오디오의 프로세싱은 많은 계산성능을 필요로 한다. 소비자 시장에서는 현재 많은 비디오와 오디오 포맷(MPEG-2, MPEG-4, and H.264)들이 있고, 계속 성장하고 있다.
가전제품은 유연한 방법으로 이들 포맷들을 지원해야 한다. 가전제품은 주로 거실과 작고 조용한 곳에서 사용한다. 전력소비는 작고 조용한 쿨링 시스템으로도 충분할 정도로 낮아야 한다. 이들 요구조건을 고려하면, 현재 가전제품은 강력하고, 유연성있고, 효율적이어야 한다.

cell 프로세서는 칩에 여러개의 프로세서 코어를 가지고 있으며, 성능, 유연성 그리고 에너지 효율성의 풍부함으로서 이들 요구를 만족시킬 수 있다.
cell 프로세서가 에너지 효율적으로 디자인 되었다고 할지라도, 전원관리의 특징은 전력 소비를 줄이기 위해서 반드시 활성화 해야 한다.
cell 프로세서의 연산 능력을 충분히 사용하기 위해서는 프로그래머가 애플리케이션을 멀티쓰레드로 나누어야하고 각 쓰레드는 cell 프로세서에서 수행되고 있는 프로세서 코어들에 할당된다. 가전제품 상에서 수행되는 애플리케이션은 보통 real-time 이고, 쓰레드 스케줄링은 real-time 조건을 만족시키기 위해서 중요하다.
반면에, real-time 시스템들은 전원관리 특징을 반드시 고려해야 한다.)예를 들어 프로세서 코어에 쓰레드가 할당될 때, 셧다운 되고 느려지는 것)
전원 관리 특징 오버헤드가 변하는 것 때문에, 쓰레드 할당은 반드시 변화의 횟수를 줄이기 위해 주의깊게 해야 한다.
프로세서가 좀 더 강력하게 됨으로서, 애플리케이션의 타입과 가전제품 상에서 동작하는 쓰레드의 갯수는 매우 커진다. 소프트웨어 플랫폼은 가전제품의 개발비용을 줄이기 위해서 프로그래밍성이 반드시 발달해야 한다. 이것을 고려하면, 우리는 cell 프로세서를 위한 real-time 소프트웨어 플랫폼을 개발되어야 한다. 프로세싱 리소스의 가상화를 통하여, real-time 리소스 스케줄러는 확장성, 효율성, 프로그래밍성이 발달했다.

그림 1 은 cell 프로세서의 실행상태를 나타내고 있다. 프로세서는 하나의 power processor element(PPE), 8 개의 synergistic(상승적인) processor elements(SPEs), 메모리 인터페이스 콘트롤러(MIC), i/o 인터페이스(IOC), 그리고 element interface bus(EIB) 로 구성된다.
PPE 는 power 아키텍처 기반의 범용 프로세서 코어이다. 이것은 64 bit 레지스터, vector multimedia extension(VMX) register, 512 Kbyte L2 cache 를 가지고 있다. SPE 는 mediaprocessor core 이고, 128 bit register, 4-way single-instruction multiple-data(SIMD) 명령어들, 256 Kbyte local storage(LS), 메모리 플로우 컨트롤러에 direct momory access(DMA) 장착되어 있다.
PPE 는 예를 들면, 리눅스와 같은 범용 운영체제를 실행할 수 있다. SPE 는 연산(계산) 엔진으로서 동작한다.

우리의 타겟 제품들, 디지털 TV, 하드 디스크 드라이브와 HD DVD 레코더들, 홈서버를 포함하는 디지털 가전제품이다. 디지털 가전제품 상에서 동작하는 digital-media 애플리케이션은 mediaprocessing 엔진이 요구된다. 디자이너(designers)는 cell 프로세서의 소프트웨어 엔진의 도구이다.
소프트웨어 엔진들은 예를 들면, MPEG-2, H.264, Advanced Audio Coding(AAC), Audio Code 3 같은 비디오, 오디오 포맷을 처리한다.
오늘날, 이것들은 디지털 비디오의 많은 소스이다. 그러므로 multistream 능력은 현재 디지털 가전제품의 가장 중요한 특징이다.

그림 2 를 보면 cell 프로세서 기반의 가전제품의 예를 보여주고 있다. 소프트웨어 엔진은 예를 들면, GUI, playback, recoding, multiiple stream 을 제어하기 위해서 동시에 수행하는 것을 위함이다. 랜더링 엔진은 그것들의 출력과 높은 선명도 출력의 비디오 프레임을 조립한다.
각 소프트웨어 엔진은 계속적으로 안정된 스트림 프로세싱을 유지하기 위해서 real-time 제약을 가진다. 그러므로 디지털 가전제품 상에서 수행하는 소프트웨어 플랫폼은 반드시 또한 real-time 시스템이어야 한다.

가전제품을 위해서는, mediaprocessor 의 전력 소비는 중요한 특징이다. cell 프로세서의 실행은 전력 소비의 효율성과 전원관리 특징을 고려해야 한다.
전원 관리에 깔린 기본 아이디어는 프로세서가 사용하지 않을 때에 프로세서의 클럭을 끄거나 느리게 하는 것이다. cell 프로세서가 칩에 여러개의 프로세서 코어들을 가진 이래로, 하나 또는 그 이상의 프로세서 코어는 어떤 시간에 idle 할 수 있다. 전원관리의 결점 중에 하나는 변화의 비용이 높다는 것이다. 그래서 효율적인 전원 관리는 on 과 off(또는 빠르고 느린 것) 사이의 변화 시간을 무시할 수 없다.
반면에 real-time 시스템으로서 가전제품을 위해서 애플리케이션 쓰레드의 실행 시간은 애플리케이션을 안정시키기 위해서 중요하다.
만일 프로그래머가 우선순위로서 실행시간을 조건으로 한다면, 시스템은 타이밍을 바꿀 수 없다. 게다가 쓰레드의 갯수가 스트림의 갯수가 바뀔 때, 동적으로 바뀐다. 실행시간을 바꾸거나 , 쓰레드들의 할당된 프로세서 코어를 바꾸지 않고 심지어 작업 부하가 감소했을 때도 프로세서는 idle 하기 위해 return(돌아갈 수) 없다.
그러므로, 시스템은 쓰레드를 재스케줄하고, 전원관리 특징을 사용하기 위해 실행 타이밍을 콘트롤한다.
우리는 소프트웨어 플랫폼과 전원관리와 real-time 시스템 둘 다의 관점으로 부터 수행하기위해 디자인된다. 그것은 real-time 시스템을 위한 콘트롤성과 프로그래밍성의 새로운 밸런스(균형)를 이해하기위해 새로운 프로그래밍 모델을 제공한다. SPE 가상화와 real-time 리소스 스케줄러를 사용함으로서.
스케줄러는 SPEs 와 SPEs 상의 쓰레드를 스케줄을 가상화한다. 소프트웨어 엔진의 real-time 제약을 만족시키고 cell 프로세서의 전원관리 특징을 real-time 시스템에 최적화하는 것으로.

cell 프로세서를 위한 우리의 real-time 소프트웨어 플랫폼은 2 가지의 중요한 특징을 가지고 있다. 멀티 레이어 프로그래밍 모델과 real-time 리소스 스케줄러가 그것이다. 멀티 레이어 프로그래밍 모델은 PPE 와 SPE 프로그램들을 지원한다. 프로그래머들은 SPE 모듈, 쓰레드, overlay, 유즈 케이스에 따른 것과 함께 SPE 프로그램을 write 할 수 있다. real-time 리소스 스케줄러는 모든 SPEs 을 가상화하고, SPEs 상의 SPE 쓰레드들을 스케줄 한다.

그림 3 은 real-time 소프트웨어 플랫폼의 소프트웨어 아키텍처의 개요를 보여주고 있다. 운영체제 커널은 PPE 위에 있고, 리소스 스케줄러는 커널 안에서 동작한다. 디지털 media 애플리케이션과 그것의 PPE 모듈들은 운영체제 상에서 실행된다. PPE 모듈은 주로 범용 프로세싱이나 i/o 핸들링을 목적으로 한다. SPE 모듈들은 SPEs 상에서 동작하고, 주로 디지털 media 프로세싱을 목적으로 한다. 리소스 스케줄러는 SPE 모듈들의 모든 SPE 쓰레드를 스케줄링하는 것을 제어한다.

멀티 레이어 프로그래밍 모델은 우리가 cell 프로세서에서 PPE 와 SPE 둘다 지원하기 위해 디자인되었다. PPE 를 위해서 그것은 PPE 모듈과 쓰레드, 보통 운영체제를 통해 실행되는 쓰레드 또는 태스크들을 지원한다. SPE 를 위해서 프로그래밍 모델은 3 개의 레이어를 가진다. 모듈, 쓰레드, 그리고 overlay. 그림 4 는 레이어들 사이에서 관계를 보여준다.
우리는 소프트웨어 엔진의 부분을 위한 모델 SPE 모듈을 가정하고 소개했다. 프로그래머는 거의 하나의 SPE 안에 모든 비디오 코덱이 수행할 수 있다. 그러나 높은 계산을 요구하는 H.264 코덱은 여러개의 SPE 쓰레드와 함께 수행된다. 여기서 SPE 쓰레드는 여러개의 SPEs 를 사용한다.
우리의 플랫폼은 투명한 SPE 가상화 발전시키기 위해, 컨텍스트를 저장과 복원을 지원한다.
local 저장장치의 용량제한을 이기기 위해서는, 우리는 SPE overlay 를 지원한다. 장작된 DMA 콘트롤러는 PPE 의 개입없이 LS 에서 text 와 data 를 대신할 수 있다. 프로그래머들은 그러므로 가벼운 컨텍스트 스위칭으로서 SPE overlay 를 사용할 수 있다.

그림 5 는 스트림 프로세싱 모델의 예를 보여주고 있다. 소프트웨어 엔진이 media 프로세싱을 수행하는 것은 스트림 프로세싱 모델과 함께 디자인되어진 것이다. 각 모듈은 데이터를 입력받고, 그것을 처리하고, 출력으로 결과를 내보낸다. 모든 모듈들은 데이터 스트림과 함께 연결된다.

스트림 프로세싱은 PPE 와 SPE 모듈로 구성되어 있다. 그림 5 에서 타원형은 PPE 모듈이고, 6 각형은 SPE 모듈이다. 예를 들어, SPE 모듈은 stream demmux 라고 불리고, 하나의 입력 스트림과 두 개의 출력 스트림을 가지고 있다. 모듈 입력은 디지털 컨텐츠(내용)와 video elementary stream(ES) 와 audio ES 안에서 디멀티플랙서한다. 그 다음에 모듈은 비디오 디코더와 오디오 디코더로 비디오 ES 와 오디오 ES 를 출력한다.
그림 6 은 SPE 모듈의 스케줄링 그림을 보여주고 있다. 하나 또는 그 이상의 SPE 쓰레드들은 SPE 모듈을 수행한다.
SPE 모듈의 SPE 쓰레드들은 SPE 쓰레드 중에 동기화의 지연시간을 줄이기 위해 항상 동시에 SPEs 를 스케줄링 한다. 이런 특징을 gang 스케줄링이라고 한다. 만일 SPE 쓰레드의 동기화 목표가 신속히 처리되지 못한다면, 스케줄링은 SPE 상의 SPE 쓰레드를 신속히 처리하기 위해서 스케줄링이 요구된다.
스케줄링과 SPE 쓰레드를 신속히 처리하는 것의 오버헤드는 크다. 만일 동기화가 많이 발생한다면.
SPE 모듈의 SPE 쓰레드들 중에서 동기화 하는 것이 일반적으로 많이 일어나게 되면, 오버헤드는 이슈(문제)가 된다.
오버헤드를 줄이기 위해서 스케줄러는 동시에 SPE 모듈의 SPE 쓰레드를 스케줄링하고 신속히 처리한다. 그리고 스핀락은 SPE 쓰레드들 중에서 동기화를 수행할 수 있다. 타겟 SPE 쓰레드가 항상 나란히 실행되기 때문에.

SPE 상에서 동작하는 소프트웨어는 real-time 시스템의 중요한 컨포넌트이고, 소프트웨어의 프로그래밍성은 cell 프로세서의 모든 성능을 실현하기 위해서 중요하다. 게다가 SPE 컨트롤기능은 real-time 시스템에서 전원 관리를 위해 중요하다. 우리는 SPE 가상화와 SPE 쓰레드 모델이 요구사항을 만족하기위해 디자인했다.
SPE 소프트웨어를 개발하기 위해서, SPE 툴체인은 C, C++ 컴파일러 그리고 디버거를 사용가능하다. 프로그래머는 컴파일러가 본질적으로 지원하는 SPE SIMD 기능을 사용할 수 있다. SPE 소프트웨어는 각 SPE 에 하드웨어 컨포넌트를 붙여서 직접적으로 사용할 수 있다. 예를 들면, 장착된 DMA 컨트롤러.
SPE 소프트웨어를 위한 이 레벨의 프로그래밍성을 유지하기 위해서는, 이 레벨의 SPE 가상화는 SPE 쓰레드를 거쳐야 한다.
SPE 쓰레드는 SPE 상에서 동작하고 있는 실행 내용(context)을 가상화 시킨다. SPE 레지스터, LS image, 우수한 DMA 명령어들을 포함한 SPE 쓰레드의 내용(context)은 DMA 큐에 상주한다. 가상화와 컨텍스트 스위칭의 하드웨어 투명성을 달성하기 위해서는 스케줄러가 컨텍스트가 발생했을 때, 전체의 컨텍스트와 복원을 저장해야 한다.

오버레이는 가상 메모리전에 사용된다. 운영체제에서 선택한다. 가상 메모리 기능 또는 SPU 의 synergistic execution unit(SXU) 와 LS 사이의 MMU 도 아닌, 우리는 LS 사이즈의 제한을 극복하기 위해서 오버레이를 채택했다.
SPE 오버레이를 지원하기 위해서 real-time 소프트웨어는 메인 메모리상에 SPE overlay 프로그램을 로드한다. 각 프로그램의 외부 레퍼런스(참조)를 분석한다. LS 상에 이미 로드된 외부 함수를 호출하기 위해서 프로그램들을 허가한다. SPE 오버레이를 사용하는 SPE 쓰레드가 시작할 때, 스케줄러는 LS 상의 메인 프로그램을 로드하고 이 프로그램은 첫번째 프로그램으로서 실행된다. 프로그램의 진행에 의하면, 오버레이 라이브러리는 SPE 상에서 동작한다. SPE 는 계속 프로세싱하기 위한 LS 안에 메인 메모리로 부터 적당한 오버레이 프로그램을 로드한다.

멀티레이어 프로그래밍 모델과 소프트웨어 엔진의 real-time 요구를 지속하기를 실현하기 위해서, 우리는 real-time 리소스 스케줄러를 개발했다.
스케줄러는 리눅스와 PPE 상에서 동작하는 real-time 운영체제 같은 현재 운영체제로 확장한다.
우리의 스케줄러를 사용하는 것은 현존하는 운영체제가 반드시 오직 cell 프로세서의 SPEs 를 잘 다루기 위해서 연결코드(glue code)를 사용해야 한다.
SPE 이용을 개선하기 위해서는 스케줄러는 use case 의 2 가지 타입으로서 SPEs 를 사용해야 한다.: 시분할과 전용(dedicated).
시분할(time-shared) case 는 SPE 쓰레드를 위한 것으로서, 하나의 SPE 보다 적은 성능을 요구한다. 시분할 SPE 는 SPE 쓰레드들 사이에서 공유된다. 그리고 어떤 SPE 쓰레드는 스케줄 될 수 있고, SPE 상에서 실행될 수 있다. 반면에 전용 SPE 는 그것의 성능을 개발하기위해서 하나의 SEP 를 요구하는 SPE 쓰레드를 제어한다. 전용 SPE 는 컨텍스트 스위칭 오버헤드를 줄이기 위하여 SPE 쓰레드를 명확히 해야할 의무가 있다.

스케줄러에서 실행되는 real-time 스케줄링 알고리즘은 branch and bound 알고리즘을 기반으로 한다. 이것은 critical-path 길이에 따른 발견적 branch 선택을 사용한다. 알고리즘은 스케줄링이 가능한지 또는
새로운 SPE 모듈을 받아들이기 전에 파라미터를 스케줄링하고 모든 SPE 모듈의 real-time 요구를 안전하게 하는 것이 아닌지 찾아낸다.

소프트웨어 엔진 때문에 real-time 요구를 명세하는 것은 프로그래머들은 스케줄링 파라미터를 리소스 스케줄러로 넘긴다. 그림 7 을 보면, 스케줄링 파라미터의 예가 있다. 파라미터는 SPE 쓰레드의 수를 포함하고 SPEs 의 프로세싱 비율, 그리고 SPE 모듈 사이의 선행조건을 포함한다.
SPE 쓰레드의 수를 아는 것은 동시에 수행하는 SPE 모듈의 SPE 쓰레드들이 일치하는 것을 명세할 수 있다.
SPEs 의 프로세싱 비율과 시스템 주기를 아는 것은 각 SPE 쓰레드의 할당된 실행의 양의 계산을 허가한다. 일반적으로 시스템 주기가 짧을 때, 소프트웨어 엔진의 메모리 사용량은 또한 적다. 반면에 긴 시스템 주기는 컨텍스트 스위칭 오버헤드를 만든다. 상대적으로 작고, 덜 중요하다.
요구되는 성능의 비율을 나타내기 때문에 시스템은 메모리 이용과 프로세서의 성능에 따라서 시스템 주기를 바꿀 수 있다.
게다가, SPEs 의 클럭이 바뀌면, 스케줄러는 실행의 양을 바꿀 수 있다. SPE 쓰레드의 요구되는 프로세서 성능을 유지하기 위하여.
SPE 모듈 사이의 선행 제약은 SPE 모듈의 순차적 실행을 정의하는 것을 도울 수 있다. 선행 제약이 데이터 입출력의 순서를 유지하는 것을 도와주기 때문에 소프트웨어 엔진은 SPE 모듈 사이의 single 버퍼를 사용할 수 있다. 메모리 사용을 억압하는.

선행 제약을 사용하기 위해서는, 소프트웨어 엔진은 data 프로세싱은 각 SPE 모듈을 한 단계씩 진행한다. 데이터 프로세싱의 길이가 길어지게 되고, 만일 critical-path 길이가 SPE 의 100 퍼센트를 초과하면, 소프트웨어 엔진은 프로세싱 체인 단계를 쪼갠다. 그리고 소프트웨어 파이브라이닝이 요구된다.
그림 7 에서 critical path 는 demultiplexer,video 디코더, video 프로세서로 구성된다.
critical-path 길이가 110 퍼센트인 이래로, 프로그래머는 반드시 stage path 를 쪼개야한다. 각 SPE 모듈은 pipeline 단계의 유닛이 될 수 있고, 우리는 그림 7 의 점이 있는 수직선에 소프트웨어 엔진을 쪼갤 수 있다.
critical-path 길이를 100 퍼센트보다 짧게 유지하기 위해서 최적화 후에 소프트웨어 파이프라인은 2 개의 단계, demultiplexer 과 video 디코더 사이의 쪼개진다.

그림 8 을 보면 그림 7 의 소프트웨어 엔진을 위한 결과를 스케줄링하는 것을 보이고 있다.
이 그림에서는 모든 SPEs 가 시간 분할을 하고, 각 box 는 SPE 상에서 수행중인 SPE 쓰레드를 보여준다.
시간 분할 상의 모든 SPE 쓰레드는 주기적으로 스케줄링 되고,