KR20040036945A - 하이 데이터 레이트 신호 전송을 위한 통신 프로토콜 및인터페이스의 생성 및 구현 - Google Patents

Abstract

디지털 제어 및 프리젠테이션 데이터의 사전선택된 세트를 전송하는 통신 프로토콜을 형성하도록 공동으로 링크되는 패킷 구조체를 이용한 통신 경로를 통하여 호스트와 클라이언트 간에 디지털 데이터를 전송하는 데이터 인터페이스가 개시되어 있다. 통신 프로토콜을 형성하는 패킷을 생성 및 송수신하며, 디지털 데이터를, 이들 중 하나 이상이 호스트 디바이스에 상주하면서 통신 경로를 통하여 클라이언트에 접속되는 하나 이상의 타입의 데이터 패킷으로 형성하도록 구성된 링크 제어기에 의해, 신호 프로토콜이 이용된다. 이 인터페이스는 단기간의 "시리얼" 타입 데이터 링크를 통하여, 비용효율이 높고 저전력이며 양방향의 고속 데이터 전송 메카니즘을 제공하는데, 이 데이터 링크는 착용가능한 마이크로 디스플레이를 휴대용 컴퓨터 및 무선 통신장치와 같은 디스플레이 엘리먼트에 접속하는데 특히 유용한 소규모 커넥터 및 얇은 가요성 캐이블을 갖는 구현을 자체적으로 제공한다.

Description

하이 데이터 레이트 신호 전송을 위한 통신 프로토콜 및 인터페이스의 생성 및 구현{GENERATING AND IMPLEMENTING A COMMUNICATION PROTOCOL AND INTERFACE FOR HIGH DATA RATE SIGNAL TRANSFER}

관련 출원의 상호 참조

이 출원은 2001년 12월 14일 자로 출원된 미국 특허 번호 10/020,520 으로 전환되어 계류중인, 2000년 12원 15일자로 출원된 미국 특허 가출원 번호 60/255,833, 2001년 9월 6일자로 출원되어 계류중인 미국 특허 가출원 번호 60/317,858, 2002년 2월 13일자로 출원되어 계류중인 미국 특허 가출원 번호 60/356,892 의 우선권 이익을 주장하며, 이 출원들은 여기서 완전히 참조하여 병합될 것이다

발명의 배경

Ⅰ. 발명의 분야

본 발명은 높은 데이터 전송률로 호스트 통신장치와 클라이언트 음성/시각 프리젠테이션 (presentation) 디바이스 사이에서의 신호들을 통신하기 위한 디지탈 신호 프로토콜 및 프로세스에 관한 것이다. 더욱더 자세하게는, 본 발명은 낮은 파워의 높은 데이터 레이트 전송 메커니즘을 이용하여 무선 디바이스에서 마이크로-디스플레이 유닛 또는 다른 프리젠테이션 디바이스로 멀티매체 및 다른 타입의 디지탈 신호들을 전송하는 기술에 관한 것이다.

Ⅱ. 관련 기술

컴퓨터, 전자 게임 관련 제품, 및 다양한 비디오 기술들 (예를 들어, DVD들 및 높은 선명도 (definition) 의 VCR들) 은 지난 몇년동안 매우 진보하여 몇 몇 타입의 텍스트를 포함할때에도, 매우 더 높은 해상도 (resolution) 스틸, 비디오, 비디오-온-디맨드 (vide0-on-demand), 및 그래픽 이미지들을 최종 사용자들에게 제공한다. 이러한 진보는 높은 선명도 비디오 모니터들, HDTV 모니터들, 또는 특별화된 이미지 프로젝션 구성요소와 같은 높은 해상도의 전자 뷰잉 디바이스들의 사용을 요구했다. CD 타입의 사운드 재생산을 이용할 때, DVD들 및 관련 오디오 신호 출력을 가지는 다른 디바이스들과 같은 고-선명도 또는 고-품질 오디오 데이터와 그런 시각 이미지들과의 결합은 더욱 현실적이고 내용이 충분한, 또는 최종 사용자들을 위한 실제 멀티매체 경험을 만드는데 사용된다. 게다가, MP3 플레이어와 같은 높은 유동성, 고,품질 사운드 시스템들 및 음악 전송 매커니즘들은 최종 사용자들에게 오디오의 프리젠테이션만을 위해 발전되어 왔다.

전형적 비디오 프리젠테이션 시나리오에서 비디오 데이터는 전형적으로 느린 또는 중간이라 불리는 레이트의 현재의 기술들을 이용하여 전송되며, 초당 1 내지 10킬로비트의 단위이다. 이런 데이터는 원하는 뷰잉 디바이스상에서 지연 (더 늦은) 재생을 위해, 순간 또는 더 장기간의 기억 디바이스에 버퍼링되고 저장된다. 예를 들어, 이미지들은 모뎀 또는 인터넷 연결 디바이스을 갖는 컴퓨터상에서 프로그램 레지던트를 이용하는 인터넷을 통해 또는 이용하여 전송될 수 있으며, 이미지를 디지털로 제공하는데 유용한 데이터를 수신하고 송신한다. 유사한 전송은 무선 모뎀이 장착된 휴대용 컴퓨터, 또는 무선 퍼스날 데이터 어시스턴스 (Personal Data Assistance; PDAs), 또는 무선 전화와 같은 무선 디바이스를 이용할 때 발생할 수 있다.

일단 수신되면, 이 데이터는 재생을 위해, 외부 저장 디바이스를 포함하여, RAM 또는 플래쉬 메모리와 같은 메모리 구성요소에, 회로, 또는 디바이스에 국부적으로 저장된다. 데이터 및 이미지 해상도에 의존하여, 재생은 상대적으로 빨리, 또는 장기간 지연되어 제공될 수 있다. 즉, 몇 몇 경우에, 이미지 프리젠테이션은 많은 데이터를 요구하지 않거나, 또는 몇 몇 타입의 버퍼링을 이용하여,매우 작은 또는 낮은 해상도의 이미지를 위한 어느정도의 실시간 재생을 허용하여, 작은 지연후에, 더 많은 자료들이 전송되는 동안에 몇몇 자료들이 전송된다. 전송 링크에 방해가 없다면, 일단 프리젠테이션 제공이 시작되면, 전송은 뷰잉 디바이스의 최종 사용자에게 상당히 투명하다.

여전히 이미지 또는 모션 비디오를 만드는데 이용되는 데이터는 Joint Photographic Experts Group (JPEG) 또는 Motion Picture Experts Group (MPEG), 및 다른 잘 알려진 표준 조직들 또는 매체, 컴퓨터, 및 통신 링크상에서 데이터 전송 레이트를 높이기 위한 통신 산업들에 의해 특정된 것들과 같은 몇 몇 잘 알려진 기술들 중 하나를 이용하여 종종 압축된다. 이것은 주어진 정보 양의 전송을 위해 더 작은 수의 비트를 이용함으로써 이미지 또는 데이터들의 전송을 허용한다.

데이터가 컴퓨터 또는 다른 디바이스와 같은 "로컬" 디바이스에 전송되면,결과적인 정보는 압축이 해제되어 (또는 특별한 디코딩 플레이어를 이용하여 재생되는) 대응하는 가능한 프리젠테이션 해상도 및 제어 구성요소에 기초한 적절한 프리젠테이션을 위해 준비된다. 예를 들어, 비록 원하거나 또는 필요한 만큼, 다양한 다른 해상도들이 일반적으로 가능하다고 해도,X ×Y 픽셀의 스크린 해상도 관점에서 전형적인 컴퓨터 비디오 해상도는 전형적으로 480 ×640에서 600 ×800 을 거쳐 1024 ×1024 까지의 범위이다.

또한, 이미지 제공은 이미지 내용 및 주어진 비디오 제어기의 능력에 영향을 받으며 어떤 사전에 규정된 컬러 수준들 또는 컬러 깊이 (컬러를 생성하기 위해 이용되는 픽셀당 비트) 및 강도 관점에서 이 이미지들을 다루며, 어느 부가적 오버헤드도 사용된다. 예를 들어, 비록 다른 값들과 충돌하더라도,전형적인 컴퓨터 제공은 8 내지 32, 또는 그 이상 픽셀 당 비트 의 어느 곳에서나 다양한 컬러들 (농도 및 색조) 의 제공을 예측할 수 있다.

상기 값으로부터, 주어진 스크린 이미지는 개별적으로 최저에서 최고의 전형적인 해상도들 및 깊이의 범위상에서, 2.45 메가비트 (Mb) 에서 약 33.5 Mb 까지 어느 곳의 전송을 필요로 할 것이다. 비디오 또는 운동 타입 이미지들을 초당 30 초의 레이트로 볼 때, 필요로하는 데이터 양은 초당 약 73.7 내지 1,006 메가비트의 데이터 또는 초당 약 9.21 내지 125.75 메가비트이다. 게다가, 멀티매체 제공을 위해 또는 분리된 고 해상도 오디오 프리젠테이션, CD 성능 음악과 같은 이미지와 관련된 오디오 데이터를 제공할 수 있다. 상호작용하는 커맨드, 제어,또는 신호들을 다루는 부가적 신호가 사용된다. 이 선택의 각각은 데이터를 부가하여 전송되도록 한다. 어느 경우에나, 고 품질 또는 고 해상도 이미지 데이터 및 고 품질 오디오 정보 또는 데이터 신호를 최종 사용자에게 전송하여 내용이 풍부한 경험을 만들때, 높은 데이터 전송 레이트 링크가 제공 구성요소와 그런 타입의 데이터를 제공하도록 구성된 소스 또는 호스트 디바이스사이에서 필요하다.

초당 약 115 킬로바이트 또는 920 킬로바이트의 데이터 레이트는 최근의 시리얼 인터페이스에의해 정형적으로 조정된다. USB 시리얼 인터페이스와 같은 다른 인터페이스들을 12 MBps 레이트의 데이터 전송을 수용하며, Institute of Electrical and Electronics Engineers (IEEE) 1394 표준들을 이용하여 구성된것 과 같은 특별화된 높은 레이트 전송은 100 내지 400 MBps 차수의 레이트에서 발생한다. 그러나, 이러한 레이트는 장래 무선 데이터 디바이스들 및 고 해상도, 풍부한 내용, 휴대용 비디오 디스플레이 또는 오디오 디바이스들을 구동하기 위한 출력 신호를 제공하는 서비스들 용으로 고려되는 상기에서 설명한 원하는 데이터 레이트에 부족하다. 게다가, 이러한 인터페이스들은 동작을 위하여 상당한 양의 호스트 또는 시스템 및 클라이언트 소프트웨어를 필요로한다. 또한, 그들의 소프트웨어 프로토콜 스택들은 특히 모바일 무선 디바이스 또는 전화 애플리케이션들이 고려되는 곳에서, 원하지 않는 양의 오버헤드를 만든다. 또한, 이러한 인터페이스들중 몇 몇은 미를 추구하는 모바일 애플리케이션들, 비용이 더 드는 또는 너무 많은 전력을 소비하는 복잡한 커넥터들에게 너무 무거워서 만족스럽지 않은 부피가 큰 케이블들을 사용한다.

Analog Video Graphics Adapter (VGA), Digital Video Interactive (DVI) 또는 Gigabit Video Interface (GVIF)와 같은 다른 알려진 인터페이스들이 있다. 이러한 처음 두 개는 더 높은 전송 레이트에서 데이터를 처리하는 병렬 타입의 인터페이스이지만, 또한, 무거운 케이블들을 사용하여 몇 와트의 차수에서, 많은 양의 전력을 소비한다. 이러한 특징들중 어느 것도 휴대용 소비자 전자 디바이스의 사용에 적합하지 않다. 세번째 인터페이스도 너무 많은 전력을 소비하여 비싼 또는 부피가 큰 커낵터를 사용한다.

상기 인터페이스들 중 몇 몇 및 다른 매우 높은 레이트 데이터 시스템들/프로토콜들 또는 고정된 설치 컴퓨터 장비를 위한 데이터 전송과 관련된 전송 메커니즘에 대해, 또 다른 주요 결점이 있다. 또한, 원하는 데이터 전송 레이트를 수용하기 위하여 상당한 양의 전력 및/또는 높은 현재 수준에서의 동작을 필요로 한다. 이것은 높은 모바일 소비자 지향 제품을 위한 그런 기술들의 유용성을 감소한다.

일반적으로, 가령 광학 섬유 타입 연결들 및 전송 구성요소와 같은 대체제를 이용하는 그런 데이터 전송 레이트를 수용하기 위해, 많은 양의 부가적 컨버터들 및 실제로 상업적인 소비자 지향 제품대해 원하는 것보다 더욱 복잡하고 비용이 많이 드는 구성요소들을 필요로 한다. 이제까지 광학 시스템의 비싼 속성과는 별도로, 전력 요청 및 복잡성은 라이트웨이트, 낮은 전력, 휴대용 애플리케이션을 위한 범용을 방해한다.

휴대용 또는 모바일 애플리케이션들에게서 부족한 것은 그것이 오디오, 비디오, 또는 높은 모바일 최종 사용자들에 기초한 멀티매체 인지 여부에 상관없이,고 품질의 제공 경험을 제공하는 것이다. 즉, 휴대용,컴퓨터들, 무선 전화들, PDA들,또는 다른 높은 모바일 통신장치들 또는 장비들을 사용할 때, 현재의 비디오 및 오디오 프리젠테이션 시스템 및 간단히 사용되는 디바이스들은 원하는 높은 품질의 수준에서 출력을 전달할 수 없다. 종종, 부족하다고 감지된 품질은 그런 높은 품질의 프리젠테이션 데이터를 전송하는데 필요한 획득할 수 없는 높은 데이터 레이트들의 결과이다. 따라서, 새로운 전송 메커니즘이 데이터를 제공하는 호스트 디바이스와 클라이언트 디스플레이 디바이스 또는 출력을 최종 사용자들에게 제공하는 구성요소 사이의 데이터 처리량을 증가시킨다.

요약

발명이 속하는 분야에서 존재하는 상기 결점, 및 다른 것들은 새로운 프로토콜 및 데이터 전송 메커니즘이 호스트 디바이스와 수신 클라이언트 디바이스 사이에서 데이터를 높은 데이터 레이트로 전송하도록 발전되어 온 본 발명의 실시형태에의해 해결된다.

본 발명의 실시형태의 장점은 매우 탄력적이지만, 덜 복잡하고,낮은 비용, 높은 신뢰도를 가지며 사용 범위내에서 잘 맞으며,매우 견고한 데이터 전송을 위한 기술이 제공된다는 것이다.

본 발명의 실시형태들은 호스트 디바이스와 복수의 또는 일련의 패킷 구조체를 서로 링크하여 사전 설정된 세트의 디지탈 제어 및 호스트와 클라이언트 디바이스 사이의 제공 데이터를 통신하기 위한 통신 프로토콜을 형성하는 통신 경로상의 클라이언트 디바이스사이에서 높은 레이트로 디지탈 데이터를 전송하는 Mobile Display Digital Interface (MDDI) 에 관심을 둔다. 신호 통신 프로토콜 또는 링크층은 호스트 또는 클라이언트 링크 제어기들의 물리층에 의해 사용된다. 호스트 디바이스에 존재하는 하나 이상의 링크 제어기는 통신 경로 또는 링크를 통해 클라이언트 디바이스에 결합되며, 통신 프로토콜을 형성하는 패킷들을 생성, 송신, 및 수신하여, 디지탈 제공 데이터를 하나 이상 타입의 데이터 패킷들로 형성하도록 구성된다. 인터페이스는 호스트와 클라이언트사이에서 양방향 전송을 제공한다.

본 발명의 또 다른 측면에서, 하나 이상의 클라이언트 링크 제어기, 또는 클라이언트 제어기는 클라이언트 디바이스에 배치되어 통신 경로 또는 링크를 통해 호스트 디바이스에 결합된다. 또한, 클라이언트 링크 제어기는 통신 프로토콜을 형성하는 패킷들을 생성, 송신, 및 수신하여, 디지탈 제공 데이터를 하나 이상 타입의 데이터 패킷들로 형성하도록 구성된다. 일반적으로, 호스트 또는 링크 제어기는 커맨드 또는 어떤 타입의 신호 준비 및 조회(inquiry) 프로세싱에서 사용되는 데이터 패킷을 처리하는 상태 기계를 수단으로 사용하지만, 더 늦은 범용 프로세서를 사용하여 데이터 및 통신 프로토콜에서 사용되는 덜 복잡한 패킷들의 일부를 다룬다. 호스트 제어기는 하나 이상의 차동 라인 드라이버들을 포함하지만, 클라이언트 수신기는 통신 경로에 결합된 하나 이상의 차동 라인 수신기들을 포함한다.

다른 변화가능한 길이를 갖는 사전 결정된 많은 수의 패킷들의 사전 규정된 고정된 길이 를 갖는 호스트 및 클라이언트 디바이스들 사이에서 통신되는 매체 프레임들은내에서, 이 패킷들은 그룹을 진다. 이 패킷들 각각은 패킷 길이 필드, 하나 이상의 패켓 데이터 필드, 및 주기적 용장 체크 필드를 포함한다. 서브-프레임 헤저 패킷은 호스트 링크에서 다른 패킷들의 전송 시작시에 전송되거나 위치를 잡는다. 하나 이상의 비디오 스트림 타입 패킷들 및 오디오 스트림 타입 패킷들은 통신 프로토콜에 의해 사용되어,호스트에서 클라이언트 디바이스 사용자에게 제공하기위한 순방향 링크상의 클라이언트으로 비디오 타입 데이터 및 오디오 타입 데이터를 개별적으로 전송한다. 하나 이상의 역방향 링크 캡슐화 (Reverse Link Encapsulation) 타입 패킷들은 통신 프로토콜에 의해 사용되어 클라이언트 디바이스에서 호스트 링크 제어기로 데이터를 전송한다.

필러 (filler) 타입 패킷들은 호스트 링크 제어기에 의해 생성되어 데이터를 갖지 않는 순방향 링크 송신의 기간들을 차지한다. 복수의 다른 패킷들은 통신 프로토콜에 의해 사용되어 비디오 정보를 전송한다. 그런 패킷들은 컬러 맵 (Color Map), 비트 블럭 전송 (Bit Block Transfer), 비트맵 에어리어 필 (Bitmap Area Fill), 비트맵 패턴 필 (Bitmap Pattern Fill), 및 투명 컬러 이네이블 (Transparent Color Enable) 타입 패킷들을 포함한다. 사용자 정의 스트림 타입 패킷들은 통신 프로토콜에 의해 사용되어 인터페이스-사용자 정의 데이터를 전송한다. 키보드 데이터 (Keyboard Data) 및 포인팅 디바이스 데이터 (Pointing Device Data) 타입 패킷들은 통신 프로토콜에 의해 사용되어 상기 클라이언트 디바이스와 관련된 사용자 입력 디바이스로 또는 부터 데이터를 전송한다. 링크 셧다운 (Link Shutdown) 타입 패킷은 통신 프로토콜에 의해 사용되어 상기 통신 경로상의 한 방향으로의 데이터의 전송을 종결한다.

일반적으로, 통신 경로은 일련의 4개 이상의 컨덕터들 및 실드 (shield) 를 갖는 케이블을 포함하거나 또는 사용한다. 몇 몇 실시형태에서, 링크 제어기들은USB 데이터 인터페이스를 포함하며 케이블은 다른 도체와 더불어 USB 타입 인터페이스를 사용한다. 게다가, 프린팅된 와이어들 또는 유연한 도체들이 원하는 대로 사용될 수 있다.

호스트 링크 제어기는 클라이언트 디바이스에서 디스플레이 능력 정보를 요청하여 상기 클라이언트이 어떤 타입의 데이터 및 데이터 레이트를 상기 인터페이스를 통해 수용할 수 있는지 판단한다. 클라이언트 링크 제어기는 디스플레이 또는 프리젠테이션 능력을 하나 이상의 디스플레이 능력 (Display Capabilities) 타입 패킷을 사용하는 호스트 링크 제어기로 통신한다. 멀티플 전송 모드는 통신 프로토콜에 의해 사용되어 각각은 주어진 시간 상에서 병렬로 다른 최대수의 비트 데이터의 전송을 허용하며, 각 모드는 호스트와 클라이언트 링크 제어기 상에서 협상을 통해 선택될 수 있다. 이런한 전송 모드는 동적으로 데이터 전송 중에 적용될 수 있으며, 동일나 모드는 순방향 링크상에서와 같이 역방향 링크 상에서 사용될 필요가 없다.

본 발명의 몇 몇 실시형태의 다른 측면에서, 호스트 디바이스는 무선 전화기, 무선 PDA, 또는 무선 모뎀 이 장착된 휴대용 컴퓨터와 같은 무선 통신장치를 포함한다. 전형적인 클라이언트 디바이스 마이크로-디스플레이 디바이스와 같은 휴대용 비디오 디스플레이, 및/또는 휴대용 오디오 프리젠테이션 시스템을 포함한다. 또한, 호스트는 전송된는 프리젠테이션 또는 멀티매체 데이터를 저장하는 저장 수단 또는 구성요소를 사용하여 클라이언트 디바이스 사용자에게 제공된다.

도면의 간단한 설명

본 발명의 다양한 실시형태의 구조체 및 동작과 더불어, 본 발명의 또 다른 특징이 아래 도면을 참조하여 상세히 설명될 것이다. 도면에서는, 일반적으로, 동일한 참조 부호는 동일한, 기능적으로 유사한, 및/또는 구조적으로 유사한 구성요소 또는 프로세싱 단계를 가리키며, 구성요소가 처음 나타나는 도면은 참조 부호로 자측 상단 숫자로 지시된다.

도 1a 은 본 발명이 휴대용 컴퓨터와 관련되어 사용되는 마이크로-디스플레이 디바이스의 사용을 포함하여 동작할 수 있는 기본적 배경을 도시한다.

도 1b 는 무선 트랜시버와 관련되어 사용되는 마이크로-지스플레이 및 오디오 프리젠테이션 구성요소를 포함하여 본 발명이 동작하는 기본적인 환경을 도시한다.

도 2 는 호스트 및 클라이언트의 상호연결을 갖는 모바일 디지탈 데이터 인터페이스의 대체적인 개념을 도시한다.

도 3 은 클라이언트 디바이스에서 호스트 디바이스로 데이터 전송을 실현하는데 유용한 패킷의 구조체를 도시한다.

도 4 는 MDDI 링크 제어기의 용도 및 타입 Ⅰ및 타입 U 인터페이스를 위한 물리 데이터 링크 컨덕터들을 거쳐 호스트와 클라이언트 사이에서 통과되는 신호의 타입들을 도시한다.

도 5 는 MDDI 링크 제어기의 용도 및 타입 Ⅱ, Ⅲ, 및 Ⅳ 인터페이스를 위한 물리 데이터 링크 컨덕터들을 거쳐 호스트와 클라이언트 사이에서 통과되는 신호의 타입들을 도시한다.

도 6 은 인터페이스 프로토콜을 구현하기 위해 사용되는 프레임의 구조체 및 서브-프레임들을 도시한다.

도 7은 인터페이스 프로토콜을 구현하기 위해 사용되는 패킷들의 일반적 구조체를 도시한다.

도 8 은 서브-프레임 헤더 패킷의 포맷을 도시한다.

도 9 는 필러 패킷의 포맷 및 내용을 도시한다.

도 10 은 비디오 스트림 패킷을 도시한다.

도 11 은 도 10 의 비디오 데이터 포맷 디스크립터의 포맷 및 내용을 도시한다.

도 12 는 패킷의 용도 및 패킷되지 않은 데이터 포맷을 도시한다.

도 13 은 오디오 스트림 패킷의 포맷을 도시한다.

도 14 는 바이트로 정렬되고 패킹된 데이터의 PCM 포맷의 용도를 도시한다.

도 15는 사용자 정의 스트림 패킷의 포맷을 도시한다.

도 16 은 컬러 맵 패킷의 포맷을 도시한다.

도 17 은 역방향 링크 캡슐화 패킷의 포맷을 도시한다.

도 18 은 디스플레이 능력 패킷의 포맷을 도시한다.

도 19 는 키보드 데이터 패킷의 포맷을 도시한다.

도 20 은 포인팅 디바이스 데이터 패킷의 포맷을 도시한다.

도 21 은 링크 셧다운 패킷의 포맷을 도시한다.

도 22 는 디스플레이 요청 및 상태 패킷의 포맷을 도시한다.

도 23 은 비트 블럭 전송 패킷의 포맷을 도시한다.

도 24 는 비트맵 에어리어 필 패킷의 포맷을 도시한다.

도 25 는 비트맵 패턴 필 패킷의 포맷을 도시한다.

도 26 은 통신 링크 데이터 채널 패킷의 포맷을 도시한다.

도 27 은 인터페이스 타입 핸드 오프 요청 패킷의 포맷을 도시한다.

도 28 은 인터페이스 타입 확인 패킷의 포맷을 도시한다.

도 29 는 실행 타입 핸드 오프 패킷의 포맷을 도시한다.

도 30 은 순방향 오디오 채널 인에이블 패킷의 포맷을 도시한다.

도 31 은 역방향 오디오 샘플 레이트 패킷의 포맷을 도시한다.

도 32 은 디지탈 콘텐트 프로텍션 오버헤드 패킷의 포맷을 도시한다.

도 33 은 투명 컬러 인에이블 패킷의 포맷을 도시한다.

도 34 는 라운드 트립 딜레이 측정 패킷의 포맷을 도시한다.

도 35 는 라운드 트립 딜레이 측정 패킷 동안에 이벤트의 타이밍을 도시한다.

도 36 은 본 발명에 유용한 CRC 제너레이터 및 체커의 간단한 구현를 도시한다.

도 37a 은 데이터 패킷을 보낼 때, 도 36의 디바이스에 대한 CRC 신호의 타이밍을 도시한다.

도 37b 데이터 패킷을 수신할 때, 도 36의 디바이스에 대한 CRC 신호의 타이밍을 도시한다.

도 38 은 어떠한 경합없이 전형적인 서비스 요청을 위한 단계를 도시한다.

도 39 는 링크 시작과 경합없이, 링크 재시작 시퀀스가 시작된 후에 주장되는 전형적 서비스를 위한 프로세싱 단계들을 도시한다.

도 40 은 데이터 시퀀스가 DATA-STB 인코딩을 사용하여 어떻게 전송될 수 있는지를 도시한다.

도 41 은 DATA 및 STB 신호들을 호스트의 입력 데이터로부터 생성하여, 그 후, 클라이언트의 데이터를 회복하는데 유용한 회로를 도시한다.

도 42 는 본 발명의 실시형태를 구현하는데 유용한 드라이버들 및 종단 저항 (terminating resistor) 을 도시한다.

도 43 은 호스트로부터 서비스를 보장하도록 클라이언트에 의해 사용되며 그런 서비스를 제공하도록 호스트에의해 사용되는 단계 및 신호 레벨들을 도시한다.

도 44 는 Data0, 다른 데이터 라인들 (DataX), 및 스트로브 라인들 (Stb) 상의 전이 사이에서 상대적인 스페이싱을 도시한다.

도 45 는 호스트가 패킷 송신후에 호스트가 호스트 드라이버를 억제할 때 발생할 수 있는 응답시의 딜레이의 존재를 도시한다.

도 46 은 호스트가 호스트 드라이버로 하여금 패킷을 송신하도록할 때,발생할 수 있는 응답시의 딜레이의 존재를 도시한다.

도 47 은 전송되는 데이터의 타이밍과 스트로브 펄스의 트레일링 에지 사이의 호스트 수신기 입력의 관계를 도시한다.

도 48은 스위칭 특징들 및 역방향 데이터 타이밍에 의해 발전된 대응하는 클라이언트 입력 딜레이를 도시한다.

도 49 는 상태 기계를 사용하는 본 발명을 위해 동기화가 구현될 수 있는 신호 프로세싱 단계들의 높은 수준의 다이어그램을 도시한다.

도 50 은 MDDI를 사용하는 시스템에서 순방향 및 역방향 궤도상에서 신호 프로세싱에 대해 충돌되는 전형적인 양의 딜레이를 도시한다.

도 51 은 마지날 (maginal) 라운들 트립 딜레이 측정을 도시한다.

도 52 는 역방향 링크 데이터 레이트 변화를 도시한다.

도 53 은 다양한 역방향 레이트 디바이저 대 순방향 링크 데이터 레이트의 그래프를 도시한다.

도 54a 및 54b 는 인터페이스의 동작에서 수행되는 단계들을 도시한다.

도 55 는 인터페이스 디바이스 프로세싱 패킷의 개요를 도시한다.

도 56 은 순방향 링크 패킷의 포맷을 도시한다.

도 57 은 타입-Ⅰ 링크 인터페이스에서 전파 (propagation) 딜레이 및 스큐 (skew) 에 대한 전형적인 값을 도시한다.

도 58 은 인터페이스를 통해 예시적인 신호 프로세싱에 대한 타입-Ⅰ링크 상에서 Data, Stb, 및 클록 리커버리 타이밍을 도시한다.

도 59는 타입-Ⅱ, 타입-Ⅲ, 타입-Ⅳ 링크 인터페이스에서 전파 딜레이 및 스큐의 전형적인 값을 도시한다.

도 60a, 60b, 및 60c는 서로에 대해 이상적이며, 이른, 및 늦게 개별적으로두 데이터 신호들 및 MDDI_Stb 의 타이밍을 위한 다른 가능성을 도시한다.

도 61은 타입-Ⅰ/타입-Ⅱ 인터페이스로 사용되는 인터페이스 핀 할당 (assignment) 예시적 커낵터들을 도시한다.

도 62a 및 62b 는 타입-Ⅰ 및 타입-Ⅱ 인터페이스 모두를 위한 가능한 MDDI_Data 및 MDDI_Stb 파형을 도시한다.

실시형태의 상세한 설명

Ⅰ. 개관

본 발명의 일반적인 의도는 아래에서 설명하는 바와 같이 MDDI를 제공하여 결과적으로 비용 효과, 낮은 전력 소비, 호스트 디바이스와 일련의 타입인 데이터 링크 또는 채널 사이에서 좁은 범위의 통신 링크를 거쳐 고 또는 초 고속 데이터 전송을 가능하게 하는 전송 메커니즘을 제공하는 것이다. 이러한 메커니즘은 미니어처 커낵터 및 디스플레이 구성요소 또는 오래가는 마이크로-디스플레이 (고글 또는 프로젝터) 와 같은 디바이스에 특히 유용한 얇은 유연한 케이블을 휴대용 컴퓨터, 무선 통신장치, 또는 오락 디바이스에 구현할 수 있게 한다.

본 발명은 다양한 상황에서 일반적으로 오디오, 비디오, 또는 호스트 또는 그런 데이터가 생성 또는 저장되는 소스 디바이스로부터의 멀티티매체 애플리케이션들을 위한 많은 양의 데이터를 높은 레이트로 클라이언트 디스플레이 또는 프리젠테이션 디바이스로 통신 또는 전송하는데 사용될 수 있다. 아래에서 설명되는 전형적인 애플리케이션은 휴대용 컴퓨터 또는 무선 전화 또는 모뎀으로부터 작은 비디오 스크린과 같은 시각 디스플레이 디바이스 또는 고글 또는 작은 프로젝션 렌즈 및 스크린을 포함하는 헬멧 타입와 같은 오래가는 마이크로-디스플레이 디바이스로의 데이터의 전송이다.

MDDI의 특징 또는 속성 특징은 특정 디스플레이 기술로부터 독립적이다. 이것은 데이터의 내부 구조체, 또는 그것이 구현하는 데이터 또는 커맨드의 기능적 측면에 상관없이 높은 레이트로 데이터를 전송하는 매우 유연한 메커니즘이다. 이것은 전송되는 데이터 패킷의 타이밍이 특정 디스플레이 디바이스의 특징 또는 어떤 디바이스에 대한 독특한 디스플레이 욕망에 응용된도록 또는 A-V 시스템의 결합된 오디오 및 비디오 의 요청을 충족하도록 조절된다. 인터페이스는 선택된 프로토콜을 따르는 한 매우 디스플레이 구성요소 또는 클라이언트 디바이스 애그노스틱 (agnostic)이다. 게다가, 집합된 일련의 링크 데이터 또는 데이터 레이트는 몇몇 차원의 크기로 변할 수 있으며 통신 시스템 또는 호스트 디바이스 설계자가 비용, 전력 요건, 클라이언트 디바이스 복잡성, 및 디스플레이 디바이스 갱신 레이트를 최적화할 수 있다.

데이터 인터페이스는 무선 신호 링크 또는 조그만 케이블 상에서 주로 많은 양의 높은 레이트 데이터를 전송하는데 사용된다. 그러나, 몇 몇 애플리케이션은 광학 기반 링크를 포함하여, 무선 링크를 이용하며, 동일 패킷 및 인터페이스 프로토콜을 위해 발전되어온 데이터 구조체를 이용하여 구성된다면, 낮은 전력 소비 또는 복잡성이 실용적이 되도록 원하는 수준의 전송을 유지할 수 있다.

Ⅱ. 환경

전형적인 애플리케이션은 도 1a 및 1b 에서 보여지며, 여기서 휴대용 또는 랩탑 컴퓨터 (100) 및 무선 전화 또는 PDA 디바이스 (102) 가 도시되어 오디오 재생 시스템 (108) 및 (112) 와 함께 디스플레이 디바이스 (104) 및 (106)가 개별적으로 데이터를 통신한다. 무선 디바이스는 현재 데이터를 수신하거나 미리 특정 양의 멀티매체 타입 데이터를 메모리 구성요소 또는 무선 디바이스의 최종 사용자에 의한 뷰잉및/또는 듣기를 위한 나중의 프리젠테이션을 위한 디바이스에 저장한다. 전형적인 무선 디바이스는 대부분 음성 및 간단한 텍스트 통신을 위해 사용되기 때문에. 다소 작은 디스플레이 스크린 및 디바이스 (102) 사용자에 정보를 통신하기 위한 간단한 오디오 시스템 (통화자) 을 갖는다.

컴퓨터 (100) 은 많은 스크린을 가지지만, 여전히 부적절한 외부 음성 시스템을 가지며 여전히 고 선명도 텔레비젼 또는 영화 스크린과 같은 다른 멀티매체 프리젠테이션 디바이스에 부족하다. 컴퓨터 (100) 은 설명의 목적으로 사용되고, 다른 타입의 프로세서, 상호작용하는 비디오 게임, 또는 소비자 전자 디바이스는 또한 본 발명에 사용될 수 있다. 컴퓨터 (100) 은 무선 모뎀 또는 무선 통신을 위한 디바이스에 설치된 다른 디바이스를 이용할 수 있고, 그러나 또한 그것에 한정되거나 그것에 의하지만은 않으며, 원한다면 케이블 또는 무선 링크를 이용하는 그러한 디바이스에 연결될 수 있다.

이는 더 복잡하거나 "풍부한" 데이터의 프리젠테이션을, 유용하거나 즐거운 경험으로 되지 못하게 한다. 따라서, 엔드 유저에게 정보를 제공하고 최소한 레벨의 원하는 즐거움 또는 긍정적인 경험을 제공하기 위해, 산업은 다른 메커니즘 및 디바이스들을 개발하고 있다.

전술한 바와 같이, 디바이스 (100) 의 엔드 유저에게 정보를 제공하기 위해몇가지 타입의 디스플레이가 개발되었거나 개발되고 있다. 예를 들어, 1 이상의 회사가, 시각적 디스플레이를 제공하기 위해 디바이스 유저의 눈 앞 이미지를 프로젝션할 수 있는 웨어러블 고글 세트를 개발해 왔다. 적절히 위치된 그러한 디바이스가 효율적으로 가상 이미지를 "프로젝션" 할 때, 유저의 눈에 인지됨에 있어서, 이는 시각적 출력을 제공하는 엘리먼트보다 훨씬 크다. 즉, 아주 작은 프로젝션 엘리먼트는 유저의 눈에, 통상적인 LCD 스크린 등에서 가능한 것보다 훨씬 큰 이미지를 보게 한다. 더 큰 가상 스크린 이미지의 이용은, 더 제한된 LCD 스크린 디스플레이에서 가능한 것보다 더 높은 해상도의 이미지를 사용하는 것을 허용한다. 다른 디스플레이 디바이스는, 이에 제한되는 것은 아니지만, 이미지를 표면 등에 프로젝션하기 위해 작은 LCD 스크린 또는 다양한 플랫 패널 디스플레이 엘리먼트, 프로젝션 렌즈 및 디스플레이 드라이버를 포함한다.

