KR100882166B1 - 고 데이터 레이트 인터페이스 장치 및 방법 - Google Patents

고 데이터 레이트 인터페이스 장치 및 방법 Download PDF

Info

Publication number
KR100882166B1
KR100882166B1 KR1020077000155A KR20077000155A KR100882166B1 KR 100882166 B1 KR100882166 B1 KR 100882166B1 KR 1020077000155 A KR1020077000155 A KR 1020077000155A KR 20077000155 A KR20077000155 A KR 20077000155A KR 100882166 B1 KR100882166 B1 KR 100882166B1
Authority
KR
South Korea
Prior art keywords
packet
client
data
host
display
Prior art date
Application number
KR1020077000155A
Other languages
English (en)
Other versions
KR20070023813A (ko
Inventor
존 제임스 앤더슨
브라이언 스틸
조지 에이 윌리
샤생크 셰크하르
Original Assignee
퀄컴 인코포레이티드
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 퀄컴 인코포레이티드 filed Critical 퀄컴 인코포레이티드
Priority to KR1020077000155A priority Critical patent/KR100882166B1/ko
Publication of KR20070023813A publication Critical patent/KR20070023813A/ko
Application granted granted Critical
Publication of KR100882166B1 publication Critical patent/KR100882166B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/64—Hybrid switching systems
    • H04L12/6418—Hybrid transport
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/75—Indicating network or usage conditions on the user display
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/64—Hybrid switching systems
    • H04L12/6418—Hybrid transport
    • H04L2012/6483—Video, e.g. MPEG
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Abstract

미리 선택된 디지털 제어의 세트 및 프리젠테이션 데이터를 통신하기 위한 통신 프로토콜을 형성하도록 함께 연결된 패킷 구조를 이용하여 통신 경로를 통해 호스트와 클라이언트 간에 디지털 데이터를 전송하기 위한 데이터 인터페이스. 통신 프로토콜을 형성하는 패킷을 발생, 송신 및 수신하고 디지털 데이터를 하나 이상의 데이터 패킷 타입으로 형성하도록 구성되고, 1 이상이 호스트 장치 내에 존재하여 통신 경로를 통해 클라이언트에 결합된 링크 제어기에 의해 신호 프로토콜이 이용된다. 본 인터페이스는 비용 효율적이고, 저 전력, 양방향인 고속 데이터 전송 메커니즘을 단거리 "직렬 (serial)" 타입 데이터 링크를 통해 제공하며, 이는, 입을 수 있는 (wearable) 마이크로 디스플레이와 같은 디스플레이 소자를 휴대용 컴퓨터 및 무선 통신 장치에 접속하는데 특히 유용한 소형 커넥터 및 박형 가요성 케이블로 구현될 수 있다.
호스트, 클라이언트, 인터페이스, 링크 제어기, 휴지, 웨이크 업

Description

고 데이터 레이트 인터페이스 장치 및 방법{HIGH DATA RATE INTERFACE APPARATUS AND METHOD}
35 U.S.C. §119 하의 우선권의 주장
본 출원은, 2004년 6월 4일에 출원되고 발명의 명칭이 "Switchable Threshold Differential Interface" 인 미국 특허 출원 번호 제 60/577,500 호 및 2004년 6월 7일 출원되고 발명의 명칭이 "Switchable Threshold Differential Interface" 인 미국 특허 출원 번호 제 60/577,793 호에 대해 우선권을 주장하며, 이 출원들은 본 양수인에게 양도되고 본 명세서에 명시적으로 참조로 통합되어 있다.
배경
분야
본 개시의 발명의 실시형태는 호스트 장치와 클라이언트 장치간에 고 데이터 레이트로 신호를 통신하거나 전송하기 위한 집적 회로 및 하나 이상의 전자 소자를 포함하는 디지털 신호 프로토콜, 프로세스, 방법 및 장치에 관한 것이다. 더 상세하게는, 본 개시는 내부 및 외부 장치 애플리케이션을 갖는 저 전력 고 데이터 레이트 전송 메커니즘을 사용하여, 최종 사용자에게 프리젠테이션 또는 디스플레이하기 위해 호스트 또는 제어기 장치로부터 클라이언트 장치로 멀티미디어 및 다른 타입의 디지털 신호를 전송하는 기술에 관한 것이다.
배경
컴퓨터, 전자 오락 관련 제품, 및 다양한 비디오 기술 (예를 들어, DVD's (Digital Versatile Disks) 및 고 선명 VCR (High Definition VCR)) 이 최근 몇 년간 급격히 발전하여, 그 장치의 최종 사용자에게, 일부 타입의 텍스트를 포함하는 경우에도 계속적으로 높은 해상도의 정지 화상, 비디오, 비디오 온 디맨드 (video-on-demand) 및 그래픽 이미지의 표현 (presentation) 을 제공한다. 이러한 발전은 다시 더 높은 해상도의 고 선명 비디오 모니터, HDTV (High Definition Television) 모니터 또는 특수 이미지 프로젝션 소자와 같은 전자 표시 장치의 사용을 요구한다. CD (Compact Disc) 형태의 사운드 재생, DVD, 서라운드 사운드, 및 관련 오디오 신호 출력을 갖는 기타 장치를 사용할 때와 같이, 이러한 시각 이미지를 고선명 또는 고품질 오디오 데이터와 결합하는 것이 더욱 현실적이고 풍부한 컨텐츠의, 즉 사용자에게 진정한 멀티미디어 경험을 창조하는데 사용된다.
또한, MP3 플레이어와 같은 고 이동성, 고 품질 사운드 시스템 및 음악 전송 메커니즘이 사용자에 대한 오디오 표현만을 위해 개발되어 왔다. 이는 현재 높거나 특출한 품질의 출력에 익숙해지고 이를 기대하는, 컴퓨터에서 텔레비젼, 그리고 전화에 이르는 상용 전자 장치의 통상의 사용자에 대한 기대의 증가를 가져왔다. 또한, 텔레비전 또는 영화 스튜디오, 및 스포츠 프랜차이즈 또는 설비와 같은 콘텐츠 제공기로부터의 이미지의 (지연되거나 실시간의) 재생을 위한 다양한 휴대용 디바이스 및 무선 수신기가 현재 제안되었다.
전자 제품이 관련된 통상의 비디오 프리젠텐이션 시나리오에서 비디오 데이 터는, 초당 1 내지 10 킬로바이트 정도의, 잘해야 느리거나 중간 정도라 할 수 있는 레이트의 종래 기술을 이용하여 전송된다. 그 후 이 데이터는 희망 표시 장치에서의 지연된 (이후의) 재생을 위해 임시 또는 롱-텀 메모리 장치에 버퍼링되거나 저장된다. 예를 들어, 이미지는 이미지를 디지털로 표현하는데 유용한 데이터를 수신 또는 송신하기 위해, 모뎀 또는 다른 타입의 인터넷 접속 장치를 갖는 컴퓨터 상에 존재하는 프로그램을 이용하여 인터넷을 "통해 (across)" 또는 인터넷을 이용하여 전송될 수 있다. 무선 모뎀이 장착된 휴대용 컴퓨터 또는 무선 개인 데이터 장치 (Persona Data Assistant; PDA) 또는 무선 전화와 같은 무선 장치를 이용하여 유사한 전송이 이루어질 수 있다.
데이터가 수신되면, 데이터는 위치상, 소형 하드 드라이브 등의 내부 또는 외부 저장 장치를 포함하는 RAM (Random Access Memory) 또는 플래시 메모리 등의 메모리 소자, 회로 또는 장치에 재생 (playback) 을 위해 저장된다. 데이터의 양 및 이미지 해상도에 따라 재생은 상대적으로 빨리 시작될 수도 있고 긴 지연을 갖고 수행될 수도 있다. 즉, 어떤 경우에는, 이미지 표시는, 많은 데이터를 요구하지 않는 매우 작은 또는 낮은 해상도의 이미지에 대해, 또는 작은 지연 후에 더 많은 컨텐츠가 전송되고 있는 동안 일부 컨텐츠를 표시하는 소정 타입의 버퍼링을 이용하여, 어느 정도의 실시간 재생을 가능하게 한다. 사용되고 있는 전송 링크에 관련한 다른 시스템 또는 사용자로부터의 전송 링크에 대한 방해 (interruption) 또는 간섭 (interference) 이 없는 경우, 일단 표시가 시작되면 전송은 표시 장치의 최종 사용자에게 상대적으로 투명 (transparent) 하다. 당연 히, 유선 인터넷 접속과 같이 다수의 사용자가 단일한 통신 경로를 공유하는 경우, 전송은 방해되거나 희망보다 느릴 수 있다.
정지 이미지 또는 동영상을 생성하기 위해 사용되는 데이터는 통신 링크를 통한 데이터의 전송을 빠르게 하기 위해, Joint Photographic Experts Group (JPEG), Motion Picture Experts Group (MPEG) 및 기타 공지된 표준 단체 또는 미디어, 컴퓨터 및 통신 산업의 회사에 의해 구체화된 몇몇의 공지된 기술 중 하나를 이용하여 압축되는 경우가 많다. 이는 주어진 양의 정보를 전송하는데 있어 더 작은 수의 비트를 이용함으로써 이미지 또는 데이터를 더 빨리 전송할 수 있도록 한다.
메모리, 또는 자기나 광 저장 소자와 같은 저장 메커니즘을 갖는 컴퓨터와 같은 "로컬" 장치, 또는 기타 수신 장치로 데이터가 전송되면, 최종 정보는 압축 해제 (또는 특수한 디코딩 플레이어를 이용하여 재생) 되고, 필요한 경우 디코딩 되어 대응하는 가용 표시 해상도 및 제어 소자에 기초하여 적절한 표시를 위해 준비된다. 요구 또는 필요에 따라 다양한 다른 해상도가 일반적으로 가능하지만, 예를 들어, X × Y 픽셀의 스크린 해상도 방식에서, 통상의 컴퓨터 비디오 해상도는 통상 480 × 640 픽셀과 같이 낮은 값으로부터 600 × 800 내지 1024 × 1024 까지의 범위이다.
또한 이미지 표시는 이미지 컨텐츠 및 주어진 비디오 제어기의 소정의 색 레벨 또는 색 깊이 (색을 발생하는데 사용되는 픽셀 당 비트 수) 및 강도, 그리고 사용되는 여하한 추가적인 오버헤드 비트를 다루는 성능에 영향을 받는다. 예를 들어, 통상의 컴퓨터 표시는, 다른 값도 직면하지만, 다양한 색 (음영 및 색조) 을 표현하는데 8 내지 32 또는 그 이상 정도의 픽셀 당 비트를 예상한다.
상기 값으로부터, 주어진 스크린 이미지는, 최저에서 최고의 통상 해상도 및 깊이의 범위에서 각각 2.45 메가비트 (Mb) 내지 약 33.55 Mb 정도의 데이터 전송을 필요로 할 것임을 알 수 있을 것이다. 비디오 또는 동영상을 초당 30 프레임의 레이트로 보는 경우, 필요한 데이터의 양은 약 73.7 내지 1,006 메가비트의 초당 데이터 (Mbps), 또는 초당 약 9.21 내지 125.75 메가비트 (Mbps) 이다. 또한, 멀티미디어 표시 또는 CD 품질 음악과 같은 별도의 고 해상도 오디오 프리젠테이션과 같이 이미지와 함께 오디오 데이터를 표시하기를 원할 수 있다. 양방향 명령, 제어 또는 신호를 다루는 추가적인 신호가 채용될 수도 있다. 이들 선택 사항 각각은 전송할 데이터를 추가한다. 또한 HDTV 및 영화 레코딩과 관련된 새로운 송신 기술은 데이터 및 제어 정보를 더 추가할 수 있다. 여하한 경우에도, 충실한 컨텐츠의 경험을 창조하기 위해 고품질 또는 고 해상도 이미지 데이터 및 고 품질 오디오 정보 또는 데이터 신호를 최종 사용자에게 전송하고자 하는 경우, 표시 소자와 그러한 데이터를 제공하도록 구성된 소스 또는 호스트 장치 사이에 고 데이터 전송 레이트 링크가 요구된다.
초당 115 킬로바이트 (Kbps) 또는 902 킬로비트 (Kbps) 정도의 데이터 레이트는 일부 현대 직렬 인터페이스에 의해 일상적으로 처리될 수 있다. USB 직렬 인터페이스와 같은 다른 인터페이스들은 12 MBps 와 같이 높은 데이터 전송을 수용할 수 있으며, 전기 전자 엔지니어 협회 (IEEE) 1394 표준을 이용하여 구성된 것과 같은 특수한 고속 전송은 100 내지 400 MBps 정도의 레이트로 이루어질 수 있다. 불행히도, 이들 레이트는 휴대용 비디오 디스플레이 또는 오디오 장치를 구동하기 위한 미래의 무선 데이터 장치 및 기타 고 해상도, 충실한 컨텐츠의 서비스에 사용할 것이 고려되는 희망의 고 데이터 레이트에는 부족하다. 이는 비즈니스용 컴퓨터 및 기타 표시, 게임 장치 등을 포함한다. 또한 이들 인터페이스는 현저한 양의 호스트 또는 시스템의 사용과 클라이언트 소프트웨어의 동작을 필요로 한다. 또한 그들 소프트웨어 프로토콜 스택은, 특히 이동 무선 장치 또는 전화 애플리케이션이 고려되는 경우에 바람직하지 않게 많은 양의 오버헤드를 발생한다. 이러한 장치는 이미 부담이 되는 계산 능력뿐만 아니라, 심각한 메모리 및 전력 소비 제한을 가진다. 뿐만 아니라, 이들 인터페이스 중 일부는 매우 심미성을 지향하는 이동 애플리케이션 용으로는 너무 무겁고 불만족스러운 큰 부피의 케이블과, 비용을 추가시키는 복잡한 커넥터를 이용하거나, 단순히 너무 많은 전력을 소비한다.
아날로그 비디오 그래픽 어댑터 (AVGA), 디지털 비디오 인터랙티브 (DVI) 또는 기가비트 비디오 인터페이스 (GVIF) 인터페이스 등의 다른 알려진 인터페이스가 있다. 이들 중 처음의 두 가지는 데이터를 더 높은 전송 레이트로 처리하는 병렬형 인터페이스이지만, 역시 무거운 케이블을 채용하고 수 와트 (watt) 정도의 많은 양의 전력을 소모한다. 이들 특성 중 어떤 것도 휴대용 소비자 전자 장치에 적합치 않다. 세 번째 인터페이스도 너무 많은 전력을 소비하고 비싸거나 부피가 큰 커넥터를 이용한다.
상기 인터페이스 중 일부, 그리고 다른 매우 높은 데이터 레이트 시스템/프로토콜 또는 고정 설치 컴퓨터 장치와 관련된 전송 메커니즘에 있어, 또 다른 중요한 문제점이 있다. 희망 데이터 전송 레이트를 수용하는 것은 현저한 양의 전력 및/또는 높은 전류 수준에서의 동작을 역시 요구한다. 이는 높은 이동성의 소비자 지향 제품에 대한 그러한 기술의 유용성을 현저히 감소시킨다.
일반적으로, 광섬유 형태의 접속 및 전송 소자 등의 대안을 이용하여 이러한 데이터 전송 레이트를 수용하는 것도, 진정한 상용 소비자 지향 제품에 대해 요망되는 것보다 훨씬 높은 복잡성과 비용을 가져오는 수많은 추가적 컨버터 및 소자를 필요로 한다. 광 시스템의 일반적인 고비용 특성 외에도, 그 전력 요구 및 복잡성은 경량, 저전력, 휴대용 애플리케이션에 대한 일반적인 사용을 저해한다.
휴대용, 무선 또는 이동성 애플리케이션에 대해 산업에서 부족했던 것은, 그것이 오디오, 비디오 또는 멀티미디어 기반의 것이든 간에 고도로 이동성인 최종 사용자에게 고 품질 프리젠테이션 경험을 제공하는 기술이다. 즉, 휴대용 컴퓨터, 무선 전화, PDA, 또는 기타 고도로 이동성인 통신 장치 또는 장비를 이용하는 때에, 사용되고 있는 현재의 비디오 및 오디오 표시 시스템 또는 장치는 희망하는 고 품질 수준으로 출력을 전송할 수 없다. 종종, 부족한 인식 품질은 고 품질 표시 데이터를 전송하는데 필요한 얻을 수 없는 높은 데이터 레이트의 결과이다. 이는 최종 사용자에게 표시하기 위해 더 효율적이고 개선된 또는 특성이 부가된 외부 장치로의 전송, 또는 호스트와 컴퓨터, 게임 기계 및 이동 전화와 같은 무선 장치 등의 휴대용 장치 내부의 클라이언트 사이에서의 전송 모두를 포함할 수 있 다.
후자의 경우에, 더욱더 높은 해상도의 내부 비디오 스크린, 그리고 다른 특별한 입력 및/또는 출력 장치 및 제 3 세대 전화라 불리는 것과 같은 무선 장치와 소위 랩탑 컴퓨터로의 접속에 큰 진보가 있어왔다. 그러나 내부 데이터 버스 및 접속은, 비디오 스크린 또는 기타 소자를 호스트 및/또는 다양한 기타 제어 소자 및 출력 소자가 존재하는 메인 하우징에 실장 또는 연결하는 회전 힌지나 힌지형 구조 또는 슬라이딩 접촉 구조를 통해 연결하는 것을 포함할 수도 있다. 이들은 일반적으로 높은 대역폭 또는 높은 처리량 (throughput) 의 인터페이스이다. 희망 출력량을 달성하기 위해서, 예를 들어 무선 전화에 대해 90 개의 콘덕터 또는 그 이상을 요구할 수 있는 종래 기술을 이용하여 높은 처리량의 데이터 전송 인터페이스를 구성하는 것은 매우 어렵다. 현재의 해결 방식은 통상 상대적으로 높은 신호 수준을 이용하는 병렬형 인터페이스를 채용하는 것과 관련되며, 이들은 접속이 더욱 고비용이 되고 잠재적으로 장치 기능에 영향을 줄 수 있는 방사 (radiated emission) 를 발생할 수 있다. 이는 극복해야할 많은 제조, 비용, 및 신뢰성 이슈를 제공한다.
이러한 이슈 및 요구 조건은, 예를 들어 통신 또는 계산형 장치가 개선된 데이터 성능, 인터넷 및 데이터 전송 접속 또는 빌트 인 (built in) 엔터테인먼트를 제공하기 위해 기구 및 기타 소비자 장치에 추가되는 고정 위치 설치에 대해서도 발견된다. 다른 예는 개인 비디오 및 오디오 표시 스크린이 의자 뒷면에 설치된 비행기 또는 버스가 된다. 그러나, 종종 이들 상황에서, 보이는 스크린 또 는 오디오 출력으로부터 떨어진 위치에 정보의 표시를 위한 상호 접속 링크 또는 채널을 갖는 메인 저장소, 처리 또는 통신 제어 소자를 위치시키는 것이 더욱 편리하고, 효율적이며 용이하게 서비스할 수 있다. 이 링크는 상술한 바와 같이 희망 처리량을 달성하기 위해 현저한 양의 데이터를 다룰 필요가 있을 것이다.
그러므로 데이터를 제공하는 호스트 장치와 최종 사용자에게 출력을 표시하는 클라이언트 표시 장치 또는 소자 간에 데이터 처리량을 증가시키기 위해 새로운 전송 메커니즘이 필요하다.
본 출원인은 그러한 새로운 전송 메커니즘을, 2001년 12월 14일에 출원된 미국 특허 출원 제 10/020,520 호로서 현재 주 (Zou) 등에게 2004년 7월 6일자로 허여되어 있는 미국 특허 제 6,760,722 호, 및 2002 년 9월 6일에 출원되어 현재 등록 결정된 미국 특허 출원 제 10/236,657 호로서, 양자 모두 명칭이 "고 데이터 레이트 신호 전송을 위한 통신 프로토콜 및 인터페이스를 생성의 생성 및 구현 (Generatin And Implementing A Communication Protocol And Interface For High Data Rate Signal Transfer)" 미국 특허 출원에서 제안한 바 있으며, 이들은 모두 본 발명의 양수인에게 양수되었으며 여기에 참조로 포함된다. 또한 2004년 6월 2일에 출원되고 명칭이 "더 높은 데이터 레이트를 위한 신호 프로토콜 및 인터페이스의 생성 및 구현 (Generating And Implementing a Signal Protocol and Interface for Higher Data Rates)" 인 미국 출원 제 10/860,116 호가 있다. 그들 출원에서 논의된 기술은 고속 데이터 신호에서 대량의 데이터에 대한 전송 레이트를 현저히 개선할 수 있다. 그러나 특히 비디오 표시와 관련하여 데이터 레이트를 더욱 증가시키려는 요구가 계속 증가하고 있다. 기타 데이터 신호 기술에서의 계속적인 발전으로도, 더 빠른 전송 레이트, 개선된 통신 링크 효율, 그리고 더 강력한 통신 링크 획득에 대한 요구가 여전히 존재한다. 그러므로, 호스트와 클라이언트 장치 간의 데이터 처리량을 증가시키기 위해 필요한 새로운 또는 개선된 전송 메커니즘을 개발할 필요성이 계속 존재한다.
요약
본 기술 분야에 존재하는 상기 문제점 및 기타 문제점들은, 호스트 장치와 수신 클라이언트 장치 사이에서 높은 데이터 레이트로 데이터를 전송하기 위한 새로운 프로토콜 및 데이터 전송 수단, 방법 및 메커니즘이 개발된 본 발명의 실시형태에 의해 다루어진다.
본 발명의 실시형태는 호스트 장치와 클라이언트 장치 간에 미리 선택된 (pre-selected) 디지털 제어 및 프리젠테이션 데이터를 통신하기 위한 통신 프로토콜을 형성하기 위해 복수의 또는 일련의 패킷 구조가 채용되는 통신 경로를 통해 호스트 장치와 클라이언트 장치 간에 높은 데이터 레이트로 디지털 데이터를 전송하기 위한 이동 데이터 디지털 인터페이스 (Mobile Data Digital Interface; MDDI) 를 목적으로 한다. 호스트 또는 클라이언트 링크 제어기, 수신기, 또는 드라이버에 의해 신호 통신 프로토콜 또는 링크 계층이 이용된다. 호스트 장치에 존재하는 하나 이상의 링크 제어기 또는 드라이버가 통신 경로 또는 링크를 통해 클라이언트 장치에 결합되고, 통신 프로토콜을 구성하는 패킷을 발생, 송신 및 수신하고, 디지털 프리젠테이션 데이터를 하나 이상의 데이터 패킷 타입으로 형성하도 록 구성된다. 인터페이스는 공통의 전체 하우징 또는 지지 구조 내에 존재할 수 있는 호스트와 클라이언트 사이에서 정보의 양방향 전송을 제공한다.
구현은 본질적으로, 디지털 CMOS (Complementary Metal-Oxide Semiconductor) 칩을 이용하여 용이하게 구현될 수 있는 차동 (differential) 드라이버와 수신기를 제외하는 일반적으로 모두 디지털로 구현될 수 있고, 6 개 정도의 적은 신호를 요구하며, 시스템 설계자에게 편리한 거의 모든 데이터 레이트에서 동작한다. 단순한 물리 및 링크 계층 프로토콜은 통합을 용이하게 하며, 이 단순성과 휴지 (hibernation) 상태가 휴대용 시스템이 매우 낮은 시스템 전력 소비를 가질 수 있도록 한다.
사용과 채용을 돕기 위해, 인터페이스는 장치의 비용에 매우 적은 양만을 부가하고, 표준 배터리 전압을 이용하는 인터페이스를 통해 전력 표시를 가능하게 하는 한편 매우 적은 전력 소비를 가능케 하며, 포켓형 (pocket-able) 폼 팩터 (form-factor) 를 수용할 수 있다. 인터페이스는 HDTV 이상의 해상도를 지원하도록 스케일링 가능하며, 표시 장치에 스테레오 비디오 및 7.1 오디오를 동시에 지원하며, 여하한 스크린 영역에 조건부 업데이트를 수행하고 양 방향에서 다수의 데이터 타입을 지원한다.
본 발명의 다른 태양에서, 하나 이상의 클라이언트 링크 제어기, 수신기, 장치 또는 드라이버는 클라이언트 장치 내에 배치되고, 통신 경로 또는 링크를 통해 호스트 장치에 결합된다. 또한 클라이언트 링크 제어기는 통신 프로토콜을 형성하는 패킷을 발생, 송신 및 수신하고, 디지털 프리젠테이션 데이터를 하나 이상 의 타입의 데이터 패킷으로 형성하도록 구성된다. 일반적으로, 호스트 또는 링크 제어기는 명령에서 사용되는 데이터 패킷 또는 어떤 타입의 신호 표시, 또는 어떤 타입의 신호 준비 및 질의 처리를 위한 상태 머신 (state machine) 를 채용한다. 호스트 제어기는 하나 이상의 차동 라인 드라이버를 포함한다; 한편 클라이언트 수신기는 통신 경로에 결합된 하나 이상의 차동 라인 수신기를 포함한다.
패킷은, 호스트와 클라이언트 장치 사이에서 통신되고, 상이한 가변 길이를 갖는 소정 숫자의 패킷으로 소정의 고정 길이를 갖는 미디어 프레임 내에서 그룹화 (grouping) 된다. 각각의 패킷은 패킷 길이 필드, 하나 이상의 패킷 데이터 필드, 그리고 순환 리던던시 체크 (cyclic redundancy check) 필드를 포함한다. 서브 프레임 헤더 패킷 (Sub-frame Header Packet) 은 호스트 링크 제어기로부터의 다른 패킷의 전송의 시작 위치에 배치된다. 클라이언트 장치 사용자에게의 프리젠테이션을 위해 순방향 링크를 통해 호스트로부터 클라이언트로 비디오 타입 데이터 및 오디오 타입 데이터를 각각 전송하는데, 통신 프로토콜에 의해 하나 이상의 비디오 스트림 타입 패킷 및 오디오 스트림 타입 패킷이 사용된다. 하나 이상의 역방향 링크 캡슐화 패킷은 통신 프로토콜에 의해 클라이언트 장치로부터 호스트 링크 제어기로 데이터를 전송하는데 사용된다. 이들 전송은, 일 실시형태에서, 하나 이상의 MDDI 장치를 갖는 내부 제어기로부터 내부 비디오 스크린으로의 데이터 전송을 포함한다. 다른 실시형태는 내부 사운드 시스템으로의 전송 및 조이스틱 및 복잡한 키보드를 포함하는 다양한 입력 장치로부터 내부 호스트 장치로의 전송을 포함한다.
필러 (Filler) 타입 패킷은 호스트 링크 제어기에 의해 데이터를 가지지 않는 순방향 링크 송신 기간을 점유하도록 발생된다. 비디오 정보를 전송하기 위해 복수의 다른 패킷이 통신 프로토콜에 의해 사용된다. 이러한 패킷은 컬러맵 (Color Map), 비트맵 블록 전송 (Bitmap Block Trnasfer), 비트맵 영역 채움 (Bitmap Area Fill), 비트맵 패턴 채움 (Bitmap Pattern Fill), 및 투명 컬러 인에이블 (Transparent Color Enable) 타입 패킷을 포함한다. 인터페이스-사용자 정의 데이터를 전송하기 위해 사용자 정의 스트림 (User-defined Stream) 타입 패킷이 통신 프로토콜에 의해 사용된다. 키보드 데이터 (Keyboard Data) 및 포인팅 장치 데이터 (Pointing Device Data) 타입 패킷은 상기 클라이언트 장치와 관련된 사용자 입력 장치로/로부터 데이터를 전송하기 위해 통신 프로토콜에 의해 사용된다. 링크 셧다운 (Link Shutdown) 타입 패킷은 상기 통신 경로를 통한 둘 중 한 방향의 데이터 전송을 종료하기 위해 통신 프로토콜에 의해 사용된다.
디스플레이 전력 상태 패킷은, 디스플레이와 같은 클라이언트가 사용되지 않거나 현재 능동적 사용이 아닌 경우, 시스템 리소스 상에서 시스템 전력 소비 또는 드레인을 최소화하기 위해 특정 디스플레이 제어기 하드웨어를 저전력 상태에 두는 구조, 수단 또는 방법을 제공하기 위해 생성된다. 일 실시형태에서는, 클라이언트가 클라이언트 능력 패킷의 클라이언트 특성 능력 표시자 필드의 9 비트를 사용하여 디스플레이 전력 상태 패킷에 대응하는 능력을 나타낸다.
디스플레이 전력 상태 패킷에 대한 일 실시형태의 형식에 있어서, 이 타입의 패킷은 패킷 길이, 패킷 타입, h클라이언트 ID, 전력 상태 및 CRC (Cyclic Redundancy Check) 필드를 가지도록 구성된다. 이 타입의 패킷은 통상적으로 2 바이트 타입 필드에서 타입 75 패킷으로서 식별된다. 2 바이트 h클라이언트 ID 필드는 클라이언트 ID 를 위해 보류된 정보 또는 값을 포함한다. 전력 상태 필드는 임의의 미리 선택된 비트의 값에 따라 특정 디스플레이를 특정 전력 상태에 두는데 사용되는 정보를 특정한다. 2 바이트 CRC 필드는 패킷 길이를 포함한 패킷에서의 모든 바이트의 CRC 를 특정하거나 포함한다.
통신 경로는 일반적으로 4 이상의 일련의 콘덕터 및 실드를 갖는 케이블을 포함 또는 채용한다. 또한, 희망에 따라 인쇄 배선 또는 콘덕터가 사용될 수 있으며, 일부는 가요성 기판 상에 존재한다.
호스트 링크 제어기는 상기 클라이언트가 상기 인터페이스를 통해 어떠한 타입의 데이터 및 데이터 레이트를 수용할 수 있는지를 결정하기 위해 클라이언트 장치로부터 디스플레이 능력 정보를 요청한다. 클라이언트 링크 제어기는 1 이상의 클라이언트 능력 (Client Capability) 타입 패킷을 이용하여 호스트 링크 제어기로 디스플레이 또는 프리젠테이션 능력을 통신한다. 다수의 전송 모드가 통신 프로토콜에 의해 사용될 수 있으며, 각각은 주어진 시간 기간 동안 병렬로 데이터 비트의 상이한 최대 수를 전송할 수 있도록 하며, 각각의 모드는 호스트 및 클라이언트 제어기들 간에 협상에 의해 선택될 수 있다. 이들 전송 모드는 데이터 전송 동안 동적으로 조정되며, 순방향 링크에 이용되는 것과 동일한 모드가 역방향 링크에서 이용될 필요는 없다.
본 발명의 일부 실시형태의 다른 태양에서, 호스트 장치는 무선 전화, 무선 PDA 또는 내부에 배치된 무선 모뎀을 갖는 휴대용 컴퓨터와 같은 무선 통신 장치를 포함한다. 통상적인 클라이언트 장치는 마이크로 디스플레이 장치와 같은 휴대용 비디오 디스플레이 및/또는 휴대용 오디오 프리젠테이션 시스템을 포함한다. 또한, 호스트는 클라이언트 장치 사용자에게 전송되거나 제시될 프리젠테이션 또는 멀티미디어 데이터를 저장하기 위해 저장 수단 또는 소자를 사용할 수 있다.
일부 실시형태의 또 다른 태양에서, 호스트 장치는, 후술하는 바와 같이, 무선 전화, 무선 PDA 또는 휴대용 컴퓨터 등의 무선 통신 장치와 같은 휴대용 전기 장치 내에 존재하는 드라이버를 갖는 제어기 또는 통신 링크 제어 장치를 포함한다. 이 구성에서의 통상의 클라이언트 장치는, 호스트에 결합되고 동일한 장치 내에 존재하며, 이동 전화용 고해상도 스크린과 같은 내부 비디오 디스플레이, 및/또는 휴대용 오디오 프리젠테이션 시스템 또는 다르게는 어떤 타입의 입력 시스템 또는 장치에 결합된 클라이언트 회로 또는 집적 회로 또는 모듈을 포함한다.
도면의 간단한 설명
본 발명의 구조 및 동작뿐 아니라 다른 특성 및 이점을 이하 첨부한 도면을 참조하여 더 상세히 설명한다. 도면에서, 유사한 참조번호는 통상적으로 동일하거나, 기능적으로 유사하거나, 및/또는 구조적으로 유사한 소자 또는 프로세싱 단계를 나타낸다.
도 1a 는 본 발명의 실시형태가 동작할 수 있으며, 휴대용 컴퓨터 또는 기타 데이터 처리 장치와 결합된 마이크로 디스플레이 장치 (micro-diaplay device) 또는 프로젝터의 이용을 포함하는 기본적 환경을 도시한다.
도 1b 는 본 발명의 실시형태가 동작할 수 있으며, 무선 트랜시버와 결합되어 사용되는 마이크로 디스플레이 장치 또는 프로젝터, 및 오디오 프리젠테이션 소자의 이용을 포함하는 기본적 환경을 도시한다.
도 2a 는 본 발명의 실시형태가 동작할 수 있으며, 휴대용 컴퓨터에서 사용되는 내부 디스플레이 또는 오디오 프리젠테이션 장치의 사용을 포함하는 기본적 환경을 도시한다.
도 2b 는 본 발명의 실시형태가 동작할 수 있으며, 무선 트랜시버에서 사용되는 내부 디스플레이 또는 오디오 프리젠테이션 소자의 사용을 포함하는 기본적 환경을 도시한다.
도 3 은 호스트 및 클라이언트 상호접속을 갖는 MDDI 의 전반적 개념을 도시한다.
도 4 는 클라이언트 장치로부터 호스트 장치로의 데이터 전송을 실현하는데 유용한 패킷의 구조를 도시한다.
도 5 는 타입 1 인터페이스에 대한 물리적 데이터 링크 콘덕터를 통해 호스트와 클라이언트간에 전송되는 신호의 타입 및 MDDI 링크 제어기의 사용을 도시한다.
도 6 은 타입 2, 3 및 4 인터페이스에 대한 물리적 데이터 링크 콘덕터를 통해 호스트와 클라이언트 간에 전송되는 신호의 타입 및 MDDI 링크 제어기의 사용을 도시한다.
도 7 은 인터페이스 프로토콜을 구현하는데 사용되는 프레임 및 서브 프레임 의 구조를 도시한다.
도 8 은 인터페이스 프로토콜을 구현하는데 사용되는 패킷의 일반적 구조를 도시한다.
도 9 는 서브 프레임 헤더 패킷 (Sub-frame Header Packet) 의 형식을 도시한다.
도 10 은 필러 패킷 (Filler Packet) 의 형식 및 컨텐츠를 도시한다.
도 11 은 비디오 스트림 패킷 (Video Stream Packet) 의 형식을 도시한다.
도 12a 내지 12e 는 도 11 에서 사용된 비디오 데이터 형식 디스크립터 (Video Data Format Descriptor) 에 대한 형식 및 컨텐츠를 도시한다.
도 13 은 데이터에 대한 패킷화된 형식 및 비패킷화된 형식의 사용을 도시한다.
도 14 는 오디오 스트림 패킷 (Audio Stream Packet) 의 형식을 도시한다.
도 15 는 데이터에 대한 바이트 정렬된 PCM 형식 및 패킷화된 PCM 형식의 사용을 도시한다.
도 16 은 사용자 정의 스트림 패킷 (User-Defined Stream Packet) 의 형식을 도시한다.
도 17 은 컬러 맵 패킷 (Color Map Packet) 의 형식을 도시한다.
도 18 은 역방향 링크 캡슐화 패킷 (Reverse Link Encapsulation Packet) 의 형식을 도시한다.
도 19 는 클라이언트 능력 패킷 (Client Capability Packet) 의 형식을 도시 한다.
도 20 은 키보드 데이터 패킷 (Keyboard Data Packet) 의 형식을 도시한다.
도 21 은 포인팅 장치 데이터 패킷 (Pointing Device Data Packet) 의 형식을 도시한다.
도 22 는 링크 셧다운 패킷 (Link Shutdown Packet) 의 형식을 도시한다.
도 23 은 클라이언트 요청 및 상태 패킷 (Client Request and Status Packet) 의 형식을 도시한다.
도 24a 는 비트 블록 전송 패킷 (Bit Block Transfer Packet) 의 형식을 도시한다.
도 24b 는 본 발명의 실시형태를 구현하는데 유용한 예시적인 래스터 연산의 데이터 흐름을 도시한다.
도 25 는 비트맵 영역 채움 패킷 (Bitmap Area Fill Packet) 의 형식을 도시한다.
도 26 은 비트맵 패턴 채움 패킷 (Bitmap Pattern Fill Packet) 의 형식을 도시한다.
도 27 은 판독 프레임 버퍼 패킷 (Read Frame Buffer Packet) 의 형식을 도시한다.
도 28 은 디스플레이 전력 상태 패킷 (Display Power State Packet) 의 형식을 도시한다.
도 29 는 수행 타입 핸드오프 패킷 (Perform Type Handoff Packet) 의 형식 을 도시한다.
도 30 은 순방향 오디오 채널 인에이블 패킷 (Forward Audio Channel Enable Packet) 의 형식을 도시한다.
도 31 은 역방향 오디오 샘플 레이트 패킷 (Reverse Audio Sample rate PAcket) 의 형식을 도시한다.
도 32 는 디지털 컨텐츠 보호 오버헤드 패킷 (Digital Content Protection Overhead Packet) 의 형식을 도시한다.
도 33 은 투명 컬러 및 마스크 설정 패킷 (Transparent Color and Mask Setup Packet) 의 형식을 도시한다.
도 34 는 라운드 트립 지연 측정 패킷 (Round Trip Delay Measurement Packet) 의 형식을 도시한다.
도 35 는 라운드 트립 지연 측정 패킷 동안의 이벤트의 타이밍을 도시한다.
도 36 은 본 발명을 구현하는데 유용한 CRC 생성기 및 확인기의 샘플 구현을 도시한다.
도 37a 는 데이터 패킷 전송시 도 36 의 장치에 대한 CRC 신호의 타이밍을 도시한다.
도 37b 는 데이터 패킷 전송시 도 36 의 장치에 대한 CRC 신호의 타이밍을 도시한다.
도 38a 및 38b 는 표준 차동 수신기에 비해 특히 저전력인 차동 수신기의 예시적인 동작을 도시한다.
도 39a 는 회선 쟁탈 (contention) 이 없는 통상적인 서비스 요청에 대한 프로세싱 단계를 도시한다.
도 39b 는 링크 시작시 회선 쟁탈하는, 링크 재시작 시퀀스가 시작된 후 발해지는 통상 서비스 요청에 대한 프로세싱 단계를 도시한다.
회선 쟁탈이 없는 통상적인 클라이언트 서비스 요청 이벤트에 대한 프로세싱 단계의 예가 도 39a 에 도시되어 있다.
링크 재시작 시퀀스가 시작된 후 발해지는 서비스 요청의 유사한 예가 도 39b 에 도시되어 있다.
도 40 은 DATA-STB 인코딩을 사용하여 데이터 시퀀스가 송신될 수 있는 방법을 도시한다.
도 41 은 호스트에서 입력 데이터로부터의 DATA 및 STB 신호를 발생하고, 그 후 클라이언트에서 데이터를 복구하는데 유용한 회로를 도시한다.
도 42a 는 일 실시형태를 구현하는데 유용한 드라이버 및 종단을 도시한다.
도 42b 는 차동 전류 모드 드라이버의 블록도를 도시한다.
도 43a 내지 43c 는 호스트로부터의 서비스를 보안하기 위해 클라이언트에 의해, 그리고 그러한 서비스를 제공하기 위해 호스트에 의해 채용되는 단계 및 신호 수준을 도시한다.
도 44 는 Data0, 다른 데이터 라인 (DataX) 및 스트로브 라인 (Stb) 상의 천이 간의 상대적 간격을 도시한다.
도 45 는 호스트가 패킷 전송 후에 호스트 드라이버를 디스에이블하는 때에 응답하여 발생할 수 있는 지연의 존재를 도시한다.
도 46 은 호스트가 호스트 드라이버를 패킷을 전송하도록 인에이블하는 때에 응답하여 발생할 수 있는 지연의 존재를 도시한다.
도 47 은 누설 전류 분석을 도시한다.
도 48 은 호스트 미 클라이언트 출력 인에이블 및 디스에이블 시간에 대한 스위칭 특성 및 상대적 타이밍 관계를 도시한다.
도 49 는 상태 머신을 이용하여 동기화가 구현될 수 있는 신호 처리 단계 및 조건의 높은 수준의 도면을 도시한다.
도 50 은 MDDI 를 채용하는 시스템에서 순방향 및 역방향 경로 상에서의 신호 처리에 대해 개입되는 통상의 양의 지연을 도시한다.
도 51 은 한계 (marginal) 라운드 트립 지연 측정을 도시한다.
도 52a 는 역방향 링크 데이터 레이트 변화를 도시한다.
도 52b 는 고급 역방향 데이터 샘플링의 예를 도시한다.
도 53 은 순방향 링크 데이터 레이트에 대한 역방향 레이트 제수 (Reverse Rate Divisor) 값의 그래프 표시를 도시한다.
도 54a 및 54b 는 인터페이스의 동작에서 수행되는 단계를 도시한다.
도 55 는 인터페이스 장치 처리 패킷의 개요를 도시한다.
도 56 은 순방향 링크 패킷의 형식을 도시한다.
도 57 은 타입 1 링크 인터페이스에서의 전파 지연 및 스큐 (skew) 에 대한 통상 값을 도시한다.
도 58 은 인터페이스를 통한 예시적인 신호 처리에 대한 타입 1 링크 상의 Data, Stb, 및 클록 회복 타이밍 (Clock Recovery Timing) 을 도시한다.
도 59 는 타입 2, 타입 3 또는 타입 4 링크 인터페이스에서의 전파 지연 및 스큐 (skew) 에 대한 통상 값을 도시한다.
도 60a, 60b 및 60c 는 각각 두 개의 데이터 신호 및 MDDI_Stb 의, 이상적인 것, 빠른 것 및 늦은 것의 서로에 대한 타이밍의 다른 가능성들을 도시한다.
도 61 은 인터페이스를 통한 예시적인 신호 프로세싱에 대한 지연 스큐 보상 회로를 갖는 통상적인 타입 2 순방향 링크를 도시한다.
도 62a 및 62b 는 타입 1 및 타입 2 인터페이스 모두에 대해 가능한 MDDI_Data 및 DMMI_Stb 파형을 각각 도시한다.
도 63 은 상태 머신을 이용하여 동기화가 구현될 수 있는 다른 신호 처리 단계 및 조건의 높은 수준의 도면을 도시한다.
도 64 는 다양한 역방향 링크 패킷 비트 및 제수 값의 타이밍과 일련의 클록 사이클 사이의 예시적인 상태 타이밍을 도시한다.
도 65 는 예시적인 오류 코드 전송 처리를 도시한다.
도 66 은 오류 코드 전송 처리에 유용한 장치를 도시한다.
도 67a 는 코드 오버로딩에 대한 오류 코드 전송 처리를 도시한다.
도 67b 는 코드 수신에 대한 오류 코드 전송 처리를 도시한다.
도 68a 는 호스트 초기화 웨이크 업 (wake-up) 에 대한 처리 단계를 도시한다.
도 68b 는 클라이언트 초기화 웨이크 업에 대한 처리 단계를 도시한다.
도 68c 는 회선 쟁탈이 있는 호스트 및 클라이언트 초기화 웨이크 업에 대한 처리 단계를 도시한다.
도 69 는 요청 VCP (Virtual Control Panel) 특성 패킷 (Request VCP Feature Packet) 의 형식을 도시한다.
도 70 은 VCP 특성 응답 패킷 (VCP Feature Reply Packet) 의 형식을 도시한다.
도 71 은 VCP 특성 응답 리스트 (VCP Feature Reply List) 의 형식을 도시한다.
도 72 는 설정 VCP 특성 패킷 (Set VCP Feature Packet) 의 형식을 도시한다.
도 73 은 요청 유효 파라미터 패킷 (Request Valid Parameter Packet) 의 형식을 도시한다.
도 74 는 유효 파라미터 응답 패킷 (Valid Parameter Reply Packet) 의 형식을 도시한다.
도 75 는 스케일링된 비디오 스트림 능력 패킷 (Scaled Video Stream Capability Packet) 의 형식을 도시한다.
도 76 은 스케일링된 비디오 스트림 설정 패킷 (Scaled Video Stream Setup Packet) 의 형식을 도시한다.
도 77 은 스케일링된 비디오 스트림 확인 응답 패킷 (Scaled Video Stream Acknowledgement Packet) 의 형식을 도시한다.
도 78 은 스케일링된 비디오 스트림 패킷 (Scaled Video Stream Packet) 의 형식을 도시한다.
도 79 는 요청 특정 상태 패킷 (Request Specific Status Packet) 의 형식을 도시한다.
도 80 은 유효 상태 응답 리스트 패킷 (Valid Status Replay List Packet) 의 형식을 도시한다.
도 81 은 개인 디스플레이 능력 패킷 (Personal Display Capability Packet) 의 형식을 도시한다.
도 82 는 필드 곡률 지점 리스트 (Point of Field Curvature List) 의 성분을 도시한다.
도 83 은 클라이언트 오류 보고 패킷 (Client Error Report Packet) 의 형식을 도시한다.
도 84 는 오류 보고 리스트 (Error Report List) 아이템의 형식을 도시한다.
도 85 는 클라이언트 식별 패킷 (Client Identification Packet) 의 형식을 도시한다.
도 86 은 교대 디스플레이 능력 패킷 (Alternate Display Capability Packet) 의 형식을 도시한다.
도 87 은 레지스터 액세스 패킷 (Register Access Packet) 의 형식을 도시한다.
도 88a-88c 는 가시물 (visible artifact) 을 감소시키기 위한 2 개의 디스플레이 버퍼의 이용을 도시한다.
도 89 는 이미지 전송보다 빠른 디스플레이 리프레쉬를 갖는 2 개의 버퍼를 도시한다.
도 90 은 이미지 전송보다 느린 디스플레이 리프레쉬를 갖는 2 개의 버퍼를 도시한다.
도 91 은 이미지 전송보다 훨씬 빠른 디스플레이 리프레쉬를 갖는 2 개의 버퍼를 도시한다.
도 92 는 이미지 전송보다 빠른 디스플레이 리프레쉬를 갖는 3 개의 버퍼를 도시한다.
도 93 은 이미지 전송보다 느린 디스플레이 리프레쉬를 갖는 3 개의 버퍼를 도시한다.
도 94 는 이미지 전송보다 빠른 디스플레이 리프레쉬를 갖는 1 개의 버퍼를 도시한다.
도 95 는 데이지 (daisy) 체인 및 허브를 통한 호스트-클라이언트 접속을 도시한다.
도 96 은 허브와 데이지 체인의 조합을 통해 접속된 클라이언트 장치를 도시한다.
도 97 은 컬러 맵을 도시한다.
도 98 은 데이터 전송 구성에서 하나 이상의 클라이언트의 사용을 도시한다.
도 99 는 2 개의 클라이언트를 갖는 송신 라인 상에서 종단되지 않은 스터브 (stubs) 의 사용에 대한 애플리케이션을 도시한다.
상세한 설명
I. 개관
본 발명의 대체적인 의도는, 후술하는 바와 같이, "직렬 (serial)" 형 데이터 링크 또는 채널을 이용하여, 표시 소자 등과 같은 클라이언트 장치와 호스트 장치 사이의 단거리 통신 링크를 통해 고속 또는 초고속 데이터 전송을 가능케 하는 비용 효율적이고, 저 전력 소비의 전송 메커니즘을 가져오는 또는 제공하는 MDDI (Mobile Display Digital Interface) 를 제공하는 것이다. 이 메커니즘은 내부 (하우징 또는 지지 프레임 내부) 표시 또는 출력 소자 또는 장치, 또는 입력 장치를 중앙 제어기 또는 통신 소자 또는 장치에 접속하는데 특히 유용한 소형 커넥터 및 박형 가요성 케이블로 구현된다. 또한, 이 접속 메커니즘은 입을 수 있는 (wearable) 마이크로 디스플레이 (고글 또는 프로젝터) 와 같은 외부 표시 소자 또는 장치 또는 다른 타입의 시각, 청각, 촉각 정보 표시 장치를 휴대용 컴퓨터, 무선 통신 장치, 또는 오락 장치에 접속하는데 매우 유용하다.
이동성 (Mobile) 및 표시 (Display) 라는 용어가 프로토콜의 이름에 포함되지만, 이는 인터페이스 및 프로토콜과 관련된 당업자가 용이하게 이해할 수 있는 표준 명칭을 갖는 형태의 편의를 위한 것이다. 이는 VESA (Video Electronics Standards Association) 표준 및 다양한 그 표준의 애플리케이션에 관련될 수 있다. 그러나, 하기 제시된 실시형태를 검토한 후, 많은 비 이동성 및 비 표시 관 련 애플리케이션이 본 프로토콜, 결과 인터페이스 구조, 또는 전송 메커니즘으로부터 수혜를 입을 것이며, MDDI 레이블은 본 발명 또는 그 다양한 실시형태의 본질 또는 유용성에 여하한 제한도 부과하려는 의도가 아님을 용이하게 알 수 있을 것이다.
본 발명의 장점은, 복잡도가 낮고, 비용이 낮으며, 높은 신뢰성을 갖고 사용 환경에 잘 맞으며, 높은 유연성을 유지하는 동시에 매우 로버스트한 데이터 전송을 위한 기술이 제공된다는 것이다.
본 발명의 실시형태는, 일반적으로 오디오, 비디오 또는 멀티미디어 애플리케이션 용의 대량의 데이터를, 그러한 데이터가 발생되고 특정 장치로의 전송을 위해 조작되며 기타 처리되고, 또는 저장되는 호스트 또는 소스 장치로부터, 비디오 표시 또는 프로젝션 소자, 오디오 스피커 또는 기타 표시 장치 등의 클라이언트 또는 수신 장치로 높은 레이트로 통신 또는 전송하는 다양한 상황에서 사용될 수 있다. 후술할 통상의 애플리케이션은 휴대용 컴퓨터 또는 무선 전화 또는 모뎀으로부터 소형 비디오 스크린 또는 프로젝션 렌즈 및 스크린을 포함하는 고글 또는 헬멧 형태와 같은 입을 수 있는 소형 표시 기구 등의 시각 표시 장치로의, 또는 그러한 소자 내에서 호스트에서 클라이언트 장치로의 데이터 전송이다. 즉, 프로세서 또는 제어기로부터 내부 스크린 또는 기타 표시 소자로뿐만 아니라, 클라이언트를 채용하거나 케이블이나 콘덕터로 거기에 접속된 다양한 내부 또는 외부 입력 장치로부터 내부에 위치하는 (동일한 장치 하우징 또는 지지 구조 내에 같이 위치하는) 호스트로이다.
MDDI 의 특성 또는 속성은 그것이 특정한 디스플레이 또는 프리젠테이션 기술에 독립적이라는 점이다. 이것은 데이터의 내부 구조 또는 구현하는 데이터나 명령의 기능적 측면을 고려하지 않고 높은 레이트로 데이터를 전송하기 위한 높은 유연성의 매커니즘이다. 이는 전송되고 있는 데이터 패킷의 타이밍이, 소정 장치에 대한 고유 표시 희망에 대한 특정 클라이언트 장치의 특성에 적응하도록, 또는 일부 AV (Audio Visual) 시스템에 대한, 또는 조이스틱, 터치 패드 등의 어떤 입력 장치에 대한 오디오 비디오 결합 요구를 만족시키도록 조정될 수 있도록 한다. 선택된 프로토콜이 지켜지는 한, 인터페이스는 표시 소자 또는 클라이언트 장치에 매우 무감하다. 또한, 총합 직렬 링크 데이터, 또는 데이터 레이트는 몇 오더 (order) 에 걸쳐 변할 수 있으며, 이는 통신 시스템 또는 호스트 장치 설계자가 비용, 전력 요구, 클라이언트 장치 복잡도 및 클라이언트 장치 업데이트 레이트를 최적화할 수 있게 한다.
데이터 인터페이스는 주로 유선 신호 링크 또는 작은 케이블을 통해 대량의 높은 레이트 데이터를 전송하는데 사용하기 위해 제공된다. 그러나, 일부 애플리케이션은, 그 인터페이스 프로토콜 용으로 개발된 동일한 패킷 및 데이터 구조를 이용하도록 구성되고 실용성을 위해 충분히 낮은 전력 소비 또는 복잡도로 희망 수준의 전송을 유지할 수 있다면 무선 링크도 이용할 수 있다.
Ⅱ. 환경
도 1a 및 1b 에서 통상의 애플리케이션을 볼 수 있으며, 여기서 휴대용 또는 랩탑 컴퓨터 (100) 및 무선 전화 또는 PDA 장치 (102) 가 오디오 재생 시스템 (108 및 112) 와 함께 표시 장치 (104 및 106) 각각과 통신한다. 또한, 도 1a 는 더 큰 디스플레이 또는 스크린 (114) 또는 이미지 프로젝터 (116) 로의 잠재적 연결을 도시하며, 이는 명확성을 위해 한쪽 도면에만 도시하였으나 무선 장치 (102) 에도 접속될 수 있다. 무선 장치는 현재 데이터를 수신하고 있을 수 있고, 무선 장치의 사용자의 감상 및/또는 청취를 위한 차후의 표시를 위해 이전에 소정 량의 멀티미디어 타입 데이터를 메모리 소자 또는 장치에 저장했을 수 있다. 통상의 무선 장치는 대부분의 경우 음성 및 단순한 텍스트 통신을 위해 사용되므로, 장치 (102) 사용자에게 정보를 통신하기 위한 단순한 오디오 시스템 (스피커) 및 작은 표시 스크린을 갖는다.
컴퓨터 (100) 는 휠씬 큰 스크린을 가지나, 여전히 부적절한 외부 사운드 시스템을 가지며, 고선명 텔레비젼 또는 영화 스크린과 같은 다른 멀티미디어 제공 장치도 부족하다. 컴퓨터 (100) 는 예시를 위해 사용되며, 다른 타입의 프로세서, 양방향 비디오 게임, 또는 소비자 전자 장치가 본 발명에 사용될 수 있다. 컴퓨터 (100) 는 무선 모뎀 또는 다른 무선 통신용 빌트 인 장치를 채용할 수 있으나, 이에 제한되지 않으며, 케이블 또는 무선 링크를 이용하여 희망에 따라 그러한 장치에 접속될 수 있다.
이는 유용한 또는 즐길만한 경험보다는 더 복잡한 또는 "풍부한 (rich)" 데이터의 제공을 수행한다. 그러므로, 업계에서는 최종 사용자에게 정보를 제공하고 최소 수준의 희망 오락 또는 긍정적 경험을 제공하는 다른 메커니즘 및 장치 를 개발하고 있다.
상술한 바와 같이, 장치 (100) 의 최종 사용자에게 정보를 표시하기 위한 몇몇 타입의 표시 장치가 개발되었거나 현재 개발 중이다. 예를 들어, 하나 이상의 회사가 장치 사용자의 눈 앞에 이미지를 투사하여 시각적 표시를 제공하는 착용 가능한 고글 세트를 개발하였다. 정확하게 배치되면, 그러한 장치는 사용자의 눈에 의해 인식되는 가상 이미지를 효과적으로 "투사 (project)" 하며, 이는 시각적 출력을 제공하는 소자보다 훨씬 크다. 즉, 아주 작은 프로젝션 소자가 사용자의 눈이 통상의 LCD (Liquid Crystal Display) 스크린 등에 의한 것보다 훨씬 큰 이미지를 "볼" 수 있게 하는 것이다. 또한 더 큰 가상 스크린 이미지의 사용은 제한된 LCD 스크린 디스플레이로 가능한 것에 비해 훨씬 높은 해상도의 사용을 가능하게 한다. 다른 표시 장치는 소형 LCD 스크린 또는 다양한 평판 표시 소자, 프로젝션 렌즈 및 표면에 이미지를 투사하기 위한 디스플레이 드라이버 등을 포함하나 이에 제한되지 않는다.
신호를 다시 다른 곳으로 전송하거나 저장하는 다른 사용자에게 또는 다른 장치에게 출력을 제공하기 위한 또는 무선 장치 (102) 또는 컴퓨터 (100) 에 접속되거나 그 사용과 관련된 추가적인 소자가 존재할 수 있다. 예를 들어, 데이터는 플래시 메모리에, 광 형태로, 예를 들어 기록 가능한 CD 매체를 이용하여, 또는 자기 테이프 레코더 및 유사 장치 등 자기 매체 상에 차후의 사용을 위하여 저장될 수 있다.
또한, 많은 무선 자치 및 컴퓨터가 현재 빌트 인 MP3 음악 디코딩 기능뿐만 아니라 기타 고급 사운드 디코더 및 시스템을 가지고 있다. 휴대용 컴퓨터는 CD 및 DVD 재생 성능을 원칙적으로 이용하며, 일부는 사전 기록된 오디오 파일을 수신하기 위한 소형의 전용 플래쉬 메모리를 갖는다. 이러한 성능을 갖는 것과 관련한 이슈는, 디지털 음악이 고도로 증진된 특성의 풍부한 경험을 약속하지만, 이는 디코딩과 재생 과정이 페이스를 유지할 수 있는 경우만 그렇다는 점이다. 이는 디지털 비디오 파일에 대해서도 동일하다.
사운드 재생을 돕기 위해, 외부 스피커 (114) 가 도 1a에 도시되며, 이는 서브 우퍼, 또는 전방 및 후방 사운드 프로젝션을 위한 "서라운드 사운드" 스피커와 같은 추가적인 소자를 수반할 수 있다. 동시에, 스피커 또는 이어폰 (108) 은 도 1b 의 소형 표시 장치 (106) 의 지지 프레임 또는 메커니즘에 빌트 인으로 표시된다. 주지하다시피, 전력 증폭기 또는 사운드 변형 (shaping) 장치를 포함하는 다른 오디오 또는 사운드 재생 소자가 사용될 수 있다.
어떤 경우에도, 상술한 바와 같이 데이터 소스에서 최종 사용자로 하나 이상의 통신 링크 (110) 를 통해 고품질 또는 고해상 이미지 데이터 및 고품질 오디오 정보 또는 데이터 신호를 전송하고자 하는 경우, 높은 데이터 레이트가 필요하다. 즉, 현재의 전송 메커니즘은 통상적으로 요망되는 높은 데이터 레이트를 달성하지 못하므로, 링크 (110) 는 명백히, 전술한 바와 같은 데이터 통신에 있어 잠재적인 병목이며, 시스템 성능을 제한하고 있다. 예를 들어 상술한 바와 같이, 픽셀 당 24-32 비트의 색 깊이와 30 fps 의 데이터 레이트에서, 1024 × 1024 픽셀과 같이 높은 이미지 해상도에 있어서 데이터 레이트는 755 Mbps 이상에 도달할 수 있 다. 또한, 그러한 이미지는 대화형 게임 또는 통신, 또는 다양한 명령, 제어, 또는 신호를 다루고 또한 데이터 량 또는 데이터 레이트를 증가시키는 잠재적인 추가 신호 및 오디오 데이터를 포함하는 멀티미디어 제공의 일부로 제공될 수 있다.
데이터 링크를 수립하기 위해 요구되는 케이블 또는 상호연결이, 즉 디스플레이와 관련된 이동 장치가 적을수록 사용이 더 용이하고, 더 많은 사용자 베이스에 의해 채택될 가능성이 더 높다는 것은 명백하다. 특히 다수의 장치가 완전한 오디오-비주얼 경험을 수립하는데 공통으로 사용될 때, 더욱이 디스플레이와 오디오 출력 장치의 품질 수준이 증가하는 때에 그렇다.
비디오 스크린 및 다른 출력 또는 입력 장치에서의 많은 상기 및 다른 개선들에 관련된 다른 애플리케이션을 도 1c 및 1d 에서 볼 수 있으며, 도 1c 및 1d 에서 휴대용 또는 랩탑 컴퓨터 (130) 및 무선 전화 또는 PDA 장치 (140) 는 각각, 오디오 재생 시스템 (136 및 146) 과 함께, "내부" 디스플레이 장치 (134 및 144) 와 데이터를 통신하는 것으로 도시된다.
도 1c 및 1d 에서, 전체적인 전자 장치 또는 제품의 작은 단면을 (cut-away) 가 이용하여, 오늘날 전자 산업에 걸쳐 이용되는 일부 알려진 타입의 회전 접합을 거쳐 대응하는 클라이언트를 갖는 비디오 표시 소자 또는 스크린에 이들을 접속하는 일반화된 통신 링크, 여기서는 138 및 148 을 갖는 장치의 일부에서 하나 이상의 내부 호스트 및 제어기의 위치를 도시한다. 이러한 전송에 관련된 데이터량은 링크 (138 및 148) 를 포함하는 많은 콘덕터를 요구하는 것을 알 수 있을 것이다. 그러한 데이터를 전송하기 위해 이용가능한 병렬 또는 다른 알려진 인터페 이스 기술의 타입 때문에, 오늘날 증가하고 있는 표시 소자, 그러한 장치상에서의 고급 컬러 및 그래픽 인터페이스의 필요성을 만족시키기 위해, 그러한 통신 링크는 90 개 이상의 콘덕터에 달하는 것으로 추정된다.
불행하게도, 더 높은 데이터 레이트는 데이터를 전송하기 위해 이용 가능한 현재 기술을 초과한다. 단위 시간당 전송되어야 하는 데이터의 미가공 (raw) 양의 관점과, 신뢰할 수 있는 비용 효율적인 물리적 전송 메커니즘 제조의 관점에서 모두 그렇다.
일관되게 (더) 낮은 전력, 경량, 및 가능한 간단하고 경제적인 선로화 구조를 가능하게 하는, 표시 소자와 데이터 소스 사이의 데이터 전송 링크 또는 통신 경로에 대해 더 높은 레이트로 데이터를 전송하기 위한 기술, 구성, 수단 또는 방법이 필요하다. 본 출원인은 이동, 휴대용, 또는 심지어 고정 위치 장치의 배열이 데이터를 소망의 디스플레이, 마이크로 디스플레이 또는 오디오 전송 소자로, 낮은 소비전력과 복잡도를 유지하면서 매우 높은 데이터 레이트로 전송할 수 있도록, 이들 및 다른 목적을 달성하는 새로운 기술, 또는 방법 및 장치를 개발했다.
Ⅲ. 고 레이트 디지털 데이터 인터페이스 시스템 구조
새로운 장치 인터페이스를 생성하고 효율적으로 이용하기 위해, 저출력 신호를 이용하여 고 데이터 전송 레이트를 제공하는 신호 프로토콜 및 시스템 구조가 공식화되었다. 프로토콜은 패킷 및 공통 프레임 구조, 또는 인터페이스상에 부 과된 명령 또는 동작 구조와 함께 미리 선택된 데이터 세트 또는 데이터 타입을 통신시키기 위한 프로토콜을 형성하기 위해 서로 연결된 구조들에 기초한다.
A. 개관
MDDI 링크를 통해 접속되거나 또는 통신하는 장치들은 호스트와 클라이언트라고 하며, 클라이언트는, 다른 출력 및 입력 장치가 고려되기는 하지만, 통상 어떤 타입의 표시 장치이다. 호스트로부터 디스플레이로의 데이터는 순방향 (순방향 트래픽 또는 링크라 한다) 으로 이동하고, 클라이언트로부터 호스트로의 데이터는, 호스트에 의해 인에이블되는 대로, 역방향 (역방향 트랙픽 또는 링크) 으로 이동한다. 이것은 도 2 에서 기본 구성으로 도시된다. 도 2 에서, 호스트 (202) 는 순방향 링크 (208) 및 역방향 링크 (210) 를 포함하는 것으로 도시된 양방향 통신 채널 (206) 을 이용하여 클라이언트 (204) 에 접속된다. 그러나, 이들 채널은 데이터 전송이 순방향 또는 역방향 링크 동작 사이에서 효과적으로 스위칭되는 공통 콘덕터 세트에 의해 형성된다. 이는 현저하게 감소된 콘덕터의 수를 가능케 하며, 이동 전자 장치에 대해서와 같이 저 전력 환경에서의 고속 데이터 전송에 대한 현재의 접근법이 부딪친 여러 가지 문제점 중 하나를 바로 처리한다.
다른 곳에 설명된 바와 같이, 호스트는 본 발명의 이용으로 수혜를 받을 수 있는 장치의 몇몇 타입의 장치 중 하나를 포함한다. 예를 들어, 호스트 (202) 는 핸드헬드, 랩탑, 또는 유사한 이동 연산 장치 형태의 휴대용 컴퓨터일 수 있다. 호스트 (202) 는 PDA, 페이징 장치, 또는 많은 무선 전화 또는 모뎀 중 하나일 수도 있다. 다르게는, 호스트 (202) 는 휴대용 DVD 또는 CD 플레이어, 또는 게임 플레잉 장치와 같은 휴대용 엔터테인먼트 또는 프리젠테이션 장치일 수 있다.
또한, 호스트는, 클라이언트에 대해 고속 통신 링크가 요망되는, 널리 이용되거나 계획된 다양한 다른 상품에서 호스트 장치 또는 제어 소자로서 존재할 수 있다. 예를 들어, 호스트는 비디오 레코딩 장치로부터, 개선된 응답을 위한 저장 기반의 클라이언트 또는 프리젠테이션을 위한 고 해상도의 더 큰 스크린으로 고 데이터 레이트로 데이터를 전송하는데 이용될 수 있다. 적재물 목록 (onboard inventory) 또는 연산 시스템 및/또는 다른 가정용 장치에 대한 블루투스 접속을 을 포함하는 냉장고와 같은 기기는, 인터넷 또는 블루투스 접속 모드에서 동작하는 경우에 개선된 스크린 표시 성능을 가질 수 있거나, 전자 컴퓨터 또는 제어 시스템 (호스트) 이 캐비넷의 다른 곳에 존재하는 동안 실내 디스플레이 (클라이언트) 와 키패드 또는 스캐너 (클라이언트) 를 위한 배선 (wiring) 필요를 감소시킬 수 있다. 일반적으로, 당업자는 새롭게 추가되거나 기존의 커넥터 또는 케이블에 이용 가능한 제한된 수의 콘덕터를 이용하여 정보의 고 데이터 레이트 전송으로 구 장치를 개량하는 능력뿐만 아니라, 이 인터페이스의 이용으로 수혜 받을 수 있는 폭 넓은 여러 현대의 전자 장치 및 애플리케이션을 알 수 있을 것이다.
동시에, 클라이언트 (204) 는 최종 사용자에게 정보를 제공하거나, 사용자로부터 호스트에게 정보를 제공하기 위해 유용한 다양한 장치를 포함할 수 있다. 예를 들어, 고글 또는 안경에 통합된 마이크로 디스플레이, 모자 또는 헬맷에 내장된 프로젝션 장치, 창문 또는 윈드실드 (windshield) 등에서 차량에 내장된 소형 스크린 또는 홀로그래픽 소자, 또는 고품질의 사운드 또는 음악을 제공하기 위한 다양한 스피커, 헤드폰 또는 사운드 시스템이 있다. 다른 프리젠테이션 장치는 미팅, 또는 영화 및 텔레비젼 이미지를 위한 정보를 제공하는데 이용되는 프로젝터 또는 프로젝션 장치를 포함한다. 다른 예는, 사용자로부터의 접촉 또는 사운드 외에는 실제 "입력" 을 거의 갖지 않는 장치 또는 시스템으로부터 현저한 양의 정보를 전송하는 때에 호출될 수 있는 터치 패드 또는 민감한 장치, 음성 인식 입력 장치, 보안 스캐너 등이 된다. 또한, 컴퓨터 및 자동차 키트 또는 데스크탑 키트용 도킹 (docking) 스테이션과 무선전화용 홀더가 최종 사용자 또는 다른 장치 및 장비로의 인터페이스 장치로서 동작할 수 있으며, 특히 고속 네트워크가 연관된 경우, 데이터의 전송을 지원하기 위하여 클라이언트 (마우스와 같은 출력 또는 입력 장치) 또는 호스트를 채용할 수 있다.
그러나, 당업자는 본 발명이 이러한 장치에 한정되지 않으며, 저장 및 전송의 관점에서 또는 재생에 있어서 프리젠테이션의 관점에서, 고품질의 이미지 및 사운드를 최종 사용자에게 제공하기 위한, 이용을 위해 제안되거나 시장에 나온 많은 다른 장치가 존재함을 용이하게 인식할 것이다. 본 발명은 원하는 사용자 경험을 실현하기 위해 필요한 고 데이터 레이트를 수용하는 다양한 소자 또는 장치 사이에서 데이터 처리량을 증가시킴에 있어 유용하다.
발명된 MDDI 및 통신 신호 프로토콜은, (예를 들어) 호스트 프로세서, 제어기 또는 회로 소자와, 장치 또는 장치 하우징 또는 구조물 내의 디스플레이 사이의 상호접속을 간단화하는데 (내부 모드라 함), 그리고 외부 소자, 장치 또는 장비로 의 접속뿐만 아니라 신뢰성을 향상시키는데 (외부 모드라 함) 이용될 수 있다.
이 인터페이스 구조에 의해 이용되는 각각의 신호 쌍에 대한 집합 직렬 링크 데이터 레이트는 큰 크기 오더에 걸쳐 변화할 수 있고, 이는 시스템 또는 장치 설계자가 주어진 애플리케이션 또는 목적을 위해 비용, 전력, 구현 복잡도 및 디스플레이 업데이트 레이트를 용이하게 최적화할 수 있도록 한다. MDDI 의 속성은 디스플레이 또는 다른 프리젠테이션 장치 (타겟 클라이언트) 기술에 독립적이다. 인터페이스를 통하여 전송된 데이터 패킷의 타이밍은, 오디오-비디오 시스템의 결합된 타이밍 요구 사항 또는 디스플레이 장치, 사운드 시스템, 메모리 및 제어 소자와 같은 특정 클라이언트의 특징에 적응되도록 용이하게 조절될 수 있다. 이것은 시스템이 매우 적은 전력소모를 가지도록 할 수 있는 반면, 적어도 얼마간의 레벨에서 MDDI를 이용하기 위해 프레임 버퍼를 갖는 것은 다양한 클라이언트의 요구 조건은 아니다.
B. 인터페이스 타입
MDDI 는 통신과 컴퓨터 산업에서 발견되는, 적어도 4 개, 잠재적으로는 그 이상의 다소 구별된 인터페이스의 물리적 타입을 다루는 것으로 생각된다. 이것들은 단순히 타입 1, 타입 2, 타입 3 및 타입 4 로 식별되지만, 당업자에 의해 그들이 사용되는 애플리케이션 또는 연관된 산업에 따라 다른 레이블 또는 지시가 적용될 수도 있다. 예컨대, 단순한 오디오 시스템은 보다 복잡한 멀티미디어 시스템보다 더 적은 접속을 사용하고, "채널" 과 같은 특징을 다르게 참조할 수도 있는 등이다.
타입 1 인터페이스는 6-와이어, 또는 다른 타입의 도전체 또는 도전성 소자인터페이스로 구성되며, 이는 이동 전화 또는 무선 전화, PDA, 전자 게임, 및 CD 플레이어 또는 MP3 플레이어와 같은 휴대용 미디어 플레이어, 및 유사한 장치 또는 전자 소비자 기술의 비슷한 타입에 이용되는 장치에 적합하게 한다. 일 실시형태에서 인터페이스는, 디스플레이가 신속히 업데이트되도록 요구하지 않고, 내장된 MDDI 링크 제어기를 구비하지 않는 랩탑, 노트북 또는 데스크톱 개인용 컴퓨터, 및 유사한 장치 또는 애플리케이션에 더 적합한 8-와이어 (도전체) 인터페이스로서 구성될 수 있다. 이 인터페이스 타입은 또한 추가적인 2-와이어 유니버설 시리얼 버스 (USB) 인터페이스를 이용하여 구별될 수 있으며, 이는 대부분의 개인용 컴퓨터에서 볼 수 있는 기존 운영 체계 또는 발견된 소프트웨어 지원을 수용하는데 매우 유용하다.
타입 2, 타입 3, 및 타입 4 인터페이스는 고성능 클라이언트 또는 장치에 적합하고, 데이터 신호에 적절한 차폐와 저손실 전송을 제공하기 위한 추가적인 트위스티드 페어 (twisted-pair) 타입 도전체를 갖는 훨씬 더 복잡한 선로를 사용한다.
타입 1 인터페이스는 디스플레이, 오디오, 제어와 제한된 신호 정보를 포함할 수 있는 신호를 통과시키고, 일반적으로 고해상도 풀 레이트 비디오 데이터를 요구하지 않는 이동 클라이언트 또는 클라이언트 장치용으로 사용된다. 타입 1 인터페이스는 30 fps 에서의 SVGA (Super Video Graphics Array) 해상도 및 5.1 채널 오디오를 용이하게 지원할 수 있고, 최소 구성에서 총 3개의 와이어 쌍, 즉, 데 이터 송신용의 2 쌍 및 전력 전송용의 한 쌍만을 이용할 수 있다. 이러한 타입의 인터페이스는 주로, 장치 내에서 접속 및 신호 전송에 대해 USB 호스트가 통상적으로 이용 불가능한 이동 무선 장치와 같은 장치용으로 의도된다. 이 구성에서, 이동 무선 장치는 MDDI 호스트 장치이고, 일반적으로 프리젠테이션, 디스플레이 또는 재생을 위해 클라이언트에게 데이터를 전송하는 호스트로부터의 통신 링크 (순방향 트래픽 또는 링크) 를 제어하는 "마스터" 로서 동작한다.
이 인터페이스에서 호스트는 클라이언트에게, 특정 기간 동안 버스 (링크) 를 인수하고 역방향 패킷으로서 데이터를 호스트로 전송하는 것을 가능케 하는 특별한 명령 또는 패킷 타입을 전송함으로써 호스트에서 클라이언트로부터의 (역방향 트래픽 또는 링크) 통신 테이터의 수신을 가능하게 한다. 역방향 패킷이 도 4 에 도시되며, 여기서 캡슐화 패킷 (후술) 이라고 지칭되는 패킷 타입이, 역방향 링크를 생성시키면서, 전송 링크를 통한 역방향 패킷의 전송을 수용하기 위해 이용된다. 데이터에 대해 클라이언트를 폴링하기 위해 호스트에게 할당된 시간 간격은 호스트에 의해 미리 결정되고, 각각의 특정 애플리케이션의 요구사항에 기초한다. 이러한 타입의 반 듀플렉스 양방향 (half-duplex bi-directional) 데이터 전송은 클라이언트로부터의 정보 또는 데이터의 전송을 위해 USB 포트가 사용 가능하지 않은 경우에 특히 유용하다.
HDTV 타입 또는 유사한 고해상도가 가능한 고성능 디스플레이는 풀-모션 비디오를 지원하기 위해 약 1.5 Gbps 레이트 데이터 스트림을 요구한다. 타입 2 인터페이스는 병렬 2 비트 전송에 의해, 타입 3 은 병렬 4 비트 전송에 의해, 그리 고 타입 4 인터페이스는 병렬 8 비트 전송에 의해 고 데이터 레이트를 지원한다. 타입 2 와 타입 3 이 타입 1 과 동일한 케이블과 커넥터를 사용하지만, 휴대용 장치 상의 더 높은 성능 비디오 애플리케이션을 지원하기 위해 2 배 및 4 배의 데이터 레이트로 동작할 수 있다. 타입 4 인터페이스는 매우 높은 성능의 클라이언트 또는 디스플레이용으로 적합하며, 추가적인 트위스티드 페어 데이터 신호를 포함하는 조금 더 큰 케이블을 요구한다.
MDDI에 의해 이용된 프로토콜은 이용될 수 있는 가장 높은 데이터 레이트가 무엇인지를 교섭하여, 각각의 타입 1, 2, 3 또는 4 호스트가 여하한 타입 1, 2, 3 또는 4 클라이언트와 일반적으로 통신할 수 있도록 한다. 최소한의 성능의 장치라 할 수 있는 장치의 성능 또는 사용 가능한 특성이 링크의 성능을 설정하는데 사용된다. 원칙적으로, 호스트와 클라이언트 모두가 타입 2, 타입 3, 또는 타입 4 인터페이스를 이용할 수 있는 시스템에서조차도, 양자 모두는 타입 1 인터페이스로서 동작을 개시한다. 그 후, 호스트는 타겟 클라이언트의 성능을 결정하고, 특정 애플리케이션에 적당하도록, 타입 2, 타입 3 또는 타입 4 모드 중 하나로의 핸드오프 또는 재구성 동작을 교섭한다.
일반적으로, 호스트가 적절한 링크 레이어 프로토콜 (후술) 을 이용하고, 더 높은 해상도 표시 컨텐츠 (content) 을 위하는 등으로 더 높은 속도의 전송을 지원하기 위해 더 빠른 모드로 스텝 업 (step-up) 하거나 전력을 절약하기 위해 일반적으로 임의의 시간에 더 느린 모드로 스텝 다운하거나 또는 동작을 다시 재구성하는 것이 가능하다. 예를 들면, 시스템이 배터리와 같은 전원에서 AC 전원으로 스 위치할 때, 또는 디스플레이 미디어 소스가 더 낮거나 더 높은 해상도 형식으로 스위칭할 때 호스트는 인터페이스 타입을 변경할 수 있고, 또는 이들의 결합 또는 다른 조건이나 이벤트가 인터페이스 타입 또는 전송 모드 변경의 기초로서 고려될 수 있다.
또한, 시스템이 일 방향에 있는 일 모드와 다른 방향에 있는 다른 모드를 이용하여 데이터를 통신하는 것도 가능하다. 예를 들어, 타입 4 인터페이스 모드는 고속으로 디스플레이에 데이터를 전송하는데 이용될 수 있는 반면, 타입 1 모드가 키보드 또는 포인팅 장치와 같은 주변 장치로부터 호스트 장치로 데이터를 전송할 때 이용된다. 당업자는 호스트와 클라이언트가 상이한 레이트로 아웃 고잉 (outgoing) 데이터를 통신할 수도 있다는 것을 알 수 있을 것이다.
종종, MDDI 프로토콜의 사용자는 "외부" 모드와 "내부" 모드를 구별할 수 있다. 외부 모드는 하나의 장치 내의 호스트를 호스트로부터 약 2 미터 정도까지 떨어져 있는 장치 외부의 클라이언트로 연결시키기 위한 프로토콜 및 인터페이스의 사용을 말한다. 이 경우, 호스트는 양쪽 장치가 용이하게 모바일 환경에서 동작할 수 있도록 외부 클라이언트에게 전력을 보낼 수도 있다. 내부 모드는 호스트가 공통 하우징 또는 지지 프레임 또는 어떤 종류의 구조물 내부 등, 동일한 장치 내에 포함되는 클라이언트에 연결될 때를 말한다. 일 예는 클라이언트가 디스플레이 또는 디스플레이 드라이버, 또는 키패드나 터치-패드와 같은 입력 장치 또는 사운드 시스템이고, 호스트가 중앙 제어기, 그래픽 엔진, 또는 CPU 소자인 무선 전화 또는 다른 무선 장치, 또는 휴대용 컴퓨터 또는 게임 장치 내의 애플리케 이션일 것이다. 클라이언트가 외부 모드 애플리케이션에 대비하여 내부 모드 애플리케이션에서 호스트에 훨씬 더 가깝게 위치하기 때문에, 일반적으로 그와 같은 구성에서 클라이언트에 대한 전력 연결에 대한 상술한 요구사항은 없다.
C. 물리적 인터페이스 구조
호스트와 클라이언트 장치 사이에서 통신을 확립하기 위한 장치 또는 링크 제어기의 일반적인 배치가 도 5 및 도 6 에 도시된다. 도 5 및 도 6 에서, MDDI 링크 제어기 (402 및 502) 는 호스트 장치 (202) 내에 설치된 것으로 도시되고, MDDI 링크 제어기 (404 및 504) 는 클라이언트 장치 (204) 내에 설치된 것으로 도시된다. 이전과 같이, 호스트 (202) 는 일련의 콘덕터를 포함하는 양방향 통신 채널 (406) 을 이용하여 클라이언트 (204) 와 연결된다. 후술하는 바와 같이, 호스트와 클라이언트 링크 제어기 모두는, 호스트 제어기 (드라이버) 또는 클라이언트 제어기 (수신기) 중 하나에 응답하도록 설정, 조정되거나 프로그램될 수 있는 단일 회로 설계를 이용한 집적 회로로 제조될 수 있다. 이것은 단일 회로 장치의 더 큰 스케일 제조이기 때문에 더 낮은 비용을 제공한다.
도 6 에서, MDDI 링크 제어기 (502) 는 호스트 장치 (202') 내에 설치되는 것으로 도시되고, MDDI 링크 제어기 (504) 는 클라이언트 장치 (204') 내에 설치되는 것으로 도시된다. 이전과 같이, 호스트 (202') 는 일련의 도전체를 포함하는 양방향 통신 채널 (506) 을 이용하여 클라이언트 (204') 와 연결된다. 후술하는 바와 같이, 호스트와 클라이언트 링크 제어기 모두 단일 회로 설계를 이용하여 제조될 수 있다.
또한, MDDI 링크 또는 사용된 물리적 콘덕터를 통해, 디스플레이 장치와 같은 클라이언트와 호스트 사이에서 통과하는 신호들이 도 5 및 도 6 에 도시된다. 도 5 및 도 6 에서 도시된 바와 같이, MDDI 를 통하여 데이터를 전송하기 위한 주된 경로 또는 메커니즘은 MDDI_DataO+/- 및 MDDI_Stb+/-로 표시된 데이터 신호를 이용한다. 이들 각각은 케이블 내의 한 쌍의 차동 와이어를 통해 전송되는 저전압 데이터 신호이다. 인터페이스를 통해 전송된 각 비트에 대한 MDDI_Data0 쌍 또는 MDDI_Stb 쌍 중 하나에 대하여 단 하나의 천이가 있다. 이것은 전류 기반이 아니라 전압 기반 전송 메커니즘이어서, 정전류 소비는 거의 0 이다. 호스트는 클라이언트 디스플레이에 MDDI_Stb 신호를 구동시킨다.
데이터가 MDDI_데이터 쌍을 통해 순방향 및 역방향 모두로 흐를 수 있는, 즉, 양방향 전송 경로인 동안, 호스트는 데이터 링크의 마스터 또는 제어기이다. MDDI_Data0 및 MDDI-Stb 신호 경로는 잡음 무감성 (immunity) 을 극대화하기 위해 차동 모드에서 동작된다. 이러한 라인 상의 신호에 대한 데이터 레이트는 호스트에 의해 전송된 클록의 레이트에 의해 결정되고, 약 1kbps 에서 400 Mbps 이상까지의 범위에서 변할 수 있다.
타입 2 인터페이스는 타입 1 의 인터페이스 이외에 MDDI_Data1+/- 로 지칭된 추가적인 데이터 쌍 또는 콘덕터나 경로를 포함한다. 타입 3 인터페이스는 타입 2 인터페이스 이외에 MDDI_Data2+/- 및 MDDI_Data3+/- 로 지칭된 두 개의 추가적인 데이터 쌍 또는 신호 경로를 포함한다. 타입 4 인터페이스는 타입3 인터페이스 이외에 각각 MDDI_data4+/-, MDDI_Data5+/-, MDDI_Data6+/-, 및 MDDI_Data7+/- 로 지칭된 4 개의 데이터쌍 또는 신호 경로를 더 포함한다. 상기 인터페이스 구조의 각각에서, 호스트는 HOST_Pwr 및 HOST_Gnd 로 지정된 와이어 쌍 또는 신호를 사용하여, 클라이언트 또는 디스플레이에 전력을 보낼 수 있다. 아래에서 더 설명하는 바와 같이, 다른 모드에 대하여 이용 가능하거나 존재하는 것보다 더 적은 콘덕터를 채용하는 인터페이스 "타입" 이 사용되고 있을 때, 전력 전송은, 희망에 따라, MDDI_data4+/-, MDDI_Data5+/-, MDDI_Data6+/- 또는 MDDI_Data7+/- 콘덕터에 대한 몇몇 구조에 수용될 수 있다. 몇몇 애플리케이션은 다를 수도 있지만, 이러한 전력 전송은 일반적으로 외부 모드에 대해 사용되고, 내부 모드에 대해서는 일반적으로 필요하지 않다.
다양한 모드에 대한 MDDI 링크를 통해 호스트와 클라이언트 (디스플레이) 사이에 전송되는 신호의 개요를 인터페이스 타입에 따라, 아래의 표 1 에 나타낸다.
Figure 112007000702303-pct00001
또한 호스트로부터의 전송을 위한 HOST_Pwr/Gnd 접속은 일반적으로 외부 모드를 위해 제공된다는 점을 유의하라. 일반적으로 내부 애플리케이션 또는 동작 모드는 다른 내부 리소스로부터 직접적으로 전력을 끌어쓰는 클라이언트를 갖고, 전력 공급을 제어하기 위해 MDDI 을 이용하지 않으며, 이는 당업자에게 명백하고 여기에서는 더 상세하게 설명하지 않는다. 그러나, 당업자가 알 수 있는 바와 같이, 예를 들면 어떤 종류의 전력 제어, 동기화 또는 상호 접속 편의성을 위해 MDDI 를 통하여 전력이 공급되도록 허용하는 것은 물론 가능하다.
전술한 구조 및 동작을 구현하는데 사용되는 케이블링은 공칭적으로 1.5 미터 단위이며, 일반적으로 2 미터 이하이고, 3 쌍의 트위스트된 멀티 스트랜드 와이어의 콘덕터를 포함한다. 와이어 크기는 특정 크기에 한정되지는 않지만, 최대 총 종단 (end-to-end) 저항, 피트당 최대 커패시턴스, 각 쌍의 임피던스 및 크로스토크 (crosstalk) 에 대한 전기적 사양 또는 제한을 충족시켜야 한다.
추가적인 드레인 와이어로서, 호일 차폐 커버링이 랩핑 (wrapping) 되거나 다른 방식으로는, 여기서는 3 개인 전체 트위스트된 쌍의 세트 또는 그룹 및 드레인 와이어 상에 형성된다. 트위스티드 페어와 차폐 드레인 콘덕터는 클라이언트용 실드에 접속된 실드로 클라이언트 커넥터에서 종단되고, 당해 기술분야에서 잘 알려진 바와 같이, 전체 케이블을 커버하는 절연층이 있다. 와이어는 HOST_Gnd 와 HOST_Pwr; MDDI_Stb+ 와 MDDI_stb-; MDDI_ Data0+ 와 MDDI_Data0- ; MDDI_Datal+ 와 MDDI_Datal- 등과 같이 짝지어진다. 그러나, 당해 기술분야에서 알려진 바와 같이, 구체적 애플리케이션에 따라, 본 발명의 실시형태를 구현하기 위하여 다양한 콘덕터 및 케이블링 (cabling) 이 이용될 수 있다. 예를 들어, 몇몇 애플리케이션에서는 케이블을 보호하기 위해 보다 무거운 외부면 코팅 또는 심지어 금속 층이 이용될 수도 있는 반면, 다른 애플리케이션에서는 보다 얇고 평평한, 도전성의 리본 타입 구조가 적절할 수 있다.
이하 더 설명하는 바와 같이, 데이터 전송을 위한 내부의 접속 또는 상호접속 모드, 디바이스, 프로토콜, 장치 또는 기술로서 "내부 모드" 에 사용되는 경우, 하나 이상의 클라이언트가 단일 호스트 디바이스에 접속될 수 있는 것이 가능하다. 내부 모드 동작에 있어서, 이러한 타입의 구성을 갖는 것이 허용될 수 있다. 그러나, 이러한 상황에서, 하나의 클라이언트만이 MDDI 인터페이스에 대한 신호인 MDDI Data 신호를 호스트로 구동시키도록 구성되거나, 구동시키는 것이 가능할 수도 있다. 이 경우, 나머지 클라이언트 또는 클라이언트들은 호스트로부터의 신호의 수신기로서 동작하며 MDDI Data 신호에 대한 소스 또는 구동기로서 동작하지는 않는다.
단일 호스트를 갖는 다수의 클라이언트를 사용하기 위한 하나의 애플리케이션은 휴대 전화와 같은 무선 디바이스 상에서 LCD 패널과 같은 비디오 또는 비주얼 디스플레이 패널의 영역 내에 존재한다. 이러한 다양한 무선 디바이스들은 2 개의 LCD 패널을 갖도록 설계되고 있으며, 하나의 패널은 정보 또는 영상의 메인 또는 주요한 더 큰 디스플레이로서 사용되고, 더 작은 패널은, 전화가 스탠바이 상태거나 또는 전화에 걸려오는 호출을 대기하는 수동 모드인 경우와 같이 통상적으로 메인 또는 주 디스플레이가 사용되지 않는 동안 전화 상태, 호출자 ID, 시간, 또는 다른 기능에 사용된다.
여기서, 각각의 LCD 패널은, MDDI 호스트에 접속되는 MDDI 클라이언트를 포함하거나 MDDI 클라이언트에 접속될 수 있다. 메인 LCD 패널은 패킷을 호스트에 역전송할 수 있지만, 보조 LCD 패널은 호스트로부터 패킷을 수신하기만 할 것이다. 이것은 내부 모드 애플리케이션이기 때문에, 호스트는 클라이언트 디바이스의 특성을 미리 인식하고 있을 것이므로, 보조 패널이 그 능력 또는 상태를 호스트에 역전송할 수 있는 것은 강제적이지 않다.
데이터 전송 구성에서 하나 이상의 클라이언트를 사용하는 예 (이 경우에는 2 클라이언트) 가 도 98 에 도시되어 있다. 도 98 에서는, 호스트 (9800) 가 콘덕터, 케이블 또는 버스 (9802 및 9804) 를 통해 각각 클라이언트 (9806 및 9808) 에 접속된다. 각각의 MDDI_Data 및 MDDI_Stb 쌍은 본 명세서의 다른 부분에서 설명한 바와 같이 동작하며, 패킷 및 전송 관계를 갖는 본 발명의 신호 프로토콜 및 이하 설명하는 메커니즘을 사용하여, 고 레이트로 데이터를 전송하고 특정 커맨드 또는 세팅을 통신하거나 프리젠테이션 능력을 확인하기 위해 클라이언트로부터 정보를 요청하는 것 등을 할 수 있다. 본 실시형태에서, 클라이언트 (9806) 는, 호스트 또는 호스트 및 클라이언트를 사용하는 몇몇 타입의 기구, 설비 또는 장치에 대해 "주" 또는 메인 디스플레이 패널로 동작하는 몇몇 타입의 LCD 디스플레이 디바이스 또는 패널에 결합되거나, 일부로서 또는 그 위에 형성되거나 또는 그에 접속된다. 한편, 클라이언트 (9808) 는, 호스트 또는 호스트 및 클라이언트를 사용하는 몇몇 디바이스에 대해 "주" 또는 메인 디스플레이 패널로서 동작하는 몇몇 타입의 LCD 디스플레이 디바이스 또는 패널에 일부로서 또는 그 위에 형성되거나 그에 접속된다.
2 디스플레이 소자 또는 디바이스는 동일할 필요가 없고 동일한 타입 또는 특성일 필요조차 없으며, 원하는 용도인 2 개의 개별 디스플레이 디바이스면 된다. 예를 들어, 상이한 타입의 LCD 패널일 수도 있고, 하나는 LCD 기반 디스플레이 소자이고 다른 하나는 소망에 따라 CRT 에서 바이오루미네슨스에 이르는 상이한 타입의 디스플레이 기술을 사용할 수 있다. 도 98 에서, 각각의 클라이언트는 각각 상이한 버스 또는 세트의 콘덕터 (9810 및 9812) 를 통해 통신하여, 정보 및/또는 커맨드를 각각의 디스플레이 소자 또는 패널에 전송하거나 정보 또는 신호를 제어한다. 설명한 바와 같이, 클라이언트는 패널 제어기 (9814 및 9816) 를 구현하는데 사용되는 회로의 일부로서 형성될 수 있고, 또는 회로, 콘덕터, 또는 패널 영역 위 또는 내부의 소자의 일부로서 고정되거나 형성될 수 있다.
회로 또는 패널 소자를 형성할 때 다른 소자에 대한 적절한 트랜지스터의 형성, 또는 회로 모듈 등의 사후 부착 등 당업자에게 자명한, 패널에 클라이언트를 배치하는 몇몇 가능한 시나리오가 존재한다. 또한, 클라이언트 그 자체 및 패널 제어기는 일부 애플리케이션에서는 개별 소자일 수 있고, 또는 다른 애플리케이션에서는 단일 모듈 또는 집적 회로 콤포넌트, 디바이스 또는 소자로서 생성될 수도 있다. 패널을 가로질러 물리적 어레이로 위치되는 픽셀 또는 이미지 디스플레이 소자는 LCD 패널을 형성하며, 2 개의 패널 중 하나는 메인 또는 주 LCD 패널로서 동작하는 패널이고 다른 하나는 보조적이거나, 부가적이거나 예비적인 (리던던시에 대한 소망에 따라 백업일 수 있는) 패널이다. 따라서, 주 (또는 메인) 클라이언트와 보조 클라이언트를 결합하였다. 임의의 소정 시간 또는 시간 주기에, 하나의 클라이언트만이 호스트와 정보를 통신하거나 신호를 역전송한다. 그렇지 않으면, 호스트는, 정보가 상이한 클라이언트로부터 발신되고 있는지 또는 어떠한 클라이언트로부터 발신되고 있는지를 정확하게 인식하지 못한다. 프로토콜의 다른 버전은 소망에 따라 클라이언트 사이를 스위칭하거나 더 정제된 제어를 수용하는 방식으로 클라이언트 ID 또는 식별자 수신을 사용할 수도 있다. 본 명세서에서 나타낸 바와 같이 패킷에는 많은 보류 ID 부분이 존재한다. 통상적으로, 보조 패널의 사용은 이 시점에 동일한 타입의 복귀 신호 또는 호스트와의 통신을 요구하거나 이용하지 않는다. 그러나, 본 발명은 소망에 따라 커맨드에 응답하여 또는 실패 모드 등에서 특정한 주기의 시간 동안 주 및 보조 상태의 이러한 제어 또는 교대를 금지하지는 않는다. 또한, 동작의 내부 모드에 대해 수행되는 경우, 디스플레이 소자의 특성은 일반적으로 미리 인식되고, 신규의 주 디스플레이로서 선택될 수 없다면 보조 디스플레이 부분에서 정보의 역방향 링크 통신이 단순히 요구되지는 않으며, 이 경우 이전의 주 디스플레이는 더이상 그 모드에서는 사용되지 않는다.
D. 데이터 타입 및 레이트
모든 범위의 사용자 경험과 애플리케이션에 유용한 인터페이스를 달성하기 위해서, MDDI 는 다양한 클라이언트와 디스플레이 정보, 오디오 트랜스듀서, 키보드, 포인팅 장치, 및 제어 정보와 함께 이동 통신, 연산 또는 디스플레이 장치에 집적되거나 함께 동작할 수 있는 다수의 다른 입력 또는 출력 장치, 및 그 조합들에 대한 지원을 제공한다. MDDI 는 최소 숫자의 케이블 또는 콘덕터를 사용하여 순방향 또는 역방향 링크에서 호스트와 클라이언트 사이를 가로지르는 데이터 스트림의 다양한 잠재적인 타입을 수용할 수 있도록 설계된다. 등시성 (isochronous) 스트림과 비동기 스트림 (업데이트) 모두 지원된다. 모든 데이터 레이트가, 채용된 최대 직렬 레이트와 데이터 쌍의 개수에 의해 제한되는 최대 희망 MDDI 링크 레이트보다 이하인 한 데이터 타입의 다양한 조합이 가능하다. 이것들은 아래의 표 2 및 표 3 에 나열된 것을 포함할 수 있으나, 이에 제한되지는 않는다.
호스트로부터 클라이언트로의 전송
등시성 비디오 데이터 720x480, 12 비트, 30f/s ~124.5 Mbps
등시성 스테레오 오디오 데이터 44.1kHz, 16 비트, 스테레오 ~ 1.4 Mbps
비동기 그래픽 데이터 800x600, 12비트, 10f/s, 스테레오 ~115.2 Mbps
비동기 제어 최소 << 1.0 Mbps
클라이언트로부터 호스트로의 전송
등시성 음성 데이터 8 kHz, 8 비트 << 1.0 Mbps
등시성 비디오 데이터 640x480, 12 비트, 24f/s ~ 88.5 Mbps
비동기 상태, 사용자 입력 등 최소 << 1.0 Mbps
인터페이스는 고정된 것이 아니라 확장성이 있어서 장래의 시스템 유연성을 위해, 사용자 정의 데이터를 포함하는 다양한 정보 "타입" 의 전송을 지원할 수 있다. 수용될 데이터의 특정 예는 : 전체 또는 부분적인 스크린 비트맵 필드 중 하나의 형태의 풀-모션 비디오 또는 압축 비디오; 전력을 보존하고 구현 비용을 줄이기 위한 낮은 레이트에서의 정적 (static) 비트맵; 다양한 해상도 또는 레이트의 PCM 또는 압축 오디오 데이터; 포인팅 장치 위치 및 선택, 및 아직 정의되지 않은 성능을 위한 사용자 정의 가능 데이터이다. 그런 데이터는 또한 장치 능력을 검출하고 동작 파라미터를 설정하기 위한 제어 또는 상태 정보와 함께 전송될 수도 있다.
본 발명의 실시형태는 다음을 포함하지만, 그에 한정되지는 않는 데이터 전송에서의 사용을 위한 기술 분야를 진보시킨다: 영화 감상 (비디오 디스플레이 및 오디오); 제한된 개인용 뷰 (그래픽 디스플레이, 종종 비디오와 오디오가 결합됨)를 갖는 개인용 컴퓨터의 사용; PC, 콘솔, 또는 개인용 장치 (동작 그래픽 디스플레이, 또는 합성 비디오 및 오디오)상의 비디오 게임 플레잉; 정지 디지털 화상용의 카메라나 디지털 비디오 이미지 캡쳐를 위한 캠코더, 비디오 전화 (양방향 저 레이트 비디오 및 오디오) 형태의 장치를 사용한 인터넷 "서핑"; 비디오 모니터, 키보드, 및 마우스에 연결된 데스크 탑 도킹 스테이션에 도킹되거나 프리젠테이션하기 위한 프로젝터로 도킹된 전화, 컴퓨터 또는 PDA 이용; 및 무선 포인팅 장치 및 키보드 데이터를 포함하는, 셀 폰, 스마트 폰, 또는 PDA 를 이용한 생산성 향상 또는 엔터테인먼트용.
아래에서 설명될 고속 데이터 인터페이스는 일반적으로 와이어-라인 또는 케이블 타입 링크로서 구성된 통신 또는 전송 링크를 통해 대량의 A-V 타입 데이터를 제공하는 관점에서 제시된다. 그러나, 데이터 전송의 원하는 레벨을 유지할 수 있다면, 신호 구조, 프로토콜, 타이밍 또는 전송 메커니즘은 광학 또는 무선 매체의 형태로 링크를 제공하기 위해 조정될 수 있음은 자명할 것이다.
MDDI 신호는 기본 신호 프로토콜 또는 구조에 대해 공통 프레임 레이트 (Common Frame Rate; CFR) 로 알려진 개념을 사용한다. 공통 프레임 레이트를 사용하는 배후의 개념은, 다중 스트림에 대한 프레임 타이밍 또는 클록을 유도하는데 사용될 수 있는 레이트로 서브 프레임 헤더 패킷을 전송함으로써 동시적 등시성 데이터 스트림에 대한 동기화 펄스를 제공하는 것이다. 서브 프레임 헤더 패킷이 전송되는 레이트는 공통 프레임 레이트이다. 클라이언트 장치는 이러한 공통 프레임 레이트를 시간 레퍼런스로 사용할 수 있다. 낮은 CFR 은 서브 프레임 헤더를 송신하기 위한 오버헤드를 감소시킴으로써 채널 효율을 증가시킨다. 한편 높은 CFR 은 대기 시간을 감소시키고, 오디오 샘플을 위한 더 작은 유연한 데이터를 허용한다. 본 발명의 인터페이스의 CFR 은 동적으로 프로그래밍할 수 있고, 특정 애플리케이션에 사용되는 등시성 스트림에 적합한 많은 값 중 하나로 설정될 수도 있다. 즉, CF 값은 소망에 따라, 주어진 클라이언트와 호스트 구성에 가장 맞도록 선택된다.
조정 또는 프로그램 가능한, 서브 프레임 당 요구되는 일반적인 바이트의 수는 비디오 또는 마이크로 디스플레이용 등의 애플리케이션에 가장 사용되기 쉬운 등시성 데이터 스트림에 대해 표 4에서 도시된다.
Figure 112007000702303-pct00002
서브 프레임 당 바이트의 분수 (fractional) 카운트는 단순한 프로그래밍 가능 M/N 카운터 구조를 이용하여 용이하게 획득된다. 예를 들어, 서브 프레임 당 26-2/3 바이트의 카운트는, 26 바이트를 포함하는 하나의 서브 프레임 후에 각각 27 바이트를 포함하는 2 개의 서브 프레임을 전송함으로써 구현된다. 서브 프레임 당 정수 개의 바이트를 생성하기 위해 더 작은 CFR 이 선택될 수도 있다. 그러나, 일반적으로 말하면, 하드웨어에서 단순한 M/N 카운터를 구현하는 것은, 본 발명의 실시형태의 일부 또는 모두를 구현하는데 사용된 집적 회로 칩 또는 전자 모듈 내에서 더 큰 오디오 샘플 FIFO 버퍼에 필요한 영역보다 더 적은 영역을 요구해야만 한다.
상이한 데이터 전송 레이트와 데이터 타입의 효과를 설명하는 예시적 애플리케이션은 가라오케 (Karaoke) 시스템이다. 가라오케에 대하여, 시스템에서 최종 사용자 또는 사용자가 음악 비디오 프로그램을 따라 노래를 부른다. 노래의 가사가 스크린상의 어딘가, 통상적으로 바닥에 표시되어 사용자는 노랫말과 대강의 노래 타이밍을 안다. 이 애플리케이션은 빠르지 않은 그래픽 업데이트를 하는 비디오 디스플레이와 사용자 음성 또는 음성과 스트레오 오디오 스트림의 혼합을 요구한다.
300 Hz의 공통 프레임 레이트를 가정한다면, 각각의 서브 프레임은 클라이언트로의 순방향 링크를 통한 92,160 바이트의 비디오 컨텐츠와 588 바이트의 오디오 컨텐츠 (스테레오에서, 147 16-비트 샘플을 기초로 함) 로 구성되고, 평균 26.67 (26-2/3) 바이트의 음성이 마이크에서부터 이동 가라오케 기계까지 다시 전송된다. 비동기 패킷은, 가능하다면 머리에 설치되는 (head mounted) 디스플레이인 클라이언트와 호스트 사이에서 전송된다. 이것은 1 초 간격 또는 주기의 1/30 번째에서 가사가 있는 텍스트로 업데이트되는 스크린의 1/4 높이를 포함하고, 가사가 있는 텍스트가 업데이트되지 않을 때 서브 프레임에서 전송되는 다른 잡다한 제어 및 상태 명령을 포함한다.
표 5 는 가라오케의 예에 대하여 어떻게 데이터가 공통 프레임 내에 할당되는지를 도시한다. 사용되고 있는 총 레이트는 약 279 Mbps 로 선택된다. 280 Mbps 보다 조금 높은 레이트는, 수시 (occasional) 제어와 상태 메시지의 사용을 허용하는 서브 프레임당 약 400 바이트의 다른 데이터가 전송되는 것을 허용한다.
엘리먼트 레이트 서브 프레임 당 오버헤드 바이트 서브 프레임 당 미디어 바이트
640 x 480 픽셀 및 30 fps 의 뮤직 비디오 2* 28 = 56 92160
640 x 120 픽셀 및 1 fps 의 가사 텍스트. 1/30 초, 10 서브 프레임마다 업데이트됨. 28 23040
44,100 sps, 스테레오, 16 비트의 CD 오디오 2 * 16 = 32 588
8,000 sps, 모노, 8 비트의 음성 28 + 8 + 8 + (4*16) + (3*27) = 125 26.67 (최대 27)
서브 프레임 헤더 22
총 바이트/CF 263 115815
총 레이트 (Mbps) (263+115815)*8*300 = 278.5872
Ⅲ. (계속) 고 레이트 디지털 데이터 인터페이스 시스템 구조
E. 링크 계층
MDDI 고속 직렬 데이터 신호를 이용하여 전송되는 데이터는, 차례로 링크되는 시간 다중화된 패킷의 스트림으로 구성된다. 송신 장치가 전송하기 위한 데이터를 가지지 않을 때도, 일반적으로 MDDI 링크 제어기는 필러 패킷을 자동적으로 전송하며, 그에 따라 패킷의 스트림을 유지한다. 간단한 패킷 구조의 사용은 비디오와 오디오 신호 또는 데이터 스트임에 대해 신뢰할 만한 등시성 타이밍을 보장한다.
패킷의 그룹이 서브 프레임이라고 불리는 신호 엘리먼트 또는 구조 내에 포함되고, 서브 프레임의 그룹은 미디어 프레임이라 불리는 신호 엘리먼트 또는 구조 내에 포함된다. 그들 각각의 크기와 데이터 전송 용도에 따라, 서브 프레임은 하나 이상의 패킷을 포함하고, 미디어 프레임은 하나 이상의 서브 프레임을 포함한다. 여기에서 보여진 실시형태에 채용된 프로토콜에 의해 제공되는 가장 큰 서브 프레임은 232-1 또는 4,294,967,295 바이트 정도이고, 그러면 가장 큰 미디어 프레임 사이즈는 216-1 또는 65,535 서브프레임 정도가 된다.
특별한 서브 프레임 헤더 패킷은 아래 설명된 것처럼, 각각의 서브 프레임 시작에 나타나는 고유 식별자를 포함한다. 그 식별자는 또한 호스트와 클라이언트 사이에서 통신이 시작될 때 클라이언트 장치에서 프레임 타이밍을 획득하기 위해 사용된다. 링크 타이밍 획득은 아래에서 더 상세하게 설명된다.
통상적으로, 디스플레이 스크린은 풀 모션 비디오가 디스플레이되고 있을 때 미디어 프레임당 한번 업데이트된다. 디스플레이 프레임 레이트는 미디어 프레임 레이트와 동일하다. 링크 프로토콜은, 희망 애플리케이션에 따라, 전체 디스플레이 상의 풀-모션 비디오 또는 정적 이미지에 의해 둘러싸인 작은 영역의 풀-모션 비디오 컨텐츠를 지원한다. 웹 페이지 또는 이메일을 보는 것과 같은 몇몇의 저전력 이동 애플리케이션에서, 디스플레이 스크린은 가끔씩만 업데이트될 필요가 있을 수 있다. 그 상황에서, 전력 소비를 최소로 하기 위해 단일 서브 프레임을 송신하고 링크를 셧다운하거나 비활성화하는 것이 유리하다. 인터페이스는 스테레오 비젼과 같은 효과도 지원하고, 그래픽 원시 함수 (primitive) 를 핸들링한다.
서브프레임은 시스템이 주기적으로 높은 우선 순위 패킷의 송신을 인에이블 하도록 허용한다. 이는 동시 등시성 스트림이 데이터 버퍼링의 최소량과 공존할 수 있도록 한다. 이것은 표시 프로세스에 제공되는 하나의 유익한 실시형태로, 다수의 데이터 스트림 (비디오, 제어, 상태, 포인팅 장치 데이트 등) 이 본질적으로 공통 채널을 공유할 수 있도록 한다. 그것은 상대적으로 적은 신호를 이용하여 정보를 전송한다. 또한, 이는 CRT 모니터 또는 다른 클라이언트-기술-특정 동작을 위한 수평 동기 펄스 및 블랭킹 (blanking) 간격과 같은 디스플레이-기술-특정 동작을 인에이블 한다.
F. 링크 제어기
도 5 및 도 6 에 도시된 MDDI 링크 제어기는 MDDI 데이터와 스트로브 신호를 수신하기 위해 이용되는 차동 라인 수신기를 제외하고는 완벽한 디지털 구현을 위해 제조되거나 조립된다. 그러나, CMOS 타입 ID 를 만들 때 등에서, 차동 라인 드라이버 및 수신기도 링크 제어기와 동일한 디지털 집적 회로에서 구현될 수 있다. 비트 회복 또는 링크 제어용 하드웨어 구현을 위해 어떤 아날로그 기능 또는 위상 잠금 루프 (Phase Lock Loop; PLL) 도 요구되지 않는다. 호스트 및 클라이언트 링크 제어기는 링크 동기화용 상태 머신을 포함하는 클라이언트 인터페이스를 제외하고는, 매우 유사한 기능을 보유한다. 그러므로, 본 발명의 실시형태는 호스트 또는 클라이언트 중 하나로서 구성될 수 있는 단일 제어기 설계 또는 회로를 만들 수 있다는 실제적인 이익을 허용하며, 이는 전체로서, 링크 제어기에 대한 제조 비용을 절감한다.
Ⅳ. 인터페이스 링크 프로토콜
A. 프레임 구조
패킷 전송용 순방향 링크 통신을 구현하기 위해 사용된 신호 프로토콜 또는 프레임 구조가 도 7 에 도시된다. 도 7 에 도시된 바와 같이, 정보 또는 디지털 데이터는 패킷으로 알려진 엘리먼트로 그룹화된다. 다수의 패킷은 다시 "서브 프레임" 이라 하는 것을 형성하기 위해 함께 그룹화되고, 다수의 서브 프레임은 다시 "미디어" 프레임을 형성하기 위해 함께 그룹화된다. 프레임 형성과 서브 프레임 전송을 제어하기 위해, 각 서브 프레임은 서브 프레임 헤더 패킷 (Sub-frame Header Packet; SHP) 이라 하는 특별히 미리 정의된 패킷으로 시작한다.
호스트 장치는 주어진 전송에 대해 사용될 데이터 레이트를 선택한다. 이 레이트는 호스트의 최대 전송 능력 또는 호스트에 의해 소스로부터 검색되고 있는 데이터, 및 데이터가 전송되고 있는 클라이언트나 다른 장치의 최대 능력 모두에 기초하여 호스트 장치에 의해 동적으로 변경될 수 있다.
MDDI 또는 진보적인 신호 프로토콜을 가지고 동작하기 위해서 설계되거나 동작할 수 있는 수신 클라이언트 장치는, 사용될 수 있는 데이터 타입 및 지원되는 특성 뿐만 아니라 사용할 수 있는 최대 또는 현재 최대 데이터 전송 레이트, 또는 사용되어질 수 있는 더 느린 최소 레이트를 결정하도록 호스트에 의해 질의 (query) 될 수 있다. 이 정보는, 아래에서 더 설명되는 바와 같이, 클라이언트 능력 패킷 (Client Capability Packet; DCP) 을 사용하여 전송될 수 있다. 클라이언트 디스플레이 장치는 미리 선택된 최소 데이터 레이트에서 또는 최소 데이터 레이트 범위 내에서 인터페이스를 사용하여 다른 장치와 통신하거나 데이터를 전송할 수 있고, 호스트는 클라이언트 장치의 전체 능력을 결정하기 위해 이 범위 내의 데이터 레이트를 이용하여 질의를 수행할 것이다.
비트맵의 본질 (nature) 과 클라이언트의 비디오 프레임 레이트 능력을 정의하는 다른 상태 정보는 상태 패킷으로 호스트에 전송할 있어, 호스트가 임의의 시스템 제한 내에서 실용성에 따라 또는 희망에 따라 효율적 또는 최적으로 인터페이스를 구성할 수 있다.
호스트는 현재의 서브 프레임 내에 (더 이상) 전송될 데이터 패킷이 없을 때, 또는 호스트가 순방향 링크용으로 선택된 데이터 송신 레이트와 보조를 맞추기에 충분한 레이트로 전송할 수 없을 때, 호스트는 필러 (filler) 패킷을 전송한다. 각 서브 프레임이 서브 프레임 헤더 패킷으로 시작하기 때문에, 이전의 서브 프레임의 종단은 이전의 서브 프레임을 정확하게 채우는 패킷 (필러 패킷인 경우가 대부분) 을 포함한다. 패킷 자체를 보유할 데이터 공간이 부족한 경우, 대체로 필러 패킷은 서브 프레임 내의, 또는 다음의 이전 서브 프레임의 종단 그리고 서브 프레임 헤더 패킷 전의 마지막 패킷이 된다. 그 서브 프레임 내에서 송신될 각 패킷에 대한 서브 프레임 내에 충분한 공간이 남아 있도록 보장하는 것이 호스트 장치 내에서 제어 동작의 임무이다. 동시에, 호스트 장치가 데이터 패킷의 전송을 촉발하면, 호스트는 데이터 언더 런 (under-run) 조건을 야기시키지 않고 프레임 내에서 그 사이즈의 패킷을 성공적으로 완료할 수 있어야 한다.
실시형태의 일 태양에서, 서브 프레임 송신은 두 가지 모드를 가진다. 한 모드는 라이브 비디오 및 오디오 스트림을 송신하기 위해 사용되는, 주기적 서브 프레임 모드, 또는 주기적 타이밍 에포크 (epoch) 이다. 이 모드에서, 서브 프레임 길이는 영 (0) 이 아닌 것으로 정의된다. 두 번째 모드는 새로운 정보가 사용 가능할 때에 클라이언트에게 비트맵 데이터를 제공하도록 프레임이 사용되는 비동기 또는 비 주기 모드이다. 이 모드는 서브 프레임 헤더 패킷에서 서브 프레임 길이를 0 으로 설정하여 정의된다. 주기 모드를 사용할 때, 서브 프레임 패킷 수신은 클라이언트가 순방향 링크 프레임 구조에 동기화될 때 개시할 수 있다. 이것은 도 49 또는 도 63 에 대하여 아래에서 설명된 상태도에 따라 정의된 "인 싱크 (in sync)" 상태에 해당한다. 비동기 비 주기 서브 프레임 모드에서, 수신은 제 1 서브 프레임 헤더 패킷이 수신된 후에 개시한다.
B. 전체 패킷 구조
인터페이스가 확장가능하고 추가적인 패킷 구조가 소망에 따라 추가될 수 있음을 유념하여, 본 실시형태에 의해 구현된 통신 또는 신호 프로토콜, 또는 데이터를 전송하는 방법 또는 수단을 공식화하기 위해 사용된 패킷의 형식 또는 구조가 아래 제시된다. 패킷은 인터페이스에서의 그 기능, 즉 그들이 전송하거나 연관된 명령, 정보, 값 또는 데이터의 관점에서 상이한 "패킷 타입" 으로 레이블링 또는 분류된다. 그러므로, 각 패킷 타입은 전송되고 있는 패킷과 데이터를 조작하는 데 사용되는 주어진 패킷에 대하여 미리 정의된 패킷 구조를 나타낸다. 자명한 바와 같이, 패킷은 미리 선택된 길이를 가지거나, 그 기능에 따라 변화하거나 동적으로 변경할 수 있는 길이를 가질 수 있다. 또한 패킷은, 프로토콜이 표준으로 수용되는 동안 변경되는 것과 같이, 여전히 동일한 기능이 실현되더라도, 상이한 이름을 가질 수 있다. 다양한 패킷에서 사용된 바이트 또는 바이트 값은 멀티 비트 (8- 또는 16- 비트) 무부호 (unsigned) 정수로 구성된다. 채용된 패킷의 요약은 그들의 "타입" 지정과 함께 타입 순으로 나열되고, 표 6a 내지 표 6b 에 도시된다.
각 표는 용이한 설명과 이해를 위해 전체적인 패킷 구조 내에서의 패킷의 일반적인 "타입" 을 나타낸다. 이러한 그룹화에 의해 본 발명에 대하여 부과되거나 표현되는 어떠한 제한이나 다른 영향은 없으며, 패킷은 소망에 따라 많은 다른 방식으로 조직될 수 있다. 패킷의 전송이 유효한 것으로 생각되는 방향도 표시된다.
링크 제어 패킷
패킷 이름 패킷 타입 순방향에서 유효 역방향에서 유효
서브 프레임 헤더 패킷 15359 x
필러 패킷 0 x x
역방향 링크 캡슐화 패킷 65 x
링크 셧다운 패킷 69 x
디스플레이 전력 상태 패킷 75 x
순방향 오디오 채널 인에이블 패킷 78 x
수행 타입 핸드오프 패킷 77 x
라운드 트립 지연 측정 패킷 82 x
순방향 링크 스큐 교정 패킷 83 x
기본 미디어 스트림 패킷
패킷 이름 패킷 타입 순방향에서 유효 역방향에서 유효
비디오 스트림 패킷 16 x x
오디오 스트림 패킷 32 x x
보류 스트림 패킷 1 - 15, 18 - 31, 33 - 55 x x
사용자 정의 스트림 패킷 56 -63 x x
컬러 맵 패킷 64 x x
역방향 오디오 샘플 레이트 패킷 79 x
투명 컬러 및 마스크 설정 패킷 81 x
클라이언트 상태 및 제어 패킷
패킷 이름 패킷 타입 순방향에서 유효 역방향에서 유효
클라이언트 능력 패킷 66 x
키보드 데이터 패킷 67 x x
포인팅 디바이스 데이터 패킷 68 x x
클라이언트 요청 및 상태 패킷 70 x
디지털 콘텐츠 보호 오버헤드 패킷 80 x x
요청 VCP 특성 패킷 128 x
VCP 특성 응답 패킷 129 x
설정 VCP 특성 패킷 130 x
요청 유효 파라미터 패킷 131 x
유효 파라미터 응답 패킷 132 x
요청 특정 상태 패킷 138 x
유효 상태 응답 리스트 패킷 139 x
개인 디스플레이 능력 패킷 141 x
클라이언트 에러 리포트 패킷 142 x
스케일링된 비디오 스트림 능력 패킷 143 x
클라이언트 식별 패킷 144 x
교대 디스플레이 능력 패킷 145 x
레지스터 액세스 패킷 146 x x
향상된 그래픽 및 디스플레이 패킷
패킷 이름 패킷 타입 순방향에서 유효 역방향에서 유효
비트맵 블록 전송 패킷 71 x
비트맵 영역 채움 패킷 72 x
비트맵 패턴 채움 패킷 73 x
판독 프레임 버퍼 패킷 74 x
스케일링된 비디오 스트림 능력 패킷 143 x
스케일링된 비디오 스트림 설정 패킷 136 x
스케일링된 비디오 스트림 확인응답 패킷 137 x
스케일링된 비디오 스트림 패킷 18 x
이 텍스트 내의 다른 설명으로부터 명백한 것은, 서브 프레임 헤더, 필러, 역방향 캡슐화, 링크 셧다운, 클라이언트 능력, 및 클라이언트 요청 및 상태 패킷 각각은 외부 모드 동작에 대한 통신 인터페이스의 다양한 실시형태에서 매우 중요한 것으로 고려되거나 요구되기까지 한다. 그러나, 역방향 캡슐화, 링크 셧다운, 클라이언트 능력, 및 클라이언트 요청 및 상태 패킷은 내부 모드 동작에서는 선택적인 것으로 고려될 수 있다. 이것은, 감소된 세트의 통신 패킷 및 그에 대응하는 단순한 제어 및 타이밍으로 매우 고속의 데이터 통신을 가능케하는 또 다른 타입의 MDDI 프로토콜을 생성한다.
패킷은 공통 기본 구조 또는 패킷 길이 필드, 패킷 타입 필드, 데이터 바이트 및 CRC 필드를 포함하는 최소 필드의 전체 세트를 포함하며, 이는 도 8 에 도시된다. 도 8 에 도시된 바와 같이, 패킷 길이 필드는, 멀티 비트 또는 바이트 값 형태로 패킷 내 총 비트 수 또는 패킷 길이 필드와 CRC 필드 사이의 그 길이를 특정하는 정보를 포함한다. 일 실시형태에서, 패킷 길이 필드는 16-비트 또는 2-바이트 폭의 무부호 정수를 포함하고, 이는 패킷 길이를 특정한다. 패킷 타입 필드는 패킷 내에 포함되는 정보의 타입을 지정하는 또 다른 멀티 비트 필드이다. 예시적인 실시형태에, 이는 16-비트 무부호 정수의 형태의 16-비트 또는 2바이트 폭의 값이고, 디스플레이 능력, 핸드오프, 비디오 또는 오디오 스트림, 상태 등과 같은 데이터 타입을 특정한다.
세 번째 필드는 그 패킷의 일부로 호스트와 클라이언트 장치 사이에 전송되거나 보내지고 있는 비트 또는 데이터를 포함하는 데이터 바이트 필드이다. 데이터의 형식은, 전송되고 있는 데이터의 구체적인 타입에 따라서 각각의 패킷 타입에 대해 구체적으로 정의되고, 그 자체의 형식 요구사항에 의해 일련의 추가적인 필드로 분리될 수 있다. 즉, 각각의 패킷 타입은 이 부분 또는 필드에 대해 정의된 형식을 가질 것이다. 최종 필드는, 데이터 바이트, 패킷 타입, 및 패킷 길이 필드에 대해 계산된 16-비트 순환 중복 검사의 결과를 포함하는 CRC 필드이며, 이는 패킷 내 정보의 무결성 (integrity) 을 확인하는데 사용된다. 즉, CRC 필드 자체를 제외하고 전체 패킷에 걸쳐 계산된다. 클라이언트는 일반적으로 검출된 CRC 오류의 총 수 (count) 를 유지하고, 클라이언트 요청 및 상태 패킷 내에서 이 카운트를 다시 호스트에 보고한다 (이하를 참조).
일반적으로, 이러한 필드 폭과 조직은 2-바이트 필드가 짝수 바이트 경계에 정렬되고, 4-바이트 필드가 4 바이트 경계에 정렬됨을 유지하도록 설계된다. 이것은 패킷 구조가 대부분의 또는 일반적으로 이용되는 프로세서 또는 제어 회로에 대해 만나게 되는 데이터 타입 정렬 규칙을 위반함이 없이 호스트와 클라이언트의 또는 이와 관련된 메인 메모리 공간에 용이하게 구축될 수 있도록 한다.
패킷의 전송 동안에, 필드는 최소 유효 비트 (LSB) 에서 먼저 시작하고 최종적으로 전송되는 최대 유효 비트 (MSB) 에서 끝나도록 송신된다. 1 보다 큰 바이트 길이의 파라미터는 먼저 최소 유효 바이트를 사용하여 송신되는데, 이는 LSB 가 먼저 전송되는 더 짧은 파라미터에 대하여 사용되는 것과 같이, 8 비트 길이 보다 큰 파라미터에 대하여 동일한 비트 송신 패턴이 사용되도록 한다. 각 패킷의 데이터 필드는 아래 부분에서 정의되는 순서로 일반적으로 송신되며, 리스트의 첫번째 필드는 처음으로 송신되고 설명된 마지막 필드는 마지막으로 송신된다. MDDI_Data0 신호 경로 상의 데이터가 타입 1, 타입 2, 타입 3, 또는 타입 4 중 하나에서 인터페이스상에서 송신된 바이트의 비트 "0" 과 정렬된다.
디스플레이를 위해 데이터를 처리할 때, 픽셀의 어레이에 대한 데이터는 전자 공학 분야에서 전통적으로 행해진 바와 같이 우선 행, 그리고 나서 열로 송신된다. 즉, 비트맵에서 동일한 행에 나타나는 모든 픽셀은 최 좌측 픽셀이 우선 송신되고 최 우측 픽셀이 최후에 송신되는 순서로 송신된다. 행의 최 우측 픽셀이 송신된 후, 그 다음에 시퀀스 내의 다음 픽셀은 다음 행의 최 좌측 픽셀이다. 필요에 따라 다른 구성이 수용될 수 있지만, 대부분의 디스플레이에 대하여 픽셀의 행은 일반적으로 위에서 아래의 순서로 송신된다. 게다가 비트맵을 핸들링함에 있어, 여기에서 따르는 종래의 접근방법은 비트맵의 좌측 상부 모서리를 위치 또는 오프셋 "0,0" 으로 레이블링하여 기준점을 정의하는 것이다. 비트맵에서 위치를 정의하거나 결정하기 위해 사용된 X 와 Y 좌표는 각각 비트맵의 좌측 및 하부로 접근함에 따라 값이 증가된다. 제 1 행 및 제 1 열 (이미지의 좌측 상부 모서리) 은 인덱스 값 0 으로 시작한다. 디스플레이 사용자가 볼 때, X 좌표의 크기는 이미지의 우측을 향하여 증가하고 Y 좌표 크기는 이미지의 아래를 향해서 증가한다.
디스플레이 윈도우는 비트맵의 가시부, 물리적 디스플레이 매체 상에서 사용자가 볼 수 있는 비트맵의 픽셀 부분이다. 디스플레이 윈도우와 비트맵이 동일한 사이즈인 경우가 대부분이다. 디스플레이 윈도우의 상부 좌측 모서리는 항상 비트맵 픽셀 위치 0,0 을 표시한다. 디스플레이 윈도우의 폭은 비트맵의 X 축에 해당하고, 본 실시형태에 대한 디스플레이 윈도우의 폭은 해당 비트맵의 폭보다 작거나 동일하다. 윈도우의 높이는 비트맵의 Y 축에 해당하고, 본 실시형태에 대한 디스플레이 윈도우의 높이는 해당 비트맵의 높이보다 작거나 동일하다. 디스플레이 윈도우는 비트맵의 가시부로서만 정의되기 때문에 프로토콜에서 그 자체는 어드레스 가능하지 않다.
비트맵과 디스플레이 윈도우 사이의 관계는 컴퓨터, 전자 기술, 인터넷 통신 기타 전자관련 기술분야에 잘 알려져 있다. 따라서, 이러한 원리의 추가적인 설명 또는 예시를 여기에서 더 이상 제공하지 않는다.
C. 패킷 정의
1. 서브 프레임 헤더 패킷
서브 프레임 헤더 패킷은 모든 서브 프레임의 첫 번째 패킷이고, 도 9 에서 나타낸 바와 같은 기본 구조를 가진다. 서브 프레임 헤더 패킷은 호스트 클라이언트 동기화를 위해 사용되고, 모든 호스트가 이 패킷을 발생시킬 수 있어야 하는 한편, 모든 클라이언트가 이 패킷을 수신하여 해석할 수 있어야 한다. 도 9 의 일 실시형태에서 볼 수 있는 바와 같이, 이러한 타입의 패킷은 일반적으로, 패킷 길이, 패킷 타입, 고유 워드 (Unique Word), 보류 1 (Reserved 1), 서브 프레임 길이, 프로토콜 버전, 서브 프레임 카운트, 그리고 미디어 프레임 카운트 필드를 순서대로 갖도록 구성된다. 일 실시형태에서, 이러한 타입의 패킷은 일반적으로 타입 15359 (Ox3bff 16진수) 패킷으로 식별되고, 패킷 길이 필드를 제외하고, 20 바이트의 미리 선택된 고정 길이를 이용한다.
패킷 타입 필드와 고유 워드 필드는 각각 2 바이트 값 (16-비트 무부호 정수) 을 이용한다. 이러한 2 개 필드의 4-바이트 조합은 함께 양호한 자기상관 (autocorrealtion) 을 갖는 32-비트 고유 워드를 형성한다. 일 실시형태에서, 실제 고유 워드는 Ox005a3bff 이고, 여기서 하위 16비트가 패킷 타입으로서 먼저 송신되고, 최대 유효 16비트가 후에 전송된다.
보류 1 필드는 장래 사용을 위한 보류 공간인 2 바이트를 포함하고, 이 시점에서는 일반적으로 모든 비트를 0 으로 설정하여 구성된다. 이 필드의 일 목적은 후속 2 바이트 필드가 16-비트 워드 어드레스에 정렬되도록 하고 4-바이트 필드가 32-비트 워드 어드레스에 정렬되도록 하는 것이다. 최소 유효 바이트는 호스트가 다중 클라이언트 장치를 어드레스할 수 있는지 여부를 나타내기 위해 보류된다. 이 바이트에 대한 0 값은 호스트가 단일의 클라이언트 장치와만 동작할 수 있다는 것을 나타내기 위해 보류된다.
서브 프레임 길이 필드는 서브 프레임당 바이트 개수를 특정하는 4 바이트의 정보 또는 값을 포함한다. 일 실시형태에서, 이 필드의 길이는, 링크가 유휴 상태로 셧다운되기 전에 호스트에 의해 하나의 서브 프레임만이 송신될 것이라는 것을 나타내기 위해 0 으로 설정될 수 있다. 이 필드에 있는 값은 일 서브 프레임에서 다음 서브 프레임으로 천이할 때 "온 더 플라이 (on-the-fly)" 로 동적으로 변경될 수 있다. 이 기능은 등시성 데이터 스트림을 수용하기 위한 동기 펄스 신호에 작은 타이밍 조정을 수행하는데 유용하다. 서브 프레임 헤더 패킷의 CRC 가 유효하지 않으면, 링크 제어기는 현재 서브 프레임의 길이를 추정하기 위해 양호한 것으로 알려진 이전 서브 프레임 헤더 패킷의 서브 프레임 길이를 이용하여야 한다.
프로토콜 버전 필드는 호스트에 의해 이용되는 프로토콜 버전을 특정하는 2 바이트를 포함한다. 프로토콜 버전 필드는 사용되고 있는 프로토콜의 제 1 버전 또는 현재의 버전을 특정하도록 "0" 으로 설정될 수 있다. 이 값은 새로운 버천이 생성됨에 따라 시간에 따라 변할 것이고, 일부 버전 필드에 대해서는 이미 '1' 값으로 업그레이드되고 있다. 알려진 바와 같이, 아마도, 또는 일반적으로 버전 값은, MDDI 와 같은 인터페이스를 커버하는 승인된 표준 문서에 대한 현재의 버전 넘버를 따를 수 있다.
서브 프레임 카운트 필드는 미디어 프레임의 시작 이후로 송신되었던 서브프레임의 수를 나타내는 시퀀스 넘버를 특정하는 2 바이트를 포함한다. 미디어 프레임의 첫 번째 서브 프레임은 영 (0) 의 서브 프레임 카운트를 가진다. 미디어 프레임의 최종 서브 프레임은, n 이 미디어 프레임 당 서브 프레임의 수인 경우, n-1의 값을 가진다. 서브 프레임 카운트 필드의 값은, 제로 카운트를 갖게 되는 미디어 프레임의 첫 번째 서브 프레임을 제외하고는, 이전 서브 프레임 패킷에서 전송된 서브 프레임 카운트에 1 을 더한 값과 동일하다. 서브 프레임 길이가 영 (비주기 서브 프레임을 가리킴) 으로 설정된다면, 서브 프레임 카운트 또한 0 으로 설정된다.
미디어 프레임 카운트 필드는, 전송되고 있는 현재 미디어 아이템 또는 데이터의 개시 이후로 송신된 미디어 프레임의 수를 나타내는 시퀀스 넘버를 특정하는 4 바이트 (32-비트 무부호 정수) 를 포함한다. 미디어 아이템의 첫 번째 미디어 프레임은 0 의 미디어 프레임 카운트를 갖는다. 미디어 프레임 카운트는 각각의 미디어 프레임의 첫 번째 서브 프레임에 앞서 증가되고, 최대 미디어 프레임 카운트 (예를 들어, 미디어 프레임 번호 232-1 = 4,294,967,295) 가 이용된 후 0 으로 되돌아간다 (wraps back). 미디어 프레임 카운트 값은 일반적으로 종단 애플리케이션의 요구에 맞도록 호스트에 의해 언제든지 재설정할 수 있다.
2. 필러 패킷
필러 패킷은, 순방향 또는 역방향 링크 둘 중 하나를 통해 송신될 이용가능한 다른 정보가 없을 경우, 클라이언트 장치로 또는 클라이언트 장치로부터 전송되는 패킷이다. 필요 시 다른 패킷을 송신하는데 있어 최대의 유연성을 허용하기 위해 필러 패킷은 최소 길이를 가질 것이 권장된다. 서브 프레임 또는 역방향 링크 캡슐화 패킷 (아래 참조) 의 바로 끝에서, 링크 제어기는, 패킷 무결성을 유지하도록 나머지 공간을 채우기 위해 필러 패킷의 사이즈를 설정한다. 필러 패킷은, 호스트 또는 클라이언트가 송신 또는 교환할 정보를 갖지 않는 경우, 링크 상의 타이밍을 유지시키는데 유용하다. 모든 호스트 및 클라이언트는 인터페이스를 효율적으로 이용하기 위해 이 패킷을 송신 및 수신할 수 있어야 할 필요가 있다.
필러 패킷의 형식 및 컨텐츠의 예시적인 실시형태가 도 10 에 도시된다. 도 10 에 도시된 바와 같이, 이 타입의 패킷은 패킷 길이, 패킷 타입, 필러 바이트 및 CRC 필드를 갖도록 구성된다. 일 실시형태에서, 이 타입의 패킷은 일반적으로, 2-바이트 타입 필드에서 표시된 타입 0 으로서 식별된다. 필러 바이트 필드의 비트 또는 바이트는, 필러 패킷을 원하는 길이가 될 수 있도록 가변 개수의 전부 0 비트인 값을 포함한다. 최소의 필러 패킷은 이 필드에 바이트를 포함하지 않는다. 즉, 이 패킷은 패킷 길이, 패킷 타입 및 CRC 만으로 구성되며, 일 실시형태에서는 6 바이트의 미리 선택된 고정 값 또는 4 의 패킷 길이를 이용한다. CRC 값은 일부 다른 패킷 타입에서는 제외될 수도 있는 패킷 길이를 포함하는 패킷의 모든 바이트에 대하여 결정된다.
3. 비디오 스트림 패킷
통상, 비디오 스트림 패킷은 디스플레이 장치의 직사각형 영역을 업데이트하기 위한 비디오 데이터를 운반한다. 이 영역의 사이즈는 단일 픽셀만큼 작거나 전체 디스플레이만큼 클 수 있다. 스트림을 디스플레이하는데 필요한 모든 콘텍스트 (context) 가 비디오 스트림 패킷 내에 포함되기 때문에, 시스템 자원에 의해 제한되지만 거의 무한한 수의 동시 디스플레이되는 스트림이 존재할 수 있다. 비디오 스트림 패킷 (비디오 데이터 형식 디스크립터) 의 일 실시형태의 형식이 도 10 에 도시된다. 도 10 에 도시된 바와 같이, 일 실시형태에서, 이 타입의 패킷은 패킷 길이 (2 바이트), 패킷 타입, b클라이언트 ID, 비디오 데이터 디스크립터, 픽셀 디스플레이 속성 (Attribute), X 좌측 에지 (X Left Edge), Y 탑 에지 (Y Top Edge), X 우측 에지 (X Right Edge), Y 바닥 에지 (Y Bottom Edge), X 및 Y 시작 (Start), 픽셀 카운트, 파라미터 CRC, 픽셀 데이터 및 픽셀 데이터 CRC 필드를 갖도록 구성된다. 이 타입의 패킷은 일반적으로, 2 바이트 타입 필드에서 표시되는 타입 16 으로 식별된다. 일 실시형태에서, 클라이언트는, 클라이언트 능력 패킷의 RGB, 흑백, 및 Y Cr Cb 능력 필드를 이용하여 비디오 스트림 패킷을 수신할 수 있는 능력을 나타낸다.
일 실시형태에서, b클라이언트 ID 필드는 클라이언트 ID 를 위해 보류되는 2 바이트의 정보를 포함한다. 이것은 새롭게 개발된 통신 프로토콜이기 때문에, 실제 클라이언트 ID 는 아직 공지되지 않거나 충분히 통신가능하지 않다. 따라서, 당업자에게 명백한 것처럼, 이러한 ID 값이 알려질 때까지, 일반적으로 이 필드의 비트들은 0 으로 설정되고, 그 때 ID 값이 삽입되거나 이용될 수 있다. 동일한 프로세스가 이하 설명할 클라이언트 ID 필드에 대해서도 일반적으로 유효할 것이다.
상술된 예시적인 비디오 데이터 디스크립터 필드의 동작을 실현하기 위해 채용되는 형식 및 콘텐츠가 도 12a 내지 12e 에 도시되어 있다. 도 12a 내지 12e 에서, 비디오 데이터 형식 디스크립터 필드는, 해당 패킷의 스트림 내 픽셀 데이터에서 각 픽셀의 형식을 특정하는 16-비트 무부호 정수의 형태로 2 바이트를 포함한다. 또 다른 비디오 스트림 패킷은 상이한 픽셀 데이터 형식, 즉, 비디오 데이터 형식 디스크립터의 다른 값을 사용할 수도 있고, 유사하게, 스트림 (디스플레이 영역) 은 데이터 형식을 온더플라이 (on-the-fly) 로 변경할 수도 있다. 픽셀 데이터 형식은 클라이언트 능력 패킷에서 정의된 바와 같은 클라이언트에 대한 유효한 형식 중 적어도 하나에 따라야 한다. 비디오 데이터 형식 디스크립터는 현재의 패킷만을 위한 픽셀 형식을 정의하나, 그것이 특정한 비디오 스트림의 수명 동안 일정한 형식이 계속 사용됨을 의미하는 것은 아니다.
도 12a 내지 도 12d 는 비디오 데이터 형식 디스크립터가 코딩되는 방법을 도시한다. 이들 도면 및 이 실시형태에서 이용되는 바와 같이, 비트 [15:13] 가 도 11a 에 도시된 바와 같이 '000'인 경우, 비디오 데이터는 픽셀 당 비트 수가 비디오 데이터 형식 디스크립터 워드의 비트 3 내지 0 에 의해 정의되는 흑백 픽셀의 배열로 구성된다. 일반적으로, 비트 11 내지 4 는 장래의 사용 또는 애플리케이션을 위해 보류되고, 이 상황에서는 0 으로 설정된다. 이와 달리 비트 [15:13] 가 도 11b 에 도시된 바와 같이 '001' 값인 경우, 비디오 데이터는 각각이 컬러 맵 (팔레트) 을 통해 컬러를 특정하는 컬러 픽셀의 배열로 구성된다. 이 상황에서, 비디오 데이터 형식 디스크립터 워드의 비트 5 내지 0 은 픽셀 당 비트 수를 정의하고, 비트 11 내지 6 은 일반적으로, 장래의 사용 또는 애플리케이션을 위해 보류되며 0 으로 설정된다. 이와 달리 비트 [15:13] 가 도 12c 에 도시된 바와 같이 '010' 인 경우, 적색의 픽셀 당 비트 수가 비트 11 내지 8 에 의해 정의되고, 녹색의 픽셀 당 비트 수가 비트 7 내지 4 에 의해 정의되며, 청색의 픽셀 당 비트 수가 비트 3 내지 0 에 의해 정의되는 컬러 픽셀의 배열로 비디오 데이터가 구성된다. 이 상황에서, 각 픽셀 내 비트의 총 수는 적색, 녹색 및 청색에 대해 이용된 비트 수의 합이다.
그러나, 이와 달리 비트 [15:13] 가 도 12d 에 도시된 바와 같이, '011' 값 또는 스트링인 경우, 휘도 (Y) 의 픽셀 당 비트 수가 비트 11 내지 8 에 의해 정의되고, Cb 성분의 비트 수가 비트 7 내지 4 에 의해 정의되며, Cr 성분의 비트 수가 비트 3 내지 0 에 의해 정의되는, 휘도 및 크로미넌스 (chrominance) 정보를 갖는 4:2:2 YCbCr 형식의 비디오 데이터의 배열로 비디오 데이터가 구성된다. 각 픽셀 내의 총 비트 수는 적색, 녹색 및 청색에 대해 이용된 비트 수의 합이다. Cb 및 Cr 성분은 Y 의 레이트의 반으로 송신된다. 또한, 이 패킷의 픽셀 데이터 부분의 비디오 샘플은 다음 Cbn, Yn, Crn, Yn+1, Cbn+2, Yn+2, Crn+2, Yn+3 ... 과 같이 조직되며, 여기서 Cbn 및 Crn 은 Yn 및 Yn+1 과 연관되며, Cbn+2 및 Crn+2 는 Yn+2 및 Yn+3 과 연관되는 등이다.
Yn, Yn+1, Yn+2 및 Yn+3 은 단일 행의 좌측으로부터 우측으로의 4 개의 연속적인 픽셀의 휘도 값이다. 비디오 스트림 패킷에 의해 참조된 윈도우의 일 행에 홀수의 픽셀 (X Right Edge - X Left Edge +1) 이 존재하는 경우, 각각의 행의 마지막 픽셀에 대응하는 Y 값은 다음의 행의 제 1 픽셀의 Cb 값이 후속하고, 행의 마지막 픽셀에 대한 Cr 값은 송신되지 않는다. Y Cb Cr 형식을 이용하는 윈도우는 짝수개의 픽셀의 폭을 가질 것을 권장한다. 패킷의 픽셀 데이터는 짝수의 픽셀을 포함하여야 한다. 픽셀 데이터의 마지막 픽셀이 비디오 스트림 패킷 헤더에 특정된 윈도우의 일 행의 마지막 픽셀에 대응하는 경우, 즉, 픽셀 데이터의 마지막 픽셀의 X 위치가 X 우측 에지와 동일한 경우, 홀수 또는 짝수의 픽셀을 포함할 수 있다.
위와 달리 비트 [15:13] 가 '100' 값인 경우, 픽셀 당 비트 수가 비디오 데이터 형식 디스크립터 워드의 비트 3 내지 0 에 의해 정의되는 베이어 (Bayer) 픽셀의 배열로 비디오 데이터가 구성된다. 픽셀 그룹 패턴은 도 12e 에 도시된 바와 같이 비트 5 및 비트 4 에 의해 정의된다. 픽셀 데이터의 순서는 수평 또는 수직일 수도 있고, 행 또는 열의 픽셀은 순방향 또는 역방향 순서로 송신될 수도 있으며 비트 8 내지 6 으로 정의된다. 비트 11 내지 비트 9 는 0 으로 설정된다. 베이어 (Bayer) 형식의 픽셀 그룹 중 4 개 픽셀의 그룹은 일부 디스플레이 기술에서 종종 단독 픽셀이라 하는 것과 유사하다. 그러나, 베이어 형식의 한 픽셀은 픽셀 그룹 모자이크 패턴의 4 개 컬러 픽셀 중 단 하나이다.
도면에 도시된 모든 5 개의 형식에 대하여, "P" 로 지정된 비트 12 는 픽셀 데이터 샘플이 패킹되는지 여부, 즉 바이트-정렬 픽셀 데이터를 특정한다. 이 필드의 '0' 값은, 픽셀 데이터 필드의 각각의 픽셀이 MDD 인터페이스 바이트 경계와 정렬된 바이트임을 나타낸다. '1' 의 값은, 픽셀 데이터 내의 각각의 픽셀 및 각각의 픽셀 내의 각각의 컬러가 이전 픽셀 또는 픽셀 내의 컬러에 대하여 비사용 비트를 남기지 않고 패킹됨을 나타낸다. 바이트 정렬 픽셀 데이터와 패킷화된 픽셀 데이터 형식의 차이점이 도 13 에 보다 상세하게 도시되는데, 여기에서 바이트-정렬된 데이터는 그렇지 않은 패킷화된 픽셀 형식과 달리 데이터 서브 프레임의 미사용 부분을 남길 수도 있음을 명확히 알 수 있다.
4. 오디오 스트림 패킷
오디오 스트림 패킷은 클라이언트의 오디오 시스템을 통해, 또는 독립형 오디오 프리젠테이션 장치를 위해 재생될 오디오 데이터를 운반한다. 상이한 오디오 데이터 스트림은 사운드 시스템 내에서 분리된 오디오 채널, 예를 들어, 이용될 오디오 시스템의 타입에 따라, 좌측-전면, 우측-전면, 중앙, 좌측-후면, 및 우측-후면에 대하여 할당될 수 있다. 오디오 채널의 풀 컴플리먼트 (complement) 는 향상된 공간 사운드 신호 처리를 포함하는 헤드셋에 대해 제공된다. 클라이언트는 오디오 채널 능력 및 클라이언트 능력 패킷의 오디오 샘플 레이트 필드를 이용하여 오디오 스트림 패킷을 수신하는 성능을 나타낸다. 오디오 스트림 패킷의 형식은 도 14 에 도시된다.
도 14 에 도시된 바와 같이, 일 실시형태에서 이러한 타입의 패킷은, 패킷 길이, 패킷 타입, b클라이언트 ID, 오디오 채널 ID, 보류 1, 오디오 샘플 카운트, 샘플 및 패킷 당 비트, 오디오 샘플 레이트, 파라미터 CRC, 디지털 오디오 데이터 및 오디오 데이터 CRC 필드를 갖도록 구성된다. 일 실시형태에서, 이 타입의 패킷은 통상적으로 타입 32 패킷으로 식별된다.
b클라이언트 ID 필드는 이전에 이용된 바와 같이 클라이언트 ID 를 위해 보류된 2 바이트의 정보를 포함한다. 보류 1 필드는 장래의 사용을 위해 보류된 2 바이트를 포함하고, 이 시점에서는 일반적으로 모든 비트를 0 으로 설정하여 구성된다.
샘플 및 패킹 당 비트 필드는 오디오 데이터의 패킹 형식을 특정하는 8-비트 무부호 정수의 형태의 1 바이트를 포함한다. 통상적으로 이용되는 형식은 비트 4 내지 비트 0 이 PCM 오디오 샘플당 비트 수를 정의하는 것이다. 그 후 비트 5 는, 디지털 오디오 데이터 샘플이 패킷화되는지 여부를 특정한다. 패킷화된 오디오 샘플과 바이트-정렬 오디오 샘플들 사이의 차이는 도 15 에 도시되며, 여기에서 10-비트 샘플을 사용하였다. '0' 값은, 디지털 오디오 데이터 필드의 각각의 PCM 오디오 샘플이 MDDI 바이트 경계로 정렬된 것을 나타내고, '1' 의 값은, 각각의 연속하는 PCM 오디오 샘플이 이전의 오디오 샘플에 대하여 패킷화된 것을 나타낸다. 통상적으로, 이 비트는, 비트 4 내지 비트 0 (PCM 오디오 샘플 당 비트 수) 에 정의된 값이 8 의 배수가 아닌 경우에만 효과적이다. 비트 7 내지 비트 6 은 장래의 사용을 위해 보류되고 일반적으로, 0 의 값으로 설정된다.
5. 보류 스트림 패킷
일 실시형태에서, 패킷 타입 1 내지 15, 18 내지 31, 및 33 내지 55 는 직면하는 다양한 애플리케이션에 대한 희망에 따라, 패킷 프로토콜의 장래의 버전 또는 변동에 이용하기 위해 정의될 스트림 패킷을 위해 보류된다. 역시, 이것은 다른 기술에 비해, 계속적으로 변화하는 기술 및 시스템 설계에 대처하여 MDDI 를 더 유연하고 유용하게 하는 부분이다.
6. 사용자-정의 스트림 패킷
타입 56 내지 63 으로 알려져 있는 8 개의 데이터 스트림 타입은, MDDI 링크와 함께 이용하기 위한 장비 제조자에 의해 정의될 수 있는 독점적 애플리케이션에 서의 사용을 위해 보류된다. 이들은 사용자 정의 스트림 패킷으로 알려져 있다. 이러한 패킷은 여하한 목적을 위해 이용될 수도 있지만, 호스트 및 클라이언트는, 이용의 결과가 매우 잘 이해되거나 알려진 상황에서만 이러한 패킷을 이용하여야 한다. 스트림 파라미터 및 이들 패킷 타입에 대한 데이터의 구체적 정의는 이러한 패킷 타입을 구현하거나 그들의 이용을 탐색하는 특정한 장비 제조자 또는 인터페이스 설계자에게 남겨둔다. 사용자 정의 스트림 패킷의 일부 예시적인 이용은, 테스트 파라미터 및 테스트 결과, 팩토리 교정 데이터, 및 독점적 특별 이용 데이터를 전송하는 것이다. 일 실시형태에서 사용되는 바와 같은 사용자 정의 스트림 패킷의 형식은 도 16 에 도시된다. 도 16 에 도시된 바와 같이, 이 타입의 패킷은 패킷 길이 (2 바이트), 패킷 타입, b클라이언트 ID 넘버, 스트림 파라미터, 파라미터 CRC, 스트림 데이터 및 스트림 데이터 CRC 필드를 갖도록 구성된다.
7. 컬러 맵 패킷
컬러 맵 패킷은 클라이언트에게 컬러를 제공하기 위해 이용된 컬러 맵 참조 표 (look-up table) 의 컨텐츠를 특정한다. 일부 애플리케이션은 단일 패킷으로 송신될 수 있는 데이터의 양보다 더 큰 컬러 맵을 요구할 수 있다. 이런 경우, 후술되는 필드 길이 및 오프셋을 이용함으로써 각각 컬러 맵의 상이한 서브 세트를 갖는 다수의 컬러 맵 패킷이 전송될 수 있다. 일 실시형태의 컬러 맵 패킷의 형식은 도 17 에 도시된다. 도 17 에 도시된 바와 같이, 이 타입의 패킷은, 패킷 길이, 패킷 타입, h클라이언트 ID, 컬러 맵 아이템 카운트, 컬러 맵 오프셋, 파라미터 CRC, 컬러 맵 데이터, 및 데이터 CRC 필드를 갖도록 구성된다. 일 실시형태에서, 이 타입의 패킷은 일반적으로, 패킷 타입 필드 (2 바이트) 에서 특정된 타입 64 패킷 (비디오 데이터 형식 및 컬러 맵 패킷) 으로 식별된다. 클라이언트는 클라이언트 능력 패킷의 컬러 맵 사이즈 및 컬러 맵 폭 필드를 이용하여 컬러 맵 패킷을 수신하는 능력을 나타낸다.
8. 역방향 링크 캡슐화 패킷
예시적인 실시형태에 있어서, 데이터는 역방향 링크 캡슐화 패킷을 이용하여 역방향으로 전송된다. 패킷이 역방향으로 송신될 수 있도록, 순방향 링크 패킷이 송신되고 MDDI 링크 동작 (전송 방향) 은 이 패킷 중에 변경되거나 전환된다. 일 실시형태의 역방향 링크 캡슐화 패킷의 형식이 도 18 에 도시된다. 도 18 에 도시된 바와 같이, 이 타입의 패킷은, 패킷 길이, 패킷 타입, h클라이언트 ID, 역방향 링크 플래그, 역방향 레이트 제수, 턴 어라운드 1 길이, 턴 어라운드 2 길이, 파라미터 CRC, 올 제로 1, 턴 어라운드 1, 역방향 데이터 패킷, 턴 어라운드 2 및 올 제로 2 필드를 갖도록 구성된다. 일 실시형태에서, 이러한 타입의 패킷은 통상적으로 타입 65 패킷으로 식별된다. 외부 모드에 대하여, 모든 호스트는 이 패킷을 생성시키고 데이터를 수신할 수 있어야 하며, 희망 프로토콜과 결과적인 속도를 효율적으로 이용하기 위하여 모든 클라이언트는 호스트에게 데이터를 송신하고 수신할 수 있어야 한다. 이 패킷의 구현은 내부 모드에 대하여서는 선택적이지만, 역방향 링크 캡슐화 패킷은 호스트가 데이터를 클라이언트로부터 수신하는데 이용된다.
MDDI 링크 제어기는 역방향 링크 캡슐화 패킷을 송신하는 동안 특별한 방식으로 작동한다. MDDI 는 일반적으로 항상 링크의 제어기로서의 호스트에 의해 구동되는 스트로브 신호 (strobe signal) 를 갖는다. 호스트는 역방향 링크 캡슐화 패킷의 턴 어라운드 및 역방향 데이터 패킷 부분의 각각의 비트에 대하여 0 을 송신하는 것처럼 작동한다. 2 번의 턴 어라운드 시간 및 역방향 데이터 패킷을 위해 할당된 시간 동안 각각의 비트 경계에서 호스트는 MDDI_Strobe 신호를 토글링한다. 즉, 호스트는 MDDI_Stb 를 올 제로 1 필드의 시작에서 올 제로 2 필드의 끝까지 토글링한다. (이것은 올 제로 데이터를 송신하고 있는 것과 같은 동작이다.)
호스트는 그 MDDI 데이터 신호 라인 드라이버를 디스에이블 하고 일반적으로 턴 어라운드 1 필드의 마지막 비트 전에 그들이 완전히 디스에이블 되었는지 확인하며, 그 후 턴 어라운드 2 필드 동안 그 라인을 다시 인에이블 하고 일반적으로 턴 어라운드 2 필드의 마지막 비트 전에 그들이 완전히 다시 인에이블 되었는지 확인한다. 클라이언트는 턴 어라운드 길이 파라미터를 판독하고 턴 어라운드 1 필드의 마지막 비트 후에 즉시 호스트를 향해 데이터 신호를 구동한다. 즉, 클라이언트는, 이하에서 그리고 그 외에 설명된 바와 같이, 패킷 컨텐츠에서 특정된 MDDI 스트로브의 소정 상승 에지 (rising edge) 에서 새로운 데이터를 링크로 클록 (clock) 한다. 클라이언트는 호스트로 패킷을 보내기 위해 사용 가능한, 가지고 있는 시간의 길이를 알기 위해 패킷 길이 및 턴 어라운드 길이 파라미터를 사용한다. 클라이언트는 호스트로 보낼 데이터가 없는 경우 필러 패킷을 전송하거나 데이터 라인을 영 상태로 구동 (drive) 한다. 데이터 라인이 0 으로 구동된 경우, 호스트는 이를 (유효한 길이가 아니라) 길이 0 의 패킷으로 해석하고, 호스트는 현재 역방향 링크 캡슐화 패킷의 길이 동안 클라이언트로부터 더 이상의 패킷을 받아들이지 않는다.
일 실시형태에서, 클라이언트 요청의 역방향 링크 요청 필드 및 상태 패킷은, 클라이언트가 호스트에게 데이터를 다시 송신하기 위해 역방향 링크 캡슐화 패킷에서 필요한 바이트의 수를 호스트에게 알려주기 위해 이용될 수도 있다. 호스트는 역방향 링크 캡슐화 패킷 내에 적어도 그 수의 바이트를 할당함으로써 요청을 허가하려고 한다. 호스트는 서브 프레임 내에서 하나 이상의 역방향 링크 캡슐화 패킷을 송신할 수도 있다. 클라이언트는 거의 모든 시간에 클라이언트 요청 및 상태 패킷을 송신할 수도 있고, 호스트는 역방향 링크 요청 파라미터를 하나의 서브 프레임에 요청된 바이트의 총 수로 해석한다.
9. 클라이언트 능력 (Client Capability) 패킷
호스트는, 일반적으로 최적의 또는 희망하는 방식으로 호스트-대-클라이언트 링크를 구성하기 위하여, 통신하는 클라이언트 (디스플레이) 의 능력을 알 필요가 있다. 디스플레이는, 순방향 링크 동기화가 획득된 이후에 클라이언트 능력 패킷을 호스트에게 송신할 것을 권장한다. 이러한 패킷의 송신은 역방향 링크 캡슐화 패킷의 역방향 링크 플래그를 이용하여 호스트에 의해 요청될 때 필요한 것으로 생각된다. 클라이언트 능력 패킷은 클라이언트의 능력을 호스트에게 알려주기 위해 이용된다. 외부 모드에 대하여, 모든 호스트는 이 패킷을 수신할 수 있어야 하고, 모든 클라이언트는 이 인터페이스 및 프로토콜을 완전히 이용하기 위해 이 패킷을 송신할 수 있어야 한다. 이러한 상황에서, 디스플레이, 키보드 또는 다른 입/출력 장치 등의 클라이언트의 능력은 이미 단일 성분 또는 일부 타입의 유닛으로의 조립 또는 제조 시에 호스트에게 잘 정의되고 알려져 있기 때문에, 내부 모드에 대하여서는 이 패킷의 구현은 선택적이다.
일 실시형태의 클라이언트 능력 패킷의 형식이 도 19 에 도시된다. 도 19 에 도시된 바와 같이, 이러한 실시형태에서 이 타입 패킷은, 패킷 길이, 패킷 타입, c클라이언트 ID, 프로토콜 버전, 최소 프로토콜 버전, 사전 교정 (Pre-Calibration) 데이터 레이트 능력, 인터페이스 타입 능력, 교대 디스플레이의 넘버, 사후 교정 데이터 레이트 능력, 비트맵 폭, 비트맵 높이, 디스플레이 윈도우 폭, 디스플레이 윈도우 높이, 컬러 맵 사이즈, 컬러 맵 RGB 폭, RGB 능력, 흑백 능력, 보류 1, Y Cr Cb 능력, 베이어 능력, 보류 2, 클라이언트 특성 능력, 최대 비디오 프레임 레이트, 최소 비디오 프레임 레이트, 최소 서브 프레임 레이트, 오디오 버퍼 깊이, 오디오 채널 능력, 오디오 샘플 레이트 능력, 오디오 샘플 해상도, Mic 오디오 샘플 해상도, Mic 샘플 레이트 능력, 키보드 데이터 형식, 포인팅 장치 데이터 형식, 컨텐츠 보호 타입, 제조자 이름, 제품 코드, 보류 3, 시리얼 번호, 제조 주 (week), 제조 년 (year) 및 CRC 필드를 갖도록 구성된다. 예시적인 실시형태에서, 이 타입의 패킷은 통상적으로, 타입 66 패킷으로 식별된다.
10. 키보드 데이터 패킷
키보드 데이터 패킷은 클라이언트 장치로부터 호스트로 키보드 데이터를 송신하기 위해 이용된다. 무선 (또는 유선) 키보드는, 헤드 장착 비디오 디스플레이/오디오 프리젠테이션 장치를 포함하나 이에 제한되지 않는 다양한 오디오 장치 또는 디스플레이와 함께 이용될 수 있다. 키보드 데이터 패킷은, 몇몇 공지된 키보드와 같은 장치들 중 하나로부터 호스트로 수신된 키보드 데이터를 릴레이한다. 이 패킷은 또한, 데이터를 키보드로 송신하기 위한 순방향 링크에서 이용될 수 있다. 클라이언트는 클라이언트 능력 패킷의 키보드 데이터 필드를 이용하여 키보드 데이터 패킷을 송신 및 수신하는 능력을 나타낸다.
키보드 데이터 패킷의 형식은 도 20 에 도시되며, 키보드로부터 또는 키보드를 위한 가변수의 정보 바이트를 포함한다. 도 20 에 도시된 바와 같이, 이 타입의 패킷은, 패킷 길이, 패킷 타입, b클라이언트 ID, 키보드 데이터 형식, 키보드 데이터 및 CRC 필드를 갖도록 구성된다. 여기서, 이 타입의 패킷은 일반적으로 타입 67 패킷으로 식별된다.
b클라이언트 ID 는 전처럼, 보류 필드이고, CRC 는 패킷의 바이트의 전체에 걸쳐 수행된다. 키보드 데이터 형식 필드는 키보드 데이터 형식을 설명하는 2 바이트 값을 포함한다. 비트 6 내지 0 은 클라이언트 능력 패킷의 키보드 데이터 형식 필드와 동일해야 한다. 이 값은 127 이 아니다. 비트 15 내지 7 은 장래의 사용을 위해 보류되고, 따라서 현재는 0 으로 설정된다.
11. 포인팅 장치 데이터 패킷
포인팅 장치 데이터 패킷은, 무선 마우스 또는 다른 포인팅 장치로부터의 위치 정보를 클라이언트로부터 호스트로 송신하는 방법, 구성 또는 수단으로서 이용된다. 또한, 데이터는 이 패킷을 이용하여 순방향 링크로 포인팅 장치로 송신될 수 있다. 포인팅 장치 데이터 패킷의 예시적인 형식이 도 21 에 도시되며, 포인팅 장치로부터 또는 포인팅 장치를 위한 가변수의 정보 바이트를 포함한다. 도 21 에 도시된 바와 같이, 이 타입의 패킷은, 패킷 길이, 패킷 타입, b클라이언트 ID, 포인팅 장치 형식, 포인팅 장치 데이터, 및 CRC 필드를 갖도록 구성된다. 예시적인 실시형태에서, 이 타입의 패킷은 일반적으로 1-바이트 타입 필드의 타입 68 패킷으로서 식별된다.
12. 링크 셧다운 패킷
링크 셧다운 패킷은, MDDI 데이터 및 스트로브가 셧다운되고 저-전력 소비 "휴지 (hiberation)" 상태로 들어감을 나타내는 방법 또는 수단으로서, 호스트로부터 클라이언트에게 송신된다. 이 패킷은 고정 비트맵이 이동 통신 장치로부터 디스플레이로 송신된 이후, 또는 당분간 호스트로부터 클라이언트로 전송하기 위한 정보가 더 이상 없을 경우에, 링크를 막고 전력을 절약하는데 유용하다. 호스트가 다시 패킷을 송신하는 경우, 정상 동작이 다시 시작된다. 휴지 이후에 송신되는 첫 번째 패킷은 서브 프레임 헤더 패킷이다. 일 실시형태에 대한 클라이언트 상태 패킷의 형식이 도 22 에 도시된다. 도 22 에 도시된 바와 같이, 이 타입의 패킷은, 패킷 길이, 패킷 타입, CRC 필드 및 올 제로 필드를 갖도록 구성된다. 일 실시형태에서, 이 타입의 패킷은 일반적으로, 1-바이트 타입 필드의 타입 69 패킷으로서 식별된다.
패킷 길이 필드는 패킷 길이 필드를 제외한 패킷 내 바이트의 총 수를 특정하는데 2 바이트를 이용한다. 일 실시형태에서, 이 패킷의 패킷 길이는 링크 셧다운 패킷이 전송되는 시간에 효력을 갖는 인터페이스 타입 또는 링크 모드에 독립적이다. 그러므로 통상적인 패킷 길이는, 타입 1 모드에 대해 20 바이트 (패킷 전체로는 22 바이트), 타입 2 모드에 대해 36 바이트 (패킷 전체로는 38 바이트), 타입 3 모드에 대해 68 바이트 (패킷 전체로는 70 바이트), 그리고 타입 4 모드에 대해 132 바이트 (패킷 전체로는 134 바이트) 가 된다.
올 제로 필드는, MDDI_Data 신호가 충분한 시간 동안 로직 영 레벨에 있어 클라이어트가 호스트의 라인 드라이버를 디스에이블 하기 전에 MDDI_Stb 만을 이용하여 클록 복구를 시작할 수 있도록 하는 것을 보장하기 위해 가변수의 바이트를 이용한다. 올 제로 필드의 길이는 링크 셧다운 패킷이 전송되는 시간에 효력을 갖는 인터페이스 타입 도는 링크 동작 모드에 독립적이다. 올 제로 필드의 길이는, 여하한 인터페이스 타입 세팅에 대해 MDDI_Stb 상에서 64 펄스를 생성하도록 한다. 그러므로 각각의 인터페이스 타입에 대한 올 제로 길이는 타입 1 에 대해 16 바이트, 타입 2 에 대해 32 바이트, 타입 3 에 대해 64 바이트, 그리고 타입 4 에 대해 128 바이트가 된다.
CRC 필드는 패킷 길이에서 패킷 타입까지의 16 비트 CRC 바이트를 포함하는 2 바이트를 이용한다.
저 전력 휴지상태에서, MDDI_Data0 드라이버는 올 제로 필드의 마지막 비트 후 16 번째 내지 48 번째 MDDI_Stb 사이클 또는 펄스 후에 시작하는 고 임피던스 상태로 디스에이블된다. 타입 2, 타입 3, 또는 타입 4 링크에 대해, MDDI_Data1 내지 MDDI_DataPwr7 신호도, MDDI_Data0 드라이버가 디스에이블되는 시간과 동일한 시간에 고 임피던스 상태로 배치된다. 호스트 또는 클라이언트는 MDDI 링크가 다른 곳에서 설명되는 바와 같이 휴지상태로부터 "웨이크 업 (wake up)" 하도록 할 수 있으며, 이는 본 발명의 주요한 진보 또는 장점이다.
올 제로 필드의 정의에서 설명한 바와 같이, MDDI_Stb 는 링크 셧다운 패킷의 CRC 필드의 MSB 전 64 사이클동안 토글링하여 클라이언트 제어기에서의 순차적인 셧다운을 용이하게 한다. 한 사이클은 저에서 고로의 (low-to-high) 천이 후 고에서 저로의 (high-to-low) 천이, 또는 고에서 저로의 천이 후 저에서 고로의 천이이다. 올 제로 필드가 전송된 후, 호스트의 MDDI_Stb 드라이버는 디스에이블된다.
13. 클라이언트 요청 및 상태 패킷
호스트는 클라이언트로부터 적은 량의 정보를 필요로 하므로, 일반적으로 최적의 방식으로 호스트-대-클라이언트 링크를 구성할 수 있다. 클라이언트가 각각의 서브 프레임에서 하나의 클라이언트 요청 및 상태 패킷을 호스트로 송신할 것을 권장한다. 호스트에게 신뢰할 수 있게 전송되는 것을 보장하기 위해 클라이언트는 이 패킷을 역방향 링크 캡슐화 패킷의 첫 번째 패킷으로서 전송하는 것이 일반적으로 권장된다. 또한, 이러한 패킷의 전송은 역방향 링크 캡슐화 패킷의 역방향 링크 플래그를 이용하여 호스트에 의해 요청되는 경우에도 달성된다. 클라이언트 요청 및 상태 패킷은 오류 및 상태를 호스트에 보고하는데 이용된다. 외부 모드 동작에 대해서, 모든 호스트는 이러한 패킷을 수신할 수 있어야 하고, 모든 클라이언트는 적절하게 또는 최적으로 MDDI 프로토콜을 사용하기 위하여 이러한 패킷을 전송할 수 있어야 한다. 내부 호스트 및 내부 클라이언트인 내부 동작에 대해 이 패킷에 대한 지원이 있을 것이 권장되기는 하지만, 필수적이지는 않다.
클라이언트 요청 및 상태 패킷의 형식은 도 23 에 도시된다. 도 23 에 도시된 바와 같이, 이 타입의 패킷은, 패킷 길이, 패킷 타입, c클라이언트 ID, 역방향 링크 요청, 능력 변화, 클라이언트 비지 (Client Busy), CRC 오류 카운트 및 CRC 필드를 갖도록 구성된다. 일반적으로 이러한 타입의 패킷은 1-바이트 타입 필드의 타입 70 패킷으로서 식별되고, 통상적으로 12 바이트의 미리 선택된 고정 길이를 이용한다.
역방향 링크 요청 필드는, 클라이언트가 데이터를 호스트에게 다시 송신하기 위해 역방향 링크 캡슐화 패킷에서 필요로 하는 바이트의 수를 호스트에게 알려주기 위해 이용될 수도 있다. 호스트는 역방향 링크 캡슐화 패킷에서 적어도 그 수의 바이트를 할당함으로써 요청을 허가한다. 호스트는 데이터를 수용하기 위하여 서브 프레임에 하나 이상의 역방향 링크 캡슐화 패킷을 송신할 수 있다. 클라이언트는 언제라도 클라이언트 요청 및 상태 패킷을 송신할 수 있으며, 호스트는 역방향 링크 요청 파라미터를 하나의 서브 프레임에서 요청된 바이트의 총 수로 해석할 것이다. 역방향 링크 데이터가 호스트로 다시 송신되는 방법에 대한 상세한 및 구체적인 예는 아래에 나타낸다.
14. 비트맵 블록 전송 패킷
비트맵 블록 전송 패킷은 임의의 방향으로 디스플레이 영역을 스크롤하기 위한수단, 구성 또는 방법을 제공한다. 이 기능을 갖는 디스플레이는 클라이언트 능력 패킷의 디스플레이 특성 능력 표시자 필드의 비트 0 에서 능력을 보고할 것이다. 일 실시형태에 대한 비트맵 블록 전송 패킷의 형식이 도 24 에 도시된다. 도 24 에 도시된 바와 같이, 이 타입의 패킷은, 패킷 길이, 패킷 타입, h클라이언트 ID, 상부 좌측 X 값, 상부 좌측 Y 값, 윈도우 폭, 윈도우 높이, 윈도우 X 이동, 윈도우 Y 이동, 및 CRC 필드를 갖도록 구성된다. 일반적으로 이 타입의 패킷은 타입 71 패킷으로 식별되고, 일 실시형태에서 15 바이트의 미리 선택된 고정 길이를 이용한다. 2 바이트 h클라이언트 ID 필드는, 전술한 바와 같이 클라이언트 ID 를 위해 보류된 정보 또는 값을 포함한다. 이 필드는 일반적으로 장래의 사용을 위해 보류되기 때문에, 다른 값으로 설정되거나, 원하는 정보를 전송하기 위해 당업자가 이용할 수도 있지만, 이 비트를 로직 0 레벨로 설정함으로써 현재값은 통상적으로 0 으로 설정되어 있다.
일 실시형태에서, 2 바이트 픽셀 데이터 속성 필드는, 픽셀 데이터가 어디서 업데이트될지를 특정하는 값을 가지며, 비트 1 및 0 은 픽셀 데이터가 업데이트될 디스플레이를 선택한다. 클라이언트 내 주 디스플레이가 스테레오 이미지를 지원하지 않는 경우, 클라이언트는 주 디스플레이 내 픽셀 데이터를 비트 조합 01, 10 또는 11 중 하나로 할 수 있다. 값 11 은 스테레오 디스플레이 능력을 지원하지 않는 클라이언트 내 주 디스플레이를 어드레싱하는데 사용할 것을 추천한다. 비트 [1:0] 이 값 11 (더블 로직 1) 을 가지는 경우, 픽셀 데이터는 좌측눈 및 우측눈 모두의 프레임 버퍼에서 업데이트되고, 비트 [1:0] 이 값 10 (로직 1, 로직 0) 을 가지는 경우, 픽셀 데이터는 좌측눈의 프레임 버퍼에서만 업데이트된다. 비트 [1:0] 이 값 01 (로직 0, 로직 1) 을 가지는 경우, 픽셀 데이터는 우측눈의 프레임 버퍼에서만 업데이트된다. 비트 [1:0] 이 값 00 (더블 로직 0) 을 가지는 경우, 픽셀 데이터는 이하 비트 8 내지 11 에 의해 특정되는 교대 디스플레이의 프레임 버퍼에서 업데이트된다.
일 실시형태에서, 픽셀 데이터 속성 필드의 비트 2 는, 좌측눈 또는 우측눈에 대한 버퍼가 이 동작에 대한 이미지의 소스인지 여부를 특정한다. 비트 2 는 비트 [1:0] 이 00 과 동일하지 않은 경우에만 인가되며, 이것은 일반적으로 이미지의 수신지가 교대 디스플레이 중 하나인 경우 주 이미지 버퍼로부터의 소스 데이터를 지원하지 않는 것을 의미하도록 구현된다. 비트 2 는 데이터 소스에서와 같이 좌측눈 및 우측눈 프레임 버퍼 사이를 차별화 또는 특정하는데 사용된다. 비트 2 가 0 과 동일한 경우, 좌측눈 프레임 버퍼가 데이터 소스이고, 비트 2 가 1 과 동일한 경우, 우측눈 프레임 버퍼가 데이터 소스이다.
픽셀 데이터 속성 필드의 비트 3 은, 디스플레이를 리프레쉬하는데 사용되는 버퍼 또는 오프라인 이미지 버퍼가 이 동작에 대한 이미지의 소스가 될지 여부를 특정한다. 또한, 비트 3 은, 교대 디스플레이가 오프라인 이미지 버퍼를 이용하는 경우 교대 디스플레이에 인가될 수도 있다. 그러나, 이것은 이미지의 수신지가 교대 디스플레이인 경우 또는 그 반대의 경우, 주 이미지 버퍼로부터의 소스 데이터를 지원하지 않는다. 비트 3 이 0 의 값 또는 로직 0 레벨과 동일한 경우, 디스플레이를 리프레쉬하는데 사용되는 이미지 버퍼가 데이터 소스이다. 비트 3 이 1 의 값 또는 로직 1 레벨인 경우, 오프라인 이미지 버퍼가 데이터 소스이다.
픽셀 데이터 속성 필드의 비트 7 및 6 은, 픽셀 데이터가 업데이트되거나 기록되는 프레임 버퍼를 특정하는 디스플레이 업데이트 비트로서 동작한다. 프레임 업데이트 비트의 효과는 나중에 더 상세히 설명한다. 비트 [7:6] 이 '01' (로직 0, 로직 1) 인 경우, 픽셀 데이터는 오프라인 이미지 버퍼에 기록된다. 비트 [7:6] 이 '00' (더블 로직 0) 인 경우, 픽셀 데이터는 디스플레이를 리프레쉬하는데 사용되는 이미지 버퍼에 기록된다. 비트 [7:6] 이 '11' (더블 로직 1) 인 경우, 픽셀 데이터는 모든 이미지 버퍼에 기록된다. 비트 [7:6] 이 '10' 인 경우, 무효값으로 취급된다. 이러한 비트는 현재 장래의 사용을 위해 보류되어 있다. 이러한 상황에서는, 전체 커맨드가 무시되고 어떠한 프레임 버퍼도 업데이트되지 않는다.
픽셀 데이터 속성 필드의 비트 11 내지 8 은, 픽셀 데이터가 업데이트되는 교대 디스플레이 또는 교대 클라이언트 위치를 특정하는 4 비트 무부호 정수를 형성한다. 비트 0 및 1 은, 클라이언트가 비트 11 내지 8 을 교대 디스플레이 수로서 해석하도록 하기 위해 값 00 (더블 로직 0) 과 동일하게 설정된다. 비트 1 및 0 이 00 과 동일하지 않으면, 비트 8 내지 11 은 일반적으로 로직 0 값 또는 레벨로 설정된다. 비트 4 내지 5 및 12 내지 15 는 장래의 사용을 위해 보류되고 일반적으로 로직 0 레벨 또는 값으로 설정된다.
일 실시형태에서, 2 바이트 래스터 연산 필드 (Raster Operation field) 는, 소스 및 수신지 위치에서 픽셀을 합성하여 수신지 이미지 위치에 기록될 새로운 픽셀 값을 형성하는 방법을 특정한다. 래스터 연산은 프레임 버퍼에서 동일한 크기의 소스 영역 및 수신지 영역이 수신지 영역으로 병합되는 방법을 규정한다. 래스터 연산 또는 래스터 연산들에서 데이터에 대한 프로세싱의 흐름이 도 24b 에 도시되어 있다. 클라이언트가 클라이언트 능력 패킷에서 특정되는 래스터 연산 필드를 지원하지 않는 경우, 호스트는 일반적으로 비트 3 내지 0 을 3 과 동일하게 하여 이 필드를 전송하고 클라이언트는 비트 3 내지 0 을 무시한다.
일 실시형태에서, 비트 3 내지 0 은 실제 래스터 연산을 이하 표 7 에 나타낸 값들 중 하나로 설정하거나 사용함으로써 특정하여 다음에 나타내는 그 값에 대응하는 동작을 선택한다. 즉, 제 1 열에 리스트된 각각의 특정 비트 [3:0] 값은 제 2 열에 특정된 동작을 유발하고, 제 3 열에서 명확화를 위해 더 규정한다.
비트 [3:0] 값 수신지 위치에 저장된 값 규정
0 0
1 소스 & 수신지 로직 AND 연산
2 소스 & ~수신지 소스 AND (낫 (not) 수신지)
3 소스
4 ~소스 & 수신지 (낫 소스) AND 수신지
5 수신지 연산 없음
6 소스 ^ 수신지 로직 XOR 연산
7 소스 │ 수신지 로직 OR 연산
8 ~(소스 │ 수신지) 낫 (소스 OR 수신지)
9 ~(소스 ^ 수신지) 낫 (소스 XOR 수신지)
10 ~(수신지) 낫 (수신지)
11 소스 │ ~수신지 소스 OR (낫 수신지)
12 ~소스 낫 소스
13 ~소스 │ 수신지 (낫 소스) OR 수신지
14 ~(소스 & 수신지) 낫 (소스 AND 수신지)
15 올 1
비트 9 내지 8 은 수신지 픽셀이 투명 컬러와 관련된 수신지 위치에 기록되는지 여부를 특정하는데 사용된다. 클라이언트 능력 패킷의 클라이언트 특성 능력 지시자 필드의 비트 4 는, 투명 컬러 및 투명 마스크 능력이 클라이언트에 의해 지원되는지 여부를 나타낸다. 유사하게, 교대 디스플레이 능력 패킷의 디스플레이 특성 능력 지시자 필드의 비트 4 는, 투명 컬러 및 투명 마스크 능력이 특정 교대 디스플레이에 의해 지원되는지 여부를 나타낸다. 투명 컬러 및 투명 마스크가 지원되지 않으면, 래스터 연산은 비트 [9:8] 이 00 으로 설정된 것처럼 동작한다. 비트 [9:8] 에 의해 특정된 연산은, 래스터 연산이 클라이언트 디바이스에 의해 지원되는지 여부를 적용한다. 클라이언트가 래스터 연산을 지원하지 않으면, 비트 [9:8] 에 의해 규정된 연산에 대해 고려되는 해당 수신지 픽셀값은 소스 픽셀값에만 동일하다. 이러한 동작은 비트 [3:0] 을 3 으로 설정하는 경우와 동일하다.
비트 [9:8] 의 값이 00 과 동일한 경우, 투명 컬러는 사용되지 않는다. 해당 수신지 픽셀은 투명 컬러 또는 투명 마스크의 값을 고려하지 않고 수신지 픽셀 위치에 기록된다. 투명 컬러는 투명 컬러 및 마스크 설정 패킷에 의해 규정된다. 01 과 동일한 비트 [5:4] 값은 현재 장래의 사용을 위해 보류되어 있고 통상적으로 사용되지 않지만, 당업자가 관련된 사용을 확립하는데 이용할 수도 있다. 비트 [5:4] 의 값이 10 인 경우, 소스 픽셀이 투명 마스크로 AND 되는 래스터 연산에 의해 연산된 해당 수신지 픽셀이 투명 컬러와 동일하면 해당 픽셀은 수신지 픽셀 위치에 기록되지 않는다. 그렇지 않으면, 수신지 픽셀 위치에 기록된다. 비트 [9:8] 의 값이 11 과 동일한 경우, 래스터 연산에 의해 연산된 해당 수신지 픽셀이 투명 컬러와 동일하면 해당 픽셀은 수신지 픽셀 위치에 기록된다. 그렇지 않으면 해당 픽셀은 수신지 픽셀 위치에 기록되지 않는다.
비트 15 내지 10 및 7 내지 4 는 장래의 사용을 위해 보류되고, 따라서, 일반적으로 로직 0 값 또는 레벨과 동일하게 설정된다.
나머지 필드는 이동될 윈도우의 상부 좌측 코너 좌표의 X 및 Y 값, 이동될 윈도우의 폭 및 높이, 및 윈도우가 수평 및 수직으로 이동될 픽셀의 수를 각각 특정하는데 사용된다. 마지막 2 필드에 대한 양의 값은 윈도우가 우측 및 아래로 이동하게 하고, 음의 값은 좌측 및 위로 각각 이동하게 한다. CRC 필드 (여기서는 2 바이트) 는 패킷 길이를 포함하는 패킷에서 모든 바이트의 16 비트 CRC 를 포함한다.
15. 비트맵 영역 채움 패킷 (Bitmap Area Fill Packet)
비트맵 영역 채움 패킷은 디스플레이의 영역을 단일 컬러로 쉽게 초기화시키기 위한 수단, 구성 또는 방법을 제공한다. 이 능력을 갖는 디스플레이는, 클라이언트 능력 패킷의 클라이언트 특성 능력 표시자 필드의 비트 1 에서의 능력을 보고할 것이다. 비트맵 영역 채움 패킷의 형식에 대한 일 실시형태가 도 25 에 도시된다. 도 25 에 도시된 바와 같이, 이 경우에 이러한 타입의 패킷은, 패킷 길이, 패킷 타입, h클라이언트 ID, 비디오 데이터 형식 디스크립터, 픽셀 데이터 속성, 래스터 연산, 상부 좌측 X 값, 상부 좌측 Y 값, 윈도우 폭, 윈도우 높이, 픽셀 영역 채움값 및 CRC 필드를 갖도록 구성된다. 일반적으로, 이 타입의 패킷은 2 바이트 타입 필드에서 타입 72 패킷으로서 식별된다.
2 바이트 h클라이언트 ID 필드는 전술한 바와 같은 클라이언트 ID 를 위해 보류된 정보 또는 값을 포함한다. 이 필드는 일반적으로 장래의 사용을 위해 보류되기 때문에, 이 비트를 로직 0 레벨로 설정함으로써 통상적으로 0 으로 설정되지만, 원하는 정보를 전송하기 위해 다른 값으로 설정되거나 당업자가 이용할 수도 있다.
2 바이트를 사용하는 이 실시형태에서, 비디오 데이터 형식 디스크립터 필드는, 픽셀 데이터 채움 값의 형식을 특정한다. 이 형식은 전술한 비디오 스트림 패킷에서의 동일한 필드와 동일하다. 픽셀 영역 채움 값 필드 (4 바이트) 는 이 패킷의 파라미터에 의해 특정된 윈도우에 채워질 픽셀 값을 포함한다. 이 픽셀의 형식은 비디오 데이터 형식 디스크립터 필드에서 특정된다. 픽셀 영역 채움값에 대한 픽셀 형식의 예는 전술한 바와 동일하다. Y Cb Cr 형식이 선택되면, 투명 컬러 및 투명 마스크는 전술한 바와 같이, 픽셀 1 & 2 Cb, 픽셀 1 Y, 픽셀 1 & 2 Cr, 및 픽셀 2 Y 에 대한 서브 필드를 포함할 것이다. 투명 컬러값에 대해 할당되는 바이트의 수는 비디오 데이터 형식 디스크립터 필드에 의해 결정된다.
픽셀 데이터 속성 및 래스터 연산 필드는 전술한 비트맵 블록 전송 패킷의 동일한 필드와 유사하게 기능하고, 이하 더 상세히 설명한다.
나머지 필드는 이동될 윈도우의 상부 좌측 코너 좌표의 X 및 Y 값을 특정하는데 사용된다. 윈도우 상부 좌측 좌표 X 값 및 Y 값 필드는 2 바이트를 사용하여, 각각 채워질 윈도우의 상부 좌측 코너 좌표의 X 및 Y 값을 특정한다. 윈도우 폭 및 높이 필드 (각각 2 바이트) 는 채워질 윈도우의 폭 및 높이를 특정한다. CRC 필드 (여기서는 2 바이트) 는 패킷 길이를 포함하는 패킷에서 모든 바이트의 16 비트 CRC 를 포함한다.
16. 비트맵 패턴 채움 패킷 (Bitmap Pattern Fill Packet)
비트맵 패턴 채움 패킷은 디스플레이의 영역을 미리 선택된 패턴으로 쉽게 초기화시키기 위한 수단 또는 구성을 제공한다. 이 성능을 갖는 클라이언트는 클라이언트 능력 패킷의 클라이언트 특성 능력 필드의 비트 2 에서 이 성능을 보고한다. 수평 또는 수직 패턴 오프셋이 영이 아닌 경우가 아니면, 채움 패턴의 상부 좌측 코너는 채워질 윈도우의 상부 좌측 코너와 정렬된다. 채워질 윈도우가 채움 패턴보다 넓거나 높다면, 패턴은 윈도우를 채우기 위해 여러 번 수평 또는 수직으로 반복시킬 수 있다. 반복되는 마지막 패턴의 우측 또는 하부가 필요에 따라 절단된다. 윈도우가 채움 패턴보다 작다면, 채움 패턴의 우측 또는 하부가 윈도우에 맞도록 절단될 수 있다.
수평 패턴 오프셋이 영이 아니라면, 윈도우의 좌측과 좌측에 수평 패턴 오프셋을 더한 것 사이의 픽셀들은 패턴의 최 우측 픽셀들로 채워진다. 수평 패턴 오프셋은 패턴 폭보다 작아야 한다. 유사하게, 수직 패턴 오프셋이 영이 아니라면, 윈도우의 상측과 상측에 수직 패턴 오프셋을 더한 것 사이의 픽셀들은 패턴의 최하부 픽셀들로 채워진다. 수직 패턴 오프셋은 패턴 높이보다 작아야 한다.
비트맵 패턴 채움 패킷의 형식에 대한 일 실시형태가 도 26 에 도시되어 있다. 도 26 에 도시된 바와 같이, 이러한 타입의 패킷은 패킷 길이, 패킷 타입, h클라이언트 ID, 비디오 데이터 형식 디스크립터, 픽셀 데이터 속성, 래스터 연산, 상부 좌측 X 값, 상부 좌측 Y 값, 윈도우 폭, 윈도우 높이, 패턴 폭, 패턴 높이, 수평 패턴 오프셋, 수직 패턴 오프셋, 파라미터 CRC, 패턴 픽셀 데이터 및 픽셀 데이터 CRC 필드를 갖도록 구성된다. 일부 실시형태에서, 이러한 타입의 패킷은 일반적으로 1 바이트 타입 필드에서 타입 73 패킷으로 식별된다.
2 바이트 h클라이언트 ID 필드는 전술한 바와 같이 클라이언트 ID 를 위해 보류된 정보 또는 값을 포함한다. 이 필드는 일반적으로 장래의 사용을 위해 보류되기 때문에, 현재의 값은 이 비트를 통상적으로 로직 0 레벨로 설정함으로써 0 으로 설정되어 있다.
2 바이트 비디오 데이터 형식 디스크립터 필드는 픽셀 영역 채움 값의 형식을 특정한다. 도 11 은, 비디오 데이터 형식 디스크립터가 코딩되는 방법을 설명한다. 이 형식은 비디오 스트림 패킷의 동일한 필드와 동일하다.
픽셀 데이터 속성 및 래스터 연산 필드는 전술한 비트맵 블록 전송 패킷의 동일한 필드와 유사하게 기능하며, 이하 더 상세히 설명한다.
비트맵 패턴 채움 패킷의 나머지 필드는, 채워질 윈도우의 상부 좌측 코너 좌표의 X 및 Y 값, 채워질 윈도우의 폭 및 높이, 채움 패킷으로 사용될 패턴 폭 및 높이, 및 채워질 특정 윈도우의 좌측 및 탑 에지로부터 픽셀 데이터 패턴의 수평 및 수직 오프셋을 특정하는데 각각 사용된다. 패턴 CRC 필드 (여기서는 2 바이트) 는 패킷 길이부터 비디오 포맷 디스크립터까지의 패킷에서 모든 바이트의 16 비트 CRC 를 포함한다. 이 CRC 가 체크를 실패하면, 전체 패킷은 폐기될 것이다. 패턴 픽셀 데이터 CRC 필드는 패턴 픽셀 데이터만의 16 비트 CRC 를 포함한다. 이 CRC 가 체크를 실패하면, 패턴 픽셀 데이터는 여전히 사용될 수도 있지만 CRC 오류 카운트는 증가될 것이다. 패턴 픽셀 데이터 필드는, 비디오 데이터 형식 디스크립터에 의해 특정된 형식으로 채움 패턴을 특정하는 미가공 비디오 정보를 포함한다.
17. 판독 프레임 버퍼 패킷
판독 프레임 버퍼 패킷은 역방향 링크를 통해 호스트로 역전송될 클라이언트 내의 프레임 버퍼의 장방형 영역을 선택, 결정, 또는 특정하는 구조, 수단 또는 방법을 제공한다. 반환될 픽셀 데이터의 형식은 디스플레이 고유의 형식이고, 이 포맷은 일반적으로 역방향 링크를 통해 호스트로 전송될 비디오 스트림 패킷의 데이터 포맷 디스크립터 필드에서 특정된다. 호스트로 반환될 픽셀 데이터는 현재 디스플레이되고 있는 이미지 버퍼로부터이다. 일반적으로 클라이언트는 판독 프레임 버퍼 패킷에 의해 특정된 디스플레이 영역을 반환하는데 필요한 만큼 많은 역방향 링크 캡슐화 패킷에서 그만큼 많은 비디오 스트림 패킷을 사용한다. 이 능력을 갖는 클라이언트는 클라이언트 능력 패킷의 클라이언트 속성 능력 지시자의 비트 3 을 사용하여 이 능력을 보고하거나 또는 이를 나타낸다.
판독 프레임 버퍼 패킷에 대한 일시형태의 형식이 도 27 에 도시되어 있다. 도 27 에 도시된 바와 같이, 이러한 타입의 패킷은 패킷 길이, 패킷 타입, h클라이언트 ID, 디스플레이 데이터 속성, X 좌측 에지, Y 탑 에지, X 우측 에지, Y 바닥 에지, 및 CRC 필드를 갖도록 구성된다. 일 실시형태에서, 이러한 타입의 패킷은 일반적으로 타입 필드에서 타입 74 패킷으로 식별된다.
2 바이트 패킷 길이 필드는 패킷 길이 필드를 포함하지 않은 패킷에서 바이트의 총 수를 특정한다. 일 실시형태에서, 이 패킷 길이는 16 으로 고정된다. 2 바이트 h클라이언트 ID 필드는 전술한 바와 같이 클라이언트 ID 를 위해 보류된 정보 또는 값을 포함한다. 이 필드는 일반적으로 장래의 사용을 위해 보류되기 때문에, 당업자가 원하는 정보를 전송하는데 사용될 수도 있지만, 현재는 이 비트를 '0' (로직 0 레벨 또는 상태) 으로 설정함으로써 0 으로 설정되어 있다.
일 실시형태에서, 2 바이트 디스플레이 데이터 속성 빌드는, 픽셀 데이터가 어디서 판독되는지를 특정하는 값을 가지며, 비트 0 은 픽셀 데이터가 판독될 프레임 버퍼를 특정한다. 비트 0 이 값 0 (로직 0) 과 동일한 경우, 픽셀 데이터는 이하 비트 8 내지 비트 11 에 의해 특정되는 교대 디스플레이의 프레임 버퍼로부터 판독된다. 비트 0 이 값 1 (로직 1) 과 동일한 경우, 픽셀 데이터는 주 디스플레이의 프레임 버퍼로부터 판독된다.
일 실시형태에서, 디스플레이 데이터 속성 필드의 비트 2 는 좌측눈 또는 우측눈 프레임 버퍼에 대한 버퍼가 판독될 데이터의 소스인지 여부를 특정한다. 일반적으로, 비트 2 는 주 디스플레이가 스테레오 이미지를 지원하는 경우에만 인가된다. 비트 2 가 0 (로직 0 레벨) 과 동일한 경우, 좌측눈 프레임 버퍼가 데이터 소스이고, 비트 2 가 1 (로직 1 레벨) 과 동일한 경우, 우측눈 프레임 버퍼가 데이터 소스이다.
디스플레이 데이터 속성 필드의 비트 3 은, 디스플레이를 리프레쉬하는데 사용되는 버퍼 또는 오프라인 이미지 버퍼가 이 동작에 대한 이미지의 소스가 될지 여부를 특정한다. 또한, 교대 디스플레이가 오프라인 이미지 버퍼를 이용하면 비트 3 은 교대 디스플레이에만 인가될 수도 있다. 그러나, 이것은 이미지의 수신지가 교대 디스플레이인 경우 또는 그 반대의 경우 주 이미지 버퍼로부터의 소스 데이터를 지원하지 않는다. 비트 3 이 0 의 값 또는 로직 0 레벨과 동일한 경우, 디스플레이를 리프레쉬하는데 사용되는 이미지 버퍼가 데이터 소스이다. 비트 3 이 1 의 값 또는 로직 1 레벨과 동일한 경우, 오프라인 이미지 버퍼가 데이터 소스이다.
디스플레이 데이터 속성 필드의 비트 11 내지 8 은, 픽셀 데이터가 판독될 교대 클라이언트 위치 또는 디스플레이를 특정한다. 비트 0 은, 클라이언트가 비트 11 내지 8 을 교대 디스플레이 수로 해석하도록 값 0 (로직 0) 과 동일하게 설정된다. 비트 0 이 0 과 동일하지 않으면, 비트 8 내지 11 은 일반적으로 로직 0 값 또는 레벨과 동일하게 설정된다. 비트 1, 4 내지 7 및 12 내지 15 는 장래의 사용을 위해 예약되고 일반적으로 로직 0 레벨 또는 0 값으로 설정된다.
일 실시형태에서, 2 바이트 X 좌측 에지 및 Y 탑 에지 필드는 픽셀 데이터 필드에 의해 채워질 스크린 윈도우 좌측 에지의 X 좌표 및 탑 에지의 Y 좌표를 특정하며, X 우측 에지 및 Y 바닥 에지 필드는 업데이트되는 윈도우 우측 에지의 X 좌표, 및 바닥 에지의 Y 좌표를 특정한다.
일 실시형태에서, 2 바이트 CRC 필드는 패킷 길이를 포함하는 패킷에서 모든 바이트의 CRC 를 특정하거나 포함한다.
18. 디스플레이 전력 상태 패킷
디스플레이 전력 상태 패킷은, 디스플레이와 같은 클라이언트가 사용되지 않거나 현재 능동적으로 사용되지 않는 경우 시스템 리소스에서 시스템 전력 소비 또는 드레인을 최소화하기 위해, 제어되는 특정 클라이언트 또는 관련되거나 접속된 클라이언트, 또는 제어기 하드웨어를 저전력 상태에 두는 구조, 수단 또는 방법을 제공한다. 이러한 타입의 패킷은 외부 모드 구성 또는 동작에 대한 인터페이스 또는 인터페이스 구조 및 프로토콜의 애플리케이션에 가장 유용하다. 이러한 애플리케이션에서는, 외부 장치가 배터리와 같은 한정된 전력 리소스 상에서 동작하거나 또는 한정된 공간에서의 오버히팅과 같은 또 다른 전력 제한 및 관계를 가져서, 주기 또는 비활동 또는 비사용에 대해 최소한의 동작 조건이 요구된다. 일 실시형태에서는, 클라이언트가 클라이언트 능력 패킷의 클라이언트 특성 능력 표시자 필드의 9 비트를 사용하여 디스플레이 전력 상태 패킷에 대응하는 능력을 나타낸다.
디스플레이 전력 상태 패킷에 대한 일 실시형태의 형식이 도 28 에 도시되어 있다. 도 28 에 도시된 바와 같이, 일 실시형태에서, 이러한 타입의 패킷은 패킷 길이, 패킷 타입, h클라이언트 ID, 전력 상태 및 CRC 필드를 갖도록 구성된다. 이러한 타입의 패킷은 일반적으로 2-바이트 타입 필드의 타입 75 패킷으로서 식별되고, 미리 선택된 8 바이트의 고정 길이를 사용한다. 2-바이트 h클라이언트 ID 필드는 미리 사용된 바와 같이, 클라이언트 ID 에 대해 보류된 정보 또는 값을 포함한다. 이러한 필드는 일반적으로 장래의 사용을 위해 보류되기 때문에, 현재값은 비트를 '0' (로직 0 레벨 또는 상태) 으로 설정함으로써 0 으로 설정되지만, 이는 원하는 정보를 전송하기 위한 당업자가 이용할 수도 있다.
여기서는 2 바이트인 전력 상태 필드는, 디스플레이와 같은 클라이언트에 관련된 특정 장치, 하드웨어, 또는 설비를 특정한 전력 상태에 두는데 사용되는 정보를 특정한다. 디스플레이를 위해 사용되는 경우, 이 필드의 비트 0 은 패킷이 주 디스플레이에 적용되고 있는지 다른 디스플레이에 적용되고 있는지 여부를 특정한다. 비트 0 이 1 인 경우, 패킷은 주 디스플레이에 적용된다. 비트 0 이 0 인 경우, 패킷은 비트 11 내지 8 에 의해 특정된 다른 디스플레이에 적용된다. 비트 1 은 장래의 사용을 위해 보류되고 일반적으로 0 으로 설정된다.
전력 상태 필드의 비트 3 내지 2 는 비트 11 내지 8 및 비트 0 에 의해 선택된 디스플레이의 전력 상태를 특정한다. 비트 [3:2] 가 '00' 의 값을 가지는 경우, 선택된 디스플레이는 발광하지 않고, 최소량의 전력을 소모할 것이고, 프레임 버퍼의 콘텐츠는 이 상태동안 보류되는 것이 보장되지 않는다. 비트 [3:2] 가 '01' 의 값을 가지는 경우, 선택된 디스플레이는 발광하지 않고 비교적 최소량의 전력이 소모되며, 프레임 버퍼의 콘텐츠는 이 상태동안 보류되는 것이 보장된다. 디스플레이는 상태 00 에서보다 더 많은 전력을 소모할 수도 있다. 클라이언트는 클라이언트 능력 패킷의 클라이언트 특성 능력 표시자 필드의 비트 10 을 사용하여 상태 01 을 지원할 능력을 나타낼 수 있다. 전력 상태 필드의 비트 [3:2] 가 '10' 의 값을 가지는 경우, 선택된 디스플레이는 발광하고 관련 프레임 버퍼로부터 이미지를 디스플레이한다. 비트 [3:2] 에 대한 '11' 의 값은 장래의 사용을 위해 보류된 값 또는 상태이며 사용되지 않는다.
이러한 패킷의 사용은 디스플레이 애플리케이션에 가장 유용하지만 본 발명에 의해 디스플레이에만 한정되는 것은 아니며, MDDI 가 사용되거나, 클라이언트가 제어되거나 통신하는 다른 하드웨어 소자와 관련하여 전력 제어가 필요하거나 요구될 수도 있는 또 다른 애플리케이션, 구성 또는 상황이 존재할 수도 있음을 당업자는 인식할 것이다. 이러한 상황에서, 전술한 비트들은 유사한 기능을 가질 수도 있지만, 이해하는 바와 같이, 이러한 소자들의 주요 소자 또는 부수적 소자를 활성화시키거나 전력 레벨을 설정하는 것 등을 할 수 있다.
일 실시형태에서, 전력 상태 필드의 비트 11 내지 8 은, 전력 상태가 적용되는 또 다른 디스플레이를 특정하는 4-비트의 무부호 정수를 형성한다. 비트 0 은, 클라이언트가 비트 11 내지 8 을 또 다른 디스플레이 수로 해석할 수 있도록 로직 0 값으로 설정된다. 비트 0 이 1 인 경우, 비트 11 내지 8 은 0 이다.
비트 7 내지 4 및 비트 15 내지 12 는 장래의 사용을 위해 보류되고, 일반적으로 현재 애플리케이션 또는 설계를 위해 로직 0 레벨 또는 값으로 설정된다.
2 바이트의 CRC 필드는 패킷 길이를 포함하는 패킷의 모든 바이트의 CRC 를 특정하거나 포함한다.
디스플레이 전력 상태가 일반적으로 인터페이스 구조 또는 프로토콜에 의해 지원되는 요약을 이하 표 8 에 나타낸다. 나타낸 바와 같이, 다양한 조합의 클라이언트 특성 능력 비트 10 및 9 가 원하는 전력 상태 중 다양한 하나를 확립, 설정 또는 트리거하는데 사용된다. 주어진 행 및 열 위치에 나타낸 표시는, 그 열의 상단에 특정된 디스플레이 전력 상태가 클라이언트 특성 능력 지시자 비트의 조합에 대해 지원되는지를 나타낸다. 표 8 의 제 1 및 제 3 행에서는, 클라이언트가 디스플레이 전력 상태 패킷을 지원할 능력을 갖지 않는 경우 전력 상태 "10" 만 허용되는 것을 알 수 있다. 디스플레이 전력 상태가 디스플레이에 전송될 수 없는 경우에도, 단일 마크는, 디스플레이가 "언제나 온" 상태에 있고 저 전력 상태에 있을 수 없음을 나타낸다.
클라이언트 특성 능력 표시자 비트 9 및 10 값 전력 상태 = 00 전력 상태 = 01 전력 상태 = 10
비트 9 = 0 및 비트 10 = 0 비트 9 = 1 및 비트 10 = 0 비트 9 = 0 및 비트 10 = 1 비트 9 = 1 및 비트 10 = 1 X X X X X X X
19. 수행 타입 핸드오프 패킷
수행 타입 핸드오프 패킷은, 이 패킷에서 특정된 모드로 핸드오프 하도록 클라이언트에 명령하기 위해 호스트가 사용하는 수단, 구성 또는 방법이다. 이것은, 클라이언트 능력 패킷에서 설명한 바와 같이, 클라이언트에 의해 지원되는 인터페이스 타입 설정 중 하나이다. 호스트 및 클라이언트는, 이 패킷이 송신된 직후에 특정한 순방향 및 역방향 링크 인터페이스 타입을 스위칭해야 한다. 수행 타입 핸드오프 패킷에 대한 일 실시형태의 형식이 도 29 에 도시되어 있다. 타입 1 과는 다른 인터페이스 타입을 지원하는 호스트 및 클라이언트는 이 패킷을 위한 지원을 제공해야 한다. 일반적으로, 호스트는 수행 타입 핸드오프 패킷을 송신하기 직전에 클라이언트 요청 및 상태 패킷을 판독하여 클라이언트가 호스트와 동기인지를 확인하는 것이 바람직하다.
도 29 에 도시된 바와 같이, 일 실시형태에서, 이러한 타입의 패킷은 패킷 길이, 패킷 타입, 인터페이스 타입, 보류 1, 지연 필러, 및 CRC 필드를 갖도록 구성된다. 이러한 타입의 패킷은 일반적으로 2-바이트 타입 필드에서 타입 77 패킷으로 식별된다.
일 실시형태에서, 인터페이스 타입 필드는 1 바이트값을 사용하여, 링크를 위해 채용되거나 사용될 새로운 인터페이스 타입을 확인한다. 이 필드의 값은 다음의 방식으로 인터페이스 타입을 특정하거나 표현한다. 비트 2 내지 0 은 순방향 링크 상에서 사용될 인터페이스 타입을 정의하고, 1 의 값은 타입 1 모드의 핸드오프를 나타내거나 특정하고; 2 의 값은 타입 2 모드의 핸드오프, 3 의 값은 타입 3 모드의 핸드오프, 및 4 의 값은 타입 4 모드의 핸드오프를 나타내거나 특정한다. 비트 5 내지 3 은 역방향 링크 상에서 사용되는 인터페이스 타입을 정의하고, 1 의 값은 타입 1 모드의 핸드오프를 나타내거나 특정하고; 2 의 값은 타입 2 모드의 핸드오프, 3 의 값은 타입 3 모드의 핸드오프, 및 4 의 값은 타입 4 모드의 핸드오프를 나타내거나 특정한다. 0, 5 내지 7 의 값은 장래의 사용을 위해 현재 보류되어 있다.
지연 필러 필드는, 수행 인터페이스 타입 핸드오프 패킷 직후의 패킷 개시시에 새로운 인터페이스 타입을 사용하기 위해 클라이언트가 설정 또는 사용으로 스위칭하도록 준비하거나 구성되는 시스템의 부분 상에서 충분한 시간을 허용하는 수단, 구조, 또는 방법으로서 생성된다. 이 필드는, 모두 로직 0 레벨 또는 값으로 설정되거나 그와 동일한 일 군의 바이트 또는 8-비트 값을 포함한다. 이 필드에서 사용되는 바이트의 수는, 이 필드가 64 MDDI_Stb 사이클과 동등한 길이가 되도록 선택된다. 지연 필러 필드의 길이는 순방향 링크의 인터페이스 타입 설정에 기초하여, 타입 1 순방향 링크 인터페이스 타입에 대해서는 16 바이트, 타입 2 인터페이스 타입에 대해서는 32 바이트, 타입 3 인터페이스 타입에 대해서는 64 바이트일 것이고, 타입 4 순방향 링크 인터페이스 타입을 특정하거나 사용하는 경우에는 128 바이트일 것이다.
보류 1 필드 (여기서는 1 바이트) 는 장래 정보를 통지하는데 사용하기 위해 보류된다. 이 필드의 모든 비트는 일반적으로 로직 0 레벨로 설정된다. 이러한 필드의 목적은, 모든 후속 2 바이트 필드가 16-비트 워드 어드레스로 정렬하고 4-바이트 필드가 32-비트 워드 어드레스로 정렬하게 하는 것이다. CRC 필드 (여기서는 2 바이트) 는 패킷 길이를 포함하는 패킷에서 모든 바이트의 16-비트 CRC 를 포함한다.
20. 순방향 오디오 채널 인에이블 패킷
이 패킷은, 호스트가 클라이언트의 오디오 채널을 인에이블 또는 디스에이블할 수 있도록 하는 구성, 방법 또는 수단을 제공한다. 이 성능은, 호스트에 의해 출력될 오디오가 없을 경우에 클라이언트 (예컨대, 디스플레이) 가 전력을 절약하기 위해 오디오 증폭기 또는 유사한 회로 소자를 끌 (power off) 수 있도록 하는데 유용하다. 이것은, 오디오 스트림의 존재 또는 부재를 표시자로서 단순히 이용하여서 내부적으로 구현하기가 훨씬 더 어렵다. 클라이언트 시스템이 파워 업 (powered-up) 되는 디폴트 상태는 모든 오디오 채널이 인에이블된 상태이다. 순방향 오디오 채널 인에이블 패킷의 일 실시형태의 형식이 도 30 에 도시된다. 도 30 에 도시된 바와 같이, 이 타입의 패킷은, 패킷 길이, 패킷 타입, h클라이언트 ID, 오디오 채널 인에이블 마스크 및 CRC 필드를 갖도록 구성된다. 일반적으로, 이러한 타입의 패킷은 1-바이트 타입 필드에서 타입 78 패킷으로 식별되고, 4 바이트의 미리 선택된 고정 길이를 이용한다.
21. 역방향 오디오 샘플 레이트 패킷
이 타입의 패킷은, 호스트가 클라이언트의 오디오 채널을 인에이블하거나 디스에이블하게 하는 구조, 방법 또는 수단을 제공한다. 이 능력은 매우 유용하여, 호스트에 의해 출력될 오디오가 없는 경우 클라이언트는 오디오 증폭기를 파워오프하여 전력을 절약할 수 있다. 오디오 스트림의 존재 또는 부재를 사용하여 내부적으로 구현하는 것은 매우 어렵다. 클라이언트 시스템이 파워업되거나 호스트에 접속되는 경우 디폴트 상태는 모든 오디오 채널이 인에이블되는 상태이다. 호스트 및 클라이언트에 접속된 오디오 시스템은, 0 으로부터 1 상태 또는 값으로 천이한 오디오 채널 인에이블 마스크 필드에서 하나 이상의 비트를 갖는 순방향 오디오 채널 인에이블 패킷을 클라이언트가 수신한 후, 약 100 밀리세컨드 이하내에 의도한 또는 원하는 방식으로 오디오 신호를 출력할 준비가 되거나 출력할 수 있다. 클라이언트는 클라이언트 능력 패킷의 오디오 채널 능력 필드의 비트 15 에 대해 설정된 값을 사용하여 순방향 오디오 채널 인에이블 패킷에 대응하는 능력을 나타낸다.
이 패킷은, 호스트로 하여금 역방향 링크 오디오 채널을 인에이블 또는 디스에이블 하고, 이 스트림의 오디오 데이터 샘플 레이트를 설정할 수 있게 한다. 호스트는 클라이언트 능력 패킷에서 유효하다고 규정된 샘플 레이트를 선택한다. 호스트가 유효하지 않은 샘플 레이트를 선택하는 경우, 클라이언트는 오디오 스트림을 호스트에게 송신하지 않고, 적절한 오류, 오류 값 또는 오류 신호가 클라이언트 오류 보고 패킷에서 호스트에게 전송될 수 있다. 호스트는 샘플 레이트를 255 로 설정함으로써 역방향 링크 오디오 스트림을 디스에이블 할 수 있다. 클라이언트 시스템이 초기에 파워 업되거나 접속되는 때에 가정되는 디폴트 상태는 역방향 링크 오디오 스트림이 디스에이블 된 것이다. 역방향 오디오 샘플 레이트 패킷에 대한 일 실시형태의 형식은 도 31 에 도시된다. 도 31 에 도시된 바와 같이, 이 타입의 패킷은, 패킷 길이, 패킷 타입, h클라이언트 ID, 오디오 샘플 레이트, 보류 1 및 CRC 필드를 갖도록 구성된다. 일반적으로, 이 타입의 패킷은 타입 79 패킷으로 식별되며, 4 바이트의 미리 선택된 고정 길이를 이용한다.
22. 디지털 컨텐츠 보호 오버헤드 패킷
이 패킷은, 호스트 및 클라이언트가 하여금 사용되고 있는 디지털 컨텐츠 보호 방법에 관한 메시지를 교환할 수 있도록 하는 구성, 방법 또는 수단을 제공한다. 현재, 디지털 송신 컨텐츠 보호 (Digital Transmisson Content Protection; DTCP), 또는 고-대역폭 디지털 컨텐츠 보호 시스템 (High-bandwidth Digital Content Protection System; HDCP) 시스템의 2 타입의 컨텐츠 보호가, 장래의 대안적 보호 방식 지정을 위한 공간을 예비하여 고려된다. 이용되고 있는 방법은 이 패킷의 컨텐츠 보호 타입 파라미터에 의해 특정된다. 디지털 컨텐츠 보호 오버헤드 패킷의 일 실시형태의 형식이 도 32 에 도시된다. 도 32 에 도시된 바와 같이, 이 타입의 패킷은, 패킷 길이, 패킷 타입, b클라이언트 ID, 컨텐츠 보호 타입, 컨텐츠 보호 오버헤드 메시지, 및 CRC 필드를 갖도록 구성된다. 일반적으로, 이 타입의 패킷은 타입 80 패킷으로 식별된다.
23. 투명 컬러 및 마스크 설정 패킷
투명 컬러 및 마스크 설정 패킷은, 어떠한 컬러가 투명한지를 특정하고 이미지 표시용 투명 컬러의 이용을 인에이블 또는 디스에이블하는데 이용되는 구성, 방법 또는 수단이다. 일 실시형태에서, 이 성능을 갖는 디스플레이 또는 클라이언트는 클라이언트 능력 패킷의 클라이언트 특성 능력 필드의 비트 4 에서 그 성능을 보고한다. 투명 컬러에 대한 값을 갖는 픽셀이 비트맵에 기록되는 경우, 컬러는 이전 값으로부터 변경되지 않는다. 투명 컬러 인에이블 패킷의 형식은 도 33 에 도시된다. 도 33 에 도시된 바와 같이, 일 실시형태에서 이러한 타입의 패킷은, 패킷 길이, 패킷 타입, h클라이언트 ID, 디스플레이 데이터 속성, 보류 1, 데이터 형식 디스크립터, 투명 컬러 값, 투명 마스크 값 및 CRC 필드를 갖도록 구성된다. 일반적으로, 이러한 타입의 패킷은 1-바이트 타입 필드에서 타입 81 패킷으로 식별되고, 16 바이트의 미리 선택된 고정 길이를 이용한다.
h클라이언트 ID 는 장래의 구현에서 클라이언트 ID 로 사용하기 위해 보류되어 있고, 통상적으로 0 값 (로직 0 비트) 으로 설정된다.
일 실시형태에서, 2 바이트 디스플레이 데이터 속성 필드는, 어디에 투명 픽셀 컬러가 인가될지를 특정하는 값을 가지며, 비트 0 은 투명 픽셀 컬러가 인가될 디스플레이를 선택한다. 비트 0 이 값 0 (로직 0) 과 동일하게 설정되는 경우, 투명 픽셀 컬러는 이하 비트 8 내지 11 에 의해 특정되는 교대 디스플레이에 인가된다. 비트 0 이 값 1 (로직 1) 과 동일한 경우, 투명 픽셀 컬러는 주 디스플레이에 인가된다.
일 실시형태에서, 비트 1 은, 투명 컬러 또는 마스크 필드가 투명 컬러 또는 투명 마스크를 포함하는지 여부를 선택 또는 특정한다. 비트 0 이 0 (로직 0) 과 동일한 경우, 투명 컬러 또는 마스크 필드는, 후속 래스터 연산에서 사용되거나, 또는 비디오 스트림 패킷 또는 스케일링된 비디오 스트림 패킷의 디코딩시에 사용되는 투명 컬러 값을 포함한다. 비트 0 이 1 (로직 1) 과 동일한 경우, 투명 컬러 또는 마스크 필드는, 후속 래스터 연산에서 사용되거나, 또는 비디오 스트림 패킷 또는 스케일링된 비디오 스트림 패킷의 디코딩시에 사용되는 투명 마스크 값을 포함한다.
디스플레이 데이터 속성 필드의 비트 11 내지 8 은 투명 픽셀 컬러가 인가될 교대 클라이언트 위치 또는 디스플레이를 특정한다. 비트 0 은, 클라이언트가 비트 11 내지 8 을 교대 디스플레이 수로 해석하도록 0 (로직 0) 의 값과 동일하게 설정된다. 비트 0 이 0 과 동일하지 않으면, 비트 8 내지 11 은 일반적으로 로직 0 값 또는 레벨과 동일하게 설정되고 무시된다.
디스플레이 데이터 속성 필드의 비트 7 내지 2 및 15 내지 12 는 장래의 사용을 위해 보류되고, 일반적으로 로직 0 레벨 또는 0 값으로 설정된다.
2 바이트의 보류 1 필드는 장래의 사용을 위해 보류된다. 이 필드의 모든 비트는 일반적으로 0 (로직 0 레벨 또는 상태) 으로 설정된다. 일 실시형태에서, 이 필드의 목적은, 모든 후속 2 바이트 필드가 16 비트 워드 어드레스로 정렬되게 하고, 4 바이트 필드를 32 비트 워드 어드레스로 정렬되게 하는 것이다.
일 실시형태에서, 투명 컬러 인에이블 패킷의 비디오 데이터 형식 디스크립터 필드는 2 바이트를 사용하여 투명 컬러 값의 형식을 특정한다. 도 11 은 비디오 데이터 형식 디스크립터가 코딩되는 방법을 도시한다. 이 형식은 비디오 스트림 패킷의 동일한 필드와 동일하다.
일 실시형태에서, 투명 컬러 값 필드는, 후속 래스터 연산에서, 또는 비디오 스트림 패킷 또는 스케일링된 비디오 스트림 패킷의 디코딩시에, 투명 컬러의 값으로서 사용될 픽셀 값에 대해 몇몇 바이트 (이 예에서는, 패킷의 길이 - 넌 "값" 필드에 대해서 12 로서 지정되고 투명 마스크 필드와 공유하기 위해 2 로 나눠짐) 를 특정 또는 할당하는데 사용된다. 이 값의 형식은 비디오 데이터 형식 디스크립터 필드에서 특정된다. 투명 컬러에 대한 픽섹 형식의 예는 전술한 바와 동일하다. Y Cb Cr 형식이 선택되면, 투명 컬러 및 투명 마스크는 통상적으로 전술한 바와 같이, 픽셀 1 & 2 Cr, 픽섹 1 Y, 픽셀 1 & 2 Cr, 및 픽섹 2 Y 에 대한 서브 필드를 포함한다. 투명 컬러 값에 대해 할당되는 바이트의 수는 비디오 데이터 형식 디스크립터 필드에 의해 결정된다.
일 실시형태에서, 투명 마스트 값 필드는, 후속 래스터 연산에서, 또는 비디오 스트림 패킷 또는 스케일링된 비디오 스트림 패킷의 디코딩시에, 투명 마스크로서 사용될 픽셀 값에 대해 몇몇 바이트 (이 예에서는, 패킷의 길이 - 넌 "값" 필드에 대해서 12 로서 지정되고 투명 마스크 필드와 공유하기 위해 2 로 나눠짐) 를 특정 또는 할당하는데 사용된다. 이 값의 형식은 비디오 데이터 형식 디스크립터 필드에서 특정되는 투명 컬러 값의 형식과 동일하다. 이 필드에 할당되는 바이트의 수는 비디오 데이터 형식 디스크립터 필드에 의해 결정된다. 이 필드의 길이는 투명 컬러 값 필드의 길이와 동일하다.
일 실시형태에서, 투명 또는 마스크 값 필드는, 디스플레이 데이터 속성 필드의 비트 1 에 의해 특정되는 바와 같이 픽셀 값을 투명 컬러 또는 투명 마스크의 값으로서 사용하기 위해 4 바이트를 사용 또는 할당한다. 이 픽셀의 형식은 비디오 데이터 형식 디스크립터 필드에서 특정된다.
CRC 필드는 2 바이트를 사용하여 패킷 길이를 포함하는 패킷에서 모든 바이트의 CRC 를 포함하거나 표현한다.
24. 라운드 트립 지연 측정 패킷
라운드 트립 지연 측정 패킷은, 호스트로부터 클라이언트 (디스플레이) 로의 전송 지연 더하기 클라이언트 (디스플레이) 로부터 다시 호스트로의 지연을 측정하는데 이용되는 구성, 방법 또는 수단을 제공한다. 이 측정은 본질적으로 라인 드라이버와 수신기, 및 상호 접속된 하위 시스템에 존재하는 지연을 포함한다. 이 측정은 일반적으로 상술되었던, 역방향 링크 캡슐화 패킷 내의 턴 어라운드 지연 및 역방향 링크 레이트 제수 파라미터를 설정하는데 이용된다. 이 패킷은, MDDI 링크가 특정한 애플리케이션을 위해 의도된 최대 속도로 실행되고 있는 경우에 가장 유용하다. 이 패킷은 타입 1 모드에서, 그리고 라운드 트립 지연 측정 범위를 증가시키기 위하여 더 낮은 데이터 레이트로 전송될 수 있다. MDDI_Stb 신호는, 다음의 필드, 즉 올 제로 및 보호 시간, 및 측정 주기 모두 동안 올 제로 데이터가 송신되는 것처럼 동작한다. 이는 MDDI_Stb 가 그 데이터 레이트의 반으로 토글링하게 하므로, 측정 주기 동안 클라이언트에서 주기적인 클록으로 이용될 수 있다.
일 실시형태에서, 클라이언트는 일반적으로, 클라이언트 능력 패킷의 클라이언트 특성 능력 표시자 중 비트 18 의 이용을 통해 라운드 트립 지연 측정 패킷을 지원하는 능력을 나타낸다. 모든 클라이언트가 라운드 트립 지연 측정을 지원하는 것이 권장되지만, 호스트가 최대 케이블 지연과 최대 드라이버 및 수신기 지연에 기초하여 최악의 경우의 라운드 트립 지연을 인지하는 것도 가능하다. 또한, 이것은 인터페이스가 이용되고 있는 장치의 알려진 설계 요소 (콘덕터 길이, 회로 타입 및 특성 등) 의 일 태양이므로, 호스트는 내부 모드에 이용되는 MDDI 링크에 대해 미리 라운드 트립 지연을 인지할 수도 있다.
라운드 트립 지연 측정 패킷의 형식은 도 34 에 도시된다. 도 34 에 도시된 바와 같이, 일 실시형태에서 이 타입의 패킷은, 패킷 길이, 패킷 타입, h클라이언트 ID, 파라미터 CRC, 보호 시간 1, 측정 주기, 올 제로 및 보호 시간 2 필드를 갖도록 구성된다. 일반적으로, 이 타입의 패킷은 타입 82 패킷으로 식별되고, 200 비트의 미리 선택된 고정 길이를 이용한다.
라운드 트립 지연 측정 패킷 동안 발생하는 이벤트의 타이밍이 도 35 에 도시된다. 도 35 에서, 호스트는, 올 제로 및 보호 시간 1 필드 전에 오는 파라미터 CRC 및 스트로브 정렬 필드의 존재에 의해 도시된, 라운드 트립 지연 측정 패킷을 송신한다. 패킷이 클라이언트 디스플레이 장치 또는 프로세싱 회로에 도달하기 이전에 지연 (3502) 이 발생한다. 클라이언트가 패킷을 수신함에 따라, 클라이언트는, 클라이언트에 의해 결정된 측정 주기의 시작에 실제적으로 가능한 한 정확하게 0xff, 0xff 및 30 바이트의 0x0 패턴을 송신한다. 클라이언트가 이 시퀀스를 송신하기 시작하는 실제 시간은, 호스트의 관점에서는 측정 주기의 시작으로부터 지연된다. 이 지연의 양은 실질적으로, 패킷이 라인 드라이버와 수신기 및 상호 접속된 하위 시스템 (케이블, 콘덕터) 을 통해 전파되는데 걸리는 시간이다. 클라이언트로부터 호스트로 다시 전파되는 패턴에 대해 유사한 양의 지연 (3504) 이 발생한다.
클라이언트로/로부터 가로지르는 신호에 대한 라운드 트립 지연 시간을 정확하게 결정하기 위하여, 호스트는, 측정 주기의 시작 후 0xff, 0xff 및 30 바이트의 0x0 시퀀스의 시작이 도착 시에 검출될 때까지 일어나는 순방향 링크 비트 시간 주기를 카운팅한다. 이 정보는 라운드 트립 신호가 호스트로부터 클라이언트로 전송되고 다시 돌아오는 시간 양을 결정하는데 이용된다. 타입 2 내지 4 의 역방향 링크 또는 모드가 사용되고 있을때, 데이터 레이트 및 라운드 트립 지연 스큐가 각각의 비트의 도달 시간을 상이하게 할 정도로 충분히 크면, 호스트는 모든 MDDI_Data 쌍의 라운드 트립 지연 값을 측정하고 저장한다.
호스트 및 클라이언트 모두는 MDDI_Data 라인을 정의된 상태로 유지하기 위해 2 가드 시간 모두 동안 라인을 로직 0 레벨로 구동한다. 2 가드 시간 모두 동안 호스트 및 클라이언트의 인에이블 및 디스에이블 시간은, MDDI_Data 신호가 임의의 유효한 라운드 트립 지연 시간에 대해 유효한 로우 레벨에 있도록 한다.
호스트 및 클라이언트 양자는 MDDI_DATA 라인을 규정된 상태로 유지시키기 위한 모든 보호 시간 동안 라인을 로직 0 레벨로 유도한다. 보호 시간 동안의 호스트 및 클라이언트의 인에이블 및 디스에이블 시간은 MDDI_Data 신호가 임의의 유효 라운드 트립 지연 시간 동안 유효하도록 하는 시간이다.
25. 순방향 링크 스큐 교정 패킷
일 실시형태에서, 순방향 링크 스큐 교정 패킷은, 클라이언트 또는 디스플레이가 MDDI_Stb 신호에 대한 MDDI_Data 신호의 전송 지연의 차이에 대하여 스스로를 교정할 수 있도록 한다. 지연 스큐 보상이 없으면, 일반적으로 최대 데이터 레이트는 이들 지연의 잠재적인 최악의 경우의 변화를 고려하여 제한된다. 통상적으로, 이 패킷은 순방향 링크 데이터 레이트가 대략 50 Mbps 또는 그 이하의 레이트로 구성되는 경우에만 송신되도록 권장된다. 디스플레이를 교정하기 위해 이 패킷을 송신한 이후, 데이터 레이트는 50Mbps 보다 높게 증가될 수 있다. 데이터 레이트가 스큐 교정 프로세스 동안 너무 높게 설정되는 경우, 클라이언트는 비트 주기의 에일리어스 (alias) 에 동기화할 수 있으며 이는 지연 스큐 보상 설정이 하나 이상의 비트 시간 만큼 오프 (off) 되어 오류 있는 데이터 클록을 초래할 수 있다. 인터페이스의 가장 높은 데이터 레이트 타입 또는 가능한 가장 좋은 인터페이스 타입은, 모든 기존 데이터 비트가 교정되도록 순방향 링크 스큐 교정 패킷을 송신하기 이전에 선택된다. 클라이언트는 클라이언트 능력 패킷의 클라이언트 특성 능력 지시자 필드의 비트 19 를 사용하여 순방향 링크 스큐 교정 패킷을 지원할 능력을 나타낸다.
스큐 교정을 수행하기 전에, 호스트는 클라이언트 능력 패킷의 사전 교정 데이터 레이트 능력 필드에 의해 특정된 레이트보다 고속으로 데이터를 전송하지 않는다. 그러나, 교정이 수행된 후, 호스트는 사후 교정 데이터 레이트 능력 필드에 의해 정의된 레이트까지 데이터를 전송할 수도 있다. 온도에서의 변화에 기인하는, 상이한 신호 쌍들간의 상대적인 지연의 변화를 정정하기 위해, 호스트는 일정한 간격에서 순방향 링크 스큐 교정 패킷을 전송하는 것이 권장된다.
순방향 링크 스큐 교정 패킷의 형식의 일 실시형태가 도 56 에 도시된다. 도 56 에 도시된 바와 같이, 이러한 타입의 패킷은, 패킷 길이 (2 바이트), 패킷 타입, h클라이언트 ID, 파라미터 CRC, 올 제로 1, 교정 데이터 시퀀스, 및 CRC 필드를 갖도록 구성된다. 이 타입의 패킷은 일반적으로 타입 필드에서 타입 83 패킷으로 식별된다.
가상 제어 패널
가장 제어 패널 (VCP) 의 이용은 호스트가 클라이언트에서 소정 사용자 제어를 설정할 수 있도록 한다. 이들 파라미터가 호스트에 의해 조정될 수 있게 함으로써, 사용자가 오디오 볼륨 또는 디스플레이 휘도와 같은 파라미터를 조정할 수 있게 하는 스크린이 클라이언트의 하나 이상의 마이크로프로세서가 아니라 호스트 소프트웨어에 의해 생성될 수 있기 때문에, 클라이언트의 사용자 인터페이스가 단순화될 수 있다. 호스트는 클라이언트의 파라미터 설정을 판독하고 각각의 제어를 위해 유효값의 범위를 결정할 수 있는 능력을 갖는다. 일반적으로 클라이언트는 호스트에게 어떤 파라미터가 조정될 수 있는지를 보고할 수 있는 능력을 갖는다.
일반적으로 특정된 제어 코드 (VCP 코드) 및 관련 데이터 값은, 클라이언트에서 제어 및 설정을 특정하는데 이용된다. 패킷 정의에서의 적절한 데이터 필드 정렬을 보존하고, 장래에 이 인터페이스 또는 추가 성능 강화에 대한 고유한 보조 값을 지원하기 위해 MDDI 설명서의 VCP 코드는 16 비트로 확장된다.
26. 요청 VCP 특성 패킷
요청 VCP 특성 패킷은, 호스트가 특정한 제어 파라미터 또는 모든 유효 제어 파라미터의 현재의 설정을 요청하는 수단, 메커니즘 또는 방법을 제공한다. 일반적으로, 클라이언트는 VCP 특성 응답 패킷 내의 적절한 정보로 VCP 패킷에 응답한다. 일 실시형태에서 클라이언트는, 클라이언트 능력 패킷의 클라이언트 특성 능력 표시자 필드의 비트 13 을 이용하여 요청 VCP 특성 패킷을 지원할 수 있는 능력을 나타낸다.
일 실시형태의 요청 VCP 특성 패킷의 형식이 도 69 에 도시된다. 도 69 에 도시된 바와 같이, 이 타입의 패킷은, 패킷 길이, 패킷 타입, h클라이언트 ID, 디스플레이 선택자, MCCS (Monitor Control Command Set) VCP 코드, 및 CRC 필드를 갖도록 구성된다. 일 실시형태에서 이 타입의 패킷은 2 바이트 타입 필드에 표시된 타입 128 로 일반적으로 식별된다. 패킷 길이 필드를 제외한 패킷의 바이트의 총 수를 특정하는 패킷 길이는 통상적으로 이 타입의 패킷에 대하여 8 바이트의 길이로 고정된다.
h클라이언트 ID 필드는 장래의 구현에서 클라이언트 ID 로서 사용하기 위해 보류되고, 통상적으로 0 으로 설정된다.
일 실시형태에서, VCP 특성 응답 패킷 내의 2 바이트 디스플레이 선택자 필드는 VCP 패킷을 인가할 디스플레이를 지정한다. 디스플레이 선택자 필드의 비트 0 은 VCP 패킷이 인가될 디스플레이를 선택한다. 비트 0 이 0 과 동일한 경우, VCP 패킷은 이하 비트 11 내지 8 에 의해 특정되는 교대 디스플레이에 인가된다. 한편, 비트 0 이 1, 즉 로직 1 과 동일하면, VCP 패킷은 주 디스플레이에 인가된다. 현재 디스플레이 선택자 필드의 비트 7 내지 1 은 장래의 사용을 위해 보류되어 있고, 일반적으로 0 값과 동일하게 설정되고, 비트는 로직 0 레벨에 설정된다.
디스플레이 선택자 필드의 비트 11 내지 8 은 4 비트 무부호 정수 값을 사용하여 VCP 패킷이 인가될 교대 디스플레이를 특정한다. 디스플레이 선택자 필드의 비트 0 이 0 (로직 0 레벨) 과 동일한 경우, 클라이언트는 비트 11 내지 8 을 교대 디스플레이 수로 해석한다. 비트 0 이 0 과 동일하지 않으면, 비트 11 내지 8 은 0 으로 설정되고, 무시될 것이다. 비트 15 내지 12 는 장래의 사용을 위해 보류되고, 일반적으로 0 값으로 설정되며, 각 비트는 로직 0 레벨로 설정된다.
MCCS VCP 코드 필드는 MCCS VCP 제어 코드 파라미터를 특정하는 2 바이트의 정보를 포함한다. 0 내지 255 의 범위의 값이, VCP 특성 응답 패킷이 특정한 MCCS 코드에 대응하는 VCP 특성 응답 리스트 내의 단일 아이템으로 반환되게 한다. 65535 (0xffff) 의 MCCS VCP 코드는 클라이언트에 의해 지원되는 각각의 제어에 대한 특성 응답 리스트 아이템을 포함하는 VCP 특성 응답 리스트로 VCP 특성 응답 패킷을 요청한다. 이 필드를 위한 256 내지 65534 의 값은 장래의 사용을 위해 보류되고 현재 이용되지 않는다.
2 바이트 CRC 필드는 패킷 길이를 포함하는 패킷에서 모든 바이트의 CRC 를 포함한다.
27. VCP 특성 응답 패킷
VCP 특성 응답 패킷은, 클라이언트가 특정한 제어 파라미터 또는 모든 유효 제어 파라미터의 현재의 설정으로 호스트 요청에 응답하는 수단, 메커니즘, 또는 방법을 제공한다. 일반적으로, 클라이언트는 요청 VCP 특성 패킷에 응답하여VCP 특성 응답 패킷을 송신한다. 이 패킷은, 특정 파라미터의 현재 설정을 결정하거나, 특정 제어를 위한 유효 범위를 결정하거나, 특정 제어가 클라이언트에 의해 지원되는지 여부를 결정하거나, 또는 클라이언트에 의해 지원되는 제어의 셋을 결정하는데 유용하다. 클라이언트에서 구현되지 않는 특정한 제어를 참조하는 요청 VCP 특성이 송신되는 경우, VCP 특성 응답 패킷은 적절한 오류 코드를 포함하는 구현되지 않은 제어에 대응하는 단일 VCP 특성 응답 리스트 아이템으로 반환된다. 일 실시형태에서, 클라이언트는 클라이언트 능력 패킷의 클라이언트 특성 능력 필드의 비트 13 을 이용하여 VCP 특성 응답 패킷을 지원할 능력을 나타낸다.
일 실시형태의 VCP 특성 응답 패킷의 형식이 도 70 에 도시된다. 도 70 에 도시된 바와 같이, 이 타입의 패킷은, 패킷 길이, 패킷 타입, c클라이언트 ID, MCCS 버전, 응답 시퀀스 넘버, VCP 특성 응답 리스트, 및 CRC 필드를 갖도록 구성된다. 일 실시형태에서 이 타입의 패킷은 2 바이트 타입 필드에 나타내진 바와 같이 타입 129 로 일반적으로 식별된다.
c클라이언트 ID 필드는 클라이언트 ID 를 위해 보류된 정보를 포함한다. 이 필드는 장래의 사용을 위해 보류되고 일반적으로 0으로 설정된다.
일 실시형태에서, VCP 특성 응답 패킷 내의 2 바이트 디스플레이 선택자 필드는 VCP 패킷을 인가할 디스플레이를 지정한다. 디스플레이 선택자 필드의 비트 0 은 VCP 패킷이 인가될 디스플레이를 선택한다. 비트 0 이 0 과 동일한 경우, VCP 패킷은 이하 비트 11 내지 8 에 의해 특정되는 교대 디스플레이에 인가된다. 한편, 비트 0 이 1, 즉 로직 1 레벨과 동일하면, VCP 패킷은 주 디스플레이에 인가된다. 현재, 디스플레이 선택자 필드의 비트 7 내지 1 은 장래의 사용을 위해 보류되어 있고, 일반적으로 0 값과 동일하게 설정되며 그 비트들은 로직 0 레벨로 설정된다.
디스플레이 선택자 필드의 비트 11 내지 8 은 4 비트 무부호 정수 값을 사용하여 VCP 패킷이 인가될 교대 디스플레이를 특정한다. 디스플레이 선택자 필드의 비트 0 이 0 (로직 0 레벨) 과 동일한 경우, 클라이언트는 비트 11 내지 8 을 교대 디스플레이 수로 해석한다. 비트 0 이 0 과 동일하지 않으면, 비트 11 내지 8 은 0 으로 설정되고, 무시될 것이다. 비트 15 내지 12 는 장래의 사용을 위해 보류되고, 일반적으로 0 값으로 설정되며 각 비트는 로직 0 레벨로 설정된다.
MCCS 버전 필드는 클라이언트에 의해 구현되는 VESA MCCS 설명서의 버전을 특정하는 2 바이트의 정보를 포함한다.
VCP 특성 응답 패킷 내의 2 바이트 응답 시퀀스 넘버 필드는 클라이언트에 의해 반환되는 VCP 특성 응답 패킷의 시퀀스 넘버를 특정하는 정보 또는 데이터를 포함한다. 클라이언트는, 65535 의 MCCS 제어 코드 값을 갖는 요청 VCP 특성 패킷에 응답하여 하나 이상의 VCP 특성 응답 패킷을 반환한다. 클라이언트는 다수의 VCP 특성 응답 패킷에 걸쳐 특성 응답 리스트를 확산하거나 전송할 수 있다. 이 경우에, 클라이언트는 각각의 연속적인 패킷에 시퀀스 넘버 또는 식별자를 할당하고, 단일한 요청 VCP 특성 패킷에 응답하여 송신된 VCP 특성 응답 패킷의 시퀀스 넘버는 0 에서 시작하여 1 씩 증가한다. 마지막 VCP 특성 응답 패킷의 마지막 VCP 특성 리스트 아이템은, 패킷이 마지막 것이고 반환된 패킷의 그룹의 가장 높은 시퀀스 넘버를 포함함을 식별하기 위해, 0xffff 와 동일한 MCCS VCP 제어 코드 값을 포함하여야 한다. 요청 VCP 특성 패킷에 응답하여 오직 하나의 VCP 특성 응답 패킷이 전송되는 경우에, 그 단일한 패킷의 응답 시퀀스 넘버는 일반적으로 0 으로 설정되고 VCP 특성 응답 리스트는 0xffff 과 동일한 VCP 특성 응답 리스트 아이템에서 MCCS VCP 코드를 갖는 VCP 특성 응답 리스트 아이템을 포함한다. VCP 특성 응답 리스트 아이템 패킷의 최대값 및 현재값 필드 (도 71) 는 MCCP VCP 제어 코드가 0xffff 와 동일한 경우 0 으로 설정된다.
리스트 필드내 특성의 수는, 이 패킷의 VCP 특성 응답 리스트에 있는 VCP 특성 응답 리스트 아이템의 수를 특정하는 2 바이트를 포함하는 반면, VCP 특성 응답 리스트 필드는 하나 이상의 VCP 특성 응답 리스트 아이템을 포함하는 일군의 바이트이다. 일 실시형태의 단일한 VCP 특성 응답 리스트 아이템의 형식이 도 71 에 도시된다.
도 71 에 도시된 바와 같이, 각각의 VCP 특성 응답 리스트 아이템은 길이에 있어 12 바이트이며, MCCS VCP 코드, 결과 코드, 최대값, 및 현재 값 필드를 포함한다. 2-바이트 MCCS VCP 코드 필드는 이 리스트 아이템과 연관된 MCCS VCP 제어 코드 파라미터를 특정하는 데이터 또는 정보를 포함한다. 본 실시형태에 대해서, VESA MCCS 설명서 버전 2 및 그 후의 것에 규정된 제어 코드값만이 유효한 것으로 고려된다. 2-바이트 결과 코드 필드는 특정된 MCCS VCP 제어에 관한 정보 요청에 관련된 오류 코드를 특정하는 정보를 포함한다. 이 필드의 '0' 값은 오류가 존재하지 않는다는 것을 의미하는 반면, '1' 의 값은 특정한 제어가 클라이언트에서 구현되지 않는다는 것을 의미한다. 2 내지 65535 의 이 필드에 대한 다른 값은 장래의 사용 및 기술 분야에서 고려되는 다른 애플리케이션의 구현을 위해 현재 보류되고, 현재는 이용되지 않는다.
4-바이트의 최대 값 필드는, 특정한 MCCS 제어가 설정될 수 있는 가능한 가장 큰 값을 특정한다. 요청된 제어가 클라이언트에서 구현되지 않는 경우, 이 값은 0 으로 설정된다. 반환된 값이 길이에 있어서 32 비트 (4 바이트) 보다 작은 경우, 그 값은 최상위 (이용되지 않는) 바이트를 0 으로 남겨둔 32-비트 정수로 캐스팅된다. 4-바이트 현재 값 필드는, 특정한 MCCS VCP 연속 (C) 또는 불연속 (NC) 제어의 현재 값을 특정하는 정보를 포함한다. 요청된 제어가 클라이언트에서 구현되지 않거나 제어가 구현되지만 표 (T) 데이터 타입인 경우, 이 값은 0 으로 설정된다. 반환된 값이 VESA MCCS 규정당 길이에 있어서 32 비트 (4 바이트) 보다 작은 경우, 그 값은 최상위 (이용되지 않는) 바이트를 0 으로 남겨둔 32-비트 정수로 캐스팅된다. 특정 MCCS VCP 코드가 불연속적인 제어 또는 표 데이터 타입에 대응하면, 최대 값 필드는 0 으로 설정되거나 선택된다.
28. 설정 VCP 특성 패킷
설정 VCP 특성 패킷은, 호스트가 클라이언트의 연속적 및 불연속적 제어 모두에 대해 VCP 제어 값을 설정하는 수단, 메커니즘, 또는 방법을 제공한다. 일 실시형태에서, 클라이언트는, 클라이언트 능력 패킷의 클라이언트 특성 능력 필드의 비트 13 을 이용하여 설정 VCP 특성 패킷을 지원할 능력을 나타낸다.
일 실시형태의 설정 VCP 특성 패킷의 형식이 도 72 에 도시된다. 도 72 에 도시된 바와 같이, 이 타입의 패킷은, 패킷 길이, 패킷 타입, h클라이언트 ID, 디스플레이 선택자, MCCS VCP 코드, 리스트 내 값의 수 (Number of Values in the List), 제어 값 리스트, 및 CRC 필드를 갖도록 구성된다. 이 패킷의 타입은 2 바이트 타입 필드에 나타낸, 타입 130 으로 일반적으로 식별되며, 패킷 길이 필드를 제외하고 20 바이트 길이이다.
역시, h클라이언트 ID 필드는 클라이언트 ID 를 특정하거나 클라이언트 ID 로서 동작하기 위해 2-바이트 값을 이용한다. 이 필드는 장래의 사용을 위해 보류되고 현재 0 으로 설정된다.
일 실시형태에서, VCP 특성 응답 패킷 내의 2 바이트 디스플레이 선택자 필드는 VCP 패킷을 인가할 디스플레이를 지정한다. 디스플레이 선택자 필드의 비트 0 은 VCP 패킷이 인가될 디스플레이를 선택한다. 비트 0 이 0 과 동일한 경우, VCP 패킷은 이하 비트 11 내지 8 에 의해 특정되는 교대 디스플레이에 인가된다. 한편, 비트 0 이 1, 즉 로직 1 레벨과 동일하면, VCP 패킷은 주 디스플레이에 인가된다. 현재, 디스플레이 선택자 필드의 비트 7 내지 1 은 장래의 사용을 위해 보류되어 있고, 일반적으로 0 값과 동일하게 설정되며 그 비트들은 로직 0 레벨로 설정된다.
디스플레이 선택자 필드의 비트 11 내지 8 은 VCP 패킷이 인가될 교대 디스플레이를 특정한다. 디스플레이 선택자 필드의 비트 0 이 0 (로직 0 레벨) 과 동일한 경우, 클라이언트는 비트 11 내지 8 을 교대 디스플레이 수로 해석한다. 비트 0 이 0 과 동일하지 않으면, 비트 11 내지 8 은 0 으로 설정되고, 무시될 것이다. 비트 15 내지 12 는 장래의 사용을 위해 보류되고, 일반적으로 0 값으로 설정되며 각 비트는 로직 0 레벨로 설정된다.
설정 VCP 특성 패킷에 대한 MCCS VCP 코드 필드는 조정될 MCCS VCP 제어 코드 파라미터를 특정하기 위해 2 바이트의 정보 또는 값을 이용한다. 2-바이트의 리스트 필드 내 값의 수는 제어 값 리스트에 존재하는 16-비트 값의 개수를 특정하는 정보 또는 값을 포함한다. MCCS 제어 코드가 클라이언트 내 표와 관련되지 않은 경우, 제어 값 리스트는 보통 하나의 아이템을 포함한다. 표와 무관한 (non-table-related) 제어의 경우에, 제어 값 리스트는, MCCS VCP 코드 필드에 의해 특정된 제어 파라미터에 기록할 새로운 값을 특정하는 값을 포함할 것이다. 표와 관련된 (table-related) 제어에 있어서, 제어 값 리스트에서의 데이터의 형식은 특정된 MCCS VCP 코드의 파라미터 설명에 의해 특정된다. 리스트가 하나의 바이트보다 큰 값을 포함하는 경우, 다른 곳에서 정의된 방법에 따라, 최하위 바이트가 먼저 송신된다. 마지막으로, 2 바이트 CRC 필드는 패킷 길이를 포함하는 패킷의 모든 바이트의 16 비트 CRC 를 포함한다.
29. 요청 유효 파라미터 패킷
요청 유효 파라미터 패킷은, 특정한 NC 거나 표 (T) 제어에 의해 지원되는 파라미터의 리스트를 포함하는 유효 파라미터 응답 패킷을 클라이언트가 반환하도록 요구하기 위한 유용한 수단 또는 구성으로서 이용된다. 이 패킷은 불연속 제어 또는 클라이언트 내 표에 관련된 제어만을 특정하여야 하고, 모든 제어를 특정하기 위한 65535 (0xffff) 의 MCCS VCP 코드 값을 특정해서는 안된다. 지원되지 않거나 유효하지 않은 MCCS VCP 코드가 특정되는 경우, 유효한 파라미터 응답 패킷에서 적절한 오류 값이 반환된다. 일 실시형태에서, 클라이언트는 디스플레이 능력 패킷의 클라이언트 특성 능력 필드의 비트 13 을 이용하여 요청 유효 파라미터 패킷을 지원하는 능력을 나타낸다.
일 실시형태에서의 요청 유효 파라미터 패킷의 형식이 도 73 에 도시된다. 도 73 에 도시된 바와 같이, 이 타입의 패킷은, 패킷 길이, 패킷 타입, h클라이언트 ID, 디스플레이 선택자, MCCS VCP 코드, 및 CRC 필드를 갖도록 구성된다. 일반적으로 이 타입의 패킷은, 일 실시형태에서 2 바이트 타입 필드에 표시된 타입 131 로 식별된다.
2-바이트 패킷 길이 필드에 나타내진 패킷 길이는, 일반적으로 8 의 패킷 길이 필드를 제외한 패킷 내 바이트의 총 수를 갖도록 설정된다. 역시, h클라이언트 ID 는 클라이언트 ID 를 특정하지만, 당업자에게 알려진 바와 같이, 현재는 장래의 사용을 위해 보류되고, 0 값 또는 로직 0 레벨로 설정된다.
일 실시형태에서, 요청 유효 파라미터 패킷 내의 2 바이트 디스플레이 선택자 필드는 VCP 패킷을 인가할 디스플레이를 지정한다. 디스플레이 선택자 필드의 비트 0 은 VCP 패킷이 인가될 디스플레이를 선택한다. 비트 0 이 0 과 동일한 경우, VCP 패킷은 이하 비트 11 내지 8 에 의해 특정되는 교대 디스플레이에 인가된다. 한편, 비트 0 이 1, 즉 로직 1 레벨과 동일하면, VCP 패킷은 주 디스플레이에 인가된다. 현재, 디스플레이 선택자 필드의 비트 7 내지 1 은 장래의 사용을 위해 보류되어 있고, 일반적으로 0 값과 동일하게 설정되며 그 비트들은 로직 0 레벨로 설정된다.
디스플레이 선택자 필드의 비트 11 내지 8 은 VCP 패킷이 인가될 교대 디스플레이를 특정한다. 디스플레이 선택자 필드의 비트 0 이 0 (로직 0 레벨) 과 동일한 경우, 클라이언트는 비트 11 내지 8 을 교대 디스플레이 수로 해석한다. 비트 0 이 0 과 동일하지 않으면, 비트 11 내지 8 은 0 으로 설정되고, 무시될 것이다. 비트 15 내지 12 는 장래의 사용을 위해 보류되고, 일반적으로 0 값으로 설정되며 각 비트는 로직 0 레벨로 설정된다.
2-바이트 MCCS VCP 코드 필드는 질의될 불연속 MCCS VCP 제어 코드 파라미터를 특정하는 값을 포함한다. 이 필드의 값은 클라이언트에서 구현되는 불연속 제어에 대응한다. 통상 값 256 내지 65535 (0xffff) 는 보류되거나 비유효한 것으로서 간주되고, 오류 응답에 있어서 비구현된 제어로서 생각된다. 여기서는 2 바이트인 CRC 필드는 패킷 길이를 포함하는 패킷에서 모든 바이트의 CRC 를 포함한다.
30. 유효 파라미터 응답 패킷
유효 파라미터 응답 패킷은 요청 유효 파라미터 패킷에 응답하여 송신된다. 표의 컨텐츠를 반환하는 제어 또는 불연속 MCCS VCP 제어에 대한 유효 설정을 식별하는 수단, 방법, 또는 구성으로서 이용된다. 제어가 클라이언트 내의 표에 관련된다면, VCP 파라미터 응답 리스트는 단순히 요청되는 순차적인 표 값의 특정 리스트를 포함한다. 표의 컨텐츠가 단일 유효 파라미터 응답 패킷에 맞을 수 없는 경우, 순차적인 응답 시퀀스 넘버를 갖는 다수의 패킷이 클라이언트에 의해 송신될 수 있다. 일 실시형태에서, 클라이언트는 클라이언트 능력 패킷의 클라이언트 특성 능력 필드의 비트 13 을 이용하여 유효 파라미터 응답 패킷을 지원하는 능력을 나타낸다.
호스트는 다음으로 표의 컨텐츠를 요청할 수 있다: 판독/기록 파라미터, LUT (Look-Up Table) 오프셋, 및 RGB 선택과 같은 필요한 또는 희망하는 파라미터를 포함하는 설정 VCP 특성 패킷을 호스트가 전송한다; 그 후, 희망 제어를 특정하는 요청 유효 파라미터 패킷이 호스트에 의해 송신된다; 그 후, 클라이언트가 표 데이터를 포함하는 하나 이상의 유효 파라미터 응답 패킷을 반환한다. 이런 동작 시퀀스는 MCCS 동작 모델에 기술된 표 판독 기능과 유사한 기능을 수행한다.
특정 클라이언트 파라미터가 클라이언트에 의해 지원되지 않는 경우, 일 실시형태에서, 이 패킷의 대응 필드는 255 의 값을 포함한다. 클라이언트에서 이용되는 파라미터에 대하여, 대응 필드는 클라이언트에서의 파라미터의 값을 포함하여야 한다.
일 실시형태를 위한 유효 파라미터 응답 패킷의 형식이 도 74 에 도시된다. 도 74 에 도시된 바와 같이, 이 타입의 패킷은, 패킷 길이, 패킷 타입, c클라이언트 ID, 디스플레이 선택자, MCCS VCP 코드, 응답 코드, 응답 시퀀스 넘버, 리스트에서의 넘버 값, VCP 파라미터 응답 리스트, 및 CRC 필드를 갖도록 구성된다. 일 실시형태에 대해 이 타입의 패킷은 2 바이트 타입 필드에 표시된, 타입 132 로 일반적으로 식별된다.
c클라이언트 ID 필드는 전술한 바와 같이 장래 클라이언트 ID 를 위해 보류되어 있다.
일 실시형태에서, 2 바이트 디스플레이 선택자 필드는 VCP 패킷을 인가할 디스플레이를 지정한다. 디스플레이 선택자 필드의 비트 0 은 VCP 패킷이 인가될 디스플레이를 선택한다. 비트 0 이 0 과 동일한 경우, VCP 패킷은 이하 비트 11 내지 8 에 의해 특정되는 교대 디스플레이에 인가된다. 한편, 비트 0 이 1, 즉 로직 1 레벨과 동일하면, VCP 패킷은 주 디스플레이에 인가된다. 현재, 디스플레이 선택자 필드의 비트 7 내지 1 은 장래의 사용을 위해 보류되어 있고, 일반적으로 0 값과 동일하게 설정되거나 그 비트들은 로직 0 레벨로 설정된다.
디스플레이 선택자 필드의 비트 11 내지 8 은 VCP 패킷이 인가될 교대 디스플레이를 특정한다. 비트 0 이 0 (로직 0 레벨) 과 동일한 경우, 클라이언트는 비트 11 내지 8 을 교대 디스플레이 수로 해석한다. 비트 0 이 0 과 동일하지 않으면, 비트 11 내지 8 은 0 으로 설정되고, 무시될 것이다. 비트 15 내지 12 는 장래의 사용을 위해 보류되고, 일반적으로 0 값으로 설정되며 각 비트는 로직 0 레벨로 설정된다.
일 실시형태에서, 3-바이트 MCCS VCP 코드 패킷은 이 패킷에 의해 기술되는 불연속 MCCS VCP 제어 코드 파라미터를 특정하는 값을 포함한다. 유효하지 않은 MCCS VCP 제어 코드가 요청 유효 파라미터 패킷에 의해 특정되는 경우, 동일한 유효하지 않은 파라미터 값이 응답 코드 필드 내의 적절한 값으로 이 필드 내에 특정될 것이다. MCCS 제어 코드가 유효하지 않은 경우, VCP 파라미터 응답 리스트는 0 길이를 갖는다.
응답 코드 필드는 특정된 MCCS VCP 제어에 관한 정보에 대한 요청에 관련된 응답의 성질 (nature) 을 특정하는 2 바이트의 값 또는 정보를 포함한다. 이 필드의 값이 0 인 경우, 이 데이터 타입에 대해 오류가 존재하지 않는 것으로 간주되고, 가장 높은 응답 시퀀스 넘버를 갖는 시퀀스 내의 마지막 유효 파라미터 응답 패킷이 전송된다. 이 필드의 값이 1 인 경우, 오류가 존재하지 않는 것으로 간주되나, 가장 높은 시퀀스 넘버를 갖는 다른 유효 파라미터 응답 패킷이 송신된다. 이 필드의 값이 2 인 경우, 특정된 제어는 클라이언트에서 구현되지 않는 것으로 간주된다. 이 필드의 값이 3 인 경우, 특정된 제어는 불연속 제어가 아니다 (항상 0 내지 최대값의 모든 값의 유효 셋을 갖는 연속적인 제어이다). 이 필드에 대한 4 내지 65535 의 값은 장래의 사용을 위해 보류되고, 일반적으로 이용되지 않는다.
2-바이트 응답 시퀀스 넘버 필드는 클라이언트에 의해 반환되는 유효 파라미터 응답 패킷의 시퀀스 넘버를 특정한다. 클라이언트는 요청 유효 파라미터 패킷에 응답하여 하나 이상의 유효 파라미터 응답 패킷을 반환한다. 클라이언트는 다수의 유효 파라미터 응답 패킷에 걸쳐 VCP 파라미터 응답 리스트를 확산할 수 있다. 이 후자의 경우에, 클라이언트는 각각의 연속적인 패킷에 시퀀스 넘버를 할당하고, 시퀀스의 마지막 패킷을 제외한 모든 패킷에서 응답 코드를 1 로 설정할 것이다. 시퀀스의 마지막 유효 파라미터 응답 패킷은 가장 높은 응답 시퀀스 넘버를 갖고 응답 코드는 0 의 값을 포함하게 된다.
2-바이트 리스트 내 값의 수 (Number of Value in the List) 필드는 VCP 파라미터 응답 리스트에 존재하는 16-비트 값의 수를 특정한다. 응답 코드가 0 이 아닌 경우, 리스트 내 값의 수 파라미터는 0 이다. VCP 파라미터 응답 리스트 필드는, MCCS 제어 코드 필드에 의해 특정되는 불연속 제어를 위한 유효 값의 셋을 나타내는 0 내지 32760 2-바이트 값의 리스트를 포함한다. 불연속 제어 코드의 정의는 VESA MCCS 설명서에 특정된다. 마지막으로, 이 실시형태에서, CRC 필드는 패킷 길이를 포함하는 패킷 내 모든 바이트의 16 비트 CRC 를 포함한다.
스케일링된 비디오 스트림 이미지
MDDI 또는 프로토콜 메커니즘, 구조, 수단 또는 방법은 호스트가 원 이미집다 크게 또는 작게 스케일링된 이미지를 클라이언트에게 보낼 수 있도록 하는 스케일링된 비디오 스트림 이미지에 대한 지원을 제공하고, 스케일링된 이미지는 메인 이미지 버퍼에 복사된다. 스케일링된 비디오 스트림 기능 및 관련 프로토콜 지원에 대한 개요는 다른 곳에서 제공된다. 스케일링된 비디오 스트림을 지원할 수 있는 능력은 특정 상태 패킷 요청에 응답하여 전송되는 스케일링된 비디오 스트림 능력 패킷 내에서 또는 그에 의해서 정의된다.
이하 설명하는 스케일링된 비디오 스트림 패킷의 헤더는, 이미지를 디스플레이하는데 필요한 전체 콘텍스트를 그 헤더가 포함하는 단순한 비디오 스트림 패킷과는 약간 다르다. 스케일링된 비디오 스트림 패킷은 설정 패킷을 사용하여 소스 및 목적 윈도우 크기 및 위치의 파라미터를 정의하고, 픽셀 데이터를 송신하기 위한 개별적으로 스케일링된 비디오 스트림 패킷을 정의한다. 클라이언트는 각 스트림에 관련된 내부 저장소를 할당하여 설정 패킷으로부터의 스트림 파라미터 및 각 스트림에 관련된 픽셀 데이터의 일부를 저장한다. 각 스트림에 요구되는 저장량은 소스 및 목적 이미지의 크기, 및 설정 패킷에 특정된 값에 따라 상이할 것이다. 이러한 이유 때문에, 프로토콜은, 클라이언트가 각 스케일링된 비디오 스트림과 관련된 저장소의 할당을 위한 동적 메모리 할당을 구현하도록 설계된다.
프로그램 소스에 고유한 크기를 갖는 디스플레이에 비디오 스트림을 전송하고, 디스플레이가, 특정한 목적 애플리케이션에 적절한 방식으로 이미지를 스케일링하고 위치시키는 것이 유용하다. 다수의 비디오 이미지의 실시간 스케일링을 위한 구현은 충분히 복잡하여, 이 특성의 지원은 클라이언트에서 선택적이다.
31. 스케일링된 비디오 스트림 능력 패킷
스케일링된 비디오 스트림 능력 패킷은 클라이언트에서의 또는 클라이언트에 의해 이용되는 스케일링된 비디오 스트림 소스 이미지의 특성을 정의한다. 스케일링된 비디오 스트림 능력 패킷의 형식이 일반적으로 도 75 에 도시된다. 도 75 에 도시된 바와 같이, 일 실시형태에서, 스케일링된 비디오 스트림 능력 패킷은 패킷 길이, 패킷 타입, c클라이언트 ID, 최대 스트림 수 (Max Number of Streams), 소스 최대 X 사이즈, 소스 최대 Y 사이즈, RGB 능력, 흑백 능력, 보류 1, Y Cr Cb 능력, 보류 2, 및 CRC 필드를 갖도록 구성된다. 일 실시형태에서, 패킷 길이는, 길이 필드에 도시된 바와 같이, 클라이언트 ID 를 위해 보류되거나 그렇지 않으면 영으로 설정된 c클라이언트 ID 필드 및 CRC 필드를 포함하여 고정된 20 바이트가 되도록 선택된다. 일 실시형태에서, 클라이언트는 유효 상태 응답 리스트 패킷의 유효 파라미터 응답 리스트 내의 143 의 파라미터 값을 이용하여, 스케일링된 비디오 스트림 능력 패킷을 지원할 수 있는 능력을 나타낸다.
2-바이트 최대 스트림 수 필드는 한번에 할당될 수 있는 동시적인 스케일링된 비디오 스트림의 최대 개수를 식별하기 위한 값을 포함한다. 일 실시형태에서, 클라이언트는, 최대 개수의 스케일링된 비디오 스트림이 이미 할당되었다면, 스케일링된 비디오 스트림 할당 요청을 부인하여야 한다. 최대 개수보다 적은 스케일링된 비디오 스트림이 할당된 경우, 클라이언트는 클라이언트에서의 다른 리소스 제한에 기초하여 할당 요청을 부인할 수도 있다.
소스 최대 X 사이즈 및 Y 사이즈 필드 (2 바이트) 는 픽셀의 개수로서 표현되는 스케일링된 비디오 스트림 소스 이미지의 최대 폭 및 높이를 위한 값을 각각 특정한다.
RGB 능력 필드는 RGB 형식으로 디스플레이될 수 있는 해상도의 비트 수를 특정하기 위해 값을 이용한다. 스케일링된 비디오 스트림이 RGB 형식을 이용할 수 없으면, 이 값은 0 으로 설정된다. RGB 능력 워드는 3 개의 별개의 무부호 값: 각각의 픽셀 내 청색 비트의 최대 개수 (청색 강도) 를 정의하는 비트 3 내지 0, 각각의 픽셀 내 녹색 비트의 최대 개수 (녹색 강도) 를 정의하는 비트 7 내지 4, 각각의 픽셀 내 적색 비트의 최대 개수 (적색 강도) 를 정의하는 비트 11 내지 8 으로 구성되는 반면, 비트 15 내지 12 는 장래의 능력 정의에서의 장래의 사용을 위해 보류되고, 일반적으로 0 으로 설정된다.
1-바이트 흑백 능력 필드는 흑백 형식으로 디스플레이될 수 있는 해상도의 비트 수를 특정하는 값을 포함한다. 스케일링된 비디오 스트림이 흑백 형식을 이용할 수 없으면, 이 값은 0 으로 설정된다. 비트 7 내지 4 는 장래의 사용을 위해 보류되며, 그러므로, 당업자에게 이해되는 바와 같이 시간에 따라 변화될 수도 있으나, 현재 애플리케이션에 대해서는 영 ('0') 으로 설정되어야 한다. 비트 3 내지 0 은 각각의 픽셀에 존재할 수 있는 그레이스케일 비트의 최대 개수를 정의한다. 이러한 4 개의 비트는 각각의 픽셀이 1 내지 15 비트로 구성되도록 특정하는 것을 가능하게 한다. 값이 0 이면, 흑백 형식은 스케일링된 비디오 스트림에 의해 지원되지 않는다.
보류 1 필드 (여기에서 1 바이트) 는 스케일링된 비디오 스트림 패킷 정보 또는 데이터에 관련된 값을 제공하는데 있어서의 장래의 사용을 위해 보류된다. 그러므로, 현재, 이 필드에 있는 모든 비트가 로직 '0' 으로 설정된다. 이 필드의 일 목적은 모든 후속 2-바이트 필드로 하여금 16-비트 워드 어드레스에 정렬되게 하고 4-바이트 필드로 하여금 32-비트 워드 어드레스에 정렬하도록 하는 것이다.
2-바이트 Y Cb Cr 능력 필드는 Y Cb Cr 형식으로 디스플레이될 수 있는 해상도의 비트 수를 특정하는 값을 포함한다. 스케일링된 비디오 스트림이 Y Cb Cr 형식을 이용할 수 없으면, 이 값은 0 이다. Y Cb Cr 능력 워드는 3 개의 별개의 무부호 값: Cr 샘플을 특정하는 비트의 최대 개수를 정의하는 비트 3 내지 0; Cb 샘플을 특정하는 비트의 최대 개수를 정의하는 비트 7 내지 4; Y 샘플을 특정하는 비트의 최대 개수를 정의하는 비트 11 내지 8 로 구성되고, 비트 15 내지 12 는 장래의 사용을 위해 보류되고 일반적으로 0 으로 설정된다.
1-바이트 능력 비트 필드는 스케일링된 비디오 스트림과 관련된 능력을 특정하는 플래그 세트를 포함한다. 플래그는 다음과 같이 정의된다: 비트 0 은 패킷화 형식으로 존재할 수 있는 스케일링된 비디오 스트림 패킷의 픽셀 데이터를 커버한다. 패킷화되고 바이트-정렬된 픽셀 데이터의 예를 이전의 도 13 에 도시한다. 비트 1 은 장래의 사용을 위해 보류되고 일반적으로 0 으로 설정된다; 비트 2 도 장래의 사용을 위해 보류되고 0 으로 설정된다; 비트 3 은 컬러 맵 데이터 형식으로 특정될 수 있는 스케일링된 비디오 스트림을 커버한다. 메인 이미지 버퍼 및 알파-커서 이미지 평면에 대해 이용된 것과 동일한 컬러 맵 표가 스케일링된 비디오 스트림에 대해 이용된다. 컬러 맵은 다른 곳에서 설명된 컬러 맵 패킷을 이용하여 구성된다; 그리고 비트 7 내지 4 는 장래 사용을 위해 보류되고 일반적으로 0 으로 설정된다.
보류 2 필드 (여기에서 1 바이트) 는 스케일링된 비디오 스트림 패킷 정보 또는 데이터에 관련된 값을 제공하는데 있어서의 장래의 사용을 위해 보류된다. 그러므로, 현재, 이 필드에 있는 모든 비트는 로직 '0' 으로 설정된다. 이 필드의 일 목적은 모든 후속 2-바이트 필드로 하여금 16-비트 워드 어드레스에 정렬되도록 하고 4-바이트 필드로 하여금 32-비트 워드 어드레스에 정렬되도록 하는 것이다.
32. 스케일링된 비디오 스트림 설정 패킷
스케일링된 비디오 스트림 설정 패킷은 스케일링된 비디오 스트림의 파라미터를 정의하는데 사용되는 수단, 구조 또는 방법을 제공하며, 클라이언트는 이미지의 버퍼링 및 스케일링을 위한 내부 저장소를 할당하기 위해 이 정보를 사용한다. 스트림은, X 이미지 사이즈 및 Y 이미지 사이즈 필드를 0 으로 하여 이 패킷을 송신함으로써 할당 해제 (de-allocated) 될 수도 있다. 할당 해제된 스케일링된 비디오 스트림은 동일 또는 상이한 스트림 파라미터로 이후에 재할당될 수도 있다. 일 실시형태에서, 클라이언트는, 유효 상태 응답 리스트 패킷의 유효 파라미터 응답 리스트 내의 143 의 파라미터 값을 이용하여, 그리고 스케일링된 비디오 스트림 능력 패킷의 스트림 최대 수 (Maximum Number of Streams) 필드의 0 이 아닌 값을 이용함으로써, 스케일링된 비디오 스트림 설정 패킷을 지원할 수 있는 능력을 나타낸다.
스케일링된 비디오 스트림 설정 패킷의 형식은 일반적으로 도 76 에 도시된다. 도 76 에서 볼 수 있는 바와 같이, 일 실시형태에서 스케일링된 비디오 스트림 설정 패킷은 패킷 길이, 패킷 타입, h클라이언트, 스트림 ID, 비디오 데이터 형식 디스크립터, 픽셀 데이터 속성, X 좌측 에지, Y 상부 에지, X 우측 에지, Y 하부 에지, X 이미지 사이즈, Y 이미지 사이즈 및 CRC 필드를 갖도록 구성된다.
2-바이트 패킷 길이 필드는 패킷 길이 필드를 제외한 패킷 내 총 바이트 수를 정의한다. 일 실시형태에서, 이러한 패킷 길이는 24 로 고정된다. 2-바이트 패킷 타입 필드는 패킷을 스케일링된 비디오 스트림 설정 패킷으로 식별하기 위해 값 136 을 사용한다. 알려진 바와 같이, 2-바이트 h클라이언트 ID 필드는 클라이언트 ID 로서 장래에 사용하기 위해 보류되고, 일시적으로 또는 프로토콜 사용자가 어떤 ID 값이 사용될지를 결정하기까지, 일반적으로 모든 비트가 로직 0 값으로 설정된다.
스트림 ID 필드는 스트림 ID 를 위한 고유 식별자를 특정하는데 2 바이트를 사용한다. 이 값은 호스트에 의해 할당되며, 클라이언트 능력 패킷에서 특정되는 0 으로부터 최대 스트림 ID 값까지의 범위 내에 존재해야 한다. 호스트는 각각의 활성 스트림이 고유의 값을 할당받고 더 이상 활성이 아닌 스트림은 할당 해제 되거나 재할당되는 것을 보장하도록, 스트림 ID 값의 사용을 주의 깊게 관리하여야 한다.
일 실시형태에서, 비디오 데이터 형식 디스크립터 필드는, 현재 패킷의 현재 스트림의 픽셀 데이터 내의 각각의 픽셀의 형식을 특정하는데 2 바이트를 사용한다. 픽셀 데이터 형식은 알파-커서 이미지 능력 패킷에서 정의될 수도 있는 알파-커서 이미지 평면을 위한 유효 형식 중에서 적어도 하나 또는 일반적으로 전술한 다른 패킷 내에서 정의되는 다른 소정의 이미지 패턴에 부합하여야 한다. 비디오 데이터 형식 디스크립터는 현재의 패킷에 대한 픽셀 형식만을 정의하며, 특정 비디오 스트림의 존속 기간 동안 계속하여 동일한 형식이 이용될 것임을 의미하지는 않는다. 도 11 은 비디오 데이터 형식 디스크립터가 어떻게 코딩되는지에 대한 일 실시형태를 나타내며, 다른 패킷에 대해 전술한 바와 같다.
예를 들어, 도 12a 내지 12d 에 도시된 바와 같이, 일 실시형태에서 사용되는 경우, 비트 [15:13] 이 '000' 과 동일하면, 비디오 데이터는, 픽셀당 비트의 수가 비디오 데이터 형식 디스크립터 워드의 비트 3 내지 0 에 의해 규정되는 단색 픽셀의 어레이로 구성된다. 비트 11 내지 4 는 일반적으로 장래의 사용 또는 애플리케이션을 위해 보류되고 이 상황에서는 0 으로 설정된다. 대신에, 비트 [15:13] 이 값 '001' 과 동일한 경우, 비디오 데이터는, 각각 컬러 맵 (팔레트) 을 통해 컬러를 특정하는 컬러 픽셀의 어레이로 구성된다. 이러한 경우, 비디오 데이터 형식 디스크립터 워드의 비트 5 내지 0 은 픽셀당 비트의 수를 규정하고, 비트 11 내지 6 은 일반적으로 장래의 사용 또는 애플리케이션을 위해 보류되며 0 과 동일하게 설정된다. 대신에, 비트 [15:13] 이 값 '010' 과 동일한 경우, 비디오 데이터는, 적색의 픽셀당 비트의 수가 비트 11 내지 8 에 의해 규정되고 녹색의 픽셀당 비트의 수가 비트 7 내지 4 에 의해 규정되고 청색의 픽셀당 비트의 수가 비트 3 내지 0 에 의해 규정되는 컬러 픽셀의 어레이로 구성된다. 이러한 상황에서, 각 픽셀에서의 비트의 총 수는 적색, 녹색 및 청색에 사용되는 비트의 수의 합이다.
그러나, 도 12d 에 도시된 바와 같이, 비트 [15:13] 이 값 또는 스트링 '011' 과 동일한 경우, 비디오 데이터는, 휘도 및 색차 정보를 갖는 4:2:2 YCbCr 형식의 비디오 데이터 어레이로 구성되며, 여기서 휘도 (Y) 의 픽셀당 비트의 수는 비트 11 내지 8 에 의해 규정되고, Cb 성분의 비트의 수는 비트 7 내지 4 에 의해 규정되고, Cr 성분의 비트의 수는 비트 3 내지 0 에 의해 규정된다. 각 픽셀의 비트의 총 수는 적색, 녹색 및 청색에 사용되는 비트의 수의 합이다. Cb 및 Cr 성분은 Y 의 1/2 레이트로 전송된다. 또한, 이 패킷의 픽셀 데이터 부분에서의 비디오 샘플은 다음과 같이: Cbn, Yn, Crn, Yn+1, Cbn+2, Yn+2, Crn+2, Yn+3, ... 으로 구성되며, Cbn 및 Crn 은 Yn 및 Yn+1 과 결합되고, Cbn+2 및 Crn+2 는 Yn+2 및 Yn+3 과 결합된다. Yn, Yn+1, Yn+2 및 Yn+3 은 좌측으로부터 우측으로의 단일 행에서 4 개의 연속적 픽셀의 휘도 값이다.
모든 4 개의 형식에 대해 전술하였다. 도면에서 "P" 로 지정된 비트 12 는 픽셀 데이터 샘플이 패킹되었는지 여부 또는 바이트 정렬된 픽셀 데이터인지 여부를 특정한다. 이 필드에서 '0' 의 값은, 픽셀 데이터 필드의 각 픽셀이 MDDI 바이트 경계로 바이트 정렬된 것을 나타낸다. '1' 의 값은, 픽셀 데이터의 각 픽셀내 각각의 픽셀 및 각각의 컬러가, 미사용 비트가 없는 픽셀 내에서 이전의 픽셀 또는 컬러에 대해 패킹된 것을 나타낸다.
일 실시형태에서, 2 바이트 픽셀 데이터 속성 필드는 다음과 같이 해석되는 값을 가지며, 비트 1 및 0 은 장래의 사용을 위해 보류되어 현재는 일반적으로 로직 0 으로 설정되고, 비트 2 는 픽셀 데이터가 인터레이스 형식인지 여부를 나타낸다. 비트 2 가 0 인 경우, 픽셀 데이터는 표준 진행 형식이다. 행 번호 (픽셀 Y 좌표) 는 1 행으로부터 다음 행으로 진행할 때 1 씩 증가한다. 비트 2 가 1 인 경우, 픽셀 데이터는 인터레이스 형식이다. 행 번호 (픽셀 Y 좌표) 는 1 행으로부터 다음 행으로 진행할 때 2 씩 증가한다.
일 실시형태에서, 비트 3 은 픽셀 데이터가 교대 픽셀 형식인지 여부를 나타낸다. 이것은 비트 2 에 의해 인에이블된 표준 인터레이스 모드와 유사하지만, 인터레이스는 수평적이기 보단 수직적이다. 비트 3 이 0 인 경우, 픽셀 데이터는 표준 진행 형식으로 생성되거나 배치된다. 열 번호 (픽셀 X 좌표) 는 각각의 연속적 픽셀이 수신됨에 따라 1 씩 증가한다. 비트 3 이 1 인 경우, 픽셀 데이터는 교대 픽셀 형식으로 생성되거나 배치된다. 열 번호 (픽셀 X 좌표) 는 각 픽셀이 수신됨에 따라 2 씩 증가한다.
또한, 비트 4 내지 15 는 장래의 사용을 위해 보류되고, 현재의 애플리케이션 또는 설계에서는 일반적으로 로직 0 레벨 또는 값으로 설정된다.
33. 스케일링된 비디오 스트림 확인 응답 패킷
스케일링된 비디오 스트림 확인 응답 패킷은 클라이언트가 스케일링된 비디오 스트림 설정 패킷의 수신을 확인 응답하게 한다. 클라이언트는 유효 상태 응답 리스트 패킷의 유효 파라미터 응답 리스트 내의 143 의 파라미터 값을 통해, 그리고 스케일링된 비디오 스트림 능력 패킷의 최대 스트림 수 필드 내의 0 이 아닌 값을 통해 스케일링된 비디오 스트림 확인 응답 패킷을 지원할 수 있는 능력을 나타낼 수 있다.
스케일링된 비디오 스트림 확인 응답 패킷의 형식이 일반적으로 도 77 에 도시된다. 도 77 에 도시된 바와 같이, 일 실시형태에서 스케일링된 비디오 스트림 확인 응답 패킷은 패킷 길이, 패킷 타입, c클라이언트, 스트림ID, ACK 코드 및 CRC 필드를 갖도록 구성된다. 2-바이트 패킷 길이 필드는, 이러한 패킷 타입에 대해 값 10 을 갖는, 패킷 길이 필드를 제외한 총 바이트 수를 정의하는데 이용되는 반면, 137 의 패킷 타입은 패킷을 스케일링된 비디오 스트림 확인 응답 패킷으로 식별한다.
2-바이트 c클라이언트 ID 필드는 클라이언트 ID 를 위한 장래 사용을 위해 보류되고, 일반적으로 0 으로 설정된다. 2-바이트 스트림 ID 필드는 스트림 ID 에 대한 고유 식별자를 규정한다. 이것은 스케일링된 비디오 스트림 설정 패킷에서 호스트에 의해 할당된 것과 동일한 값이다.
2-바이트 Ack 코드 필드는 특정 스케일링된 비디오 스트림의 업데이트의 시도의 결과를 설명하는 코드를 포함하는 값을 제공한다. 일 실시형태에서, 코드는 다음과 같이 정의된다.
0 - 스트림 할당 시도는 성공적이었다.
1 - 스트림 할당 해제 시도는 성공적이었다.
2 - 이미 할당되었던 스트림 ID 를 할당하는 무효 시도.
3 - 이미 할당 해제된 스트림 ID 를 할당 해제하는 무효 시도.
4 - 클라이언트가 스케일링된 비디오 스트림을 지원하지 않는다.
5 - 스트림 파라미터가 클라이언트의 능력과 일치되지 않는다.
6 - 클라이언트에 의해 허용된 최대값보다 큰 스트림 ID 값.
7 - 특정 스트림을 할당에 이용가능한 클라이언트의 불충분한 리소스.
2-바이트 CRC 필드는 패킷 길이를 포함하는 패킷 내 모든 바이트의 CRC 를 포함한다.
34. 스케일링된 비디오 스트림 패킷
스케일링된 비디오 스트림 패킷은 특정한 스케일링된 비디오 스트림과 관련된 픽셀 데이터를 전송하기 위해 이용된다. 이 패킷에 의한 영역 참조의 사이즈는 스케일링된 스트림 설정 패킷에 의해 정의된다. 클라이언트는 유효 상태 응답 리스트 패킷의 유효 파라미터 응답 리스트 내 143 의 파라미터 값을 통해, 그리고 스케일링된 비디오 스트림 확인 응답 패킷의 Ack 코드 필드 내의 성공적인 스케일링된 비디오 스트림 할당 응답을 이용하여 스케일링된 비디오 스트림 패킷을 지원할 수 있는 클라이언트의 능력을 표시할 수 있다.
스케일링된 비디오 스트림 패킷의 일 실시형태의 형식이 도 78 에 일반적으로 도시되어 있다. 도 78 에 도시된 바와 같이, 스케일링된 비디오 스트림 패킷은 패킷 길이, 패킷 타입, h클라이언트 ID, 스트림 ID, 픽셀 데이터 속성, 픽셀 카운트, 파라미터 CRC, 픽셀 데이터, 및 픽셀 데이터 CRC 필드를 갖도록 구성된다. 2-바이트 패킷 타입 필드는 18 의 값을 사용하여 패킷을 스케일링된 비디오 스트림 패킷으로 식별한다. h클라이언트 ID 필드는 클라이언트 ID 를 위해 보류되어 일반적으로 0 으로 설정된다. 전과 같이, 2-바이트 스트림 ID 필드는 스트림 ID 를 위한 고유 식별자를 특정한다. 이 값은 스케일링된 비디오 스트림 설정 패킷에서 호스트에 의해 특정되고, 스케일링된 비디오 스트림 확인 응답 패킷에서 확인된다.
일 실시형태에서, 2-바이트 픽셀 데이터 속성 필드는 픽셀 데이터 라우팅 및 디스플레이 업데이트 또는 버퍼 위치를 특정하는 값을 갖는다. 일 실시형태에서, 이러한 값들은 다음과 같이 해석되어, 비트 1 및 0 은 픽셀 데이터가 라우팅될 디스플레이를 선택한다. 비트 값 '11' 또는 '00' 인 경우, 픽셀 데이터는 두 눈 모두로 또는 모두에 대해 디스플레이되고, 비트 값 '10' 인 경우, 픽셀 데이터는 좌측 눈으로만 라우팅되고, 비트 값 '01' 인 경우 픽셀 데이터는 우측 눈으로만 라우팅된다.
비트 7 및 6 은 픽셀 데이터가 기록될 프레임 버퍼를 특정하는 디스플레이 업데이트 비트이다. 프레임 업데이트 비트의 효과는 다른 곳에서 더 자세하게 설명한다. 비트 [7:6] 이 '01' 인 경우에, 픽셀 데이터는 오프라인의 이미지 버퍼에 기록된다. 비트 [7:6] 이 '00' 인 경우에, 픽셀 데이터는 디스플레이를 리프레쉬하는데 이용되는 이미지 버퍼에 기록된다. 비트 [7:6] 이 '11' 인 경우에, 픽셀 데이터는 모든 이미지 버퍼에 기록된다. 비트 [7:6] 이 '10' 인 경우에, 이는 무효 값으로 다루어진다. 이러한 비트들은 장래 사용을 위해 현재로서는 보류된다. 이런 상황에서, 픽셀 데이터는 무시되고 어떤 이미지 버퍼에도 기록되지 않게 된다. 비트 15 내지 14 및 11 내지 8 은 장래의 사용을 위해 보류되고 일반적으로 로직 0 레벨 또는 값으로 설정된다.
일 실시형태에서, 비트 [13:12] 또는 13 및 12 는, 수신지 픽셀이 투명 컬러 및 투명 마스크에 관련될 때 수신지 위치에 기록될지 여부를 특정하는데 사용된다. 비트 [13:12] 가 값 00과 동일한 경우, 투명 컬러는 사용되지 않는다. 해당 수신지 픽셀은 투명 컬러 또는 투명 마스크의 값을 고려하지 않고 수신지 픽셀 위치에 기록된다. 투명 컬러는 투명 컬러 및 마스크 설정 패킷에 의해 정의된다. 비트 [13:12] 에 대한 01 의 값은 장래의 사용을 위해 보류되고, 일반적으로 사용되지 않거나 유효한 상태로 고려되지 않는다. 비트 [13:12] 가 값 10 과 동일한 경우, 투명 마스크와 AND 된 소스 이미지 픽셀이 투명 컬러와 동일하지 않으면 수신지 픽셀은 수신지 위치에 기록되며, 이 경우 해당 픽셀은 수신지 픽셀 위치에 기록되지 않는다. 비트 [13:12] 가 값 11 과 동일한 경우, 투명 마스크와 AND 된 소스 이미지 픽셀이 투명 컬러와 동일하지 않으면 수신지 픽셀은 수신지 픽셀 위치에 기록되지 않으며, 이 경우 해당 픽셀은 수신지 픽셀 위치에 기록된다.
2-바이트 픽셀 카운트 필드는 이하의 픽셀 데이터 필드 내의 픽셀 수를 규정한다. 2-바이트 파라미터 CRC 필드는 패킷 길이로부터 픽셀 카운트까지 모든 바이트의 CRC 를 갖는다. 이러한 CRC 가 확인을 실패한다면, 모든 패킷이 폐기된다. 2-바이트 픽셀 데이터 필드는 스케일링 되고 그 후에 디스플레이될 미가공 (raw) 비디오 정보를 포함한다. 데이터는 비디오 데이터 형식 디스크립터 필드에 의해 설명된 방식으로 구성된다. 데이터는 미리 규정된 대로, 한 번에 한 행씩 전송된다.
2-바이트 픽셀 데이터 CRC 필드는 픽셀 데이터만의 CRC 를 포함한다. 이CRC 가 확인을 실패하면, 픽셀 데이터는 여전히 이용될 수 있지만, CRC 오류 카운트가 증가된다.
35. 요청 특정 상태 패킷
요청 특정 상태 패킷은 호스트가, 클라이언트가 이 패킷에 특정된 것과 같이 호스트에 능력 또는 상태 패킷을 다시 송신할 것을 요청하는 수단, 메커니즘 또는 방법을 제공한다. 클라이언트는 다음 역방향 링크 캡슐화 패킷에서 특정 타입의 패킷을 반환한다. 클라이언트가 요청 특정 상태 패킷에 대하여 응답하는 능력을 갖는 경우, 클라이언트는 클라이언트 능력 패킷의 클라이언트 특성 능력 필드의 비트 17 을 일반적으로 설정할 것이다. 클라이언트가 응답할 수 있는 모든 타입의 상태 패킷을 결정하기 위해서 호스트가 이용하는 편리한 방법은, 다른 부분에 설명된 유효 상태 응답 리스트 패킷을 이용하는 것이다. 클라이언트는 클라이언트 능력 패킷의 클라이언트 특성 능력 필드의 비트 21 을 이용하여 유효 상태 응답 리스트 패킷으로 응답할 수 있는 능력을 나타낼 수 있다.
요청 특정 상태 패킷의 일 실시형태의 형식이 일반적으로 도 79 에 도시된다. 도 79 에 도시된 바와 같이, 요청 특정 상태 패킷은 패킷 길이, 패킷 타입, h클라이언트 ID, 상태 패킷 ID 및 CRC 필드를 갖도록 구성된다. 패킷 길이 필드는 패킷 길이 필드를 제외한 패킷 내의 바이트의 총 수를 특정하고, 이 패킷 타입에 대해서는 일반적으로 값 10 으로 고정된다. 패킷 타입 138 은 패킷을 요청 특정 상태 패킷으로 식별한다. h클라이언트 ID 필드 (2 바이트) 는 클라이언트 ID 를 위한 장래의 사용을 위해 보류되고, 현재는 0 으로 설정되는 한편, 2-바이트 상태 패킷 ID 필드는, 클라이언트가 호스트로 전송하려고 하는 능력 또는 상태 패킷의 타입을 특정한다. 통상적인 패킷 타입은 다음과 같다:
66 - 클라이언트 능력 패킷이 클라이언트에 의해 전송된다.
133 - 알파-커서 이미지 능력 패킷이 클라이언트에 의해 전송된다.
139 - 클라이언트가 전송할 수 있는 능력 및 상태 패킷의 정확한 타입을 식별하는 유효 상태 응답 리스트 패킷이 전송된다.
141- 개인 클라이언트 능력 패킷이 클라이언트에 의해 전송된다.
142 - 클라이언트 오류 보고 패킷이 클라이언트에 의해 전송된다.
143 - 스케일링된 비디오 스트림 능력 패킷이 클라이언트에 의해 전송된다.
144 - 클라이언트 식별 패킷이 클리이언트에 의해 전송된다.
패킷 타입 56 내지 63 은 제조자-특정 능력 및 상태 식별자를 위해 이용될 수 있다.
역시 CRC 필드는 패킷 길이를 포함하는 패킷의 모든 바이트의 CRC 를 포함한다.
36. 유효 상태 응답 리스트 패킷
유효 상태 응답 리스트 패킷은 클라이언트가 반환할 능력을 갖는 상태 및 능력 패킷의 리스트를 갖도록 하는 구성, 수단 또는 방법을 호스트에게 제공한다. 클라이언트는 클라이언트 능력 패킷의 클라이언트 특성 능력 필드의 비트 21 을 사용하여 유효 상태 응답 리스트 패킷을 지원할 수 있는 능력을 표시할 수 있다.
유효 상태 응답 리스트 패킷의 일 실시형태의 형식이 일반적으로 도 80 에 도시된다. 도 80 에 도시한 바와 같이, 유효 상태 응답 리스트 패킷은 패킷 길이, 패킷 타입, c클라이언트 ID, 리스트 내 값 수 (Number of Values in the List), 유효 파라미터 응답 리스트 및 CRC 필드를 갖도록 구성된다. 이 타입의 패킷에 대한 패킷 길이는 일반적으로 값 10 으로 고정되고, 타입 값 139 는 패킷을 유효 상태 응답 패킷으로 식별한다. c클라이언트 ID 는 클라이언트 ID 로서의 장래에 이용을 위해 보류되고, 일반적으로 0 으로 설정된다. 2-바이트 리스트 내 값 수 필드는 후속하는 유효 파라미터 응답 리스트 내의 아이템 수를 특정한다.
유효 파라미터 응답 리스트 필드는 클라이언트가 호스트로 송신할 수 있는 능력 또는 상태 패킷의 타입을 특정하는 2 바이트 파라미터의 리스트를 포함한다. 클라이언트가 요청 특정 상태 패킷에 응답할 수 있음을 (디스플레이 능력 패킷의 디스플레이 특성 능력 표시자 필드의 비트 21 을 이용하여) 나타내면, 적어도 클라이언트 능력 패킷 (패킷 타입 = 66) 및 유효 상태 응답 리스트 패킷 (패킷 타입 =139) 를 송신할 수 있다. 일 실시형태의 목적을 위한 개별적 할당에 따라, 클라이언트에 의해 전송될 수 있고 이 리스트에 포함될 수 있는 패킷 타입은 다음과 같다:
66 - 클라이언트 능력 패킷
133 - 알파-커서 이미지 능력 패킷
139 - 클라이언트가 송신할 수 있는 능력 및 상태 패킷의 정확한 타입을 식별하는 유효 상태 응답 리스트 패킷
141 - 개인 디스플레이 능력 패킷
142 - 클라이언트 오류 보고 패킷
143 - 스케일링된 비디오 스트림 능력 패킷
144 - 클라이언트 식별 패킷
145 - 교대 디스플레이 능력 패킷
패킷 타입 56 내지 63 은 제조자-특정 능력 및 상태 식별자를 위해 이용될 수 있다.
CRC 필드는 패킷 길이를 포함하는 패킷의 모든 바이트의 CRC 를 포함한다.
37. 개인 디스플레이 능력 패킷
개인 디스플레이 능력 패킷은, 헤드 장착 디스플레이 또는 디스플레이 안경과 같은 개인 디스플레이 장치의 능력을 기술하는 파라미터 세트를 제공한다. 이는 호스트가 클라이언트의 특정 능력에 따라 디스플레이 정보를 커스터마이즈할 수 있도록 한다. 반면에 클라이언트는, 유효 상태 응답 리스트 패킷의 유효 파라미터 응답 리스트 내의 대응 파라미터를 이용함으로써 개인 디스플레이 능력 패킷을 전송하는 능력을 나타낸다.
개인 디스플레이 능력 패킷의 일 실시형태의 형식이 일반적으로 도 81 에 도시된다. 도 81 에 도시한 바와 같이, 개인 디스플레이 능력 패킷은 패킷 길이, 패킷 타입, c클라이언트 ID, 서브-픽셀 레이아웃, 픽셀 형상 (Pixel Shape), 뷰의 수평필드 (Horizontal Field of View), 뷰의 수직필드 (Vertical Field of View), 비주얼 축 교차 (Visual Axis Crossing), 좌/우측 이미지, 시 쓰루 (See Through), 최대 휘도, 광학 능력 (Optical Capability), 최소 IPD, 최대 IPD, 필드 곡률 지점 리스트 (Point of Field of Curvature) 및 CRC 필드를 갖도록 구성된다. 일 실시형태에서, 패킷 길이 필드값은 68 로 고정된다. 패킷 타입값 141 은 패킷을 개인 디스플레이 능력 패킷으로 식별한다. c클라이언트 ID 필드는 장래 사용을 위해 보류되고, 현재는 일반적으로 0 으로 설정된다.
일 실시형태에서, 서브-픽셀 레이아웃 필드는 다음의 값을 이용하여 상부에서 하부로, 좌측에서 우측으로 서브-픽셀의 물리적 레이아웃을 특정한다: 서브 픽셀 레이아웃이 정의되지 않았음을 나타내는 0; 적색, 녹색, 청색 스트립을 나타내는 1; 청색, 녹색, 적색 스트라이프를 나타내는 2; 상부 좌측에 적색, 하부 우측에 청색, 하부 좌측 및 상부 우측에 하나씩 두 개의 녹색 서브 픽셀의 2 x 2 서브 픽셀 배치를 갖는 쿼드 픽셀 (quad-pixel) 을 나타내는 3; 하부 좌측에 적색, 상부 우측에 청색, 상부 좌측 및 하부 우측에 하나씩 두 개의 녹색 서브 픽셀의 2 x 2 서브 픽셀 배치를 갖는 쿼드 픽셀을 나타내는 4; 델타 (트라이어드 (Triad)) 를 나타내는 5; 적색, 녹색, 및 청색으로 중첩된 모자이크 (예를 들어 필드-시퀀셜 (field-sequential) 컬러를 갖는 LCOS 디스플레이) 를 나타내는 6; 장래의 사용을 위해 일반적으로 보류된 7 내지 255 값.
일 실시형태에서, 픽셀 형상 필드는, 다음의 값을 이용하여, 특정 구성의 서브 픽셀로 이루어지는 각각의 픽셀의 형상을 특정한다: 서브 픽셀 형상이 정의되지 않음을 나타내는 0; 라운드를 나타내는 1; 정사각형을 나타내는 2; 직사각형을 나타내는 3; 타원형 (oval) 을 나타내는 4; 타원 (elliptical) 을 나타내는 5; 그리고 당업자에게 이해될 수 있는 바와 같이, 장래에 원하는 형상을 나타내는데 이용되도록 보류된 6 내지 255.
일 실시형태에서, 1-바이트의 뷰의 수평 필드 (HFOV) 필드는 0.5 도 증분으로 뷰의 수평 필드를 특정 (예를 들어, HFOV 가 30 도이면, 이 값은 60) 한다. 이 값이 0 이면 HFOV 는 특정되지 않는다.
일 실시형태에서, 1-바이트의 뷰의 수직 필드 (VFOV) 필드는 0.5 도 증분으로 뷰의 수직 필드를 특정 (예를 들어, VFOV 가 30 도이면, 이 값은 60) 한다. 이 값이 0 이면 VFOV 는 특정되지 않는다.
일 실시형태에서, 1-바이트의 비주얼 축 교차 (Visual Axis Crossing) 필드는 0.01 디옵터 (1/m) 증분으로 비주얼 축 교차를 특정 (예를 들어, 비주얼 축 교차가 2.22 미터이면, 이 값은 45) 한다. 이 값이 0 이면 비주얼 축 교차는 특정되지 않는다.
일 실시형태에서, 1-바이트의 좌측/우측 이미지 중첩 (Left/Right Image Overlap) 필드는 좌측 및 우측 이미지의 중첩의 퍼센티지를 특정한다. 이미지 오버랩의 허용가능한 범위는 퍼센트로 1 내지 100 이다. 101 내지 255 의 값은 유효하지 않으며, 일반적으로 사용되지 않는다. 이 값이 0 이면 이미지 중첩은 특정되지 않는다.
일 실시형태에서, 1-바이트의 시-스루 (See Through) 필드는 이미지의 시-스루 퍼센티지를 특정한다. 시-스루의 허용가능한 퍼센트 범위는 0 내지 100 이다. 101 내지 254 의 값은 유효하지 않으며 이용되지 않는다. 이 값이 255 이면 시-스루 퍼센티지는 특정되지 않는다. 1-바이트의 최대 휘도 필드는 20 니트 (nits) 의 증분으로 최대 밝기를 특정 (예를 들어 최대 밝기가 100 니트이면, 이 값은 5) 한다. 이 값이 0 이면 최대 휘도는 특정되지 않는다.
일 실시형태에서, 2-바이트의 광학 능력 플래그 필드는 디스플레이의 광학 능력을 특정하는 다양한 필드를 포함한다. 이들 비트 값은 일반적으로 비트 15 내지 5 가 장래의 사용을 위해 보류되며, 일반적으로 0 으로 설정되도록 할당된다. 비트 4 는 안경 촛점 조정 (Eye Glass Focus Adjustment) 을 선택하는데, '0' 값은 디스플레이가 안경 촛점 조정을 갖지 않음을 의미하고 '1' 값은 디스플레이가 안경 촛점 조정을 가짐을 의미한다. 비트 3 내지 2 는 다음에 따라 쌍안 기능 (Binocular Function) 을 선택한다: 0 값은 디스플레이가 쌍안용이며 2 차원 (2D) 이미지만을 디스플레이할 수 있음을 의미하고; 1 은 디스플레이가 쌍안용이고 3 차원 (3D) 이미지를 디스플레이할 수 있음을 의미하고; 2 는 디스플레이가 단안용 (monocular) 임을 의미하며, 3 은 장래의 사용을 위해 보류된다. 비트 1 내지 0 은 좌측-우측 필드 곡률 대칭을 선택하는데, 0 값은 필드 곡률이 규정되지 않음을 의미한다. 이 필드가 0 이면, 포인트 C3 를 제외하고는 A1 내지 E5 의 모든 필드 곡률 값이 0 으로 설정되고, 포인트 C3 는 디스플레이의 초점 거리를 특정하거나, 0 으로 설정되어 초점 거리가 특정되지 않았음을 나타낸다. 1 값은 좌측 및 우측 디스플레이가 동일한 대칭을 갖음을 의미하고, 2 값은 좌측 및 우측 디스플레이는 수직 축 (열 C) 에 대해 거울 대칭됨 (mirrored) 을 의미하고, 3 은 장래의 사용을 위해 보류된다.
일 실시형태에서, 1-바이트의 최소 동공 간 거리 (Inter-Pupillary Distance (IPD) Minimum) 필드는 밀리미터 (mm) 단위로 최소 동공 간 (inter-pupillary) 거리를 특정한다. 이 값이 0 이면 최소 동공간 거리는 특정되지 않는다. 1-바이트의 최대 동공 간 거리 (Inter-Pupillary Distance (IPD) Maximum) 필드는 밀리미터 (mm) 단위로 최대 동공 간 (inter-pupillary) 거리를 특정한다. 이 값이 0 이면 최대 동공 간 거리는 특정되지 않는다.
필드 곡률 지점 리스트 필드는 1 내지 65535 의 범위로 천분의 1 디옵터 (1/m) 단위의 초점 거리를 특정하는 (예를 들어, 1 은 0.001 디옵터이고 65535 는 65.535 디옵터) 25 개의 2 바이트 파라미터들의 리스트를 포함한다. 필드 곡률 지점 리스트의 25 개의 구성요소는 도 82 에 도시된 바와 같이 A1 내지 E5 로 레이블링 되어 있다. 점들은 디스플레이의 액티브 영역에 걸쳐 균일하게 분포된다. 열 C 는 디스플레이의 수직 축에 대응하며, 행 3 (row 3) 은 디스플레이의 수평 축에 대응한다. 열 A 및 E 는 디스플레이의 좌측 및 우측 에지에 각각 대응한다. 그리고, 행 1 및 5 는 디스플레이의 상부 및 하부 에지에 각각 대응한다. 리스트에서 25 개의 점의 순서는, A1, B1, C1, D1, E1, A2, B2, C2, D2, E2, A3, B3, C3, D3, E3, A4, B4, C4, D4, E4, A5, B5, C5, D5, E5 이다.
CRC 필드는 패킷 길이를 포함하는 패킷 내 모든 바이트의 CRC 를 포함한다.
38. 클라이언트 오류 보고 패킷
클라이언트 오류 보고 패킷은 클라이언트가 호스트에 동작 오류의 리스트를 제공할 수 있도록 하는 메커니즘 또는 수단으로 작용한다. 클라이언트는, 호스트로부터 특정 명령을 받은 결과로서 그 정상 동작 중에 넓은 범위의 오류를 검출할 수 있다. 이러한 오류들의 예는: 클라이언트가 지원하지 않는 모드로 동작하도록 명령받은 것, 클라이언트의 능력의 범위를 초과하거나 넘어서는 특정 파라미터를 포함하는 패킷을 수신한 것, 부적절한 시퀀스에서 모드에 진입하도록 명령받은 것을 포함할 수 있다. 클라이언트 오류 보고 패킷은 정상 동작동안 오류를 검출하는데 이용될 수 있지만, 시스템 설계자 및 통합자가 호스트 및 클라이언트 시스템의 개발 및 통합에서의 문제를 진단하는데 가장 유용하다. 클라이언트는 유효 상태 응답 리스트 패킷의 유효 파라미터 응답 리스트에서 142 의 파라미터 값을 이용하여 클라이언트 오류 보고 패킷을 전송하는 능력을 나타낸다.
클라이언트 오류 보고 패킷에 대한 일 실시형태의 형식이 도 83 에 일반적으로 도시된다. 도 83 에 도시된 바와 같이, 클라이언트 오류 보고 패킷은 패킷 길이, 패킷 타입, c클라이언트 ID, 리스트 아이템 수, 오류 코드 리스트 및 CRC 필드를 갖도록 구성된다. 142 의 패킷 타입 값은 패킷을 클라이언트 오류 보고 패킷으로 식별한다. c클라이언트 ID 필드는 장래 사용을 위해 보류되고, 현재는 일반적으로 0 으로 설정된다. 리스트 아이템 수 필드 (2 바이트) 는 후속하는 오류 코드 리스트 내 아이템 수를 특정한다. 오류 코드 리스트 필드 (여기에서 8 바이트) 는 하나 이상의 오류 보고 리스트 아이템을 포함하는 리스트이다. 단일 오류 보고 리스트 아이템의 형식이 도 84 에 도시된다.
도 84 에 도시된 일 실시형태에서, 각각의 오류 보고 리스트 아이템은 정확히 4 바이트 길이이며, 일 실시형태에서 다음을 포함하는 구조를 가진다: 보고되고 있는 오류의 타입을 특정하는 2 바이트 디스플레이 오류 코드 필드, 클라이언트 오류 코드 패킷에 의해 정의되는 오류에 관한 고도로 상세한 사항을 특정하는 2 바이트 오류 서브 코드 필드. 각각의 클라이언트 오류 코드의 구체적 정의는 클라이언트의 제조자에 의해 정의된다. 오류 서브 코드는 모든 디스플레이 오류 코드에 대하여 정의될 필요는 없으며, 오류 서브 코드가 정의되지 않은 경우에 그 값은 0 으로 설정된다. 각각의 오류 서브 코드의 구체적 정의는 클라이언트의 제조자에 의해 정의된다.
39. 클라이언트 식별 패킷
클라이언트 식별 패킷은, 요청 특정 상태 패킷에 응답하여 클라이언트가 식별 데이터를 반환할 수 있도록 한다. 일 실시형태에서, 클라이언트는 유효 상태 응답 리스트 패킷의 유효 파라미터 응답 리스트 내 144 의 파라미터 값을 이용하여 클라이언트 식별 패킷을 전송하는 능력을 나타낸다. 호스트가 이 데이터를 클라이언트로부터 판독함으로써 클라이언트 장치의 제조자 이름 및 모델 번호를 결정할 수 있는 것이 유용하다. 이 정보는 클라이언트가 클라이언트 능력 패킷에 기술될 수 없는 특별한 능력을 갖는지 여부를 결정하는데 이용될 수 있다. 클라이언트로부터 식별 정보를 판독하는데에는 잠재적으로 두 가지 방법, 수단, 또는 메커니즘이 있다. 하나는, 베이스 EDID 구조에서와 유사한 필드를 포함하는 클라이언트 능력 패킷의 이용을 통한 것이다. 다른 방법은, 클라이언트 능력 패킷 내 유사한 필드에 비해 더 풍부한 정보 세트를 포함하는 클라이언트 식별 패킷의 이용을 통한 것이다. 이는 호스트가 3-캐릭터 EISA 코드를 할당받지 않은 제조자를 식별할 수 있도록 하고, 시리얼 번호가 알파뉴메릭 캐릭터를 포함할 수 있도록 한다.
클라이언트 식별 패킷의 일 실시형태의 형식이 일반적으로 도 85 에 도시된다. 도 85 에 도시된 바와 같이, 클라이언트 식별 패킷은 패킷 길이, 패킷 타입, c클라이언트 ID, 제조 주 (week), 제조 년, 제조자 이름의 길이, 제품명 길이, 시리얼 번호 길이, 제조자 명 스트링, 제품명 스트링, 시리얼 번호 스트링 및 CRC 필드를 갖도록 구성된다.
2 바이트 패킷 타입 필드는 패킷을 클라이언트 식별 패킷으로 식별하는 값을 포함한다. 일 실시형태에서 이 값은 144 로 설정된다. 다시, c클라이언트 ID 필드 (2 바이트) 는 클라이언트 ID 를 위한 장래의 이용을 위해 보류되고, 일반적으로 0 으로 설정된다. CRC 필드 (2 바이트) 는 패킷 길이를 포함하는 모든 바이트의 16 비트 CRC 를 포함한다.
1 바이트 제조 주 (Week of Manufacture) 필드는 디스플레이의 제조의 주를 규정하는 값을 포함한다. 적어도 일 실시형태에서, 이 값은, 클라이언트에 의해 지원된다면 1 에서 53의 범위 내에 있다. 이 필드가 클라이언트에 의해 지원되지 않으면, 일반적으로 영으로 설정된다. 1 바이트의 제조 년 (Year of Manufacture) 필드는 클라이언트 (디스플레이) 의 제조 연도를 규정하는 값을 포함한다. 다른 기준 년도가 사용될 수 있지만, 이 값은 1990 년을 출발점으로한 오프셋이다. 1991에서 2245의 범위의 연도가 이 필드에 의해 나타내질 수 있다. 예: 2003 년은 13 의 제조 년 값에 대응한다. 이 필드가 클라이언트에 의해 지원되지 않으면 이는 0 값으로 설정되어야 한다.
제조자 이름의 길이, 제품명 길이, 시리얼 번호 필드의 길이는, 각각 임의의 널 종단 또는 널 패드 문자를 포함하는 제조사 이름 스트링 필드의 길이, 임의의 널 종단 또는 널 패드 문자를 포함하는 제품명 길이, 및 임의의 널 종단 또는 널 패드 문자를 포함하는 시리얼 번호 스트링 필드의 길이를 특정하는 2 바이트 값을 각각 포함한다.
제조자 이름 스트링, 제품명 스트링, 및 시리얼 번호 스트링은 각각 길이 제조자 이름, 제품명, 및 시리얼 번호 필드를 특정하는 가변 수의 바이트를 포함하며, 이들은 각각 제조자, 제품명, 및 디스플레이의 알파뉴메릭 시리얼 번호를 특정하는 ASCII 스트링을 각각 포함한다. 이러한 스트링 각각은 하나 이상의 널 문자에 의해 종결된다.
40. 교대 디스플레이 능력 패킷
교대 디스플레이 능력 패킷은 MDDI 클라이언트 제어기에 부착된 교대 디스플레이의 능력을 나타내는 수단, 구조, 또는 방법으로 사용된다. 이것은 요청 특정 상태 패킷에 응답하여 전송된다. 프롬프트 (prompt) 되면, 클라이언트 장치는, 지원되는 각각의 교대 디스플레이에 대한 교대 디스플레이 능력 패킷을 전송한다. 클라이언트가 하나 이상의 교대 디스플레이를 갖는 경우, 효율적이진 않지만 요구에 따라 다수의 요청 특정 상태 패킷을 사용할 수도 있지만, 클라이언트는 단일한 요청 특정 상태 패킷에 응답하여 각 디스플레이 중 하나에 다수의 교대 디스플레이 능력 패킷을 전송하거나 생성하거나 제공해야 한다. 클라이언트는 Alt 디스플레이 수 필드의 값에 기초하여, 소위 "비순차적 순서" 로 교대 디스플레이 능력 패킷을 전송할 수도 있다. 클라이언트는 유효 상태 응답 리스트 패킷의 유효 파라미터 응답 리스트에서 145 의 파라미터 값을 통해 교대 디스플레이 능력 패킷을 전송할 능력을 나타낼 수 있다.
내부 모드에서 작동되는 MDDI 시스템에 대하여, MDDI 클라이언트 제어기와 연결된 디스플레이를 2 개 이상 가지는 것은 일반적일 수 있다. 예시적인 애플리케이션은 플립의 내부의 큰 디스플레이와 외부의 더 작은 디스플레이를 갖는 휴대 전화이다. 2 개의 잠재적인 이유에서, 내부 모드에서 클라이언트가 교대 디스플레이 능력 패킷을 반환할 필요는 없다. 첫 번째로, 이들이 공통 장치 또는 하우징 내에서 이용되므로, 호스트는 이미 제조 중에 프로그램되었거나, 다른 방법으로 그 능력을 인지할 수 있다. 두 번째로, 둘의 조립으로 인해, 클라이언트는 호스트로의 접속으로부터 용이하게 접속 해제되거나 분리될 수 없으며, 호스트는 클라이언트 능력의 하드 코딩된 (hard-coded) 복사본을 포함하거나, 최소한 그렇지 않은 경우 발생할 수 있는 클라이언트의 변화에 따라 그들이 변하지 않음을 알 수 있다.
클라이언트 능력 패킷의 교대 디스플레이 수 필드는 일 이상의 디스플레이가 부착되어 있음을 보고하는데 이용되고, 교대 디스플레이 능력 패킷은 각 교대 디스플레이의 능력을 보고한다. 비디오 스트림 패킷은 픽셀 데이터 속성 필드 내의 4 비트를 포함하여, 클라이언트 장치 내의 각 교대 디스플레이에 어드레싱한다.
교대 디스플레이 능력 패킷의 일 실시형태의 형식이 일반적으로 도 89 에 도시된다. 도 89 에 도시된 바와 같이, 교대 디스플레이 능력 패킷은 패킷 길이, 패킷 타입, c클라이언트 ID, 교대 디스플레이 넘버, 보류 1, 비트맵 폭, 비트맵 높이, 디스플레이 윈도우 폭, 디스플레이 윈도우 높이, 컬러 맵 RGB 폭, RGB 능력, 흑백 능력, 보류 2, Y Cb Cr 능력, 베이어 능력, 보류 3, 디스플레이 특성 능력 및 CRC 필드를 갖도록 구성된다. 145 의 패킷 타입 값은 패킷을 교대 디스플레이 능력 패킷으로 식별한다. c클라이언트 ID 필드는 장래 사용을 위해 클라이언트 ID 를 위해 보류되고, 일반적으로 비트들을 로직 0 레벨로 설정함으로써 0 값으로 설정된다.
교대 디스플레이 넘버 필드는 0에서 15의 범위의 정수로 교대 디스플레이의 정체를 나타내기 위해 1 바이트를 사용한다. 첫 번째 교대 디스플레이는 통상적으로 넘버 0 으로 표시되고, 다른 교대 디스플레이는, 교대 디스플레이 총수에서 1 을 뺀 것을 사용되는 가장 큰 값으로 하여, 고유한 교대 디스플레이 개수로 식별된다. 교대 디스플레이의 총 개수에서 1 을 뺀 값보다 더 큰 값은 이용되지 않는다. 예: 주 디스플레이와 MDDI 클라이언트에 연결된 콜러-ID 디스플레이를 갖는 휴대 전화는 하나의 교대 디스플레이를 가지며, 따라서 콜러-ID 디스플레이의 교대 디스플레이 넘버가 영이고, 클라이언트 능력 패킷의 교대 디스플레이 수 필드는 1 의 값을 갖는다.
보류 1 필드 (1 바이트) 는 장래 사용을 위해 보류된다. 따라서, 이 필드에 있는 모든 비트는 현재 0 또는 로직 0 레벨과 동일하게 설정된다. 일 실시형태에서, 이 필드를 패킷에 존재시키는 일 목적은 모든 후속 2 바이트 필드가 16 비트 워드 어드레스에 정렬하도록 하고 4-바이트 필드가 32-비트 워드 어드레스에 정렬하도록 하는 것이다.
비트맵 폭 필드는 픽셀 수로 표현되는 비트맵의 폭을 특정하는 2 바이트를 사용한다. 비트맵 높이 필드는 픽셀 수로 표현되는 비트맵의 높이를 특정하는 2 바이트를 사용한다. 디스플레이 윈도우 폭 필드는 픽셀 수로 표현되는 디스플레이 윈도우의 폭을 특정하는 2 바이트를 사용한다. 디스플레이 윈도우 높이 필드는 픽셀 수로 표현되는 디스플레이 윈도우의 높이를 특정하는 2 바이트를 사용한다.
컬러 맵 RGB 폭 필드는 컬러 맵 (팔레트) 디스플레이 모드에서 디스플레이될 수 있는 적색, 녹색, 및 청색 성분의 비트의 수를 특정하는 2 바이트를 사용한다. 각각의 컬러 성분 (적색, 녹색, 및 청색) 에 대하여 최대 8 비트가 이용될 수 있다. 각각의 컬러 성분의 8 비트가 컬러 맵 패킷 내에서 보내진다 해도, 이 필드에 규정된 각각의 컬러 성분의 최하위 비트의 수 (the number of least significant bits) 만이 이용된다. 디스플레이 클라이언트가 컬러 맵 (팔레트) 형식을 이용할 수 없으면 이 값이 영이다. 컬러 맵 RGB 폭 워드는 3 개의 별개의 무부호 값으로 구성된다:
비트 3 내지 0 은 각각의 픽셀 내 청색 비트의 최대 수를 정의하고, 0 내지 8 의 값이 유효한 것으로 고려된다. 비트 7 내지 4 는 각각의 픽셀 내 녹색 비트의 최대 수를 정의하고 0 내지 8 의 값이 유효한 것으로 고려된다. 비트 11 내지 8 은 각각의 픽셀 내의 적색 비트의 최대 수를 정의하고, 0 내지 8 의 값이 유효한 것으로 고려된다. 비트 14 내지 12 는 장래 사용을 위해 보류되고, 일반적으로 0 으로 설정된다. 비트 15 는 패킷화되거나 (packed) 패킷화되지 (unpacked) 않은 컬러 맵 픽셀 데이터를 받아들이는 클라이언트의 능력을 나타내는데 이용된다. 비트 15 가 로직 1 레벨로 설정되는 경우에, 이것은 클라이언트가 컬러 맵 픽셀 데이터를 패킷화되거나 패킷화되지 않은 형식으로 수신할 수 있음을 나타낸다. 비트 15 가 로직 0 으로 설정된다면, 이것은 클라이언트가 컬러맵 픽셀 데이터를 패킷화되지 않은 형식으로만 수신할 수 있음을 나타낸다.
RGB 능력 필드는 RGB 형식으로 디스플레이될 수 있는 해상도의 비트 수를 특정하기 위하여 2 바이트를 사용한다. 일 실시형태에서, 클라이언트가 RGB 형식을 사용할 수 없다면, 이 값은 0 과 동일하게 설정된다. RGB 능력 워드는 3 개로 별개의 무부호 값으로 구성된다: 비트 3 내지 0 은 각각의 픽셀에서 청색 비트의 최대수 (청색 강도) 를 규정하고, 비트 7 내지 4 는 각각의 픽셀에서 녹색 비트의 최대수 (녹색 강도) 를 규정하고, 비트 11 내지 8 은 각각의 픽셀에서 적색 비트의 최대수 (적색 강도) 를 규정한다. 비트 14 내지 12 는 장래 사용을 위해 보류되고 0 으로 설정된다. 비트 15 는 RGB 픽셀 데이터를 패킷화되거나 패킷화되지 않은 형식으로 받아들이는 클라이언트의 능력을 나타내는데 이용된다. 비트 15 가 로직 1 레벨로 설정되는 경우에, 이것은 클라이언트가 RGB 픽셀 데이터를 패킷화되거나 패킷화되지 않은 형식으로 수신할 수 있음을 나타낸다. 비트 15 가 로직 0 으로 설정된다면, 이것은 클라이언트가 RGB 픽셀 데이터를 패킷화되지 않은 형식으로만 수신할 수 있음을 나타낸다.
1-바이트의 흑백 능력 필드는 흑백 형식으로 디스플레이될 수 있는 해상도의 비트 수를 특정하는 값 또는 정보를 포함한다. 클라이언트가 흑백 형식을 이용할 수 없으면 이 값은 0 과 동일하게 설정된다. 비트 6 내지 4는 장래 사용을 위해 보류되고 일반적으로 0 으로 설정된다. 비트 3 내지 0은 각각의 픽셀에 존재할 수 있는 그레이 스케일 비트의 최대수를 규정한다. 이들 4 비트는 각각의 픽셀 각각이 1 내지 15 비트로 구성됨을 특정하는 것을 가능하게 한다. 값이 영이면 흑백 형식이 클라이언트에 의해 지원되지 않는다. 비트 7 은, 1 로 설정된 경우, 클라이언트가 흑백 픽셀 데이터를 패킷화되거나 패킷화되지 않은 형식으로 받아들일 수 있음을 나타낸다. 비트 7 이 0 으로 설정된 경우, 이는 클라이언트가 흑백 픽셀 데이터를 패킷화되지 않은 형식으로만 받아들일 수 있음을 나타낸다.
보류 2 필드는 장래 사용을 위해 보류되는 1 바이트 폭의 필드이고, 이 필드에 있는 모든 비트는 일반적으로 로직 0 레벨로 설정된다. 일 실시형태에서, 이 필드를 패킷에 존재시키는 일 목적은 모든 후속 2 바이트 필드가 16 비트 워드 어드레스에 정렬하도록 하고 4-바이트 필드가 32-비트 워드 어드레스에 정렬하도록 하는 것이다.
2-바이트의 Y Cb Cr 능력 필드는 Y Cb Cr 형식으로 디스플레이될 수 있는 해상도 비트 수를 특정한다. 클라이언트가 Y Cb Cr 형식을 이용할 수 없으면 이 값이 0 이다. Y Cb Cr 능력 워드는 3 개의 별개의 무부호 값으로 구성된다: 비트 3 내지 0은 Cb 샘플을 특정하는 최대 비트 수를 규정하고, 비트 7 내지 4는 Cr 샘플을 특정하는 최대 비트 수를 규정하고, 비트 11 내지 8은 Y 샘플을 특정하는 최대 비트 수를 규정하고, 비트 14 내지 12는 장래 사용을 위해 보류되고 0 으로 설정된다. 1 로 설정된 경우에, 비트 15 는 클라이언트가 Y Cb Cr 픽셀 데이터를 패킷화되거나 패킷화되지 않은 형식으로 수신할 수 있음을 나타낸다. 비트 15 가 0 으로 설정된 경우에, 이는 15 는 클라이언트가 Y Cb Cr 픽셀 데이터를 패킷화되지 않은 형식으로만 수신할 수 있음을 나타낸다.
2 바이트 베이어 (Bayer) 능력 필드는 베이어 형식으로 전송될 수 있는 해상도의 비트 수, 픽셀 그룹 및 픽셀 순서를 특정한다. 클라이언트가 베이어 형식을 사용할 수 없다면, 이 값은 0 으로 설정된다. 베이어 능력 필드는 다음의 값으로 구성된다: 비트 3 내지 0 은 각각의 픽셀에 존재하는 강도의 최대 비트 수를 규정하고, 비트 5 내지 4 는 요구될 수 있는 픽셀 그룹 패턴을 규정한다. 비트 8 내지 6 은 요구되는 픽셀 순서를 규정하고, 비트 14 내지 9 는 장래 사용을 위해 보류되고, 0 으로 설정된다. 1 로 설정된 경우에, 비트 15 는 클라이언트가 베이어 픽셀 데이터를 패킷화되거나 패킷화되지 않은 형식으로 수신할 수 있음을 나타낸다. 비트 15 가 0 으로 설정된다면, 이것은 클라이언트가 베이어 픽셀 데이터를 패킷화되지 않은 형식으로만 수신할 수 있음을 나타낸다.
여기서는 2 바이트인 보류 3 필드는 장래의 사용을 위해 보류된다. 따라서, 이 필드의 모든 비트는 통상적으로 로직 0 레벨 또는 0 값과 동일하게 설정된다. 일 실시형태에서, 이 필드를 패킷에 존재시키는 현재의 목적은 후속 2 바이트 필드를 16 비트 워드 어드레스로 정렬시키고, 4 비이트 필드를 32 비트 워드 어드레스로 정렬시키기 위해서이다.
여기서는 4 바이트를 사용하는 디스플레이 속성 능력 표시자 필드는, 교대 디스플레이 내의 특정 특성이 지원되는지 여부를 지정하는 플래그의 세트를 포함한다. 1 로 설정된 비트는 특정의 또는 소정의 능력이 지원됨을 나타내고, 0 으로 설정된 비트는 능력이 지원되지 않음을 나타낸다.
일 실시형태에서, 디스플레이 특성 능력 필드는, 지원되는 교대 디스플레이에서 특정 특성을 지정하는 플래그의 세트를 포함하는 4 바이트를 사용한다. 로직 1 레벨로 설정된 비트는, 능력이 지원됨을 나타내고, 로직 0 레벨로 설정된 비트는 능력이 지원되지 않음을 나타낸다. 일 실시형태에서, 비트 0 에 대한 값은 비트맵 블록 전송 패킷 (패킷 타입 71) 이 지원되는지 여부를 나타낸다. 비트 1, 2 및 3 에 대한 값은 비트맵 영역 채움 패킷 (패킷 타입 72), 비트맵 패턴 채움 패킷 (패킷 타입 73), 또는 판독 프레임 버퍼 패킷 (패킷 타입 74) 가 각각 지원되는지 여부를 나타낸다. 비트 4 에 대한 값은, 교대 디스플레이가 투명 컬러 인에이블 패킷을 사용하여 하나의 컬러를 투명하게 할 능력을 가졌는지 여부를 나타낸다.
일 실시형태에서, 디스플레이 특성 능력 필드의 비트 10 값은, 교대 디스플레이가 디스플레이 전력 상태 01 을 지원할 능력을 가졌는지 여부를 나타낸다. 디스플레이 전력 상태는 전술한 디스플레이 전력 상태 패킷의 전력 상태 필드의 비트 [3:2] 를 사용하여 설정된다. 디스플레이 전력 상태 01 은, 선택된 디스플레이가 발광하지 않고 소모한다 해도 최소량의 전력을 소모하는 상태이며, 프레임 버퍼의 콘텐츠는 이 상태동안 유지되는 것이 일반적으로 보장되거나 확신된다.
디스플레이 특성 능력 필드의 비트 13 의 값은, 교대 디스플레이가 VCP 특성 패킷: 요청 VCP 특성 패킷, VCP 특성 응답 패킷, 설정 VCP 특성 패킷, 요청 유효 파라미터 패킷 및 유효 파라미터 응답 패킷을 지원함으로써 하나 이상의 비디오 파라미터를 설정할 능력을 가졌는지 여부를 나타낸다. 비트 14 에 대한 값은, 교대 디스플레이가 픽셀 데이터를 오프라인 디스플레이 프레임 버퍼로 기록할 능력을 가졌는지 여부를 나타내며, 도 88a 에 도시되어 있다. 이 비트가 로직 1 레벨로 설정되면, 디스플레이 업데이트 비트 (비디오 스트림 패킷의 픽셀 데이터 특성 필드의 비트 7 및 6) 는 값 '01' 로 설정될 수도 있다.
디스플레이 특성 능력 필드의 비트 15 에 대한 값은, 픽셀 데이터를, 현재 디스플레이 이미지를 리프레쉬하는데 사용되고 있는 디스플레이 프레임 버퍼로만 기록할 능력을 가졌는지 여부를 나타내며, 도 88b 에 도시되어 있다. 이 비트가 로직 1 이면, 디스플레이 업데이트 비트 (비디오 스트림 패킷의 픽셀 데이터 속성 필드의 비트 7 및 6) 는 값 '00' 으로 설정될 수도 있다. 비트 16 에 대한 값은, 교대 디스플레이가 픽셀 데이터를 단일 비디오 스트림 패킷으로부터 모든 디스플레이 프레임 버퍼로 기록할 능력을 가졌는지 여부를 나타내며, 도 88c 에 도시되어 있다. 이 비트가 로직 1 레벨로 설정되면, 디스플레이 업데이트 비트 (비디오 스트림 패킷의 픽셀 데이터 속성 필드의 비트 7 및 6) 은 값 '11' 로 설정될 수도 있다.
일 실시형태에서, 디스플레이 특성 능력 필드의 비트 21 에 대한 값은, 비트맵 블록 전송 패킷 (패킷 타입 71), 비트맵 영역 채움 패킷 (패킷 타입 72) 및 비트맵 패턴 채움 패킷 (패킷 타입 73) 이 비트 0, 1, 및 2 또는 이 필드에 의해 특정되는 바와 같이 교대 디스플레이에 의해 지원되는 경우, 교대 디스플레이가 이 패킷들의 래스터 연산 필드를 사용할 능력을 가졌는지 여부를 나타낸다. 일 실시형태에서, 비트 21 이 로직 0 레벨 또는 값을 갖고, 패킷이 지원되면, 교대 디스플레이는 래스터 연산 필드를 사용할 능력을 갖지 않고 통상적으로 이 패킷에 의해 특정된 픽셀 위치를 카피 또는 기록할 능력만을 갖는다.
일 실시형태에서, 디스플레이 특성 능력 필드의 비트 9 내지 5, 11, 12, 20 내지 17 및 31 내지 22 는 현재 장래의 사용 또는 시스템 설계자에게 유용한 다른 지정을 위해 보류되어 있고, 일반적으로 0 값 또는 로직 0 레벨로 설정된다.
일 실시형태에서, 2 바이트 CRC 필드는 패킷 길이를 포함하는 패킷에서 모든 바이트의 16 비트 CRC 를 포함한다.
41. 레지스터 액세스 패킷
레지스터 액세스 패킷은, MDDI 링크의 대향 단에서 구성 및 상태 레지스터를 액세스하는 수단, 매커니즘, 또는 방법을 호스트 또는 클라이언트에 제공한다. 이러한 레지스터는 각각의 디스플레이 또는 장치 제어기에 고유한 것일 가능성이 높다. 이러한 레지스터는 설정 구성, 동작 모드를 요구하고 기타 유용하고 필요한 설정을 갖는 많은 디스플레이에 이미 존재한다. 레지스터 액세스 패킷은, MDDI 호스트 또는 클라이언트가 MDDI 링크를 이용하여 레지스터에 기록하고 레지스터를 판독하기 위한 요청을 하는 것을 모두 허용한다. 호스트 또는 클라이언트가 레지스터 판독을 요청하는 경우, 대향 단은 동일한 패킷 타입으로 레지스터 데이터를 전송함으로써, 또한 판독/기록 정보 필드를 이용하여 이것이 특정의 레지스터로부터 판독된 데이터라는 것을 표시함으로써 응답해야 한다. 레지스터 액세스 패킷은, 1 보다 큰 레지스터 카운트를 특정함으로써 다수의 레지스터를 판독하고 기록하는 데에 이용될 수 있다. 클라이언트는 클라이언트 능력 패킷의 클라이언트 특성 능력 필드의 비트 22 를 이용하여 레지스터 액세스 패킷을 지원하는 능력을 표시한다. 클라이언트는 캡슐화 패킷을 이용하여 레지스터 액세스 패킷을 전송하고, 따라서 패킷 구성 또는 구조 내에 패킷으로 나타나는 것을 제공한다.
레지스터 액세스 패킷의 일 실시형태의 형식이 일반적으로 도 87 에 도시된다. 도 87 에 도시한 바와 같이, 레지스터 액세스 패킷은 패킷 길이, 패킷 타입, b클라이언트 ID, 판독/기록 Info 또는 정보, 레지스터 어드레스, 파라미터 CRC, 레지스터 데이터 리스트 및 레지스터 데이터 CRC 필드를 갖도록 구성된다. 146 의 패킷 타입 값은 패킷을 레지스터 액세스 패킷으로 식별한다. b클라이언트 ID 필드는 장래 사용을 위해 보류되고, 현재는 일반적으로 0 으로 설정된다.
일 실시형태에서, 2-바이트의 판독/기록 Info 필드는 특정 패킷을 기록, 또는 판독, 또는 패킷의 타입인 판독에 대한 응답으로 특정하기 위한 메커니즘으로서 동작하며, 데이터 값의 카운트를 제공한다.
비트 15 내지 14 는 판독/기록 플래그로서 기능한다. 비트 [15:14] 가 '00' 이라면, 이 패킷 레지스터 어드레스 필드에 의해 어드레싱되는 레지스터에 기록될 데이터를 포함한다. 특정 레지스터에 기록될 데이터는 레지스터 데이터 리스트 필드에 포함된다. 비트 [15:14] 가 '10' 이라면, 이것은 레지스터 어드레스 필드에 의해 어드레싱된 하나 이상의 레지스터로부터의 데이터 요청이다. 비트 [15:14] 가 '11' 이라면, 그 패킷은 '10' 으로 설정된 판독/기록 플래그의 15:14 비트를 갖는 레지스터 액세스 패킷에 대한 응답으로 요청된 데이터를 포함한다. 레지스터 어드레스 필드는 첫 번째 레지스터 데이터 리스트 아이템에 대응하는 레지스터의 어드레스를 포함하고, 레지스터 데이터 리스트 필드는 어드레스 또는 어드레스들로부터 판독되는 데이터를 포함한다. 비트 [15:14] 가 '01' 이라면, 이것은 유효하지 않은 값으로서 다루어지고, 이러한 값은 장래 사용을 위해 보류되며, 지금은 사용되지 않으나, 당업자는 장래의 애플리케이션에서 이를 어떻게 이용할 지 인식할 것이다.
비트 13:0 은 레지스터 데이터 리스트 필드에서 전송될 32-비트 레지스터 데이터 아이템의 수를 특정하는 14-비트의 무부호 정수를 사용한다. 비트 15:14 가 '00' 이라면, 비트 13:0 은 레지스터 어드레스 필드에 의해 특정되는 레지스터에서 시작하여 레지스터에 기록될 레지스터 데이터 리스트 필드에 포함된 32-비트 레지스터 데이터 아이템의 수를 특정한다. 비트 15:14 가 '10' 과 같다면, 비트 13:0 은, 수신 장치가 레지스터가 판독되어야 함을 요청한 장치로 전송하는 32-비트 레지스터 데이터 아이템의 수를 특정한다. 이 패킷의 레지스터 데이터 리스트 필드는 어떠한 아이템도 포함하지 않고, 길이가 0 이다. 비트 15:14 가 '11' 과 같다면, 비트 13:0 은 레지스터 데이터 리스트 필드에 포함된 레지스터로부터 판독된 32-비트의 레지스터 데이터 아이템의 수를 특정한다. 비트 15:14 는 현재는 '01' 으로 설정되지 않는데, 이것은 유효하지 않은 값으로 고려되며, 그렇지 않다면 장래의 지정 또는 사용을 위해 보류된다.
레지스터 어드레스 필드는 기록 또는 판독될 레지스터 어드레스를 나타내기 위해 4 바이트를 사용한다. 어드레싱이 32 비트보다 작은 레지스터에 어드레싱 하기 위해 상위 비트는 0 으로 설정된다.
2-바이트의 파라미터 CRC 필드는 패킷 길이로부터 레지스터 어드레스까지의 모든 바이트의 CRC 를 포함한다. 이러한 CRC 가 확인을 실패하면, 전체 패킷이 폐기된다.
레지스터 데이터 리스트 필드는 클라이언트 레지스터에 기록될 4-바이트 레지스터 데이터 값 또는 클라이언트 장치 레지스터로부터 판독된 값의 리스트를 포함한다.
2-바이트 레지스터 데이터 CRC 필드는 단지 레지스터 데이터 리스트만의 CRC 를 포함한다. 이러한 CRC 가 확인을 실패하면, 레지스터 데이터는 여전히 사용될 수도 있지만, CRC 오류 카운트는 증가한다.
D. 패킷 CRC
CRC 필드는 패킷의 끝에, 그리고 가끔은 매우 큰 데이터 필드를 가질 수 있는, 따라서 전송 동안 오류 발생 가능성이 높은 패킷 내의 특정 중요 파라미터 뒤에 나타난다. 2 개의 CRC 필드를 갖는 패킷에서, CRC 생성기는, 하나만 이용되는 때에, 제 1 CRC 후에 재 초기화되어 긴 데이터 필드에 후속하는 CRC 계산이 패킷 시작에서의 파라미터에 의해 영향을 받지 않는다.
패킷이 다수의 비트 오류를 포함하면서 양호한 CRC 를 생성할 미세한 가능성이 존재한다. 오류를 갖는 패킷 상에서 양호한 CRC 를 검출할 확률은 다수의 오류를 포함하는 매우 긴 패킷에서 7.6×10-6 에 근접한다. 설계에 의해, MDDI 링크는 매우 낮거나 0 인 오류 레이트를 가질 것이다. CRC 는 링크의 안정성을 모니터링하는데 사용되도록 의도되는 것이며, 패킷이 재전송되어야 하는지 여부를 결정하기 위해 특정 패킷 상의 오류를 검출하도록 의도되는 것은 아니다.
예시적인 실시형태에서, CRC 계산을 위해 이용되는 다항식은 CRC-16, 또는 X16 + X15 + X2 +X0 로 알려진다. 본 발명의 구현에 유용한 CRC 생성기 및 체커 (3600) 의 샘플 구현이 도 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 에 도달할 때까지 계속된다.
예를 들어, 클라이언트 요청 및 상태 패킷에 대한 패킷 컨텐츠가: 0x000c, 0x0046, 0x000, 0x0400, 0x00, 0x00, 0x0000 (또는, 0x0c, 0x00, 0x46, 0x00, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, 0x00 과 같은 바이트의 시퀀스로서 나타내어짐) 이며, 멀티플렉서 (3604 및 3606), 및 낸드 게이트 (3608) 의 입력을 이용하여 제출된다면, Tx_MDDI_Data_With_CRC 라인 상의 결과적인 CRC 출력은 0xd9aa (또는 0xaa, 0xd9 와 같은 시퀀스로 나타내어짐) 이다.
CRC 생성기 및 체커 (3600) 가 CRC 체커 로서 구성될 때, Rx_MDDI_Data 라인상에서 수신된 CRC 는 멀티플렉서 (3604) 및 익스클루시브-OR (XOR) 게이트 (3612) 에 입력되고, NOR 게이트 (3610), AND 게이트 (3608) 및 AND 게이트 (3614) 를 이용하여 CRC 레지스터에서 발견된 값과 비트 단위로 비교된다. 여하한 오류가 있으면, AND 게이트 (3614) 에서 출력될 때, 게이트 (3614) 의 출력을 레지스터 (3602) 의 입력으로 연결함으로써 CRC 는 CRC 오류를 포함하는 매 패킷에 대하여 한번씩 증가된다. 도 36 의 다이어그램에 도시된 예시 회로는 주어진 CHECK_CRC_NOW 윈도우 내에서 2 이상의 CRC 오류 신호를 출력할 수 있음을 유의하라 (도 37b 참조). 따라서, 일반적으로, CRC 오류 카운터는 일반적으로 CHECK_CRC_NOW 가 활성화된 각각의 간격 내에서 첫 번째 CRC 오류 인스턴스만을 카운팅한다. CRC 생성기로서 구성되면, CRC 는 패킷의 끝과 일치하는 시간에 CRC 레지스터에 기록 (clock out) 된다.
입출력 신호 및 인에이블 신호에 대한 타이밍은 도 37a 및 도 37b 에 도시된다. CRC 의 발생과 데이터 패킷의 송신이, Gen_Reset, Check_CRC_Now, Generate_CRC_Now, 및 Sending_MDDI_Data 신호의 상태 (0 또는 1) 로, Tx_MDDI_Data_Before_CRC 및 Tx_MDDI_Data_With_CRC 신호와 함께, 도 37a 에 도시된다. 데이터 패킷의 수신과 CRC 값의 확인은, Gen_Reset, Check_CRC_Now, Generate_CRC_Now, 및 Sending_MDDI_Data 신호의 상태로, Rx_MDDI_Data 및 CRC 오류 신호와 함께, 도 37b 에 도시된다.
E. 패킷 CRC 에 대한 오류 코드 오버로드
호스트와 클라이언트 사이에 데이터 패킷과 CRC 만이 송신될 때마다, 수용되고 있는 오류 코드는 없다. 유일한 오류는 동기화의 손실이다. 그렇지 않으면, 양호한 데이터 전송 경로 또는 파이프라인의 부족으로부터 링크가 타임아웃되기를 기다려야 하고, 그 후 링크를 리셋하고 진행하여야 한다. 불행히도, 이는 시간 소모적이고 다소 비효율적이다.
일 실시형태에서 이용하기 위해, 패킷의 CRC부분이 오류 코드 정보를 전송하는데 이용되는 새로운 기법이 개발되었다. 이는 도 65 에 일반적으로 도시된다. 즉, 통신 프로세싱 또는 링크 내에서 발생할 수 있는 특정의 미리 정의된 오류 또는 결함을 나타내는 데이터 전송을 취급하는 프로세서 또는 장치에 의해 하나 이상의 오류 코드들이 발생된다. 오류가 발생하면, 적절한 오류 코드가 발생되고 패킷의 CRC 를 위한 비트를 이용하여 전송된다. 즉, 희망 오류 코드로 CRC 값이 오버로드 (overload) 또는 오버라이트 (overwrite) 되고, 이는 CRC 필드의 값을 모니터하는 오류 모니터 또는 체커에 의해 수신단에서 검출될 수 있다. 어떠한 이유로 CRC 값이 오류 코드와 합치하는 경우, 오류의 컴플리먼트 (compliment) 가 전송되어 혼동을 방지한다.
일 실시형태에서, 로버스트한 오류 경고 및 검출 시스템을 제공하기 위해, 오류가 검출된 후에 전달 또는 전송되는 일련의 패킷, 일반적으로는 전부를 이용하여, 오류 코드가 수차례 전송될 수 있다. 이는 시스템으로부터 오류를 발생시키는 조건이 제거되는 포인트까지 발생하며, 당해 포인트에서 다른 값에 의해 오버로딩됨이 없이 정규 CRC 비트가 전송된다.
CRC 값을 오버로딩하는 이 기법은, 여분 비트 또는 필드의 최소량을 이용하면서, 시스템 오류에 대한 휠씬 빠른 응답을 제공한다.
도 66 에 도시된 바와 같이, 이전에 기술되거나 공지된 다른 회로의 부분을 구성할 수 있는 오류 검출기 또는 검출 수단 (6602)을 사용하여 CRC 오버라이팅 메커니즘 또는 장치 (6600) 가 도시되며, 통신 링크 또는 프로세스 내 오류의 발생 또는 존재를 검출한다. 미리 선택된 오류 메시지를 저장하기 위해 참조표 (look up table) 와 같은 기법을 이용하거나 다른 회로의 일부로 형성될 수 있는 오류 코드 생성기 또는 수단 (6604) 은, 하나 이상의 오류 코드를 발생시켜 발생 시에 검출된 특정의 소정의 오류 또는 결함들을 나타낸다. 장치 (6602 및 6604) 는 요구에 따라 단일 회로 또는 장치로, 또는 다른 공지의 프로세서 또는 엘리먼트에 대한 프로그램된 단계들의 시퀀스의 일부로서 형성될 수 있음을 용이하게 인식할 수 있을 것이다.
선택된 오류 코드 또는 코드들이 전송되고 있는 CRC 값과 동일한지 알기 위한 확인을 위한 CRC 값 비교기 또는 비교 수단 (6606) 이 도시된다. 이러한 경우라면, 원래의 CRC 패턴 또는 값으로 오해되지 않고 검출 방식을 혼동시키거나 복잡하게 하지 않도록, 오류 코드의 컴플리먼트를 제공하기 위해 코드 컴플리먼트 생성기 또는 생성 수단 또는 장치가 사용된다. 그러면, 오류 코드 선택기 또는 선택 수단 엘리먼트 또는 장치 (6610) 는 삽입 또는 오버라이트를 희망하는 오류 코드 또는 값, 또는 그들 각각의 컴플리먼트를 적절하게 선택한다. 오류 코드 CRC 오버라이터 또는 오버라이팅 메커니즘 또는 수단 (6612) 은, 수신 장치에 소망의 오류 코드를 전송하기 위하여, 삽입될 데이터 스트림, 패킷, 및 소망의 코드를 수신하여 대응되거나 적절한 CRC 값을 오버라이트하는 장치이다.
언급된 바와 같이, 일련의 패킷을 이용하여 오류 코드는 수차례 전송될 수 있으며, 따라서 오버라이터 (6612) 는, 필요한 만큼 또는 요구되는 만큼 그들의 값을 저장 또는 보유하는데 이용될 수 있는 공지의 저장 위치 또는 이전의 엘리먼트로부터 리콜하거나 프로세스 동안에 코드들의 카피를 유지하기 위하여, 메모리 저장 엘리먼트를 이용할 수도 있다.
도 66 의 오버라이팅 메커니즘의 일반적 프로세싱 구현의 추가적 세부사항이 도 67a 및 67b 에 도시된다. 도 67a에서, 하나 이상의 오류가 통신 데이터 또는 프로세스의 단계 (6702) 에서 검출되고, 이 조건을 나타내기 위하여 단계 (6704) 에서 오류코드가 선택된다. 동시에, 또는 적절한 시점에서, 대체될 CRC 값이 단계 (6706) 에서 확인되고, 단계 (6708) 에서 희망 오류 코드와 비교된다. 이러한 비교의 결과는, 전에 언급된 바와 같이, 소망의 코드 또는 다른 대표적인 값이 현재 CRC 값과 동일한지 아닌지에 대한 결정이다. 만약 그렇다면, 프로세싱은 단계 (6712) 로 진행되어, 요구되는 바에 따라 컴플리먼트, 또는 어떤 상황에서는 다른 대표적인 값이 삽입될 코드로서 선택된다. 단계 (6710) 또는 (6714) 에서 어떤 오류 코드 또는 값이 삽입될지 결정되면, 그 적절한 코드는 삽입을 위해 선택된다. 이러한 단계들은 명확성을 위해 별개로 도시되지만, 일반적으로 단계 (6708) 결정의 출력에 기초한 단일 선택을 나타낸다. 마지막으로, 단계 (6716) 에서, 전송을 위한 CRC 위치에서 적절한 값이 프로세스에 의해 타겟이 되는 패킷들로 오버라이팅된다.
도 67b 에 나타난 바와 같이, 단계 (6722) 에서 패킷 수신측에서 패킷 CRC 값이 모니터링되고 있다. 일반적으로, 데이터 전송에서 오류가 발생하였는지 여부 및 패킷 또는 패킷들의 재전송을 요구할지 또는 더 이상의 동작을 금지할지 등을 결정하기 위해 시스템 내에서 하나 이상의 프로세스에 의해서 CRC 값이 모니터링되고 있으며, 이들 중 일부는 상술하였다. 그러한 모니터링의 일부로서, 값을 공지의 또는 미리 선택된 오류 코드 또는 대표 값과 비교하고 오류의 존재를 검출하는데 그 정보가 기록될 수도 있다. 다르게는, 별개의 오류 검출 프로세스 및 모니터가 구현될 수 있다. 코드가 존재하는 것으로 나타나면, 단계 (6724) 에서 추가적인 처리를 위해 추출되거나 다른 방식으로 기록된다. 단계 (6726) 에서 이것이 실제 코드 또는 컴플리먼트인지 여부를 결정할 수 있고, 이 경우 추가적인 단계 (6728) 가 그 값을 소망의 코드값으로 변환하는데 이용된다. 어떤 경우에도, 그 후 결과적인 추출된 코드, 컴플리먼트, 또는 기타 복구된 값들이 단계 (6730) 에서 전송된 코드로부터 어떤 오류가 발생했는지 검출하는데 사용된다.
V. 링크 휴지
MDDI 링크는 휴지상태로 신속히 진입할 수 있고 휴지로부터 신속히 웨이크 업 할 수 있다. 사용을 위해 매우 신속히 다시 웨이크 업 할 수 있으므로, 이러한 응답성은 통신 시스템 또는 장치가 MDDI 링크를 자주 휴지상태로 진입하게 함으로써 전력 소비를 감소시킬 수 있게 한다. 일 실시형태에서, 외부 모드로서 클라이언트는 최초 휴지로부터 웨이크 업 (wake up) 하며, 1 Mbps 와 일치하는 스트로브 펄스 타이밍에 따라 데이터 레이트로 휴지로부터 웨이크 업 하는데, 즉 MDDI_Stb 쌍은 500kHz 레이트로 토글링해야 한다. 클라이언트의 특성이 일단 호스트에 의해 발견되거나 호스트와 통신하게 된다면, 호스트는 일반적으로 클라이언트가 동작할 수 있는 1 Mbps 로부터 최대 레이트에 이르는 임의의 레이트에서 링크를 웨이크 업 할 수 있다. 내부 모드 클라이언트는 호스트 및 클라이언트 양자가 동작할 수 있는 임의의 레이트에서 웨이크 업 할 수 있다. 또한, 이것은 일반적으로 내부 모드 클라이언트가 웨이크 업 하는 최초 시점에도 적용될 수 있다.
일 실시형태에서, 링크가 휴지로부터 웨이크 업하는 때에 호스트 및 클라이언트는 펄스의 시퀀스를 교환한다. 이들 펄스는 최대 링크 동작 속도에서 신호를 수신하는데 요구되는 차동 수신기로서, 전류의 일부만을 소비하는 저속 라인 수신기를 이용하여 검출될 수 있다. 호스트 또는 클라이언트가 링크를 웨이크-업 할 수 있으므로, 웨이크-업 (wake-up) 프로토콜은 호스트 및 클라이언트가 동시에 웨이크-업 하려고 시도한다면 발생할 수 있는 가능한 회선 경합 (contention) 을 다루도록 설계된다.
휴지상태 동안 MDDI_Data 및 MDDI_Stb 차동 드라이버는 고 임피던스 상태에서 디스에이블되고, 링크가 휴지 상태거나 휴지 상태에 존재하는 동안 모든 차동 쌍의 차동 전압은 0 볼트이다. 휴지로부터의 웨이크-업 동안 펄스의 시퀀스를 검출하는데 이용되는 차동 라인 수신기는 의도적인 전압 오프셋을 갖는다. 일 실시형태에서, 이러한 수신기의 로직 1 과 로직 0 사이의 문턱값은 약 125 mV 이다. 이것은 링크 웨이크-업 시퀀스 동안 비구동 (un-driven) 차동 쌍이 로직 0 으로 보이도록 한다. 그러나, 당업자가 이해하는 바와 같이, 차동 드라이버에 의해 구동되는 정규의 로직 1 레벨은 125 mV 오프셋을 갖는 차동 수신기에 의해 여전히 로직 1 레벨로 해석된다. 0 입력 오프셋을 갖는 표준 차동 수신기에 대해 125 mV 오프셋을 갖는 특정 저전력 차동 수신기의 동작의 일 예가 도 38 에 도시되어 있다. 이 파형은 통상적인 MDDI 신호를 나타내지는 않으며, 본 명세서에서는 2 타입의 차동 수신기 사이의 차이를 명백하게 하거나 설명하기 위해 제공된다.
휴지상태로 진입하기 위하여, 호스트는 링크 셧다운 패킷의 CRC 후 64 MDDI_Stb 사이클을 전송한다. 호스트는 CRC 후 (출력 디스에이블 전파 지연을 포함하는) 16 내지 56 MDDI_Stb 사이클 범위의 호스트의 MDDI_DATA0 출력을 디스에이블한다. 호스트는 웨이크-업 시퀀스를 개시하기 전에, 링크 셧다운 패킷의 CRC 후 64 MDDI_Stb 사이클을 전송하는 것을 종료한다. 일 실시형태에서, 호스트가 개시한 웨이크-업은 MDDI_Stb 상에서 펄스를 구동하기 전에, MDDI_Data0 가 유효한 로직 1 레벨에 도달한 후 적어도 100 nsec 을 기다려야 하는 호스트로서 규정된다. 일 실시형태에서, 클라이언트는, 호스트를 웨이크-업하려고 MDDI_Data0 를 로직 1 레벨로 구동하기 전에, 링크 셧다운 패킷의 CRC 후 적어도 60 MDDI_Stb 사이클을 대기한다.
휴지상태로부터 "웨이크-업" 하기 위해, 몇몇 동작 또는 프로세스가 수행된다. 클라이언트, 여기서는 디스플레이가 호스트로부터의 데이터 또는 통신, 서비스를 필요로 하는 경우에, 소망에 따라 다른 주기가 사용될 수 있지만, MDDI_Stb 가 비활성인 동안 클라이언트는 MDDI_Data0 라인을 약 70 내지 1000 μsec 동안 로직 1 상태로 구동하고, MDDI_Stb 가 활성이 된 후 MDDI_Data0 를 약 70 MDDI_Stb 사이클 (60 내지 80 의 범위) 동안 로직 0 레벨로 구동되도록 유지하여 요청 펄스를 생성한다. 그 후, 클라이언트는 MDDI_Data0 드라이버를 고-임피던스 상태에 둠으로써 디스에이블시킨다.
MDDI_Stb 가 휴지동안 활성인 경우, 비록 가능성은 낮지만, 클라이언트는 단지 MDDI_Data0 만을 대략 70 MDDI_Stb 사이클 (60 내지 80 의 범위에서) 동안 로직 1 상태로 구동할 수도 있다. 이 동작은 호스트로 하여금 순방향 링크 (208) 상에서 데이터 트래픽을 시작 또는 재시작하고 그 상태에 대해 클라이언트를 폴링하게 한다.
호스트는 (+125 mV 오프셋을 갖는 저전력 차동 수신기를 사용하여) 요청 펄스의 존재를 검출해야만 하고, 우선 MDDI_Stb 를 로직 0 레벨로 구동하고 적어도 약 100 nsec 동안 MDDI_Data0 를 로직 하이 (high) 레벨로 구동하는 개시 시퀀스를 시작하여야 한다. 그 후에, MDDI_Stb 를 토글링하는 동안, 계속하여 MDDI_Data0 를 로직 1 레벨로 대략 150 MDDI_Stb 사이클 (140 내지 160 의 범위에서) 동안 구동하고, 로직 0 으로 대략 50 MDDI_Stb 사이클 (40 내지 60 의 범위에서) 동안 구동한다. 로직 1 상태에 있는 MDDI_Data0 를 80 MDDI_Stb 사이클보다 오래 검출한다면, 클라이언트는 서비스 요청 펄스를 전송하여서는 안된다. 클라이언트가 60 내지 80 MDDI_Stb 사이클 동안 MDDI_Data0 을 로직 0 레벨에서 검출하는 경우, 호스트가 MDDI_Data0 을 로직 0 레벨로 50 MDDI_Stb 사이클 동안 구동하는 인터벌의 탐색을 시작한다. 호스트가 MDDI_Datat0 를 로직 0 레벨로 50 MDDI_Stb 사이클 동안 구동한 후에, 호스트는 링크를 통하여 패킷을 전송하는 것을 개시한다. 전송되는 첫 번째 패킷은 서브 프레임 헤더 패킷이다. 클라이언트는 MDDI_Data0 이 50 사이클 간격의 40 MDDI_Stb 사이클 동안 로직 0 레벨인 후에 서브 프레임 헤더 패킷의 탐색을 시작한다. 휴지 프로세싱 및 개시 시퀀스에 관계된 시간 및 시간 간격의 허용 오차의 선택의 특징을 이하 설명한다 (이하의 도 68a 내지 도 68c 참조).
호스트는 먼저 MDDI_Stb 를 인에이블 함으로써 웨이크-업을 개시하고, 동시에 이를 로직 0 레벨로 구동할 수 있다. MDDI_Stb 는 이하 설명하는 바와 같이 펄스가 출력될 때까지 로직 1 레벨로 구동되어서는 안 된다. MDDI_Stb 가 로직 0 레벨에 도달한 후에, 호스트는 MDDI_Data0 를 인에이블시키고, 동시에 이를 로직 1 레벨로 구동한다. MDDI_Data0 는, 후술하는 바와 같이 50 MDDI_Stb 펄스의 간격 동안 로직 0 레벨로 구동되는 간격까지 웨이크 업 프로세스 동안 로직 0 레벨로 구동되지 않아야 한다. 호스트는 MDDI_Stb 상의 펄스 구동 전에, MDDI_Data0 가 유효한 로직 1 레벨에 도달한 후 200 nsec 이상을 대기하여야 한다. 최악의 경우의 출력 인에이블 지연을 고려하는 동안, 이러한 타이밍 관계가 발생한다. 이것은 호스트에 의해 구동되는 MDDI_Data0 상의 로직 1 레벨에 의해 웨이크 업 된 이후에 그 MDDI_Stb 수신기를 완전히 인에이블하기에 충분한 시간을 갖는 것을 실질적으로 보장한다.
회선 쟁탈이 없는 통상적인 클라이언트 서비스 요청 이벤트 (3800) 에 대한 프로세싱 단계의 예시가 도 38a 에 도시되며, 여기서 이벤트는 편의상 A, B, C, D, E, F, 및 G 의 문자로 표시된다. 프로세스는, 호스트가 클라이언트로 링크 셧다운 패킷을 보내어 링크가 저전력 휴지상태로 천이 (transition) 됨을 알리는 포인트 A 에서 시작한다. 다음 단계에서, 포인트 B 에 나타난 바와 같이, MDDI_Data0 드라이버를 디스에이블하고 MDDI_Stb 드라이버를 로직 0 레벨로 설정함으로써 호스트는 저전력 휴지상태에 진입한다. MDDI_Data0 은 고임피던스 바이어스 네트워크에 의해 로직 0 레벨로 구동된다. 약간의 시간 기간 후에, 포인트 C 에 나타난 바와 같이 MDDI_Data0 을 로직 1 로 구동함으로써 클라이언트는 서비스 요청을 호스트에 보낸다. 고 임피던스 바이어스 네트워크를 이용하여 호스트는 계속 로직 0 레벨을 어서트 (assert) 하지만, 클라이언트의 드라이버는 라인을 로직 1 레벨로 강제한다. 50 ㎲ 내에, 호스트는 서비스 요청 펄스를 인식하고, 포인트 D 에서 볼 수 있는 바와 같이 그 드라이버를 인에이블하여 MDDI_Data0 에 로직 1 레벨을 어서트한다. 포인트 E 에 나타난 바와 같이, 그러면 클라이언트는 서비스 요청 펄스를 어서트하려는 시도를 중단하고, 클라이언트는 그 드라이버를 고임피던스 상태에 위치시킨다. 포인트 F 에 나타난 바와 같이, 호스트는 MDDI_Data0 을 로직 0 레벨로 50 ㎲ 동안 구동하고, 또한 MDDI_Data0 상의 로직 0 레벨과 일치하는 방식으로 MDDI_Stb 를 발생시키기 시작한다. 클라이언트는 MDDI_Data0 이 40 MDDI_Stb 사이클 동안 로직 0 레벨에 있은 후, 서브 프레임 헤더 패킷을 탐색하기 시작한다. MDDI_Data0 을 로직 0 레벨로 어서트하고 MDDI_Stb 를 50 ㎲ 동안 구동한 후에, 포인트 G 에 나타난 바와 같이, 호스트는 서브 프레임 헤더 패킷을 전송함으로써 순방향 링크에서 데이터를 송신하기 시작한다.
링크 재시작 시퀀스가 시작된 후 서비스 요청이 어서트 되는 유사한 예가 도 39b 에 도시되며, 역시 이벤트는 문자 A, B, C, D, E, F, 및 G 로 표시된다. 이는, 클라이언트로부터의 요청 펄스 또는 신호가 서브 프레임 헤더 패킷의 손상 (corrupting) 에 가장 근접하는 최악의 경우 시나리오를 나타낸다. 링크가 저전력 휴지상태로 천이하리라는 것을 알리기 위해 호스트가 링크 셧다운 패킷을 클라이언트 장치에 다시 전송하는 포인트 A 에서 프로세스가 시작한다. 다음 단계에서, 포인트 B 에 나타난 바와 같이, MDDI_Data0 드라이버를 디스에이블하고 MDDI_Stb 드라이버를 로직 0 레벨로 설정함으로써 호스트는 저전력 휴지상태에 진입한다. 전과 같이, 고 임피던스 바이어스 네트워크에 의해 MDDI_Data0 은 로직 0 레벨로 구동된다. 시간 기간 후에, 포인트 C 에 나타난 바와 같이, MDDI_Data0 을 150 ㎲ 동안 로직 1 레벨로 구동함으로써 호스트는 링크 재시작 시퀀스를 시작한다. 포인트 D 에서 볼 수 있는 바와 같이, 링크 재시작 시퀀스가 시작한 후 50 ㎲ 경과 전에, 디스플레이는 70 ㎲ 기간 동안 MDDI_Data0 을 어서트 한다. 이는, 디스플레이가 호스트로부터 서비스를 요청할 필요가 있으며 호스트가 이미 링크 재시작 시퀀스를 시작했음을 인식하지 못하기 때문에 발생한다. 그러면, 포인트 E 에 나타난 바와 같이, 클라이언트는 서비스 요청 펄스를 어서트 하려는 시도를 중단하며, 클라이언트는 그 드라이버를 고 임피던스 상태로 위치시킨다. 호스트는 계속해서 MDDI_Data0 을 로직 1 레벨로 구동한다. 포인트 F 에 나타난 바와 같이, 호스트는 MDDI_Data0 을 50 ㎲ 동안 로직 0 레벨로 구동하며, 또한 MDDI_Data0 상의 로직 0 레벨과 일치하는 방식으로 MDDI_Stb 를 발생시키기 시작한다. MDDI_Data0 을 로직 0 레벨로 어서트 하고 MDDI_Stb 를 50 ㎲ 동안 구동한 후에, 포인트 G 에 나타난 바와 같이, 서브 프레임 헤더 패킷을 전송함으로써 호스트는 순방향 링크로 데이터를 전송하기 시작한다.
전술한 바로부터, 관련된 이전의 솔루션은 호스트로 하여금 웨이크 업 시퀀스의 일부로서 2 개의 상태를 거치게 함을 알 수 있다. 제 1 상태에 대하여, 호스트는 150 ㎲ 동안 MDDI_Data0 신호를 하이 (high) 로 구동하고, 그 후 MDDI_Stb 라인을 활성화시키는 동안 MDDI_Data0 신호를 50 ㎲ 동안 로우 (low) 로 구동하고, 그 후 MDDI 패킷을 송신하기 시작한다. 이 프로세스는, MDDI 장치 및 방법을 이용하여 달성가능한 데이터 레이트의 관점에서 기술 수준을 진보시키는 데에는 잘 동작한다. 그러나, 전술한 바와 같이, 조건에 대한 응답 시간 감소의 관점에서의, 또는 다음 단계 또는 프로세스를 더 빨리 선택할 수 있는 더 나은 속도는 프로세스 또는 엘리먼트를 단순화하는 능력이며, 항상 요구되는 것이다.
출원인들은, 호스트가 신호 토글링에 대한 타이밍에 기초한 클록 사이클을 이용하는 웨이크 업 프로세스 및 타이밍에 대한 새롭고 개선된 접근 방법을 찾아냈다. 이 구성에서, 웨이크 업 시퀀스의 시작에서 호스트가 MDDI_Data0 신호를 하이로 구동하고 0 내지 10 ㎲ 후에 호스트는 MDDI_Stb 의 토글링을 시작하며, 신호가 로우로 구동될 때까지 기다리지 않는다. MDDI_Data0 신호가 항상 로직 0 레벨에 있는 것처럼, 웨이크 업 시퀀스 동안에, 호스트는 MDDI_Stb 를 토글링한다. 이는 효율적으로 클라이언트 측으로부터의 시간 개념을 제거하며, 이 기간 동안 호스트는 최초의 2 개의 상태에 대하여 이전의 150 ㎲ 및 50 ㎲ 기간으로부터, 이들 기간에 대해 150 클록 사이클 및 50 클록 사이클로 변화한다.
이제 호스트는, 그 데이터 라인을 하이로 구동하고, 데이터 라인이 0 인 것처럼 10 클록 사이클 내에 스트로브 신호 전송을 시작하는 책임을 지게 된다. 호스트가 150 클록 사이클 동안 데이터 라인을 하이로 구동한 후에, 호스트는 스트로브 신호를 계속 전송하면서 데이터 라인을 50 클록 사이클 동안 로우로 구동한다. 이들 프로세스를 모두 완료한 후에, 호스트는 제 1 서브 프레임 헤더 패킷을 송신하기 시작한다.
클라이언트 측에서, 클라이언트 구현은 이제, 데이터 라인이 먼저 하이 그 다음에 로우인 클록 사이클의 수를 계산하는데 발생된 클록을 이용할 수 있다. 하이 상태로 구동되는 데이터 라인 모두에서 발생될 필요가 있는 클록 사이클 수는 150 이고, 로우 상태로 구동되는 데이터 라인은 50 이다. 이는 적절한 웨이크 업 시퀀스에 대하여, 클라이언트는 데이터 라인이 로우인 적어도 50 개의 연속적인 클록 사이클이 후속하는, 데이터 라인이 하이인 적어도 150 개의 연속적인 클록 사이클을 카운팅할 수 있어야 한다는 것을 의미한다. 이러한 두 개의 조건이 충족되면, 클라이언트는 제 1 서브프레임의 고유 워드에 대한 탐색을 시작할 수 있다. 이 패턴에서의 브레이크 (break) 는 클라이언트가 다시 처음의 150 개의 데이터 라인이 하이인 연속적인 클록 사이클을 찾는 초기 상태로 카운터를 회복하기 위한 기초로서 이용된다.
전술한 바와 같이, 휴지로부터의 호스트 기반 웨이크 업을 위한 본 발명의 클라이언트 구현은, 클록 레이트가 1 Mbps 에서 시작하도록 강제되지 않는다는 점을 제외하고는 초기 시작의 경우와 매우 유사하다. 대신에, 통신 링크가 휴지로 진입할 때 클록 레이트는 활성이었던 이전의 여하한 레이트에서 재개되도록 설정될 수 있다. 전술한 바와 같이 호스트가 스트로브 신호의 전송을 시작하면, 클라이언트는 데이터 라인이 로우인 적어도 50 개의 연속적인 클록 사이클이 후속하는 데이터 라인이 하이인 적어도 150 개의 연속적인 클록 사이클을 카운팅할 수 있어야 한다. 이러한 두 개의 조건이 충족되면, 클라이언트는 고유 워드의 검색을 시작할 수 있다.
휴지로부터의 클라이언트 기반 웨이크 업을 위한 본 발명의 클라이언트 구현은, 클라이언트로 하여금 데이터 라인을 구동하게 함으로써 시작한다는 점을 제외하고는 호스트 기반의 웨이크 업과 유사하다. 클라이언트는, 호스트 장치를 웨이크 업하기 위한 클록 없이 비동기적으로 데이터 라인을 구동할 수 있다. 일단 데이터 라인이 클라이언트에 의해 하이로 구동된다는 것을 호스트가 인식하면, 그 웨이크 업 시퀀스가 시작될 수 있다. 클라이언트는 호스트 시작에 의해 또는 웨이크 업 프로세스 중에 발생된 클록 사이클의 수를 카운팅할 수 있다. 일단 클라이언트가 데이터가 하이인 70 개의 연속적인 클록 사이클을 카운팅하면, 데이터 라인을 하이로 구동하는 것을 멈출 수 있다. 이 시점에서, 호스트도 이미 데이터 라인을 하이로 구동하고 있어야 한다. 그 후 클라이언트는 데이터가 하이인 80 개의 연속적인 클록 사이클을 카운팅하여 데이터 라인이 하이인 150 개의 클록 사이클에 도달할 수 있으며, 그 후에 데이터 라인이 로우인 50 개의 클록 사이클을 탐색할 수 있다. 이러한 세 개의 조건이 충족되면, 클라이언트는 고유 워드 탐색을 시작할 수 있다.
웨이크 업 처리의 이러한 새로운 구현의 장점은 시간 측정 장치에 대한 요구를 제거한다는 점이다. 이것이 오실레이터이든, 또는 커패시터 방전 회로이든, 기타 공지의 장치이던, 클라이언트는 더 이상 시작 조건을 결정하기 위해 그러한 외부 장치를 필요로 하지 않는다. 이는 클라이언트 장치 보드에 제어기, 카운터 등을 구현할 때 비용과 회로 영역을 절약한다. 이것이 클라이언트에게 이익이 되지 않을 수도 있으나, 호스트에 대하여서는, 이 기술은 코어 회로에 사용되고 있는 초고밀도 로직 (VHDL) 의 관점에서 호스트를 잠재적으로 단순화하기도 한다. 코어 소자가 호스트 기반의 웨이크 업을 기다리기 위해 외부 회로를 운영되고 있을 필요가 없을 것이므로, 웨이크 업 통지 및 측정 소스로서의 데이터 및 스트로브 라인 이용의 전력 소비도 낮아질 것이다. 이용된 사이클 수나 클록 주기는 예시적인 것이며, 당업자에게 명백한 바와 같이 다른 기간이 이용될 수 있다.
웨이크 업 처리의 이러한 새로운 구현의 장점은 시간 측정 장치에 대한 요구를 제거한다는 점이다. 이것이 오실레이터이든, 또는 커패시터 방전 회로이든, 기타 공지의 장치이던, 클라이언트는 더 이상 시작 조건을 결정하기 위해 그러한 외부 장치를 필요로 하지 않는다. 이는 클라이언트 장치 보드에 제어기, 카운터 등을 구현할 때 비용과 회로 영역을 절약한다. 이것이 클라이언트에게 이익이 되지 않을 수도 있으나, 호스트에 대하여서는, 이 기술은 코어 회로에 사용되고 있는 VHDL 의 관점에서 호스트를 잠재적으로 단순화하기도 한다. 코어 소자가 호스트 기반의 웨이크 업을 기다리기 위해 외부 회로를 운영하여가 운영될 필요가 없을 것이므로, 웨이크 업 통지 및 측정 소스로서의 데이터 및 스트로브 라인 이용의 전력 소비도 낮아질 것이다.
이러한 새로운 기술의 동작을 명확히 하고 설명하기 위해, MDDI_Data0, MDDI_Stb, 및 클록 사이클에 대한 다양한 동작들의 타이밍이 도 68a, 68b, 및 68c 에 도시된다.
회선 쟁탈이 없는 통상의 호스트-시작 (host-initiated) 웨이크 업에 대한 프로세싱 스텝의 예가 도 68a 에 도시되어 있으며, 역시 이벤트는 편의상 문자 A, B, C, D, E, F, 및 G 로 나타낸다. 프로세스는, 링크가 저전력 휴지상태로 천이함을 알리기 위해 호스트가 링크 셧다운 패킷을 클라이언트 장치로 전송하는 포인트 A 에서 시작한다. 다음 단계인 포인트 B 에서, 호스트는 약 64 사이클 동안 (또는 시스템 설계에서 요구되는 대로) MDDI_Stb 를 토글링하여, MDDI_Stb 의 토글링을 멈추기에 앞서 클라이언트에 의한 프로세싱이 완료될 수 있도록 하며, 이는 클라이언트 장치에서 회복된 클록을 정지한다. 또한, 호스트는 MDDI_Data0 을 로직 0 레벨로 초기에 설정하고, 그 후 CRC 후 16 내지 48 사이클 (일반적으로 출력 디스에이블 전송 지연을 포함) 의 범위에서 MDDI_Data0 출력을 디스에이블한다. CRC 후 약 48 사이클 후에 그리고 다음 스테이지 (C) 전에, 클라이언 내 MDDI_Data0 및 MDDI_Stb 에 대한 고속 수신기를 저 전력 상태로 위치시키는 것이 바람직하다. 클라이언트는, 링크 셧다운 패킷의 CRC 후 48번째 MDDI_Stb 사이클의 상승 에지 후의 임의의 시간에 MDDI_Data0 및 MDDI_Stb 에 대한 그 고속 수신기를 휴지상태로 둔다. 클라이언트가 링크 셧다운 패킷의 CRC 후 64 번째 MDDI_Stb 사이클의 상승 에지 전에 MDDI_Data0 및 MDDI_Stb 에 대한 그 고속 수신기를 휴지상태로 둘 것을 권장한다.
MDDI_Data0 및 MDDI_Stb 드라이버를 디스에이블시키고 호스트 제어기를 저전력 휴지상태로 위치시킴으로써, 포인트 또는 단계 C 에서 호스트는 저전력 휴지상태에 진입한다. MDDI_Stb 드라이버를 (고임피던스 네트워크 바이어스 네트워크를 이용하여) 로직 0 레벨로 설정하거나, 소망에 따라 휴지 동안에 토글링을 계속하도록 설정할 수도 있다. 클라이언트도 저전력 레벨 휴지상태에 있다.
약간의 시간 주기 후에, MDDI_Data0 및 MDDI_Stb 드라이버 출력을 인에이블함으로써 포인트 D 에서 호스트는 링크 재시작 시퀀스를 시작한다. 드라이버들이 그들 각각의 출력을 완전히 인에이블하는데 필요한 동안, 호스트는 MDDI_Data0 을 로직 1 레벨로 MDDI_Stb 를 로직 0 으로 구동한다. 통상적으로, 호스트는 이러한 출력이 원하는 로직 레벨에 도달한 후 (MDDI_Data0 은 유효 로직 1 레벨에 도달하고 MDDI_Stb 는 유효 로직 0 레벨에 도달함), MDDI_Stb 에 펄스를 구동하기 전에 약 200 나노초 동안 대기한다. 이는 클라이언트에게 MDDI_Stb 상에서 고속 펄스를 수신하기 위한 준비의 시간을 허용한다. 먼저, 클라이언트는 +125 mV 입력 오프셋 전압을 갖는 저전력 차동 수신기를 사용하여 웨이크업 펄스를 검출한다.
호스트 드라이버가 인에이블되고 MDDI_Data0 이 로직 1 레벨로 구동되면, 포인트 E 에 나타난 바와 같이, 호스트는 150 MDDI_Stb 사이클의 기간 동안 MDDI_Stb 를 토글링하기 시작한다. 포인트 F 에 나타난 바와 같이, 호스트는 MDDI_Data0 을 50 사이클 동안 로직 0 레벨로 구동하고, MDDI_Data0 이 40 MDDI_Stb 사이클 동안 로직 0 레벨에 있은 후에 클라이언트는 서브 프레임 헤더 패킷의 탐색을 시작한다. 포인트 G 에 나타난 바와 같이 호스트는 서브프레임 헤더 패킷을 전송함으로써 순방향 링크로 데이터를 전송하기 시작한다.
회선 쟁탈이 없는 통상적인 클라이언트-시작 (client-initiated) 웨이크 업에 대한 프로세싱 단계의 예가 도 68b 에 도시되며, 역시 이벤트는 편의상 문자 A, B, C, D, E, F, G, H, 및 I 를 이용하여 나타낸다. 이전과 같이, 호스트가 링크가 저전력 상태로 천이되는 것을 클라이언트에게 알리는 링크 셧다운 패킷을 전송하는 포인트 A 에서 프로세스가 시작한다.
포인트 B 에서, 호스트는 약 64 사이클 동안 (또는 시스템 설계에서 요구되는 대로) MDDI_Stb 를 토글링하여 MDDI_Stb 의 토글링을 멈추기에 앞서 클라이언트에 의한 프로세싱이 완료될 수 있도록 하며, 이는 클라이언트 장치에서 회복된 클록을 정지한다. 또한 호스트는 MDDI_Data0 을 로직 0 레벨로 초기에 설정하고, 그 후 CRC 후 16 내지 48 사이클 (일반적으로 출력 디스에이블 전송 지연을 포함) 의 범위에서 MDDI_Data0 출력을 디스에이블한다. CRC 후 약 48 사이클 후, 그리고 다음 스테이지 (C) 전에, 클라이언트 내 MDDI_Data0 및 MDDI_Stb 에 대한 고속 수신기를 저 전력 상태에 위치시키는 것이 바람직할 수 있다.
MDDI_Data0 및 MDDI_Stb 드라이버를 디스에이블시키고 호스트 제어기를 저전력 휴지상태로 위치시킴으로써, 포인트 또는 단계 C 에서 호스트는 저전력 휴지상태에 진입한다. 또한, MDDI_Stb 드라이버를 (고임피던스 네트워크 바이어스 네트워크를 이용하여) 로직 0 레벨로 설정하거나, 소망에 따라 휴지 동안에 토글링을 계속하도록 설정할 수 있다. 클라이언트도 저전력 레벨 휴지상태에 있다.
약간의 시간 주기 후에, MDDI_Stb 수신기를 인에이블하고, 또한 호스트가 그 MDDI_Stb 드라이버를 인에이블 하기 전에 MDDI_Stb 의 수신된 버전의 상태가 클라이언트에서 로직 0 레벨임을 보장하기 위해 MDDI_Stb 수신기에서 오프셋을 인에이블함으로써, 클라이언트는 포인트 D 에서 링크 재시작 시퀀스를 시작한다. 희망에 따라, 유효한 차동 신호의 수신을 보장하고 오류있는 신호를 억제하기 위해 클라이언트가 수신기의 인에이블 직전에 오프셋을 인에이블하는 것이 바람직할 것이다. 클라이언트는, MDDI_Data0 라인을 로직 1 레벨로 구동하는 동안 MDDI_Data0 드라이버를 인에이블한다. 오프셋을 인에이블하고 및 표준 MDDI_Stb 차동 수신기를 인에이블하는 시간이 200 nsec 보다 작다면 MDDI_Data0 및 MDDI_Stb 가 동시에 인에이블되는 것이 가능하다.
1 밀리초 내에, 포인트 E 에서, 호스트는 클라이언트로부터의 서비스 요청 펄스를 인식하고, 호스트는 MDDI_Data0 및 MDDI_Stb 드라이버 출력을 인에이블함으로써 링크 재시작 시퀀스를 시작한다. 드라이버가 그들 각각의 출력을 완전히 인에이블하는데 걸리는 시간 동안, 호스트는 MDDI_Data0 을 로직 1 레벨로 MDDI_Stb 를 로직 0 으로 구동한다. 통상적으로, MDDI_Stb 에 펄스를 구동하기 전에 호스트는 이들 출력이 원하는 로직 레벨에 도달한 후 약 200 나노초 정도 대기한다. 이는 클라이언트에게 수신 준비의 시간을 허용한다.
호스트 드라이버가 인에이블되고 MDDI_Data0 이 로직 1 레벨로 구동되면, 포인트 F 에 나타난 바와 같이, 호스트는 150 MDDI_Stb 사이클의 기간 동안 MDDI_Stb 에 펄스를 출력하기 시작한다. 클라이언트가 MDDI_Stb 에서 첫 번째 펄스를 인식할 때, 그 MDDI_Stb 수신기에서 오프셋을 디스에이블한다. 클라이언트는 계속해서 MDDI_Data0 을 70 MDDI_Stb 사이클 동안 로직 1 레벨로 구동하고, 포인트 G 에서 MDDI_Data0 드라이버를 디스에이블한다. 호스트는 계속해서 MDDI_Data0 을 추가적인 80 MDDI_Stb 펄스 기간 동안 로직 1 레벨로 구동하고, 포인트 H 에서 MDDI_Data0 을 로직 0 레벨로 구동한다.
포인트 G 및 H 에서 보는 바와 같이, 호스트는 50 사이클 동안 로직 0 레벨로 MDDI_Data0 을 구동하고, MDDI_Data0 이 40 MDDI_Stb 사이클 동안 로직 0 레벨에 있은 후에 클라이언트는 서브 프레임 헤더 패킷의 탐색을 시작한다. 포인트 I 에 나타난 바와 같이, MDDI_Stb 를50 사이클 기간 동안 구동한 후, 호스트는 서브 프레임 헤더 패킷을 전송함으로써 순방향 링크에서 데이터를 전송하기 시작한다.
클라이언트로부터의 회선 쟁탈이 있는, 즉 클라이언트도 링크를 웨이크 업하기를 원하는 통상적인 호스트-시작 웨이크 업에 대한 프로세싱 단계의 예가 도 68c 에 도시된다. 역시 이벤트는 편의상 문자 A, B, C, D, E, F, G, H, 및 I 를 이용하여 나타낸다. 이전과 같이, 프로세스는 링크가 저전력 상태로 천이됨을 클라이언트에게 알리기 위해 호스트가 링크 셧다운 패킷을 전송하는 포인트 A 에서 시작하고, 클라이언트에 의한 프로세싱이 완료될 수 있도록 약 64 사이클 (또는 시스템 설계에서 요구되는 바대로) 동안 MDDI_Stb 가 토글링 되는 포인트 B 로 진행하고, 다음 MDDI_Data0 및 MDDI_Stb 드라이버를 디스에이블하고 호스트 제어기를 저전력 휴지상태로 위치시킴으로써 호스트가 저전력 휴지상태에 진입하는 포인트 C 로 진행한다. 얼마간의 시간 기간 후에, 포인트 D 에서 MDDI_Data0 및 MDDI_Stb 드라이버 출력을 인에이블함으로써 호스트는 링크 재시작 시퀀스를 시작하고, 포인트 E 에 나타나는 바와 같이, 150 MDDI_Stb 사이클 기간동안 MDDI_Stb 를 토글링하기 시작한다.
포인트 E 후 70 MDDI_Stb 사이클까지에서, 여기서는 포인트 F 에서, 클라이언트는 아직 호스트가 MDDI_Data0 을 로직 1 레벨로 구동하고 있다는 것을 인식하지 못하고, 따라서 클라이언트도 MDDI_Data0 을 로직 1 레벨로 구동한다. 이는, 클라이언트가 서비스를 요청하고자 하지만 그가 통신하고자 시도하고 있는 호스트가 이미 링크 재시작 시퀀스를 시작했다는 것을 인식하지 못하기 때문에 발생한다. 포인트 G 에서, 클라이언트는 MDDI_Data0 을 구동하기를 중단하고, 그 출력을 디스에이블함으로써 그 드라이버를 고임피던스 상태에 위치시킨다. 호스트는 추가적인 80 사이클 동안 계속해서 MDDI_Data0 을 로직 1 레벨로 구동한다.
포인트 H 에 나타난 바와 같이, 호스트는 50 사이클 동안 MDDI_Data0 을 로직 0 레벨로 구동하며, MDDI_Data0 이 40 MDDI_Stb 사이클 동안 로직 0 레벨에 있은 후에 클라이언트는 서브 프레임 헤더 패킷을 찾기 시작한다. 포인트 I 에 나타난 바와 같이, 서브 프레임 헤더 패킷을 전송함으로써 호스트는 순방향 링크에서 데이터를 전송하기 시작한다.
Ⅵ. 인터페이스 전기적 사양
예시적인 실시형태에서, 영으로의 비복귀 (Non-Return-to-Zero; NRZ) 형식의 데이터는 데이터-스트로브 신호 또는 DATA-STB 형식을 이용하여 인코딩되며, 이는 클록 정보가 데이터 및 스트로브 신호에 삽입되도록 한다. 클록은 복잡한 위상 고정 (phase lock) 루프 회로 없이 복구될 수 있다. 데이터는 양방향 차동 링크를 통해 전송되며, 상술한 바와 같이 다른 콘덕터, 인쇄 배선, 또는 전송 소자들이 이용될 수 있지만, 일반적으로 유선 케이블을 이용하여 구현된다. 스트로브 신호 (STB) 는 호스트에 의해서만 구동되는 일방향 링크를 통해 전송된다. 데이터 라인 또는 신호 상에서 동일하게 유지되는 0 또는 1 의 마주하는 (back-to-back) 상태가 있는 경우에는 언제나, 스트로브 신호는 값 (0 또는 1) 을 토글링한다.
비트 "1110001011" 과 같은 데이터 시퀀스가 어떻게 DATA-STB 인코딩을 이용하여 송신되는지에 대한 예는 도 40 의 그래프 형태로 도시되어 있다. 도 40 에서, DATA 신호 (4002) 는 신호 타이밍도의 최상단 라인에 도시되어 있으며, STB 신호 (4004) 는 제 2 라인에 도시되어 있고, 각 시간은 적당하게 (공통 시작점) 정렬되어 있다. 시간이 경과함에 따라, DATA 라인 (신호) (4002) 상에 발생하는 상태 변화가 있을 때, STB 라인 (신호) (4004) 은 이전 상태를 유지하고, 이에 따라, DATA 신호의 첫 번째 '1' 상태가 STB 신호에 대한 첫 번째 'O' 상태, 그 시작 값과 상관한다. 그러나, DATA 신호의 상태, 레벨이 변하지 않는 경우, 또는 변하지 않는 때, STB 신호는, DATA 가 다른 '1' 값을 제공하는 도 40 의 경우와 같이, 반대 상태 또는 본 예에서는 '1' 로 토글링 한다. 즉, DATA 와 STB 사이에 비트 사이클당 오직 하나의 변환이 존재한다. 따라서, STB 신호는 DATA 신호가 '1' 로 유지되는 때에 이번에는 '0' 으로 다시 천이하며, DATA 신호가 '0' 으로 레벨을 변경할 때, 이 레벨 또는 값을 유지한다. DATA 신호가 '1' 에 남아있을 때, STB 신호는 반대 상태 또는 본 실시예에서 '1' 로 토글링되고, DATA 신호가 레벨 또는 값을 변경하거나 유지함에 따라 이와 같이 계속된다.
이러한 신호들이 수신되는 때, 익스클루시브 OR (XOR) 동작이 DATA 및 STB 신호에 수행되어 클록 신호 (4006) 를 생성하고, 이는 소망의 데이터 및 스트로브 신호들과 상대적 비교를 위해 타이밍도의 최하단에 도시된다. 호스트에서 DATA 및 STB 출력 또는 입력 데이터로부터의 신호를 생성하고, 그 후 클라이언트에서 DATA 및 STB 신호로부터 데이터를 복구 또는 재획득 (recapturing) 하는데 유용한 예시적인 회로가 도 41 에 도시된다.
DATA 상에서 발생하는 상태의 변화가 존재하면, STB 는 이전의 상태를 유지한다. 그러나, DATA 가 변화하지 않으면, STB 는 반대 상태로 토글한다. 즉, DATA 와 STB 사이에 MDDI_Data0+/- 의 경로가 존재하고, 비트 사이클당 항상 하나의 천이만 존재한다. 링크의 수신단에서는, DATA 와 STB 의 익스클루시브 OR 을 수행함으로써 클록 신호 (도 40 에서 CLK 신호) 가 생성된다. 데이터-스트로브 인코딩 신호는 데이터 및 클록을 사용하는 시스템에 비해 지연 스큐에 대해 거의 2 배의 공차가 허용되기 때문에, 데이터-스트로브 인코딩의 사용은 통상의 시스템에 대해 이점을 갖는다. MDDI_Stb+/- 에서의 스큐는, 호스트 및 클라이언트의 드라이버 및 수신기를 통한 경로 지연에서의 차이, 및 MDDI_Data0+/- 및 MDDI_Stb+/- 의 접속을 통한 지연에서의 차이에 의해 유발될 수 있다. 스큐, 및 MDDI_Data0+/- 와 MDDI_Stb+/- 경로에서의 다른 결함들에 의해 영향받는 타이밍의 정량적 분석을 이하 더 상세히 설명한다.
타입 2, 타입 3 및 타입 4 에 있어서, MDDI_Data0+/- 및 MDDI_Stb+/- 는, 비트 사이클당 하나의 천이만을 갖는 타입 1 과 동일한 방식으로 동작한다. 다른 MDDI_Data 신호는 MDDI_Data0 과 동일한 레이트 및 위상으로 데이터를 전달한다. MDDI_Data0+/- 와 MDDI_Stb+/- 의 익스클루시브 OR 로부터 생성된, 클라이언트에서 복구된 클록 또한 MDDI_Data1+/- 내지 MDDI_Data7+/- 을 샘플링하는데 사용된다.
입력 데이터로부터 DATA 및 STB 를 생성하여, DATA 및 STB 로부터 입력 데이터를 복구하는데 유용한 예시적인 회로가 도 41 에 도시되어 있다. 도 41 에서, 송신부 (4100) 는 원본 DATA 및 STB 신호들을 중간 신호 경로 (4102) 를 통해 생성 및 송신하는데 이용되는 반면, 수신부 (4120) 는 신호를 수신하고 데이터를 복구하는데 이용된다. 도 41 에 도시된 바와 같이, 호스트로부터 클라이언트로 데이터를 전송하기 위해, DATA 신호는 2 개의 D-타입플립-플롭 회로 소자들 (4104 및 4106) 로, 그 회로를 트리거하기 위한 클록 신호와 함께 입력된다. 그 후, 2 개의 플립-플롭 회로 출력들 (Q) 은 2 개의 차동 라인 드라이버들 (4108 및 4110) 을 이용하여 MDDI_Data0+, MDDI_Data0- 및 MDDI_Stb+, MDDI_StB- 신호의 차동쌍으로 각각 분리된다 (전압 모드). 3-입력 익스클루시브 NOR (XNOR) 게이트, 회로, 또는 로직 소자 (4112) 는 DATA 및 두 플립-플롭 모두의 출력을 수신하기 위해 연결되며, 제 2 플립-플롭을 위한 데이터 입력을 제공하는 출력을 생성하고, 이는 다시 MDDI_Stb+, MDDI_Stb- 신호들을 생성한다. 편의를 위해, XNOR 게이트는 스트로브를 생성하는 플립-플롭의 Q 출력을 효율적으로 반전하는 것을 나타내도록 위치한 반전 버블 (inversion bubble) 을 가진다.
도 41 의 수 신부 (4120) 에서, MDDI_Data0+, MDDI_Data0- 및 MDDI_Stb+, MDDI_Stb- 신호들은 2 개의 차동 라인 수신기들 (4122 및 4124) 각각에 의해 수신되며, 이는 차동 신호들로부터 단일 출력을 생성한다. 그 후, 증폭기들의 출력들은, 클록 신호를 생성하는 2-입력 XOR 게이트, 회로 또는 로직 소자 (4126) 의 입력들 각각으로 입력된다. 클록 신호는 지연 소자 (4132) 를 통해 DATA 신호의 지연된 버전을 수신하는 2 개의 D-타입플립-플롭 회로들 (4128 및 4130) 각각을 트리거링하는데 이용되며, 2 개의 D-타입플립-플롭 회로들 (4128 및 4130) 중 하나 (4128) 는 데이터 '0' 값을 생성하고 다른 하나 (4130) 는 데이터 '1' 값을 생성한다. 또한, 클록은 XOR 로직으로부터도 독립적인 출력을 가진다. 클록 정보가 DATA 와 STB 사이에 분산되기 때문에, 어떤 신호도 반 클록 레이트보다 빠르게 상태들 사이에서 천이하지 않는다. 클록은 DATA 및 STB 신호들의 익스클루시브 OR 프로세싱을 이용하여 재생성되기 때문에, 시스템은 클록이 단일 전용 데이터 라인을 통해 직접 송신되는 경우의 상황과 비교하여, 입력 데이터와 클록 사이의 거의 2 배의 스큐를 허용한다.
도 41 또는 도 57 에서 설명한 데이터 복구 회로의 지연 엘리먼트는, 통상의 클록 데이터 통신 링크에 통상적으로 사용되는 동기화 데이터 포획 회로보다 구현하기 더 어렵지만, 데이터 스트로브 인코딩은 지연 스큐 교정을 사용할 필요없이 거의 2 배의 데이터 레이트를 허용한다. 데이터 복구 회로의 엘리먼트의 결정적 전파 지연은 동일한 회로에서의 다른 지연에 대응하기 때문에 달성하기 용이하다. 다른 경로상의 지연보다 긴 일부 경로의 지연을 생성하면 되기 때문에, I/O 패드 회로에서의 심플 로직 엘리먼트와 같은 통상의 회로에서 구현하기 용이할 수 있다.
MDDI 데이터 쌍, MDDI_Stb+, 및 MDDI_Stb- 신호들은 차동 모드로 동작하여, 잡음의 부정적 영향으로부터의 내성을 최대화한다. 각각의 차동 쌍은 신호를 전송하는데 이용되고 있는 케이블 또는 콘덕터의 특성 임피던스로 병렬-종단된다. 일반적으로, 모든 병렬-종단은 클라이언트 장치 내에 존재한다. 이것은 순방향 트래픽 (호스트로부터 클라이언트로 전송된 데이터) 을 위한 차동 수신기 부근에 있지만, 역방향 트래픽 (클라이언트로부터 호스트로 전송된 데이터) 을 위한 케이블 또는 다른 콘덕터 또는 전송 소자의 구동 단에 존재한다. 역방향 트래픽에 대하여, 신호는 클라이언트에 의해 구동되고, 호스트에서 고 임피던스 수신기에 의해 반사되며, 클라이언트에서 종단된다. 전술한 바와 같이, 역방향 데이터 또는 역방향 링크를 통한 데이터는 케이블 내의 라운드 트립 지연의 역수보다 큰 데이터 레이트에서 전달되거나 전송될 수 있다. MDDI_Stb+ 및 MDDI_Stb- 콘덕터 또는 신호는 호스트에 의해서만 구동된다.
본 발명의 MDDI 의 일부로서 신호를 전송하기 위한 드라이버, 수신기 및 종단을 달성하기에 유용한 소자들의 예시적인 구성이 도 42a 에 도시된다. 예시적인 인터페이스는, 1 V 보다 낮은 전력 스윙 및 낮은 전력 드레인을 이용한 저전압 센싱, 여기서는 200 mV 를 이용한다. 각 신호 쌍의 드라이버는 차동 전류 출력을 갖는다. MDDI 패킷을 수신하는 동안, MDDI_Data 및 MDDI_Stb 쌍은 0 볼트의 문턱 전압을 갖는 종래의 차동 수신기를 사용한다. 휴지상태에서, 드라이버 출력은 디스에이블되고, 병렬-종단 저항은 각각의 신호 쌍의 차동 전압을 0 볼트로 만든다. 휴지 동안 MDDI_Data0 쌍에 대한 특별한 수신기는 +125 mV 의 오프셋 입력 차동 전압 문턱값을 갖는데, 이것은 휴지 라인 수신기로 하여금 구동되지 않은 신호 쌍을 로직 0 레벨로 해석하게 한다.
차동 쌍의 차동 전압은 포지티브(+) 신호의 전압에서 네거티브(-) 신호의 전압을 감산한 차이로서 정의된다. 차동 쌍 신호의 명칭은 "+" 또는 "-" 로 끝나고, 이것은 각각 쌍의 포지티브 또는 네거티브 신호를 나타낸다. 차동 쌍 장치의 출력 전류는 포지티브(+) 출력으로부터 나오는 전류로 정의된다. 차동 장치의 네거티브(-) 출력을 통과하는 전류는 크기에서는 항상 동일하지만 동일한 차동 장치의 포지티브(+) 출력을 통과하는 전류에 비해 방향이 반대이다.
본 발명의 몇몇 실시형태를 구현하는데 유용한 차동 전류 모드 드라이버의 예시적인 블록 개략도가 도 42b 에 도시되어 있다. 스위칭된 차동 출력 스테이지는 전류원을 포지티브 또는 네거티브 드라이버 출력에 라우팅한다. 0.35 V 전압원이 그라운드에 대해 측정된 출력 전압을 항상 0.35 V 이상으로 유지한다.
데이터 흐름의 방향이 (호스트에서 클라이언트 또는 클라이언트에서 호스트로) 변할 때, 때로는 호스트 또는 클라이언트가 차동 쌍의 유효한 로직-레벨을 보장하기 위해 차동 쌍을 로직 1 레벨 또는 로직 0 레벨로 동시에 구동할 수 있다. 출력 전압 범위 및 출력 사양은 동일한 로직 레벨로 구동되는 동시 구동 출력으로 여전히 만족될 것이다. 일부 시스템에서, 휴지상태 동안 그리고 링크가 휴지상태로부터 웨이크-업 하는 소정 시간에서 작은 오프셋 전압을 생성하기 위해 작은 전류를 종단된 차동 쌍으로 인가하는 것이 필요할 수 있다. 이러한 상황에서, 인에블된 오프셋-전류 바이어스 회로는 이하의 전류 레벨을 인가한다: IESD-and-Rx - 통상 IESD-and-Rx ≤ 1 μA 인 내부 ESD 다이오드 및 차동 수신기 입력; ITx-Hi-Z - 통상 ITx-Hi-Z ≤ 1 μA 인 고-임피던스 상태의 차동 드라이버 출력; Iexternal-ESD - 통상 Iexternal-ESD ≤ 3 μA 인 외부 ESD 보호 다이오드를 통한 누설.
이들 각각의 누설 전류가 도 47 에 도시된다. 풀-업 및 풀-다운 회로는 전술한 최악의 경우의 누설 조건이 모두 동시에 발생하는 때, 최소 차동 전압을 달성하여야 한다. 외부 ESD 보호 다이오드가 없는 내부 모드에서 총 누설은 ≤ 4 μA 이고, 외부 ESD 보호가 있는 외부 모드에서 ≤ 10μA 이다.
차동 라인 드라이버 및 라인 수신기의 전기적 파리미터 및 특성은 일 예시적인 실시형태에 대해 표 9a 내지 9d 에서 설명된다. 기능적으로, 드라이버는 입력상의 로직 레벨을 긍정 (positive) 출력으로 전송하고, 입력의 반전값을 부정 (negative) 출력으로 전송한다. 입력으로부터 출력까지의 지연은 차동적으로 구동되는 차동 라인에 잘 매칭된다. 대부분의 구현에서, 출력 상의 전압 스윙은 입력 상의 스윙에 비해 작고, 전력 소비 및 전자기 방출을 최소화한다. 일 실시형태에서, 0.5 V 부근의 최소 전압 스윙이 존재한다. 그러나, 당업자가 용이하게 인식할 수 있는 바와 같이, 다른 값들이 이용될 수 있으며, 본 발명자는 설계 제한에 따라 일부 실시형태에서는 더 작은 값을 고려한다.
차동 라인 수신기는 고속 전압 비교기와 동일한 특성을 가진다. 도 41 에서, 버블이 없는 입력은 긍정 입력이며, 버블을 가진 입력은 부정 입력이다. 출력은 (Vinput+) - (Vinput-) 가 0 보다 큰 경우 로직 1 이다. 이를 설명하는 다른 방식은, 로직 0 및 1 전압 레벨에서 출력이 잘린 (clipped) 매우 큰 (거의 무한의) 이득을 가진 차동 증폭기이다.
상이한 쌍들 사이의 지연된 스큐는 최고 잠재 속도로 차동 송신 시스템을 동작하기 위해 최소화되어야 한다.
Figure 112007000702303-pct00003
주의 1 : 최대 상승 및 하강 시간은, 하나의 차동 쌍에서 하나의 비트를 송신하는 간격의 30% 와 100 nsec 중 작은 값.
Figure 112007000702303-pct00004
주의 1 : 최대상승 및 하강 시간은, 하나의 차동 쌍에서 하나의 비트를 송신하는 간격의 30% 와 100 nsec 중 작은 값.
주의 2 : 클라이언트가 호스트에 데이터를 전송할 때의 전체 케이블 종단 임피던스에 영향을 미치는 TP4 에서 100 옴 차동 종단 저항과 드라이버 임피던스가 병렬이기 때문에 최소 클라이언트 드라이버 임피던스가 특정된다.
Figure 112007000702303-pct00005
Figure 112007000702303-pct00006
도 42 에서, 호스트 제어기 (4202) 및 클라이언트 또는 디스플레이 제어기 (4204) 가 통신 링크 (4206) 를 통해 패킷들을 송신하는 것으로 도시되어 있다. 호스트 제어기는 전송될 클라이언트 데이터 신호들을 수신할 뿐만 아니라 전송될 호스트 DATA 및 STB 신호를 수신하는 일련의 3 개의 드라이버 (4210, 4212 및 4214) 를 채택하는 반면, 클라이언트는 3 개의 드라이버 (4230, 4232 및 4234) 를 채용한다. 호스트 DATA (4212) 의 전송을 담당하는 드라이버는, 일반적으로 호스트로부터 클라이언트로의 전송이 요구되는 경우에 한하여 통신 링크의 활성화를 허용하도록 하기 위해 인에이블 신호 입력을 채택한다. STB 신호가 데이터 전송의 일부로서 형성되기 때문에, 그 드라이버 (4212) 에 대해서는 어떠한 부가적인 인에이블 신호도 채택되지 않는다. 클라이언트 DATA 및 STB 수신기 (4132, 4230) 각각의 입력은, 각각 이들에 걸쳐 페이싱된 (paced) 종단 임피던스 또는 저항 (4218 및 4220) 을 갖는다. 클라이언트 제어기의 드라이버 (4234) 는 클라이언트로부터 호스트로 전송되고 있는 데이터 신호를 준비하는데 이용되는데, 입력측의 드라이버 (4214) 가 데이터를 프로세싱한다.
특별한 수신기 (드라이버) (4216, 4236) 는 DATA 라인에 결합 또는 접속되고, 다른 부분에서 설명한 휴면 제어의 일부로서, 전술한 125 mV 전압을 생성 또는 사용한다. 오프셋은 휴면 라인 수신기로 하여금 인가되지 않은 신호 쌍을 로직 0 레벨로서 해석하도록 한다.
상술한 드라이버들 및 임피던스들은 별개의 소자들 또는 회로 모듈의 일부로서, 또는 비용적으로 더 효율적인 인코더 또는 디코더 솔루션으로서 동작하는 주문형 집적회로 (ASIC) 로서 형성될 수 있다.
전력이 호스트 장치로부터 클라이언트 장치 또는 디스플레이로 HOST_Pwr 및 HOST_Gnd 로 표시된 신호들을 이용하여 한 쌍의 도전체를 통해 전송되는 것을 쉽게 알 수 있다. 신호의 HOST_Gnd 부분은 기준 접지 및 클라이언트 장치를 위한 전력 공급 복귀 경로 또는 신호로서 동작한다. HOST_Pwr 신호는 호스트 장치에 의해 구동되는 클라이언트 장치 전력 공급으로서 동작한다. 예시적인 구성에서, 저전력 애플리케이션에 대하여, 클라이언트 장치는 500 mA 까지 흡수 (draw) 하는 것이 허용된다. HOST_Pwr 신호는, 호스트 장치 내에 존재하는 리튬 이온 타입 배터리 또는 배터리 팩과 같은, 그러나 이에 한정되지 않는 이동식 전력원으로부터 제공될 수 있으며, HOST_Gnd 에 대하여 3.2 내지 4.3 볼트 범위에 있다.
Ⅶ. 타이밍 특성
A. 개요
휴지상태 (서비스가 요청되거나, 희망되거나 요구되지 않는) 에 진입하고 호스트로부터의 클라이언트에 대한 서비스를 안정화하기 위해 채용되는, 호스트 또는 클라이언트 개시에 의한 단계 및 신호 레벨이 각각 도 43a, 43b, 43c 에 도시된다. 도 43a, 43b 및 43c 에서, 도시된 신호의 처음 부분은 호스트로부터 전송되고 있는 링크 셧다운 패킷을 도시하고, 데이터 라인은 그 후 고 임피던스 바이어스 회로를 이용하여 로직 0 상태로 구동된다. 드라이버가 디스에이블된 클라이언트 또는 호스트에 의해서는 데이터가 전송되고 있지 않다. MDDI_Stb 는 링크 셧다운 패킷 동안 활성이므로, MDDI_Stb 신호 라인에 대한 일련의 스트로브 펄스는 아래쪽에서 볼 수 있다. 이 패킷이 끝나면, 호스트가 바이어스 회로를 구동하고 로직을 0 으로 구동함에 따라, 로직 레벨은 0 으로 변경된다. 이는 호스트로부터의 마지막 신호 전송 또는 신호의 종료를 나타내고, 과거의 여하한 시간에서도 일어났을 수 있으며, 이전의 서비스 중단 및 서비스 개시 전의 신호 상태를 나타내기 위해 포함된다. 희망하는 경우, 그러한 신호는 단지, 이 호스트 장치에 의해 수행되어온 '알려진' 이전의 통신 없이 통신 링크를 적절한 상태로 리셋하기 위해 전송될 수 있다.
도 43a 에 도시된 바와 같이, 그리고 링크 셧다운 패킷에 대해 전술한 바와 같이, 저전력 휴지상태에서 MDDI_Data0 드라이버는 링크 셧다운 패킷 내 올 제로 필드의 마지막 비트 후 16 내지 18 번째 MDDI_Stb 사이클 또는 펄스 후에 시작하는 고 임피던스 상태로 디스에이블된다. 타입 2, 타입 3 또는 타입 4 링크에 대해 MDDI_Data1 내지 MDDI_DataPwr7 신호도 MDDI_Data0 드라이버가 디스에이블되는 것과 동시에 고 임피던스 상태로 위치된다. 올 제로 필드의 정의에서 설명한 바와 같이, MDDI_Stb 는 링크 셧다운 패킷의 CRC 필드의 MSB 후에 64 차이클 (또는 시스템 설계에 의해 요구되는 대로) 토글링하여, 클라이언트에 의한 프로세싱이 완료될수 있도록 하고, 클라이언트 제어기에서의 순차적인 셧다운을 용이하게 한다. 한 사이클은 로우에서 하이로의 (low-to-high) 천이 후 하이에서 로우로의 천이, 또는 하이에서 로우로의 천이 후 로우에서 하이로의 천이이다. 올 제로 필드가 전송된 후, 호스트의 MDDI_Stb 및 MDDI_Data0 드라이버는 디스에이블되고, 호스트는 저전력 휴지상태로 진입한다. 얼마간의 시간 기간 후, 호스트는 MDDI_Data0 및MDDI_Stb 라인 또는 드라이버 출력을 인에이블 함으로써 도 43b 및 43c 에 도시된 바와 같이 링크 재시작 시퀀스를 시작하고, 호스트 또는 클라이언트 개시 웨이크 업 요청의 일부로서 MDDI_Stb 를 토글링하기 시작한다.
도 43b 에 도시된 바와 같이, MDDI_Data0 및 MDDI_Stb 에 대한 드라이버로부터의 신호 출력이 디스에이블되고 얼마간의 시간이 지난 후, 호스트는 tstb-dagta-enbl 로 표시되는 시간 기간, 그 동안 라인은 그것이 완전히 인에이블될 때까지 로직 0 레벨로 구동되는 기간 동안 MDDI_Stb 드라이버를 인에이블하고 그 후 MDDI_Data0 드라이버를 인에이블 함으로써 서비스 또는 휴지로부터의 웨이크 업을 개시한다. 호스트는 MDDI_Data0 이 하이 또는 로직 1 레벨에 도달한 후 MDDI_Stb 를 로직 0 레벨로 유지하고, 이는 tclient-startup 으로 표시되는 시간 기간 동안 일어난다. tclient-startup 기간의 종료 후, 호스트는 MDDI_Stb 신호 또는 라인을 토글링한다. 호스트는 MDDI_Data0 라인을 하이, 로직 1 레벨로 구동하는 반면, 클라이언트는 trestart-high 로 표시되는 기간 동안 MDDI_Data0 을 구동하지 않고 그 후 MDDI_Data0 라인을 로우, 또는 로직 0 레벨로 trestart-low 로 표시되는 기간 동안 구동한다. 이후, 제 1 순방향 트래픽이 서브 프레임 헤더 패킷으로 시작하고, 순방향 트래픽 패킷이 그 다음에 전송된다. MDDI_Stb 신호는 trestart-low 기간 및 후속 서브 프레임 헤더 프레임 동안 활성이다.
도 43c 에 도시된 바와 같이, MDDI_Data0 및 MDDI_Stb 에 대한 드라이버로부터의 신호 출력이 디스에이블되어 얼마간의 시간이 지난 후, 클라이언트는 MDDI_Stb 수신기의 오프셋 또는 출력 신호를 tstb-dagta-enbl 로 표시된 시간 기간 동안 상술한 바와 같이 인에이블 함으로써, 호스트가 그 MDDI_Stb 드라이버를 인에이블 하기 전에 서비스 요청 또는 휴지로부터의 웨이크 업을 개시한다. 그러면 클라이언트 호스트가 MDDI_Stb 토글링을 시작하기 전에 그 MDDI_Data0 드라이버를 thost-detect 로 표시된 기간 동안 구동하고, 그동안 라인은 로직 0 레벨로 구동된다.
호스트가 thost-detect 동안 요청을 검출하기 전에 소정의 시작이 경과하거나 필요할 수 있고, 그 후 호스트는, 호스트가 MDDI_Data0 을 trestart-high 기간 동안 로직 1 또는 하이 레벨로 구동함으로써 링크 시작 시퀀스와 함께 MDDI_Stb 토글링을 시작하기 전에 tstb-startup 으로 표시되는 기간 동안 MDDI_Stb 를 로직 0 레벨로 유지함으로써 응답한다. 클라이언트가 MDDI_Stb 상에서 제 1 펄스를 인식한 경우, 클라이언트는 MDDI_Stb 수신기의 오프셋을 디스에이블한다. 클라이언트는 호스트가 라인을 구동함을 검출할 때까지 계속해서 tclient-detect 로 표시된 기간 동안 MDDI_Data0 을 로직 1 레벨로 구동한다. 이 시점에서, 클라이언트는 요청을 철회 (de-assert) 하고 MDDI_Data0 을 디스에이블하여 클라이언트로부터의 출력이 다시 로직 0 레벨로 가고 호스트는 MDDI_Data0 을 구동하고 있다. 이전과 같이, 호스트는 계속해서 MDDI_Data0 을 로직 1 레벨로 treatrt-high 기간 동안 구동하고, 그 후 MDDI_Data0 라인을 trestart-low 기간 동안 고동하며, 그 후 제 1 순방향 트래픽은 서브 프레임 헤더 패킷으로 시작한다. MDDI_Stb 신호는 trestart-low 기간 및 서브 프레임 헤더 패킷 동안 활성이다.
표 10 은 상술한 다양한 기간의 길이에 대한 대표적인 시간 또는 프로세싱 기간 및 예시적인 최소 및 최대 데이터 레이트를 나타내며, 여기서:
Figure 112007000702303-pct00007
이고, Link_Data_Rate 는 신호 데이터 쌍의 비트 레이트이다.
Figure 112007000702303-pct00008
당업자는 도 41 및 42 에 도시된 개별 소자의 기능이 잘 알려져 있으며, 도 42 의 소자의 기능은 도 43a, 43b 및 43c 의 타이밍도에 의해 확인됨을 용이하게 인식할 수 있을 것이다. 도 42 에 도시된 직렬 종결 (termination) 및 휴지 저항에 관한 세부 사항은, 데이터-스트로브 인코딩을 수행하고 그로부터 클록을 복구하는 방법의 설명으로는 불필요하므로 도 41 에서 생략되었다.
B. 데이터-스트로브 타이밍 순방향 링크
호스트 드라이버 출력으로부터의 순방향 링크 상의 데이터 전송을 위한 스위칭 특성이 표 11a 에 나타난다. 표 11 은 소망의 최소 및 최대값 대 소정의 신호 천이가 발생하는 통상 시간을 표 형식으로 제시한다. 예를 들어, 데이터 값 ('0' 또는 '1' 의 출력) 의 시작부터 끝까지의 천이, Data0 에서 Data0 으로의 천이가 일어나는, ttdd-(host-output) 이라 하는 시간의 통상 길이는 ttbit 인 반면, 최소 시간은 약 ttbit-0.5 nsec 이고 최대 시간은 약 ttbit+0.5 nsec 이다. Data0, 다른 데이터 라인 (DataX) 및 스트로브 라인 (Stb) 상의 천이들 사이의 상대적 간격은 도 44 에 도시되며, 여기서 Data0 에서 Strobe, Strobe 에서 Strobe, Strobe 에서 Data0, Data0 에서 비-Data0, 비-Data0 에서 비-Data0, 비-Data0 에서 Strobe, 그리고 Strobe 에서 비-Data0 으로의 천이가 도시되며, 이들은 각각 ttds-(host-output), ttss-(host-output), ttsd-(host-output), ttddx-(host-output), ttdxdx-(host-output), ttdxs-(host-output), 및 ttsdx-(host-output) 이라고 칭한다.
Figure 112007000702303-pct00009
순방향 링크 상에서 데이터를 전송하는 동일 신호에 대한 클라이언트 수신기 입력에 대한 통상의 MDDI 타이밍 요구조건이 표 11b 에 나타난다. 지연 시간을 제외하고는 동일한 시간이 논의되고 있으므로, 당업자가 인식할 수 있는 바와 같이, 신호 특성 또는 각각의 레이블의 의미를 설명하기 위해 새로운 도면은 필요 없다.
Figure 112007000702303-pct00010
도 45 및 46 은 호스트가 호스트 드라이버를 디스에이블 또는 인에이블 하는 때에 응답하여 발생할 수 있는 지연의 존재를 각각 도시한다. 호스트가 역방량링크 캡슐화 패킷 도는 라운드 트립 지연 측정 패킷과 같은 소정 패킷을 전송하는 경우, 호스트는 도 45 에 전송되어 온 것으로 도시된 파라미터 CRC, 스트로브 정렬 및 올 제로 패킷 등의 희망 패킷이 전송된 후 라인 드라이버를 디스에이블한다. 그러나, 도 45 에 도시된 바와 같이, 존재하는 특정 제어 또는 회로 소자로 잠재적으로 달성할 수 있기는 하지만, 필수적으로 순간적으로 스위치 하는 것은 아니며, 응답하는데 호스트 드라이버 디스에이블 지연 기간이라고 하는 기간이 걸린다. 이 시간 기간이 0 나노초 (nsec) 길이인 것처럼 거의 순간적으로 일어날 수 있는 반면, 조금 더 긴 기간에 걸쳐 더 용이하게 연장될 수도 있는데, 10 nsec 가 소망 최대 기간 길이이며 이는 보호 시간 1 또는 턴 어라운드 1 패킷 기간 동안 일어난다.
도 46 을 보면, 호스트 드라이버가 역방향 링크 캡슐화 패킷 또는 라운드 트립 지연 측정 패킷과 같은 패킷을 전송하기 위해 인에이블되는 때에 신호 레벨 변화가 수행됨을 볼 수 있다. 여기서, 보호 시간 2 또는 턴 어라운드 2 패킷 기간 후에, 호스트 드라이버는 인에이블 되어 레벨, 여기서는 '0' 을 구동하기 시작하며, 이 값은 호스트 드라이버 인에이블 지연 기간이라고 하는 시간 기간 동안 접근되거나 도달될 수 있고, 이는 제 1 패킷 전송 전에 드라이버 재 인에이블 기간 동안 일어난다.
유사한 프로세스가 드라이버 및 클라이언트 장치, 여기서는 디스플레이에 대한 신호 전송에 대해 발생한다. 이들 기간의 길이에 대한 일반적인 가이드라인 및 그들 각각의 관계가 아래 표 12 에 나타난다.
설명 Min. Max. 단위
호스트 드라이버 디스에이블 지연 0 10 nsec
호스트 드라이버 인에이블 지연 0 2.0 nsec
디스플레이 드라이버 디스에이블 지연 0 10 nsec
디스플레이 드라이버 인에이블 지연 0 2.0 nsec
C. 호스트 및 클라이언트 출력 인에이블 및 디스에이블 시간
호스트 및 클라이언트 출력 인에이블 및 디스에이블 시간 또는 역방향 링크 캡슐화 패킷 구조 및 기간에 대한 동작에 대한 스위칭 특성 및 상대적 타이밍 관계가 도 48 에 도시된다. 드라이버 출력 기능 또는 동작은 다음과 같이 레이블링 된다: 호스트 출력 인에이블 시간에 대해 thost-enabhle, 호스트 출력 디스에이블 시간에 대해 thost-disable, 클라이언트 출력 인에이블 시간에 대해 tclient-enable, 그리고 클라리언트 출력 디스에이브 시간에 대해 tclient-disable. 특정 신호 천이에 대한 통상의 시간은 이하에서 설명된다. 이들 동작에 대한 최소 기간은 0 나노초가 되며, 통상의 또는 최대 값은 인터페이스를 채용하는 시스템 설계로부터, 가능하게는 8 나노초 또는 그 이상의 오더로 결정된다.
이들 기간의 길이 (호스트 및 클라이언트 인에이블/디스에이블 시간) 및 그들 각각의 관계에 대한 일반적인 가이드라인이 아래 표 13 에 나타난다.
Figure 112007000702303-pct00011
Ⅷ. 링크 제어의 구현 (링크 제어기 동작)
A. 상태 머신 (state machine) 패킷 프로세서
소망에 따라 더 낮은 레이트가 분명히 수용되지만, MDDI 링크를 통해 전송되고 있는 패킷은 통상적으로 300 Mbps 이상의 오더, 400 Mbps 등의 레이트로 매우 신속히 디스패치 된다. 이러한 타입의 버스 또는 전송 링크 속도는 현재 상업적으로 이용 가능한 (경제적인) 범용 마이크로프로세서 등이 제어하기에는 너무 크다. 따라서, 이러한 타입의 신호 전송을 달성하기 위한 실제적인 구현은 프로그램가능 상태 머신을 이용하여, 그들이 의도된 적절한 시청각 서브시스템으로 전송 또는 방향 조절되는 패킷을 생성하도록 입력 패킷 스트림을 파싱하는 것이다. 그러한 장치는 공지된 것이며, 소정의 높은 속도 또는 매우 높은 속도 동작을 달성하기 위한 제한된 수의 동작들, 기능들, 또는 상태들에 일반적으로 전용되는 회로들을 이용한다.
범용 제어기, 프로세서 또는 프로세싱 소자는 더 낮은 속도를 요구하는 제어 또는 상태 패킷들과 같은 몇몇 정보를 더 적절히 다루거나 이에 대해 동작을 수행하는데 이용될 수 있다. 이러한 패킷들 (제어, 상태 또는 다른 미리 정의된 패킷) 이 수신될 때, 상태 머신은 그들을 데이터 버퍼 또는 이와 유사한 프로세싱 소자들을 통해 범용 프로세서로 전송하며, 이에 따라 시청각 패킷들이 동작을 위해 그들의 적절한 목적지로 전송되는 동안 그 패킷들은 소정의 결과 (효과) 를 제공도록 응답될 수 있다. 장래에, 마이크로프로세서 또는 다른 범용 제어기, 프로세서, 또는 프로세싱 소자가 더 높은 데이터 레이트 프로세싱 성능을 달성하기 위해 제조되면, 이하에서 설명하는 상태 또는 상태 머신은 통상적으로 저장 소자 또는 매체에 저장된 프로그램으로서의, 그와 같은 장치의 소프트웨어 제어를 이용함으로써 구현될 수도 있다.
일부 실시형태에서 범용 프로세서 기능은, 일부 모뎀 또는 그래픽 프로세서가 몇몇 기능들을 수행하고 하드웨어 복잡도 및 비용을 감소시키기 위해 컴퓨터에서 볼 수 있는 CPU 의 프로세싱 전력을 활용하는 것과 같은 방식으로, 컴퓨터 애플리케이션 내의 마이크로 프로세서 (CPU) 또는 제어기, 프로세서, 디지털 신호 프로세싱 장치 (DSP), 특수 회로 또는 무선 장치에서 볼 수 있는 ASIC 에 대해 이용 가능한 프로세싱 전력 또는 초과 사이클을 이용함으로써 실현될 수 있다. 그러나, 이 사이클 공유 또는 사용이 프로세싱 속도, 타이밍 또는 그와 같은 소자의 전체적인 동작에 부정적인 영향을 줄 수 있고, 그래서 많은 애플리케이션에서, 이 일반적인 프로세싱을 위해서는 전용 회로 또는 소자가 바람직하다.
이미지 데이터가 디스플레이 (마이크로 -디스플레이) 상에 표시되거나 호스트 장치에 의해 전송된 모든 패킷을 신뢰성 있게 수신하기 위해, 클라이언트 신호 프로세싱은 순방향 링크 채널 타이밍에 동기된다. 즉, 클라이언트 및 클라이언트 회로에 도착한 신호들은 적절한 신호 프로세싱이 일어나도록 실질적으로 시간 동기화될 것이 요구된다. 일 실시형태의 신호에 의해 달성된 상태의 높은 레벨의 도면이 도 49 의 도시에 제공된다. 도 49 에서, 상태 머신 (4900) 에 대해 가능한 순방향 링크 동기화 "상태" 는 하나의 어싱크 프레임 상태 (ASYNC FRAME STATE; 4904), 2 개의 획득 싱크 상태 (ACQUIRING SYNC STATE; 4902 및 4906), 3 개의 인-싱크 상태들 (INSYNC STATE; 4908, 4910, 및 4912) 로 분류되어 도시된다.
시작 단계 또는 상태 (4902) 에 의해 도시된 바와 같이, 표시 장치와 같은 디스플레이 또는 클라이언트가 미리 선택된 "싱크 없음 (no sync)" 상태에서 시작하고, 검출되는 제 1 서브 프레임 헤더 패킷에서 고유 워드를 검색한다. 이 싱크 없음 상태는 타입 1 인터페이스가 선택된 최소 통신 설정 또는 "폴 백 (fall-back)" 설정을 나타냄을 유의하라. 탐색 동안 고유 워드가 발견되는 때에, 클라이언트는 서브 프레임 길이 필드를 저장한다. 이 제 1 프레임의 처리에 대해서는, 또는 동기화가 얻어질 때까지는 CRC 비트의 확인이 없다. 이 서브 프레임 길이가 0 인 경우, 싱크 상태 프로세싱은 여기서 "어싱크 프레임 (async frame)" 상태로 표시되는 상태 (4904) 에 따라서 진행하며, "어싱크 프레임" 은 동기화가 아직 달성되지 않았음을 나타낸다. 프로세싱의 이 단계는, 도 49 에서 콘드 3 (cond 3) 또는 조건 3 을 만난 것으로 표시된다. 그렇지 않고, 프레임 길이가 0 보다 크면, 싱크 상태 프로세싱은 인터페이스 상태가 "1 싱크 프레임을 찾음 (found one sync frame)" 으로 설정되는 상태 (4906) 으로 진행한다. 프로세싱 내의 이 단계는 도 49 에서 콘드 5 또는 조건 5 를 만난 것으로 표시된다. 또한, 상태 머신이 0 보다 큰 프레임 길이에 대해 프레임 헤더 패킷 및 양호한 CRC 결정을 보는 경우, 프로세싱은 "1 싱크 프레임을 찾음" 상태로 진행한다. 이는 도 49 에서 콘드 6 또는 조건 6 을 만난 것으로 표시된다.
시스템이 "싱크 없음" 외의 상태에 있는 각각의 상황에서, 양호한 CRC 결과를 갖는 패킷이 검출되는 경우, 인터페이스 상태는 "인싱크 (insync)" 상태 (4908) 로 변경된다. 프로세싱의 이 단계는 도 49 에서 콘드 1, 또는 조건 1 을 만난 것으로 표시된다. 반면, 여하한 패킷의 CRC 가 정확하지 않은 경우, 싱크 상태 프로세싱은 인터페이스 상태 (4902) 의 "싱크 프레임 없음 (NO SYNC FRAME)" 상태로 진행 또는 복귀한다. 프로세싱의 이 부분은 도 49 의 상태도에서 콘드 2 또는 조건 2 를 만난 것으로 도시된다.
B. 싱크를 위한 획득 시간
인터페이스는 동기가 상실되었다고 결정하고 "싱크 프레임 없음" 상태로 복귀하기 전에 특정 수의 "싱크 오류" 를 허용하도록 구성될 수 있다. 도 49 에서, 상태 머신이 "인-싱크 상태" 에 도달하고 어떠한 오류도 발견되지 않았다면, 이는 연속적으로 콘드 1 결과를 만나고, "인-싱크 상태" 에 남아있는다. 그러나, 일단 하나의 콘드 2 결과가 검출되면, 프로세싱은 "하나의 싱크 오류 (one-sync-error)" 상태 (4910) 로 상태를 변경한다. 이 시점에서, 프로세싱이 또 다른 콘드 1 결과를 검출하는 결과를 가져오는 경우 상태 머신은 "인 싱크" 상태로 복귀하고, 그렇지 않으면 이는 다른 콘드 2 결과와 만나서 "2-싱크-오류 (TWO-SYNC-ERRORS)" 상태 (4912) 로 이동한다. 다시, 콘드 1 이 발생하는 경우, 프로세싱은 상태 머신을 "인-싱크" 상태로 복귀시킨다. 그렇지 않으면, 또 다른 콘드 2 를 만나고, 프로세싱은 상태 머신을 "싱크 없음" 상태로 복귀한다. 인터페이스가 "링크 셧다운 패킷" 을 만나는 경우, 동기화 될 상대가 없으므로 이는 링크가 데이터 송신을 종료시키고, "싱크 프레임 없음" 상태로 복귀하도록 함을 이해할 수 있을 것이며, 이는 도 49 의 상태도에서 콘드 4, 또는 조건 4 를 만나는 것으로 지칭된다.
서브 프레임 내의 몇몇 고정 위치에 나타날 수 있는 고유 워드의 반복되는 "잘못된 사본 (false copy)" 이 존재하는 것이 가능함을 알 것이다. 그 상황에서, MDD 인터페이스 프로세싱이 "인 싱크" 상태로 진행하기 위해 프로세싱될 때, 서브 프레임 헤더 패킷상의 CRC 가 또한 유효해야 하기 때문에, 상태 머신이 서브 프레임에 동기화될 가능성은 매우 적다.
호스트는 링크가 셧 다운되고 MDD 인터페이스가 휴지상태에 있거나 휴지상태로 구성되기 전에 오직 하나의 서브 프레임만을 송신할 것임을 나타내기 위해 서브 프레임 헤더 패킷 내의 서브 프레임 길이는 0 으로 설정될 수 있다. 이 경우에, 링크가 유휴 상태로 천이하기 전에 하나의 서브 프레임만이 송신되기 때문에 클라이언트는 서브 프레임 헤더 패킷을 검출한 후 순방향 링크를 통해 즉시 패킷들을 수신해야만 한다. 보통 또는 통상적인 동작에서, 서브 프레임 길이는 0 이 아니고, 클라이언트는 인터페이스가 도 49 에서 "인-싱크" 상태로서 집합적으로 도시된 이들 상태들에 있는 동안, 오직 순방향 링크 패킷만을 프로세싱한다.
호스트가 이미 순방향 링크 데이터 시퀀스를 전송하고 있는 동안, 외부 모드 클라이언트 장치가 호스트에 부착될 수도 있다. 이러한 상황에서, 클라이언트는 호스트에 동기화되어야 한다. 디스플레이가 순방향 링크 신호에 동기화하기 위해 요구되는 시간은 서브 프레임 크기 및 순방향 링크 데이터 레이트에 의존하여 변할 수 있다. 순방향 링크 내의 무작위 또는 더 무작위 데이터의 일부로서 고유 워드의 "잘못된 사본" 을 검출할 가능성은, 서브 프레임 크기가 클 때 더 크다. 동시에, 순방향 링크 데이터 레이트가 더 느릴 때, 잘못된 검출로부터 회복할 수 있는 능력은 더 낮고, 그렇게 하는데 걸리는 시간은 더 길다.
하나 이상의 실시형태에 대해, 순방향 링크 송신이 저전력 모드로 가거나 링크를 완전히 셧다운하는 것을 멈추기 전에 MDDI 역방향 링크가 안정하도록 보장하기 위해 MDDI 호스트가 소정의 추가적인 단계를 수행하여야 할 것을 권장 또는 이해한다.
발생할 수 있는 하나의 문제는, 호스트가 부정확한 라운드 트립 지연 값 측정을 이용하는 경우, 이는, 순방향 링크가 양호해 보이더라도, 클라이언트로부터의 모든 후속 수신 데이터 송신이 실패하도록 한다. 이것은 호스트가 클라이어트가 순방향 링크와 동기되지 않은 때에 라운드 트립 지연 측정 패킷을 전송하려하는 경우에, 또는 라운드 트립 지연에 의해 영향을 받는 차동 드라이버 또는 수신기의 전파 지연의 큰 변화를 초래하는 극단적인 대기 온도 변화에 기인하여 발생할 수 있다. 중간 케이블 또는 접속 컨택트의 시패도 클라이언트가 일시적으로 동기화를 상실하고 다시 재획득하도록 할 수 있고, 그 시간 동안 라운드 트립 지연 측정 패킷 수신을 누락할 수 있다. 이후의 역방향 링크 패킷은 호스트에 의해 적절하게 디코딩될 수 없게 된다.
발생할 수 있는 다른 타입의 문제는, 클라이언트가 일시적으로 동기를 잃는 경우, 클라이언트가 동기를 재획득할 수 있기 전에 호스트가 링크 셧다운 패킷을 전송하는 것이다. 링크 셧다운 패킷을 수신하지 않았고 링크가 휴지라서 클록을 가지지 않기 때문에 클라이언트가 휴지상태에 들어갈 수 없는 동안에 호스트는 휴지상태에 있을 것이다.
이러한 문제를 극복하는데 유용한 하나의 기술 또는 실시형태는, 호스트가 링크를 휴지상태로 놓기 전에 클라이언트가 순방향 링크와 동기화 되도록 보장하게 하는 것이다. 동작 동안 일어나는 케이블, 콘덕터, 또는 커넥터 분리, 파손 또는 미접촉에 기인하여 링크가 갑자기 파괴되거나 실패하는 경우, 또는 MDDI 호스트가 전력을 잃는 경우와 같이 MDDI 호스트가 그렇게 할 수 없거나 할 기회를 갖지 않는 경우, 호스트는 라운드 트립 지연 측정 프로세스를 시작하거나 역방향 링크 캡슐화 패킷을 전송하기 전에 먼저 클라이언트가 동기화되었는지 확인하려고 시도하여야 한다.
호스트는 클라이언트에 의해 전송된 클라이언트 요청 및 상태 패킷 내 CRC 오류 카운트 필드를 관찰하여 순방향 링크 무결성을 판정한다. 이 패킷은 호스트에 의하여 클라이언트로부터 요청된다. 그러나 중요한 링크 실패 또는 파괴의 경우, 클라이언트는 패킷을 적절하게 디코딩할 수 없고, 어쩌면 수신조차 할 수 없으므로 이 요청은 응답되지 않을 가능성이 높다. 역방향 링크 캡슐화 패킷에서 전송된 클라이언트 요청 및 상태 패킷을 이용한 CRC 오류 카운트에 대한 요청은 첫 번째 무결성 체크, 일종의 제 1 방어선으로 동작한다. 또한, 호스트는 라운드 트립 지연 측정 패킷을 전송하여 클라이언트가 동기를 잃었는지에 관한 가정이 유효한지 여부를 확인할 수 있다. 클라이언트가 라운드 트립 지연 측정 패킷에 응답하지 않는 경우, 호스트는 클라이언트가 동기를 잃었다고 결론을 내리고 다시 동기로 되돌리기 위한 프로세스를 시작할 수 있다.
클라이언트가 클라이언트 요청 및 상태 패킷을 호스트로 반환하도록 요구하기 위해 역방향 링크 플래그 필드의 비트 1 을 1 로 설정하여, 클라이언트에 역방향 링크 캡슐화 패킷을 주기적으로 전송함으로써 호스트는 계속적으로 클라이언트의 CRC 오류 카운트를 모니터링해야 한다.
호스트가 클라이언트가 순방향 링크와의 동기를 잃었음이 확실하다고 결론을 내리면, 호스트는 필러 패킷 외의 다른 패킷을 전송하려 시도하기 전에 다음 서브 프레임 헤더까지 대기한다. 이것은, 클라이언트에게 서브프레임 헤더 패킷 내에 포함된 하나의 고유 워드를 검출 또는 탐색하는데 충분한 시간을 허용하기 위해 이루어진다. 이후, 호스트는 정확한 위치에서 고유 워드를 찾지 못하였을 것이므로 클라이언트는 자신을 리셋햇을 것으로 가정할 수 있다. 이 시점에서, 호스트는 라운드 트립 지연 측정 패킷으로 서브프레임 헤더 패킷을 뒤따를 수 있다. 클라이언트가 여전히 라운드 트립 지연 측정 패킷에 정확하게 반응하지 않는 경우, 호스트는 재동기화 프로세스를 반복할 수 있다. 정확한 응답이란, 클라이언트가 라운드 트립 지연 측정 패킷의 측정 기간 내에 호스트에게 특정 시퀀스를 다시 전송하는 것이다. 이 시퀀스가 수신되지 않은 경우, 역방향 링크 캡슐화 패킷에서 역방향 데이터를 수신하려는 시도는 실패할 것이다. 계속적인 이러한 실패는 다른 방식으로 다루어져야 할 다른 시스템 오류를 나타내며, 이는 이 시점에서 링크 동기화의 일부가 아니다.
그러나, 성공적인 라운드 트립 지연 측정 패킷 후에 호스트가 여전히 역방향 링크 캡슐화 패킷에서 망가진 데이터를 보거나 응답을 보지 못하는 경우, 라운드 트립 지연 측정 패킷을 다시 보냄으로써 역방향 데이터 샘플링이 정확한지를 확인하여야 한다. 몇 번의 시도 후 이것이 성공적이지 않으면, 일 실시형태에서는, 호스트가 역방향 레이트 제수 값을 증가시켜 역방향 데이터 레이트를 감소시킬 것이 권장된다.
호스트는 MDDI 링크를 휴지상태로 위치시키기 전에, 상술한 링크 실패 검출 및 가능하게는 링크 재동기화 단계를 수행하여야 한다. 이는 일반적으로 링크가 나중에 재시작될 때 수행되는 라운드 트립 지연 측정 패킷이 성공적이도록 보장한다. 호스트가 링크 실패를 의심할 이유가 없고, 역방향 링크 캡슐화 패킷에 대한 정확한 응답 및 0 개의 순방향 링크 CRC 오류가 클라이언트에 의해 보고되고 있는 경우, 호스트는 모든 것이 순조롭게 또는 적절하게 (예를 들어, 링크 실패 없이) 동작 또는 기능하고 있음을 가정하고 전력 다운/휴지 프로세스로 진행할 수 있다.
호스트가 동기화를 테스트할 수 있는 다른 방법은 호스트가 라운드 트립 지연 측정 패킷을 전송하고 클라이언트로부터의 적당한 응답을 확인하는 것이다. 적당한 응답이 호스트에 의해 수신되면, 클라이언트가 성공적으로 순방향 링크 패킷을 해석하고 있음을 합리적으로 가정할 수 있다.
C. 초기화
상술한 바와 같이, "시작" 시간에, 호스트는 순방향 링크를 최소로 요구되거나 희망하는, 1 Mbps 의 데이터 레이트 이하에서 동작하도록 구성하고, 서브 프레임 길이 및 미디어-프레임 레이트를 주어진 애플리케이션에 적절하도록 구성한다. 즉, 순방향 링크 및 역방향 링크 모두 타입 1 인터페이스를 이용하여 동작하기 시작한다. 일반적으로, 이러한 파라미터는, 호스트가 클라이언트 디스플레이 (또는 다른 타입의 클라이언트 장치) 를 위한 희망 구성 또는 능력을 결정하는 동안, 일시적으로만 이용될 것이다. 호스트는, 디스플레이 또는 클라이언트가 클라이언트 능력 패킷으로 응답하도록 요청하기 위해, 일 (1) 의 값으로 설정된 요청 플래그의 비트 '0' 을 가지는 역방향 링크 캡슐화 패킷이 후속하는 서브 프레임 헤더 패킷을 순방향 링크를 통해 송신 또는 전송한다. 일단 디스플레이가 순방향 링크 상에서 (또는 그와의) 동기화를 획득하면, 클라이언트 능력 패킷 및 클라이언트 요청 및 상태 패킷을 역방향 링크 또는 채널을 통해 송신한다.
호스트는 최적 또는 소정 레벨의 성능을 위해 링크를 어떻게 재구성할지를 결정하기 위해 클라이언트 능력 패킷의 컨텐츠를 조사한다. 호스트는, 호스트 및 클라이언트가 서로 호환되는 버전의 프로토콜을 이용하는 것을 확인하기 위해 프로토콜 버전 및 최소 프로토콜 버전 필드를 조사한다. 일반적으로, 프로토콜 버전은 클라이언트 능력 패킷의 처음 2 개의 파라미터로 남아 있으므로, 프로토콜의 다른 요소들이 호환되지 않을 수 있거나 호환되는 것으로 완전히 인식되지 않는 때라도 호환성이 판정될 수 있다.
내부 모드에서, 호스트는 클라이언트 능력 패킷을 수신할 필요 없이 미리 클라이언트의 파라미터를 알 수 있다. 링크는 호스트 및 클라이언트 모두가 동작할 수 있는 여하한 데이터 레이트에서 시작할 수 있다. 많은 실시형태에서, 시스템 설계자는 데이터 전송을 재촉하기 위해 최대 달성 가능한 데이터 레이트에서 링크를 시작하도록 선택하는 경우가 많으나, 이는 필수적인 것은 아니고 다른 경우에서는 사용되지 않을 수 있다. 내부 모드 동작에서, 유지 시퀀스로부터의 링크 시작 동안 스트로브 펄스의 주파수는 이 희망 레이트와 일치하는 것이 보통일 것이다.
D. CRC 프로세싱
모든 패킷 타입에 대하여, 패킷 프로세서 상태 머신은 CRC 체커가 적절히 또는 알맞게 제어되는 것을 보장한다. 또한, 프로세서는 CRC 비교가 하나 이상의 오류가 검출을 가져오는 때에 CRC 오류 카운터를 증가시키며, CRC 카운터를 프로세싱되고 있는 각 서브 프레임의 시작에서 리셋시킨다.
E. 동기화 체크의 다른 상실
상술한 일련의 단계들 또는 상태들이 더 높은 데이터 레이트 또는 처리량 속도를 생성하기 위해 작용하는 반면, 출원인은 호스트와의 동기화의 손실이 있음을 선언하기 위해 클라이언트가 사용하는 조건들의 변경 또는 다른 배열이 휠씬 더 높은 데이터 레이트 또는 처리량을 달성하는데 효과적으로 이용될 수 있음을 발견하였다. 새로운 발명의 실시형태는 동일한 기본 구조를 가지나, 상태를 변경하기 위한 조건들이 변경된다. 또한, 서브 프레임 동기화를 위한 체크를 수행하는 것을 돕기 위해 새로운 카운터가 구현된다. 이러한 단계들 및 조건들은 도 63 과 관련해 제시되며, 도 63 은 본 방법 또는 상태 머신의 동작들을 확립하는데 유용한 일련의 조건들 및 상태들을 도시한다. 명확히 하기 위해, 오직 "획득-싱크 상태 (AQUIRING-SYNC STATE)" 및 "인 싱크 상태 (IN-SYNC STATE)" 부분만이 도시된다. 또한, 결과적인 상태가 상태 머신 자체와 실질적으로 동일하기 때문에, 동일한 번호를 이용한다. 그러나, 상태 (및 상태 머신의 동작) 을 변경하기 위한 조건들이 다소 변하며, 그래서 차이를 식별하는 데 있어서의 편의를 위해, 2 개의 도면들 사이에 명확성을 위해 모두 번호를 다시 부여한다 (1, 2, 3, 4, 5, 및 6 대 61, 62, 63, 64 및 65). 어싱크 프레임 (ASYNC FRAME) 상태는 본 설명에서 고려되지 않기 때문에, 하나의 상태 (4904) 및 조건 (6) 은 본 도면에서 더 이상 이용되지 않는다.
도 63 에서, (디스플레이 또는 프리젠테이션을 위한) 시스템 또는 클라이언트는 상태 머신 (5000) 가 도 49 에서와 같이 미리 선택된 "싱크 없음 (no sync)" 상태 (4902) 에 있는 상태로 시작한다. 싱크 없음 상태 (4902) 로부터의 상태 변경을 위한 제 1 상태 변경은 싱크 패턴의 발견인 조건 (64) 에 있다. 서브 프레임 헤더의 CRC 도 이 패킷 상에서 통과함을 가정하면 (조건 61 충족), 패킷 프로세서 상태 머신의 상태는 인-싱크 상태 (4908) 로 변경될 수 있다. 싱크 오류, 조건 62 는 상태 머신이 상태 (4910) 로 이동하게 하고, 상태 (4912) 로의 두 번째 발생을 유발하게 된다. 그러나, MDDI 패킷의 임의의 CRC 오류는 상태 머신이 인-싱크 상태 (4908) 에서 나와 하나의 싱크 오류 상태 (4910) 로 이동하는 것을 유발하게 됨을 발견하였다. 임의의 MDDI 패킷의 또 다른 CRC 오류는 2 개의 싱크 오류 상태 (4912) 로 이동하는 것을 유발하게 된다. 정확한 CRC 값으로 디코딩된 패킷은 상태 머신이 인-싱크 상태 (4908) 로 복귀하도록 하게 된다.
변화된 것은 CRC 값 또는 '모든' 패킷에 대한 결정을 이용하는 것이다. 즉, 상태 머신이 단순히 서브 프레임 헤더 패킷들을 관찰하는 대신 동기화의 손실을 판정하기 위해 모든 패킷에 대한 CRC 값을 주시하도록 하는 것이다. 이 구성 또는 프로세스에서, 동기화의 손실은 고유 워드 및 단순한 서브 프레임 CRC 값을 이용하여 결정되지 않는다.
새로운 인터페이스 구현은 MDD 인터페이스 링크가 동기화 오류를 훨씬 더 빠르게 인식하고 그에 따라 그로부터 더 빨리 복구될 수 있도록 한다.
이 시스템을 더 로버스트하게 하기 위해, 클라이언트는 서브 프레임 카운터도 부가하거나 이용하여야 한다. 그러면, 클라이언트는 고유 워드의 존재를 그것이 신호에서 도착 또는 발생할 것으로 기대되는 시간에 체크한다. 고유 워드가 정확한 시간에 발생하지 않는 경우, 클라이언크는, 서브 프레임 길이보다 큰 수개의 (여기서는 3) 패킷 시간 또는 기간을 기다려야 하는 경우보다 휠씬 빨리 동기화 실패가 발생한 것을 인식할 수 있다. 고유 워드에 대한 테스트가 고유 워드가 존재하지 않는 것, 즉 타이밍이 정확하지 않음을 나타내는 경우, 클라이언트는 즉시 동기화의 링크 손실을 선언하고, 싱크 없음 상태로 이동한다. 적절한 고유 워드의 존재에 대한 검사 프로세스는, 고유 단어가 정확하지 않음을 말하는 조건 65 (콘드 65) 를 상태 머신에 추가한다. 서브 프레임 패킷이 클라이언트에 수신될 것이 기대되고 맞지 않을 경우, 클라이언트는 즉시 싱크 없음 상태 (4902) 로 이동하여, 상태 (4910) 및 상태 (4912) 를 거쳐 가로지르며 일반적으로 마주치는 다수의 싱크 오류 (조건 62) 를 기다리는 추가적인 시간을 절약한다.
이 변화는 서브 프레임 길이를 카운트하기 위해 클라이언트 코어 내의 추가적인 카운터 또는 카운팅 기능을 이용한다. 일 실시형태에서, 카운트 다운 기능이 이용되고, 카운터가 만료되면 서브 프레임 워드를 체크하기 위해 현재 처리되고 있는 여하한 패킷의 전송이 중단된다. 다르게는, 카운터는 희망의 최대 또는 특별한 희망 값과 카운트를 비교하며, 카운트 업할 수 있으며, 그 시점에서 현재 패킷이 체크된다. 이 프로세스는 클라이언트가 클라이언트 상에서 비정상적으로 긴 길이를 가지고 부정확하게 수신된 패킷을 디코딩하는 것을 막는다. 디코딩 되고 있는 일부 다른 패킷을 인터럽트 하는데 서브 프레임 길이 카운드가 필요한 경우, 어떠한 패킷도 서브 프레임 경계를 가로질러서는 안되므로, 동기화 상실이 판정될 수 있다.
Ⅸ. 패킷 프로세싱
상태 머신이 수신하는 상술한 각 타입의 패킷에 있어, 그 패킷은 인터페이스 동작을 구현하기 위한 특정 프로세싱 단계 또는 일련의 단계들을 수행한다. 순방향 링크 패킷은 이하의 표 14 에 나열된 예시적인 프로세싱에 따라 일반적으로 프로세싱된다.
패킷 타입 패킷 프로세서 상태 머신 응답
서브 프레임 헤더 (Sub-Frame Header; SH) 양호한 패킷 확인, 서브 프레임 길이 필드 포착, 및 범용 프로세서로 패킷 파라미터 전송
필러 (Filler; F) 데이터 무시
비디오 스트림 (Video Stream; VS) 비디오 데이터 형식 디스크립터 및 기타 파라미터 해석, 패킷회된 픽셀 데이터를 필요한 경우 패킷화 해제, 필요한 경우 컬러 맵을 통해 픽셀을 변환, 및 비트맵의 적절한 위치에 픽셀 데이터를 기록
오디오 스트림 (Audio Stream; AS) 오디오 샘플 클록 생성기에 오디오 샘플 레이트 설정을 전송, 특정 크기의 오디오 샘플을 분리, 필요한 경우 오디오 샘플 데이터를 패킷화 해제, 및 적절한 오디오 샘플 FIFO 로 오디오 샘플 라우팅
컬러 맵 (Color Map; CM) 컬러 맵 크기 및 오프셋 파라미터 판독, 그리고 컬러 맵 메모리 또는 저장 위치에 컬러 맵 데이터 기록
역방향 링크 캡슐화 (Reverse Link Encapsulation; REL) 적절한 시간에 역방향으로 패킷을 전송하는 것을 용이하게 함. 역방향 링크 플래그가 조사되고, 필요에 따라 클라이언트 능력 패킷이 전송된다. 클라이언트 요청 및 상태 패킷도 적절하게 전송된다.
클라이언트 능력 (Cliecnt Capability; CC) 역방향 링크 캡슐화 패킷의 역방향 링크 플래그 필드를 이용하여 호스트에 의해 요청된 경우 이 타입의 패킷을 전송한다.
키보드 (Keyboard; K) 이들 패킷을 키보드 타입 장치 (존재하는 경우) 와 통신하는 범용 프로세서로/로부터 패스. 사용이 바람직함.
포인팅 장치 (Pointing Device; PD) 이들 패킷을 포인팅 타입 장치 (존재하는 경우) 와 통신하는 범용 프로세서로/로부터 패스. 사용이 바람직함.
링크 셧다운 (Link Shutdown; LS) 링크가 셧다운 되었음을 기록하고 범용 프로세서에 통지
클라이언트 요청 및 상태 (Client Request and Staus; CRS) 이 패킷을 역방향 링크 캡슐화 패킷의 첫 번재 패킷으로 전송
비트맵 블록 전송 (Bitmap Block Transfer; BPT) 비디오 데이터 형식 디스크립터와 같은 패킷 파라미터를 해석, 어떤 픽셀이 먼저 이동할지 결정, 요구에 따라 비트맵 내의 픽셀 이동
비트맵 영역 채움 (Bitmap Area Fill; BAF) 패킷 파라미터 해석, 필요한 경우 컬러 맵을 통해 픽셀 변환, 픽셀 데이터를 비트맵 내 적절한 위치에 기록
비트맵 패턴 채움 (Bitmap Pattern Fill; BPF) 패킷 파라미터 해석, 필요한 경우 패킷화된 픽셀 데이터 패킷화 해제, 필요한 경우 컬러맵을 통해 픽셀 변환, 및 비트맵 내의 적절한 위치에 픽셀 데이터 기록
통신 링크 채널 (Communication Link Channel; CLC) 이 데이터를 범용 프로세서에 직접 전송
휴지로부터의 웨이크-업 특별한 목적의 상태 머신이 웨이크 업 시퀀스를 전송하고 검출하는 로우 레벨 기능을 제어한다.
수행 타입 핸드오프 (Perform Type Handoff; PTH) 그러한 패킷에 대해, 직접 또는 그들을 범용 프로세서로 전송함으로써, 또한 하드웨어에게 모드 변경을 수행할 것을 명령함으로써 동작할 수도 있다.
Ⅹ. 역방향 링크 데이터 레이트 감축
호스트 링크 제어기를 위해 이용되는 특정 파라미터가 매우 바람직하게 최대 또는 더욱 최적화된 (스케일) 역방향 링크 데이터 레이트를 획득하기 위해 특정 방식으로 조정되거나 구성될 수 있음이 본 발명자에 의해 관찰되었다. 예를 들어, 역방향 링크 캡슐화 패킷의 역방향 데이터 패킷 필드를 전송하는데 이용되는 시간 동안, MDDI_Stb 신호쌍이 순방향 링크 데이터 레이트의 반으로 주기적 데이터 클록을 생성하기 위해 토글링된다. 이는 호스트 링크 제어기가, 모두 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+/- 생성, 클라이언트로의 케이블 전송, 클라이언트 수신기, 클록 생성, 신호 클록킹, DataO+/- 생성, 호스트로의 케이블 전송, 및 호스트 수신기단을 위한 프로세싱부 부근에 도시된다.
순방향 링크 데이터 레이트 및 마주치는 신호 처리 지연에 따라, 이 "라운드 트립" 효과 또는 이벤트들 세트가 완료되는데 MDDI_Stb 신호상의 1 사이클 보다 더 긴 시간을 요구할 수 있으며, 이는 시간 또는 사이클의 바람직하지 않은 양을 소비하는 결과를 낳는다. 이 문제를 회피하기 위해, 역방향 레이트 제수는 역방향 링크 상의 1 비트 시간이 MDDI_Stb 신호의 다수의 사이클에 걸치는 것을 가능하게 한다. 이는 역방향 링크 데이터 레이트가 순방향 링크 레이트보다 작다는 것을 의미한다.
인터페이스를 통한 신호 지연의 실제 길이는, 이용되는 각각의 구체적인 호스트-클라이언트 시스템 또는 하드웨어에 따라 다를 수 있음을 유의하여야 한다. 필수적인 것은 아니나, 일반적으로, 시스템의 실제 지연을 측정하여 역방향 레이트 제수가 최적값으로 설정될 수 있도록 하기 위해 라운드 트립 지연 측정 패킷을 이용함으로써 각각의 시스템을 더욱 잘 동작하도록 할 수 있다. 호스트는 보다 간단하지만 보다 느린 속도에서 동작하는 기본 데이터 샘플링 또는 더 복잡하지만 보다 높은 역방향 데이터 레이트를 지원하는 고급 데이터 샘플링을 지원할 수 있다. 양 방법을 지원하는 클라이언트 능력은 동일하게 고려된다.
라운드 트립 지연은 호스트가 라운드 트립 지연 측정 패킷을 클라이언트로 송신하도록 함으로써 측정될 수 있다. 클라이언트는, 측정 기간 필드라 불리는 그 패킷 내의 미리 선택된 측정 윈도우 안에서, 또는 윈도우 동안, 일 (1) 의 시퀀스를 호스트로 다시 송신함으로써 이 패킷에 응답한다. 이 측정의 상세한 타이밍은 전술하였다. 라운드 트립 지연은 역방향 링크 데이터가 안전하게 샘플링될 수 있는 레이트를 결정하는데 이용된다.
라운드 트립 지연 측정은, 측정 기간 필드의 시작과 0xff, 0xff, 0x00 응답 시퀀스가 클라이언트로부터 호스트에서 다시 수신되는 시간 기간의 시작 사이에서 발생하는 순방향 링크 데이터 클록 간격들의 수를 결정, 검출, 또는 카운팅하는 단계로 이루어진다. 클라이언트로부터의 응답이, 측정 카운트가 막 증가하려 하기 전에 순방향 링크 클록 기간의 작은 부분에서 수신될 수 있음을 유의하라. 이 변경되지 않은 값이 역방향 레이트 제수를 계산하는데 이용되는 경우, 신뢰할 수 없는 데이터 샘플링으로 인해 역방향 링크 상에 비트 오류를 유발할 수 있다. 이 상황의 예가 도 51 에 도시되어 있으며, 여기서 호스트에서의 MDDI_Data, 호스트에서의 MDDI_Stb, 호스트 내의 순방향 링크 데이터 클록, 및 지연 카운트를 나타내는 신호가 해당 픽셀을 그림의 형태로 도시된 수신지 픽셀 위치에 기록한다. 도 51 에서, 응답 시퀀스는, 지연 카운트가 6 으로부터 7 로 막 증가되려 하는 때보다 순방향 링크 클록 기간의 일부 전에 클라이언트로부터 수신된다. 지연이 6 일 것으로 추측되면, 호스트는 비트 천이 직후에 또는 가능하게는 비트 천이 중에 역방향 데이터를 샘플링할 것이다. 이는 호스트에서의 잘못된 샘플링을 초래할 수 있다. 이러한 이유로, 측정된 지연은 통상적으로 역방향 데이트 제수를 계산하는데 이용되기 전에 1 씩 증가되어야 한다.
역방향 링크 제수는 호스트가 역방향 링크 데이터를 샘플링하기 전에 기다려야 하는 MDDI_Stb 사이클의 수이다. MDDI_Stb 가 순방량 링크 레이트의 1/2 의 레이트로 반복되기 때문에, 정정된 라운드 트립 지연 측정은 2 에 의해 나누어지고, 그 후 가까운 정수로 올림 (rounded up) 된다. 식으로 표현하면, 그 관계는 다음과 같다:
Figure 112007000702303-pct00012
주어진 예에서 이는 다음과 같이 된다:
Figure 112007000702303-pct00013
이 예에서 이용된 라운드 트립 지연 측정이 6 이 아니라 7 인 경우에도, 역방향 레이트 제수는 4 가 된다.
역방향 링크 데이터는 호스트에 의해 역방향 링크 클록의 상승 에지에서 샘플링된다. 역방향 링크 클록을 생성하기 위해 호스트와 클라이언트 양측 모두에 카운터 또는 이와 유사한 공지의 회로나 장치가 존재한다. 카운터는 역방향 링크 캡슐화 패킷의 역방향 링크 패킷 필드 내의 제 1 비트의 시작에서 역방향 링크 클록의 제 1 상승 에지가 발생하도록 초기화된다. 이는 이하에 주어진 실시예에 대하여 도 52 에 도시된다. 카운터는 MDDI_Stb 신호의 각 상승 에지에서 증가하고, 카운트가 다시 시작될 때까지 발생하는 카운트의 수는 역방향 링크 캡슐화 패킷 내의 역방향 레이트 제수 파라미터에 의해 설정된다. MDDI_Stb 신호가 순방향 링크 레이트의 절반에서 토글링하기 때문에, 역방향 링크 레이트는 순방향 링크 레이트 나누기 역방향 레이트 제수의 절반이다. 예를 들어, 순방향 링크 레이트가 200 Mbps 이고, 역방향 레이트 제수가 4 인 경우, 역방향 링크 데이터 레이트는 다음과 같이 표현된다:
Figure 112007000702303-pct00014
역방향 링크 캡슐화 패킷 내의 MDDI_Data0 및 MDDI_Stb 신호 라인의 타이밍을 도시하는 예가 도 52 에 도시되며, 여기서 예시로 사용된 패킷 파라미터들은 다음과 같은 값을 갖는다:
패킷 길이 = 1024 (0x0400) 턴 어라운드 1 길이 = 1
패킷 타입 = 65 (0x41) 턴 어라운드 2 길이 = 1
역방향 링크 플래그 = 0 역방향 레이트 제수 = 2
파라미터 CRC = 0xdb43 올 제로는 0x00
패킷 길이와 파라미터 CRC 필드 사이의 패킷 데이터는 :
0x00, 0x04, 0x41, 0x00, 0x02, 0x01, 0x01, 0x43, 0xdb, 0x00 ...
클라이언트로부터 반환되는 첫 번째 역방향 링크 패킷은 패킷 길이 7 및 패킷 타입 70 을 갖는 클라이언트 요청 및 상태 패킷이다. 이 패킷은 바이트 값 0x07, 0x00, 0x46,...등등으로 시작한다. 그러나, 제 1 바이트 (0x07) 만 도 52 에서 볼 수 있다. 이 첫 번째 역방향 링크 패킷은 실제 역방향 링크 지연을 설명하기 위해 도면에서 거의 하나의 역방향 링크 클록 기간만큼 시간 이동된다. 0 의 호스트로부터 클라이어언트로의 라운드 트립 지연을 가진 이상적인 파형은 점선 자취로 도시된다.
파라미터 CRC 필드의 MS 바이트는 패킷 타입, 그리고 올 제로 필드 후에 전송된다. 호스트로부터의 스트로브는 호스트로부터의 데이터가 레벨을 변경함에 따라 1 로부터 0 으로 스위칭되고 다시 1 로 돌아와 더 넓은 펄스를 형성한다. 데이터가 0 으로 됨에 따라, 스트로브는 더 높은 레이트로 스위칭되며, 오직 데이터 라인 상의 데이터의 변화만이 정렬 필드의 종단 근방에서의 변경을 유발한다. 연장된 시간 기간에 대하여 데이터 신호의 고정된 0 또는 1 레벨 및 펄스 패턴 (에지) 상에서 하강하는 천이로 인해, 스트로브는 도면의 나머지 부분동안 더 높은 레이트로 스위칭된다.
호스트에 대한 역방향 링크 클록은 클록이 역방향 링크 패킷을 수용하기 위해 시작하는 턴 어라운드 1 기간의 종료까지 0 에 있다. 도면의 하부에 있는 화살표는, 본 개시의 나머지로부터 명백한 바와 같이 데이터가 샘플링되는 시점을 나타낸다. 전송되고 있는 패킷 필드의 제 1 바이트 (여기서 11000000) 는 턴 어라운드 1 이후에 시작하는 것으로 도시되며, 그 라인 레벨은 디스에이블되고 있는 호스트 드라이버로부터 안정화된다. 비트 3 에 대하여 보는 바와 같이, 제 1 비트의 이동에서의 지연은 데이터 신호에 대해 점선들에서 볼 수 있다.
도 53 에서, 순방향 링크 데이터 레이트에 기초한 역방향 레이트 제수의 통상적인 값을 볼 수 있다. 실제 역방향 레이트 제수는 적절한 역방향 링크 동작을 보장하기 위해 라운드 트립 링크 측정의 결과로서 결정된다. 제 1 영역 (5302) 은 안전 동작의 영역에 대응하고, 제 2 영역 (5304) 은 한계 (marginal) 성능의 영역에 대응하며, 한편 제 3 영역 (5306) 은 적절히 기능할 가능성이 적은 설정을 나타낸다.
라운드 트립 지연 측정 및 역방향 레이트 제수 설정은 송신 또는 수신된 비트의 수보다는 실제 클록 기간 단위의 관점에서 표현되고 동작하기 때문에, 순방향 또는 역방향 링크 상의 인터페이스 타입 설정들 중 여하한 것으로 동작하는 동안, 라운드 트립 지연 측정 및 역방향 레이트 제수 설정은 동일하다.
통상, 가능한 가장 큰 역방향 레이트 제수는 타입 1 인터페이스를 이용하여 라운드 트립 지연 측정의 측정 윈도우 내에서 전송될 수 있는 비트 수의 반이고, 예를 들어 다음과 같다:
Figure 112007000702303-pct00015
라운드 트립 지연보다 작은 역방향 비트 시간을 허용하는 대안으로서, 고급 역방향 데이터 샘플링 방법이 채용될 수도 있다. 이 기법에 있어서, 호스트는 라운드 트립 지연을 측정할 뿐만 아니라, 0 지연을 갖는 클라이언트 및 링크의 '이상적' 비트 경계에 대한 클라이언트로부터의 응답의 위상을 결정한다. 클라이언트 장치 응답의 위상을 앎으로써, 호스트는 클라이언트로부터의 역방향 데이터 비트를 샘플링하는 상대적으로 안전한 시간을 결정할 수 있다. 라운드 트립 지연 측정은 호스트에게 역방향 데이터 패킷 필드의 시작에 대한 역방향 데이터의 제 1 비트의 위치를 표시한다.
고급 역방향 데이터 샘플링의 일례의 일 실시형태가 도 52b 에 그림의 형태로 도시된다. 0 라우드 트립 지연을 갖는 이상적 역방향 데이터 신호는 점선 파형으로 도시된다. 3.5 내지 4 MDDI_Stb 사이클 사이의 실제 라운드 트립 지연은 실선 파형과 이상 사이의 지연의 차이로 볼 수 있다. 이는 라운드 트립 지연 측정 패킷을 이용하여 측정된 것인, 7 순방향 링크 비트 시간과 동일한 측정된 라운드 트립 지연 값과 동일한 지연이다. 본 실시형태에서, 역방향 데이터 비트는 2 MDDI_Stb 펄스 길이이며, 이는 4 순방향 링크 비트 시간이고, 역방향 레이트 제수 2 에 대응한다. 고급 역방향 데이터 샘플링에 대해, 다른 곳에서 설명된 것과 같은 계산 대신에 2 의 미리 선택된 역방향 레이트 제수를 이용하는 것이 편리하다. 이상적 샘플링 포인트는 상술한 종래의 측정을 이용하여 용이하게 결정될 수 있으므로, 이는 고급 역방향 데이터 샘플링에 대해 실질적으로 최적의 선택인 것으로 보인다.
역방향 데이터에 대한 이상적 샘플링 포인트는, 총 라운드 트립 지연 나누기 역방향 비트 당 순방향 링크 클록의 수의 나머지, 즉 라운드 트립 지연 모듈로 (modulo) 역방향 비트 당 순방향 링크 클록을 취하여 용이하게 계산될 수 있다. 그 후 1 또는 2 를 감산하여 데이터 천이로부터 떨어진 안전한 점을 얻는다. 이 예에서, 7 mod 4 = 3 이고, 3-1=2 또는 3-2=1 이다. 안전한 샘플링 포인트는 0 라운드 트립 지연에 대한 '이상적' 비트 경계의 에지로부터 1 또는 2 순방향 링크 비트 시간이다. 타이밍도의 하부에 일련의 수직 화살표로 표시된 바와 같이, 도면은 이상적 비트 경계로부터 2 순방향 링크 비트 시간에서 샘플링 포인트를 도시한다. 첫 번째 샘플링 포인트는 측정된 라운드 트립 지연 더하기 안전한 샘플링을 위한 오프셋 후 첫 번째 이상적 비트 경계이다. 이 예에서, 라운드 트립 지연 측정값은 7 이므로, 다음 이상적 비트 경계는 8 번째 비트 시간에 있으며, 거기에 안전한 샘플링 포인트를 위해 1 또는 2 를 더하여, 제 1 비트는 역방향 데이터 패킷 필드의 시작 후 9 또는 10 순방향 링크 비트 시간 후에 샘플링될 것이다.
XI. 턴 어라운드 및 보호 시간
역방향 링크 캡슐화 패킷 내의 턴 어라운드 1 필드는 호스트 드라이버가 디스에이블 하고, 클라이언트 드라이버가 동시에 인에이블 하는 시간을 허용한다. 라운드 트립 지연 측정 패킷 내의 보호 시간 1 필드는 호스트 및 클라이언트의 오버랩을 가능하게 하여, 클라이언트 드라이버는 호스트 인터페이스 드라이버가 디스에이블 되기 전에 인에이블 할 수 있다. 역방향 링크 캡슐화 패킷 내의 턴 어라운드 2 필드는 클라이언트로부터의 이전 필드 내의 데이터가 호스트 드라이버가 인에이블 되기 전에 완전히 송신될 수 있도록 한다. 보호 시간 2 필드는 클라이언트 및 호스트 드라이버가 로직 0 레벨로 동시에 구동할 수 있도록 하는 시간 값 또는 기간을 제공한다. 보호 시간 1 및 보호 시간 2 필드는 일반적으로 조정될 수 없는 길이의 미리 설정되거나 미리 선택된 값으로 채워진다. 이용되고 있는 인터페이스 하드웨어에 따라, 이들 값은 경험적인 데이터를 이용하여 개발될 수 있으며 어떤 경우에는 동작을 개선하도록 조정될 수 있다.
턴 어라운드 1
몇 가지 인자가 턴 어라운드 1 필드의 결정에 기여하며, 이들은 순방향 링크 데이터 레이트, 호스트 내 MDDI_Data 드라이버의 최대 디스에이블 시간, 및 일반적으로 호스트 디스에이블 시간과 동일한 클라이언트 드라이버의 인에이블 시간이다. 턴 어라운드 1 필드의 길이는 24·tBIT 로 선택된다 (표 13). 턴 어라운드 1 필드의 순방향 링크 바이트의 수 단위의 길이는 인터페이스 타입 팩터 (Interface Type Factor) 를 이용하여 결장되며, 다음 관계를 이용하여 계산된다:
Figure 112007000702303-pct00016
여기서, 인터페이스 타입 팩터는 타입 1 에 대해 1, 타입 2 에 대해 2, 타입 3 에 대해 4, 타입 4 에 대해 8 이다.
턴 어라운드 2
턴 어라운드 2 에 대해 일반적으로 사용되는 시간의 길이를 결정하는 인자는, 통신 링크의 라운드 트립 지연, 클라이언트 내 MDDI_Data 드라이버의 최대 디스에이블 시간, 및 클라이언트 드라이버 디스에이블 시간과 동일하게 특정되는 호스트 드라이버의 인에이블 시간이다. 최대 호스트 드라이버 인에이블 시간 및 클라이언트 드라이버 디스에이블 시간은 다른 곳에서 특정된다. 라운드 트립 지연은 tBIT 의 단위로 측정된다. 턴 어라운드 2 필드의 순방향 링크 바이트의 수로 특정되는 최소 길이는 다음 관계에 따라 계산된다:
Figure 112007000702303-pct00017
예를 들어, 10 순방향 링크 클록의 라운드 트립 지연을 갖는 타입 3 순방향 링크는 통상 다음 오더의 턴 어라운드 2 지연을 이용한다:
Figure 112007000702303-pct00018
XII. 다른 역방향 링크 타이밍
상술한 타이밍 및 보호 밴드의 사용이 고속 데이터 전송 레이트 인터페이스를 달성하도록 작용하지만, 본 발명자들은 역방향 타이밍 발견을 변경함으로써, 라운드 트립 시간보다 더 짧은 역방향 비트 길이를 가능케 하는 기술을 발견하였다.
상술한 바와 같이, 역방향 링크의 타이밍에 대한 이전의 접근법은, 역방향 타이밍 패킷의 보호 시간 1 의 마지막 비트로부터 IO 클록의 상승 에지에서 첫 번째 비트가 샘플링 될 때까지 클록 사이클의 수가 카운팅되도록 구성된다. 그것은, MDDI 에 대한 입력 및 출력을 타이밍하는데 사용되는 클록 신호(들)이다. 역방향 레이트 제수 (divisor) 에 대한 계산은 다음과 같이 주어진다:
Figure 112007000702303-pct00019
이는 매우 신뢰성 있는 역방향 링크를 가져오는 라운드 트립 지연과 동일한 비트폭을 제공한다. 그러나, 그 역방향 링크는 더 빠르게, 즉, 더 높은 데이터 전송 레이트로 구동할 수 있음이 보여져 왔고, 본 발명자들은 이를 이용한다. 새로운 발명의 기술은 인터페이스의 추가적인 능력을 이용하여 더 높은 속도를 달성할 수 있게 한다.
이는 호스트가 1 이 샘플링 될 때까지 클록 사이클의 수를 카운팅하게 함으로써 달성되며, 그 호스트는 역방향 타이밍 패킷 동안에 상승 에지 및 하강 에지 모두에서 데이터 라인을 샘플링한다. 이것은 비트가 안정적임을 보장하기 위하여 호스트가 역방향 비트 내에서 가장 유용하거나 훨씬 최적인 샘플링 포인트를 선택할 수 있게 한다. 즉, 역방향 트래픽 역방향 캡슐화 패킷에 대한 데이터를 샘플링하기 위해 가장 유용하거나 최적인 상승 에지를 찾는 것이다. 최적 샘플링 포인트는, 첫 번째 1 이 상승 에지 또는 하강 에지에서 발견되었는지 여부 및 역방향 링크 제수 모두에 의존한다. 새로운 타이밍 방법은 호스트가 역방향 캡슐화 패킷의 어디에서 샘플링할지를 판정하기 위해, 역방향 링크 타이밍에 대하여 클라이언트에 의해 송신된 OxFF OxFF OxOO 패턴의 제 1 에지를 탐색하기만 할 수 있게 한다.
도달하는 역방향 비트의 예 및 그 비트가 다양한 역방향 레이트 제수를 탐색하는 방법이, 보호 시간 1 의 마지막 비트 이래로 발생된 다수의 클록 사이클과 함께 도 64 에 도시된다. 도 64 에서, 제 1 에지가 상승 에지와 하강 에지 (상승/하강으로 표시함) 사이에 발생하면, 1 의 역방향 레이트 제수에 대한 최적의 샘플링 포인트인 최적의 샘플 포인트는, 그것이 역방향 비트의 기간 내에서 발생하는 유일한 상승 에지이므로, 'b' 로 표시된 클록 사이클 에지임을 알 수 있다. 2 의 역방향 레이트 제수에 대하여, 최적의 샘플링 포인트는, 사이클 에지 'c' 가 'b' 보다 비트 에지에 더 근접하므로, 여전히 클록 사이클 리딩 에지 (leading edge) 'b' 일 것이다. 4 의 역방향 레이트 제수에 대하여, 최적의 샘플링 포인트는, 아마도 값이 안정화된 역방향 비트의 백 에지 (back edge) 에 더 근접하므로, 아마도 클록 사이클 에지 d' 일 것이다.
그러나, 도 64 를 다시 참조하면, 제 1 에지가 하강 에지와 상승 에지 (하강/상승으로 표시함) 사이에서 발생하면, 1 의 역방향 레이트 제수에 대한 최적의 샘플링 포인트는, 그것이 역방향 비트 시간 기간 내의 유일한 상승 에지이므로, 샘플링 포인트 클록 사이클 에지 'a' 이다. 2 의 역방향 레이트 제수에 대하여, 최적의 샘플링 포인트는 에지 'b' 이며, 4 의 역방향 레이트 제수에 대하여, 최적의 샘플링 포인트는 에지 'c' 이다.
역방향 레이트 제수가 점점 더 커짐에 따라, 중앙에 가장 근접한 상승 에지여야 하므로, 최적의 샘플링 포인트는 확인 또는 선택하기가 더 용이해 진다.
호스트는 이러한 기술을 이용하여, 타이밍 패킷 데이터의 상승 데이터 에지가 데이터 라인 상에서 관측되기 전에 상승 클록 에지의 개수를 알 수 있다. 그 후, 에지가 상승 에지와 하강 에지 사이 또는 하강 에지와 상승 에지 사이 중 어디에서 발생하는지, 그리고 역방향 레이트 제수가 무엇인지에 기초하여, 비트가 항상 가능한 한 중앙에 가깝게 샘플링 되도록 타당성 있게 보장하기 위해 얼마나 많은 추가적인 클록 사이클이 넘버 카운터에 추가될지를 결정할 수 있다.
일단 호스트가 클록 사이클의 수를 선택 또는 결정하였으면, 클라이언트와 함께 다양한 역방향 레이트 제수를 "탐색" 하여, 특정 역방향 레이트 제수가 작동할 것인지를 결정할 수 있다. 호스트 (및 클라이언트) 는 1 의 제수로 시작하고 클라이언트로부터 수신된 역방향 상태 패킷의 CRC 를 확인하여, 이 역방향 레이트가 데이터를 전송하도록 적절하게 기능하는지를 결정할 수 있다. 만약 CRC 가 틀리면, 샘플링 오류가 존재할 가능성이 있으며, 호스트는 역방향 레이트 제수를 증가시키고 상태 패킷을 다시 요청하려 할 수 있다. 두 번째 요청된 패킷이 틀리면, 제수가 다시 증가되고 요청이 다시 이루어질 수 있다. 만약 이 패킷이 정확하게 디코딩되면, 이 역방향 레이트 제수는 모든 추후의 역방향 패킷에 대해 이용될 수 있다.
이 방법은, 역방향 타이밍이 초기의 라운드 트립 타이밍 추정치로부터 변경되지 않기 때문에 효과적이고 유용하다. 만약 순방향 링크가 안정적이면, 클라이언트는 역방향 링크 실패가 존재하더라도 순방향 링크 패킷을 계속 디코딩할 것이다. 물론, 이 방법은 완전한 역방향 링크를 보장하지 않기 때문에, 링크에 대한 역방향 링크 제수를 설정하는 것은 여전히 호스트의 책임이다. 또한, 제수는, IO 클록을 발생시키는데 이용되는 클록의 품질에 주로 의존한다. 만약 그 클록이 상당한 양의 지터 (jitter) 를 가지면, 샘플링 오류의 확률이 더 크다. 이러한 오류 확률은 라운드 트립 지연에서의 클록 사이클의 양과 함께 증가한다.
이러한 구현은 타입 1 역방향 데이터에 대하여 가장 잘 작동할 것으로 보이지만, 오직 하나의 데이터 쌍에 대해 효과가 있는 레이트로 링크를 구동시키기에 잠재적으로 너무 큰 데이터 라인들 사이의 스큐 (skew) 로 인해 타입 2 내지 타입 4 역방향 데이터에 대하여서는 문제를 나타낼 수도 있다. 그러나, 데이터 레이트는, 아마 동작을 위한 타입 2 내지 타입 4 에 대해서도 이전의 방법으로 감소될 필요는 없을 것이다. 또한, 이러한 방법은, 이상적인 또는 최적의 클록 샘플 위치를 선택하기 위해 각각의 데이터 라인에 복제될 경우에 가장 잘 작동할 수 있다. 만약 각각의 데이터 쌍에 대하여 그들이 동일한 샘플 시간에 있으면, 이 방법은 계속 작동하게 된다. 만약 그들이 상이한 샘플 주기에 있으면, 2 개의 상이한 접근법이 사용될 수 있다. 첫 번째는, 각각의 데이터 쌍에 대하여 동일하지 않더라도, 각각의 데이터 포인트에 대한 소망의 또는 더 최적의 샘플 위치를 선택하는 것이다. 그 후 호스트는 데이터 쌍의 세트로부터 모든 비트, 즉, 타입 2 에 대하여 2 비트, 타입 3 에 대하여 4 비트, 그리고 타입 4 에 대하여 8 비트를 샘플링한 이후에 데이터 스트림을 재구성할 수 있다. 다른 선택은, 모든 데이터 쌍에 대한 데이터 비트가 동일한 클록 에지에서 샘플링 될 수 있도록 호스트가 역방향 레이트 제수를 증가시키는 것이다.
XIII. 링크 지연 및 스큐의 효과
MDDI_Data 쌍과 MDDI_Stb 사이의 순방향 링크에 대한 지연 스큐는, 지연 스큐 보상이 사용되지 않으면, 최대 가능한 데이터 레이트를 제한할 수 있다. 타이밍 스큐를 야기하는 지연의 차이는, 아래에서 개략적으로 설명되는 제어기 로직, 라인 드라이버 및 수신기, 그리고 케이블 및 커넥터에 기인한다.
A. 스큐에 의해 제한되는 링크 타이밍 분석 (MDDI 타입 1)
1. 타입 1 링크의 지연 및 스큐 예
타입 1 인터페이스 링크를 수용하기 위한, 도 41 에 도시된 것과 유사한 통상의 인터페이스 회로가 도 57 에 도시되어 있다. 도 57 에서, 전송 지연 및 스큐에 대한 예시적 또는 통상적인 값이 MDDI 타입 1 순방향 링크의 수개의 프로세싱 또는 인터페이스 스테이지 각각에 대하여 나타나 있다. 도 58 에 나타낸 바와 같이, MDDI_Stb 와 MDDI_Data0 사이의 지연에서의 스큐는 출력 클록의 듀티 사이클이 왜곡되게 한다. 몇몇 경우, 이것은 RXFF 스테이지로의 설정 시간을 매우 작게 한다. 플립 플롭 (5728, 5732) 을 이용하는 수신기 플립-플롭 (RXFF) 스테이지의 D 입력에서의 데이터는, 클록 에지 이후에 약간 변하여 신뢰성 있게 샘플링될 수 있다. 도면은, 이러한 타이밍 관계를 생성하는데 있어서의 2 개의 상이한 문제를 해결하는데 이용되는 2 개의 캐스케이드 된 지연 라인 (5732a 및 5732b) 을 도시한다. 실제 구현에서, 이들은 단일 지연 엘리먼트로 결합될 수 있다.
인터페이스를 통한 예시적인 신호 프로세싱에 대한 타입 1 상의 데이터, Stb, 및 클록 복원 타이밍은 도 58 에 도시되어 있다.
일반적으로, 현저한 총 지연 스큐는 다음의 스테이지에서의 스큐의 합으로부터 생기거나 발생한다: 플립-플롭 (5704, 5706) 을 갖는 송신기 플립-플롭 (TXFF); 드라이버 (5708, 5710) 를 갖는 송신기 드라이버 (TXDRVR); 케이블 (5702); 수신기 (5722, 5724) 를 갖는 수신기 라인 수신기 (RXRCVR); 및 수신기 XOR 로직 (RXXOR). 지연1 (Delay1; 5732a) 은 다음의 관계식
Figure 112007000702303-pct00020
에 의해 결정되는 RXXOR 스테이지에서의 XOR 게이트 (5736) 의 지연과 매치되거나 그를 초과해야 한다.
이 요건을 만족하여 수신기 플립-플롭 (5728, 5732) 의 D 입력이 그 클록 입력 전에 변하지 않는 것이 바람직하다. 이것은, RXFF 의 홀드 시간 (hold-time) 이 0 인 경우에 성립한다.
지연2 의 목적 또는 기능은 다음의 관계식
Figure 112007000702303-pct00021
에 따라 RXFF 플립-플롭의 홀드 시간을 보상하는 것이다.
많은 시스템에서, 홀드-시간이 0 이기 때문에 이것은 0 일 것이고, 당연히 그 경우, 지연2 의 최대 지연 또한 제로일 수 있다.
수신기 XOR 스테이지에서의 스큐에 대한 최악의 경우의 기여는, 지연1 은 최대값이며 XOR 게이트로부터의 클록 출력은 다음의 관계식
Figure 112007000702303-pct00022
에 따라 가능하면 조기에 나오는 데이터-레이트/스트로브-얼리 (data-late/strobe-early) 경우에서이다.
이 상황에서, 데이터는 시간에 대하여 매우 근접한 2 개의 비트 주기, n 및 n+1 사이에서 변할 수 있으며, 여기서, 비트 n+1 은 수신기 플립-플롭에 클록 (clock) 된다.
MDDI 타입 1 링크의 최대 데이터 레이트 (최소 비트 주기) 는 MDDI 링크에서의 모든 드라이버, 케이블, 및 수신기를 통해 만나는 최대 스큐 더하기 RXFF 스테이지로의 총 데이터 설정의 함수이다. RXRCVR 스테이지의 출력까지의 링크에서의 총 데이터 스큐는 다음과 같이 표현될 수 있다:
Figure 112007000702303-pct00023
"케이블" 은 다양한 콘덕터 또는 상호 접속이나 배선 및 해당 지연을 나타내며, 최소 비트 주기는 다음과 같이 주어진다:
Figure 112007000702303-pct00024
도 57 에 도시된 예에서, 외부 모드에 대해
Figure 112007000702303-pct00025
=1000 psec 이며, 최소 비트 주기는 다음
Figure 112007000702303-pct00026
과 같이 표현되거나, 약 434 Mbps 라 할 수 있다. 도 57 에 도시된 예에서, 내부 모드에 대해,
Figure 112007000702303-pct00027
=500 psec 이고, 최소 비트 주기는 다음
Figure 112007000702303-pct00028
과 같이 표현되거나, 약 555 Mbps 라 할 수 있다.
호스트가 지연 스큐 교정 패킷을 사용하면, 다음의 식
Figure 112007000702303-pct00029
의 스큐 교정으로 호스트에 대한 클록 지터 요건 및 최대 지연 비대칭, 및
Figure 112007000702303-pct00030
의 스큐 교정으로 호스트에 대한 최대 지연 스큐 요건에 의해 정의되는 바와 같은 호스트 디바이스에서 지연 비대칭, 지연 스큐 및 클록 지터의 추가적인 요건이 존재한다.
B. MDDI 타입 2, 3, 및 4 에 대한 링크 타이밍 분석
타입-2, 3, 및 4 인터페이스 링크를 수용하기 위한, 도 41 및 57 에 도시된 것과 유사한 통상의 인터페이스 회로가 도 59 에 도시되어 있다. 추가적인 신호 프로세싱을 수용하기 위하여, TXFF (5904), TXDRVR (5908), RXRCVCR (5922) 및 RXFF (5932, 5928, 5930) 스테이지에 추가적인 요소가 사용된다. 도 59 에서, 전파 지연 및 스큐에 대한 예시적이거나 통상적인 값이 MDDI 타입 2 순방향 링크의 수개의 프로세싱 또는 인터페이스 스테이지 각각에 대하여 나타나 있다. 출력 클록의 듀티 사이클에 영향을 주는 MDDI_Stb 와 MDDI_Data0 사이의 지연에서의 스큐에 더하여, 이들 2 개의 신호 모두와 다른 MDDI_Data 신호 사이의 스큐도 존재한다. 플립-플롭 (5928, 5930) 으로 구성된 수신기 플립-플롭 B (RXFFB) 스테이지의 D 입력에서의 데이터는, 클록 에지 직후에 약간 변하여 신뢰성 있게 샘플링될 수 있다. MDDI_Data1 이 MDDI_Stb 또는 MDDI_Data0 보다 먼저 도착하면, MDDI_Data1 은 샘플링되기 위해 적어도 지연 스큐의 양만큼 지연되어야 한다. 이것을 달성하기 위하여, 데이터는 지연3 지연 라인을 이용하여 지연된다. MDDI_Data1 이 MDDI_Stb 또는 MDDI_Data0 보다 더 늦게 도착하고, 또한 지연 3 만큼 지연되면, MDDI_Data1 이 변경되는 포인트는 그 다음 클록 에지에 더 근접하게 이동된다. 이 프로세스는 MDDI 타입 2, 3, 또는 4 링크의 데이터 레이트의 상한을 결정한다. 2 개의 데이터 신호와 MDDI_Stb 의 서로에 대한 타이밍 또는 스큐 관계에 대한 일부 상이한 예시적 가능성이 도 60a, 60b, 및 60c 에 도시된다.
MDDI_DataX 가 가능한 한 조기에 도착할 경우에 RXFFB 에서 신뢰성 있게 데이터를 샘플링하기 위하여, 지연3 은 다음의 관계식에 따라 설정된다:
Figure 112007000702303-pct00031
최대 링크 속도는 최소 허용 가능 비트 주기에 의해 결정된다. 이것은 MDDI_DataX 가 가능한 늦게 도착하는 경우에 가장 영향을 받는다. 그 경우, 최소 허용 가능 사이클 시간은 다음으로 주어진다:
Figure 112007000702303-pct00032
그러면, 링크 속도의 상한은
Figure 112007000702303-pct00033
이고, 그 가정 하에서,
Figure 112007000702303-pct00034
이다.
상기 예에서, 최소 비트 주기의 하한은 다음의 관계에 의해 주어진다:
Figure 112007000702303-pct00035
이는 약 174 Mbps 이다.
이는 타입 1 에 사용될 수 있는 최대 데이터 레이트보다 훨씬 느리다. MDDI 의 자동 지연 스큐 보상 기능은 지연 스큐가 최대 링크 레이트에 대해 갖는 영향을 현저히 감소시키며, 이는 유효 데이터 설정의 바로 경계의 (on-the-edge) 요인이다. MDDI_Data0 와 MDDI_Stb 사이의 교정된 스큐는
Figure 112007000702303-pct00036
이고, 최소 비트 주기는
Figure 112007000702303-pct00037
이다.
"TB" 또는 tB 가 비트 경계로부터 최소 출력 레벨까지의 신호 지터인 경우, 비대칭은 단순히 차동 수신기를 통한 또는 차동 수신기의 내부 지연의 비대칭 특성을 지칭한다. "TP4" 는 클라이언트에 대한 수신기와 차동 라인 드라이버에 대한 접속 또는 인터페이스 (클라이언트 내 MDDI 제어기 장치의 핀) 와 같은 전기적 특성 및 테스트 목적과 관련되거나 이를 위해 효과적으로 정의된다. 이는 신호 지연이 측정되고 시스템의 나머지 부분을 통한 링크에 대해 특징지워지는 편리한 또는 미리 정해진 점을 나타낸다. 일 실시형태에서, TP4 에서의 파라미터 tB 의 최대값은 클라이언트 송신기에 대해서, 외부 모드에 대해 관계
Figure 112007000702303-pct00038
에 의해 정의되고, 내부 모드에 대해
Figure 112007000702303-pct00039
에 의해 정의되며, 클라이언트 수신기에 대한 외부 모드에 대해서는
Figure 112007000702303-pct00040
로 정의된다.
레이블 TP4 는 인터페이스 및 링크의 다양한 테스트 지점 (TP) 에 번호를 메기는데 유용하다. 일 실시형태에서, 이 테스트 지점 위치는 냅 및 외부 모드에 대해 동일하게 정의된다. 차동 라인 드라이버 및 수신기를 포함하는 호스트 내의 MDDI 제어기 장치의 접속 또는 인터페이스 핀을 위한, 또는 그와 관계된 해당 "TP0" 테스트 지점이 존재한다. 이 실시형태에서, TP0 에서의 파라미터 TB 의 최대값은 호스트 수신기에 대하여, 내부 모드에 대해 관계
Figure 112007000702303-pct00041
로 정의되고, 외부 모드에 대해
Figure 112007000702303-pct00042
로 정의되며, 호스트 송신기에 대해
Figure 112007000702303-pct00043
로 정의된다.
도 59 에 도시된 예에서,
Figure 112007000702303-pct00044
이고, 최소 비트 주기는
Figure 112007000702303-pct00045
,
약 606 Mbps 이다.
MDDI_Data1 이 가능한 한 빨리 도착하는 경우에 RXFFB 에서 데이터를 신뢰성 있게 샘플링하기 위해, 관련된 프로그램 가능 지연은 1 탭 (tap) 의 정확성으로 최적 설정으로 조정되며, 추가적인 탭 지연이 안전을 위해 추가된다. 최대 링크 속도는 최소 허용 가능 비트 주기에 의해 결정된다. 이는 MDDI_Data1 가 가능한 한 빨리 도착하는 경우에 가장 영향을 받는다. 그 경우, 최소 허용 가능 사이클 시간은:
Figure 112007000702303-pct00046
이고, 여기서 "TA" 또는 tA 는 비트 경계로부터 센터 크로싱 (crossing) 까지의 신호 지터를 나타낸다.
도 59 에 주어진 예에서, MDDI_Data1 의 샘플링에 기초한 최소 비트 주기의 하한은 다음과 같다:
Figure 112007000702303-pct00047
일 실시형태에서, 내부 모드에 대한 호스트 송신기에서의 지연 스큐, 지연 비대칭 및 클록 지터에 대한 통상적인 총 지연 시간은
Figure 112007000702303-pct00048
으로 정의되고, 외부 모드에 대해서는
Figure 112007000702303-pct00049
으로 정의되는 반면, 내부 모드에 대한 클라이언트 장치에서의 지연 스큐, 지연 비대칭, 및 설정 시간에 대한 통상적인 총 지연 시간 (tB-TP4) 은
Figure 112007000702303-pct00050
이고, 외부 모드에 대해서는
Figure 112007000702303-pct00051
이며, 여기서 TBD 라는 용어는 외부 모드 접속에 대해 잘 알려진 다양한 특성 및 동작 요구사항에 의존하여 추후 결정될 값의 레이블을 보유하는 유연한 장소이다.
도 59 에서와 유사하게, 지연 스큐 보상 회로를 갖는, MDDI 타입 2 순방향 링크에 대한 실시형태의 통상적 인터페이스 회로가 도 61 에 도시되어 있다. RXRCVCR 단 후에, 선택가능한 지연 엘리먼트 (6102 및 6104) 라는 추가적인 엘리먼트가 사용되고, 이와 함께 교정 입력 드라이버 (6106 및 6108) 가 각각 AND 게이트 (6112 및 6114) 에 결합되며, 그 출력은 차례로 XOR 게이트 (6116) 에 접속된다. XOR 게이트 (6116) 는 도시한 바와 같이 RXFFA 단에 입력을 제공한다. 이러한 엘리먼트들은 추가적인 신호 프로세싱을 수용하기 위해 사용된다. 드라이버 (6108 및 6106) 는, 각각 드라이버 (5724 및 5924) 의 출력에 대한 신호 전송 경로를 위해 선택가능한 양의 지연이 주입 또는 사용되게 한다.
이 예에서는, 데이터 및 스트로브 신호의 상대적 도달 시간을 미세하게 조율하기 위해 가변 지연 (6102 및 6104) 가 사용된다. 이 신호들의 도달 시간을 정렬하는 것은 수신기의 D 플리플롭 (5728, 5730, 5928, 5930) 입력에서의 데이터가 미리 양호하게 설정되게 한다. 클라이언트 디바이스가 순방향 링크 스큐 교정 패킷의 교정 데이터 시퀀스 필드를 수신하는 경우, 단순한 상태 머신이 모든 차동 쌍 신호의 동시적 천이를 조사하여, 최적의 조절가능한 지연 설정을 결정할 수 있다. 상태 머신은 가변 지연을 조절하기 위해 연속적인 근사 알고리즘을 사용하여, 데이터가 안전하게 샘플링될 수 있는 지점을 발견하고, 신뢰할 수 있는 동작을 위해 가장 안전한 설정쪽으로 지연을 1 탭만큼 조절할 수 있다 (MDDI_Stb 경로 상에서는 1 미만의 탭이고, MDDI_Data 경로 상에서는 1 초과의 탭일 것이다). 교정 데이터 시퀀스 필드는 모든 차동 쌍에서 다수의 동시적 천이를 포함하여 이를 용이하게 한다.
도 61 에 주어진 이 예에서, MDDI_Data1 을 샘플링하는데 기반한 최소 비트 주기의 하한은:
Figure 112007000702303-pct00052
이다.
이것은 MDDI_Data1 에 대한 교정되지 않은 링크 타이밍에 비해 현저한 개선이다. 그러나, 지연 스큐 교정 링크 상에서 최대 데이터 레이트에 대한 하나의 잠재적 결정 인자는, 전술한 예에서 나타낸 바와 같이 MDDI_STb 와 MDDI_Data0 사이의 지연을 매칭시키는 능력에 의해 통상적으로 제한될 것이다. 도 61 의 지연5 에 정교한 조절을 제공하는 것과 같이, 본 명세서에서 설명하는 스큐 보상 아키텍쳐에 대해 많은 가능한 개선이 존재한다.
지연 스큐 보상이 이용되는 경우, 호스트 드라이버 출력에서 허용되거나 허용될 수 있는 차동 스큐의 양에는 통상적으로 상한이 존재한다. 이것은 내부 및 외부 모드 모두에 대해 정의된다. 이러한 제한 또는 한계가 없다면, 매우 저속으로 동작하는 호스트 디바이스에 대한 클라이언트 디바이스에서의 정정이 필요한 매우 넓은 범위의 차동 스큐가 존재할 것이다. 스큐 보상의 주 용도는, 디바이스가 더 고속으로 동작하도록 지연 스큐를 감소시키는 것이기 때문에, 통상적으로 지연 스큐의 최대 한계는 지연 스큐 보상을 사용하는 호스트에 대한 시스템 또는 디바이스 설계자에 의해 특정된다. 클라이언트 디바이스에 사용되는 스큐 보상의 총 양은 다음의 3 개의 파라미터의 합이다. 도 61 에서 TXFF + TXDRVR 단의 최대 지연 스큐인, 호스트 드라이버 출력의 최대 차동 스큐; 도 61 에서 CABLE 단의 최대 지연 스큐인, TP0 내지 TP4 까지의 상호접속 서브 시스템에서 최대 차동 스큐; 및 차동 수신기 입력과 데이터 샘플링 회로 사이에서 클라이언트의 최대 차동 스큐. 후자의 파라미터는 도 61 에서 RXRCVR 단의 입력으로부터 RXFFA 및 RXFFB 단의 입력까지의 최대 지연 스큐이다.
XIV. 물리 계층 상호접속 설명
본 발명에 따른 인터페이스를 구현하는데 유용한 물리 접속은, 호스트 측에서 Hirose Electric Company Ltd. 에 의해 제조된 부품 번호 3260-8S2(01) 및 클라이언트 장치 측에서 Hirose Electric Company Ltd. 에 의해 제조된 부품 번호 3240-8P-C 와 같이 상업적으로 이용가능한 부품을 이용하여 실현될 수 있다. 타입 1/타입 2 인터페이스와 이용되는 그러한 커넥터에 대한 예시적인 인터페이스 핀 할당 또는 "핀아웃 (pinout)" 이 표 15 에 나열되어 있고 도 61 에 도시되어 있다.
Figure 112007000702303-pct00053
실드는 호스트 인터페이스에서 HOST_Gnd 에 접속되며, 케이블 내의 실드 드레인 와이어는 클라이언트 커넥터의 실드에 접속된다. 그러나, 실드 및 드레인 와이어는 클라이언트 내부의 회로 그라운드에 접속되지 않는다.
상호접속 엘리먼트 또는 장치는, 상대적인 장치 크기에 비해 거슬리거나 추하지 않고, PDA 및 무선 전화, 또는 휴대형 게임 장치와 같은 이동 통신 및 컴퓨팅 장치와 함께 사용하기에 충분히 작도록 선택 또는 설계된다. 여하한 커넥터 및 케이블링도 통상적인 소비자 환경에서 이용하기에 충분히 내구력이 있어야 하며, 특히, 케이블링에 대하여 작은 크기 및 상대적으로 낮은 비용을 제공하여야 한다. 전송 엘리먼트는, 타입 1 및 타입 2 에 대하여 약 450 Mbps 까지, 그리고 8-비트 병렬 타입 4 버전에 대하여 3.6 Gbps 까지의 전송 레이트를 갖는 차동 NRZ 데이터인 데이터 및 스트로브 신호를 수용해야 한다.
내부 모드 애플리케이션의 경우, 콘덕터에 대하여 동일한 의미로 사용되는 커넥터가 없거나 그러한 접속 엘리먼트가 극히 소형화되는 경향이 있다. 일 예는, 집적회로를 수용하기 위한 제로 삽입 포스 (zero insertion force) "소켓" 이나 호스트 또는 클라이언트 장치를 하우징하는 엘리먼트이다. 다른 예는, 호스트 및 클라이언트가 다양한 상호접속 콘덕터로 인쇄 회로 기판 상에 상주하며 집적회로의 상호접속용 콘덕터 상의 컨택트에 납땜되는, 하우징으로부터 연장하는 "핀" 또는 컨택트를 갖는 것이다.
전술한 내부 모드에서와 같이 2 클라이언트의 접속에 주목하는 경우, 배선, 접속, 및 더 적절한 데이터 전송 및 통신을 위한 주 클라이언트의 배치에서의 특정한 요소들에 주의해야 한다. 클라이언트들을 접속시키는 접속 또는 케이블은 도 99 에서 도시하는 구성에서 설명하는 바와 같이 종단되지 않은 스터브 (stub) 를 필수적으로 포함하는 송신 라인을 형성한다. 도 99 에서, 호스트 (9902) 는, 각각 위치 A 및 B 에서 호스트로부터 클라이언트로 신호를 공급 또는 전송하는 2 개의 스터브 (여기서는 스터브1 및 스터브2) 로 분기되는 콘덕터 (9904) 를 통해 접속되도록 도시되어 있다. 또한, 본 발명의 실시형태 또는 애플리케이션을 단지 설명하기 위한 목적이고 제한하려는 것이 아니며, 클라이언트는 LCD 제어기 또는 LCD 디스플레이 소자 또는 패널의 일부, 또는 그에 접속되거나, 결합되거나 통신하는 것으로 도시된다. 이러한 2 개의 클라이언트 디바이스가 내부 모드로 접속되는 경우, MDDI_Data 쌍 상에서 수신 및 송신하고 종단 저항 (임피던스) 과 함께 위치되는 주 클라이언트 디바이스는, 도 99 에서 "위치 A" 로 특정되고 길이 Lstub1 이하의 길이 Lstub2 을 갖는 케이블의 "말단" 에 위치 또는 접속된다. 다른 클라이언트 (또는 몇몇 예에서의 클라이언트) 는, 도 99 에서 "위치 B" 로 특정되고 그 말단과 호스트의 중간에 위치되는 케이블로부터의 브랜치의 "말단" 에 위치 또는 접속된다. 도 99 는 당업자가 본 실시형태를 사용할 때 이러한 송신 라인 스터브가 일반적으로 어떻게 정의되는지를 나타낸다. 본 발명의 다양한 실시형태의 장치 또는 기술을 이용하는 자는, 송신 라인의 속도 인자 및 드라이버 출력 신호의 최소 상승 시간을 고려하면서 신호 품질을 임의의 제한 또는 요건에 충족시켜 적절한 고속 동작 및 에러가 없는 (또는 최소인) 통신을 유지하는 것을 보장하기 위해, 송신 라인에서 스터브의 길이를 한정함으로써 이러한 구성을 구현해야 한다.
XV. 동작
본 발명의 실시형태들을 이용하는 인터페이스의 동작 중에 데이터 및 패킷을 프로세싱함에 있어서 수행되는 일반적인 단계의 요약이, 도 55 에서 패킷을 프로세싱하는 인터페이스 장치의 개요과 함께, 도 54a 및 도 54b 에 도시된다. 이들 도면에서, 프로세스는, 여기에서 케이블인 통신 경로를 이용하여 클라이언트와 호스트가 접속되어 있는지 여부에 대하여 판정하는 단계 (5402) 에서 시작한다. 이것은, (USB 인터페이스에 대하여 관측되는 바와 같이) 호스트로의 입력에서의 커넥터 또는 케이블 또는 신호의 존재를 검출하는 소프트웨어 또는 하드웨어, 또는 다른 공지의 기술을 이용한, 호스트에 의한 주기적인 폴링의 사용을 통하여 발생할 수 있다. 호스트에 접속된 클라이언트가 없으면, 애플리케이션에 의존한 어떠한 소정 길이의 대기 상태에 진입하거나, 휴지 모드 (hibernation mode) 로 진입하거나, 사용자가 호스트를 재활성화시키도록 동작을 취할 것을 요구할 수 있는 추후 사용을 대기하도록 불활성화될 수 있다. 예를 들어, 호스트가 컴퓨터 타입 장치에 상주할 경우, 사용자는 스크린상의 아이콘을 클릭하거나, 클라이언트를 검색하도록 호스트 프로세싱을 활성화시키는 프로그램을 요청해야 할 수 있다. 또한, 호스트 또는 상주 호스트 소프트웨어의 능력 및 구성에 의존하여, USB 타입 접속의 단순한 플러그-인이 호스트 프로세싱을 활성화시킬 수 있다.
일단 클라이언트가 호스트에 접속되거나 호스트가 클라이언트에 접속되거나, 존재하는 것으로서 검출되면, 단계 5404 및 5406 에서, 클라이언트 또는 호스트는 서비스를 요청하는 적절한 패킷을 전송한다. 단계 5404 에서, 클라이언트는 클라이언트 서비스 요청 또는 상태 패킷을 전송할 수 있다. 상술한 바와 같이, 링크는 미리 셧다운 되거나 휴지 모드일 수 있으므로, 이것은 후속하는 통신 링크의 완전한 초기화가 아닐 수도 있음을 유의하라. 일단 통신 링크가 동기화되고, 호스트가 클라이언트와의 통신을 시도하고 있으면, 단계 5408 에서와 같이, 클라이언트 또한 클라이언트 능력 패킷을 호스트에 제공한다. 이제 호스트는 전송 레이트 등 클라이언트가 수용할 수 있는 지원의 타입의 결정을 시작할 수 있다.
또한, 일반적으로, 단계 5410 에서, 호스트 및 클라이언트는 이용될 서비스 모드의 타입 (레이트/속도), 예를 들어, 타입 1, 타입 2 등을 협상한다. 일단 서비스 타입이 확립되면, 호스트는 정보를 전송하기 시작할 수 있다. 또한, 단계 5411 에 도시된 바와 같이, 호스트는 라운드 트립 지연 측정 패킷을 이용하여, 다른 신호 프로세싱과 병렬로 통신 링크의 타이밍을 최적화할 수도 있다.
전술한 바와 같이, 모든 전송은, 단계 5412 에서 전송되는 것으로 나타낸 서브 프레임 헤더 패킷으로 시작하고, 그 후, 여기에서 비디오 및 오디오 스트림 패킷인 데이터의 타입 및 단계 5414 에서 전송되는 것으로 나타낸 필러 패킷이 후속한다. 오디오 및 비디오 데이터는 미리 준비되거나 패킷에 매핑되며, 필러 패킷들은 필요하거나 원할 경우에 삽입되어, 미디어 프레임에 대하여 필요한 수의 비트를 채운다. 호스트는 순방향 오디오 채널 인에이블 패킷과 같은 패킷을 전송하여 사운드 장치를 활성화시킬 수 있다. 또한, 호스트는, 단계 5416 에서의 컬러맵, 비트맵 블록 전송 또는 다른 패킷의 전송로서 여기에 나타낸, 상술한 다른 패킷 타입을 이용하여 명령 및 정보를 전송할 수 있다. 또한, 호스트 및 클라이언트는 적절한 패킷을 이용하여 키보드 또는 포인팅 장치에 관한 데이터를 교환할 수 있다.
동작 동안, 수개의 상이한 이벤트 중 하나가 발생할 수 있으며, 이는 호스트 또는 클라이언트가 상이한 데이터 레이트 또는 인터페이스 모드의 타입을 희망하도록 한다. 예를 들어, 데이터를 통신하는 컴퓨터 또는 다른 장치는, 데이터를 프로세싱 함에 있어, 패킷의 준비 또는 프리젠테이션에서의 속도 감소 (slow down) 을 야기하는 로딩 조건을 만날 수 있다. 데이터를 수신하는 클라이언트 장치는 전용 AC 전원으로부터 더 제한된 배터리 전원으로 변할 수 있으며, 데이터를 신속하게 전송하거나 커맨드를 용이하게 프로세싱할 수 없거나, 더 제한된 전력 설정 하에서 동일한 정도의 해상도 또는 컬러를 이용하지 못할 수도 있다. 다르게는, 어느 하나의 장치가 더 고속의 레이트로 데이터를 전송할 수 있도록 제한된 조건이 감소되거나 사라지게 할 수 있다. 이것이 더 바람직하므로, 더 높은 전송 레이트 모드로 변경하도록 요청될 수 있다.
이들 또는 다른 타입의 기지(旣知)의 조건들이 발생하거나 변경되면, 호스트 또는 클라이언트는 그 조건을 검출하고 인터페이스 모드의 협상을 시도할 수도 있다. 이것은 단계 5420 에 도시되고, 여기서 호스트가 다른 모드로의 핸드오프를 요청하는 클라이언트로 인터페이스 타입 핸드오프 요청 패킷을 전송하고, 클라이언트가 변경을 원함을 확인하는 인터페이스 타입 확인 응답 패킷을 전송하며, 특정 모드로 변경하기 위해 호스트가 수행 타입 핸드 오프 패킷을 전송한다.
특정 순서의 프로세싱을 요구하는 것은 아니지만, 클라이언트 및 호스트는 또한 포인팅 장치, 키보드, 또는 그러한 엘리먼트가 호스트 측에 존재할 수도 있지만 클라이언트와 주로 관련된 다른 사용자 타입 입력 장치를 위해 의도되거나 그 장치로부터 수신된 데이터에 관한 패킷들을 교환할 수 있다. 통상적으로, 이들 패킷은, 상태 머신 (5502) 가 아닌 범용 프로세서 타입 엘리먼트를 이용하여 프로세싱된다. 또한, 상술한 커맨드 중 일부도 범용 프로세서 (5504, 5508) 에 의해 프로세싱될 것이다.
데이터 및 명령이 호스트와 클라이언트 사이에서 교환된 후, 어떤 포인트에서, 추가적인 데이터가 전송되어야 하는지, 또는 호스트 또는 클라이언트가 전송의 서비스를 중단하는지에 관한 결정이 이루어진다. 이것은 단계 5422 에 도시된다. 만약 링크가 휴지상태에 진입하거나 완전히 셧다운 되어야 하면, 호스트는 링크 셧다운 패킷을 클라이언트에게 전송하고, 양측은 데이터의 전송을 종료한다.
상기 동작 프로세싱에서 전송되는 패킷들은 호스트 및 클라이언트 제어기에 관련하여 전술한 드라이버 및 수신기를 이용하여 전송될 것이다. 도 55 의 개요에 도시된 바와 같이, 이들 라인 드라이버 및 다른 로직 엘리먼트는 상술된 상태 머신 및 범용 프로세서에 접속된다. 도 55 에서, 상태 머신 (5502) 및 범용 프로세서 (5504 및 5508) 는, 전용 USB 인터페이스, 메모리 엘리먼트, 또는 데이터 소스 및 비디오 디스플레이 장치용 비디오 제어 칩을 포함하지만 이에 제한되지 않는 링크 제어기 외부에 존재하고 이들과 상호 작용하는 기타 소자 등의 도시되지 않은 다른 엘리먼트에 더 접속될 수 있다.
프로세서 및 상태 머신은 보호 시간 등에 관련하어 상술된 바와 같은 드라이버의 인에이블 및 디스에이블에 대한 제어를 제공하여, 통신 링크의 효율적인 확립 또는 종료, 및 패킷의 전송을 보장한다.
XVI. 디스플레이 프레임 버퍼
비디오 데이터 버퍼링 요건은 컴퓨팅 그래픽에 비하여 비디오 동화상에 대하여 상이하다. 대부분, 픽셀 데이터는 클라이언트의 로컬 프레임 버퍼에 저장되어, 클라이언트 상의 이미지가 국부적으로 (locally) 리프레쉬 (refresh) 되게 할 수 있다.
풀-모션 비디오가 디스플레이되고 있는 경우 (디스플레이 내의 거의 모든 픽셀이 각각의 미디어 프레임마다 변경됨), 보통 그 디스플레이 상의 이미지가 제 2 프레임 버퍼로부터 리프레쉬되는 동안 입력 픽셀 데이터를 하나의 프레임 버퍼에 저장하는 것이 바람직하다. 아래에서 설명되는 바와 같이, 3 개 이상의 디스플레이 버퍼가 가시물 (visible artifact) 을 제거하는데 이용될 수 있다. 하나의 프레임 버퍼에 전체 이미지가 수신되었을 경우, 버퍼의 역할들이 교환될 수 있으며, 새롭게 수신된 이미지는 디스플레이를 리프레쉬하는데 이용되고, 다른 버퍼는 그 다음 프레임의 이미지로 채워진다. 이러한 개념은 도 88a 에 도시되며, 여기서 디스플레이 업데이트 비트를 "01" 로 설정함으로써 픽셀 데이터가 오프라인 이미지 버퍼에 기록된다.
다른 애플리케이션에서, 호스트는 전체 이미지를 다시 칠할 필요없이 이미지의 작은 일부만을 업데이트 할 필요가 있다. 이 상황에서는, 도 88b 에 상세히 도시된 바와 같이, 디스플레이를 리프레쉬하는데 이용되고 있는 버퍼에 새로운 픽셀들을 직접 기록하는 것이 바람직하다.
작은 비디오 윈도우를 갖는 고정된 이미지를 갖는 애플리케이션에서, 도 91c 에 도시된 바와 같이, 고정 이미지를 양 버퍼 모두에 기록한 후 (디스플레이 업데이트 비트는 "11" 과 같음), 디스플레이 업데이트 비트를 "01" 로 설정함으로써 오프라인 버퍼에 동화상의 픽셀을 기록하는 것이 가장 용이하다.
다음의 법칙은, 동시적으로 새로운 정보를 클라이언트에 기록하고 디스플레이를 리프레쉬하는 동안의 버퍼 포인터의 유용한 조작을 설명한다. 3 개의 버퍼 포인터가 존재한다: MDDI 링크를 통한 데이터로부터 현재 채워지고 있는 버퍼로의 current_fill 포인트. 가장 최근에 채워진 버퍼에 대한 just_filled 포인트. 디스플레이를 리프레쉬하는데 현재 이용되고 있는 버퍼에 대한 being_displayed 포인트. 모든 3 개의 버퍼 포인터는 0 부터 N-1 까지의 값을 포함할 수 있으며, 여기서, N 은 디스플레이 버퍼의 개수이며, N ≥ 2 이다. 버퍼 포인터에 대한 계산은 mod N 이며, 예를 들어, N = 3 이고, current_fill = 2 인 경우, current_fill 의 증가는 current_fill 이 0 으로 설정되게 한다. N = 2 인 간단한 경우에, just_filled 는 항상 current_fill 의 컴플리먼트이다. 매 MDDI 미디어 프레임 경계 (서브 프레임 카운트 필드를 갖는 서브 프레임 헤더 패킷은 0 임) 에 대하여, 다음의 동작이 특정 순서대로 수행된다: just_filled 을 current_fill 로 설정하고 current_fill 를 current_fill+1 과 동일하게 설정한다.
MDDI 비디오 스트림 패킷들은 다음의 방법 또는 구조에 따라 버퍼를 업데이트 한다: 디스플레이 업데이트 비트가 '01' 과 같을 경우에 current_fill 에 의해 특정된 버퍼에 픽셀 데이터가 기록된다; 디스플레이 업데이트 비트가 '00' 과 같을 경우에 just_filled 에 의해 특정된 버퍼에 픽셀 데이터가 기록된다; 디스플레이 업데이트 비트가 '11' 과 같을 경우에는 모든 버퍼에 픽셀 데이터가 기록된다. 디스플레이는 being_displayed 포인터에 의해 특정되는 버퍼로부터 리프레쉬된다. 디스플레이가 하나의 프레임 리프레쉬 기간 (refresh epoch) 의 마지막 픽셀을 리프레쉬한 후, 그리고 그 다음 프레임 리프레쉬 기간 내의 제 1 픽셀의 리프레쉬를 시작하기 전에, 디스플레이 업데이트 프로세스는 being_refreshed 를 just_filled 와 같게 설정하는 동작을 수행한다.
픽셀 데이터 속성 필드를 갖는 패킷은, 픽셀 데이터가 기록될 프레임 버퍼를 특정하는 1 쌍의 디스플레이 업데이터 비트를 포함한다. 클라이언트 능력 패킷은, 어떤 디스플레이 업데이트 비트의 조합이 클라이언트에서 지원되는지를 나타내는 3 개의 추가적인 비트를 갖는다. 많은 경우, 컴퓨터로 생성된 이미지는 사용자 입력에 기초하여 또는 컴퓨터 네트워크로부터 수신된 정보로부터 유도되어 증가적으로 (incrementally) 업데이트될 필요가 있다. 디스플레이 업데이트 비트 조합 "00" 및 "11" 은, 픽셀 데이터를 디스플레이되고 있는 프레임 버퍼 또는 양자 모두의 프레임 버퍼에 기록되게 함으로써 이 동작 모드를 지원한다.
비디오 이미지를 수용하는 경우, 도 89 는, 비디오 데이터가 디스플레이 업데이트 비트를 "01" 로 하여 MDDI 링크를 통하여 송신되는 때에 프레임 버퍼의 쌍을 이용하여 비디오 이미지가 어떻게 디스플레이되는지를 도시한다. 미디어-프레임 경계가 MDDI 링크에서 검출된 후, 현재 리프레쉬되고 있는 프레임에 대한 리프레쉬 프로세스가 완료되는 때에 디스플레이 리프레쉬 프로세스가 그 다음 프레임 버퍼로부터 리프레쉬를 시작할 것이다.
도 89 와 관련한 중요한 가정은, 클라이언트가 디스플레이를 리프레쉬하기 위해 프레임 버퍼로부터 픽셀을 판독하는 것과 동일한 순서로 (보통, 행 (row) 단위로 판독하여, 스크링의 좌상부 (upper-left) 코너에서 스크린의 우하부 (bottom-right) 코너로) 전송되는 픽셀의 연속적인 스트림으로서 호스트로부터 이미지가 수신된다는 것이다. 이것은, 디스플레이 리프레쉬 및 이미지 전송 동작이 동일한 프레임 버퍼를 참조하는 경우에 중요한 세부 사항이다.
부분 이미지의 표시를 피하기 위하여, 디스플레이 리프레쉬 프레임 레이트는 이미지 전송 프레임 레이트보다 더 클 필요가 있다. 도 90 은 이미지 분열 (image fragmentation) 이 어떻게 느린 디스플레이 리프레쉬 레이트, 즉 디스플레이 리프레쉬가 이미지 전송보다 느린 레이트로 일어날 수 있는지를 도시한다.
컴퓨터 그래픽 이미지와 비디오 동화상의 조합을 포함하는 이미지에서, 비디오 픽셀 데이터는 미디어 프레임의 작은 부분을 점유할 수 있다. 이것은, 디스플레이 리프레쉬 동작 및 이미지 전송이 동일한 프레임 버퍼를 참조하는 상황에서 중요할 수 있다. 이들 상황은 도 91 에서 그물눈 음영으로 도시되어 있으며, 여기서 디스플레이를 리프레쉬하기 위해 버퍼로부터 판독된 픽셀들은 2 개의 프레임 이전에 버퍼에 기록된 픽셀일 수 있거나, 동일한 프레임 버퍼에 즉시 기록되고 있는 프레임에 대응할 수 있다.
도 92 에 도시된 바와 같이, 클라이언트에서의 3 개의 프레임 버퍼의 이용은, 프레임 버퍼로의 액세스를 위한 작은 윈도우의 쟁탈 (contention) 문제를 해결할 것이다.
그러나, 도 93 에 도시된 바와 같이 디스플레이 리프레쉬 레이트가 MDDI 링크를 통한 미디어-프레임 레이트보다 작으면 여전히 문제가 존재한다.
도 94 에 도시된 바와 같이, 비디오 동영상을 위한 단일 버퍼의 이용은 조금 문제가 있다. 디스플레이 리프레쉬가 버퍼로의 이미지 전송보다 더 빠른 경우, 리프레쉬되고 있는 이미지는 가끔 기록되고 있는 프레임의 상부를 나타내며, 이미지의 하부는 이전에 전송된 프레임이 된다. 디스플레이 리프레쉬가 이미지 전송보다 더 신속한 경우 (바람직한 동작 모드), 프레임이 유사한 분할된 (split) 이미지를 나타내는 경우가 더 자주 존재한다.
XVII. 다수 클라이언트 지원
현재의 프로토콜 버전은 다수 클라이언트 장치를 직접 지원하는 것으로 보이지 않는다. 그러나, 대부분의 패킷은, 다수 클라이언트를 갖는 시스템에서 특정 클라이언트 장치를 어드레싱하는데 이용될 수 있는 보류 클라이언트 ID (reseved Client ID) 필드를 포함한다. 현재, 많은 애플리케이션에 대하여, 이 클라이언트 ID 또는 이들 클라이언트 ID 는 0 으로 설정된다. 또한, 서브 프레임 헤더 패킷은, 호스트가 다수 클라이언트 시스템을 지원하는지 여부를 나타내는 필드를 포함한다. 따라서, 시스템 설계자가 다수 클라이언트 호스트 및 클라이언트와의 추후 호환성을 계획하는 것을 돕도록, MDDI 또는 프로토콜의 추후 애플리케이션에서 다수 클라이언트 장치가 접속 및 어드레싱 될 수 있는 방법이 존재한다.
다수 클라이언트를 갖는 시스템에서, 도 95 에 도시한 바와 같은 클라이언트의 데이지 체인을 이용하거나 허브를 이용하여, 또는 도 96 에 도시한 바와 같은 이러한 기술들의 조합을 이용하여, 클라이언트가 호스트에 접속되는 것이 유용하다. 또한, 어드레스 0 을 원하는 하나 이상의 클라이언트가 접속된 경우의 오류 메시지와 같은, 접속된 클라이언트를 관리하는 어떠한 오류 메시지를 호스트가 디스플레이하는 것이 유용할 수도 있으며, 이것은 그 디스플레이가 그 클라이언트를 동작시키도록 설정되거나 기대되는 것과 같은 다수의 클라이언트 시스템의 경우가 아니어야 한다.
XVIII. 부록
본 발명의 실시형태를 위한 구성 및 프로토콜을 구현하는데 이용되는 다양한 패킷에 대하여 상술한 형식, 구조 및 컨텐츠에 더하여, 더 상세한 필드 컨텐츠 또는 동작이 일부 패킷 타입에 대하여 여기에 제공된다. 이들은 당업자로 하여금 다양한 애플리케이션에 대하여 본 발명을 더 용이하게 이해하고 실시할 수 있도록 하기 위해 각각의 이용 또는 동작을 명확히 하기 위해 제시된다. 아직 설명되지 않은 몇 개의 필드만이 여기에서 더 설명된다. 또한, 이들 필드는 상술된 실시형태와 관련된 예시적인 정의 및 값으로 제공된다. 그러나, 그러한 값들은 본 발명을 제한하는 것으로 생각되어서는 안되고, 인터페이스 및 프로토콜을 구현하기 위해 유용한 하나 이상의 실시형태를 나타내며, 모든 실시형태들이 함께 또는 동시에 실시될 필요는 없다. 당업자가 용이하게 인식할 수 있는 바와 같이, 데이터의 희망 프리젠테이션 또는 데이터 레이트 전송 결과를 달성하기 위하여, 다른 값이 다른 실시형태에서 사용될 수 있다.
A. 비디오 스트림 패킷에 대하여
일 실시형태에서, 여기서는 2 바이트인 픽셀 데이터 속성 필드는 다음과 같이 해석되는 일련의 비트 값을 가진다. 비트 1 및 0 은 디스플레이 픽셀 데이터가 어떻게 라우팅 되는지를 선택한다. '11' 의 비트 값에 대하여, 데이터는 양쪽 눈에 대하여 또는 양쪽 눈으로 디스플레이되고, 비트 값 '10' 에 대하여 데이터는 좌측눈으로만 라우팅되며, 비트 값 '01' 에 대하여 데이터는 우측눈으로만 라우팅되며, '00' 의 비트 값에 대하여, 데이터는 아래에서 설명되는 비트 8 내지 11 에 의해 특정될 수 있는 교대 디스플레이로 라우팅된다. 클라이언트 내의, 또는 클라잉너트에 의해 사용되거나 동작되는 주 디스플레이가 스테레오 이미지 또는 어떤 형식의 이미지를 지원하지 않는 경우, 이들 명령은 디스플레이에 의해 소망하는 바대로 효과를 가지도록 주입될 수 없다. 이 상황 또는 구성에서, 결과적인 명령 또는 제어는 디스플레이에 의해 구현되지 않을 것이므로, 클라이언트는 픽셀 데이터를 비트 값에 무관하게, 또는 어떠한 비트 조합 '01', '10' 또는 '11' 에 대해서도 주 디스플레이로 라우팅하여야 한다. 값 '11' 이 스테레오 디스플레이 기능을 지원하지 않는 클라이언트 내의 주 디스플레이를 어드레싱 하는데 사용되는 것을 권장하지만, 본 실시형태에서 필수적인 것은 아니다.
비트 2 는 픽셀 데이터가 인터레이스 (interlace) 형식으로 제공되는지 여부를 나타내며, '0' 의 값은 픽셀 데이터가 표준 진행 (progressive) 형식이고 행 (row) 넘버 (픽셀 Y 좌표) 는 하나의 행으로부터 그 다음 행으로 진행할 경우에 1 만큼 증가됨을 나타낸다. 이 비트가 '1' 의 값을 가질 경우, 픽셀 데이터는 인터레이스 형식이며, 행 넘버는 하나의 행으로부터 그 다음 행으로 진행할 경우에 2 만큼 증가 된다. 비트 3 은 픽셀 데이터가 교호 픽셀 형식임을 나타낸다. 이것은 비트 2 에 의해 인에이블되는 표준 인터레이스 모드와 유사하지만, 그 인터레이싱은 수평이 아니라 수직이다. 비트 3 이 '0' 일 경우, 픽셀 데이터는 표준 진행 형식이며, 열 넘버 (픽셀 X 좌표) 는 각각의 연속적인 픽셀이 수신됨에 따라 1 만큼 증가된다. 비트 3 이 '1' 일 경우, 픽셀 데이터는 교호 픽셀 형식이며, 열 넘버는 각각의 픽셀이 수신됨에 따라 2 만큼 증가된다.
비트 4 는 데이터가 무선 전화기 또는 유사한 장치나 휴대형 컴퓨터 또는 상술한 바와 같은 그러한 다른 장치에 대한 내부 디스플레이로/로부터 전송되고 있거나, 데이터가 장치에 내장되거나 직접 결합된 카메라로/로부터 전송되고 있는 경우와 같이, 픽셀 데이터가 디스플레이 또는 카메라에 관련되는지 여부를 나타낸다. 비트 4 가 '0' 일 경우, 픽셀 데이터는 디스플레이 프레임 버퍼로/로부터 전송되고 있다. 비트 4 가 '1' 일 경우, 픽셀 데이터는 어떤 타입의 카메라 또는 비디오 장치로/로부터 전송되고 있으며, 그러한 장치는 공지되어 있다.
비트 5 는 픽셀 데이터가 디스플레이 내의 다음 연속적인 픽셀 행을 포함하는 때를 나타내는데 이용된다. 비트 5 가 '1' 과 같이 설정되는 경우에 이러한 경우로 간주된다. 비트 5 가 '1' 로 설정되는 때, X 좌측 에지, Y 상부 에지, X 우측 에지, Y 하부 에지, X 시작 및 Y 시작 파라미터는 규정되지 않고 클라이언트에 의해 무시된다. 비트 15 가 로직 1 레벨로 설정되는 경우에, 이는 이 패킷의 픽셀 데이터가 이미지 내 픽셀의 최후 열임을 나타낸다. 클라이언트 능력 패킷의 클라이언트 특성 능력 표시자 필드의 비트 8 은 이러한 특성이 지원되는지 여부를 나타낸다.
비트 7 및 6 은 픽셀 데이터가 기록되는 프레임 버퍼를 특정하는 디스플레이 업데이트 비트이다. 더 구체적인 효과는 다른 곳에서 설명한다. '01' 의 비트 값에 대하여, 픽셀 데이터는 오프라인 이미지 버퍼에 기록된다. '00' 의 비트 값에 대하여, 픽셀 데이터는 디스플레이를 리프레쉬하는데 이용되는 이미지 버퍼에 기록된다. '11' 의 비트 값에 대하여, 픽셀 데이터는 모든 이미지 버퍼에 기록된다. '10' 의 비트 값 또는 조합은 무효한 값 또는 지정으로서 취급되며, 픽셀 데이터는 무시되어 여하한 이미지 버퍼에도 기록되지 않는다. 이 값은 인터페이스의 장래의 애플리케이션용의 용도를 가질 수 있다.
비트 8 내지 11 은, 픽셀 데이터가 라우팅될 교대 디스플레이 또는 디스플레이 위치를 특정하는데 사용된다. 비트 0 및 1 은, 디스플레이 클라이언트가 비트 8 내지 11 을 교대 디스플레이 넘버로서 해석하기 위해 '00' 으로 설정된다. 비트 0 및 1 이 '00' 과 같지 않으면, 비트 8 내지 11 은 로직 0 레벨로 설정된다.
비트 13 및 12 는, 수신지 픽셀이 투명 컬러 및 투명 마스크에 관련되는 수신지 위치에 기록될지 여부를 특정하는데 사용된다. 00 (더블 로직 0 레벨) 과 동일한 값을 갖는 비트 [13:12] 에 대해서, 투명 컬러는 사용되지 않는다. 해당 수신지 픽셀은 투명 컬러 또는 투명 마스크의 값을 고려하지 않고 수신지 픽셀 위치에 기록된다. 투명 컬러는 다른 부분에서 설명하는 투명 컬러 인에이블 패킷에 의해 정의된다. 비트 [13:12] 에 대한 값 01 (로직 0, 로직 1 레벨) 은 장래의 사용을 위해 현재 보류된 값을 나타내고, 통상적으로 사용되지 않는다. 비트 [13:12] 가 10 (로직 1, 로직 0 레벨) 의 값을 갖는 경우, 투명 마스크와 로직 AND 되는 소스 이미지 픽셀이 투명 컬러와 동일하지 않으면 해당 수신지 픽셀은 수신지 픽셀 위치에 기록되고, 해당 픽셀은 수신지 픽셀 위치에 기록되지 않는다. 비트 [13:12] 가 11 (더블 로직 1) 의 값을 갖는 경우, 투명 마스크와 로직 AND 되는 소스 이미지 픽셀이 투명 컬러와 동일하지 않으면, 해당 수신지 픽셀은 수신지 픽셀 위치에 기록되지 않고, 이 경우 해당 픽셀은 수신지 픽셀 위치에 기록된다.
비트 14 는 장래 사용을 위해 보류되며, 일반적으로, 로직 0 레벨로 설정된다. 설명한 바와 같이, 비트 15 는 비트 5 와 함께 사용되고, 비트 15 를 로직 1 로 설정하는 것은 픽셀 데이터 필드의 픽셀 행이 데이터 프레임에서 픽셀의 최후 행임을 나타낸다. 비트 5 를 로직 1 로 설정하는 것은 다음 비디오 프레임의 제 1 픽셀 행에 대응할 것이다.
2-바이트 X 시작 및 Y 시작 필드는 픽셀 데이터 필드 내의 제 1 픽셀에 대한 포인트의 절대 X 및 Y 좌표 (X 시작, Y 시작) 를 특정한다. 2-바이트 X 좌측 에지 및 Y 상부 에지 필드는 픽셀 데이터 필드에 의해 채워지는 스크린 윈도우의 좌측 에지의 X 좌표 및 상부 에지의 Y 좌표를 특정하는 반면, X 우측 에지 및 Y 하부 에지 필드는, 업데이트 되고 있는 윈도우의 우측 에지의 X 좌표 및 하부 에지의 Y 좌표를 특정한다.
픽셀 카운트 필드 (2 바이트) 는 아래의 픽셀 데이터 필드 내의 픽셀의 개수를 특정한다.
파라미터 CRC 필드 (2 바이트) 는 패킷 길이로부터 픽셀 카운트까지의 모드 바이트의 CRC 를 포함한다. 만약 이 CRC 가 확인을 실패하면, 전체 패킷은 폐기된다.
픽셀 데이터 필드는 디스플레이될 미가공 비디오 정보를 포함하며, 이는 비디오 데이터 형식 디스크립터 필드에 의해 설명되는 방식으로 구성된다. 데이터는 다른 곳에서 설명된 바와 같이 한번에 하나의 "행 (row)" 이 송신된다. 픽셀 데이터 속성 필드의 비트 5 가 로직 레벨 1 로 설정되는 경우에, 픽셀 데이터 필드는 정확하게 하나의 픽셀 행을 포함하며, 전송되는 최초 픽셀은 최 좌측 픽셀에 대응하고, 전송되는 최후 픽셀은 픽셀의 최 우측 픽셀에 대응한다.
픽셀 데이터 CRC 필드 (2 바이트) 는 픽셀 데이터만의 16-비트 CRC 를 포함한다. 만약 이 값의 CRC 검증이 실패하면, 픽셀 데이터가 여전히 사용될 수 있지만 CRC 오류 카운트가 증가된다.
B. 오디오 스트림 패킷에 대하여
일 실시형태에서, 오디오 채널 ID 필드 (1 바이트) 는 8 비트의 무부호 정수값을 사용하여, 오디오 데이터가 클라이언트 장치에 의해 전송되는 특정 오디오 채널을 식별한다. 물리적인 오디오 채널은 0, 1, 2, 3, 4, 5, 6, 또는 7 의 값으로서 이 필드에 의해 물리적인 채널에서 특정되거나 물리적인 채널로 매핑되며, 이 값은, 각각, 좌측 전방, 우측 전방, 좌측 후방, 우측 후방, 전방 중앙, 서브-우퍼, 서라운드 좌측, 및 서라운드 우측 채널을 나타낸다. 254 의 오디오 채널 ID 값은 디지털 오디오 샘플의 단일 스트림이 좌측 전방 및 우측 전방 채널 모두로 전송됨을 나타낸다. 이것은, 스테레오 헤드셋이 음성 통신용으로 사용되거나, 생산성 개선 애플리케이션 (apps) 이 PDA 에 사용되는 것과 같은 애플리케이션, 또는 단순한 사용자 인터페이스가 경고 톤을 발생시키는 다른 애플리케이션용의 통신을 단순화한다. 8 내지 253, 및 255 범위의 ID 필드에 대한 값은, 당업자가 예상할 수 있는 바와 같이, 새로운 설계가 추가적인 지정을 원하는 경우에 이용하기 위해 현재 보류되어 있다.
일반적으로, 보류 1 필드 (1 바이트) 는 추후 사용을 위해 보류되며, 이 필드의 모든 비트는 0 으로 설정된다. 이 필드의 하나의 기능은 모든 후속적인 2 바이트 필드를 16-비트 워드 어드레스와 정렬되게 하고 4 바이트 필드를 32-비트 워드 어드레스와 정렬되게 하는 것이다.
오디오 샘플 카운트 필드 (2 바이트) 는 이 패킷 내의 오디오 샘플의 개수를 특정한다.
샘플 당 비트 및 패킹 (Bit Per Sample and Packing) 필드는 오디오 데이터의 패킹 형식을 특정하는 1 바이트를 포함한다. 일 실시형태에서, 통상 채용되는 형식은 비트 4 내지 0 이 PCM 오디오 샘플 당 비트의 개수를 정의하는 것이다. 그러면 비트 5 는 디지털 오디오 데이터 샘플이 패킷화되는지 여부를 특정한다. 상술한 바와 같이, 도 12 는 패킷화된 오디오 샘플과 바이트-정렬된 오디오 샘플 간의 차이를 나타낸다. 비트 5 에 대한 '0' 의 값은 디지털 오디오 데이터 필드 내의 각 PCM 오디오 샘플이 인터페이스 바이트 경계와 바이트-정렬되며, '1' 의 값은 각각의 후속적인 PCM 오디오 샘플이 이전의 오디오 샘플에 대하여 패킷화됨을 나타낸다. 이 비트는, 비트 4 내지 0 에서 정의된 값 (PCM 오디오 샘플 당 비트의 개수) 이 8 의 배수가 아닐 경우에만 효과적이다. 비트 7 내지 6 은 시스템 설계가 추가적인 지정을 희망하는 경우에서의 사용을 위해 보류되고, 일반적으로 0 의 갑으로 설정된다.
오디오 샘플 레이트 필드 (1 바이트) 는 오디오 PCM 샘플 레이트를 특정한다. 채용된 형식은, 각각, 0 의 값에 대하여 8,000 sps (samples per se콘드) 의 레이트를 나타내며, 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 내지 255 의 값은 추후 사용을 위해 보류되어, 현재 0 으로 설정된다.
파라미터 CRC 필드 (2 바이트) 는 패킷 길이로부터 오디오 샘플 레이트까지의 모든 바이트의 16-비트 CRC 를 포함한다. 만약 이 CRC 가 적절한 확인을 실패하면, 전체 패킷이 폐기된다. 디지털 오디오 데이터 필드는 재생될 미가공 오디오 샘플을 포함하며, 통상적으로 무부호 정수와 같은 선형 형식의 형태이다. 오디오 데이터 CRC 필드 (2 바이트) 는 오디오 데이터만의 16-비트 CRC 를 포함한다. 만약 이 CRC 가 확인에 실패하면, 오디오 데이터는 여전히 사용될 수 있지만, CRC 오류 카운트가 증가된다.
C. 사용자 정의 스트림 패킷에 대하여
일 실시형태에서, 2-바이트 스트림 ID 넘버 필드는 특정 사용자 정의 스트림을 식별하는데 이용된다. 통상적으로, 스트림 파라미터 및 스트림 데이터 필드의 컨텐츠는 MDDI 장비 제조자에 의해 정의된다. 2-바이트 스트림 파라미터 CRC 필드는 패킷 길이로부터 오디오 코딩 바이트까지의 스트림 파라미터의 모든 비트의 16-비트 CRC 를 포함한다. 만약 이 CRC 가 확인에 실패하면, 전체 패킷이 폐기된다. 스트림 파라미터 및 스트림 파라미터 CRC 필드 양자는, MDDI 의 최종 애플리케이션에 의해 필요하지 않으면, 즉, 선택사항으로 생각되면 폐기될 수 있다. 2-바이트 스트림 데이터 CRC 필드는 스트림 데이터만의 CRC 를 포함한다. 만약 이 CRC 가 적절한 확인을 실패하면, 애플리케이션의 요구 사항에 따라, 스트림 데이터의 사용은 선택적이다. 일반적으로, 양호한 CRC 에 의존하는 스트림 데이터의 사용은, CRC 가 양호한 것으로 확인될 때까지 스트림 데이터가 버퍼링될 것을 요구한다. CRC 오류 카운트는, 그 CRC 가 확인되지 않으면 증가된다.
D. 컬러 맵 패킷에 대하여
이전에 사용된 바와 같이, 2-바이트 h클라이언트 ID 필드는 클라이언트 ID 용으로 보류된 정보 또는 값을 포함한다. 일반적으로, 이 필드는 추후 사용을 위해 보류되기 때문에, 현재의 값은, 그 비트를 '0' 으로 설정함으로써, 0 으로 설정된다.
2-바이트 컬러 맵 아이템 카운트 필드는 컬러 맵 데이터 필드에 포함되어 있는 3-바이트 컬러 맵 아이템, 또는 이 패킷 내의 컬러 맵 데이터에 존재하는 컬러 맵 표 엔트리의 총 수를 특정하기 위해 값을 사용한다. 이 실시형태에서, 컬러 맵 데이터에서의 바이트의 수는 컬러 맵 아이템 카운트의 3 배이다. 컬러 맵 아이템 카운트는 컬러 맵 데이터를 전송하지 않도록 0 으로 설정된다. 만약 컬러 맵 사이즈가 0 이면, 일반적으로, 컬러 맵 오프셋 값은 여전히 전송되지만 디스플레이에 의해 무시된다. 컬러 맵 오프셋 필드 (4 바이트) 는 클라이언트 장치에서의 컬러 맵 표의 시작으로부터 이 패킷에서의 컬러 맵 데이터의 오프셋을 특정한다.
2-바이트 파라미터 CRC 필드는 패킷 길이로부터 오디오 코딩 바이트까지의 모든 바이트의 CRC 를 포함한다. 만약 이 CRC 가 확인에 실패하면, 전체 패킷은 폐기된다.
컬러 맵 데이터 필드에 대하여, 각각의 컬러 맵 위치의 폭은 컬러 맵 아이템 사이즈 필드에 의해 특정되는데, 일 실시형태에서, 제 1 부분은 청색의 크기를 특정하며, 제 2 부분은 녹색의 크기를 특정하며, 제 3 부분은 적색의 크기를 특정한다. 컬러 맵 사이즈 필드는 컬러 맵 데이터 필드에 존재하는 3-바이트 컬러 맵 표 아이템의 개수를 특정한다. 만약 단일의 컬러 맵이 하나의 비디오 데이터 형식 및 컬러 맵 패킷에 맞추어질 수 없으면, 전체 컬러 맵은, 각각의 패킷 내에 상이한 컬러 맵 데이터 및 컬러 맵 오프셋을 갖는 다중의 패킷을 전송함으로써 특정될 수 있다. 각각의 컬러 맵 데이터 아이템에서의 청색, 녹색, 및 적색의 비트 수는 디스플레이 능력 패킷의 컬러 맵 RGB 폭 (Color Map RGB Width) 필드에서 특정되는 것과 일반적으로 동일하다.
2-바이트 컬러 맵 데이터 CRC 필드는 컬러 맵 데이터만의 CRC 를 포함한다. 만약 이 CRC 가 확인에 실패하면, 컬러 맵 데이터가 여전히 사용될 수 있지만 CRC 오류 카운트가 증가된다.
각각의 컬러 맵 데이터 아이템은 청색, 녹색, 적색의 순서로 각 성분의 최하위 비트 (LSB) 가 먼저 송신되어야 한다. 각각의 컬러 맵 아이템의 개별 적색, 녹색 및 청색 성분은 패킷화 되지만, 각각의 컬러 맵 아이템 (청색 성분의 LSB) 은 바이트-정렬되어야 한다. 도 97 은 청색의 6 비트, 녹색의 8 비트, 및 적색의 7 비트를 갖는 컬러 맵 데이터 아이템의 일 예를 도시한다. 이 예에 있어서, 컬러 맵 패킷 내의 컬러 맵 아이템 크기는 21 이며, 클라이언트 능력 패킷의 컬러 맵 RGB 폭 필드는 0x0786 과 같다.
E. 역방향 링크 캡슐화 패킷에 대하여
파라미터 CRC 필드 (2 바이트) 는 패킷 길이로부터 턴 어라운드 길이까지의 모든 바이트의 16-비트 CRC 를 포함한다. 이 CRC 가 확인에 실패하면, 전체 패킷은 폐기된다.
일 실시형태에서, 역방향 링크 플래그 필드 (1 바이트) 는 클라이언트로부터 정보를 요청하고 역방향 링크 타입을 특정하기 위한 플래그 세트를 포함한다. 일 비트 (예를 들어, 비트 0) 가 로직 1 레벨로 설정되면, 호스트는 클라이언트로부터 특정 정보를 요청하지만, 그 비트가 로직 0 레벨로 설정되면, 호스트는 클라이언트로부터 정보를 요구하지 않는다. 비트 0 은, 일반적으로 역방향 데이터 패킷 필드에서 클라이언트에 의해 호스트로 전송되는 클라이언트 능력 패킷을 호스트가 요구하는 경우를 나타내는데 사용된다. 비트 1 은, 역방향 데이터 패킷 필드에서 클라이언트에 의해 호스트로 전송되는 클라이언트 요청 및 상태 패킷을 호스트가 요구하는 경우를 나타내는데 사용된다. 나머지 비트 (여기서는 비트 2 내지 7) 는 장래의 사용을 위해 보류되고 0 으로 설정된다. 그러나, 역방향 링크를 위한 플래그를 설정하도록 요구되는 바에 따라 더 많은 비트가 사용될 수 있다.
역방향 레이트 제수 필드 (1 바이트) 는 역방향 링크 데이터 클록과 관련하여 발생하는 MDDI_Stb 사이클의 수를 특정한다. 역방향 링크 데이터 클록은 순방향 링크 데이터 클록 나누기 역방향 레이트 제수의 2 배와 같다. 역방향 링크 데이터 레이트는 역방향 링크 데이터 클록 및 역방향 링크 상의 인터페이스 타입과 관련된다. 이 실시형태에서, 타입 1 인터페이스에 대해 역방향 데이터 레이트는 역방향 링크 데이터 클록과 동일하며, 타입 2, 타입 3, 및 타입 4 인터페이스에 대해서는 역방향 데이터 레이트는, 각각, 역방향 링크 데이터 클록의 2 배, 4배, 및 8 배와 같다.
올 제로 1 필드는, 비트를 로직 0 레벨로 설정함으로써 값이 0 과 같게 설정되는, 여기서는 8 바이트의 바이트 그룹을 포함하며, 턴 어라운드 1 필드 동안 호스트의 라인 드라이버를 디스에이블링 하기 전에 MDDI_Stb 만을 이용하여 클라이언트가 클록 복구를 시작할 수 있도록 하게 하는데 충분한 시간 동안 모든 MDDI_Data 신호들이 로직 0 임을 보장하는데 이용된다. 일 실시형태에서, 올 제로1 필드의 길이는 케이블의 라운드 트립 지연에서의 순방향 링크 바이트 송신 시간의 수보다 크거나 같다.
턴 어라운드 1 길이 필드 (1 바이트) 는 턴 어라운드1 에 대하여 할당된 바이트의 총수를 특정하고, 제 1 턴 어라운드 주기를 확립한다. 턴 어라운드 1 필드는 턴 어라운드 1 길이 파라미터에 의해 특정되는 수의 바이트를 채용하고, 이는 클라이언트 내의 MDDI_Data 라인 드라이버가 호스트 내의 라인 드라이버들이 디스에이블 되기 전에 인에이블 할 수 있도록 하기 위해 할당된다. 클라이언트는 턴 어라운드 1 의 비트 0 동안에 그 MDDI_Data 라인 드라이버를 인에이블시키며, 호스트는 턴 어라운드 1 의 최후 비트 전에 완전하게 디스에이블되도록 그 출력을 디스에이블시킨다. MDDI_Stb 신호는 MDDI_Data0 가 전체 턴 어라운드 1 주기 동안 로직 0 레벨인 것처럼 동작한다. 턴 어라운드 1 의 설정에 대한 보다 완전한 설명은 전술하였다.
역방향 데이터 패킷 필드는 클라이언트로부터 호스트로 전송되는 일련의 데이터 패킷을 포함한다. 호스트로 전송할 데이터가 없는 경우에, 클라이언트는 필러 패킷을 전송하거나 MDDI_Data 라인을 로직 0 상태 또는 레벨로 구동할 수 있다. 이 실시형태에서, MDDI_Data 라인이 0 으로 구동된다면, 호스트는 이것을 (유효한 길이가 아닌) 0 길이를 갖는 패킷으로서 해석하고, 호스트는 현재 역방향 링크 캡슐화 패킷의 기간동안 클라이언트로부터 추가적인 패킷을 받지 않을 것이다.
턴 어라운드 2 길이 필드 (1 바이트) 는, 제 2 턴 어라운드 주기를 확립하기 위해, 턴 어라운드 2 에 대하여 할당된 바이트의 총수를 특정한다. 권장되는 턴 어라운드 2 의 길이는 라운드 트립 지연에 대해 요구되는 바이트의 수 더하기 호스트가 그 MDDI_Data 드라이버를 인에이블 하는데 필요한 시간이다. 턴 어라운드 2 길이는 호스트에서 역방향 링크 패킷을 처리하는데 충분한 시간을 허용하기 위해 요구되거나 계산되는 최소값보다 큰 값일 수도 있다.
턴 어라운드 2 필드는 턴 어라운드 길이 파라미터에 의해 특정되는 수의 바이트로 구성된다. 호스트는 턴 어라운드 2 동안 그 MDDI_Data 라인 드라이버를 인에이블 하기 전에 최소한 라운드 트립 지연 시간 동안 대기한다. 호스트는 그 MDDI_Data 라인 드라이버들을 일반적으로 턴 어라운드 2 의 마지막 비트 전에 완전히 인에이블 되도록 인에이블하고, 클라이언트는 그 출력들을 턴 어라운드 2 의 마지막 비트 전에 완전히 디스에이블 되도록 디스에이블한다. 턴 어라운드 2 필드의 목적은 역방향 데이터 패킷 필드로부터의 데이터의 잔여량이 클라이언트로부터 송신 또는 전송될 수 있도록 하는 것이다. 인터페이스를 구현하는 상이한 시스템 및 할당된 안전 마진의 양의 변화에 따라, 호스트나 클라이언트 어느 쪽도, 호스트 내의 또는 호스트의 라인 수신기에서 볼 때 턴 어라운드 2 필드 기간의 일부 동안 MDDI_Data 신호를 로직 0 레벨로 구동하고 있지 않을 것이다. MDDI_Stb 신호는 MDDI_Data0 이 실질적으로 전체 턴 어라운드 2 기간 동안 로직 0 레벨에 있는 것처럼 행동한다. 턴 어라운드 2 의 설정의 설명은 상기하였다.
역방향 데이터 패킷 필드는 클라이언트로부터 호스트로 전송되는 일련의 데이터 패킷을 포함한다. 전술한 바와 같이, 필러 패킷은 다른 패킷 타입에 의해 사용되지 않는 잔여 공간을 채우기 위해 전송된다.
올 제로 2 필드는, 비트를 로직 0 레벨로 설정함으로써 값이 0 과 같게 설정되는 바이트 그룹 (본 실시형태에서는 8) 을 포함하며, 턴 어라운드 2 필드에 후속하는 호스트의 라인 드라이버의 인에블링 후에 MDDI_Data0 및 MDDI_Stb 양자 모두를 이용하여 클라이언트가 클록 복구를 시작할 수 있도록 하는데 충분한 시간 동안 모든 MDDI_Data 신호가 로직 0 레벨에 있는 것을 보장하는데 사용된다.
F. 클라이언트 능력 패킷에 대하여
일 실시형태에서 설명한 바와 같이, 프로토콜 버전 필드는 클라이언트에 의해 이용되는 프로토콜 버전을 특정하기 위해 2 바이트를 사용한다. 초기 버전은 현재 1 로 설정되고, 알려지는 대로 새로운 버천이 생성되면서 시간에 따라 변화하는 한편, 최소 프로토콜 버전 필드는 클라이언트가 채택 또는 해석할 수 있는 최소 프로토콜 버전을 특정하기 위해 2 바이트를 사용한다. 이 경우에, 0 값 또한 유효한 값이다. 사전 교정 데이터 레이트 능력 필드 (2 바이트) 는, 클라이언트가 순방향 링크 스큐 교정을 수행하기 전에 순방향 링크에서 각각의 데이터 쌍에 대해 수신할 수 있는 최대 데이터 레이트를 특정하고, 초당 메가비트 (Mbps) 의 형태로 특정된다. 클라이언트가 순방향 링크 스큐 교정 패킷을 지원하면, 사후 교정 데이터 레이트 능력 필드의 값은, 클라이언트가 스큐 교정을 수행한 후 가능한 데이터 레이트를 나타낸다.
일 실시형태에서, 인터페이스 타입 능력 필드 (1 바이트) 는 순방향 및 역방향 링크 상에서 지원되는 인터페이스 타입을 특정한다. '1' 로 설정된 비트는 특정 인터페이스 타입이 지원됨을 나타내고, '0' 으로 설정된 비트는 특정 타입이 지원되지 않음을 나타낸다. 호스트 및 클라이언트는 순방향 및 역방향 라인 상에서 최소한 타입 1 을 지원해야만 한다. 연속적인 범위의 인터페이스 타입을 지원하여야 한다는 요건은 없다. 예를 들어, 인터페이스에서 단지 타입 1 및 타입 3 만을 지원하고 타입 3 및 타입 4 를 지원하지 않는 것이 완전하게 유효하게 된다. 또한, 순방향 및 역방향 링크가 동일한 인터페이스 타입으로 동작할 필요가 없다. 그러나, 링크가 휴지상태로부터 벗어나는 경우에 순방향 및 역방향 링크 모두는 다른 모드가 협상, 선택 또는 호스트 및 클라이언트 양자에 의해 승인되기까지 타입 1 모드에서 동작을 개시해야 한다.
일 실시형태에서 지원되는 인터페이스는, 순방향 링크 상에서 타입 2 (2 비트), 타입 3 (4 비트) 또는 타입 4 (8 비트) 모드 중 하나를 선택하기 위하여 비트 0, 비트 1 또는 비트 2 를 각각 선택하고, 역방향 링크 상에서 타입 2, 타입 3 또는 타입 4 모드 중 하나를 선택하기 위해 비트 3, 비트 4 또는 비트 5 를 각각 선택함으로써 표시되며, 비트 6 및 7 은 보류되고 이때에는 일반적으로 0 으로 설정된다.
일 실시형태에서, 클라이언트 능력 패킷의 교대 디스플레이 필드는 0 내지 16 까지의 범위일 수도 있는 1 바이트를 사용하고, 17 내지 255 의 값은 장래의 사용을 위해 보류되고 사용되지 않으며 하나 이상의 디스플레이가 부착된 것을 나타내거나 리포트하고, 교대 디스플레이 능력 패킷은 각각의 교대 디스플레이의 능력을 리포트한다. 교대 디스플레이 수 필드는, 통상적으로 수 0 으로 지정되는 제 1 교대 디스플레이를 갖는 교대 디스플레이의 아이덴티티를 나타내기 위해 1 바이트를 사용하고, 다른 교대 디스플레이는, (0 값으로부터 시작하여) 교대 디스플레이의 총수에서 1 을 감산하여 사용되는 최대값을 갖는 고유 교대 디스플레이 수 값으로 식별된다.
일 실시형태에서, 사후 교정 데이터 레이트 능력 필드는, 클라이언트가 순방향 링크 스큐 교정을 수행한 후 순방향 MDDI 링크에서 각각의 데이터 쌍을 수신할 수 있는 최대 데이터 레이트를 특정하는데 사용된다. 또한, 이 레이트는 초당 메가비트 (Mbps) 의 수로 특정된다. 클라이언트 디바이스가 순방향 링크 스큐 교정 패킷을 지원하지 않으면, 이 필드는 0 값으로 설정된다.
여기서는 2 바이트인 비트맵 폭 및 높이 필드는 픽셀에서 비트맵의 폭 및 높이를 각각 특정한다. 디스플레이 윈도우 폭 필드는, 픽셀의 수로 표현되는 디스플레이 윈도우의 폭을 특정하는 2 바이트를 사용한다. 디스플레이 윈도우 높이 필드는, 픽셀의 수로 표현되는 디스플레이 높이를 특정하는 2 바이트를 사용한다.
컬러 맵 크기 필드는 4 바이트를 사용하여, 클라이언트의 컬러 맵 테이블에 존재하는 테이블 아이템의 최대 수를 특정한다. 클라이언트가 컬러 맵 형식을 사용할 수 없으면, 이 값은 0 으로 설정된다.
컬러 맵 RGB 폭 필드는, 컬러 맵 (파레트) 디스플레이 모드에 디스플레이될 수 있는 적색, 녹색 및 청색 콤포넌트의 비트 수를 특정하는 2 바이트를 사용한다. 각각의 컬러 성분에 대해 최대 8 비트가 사용될 수 있다. 각각의 컬러 성분의 8 비트가 컬러 맵 패킷에서 전송되는 경우에도, 이 필드에서 정의된 각각의 컬러 성분의 최소 유효 비트의 수만이 사용된다. 디스플레이 클라이언트가 컬러 맵 (파레트) 형식을 사용할 수 없으면, 이 값은 0 이다.
RGB 능력 필드 (2 바이트) 는, RGB 형식에서 디스플레이될 수 있는 해상도 비트의 수를 특정한다. 디스플레이가 RGB 형식을 사용할 수 없으면, 이 값은 0 이다. RGB 능력 워드는 3 개의 개별적 무부호 값으로 구성되며: 비트 3 내지 0 은 청색 비트의 최대 수를 정의하고, 비트 7 내지 4 는 녹색 비트의 최대 수를 정의하고, 비트 11 내지 8 은 각각의 픽셀에서 적색 비트의 최대 수를 정의한다. 현재, 비트 14 내지 12 는 장래의 사용을 위해 보류되고 일반적으로 0 으로 설정된다. 비트 14 내지 12 는 장래의 사용을 위해 보류되고 일반적으로 0 으로 설정된다. 비트 15 가 로직 1 레벨로 설정되는 경우, 클라이언트가 패킹된 또는 패킹되지 않은 형식으로 RGB 픽셀 데이터를 수용할 수 있음을 나타낸다. 비트 15 가 로직 0 레벨로 설정되면, 클라이언트가 패킹되지 않은 형식으로만 RGB 픽셀 데이터를 수용할 수 있음을 나타낸다.
일 실시형태에서, 흑백 능력 필드 (1 바이트) 는 흑백 형식으로 디스플레이될 수 있는 해상도의 비트 수를 특정하는데 사용된다. 디스플레이가 흑백 형식을 사용할 수 없는 경우 이 값은 0 으로 설정된다. 비트 7 내지 4 는 장래의 사용을 위해 보류되며, 그에 따라 0 으로 설정된다. 비트 3 내지 0 은 각각의 픽셀에 대하여 존재할 수 있는 그레이 스케일의 최대 비트 수를 규정한다. 이들 4 개의 비트는 각각의 픽셀에 대하여 1 내지 15 의 값들을 특정할 수 있도록 한다. 그 값이 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 으로 설정된다.
베이어 (Bayer) 능력 필드는 베이어 형식으로 전송될 수 있는 해상도의 비트수, 픽셀 그룹 및 픽셀 순서를 특정하기 위해 1 바이트를 사용한다. 클라이언트가 베이어 형식을 사용할 수 없다면 이 값은 0 이다. 베이어 능력 필드는 다음의 값들로 구성된다: 비트 3 내지 0 은 각각의 픽셀에 존재하는 강도 비트의 최대 수를 정의하는 한편, 비트 5 내지 4 는 요구되는 픽셀 그룹 패턴을 규정하고, 비트 8 내지 6 은 요구되는 픽셀 순서를 규정하며, 비트 14 내지 9 는 장래 사용을 위해 보류되며 그간 일반적으로 0 으로 설정된다. 로직 1 레벨로 설정되는 경우에 비트 15 는 클라이언트가 패킷화 또는 비패킷화된 형식 중 하나로 베이어 픽셀 데이터를 수신할 수 있음을 나타낸다. 비트 15 가 0 으로 설정되면, 이는 클라이언트가 베이어 픽셀 데이터를 단지 비패킷화된 형식으로만 수신할 수 있음을 나타낸다.
일 실시형태에서, 클라이언트 특성 능력 필드는 지원되는 클라이언트에서의 특정 특성을 나타내는 플래그 세트를 포함하는 4 바이트를 사용한다. 로직 1 레벨로 설정된 비트는 능력이 지원됨을 나타내는 반면, 로직 0 레벨로 설정된 비트는 능력이 지원되지 않음을 나타낸다. 일 실시형태에서, 비트 0 에 대한 값은, 비트맵 블록 전송 패킷 (패킷 타입 71) 이 지원되는지 여부를 나타낸다. 비트 1, 2 및 3 에 대한 값은, 각각 비트 영역 채움 패킷 (패킷 타입 72), 비트맵 패턴 채움 패킷 (패킷 타입 73) 또는 판독 프레임 버퍼 패킷 (패킷 타입 74) 이 지원되는지 여부를 나타낸다. 비트 4 에 대한 값은, 클라이언트가 투명 컬러 및 마스크 패킷을 지원할 능력을 가지는지 여부를 나타내고, 비트 5 및 6 에 대한 값은, 클라이언트가 패킷화된 형식 또는 패킷화되지 않은 형식으로 오디오 데이터를 수용할 수 있는지를 각각 나타내고, 비트 7 에 대한 값은, 클라이언트가 카메라로부터 역방향 링크 비디오 스트림을 전송할 수 있는지 여부를 나타낸다. 비트 8 에 대한 값은, 클라이언트가 픽셀 데이터의 풀 (full) 라인을 수신하고 비디오 스트림 패킷의 픽셀 데이터 속성 필드의 비트 5 에 의해 특정되는 바에 따라 디스플레이 어드레싱을 무시하는 능력을 가지는지 여부, 및 클라이언트가 픽셀 데이터 속성 필드의 비트 15 를 이용하여 프레임 동기 또는 비디오 프레임 데이터의 끝을 검출할 수 있는지 여부를 나타낸다.
비트 9 의 값은, 클라이언트가 요청 특정 상태 패킷을 해석하고 유효 상태 응답 리스트 패킷에 응답하는 능력을 가졌는지 여부를 나타낸다. 클라이언트는 전술한 바와 같은 유효 상태 응답 리스트 패킷의 유효 파라미터 응답 리스트 필드에서 추가적인 상태를 반환할 능력을 가진 것을 나타낼 수 있다. 비트 10 의 값은, 클라이언트가 디스플레이 전력 상태 01 을 지원할 능력을 가졌는지 여부를 나타낸다. 디스플레이 전력 상태는 전술한 디스플레이 전력 상태 패킷의 전력 상태 필드의 비트 [3:2] 를 사용하여 설정된다. 디스플레이 전력 상태 01 은, 선택된 디스플레이가 발광하지 않고, 소모한다해도 최소한의 전력량을 소모하고 있는 상태이며, 프레임 버퍼의 컨텐츠는 이 상태동안 일반적으로 보류되는 것이 보장된다.
비트 11 및 12 에 대한 값은, 각각 클라이언트가 포인팅 장치와 통신하여 포인팅 장치 데이터 패킷을 전송 및 수신할 수 있는지 또는 키보드와 통신하여 키보드 데이터 패킷을 전송 및 수신할 수 있는지를 나타낸다. 비트 13 에 대한 값은 VCP 특성 패킷들 즉, 요청 VCP 특성 패킷, VCP 특성 응답 패킷, 설정 VCP 특성 패킷, 요청 유효 파라미터 패킷 및 유효 파라미터 응답 패킷을 지원함으로써 하나 이상의 오디오 또는 비디오 파라미터들을 설정하는 능력을 가지는지 여부를 나타낸다. 비트 14 에 대한 값은 클라이언트가 픽셀 데이터를 오프라인 디스플레이 프레임 버퍼에 기록할 수 있는 능력을 갖는지 여부를 나타내며, 도 88a 에 도시되어 있다. 이 비트가 로직 1 로 설정된다면, 디스플레이 업데이트 비트 (비디오 스트림 패킷의 픽셀 데이터 속성 필드의 비트 7 및 6) 는 값 '01' 로 설정될 수 있다.
비트 15 에 대한 값은 클라이언트가 픽셀 데이터를 현재 디스플레이 이미지를 리프레쉬하는데 이용되고 있는 디스플레이 프레임 버퍼로만 기록할 수 있는 능력을 갖는지 여부를 나타내며 도 88b 에 도시되어 있다. 이 비트가 로직 1 로 설정된다면 디스플레이 업데이트 비트 (비디오 스트림 패킷의 픽셀 데이터 속성 필드의 비트 7 및 6) 는 값 '00' 으로 설정될 수 있다. 비트 16 에 대한 값은 클라이언트가 픽셀 데이터를 단독 비디오 스트림 패킷으로부터 모든 디스플레이 프레임 버퍼로 기록하는 능력을 갖는지 여부를 나타내며 도 88c 에 도시되어 있다. 이 비트가 로직 1 과 동일하게 설정된다면 디스플레이 업데이트 비트 (비디오 스트림 패킷의 픽셀 데이터 속성 필드의 비트 7 및 6) 는 값 '11' 로 설정될 수 있다.
일 실시형태에서, 비트 17 에 대한 값은 클라이언트가 요청 특정 상태 패킷에 응답하는 능력을 갖는지 여부를 나타내고, 비트 18 에 대한 값은 클라이언트가 라운드 트립 지연 측정 패킷에 대해 응답하는 능력을 갖는지 여부를 나타내며, 비트 19 에 대한 값은 클라이언트가 순방향 링크 스큐 교정 패킷에 대한 능력을 갖는지 여부를 나타낸다. 일 실시형태에서, 비트 20 에 대한 값은 클라이언트가 디스플레이 전력 상태 패킷에 응답할 능력을 갖는지 여부를 나타낸다.
일 실시형태에서, 비트 21 에 대한 값은, 비트 0, 1 및 2 또는 이 필드에 의해 특정되는 바와 같이 비트맵 블록 전송 패킷 (패킷 타입 71), 비트맵 영역 채움 패킷 (패킷 타입 72), 및 비트맵 패턴 채움 패킷 (패킷 타입 73) 의 래스터 연산 필드가 클라이언트에 의해 지원되는 경우, 클라이언트가 이 필드들을 사용할 능력을 가진 경우를 나타낸다. 일 실시형태에서, 비트 21 이 로직 0 레벨 또는 값을 가지고, 패킷이 지원되는 경우, 클라이언트는, 래스터 연산 필드를 사용할 능력을 갖지 않고, 이 패킷들에 의해 특정되는 픽셀 위치를 카피하거나 기록할 능력만을 갖는다.
비트 22 에 대한 값은 클라이언트가 레지스터 액세스 패킷에 대해 응답하는 능력을 갖는지 여부를 나타낸다. 비트 23 내지 31 은 장래 사용을 위해 또는 시스템 설계자를 위해 유용한 다른 지정을 위해 보류되고, 일반적으로 0 값 또는 로직 0 레벨로 설정된다.
최소 서브 프레임 레이트 필드 (2 바이트) 는 프레임에서 초당 최소 서브 프레임 레이트를 특정한다. 최소 서브 프레임 레이트는 특정한 클라이언트의 센서 또는 포인팅 디바이스를 판독하기에 충분하도록 클라이언트 상태 업데이트 레이트를 유지한다.
오디오 버퍼 깊이 필드 (2 바이트) 는 각각의 오디오 스트림에 전용되는 디스플레이에서 탄력적 버퍼의 깊이를 특정한다.
본 실시형태에서는 2 바이트를 사용하는 오디오 채널 능력 필드는, 어떤 오디오 채널이 클라이언트 또는 클라이언트에 접속된 장치에 의해 지원되는지를 나타내는 플래그 그룹을 포함한다. 1 로 설정된 비트는 채널이 지원됨을 나타내고, 0 으로 설정된 비트는 채널이 지원되지 않음을 나타낸다. 비트 위치는 상이한 채널로 할당되며, 일 실시형태에서 예를 들면 비트 위치 0, 1, 2, 3, 4, 5, 6, 및 7 은 좌측 전방, 우측 전방, 좌측 후방, 우측 후방, 전방 중앙, 서브-우퍼, 서라운드 좌측, 및 서라운드 우측 채널을 각각 나타낸다. 비트 8 내지 14 는 장래의 사용을 위해 현재 보류되고 일반적으로 0 으로 설정된다. 일 실시형태에서, 비트 15 는 클라이언트가 순방향 오디오 채널 인에이블 패킷에 대한 지원을 제공하는지 여부를 나타내는데 이용된다. 이러한 경우에, 비트 15 는 로직 1 레벨로 설정된다. 그러나, 클라이언트가 순방향 오디오 채널 인에이블 패킷의 결과로서 오디오 채널을 디스에이블할 수 없거나, 클라이언트가 어떠한 오디오 능력도 지원하지 않는다면, 이 비트는 로직 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) 로 할당되며, 비트 9 내지 15 는 희망에 따라 장래의 사용을 위해 또는 다른 레이트 사용을 위해 보류되어 이들은 현재 '0' 으로 설정된다. 이들 비트들 중 하나에 대한 비트 값을 '1' 로 설정하는 것은 특정한 샘플 레이트가 지원됨을 나타내고, 비트를 '0' 으로 설정하는 것은 그 샘플 레이트가 지원되지 않음을 나타낸다.
순방향 링크에 있어서, 2 바이트 오디오 샘플 해상도 필드는 오디오 스트림 패킷에서 클라이언트로 전송될 오디오 샘플당 비트의 수를 특정한다.
역방향 링크에 있어서, 2 바이트 Mic 오디오 샘플 해상도 필드는 오디오 스트림 패킷의 mic 에 의해 호스트로 전송되는 오디오 샘플당 비트의 수를 특정한다.
역방향 링크에 대하여, 2-바이트 마이크 샘플 레이트 능력 필드는, 클라이언트 장치에서 마이크로폰의 오디오 샘플 레이트 능력을 나타내는 플래그 세트를 포함한다. MDDI 의 목적으로, 클라이언트 장치 마이크로폰은 적어도 초당 8,000 샘플 레이트를 최소한 지원하도록 구성된다. 이 필드에 대한 비트 위치는 상이한 레이트로 할당되는데, 예를 들어 비트 위치 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) 을 나타내는데 각각 사용되고, 비트 9 내지 15 는 희망에 따라 장래의 사용을 위해 또는 다른 레이트 사용을 위해 보류되며 따라서 이들은 현재 '0' 으로 설정된다. 이들 비트들 중 하나에 대한 비트값을 '1' 로 설정하는 것은 특정 샘플 레이트가 지원됨을 나타내고, 비트를 '0' 으로 설정하는 것은 그 샘플 레이트가 지원되지 않음을 나타낸다. 마이크로폰이 접속되지 않은 경우, 마이크 샘플 레이트 능력 비트의 각각은 0 과 동일하게 설정된다.
키보드 데이터 형식 필드 (여기에서 1 바이트) 는 키보드가 클라이언트 시스템에 접속되는지 여부 및 접속된 키보드 타입을 특정한다. 일 실시형태에서, 비트 6 내지 0 에 의해 수립된 값은 접속된 키보드의 타입을 규정하는데 사용된다. 값이 제로 (0) 라면, 키보드 타입은 알려지지 않은 것으로 간주된다. 값 1 에 대하여, 키보드 데이터 형식은 표준 PS-2 스타일로 간주된다. 2 내지 125 의 범위의 값들은 현재 사용되지 않으며, 시스템 설계자 및 인터페이스 인코포레이터 (incorporator) 또는 제품 개발자가 MDD 인터페이스 및 대응하는 클라이언트 또는 호스트와 함께 이용하기 위한 특정 키보드 또는 입력 장치를 규정하는데 이용하기 위하여 보류된다. 값 126 은 키보드 데이터 형식이 사용자 정의됨을 나타내는 반면, 값 127 은 키보드가 이 클라이언트에 접속될 수 없음을 나타낸다. 또한, 비트 7 은 키보드가 클라이언트와 통신할 수 있는지 여부를 나타내는데 이용될 수 있다. 이 비트의 의도된 사용은 키보드가 무선 링크를 사용하여 클라이언트와 통신할 수 있을 때를 나타낸다. 비트 6 내지 0 가 키보드가 클라이언트에 접속될 수 없음을 나타낸다면, 비트 7 은 0 레벨로 설정될 것이다. 따라서, 일 실시형태에서, 비트 7 의 값이 0 인 경우에, 키보드 및 클라이언트는 통신할 수 없는 없으나, 비트 7 의 값이 1 이라면, 키보드 및 클라이언트는 그들이 서로 통신할 수 있음을 확인한다.
포인팅 장치 데이터 형식 필드 (여기에서 1 바이트) 는 포인팅 장치가 클라이언트 시스템에 접속되어 있는지 여부 및 접속된 포인팅 장치의 타입을 특정한다. 일 실시형태에서, 비트 6 내지 0 에 의해 수립된 값은 접속된 포인팅 장치의 타입을 규정하는데 이용된다. 이 값이 제로 (0) 라면, 포인팅 장치 타입은 알려지지 않은 것으로 간주된다. 값 1 에 대해서, 포인팅 장치 데이터 형식은 표준 PS-2 스타일인 것으로 간주된다. 2 내지 125 의 범위의 값들은 현재 사용되지 않으며, MDD 인터페이스 및 대응하는 클라이언트 또는 호스트와 함께 사용하기 위하여 특정 포인팅 장치 또는 입력 장치를 규정하는 시스템 설계자 및 인터페이스 인코포레이터 또는 제품 설계자의 사용을 위해 보류된다. 값 126 은 포인팅 장치 데이터 형식이 사용자-정의됨을 나타내고, 값 127 은 포인팅 장치가 이 클라이언트에 접속될 수 없음을 나타내는데 이용된다. 또한, 비트 7 은 포인팅 장치가 클라이언트와 통신할 수 있는지 여부를 나타내는데 이용될 수 있다. 이 비트의 의도된 사용은 언제 키보드가 무선 링크를 이용하여 클라이언트와 통신할 수 있는지를 나타낸다. 비트 6 내지 0 이 포인팅 장치가 클라이언트에 접속될 수 없음을 나타낸다면, 비트 7 은 0 으로 설정될 것이다. 따라서, 일 실시형태에서, 비트 7 이 0 인 경우에 포인팅 장치 및 클라이언트는 통신할 수 없지만, 비트 7 의 값이 1 이라면 포인팅 장치 및 클라이언트는 그들이 서로 통신할 수 있음을 확인한다.
컨텐츠 보호 타입 필드 (2 바이트) 는, 디스플레이에 의해 지원되는 디지털 컨텐츠 보호의 타입을 나타내는 플래그 세트를 포함한다. 현재, 비트 위치 0 은 DTCP 가 지원되는 때를 나타내는데 사용되고, 비트 위치 1 은 HDCP 가 지원되는 때를 나타내는데 사용되며, 비트 2 내지 15 는 소망에 따라 또는 이용가능한 경우 다른 보호 방식으로 사용하기 위해 보류되어 이들은 현재 0 으로 설정된다.
Mfr 이름 필드 (여기에서, 2 바이트) 는 제조자의 EISA 3-캐릭터 ID 를 포함하고, VESA EDID 사양에서와 동일한 방식으로 5-비트 캐릭터로 패킷화된다. 캐릭터 'A' 는 00001 바이너리로 표현되고, 캐릭터 'Z' 는 11010 바이너리로 나타내어지며, 'A' 와 'Z' 사이의 모든 문자들은 'A' 와 'Z' 사이의 알파벳 순서에 대응하는 순차적인 바이너리 값들로 표현된다. Mfr 이름 필드의 최상위 비트는 사용되지 않고, 장래의 구현에서 사용될 때까지 현재로서는 로직 0 으로 일반적으로 설정된다. 예: 스트링 "XYZ" 에 의해 나타내어지는 제조자는 0x633a 의 Mfr 이름 값을 가질 것이다. 이 필드가 클라이언트에 의해 지원되지 않는다면, 일반적으로 0 으로 설정된다. 제품 코드 필드는 디스플레이 제조자에 의해 할당된 제품 코드를 포함하는 2 바이트를 이용한다. 이 필드가 클라이언트에 의해 지원되지 않는다면, 일반적으로 0 으로 설정된다.
보류 1, 보류 2 및 보류 3 필드 (여기에서 각각 2 바이트) 는 장래에 정보를 수여하는데 사용하기 위해 보류된다. 이들 필드의 모든 비트는 일반적으로 로직 0 레벨로 설정된다. 이러한 필드의 목적은 모든 후속하는 2 바이트 필드로 하여금 16-비트 워드 어드레스에 정렬되게 하고 4-바이트 필드로 하여금 32-비트 워드 어드레스에 정렬되게 하는 것이다.
일 실시형태에서 시리얼 번호 필드는 숫자 형식으로 디스플레이의 시리얼 번호를 특정하기 위하여 4 바이트를 사용한다. 이 필드가 클라이언트에 의해 지원되지 않는다면, 일반적으로 0 으로 설정된다. 제조 주 (Week of Manufactured) 필드는 디스플레이의 제조 주를 규정하기 위하여 1 바이트를 사용한다. 이 값은, 클라이언트에 의해 지원된다면, 통상적으로 1 내지 53 의 범위이다. 이 필드가 클라이언트에 의해 지원되지 않는다면, 0 으로 설정된다. 제조 년 (Year of Manufacture) 필드는 디스플레이의 제조 년을 규정하는 1 바이트이다. 이 값은 1990년으로부터의 오프셋이다. 1991 내지 2245 범위의 년도가 이 필드에 의해 표현될 수 있다. 예: 2003 년은 제조 년 값 13 에 대응한다. 이 필드가 클라이언트에 의해 지원되지 않는다면, 0 으로 설정된다.
CRC 필드 (여기서 2 바이트) 는 패킷 길이를 포함하여 패킷 내 모든 바이트의 16 비트 CRC 를 포함한다.
G. 디스플레이 요청 및 상태 패킷에 대하여
역방향 링크 요청 필드 (3 바이트) 는, 클라이언트가 호스트에게 정보를 전송하기 위해 그 다음의 서브 프레임에서 역방향 링크에 필요로 하는 바이트 수를 특정한다.
CRC 오류 카운트 필드 (1 바이트) 는, 미디어 프레임의 시작 이후 얼마나 많은 CRC 오류가 발생하였는지를 나타낸다. CRC 카운트는 0 의 서브 프레임 카운트를 가지는 서브 프레임 헤더 패킷이 전송되는 경우 재설정된다. CRC 오류의 실제 개수가 255 를 초과하면, 이 값은 일반적으로 255 에서 포화된다.
능력 변경 (Capability Change) 필드는 클라이언트의 능력의 변경을 나타내는데 1 바이트를 사용한다. 이는, 사용자가 마이크로폰, 키보드 또는 디스플레이와 같은 주변 장치를 접속하는 경우 또는 어떤 다른 이유 때문에 발생할 수 있다. 비트 [7:0] 가 0 과 동일하면, 최종 클라이언트 능력 패킷이 전송된 이래로 능력은 변하지 않았다. 그러나, 비트 [7:0] 가 1 내지 255 와 동일한 경우에는, 능력은 변하였다. 클라이언트 능력 패킷은 새로운 디스플레이 특징들을 결정하기 위해 조사된다.
클라이언트 비지 플래그 (Client Busy Flag) 필드는 클라이언트가 특정 기능을 수행하고 있으며 아직 그 기능과 관련된 다른 패킷을 받아들일 준비가 되어 있지 않음을 나타내는 2 바이트를 사용한다. 로직 1 레벨 또는 값으로 설정된 비트는 특정 기능이 현재 클라이언트에 의해 수행되고 있으며 클라이언트 내의 관련 기능은 동작 중 (busy) 임을 나타낸다. 클라이언트 내 관련 기능이 준비되면, 비트는 로직 0 으로 설정된다. 클라이언트에서 지원되지 않는 모든 기능에 대해 클라이언트는 동작 중 상태 (1 로 설정된 비트) 로 복귀하여야 한다.
일 실시형태에서, 이들 바이트는 다음 관계에 따라 해석된다. 비트 0 이 '1' 이면 비트맵 블록 전송 기능이 동작 중이고, 비트 1 이 '1' 이면 비트맵 영역 채움 기능이 동작 중이며, 비트 2 가 '1' 이면 비트맵 패턴 채움 기능이 동작 중이다. 동시에, 비트 3 이 '1' 이면 그래픽스 서브시스템은 클라이언트 내 프레임 버퍼의 사용을 요구하는 동작을 수행중이다. 프레임 버퍼의 사용을 요구하는 다른 그래픽스 기능은 이 비트가 로직 1 로 설정될 때까지 시작되지 않을 수도 있다.
현재 비트 4 내지 15 는 장래 사용을 위해 보류되어 있고, 이들 비트가 장래에 할당되는 경우 동작 중 상태를 나타내기 위해 로직 1 레벨 또는 상태로 설정된다.
H. 비트맵 블록 전송 패킷에 대하여
윈도우 상부 좌측 좌표 X 값 및 Y 값 필드는 각각, 이동될 윈도우의 상부 좌측 코너의 좌표 X 및 Y 값을 특정하기 위해 2 바이트를 사용한다. 윈도우 폭 및 높이 필드는 이동될 윈도우의 폭과 높이를 특정하기 위해 각각 2 바이트를 사용한다. 윈도우 X 이동 및 Y 이동 필드는, 윈도우가 수평 및 수직으로 각각 이동될 픽셀 수를 특정하는데 각각 2 바이트를 사용한다. 통상적으로, X 에 대한 양의 값은 윈도우가 우측으로 이동되게 하고 음의 값은 좌측으로 이동되게 하는 한편, Y 에 대한 양의 값은 윈도우를 하부로 이동되게 하고 음의 값은 상부로 이동하게 하도록 이들 좌표들이 구성된다.
I. 비트맵 영역 채움 패킷에 대하여
일 실시형태에서, 2 바이트 픽셀 데이터 속성 필드는, 픽셀 데이터가 어디서 업데이트되는지를 특정하는 값을 가지며, 비트 1 및 0 은 픽셀 데이터가 업데이트될 디스플레이를 선택한다. 클라이언트의 주 디스플레이가 스테레오 이미지를 지원하지 않으면, 클라이언트는 비트 조합 01, 10 또는 11 중 하나에 대해 주 디스플레이의 픽셀 데이터에 영향을 미칠 수 있다. 스테레오 디스플레이 능력을 지원하지 않는 클라이언트에서 주 디스플레이를 어드레스하는데 값 11 이 사용되는 것이 추천된다. 비트 [1:0] 이 값 11 (로직 1, 로직 1) 을 갖는 경우, 픽셀 데이터는 픽셀 데이터는 좌측눈 및 우측눈 모두의 프레임 버퍼에서 업데이트되고, 비트 [1:0] 이 값 10 (로직 1, 로직 0) 을 가지면, 픽셀 데이터는 좌측눈의 프레임 버퍼에서만 업데이트된다. 비트 [1:0] 이 값 01 (로직 0, 로직 1) 을 갖는 경우, 픽셀 데이터는 우측눈의 프레임 버퍼에서만 업데이트된다. 비트 [1:0] 이 값 00 (더블 로직 0) 을 갖는 경우, 픽셀 데이터는 이하 비트 8 내지 11 에 의해 특정되는 교대 디스플레이의 프레임 버퍼에서 업데이트된다.
일 실시형태에서, 픽셀 데이터 속성 필드의 비트 4 는, 좌측눈 또는 우측눈에 대한 버퍼가 이 동작을 위한 이미지의 소스인지 여부를 특정한다. 비트 [1:0] 이 00 과 동일하지 않은 경우 비트 4 만 적용되며, 이것은 일반적으로, 이미지의 수신지가 교대 디스플레이 중 하나인 경우 주 이미지 버퍼로부터의 소스 데이터를 지원하지 않는 것을 의미하도록 구현된다. 비트 4 는 데이터 소스로서 좌측눈 및 우측눈 프레임 버퍼 사이를 구별 또는 특정하는데 사용된다. 또한, 비트 4 의 적용은, 클라이언트 능력 패킷의 클라이언트 특성 능력 지시자 필드의 비트 21, 또는 교대 디스플레이 능력 패킷의 디스플레이 특성 능력 지시자 필드의 비트 21 에 의해 표시되는 특정한 디스플레이 상에서 클라이언트가 래스터 연산을 지원하는 경우로 한정된다. 이용되는 경우, 비트 4 가 0 (로직 0 레벨) 이면 좌측 눈 프레임 버퍼가 데이터 소스지만, 비트 2 가 1 (로직 1 레벨) 이면 우측 눈 프레임 버퍼가 데이터 소스이다.
픽셀 데이터 속성 필드의 비트 5 는, 디스플레이를 리프레쉬하는데 사용되는 버퍼 또는 오프라인 이미지 버퍼가 이 동작에 대한 수신지 이미지로서 래스터 연산에 대한 입력이 될지 여부를 특정한다. 또한, 교대 디스플레이가 오프라인 이미지 버퍼를 이용하면, 비트 5 는 교대 디스플레이에 인가될 수도 있다. 그러나, 이것은, 이미지의 수신지가 교대 디스플레이 또는 그 역인 경우 주 이미지로부터의 소스 데이터를 지원하지 않는다. 사용되는 경우, 비트 5 가 0 값 또는 로직 0 레벨과 동일한 경우, 디스플레이를 리프레쉬하는데 사용되는 이미지 버퍼가 데이터 소스이다. 비트 5 가 1 값 또는 로직 1 레벨과 동일한 경우, 오프라인 이미지 버퍼가 데이터 소스이다.
픽셀 데이터 속성 필드의 비트 7 및 6 은, 픽셀 데이터가 업데이트 또는 기록될 프레임 버퍼를 특정하는 디스플레이 업데이트 비트로서 동작한다. 프레임 업데이트 비트의 효과는 상술하였다. 비트 [7:6] 가 '01' (로직 0, 로직 1) 인 경우, 픽셀 데이터는 오프라인 이미지 버퍼에 기록된다. 비트 [7:6] 이 '00' (더블 로직 0) 인 경우 픽셀 데이터는 디스플레이를 리프레쉬하는데 사용되는 이미지 버퍼에 기록된다. 비트 [7:6] 이 '11' (더블 로직 1) 인 경우, 픽셀 데이터는 모든 이미지 버퍼에 기록된다. 비트 [7:6] 이 '10' 인 경우, 무효인 값으로 취급된다. 이 비트들은 현재 장래의 사용을 위해 보류되어 있다. 이 상황에서, 전체 커맨드는 무시되고 어떠한 프레임 버퍼도 업데이트되지 않는다.
픽셀 데이터 속성 필드의 비트 11 내지 8 은, 픽셀 데이터가 업데이트될 교대 디스플레이 또는 교대 클라이언트 위치를 특정한다. 비트 0 및 1 은, 클라이언트가 비트 11 내지 8 을 교대 디스플레이 수로서 해석하도록 하기 위해 00 의 값과 동일한 값으로 설정된다. 비트 1 및 0 이 00 과 동일하지 않으면, 비트 8 내지 11 은 일반적으로 로직 0 값 또는 레벨로 설정된다. 비트 2, 3 및 12 내지 15 는 장래의 사용을 위해 보류되고 일반적으로 로직 0 레벨 또는 값으로 설정된다.
일 실시형태에서, 2 바이트 래스터 연산 필드는, 소스 및 수신지 위치에서 픽셀을 합성하여 수신지 이미지 위치에 기록될 새로운 픽셀 값을 형성하는 방법을 특정한다. 래스터 연산은 프레임 버퍼에서 동일한 크기의 2 개의 상이한 장방형 영역이 함께 병합되는 방법을 규정한다. 또한, 수신지 이미지 영역은 함께 병합되는 2 개의 이미지 중 하나이다. 2 이미지의 2 번째를 소스 이미지라 한다. 클라이언트가 클라이언트 능력 패킷에서 특정된 바와 같은 래스터 연산 필드를 지원하지 않으면, 호스트는 일반적으로 이 패킷을 3 과 동일한 비트 3 내지 0 으로 전송하고 클라이언트는 비트 3 내지 0 을 무시한다.
일 실시형태에서, 비트 3 내지 0 은, 실제 래스터 연산을 이하 표 16 에 도시된 값들 중 하나로 특정하여 그 값의 다음에 나타낸 대응 연산을 선택하는데 사용된다. 즉, 제 1 열에 리스트된 각각의 특정 비트 [3:0] 값은 제 2 열에 특정된 동작을 유발시키고, 제 3 열에서 더 명확히 규정된다.
비트 [3:0] 값 수신지 위치에 저장된 값 규정
0 0
1 소스 & 수신지 로직 AND 연산
2 소스 & ~수신지 소스 AND (낫 (not) 수신지)
3 소스
4 ~소스 & 수신지 (낫 소스) AND 수신지
5 수신지 연산 없음
6 소스 ^ 수신지 로직 XOR 연산
7 소스 │ 수신지 로직 OR 연산
8 ~(소스 │ 수신지) 낫 (소스 OR 수신지)
9 ~(소스 ^ 수신지) 낫 (소스 XOR 수신지)
10 ~(수신지) 낫 (수신지)
11 소스 │ ~수신지 소스 OR (낫 수신지)
12 ~소스 낫 소스
13 ~소스 │ 수신지 (낫 소스) OR 수신지
14 ~(소스 & 수신지) 낫 (소스 AND 수신지)
15 올 1
비트 9 내지 8 은 수신지 픽셀이 투명 컬러와 관련된 수신지 위치에 기록되는지 여부를 특정하는데 사용된다. 클라이언트 능력 패킷의 클라이언트 특성 능력 지시자 필드의 비트 4 는, 투명 컬러 및 투명 마스크 능력이 클라이언트에 의해 지원되는지 여부를 나타낸다. 유사하게, 교대 디스플레이 능력 패킷의 디스플레이 특성 능력 지시자 필드의 비트 4 는, 투명 컬러 및 투명 마스크 능력이 특정 교대 디스플레이에 의해 지원되는지 여부를 나타낸다. 투명 컬러 및 투명 마스크가 지원되지 않으면, 래스터 연산은 비트 [9:8] 이 00 으로 설정된 것처럼 동작한다. 비트 [9:8] 에 의해 특정되는 동작은, 래스터 연산이 클라이언트 디바이스에 의해 지원되는지 여부를 적용한다. 클라이언트가 래스터 연산을 지원하지 않으면, 비트 [9:8] 에 의해 정의되는 동작에 대해 고려될 해당 수신지 픽셀은 소스 픽셀값에만 동일하다. 이러한 동작은 비트 [3:0] 이 3 으로 설정되는 것과 동일하다.
비트 [9:8] 이 00 과 동일한 경우, 투명 컬러는 사용되지 않는다. 해당 수신지 픽셀은 투명 컬러 인에이블 패킷에 의해 규정된 투명 컬러의 값을 고려하지 않고 수신지 픽셀 위치에 기록된다. 투명 컬러는 투명 컬러 및 마스크 설정 패킷에 의해 정의된다. 10 과 동일한 비트 [5:4] 의 값은 현재 장래의 사용을 위해 보류되고 통상적으로 사용되지 않는다. 비트 [5:4] 의 값이 10 과 동일한 경우, 소스 픽셀을 투명 마스크와 AND 하는 레스터 연산에 의해 연산된 해당 수신지 픽셀이 투명 컬러와 동일하면 해당 픽셀은 수신지 위치에 기록되지 않는다. 그렇지 않으면, 수신지 픽셀 위치에 기록된다. 비트 [9:8] 의 값이 11 과 동일한 경우, 래스터 연산에 의해 연산된 수신지 픽셀이 투명 컬러와 동일하면, 해당 픽셀은 수신지 픽셀 위치에 기록된다. 그렇지 않으면, 해당 픽셀은 수신지 픽셀 위치에 기록되지 않는다.
비트 15 내지 10 및 7 내지 4 는 장래의 사용을 위해 보류되고, 따라서, 일반적으로 로직 0 값 또는 레벨로 설정된다.
비트 15 내지 10 및 7 내지 4 는 장래의 사용을 위해 보류되고, 따라서, 일반적으로 로직 0 값 또는 레벨로 설정된다.
J. 비트맵 패턴 채움 패킷에 대하여
일 실시형태에서, 비트맵 패턴 채움 패킷의 윈도우 상부 좌측 좌표 X 값 및 Y 값 필드는 2 바이트를 사용하여 채워질 윈도우의 상부 좌측 코너 좌표의 X 및 Y 값을 각각 특정한다. 윈도우 폭 및 높이 필드 (각각 2 바이트) 는 채워질 윈도우의 폭 및 높이를 특정한다. 패턴 폭 및 패턴 높이 필드 (각각 2 바이트) 는 각각 채움 패턴의 폭 및 높이를 특정한다. 수평 패턴 오프셋 필드 (2 바이트) 는 채워질 특정 윈도우의 좌측 에지로부터 픽셀 데이터 패턴의 수평 오프셋을 특정한다. 특정되는 값은 패턴 폭 필드에서의 값 미만일 것이다. 수직 패턴 오프셋 필드 (2 바이트) 는 채워질 특정 윈도우의 탑 에지로부터의 픽셀 데이터 패턴의 수직 오프셋을 특정한다. 특정되는 값은 패턴 높이 필드에서의 값 미만일 것이다.
일 실시형태에서, 2 바이트 픽셀 데이터 속성 필드는, 픽셀 데이터가 어디서 업데이트되는지를 특정하며, 비트 1 및 0 은 픽셀 데이터가 업데이트될 디스플레이를 선택한다. 클라이언트의 주 디스플레이가 스테레오 이미지를 지원하지 않으면, 클라이언트는, 비트 조합 01, 10 또는 11 중 하나에 대한 주 디스플레이에서의 픽셀 데이터에 영향을 미칠 수 있다. 스테레오 디스플레이 능력을 지원하지 않는 클라이언트 내 주 디스플레이에 어드레스하는데 값 11 이 추천된다. 비트 [1:0] 이 값 11 (로직 1, 로직 1) 을 가지는 경우, 픽셀 데이터는 좌측눈 및 우측눈 모두의 프레임 버퍼에서 업데이트되고, 비트 [1:0] 이 값 10 (로직 1, 로직 0) 을 가지면, 픽셀 데이터는 좌측눈의 프레임 버퍼에서만 업데이트된다. 비트 [1:0] 이 값 01 (로직 0, 로직 1) 을 가지는 경우, 픽셀 데이터는 우측눈의 프레임 버퍼에서만 업데이트된다. 비트 [1:0] 가 값 00 (더블 로직 0) 을 가지는 경우, 픽셀 데이터는 이하 비트 8 내지 11 에 의해 특정되는 교대 디스플레이의 프레임 버퍼에서 업데이트된다.
비트 3 내지 2 는 장래의 사용을 위해 보류되고 0 으로 설정된다.
비트 4 는, 이 연산을 위한 수신지 이미지로서 래스터 연산의 입력이 좌측눈에 대한 버퍼인지 우측눈에 대한 버퍼인지 여부를 특정한다. 비트 4 는, 이미지의 수신지가 교대 디스플레이 중 하나인 경우 주 이미지 버퍼로부터의 소스 데이터가 지원되지 않음을 의미하는, 비트 [1:0] 이 00 이 아닌 경우에만 적용된다. 또한, 일반적으로, 클라이언트 능력 패킷의 클라이언트 특성 능력 지시자 필드의 비트 21, 또는 교대 디스플레이 능력 패킷의 디스플레이 특성 능력 지시자 필드의 비트 21 에 의해 표시되는 특정 디스플레이 상에서 클라이언트가 래스터 연산을 지원하는 경우에만 비트 4 가 적용된다. 비트 4 가 0 인 경우, 좌측눈 프레임 버퍼가 데이터 소스이고, 비트 4 가 1 인 경우 우측눈 프레임 버퍼가 데이터 소스이다.
비트 5 는, 이 연산을 위한 수신지 이미지로서 래스터 연산의 입력으로 동작하는 버퍼가, 디스플레이를 리프레쉬하는데 사용되는 버퍼인지 또는 오프라인 버퍼인지 여부를 특정한다. 또한, 교대 디스플레이가 오프라인 이미지 버퍼를 이용하면 비트 5 가 교대 디스플레이에 적용될 수도 있다. 이미지의 수신지가 교대 디스플레이 중 하나인 경우 주 이미지 버퍼로부터의 소스 데이터가 지원되지 않는다. 비트 5 가 0 인 경우, 디스플레이를 리프레쉬하는데 사용되는 이미지 버퍼가 데이터 소스이고, 비트 5 가 1 인 경우, 오프라인 이미지 버퍼가 데이터 소스이다.
픽셀 데이터 속성 필드의 비트 7 및 6 은, 픽셀 데이터가 업데이트되거나 기록될 프레임 버퍼를 특정하는 디스플레이 업데이트 비트로서 동작한다. 프레임 업데이트 비트의 효과는 상술하였다. 비트 [7:6] 이 '01' (로직 0, 로직 0) 인 경우, 픽셀 데이터는 오프라인 이미지 버퍼로 업데이트된다. 비트 [7:6] 이 '00' (더블 로직 0) 인 경우, 픽셀 데이터는 디스플레이를 리프레쉬하는데 사용되는 이미지 버퍼로 기록된다. 비트 [7:6] 이 '11' (더블 로직 1) 인 경우, 픽셀 데이터는 모든 이미지 버퍼에서 업데이트된다. 비트 [7:6] 이 '10' 인 경우, 이것은 무효값으로 취급된다. 이 비트들은 현재 장래의 사용을 위해 보류되어 있다. 이 경우, 전체 커맨드는 무시되고 어떠한 프레임 버퍼도 업데이트되지 않는다.
픽셀 데이터 속성 필드의 비트 11 내지 8 은, 픽셀 데이터가 업데이트될 교대 클라이언트 위치 또는 디스플레이를 특정한다. 클라이언트가 비트 11 내지 8 을 교대 디스플레이 수로 해석하도록 하기 위해, 비트 0 및 1 은 값 00 (더블 로직 0) 과 동일하게 설정된다. 비트 1 및 0 이 00 과 동일하지 않으면, 비트 8 내지 11 은 일반적으로 로직 0 값 또는 레벨과 동일하게 설정된다. 비트 2, 3 및 12 내지 15 는 장래의 사용을 위해 보류되고, 일반적으로 로직 0 레벨 또는 값으로 설정된다.
일 실시형태에서, 2 바이트 래스터 연산 필드는, 소스 및 수신지 위치에서 픽셀을 합성하여 수신지 이미지 위치에 기록될 새로운 픽셀값을 형성하는 방법을 특정한다. 래스터 연산은, 프레임 버퍼에서 동일한 크기의 2 개의 상이한 장방형 영역이 함께 병합되는 방법을 규정한다. 또한, 수신지 이미지 영역은 함께 병합되는 2 개의 이미지 중 하나이다. 2 이미지 중 2 번째를 소스 이미지라 한다. 클라이언트가 클라이언트 능력 패킷에서 특정되는 바와 같이 래스터 연산 필드를 지원하지 않으면, 호스트는 일반적으로 이 패킷을 3 과 동일한 비트 3 내지 0 으로 전송하고, 클라이언트는 비트 3 내지 0 을 무시한다.
일 실시형태에서, 비트 3 내지 0 은, 실제 래스터 연산을 이하 표 17 에 도시된 값들 중 하나로 특정하여 그 값의 다음에 나타낸 대응 연산을 선택하는데 사용된다. 즉, 제 1 열에 리스트된 각각의 특정 비트 [3:0] 값은 제 2 열에 특정된 동작을 유발시키고, 제 3 열에서 더 명확히 규정된다.
비트 [3:0] 값 수신지 위치에 저장된 값 규정
0 0
1 소스 & 수신지 로직 AND 연산
2 소스 & ~수신지 소스 AND (낫 (not) 수신지)
3 소스
4 ~소스 & 수신지 (낫 소스) AND 수신지
5 수신지 연산 없음
6 소스 ^ 수신지 로직 XOR 연산
7 소스 │ 수신지 로직 OR 연산
8 ~(소스 │ 수신지) 낫 (소스 OR 수신지)
9 ~(소스 ^ 수신지) 낫 (소스 XOR 수신지)
10 ~(수신지) 낫 (수신지)
11 소스 │ ~수신지 소스 OR (낫 수신지)
12 ~소스 낫 소스
13 ~소스 │ 수신지 (낫 소스) OR 수신지
14 ~(소스 & 수신지) 낫 (소스 AND 수신지)
15 올 1
비트 9 내지 8 은, 수신지 픽셀이 투명 컬러에 관련되는 수신지 위치에 기록되는지 여부를 특정하는데 사용된다. 클라이언트 능력 패킷의 클라이언트 특성 능력 지시자 필드의 비트 4 는, 투명 컬러 및 투명 마스크 능력이 클라이언트에 의해 지원되는지 여부를 나타낸다. 유사하게, 교대 디스플레이 능력 패킷의 디스플레이 특성 능력 지시자의 비트 4 는, 투명 컬러 및 투명 마스크 능력이 특정 교대 디스플레이에 의해 지원되는지 여부를 나타낸다. 투명 컬러 및 투명 마스크가 지원되지 않는 경우, 래스터 연산은 비트 [9:8] 가 00 으로 설정된 것처럼 동작한다. 비트 [9:8] 에 의해 특정되는 동작은, 래스터 연산이 클라이언트 디바이스에 의해 지원되는지 여부를 적용한다. 클라이언트가 래스터 연산을 지원하지 않으면, 비트 [9:8] 에 의해 정의되는 연산에 대해 고려되는 해당 수신지 픽셀 값은 소스 픽셀 값에만 동일하다. 이 동작은 비트 [3:0] 이 3 으로 설정된 것과 동일하다.
픽셀 데이터 속성 필드의 비트 [9:8] 의 값이 00 과 동일한 경우, 투명 컬러는 사용되지 않는다. 해당 수신지 픽셀은 투명 컬러 또는 투명 마스크의 값을 고려하지 않고 수신지 픽셀 위치에 기록된다. 투명 컬러는 투명 컬러 및 마스크 설정 패킷에 의해 정의된다. 01 과 동일한 비트 [5:4] 값은 현재 장래의 사용을 위해 보류되어 있고 통상적으로 사용되지 않지만, 당업자가 관련된 사용을 확립하는데 이용할 수도 있다. 비트 [5:4] 의 값이 10 인 경우, 소스 픽셀을 투명 마스크와 AND 하는 래스터 연산에 의해 연산된 해당 수신지 픽셀이 투명 컬러와 동일하면 해당 픽셀은 수신지 픽셀 위치에 기록되지 않는다. 그렇지 않으면, 수신지 픽셀 위치에 기록된다. 비트 [9:8] 의 값이 11 과 동일한 경우, 래스터 연산에 의해 연산된 해당 수신지 픽셀이 투명 컬러와 동일하면 해당 픽셀은 수신지 픽셀 위치에 기록된다. 그렇지 않으면 해당 픽셀은 수신지 픽셀 위치에 기록되지 않는다.
비트 15 내지 10 및 7 내지 4 는 장래의 사용을 위해 보류되고, 따라서 일반적으로 로직 0 값 또는 레벨과 동일하게 설정된다.
일 실시형태에서, 비트맵 패턴 채움 패킷의 2 바이트 파라미터 CRC 필드는 패킷 길이부터 비디오 형식 디스크립터까지의 모든 바이트의 CRC 를 포함한다. 이 CRC 가 체크를 실패하면, 전체 패킷은 폐기된다. 패턴 픽셀 데이터 필드는, 비디오 데이터 형식 디스크립터에 의해 특정되는 형식에서 채움 패턴을 특정하는 미가공 비디오 정보를 포함한다. 데이터는 바이트로 패킷화되고 각 행의 제 1 픽셀은 바이트 정렬될 것이다. 채움 패턴 데이터는 일시에 행으로 송신된다. 비트맵 패턴 채움 패킷에 대한 패턴 픽셀 데이터 CRC 필드는, 패턴 픽셀 데이터만의 CRC 를 포함하는 2 바이트를 사용한다. 이 CRC 가 체크를 실패하면, 패턴 픽셀 데이터는 여전히 사용될 수 있지만, CRC 오류 카운트는 증가될 것이다.
K. 순방향 오디오 채널 인에이블 패킷에 대하여
오디오 채널 인에이블 마스크 필드 (1 바이트) 는 클라이언트에서 어떤 오디오 채널이 인에이블될지를 나타내는 플래그 그룹을 포함한다. 1 로 설정된 비트는 대응하는 채널을 인에이블시키고, 0 으로 설정된 비트는 대응하는 채널을 디스에이블시킨다. 비트 0 내지 5 는, 좌측 전방, 우측 전방, 좌측 후방, 우측 후방, 전방 중앙, 및 서브-우퍼 채널을 각각 담당하는 채널 0 내지 5 를 지정한다. 비트 6 및 7 은 장래의 사용을 위해 보류되고, 일반적으로 한동안 0 과 동일하게 설정된다.
L. 역방향 오디오 샘플 레이트 패킷에 대하여
오디오 샘플 레이트 필드 (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) 을 지정하는데 사용되고, 9 내지 254 의 값은 희망에 따라 다른 레이트 사용을 위해 보류되어 이들은 현재 '0' 으로 설정된다. 255 의 값은 역방향 링크 오디오 스트림을 디스에이블 하는데 사용된다.
샘플 형식 필드 (1 바이트) 는 디지털 오디오 샘플의 형식을 특정한다. 비트 [1:0] 가 '0' 과 동일하면, 디지털 오디오 샘플은 리니어 형식이고, 1 과 동일하면 디지털 오디오 샘플은 μ-로우 (μ-Law) 형식이며, 2 와 동일하면 그 디지털 오디오 샘플은 A-로우 (A-Law) 형식이다. 비트 [7:2] 는 희망에 따라 오디오 형식을 지정하는 다른 사용을 위해 보류되고, 일반적으로 0 과 동일하게 설정된다.
M. 디지털 컨텐츠 보호 오버헤드 패킷에 대하여
컨텐츠 보호 타입 필드 (1 바이트) 는 사용되는 디지털 컨텐츠 보호 방법을 특정한다. '0' 의 값은 디지털 송신 컨텐츠 보호 (DTCP) 를 나타내고 1 의 값은 고 대역 디지털 컨텐츠 보호 시스템 (HDCP) 을 나타낸다. 2 내지 255 의 값은 현재 특정되지는 않지만 희망에 따라 다른 보호 방식의 사용을 위해 보류된다. 컨텐츠 보호 오버헤드 메시지 필드는 호스트와 클라이언트 사이에서 전송되는 컨텐츠 보호 메시지들을 포함하는 가변 길이 필드이다.
N. 라운트 트립 지연 측정 패킷에 대하여
2-바이트 패킷 길이 필드는 패킷 길이 필드를 제외한 패킷 내 바이트의 총 수를 특정하며, 일 실시형태에서 159 의 고정된 길이를 갖도록 선택된다. 2-바이트 패킷 타입 필드는 값 82 로 이러한 패킷 타입을 식별하고, 패킷을 라운드 트립 지연 측정 패킷으로 식별한다. h클라이언트 ID 필드는 이전과 같이, 클라이언트 ID 로서의 장래 사용을 위해 보류되고 일반적으로 0 으로 설정된다.
일 실시형태에서, 파라미터 CRC 필드 (2 바이트) 는 패킷 길이에서부터 패킷 타입까지 모든 바이트의 16-비트 CRC 를 포함한다. 이 CRC 가 확인을 실패하면, 전체 패킷은 폐기된다.
보호 시간 1 필드 (여기에서 64 바이트) 는 호스트 내의 라인 드라이버가 디스에이블되기 전에 클라이언트 내의 MDDI_Data 라인 드라이버가 인에이블할 수 있도록 하는데 이용된다. 클라이언트는 보호 시간 1 의 비트 0 동안 그 MDDI_Data 라인 드라이버를 인에이블시키고, 호스트는 보호 시간 1 의 최후 비트 전에 완전하게 디스에이블되도록 그 라인 드라이버를 디스에이블시킨다. 호스트와 클라이언트 모두는 그들이 디스에이블되지 않은 경우에 보호 시간 1 동안 로직 0 레벨을 구동한다. 이 필드의 다른 목적은, 호스트의 라인 드라이버를 디스에이블하기 전에 MDDI_Stb 만을 이용하여 클라이언트가 클록 또는 클록 신호의 복구를 시작할 수 있도록 하기에 충분한 시간 동안 모든 MDDI_Data 신호들이 로직 0 레벨에 있을 것을 보장하는 것이다.
측정 기간 (Measurement Period) 필드는 클라이언트가 0xff 의 2 바이트, 및 순방향 링크에서 사용되는 데이터 레이트의 절반에서 0x00 의 30 바이트로 응답할 수 있도록 하는데 사용되는 64 바이트 윈도우이다. 이 데이터 레이트는 1 의 역방향 링크 레이트 제수에 대응한다. 클라이언트는 측정 기간의 시작인 것으로 인식하는 시점에 즉시 이 응답을 반환한다. 클라이언트로부터의 이러한 응답은 호스트에서의 측정 기간의 최초 비트의 시작 후, 정확히 클라이언트에서의 로직 지연과 링크의 라운드 트립 지연을 더한 시간에 호스트에서 수신될 것이다.
올 제로 1 필드 (2 바이트) 는 호스트 및 클라이언트 내의 MDDI_Data 라인 드라이버가 오버래핑할 수 있도록 하여 MDDI_Data 가 언제나 구동되도록 하는 0 들을 포함한다. 호스트는 올 제로 필드 1 의 비트 0 동안 MDDI_Data 라인 드라이버를 인에이블하고, 클라이언트도 측정 기간의 끝에서와 같이 신호를 로직 0 레벨로 구동한다.
보호 시간 2 필드의 값 (64 바이트) 은, 라운드 트립 지연이 측정 기간에서 측정될 수 있는 최대량인 경우에, 클라이언트에 의해 구동되는 측정 기간의 오버랩을 허용한다. 클라이언트는 보호 시간 2 의 비트 0 동안 그 라인 드라이버를 디스에이블시키고, 호스트는 보호 시간 2 의 최후 비트 후에 즉시 그 라인 드라이버를 인에이블시킨다. 호스트와 클라이언트 모두는 그들이 디스에이블되지 않은 경우에 보호 시간 2 동안 로직 0 레벨을 구동한다. 이 필드의 다른 목적은, 클라이언트가 호스트에 대한 라인 드라이버를 인에이블링한 후에 MDDI_Data0 및 MDDI_Stb 모두를 이용하여 클록 신호 복구를 시작할 수 있게 하는데 충분한 시간 동안 모든 MDDI_Data 신호들이 로직 0 레벨에 있는 것을 보장하는 것이다.
O. 순방향 링크 스큐 교정 패킷에 대하여
일 실시형태에서, 파라미터 CRC 필드 (2 바이트) 는 패킷 길이에서부터 패킷 타입까지의 모든 바이트의 16-비트 CRC 를 포함한다. 이 CRC 가 확인을 실패하면, 전체 패킷은 폐기된다.
올 제로 1 필드는 교정 데이터 시퀀스 필드의 개시에서 MDDI_Stb 상의 천이가 있을 것이라는 것을 보장하기 위해 8 바이트를 사용한다. 일반적으로, 이러한 바이트들은 0 과 동일한 8-비트 무부호 정수를 채용한다. 또한, 클라이언트 코어 로직이 클록 복구 회로의 모드를, MDDI_0 과 MDDI_Stb 의 XOR 을 이용하는 것으로부터 단순히 MDDI_Stb 또는 MDDI_Stb 신호를 복구된 클록으로서 이용하는 것으로 변경하는데 충분한 시간을 제공한다.
교정 데이터 시퀀스 필드는 모든 데이터 기간에서 MDDI_Data 신호가 토글링하도록 하는 데이터 시퀀스를 포함한다. 교정 데이터 시퀀스 필드의 길이는 순방향 링크 상에서 사용되고 있는 인터페이스에 의해 결정된다. 교정 데이터 시퀀스의 프로세싱 동안, MDDI 호스트 제어기는 모든 MDDI_Data 신호를 스트로브 신호와 동일하게 설정한다. 클라이언트 클록 복구 회로는, 교정 데이터 시퀀스 필드가 클라이언트에 의해 수신되고 있는 동안 데이터 클록을 복구하기 위해 MDDI_Stb XOR MDDI_Data0 보다는 MDDI_Stb 만을 사용하여야 한다. 교정 데이터 시퀀스 필드의 시작에서 MDDI_Stb 신호의 정확한 위상에 의존하여, 일반적으로 교정 데이터 시퀀스는, 이 패킷이 전송되는 때 사용되고 있는 인터페이스 타입에 기초하여 다음 중의 하나가 될 것이다:
타입 1 - (64 바이트 데이터 시퀀스) Oxaa, Oxaa... 또는 Ox55, Ox55...
타입 2 - (128 바이트 데이터 시퀀스) Oxcc, Oxcc... 또는 Ox33, Ox33...
타입 3 - (256 바이트 데이터 시퀀스) OxfO, OxfO... 또는 OxOf, OxOf...
타입 4 - (512 바이트 데이터 시퀀스) Oxff, OxOO, Oxff, OxOO... 또는 OxOO, Oxff, OxOO, Oxff...
올 제로 2 필드는 8 바이트를 사용하여, 클라이언트 코어 로직이 클록 복구 회로의 모드를, MDDI_Stb 신호를 복구된 클록으로서 사용하는 것으로부터 MDDI_0 과 MDDI_Stb 의 XOR 을 사용하는 원상태로 변경하는데 충분한 시간을 제공한다. 일반적으로, 이 바이트는 0 과 동일한 8 비트 무부호 정수를 채용한다.
타입 1 과 타입 2 모두에 대해 가능한 MDDI_Data 와 MDDI_Stb 파형의 예가 도 62a 와 도 62b 에 각각 도시된다.
XIX. 결론
본 발명의 다양한 실시형태가 상술되었지만, 이들은 한정이 아니라 예시로서만 제공되었음을 이해하여야 한다. 그러므로, 본 발명의 외연 및 범위는 상술한 예시적인 실시형태들 중의 어떠한 실시형태에 의해서도 한정되지 않으며, 다음의 청구범위와 그 균등물에 따라서만 정의되어야 한다.

Claims (48)

  1. 삭제
  2. 삭제
  3. 삭제
  4. 삭제
  5. 삭제
  6. 삭제
  7. 삭제
  8. 삭제
  9. 삭제
  10. 삭제
  11. 삭제
  12. 삭제
  13. 삭제
  14. 삭제
  15. 삭제
  16. 삭제
  17. 삭제
  18. 삭제
  19. 삭제
  20. 삭제
  21. 삭제
  22. 삭제
  23. 삭제
  24. 삭제
  25. 삭제
  26. 삭제
  27. 삭제
  28. 삭제
  29. 삭제
  30. 삭제
  31. 삭제
  32. 삭제
  33. 삭제
  34. 이동 디스플레이 디지털 인터페이스 (MDDI) 시스템에서 복수의 데이터 채널로부터 데이터 채널 각각을 역방향 데이터 샘플링하는 방법으로서,
    호스트로부터 클라이언트로 라운드 트립 지연 측정 패킷을 전송하는 단계;
    상기 데이터 채널 각각에 대한 클라이언트에 의해, 상기 라운드 트립 지연 측정 패킷의 측정 윈도우 내부의 펄스를 상기 호스트로 전송하는 단계;
    상기 데이터 채널 각각에 대한 상기 라운드 트립 지연 측정 패킷의 측정 윈도우 내부에서 전송된 상기 펄스를 검출함으로써 상기 MDDI 시스템의 라운드 트립 지연을 측정하는 단계;
    상기 전송된 펄스의 위상을 결정하는 단계;
    상기 데이터 채널 각각의 측정된 라운드 트립 지연을 저장하는 단계; 및
    상기 데이터 채널 각각의 상기 저장된 라운드 트립 지연에 기초하여 상기 클라이언트에 의해 전송된 역방향 데이터의 샘플링을 개시하는 시간을 결정하는 단계를 포함하는, 역방향 데이터 샘플링 방법.
  35. 제 34 항에 있어서,
    상기 라운드 트립 지연을 측정하는 단계는 상기 호스트로부터 상기 클라이언트로의 전파 지연 및 상기 클라이언트로부터 상기 호스트로의 전파 지연을 측정하는 단계를 포함하는, 역방향 데이터 샘플링 방법.
  36. 제 34 항에 있어서,
    상기 측정된 라운드 트립 지연에 기초하여 역방향 링크 캡슐화 패킷에서 링크 레이트 제수 (divisor) 를 결정하는 단계를 더 포함하는, 역방향 데이터 샘플링 방법.
  37. 이동 디스플레이 디지털 인터페이스 (MDDI) 시스템에서 복수의 데이터 채널로부터 데이터 채널 각각을 역방향 데이터 샘플링하는 시스템으로서,
    호스트로부터 클라이언트로 라운드 트립 지연 측정 패킷을 전송하는 수단;
    상기 데이터 채널 각각에 대한 클라이언트에 의해, 상기 라운드 트립 지연 측정 패킷의 측정 윈도우 내부의 펄스를 상기 호스트로 전송하는 수단;
    상기 데이터 채널 각각에 대한 상기 라운드 트립 지연 측정 패킷의 측정 윈도우 내부에서 전송된 상기 펄스를 검출함으로써 상기 MDDI 시스템의 라운드 트립 지연을 측정하는 수단;
    상기 전송된 펄스의 위상을 결정하는 수단;
    상기 데이터 채널 각각의 측정된 라운드 트립 지연을 저장하는 수단; 및
    상기 데이터 채널 각각의 상기 저장된 라운드 트립 지연에 기초하여 상기 클라이언트에 의해 전송된 역방향 데이터의 샘플링을 개시하는 시간을 결정하는 수단을 구비하는, 역방향 데이터 샘플링 시스템.
  38. 제 37 항에 있어서,
    상기 라운드 트립 지연을 측정하는 수단은 상기 호스트로부터 상기 클라이언트로의 전파 지연 및 상기 클라이언트로부터 상기 호스트로의 전파 지연을 측정하는 수단을 구비하는, 역방향 데이터 샘플링 시스템.
  39. 제 37 항에 있어서,
    상기 측정된 라운드 트립 지연에 기초하여 역방향 링크 캡슐화 패킷에서 링크 레이트 제수를 결정하는 수단을 더 구비하는, 역방향 데이터 샘플링 시스템.
  40. 이동 디스플레이 디지털 인터페이스 (MDDI) 시스템에서 복수의 데이터 채널로부터 데이터 채널 각각을 역방향 데이터 샘플링하게 하는 코드를 포함하는 컴퓨터 판독가능 매체로서,
    상기 컴퓨터 코드는,
    호스트로부터 클라이언트로 라운드 트립 지연 측정 패킷을 전송하게 하는 코드;
    상기 데이터 채널 각각에 대한 클라이언트에 의해, 상기 라운드 트립 지연 측정 패킷의 측정 윈도우 내부의 펄스를 상기 호스트로 전송하게 하는 코드;
    상기 데이터 채널 각각에 대한 상기 라운드 트립 지연 측정 패킷의 측정 윈도우 내부에서 전송된 상기 펄스를 검출함으로써 상기 MDDI 시스템의 라운드 트립 지연을 측정하게 하는 코드;
    상기 전송된 펄스의 위상을 결정하게 하는 코드;
    상기 데이터 채널 각각의 측정된 라운드 트립 지연을 저장하게 하는 코드; 및
    상기 데이터 채널 각각의 상기 저장된 라운드 트립 지연에 기초하여 상기 클라이언트에 의해 전송된 역방향 데이터의 샘플링을 개시하는 시간을 결정하게 하는 코드를 포함하는, 컴퓨터 판독가능 매체.
  41. 제 40 항에 있어서,
    상기 라운드 트립 지연을 측정하게 하는 코드는 상기 호스트로부터 상기 클라이언트로의 전파 지연 및 상기 클라이언트로부터 상기 호스트로의 전파 지연을 측정하게 하는 코드를 포함하는, 컴퓨터 판독가능 매체.
  42. 제 40 항에 있어서,
    상기 측정된 라운드 트립 지연에 기초하여 역방향 링크 캡슐화 패킷에서 링크 레이트 제수를 결정하게 하는 코드를 더 포함하는, 컴퓨터 판독가능 매체.
  43. 삭제
  44. 삭제
  45. 삭제
  46. 삭제
  47. 삭제
  48. 삭제
KR1020077000155A 2004-06-04 2005-06-03 고 데이터 레이트 인터페이스 장치 및 방법 KR100882166B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020077000155A KR100882166B1 (ko) 2004-06-04 2005-06-03 고 데이터 레이트 인터페이스 장치 및 방법

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US60/577,500 2004-06-04
US60/577,793 2004-06-07
KR1020077000155A KR100882166B1 (ko) 2004-06-04 2005-06-03 고 데이터 레이트 인터페이스 장치 및 방법

Related Child Applications (2)

Application Number Title Priority Date Filing Date
KR1020087018473A Division KR100926658B1 (ko) 2004-06-04 2005-06-03 고 데이터 레이트 인터페이스 장치 및 방법
KR1020087018472A Division KR100914420B1 (ko) 2004-06-04 2005-06-03 고 데이터 레이트 인터페이스 장치 및 방법

Publications (2)

Publication Number Publication Date
KR20070023813A KR20070023813A (ko) 2007-02-28
KR100882166B1 true KR100882166B1 (ko) 2009-02-06

Family

ID=41346360

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020077000155A KR100882166B1 (ko) 2004-06-04 2005-06-03 고 데이터 레이트 인터페이스 장치 및 방법

Country Status (1)

Country Link
KR (1) KR100882166B1 (ko)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002049314A2 (en) * 2000-12-15 2002-06-20 Qualcomm Incorporated Generating and implementing a communication protocol and interface for high data rate signal transfer
WO2003023587A2 (en) * 2001-09-06 2003-03-20 Qualcomm, Incorporated Generating and implementing a communication protocol and interface for high data rate signal transfer
WO2003039081A1 (de) 2001-10-31 2003-05-08 Siemens Aktiengesellschaft Verfahren, empfangseinrichtung und sendeeinrichtung zur bestimmung des schnellsten nachrichtenpfades ohne uhrensynchronisation

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002049314A2 (en) * 2000-12-15 2002-06-20 Qualcomm Incorporated Generating and implementing a communication protocol and interface for high data rate signal transfer
WO2003023587A2 (en) * 2001-09-06 2003-03-20 Qualcomm, Incorporated Generating and implementing a communication protocol and interface for high data rate signal transfer
WO2003039081A1 (de) 2001-10-31 2003-05-08 Siemens Aktiengesellschaft Verfahren, empfangseinrichtung und sendeeinrichtung zur bestimmung des schnellsten nachrichtenpfades ohne uhrensynchronisation

Also Published As

Publication number Publication date
KR20070023813A (ko) 2007-02-28

Similar Documents

Publication Publication Date Title
KR100926658B1 (ko) 고 데이터 레이트 인터페이스 장치 및 방법
KR101245962B1 (ko) 고 데이터 레이트 인터페이스 장치 및 방법
KR101019935B1 (ko) 고 데이터 레이트 인터페이스 장치 및 방법
KR100919761B1 (ko) 고 데이터 레이트 인터페이스 장치 및 방법
KR100906319B1 (ko) 링크 동기화를 갖는 고 데이터 레이트 인터페이스
US8650304B2 (en) Determining a pre skew and post skew calibration data rate in a mobile display digital interface (MDDI) communication system
KR100827573B1 (ko) 높은 데이터 레이트 인터페이스
US20060034301A1 (en) High data rate interface apparatus and method
JP2009134746A (ja) 改善されたリンク制御を有する高速データレートインタフェース
KR20060096161A (ko) 향상된 링크 동기화를 제공하는 고속 데이터 레이트인터페이스
KR100882166B1 (ko) 고 데이터 레이트 인터페이스 장치 및 방법

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
A107 Divisional application of patent
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20121227

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20131227

Year of fee payment: 6

FPAY Annual fee payment

Payment date: 20141230

Year of fee payment: 7

LAPS Lapse due to unpaid annual fee