또한, 다른 유저에게, 또는 차례로 신호를 다른 곳으로 전송하거나 저장하는 다른 디바이스에게 출력을 제공하기 위해, 무선 디바이스 (102) 또는 컴퓨터 (100) 의 이용과 연결 또는 연관하여 부가적인 엘리먼트가 존재한다. 예를 들어, 데이터는 예를 들어 라이터블 CD 매체 또는 자기 테이프 레코더 등을 이용하여, 나중에 사용하기 위해서 광학적 형태로 플래시 메모리에 저장될 수도 있다

또한, 요즘 여러가지 무선 디바이스 및 컴퓨터는, 다른 진보된 사운드 디코더 및 시스템 뿐만 아니라, 내장 MP3 음악 디코딩 능력을 가진다. 휴대형 컴퓨터는 CD 및 DVD 재생 능력을 일반적인 규칙으로 이용하며, 어떤 컴퓨터는, 사전 녹음된 오디오 파일을 받기 위한 작은 할당 플래시 메모리 리더를 갖는다. 그러한 능력을갖는 것에 대한 이슈는, 디지털 음악 파일은 급격히 증가하는 특성이 풍부한 경험 (feature rich experience) 을 약속하지만, 디코딩 및 재생 프로세스가 보조를 맞출 수 있을 때만 그러하다는 것이다. 디지털 비디오 파일에도 같은 사항이 적용된다.

사운드 재생을 보조하기 위해, 외부 스피커 (114) 가 도 1a 에 도시되어 있으며, 이는 전후 사운드 프로젝션을 위해 서브-우퍼 또는 "서라운드-사운드" 스피커와 같은 부가적인 엘리먼트와 동반될 수 있다. 동시에, 스피커 또는 이어폰 (108) 이, 도 1b 의 서포트 프레임 또는 마이크로-디스플레이 디바이스 (106) 에 내장된 것으로 지시된다. 알려진 것처럼 다른 오디오 또는 사운드 재생 엘리먼트는 전력 증폭 또는 사운드 형성 디바이스를 포함하기 위해 이용될 수 있다.

어떤 경우에는, 전술한 바대로, 데이터 소스로부터 엔드 유저로 하나 이상의 통신 링크 (110) 를 통해, 고품질 또는 고해상도 이미지 데이터 및 고품질 오디오 정보 또는 데이터 신호를 전송하고 싶을 때, 높은 데이터 레이트가 요구된다. 즉, 현재 전송 메커니즘은 통상적으로 원하는 높은 데이터 레이트를 달성하지 못하므로, 전송 링크 (110) 는 데이터 통신에 있어서 전술한 바대로 명확히 잠재적인 보틀넥이며 시스템 성능을 제한한다. 예로 전술한 바대로, 24-32 bits per pixel 의 컬러 뎁스 (color depth) 및 30 fps 의 데이터 레이트를 갖는 1024 x 1024 pixels 와 같은 더 높은 이미지 해상도에서, 데이터 레이트는 755 Mbps 이상을 초과하는 레이트에 접근할 수 있다. 또한, 그러한 이미지는, 오디오 데이터 및 인터랙티브 게임 또는 통신, 또는 다양한 명령, 제어, 또는 신호를 취급하는 잠재적으로 부가적인 신호를 포함하는 멀티매체 프리젠테이션 또는 다양한 명령의 일부분으로 제공될 수 있으며, 또한 양 또는 데이터 및 데이터 레이트를 증가시킨다.

또한, 데이터 링크를 수립하는데에 더 적은 케이블 또는 인터커넥션이 필요하다는 것은 명백하며, 이는 디스플레이와 연관된 모바일 디바이스가 이용하기 쉽고, 더 큰 유저 기반에 의해 사용될 법 하다는 것을 의미한다. 특히, 풀 오디오-비주얼 경험을 수립하는데 이용되는 멀티플 디바이스가 일반적으로 사용되는 경우, 더 자세히는 디스플레이 및 오디오 출력 디바이스의 품질 수준이 증가하는 경우 사실이다.

그러나, 더 높은 데이터 레이트는 데이터 전송에 사용될 수 있는 현재 기술을 초과한다. 필요한 것은, 프리젠테이션 엘리먼트와 데이터 소스 사이의 데이터 전송 링크 또는 통신 경로에 대해서 더 높은 레이트로 데이터를 전송하는 기술이며, 이는 일관되게 가능한 한 낮은 전력, 가벼운 무게, 및 단순하고 경제적인 케이블 구조체를 허용한다. 원하는 저전력 소비, 및 복잡도를 유지하면서도, 이러한 목표 및 모바일, 휴대형, 또는 고정된 장소 디바이스의 어레이가 데이터를 원하는 디스플레이, 마이크로-디스플레이, 또는 오디오 전송 엘리먼트로, 아주 높은 데이터 레이트로 전송하는 다른 목표를 허용하기 위해서, 출원인은 새로운 기술, 즉 방법 또는 장치를 개발했다.

Ⅲ. 하이 레이트 디지털 데이터 인터페이스 시스템 아키텍쳐

새로운 디바이스 인터페이스를 생성하고 효율적으로 이용하기 위해서, 저전력 신호를 이용하여 아주 높은 데이터 전송 레이트를 제공하는 신호 프로토콜 및시스템 아키텍쳐가 만들어졌다. 이 프로토콜은 패킷 및 공통 프레임 구조체, 인터페이스에 부과된 명령 또는 동작 구조체 또는 사전-선택된 데이터 세트 또는 데이터 타입을 통신하기 위한 프로토콜을 형성하는 함께 링크된 구조체, 에 기초한다.

A. 개관

MDDI 링크를 통해 연결된 또는 그를 통해 통신하는 디바이스는 호스트 및 클라이언트라고 불리우며, 통상적으로 클라이언트는 어떤 타입의 디스플레이 디바이스가다. 호스트에서 디스플레이로 가는 데이터는 정방향 (정방향 트래픽 또는 링크라고 불리움) 으로 이동하며, 호스트에 의해 인에이블되는, 디스플레이에서 호스트로 가는 데이터는 역방향 (역방향 트래픽 또는 링크라고 불리움) 으로 이동한다. 이는 도 2 에 도시된 기본 설정에서 설명된다. 도 2 에서, 호스트 (202) 는, 정방향 링크 (208) 및 역방향 링크 (210) 를 포함하는 양방향 통신 채널 (206) 을 이용하여 클라이언트 (204) 에 연결된다. 그러나, 이 채널은, 데이터 전송이 정방향 또는 역방향 링크 동작 사이에서 효율적으로 스위치되는 컨덕터의 일반적인 세트 에 의해 형성된다.

다른 곳에 논의된 것처럼, 호스트는, 본 발명을 이용함으로써 이득을 얻을 수 있는 몇가지 타입의 디바이스를 포함한다. 예를 들어, 호스트 (202) 는 핸드헬드, 랩탑, 또는 유사한 모바일 컴퓨팅 디바이스 형태의 휴대형 컴퓨터일 수 있으며, PDA, 페이징 디바이스, 여러가지 무선전화 또는 모뎀일 수 있다. 다른 방법으로는, 호스트 (202) 는, 휴대형 DVD 또는 CD 플레이어, 또는 게임 플레잉 디바이스와 같은 휴대형 엔터테인먼트 또는 프리젠테이션 디바이스일 수 있다. 동시에, 클라이언트 (204) 는, 정보를 엔드 유저에게 제공하는데에 유용한 여러가지 디바이스를 포함할 수 있다. 예를 들어, 마이크로-디스플레이 통합 고글 또는 안경, 모자나 헬멧에 내장된 프로젝션 디바이스, 창문이나 윈드실드와 같은, 차량에 내장된 작은 스크린 또는 홀로그래픽 엘리먼트, 또는 고품질 사운드 또는 음악을 제공하기 위한 다양한 스피커, 헤드폰 또는 사운드 시스템 등이다. 그러나, 보존이나 수송의 관점에서 또는 재생의 프리젠테이션의 관점에서, 본 발명이 이러한 디바이스에만 한정되지 않는다는 것, 시장에는 엔드 유저에게 고품질 이미지 및 사운드를 제공하기 위해 의도된 다른 많은 디바이스가 있다는 것을, 당업자는 인식할 것이다. 본 발명은, 원하는 유저 경험을 실현하는데에 필요한 높은 데이터 레이트를 제공하는 다양한 디바이스 사이의 처리량을 증가시키는데에 유용하다.

B. 인터페이스 타입

통신 및 컴퓨터 산업에서, MDD 인터페이스는 5 이상의 다소 구별되는 물리적 타입의 인터페이스를 어드레스하는 것으로 계획된다. 이 시점에서, 이는 단순히, 타입 I, 타입 II, 타입 III, 타입 IV, 및 타입 U 로 레이블된다.

타입 I 인터페이스는, 비슷한 타입의 전자 소비 기술에서, 모바일 또는 무선 전화, PDA, 전자책, 전자 게임, 및 CD 플레이어, MP3 플레이어와 같은 휴대형 매체 재생기 및 디바이스에 적합하게 하는 6 와이어 (컨덕터) 인터페이스로 설정된다. 타입 U 인터페이스는, 랩탑, 노트북, 또는 데스크탑 개인 컴퓨터 및 유사한 디바이스 또는 애플리케이션에 더 적합한 8 와이어 (컨덕터) 인터페이스로 설정되며, 이는 재빨리 업데이트되어야 할 디스플레이를 필요로 하지 않고 내장 MDDI 링크 제어기를 필요로 하지 않는다. 또한, 이러한 인터페이스 타입은, 부가적인 2 와이어 유니버설 시리얼 버스 (USB) 인터페이스를 이용함으로써 구별 가능하며, 이는 대부분의 퍼스널 컴퓨터에서 존재하는 오퍼레이팅 시스템 또는 소프트웨어 지원을 제공하는데에 매우 유용하다. 또한, 예를 들어, 타입 U 인터페이스는, 디스플레이가 단순히 컴퓨터 또는 유사한 디바이스의 스탠다드 USB 포트에 연결하는 USB 커넥터를 지닌 USB-only 모드에서 사용될 수 있다.

타입 II, 타입 III, 및 타입 IV 인터페이스는 고성능 디스플레이 또는 디바이스에 적합하며, 적합한 쉴딩 및 데이터 시그널의 낮은 손실 전송을 제공하기 위해 부가적인 트위스티드-페어 타입 컨덕터를 갖는 더 큰 복잡한 케이블을 이용한다.

타입 I 인터페이스는, 디스플레이, 오디오, 제어, 및 제한된 신호 정보를 포함할 수 있는 신호를 통과시키며, 통상적으로 고해상도 풀-레이트 비디오 데이터를 요구하지 않는 디바이스에 사용된다. 이러한 타입의 인터페이스는 주로, 모바일 무선 디바이스와 같은, USB 호스트가 통상적으로 신호의 연결 및 전송을 위한 디바이스 내에서 사용가능하지 않은 디바이스에 사용되도록 의도된 것이다. 이러한 설정에서, 모바일 디바이스는 MDDI 호스트 디바이스가며, 호스트로부터의 통신 링크를 제어하는 "마스터" 로서 작용하며, 이는 일반적으로 디스플레이 데이터를 클라이언트로 보낸다 (정방향 트래픽 또는 링크).

이러한 인터페이스에서, 특별한 명령 또는 패킷 타입을, 버스를 특정한 기간 동안 테이크 오버하고 역방향 패킷으로 데이터를 호스트로 보내는 것을 허용하는클라이언트에 전송함으로써, 호스트는 클라이언트로부터 호스트에서의 통신 데이터의 수신을 인에이블한다. 이는 도 3 에 도시되며, 이 경우 캡슐화 패킷 (후술함) 이라고 불리우는 형태의 패킷이 사용되어, 전송 링크에 대한 역방향 패킷의 전송을 제공하며, 역방향 링크를 생성한다. 데이터에 대한 디스플레이를 얻기 위해 호스트에 할당된 시간 간격은 호스트에 의해 미리 결정되고, 각각의 특정한 애플리케이션의 요구사항에 기초한다. USB 포트가 클라이언트로부터의 정보 또는 데이터의 전송에 사용가능하지 않은 경우, 이러한 타입의 하프 듀플렉스 양방향 데이터 전송은 특히 바람직하다.

USB 인터페이스가 많은 량의 머더보드 또는 다른 하드웨어에 의해, 또는 오퍼레이팅 시스템 소프트웨어에 의해 널리 지원되는 경우, 타입 U 인터페이스는, 랩탑 및 데스크탑 애플리케이션에서의 사용에 적합한 신호를 전송한다. 부가된 USB 인터페이스의 이용은 "플러그 앤 플레이" 특성 및 쉬운 애플리케이션 설정의 이용을 허용한다. 또한, 클라이언트 디바이스 용의 비디오 및 오디오 데이터가 저전력 및 고속으로 트위스티드 페어를 이용하여 전송될 수 있을 때, USB 의 포함은 명령, 상태, 오디오 데이터 등의 범용 양방향 흐름을 허용한다. 후술하는 바대로, 전력은 다른 와이어를 이용하여 전송될 수 있다. USB 인터페이스를 이용한 본 발명의 실시형태는, 주로 USB 연결에 대한 시그널링 및 제어를 행하는 경우 1 컨덕터 세트를 통한 고속 전송을 허용하며, 이는 사용하지 않을 때는 셧 다운되어 적은 전력을 소비할 수 있다.

USB 인터페이스는, 현대 퍼스널 컴퓨터 장비에 있어서 매우 광범위하게 이용되는 표준이며, USB 인터페이스의 디테일 및 그 동작은 당업계에 매우 잘 알려져 있으므로 여기에서 설명하지 않는다. USB 인터페이스에 대해, 호스트와 디스플레이 사이의 통신은, 유니버설 시리얼 버스 명세 사항 (specification), 리비전 2.0 을 따른다. USB 가 주 신호 채널이며 음성 리턴 채널이 사용되는 것이 가능한 경우에 타입 U 인터페이스를 이용하는 애플리케이션에 있어서, MDDI 시리얼 데이터 신호를 통해서 호스트가 클라이언트를 폴 (poll) 하는 것은 선택적이다.

HDTV 타입 또는 유사한 고해상도가 가능한 고성능 디스플레이는, 풀-모션 비디오를 지원하기 위해 약 1.5 Gbps 레이트 데이터 스트림을 요구한다. 타입 II 인터페이스는 2 bits 를 병렬로 전송함으로써, 타입 III 은 4 bits 를 병렬로 전송함으로써, 그리고 타입 IV 는 8 bits 를 병렬로 전송함으로써 높은 데이터 레이트를 지원한다. 어떤 것이 사용될 수 있는 가장 높은 데이터 레이트인지 협상하여, MDDI 에 의해 이용되는 프로토콜은 각각의 타입 I, II, III, 또는 IV 호스트가 임의의 타입 I, II, III, 또는 IV 클라이언트 또는 디스플레이와 통신하는 것을 허용한다. 어느 것이 가장 능력이 적은 디바이스로 불릴 것인지의 능력 또는 사용가능한 특성은, 링크의 성능을 설정하기 위해 사용된다. 일반적으로, 호스트 및 클라이언트 모두가 타입 II, 타입 III, 또는 타입 IV 인터페이스를 이용할 수 있는 시스템에 대해서도, 둘 모두는 타입 I 인터페이스로 동작을 시작한다. 그 후, 특정한 애플리케이션에 적합하도록, 호스트는 타겟 클라이언트 또는 디스플레이의 능력을 결정하고, 핸드-오프 또는 재설정 동작을 타입 II, 타입 III, 또는 타입 IV 모드로 협상한다.

일반적으로 호스트가 적합한 링크-층 프로토콜 (후에 설명함) 을 이용하며, 어느 때에나 전력을 절약하기 위해 더 느린 모드로 스텝 다운 또는 재설정하거나 더 높은 해상도 디스플레이 내용과 같은 더 높은 속도의 전송을 지원하기 위해서 더 빠른 모드로 스텝 업하는 것이 가능하다. 예를 들어, 디스플레이 시스템이 배터리와 같은 전원 소스에서 AC 전력으로 스위치될 때, 또는 디스플레이 매체의 소스가 더 낮거나 높은 해상도 포맷으로 스위치될 때 호스트는 디스플레이 모드를 변화시킬 수 있으며, 이들의 조합 또는 다른 조건 또는 이벤트는 디스플레이 또는 데이터 전송 모드를 변화시키는 기초로 간주될 수 있다.

또한, 1 방향에서 1 모드 및 또다른 방향에서 또다른 모드를 이용하여, 시스템이 데이터를 통신하는 것도 가능하다. 예를 들어, 키보드나 포인팅 디바이스와 같은 주변 디바이스로부터 호스트 디바이스로의 데이터 전송에는 타입 I 또는 타입 U 모드가 이용되는 반면, 타입 IV 인터페이스 모드는 높은 레이트에서의 디스플레이에 데이터를 전송하기 위해 사용될 수 있다.

C. 물리 인터페이스 구조체

호스트와 클라이언트 디바이스 사이의 통신을 수립하기 위한 디바이스 또는 링크 제어기의 일반적인 성질이 도 4 및 5 에 도시되어 있다. 도 4 및 5 에서, MDDI 링크 제어기 (402 및 502) 는 클라이언트 디바이스 (204) 에 설치되어 도시된다. 예전처럼, 일련의 컨덕터를 포함하는 양방향 통신 채널 (406) 을 이용하여, 호스트 (202) 는 클라이언트 (204) 에 연결된다. 후술하는 바와 같이, 호스트 및 클라이언트 링크 제어기 모두는, 호스트 제어기 (드라이버) 또는 클라이언트 제어기(수신기) 로 응답하도록 설정, 조정, 또는 프로그램될 수 있는 단일 회로 디자인을 이용하여, 직접 회로로 제작될 수 있다. 단일 회로 디바이스의 더 큰 스케일 제작으로 인하여, 이는 더 낮은 비용을 제공한다.

도 4 에서, 또한, MDDI 의 타입 U 인터페이스 버전을 수행하는데 이용되는 USB 호스트 디바이스 (408) 및 USB 클라이언트 디바이스 (410) 가 도시된다. 그러한 기능을 수행하기 위한 회로 및 디바이스는 당업계에 잘 알려져 있고, 더이상 자세히 언급하지 않는다.

도 5 에서, MDDI 링크 제어기 (502) 가 호스트 디바이스 (202') 에 설치되어 도시되며, MDDI 링크 제어기 (504) 가 클라이언트 디바이스 (204') 에 설치되어 도시된다. 예전처럼, 일련의 컨덕터를 포함하는 양방향 통싱 채널 (506) 을 이용하여, 호스트 (202') 는 클라이언트 (204') 에 연결된다. 전술한 바대로, 호스트 및 클라이언트 링크 제어기 둘 모두는 단일 회로 디자인을 이용하여 제작될 수 있다.

또한, MDDI 링크를 통하여, 디스플레이 디바이스와 같은 호스트와 클라이언트 사이에 통과되는 신호 또는 사용되는 물리적인 컨덕터는 도 4 및 도 5 에 도시된다. 도 4 및 5 에서 보듯이, MDDI 를 통하여 전송되는 데이터의 주요 경로 또는 메커니즘은 MDDI_Data0+/- 및 MDDI_Stb+/- 로 레이블되는 데이터 신호를 이용한다. 이들 각각은, 케이블에서 와이어의 차동 페어를 통해 전송되는 저전압 데이터 신호이다. 인터페이스를 통해 보내지는 각각의 비트에 대해 MDDI_Data0 페어 또는 MDDI_Stb 페어 상에서 단지 하나의 트랜지션이 존재한다. 이는 전류 기반이 아닌 전압 기반 전송 메커니즘이어서, 정전류 소비는 거의 0 이다. 호스트는 MDDI_Stb신호를 클라이언트 디스플레이로 구동한다.

데이터가 MDDI_Data 페어를 통해 정방향 및 역방향 모두로 흐를 수 있을 때, 즉 양방향 전송 경로일 때, 호스트는 데이터 링크의 마스터 또는 제어기이다. 노이즈 면역을 최대화하기 위해서, MDDI_Data0 및 MDDI-Stb 신호 경로는 차동 모드로 동작한다. 이러한 라인에 대한 신호의 데이터 레이트는 호스트에 의해 보내진 클럭의 레이트에 의해 결정되고, 1 kbps 에서 400 Mbps 이상의 범위에서 변할 수 있다.

타입 II 인터페이스는, 타입 I 의 것 이외에, 하나의 부가적인 데이터 페어 또는 컨덕터 또는 경로를 포함하며, 이는 MDDI_Data1+/- 로 불리운다. 타입 III 인터페이스는, 타입 II 의 것 이외에, 두개의 부가적인 데이터 페어 또는 신호 경로를 포함하며, 이는 MDDI_Data2+/- 및 MDDI_Data3+/- 로 불리운다. 타입 IV 인터페이스는, 타입 III 의 것 이외에, 네개의 데이터 페어 또는 신호 경로를 더 포함하며, 이는 각각 MDDI_Data4+/-, MDDI_Data5+/-, MDDI_Data6+/- 및 MDDI_Data7+/- 로 불리운다. 각각의 전술한 인터페이스 설정에서, MDDI_Pwr 및 MDDI_Gnd 로 지정된 와이어 페어 또는 신호를 이용하여, 호스트는 전력을 클라이언트 또는 디스플레이로 전송한다.

일반적으로 타입 U 설정에 대해서만 가능하게 만들어진 한 타입은 전송은, MDDI USB 연결 또는 신호 경로이다. MDDI USB 연결은, 호스트와 클라이언트 디스플레이 사이의 통신에 대해서 제 2 경로를 포함한다. 특정한 애플리케이션에서, 호스트와 클라이언트 사이에 특정 정보를 상대적으로 낮은 데이터 레이트로 전송하는 것이 더 바람직할 수도 있다. USB 전송 링크를 사용하는 것은, USB 호스트 또는 제한된 호스트 능력을 갖는 MDDI 링크 제어기 없는 디바이스가, 타입 U 인터페이스를 갖는 MDDI-호환 클라이언트 또는 디스플레이와 통신하는 것을 허용한다. USB 인터페이스를 이용하여 디스플레이로 유용하게 전송될 수 있는 정보의 예는, 정적 비트맵, 디지털 오디오 스트림, 포인팅 디바이스 데이터, 키보드 데이터 및 제어 및 상태 정보이다. 또한, USB 인터페이스를 통해서 지원되는 모든 기능은, 프라이머리 MDDI 고속 시리얼 데이터 경로를 이용하여 수행될 수 있다. 위에 정의된 데이터 (아래의 패킷 참조) 가 USB 타입 인터페이스를 통해 전송되는 동안, 데이터를 패킷 백-투-백 의 형태로 체이닝 (chaining) 하는 요구사항은 그러한 USB 인터페이스에는 적용되지 않으며, MDDI 타입 핸드오프를 지원하는 패킷도 사용하지 않는다.

MDDI 링크를 통해 호스트와 클라이언트 (디스플레이) 사이에 통과되는 신호의 요약이, 인터페이스 타입에 따라 아래의 표 I 에 설명되어 있다.

[표 I]

전술한 구조체 및 동작을 수행하기 위해 일반적으로 이용되는 케이블링은,명목상으로 길이는 1.5 미터 정도이며 컨덕터의 3 트위스티드 페어를 포함하며, 각각은 차례로 여러 가닥의 30 AWG 와이어이다. 부가적인 드레인 와이어로서, 호일 실드 커버링은 3 트위스티드 페어 위에 싸여지거나 (wrapped), 아니면 형성된다. 트위스티드 페어 및 실드 드레인 컨덕터는, 디스플레이 (클라이언트) 에 대한 실드에 연결된 실드를 갖는 디스플레이 커넥터에서 종결되며, 당업계에 잘 알려진 것처럼 전체 케이블을 덮는 절연 층이 존재한다. 와이어는, MDDI_Gnd 와 MDDI_Pwr, MDDI_Stb+ 와 MDDI_Stb-, MDDI_Data0+ 와 MDDI_Data0-, MDDI_Data1+ 와 MDDI_Data1- 등으로 페어된다. 명목상 케이블 지름은 3.0 mm 정도, 명목상 임피던스는 85 ohms ±10 %, 그리고 DC 저항은 명목상 1000 feet 당 100 ohms 이다. 산호 전파 속도는 명목상 0.66c 이어야 하며, 케이블을 지나는 최대 딜레이는 8.0 nsec 이하이어야 한다.

D. 데이터 타입 및 레이트

전 범위의 유저 경험 및 애플리케이션에 대한 유용한 인터페이스를 달성하기 위해서, 모바일 디지털 데이터 인터페이스 (MDDI) 는 다양한 디스플레이 및 디스플레이 정보, 오디오 트랜스듀서, 키보드, 포인팅 디바이스, 및 통합되거나 모바일 디스플레이 디바이스와 관련하여 작업할 수 있는 다른 여러가지 입력 디바이스, 제어 정보 및 그 조합에 대한 지원을 제공한다. MDD 인터페이스는, 최소한의 수의 케이블 또는 컨덕터를 이용하여 정방향 또는 역방향 링크의 방향으로, 호스트와 클라이언트 사이에서 데이터가 오고가는 스트림의 잠재적인 다양한 타입을 제공하도록 할수 있게 디자인된 것이다. 등시적 스트림 및 비동기적 스트림 (업데이트) 둘 모두가 지원된다. 합계 데이터 레이트가 최대의 원하는 MDDI 링크 레이트 이하인 한, 데이터 타입의 여러가지 조합이 가능하다. 이는 아래의 표 II 및 III 에 열거된 아이템을 포함하지만 이에 한정되지는 않는다.

[표 II]

[표 III]

인터페이스는 고정되지 않으며, 미래의 시스템 유연성을 위해서 유저-정의 데이터를 포함하는 다양한 정보 "타입" 의 전송을 지원할 수 있도록 하기 위해 확장가능하다. 제공되는 데이터의 특정한 예는, 풀-모션 비디오, 전체 또는 일부 스크린 비트맵 필드 또는 압축된 비디오; 전력을 보존하고 수행 비용을 줄이기 위한 낮은 레이트에서의 정적 비트맵; 다양한 해상도 또는 레이트에서의 PCM 또는 압축된 오디오 데이터; 포인팅 디바이스 위치 및 선택, 및 아직 정의되지 않은 능력에 대한 유저-정의가능한 데이터이다. 또한, 그러한 데이터는, 디바이스 능력 또는 세트 오퍼레이팅 파라미터를 탐지하기 위한 제어 또는 상태 정보에 따라 전송될 수도 있다.

본 발명은, 영화 보기 (비디오 디스플레이 및 오디오), 제한된 개인적 감상 (personal viewing) 을 갖는 퍼스널 컴퓨터를 이용하기 (그래픽 디스플레이, 종종 비디오 및 오디오와 결합됨), PC, 콘솔, 또는 개인 디바이스에서 비디오 게임 플레이하기 (모션 그래픽 디스플레이, 또는 합성 비디오 및 오디오), 인터넷 "서핑", 비디오 폰의 형태로 디바이스 이용하기 (양방향 저-레이트 비디오 및 오디오), 정지 디지털 사진을 위한 카메라, 또는 디지털 비디오 이미지 캡쳐를 위한 캠코더, 그리고 셀폰, 스마트폰, 또는 PDA 로의 생산성 향상 또는 엔터테인먼트 이용을 포함하지만, 이에 한정되지는 않는 데이터 전송의 사용에 대한 기술을 앞선다.

일반적으로 와이어-라인 또는 케이블 타입 링크로 설정된 통신 또는 트랜스퍼 링크를 통하여, 많은 량의 A-V 타입 데이터를 제공한다는 관점에서, 후술할 모바일 데이터 인터페이스가 제공된다. 그러나, 만약 원하는 전송의 레벨을 유지할 수 있다면, 광학적 또는 무선 매체의 형태로 링크를 제공하도록 조정하기 위해서 신호 구조체, 프로토콜, 타이밍, 또는 전송 메커니즘이 제공될 수 있다는 것은 명백하다.

MDD 인터페이스 신호는, 기본 신호 프로토콜 또는 구조체에 대해서 공통 프레임 (CF) 으로 알려진 개념을 이용한다. 공통 프레임을 이용하는 것의 배후 아이디어는, 동시의 등시성 데이터 스트림에 대해 동기화 펄스를 제공하는 것이다. 디스플레이 디바이스는 이 공통 프레임 레이트를 시간 기준으로 이용할 수 있다. 오버헤드를 증가시켜 서브-프레임 헤더를 전송함으로써, 낮은 CD 레이트는 채널 효율을 증가시킨다. 반면에, 높은 CF 레이트는 레이턴시 (latency) 를 감소시키며, 오디오 샘플에 대한 더 작은 유연한 데이터 버퍼를 허용한다. 본 발명 인터페이스의 CF 레이트는 동적으로 프로그램가능하며, 특정한 애플리케이션에서 이용되는 등시성 스트림에 적합한 여러가지 값 중의 하나로 설정될 수 있다. 즉, 주어진 디스플레이 디바이스 및 호스트 설정에 가장 적합하도록, 원하는 대로 CF 값이 설정된다.

헤드-마운티드 마이크로-디스플레이와 같은 애플리케이션에서 많이 사용되는 등시성 데이터 스트림에 대한, 조정가능하거나 프로그램가능한, 일반적으로 공통 프레임당 요구되는 바이트 수는 표 IV 에 나타난 바와 같다.

[표 IV]

공통 프레임당 바이트의 프랙셔널 카운트 (fractional count) 는, 단순한 프로그램가능 M/N 카운터 구조체를 이용하여 쉽게 얻어진다. 예를 들어, 26-2/3 bytes per CF 의 카운트는, 2 프레임의 27 바이트를 전송하고 각각 1 프레임의 26 바이트를 전송함으로써 수행된다. 더 작은 CF 레이트는, bytes per CF 의 정수 숫자를 만들기 위해 선택될 수 있다. 그러나, 일반적으로 말해서, 하드웨어 내에서 단순한 M/N 카운터를 수행하는 것은, 본 발명의 부분 또는 전체를 수행하기 위해이용되는 집적 회로 칩에서는 더 큰 오디오 샘플 FIFO 버퍼에 요구되는 것보다 더 적은 영역을 요구한다.

차동 데이터 전송 레이트 및 데이터 타입의 효과를 설명하는 예시 애플리케이션은 가라오케 시스템이다. 가라오케에서, 시스템 유저는 뮤직 비디오 프로그램을 따라 노래한다. 노래의 가사는 스크린의 아래에 표시되어, 대략 노래의 타이밍에 유저가 노래할 단어를 알게 된다. 이 애플리케이션은 빈번하지 않은 그래픽 업데이트를 갖는 비디오 디스플레이 및 유저의 목소리와 스테레오 오디오 스트림과의 믹싱을 요구한다.

만약 300 Hz 의 공통 프레임 레이트를 가정한다면, 그 후 각각의 CF 는, 디스플레이 디바이스에 대한 정방향 링크에 대해 92,160 바이트의 비디오 내용 및 588 바이트의 오디오 내용 (스테레오에서 147 16-bit 샘플에 기초할 때), 및 평균 29.67 (26-2/3) 바이트의 음성이 마이크로폰에서 모바일 가라오케 기계로 전송된다. 비동기식 패킷은 호스트와 디스플레이 사이에서 전송된다. 이는 많아야 768 바이트의 그래픽 데이터 (쿼터 스크린 높이), 및 기타 제어 및 상태 명령에 대해 약 200 바이트 (몇) 바이트 이하를 포함한다.

표 V 는, 가라오케 예에 대한 공통 프레임 내에서 어떻게 데이터가 할당되는지를 보여준다. 사용되는 총 레이트는 약 225 Mbps 로 선택된다. 약간 높은 226 Mbps 의 레이트는, 예비 제어 및 상태 메시지의 사용을 허용하는, 서브-프레임 당 약 400 바이트의 전송할 데이터를 허용한다.

[표 V]

E. 링크 층 (Link Layer)

MDD 인터페이스 고속 시리얼 데이터 신호를 이용하여 전송되는 데이터는 서로 연결된 시간-다중화 패킷의 스트림으로 구성된다. 전송 장치가 전송할 데이터를 가지고 있지 않은 때에도 MDDI 링크 콘트롤러는 자동적으로 필러 (filler) 패킷을 전송하므로, 패킷 스트림을 유지한다. 단순한 패킷 구조의 이용은 비디오와 오디오 신호 또는 데이터 스트림에 대해 신뢰할 수 있는 등시 (isochronous) 타이밍을 확보해 준다.

패킷 군은 신호 요소 (signal element) 또는 서브 프레임으로 불리는 구조 내에 포함되며, 서브 프레임 군은 신호 요소 또는 매체 프레임으로 불리는 구조 내에 포함된다. 하나의 서브 프레임은 그 크기나 데이터 전송 용도에 따라 하나 이상의 패킷을 포함하며, 하나의 매체 프레임은 서브 프레임을 하나 더 포함해야 한다. 본 발명에서 채용하는 프로토콜에 의해 제공되는 가장 큰 서브프레임은 2³²-1 오더, 즉 4,294,967,295 바이트이며, 가장 큰 매체 프레임은 2¹⁶-1 오더, 즉 65,535 서브프레임이 된다.

이하에서 논의하는 대로, 각각의 서브 프레임의 시작에는 특정한 식별자를 포함하는 특별한 헤더 패킷이 나타난다. 이 식별자는 호스트와 표시간에 통신이 개시될 때 클라이언트 디바이스에서 프레임 타이밍을 얻기 위해 사용되기도 한다. 링크 타이밍의 획득은 다음에서 더 자세히 논의한다.

일반적으로, 풀 모션 (full-motion) 비디오가 표시될 때 표시 스크린은 매체 프레임마다 한번씩 업데이트 된다. 디스플레이 프레임 레이트는 매체 프레임 레이트와 같다. 링크 프로토콜은 희망 어플리케이션에 따라, 전체 디스플레이에서의 풀 모션 또는 정적 이미지에 둘러싸인 작은 영역만의 풀 모션을 지원한다. 웹 페이지나 이 메일을 보는 것과 같은 어떤 저전력 (low-power) 어플리케이션에서는, 디스플레이 스크린은 가끔씩 업데이트 되면 족하다. 그런 상황에서, 전력 소비를 최소화하기 위해 하나의 서브 프레임을 전송한 후 연결을 차단하는 것이 유리하다. 인터페이스는 또한 스테레오 비전과 같은 효과를 지원하며 그래픽 요소를 다룬다.

서브 프레임은 주기적 기초에서 상위 우선순위 패킷의 전송을 활성화하기 위해 존재한다. 이는 동시적 등시 스트림이 최소량의 데이터 버퍼링과 공존할 수 있게 한다. 이것이, 복수의 데이터 스트림 (비디오, 음성, 상태, 포인팅 도구 등의 고속 통신) 이 본질적으로 같은 채널을 공유할 수 있도록 하는 본 발명이 디스플레이 프로세스에 제공하는 이점의 하나이다. 이는 상대적으로 적은 신호를 사용하여 정보를 전송한다. CRT 모니터에 대한 수평 동기 펄스 (horizontal sync pulses) 와 귀선 소거 기간 (blanking interval) 과 같이 디스플레이 기술 특유의 행동들이 존재할 수 있게 하기도 한다.

F. 링크 제어기

도 4 와 5 의 MDDI 링크 제어기는 MDDI 데이터와 스트로브 신호를 수신하기 위해 사용되는 차동 라인 수신기 (differential line receiver) 를 제외하고는 완전 디지털 구현으로 생산되거나 조립된다. 그러나, 차동 회선 드라이버 (driver) 와 수신기조차도 링크 제어기를 가지는 동일한 디지털 집적 회로 내에 구현될 수 있다. 링크 제어기의 하드웨어를 구현하기 위해 아날로그 기능이나 위상 락 루프 (phase lock loop; PLL) 가 필요하지 않다. 호스트와 디스플레이 링크 제어기는 링크 동기화를 위한 상태 기계를 포함하는 디스플레이 인터페이스를 제외하고는 매우 유사한 기능을 포함한다. 그러므로, 본 발명은 단일 제어기 설계 또는 호스트나 클라이언트로 조정될 수 있는 회로를 생성할 수 있는 실용적 이점을 가져오며, 이는 전체적으로 링크 제어기의 생산비용을 감소시킬 수 있다.

Ⅳ. 인터페이스 링크 프로토콜

A. 프레임 구조

신호 프로토콜 또는 프레임 구조는 도 6 에 나타난 패킷 전송을 위한 순방향 링크 통신을 구현하기 위해 이용된다. 도 6 에서 보듯이, 정보 또는 디지털 데이터는 패킷이라는 요소로 묶어진다. 다수의 패킷은 다시 함께 묶여져서 서브 프레임이라는 것을 형성하며, 다시 다수의 서브 프레임은 함께 묶여서 매체 프레임을 형성한다. 프레임의 형성과 서브 프레임의 전송을 제어하기 위해, 각각의 서브 프레임은 특별히 서브 프레임 헤더 패킷 (Sub-frame Header Packet; SHP) 이라 불리는 소정의 패킷으로 시작한다.

호스트 디바이스는 주어진 전송에서 사용될 데이터 레이트를 선택한다. 이 레이트는, 호스트나 호스트에 의해 소스로부터 회수되는 데이터의 최대 전송 능력 그리고 디스플레이나 데이터가 전송되고 있는 디바이스의 최대 능력 두 가지 모두에 기초하여 호스트 디바이스에 의해 동적으로 변경될 수 있다.

MDDI 또는 발명의 신호 프로토콜로 동작하도록 설계되거나 동작할 수 있는 수신측 클라이언트 디바이스는 사용할 수 있는 최대 또는 최근의 최대 데이터 전송 레이트를 결정하기 위해 호스트로부터 질의를 받을 수 있으며, 또는 사용 가능한 데이터 타입 및 지원되는 특성들과 함께 디폴트 최소 레이트가 사용될 수도 있다. 아래서 논의하는 대로, 이 정보는 디스플레이 능력 패킷 (Display Capability Packet; DCP) 을 사용하여 전송될 수 있다. 클라이언트 디바이스는 소정의 최소 데이터 레이트 또는 최소 데이터 레이트 범위 내에서 인터페이스를 사용하여 데이터를 전송하거나 다른 디바이스와 통신할 수 있으며, 호스트는 클라이언트 디바이스의 최대 능력을 결정하기 위해 이 범위의 데이터 레이트로 질의를 수행할 수 있다.

비트맵의 성질 및 디스플레이의 비디오 프레임 레이트 능력을 정의하는 다른 상태 정보들은 상태 패킷으로 호스트에 전송되어 호스트는 실제적으로 효율적 또는 최적으로 또는 어떤 시스템 규격 내에서 바라는 대로 인터페이스를 설정할 수 있다.

현재 서브 프레임 내에 전송할 데이트 패킷이 (더 이상) 없을 때, 또는 호스트가 순방향 링크에 대해 선택된 데이터 전송 레이트에 뒤지지 않을 정도로 충분한레이트로 전송을 할 수 없을 때 호스트는 필러 패킷을 전송한다. 각각의 서브 프레임은 서브 프레임 헤더 패킷으로 시작하기 때문에 이전 서브 프레임의 끝은 이전 서브 프레임을 정확히 채우는 패킷 (대체로 필러 패킷) 을 포함한다. 패킷 그 자체를 운반할 데이터 공간이 부족한 경우에, 필러 패킷은 대체로 서브 프레임의 마지막 프레임이 되거나 다음 이전 서브 프레임의 마지막과 서브 프레임 헤더 패킷 전이 될 것이다. 서브 프레임 내에 서브 프레임 내에서 전송될 각각의 패킷에 대한 충분한 잔여 공간이 존재하도록 하는 것은 호스트 디바이스의 컨트롤 동작의 과제이다. 동시에, 호스트 디바이스가 데이터 패킷의 전송을 시작하면, 호스트는 데이터 부족 상태 (data under-run condition) 를 초래하지 않고 그 크기 패킷의 전송을 성공적으로 완료할 수 있어야 한다.

본 발명의 실시형태의 한 측면에서, 서브 프레임 전송은 두 가지 모드를 가진다. 한 모드는 실황 비디오 또는 오디오 스트림을 전송하는데 사용되는 주기 서브 프레임 모드 (periodic sub-frame mode) 이다. 이 모드에서, 서브 프레임 길이는 0 이 아니도록 정의된다. 두 번째 모드는 새로운 정보가 사용가능한 때에만 프레임이 디스플레이 디바이스로 비트맵 데이터를 제공하는데 사용되는 비동기 또는 비 주기 모드이다. 이 모드는 서브 프레임 헤더 패킷 내에서 서브 프레임 길이를 0 으로 설정함으로써 정의된다. 주기 모드를 사용하는 때에, 서브 프레임 패킷 수신은 디스플레이가 순방향 링크 프레임 구조와 동기화 되었을 때 개시될 수 있다. 이것은 도 49 에 관하여 아래에서 논의된 상태도 (state diagram) 에 따라 정의된 "동기 (in sync)" 상태에 대응한다. 비동기 비주기 서브 프레임 모드에서, 수신은제 1 서브 프레임 헤더 패킷이 수신된 후에 개시된다.

B. 전체 패킷 구조

본 발명에 의해 구현되는 신호 프로토콜을 공식화하기 위해 사용되는 패킷의 형식 또는 구조는, 인터페이스는 확장이 가능하며 추가적인 패킷 구조가 원하는 대로 추가될 수 있음을 염두에 두고 다음에 나타내었다. 패킷은 인터페이스 내에서의 그 기능, 즉 전송하는 명령 또는 데이터의 관점에서 상이한 "패킷 타입" 으로 표지되거나 분류되었다. 따라서, 각각의 패킷 타입은, 전송되고 있는 데이터 또는 패킷을 조작하는데 사용되는 주어진 패킷에 대한 소정의 패킷 구조를 나타낸다. 쉽게 알 수 있듯이, 패킷은 소정의 길이를 가지거나, 변수나 각각의 기능에 따라 동적으로 변화될 수 있는 길이를 가질 수 있다. 다양한 패킷에서 사용되는 바이트(들) 값은 멀티 비트 (8 비트 도는 16 비트) 부호 없는 정수 (unsigned integer) 에 따라 설정될 수 있다. 그 "타입" 명칭과 함께 사용되는 패킷의 요약은 타입 순서로 표 Ⅵ 에 나타낸다. 패킷의 전송이 유효한 것으로 생각되는 방향도 U-타입 인터페이스에 대해 사용될 수 있는지 여부와 함께 표시되었다.

[표 Ⅵ]

패킷은 도 7 에서 보이는 패킷 길이 필드, 패킷 타입 필드, 데이터 바이트 필드, 그리고 CRC 필드를 포함하는 공통 기본 구조 또는 최소 필드의 전체 세트를 가지고 있다. 도 7에서 보듯이, 패킷 길이 필드는 멀티 비트 또는 바이트의 형태로패킷 내의 총 비트 수 또는 패킷 길이 필드와 CRC 필드 사이의 길이를 특정하는 정보를 포함한다. 본 예의 바람직한 실시형태에서, 패킷 길이 필드는 패킷 길이를 특정하는 16 비트, 즉 2 바이트 길이의 부호 없는 정수를 포함한다. 패킷 타입 필드는 패킷 내에 포함된 정보의 타입을 나타내는 또 다른 멀티 비트 필드이다. 본 예의 예시적인 실시형태에서, 이것은 8 비트 부호 없는 정수 형태의 8 비트, 즉 1 바이트 길이의 값이며, 디스플레이 능력, 핸드 오프, 비디오 또는 오디오 스트림, 상태 등을 나타낸다.

제 3 의 필드는 호스트와 클라이언트간에 그 패킷의 일부로서 전송되거나 보내지고 있는 비트 또는 데이터를 포함하는 데이터 바이트이다. 데이터의 형식은 전송되고 있는 데이터의 특정 타입에 따라 각 패킷 타입에 대해 특별히 정의되며, 각각 고유의 형식 요건을 가지고 추가적인 필드 시리즈로 분리될 수 있다. 즉, 각각의 패킷 타입은 이 부분 또는 필드에 대해 정의된 형식을 가지게 된다. 마지막 필드는 데이터 바이트, 패킷 타입, 및 패킷 길이 필드 모두에 대해 계산된 16 비트 주기적 용장 체크 결과를 포함하는 CRC 필드로서, 이는 패킷 내 정보의 무결성을 확인하기 위해 사용된다. 다른 말로 하면, CRC 필드 자체를 제외한 전체 패킷에 대해 계산된다는 것이다. 클라이언트는 일반적으로 검출된 CRC 에러의 총 수를 유지하고, 디스플레이 요청 및 상태 패킷에서 이 숫자를 호스트에 다시 보고한다.(아래의 설명 참조)

패킷의 전송 동안, 최하위 비트 (LSB) 를 먼저 전송하기 시작하여 최상위 비트 (MSB) 의 전송으로 완료되어 필드가 전송된다. 길이가 1 바이트 이상인 파라미터는 최하위 바이트 우선으로 전송되며, 이는 8 비트 초과의 파라미터를 전송하는데 사용되는 전송 패턴이 LSB를 우선 전송하는 8 비트 이하의 파라미터에 대해 이용되는 패턴과 동일하게 한다. MDDI_Data0 신호 패스의 데이터는 타입-Ⅰ, 타입-Ⅱ, 타입-Ⅲ, 또는 타입-Ⅳ 어느 모드에서도 인터페이스에서 전송되는 바이트의 0 비트와 정렬된다.

디스플레이를 위해 데이터를 조작할 때, 픽셀 어레이에 대한 데이터는 전자 기술에서 전통적으로 하듯이, 열 (row) 먼저, 그리고 행 (column)의 순으로 전송된다. 다른 말로 하면, 비트맵의 같은 열의 모든 픽셀은 제일 좌측의 픽셀이 먼저 전송되고 제일 우측의 픽셀이 마지막으로 전송되는 순서로 전송된다. 열의 제일 우측 픽셀이 전송된 후, 시퀀스의 그 다음 픽셀은 다음 열의 제일 좌측의 픽셀이다. 필요에 따라 다른 방식이 수용될 수 있지만, 픽셀의 열은 일반적으로 대부분의 디스플레이에서 위에서 아래의 순서로 전송된다. 또한, 비트맵을 다루는데 있어, 다음의 종래 방식은 좌상부의 비트맵을 위치 또는 오프셋 "0,0" 으로 표지하여 포인트 레퍼런스를 정의하는 것이다. 비트맵 내의 위치를 정의하거나 결정하기 위해 사용되는 X 와 Y 좌표계는 비트맵의 우하향으로 갈수록 각각 값이 증가한다. 제 1 열과 제 1 행은 0 값의 인덱스로 시작한다.

C. 패킷 정의

1. 서브 프레임 헤더 패킷

서브 프레임 헤더 패킷은 모든 서브 프레임의 첫 번째 패킷이며, 도 8 에서 나타낸 기본 구조를 가지고 있다. 도 1 에서 볼 수 있듯이, 이 패킷 타입은 패킷길이, 패킷 타입, 고유 워드, 서브 프레임 길이, 프로토콜 버전, 서브 프레임 카운트, 및 매체 프레임 카운트 필드를 일반적으로 이 순서로 가지도록 구성된다. 이 패킷 타입은 일반적으로 타입 255 (16 진수로 0xff) 로 특정되며 소정의 17 바이트 고정 길이를 사용한다.

패킷 타입 필드는 1 바이트 값을 사용하는 반면, 고유 워드 필드는 3 바이트 값을 사용한다. 이 두 필드의 4 바이트 조합은 함께 양호한 자기상관 (autocorrelation) 을 가지는 32 비트의 고유 워드를 구성한다. 하위 8 비트가 패킷 타입으로 먼저 전송되고 , 상위 24 비트가 다음에 전송되는 경우에 실제의 고유 워드는 0x005a3bff 이다.

서브 프레임 길이 필드는 서브 프레임 당 바이트 수를 특정하는 4 바이트의 정보를 포함한다. 이 필드의 길이는 링크가 휴면 상태로 차단되기 전에 호스트에 의해서 하나의 서브 프레임만이 전송될 것임을 나타내기 위해 0 으로 설정될 수도 있다. 이 필드의 값은 하나의 서브 프레임에서 다음으로 전환될 때 "온 더 플라이 (on-the-fly)" 로 동적으로 변화될 수 있다. 등시 데이터 스트림을 수용하기 위한 동기 펄스 내 미세 타이밍 조절을 하기 위해서 이 능력이 유용하다. 서브 프레임 헤더 패킷의 CRC 가 유효하지 않으면, 링크 제어기는 현재 서브 프레임의 길이를 추산하기 위해 잘 알고 있는 이전 서브 프레임 헤더 패킷의 서브 프레임 길이를 이용하여야 한다.

프로토콜 버전 필드는 호스트에 의해 이용되는 프로토콜 버전을 특정하는 2 바이트를 포함한다. 제 1 또는 최근의 프로토콜 버전이 사용되고 있음을 특정하기위해 프로토콜 버전 필드는 0으로 설정된다. 이 값은 새 버전이 만들어짐에 따라 변할 것이다. 서브 프레임 카운트 필드는 매체 프레임의 시작부터 전송된 프레임의 수를 특정하는 시퀀스 넘버를 특정하는 2 바이트를 포함한다. 매체 프레임의 첫 번째 서브 프레임은 0 인 서브 프레임 카운트를 갖는다. 매체 프레임의 마지막 서브 프레임은, n이 매체 프레임 당 서브 프레임의 수일 때, n-1의 값을 갖는다. 만약 서브 프레임 길이가 0으로 설정된다면 (비주기 서브 프레임을 나타냄) 서브 프레임 카운트 역시 0으로 설정되어야 한다.

매체 프레임 카운트 필드는 전송 중인 현재 매체 아이템 또는 데이터의 시작 이후 전송된 매체 프레임의 수를 나타내는 시퀀스 넘버를 특정하는 3 바이트를 포함한다. 매체 아이템의 첫 번째 매체 프레임은 0 인 매체 프레임 카운트를 갖는다. 매체 프레임 카운트는 각 매체 프레임의 첫 번째 서브 프레임 직전에 증가하며 최대 매체 프레임 카운트 (매체 프레임 숫자 2²⁴-1=16,777,215) 가 사용된 후에는 0 으로 되돌아간다. 매체 프레임 카운트는 일반적으로 엔드 어플리케이션의 요구를 만족시키기 위해 언제든지 리셋 될 수 있다.

2. 필러 패킷

필러 패킷은 순방향 또는 역방향으로 보낼 수 있는 또 다른 정보가 없을 때 클라이언트 디바이스에게 또는 그로부터 전송되는 패킷이다. 필요한 경우 다른 패킷을 보내는데 최대한의 유연성을 허용하기 위해 필러 패킷은 최소의 길이를 가지는 것이 바람직하다. 서브 프레임 또는 역방향 링크 캡슐화 패킷 (아래 참조) 의맨 끝에서, 링크 제어기는 패킷 무결성을 유지하기 위해 남은 공간을 채우도록 필러 패킷의 길이를 정한다.

필러 패킷의 내용과 구조는 도 9 에 나타낸다. 도 9 에서 보듯이, 이 패킷 타입은 패킷 길이, 패킷 타입, 필러 바이트, 및 CRC 필드로 구성된다. 이 패킷 타입은 일반적으로 타입 0 으로 특정되며, 이는 1 바이트 타입 필드에 의해 나타낸다. 필러 바이트 필드의 비트 또는 바이트는 필러 패킷이 원하는 길이가 될 수 있도록 하기 위해 변화 가능한 숫자의 0 비트 값을 포함한다. 가장 작은 필러 패킷은 이 필드에 아무런 바이트도 포함하지 않는다. 즉, 패킷은 패킷 길이, 패킷 타입, 및 CRC 만을 포함하며, 소정의 3 바이트 고정 길이를 이용한다.

3. 비디오 스트림 패킷

비디오 스트림 패킷은 일반적으로 디스플레이 디바이스의 정사각형 영역을 업데이트 하기 위한 비디오 데이터를 운반한다. 이 영역의 크기는 단일 픽셀만큼 작을 수도 있고, 전 디스플레이만큼 클 수도 있다. 제한 없는 숫자의 스트림이 동시에 표시될 수 있으며, 모든 표시될 내용은 비디오 스트림 패킷 내에 포함되므로 시스템 자원에 의해 제한된다. 비디오 스트림 패킷의 형식 (비디오 데이터 형식 디스크립터) 은 도 10 에 나타낸다. 도 10 에서 보듯이, 이 패킷 타입은 패킷 길이 (2 바이트), 패킷 타입, 비디오 데이터 디스크립터, 디스플레이 속성, X 좌측 에지, Y 상단 에지, X 우측 에지, Y 하단 에지, X 및 Y 시작, 픽셀 카운트, 파라미터 CRC, 픽셀 데이터, 및 CRC 필드로 구성된다. 이 패킷 타입은 일반적으로 타입 1 로 특정되며, 1 바이트 타입 필드로 나타낸다.

위에서 논의한 공통 프레임 개념은 오디오 버퍼 사이즈를 최소화하고 대기시간을 감소하는 효과적인 방법이다. 그러나, 비디오 데이터에 있어서 한 비디오 프레임의 픽셀을 매체 프레임 내 복수의 비디오 스트림 패킷에 분산시켜야 할 필요가 있을 수 있다. 또한 단일 비디오 패킷의 픽셀이 디스플레이의 완전한 정사각형 윈도우와 정확히 대응되지 않을 가능성이 높다. 초당 30 프레임의 예시적 비디오 프레임 레이트에서 초당 300 서브 프레임이 존재하며, 이는 매체 프레임 당 10 서브 프레임이 된다. 각 프레임 당 480 열의 픽셀이 존재한다면, 각 서브 프레임 내의 비디오 스트림 패킷 각각은 48 열의 픽셀을 포함한다. 다른 상황에서, 비디오 스트림 패킷은 정수의 픽셀 열을 포함하지 않을 수도 있다. 매체 프레임 당 서브 프레임의 수가 (비디오 라인이라고도 하는) 비디오 프레임 당 열의 수로 완전히 나누어지지 않는 경우의 비디오 프레임 크기에 있어서 그러하다. 정수 개의 픽셀 열을 포함하지 않더라도, 각 비디오 스트림 패킷은 정수개의 픽셀을 포함하여야 한다. 각 픽셀이 한 바이트 이상인 경우, 또는 도 12 에 보여지는 것과 같은 팩트 (packed) 형식인 경우에 이것이 중요하다.

상기의 비디오 데이터 디스크립터 필드의 동작을 실현하기 위해 채용된 형식과 내용은 도 11a-11d 에 나타내었다. 도 11a-11d 에서, 비디오 데이터 포맷 디스크립터 필드는 현재 패킷 내 현재 스트림의 픽셀 데이터 내의 각 픽셀의 형식을 특정하는 16 비트 부호 없는 정수 형태의 2 바이트를 포함한다. 다른 비디오 스트림 패킷이 다른 픽셀 데이터 형식을 이용할 수 있으며, 즉 비디오 데이터 포맷 디스크립터의 다른 값을 이용할 수 있으며, 비슷하게 어떤 스트림 (디스플레이의 영역)이 그 데이터 형식을 온 더 플라이로 바꿀 수 있다. 비디오 데이터 포맷 디스크립터는 현재 패킷에 대한 픽셀 형식을 정의하며, 이는 특정 비디오 스트림의 라이프타임 동안 일정한 형식이 계속 사용되지 않는다는 것을 의미한다.

도 11a 내지 11d 는 비디오 데이트 포맷 디스크립터가 부호화 되는 방식을 보여준다. 이 그림들에서 사용된 바와 같이, 도 11에서 보는 것과 같이 비트 [15:13] 이 '000' 과 같을 때, 비디오 데이터는 픽셀 당 비트의 수가 비디오 데이터 포맷 디스크립터 워드의 비트 3 내지 0 에 의해 정의되는 흑백 픽셀 어레이로 구성된다. 비트 11 내지 4 는 이 경우에 0 으로 설정된다. 도 11 b 에서 보듯이, 대신 비트 [15:13] 이 '001' 일 때, 비디오 데이터는 각각 컬러 맵을 통해 컬러를 특정하는 컬러 픽셀 어레이로 구성된다. 이 경우에, 비디오 데이터 포맷 디스크립터 워드의 비트 5 내지 0 은 픽셀 당 비트 수를 정의하며, 비트 11 내지 6 은 0 으로 설정된다. 도 11c 에서 보듯이, 비트 [15:13] 이 대신 '010' 일 때, 비디오 데이터는, 레드 픽셀 당 비트의 수는 비트 11 내지 8 에 의해 정의되고, 그린 픽셀 당 비트의 수는 비트 7 내지 4 에 의해 정의되며, 블루 픽셀 당 비트 수는 비트 3 내지 0 에 의해 정의되는 컬러 픽셀 어레이로 구성된다. 이 경우에, 각 픽셀의 총 비트 수는 레드, 그린 및 블루에 대해 사용된 비트 수의 합이다.

그러나, 도 11d 에서 보듯이, 비트 [15:13] 이 대신 '011' 이면, 비디오 데이터는 휘도 (Y) 픽셀 당 비트 수는 비트 11 내지 8 에 의해 정의되고, Cr 성분의 비트 수는 비트 7 내지 4 에 의해 정의되며, Cb 성분의 비트 수는 비트 3 내지 0 에 의해 정의되는 광휘 (luminance) 와 색차 (chrominance) 정보를 가지는 4:2:2형식의 비디오 데이터 어레이로 구성된다. 각 픽셀의 총 비트 수는 레드, 그린 및 블루에 대해 사용된 비트 수의 합이다. Cr 과 Cb 성분은 Y 의 절반 레이트로 보내진다. 또한, 이 패킷의 픽셀 데이터 부분의 비디오 샘플은 다음과 같이 조직된다.:Y_n, Cr_n, Cb_n,Y_n+1, Cr_n+1, Cb_n+1,Y_n+2, Cr_n+2, Cb_n+2,Y_n+3…, 여기서 Cr_n및 Cb_n는 Y_n및 Y_n+1과 연관되어 있고, Cr_n+2및 Cb_n+2는 Y_n+2및 Y_n+3과 연관되어 있는 등이다. 현재 스트림에서 한 열 (X 우측 에지-X 좌측 에지 +1) 에 홀수의 픽셀이 있다면 다음 행의 첫 번째 픽셀의 Y 값이 각 열의 마지막 픽셀에 대응하는 Cb 값 다음에 올 것이다.

도면에서 보여진 모든 형식에 대해, "P" 로 표시된 비트 12 는 픽셀 데이터 샘플이 팩 되었는지 여부 또는 바이트-정렬 (byte-aligned) 픽셀 데이터를 특정한다. 이 필드의 0 값은 픽셀 데이터 필드의 각 픽셀과 각 픽셀 내의 각 컬러가 MDDI 인터페이스 바이트 경계로 바이트-정렬됨을 나타낸다. 1 값은 픽셀 데이터 필드의 각 픽셀과 각 픽셀 내의 각 컬러가 사용되지 않는 비트 없이 픽셀 내에, 이전의 픽셀 또는 컬러에 대해 팩 업 (packed up) 되었음을 나타낸다.

특정 디스플레이 윈도우에 대한 매체 프레임의 첫 번째 비디오 스트림 패킷내의 첫 번째 픽셀은 X 좌측 에지 및 Y 상단 에지로 정의된 스트림 윈도우의 좌상부로 가며, 다음 수신된 픽셀은 같은 열의 다음 픽셀 위치로 가고, 이렇게 계속된다. 매체 프레임의 첫 번째 패킷에서, X 시작 값은 보통 X 좌측 에지의 값과 같으며, Y 시작 값은 보통 Y 상부 에지 값과 같다. 같은 스크린 윈도우에 대응되는 다음의 패킷에서, X 와 Y 시작 값은 보통 이전 서브 프레임에서 전송된 비디오 스트림 패킷 내에서 보내진 마지막 픽셀 다음에 보통 오게 될 스크린 윈도우의 픽셀 위치로 정해진다.

4. 오디오 스트림 패킷

오디오 스트림 패킷은 디스플레이의 오디오 시스템을 통해 플레이될 오디오 데이터를 운반한다. 사운드 시스템의 개별적 오디오 채널에 대해 다른 오디오 데이터 스트림이 지정될 수 있으며, 예를 들면 다음과 같다: 좌측-전면, 우측-전면, 중앙, 좌측-후면 및 우측-후면, 사용되고 있는 오디오 시스템의 타입에 따른다. 강화된 공간-음향 (spatial-acoustic) 신호 프로세싱을 포함한 헤드세트에 대해 최대로 완전한 오디오 채널이 제공된다. 오디오 스트림 패킷의 형식은 도 13 에 나타낸다. 도 3 에서 보듯이, 이 패킷 타입은 패킷 길이, 패킷 타입, 오디오 채널 ID, 오디오 샘플 카운트, 샘플 및 패킹 당 비트, 오디오 샘플 레이트, 파라미터 CRC, 디지털 오디오 데이터, 및 오디오 데이터 CRC 필드로 구성된다. 이 패킷 타입은 일반적으로 타입 2 로 특정된다.

샘플 및 패킹 필드마다의 비트는 오디오 데이터의 패킹 포맷을 명확히 하는 8-비트의 부호 없는 정수의 형태로 1 바이트를 포함한다. 일반적으로 사용되는 포맷은 0 을 통한 4 비트가 PCM 오디오 샘플마다의 비트의 수를 정의하는 것이다. 그 후 비트 5 는 디지털 오디오 데이터 샘플이 패킹되었는지 여부를 명확히 한다. 패킹된 것과 바이트-얼라인드 오디오 샘플 (byte-aligned audio samples) 과의 차이는 도 14 에 도시되어 있다. '0' 의 값은 디지털 오디오 데이터 필드 각각의 PCM오디오 샘플이 MDDI 인터페이스 바이트 바운더리 (boundary) 에 의해 바이트-얼라인드되었다는 것을 나타내고, '1' 의 값은 각각의 연속적인 PCM 오디오 샘플이 이전의 오디오 샘플에 반하여 (against) 패킹된다는 것을 나타낸다. 이러한 비트는 0 을 통한 4 비트 (PCM 오디오 샘플마다 비트의 수) 안에서 정의된 값이 8 의 복수배가 아닌 경우에만 유효하다. 6 을 통한 7 비트는 미래의 사용을 위해 보존되고, 일반적으로 0 의 값으로 설정된다.

5. 보존된 스트림 패킷 (Reserved Stream Packets)

55 를 통한 패킷 타입 3 은 스트림 패킷이 접하게 되는 다양한 응용을 위해 바람직한 패킷 프로토콜의 미래 버전 또는 변화물에서의 사용을 위해 정의되도록 보존된다. 다시, 이것은 다른 기술과 비교하여 이전의 기술과 시스템 디자인을 바꾸는 면에서 MDD 인터페이스를 더욱 융통성 있고 유용하도록 만드는 부분이다.

6. 사용자-정의 스트림 패킷 (User-Defined Stream Packets)

63 을 통한 타입 56 으로 알려진 8 데이터 스트림 타입은 MDDI 링크와의 사용을 위한 설비 제조물에 의해 정의될 수 있는 소유 응용 (proprietary applications) 에서의 사용을 위해 보존된다. 이러한 것은 사용자-정의 스트림 패킷으로 알려져 있다. 비디오 스트림 패킷은 비디오 데이터를 운반하여 디스플레이의 사각 영역 (또는 사각형이 아닌 영역) 을 업데이트한다. 이러한 패킷 타입에 대한 스트림 변수 및 데이터의 정의는 그들의 사용을 찾는 명확한 설비 제조물로 남겨진다. 사용자-정의 스트림 패킷의 포맷은 도 15 에 도시된다. 도 15 에 도시된 것처럼, 이러한 타입의 패킷은 (2 바이트) 패킷 길이 (Packet Length), 패킷 타입,스트림 ID 넘버, 스트림 변수, 변수 CRC, 스트림 데이터, 및 스트림 데이터 CRC 필드를 갖도록 조직화된다.

7. 컬러 맵 패킷 (Color Map Packets)

컬러 맵 패킷은 디스플레이에 대한 컬러를 표시하는데 사용되는 컬러 맵 룩-업 (look-up) 테이블의 내용을 명확히 한다. 몇몇의 응용은 단독의 패킷에서 전송될 수 있는 데이터의 양보다 많은 컬러 맵을 요구할 수 있다. 이러한 경우, 복수의 컬러 맵 패킷은 전송되고, 각각의 컬러 맵 패킷은 하기에 상술할 오프셋 및 길이 필드 (length fields) 를 사용하여 컬러 맵의 다양한 서브셋을 갖는다. 컬러 맵 패킷의 포맷은 도 16 에 도시된다. 도 16 에 도시된 것처럼, 이러한 타입의 패킷은 패킷 길이, 패킷 타입, 컬러 맵 데이터 사이즈, 컬러 맵 오프셋, 변수 CRC, 컬러 맵 데이터 및 데이터 CRC 필드를 갖도록 조직화된다. 이러한 타입의 패킷은 일반적으로 타입 64 패킷으로 식별된다.

8. 역 링크 캡슐화 패킷 (Reverse Link Encapsulation Packets)

데이터는 역 링크 캡슐화 패킷을 이용하여 역 방향으로 전송된다. 순방향 링크 패킷은 전송되고, MDDI 링크 작용 (전송 방향) 은, 패킷이 역방향으로 전송될 수 있도록, 변화되거나 또는 이러한 패킷의 중간에서 턴-어라운드 (turn-around) 한다. 역 링크 캡슐화 패킷의 포맷은 도 17 에 도시된다. 도 17 에 도시된 것과 같이, 이러한 타입의 패킷은 패킷 길이, 패킷 타입, 역 링크 플래그 (Reverse Link Flags), 턴-어라운드 길이 (Turn-Around Length), 변수 CRT, 턴-어라운드 1, 역 데이터 패킷, 및 턴-어라운드 2 를 갖도록 조직화된다. 이러한 타입의 패킷은 일반적으로 타입 65 패킷으로 인식된다.

역 링크 캡슐화 패킷을 전송하는 동안 MDDI 링크 제어기는 특별한 방법으로 행동한다. MDD 인터페이스는 호스트에 의해 항상 구동되는 스트로브 신호 (strobe signal) 를 가지고 있다. 호스트는 마치 그것이 턴-어라운드 및 역 링크 캡슐화 패킷의 데이터 패킷 부분의 각각의 비트에 대해 0 을 전송하는 것처럼 행동한다. 호스트는 MDDI_스트로브 신호를, 2 턴-어라운드 타임 동안 및 역 데이터 패킷에 할당된 시간 동안, 각각의 비트 바운더리에서 토글한다. (이것은 마치 그것이 모든-0 데이터를 전송하는 것과 같은 행동이다.) 호스트는 턴-어라운드 1 에 의해 명확하게 된 기간 (time period) 동안 MDDI 데이터 신호 라인 구동기를 디세이블하고, 클라이언트는 턴-어라운드 2 필드에 의해 명확하게 된 기간을 따르는 구동기 리-인에이블 (re-enable) 필드 동안에 라인 구동기를 리-인에이블 한다. 디스플레이는 턴-어라운드 길이 변수를 읽고, 턴-어라운드 1 필드에서의 마지막 비트 후에 호스트 방향으로 즉시 데이터 신호를 구동한다. 디스플레이는 호스트에 패킷을 전송하는데 이용되는 시간의 길이를 알기 위해 패킷 길이 및 턴-어라운드 길이 변수를 이용한다. 클라이언트는 필러 패킷 (filler packets) 을 전송하거나 또는 클라이언트가 호스트에 전송할 데이터를 가지고 있지 않는 경우 데이터 라인을 0 상태로 구동한다. 만약 데이터 라인이 0 으로 구동된다면, 호스트는 이것을 (유효한 길이가 아닌) 0 의 길이를 갖는 패킷으로 이해하고, 호스트는 현재의 역 링크 캡슐화 패킷 동안 클라이언트로부터 더 이상의 패킷을 받아들이지 않는다.

디스플레이는 턴 어라운드 2 필드가 시작하기 전에 적어도 하나의 역 링크클럭 기간 동안 MDDI 데이터 라인을 0 레벨로 구동한다. 이것은 데이터 라인을 턴 어라운드 2 기간 동안 결정 상태 (deterministic state) 안에 있도록 유지한다. 만약 클라이언트가 전송할 더 이상의 패킷을 가지고 있지 않다면, (다른 곳에서 토론될) 휴면 바이어스 저항은 역 데이터 패킷 필드의 나머지에 대해 데이터 라인을 0 레벨로 유지하기 때문에 그것을 0 의 레벨로 구동한 후 심지어 데이터 라인을 디세이블할 수도 있다.

디스플레이 리퀘스트 및 상태 패킷 (State Packet) 의 역 링크 리퀘스트 필드는, 호스트에게 데이터를 되돌려 전송하기 위해, 호스트에게 디스플레이가 역 링크 캡슐화 패킷에서 필요하는 바이트의 수를 알려주는데 사용될 수 있다. 호스트는 역 링크 캡슐화 패킷에서 적어도 바이트의 수를 할당함으로써 요구를 승인하도록 시도한다. 호스트는 서브-프레임에서 하나보다 많은 역 링크 캡슐화 패킷을 전송할 수 있다. 디스플레이는 디스플레이 리퀘스트 및 상태 패킷을 기껏해야 임의의 시간에 전송할 수 있고, 호스트는 역 링크 리퀘스트 변수를 하나의 서브-프레임에서 요구되는 전체 바이트 수로 이해할 것이다.

9. 디스플레이 능력 패킷 (Display Capability Packets)

호스트는, 일반적으로 최적화되거나 요구되는 방법으로 호스트-에서-디스플레이 (host-to-display) 링크를 구성하기 위해, 통신하기 위한 디스플레이 (클라이언트) 능력을 아는 것이 필요하다. 디스플레이는 순방향 링크 동기화가 이루어진 후 디스플레이 능력 패킷을 호스트로 전송하는 것이 추천된다. 역 링크 캡슐화 패킷에서 역 링크 플래그를 이용하는 호스트에 의해 요구될 때, 그러한 패킷의 전송은 고려된다. 디스플레이 능력 패킷의 포맷은 도 18 에 도시된다. 도 18 에 도시된 것과 같이, 이러한 타입의 패킷은 패킷 길이, 패킷 타입, 프로토콜 버전, 민 프로토콜 버전 (Min Protocol Version), 비트맵 폭, 비트맵 높이, 모노크롬 능력, 컬러 맵 능력, RGB 능력, Y Cr Cb 능력, 디스플레이 특성 능력, 데이터 레이트 능력, 프레임 레이트 능력, 오디오 버퍼 깊이, 오디오 스트림 능력, 오디오 레이트 능력, 민 서브프레임 레이트, 및 CRC 필드로 조직화된다. 이러한 타입의 패킷은 일반적으로 타입 66 패킷으로 식별된다.

10. 키보드 데이터 패킷 (Keyboard Data Packers)

키보드 데이터 패킷은 클라이언트 디바이스로부터 호스트로 키보드 데이터를 전송하는데 이용된다. 무선 (또는 유선) 키보드는 헤드 마운티드 비디오 디스플레이 (head mounted video display) / 오디오 프리젠테이션 디바이스를 포함하는, 그러나 거기에 한정되지 않는, 다양한 디스플레이 또는 오디오 디바이스와 관련하여 사용될 수 있다. 키보드 데이터 패킷은 키보드-라이크 (keyboard-like) 디바이스로 알려진 여러 디바이스 중의 하나에서 수신된 키보드 데이터를 호스트로 릴레이한다. 이러한 패킷은 데이터를 키보드로 전송하는 순 방향 링크상에서 또한 사용될 수 있다. 키보드 데이터 패킷의 포맷은 도 19 에 도시되고, 키보드로부터 또는 키보드를 향해 정보의 많은 수의 바이트를 포함한다. 도 19 에 도시된 것과 같아. 이러한 타입의 패킷은 패킷 길이, 패킷 타입, 키보드 데이터, 및 CRC 필드를 갖도록 조직화된다. 이러한 타입의 패킷은 일반적으로 타입 67 패킷으로 식별된다.

11. 포인팅 디바이스 데이터 패킷 (Pointing Device Data Packets)

포인팅 디바이스 데이터 패킷은 무선 마우스 또는 디스플레이의 다른 포인팅 디바이스로부터 호스트 위치 정보를 전송하는데 사용된다. 데이터는 또한 이러한 패킷을 이용하여 순 방향 링크상에서 포인팅 디바이스로 전송될 수 있다. 포인팅 디바이스 데이터 패킷의 포맷은 도 20 에 도시되고, 포인팅 디바이스로부터 또는 포인팅 디바이스를 향해 정보의 많은 수의 바이트를 포함한다. 도 20 에 도시된 것과 같이 이러한 타입의 패킷은 패킷 길이, 패킷 타입, 포인팅 디바이스 데이터 및 CRC 필드를 갖도록 조직화된다. 이러한 타입의 패킷은 1-바이트 타입 필드에서 타입 68 패킷으로 일반적으로 식별된다.

12. 링크 셧다운 패킷 (Link Shutdown Packets)

링크 셧다운 패킷은, MDDI 데이터 및 스트로브가 셧다운되고 저-전력 소비 "휴면 (hibernation)" 상태로 가는 것을 나타내기 위해, 호스트로부터 클라이언트 디스플레이로 전송된다. 이러한 패킷은 링크를 셧다운시키고, 정적인 비트맵이 이동 통신장치로부터 디스플레이로 전송된 후 또는 호스트로부터 클라이언트로 잠시동안 전송할 정보가 더 이상 존재하지 않는 경우 전력을 보존한다. 일반적인 작동은 호스트가 패킷을 다시 전송할때 다시 시작된다. 휴면 후 전송되는 제 1 패킷은 서브-프레임 헤더 패킷이다. 디스플레이 상태 패킷의 포맷은 도 21 에 도시된다. 도 21 에 도시된 것과 같이, 이러한 타입의 패킷은 1-바이트 타입 필드에서의 타입 69 패킷으로 일반적으로 식별되고, 먼저-선택된 고정된 3 바이트 길이를 이용한다.

저-전력 휴면 상태에서, MDDI_DATA 구동기는 디세이블되어 고-임피던스 상태가 되고, MDDI_DATA 신호는 디스플레이에 의해 과구동될 수 있는 고-임피던스 바이어스 네트워크를 이용한 로직 0 상태로 당겨진다. 인터페이스에 의해 이용되는 스트로브 신호는 전력 소비를 줄이기 위해 휴면 상태에서 로직 0 레벨로 설정된다. 호스트 또는 디스플레이 중 하나는 MDDI 링크를 휴면 상태에서부터 다른 곳에서 상술할 "깨어나게 (wake up)" 할 수 있고, 그것은 본 발명의 중요한 진전이며 이점이다.

13. 디스플레이 리퀘스트 및 상태 패킷 (Display Request and Status Packets)

호스트는 최적 방법으로 호스트-에서-디스플레이 (host-to-display) 링크를 구성할 수 있기 위해, 호스트는 디스플레이부터 적은 양의 정보를 필요로 한다. 디스플레이가 각각의 서브-프레임마다 하나의 디스플레이 상태 패킷을 호스트에 전송하는 것이 추천된다. 디스플레이는 이러한 패킷을 역 링크 캡슐화 패킷에서의 제 1 패킷으로서 전송하여 그것이 호스트로 확실하게 인도된다는 것을 확실하게 한다. 디스플레이 상태 패킷의 포맷은 도 22 에 도시된다. 도 22에 도시된 것과 같이, 이러한 타입의 패킷은 패킷 길이, 패킷 타입, 역 링크 퀘스트, CRT 에러 카운트, 및 CRC 필드를 가지도록 조직화된다. 이러한 타입의 패킷은 일반적으로 1-바이트 타입 필드에서 타입 70 패킷으로 일반적으로 식별되고, 미리-선택된 고정된 8 바이트 길이를 이용한다.

역 링크 리퀘스트 필드는 호스트에게, 호스트에게 데이터를 되돌아 전송하기 위해, 디스플레이가 역 링크 캡슐화 패킷에서 필요로 하는 바이트의 수를 알려주는데 사용될 수 있다. 호스트는 역 링크 캡슐화 패킷에서 적어도 상기 바이트의 수를할당함으로써 리퀘스트를 승인하도록 시도한다. 호스트는 데이터를 수용하기 위해 서브-프레임에서 하나보다 많은 역 링크 캡슐화 패킷을 전송할 수 있다. 디스플레이는 디스플레이 리퀘스트 및 상태 패킷을 임의의 시간에 전송할 수 있고, 호스트는 역 링크 리퀘스트 변수를 하나의 서브-프레임에서 요구되는 전체 바이트 수로 이해할 것이다. 역 링크 데이터가 어떻게 호스트로 되돌려 전송될 수 있는지에 대한 추가적인 세부사항 및 명확한 예는 아래에 설명된다.

14. 비트 블록 전송 패킷 (Bit Block Transfer Packets)

비트 블록 전송 패킷은 디스플레이의 스크롤 영역을 어떠한 방향으로도 스크롤 할 수 있는 수단을 제공한다. 이러한 능력을 갖고 있는 디스플레이는 디스플레이 능력 패킷의 디스플레이 특성 능력 지시자의 0 비트 안에서 능력을 보고한다. 비트 블록 전송 패킷의 포맷은 도 23에 도시되어 있다. 도 23 에 도시된 것과 같이, 이러한 타입의 패킷은 패킷 길이, 패킷 타입, 상단 왼쪽 X, 상단 왼쪽 Y 값, 윈도우 폭, 윈도우 높이, 윈도우 X 이동, 윈도우 Y 이동 및 CRC 필드를 갖도록 조직화된다. 이러한 타입의 패킷은 타입 71 패킷으로 식별되고, 미리-선택된 고정된 15 바이트 길이를 이용한다.

필드는 이동되는 윈도우의 상단 왼쪽 모서리 좌표의 X 값 및 Y 값, 이동되는 윈도우의 폭 및 높이, 및 윈도우가 수평 및 수직으로 각각 이동하는 픽셀의 수를 명확히 하는데 사용된다. 후자의 두 개의 필드에 대한 양의 값 (positive value) 는 윈도우가 오른쪽 및 아래로 이동되도록 유발하고, 음의 값은 각각 왼쪽 및 위로 이동하도록 유발한다.

15. 비트맵 영역 필 패킷 (Bitmap Area Fill Packets)

비트맵 영역 필 패킷은 디스플레이 영역을 하나의 컬러로 쉽게 초기화하는 수단을 제공한다. 이러한 능력을 가지는 디스플레이는 디스플레이 능력 패킷의 디스플레이 특성 능력 지시자 필드의 1 비트 안에서 능력을 보고한다. 비트맵 영역 필 패킷의 포맷은 도 24 에 도시된다. 도 24 에 도시된 것과 같이, 이러한 타입의 패킷은 패킷 길이, 패킷 타입, 상단 왼쪽 X 값, 상단 왼쪽 Y 값, 윈도우 폭, 윈도우 높이, 데이터 포맷 디스크립터, 픽셀 에어리어 필 값 (Pixel Area Fill Value), 및 CRC 필드를 갖도록 조직화된다. 이러한 타입의 패킷은 1-바이트 타입 필드에서 타입 72 패킷으로 일반적으로 식별되고, 미리-선택된 고정된 17 바이트 길이를 이용한다.

16. 비트맵 패턴 필 패킷 (Bitmap Pattern Fill Packets)

비트맵 패턴 필 패킷은 디스플레이 영역을 미리-선택된 패턴으로 쉽게 초기화하는 수단을 제공한다. 이러한 능력을 갖는 디스플레이는 디스플레이 능력 패킷의 디스플레이 특성 능력 지시자 필드의 2 비트 안에서 능력을 보고한다. 필 패턴의 상단 왼쪽 모서리는 채워질 윈도우의 상단 왼쪽 모서리로 정렬된다. 채워질 윈도우가 필 패턴보다 더 넓거나 또는 더 높을 때, 그 때 패턴은 윈도우를 채우기 위해 수평 또는 수직으로 몇 번 반복할 수 있다. 마지막 반복된 패턴의 오른쪽 또는 바닥은 필요한대로 종결된다. 만약에 윈도우가 필 패턴보다 더 적다면, 그 후 필 패턴의 오른쪽 면 또는 바닥은 윈도우를 맞추기 위해 종결된다.

비트맵 패턴 필 패킷의 포맷은 도 25 에 도시된다. 도 25 에 도시된 것과 같이, 이러한 타입의 패킷은 패킷 길이, 패킷 타입, 상단 왼쪽 X 값, 상단 왼쪽 Y 값, 윈도우 폭, 윈도우 높이, 패턴 폭, 패턴 높이, 데이터 포맷 디스크립터, 변수 CRT, 패턴 픽셀 데이터, 및 픽셀 데이터 CRC 필드를 갖도록 조직화된다. 이러한 타입의 패킷은 1-바이트 타입 필드에서 타입 73 패킷으로 일반적으로 식별된다.

17. 통신 링크 데이터 채널 패킷 (Communication Link Data Channel Packets)

통신 링크 데이터 채널 패킷은 PDA 와 같은 높은-레벨 컴퓨팅 능력을 가지는 디스플레이가, 이동 전화 또는 무선 데이터 포트 디바이스와 같은 무선 수신기를 가지고 통신하도록 하는 수단을 제공한다. 이러한 상황에서, MDDI 링크는 통신장치와 이동 디스플레이를 갖는 컴퓨팅 디바이스 사이의 편리한 고-스피드 인터페이스로서 행동하는데, 여기에서 이러한 패킷은 디바이스를 위한 오퍼레이팅 시스템의 데이터 링크 레이어에서 데이터를 전송한다. 예를 들어, 웹 브라우저, 이메일 클라이언트 또는 전체 PDA 가 이동 표시디바이스로 만들어졌다면, 이러한 패킷은 사용될 수 있다. 이러한 능력을 가지는 디스플레이는 디스플레이 능력 패킷의 디스플레이 특성 능력 지시자 필드의 3 비트 안에서 능력을 보고할 것이다.

통신 링크 데이터 채널 패킷의 포맷은 도 26 에 도시된다. 도 26 에 도시된 것과 같이, 이러한 타입의 패킷은 패킷 길이, 패킷 타입, 변수 CRT, 통신 링크 데이터, 및 통신 데이터 CRC 필드를 갖도록 조직화된다. 이러한 타입의 패킷은 타입 필드에서 타입 74 패킷으로 일반적으로 식별된다.

18. 인터페이스 타입 핸드오프 리퀘스트 패킷 (Interface Type HandoffRequest Packets)

인터페이스 타입 핸드오프 리퀘스트 패킷은 호스트가, 클라이언트 또는 디스플레이가 존재하는 또는 현재의 모드로부터 타입-Ⅰ(직렬), 타입-Ⅱ(2-비트 병렬), 타입-Ⅲ(4-비트 병렬), 또는 타입-Ⅳ(8-비트 병렬) 모드로 이동하는 것을 요구할 수 있도록 한다. 호스트가 특별한 모드를 요구하기 전에, 디스플레이가 요구되는 모드에서 동작할 수 있다는 것을 디스플레이 능력 패킷의 디스플레이 특성 능력 지시자 필드의 6 및 7 비트를 시험하여 명확히 하여야 한다. 인터페이스 타입 핸드오프 리퀘스트 패킷의 포맷은 도 27 에 도시된다. 도 27 에 도시된 것과 같이, 이러한 타입의 포맷은 패킷 길이, 패킷 타입, 인터페이스 타입, 및 CRC 필드를 갖도록 조직화된다. 이러한 타입의 패킷은 타입 75 패킷으로 일반적으로 식별되고, 미리-선택된 고정된 길이의 4 비트를 이용한다.

19. 인터페이스 타입 인정 패킷 (Interface Type Acknowledge Packets)

인터페이스 타입 인정 패킷은 인터페이스 타입 핸드오프 패킷의 수신을 확실히하기 위해 디스플레이에 의해 전송된다. 요구되는 모드, 타입-Ⅰ(직렬), 타입-Ⅱ(2-비트 병렬), 타입-Ⅲ(4-비트 병렬), 또는 타입-Ⅳ(8-비트 병렬) 모드는 이러한 패킷에서 변수로서 호스트에 되돌아 에코된다. 인터페이스 타입 인정 패킷의 포맷은 도 28 에 도시된다. 도 28 에 도시된 것과 같이, 이러한 타입의 패킷은, 패킷 길이, 패킷 타입, 인터페이스 타입, 및 CRC 필드를 갖도록 조직화된다. 이러한 타입의 패킷은 타입 76 패킷으로 일반적으로 식별되고, 미리-선택된 고정된 길이의 4 비트를 이용한다.

20. 실행 타입 핸드오프 패킷 (Perform Type Handoff Packets)

실행 타입 핸드오프 패킷은 호스트가 디스플레이에 명령하여 이러한 패킷에서 명확하게 된 모드로 핸드오프하도록 하는 수단이다. 이것은 인터페이스 타입 핸드오프 리퀘스트 패킷 및 인터페이스 타입 인정 패킷에 의해 이전에 요구되고 인정된 동일한 모드이다. 이러한 패킷이 전송된 후, 호스트 및 디스플레이는 동의된 모드로 스위칭하여야 한다. 디스플레이는 모드가 변하는 동안 링크 동기화를 잃고 다시-얻을 수 있다. 실행 타입 핸드오프 패킷의 포맷은 도 29 에 도시된다. 도 29 에 도시된 것과 같이, 이러한 타입의 패킷은 패킷 길이, 패킷 타입 및 CRC 필드를 갖도록 조직화된다. 이러한 타입의 패킷은 1-바이트 타입 필드에서 타입 77 패킷으로 일반적으로 식별되고, 미리-선택된 고정된 길이의 4 비트를 이용한다.

21. 순방향 오디오 채널 인에이블 패킷 (Forward Audio Channel Enable Packets)

이 패킷은 호스트가 디스플레이에서 오디오 채널을 인에이블 또는 디세이블하는 것을 허용한다. 호스트에 의해 출력될 오디오가 없는 경우 디스플레이 (클라이언트) 가 오디오 증폭기의 전원 또는 유사한 구성요소의 전원을 꺼서 전력을 절약할 수 있기 위해, 이러한 능력은 유용하다. 오디오 스트림의 존재 또는 부재를 지시자로 이용하여 함축적으로 간단하게 구현하는 것은 상당히 훨씬 더 어렵다. 디스플레이 시스템의 전원이-들어오는 기본 상태는 모든 오디오 채널이 인에이블되는 것이다. 순방향 오디오 채널 인에이블 패킷의 포맷은 도 30 에 도시된다. 도 30 에 도시된 것과 같이, 이러한 타입의 패킷은 패킷 길이, 패킷 타입, 오디오 채널 인에이블 마스크 및 CRC 필드를 갖도록 조직화된다. 이러한 타입의 패킷은 1-바이트 타입 필드에서 타입 78 패킷으로 일반적으로 식별되고, 미리-선택된 고정된 길이의 4 비트를 이용한다.

22. 역 오디오 샘플 레이트 패킷 (Reverse Audio Sample Rate Packets)

이 패킷은 호스트가 역-링크 오디오 채널을 인에이블 하거나 또는 디세이블하는 것과 이 스트림의 오디오 데이터 샘플 레이트를 설정하는 것을 허용한다. 호스트는 디스플레이 능력 패킷에서 유효하도록 정의된 샘플 레이트를 선택한다. 만약 호스트가 유효하지 않는 샘플 레이트를 선택한다면, 디스플레이는 호스트에게 오디오 스트림을 전송하지 않을 것이다. 호스트는 샘플 레이트를 255 로 설정함으로써 역-링크 오디오 스트림을 디세이블할 수 있다. 기본 상태는 디스플레이 시스템이 초기에 전원이-업 되거나 또는 디세이블된 역-링크 오디오 스트림에 연결될 때 가정된다. 역 오디오 샘플 레이트 패킷의 포맷은 도 31 에 도시된다. 도 31 에 도시된 것과 같이, 이러한 타입의 패킷은 패킷 길이, 패킷 타입, 오디오 샘플 레이트 및 CRC 필드를 갖도록 조직화된다. 이러한 타입의 패킷은 타입 79 패킷으로 일반적으로 식별되고, 미리-선택된 고정된 길이의 4 비트를 이용한다.

23. 디지털 콘텐트 프로텍션 오버헤드 패킷 (Digital Content Protection Overhead Packets)

이 패킷은 호스트 및 디스플레이가 사용되는 디지털 콘텐트 프로텍션 방법에 관련하여 메시지를 교환하도록 허용한다. 곧 두 타입의 콘텐트 프로텍션, 디지털 전송 콘텐트 프로텍션 (DTCP), 또는 고-대역폭 디지털 콘텐트 프로텍션 시스템(HDCP) 가 미래의 선택적인 프로텍션 계획 지정을 위해 보존된 룸을 가지고, 심사숙고된다. 사용되고 있는 방법은 이 패킷에서 콘텐트 프로텍션 타입 변수에 의해 명확해진다. 디지털 콘텐트 프로텍션 오버헤드 패킷의 포맷은 도 32 에 도시된다. 도 32 에 도시된 것과 같이, 이러한 타입의 패킷은 패킷 길이, 패킷 타입, 콘텐트 프로텍션 타입, 콘텐트 프로텍션 오버헤드 메시지 및 CRC 필드를 갖도록 조직화된다. 이러한 타입의 패킷은 타입 80 패킷으로 일반적으로 식별된다.

24. 투명한 컬러 인에이블 패킷 (Transparent Color Enable Packets)

투명한 컬러 인에이블 패킷은 어떠한 컬러가 디스플레이에서 투명한가를 명확히 하는데 사용되고 디스플레이 이미지를 위한 투명한 컬러의 사용을 인에이블 하거나 또는 디세이블하거나 하는데 사용된다. 이러한 능력을 가지고 있는 디스플레이는 디스플레이 능력 패킷의 디스플레이 특성 능력 지시자 필드의 4 비트 안에서 능력을 보고한다. 투명한 컬러에 대한 값을 가지고 있는 픽셀이 비트맵으로 기록될 때, 컬러는 이전 값에서부터 변화하지 않는다. 투명한 컬러 인에이블 패킷은 도 33 에 도시된다. 도 33 에 도시된 것과 같이, 이러한 타입의 패킷은 패킷 길이, 패킷 타입, 투명한 컬러 인에이블, 데이터 포맷 디스크립터, 투명한 픽셀 값, 및 CRC 필드를 갖도록 조직화된다. 이러한 타입의 패킷은 1-바이트 타입 필드에서 타입 81 패킷으로 일반적으로 식별되고, 미리-선택된 고정된 길이의 10 비트를 이용한다.

25. 라운드 트립 딜레이 측정 패킷 (Round Trip Delay Measurement Packets)

라운드 트립 딜레이 측정 패킷은 호스트로부터 클라이언트(디스플레이) 까지의 전파 딜레이에 더하여 클라이언트 (디스플레이) 로부터의 호스트로 되돌아가는 딜레이를 측정하는데 사용된다. 이 측정은 본래부터 라인 구동기, 수신기, 및 연결된 서브-시스템에 존재하는 딜레이를 포함한다. 이 측정은 턴 어라운드 딜레이 및 일반적으로 상술한 역 링크 캡슐화 패킷에서의 역 링크 레이트 제수 (devisor) 변수를 설정하는데 사용된다. 이 패킷은 MDDI 링크가 특별한 응용을 의도하는 최대한의 속도로 달리는 경우 가장 유용하다. MDDI_Stb 신호는 다음 필드 동안에 모든 0 데이터가 전송되는 것처럼 행동한다. : 모든 0, 양 쪽 보호 시간 (Guard Times), 및 측정 기간. 이것은 측정 기간동안 디스플레이에서 주기적인 클럭으로 사용될 수 있도록 하기 위해, MDDI_Stb 가 절반의 데이터 레이트로 토글하도록 유발한다.

라운드 트립 딜레이 측정 패킷의 포맷은 도 34 에 도시된다. 도 34 에 도시된 것과 같이, 이러한 타입의 패킷은 패킷 길이, 패킷 타입, 변수 CRT, 모든 0, 보호 시간 1, 측정 기간, 보호 시간 2, 및 구동 재-인에이블 필드를 갖도록 조직화된다. 이러한 타입의 패킷은 일반적으로 타입 82 패킷으로 식별되고, 미리-선택된 고정된 길이의 533 비트를 이용한다.

라운드 트립 딜레이 측정 패킷 동안 발생하는 이벤트의 타이밍은 도 35 에 도시된다. 도 35에서, 변수 CRC 및 모든 0 및 보호 시간 1 필드에 의해 따라오는 스트로브 정렬 필드에 의해 도시되고, 호스트는 라운드 트립 딜레이 측정 패킷을 전송한다. 딜레이 (3502) 는 패킷이 클라이언트 디스플레이 디바이스 또는 처리 회로에 도달하기 전에 발생한다. 디스플레이가 패킷을 수신할 때, 디스플레이는 디스플레이에 의해 결정된 측정 기간의 시작에서 실제와 같이 0xff, 0xff, 0x0 패턴을가능한한 정확하게 전송한다. 디스플레이가 이러한 시퀀스를 전송하기 시작하는 실제 시간은 호스트의 관점에서 볼 때 측정 기간의 시작으로부터 딜레이된다. 이러한 딜레이의 양은 정확하게 패킷이 라인 구동기 및 수신기를 및 연결 서브시스템을 통해 전파되는데 걸리는 시간이다. 유사한 양의 딜레이 (3504) 가 패턴이 디스플레이로부터 호스트로 되돌아 전파되어 발생한다.

신호가 클라이언트까지 갔다 왔다하는 라운드 트립 딜레이 시간을 정확히 결정하기 위해, 호스트는 0xff, 0xff, 0x0 시퀀스의 시작이 도착하자마자 탐지될 때까지, 측정 기간의 시작 후 발생하는 비트 타임 기간의 수를 카운트한다. 정보는 호스트로부터 클라이언트까지 이동하고 다시 되돌아오는 라운드 트립 신호 동안의 시간의 양을 결정하는데 사용된다. 그 후, 약 이러한 양의 절반이 클라이언트로의 신호의 편도 방향 이동으로 생겨난 딜레이에 할당된다.

디스플레이는 마지막 0xff, 0xff, 0x0 패턴을 전송한 후, 라인 구동기를 실질상 즉시 디세이블한다. 보호 시간 2 는 호스트가 다음 패킷의 패킷 길이를 전송하기 전에, 디스플레이의 라인 구동기가 고-임피던스 상태로 완전히 될 수 있도록 하는 시간을 허용한다. 휴면 (Hibernation) 풀-업 및 풀-다운 저항 (도 42) 은 MDDI_Data 신호가 라인 구동기가 호스트 및 디스플레이 양 쪽에서 디세이블된 간격에서 유효한 낮은 레벨로 고정된다는 것을 확신한다.

26. 순방향 링크 스큐 캘리브레이션 패킷 (Forward Link Skew Calibration Packet)

순방향 링크 스큐 캘리브레이션 패킷은 클라이언트 또는 디스플레이가MDDI_Stb 신호와 관련하여 MDDI-Data 신호의 전파 딜레이에서의 차이에 대해 그자체를 캘리브레이트하는 것을 허용한다. 딜레이 스큐 보상이 없이, 최대의 데이터 레이트는 이러한 딜레이에서 잠재적인 최악의-경우 변화를 설명하도록 일반적으로 제한된다. 일반적으로, 이 패킷은 단지 순방향 링크 데이터 레이트가 약 50 Mbps 또는 더 낮은 레이트로 구성될 때 전송된다. 디스플레이를 캘리브레이트하기 위해 이 패킷을 전송한 후, 데이터 레이트는 50Mbps 이상으로 오를 수 있다. 만약 데이터 레이트가 스큐 캘리브레이션 처리 도중에 너무 높게 설정되면, 디스플레이는 딜레이 스큐 보상 설정을 하나의 비트 시간보다 많도록 오프 (off) 되도록 하는 비트 기간의 얼라이어스 (alias) 로 동기화하고, 에러 데이터 클러킹을 만든다. 인터페이스의 가장 높은 데이터 레이트 타입 또는 가장 좋은 가능한 인터페이스 타입은, 모든 존재하는 데이터 비트가 캘리브레이트되게 하기 위해 순방향 링크 스큐 캘리브레이션 패킷을 전송하기 전에 선택된다.

순방향 링크 스큐 캘리브레이션 패킷의 포맷은 도 56 에 도시된다. 도 56 에 도시된 것과 같이, 이러한 타입의 패킷은 패킷 길이 (2 바이트), 패킷 타입, 변수 CRT, 캘리브레이션 데이터 시퀀스, 및 CRT 를 가지도록 구조화되어 있다. 이러한 타입의 패킷은 타입 필드에서 타입 83 패킷으로 일반적으로 식별되고, 미리-선택된 515 의 길이를 가지고 있다.

D. 패킷 CRC

CRC 필드는 패킷의 말단에 그리고 종종 현저하게 큰 데이터 필드, 즉, 전송 중 에러의 증가 가능성을 갖는 패킷의 특정한 보다 중요한 파라미터 이후에 발생한다. 2 가지의 CRC 필드를 갖는 패킷에서, 오직 하나가 이용되는 CRC 생성기는 제 1 CRC 이후에 재초기화되어, 롱 데이터 필드 이후의 CRC 계산이 패킷의 시작 시 파라미터의 영향을 받지 않는다.

본 발명의 예시적인 실시예에서, CRC 계산에 이용되는 다항식은 X¹⁶+X¹⁵+X²+X⁰로서 알려져있다. 본 발명에서 구현되는 CRC 생성기와 체커 (3602) 의 샘플 구현을 도 36 에 나타낸다. 도 36 에서, CRC 생성기 (3602) 는Tx_MDDI_Data_Before_CRC 라인 상에 입력되는 패킷의 제 1 비트의 전송 직전에 0X0001 값으로 초기화되고, 패킷의 바이트들은 레지스터로 변환되어 먼저 LSB 에 의해 시작된다. 도면의 레지스터 비트 넘버는 이용되는 다항식의 차수에 대응하며, MDDI 에 의하여 이용되는 위치에 대응되지 않는다. 단일 방향으로 CRC 레지스터를 변환하는 것이 보다 효과적이며, CRC 비트 (15) 를 갖는 결과는 MDDI CRC 필드의 비트 포지션 0 에서 나타나고, CRC 레지스터 비트 (14) 를 갖는 결과는 MDDI CRC 필드 비트 포지션 1 로 나타나며, MDDI 비트 포지션 (14) 에 도달될때까지 계속된다.

예로서, 디스플레이 요구 및 상태 패킷에 대한 패킷 콘텐츠는, 0x07, 0x46, 0x000400, 0x00 이며 (또는 0x07, 0x00, 0x46, 0x00, 0x04, 0x00, 0x00) 과 같은 일련의 바이트로 나타낸다), 다항식 (3604, 3606) 및 NAND 게이트 (3608) 의 입력을 이용하여 제출된다면, Tx_MDDI_Data_With_CRC 라인 상의 결과 CRC 출력은 0x0eal 이다 (또는, 0xal, 0x0e 와 같은 일련으로 표현된다).

CRC 생성기 및 체커 (3600) 이 CRC 체커로서 구성될 때, Rc_MDDI_Data 라인상에 수신된 CRC 는 멀티플렉서 (3604) 및 NAND 게이트 (3608) 으로 입력되어, NOR 게이트 (3610), 절대적 OR (XOR) 게이트 (3612) 및 AND 게이트 (3614) 를 이용하는 CRC 레지스터에서 발견되는 값에 의하여 비트 바이 비트로 비교된다. 어떠한 에러가 있는 경우, AND 게이트 (3614) 에 의한 출력으로서, CRC 는 게이트 (3614) 의 출력을 레지스터 (3602) 의 입력에 접속함으로써 CRC 에러를 포함하는 각각의 패킷에 대하여 증가된다. 도 36 의 도면에 나타낸 예시적인 회로는 주어진 CHECK_CRC_NOW 윈도우 내에서의 하나의 CRC 에러 신호보다 더 출력할 수 있다 (도 37b 참조). 따라서, CRC 에러 카운터만이 CHECK_CRC_NOW 가 활성화되는 각각의 인터벌 내에서의 제 1 CRC 에러를 카운트할 수 있다. CRC 생성기로서 구현되는 경우, CRC 는 패킷의 단부에 대응하는 때에 CRC 레지스터의 클록 아웃된다.

입력 및 출력 신호 및 인에이블링 신호에 대한 타이밍을 도 37a 및 도 37b 에 그래프로 나타낸다. CRC 의 생성 및 데이터 패킷의 전송을 Tx_MDDI_Data_Before_CRC 및 Tx_MDDI_DATA_With_CRC 신호 에 따라 도 37a 에 Gen_Reset, Check_CRC_Now. Generate_CRC_Now 및 Sending_MDDI_Data 신호 상태 (0 또는 1) 로 나타낸다. 데이터 패킷의 리셉션 및 CRC 값의 체킹을 도 37b 에 Rx_MDDI_Data 및 CRC 에러 신호에 따라 Gen_Reset, Check_CRC_Npw, Generate_CRC_Now, 및 Sending_MDDI_Data 신호 상태로 나타낸다.

V. 휴면으로부터의 링크 재시작

호스트가 MDDI_Data 를 구동하는 휴면 상태로부터 논리 휴면 상태로 약 150 μsec 동안 전방 링크를 재시작하고 MDDI_Stb 를 활성화함과 동시에 MDDI_Data 를로직 제로 상태로 50 μsec 동안 구동할 때, 서브-프레임 헤더 패킷을 전송하여 전방 링크 트래픽을 시작한다. 일반적으로, 버스 콘텐션은 서브프레임 헤더 패킷이 신호들 사이에 충분한 세틀링 시간을 제공함으로싸 수신되기 이전에 해결된다.

다른 기간이 원하는데로 이용될 수 있지만, 클라이언트, 여기서는 디스플레이가 호스트로부터 데이터 또는 통신을 필요로 할 때, 70 μsec 동안 로직 상태로 MDDI_Data0 라인을 구동하고, 높은 임피던스 상태에 위치시킴으로써 드라이버를 기스에이블한다. 이 액션은 호스트로하여금 전방 링크 (208) 상의 데이터 트래픽을 시작 또는 재시작하도록 하고, 상태에 대해 클라이언트를 폴 (poll) 하도록 한다. 호스트는 50 μsec 내의 요구 펄스의 존재를 검출하고, 150 μsec 동안 로직으로 및 50 μsec 이상 동안 로직 상태에서 MDDI_Data0 구동 스타트업 시퀀스를 시작해야 한다. 휴면 프로세싱 및 스타트 업 시퀀스와 관련되는 시간 간격의 오차 및 시간의 선택의 특성은 아래에서 더 설명된다.

콘텐션이 없는 일반적인 서비스 요구 이벤트 (3800) 에 대한 프로세싱 단계의 예를, 편의를 위해 이벤트를 문자 A, B, C, D, F, F, 및 G 를 이용하여 표시한 도 38 에 나타낸다. 프로세스는 포스트가 링크 셧다운 패킷을 클라이언트 디바이스로 전송할 때 포인트 A 에서 링크가 저전압 휴면 상태로 변환될 것을 알려주기 시작한다. 다음 단계에서, 호스트는 점 B 에 나타낸 바와 같이 저전압 휴면 상태를 MDDI_Data0 드라이버를 디스에이블링하고 로직 제로로 MDDI_Stb 드라이버를 설정함으로써 입력한다. MDDI_Data0 은 고 임피던스 바이어스 네트워크에 의해 제로 라벨로 구동된다. 몇몇 시간 주기 이후에, 클라이언트는 MDDI_Data0 을 점 C 에서 보여지는 바와 같이 로직 레벨로 구동하여 서비스 요구 펄스를 호소트에 전송한다. 호스트는 고 임피턴스 바이어스 네트워크를 이용하여 제로 라벨을 거의 할당하지 않지만, 클라이언트 드라이버는 라인을 로직 레벨로 하도록 한다. 점 D 에 나타낸 바와 같이, 50 μsec 에서, 호스트는 서비스 요구 펄스를 인식하고 MDDI_Data0 상의 로직 레벨을 그 드라이버를 인에이블링함으로써 할당한다. 다음으로, 점 E 에 나타낸 바와 같이, 클라이언트는 서비스 요구 펄스를 할당을 중지하고, 클라이언트는 드라이버를 고-임피던스 상태로 위치시킨다. 호스트는 점 F 에 나타낸 바와 같이 MSSI_Data0 을 로직 제로 레벨로 50 μsec 동안 구동하며, 또한 MDDI_Data0 상의 로직 제로 레벨로 지속되는 방법으로 MDDI_Stb 를 생성하기 시작한다. MDDI_Data0 를 제로 레벨로 할당하고 50 μsec 동안 MDDI_Stb 를 구동한 후, 호스트는 점 G 에 나타낸 바와 같이 서브-프레임 헤더 패킷을 전송하여 전방 링크 상의 데이터를 전송하기 시작한다.

유시한 예를 서비스 요구가 링크 재시작 시퀀스가 시작된 이후에 할당되고 이벤트가 문자 A, B, C, D, E, F, 및 G 로 다시 표시되는 도 39 에 나타낸다. 이는 클라이언트로부터의 요구 펄스가 서브-프레임 헤더 패킷을 오염시키는 최악의 경우 시나리오를 나타낸다. 이 프로세스는 호스트가 다시 링크 셧다운 패킷을 클라이언트 디바이스에 전송할 때 점 A 에서 링크가 저전압 휴면 상태로 변환할 것을 알려주기 시작한다. 다음 단계에서, 점 B 에 나타낸 바와 같이, 호스트는 MDDI_Data0 드라이버를 디스에이블링하고 MDDI_Stb 드라이버를 로직 제로로 설정하여 저전압 휴면 상태를 입력한다. 이전에, MDDI_Data0 는 고 임피던스 바이어스 네트워크로제로 라벨화되도록 구동된다. 시간 주기 이후에, 호스트는 점 C 에 나타낸 바와 같이 MDDI_Data0 를 로직 제로 레벨로 150 μsec 동안 구동하여 링크 재시작 시퀀스를 시작한다. 링크 재시작 시퀀스를 시작한 후 50 μsec 통과 이전에, 디스플레이는 또한 점 D 에 나타낸 바와 같이 70 μsec 동안 MDDI_Data0 를 할당한다. 이는 디스플레이가 호스트로부터 서비스를 요구할 필요를 갖고 호스트가 이미 링크 재시작 시퀀스를 시작하였다는 것을 인식하지 않기 때문에 발생한다. 다음으로, 점 E 에 나타낸 바와 같이 클라이언트는 서비스 요구 펄스를 할당하기 시작하며, 클라이언트는 그 드라이버를 고 임피던스 상태로 위치시킨다. 호스트는 MDDI_Data0 를 로직 레벨에 지속적으로 구동한다. 호스트는 점 F 에 나타낸 바와 같이 MDDI_Data0 를 로직 제러 레벨에 50 μsec 동안 구동하고, MDDI_Data0 상의 로직 제로 레벨에 일치하는 방식으로 MDDI_Stb 를 생성하기 시작한다. MDDI_Data0 를 제로 레벨로 할당하고 50 μsec 동안 MDDI_Stb 를 구동한 후, 점 G 에 나타낸 바와 같이 호스트는 서브프레임 헤더 패킷을 전송하여 데이터를 전방 링크 상에 전송하기 시작한다.

VI. 인터페이스 전기 설계서

본 발명의 예시적인 실시예에서, Non-Return-ti-Zero (NRZ) 포캣의 데이터는 데이터-스트로브 신호 또는 DATA-STB 포캣을 이용하여 인코드되어, 클록 정보가 데이터와 스트로브 신호에 매입되도록 한다. 클록은 복잡한 단계 로크 루프 회로 없이 회복될 수 있다. 데이터는 다른 컨덧터, 배선, 또는 전송 구성요소가 전술한 바와 같이 이용될 수 있다라도, 양방향 차동 링크 상으로 넘겨지며, 통상 와이어-라인 케이블을 이용하여 구현될 수 있다. STB 는 호스트에 의해서만 구동되는 방향성링크 상으로 넘겨진다. 스트로브 신호는 데이터 라인 및 신호 상에 동일성이 있는 백-투-백 상태 0 또는 1 이 있을 때마다 값 (0 또는 1) 을 토글한다.

비트 "1110001011" 와 같은 데이터 시퀀스의 예는 DATA-STB 인코딩을 이용하여 전송될 수 있는 방법의 예를 도 40 에 그래프 형식으로 나타낸다. 도 40 에서, DATA 신호 (4002) 를 신호 타이밍 챠트의 상부 라인 상에 나타내고, STB 신호 (4004) 를 제 2 라인 상에 나타나며, 각각의 시간은 적절하게 정렬된다 (공통 시작 점). 시간이 경과에 따라, DATA 라인 (4002) 상에서 발생하는 상태의 변경이 있고 STB 라인 (4004)(신호) 가 이전의 상태를 유지할 때, DATA 신호의 제 1 "1" 상태는 STB 신호에 대한 시작값인 제 1 "0" 상태에 부합된다. 그러나, DATA 가 다른 "1" 값을 제공하는 도 40 의 경우와 같이, DATA의 상태, 레벨이 변경되지 않는 경우 또는 그럴 때에, STB 신호는 반대 상태로 토글되거나 본 실시예에서는 "1" 로 토글된다. 즉, DATA 와 STB 사이에 비트 사이클 당 하나 및 하나의 전송만이 있다. 따라서, STB 신호 전환은 DATA 신호에 따라 "0" 에 대한 신호를 "1" 로 유지하고, 이 레벨 및 값을 DATA 신호에 따라 "0" 으로 레벨을 변경한다. DATA 신호는 "1" 로 유지할 때, STB 신호는 반대 상태로 토글하거나 현재 예에서는 "1" 로 토글하며, DATA 신호가 레벨 또는 값을 변경하거나 고정한다.

이러한 신호를 수신하면, 절대-OR (XOR)" 오퍼레이션은 DATA 및 STB 신호 상에서 수행되어, 원하는 데이터와 스트로브 신호와의 상대적인 비교를 타이밍 챠트의 하부 상에 나타낸 클록 신호 (4006) 를 생성한다. 호스트의 입력 데이터로부터 DATA 및 STB 출력 또는 신호를 생성하고 클라이언트의 DATA 및 STB 신호로부터 데이터를 회복하거나 리캡쳐링하기 위해 유용한 회로의 예를 도 41 에 나타낸다.

도 41 에서, 전송부 (4100) 는 중간 신호 경로 (4102) 상의 오리지널 DATA 와 STB 신호를 생성하고 전송하기 위해 이용되고, 리셉션부 (4120) 은 신호를 수신하고 데이터를 회복하기 위하여 이용된다. 도 41 에 나타낸 바와 같이, 데이터를 호스트에서 클라이언트로 전송하기 위하여, DATA 신호는 회로를 트리거하는 클록 신호를 따라 2 개의 D-타입 플립-플롭 회로 구성요소 (4104, 4106) 로 입력한다. 2 개의 플립-플롭 회로 출력은 MDDI_Data0+, MDDI_Data0- 및 MDDI_Stb+, MDDI_Stb- 각각의 신호의 차동 쌍으로 차동 라인 드라이버 (4108, 4110 (전압 모드)) 를 이용하여 스플리트된다. 3 입력 절대-NOR (XNOR) 게이트, 회로, 또는 로직 구성요소 (4112) 는 양 플릿-플롭의 출력 및 DATA 에 접속되어, 제 2 플립-플롭에 대하여 데이터 입력을 제공하는 출력을 생성하고, MDDI_Stb+, MDDI_Stb- 신호를 생성한다. 편의 상, XNOR 게이트는 스트로브를 생성하는 플립-플롭의 Q 출력의 효과적인 변환을 표시하기 위해 위치되는 역 버블을 갖는다.

도 41 의 레셉션부 (4120) 에서, MDDI_Data0+, MDDI_Data0- 및 MDDI_Stb+, MDDI_Stb- 신호는 차동 라인 수신기 (4122, 4124) 각각으로 수신되며, 차동 신호로부터의 단일 출력을 생성한다. 진폭기의 출력은 클록 신호를 생성하는 2 개의 입력 절대-OR (XOR) 게이트, 회로, 또는 로직 구성요소 (4126) 의 입력 각각으로 입력된다. 지연 구성요소 (4132) 를 통해 지연된 버전의 DATA 신호를 수신하고 4128 은 데이터 "0" 을 생성하고 다른 4130 은 데이터 "1" 값을 각각 생성하는 2 개의 D-타입 플립-플롭 회로 (4128, 4130) 각각을 트리거하기 위하여 클록 신호를 이용한다.클록은 XOR 로직으로부터 임피던스 출력을 갖는다. 클록 정보가 DATA 와 STB 라인 사이에 분산되기 때문에, 클록 레이트의 절반보다 빠른 상태 사이의 신호 변환이 발생되지 않는다. 클록이 DATA 및 STB 신호의 절대-OR 프로세싱을 이용하여 재생성되기 때문에, 시스템은 클록 신호가 단일 데이터 라인 상에 직접 전송될 때의 상황에 비하여 입력 데이터와 클록 사이에 총 스큐의 2 배의 오차를 효과적으로 갖는다.

MDDI Data 쌍, MDDI_Stb+ 및 MDDI_Stb 신호는 노이즈의 음의 영향으로부터의 오얌을 최대화하기 위한 차동 모드에서 동작한다. 차동 신호 경로의 각각의 부분은 신호를 전송하기 위해 이용되는 케이블 또는 컨덕터의 특성 임피던스의 1/2 로 오소스 터미네이트된다. MDDI 데이터쌍은 호스트와 클라이언트 종결시에 소오스 터미네이트된다. 이러한 2 드라이버 중 오직 하나만이 주어진 시간에 활성화되기 때문에, 전송 링크에 대한 소오스의 터미네이션이 항상 있다. MDDL_Stb+ 및 MDDI_Stb- 신호는 호스트에 의해서만 구동된다.

예시적인 구성요소의 구성은 도 42 에 나타낸 발명인 MDD 인터페이스의 파트에 따라 신호를 전송하기 위한 드라이버, 수신기 및 터미네이션에 대해 유용하며, 대응하는 MDDI_Data 및 MDDI_Stb 의 DC 전기 설계도를 표 7 에 나타낸다. 예시적인 인터페이스는 여기서는 1 V 보다 적은 전력 스윙 및 저 전력 드레인을 갖는 200 mV 의 저전압 센싱을 이용한다.

[표 Ⅶ]

차동 라인 드라이버 및 라인 수신기의 전기적 파라미터 및 특성를 표 Ⅷ 에 나타낸다. 기능적으로, 드라이버는 입력 상의 로직 레벨을 직접 양의 출력으로 전송하며, 입력의 역을 음의 출력으로 전송한다. 입력으로부터 출력으로의 지연은 상이하게 구동되는 차동 라인으로 잘 매치된다. 대부분의 구현에서는, 출력 상의 전압 스윙은 입력 상의 스윙보다 작게되어, 전력 소모 및 전자기 방출을 최소화한다. 표 Ⅷ 은 최소 전압 스윙을 약 0.5 V 로 나타낸다. 그러나, 당업자는 다른 값을 이용할 수 있으며, 발명자는 설계 규칙에 따라 몇몇 실시예에서 더 작은 값을 예상할 수 있다.

차동 라인 수신기는 고속 전압 비교기와 동일한 특성을 갖는다. 도 41 에서, 버블없는 입력은 버블이 양의 입력인 입력이고 버블갖는 입력은 음의 입력이다. 출력은 (Vinput+)-(Vinput+) 가 0 보다 큰 경우의 로직이다. 이를 설명하는 다른 방식은 로직 0 및 1 전압 레벨로 기울어지는 출력에 의해 매우 큰 (가상적으로 무한한) 게인을 갖는 차동 진폭기이다.

상이한 쌍 사이의 지연 스큐는 최고 포텐셜 속도에서의 차동 전송 시스템을 동작하기 위해 최소화되어야 한다.

도 42 에서, 호스트 제어기 (4202) 및 클라이언트 또는 디스플레이 제어기 (4204) 는 통신 링크 (4206) 상에 패킷을 전송하는 것을 나타낸다. 호스트 제어기는 일련의 3 개의 드라이버 (4210, 4212, 4214) 를 채용하여, 전송되는 클라이언트 데이터 신호를 수신하는 것과 같이, 전송되는 호스트 DATA 및 STB 신호를 수신한다. 호스트 DATA 통과에 대하여 응답가능한 드라이버는 인에이블 신호 입력을 채용하여, 호스트에서 클라이언트로의 전송을 소망할 때에만 통신 링크의 활성화가 가능하도록 한다. STB 신호가 데이터 전송 파트로서 형성되기 때문에, 추가의 인에이블 신호는 드라이버 (4212) 에 대하여 채용되지 않는다. DATA 및 STB 드라이버 각각의 출력은 터미네이션 임피던스 또는 레지스터 (4216a, 4216b, 4216c, 4216d) 각각에 접속된다.

터미네이션 레지스터 (4216a, 5216b) 는 또한 STB 신호 프로세싱에 대한 클라이언트측 수신기 (4220) 의 입력 상의 임피던스로서 작용하고, 추가적인 테미네이션 레지스터 (4216e 및 4216f) 은 레지스터 (4216c 및 4226) 와 직렬로 위치된다. 클라이언트 제어기의 6번째 드라이버 (4226) 는 클라이언트에서 호스트로 전송되는 데이터 신호를 준비하기 위하여 이용되며, 입력측 상의 테미네이션 레지스터 (4216c, 4216d) 를 통한 드라이버 (4214) 는 프로세싱을 위한 호스트로의 전송을위한 데이터를 프로세스한다.

2 개의 추가적인 레지스터 (4218a, 4218b) 는 터미네이셤 레지스터와 전원 (4220) 사이에 각각 전술한 휴면 제어의 파트로서 위치된다. 전원은 데이터의 플로우를 관리하기 위하여 이전에 언급한 높거나 낮은 레벨로의 전송 라인을 구동하기 위하여 이용된다.

전술한 드라이버 및 임피던스는, 보다 비용 효과적인 인코더 또는 디코더 설루션으로서 작용하는 불연속의 구성요소로서 형성되거나 ASIC 의 파트로서 형성될 수 있다.

한쌍의 컨덕터 상의 MDDI_Pwr 및 MDDL_Gnd 로 표시되는 신호를 이용하여 클라이언트 디바이스로 전력이 전송되거나 호스트 디바이스로부터 표시되는 것을 용이하게 볼 수 있다. 신호의 MDDI_Gnd 부는 레퍼런스 그라운드로서 작용하며, 전력 공급은 디스플레이 디바이스에 대한 경로 또는 신호를 리턴한다. MDDI_Pwr 신호는 호스트 디바이스로 구동되는 디스플레이 디바이스 전력 공급으로 작용한다. 예시적인 구성에서, 낮은 전력 애플리케이션에 대하여, 디스플레이 디바이스는 500 mA 까지 드로우업된다. MDDI_Pwr 신호는 휴대형 전원으로부터 제공될 수 있지만 이로 한정되는 것은 아니며, 호스트 디바이스에 위치되는 리튬-이온 타입 배터리 또는 배터리 팩도 가능하며, MDDI_Gnd 에 대하여 3.2 내지 4.3 볼트의 범위일 수 있다.

VII. 타이밍 특성

A. 개요

호스트로부터의 서비스를 보장하기 위한 클라이언트에 의해, 그리고, 이러한서비스를 제공하기 위하여 호스트에 의하여, 채용되는 단계 및 신호 레벨를 도 43 에 나타낸다. 도 43 에서, 표시되는 신호의 제 1 파트는 호스트로부터 전송되는 링크 셧다운 패킷을 나타내며, 데이터 라인은 고-임피던스 바이어스 회로를 이용하여 로직 제로 상태로 구동된다. 데이터는 디스에이블되는 드라이버를 갖는 클라이언트 디스플레이 또는 호스트에 의하여 전송되지 않는다. MDDL_Stb 가 링크 셧다운 패킷 동안 활성화되기 때문에, MDDI-Stb 신호 라인에 대한 일련의 스트로브 펄스를 하부에서 볼 수 있다. 패킷은 종료되고 호스트가 바이어스 회로 및 로직을 제로로 구동함에 따라 로직 레벨이 제로로 변화되면, MDDL_Stb 신호 라인은 또한 제로로 변경된다. 이는 호스트로부터의 최종 신호 전송 또는 서비스의 종결을 나타내고, 과거 어느 때에 발생되며, 서비스의 우선 시작 및 서비스 커멘스먼트를 제공하기 이전의 신호의 상태를 나타내는 것을 포함한다. 원한다면, 이러한 신호는 호스트 디바이스로 알려진 "공지된" 이전의 통신없이 적절한 상태로의 통신 링크를 리셋하기 위하여 전송될 수 있다.

도 43 에 나타낸 바와 같이, 클라이언트로부터의 신호 출력은 초기에 제로의 로직 레벨로 설정된다. 즉, 클라이언트 출력은 고 임피던스에 있으며, 드라이버는 디스에이블된다. 서비스가 요구될 때, 클라이언트는 그 드라이버를 인에이블하고, 라인이 로직 레벨로 구동되는 동안의 설정되는 시간의 주기, 즉, t_service인 호스트로 서비스 요구를 전송한다. 시간의 특정량은 호스트가 신호를 로직 레벨에서 구동함으로써 링크 스타트업 시퀀스에 의하여 응답하는 후에 t_host-detect로 나타내는 호스트가 요구를 검출하기 이전에 통과하거나 필요하게 될 수 있다. 이 점에서, 클라이언트는 요구를 디어서트하고, 서비스 요구 드라이버를 디스에이블하여 클라이언트로부터의 출력 라인을 제로 로직 레벨로 다시 진행한다. 이 시간 동안, MDDI-Stb 신호는 로직 제로 레벨에 있다.

호스트는, 호스트가 로직 레벨을 제로로 구동한 후 t_restart-high로 나타내는 기간 동안 "1" 레벨에서 호스트 데이터 출력을 구동하고, 제 1 전방 트래픽이 프레임 헤더 패킷으로 시작한 이후의 t_restart-low로 나타내는 기간 동안 전송된다. MDDI_Stb 신호는 t_restart-low기간 및 연속의 프레임 헤더 패킷 동안 활성화된다.

표 Ⅷ 은 전술한 다양한 기간의 길이에 대하여 대표적인 시간 및 최소 및 최대 데이터 레이트를 나타내는 관계를 각각 나타낸다.

[표 Ⅷ]

당업자는 도 41 및 도 42 에 나타낸 개별 구성요소의 기능을 잘 알고 있으므로 쉽게 이해할 것이며, 도 42 의 구성요소의 함수는 도 43 의 타이밍도로 확인된다. Sata-Strobe 인코딩을 수행하는 방법 및 이로부터 클록을 회복하는 방법에 대한 설명에 대한 정보가 불필요하므로 도 42 에 나타낸 시리즈 터미네이션 및 휴면 레지스터에 대한 상세한 설명은 도 41 에서는 생략한다.

B. 데이터-스트로브 타이빙 전방 링크

호스트 드라이버 출력로부터의 전방 링크 상의 데이터의 전송을 위한 스위칭 특성을 표 Ⅸ 에 나타낸다. 표 Ⅸ는 발생하는 특정 신호 변화에 대한 통상의 시간에 대한 최소 및 최대의 터뷸러 형상을 나타낸다. 예를 들어, 데이터 값의 시작으로부터 종료 시에 발생하는 변환, Data0 에서 Data0 변환, t_{tdd-(host-output)}동안 통상의 시간 길이는 t_tbit이며, 최소 시간은 약 t_tbir-0.5nsec 이고, 최대는 약 t_tbit+0.5 nsec 이다. Data0 상의 변환, 다른 데이터 라인 (DataX), 및 스트로브 라인 (Stb) 사이의 상대적인 간격을 Data0 과 Strobe, Strobe 와 Strobe, Strobe 와 Data0, Data0 과 논-Data0, 논-Data0 과 논-Data0, 논-Data0 과 Strobe, 및 Strobe 와 논-Data0 사이의 변환을 나타내며, 이들을 각각 t_{tds-(host-output),}t_{tss-(host-output),}t_{tsd-(host-output),}t_{tddx-(host-output),}t_{tdxdx-(host-output),}t_{tdxs-(host-output), 및}t_{tsdx-(host-output)}로서 도 44 에 나타낸다.

[표 Ⅸ]

전방 링크 상의 데이터를 전송하는 동일한 신호에 대한 클라이언트 수신기 입력에 대한 통상의 MDDI 타이밍 요건을 표 Ⅹ에 나타낸다. 동일한 신호를 설명하였지만 시간 지연되므로, 당업자가 이해할 수 있는 신호 특성 또는 각각의 라벨에 대한 의미를 설명하기 위해 새로운 수치가 필요하지 않다.

[표 Ⅹ]

도 45 및 도 46 은 호스트가 호스트 드라이버를 디스에이블 또는 에이블할 때 발생할 수 있는 것에 대응하여 지연의 출현을 설명한다. 역 링크 캡슐화 패킷 또는 라운드 트립 지연 측정 패킷과 같은 특정 패킷으로 진행하는 호스트의 경우, 호스트는, 전송되어지는 도 45 에 나타낸 파라미터 CRC, 스트로브 정렬, 및 모든제로 패킷과 같은 소망의 패킷이 진행한 후 라인 드라이버를 디스에이블한다. 그러나, 도 45 에 나타낸 바와 같이, 특정 제어로 포텐셜하게 달성할 수 있거나 회로 구성요소가 존재하더라도 라인의 상태는 "0" 에서 소망의 높은 값으로 스위치될 필요가 없고, 시간의 기간은 응답에 대하여 호스트 드라이버 디스에이블 지연 기간의 기간을 갖는다. 시간 기간이 0 나노초 길이와 같이 가상적으로 순식간에 발생할 수 있고, Guard Time 1 또는 Turn Around 1 패킷 시간 동안 발생하는 소망의 최대 기간 길이가 되는 10 나노초를 갖는 몇몇의 더욱 긴 기간에 걸쳐 보다 쉽게 연장될 수 있다.

도 46 을 살펴보면, 신호 레벨 변화는 역 링크 캡슐화 패킷 또는 라운드 트립 지연 측정 패킷과 같은 호스트 드라이버가 패킷을 전송하기 위해 인에이블될 때 진행되는 것을 알 수 있다. 따라서, Guard Time 2 또는 Turn Around 패킷 시간 이후에, 호스트 드라이버는 인에이블되고 여기서는 0 의 레벨을 구동하기 시작하며, 그 값은 제 1 패킷이 전송되기 이전에 드라이버 리-인에이블 기간 동안 발생하는 호스트 드라이버 인에이블 지연 기간이라 하는 시간의 기간 상에 걸쳐 접근 또는 도달된다.

유시한 프로세스가 드라이버에 대해 발생되고 신호가 여기서는 디스플레이인 클라이언트 디바이스에 전송된다. 이러한 주기에 대한 일반적인 가이드라인 및 각각의 관계를 아래의 표 ⅩI 에 나타낸다.

[표 ⅩI]

C. 데이터-스트로브 타이밍 역방향 링크

클라이언트 드라이버 출력으로부터 역방향 링크상에서 데이터를 전송하기 위해 사용된 데이터 및 스트로브에 대한 스위칭 특성과 타이밍 관계가 도 47 및 48에 도시되어 있다. 이하, 어떤 신호 변화에 대한 통상의 타임을 설명한다. 도 47은 전송되는 데이터의 타이밍과 스트로브 펄스의 선두 및 후미 에지 사이의 호스트 수신기 입력에서의 관계를 나타낸다. 즉, 스트로브 신호 (t_su-sr) 의 상승 또는 선두 에지에 대한 설정 시간과 스트로브 신호 (t_su-sf) 의 후미 또는 하강 에지에 대한 설정 시간으로서 참조한다. 이들 설정에 대한 통상의 시간 길이는 최소 8 나노초이다.

도 48은 역방향 데이터 타이밍에 의해 향상된 스위칭 특성 및 대응하는 클라이언트 출력 지연을 나타낸다. 도 48에서, 전송되는 데이터의 타이밍과 유도된 지연을 어카운팅하는 스트로브 펄스의 선두 및 후미 에지 사이의 관계를 알 수 있다. 즉, 스트로브 신호의 상승 또는 선두 에지와 데이터 (유효) 사이의 전파 지연 (t_pd-sr), 및 데이터와 스트로브 신호의 후미 또는 하강 에지 사이의 전파 지연 (t_pd-sf) 로서 참조한다. 이들 전파 지연에 대한 통상의 시간 길이는 최소 8 나노초이다.

Ⅷ. 링크 제어의 구현 (링크 제어기 동작)

A. 상태 기계 패킷 프로세서

소망하는 바와 같이, 더 낮은 레이트가 고려되더라도, MDDI 링크를 통해 전송되는 패킷은 매우 빠르게, 통상적으로 300 Mbps 이상의 레이트로 디스패치된다. 이러한 타입의 버스 또는 전송 링크 속도는 제어를 위해 현재 상업적으로 사용 가능한 (경제적) 범용 마이크로프로세서등에 대해 너무 크다. 따라서, 이러한 타입의 신호 전송을 달성하기 위한 실제 구현은 입력 패킷 스트림을 분석하기 위해 프로그램 가능한 상태 기계를 활용하여, 의도하는 적합한 오디오-시각 서브시스템으로 전송 또는 리다이렉트되는 패킷을 생성한다.

범용 제어기, 프로세서, 또는 처리 엘리먼트는 더 낮은 속도 요구를 갖는 제어 또는 상태 패킷과 같은 어떠한 정보에 더욱 적합하게 작용 또는 조정하도록 사용될 수 있다. 이들 패킷 (제어, 상태 또는 다른 사전-정의된 패킷) 이 수신될 때, 상태 기계는 데이터 버퍼 또는 유사한 처리 엘리먼트를 통해 이들을 범용 프로세서로 통과시켜서, 패킷은 오디오 및 시각 패킷이 작용을 위해 적합한 수신지로 전송되는 동안 소망하는 결과 (효과) 를 제공하도록 작용할 수 있다.

범용 프로세서 기능은, 어떠한 모뎀 또는 그래픽 프로세서가 어떠한 기능을 수행하고 하드웨어 복잡도 및 비용을 감소시키기 위해 컴퓨터에서 CPU의 처리 전력을 활용하는 것과 유사한 방식으로, 무선 디바이스에서 발견되는 컴퓨터 애플리케이션의 마이크로프로세서 (CPU), 또는 프로세서, 디지털 신호 프로세서 (DSP), 또는 ASIC에 대해 사용 가능한 처리 전력, 또는 초과 사이클을 사용함으로써 어떠한실시형태에서 실현될 수 있다. 그러나, 이것은 처리 속도, 타이밍, 또는 엘리먼트의 전체 동작에 부정적인 영향을 미칠수 있어서, 많은 애플리케이션에서, 전용 회로 또는 엘리먼트가 이러한 처리를 위해 바람직하다.

이미지 데이터를 디스플레이 (마이크로-디스플레이) 상에 나타내거나, 호스트에 의해 전송된 모든 패킷을 확실하게 수신하기 위해, 디스플레이 신호 처리는 순방향 링크 채널 타이밍과 동기되어야 한다. 즉, 디스플레이 및 디스플레이 회로에 도달하는 신호는 적절한 신호 처리가 발생하도록 시간 동기화되어야 한다. 이러한 동기화가 구현될 수 있는 신호 처리 단계 또는 방법에 의해 달성되는 상태의 하이 레벨 다이어그램이 도 49의 설명에 제공된다. 도 49에서, 상태 기계 (4900) 에 대한 가능한 순방향 링크 동기화 "상태"가 하나의 비동기 프레임 상태 (4904), 2개의 획득 동기 상태 (4902 및 4906), 및 3개의 동기 상태 (4908, 4910, 및 4912) 로서 카테고리화되어 도시되어 있다.

시작 단계 또는 상태 4902에 의해 도시된 바와 같이, 디스플레이는 사전-선택된 "부-동기화 (no-sync)" 상태에서 시작하고, 검출되는 제 1 서브-프레임 헤더 패킷에서 유일 (unique) 워드를 탐색한다. 이러한 부-동기화 상태는 타입 Ⅰ 인터페이스가 선택되는 최소 통신 설정 또는 "고장시 조치 (fall-back)" 설정을 나타낸다. 유일 워드가 탐색 동안 발견될 때, 디스플레이는 서브-프레임 길이 필드를 세이브한다. 동기화가 얻어질 때 까지, 제 1 프레임에 대한 처리를 위한 CRC 비트 체크는 없다. 이러한 서브-프레임 길이가 0인 경우에, 동기화 상태 처리는 본 명세서에서 상기 동기화가 아직 달성되지 않았음을 표시하는 "비동기 프레임" 상태로 라벨되는 상태 (4904) 로 방법에 따라 계속된다. 처리중에 이 단계는 도 49에서 인카운트된 cond3, 또는 condition 3으로서 라벨되어 있다. 그렇지 않으면, 프레임 길이가 0 보다 큰 경우에, 동기 상태 처리는 인터페이스 상태가 "하나의 동기 프레임 발견"으로 설정된 상태 4906으로 계속된다. 처리중에 이 단계는 도 49에서 인카운팅 cond5, 또는 condition 5로 라벨되어 있다. 또한, 상태 기계가 0 보다 더 큰 프레임 길이에 대한 프레임 헤더 패킷 및 양호한 CRC 결정을 발견한 경우에, 처리는 "하나의 동기 프레임 발견" 상태로 계속된다. 이것은 도 49에서 미팅 cond6, 또는 condition6으로 라벨되어 있다.

시스템이 "부 동기화" 이외의 상태에 있는 각 상황에서, 유일 워드가 검출되고 양호한 CRC 결과가 서브-프레임 헤더 패킷에 대해 결정되고, 서브-프레임 길이가 0 보다 더 클 때, 인터페이스 상태는 "동기 (in-sync)" 상태로 변화된다. 처리중에 이 단계는 도 49에서 인카운트된 cond1, 또는 condition1으로 라벨되어 있다. 한편, 서브-프레임 헤더 패킷에서 유일 워드 또는 CRC가 올바르지 않는 경우에, 동기 상태 처리는 "부 동기화 프레임" 상태의 인터페이스 상태 (4902) 로 계속되거나 복귀한다. 처리의 이 부분은 도 49에서 인카운팅 cond2, 또는 condition2로 라벨되어 있다.

B. 동기 (Sync) 에 대한 획득 시간

인터페이스는, 동기화 분실을 결정하고 "부 동기화 프레임" 상태로의 복귀 이전에 특정 수의 "동기화 에러"를 수용하도록 구성될 수 있다. 도 40에서, 상태 기계가 "동기화 상태"에 도달하고 에러가 발견되지 않으면, cond1 결과를 지속적으로 인카운팅하고 "동기화" 상태를 유지한다. 그러나, 하나의 cond2 결과가 검출되면, 처리는 상태를 "1-동기화-에러" 상태 (4910) 로 변화시킨다. 이 때, 처리가 또 다른 con1 결과 검출을 발생하면, 상태 기계는 "동기화" 상태로 복귀하고, 그렇지 않으면, 또 다른 cond2 결과를 인카운트하고, "2-동기화-에러" 상태 (4912) 로 이동한다. 다시, cond1이 발생하면, 처리는 상태 기계를 "동기화" 상태로 복귀시킨다. 그렇지 않으면, 또 다른 cond2가 인카운트되고 상태 기계는 "부 동기화" 상태로 복귀한다. 또한, "링크 폐쇄 패킷"을 인카운팅하는 것은 동기화가 없을 때 링크가 데이터 전송을 중단하게 하고 "부-동기화 프레임"으로 복귀하게 하고, 이것은 도 49의 상태 다이어그램에서, 미팅 cond4, 또는 condition4로 참조된다.

서브-프레임 내의 어떠한 고정된 위치에서 나타날 수도 있는 유일 워드의 "잘못된 카피"를 반복할 가능성이 있다. 상기 상황에서, MDD 인터페이스 처리가 "동기화" 상태로 계속되도록 처리될 때 서브-프레임 헤더 패킷에 대한 CRC가 유효해야 하기 때문에 상태 기계가 서브-프레임에 동기화하는 것은 매우 가망이 없다.

서브-프레임 헤더 패킷의 서브-프레임 길이는 링크가 폐쇄되고, MDD 인터페이스가 유휴 휴면 상태에 위치하거나 유휴 휴면 상태로 구성되기 이전에 호스트가 하나의 서브-프레임만을 송신한다는 것을 나타내기 위해 0으로 설정될 수도 있다. 이러한 경우에, 단일 서브-프레임만이 유휴 상태로 링크 변화 이전에 전송되기 때문에, 서브-프레임 헤더 패킷을 검출한 이후에 디스플레이는 순방향 링크를 통해 패킷을 즉시 수신해야 한다. 정상 또는 통상의 동작에서, 서브-프레임 길이는 0이 아니고 디스플레이는 인터페이스가 도 49에 "IN-SYNC" 상태로서 통합적으로 도시된상태에 있는 동안 순방향 링크 패킷만을 처리한다.

순방향 링크 신호에 동기화하기 위해 디스플레이에 필요한 시간은 서브-프레임 사이즈 및 순방향 링크 데이터 레이트에 따라 가변이다. 순방향 링크에서 랜덤의 일부분, 또는 더 많은 랜덤, 데이터로서 유일 워드의 "잘못된 카피"를 검출할 가능성은 서브-프레임 사이즈가 더 클 때 더 크다. 동시에, 순방향 링크 데이터 레이트가 느릴 때, 잘못된 검출로부터 복구할 능력은 낮고, 복구하기 위해 걸리는 시간은 길다.

C. 초기화

전술한 바와 같이, "시작"의 시간에서, 호스트는 최소로 요구되거나, 소망하는 1 Mbps의 데이터 레이트 이하에서 동작하도록 순방향 링크를 구성하고, 소정의 애플리케이션에 대해 적합한 서브-프레임 길이 및 매체-프레임 레이트를 구성한다. 즉, 순방향 및 역방향 링크 모두는 타입-Ⅰ 인터페이스를 사용하여 동작을 시작한다. 일반적으로, 이들 파라미터는 호스트가 클라이언트 디스플레이 (또는 다른 디바이스) 에 대한 능력 또는 소망하는 구성을 결정하는 동안 일시적으로 사용된다. 호스트는 디스플레이가 디스플레이 능력 패킷과 응답한다는 것을 요청하기 위해, 1이 값으로 설정된 요청 플래그의 비트 '0'을 갖는 역방향 링크 캡슐화 패킷에 의해 추종되는 순방향 링크를 통해 서브-프레임 헤더 패킷을 전송한다. 디스플레이가 순방향 링크상에서 (또는 순방향 링크를 사용하여) 동기화를 획득하면, 역방향 링크 또는 채널을 통해 디스플레이 능력 패킷 및 디스플레이 요청 및 상태 패킷을 전송한다.

호스트는 최적의 링크 또는 소망하는 성능 레벨을 어떻게 재구성하는지를 결정하기 위해 디스플레이 능력 패킷의 컨텐츠를 검사한다. 호스트는 호스트 및 디스플레이가 서로 호환 가능한 프로토콜의 버전을 사용하는지를 확인하기 위해 프로토콜 버전 및 최소 프로토콜 버전 필드를 검사한다. 프로토콜 버전은, 프로토콜의 다른 엘리먼트가 호환 가능하지 않거나 호환 가능한 것으로서 완벽하게 이해되더라도, 호환성이 결정될 수 있도록, 디스플레이 능력 패킷의 제 1의 2개의 파라미터를 유지한다.

D. CRC 처리

모든 패킷 타입에 있어서, 패킷 프로세서 상태 기계는, CRC 검사기가 적절하게 제어된다는 것을 보장한다. 또한, 이것은 CRC 비교가 하나 이상의 에러 검출을 발생할 때 CRC 에러 카운터를 증가시키고, 처리되는 각 서브-프레임의 시작에서 CRC 카운터를 리셋시킨다.

Ⅸ. 패킷 처리

상태 기계가 수신하는 전술한 각 타입의 패킷에 있어서, 인터페이스의 동작을 구현하기 위해 특정한 처리 단계 또는 일련의 단계를 시작한다. 일반적으로, 순방향 링크는 아래의 테이블 ⅩⅡ에 리스트된 예시적인 처리에 따라 처리된다.

[표 ⅩⅡ]

Ⅹ. 역방향 링크 데이터 레이트 감소

호스트 링크 제어기에 사용된 어떤 파라미터가 매우 바람직한, 최대 또는 더욱 최적화된 (스케일) 역방향 링크 데이터 레이트를 달성하기 위해 어떤 방식으로 조절 또는 구성될 수 있다는 것이 발명자에 의해 관찰되었다. 예를 들어, 역방향 링크 캡슐화 패킷의 역방향 데이터 패킷 필드를 전송하기 위해 사용된 시간 동안, MDDI_Stb 신호 쌍은 1/2의 순방향 링크 데이터 레이트에서 주기적 데이터 클럭을 생성하기 위해 토글한다. 이것은, 호스트 링크 제어기가 모든 0를 전송하더라도 MDDI_Data0 신호에 대응하는 MDDI_Stb 신호를 발생시키기 때문에 발생한다. MDDI_Stb 신호는 호스트로부터 디스플레이로 전송되고, 여기서, 역방향 데이터가 호스트로 역으로 전송되는 디스플레이로부터 역방향 링크 데이터를 전송하기 위한 클럭 신호를 발생시키기 위해 사용된다. MDDI를 사용하는 시스템의 순방향 및 역방향 경로상의 신호 전송 및 처리에 대해 인카운트된 통상의 지연량의 설명이 도 50에 나타나 있다. 도 50에서, 일련의 지연값 (1.5 nsec., 8.0 nsec., 2.5 nsec., 2.0 nsec., 1.0 nsec., 1.5 nsec., 8.0 nsec., 및 2.5 nsec.) 이 Stb+/- 생성, 케이블 전송-디스플레이, 디스플레이 수신기, 클럭 생성, 신호 클럭킹, Data0+/- 생성, 케이블 전송-호스트, 및 호스트 수신기 스테이지용 처리부 근처에 각각 도시되어 있다.

순방향 링크 데이터 레이트 및 인카운트된 신호 처리 지연에 따르면, 이것은 완료될 이벤트의 세트 또는 이러한 "라운드 트립" 효과에 대한 MDDI_Stb 신호상의 1 사이클 보다 더 많은 시간을 요청할 수도 있고, 이것은 시간 또는 사이클의 바람직하지 못한 소모를 발생시킨다. 이러한 문제점을 피하기 위해, 역방향 레이트 디바이저 (Divisor) 는 역방향 링크에 대한 1 비트 시간이 MDDI_Stb 신호의 다중 사이클을 스팬하는 것을 가능하게 한다. 이것은, 역방향 링크 데이터 레이트가 순방향 링크 레이트 보다 작다는 것을 의미한다.

인터페이스를 통하는 신호 지연의 실제 길이는 사용되는 각각의 특정 호스트-클라이언트 시스템 또는 하드웨어에 따라 다를 수도 있다. 일반적으로, 각 시스템은 역방향 레이트 디바이저가 최적값으로 설정될 수 있도록, 시스템에서 실제 지연을 측정하기 위해 라운드 트립 지연 측정 패킷을 사용함으로써 더 양호하게 수행되도록 구성된다.

라운드-트립 지연은 호스트가 디스플레이로 라운드 트립 지연 측정 패킷을 전송함으로써 측정된다. 디스플레이는 패킷이 측정 기간 필드라 불리는 사전-선택된 측정 윈도우 동안 또는 그것의 호스트 내부로 1의 시퀀스를 역으로 전송함으로써 이 패킷에 응답한다. 이러한 측정의 상세한 타이밍은 전술하였다. 라운드-트립 지연은 역방향 링크 데이터가 안전하게 샘플될 수 있는 레이트를 결정하기 위해 사용된다.

라운드-트립 지연 측정은, 0xff, 0xff, 0x00 응답 시퀀스가 디스플레이로부터 호스트에 수신될 때 측정 기간 필드의 시작과 타임 기간의 시작 사이에서 발생하는 순방향 링크 데이터 클럭 간격의 수를 결정, 검출, 또는 카운트하는 것으로 이루어진다. 디스플레이로부터의 응답이 측정 카운트가 증가하기 이전에 순방향 링크 클럭 기간의 작은 부분에서 수신될 수 있다. 이러한 변형되지 않은 값이 역방향 레이트 디바이저를 계산하기 위해 사용되는 경우에, 신뢰할 수 없는 샘플링으로 인한 역방향 링크상에서 비트 에러를 초래할 수 있다. 이러한 상황의 예가 도 51에 도시되어 있고, 여기서, 호스트에서의 MDDI_Data, 호스트에서의 MDDI_Stb, 호스트 내부의 순방향 링크 데이터 클럭, 및 지연 카운트를 나타내는 신호가 그래픽 형태로 도시되어 있다. 도 51에서, 응답 시퀀스는, 지연 카운트가 6으로부터 7로 증가하기 이전에 순방향 링크 클럭 기간의 일부분으로부터 수신된다. 지연이 6으로 가정되는 경우에, 호스트는 비트 변화 이후 또는 비트 변화중에 역방향 데이터를 항상 샘플한다. 이것은 호스트에서 잘못된 샘플링을 발생시킬 수 있다. 이러한 이유로, 통상적으로, 측정된 지연은 역방향 레이트 디바이저를 계산하기 위해 사용되기 이전에 1만큼씩 증가되어야 한다.

역방향 레이트 디바이저는 역방향 링크 데이터를 샘플링하기 이전에 호스트가 대기해야 하는 MDDI_Stb 사이클의 수이다. MDDI_Stb이 순방향 링크 레이트의 1/2인 레이트로 사이클되기 때문에, 정정된 라운드-트립 측정은 2로 제산될 필요가있고 다음 정수까지 라운드된다. 공식으로서 표현하면, 이 관계식은,

이다.

제공되는 예에 있어서, 이것은,

가 된다.

이 예에서 사용된 라운드 트립 지연 측정이 6이 아닌 7인 경우에, 역방향 레이트 디바이저 또한 4와 동일하다.

역방향 링크 데이터는 역방향 링크 클럭의 상승 에지상에서 호스트에 의해 샘플된다. 역방향 링크 클럭을 생성하기 위해 호스트 및 클라이언트 (디스플레이) 모두에 제공되는 카운터 또는 유사한 알려진 회로 또는 디바이스가 있다. 카운터는, 역방향 링크 클럭의 제 1 상승 에지가 역방향 링크 캡슐화 패킷의 역방향 링크 패킷 필드의 제 1 비트의 시작에서 발생하도록 초기화된다. 이것은, 아래에 제공된 예에 대해 도 52에 나타낸다. 카운터는 MDDI_Stb 신호의 각 상승 에지에서 증가하고, 랩 어라운 전 까지 발생한 카운팅의 수는 역방향 링크 캡슐화 패킷의 역방향 레이트 디바이저 파라미터에 의해 설정된다. MDDI_Stb 신호가 1/2 순방향 링크 레이트에서 토글하기 때문에, 역방향 링크 레이트는 역방향 레이트 디바이저에 의해 제산 순방향 링크 레이트의 1/2이다. 예를 들어, 순방향 링크 레이트가 200Mbps이고 역방향 레이트 디바이저가 4인 경우에, 역방향 링크 데이터 레이트는,

와 같이 표현된다.

역방향 링크 캡슐화 패킷의 MDDI_Data0 및 MDDI_Stb 신호 라인의 타이밍을 나타내는 예가 도 52에 도시되어 있고, 여기서, 설명을 위해 사용되는 패킷 파라미터는 값 :

패킷 길이 = 1024(0x0400) 턴 어라운드 1 길이 = 1

패킷 타입 = 65(0x41) 턴 어라운드 2 길이 = 1

역방향 링크 플래그 = 0 역방향 레이트 디바이저 = 2

파라미터 CRC = 0xdb43 모든 0은 0x00 이고,

패킷 길이와 파라미터 CRC 필드 사이의 패킷 데이터는 :

0x00, 0x04, 0x41, 0x00, 0x02, 0x01, 0x01, 0x43, 0xdb, 0x00, ...이다.

디스플레이로부터 복귀된 제 1 역방향 링크 패킷은 7의 패킷 길이 및 70의 패킷 타입을 갖는 디스플레이 요청 및 상태 패킷이다. 이 패킷은 바이트 값 0x07, 0x00, 0x46, ... 등과 시작한다. 그러나, 제 1 바이트 (0x07) 만이 도 52에서 볼 수 있다. 이러한 제 1 역방향 링크 패킷은 실제 역방향 링크 지연을 나타내기 위해 도면의 하나의 역방향 링크 클럭 기간에 의해 타임-시프트된다. 라운드-트립 지연을 디스플레이하기 위해 0 호스트를 갖는 이상적인 파형은 도트-라인 트레이스로 도시되어 있다.

패킷 타입에 의해 선행되는 파라미터 CRC 필드의 MS 바이트가 전송되고, 따라서 모든 0 필드이다. 호스트로부터의 스트로브는 1로부터 0으로 스위칭되고, 호스트로부터의 데이터가 더 넓은 펄스를 형성하는 레벨을 변화시킬 때 다시 1로 스위칭한다. 데이터가 0로 갈 때, 스트로브는 더 높은 레이트에서 스위치하고, 데이터 라인상의 데이터에서의 변화만이 정렬 필드의 종단 가까이에서 변화를 초래한다. 스트로브는 확장된 기간동안 데이터 신호의 고정된 0 또는 1 레벨로 인해 도면의 나머지에 대하여 더 높은 레이트로 스위치하고, 변화는 펄스 패턴 (에지) 로 떨어진다.

호스트에 대한 역방향 링크 클럭은, 클럭이 역방향 링크 패킷을 수용하기 위해 시작될 때, 턴 어라운드 1 기간의 종단 전 까지 0이다. 도면의 하위 부분에서의 화살표는 개시물의 나머지로부터 명백한 바와 같이, 데이터가 샘플될 때를 표시한다. 전송되는 패킷 필드의 제 1 바이트 (여기서는 11000000) 는 턴 어라운드 1 이후에 개시하는 것으로 도시되어 있고, 라인 레벨은 디스에이블되는 호스트 드라이버로부터 안정화된다. 제 1 비트의 패시지에서의 지연은, 비트 3에 대해 알 수 있는 바와 같이, 데이터 신호에 대한 도트된 라인에서 볼 수 있다.

도 53에서, 순방향 링크 데이터 레이트에 기초하여 역방향 레이트 디바이저의 통상을 값을 관찰할 수 있다. 실제 역방향 레이트 디바이저는 적절한 역방향 링크 동작을 보장하기 위한 라운드-트립 링크 측정의 결과로서 결정된다. 제 1 영역 (5302) 은 안전 동작의 영역에 대응하고, 제 2 영역 (5304) 은 마진 성능의 영역에 대응하고, 제 3 영역 (5306) 은 적절하게 기능할 것 같지 않는 설정을 표시한다.

라운드-트립 지연 측정 및 역방향 레이트 디바이저 설정은, 송신되거나 수신된 비트의 수 보다는 실제 클럭 기간의 단위에 기초를 두고 표현 및 동작되기 때문에, 순방향 또는 역방향 링크상에서 임의의 인터페이스 타입 설정과 동작하는 동안 동일하다.

ⅩⅠ. 턴-어라운드 및 가드 시간

전술한 바와 같이, 역방향 링크 캡슐화 패킷에서의 턴 어라운드 1 필드와 라운드 트립 지연 측정 패킷에서의 가드 시간 1 필드는 디스플레이 인터페이스 드라이버가 인에이블되기 이전에 호스트 드라이버가 디스에이블되게 하는 시간의 길이에 대한 값을 나타낸다. 턴 어라운드 2 및 가드 시간 2 필드는 호스트 드라이버가 인에이블되기 이전에 디스플레이 드라이버가 디스에이블되게 하는 시간 값을 제공한다. 일반적으로, 가드 시간 1 및 가드 시간 2 필드는 조절되는 것으로 의미되지 않는 길이에 대한 사전-설정 또는 사전-선택된 값으로 채워진다. 사용되는 인터페이스 하드웨어에 따라서, 이들 값은 경험적 데이터를 사용하여 전개될 수도 있고 동작을 개선시키기 위해 어떤 경우에서는 조절될 수도 있다.

몇몇 인자들 (factors) 은 Turn Around 1 의 길이 결정에 기여하며, 이러한 것들은 순방향 링크 데이터 레이트 (data rate), 그리고 호스트 내에서의 MDDI_Data 드라이버들의 최대 디스에이블 시간이다. 최대 호스트 드라이버 디스에이블 시간은, 드라이버들이 디스에이블 되는데 약 10 nsec.가, 그리고 인에이블 되는데 약 2 nsec.가 걸리는 것을 보여주는, [Table XI] 에 지정되어 있다. 호스트 드라이버가 디스에이블 되는데 필요한 순방향 링크 클럭의 최대 수는 다음의 관계식으로 표현된다.

Turn Around 1 의 허용 값 범위는 다음의 관계식으로 표현된다:

여기서, Interface Type Factor 는 Type-Ⅰ 에 대해서는 1, Type-Ⅱ 에 대해서는 2, Type-Ⅲ 에 대해서는 4, 그리고 Type-Ⅳ 에 대해서는 8 이다.

상기 두 개의 식을 결합하면, Interface Type Factor 부분이 상쇄되는 것을 알 수 있으며, Turn Around 1 은 다음과 같이 정의된다.

예를 들어, 1500 Mbps Type-Ⅲ 순방향 링크는 다음의 Turn Around 1 지연을 사용할 것이다.

라운드 트립 (round trip) 지연이 증가할수록, 디스플레이가 인에이블 되는 시간에 대해 호스트가 디스에이블 되는 시간에서의 포인트로부터 타이밍 마진 (timing margin) 이 개선된다.

일반적으로 Turn Around 2 에 사용되는 시간의 길이를 결정하는 인자들은 순방향 링크 데이터 레이트, 디스플레이에서 MDDI_Data 드라이버의 최대 디스에이블 시간, 그리고 통신 링크의 라운드-트립 지연이다. 디스플레이 드라이버를 디스에이블 시키는데 필요한 시간의 계산은, 상술한 바와 같은 호스트 드라이버에 대한 것과 본질적으로 동일하며, 다음의 관계식에 따라 정의된다:

그리고, Turn Around 2 의 허용 값 범위는 다음과 같이 표현된다.

예를 들어, 1500 Mbps Type-Ⅲ 순방향 링크는 통상적으로 다음 식의 오더의 Turn Around 2 지연을 사용한다.

ⅩⅡ. 링크 지연과 스큐 (skew) 의 효과

지연 스큐 보상이 사용되지 않는다면, MDDI_Data 쌍과 MDDI_Stb 간의 순방향 링크 상에서의 지연 스큐는 최대 가능한 데이터 레이트를 제한할 수 있다. 타이밍 스큐를 발생시키는 지연에서의 차이는, 이하에서 약술되는 바와 같이, 제어기 로직, 라인 드라이버들 및 수신기들, 그리고 케이블과 커넥터들에 기인한다.

A. 스큐에 의해 제한되는 링크 타이밍 분석 (MDDI Type_Ⅰ)

1. Type_Ⅰ 링크의 지연과 스큐의 예

Type_Ⅰ 인터페이스 링크를 설명하기 위하여, 도 41 에 도시된 것과 유사한 통상적인 인터페이스 회로가 도 57 에 도시되어 있다. 도 57 에, 몇몇 프로세싱 각각 또는 MDDI Type_Ⅰ 순방향 링크의 인터페이스 스테이지들에 대한 전파 지연과 스큐에 대한 예시적인 또는 통상적인 값이 도시되어 있다. MDDI_Stb 와 MDDI_Data0 간 지연에서의 스큐는 출력 클럭의 듀티-사이클이 왜곡되는 것을 야기한다. 플립-플롭 (5728, 5732) 을 사용하는 수신기 플립-플롭 (RXFF) 스테이지의 D 입력에서의 데이터는 클럭 에지 후에 약간 변화하도록 하여 신뢰도 있게 샘플 될 수 있도록 한다. 도면에는 이러한 타이밍 관계에서의 2 개의 다른 문제점들을 해결하는데 사용되는 두 개의 캐스캐이드 된 지연 라인 (5732a 및 5732b) 이 도시되어 있다. 실제적인 구현에서, 이러한 것들은 단일 지연 소자로 결합될 수도 있다.

인터페이스를 통한 예시적인 신호 프로세싱에 대한 Type_Ⅰ 링크상에서의 Data, Stb, 및 Clock Recovery Timing 이 도 58 에 도시되어 있다.

중요한 총 지연 스큐는 다음의 스테이지들에서 스큐의 합으로부터 유발되거나 일어날 수 있다: 플립-플롭 (5704, 5706) 을 갖는 송신기 플립-플롭 (TXFF); 드라이버 (5708, 5710) 를 갖는 송신기 드라이버 (TXDRVR); CABLE (5702); 수신기 (5722, 5724) 를 갖는 수신기 라인 수신기 (RXRCVR); 및 수신기 XOR 로직 (RXXOR). Delay1 (5732a) 은 다음 관계식에 의해 결정되는 RXXOR 스테이지 내의 XOR 게이트 (5736) 의 지연을 초과하거나, 또는 정합하여야 한다.

수신기 플립-플롭 (5728, 5732) 의 D 입력이 그들의 클럭 입력 전에 변하지 않도록 하기 위해 이러한 요구조건을 만족시키는 것이 바람직하다. RXFF의 홀드-시간 (hold-time) 이 0 이라면, 이것은 유효하다.

Delay2 의 목적 또는 기능은 다음의 관계식에 따라 RXFF 플립-플롭의 홀드-시간을 보상하는 것이다.

많은 시스템들에서, 홀드 시간은 0 이기 때문에 이것은 0 일 것이며, 또한 이러한 경우에 Delay2 의 최대 지연 또한 0 일 수 있다.

수신기 XOR 스테이지에서 스큐에 대한 최악의-경우의 기여는, 데이터-늦음/스트로브-빠름 (data-late/strobe-early) 경우에서, Delay1 이 최대 값이고 XOR 게이트로부터의 클럭 출력이 다음의 관계식에 따라 가능한 한 빨리 나오는 경우이다.

이러한 경우에, 데이터는 2 비트 기간, n 과 n+1 사이에서 비트 n+1 이 수신기 플립-플롭 안으로 클럭되는 시간에 아주 근사하게 변할 수도 있다.

MDDI Type_Ⅰ 링크의 최대 데이터 레이트 (최소 비트 기간) 는, MDDI 링크 내에서 모든 드라이버들, 케이블들, 그리고 수신기들을 통해 거치게되는 최대 스큐와 RXFF 스테이지 내로의 총 데이터 셋업의 합이다. RXRCVR 스테이지의 출력에 대한 링크 업 내에서의 총 지연 스큐는 다음과 같이 표현될 수 있다:

그리고, 최소 비트 기간은 다음과 같이 주어진다.

도 57 에 도시된 예에서, t_{SKEW-max(LINK)}=1.4 nsec 와 최소 비트 기간은 다음과 같이 표현된다:

, 또는 근사적으로 416 Mbps로 언급된다.

B. MDDI Type-Ⅱ, Ⅲ, 및 Ⅳ 에 대한 링크 타이밍 분석

Type-Ⅱ, Ⅲ, 및 Ⅳ 인터페이스 링크들을 설명하기 위해, 도 41 및 57 에 도시된 것과 유사한 통상적인 인터페이스 회로가 도 59 에 도시되어 있다. 추가적인 신호 프로세싱을 설명하기 위해, 추가적인 요소들이 TXFF (5904), TXDRVR (5908), RXRCVCR (5922), 및 RXFF (5932, 5928, 5930) 스테이지들 내에 사용된다. 도 59 에서, 전파 지연과 스큐에 대한 예시적인 또는 통상적인 값이 몇몇의 프로세싱 각각 또는 MDDI Type-Ⅱ 순방향 링크의 인터페이스 스테이지들에 대해 도시되어 있다. 출력 클럭의 듀티-사이클에 영향을 미치는 MDDI_Stb 와 MDDI_Data0 간의 지연 내에서의 스큐에 더하여, 이러한 두 개의 신호들 모두와 다른 MDDI_Data 신호들 간의 스큐가 또한 있다. 플립-플롭 (5928 및 5930) 으로 구성되는 수신기 플립-플롭 B (RXFFB) 스테이지의 D 입력에서의 입력은 클럭 에지 후에 약간 변하게 하며, 신뢰도 있게 샘플 될 수 있도록 한다. MDDI_Data1 이 MDDI_Stb 또는 MDDI_Data0 보다 먼저 도착한다면, MDDI_Data1은 적어도 지연 스큐의 양만큼 샘플 되기 위해 지연되어야만 한다. 이를 수행하기 위해, 데이터는 Delay3 지연 라인을 사용하여 지연된다. 만약 MDDI_Data 가 MDDI_Stb 와 MDDI_Data0 보다 늦게 도착하고 또한 Delay3 에 의해 지연된다면, MDDI_Data1 이 변하는 점은 다음 클럭 에지에 더 가깝게 이동된다. 이러한 프로세스는 MDDI Type-Ⅱ, Ⅲ, 및 Ⅳ 의 데이터 레이트의 상한을 결정한다. 타이밍 또는 두 개의 데이터 신호와 MDDI_Stb 의 서로에 대한 스큐 관계에 대한 몇 가지 예시적인 다른 가능성들이 도 60a, 60b, 및 60c 에 도시되어 있다.

MDDI_DataX가 가능한 한 빨리 도착할 때 RXFFB 내에서 신뢰도 있게 데이터를 샘플하기 위해서, Delay3 은 다음의 관계식에 따라 설정되어야 한다.

최대 링크 속도는 최소 허용 가능 비트 기간에 의해 결정된다. MDDI_DataX 가 최대한 늦게 도착하는 경우에, 이것이 가장 많이 영향을 받는다. 이러한 경우, 최소 허용 가능 사이클 시간은 다음과 같이 주어진다.

그러면, 링크 속도의 상한 경계는 다음과 같으며,

다음과 같은 가정하에 주어진다.

상기 주어진 예에서, 최소 비트 기간의 하한 경계는 다음 관계식과 같이 주어진다:

, 이는 대략 208 Mbps이다.

이것은 Type-Ⅰ 링크에 사용될 수 있는 최대 데이터 레이트 보다 더 느리다. MDDI 의 자동 지연 스큐 보상 능력은 지연 스큐가 최대 링크 레이트 상에서 갖는 영향을 현저하게 줄인다.

ⅩⅢ. 물리층 상호연결 설명

본 발명에 따른 인터페이스를 구현하는데 유용한 물리적인 연결은 호스트 측에서는 Hirose Electric Company 에 의해 제조된 부품 번호 3260-8S2(01), 디스플레이 디바이스 측에서는 Hirose Electric Company 에 의해 제조된 부품 번호 3240-8P-C 와 같은 상업적으로 이용 가능한 부품들을 사용하여 실현될 수 있다. Type-Ⅰ/Type-Ⅱ 인터페이스들에 사용되는 이러한 연결에 대한 예시적인 인터페이스 핀 할당 또는 "핀아웃 (pinout)" 이 [표 ⅩⅢ] 에 리스트되어 있으며, 도 61 에 도시되어 있다.

[표 ⅩⅢ]

실드 (shield) 는 호스트 인터페이스 내의 MDDI_Gnd 에 연결되고, 케이블 내의 실드 드레인 선은 디스플레이 커넥터의 실드에 연결된다. 그러나, 실드와 드레인 선은 디스플레이의 회로 접지 (ground) 에 연결되지 않는다.

상호연결 요소들 또는 디바이스들은, 디바이스 크기에 비해 두드러지거나 모양이 이상하지 않게, PDA 및 무선 전화기와 같은 이동 통신과 컴퓨팅 디바이스들,또는 휴대형 게임 디바이스들에 사용되기에 충분하게 작도록 선택되거나 또는 디자인된다. 어떤 커넥터들과 케이블링은 통상적인 소비자 환경에서 사용되고, 낮은 가격에 비해 특히 케이블링에 대한 작은 크기가 허용되기에 충분할 정도로 내구성이 있어야 한다. 전송 요소들은, Type Ⅰ 과 Type Ⅱ 에 대해 450 Mbps 이상의 전송 레이트, 8-비트 병렬 Type Ⅳ 버전에 대해 3.6 Gbps 이상의 전송 레이트를 갖는 차동 NRZ 데이터인 데이터 및 스트로브 신호들을 제공해야 한다.

ⅩⅣ. 동작

본 발명의 실시 형태를 이용하여 인퍼페이스 동작 동안 데이터와 패킷들을 프로세싱 하는데 수행되는 일반적인 단계들에 대한 요약이, 도 55 의 패킷을 프로세싱 하는 인터페이스 디바이스의 개요와 함께, 도 54a 및 54b 에 도시되어 있다. 이러한 도면들에서, 여기에서는 케이블인 통신 패스를 사용하여 클라이언트와 호스트가 연결되었는지 여부에 대한 결정과 함께, 프로세스는 단계 (5402)에서 시작된다. 호스트에 의한 주기적인 검사 (periodic polling), (USB 인터페이스에 대해서 볼 수 있는 바와 같이) 커텍터들 또는 케이블 또는 호스트에 대한 입력에서의 신호들의 존재를 검출하는 소프트웨어 또는 하드웨어, 또는 다른 알려진 기술들을 사용함으로써 이러한 것이 발생될 수 있다. 만약 호스트에 클라이언트가 연결되지 않았다면 그 후 단순히 소정 길이의 웨이트 상태 (wait state) 로 들어가며, 응용에 의존하여 휴면 (hibernation) 모드로 들어가거나 또는 호스트에 반응하여 행동을 취하도록 사용자에게 요구할 수도 있는 장래의 사용을 기다리도록 비활성화 된다. 예를 들어, 호스트가 컴퓨터 타입 디바이스 상에 있는 경우, 사용자는 스크린 상의아이콘을 클릭하거나 클라이언트를 위한 호스트 프로세싱 토트 룩 (tot look) 을 활성화시키는 프로그램을 요청해야만 하는 경우도 있을 수 있다. 또한, Type-U 인터페이스에 사용되는 것과 같은 USB 타입 연결의 단순한 플러그 인은 호스트 프로세싱을 활성화시킬 수 있다.

일단, 클라이언트가 호스트에 또는 역으로 연결되면, 또는 현재로서 검출되면, 단계 (5404 및 5406) 에서 클라이언트 또는 호스트는 서비스를 요청하는 적절한 패킷을 보낸다. 단계 (5404) 에서 클라이언트는 Display Service Request 또는 Status 패킷을 보낸다. 상기 논의된 바와 같이, 링크는 이전에 완전히 꺼지거나 또는 휴면 모드로 들어가며, 이는 이어지는 통신 링크의 완전한 초기화일 수는 없다. 일단, 통신 링크가 동기화되고 호스트가 클라이언트와 통신을 시도하는 중이면, 단계 (5408) 에서와 같이, 클라이언트 또한 호스트에게 Display Capabilities 패킷을 제공할 필요가 있다. 이제 호스트는 전송 레이트를 포함한 지원 타입을 결정하기 시작할 수 있고, 클라이언트를 수용할 수 있다.

일반적으로, 호스트와 클라이언트는 또한, 단계 (5410) 에서, 예를 들어 Type Ⅰ, Type U, Type Ⅱ 등과 같은 사용될 서비스 모드의 타입 (레이트/속도) 을 협상한다. 일단 서비스 타입이 설정되면, 호스트는 정보의 전송을 시작한다. 또한, 단계 (5411) 에 도시된 바와 같이, 호스트는 다른 신호 프로세싱과 병렬로 통신 링크들의 타이밍을 최적화하기 위해 Round Trip Delay Measurement Packets 를 사용할 수도 있다.

상술한 바와 같이, 단계 (5412)에서 전송되는 것과 같이 모든 전송들은 Sub-Frame Header Packet 과 함께 시작되고, 단계 (5414) 에서 전송되는 것과 같이 여기에서의 비디오 및 오디오 스트림 패킷, 그리고 필러 (filler) 패킷과 같은 데이터의 타입들이 이어진다. 오디오 및 비디오 데이터는 이전에 준비되어 페킷에 매핑될 것이며, 필러 패킷은 매체 프레임에 필요한 비트 수를 채워넣기에 필요할 정도로 삽입된다. 호스트는 사운드 디바이스를 동작시키기 위해 Forward Audio Channel Enable Packets 과 같은 패킷을 전송할 수 있으며, 또는 추가적으로 호스트는, 여기에서 단계 (5416) 에서 Color Map, Bit Block Transfer 또는 다른 패킷의 전송으로서 도시된, 상술된 다른 패킷 타입을 사용하여 명령과 정보를 전송할 수 있다. 또한, 호스트와 클라이언트는 적절한 패킷을 이용하여 키보드 또는 포인팅하는 디바이스 (pointing device) 와 관련있는 데이터를 교환할 수 있다.

동작하는 동안, 몇몇 다른 이벤트들 중 하나가 발생할 수 있으며, 호스트 또는 클라이언트가 다른 데이터 레이트 또는 인터페이스 모드의 타입을 원하도록 한다. 예를 들어, 컴퓨터 또는 데이터를 통신하는 다른 디바이스는 패킷의 준비 또는 제출 (presentation) 에 있어서 속도를 줄이는 것을 야기하는 프로세싱 데이터에서의 로딩 조건에 직면할 수도 있다. 데이터를 수신하는 디스플레이는 더욱 제한된 배터리 파워 소스에 대해 공급되는 AC 파워 소스로부터 변할 수도 있으며, 빨리 데이터를 전송하고 쉽게 명령을 프로세스 할 수 없거나, 또는 더욱 제한된 파워 세팅들 하에서 동일한 정도의 해상도 또는 컬러 깊이를 사용할 수 없을 수도 있다. 다른 방법으로, 제한 조건이 감소되거나 없어져서 더 높은 레이트로 데이터를 전송하는 디바이스가 허용될 수도 있다. 이러한 것은 더욱 바람직하며, 더 높은 전송 레이트 모드로 변하도록 하는 요구를 만들 수도 있다.

이러한 또는 알려진 다른 조건들의 타입들이 발생하거나 또는 변한다면, 호스트 또는 클라이언트는 그것들을 검출하여 인터페이스 모드에 대한 재협상을 시도할 수도 있다. 이것은 단계 (5420) 에 도시되어 있으며, 호스트가 Interface Type Handoff Request Packets 를 다른 모드로의 핸드오프를 요구하는 클라이언트에게 보내고, 클라이언트는 변화를 찾았음을 확인하는 Interface Type Acknowledge Packets 를 보내며, 그리고 호스트는 특정 모드로 변화하도록 하는 Perform Type Handoff Packets 를 보낸다.

비록, 프로세싱의 특정한 명령을 요구하지 않더라도, 클라이언트와 호스트는 또한, 의도되거나 지정하는 디바이스들, 키보드, 또는 주로 클라이언트와 관련이 있는 다른 사용자 타입 입력 디바이스들로부터, 비록 이러한 요소들이 호스트 측에 또한 존재할 수도 있지만, 수신된 데이터와 관련있는 패킷을 교환할 수 있다. 이러한 패킷들은 통상적으로 상태 기계 (state machine) 이 아닌 일반적인 프로세스 또는 타입 요소 (type element) 를 사용하여 프로세싱된다 (5502). 또한, 상술된 어떤 명령들은 일반적인 프로세서에 의해 프로세싱될 것이다 (5504, 5508).

데이터와 명령들이 호스트와 클라이언트 간에 교환된 후, 어떤 지점에서는 추가적인 데이터가 전송될지 여부 또는 호스트나 클라이언트가 전송 서비스를 중단할지 여부에 대한 결정이 이루어진다. 이것이 단계 (5422) 에 도시되어 있다. 링크가 휴면 상태에 들어가거나 또는 완전히 끊겼다면, 호스트는 Link Shutdown 패킷을 클라이언트에게 보내며, 양쪽은 데이터의 전송을 중단한다.

상술한 동작 프로세싱에서 전송되는 패킷은 호스트와 클라이언트 제어기와 관련하여 이전에 논의된 드라이버들과 수신기들을 사용하여 전송된다. 이러한 라인 드라이버들과 다른 로직 요소들은, 도 55 에 개략적으로 도시된 바와 같이 상술된 상태 기계과 일반적인 프로세서들과 연결된다. 도 55 에서, 상태 기계 (5502) 과 일반적인 프로세서들 (5504, 5508) 은, 이에 한정되지는 않으나 데이터 소스, 그리고 디스플레이 디바이스들을 위한 비디오 제어 칩들을 포함하는, USB 인터페이스, 메모리 요소들, 또는 링크 제어기의 외부에 존재하며 서로 상호작용을 하는 다른 구성요소들과 같은 도시되지 않은 다른 요소들과 더 연결될 수도 있다.

프로세서들, 그리고 상태 기계는 보호 시간 등과 관련하여 상술한 바와 같이 드라이버의 인에이블링과 디스에이블링을 통해 제어를 제공하여, 통신 링크의 효율적인 설정 또는 해제, 그리고 패킷의 전송을 보장한다.

ⅩⅤ. 부록

본 발명의 실시형태에 대한 구조체와 프로토콜을 구현하기 위해 사용된 다양한 패킷에 대해 상술한 포맷들, 구조체들, 그리고 내용들에 더하여, 더욱 상세한 분야의 내용들 또는 동작들이 몇 가지의 패킷 타입들에 대해 여기에서 설명되어진다. 이러한 것들이 여기에서 설명되어짐으로써 그들 각각의 사용 또는 동작을 더욱 명확하게 하어, 당업자가 좀 더 쉽게 이해하도록 할 수 있을 것이며 본 발명의 다양한 응용들에 대해 이용할 수 있도록 할 수 있을 것이다. 이전에 논의되지 않았던 단지 몇 가지의 분야들만이 이후에 논의될 것이다.

A. 비디오 스트림 패킷

Display attributes field(1 byte) 는 다음과 같이 해석되는 일련의 비트 값들을 갖는다. Bit 1 과 0 은 디스플레이 픽셀 데이터가 어떻게 라우팅 되는지 선택한다. 비트 값 '00' 또는 '11' 에 대해서 데이터는 모두 눈에 대해 디스플레이 되고, 비트 값 '10' 에 대해서 데이터는 오직 왼쪽 눈에 라우팅되고, 그리고 비트 값 '01' 에 대해서 데이터는 오직 오른쪽 눈에 라우팅된다. Bit 2 는 Pixel Data 가 인터레이스 (interlace) 포맷 내에 있는지 여부를 알려주며, '0' 값은 픽셀 데이터가 표준 진행 (progressive) 포맷 내에 있음을 의미하며, 행 수 (픽셀 Y 좌표) 는 하나의 행으로부터 다음 행으로 진행할 때 1 씩 증가한다. 이러한 비트는 '1' 의 값을 가지며, 픽셀 데이터는 인터레이스 포맷 내에 있으며, 그리고 행 수는 한 행으로부터 다음 행으로 진행할 때 2 씩 증가한다. Bit 3 은 Pixel Data 가 교대 (alternative) 픽셀 포맷 내에 있음을 알려준다. 이것은 Bit 2 에 의해 인에이블되는 표준 인터레이스 모드와 유사하나, 인터레이싱은 수평인 대신 수직이다. Bit 3 이 0 일 때, Pixel Data는 표준 진행 포맷 내에 있고, 열 수 (픽셀 X 좌표) 는 각각의 연속적인 픽셀이 수신될 때마다 1 씩 증가한다. Bit 3 이 1 일 때, Pixel Data 는 교대 픽셀 포맷 내에 있으며, 열 수는 각각의 픽셀이 수신될 때마다 2 씩 증가한다. Bit 7 부터 4 는 장래의 사용을 위해 유보되며, 일반적으로 0 으로 설정된다.

2-바이트X Start와Y Start fields는 Pixel Data 영역 내에서 제 1 픽셀에 대한 절대 X 와 Y 좌표점 (X Start, Y Start) 을 특정한다. XRight Edge와Y Bottom Edge fields가 오른쪽 에지의 X 좌표와 업데이트될 창의 하부 에지의 Y 좌표를 특정하는데 반해, 2-byteX left EdgeandY Top Edge fields는 Pixel Data 영역에 의해 채워진 스크린 창의 왼쪽 에지의 X 좌표와 상부 에지의 Y 좌표를 특정한다.

Pixel Count field(2 바이트) 는 아래의 Pixel Data 영역 내에서의 픽셀들의 수를 특정한다.

Parameter CRC field(2 바이트) 는 Packet Length 로부터 Pixel Count 로의 모든 바이트들의 CRC 를 포함한다. 이 CRC 가 체크하는데 실패한다면, 모든 패킷들은 버려진다.

Pixel Data field는 디스플레이될 원래의 비디오 정보를 포함하며, Video Data Format Descriptor 영역에 의해 설명된 방법으로 포맷된다. 데이터는 다른 곳에서 논의된 바와 같이 한번에 한 "행" 이 전송된다.

Pixel Data CRC field(2 바이트) 는 오직 Pixel Data 의 16-비트 CRC 를 포함한다. 만약 이러한 값의 CRC 확인에 실패한다면, Pixel Data 가 여전히 사용되나 CRC 에러 카운트가 증가된다.

B. 오디오 스트림 패킷에 대해

Audio Channel ID field(1 바이트) 는 클라이언트 디바이스에 의해 보내진 오디오 대이터에 대해 특정 오디오 채널을 확인한다. 물리적인 오디오 채널들은 이러한 영역 내에 특정되거나, 또는 이러한 영역을 각각 왼쪽 정면, 오른쪽 정면, 왼쪽 뒤, 오른쪽 뒤, 정면 중앙, 부-우퍼 (sub-woofer), 서라운드 왼쪽, 그리고 서라운드 오른쪽 채널을 나타내는 0, 1, 2, 3, 4, 5, 6, 7 값에 매핑된다. 254 의 오디오 채널 ID 값은 디지털 오디오 샘플들의 단일 스트림이 왼쪽 정면과 오른쪽 정면 채널들 모두로 보내진 것을 나타낸다. 이것은 음성 통신, PDA 에서 생산력 향상된 응용들, 또는 간단한 User Interface 가 경고 톤을 발생하는 다른 응용들에서 스테레오 헤드셋이 사용된 경우의 응용들을 간략화한다. 8 부터 253, 그리고 255 의 범위의 ID 영역에 대한 값들은 추가적인 지정에 대한 새로운 디자인이 필요한 경우에 사용할 경우를 대비하여 현재에는 유보된다.

Audio Sample Count field(2 바이트) 는 이러한 패킷 내에서의 오디오 샘플들의 수를 특정한다.

Bit Per Sample and Packing field는 오디오 데이터의 페이싱 (pacing) 포맷을 특정하는 1 바이트를 포함한다. 일반적으로 적용된 포맷은 Bit 4 부터 0 에 대해 PCM 오디오 샘플당 비트 수를 정의한다. 다음으로, Bit 5 는 Digital Audio Data 샘플들이 패킷화 되었는지 (packed) 여부를 특정한다. 상술한 바와 같이, 도 12 는 패킷화 된 것과 바이트-정렬된 (byte-aligned) 오디오 샘플들 간의 차이를 나타낸다. Bit 5 에 대한 '0' 값은 Digital Audio Data 영역 내의 각각의 PCM 오디오 샘플이 인터페이스 바이트 경계와 바이트-정렬된 것을 알려주며, '1' 값은 각각의 연속적인 PCM 오디오 샘플이 이전의 오디오 샘플에 대해 패킷화 된 것을 알려준다. 이러한 비트는 단지 Bit 4 부터 0 (PCM 오디오 샘플당 비트의 수) 내에 정의된 값이 8의 배수가 아닌 경우에만 효과적이다. Bit 7 부터 6 은 추가적인 지정을 위해 시스템 디자인이 필요한 경우 사용하기 위해 유보되며, 일반적으로 0 의 값으로 설정된다.

오디오 샘플 레이트 필드 (1 바이트) 는 오디오 PCM 샘플 레이트를 특정한다. 사용된 포맷은, 각각, 값 0 값은 8,000 sps (samples per second) 의 레이트를 나타내고, 값 1 은 16,000 sps 를 나타내고, 값 2 는 24,000 sps 를 나타내고, 값 3 은 32,000 sps 를 나타내고, 값 4 는 40,000 sps 를 나타내고, 값 5 는 48,000 sps 를 나타내고, 값 6 은 11,025 sps 를 나타내고, 값 7 은 22,050 sps 를 나타내고, 값 8 은 44,100 sps 를 나타내며, 값 9 내지 15 는 추후 사용용으로 예비하도록 일반적으로 0 으로 설정한다.

파라미터 CRC 필드 (2 바이트) 는 패킷 길이로부터 오디오 샘플 레이트까지의 모든 바이트의 16-비트 CRC 를 포함한다. 만약 이 CRC 가 적절하게 체크하지 못하면, 전체 패킷은 폐기된다. 디지털 오디오 데이터 필드는 재생될 원래의 오디오 샘플 (raw audio samples) 을 포함하고, 일반적으로, 부호없는 정수 (unsigned integer) 의 선형 포맷의 형태이다. 오디오 데이터 CRC 필드 (2 바이트) 는 오직 오디오 데이터만의 16-비트 CRC 를 포함한다. 이 CRC 가 체크를 실패할 경우, 오디오 데이터는 여전히 사용될 수 있지만 CRC 에러 카운트가 증가된다.

C. 사용자-정의 스트림 패킷의 경우

2-바이트 스트림 ID 번호 필드는 특정한 사용자 정의 스트림을 식별하는데 사용된다. 스트림 파라미터 및 스트림 데이터 필드의 콘텐츠는 MDDI 장비 제조업자에 의해 정의된다. 2-바이트 스트림 파라미터 CRC 필드는 패킷 길이로부터 오디오 코딩 바이트까지의 스트림 파라미터들의 모든 바이트의 16-비트 CRC 를 포함한다. 만약 이 CRC 가 체크를 실패하면, 전체 패킷은 폐기된다. 2-바이트 스트림 데이터레이트 CRC 필드는 오직 스트림 데이터만의 CRC 를 포함한다. 만약 이 CRC 가 적절히 체크할 수 없으면, 애플리케이션의 요건에 따라, 스트림 데이터의 사용은 선택적이다. 일반적으로, 양호한 CRC 에 의존하는 스트림 데이터의 사용은 그 CRC 가 양호하다고 확인될 때까지 스트림 데이터를 버퍼링하는 것이 요구된다. 만약 CRC 가 체크되지 않으면, CRC 에러 카운트는 증가된다.

D. 컬러 맵 패킷의 경우

컬러 맵 데이터 사이즈 필드 (2 바이트) 는 이 패킷의 컬러 맵 데이터에 존재하는 컬러 맵 테이블 엔트리의 총 갯수를 특정한다. 컬러 맵 데이터의 바이트 수는 컬러 맵 사이즈의 3 배이다. 컬러 맵 사이즈는 컬러 맵 데이터를 송신하지 않도록 0 으로 설정한다. 만약 컬러 맵 사이즈가 0 이면, 컬러 맵 오프셋 값은 여전히 송신되지만 디스플레이에 의해 무시된다. 컬러 맵 오프셋 필드 (2 바이트) 는 디스플레이 디바이스의 컬러 맵 테이블의 시작으로부터 이 패킷의 컬러 맵 데이터의 오프셋을 특정한다.

2-바이트 파라미터 CRC 필드는 패킷 길이로부터 오디오 코딩 바이트까지의 모든 바이트의 CRC 를 포함한다. 만약 이 CRC 가 체크를 실패하면, 전체 패킷은 폐기된다.

컬러 맵 데이터 필드의 경우, 각각의 컬러 맵 위치는 3-바이트 값으로, 제 1 바이트는 블루의 크기를 특정하고, 제 2 바이트는 그린의 크기를 특정하며, 제 3 바이트는 레드의 크기를 특정한다. 컬러 맵 사이즈 필드는 컬러 맵 데이터 필드에 존재하는 3-바이트 컬러 맵 테이블 아이템의 수를 특정한다. 만약 단일 컬러 맵이하나의 비디오 데이터 포맷 및 컬러 맵 패킷에 일치될 수 없으면, 전체 컬러 맵은 각각의 패킷에서의 상이한 컬러 맵 데이터 및 컬러 맵 오프셋을 갖는 다중 패킷들을 송신함으로써 특정될 수도 있다.

2-바이트 컬러 맵 데이터 CRC 필드는 오직 컬러 맵 데이터만의 CRC 를 포함한다. 만약 이 CRC 가 체크를 실패하면, 컬러 맵 데이터는 여전히 사용될 수 있지만 CRC 에러 카운트는 증가된다.

E. 역방향 링크 캡슐화 패킷의 경우

역방향 링크 플래그 필드 (1 바이트) 는 정보를 디스플레이로부터 요청하도록 일련의 플래그들을 포함한다. 만약 하나의 비트 (여기서는 비트 0) 가 1 로 설정되면, 호스트는 디스플레이 능력 패킷을 사용하여 디스플레이로부터 특정 정보를 요청한다. 만약 그 비트가 0 이면, 호스트는 디스플레이로부터 그 정보를 요구하지 않는다. 나머지 비트들 (여기서는 비트 1 내지 7) 은 추후 사용용으로 예비되며 0 으로 설정된다.

역방향 레이트 제수 필드 (reverse rate divisor field; 1 바이트) 는 역방향 링크 데이트 클럭과 관련하여 방생하는 MDDI_Stb 사이클의 수를 특정한다. 역방향 링크 데이터 클럭은 2 배의 역방항 링크 제수로 나누어지는 순방향 링크 데이터 클럭과 같다. 역방향 링크 데이터 레이트는 역방향 링크를 통한 역방향 링크 데이터 클럭 및 인터페이스 타입과 관련된다. 타입 I 인터페이스의 경우, 역방향 데이터 레이트는 역방향 링크 데이터 클럭과 동일하며, 타입 II, 타입 III, 및 타입 IV 인터페이스의 경우, 역방향 링크 데이터 레이트는, 각각, 역방향 링크 데이터 클럭의 2 배, 4 배, 및 8 배이다.

턴-어라운드 (turn-around) 1 길이 필드 (1 바이트) 는 턴-어라운드 1 용으로 할당된 전체 바이트 수를 특정한다. 턴-어라운드 1 의 권고 길이는 출력이 디스에이블되도록 호스트의 MDDI_Data 드라이버용으로 요구되는 바이트 수이다. 이것은 상술한 출력 디스에이블 시간, 순방향 링크 데이터 레이트 및 사용되는 순방향 링크 인터페이스 타입 선택에 의존한다. 턴-어라운드 1 의 설정에 대한 더 상세한 설명은 상술되어 있다.

턴-어라운드 2 길이 필드 (1 바이트) 는 턴-어라운드용으로 할당된 전체 바이트 수를 특정한다. 턴-어라운드 2 의 권고 길이는 자신의 출력 플러스 라운드-트립 (round-trip) 지연을 디스에이블되도록 디스플레이의 MDDI_Data 드라이버용으로 요구되는 바이트 수이다. 턴-어라운드 2 의 설정에 대한 설명은 상술되어 있다.

파라미터 CRC 필드 (2 바이트) 는 패킷 길이로부터 턴-어라운드 길이까지의 총 바이트의 16-비트 CRC 를 포함한다. 만약 이 CRC 가 실패하면, 전체 패킷은 폐기된다.

올 제로 (all zero) 필드 (1 바이트) 는 0 으로 설정되고, 모든 MDDI_Data 신호들이 제 1 가드 타임 (guard time) 주기 동안 라인 드라이버 (line drivers) 를 디스에이블시키기 전에 0 상태에 있는 것을 보증하는데 사용된다.

턴-어라운드 1 필드는 제 1 턴-어라운드 주기를 확립하는데 사용된다. 턴-어라운드 파라미터에 의해 특정되는 바이트 수는 클라이언트 (디스플레이) 의 라인 드라이버가 인에이블되기 전에 호스트의 MDDI_Data 라인 드라이버를 디스에이블시키도록 이 필드에 의해 할당된다. 호스트는 턴-어라운드 1 의 비트 0 동안 자신의 MDDI_Data 라인 드라이버를 디스에이블시키며, 클라이언트 (디스플레이) 는 턴-어라운드 1 의 마지막 비트 직후에 자신의 라인 드라이버를 디스에이블시킨다. MDDI_Std 신호는 턴-어라운드 주기가 모드 0 인 것 같이 행동한다.

역방향 데이터 패킷 필드는 클라이언트로부터 호스트로 전송되는 일련의 데이터 패킷들을 포함한다. 전술한 바와 같이, 다른 패킷 타입에 의해 사용되지 않은 나머지 공간을 채우기 위하여, 필터 패킷들이 송신된다.

턴-어라운드 2 필드는 제 2 턴-어라운드 주기를 확립하는데 사용된다. 턴-어라운드 길이 파라미터에 의해 특정되는 바이트 수는 이 필드에 의해 할당된다.

드라이버 리-인에이블 (re-enable) 필드는 그 다음 패킷의 패킷 길이 필드에 앞서 모든 MDDI_Data 신호들이 리-인에이블되는 것을 보증하도록 0 과 같은 1 바이트를 사용한다.

F. 디스플레이 능력 패킷의 경우

프로토콜 버전 (protocol version) 필드는 클라이언트에 의해 사용되는 프로토콜 버전을 특정하도록 2 바이트를 사용한다. 초기 버전은 0 으로 설정되지만, 최소 프로토콜 버전 필드는 클라이언트가 사용하거나 해석할 수 있는 최소의 프로토콜 버전을 특정하도록 2 바이트를 사용한다. 디스플레이 데이터 레이트 능력 필드 (2 바이트) 는 디스플레이가 인터페이스의 순방향 링크를 통하여 수신할 수 있는 최대 데이터 레이트를 특정하며, Mbps (megabits per second) 의 형태로 특정된다. 인터페이스 타입 능력 필드 (1 바이트) 는 순방향 및 역방향 링크를 통하여 지원되는 인터페이스 타입을 특정한다. 일반적으로, 이것은 순방향 링크를 통한 타입-II 모드, 타입-III 모드, 또는 타입 IV 모드를 선택하기 위하여, 각각, 비트 0, 비트 1, 또는 비트 2 를 선택함으로써 표시되고, 역방향 링크를 통한 타입-II 모드, 타입-III 모드, 또는 타입 IV 모드를 선택하기 위하여, 각각, 비트 3, 비트 4, 또는 비트 5 를 선택함으로써 표시되며, 비트 6 및 7 은 예비되어 0 으로 설정된다. 비트맵 폭 및 높이 필드 (2 바이트) 는 비트맵의 폭 및 높이를 픽셀로 특정한다.

모노크롬 (monochrome) 능력 필드 (1 바이트) 는 모노크롬 포맷으로 디스플레이될 수 있는 해상도의 비트 수를 특정하는데 사용된다. 만약 디스플레이가 모노크롬 포맷을 사용할 수 없으면, 이 값은 0 으로 설정된다. 비트 7 내지 4 는 추후 사용용으로 예비되며 0 으로 설정된다. 비트 3 내지 0 은 각각의 픽셀에 대하여 존재할 수 있는 그레이스케일 (grayscale) 비트의 최대 수를 정의한다. 이들 4 개의 비트는 각각의 픽셀에 대하여 1 내지 15 의 값을 특정할 수 있게 한다. 만약 그 값이 0 이면, 모노크롬 포맷은 디스플레이에 의해 지원되지 않는다.

컬러맵 능력 필드 (3 바이트) 는 디스플레이의 컬러맵 테이블에 존재하는 테이블 아이템의 최대 수를 특정한다. 만약 디스플레이가 컬러맵 포맷을 사용할 수 없으면, 이 값은 0 이다.

RGB 능력 필드 (2 바이트) 는 RGB 포맷으로 디스플레이될 수 있는 해상도의 비트 수를 특정한다. 만약 디스플레이가 RGB 포맷을 사용할 수 없으면, 이 값은 0 이다. RGB 능력 워드는 3 개의 별도의 부호없는 값들로 이루어지는데, 여기서, 비트 3 내지 0 은 블루 비트의 최대 수를 정의하고, 비트 7 내지 4 는 그린 비트의최대 수를 정의하고, 비트 11 내지 8 은 각각의 픽셀에 레드 비트의 최대 수를 정의한다. 일반적으로, 비트 15 내지 12 는 추후 사용용으로 예비되며 0 으로 설정된다.

Y Cr Cb 능력 필드 (2 바이트) 는 Y Cr Cb 포맷으로 디스플레이될 수 있는 해상도의 비트 수를 특정한다. 만약 디스플레이가 Y Cr Cb 포맷을 사용할 수 없으면, 이 값은 0 이다. Y Cr Cb 능력 워드는 3 개의 별도의 부호없는 값들로 이루어지는데, 여기서, 비트 3 내지 0 은 Cb 샘플에서의 최대 비트 수를 정의하고, 비트 7 내지 4 는 Cr 샘플에서의 최대 비트 수를 정의하고, 비트 11 내지 8 은 Y 샘플에서의 최대 비트 수를 정의하며, 일반적으로, 비트 15 내지 12 는 추후 사용용으로 예비되어 0 으로 설정된다.

디스플레이 특성 표시자 필드는 지원되는 디스플레이에서의 특정한 특성을 표시하는 일련의 플래그들을 포함하는 4 바이트를 사용한다. 1 로 설정된 비트는 그 능력을 지원하는 것을 나타내며, 0 으로 설정된 비트는 그 능력을 지원하지 않음을 나타낸다. 비트 0 에 대한 값은 비트맵 블록 전송 패킷 (패킷 타입 71) 을 지원하는지의 여부를 나타낸다. 비트 1, 2, 및 3 에 대한 값은, 각각, 비트맵 영역 충만 패킷 (bitmap area fill packet; 패킷 타입 72), 비트맵 패턴 충만 패킷 (패킷 타입 73), 또는 통신 링크 데이터 채널 패킷 (패킷 타입 74) 를 지원하는지의 여부를 나타낸다. 비트 4 에 대한 값은 디스플레이가 하나의 컬러를 투명하게 할 수 있는 능력을 가지는지를 나타내지만, 비트 5 및 6 에 대한 값은 디스플레이가, 각각, 비디오 데이터 또는 오디오 데이터를 패킷 포맷으로 받아들일 수 있을지를나타내며, 비트 7 에 대한 값은 디스플레이가 역방향 링크 비디오 스트림을 카메라로부터 송신할 수 있을지를 나타낸다. 비트 11 및 12 에 대한 값은 클라이언트가, 각각, 포인팅 디바이스와 통신하여 포인팅 디바이스 데이터 패킷을 송신 및 수신할 수 있을 때, 또는, 키보드와 통신하여 키보드 데이터 패킷을 송신 및 수신할 수 있을 때를 나타낸다. 일반적으로, 비트 13 내지 31 은 추후 사용용 또는 시스템 설계자에게 유용한 또 다른 지정용으로 예비되며 0 으로 설정된다.

디스플레이 비디오 프레임 레이트 능력 필드 (1 바이트) 는 디스플레이의 최대 비디오 프레임 갱신 능력을 초당 프레임으로 특정한다. 호스트는 이 필드에 특정된 값 보다 더 느린 레이트로 이미지를 갱신하도록 선택할 수도 있다.

오디오 버퍼 깊이 필드 (2 바이트) 는 각각의 오디오 스트림에 할당된 디스플레이의 탄력성있는 버퍼의 깊이를 특정한다.

오디오 채널 능력 필드 (2 바이트) 는 오디오 채널이 디스플레이 (클라이언트) 에 의해 지원됨을 표시하는 일군의 플래그들을 포함한다. 1 로 설정된 비트는 그 채널이 지원됨을 나타내며, 0 으로 설정된 비트는 그 채널이 지원되지 않음을 나타낸다. 비트 위치들은 상이한 채널들에 할당되어, 비트 위치 0, 1, 2, 3, 4, 5, 6, 및 7 은, 각각, 좌측 전방, 우측 전방, 좌측 후방, 우측 후방, 전방 중심, 서브-우퍼 (sub-woofer), 주변 좌측, 및 주변 우측 채널을 나타낸다. 일반적으로, 비트 8 내지 15 는 추후 사용용으로 예비되며 0 으로 설정된다.

순방향 링크의 경우, 2-바이트 오디오 샘플 레이트 능력 필드는 클라이언트 디바이스의 오디오 샘플 레이트 능력을 나타내도록 일련의 플래그들을 포함한다.비트 위치들은 상이한 레이트들에 할당되어, 비트 위치 0, 1, 2, 3, 4, 5, 6, 7, 및 8 은, 각각, 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, 22,050, 및 44,100 SPS (samples per second) 에 할당되며, 원할 경우, 비트 9 내지 15 는 추후 사용용 또는 또 다른 레이트의 사용용으로 예비되며, 일반적으로, 0 으로 설정된다. 이들 비트들 중 하나의 비트에 대한 비트 값을 '1' 로 설정하는 것은 특정한 샘플 레이트가 지원되는 것을 나타내며, 그 비트를 '0' 으로 설정하는 것은 그 샘플 레이트가 지원되지 않음을 나타낸다.

최소 서브-프레임 레이트 필드 (2 바이트) 는 최소의 서브-프레임을 초당 프레임으로 특정한다. 최소 서브-프레임 레이트는 디스플레이에서 특정한 센서 또는 포인팅 디바이스들을 판독하기에 충분한 디스플레이 상태 갱신 레이트를 유지한다.

역방향 링크의 경우, 2-바이트 마이크 샘플 레이트 (mic sample rate) 능력 필드는 클라이언트 디바이스에서 마이크로폰의 오디오 샘플 레이트 능력을 나타내는 일련의 플래그들을 포함한다. MDDI 를 위하여, 클라이언트 디바이스 마이크로폰은 적어도 8,000 SPS 레이트를 최소로 지원하도록 구성된다. 이 필드의 비트 위치들은 상이한 레이트들에 할당되어, 비트 위치 0, 1, 2, 3, 4, 5, 6, 7, 및 8 은, 각각, 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, 22,050, 및 44,100 SPS (samples per second) 를 나타내는데 사용되며, 원할 경우, 비트 9 내지 15 는 추후 사용용 또는 또 다른 레이트의 사용용으로 예비되며, 일반적으로, 0 으로 설정된다. 이들 비트들 중 하나의 비트에 대한 비트 값을 '1' 로 설정하는 것은 특정한 샘플 레이트가 지원되는 것을 나타내며, 그 비트를 '0' 으로 설정하는것은 그 샘플 레이트가 지원되지 않음을 나타낸다. 만약 마이크로폰이 접속되지 않으면, 각각의 마이크 샘플 레이트 능력 비트들은 0 으로 설정된다.

콘텐츠 보호 타입 필드 (2 바이트) 는 디스플레이에 의해 지원되는 디지털 콘텐츠 보호 타입을 나타내는 일련의 플래그들을 포함한다. 일반적으로, 비트 위치 0 은 DTCP 가 지원됨을 나타내는데 사용되며, 비트 위치 1 은 HDCP 가 지원되는 경우를 나타내는데 사용되며, 비트 위치 2 내지 15 는, 원할 경우 또는 사용가능한 경우, 다른 보호 방식과의 사용을 위해 예비되며 0 으로 설정된다.

G. 디스플레이 요청 및 상태 패킷의 경우

역방향 링크 요청 필드 (3 바이트) 는 정보를 호스트로 송신하기 위하여, 디스플레이가 그 다음 서브-프레임의 역방향 링크에서 요구되는 바이트 수를 특정한다.

CRC 에러 카운트 필드 (1 바이트) 는 매체-프레임의 시작 이후에 얼마나 많은 CRC 에러가 발생하였는지를 나타낸다. CRC 카운트는 0 인 서브-프레임 카운트를 갖는 서브-프레임 헤더 패킷이 송신될 때에 리셋된다. 만약 CRC 에러의 실제 수가 255 를 초과하면, 이 값은 255 으로 포화된다.

능력 변경 필드는 디스플레이의 능력의 변경을 나타내도록 1 바이트를 사용한다. 이것은 사용자가 마이크로폰, 키보드 또는 디스플레이와 같은 주변 장치와 연결될 경우, 또는 기타 다른 이유로 발생할 수 있다. 비트 [7:0] 이 0 일 경우, 그 능력은 마지막 디스플레이 능력 패킷이 송신된 이후로 변경되지 않았다. 그러나, 비트 [7:0] 이 1 내지 255 일 경우, 그 능력은 변경되었다. 디스플레이 능력패킷은 신규한 디스플레이 특성을 결정하도록 검사된다.

H. 비트 블록 전송 패킷의 경우

윈도우 상부 좌측 좌표 X 값 및 Y 값 필드는 이동될 윈도우의 상부 좌측 코너의 좌표의 X 및 Y 값을 특정하도록 각각 2 바이트를 사용한다. 윈도우 폭 및 높이 필드는 이동될 윈도우의 폭 및 높이를 특정하도록 각각 2 바이트를 사용한다. 윈도우 X 이동 및 Y 이동 필드는 윈도우가 각각 수평 및 수직으로 이동될 픽셀의 수를 특정하도록 각각 2 바이트를 사용한다. X 에 대한 양 (+) 의 값은 그 윈도우를 우측으로 이동하게 하고, 음 (-) 의 값은 좌측으로 이동하게 하지만, Y 에 대한 양 (+) 의 값은 그 윈도우를 하방으로 이동하게 하고, 음 (-) 의 값은 상방으로 이동하게 한다.

I. 비트맵 영역 충만 패킷의 경우

윈도우 상방 좌측 좌표 X 값 및 Y 값 필드는 충만될 윈도우의 상방 좌측 코너의 좌표의 X 및 Y 값을 특정하도록 각각 2 바이트를 사용한다. 윈도우 폭 및 높이 필드 (2 바이트) 는 충만될 윈도우의 폭 및 높이를 특정한다. 비디오 데이터 포맷 디스크립터 필드 (video data format descriptor field; 2 바이트) 는 픽셀 영역 충만 값의 포맷을 특정한다. 그 포맷은 비디오 스트림 패킷의 동일한 필드와 같다. 픽셀 영역 충만 값 필드 (4 바이트) 는 상술된 필드들에 의해 특정되는 윈도우에 충만될 픽셀 값을 포함한다. 이 픽셀의 포맷은 비디오 데이터 디스크립터 필드에 특정된다.

J. 비트맵 패턴 충만 패킷의 경우

윈도우 상방 좌측 좌표 X 값 및 Y 값 필드는 충만될 윈도우의 상방 좌측 코너의 좌표의 X 및 Y 값을 특정하도록 각각 2 바이트를 사용한다. 윈도우 폭 및 높이 필드 (2 바이트) 는 충만될 윈도우의 폭 및 높이를 특정한다. 패턴 폭 및 패턴 높이 필드 (각각 2 바이트) 는, 각각, 충만 패턴의 폭 및 높이를 특정한다. 2-바이트 비디오 데이터 포맷 디스크립터 필드는 픽셀 영역 충만 값의 포맷을 특정한다. 도 11 은 비디오 데이터 포맷 디스크립터가 코딩되는 방법을 나타낸 것이다. 그 포맷은 비디오 스트림 패킷에서의 동일한 필드와 같다.

파라미터 CRC 필드 (2 바이트) 는 패킷 길이로부터 비디오 포맷 디스크립터까지의 모든 바이트의 CRC 를 포함한다. 만약 이 CRC 가 체크를 실패하면, 전체 패킷은 폐기된다. 패턴 픽셀 데이터 필드는 비디오 데이터 포맷 디스크립터에 의해 특정되는 포맷으로 충만 패턴을 특정하는 원래의 비디오 정보를 포함한다. 데이터는 바이트로 패킷화되고, 각각의 로우 (row) 의 첫번째 픽셀은 바이트-정렬되야 한다. 충만 패턴 데이터는 로우를 한번에 전달받는다. 패턴 픽셀 데이터 CRC 필드 (2 바이트) 는 오직 패턴 픽셀 데이터만의 CRC 를 포함한다. 만약 이 CRC 가 체크를 실패하면, 패턴 픽셀 데이터는 여전히 사용되지만 CRC 에러 카운트가 증가된다.

K. 통신 링크 데이터 채널 패킷

파라미터 CRC 필드 (2 바이트) 는 패킷 길이로부터 패킷 타입까지의 모든 바이트의 16-비트 CRC 를 포함한다. 만약 이 CRC 가 체크를 실패하면, 전체 패킷은 폐기된다.

통신 링크 데이터 필드는 통신 채널로부터의 원래의 데이터를 포함한다. 이데이터는 디스플레이의 컴퓨팅 장치로 간단히 전달된다.

통신 링크 데이터 CRC 필드 (2 바이트) 는 오직 통신 링크 데이터만의 16-비트 CRC 를 포함한다. 만약 이 CRC 가 체크를 실패하면, 통신 링크 데이터는 여전히 유용 또는 사용되지만 CRC 에러 카운트가 증가된다.

L. 인터페이스 타입 핸드오프 요청 패킷의 경우

인터페이스 타입 필드 (1 바이트) 는 사용될 신규한 인터페이스 타입을 특정한다. 이 필드의 값은 다음의 방식으로 인터페이스 타입을 특정한다. 만약 비트 7 의 값이 0 이면, 타입 핸드오프 요청은 순방향 링크용이며, 만약 그 값이 1 이면, 타입 핸드오프 요청은 역방향 링크용이다. 비트 6 내지 3 은 추후 사용용으로 예비되며, 일반적으로, 0 으로 설정된다. 비트 2 내지 0 은 사용될 인터페이스 타입을 정의하는데 사용되며, 1 의 값은 타입-I 모드로의 핸드오프를 의미하고, 2 의 값은 타입-II 모드로의 핸드오프를 의미하고, 3 의 값은 타입-III 모드로의 핸드오프를 의미하고, 4 의 값은 타입-IV 모드로의 핸드오프를 의미한다. 0 및 5 내지 7 의 값은 또 다른 모드 또는 모드들의 조합의 추후 지정용으로 예비된다.

M. 인터페이스 타입 확인응답 패킷 (interface type acknowledge packets) 의 경우

인터페이스 타입 필드 (1 바이트) 는 사용될 신규한 인터페이스 타입을 확인하는 값을 가진다. 이 필드의 값은 다음의 방식으로 인터페이스 타입을 특정한다. 만약 비트 7 이 0 이면, 타입 핸드오프 요청은 순방향 링크용이며, 다른 방법으로, 만약 그 값이 1 이면, 타입 핸드오프 요청은 역방향 링크용이다. 일반적으로, 비트위치 6 내지 3 은, 원할 경우, 다른 핸드오프 타입을 지정하도록 사용하기 위해 예비되며, 일반적으로, 0 으로 설정된다. 그러나, 비트 위치 2 내지 0 은 부정 응답 (NAK) 를 표시하는 0 값과 함께 사용될 인터페이스 타입을 정의하는데 사용되거나 요청된 핸드오프가 수행될 수 없음을 정의하는데 사용되며, 1, 2, 3, 및 4 의 값은, 각각, 타입-I, 타입-II, 타입-III, 및 타입-IV 모드로의 핸드오프를 나타낸다. 원할 경우, 5 내지 7 의 값은 모드들의 또 다른 지정으로 사용하기 위하여 예비된다.

N. 수행 타입 핸드오프 패킷의 경우

1-바이트 인터페이스 타입 필드는 사용될 신규한 인터페이스 타입을 나타낸다. 이 필드에 존재하는 값은 비트 7 의 값을 사용하여 처음으로 인터페이스 타입을 특정하여, 타입 핸드오프가 순방향 링크용인지 역방향 링크용인지를 결정한다. '0' 의 값은 타입 핸드오프 타입이 순방향 링크용임을 나타내며, '1' 의 값은 역방향 링크용임을 나타낸다. 비트 6 내지 3 은 추후 사용용으로 예비되며, 일반적으로, 0 의 값으로 설정된다. 그러나, 비트 2 내지 0 은 사용될 인터페이스 타입을 정의하는데 사용되며, 값 1, 2, 3, 및 4 는, 각각, 타입-I, 타입-II, 타입-III, 및 타입-IV 모드로의 핸드오프의 사용을 특정한다. 이들 비트에 대한 0 및 5 내지 7 의 값의 사용은 추후 사용용으로 예비된다.

O. 순방향 오디오 채널 인에이블 패킷의 경우

오디오 채널 인에이블 마스크 필드 (1 바이트) 는 오디오 채널이 클라이언트에서 인에이블될 것을 나타내는 일련의 플래그들을 포함한다. 1 로 설정된 비트는대응하는 채널을 인에이블시키며, 0 으로 설정된 비트는 대응하는 채널 비트 0 내지 5 로 하여금, 각각, 좌측 전방, 우측 전방, 좌측 후방, 우측 후방, 전방 중심, 및 서브-우퍼 채널을 나타내는 채널 0 내지 5 를 지정할 수 없게 한다. 비트 6 및 7 은 추후 사용용으로 예비되며, 평균 시간에 0 으로 설정된다.

P. 역방향 오디오 샘플 레이트 패킷의 경우

오디오 샘플 레이트 필드 (1 바이트) 는 디지털 오디오 샘플 레이트를 특정한다. 이 필드에 대한 값들은 상이한 레이트들에 할당되며, 0, 1, 2, 3, 4, 5, 6, 7, 및 8 의 값은, 각각, 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, 22,050, 및 44,100 SPS (samples per second) 를 지정하는데 사용되며, 원할 경우, 비트 9 내지 254 값은 또 다른 레이트로 사용하기 위해 예비되며, 일반적으로, '0' 으로 설정된다. 255 의 값은 역방향 링크 오디오 스트림을 디스에이블시키는데 사용된다.

샘플 포맷 필드 (1 바이트) 은 디지털 오디오 샘플들의 포맷을 특정한다. 비트 [1:0] 이 0 일 경우, 디지털 오디오 샘플들은 선형 포맷이며, 그 값들이 1 일 경우, 디지털 오디오 샘플들은 μ-법칙 (μ-law) 포맷이며, 그 값들이 2 일 경우, 디지털 오디오 샘플들은 A-법칙 (A-law) 포맷이다. 원할 경우, 비트 [7:2] 는 오디오 포맷들을 지정하는데 또 다른 사용을 위해 예비되며, 일반적으로, '0' 으로 설정된다.

Q. 디지털 콘텐츠 보호 오버헤드 패킷의 경우

콘텐츠 보호 타입 필드 (1 바이트) 는 사용되는 디지털 콘텐츠 보호 방법을특정한다. 값 0 은 디지털 송신 콘텐츠 보호 (DTCP) 를 나타내지만, 값 1 은 하이-대역폭 디지털 콘텐츠 시스템 (HDCP) 를 나타낸다. 일반적으로, 2 내지 255 의 범위 값은 특정되지는 않지만, 원할 경우, 또 다른 보호 방식으로 사용하기 위하여 예비된다. 콘텐츠 보호 오버헤드 메시지 필드는 호스트와 클라이언트 사이에 송신되는 콘텐츠 보호 메시지들을 포함하는 가변 길이 필드이다.

R. 투명 컬러 인에이블 패킷의 경우

투명 컬러 인에이블 필드 (1 바이트) 는 투명 컬러 모드가 인에이블 또는 디스에이블될 경우를 특정한다. 만약 비트 0 이 0 이면, 투명 컬러 모드는 디스에이블되며, 만약 비트 0 이 1 이면, 투명 컬러 모드가 인에이블되고 투명 컬러는 다음 2 개의 파라미터에 의해 특정된다. 이 바이트의 비트 1 내지 7 은 추후 사용용으로 예비되며, 0 으로 설정된다.

비디오 데이터 포맷 디스크립터 필드 (2 바이트) 는 픽셀 영역 충만 값의 포맷을 특정한다. 도 11 은 비디오 데이터 포맷 디스크립터가 코딩되는 방법을 나타낸 것이다. 일반적으로, 그 포맷은 비디오 스트림 패킷의 동일한 필드와 같다.

픽셀 영역 충만 값 필드는 상술된 윈도우에 충만될 픽셀 값을 위해 할당된 4 바이트를 사용한다. 이 픽셀의 포맷은 비디오 데이터 포맷 디스크립터 필드에 특정된다.

S. 라운드 트립 지연 측정 패킷의 경우

파라미터 CRC 필드 (2 바이트) 는 패킷 길이로부터 패킷 타입까지의 모든 바이트의 16-비트 CRC 를 포함한다. 만약 이 CRC 가 체크를 실패하면, 전체 패킷은폐기된다.

올 제로 필드 (1 바이트) 는 모든 MDDI_Data 신호들이 제 1 가드 타임 (guard time) 주기 동안 라인 드라이버 (line drivers) 를 디스에이블시키기 전에 0 상태에 있는 것을 보증하기 위하여 0 을 포함한다.

가드 타임 1 필드 (8 바이트) 는 클라이언트 (디스플레이) 의 라인 드라이버들이 인에이블하기 전에, 호스트의 MDDI_Data 라인 드라이버를 디스에이블시키는데 사용된다. 호스트는 가드 타임 1 의 비트 0 동안에 자신의 MDDI_Data 라인 드라이버를 디스에이블시키고, 디스플레이는 가드 타임 1 의 마지막 비트 직후에 자신의 라인 드라이버를 인에이블시킨다.

측정 주기 필드는 디스플레이로 하여금 순방향 링크를 통하여 사용되는 하프 (half) 데이터 레이트에서 0xff, 0xff, 0x0 으로 응답하도록 하는데 사용되는 512 바이트의 윈도우이다. 이 레이트는 1 인 역방향 라인 레이트 제수에 대응한다. 디스플레이는 측정 주기의 시작에서 즉시 이 응답값을 반환한다. 이 응답은 호스트에서의 측정 주기의 제 1 비트의 시작 직후에 호스트에서 그 링크의 라운드 트립 지연을 정확하게 수신받는다. 디스플레이에서의 MDDI_Data 라인 드라이버는 디스플레이로부터 0xff, 0xff, 0x00 응답 직전 및 직후에 디스에이블된다.

가드 타임 2 필드 (8 바이트) 의 값은 호스트의 라인 드라이버들이 인에이블하기 전에, 클라이언트 MDDI_Data 라인 드라이버를 디스에이블시킨다. 가드 타임 2 는 언제나 존재하지만, 라운드 트립 지연이 측정 주기에서 측정될 수 있는 최대량일 때에만 요구된다. 클라이언트는 가드 타임 2 의 비트 0 동안에 자신의 라인 드라이버를 디스에이블시키고, 호스트는 가드 타임 2 의 마지막 비트 직후에 자신의 라인 드라이버를 인에이블시킨다.

드라이버 리-인에이블 필드 (1 바이트) 는 0 으로 송신되어, 모든 MDDI_Data 신호들이 그 다음 패킷의 패킷 길이 필드 전에 리-인에이블될 것을 보증한다.

T. 순방향 링크 스큐 캘리브레이션 패킷의 경우

파라미터 CRC 필드 (2 바이트) 는 패킷 길이로부터 패킷 타입까지의 모든 바이트의 16-비트 CRC 를 포함한다. 만약 이 CRC 가 체크를 실패하면, 전체 패킷은 폐기된다.

캘리브레이션 데이터 시퀀스 필드는 MDDI_Data 신호를 매 데이터 주기 마다 토글시키는 512 바이트 데이터 시퀀스를 포함한다. 캘리브레이션 데이터 시퀀스의 프로세싱 동안, MDDI 호스트 제어기는 모든 MDDI_Data 신호들을 스트로브 신호와 동일하게 설정한다. 디스플레이 클럭 복구 회로는 MDDI_Stb xor MDDI_Data0 보다는 MDDI_Stb 만을 사용하여, 캘리브레이션 데이터 시퀀스 필드가 클라이언트 디스플레이에 의해 수신되는 동안 데이터 클럭을 복구한다. 일반적으로, 캘리브레이션 데이터 시퀀스 필드의 시작에서 MDDI_Stb 신호의 정확한 위상에 따라, 캘리브레이션 데이터 시퀀스는 이 패킷이 송신될 때에 사용되는 인터페이스 타입에 의존하는 다음 중에 하나이다.

타입-I 및 타입-II 인터페이스에 대한 가능한 MDDI_Data 및 MDDI_Stb 파형의 일 예는, 각각, 도 62 에 도시되어 있다.

XVI. 결어

본 발명의 다양한 실시형태들이 상술되어 있지만, 그것들은 예로써 제공되는 것이지 한정하려는 것은 아님을 이해해야 한다. 따라서, 본 발명의 넓이 및 범위는 상술한 예시적인 실시형태들에 한하지 않으며, 다음의 청구 범위 및 그 균등물에 따라서만 한정되어야만 한다.

Claims (107)

1. 통신 경로를 통해 호스트 디바이스와 클라이언트 디바이스의 사이에서 하이 레이트로 디지털 프리젠테이션 데이터를 전송하는 디지털 데이터 인터페이스로서,

   상기 통신 경로를 통해 호스트와 클라이언트의 사이에서 디지털 제어와 프리젠테이션 데이터의 미리 선택된 세트를 통신하는 통신 프로토콜을 형성하도록 함께 링크된 복수의 패킷 구조체; 및

   상기 통신 경로를 통해 상기 클라이언트에 결합된 상기 호스트 디바이스에 상주하며, 상기 통신 프로토콜을 형성하는 패킷들을 생성, 전송 및 수신하고, 또한 디지털 프리젠테이션 데이터를 하나 이상 타입의 데이터 패킷으로 형성하도록 구성되어 있는 하나 이상의 링크 제어기를 구비하는, 디지털 데이터 인터페이스.
2. 제 1 항에 있어서,

   상기 호스트와 클라이언트 사이에서 통신되고 미리 정의된 고정 길이를 갖는 매체 프레임들내에 함께 그룹화된 패킷들을 더 구비하며, 소정 개수의 상기 패킷들은 상이한 가변 길이를 갖는, 디지털 데이터 인터페이스.
3. 제 1 항에 있어서,

   상기 호스트로부터 패킷들의 전송의 개시부에 위치되는 서브-프레임 헤더 패킷(Sub-frame Header Packet)을 더 구비하는, 디지털 데이터 인터페이스.
4. 제 1 항에 있어서,

   상기 통신 링크를 통한 상기 호스트와 클라이언트 사이의 정보의 양-방향 전송부를 더 구비하는, 디지털 데이터 인터페이스.
5. 제 1 항에 있어서,

   상기 링크 제어기는, 호스트 링크 제어기가고, 상기 통신 경로를 통해 상기 호스트에 결합된 상기 클라이언트 디바이스에 상주하며, 상기 통신 프로토콜을 형성하는 패킷들을 생성, 전송 및 수신하고, 또한 디지털 프리젠테이션 데이터를 하나 이상 유형의 데이터 패킷으로 형성하도록 구성되어 있는 하나 이상의 링크 제어기를 더 구비하는 디지털 데이터 인터페이스.
6. 제 5 항에 있어서,

   상기 호스트 링크 제어기는 하나 이상의 차동 라인 드라이버를 구비하고, 상기 클라이언트 링크 제어기는 상기 통신 경로에 결합된 하나 이상의 차동 라인 수신기를 구비하는, 디지털 데이터 인터페이스.
7. 제 1 항에 있어서,

   클라이언트 사용자에 대한 프리젠테이션용으로 순방향 링크를 통해 상기 호스트로부터 상기 클라이언트로 데이터를 전송하는 비디오 타입 데이터용 하나 이상의 비디오 스트림 패킷(Video Stream Packet) 및 오디오 타입 데이터용 오디오 스트림 패킷(Audio Stream Packet)들을 더 구비하는, 디지털 데이터 인터페이스.
8. 제 1 항에 있어서,

   데이터를 상기 호스트로 전송하는 상기 클라이언트용 하나 이상의 역방향 링크 캡슐화 패킷(Reverse Link Encapsulation Packet)을 더 구비하는, 디지털 데이터 인터페이스.
9. 제 1 항에 있어서,

   호스트 링크 제어기는, 상기 클라이언트 디바이스가 상기 인터페이스를 통해 수용할 수 있는 데이터의 타입 및 데이터 레이트를 결정하도록 클라이언트 디바이스로부터 디스플레이 능력 정보를 요청하는, 디지털 데이터 인터페이스.
10. 제 1 항에 있어서,

    상기 호스트 디바이스는 무선 통신장치를 구비하는, 디지털 데이터 인터페이스.
11. 제 1 항에 있어서,

    상기 호스트 디바이스는 무선 모뎀이 내장된 휴대형 컴퓨터를 구비하는, 디지털 데이터 인터페이스.
12. 제 1 항에 있어서,

    상기 호스트 디바이스는 중앙 프로세서를 구비하는, 디지털 데이터 인터페이스.
13. 제 1 항에 있어서,

    상기 호스트 디바이스는 개인 생산성 디바이스(personal productivity device)로서 구성되어 있는, 디지털 데이터 인터페이스.
14. 제 1 항에 있어서,

    상기 호스트 디바이스는 개인 오락 디바이스로서 구성되어 있는, 디지털 데이터 인터페이스.
15. 제 1 항에 있어서,

    상기 클라이언트 디바이는 휴대형 비디오 디스플레이를 구비하는, 디지털 데이터 인터페이스.
16. 제 1 항에 있어서,

    상기 클라이언트 디바이스는 휴대형 비디오 프리젠테이션 시스템을 구비하는, 디지털 데이터 인터페이스.
17. 제 16 항에 있어서,

    상기 휴대형 비디오 프리젠테이션 시스템은 DVD 플레이어를 구비하는, 디지털 데이터 인터페이스.
18. 제 16 항에 있어서,

    상기 휴대형 비디오 프레젠테이션 시스템은 게임 플레이어 디바이스를 구비하는, 디지털 데이터 인터페이스.
19. 제 1 항에 있어서,

    상기 클라이언트 디바이스는 휴대형 오디오 프리젠테이션 시스템을 구비하는, 디지털 데이터 인터페이스.
20. 제 2 항에 있어서,

    복수의 전송 모드로서, 각 모드가 주어진 시간에 걸쳐 병렬로 상이한 최대 개수의 데이터 비트를 전송할 수 있고, 동시에 각 모드는 상기 호스트와 클라이언트 링크 드라이버 사이의 협상에 의해 선택가능한, 상기 복수의 전송 모드를 더 구비하며,

    상기 전송 모드들은 데이터의 전송시 상기 모드들 사이에서 동적으로 조정가능한, 디지털 데이터 인터페이스.
21. 제 1 항에 있어서,

    컬러 맵(Color Map), 비트 블럭 트랜스퍼(Bit Block Transfer), 비트맵 에어리어 필(Bitmap Area Fill), 비트맵 패턴 필(Bitmap Pattern Fill) 및 투명 컬러 인에이블(Transparent Color Enable) 타입 패킷들의 그룹으로부터 선택된 비디오 정보를 전송하는데 사용할 수 있는 복수의 패킷을 더 구비하는, 디지털 데이터 인터페이스.
22. 제 1 항에 있어서,

    데이터를 갖지 않는 순방향 링크 전송의 기간을 점유하도록 상기 호스트에 의해 생성되는 필러 타입 패킷들(Filler type packets)을 더 구비하는, 디지털 데이터 인터페이스.
23. 제 1 항에 있어서,

    인터페이스-사용자 정의 데이터를 전송하는 사용자 정의 스트림 타입 패킷들(User-Defined Stream type packets)을 더 구비하는, 디지털 데이터 인터페이스.
24. 제 1 항에 있어서,

    상기 통신 경로를 통한 양-방향으로의 데이터의 전송을 종료시키는 상기 호스트에 의한 상기 클라이언트로의 전송용 링크 셧다운 타입 패킷(Link Shutdown type packet)을 더 구비하는, 디지털 데이터 인터페이스.
25. 제 1 항에 있어서,

    상기 호스트를 휴면 상태로부터 깨우는 상기 클라이언트용 수단을 더 구비하는, 디지털 데이터 인터페이스.
26. 사용자에 대한 프리젠테이션용으로 통신 경로를 통해 호스트 디바이스와 클라이언트 디바이스의 사이에서 하이 레이트로 디지털 데이터를 전송하는 방법으로서,

    하나 이상의 복수의 미리-정의된 패킷 구조체들을 생성하고, 미리-정의된 통신 프로토콜을 형성하도록 상기 패킷 구조체들을 함께 링크하는 단계;

    상기 통신 프로토콜을 사용하여 상기 통신 경로를 통해 상기 호스트와 상기 클라이언트 디바이스들의 사이에서 디지털 제어와 프리젠테이션 데이터의 미리 선택된 세트를 통신하는 단계;

    상기 통신 경로를 통해 상기 호스트 디바이스에 상주하는 하나 이상의 호스트 링크 제어기를 상기 클라이언트 디바이스에 결합하는 단계로서, 상기 호스트 링크 제어기가 상기 통신 프로토콜을 형성하는 패킷들을 생성, 전송 및 수신하고, 또한 디지털 프리젠테이션 데이터를 하나 이상 타입의 데이터 패킷으로 형성하도록 구성되어 있는, 상기 결합 단계; 및

    상기 링크 제어기를 사용하여 상기 통신 경로를 통해 패킷들의 형태로 데이터를 전송하는 단계를 구비하는, 디지털 데이터의 전송방법.
27. 제 26 항에 있어서,

    상기 호스트와 클라이언트 사이의 통신용 매체 프레임들내에 상기 패킷들을 함께 그룹화하는 단계를 더 구비하며,

    상기 매체 프레임들은 미리 정의된 고정 길이를 갖고, 소정 개수의 상기 패킷들은 상이한 가변 길이를 갖는, 디지털 데이터의 전송방법.
28. 제 26 항에 있어서,

    서브-프레임 헤더 타입 패킷(Sub-frame Header type packet)에 의해 상기 호스트로부터의 패킷들의 전송을 개시하는 단계를 더 구비하는, 디지털 데이터의 전송방법.
29. 제 26 항에 있어서,

    상기 통신 링크를 통해 양-방향으로 상기 호스트와 클라이언트의 사이에서 정보를 전송하는 단계를 더 구비하는, 디지털 데이터의 전송방법.
30. 제 26 항에 있어서,

    상기 통신 경로를 통해 상기 호스트 디바이스에 결합되는 상기 클라이언트디바이스에 상주하며, 상기 통신 프로토콜을 형성하는 패킷들을 생성, 전송 및 수신하고, 또한 디지털 프리젠테이션 데이터를 하나 이상 타입의 데이터 패킷으로 형성하도록 구성되어 있는 하나 이상의 클라이언트 링크 제어기를 더 구비하는, 디지털 데이터의 전송방법.
31. 제 30 항에 있어서,

    상기 호스트 링크 제어기는 하나 이상의 차동 라인 드라이버를 구비하고, 상기 클라이언트 링크 제어기는 상기 통신 경로에 결합되는 하나 이상의 차동 라인 수신기를 구비하는, 디지털 데이터의 전송방법.
32. 제 26 항에 있어서,

    비디오 타입 데이터용 하나 이상의 비디오 스트림 타입 패킷(Video Stream type Packet) 및 오디오 타입 데이터용 오디오 스트림 타입 패킷(Audio Stream type Packet)들을 사용하여 클라이언트 사용자에 대한 프리젠테이션용으로 상기 호스트로부터 상기 클라이언트로 데이터를 전송하는 단계를 더 구비하는, 디지털 데이터의 전송방법.
33. 제 26 항에 있어서,

    하나 이상의 역방향 링크 캡슐화 타입 패킷(Reverse Link Encapsulation type packet)을 사용하여 상기 클라이언트로부터 상기 호스트로 데이터를 전송하는단계를 더 구비하는, 디지털 데이터의 전송방법.
34. 제 26 항에 있어서,

    상기 클라이언트가 상기 인터페이스를 통해 수용할 수 있는 데이터의 타입 및 데이터 레이트를 결정하도록 호스트 링크 제어기에 의해 클라이언트로부터 디스플레이 능력 정보를 요청하는 단계를 더 구비하는, 디지털 데이터의 전송방법.
35. 제 34 항에 있어서,

    하나 이상의 디스플레이 능력 타입 패킷(Display Capability type packet)을 사용하여 클라이언트 링크 제어기로부터 상기 호스트 링크 제어기로 디스플레이 또는 프리젠테이션 능력을 통신하는 단계를 더 구비하는, 디지털 데이터의 전송방법.
36. 제 26 항에 있어서,

    상기 통신 경로는 일련의 4개 이상의 도전체와 실드를 갖는 케이블을 구비하는, 디지털 데이터의 전송방법.
37. 제 26 항에 있어서,

    상기 통신 경로의 일부분으로서 상기 링크 제어기 각각에 의해 USB 데이터 인터페이스를 동작시키는 단계를 더 구비하는, 디지털 데이터의 전송방법.
38. 제 26 항에 있어서,

    상기 호스트는 무선 통신장치를 구비하는, 디지털 데이터의 전송방법.
39. 제 26 항에 있어서,

    상기 호스트는 무선 모뎀이 내장된 휴대형 컴퓨터를 구비하는, 디지털 데이터의 전송방법.
40. 제 26 항에 있어서,

    상기 클라이언트 디바이스는 휴대형 비디오 디스플레이를 구비하는, 디지털 데이터의 전송방법.
41. 제 40 항에 있어서,

    상기 휴대형 비디오 디스플레이는 마이크로 디스플레이 디바이스를 구비하는, 디지털 데이터의 전송방법.
42. 제 26 항에 있어서,

    상기 클라이언트 디바이스는 휴대형 오디오 프리젠테이션 시스템을 구비하는, 디지털 데이터의 전송방법.
43. 제 26 항에 있어서,

    상기 호스트에서 상기 클라이언트 디바이스로의 전송 대상인 멀티매체 데이터를 저장하는 단계를 더 구비하는, 디지털 데이터의 전송방법.
44. 제 26 항에 있어서,

    상기 패킷 각각은, 패킷 길이 필드, 하나 이상의 패킷 데이터 필드 및 주기적 용장 체크 필드를 구비하는, 디지털 데이터의 전송방법.
45. 제 27 항에 있어서,

    상기 호스트와 클라이언트 링크 드라이버의 사이에서 각 방향으로 복수의 전송 모드 중 하나의 전송 모드의 사용을 협상하는 단계로서, 각 전송 모드는 주어진 시간에 거쳐 병렬로 상이한 최대 개수의 데이터 비트를 전송할 수 있는, 상기 협상 단계; 및

    데이터의 전송시 상기 전송 모드들 사이에서 동적으로 조정하는 단계를 더 구비하는, 디지털 데이터의 전송방법.
46. 제 26 항에 있어서,

    컬러 맵(Color Map), 비트 블럭 트랜스퍼(Bit Block Transfer), 비트맵 에어리어 필(Bitmap Area Fill), 비트맵 패턴 필(Bitmap Pattern Fill) 및 투명 컬러 인에이블(Transparent Color Enable) 타입 패킷들의 그룹으로부터 선택된 비디오 정보를 전송하는데 하나 이상의 복수의 패킷을 사용하는 단계를 더 구비하는, 디지털 데이터의 전송방법.
47. 제 26 항에 있어서,

    데이터를 갖지 않는 순방향 링크 전송의 기간을 점유하도록 상기 호스트에 의해 필러 타입 패킷들(Filler type packets)을 생성하는 단계를 더 구비하는, 디지털 데이터의 전송방법.
48. 제 26 항에 있어서,

    사용자 정의 스트림 타입 패킷들(User-Defined Stream type packets)을 사용하여 인터페이스-사용자 정의 데이터를 전송하는 단계를 더 구비하는, 디지털 데이터의 전송방법.
49. 제 26 항에 있어서,

    상기 호스트에 의한 상기 클라이언트로의 전송용 링크 셧다운 타입 패킷(Link Shutdown type packet)을 사용하여 상기 통신 경로를 통한 양 방향으로의 데이터의 전송을 종료하는 단계를 더 구비하는, 디지털 데이터의 전송방법.
50. 제 26 항에 있어서,

    상기 클라이언트와의 통신에 의해 상기 호스트를 휴면 상태로부터 깨우는 단계를 더 구비하는, 디지털 데이터의 전송방법.
51. 사용자에 대한 프리젠테이션용으로 통신 경로를 통해 호스트 디바이스와 클라이언트 디바이스와의 사이에서 하이 레이트로 디지털 데이터를 전송하는 장치로서,

    상기 호스트 디바이스에 배치된 하나 이상의 호스트 링크 제어기로서, 하나 이상의 복수의 미리 정의된 패킷 구조체를 생성하고 미리 정의된 통신 프로토콜을 형성하도록 패킷 구조체들을 함께 링크하고, 상기 통신 프로토콜을 사용하여 상기 통신 경로를 통해 상기 호스트와 상기 클라이언트 디바이스들 사이에서 디지털 제어와 프리젠테이션 데이터의 미리 선택된 세트를 통신하는 상기 하나 이상의 호스크 링크 제어기; 및

    상기 클라이언트 디바이스에 배치되고 상기 통신 경로를 통해 상기 호스트 링크 제어기에 결합된 하나 이상의 클라이언트 제어기를 구비하고,

    각각의 링크 제어기는 상기 통신 프로토콜을 형성하는 패킷들을 생성, 전송 및 수신하고, 또한 디지털 프리젠테이션 데이터를 하나 이상 타입의 데이터 패킷으로 형성하도록 구성되어 있는, 디지털 데이터의 전송장치.
52. 제 51 항에 있어서,

    상기 호스트 제어기는 상태 기계(state machine)을 구비하는, 디지털 데이터의 전송장치.
53. 제 51 항에 있어서,

    상기 호스트 제어기는 범용 신호 프로세서를 구비하는, 디지털 데이터의 전송장치.
54. 제 51 항에 있어서,

    상기 패킷들은 상기 호스트와 클라이언트 사이의 통신을 위해 매체 플레임들에 함께 그룹화되어 있고, 상기 매체 프레임들은 미리 정의된 고정 길이를 갖고 소정 개수의 상기 패킷들은 상이한 가변 길이를 갖는, 디지털 데이터의 전송장치.
55. 제 51 항에 있어서,

    상기 호스트로부터 패킷들의 전송의 개시부에 서브 프레임 헤더 타입 패킷(Sub-frame Header type packet)을 더 구비하는, 디지털 데이터의 전송장치.
56. 제 51 항에 있어서,

    상기 링크 제어기는 상기 통신 링크를 통해 양-방향으로 상기 호스트와 클라이언트 디바이스들 사이에서 정보를 전송하도록 구성되어 있는, 디지털 데이터의 전송장치.
57. 제 51 항에 있어서,

    상기 클라이언트 제어기는 상기 클라이언트 디바이스에 결합된 클라이언트수신기를 구비하는, 디지털 데이터의 전송장치.
58. 제 57 항에 있어서,

    상기 호스트 제어기는 하나 이상의 차동 라인 드라이버를 구비하고, 상기 클라이언트 수신기는 상기 통신 경로에 결합된 하나 이상의 차동 라인 수신기를 구비하는, 디지털 데이터의 전송장치.
59. 제 51 항에 있어서,

    클라이언트 사용자에 대한 프리젠테이션용으로 상기 호스트로부터 상기 클라이언트로 데이터를 전송할 때 비디오 타입 데이터용 비디오 스트림 타입 패킷들(Video Stream type packets) 및 오디오 타입용 오디오 스트림 타입 패킷들(Audio Stream type packets)을 더 구비하는, 디지털 데이터의 전송장치.
60. 제 51 항에 있어서,

    상기 클라이언트로부터 상기 호스트로 데이터를 전송하기 위한 하나이상의 역방향 링크 캡슐 타입 패킷을 더 구비하는, 디지털데이터 전송장치.
61. 제 51 항에 있어서,

    상기 호스트 링크 제어기는, 상기 클라이언트가 상기 인터페이스를 통해 제공할 수 있는 데이터 타입과 데이터 레이터를 결정할 수 있도록, 클라이언트로부터디스플레이 능력 정보를 요청하도록 구성된, 디지털 데이터 전송장치.
62. 제 61 항에 있어서,

    클라이언트 링크 제어기로부터 상기 호스트 링크 제어기로 디스플레이 또는 프리젠테이션 능력을 통신하기 위한 하나이상의 디스플레이 능력 타입 패킷을 더 구비하는, 디지털 데이터 전송장치.
63. 제 51 항에 있어서,

    상기 통신 경로는 한 시리즈로된 4개이상의 컨덕터와 하나의 실드 (shield) 를 가지는 케이블을 구비하는, 디지털 데이터 전송장치.
64. 제 63 항에 있어서,

    상기 케이블은 6개의 컨덕터와 하나의 실드를 구비하는, 디지털 데이터 전송장치.
65. 제 63 항에 있어서,

    상기 케이블은 8개의 컨덕터와 하나의 실드를 구비하는, 디지털 데이터 전송장치.
66. 제 63 항에 있어서,

    상기 통신경로는 4개의 컨덕터, USB타입 인터페이스, 및 실드로 된 케이블을 구비하는, 디지털 데이터 전송장치.
67. 제 63 항에 있어서,

    상기 케이블 컨덕터들은,

    길이 천 피트당 대략 110 옴 (ohms) 의 저항, 대략 0.66c 의 전파속도, 대략 8.0 나노초 (nanoseconds) 미만의 최대 케이블 통과 지연을 갖는 다중 스트랜드 와이어, 및

    실드를 각각 구비하는, 디지털 데이터 전송장치.
68. 제 51 항에 있어서,

    상기 호스트 디바이스는 무선 통신장치를 구비하는, 디지털 데이터 전송장치.
69. 제 51 항에 있어서,

    상기 호스트 디바이스는 무선 모뎀을 내장한 휴대형 컴퓨터를 구비하는, 디지털 데이터 전송장치.
70. 제 51 항에 있어서,

    상기 클라이언트 디바이스는 휴대형 비디오 디스플레이를 구비하는, 디지털데이터 전송장치.
71. 제 70 항에 있어서,

    상기 휴대형 비디오 디스플레이는 마이크로-디스플레이 디바이스를 구비하는, 디지털 데이터 전송장치.
72. 제 51 항에 있어서,

    상기 클라이언트 디바이스는 휴대형 오디오 프리젠테이션 시스템을 구비하는, 디지털 데이터 전송장치.
73. 제 51 항에 있어서,

    상기 호스트에 의해 상기 클라이언트로 전송되어질 멀티매체 데이터를 저장하기 위한 데이터 스토리지를 더 구비하는, 디지털 데이터 전송장치.
74. 제 51 항에 있어서,

    상기 패킷들은 각각, 패킷길이 필드, 하나이상의 패킷 데이터 필드, 및 주기적 용장 체크 (CRC) 필드를 구비하는, 디지털 데이터 전송장치.
75. 제 51 항에 있어서,

    상기 호스트 및 클라이언트 링크 제어기는 각 방향마다 복수의 전송모드들중한 전송모드를 이용하되, 각각이 소정기간 동안에 서로 다른 최대 데이터 비트수의 전송이 병렬로 가능하고 그리고 데이터 전송 동안에 상기 전송모드들간에 동적으로 조정가능하도록 구성되는, 디지털 데이터 전송장치.
76. 제 51 항에 있어서,

    칼라 맵(Color Map), 비트 블럭 전송(Bit Block Transfer), 비트맵 에리어 필(Bitmap Area Fill), 비트맵 패턴 필(Bitmap Pattern Fill), 및 투명 칼라 인에이블 타입 (transparent Color Enable Type) 패킷들로된 그룹중에서 선택한 비디오 정보를 전송하기 위한 하나이상의 복수개 패킷을 더 구비하는, 디지털 데이터 전송장치.
77. 제 51 항에 있어서,

    데이터를 갖지 않는 순방향 링크 전송의 기간을 점유하도록 상기 호스트에 의해 전송되는 필러 타입 (Filler Type) 패킷을 더 구비하는, 디지털 데이터 전송장치.
78. 제 51 항에 있어서,

    데이터를 상기 클라이언트 디바이스와 연계된 사용자 입력디바이스로 전송하거나 전송받기 위한 키보드 데이터 및 포인팅 디바이스 데이터타입 패킷을 더 구비하는, 디지털 데이터 전송장치.
79. 제 51 항에 있어서,

    상기 호스트 제어기는 상기 통신경로를 통한 어느 방향으로의 데이터의 전송을 종료시키기 위해, 링크 셧다운 타입 (Link Shutdown Type) 패킷을 상기 클라이언트 수단으로 전송하도록 구성된, 디지털 데이터 전송장치.
80. 전자 시스템에서, 사용자에게의 프리젠테이션을 위해 통신경로를 통해 호스트 디바이스와 클라이언트 디바이스간에 하이 레이트로 디지탈 데이터를 전송하는데 사용하기 위한, 컴퓨터 프로그램 제품으로서,

    컴퓨터 상에서 애플리케이션 프로그램을 실행시키기 위하여, 컴퓨터 판독가능한 프로그램 코드 수단이 내장된 컴퓨터 사용가능한 매체를 구비하되,

    상기 컴퓨터 판독가능한 프로그램 코드 수단은,

    컴퓨터 시스템으로 하여금, 하나이상의 복수개 소정 패킷 구조체를 생성하고 그들을 함께 링크하여(link) 소정의 컴퓨터 통신 프로토콜을 형성하도록 하는 컴퓨터 판독가능한 제1 프로그램 코드 수단;

    컴퓨터 시스템으로 하여금, 상기 통신 프로토콜을 이용하여 상기 통신경로상에서 상기 호스트와 상기 클라이언트간에 미리 선택한 디지털 제어 및 프리젠테이션 데이터 세트를 통신하도록 하는 컴퓨터 판독가능한 제2 프로그램 코드 수단;

    컴퓨터 시스템으로 하여금, 상기 호스트 디바이스에 내장된 하나이상의 호스트 링크 제어기를 상기 클라이언트 디바이스에 내장된 하나이상의 클라이언트 제어기에 연결시켜, 디지털 프리젠테이션 데이터를 하나이상의 데이터 타입 패킷으로 형성하도록 하는 컴퓨터 판독가능한 제3 프로그램 코드 수단으로서, 상기 링크 제어기들은 상기 통신 프로토콜을 형성하는 패킷들을 생성, 전송 및 수신하도록 구성된, 컴퓨터 판독가능한 제3 프로그램 코드 수단; 및

    컴퓨터 시스템으로 하여금, 상기 링크 제어기들을 이용하여 상기 통신경로를 통해 패킷의 형태로 데이터를 전송하도록 하는 컴퓨터 판독가능한 제4 프로그램 코드 수단을 구비하는, 컴퓨터 프로그램 제품.
81. 사용자에게의 프리젠테이션을 위해 호스트 디바이스와 클라이언트 간에 통신경로를 통해 하이 레이트로 디지털 데이터를 전송하기 위한 장치로서,

    소정의 통신 프로토콜을 생성하기 위하여, 하나이상의 복수개 소정 패킷 구조체를 생성하고 그들을 함께 링크하는 수단;

    상기 통신 프로토콜을 이용하여, 상기 통신경로를 통해 상기 호스트 디바이스와 상기 클라이언트 디바이스간에 미리 선택된 디지털 제어 및 프리젠테이션 데이터를 통신하는 수단;

    상기 통신경로를 통해 2 이상의 링크 제어기들을 연결하여, 디지털 프리젠테이션 데이터를 하나이상의 데이터 타입 패킷으로 생성하는 수단으로서, 상기 링크 제어기는 상기 호스트 및 클라이언트 마다 하나씩 있으며 각각 상기 통신 프로토콜을 형성하는 패킷을 생성, 전송 및 수신하는, 수단;

    상기 링크 제어기를 이용하여 상기 통신경로를 통해 패킷 형태로 데이터를전송하는 수단을 구비하는, 디지털 데이터 전송장치.
82. 제 81 항에 있어서,

    상기 호스트와 클라이언트간의 통신을 위해 상기 패킷들을 매체 프레임내에 함께 그룹화하는 수단을 더 구비하며, 매체 프레임은 미리 정한 고정 길이를 가지며, 미리 결정되는 상기 패킷들의 갯수가 서로 다르며 가변길이를 갖는, 디지털 데이터 전송장치.
83. 제 81 항에 있어서,

    상기 호스트로부터의 패킷 전송을 서브-프레임 헤더 타입 (Sub-frame Header Type) 패킷으로 개시하는 수단을 더 구비하는, 디지털 데이터 전송장치.
84. 제 81 항에 있어서,

    상기 통신 링크를 통해 상기 호스트와 클라이언트간에 양방향으로 정보를 전송하는 수단을 더 구비하는, 디지털 데이터 전송장치.
85. 제 81 항에 있어서,

    하나의 링크 제어기는 상기 호스트 디바이스에 연결된 호스트 제어기를 구비하고, 제2 링크 제어기는 상기 클라이언트 디바이스에 연결된 클라이언트 수신기를 구비하는, 디지털 데이터 전송장치.
86. 제 85 항에 있어서,

    상기 호스트 제어기는 하나이상의 차동 (differential) 라인 드라이버를 구비하며,

    상기 클라이언트 수신기는 상기 통신경로에 연결된 하나이상의 차동 라인 수신기를 구비하는, 디지털 데이터 전송장치.
87. 제 81 항에 있어서,

    하나이상의 비디오 타입 데이터용의 비디오 스트림 타입 패킷, 및 오디오 타입 데이터용의 오디오 스트림 타입 패킷을 이용하여, 클라이언트 사용자에게의 프리젠테이션을 위해 상기 호스트로부터 상기 클라이언트로 데이터를 전송하기 위한 수단을 더 구비하는, 디지털 데이터 전송장치.
88. 제 81 항에 있어서,

    하나이상의 역방향 링크 캡슐 타입 패킷을 이용하여 상기 클라이언트로부터 상기 호스트로 데이터를 전송하기 위한 수단을 더 구비하는, 디지털 데이터 전송장치.
89. 제 81 항에 있어서,

    호스트 링크 제어기에 의해, 상기 클라이언트가 상기 인터페이스를 통해 제공할 수 있는 데이터 타입과 데이터 레이터를 결정할 수 있도록, 클라이언트로부터 디스플레이 능력 정보를 요청하기 위한 수단을 더 구비하는, 디지털 데이터 전송장치.
90. 제 89 항에 있어서,

    하나이상의 디스플레이 능력 타입 패킷을 이용하여, 클라이언트 링크 제어기로부터 상기 호스트 링크 제어기로 디스플레이 또는 프리젠테이션 능력을 통신하기 위한 수단을 더 구비하는, 디지털 데이터 전송장치.
91. 제 81 항에 있어서,

    상기 통신경로는 한 시리즈로된 4개이상의 컨덕터와 하나의 실드 (shield) 를 가지는 케이블을 구비하는, 디지털 데이터 전송장치.
92. 제 81 항에 있어서,

    상기 링크 제어기 각각에 의해 상기 통신경로의 일부로서 USB 데이터 인터페이스를 구동하기 위한 수단을 더 구비하는, 디지털 데이터 전송장치.
93. 제 81 항에 있어서,

    상기 호스트는 무선통신장치를 구비하는, 디지털 데이터 전송장치.
94. 제 81 항에 있어서,

    상기 호스트는 무선모뎀을 내장한 휴대형 컴퓨터를 구비하는, 디지털 데이터 전송장치.
95. 제 81 항에 있어서,

    상기 클라이언트 디바이스는 휴대형 비디오 디스플레이를 구비하는, 디지털 데이터 전송장치.
96. 제 95 항에 있어서,

    상기 휴대형 비디오 디스플레이는 마이크로-디스플레이 디바이스를 구비하는, 디지털 데이터 전송장치.
97. 제 81 항에 있어서,

    상기 클라이언트 디바이스는 휴대형 오디오 프리젠테이션 시스템을 구비하는, 디지털 데이터 전송장치.
98. 제 81 항에 있어서,

    상기 호스트 측에서 상기 클라이언트로 전송할 멀티매체 데이터를 저장하기 위한 수단을 더 구비하는, 디지털 데이터 전송장치.
99. 제 81 항에 있어서,

    상기 패킷들은 각각 패킷 길이 필드, 하나이상의 패킷 데이터 필드, 및 주기적 용장 체크 (CRC) 필드를 구비하는, 디지털 데이터 전송장치.
100. 제 82 항에 있어서,

     소정 기간 동안에 상이한 최대 데이터 비트수의 전송이 각각 가능하도록, 상기 호스트 링크 드라이버와 클라이언트 링크 드라이버간에 각 방향마다 복수의 전송모드들중 하나의 전송모드의 이용을 협상하기 위한 수단; 및

     데이터 전송 동안에 상기 전송모드들 간에 동적으로 조정하기 위한 수단을 구비하는, 디지털 데이터 전송장치.
101. 제 81 항에 있어서,

     칼라 맵(Color Map), 비트 블럭 전송(Bit Block Transfer), 비트맵 에리어 필(Bitmap Area Fill), 비트맵 패턴 필(Bitmap Pattern Fill), 및 투명 칼라 인에이블 타입 (transparent Color Enable Type) 패킷들로된 그룹중에서 선택한 비디오 정보를 하나이상의 복수개 패킷을 이용하여 전송하기 위한 수단을 더 구비하는, 디지털 데이터 전송장치.
102. 제 81 항에 있어서,

     데이터를 갖지 않는 순방향 링크 전송의 기간을 점유하기 위하여 상기 호스트에 의해 필러 타입 (Filler Type) 패킷을 생성하는 수단을 더 구비하는, 디지털 데이터 전송장치.
103. 제 81 항에 있어서,

     사용자 정의 타입 패킷을 이용하여 인터페이스-사용자 정의된 데이터를 전송하는 수단을 더 구비하는, 디지털 데이터 전송장치.
104. 제 81 항에 있어서,

     키보드 데이터 및 포인팅 디바이스 데이터타입 패킷을 이용하여, 데이터를 상기 클라이언트 디바이스와 연계된 사용자 입력디바이스로 전송하거나 전송받기 위한 수단을 더 구비하는, 디지털 데이터 전송장치.
105. 제 81 항에 있어서,

     상기 호스트에 의해 상기 클라이언트로 전송되는 링크 셧다운 타입 패킷을 이용하여, 상기 통신경로상의 어느 한 방향에서, 데이터의 전송을 종료하기 위한 수단을 더 구비하는, 디지털 데이터 전송장치.
106. 전자 시스템에서, 사용자에게의 프리젠테이션을 위해 통신경로를 통해 호스트 디바이스와 클라이언트 디바이스간에 고속으로 디지탈 데이터를 전송하는데 사용하기 위한, 프로세서로서,

     상기 프로세서는,

     하나이상의 복수개 소정 패킷 구조체를 생성하고 그들을 함께 링크하여 소정의 통신 프로토콜을 형성하고;

     디지털 프리젠테이션 데이터를 하나이상의 데이터 타입 패킷으로 형성하고,

     상기 통신 프로토콜을 이용하여, 상기 호스트와 상기 클라이언트 디바이스간에 상기 통신경로를 통해 미리 선택된 디지털 제어 및 프리젠테이션 데이터 세트를 통신하고; 그리고,

     상기 통신경로를 통해 데이터를 패킷 형태로 전송하도록 구성된, 프로세서.
107. 통신경로를 통해 호스트 디바이스와 클라이언트 디바이스간에 하이 레이트로 디지털 데이터를 전송하는 전자 시스템에서 동기화를 획득하는데 이용하기 위한 상태 기계로서,

     상기 상태기계는,

     하나이상의 비동기 프레임 상태 동기화상태(Async Frames State synchronization state), 2이상의 획득 동기 상태 동기화상태 (Acquiring Sync States synchronization state), 및 3이상의 인-싱크 상태 동기화상태 (In-Sync states synchronization states) 를 갖도록 구성되는, 상태기계.