WO2010002412A1 - Exchanging information between components - Google Patents

Exchanging information between components Download PDF

Info

Publication number
WO2010002412A1
WO2010002412A1 PCT/US2008/070093 US2008070093W WO2010002412A1 WO 2010002412 A1 WO2010002412 A1 WO 2010002412A1 US 2008070093 W US2008070093 W US 2008070093W WO 2010002412 A1 WO2010002412 A1 WO 2010002412A1
Authority
WO
WIPO (PCT)
Prior art keywords
transceiver
host processor
bank
information
message
Prior art date
Application number
PCT/US2008/070093
Other languages
French (fr)
Inventor
In Sung Cho
Kumar Mahesh
Prakash Kamath
Jeffrey Gilbert
Rob Frizzell
Original Assignee
Sibeam, Inc.
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
Priority claimed from US12/165,472 external-priority patent/US8897719B2/en
Priority claimed from US12/165,468 external-priority patent/US9531986B2/en
Priority claimed from US12/164,907 external-priority patent/US9264762B2/en
Priority claimed from US12/164,757 external-priority patent/US20090327572A1/en
Priority claimed from US12/165,494 external-priority patent/US20090327547A1/en
Priority claimed from US12/164,810 external-priority patent/US8116333B2/en
Priority claimed from US12/164,849 external-priority patent/US8341271B2/en
Application filed by Sibeam, Inc. filed Critical Sibeam, Inc.
Publication of WO2010002412A1 publication Critical patent/WO2010002412A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/16—Handling requests for interconnection or transfer for access to memory bus
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/42—Bus transfer protocol, e.g. handshake; Synchronisation
    • G06F13/4282—Bus transfer protocol, e.g. handshake; Synchronisation on a serial bus, e.g. I2C bus, SPI bus

Definitions

  • the present invention relates to the field of communicating information between devices in a wireless communication system; more particularly, the present invention relates to a host and transceiver in a wireless communication system, including their interaction, communication, and/or initialization.
  • WirelessHDTM is an industry-led effort to define a specification for the next generation wireless digital network interface specification for wireless high- definition (HD) signal transmission for consumer electronics products.
  • WiHDTM WirelessHDTM
  • the WirelessHDTM (WiHDTM) standard allows for uncompressed digital transmission of HD video and audio and data signals, with a goal of being the same or higher quality as wired HDMI.
  • the specification has been designed and optimized for wireless display connectivity, achieving high-speed rates up to 4 Gbit/s.
  • the signal will operate on the 60 GHz band and support the bandwidth required to support both current and future HD signals. Operation in the 60 GHz band previously required line of sight to communicate between two devices.
  • the WiHD standard overcomes this limitation through the use of beamforming at both the receiver and transmitter to achieve non line of sight communication.
  • the apparatus is for use in a wireless communication system for communicating with a wireless network and comprises a host processor having an I C interface, a transceiver having an I C interface, a physical interface coupling the host processor and the transceiver, the physical interface having an I 2 C bus coupled to the I C interface of both the host processor and the transceiver and multiple separate banks of memory accessible by the host processor and the transceiver to exchange information between the host processor and the transceiver, where the host processor and the transceiver access the plurality of banks of memory via their respective I 2 C interfaces.
  • the apparatus is used in a wireless communication system for communicating with a wireless network, and includes a host processor having an I C interface, a transceiver having an I C interface, and a physical interface coupling the host processor and the transceiver.
  • the physical interface comprises an I C bus coupled to the I C interfaces of both the host processor and the transceiver, and is compatible with HDMI.
  • the apparatus is for use in a wireless communication system for communicating with a wireless network and comprises a host processor, a transceiver, a physical interface coupling the host processor and the transceiver, and a memory accessible by the host processor and the transceiver to exchange information between the host processor and the transceiver.
  • the transceiver is operable to store data in the memory for the host processor to send data to the host processor using the memory and asserts a control signal to the host processor to notify the host processor that the memory contains data for the host processor, and the host processor is operable to access the memory to obtain the data thereafter.
  • the data is associated with a remote device in the wireless network and is stored as one or more packets at a first storage location in the memory with a first identifier identifying the remote device.
  • the method comprises: accessing a memory to obtain one or more bitmaps that map each bit location in the bitmap to an index value, where one index value is assigned to each remote wireless media device of a wireless network in a wireless communication system; and examining those bitmaps and determining at least one characteristic of a remote wireless media device and a device identifier that identifies the remote wireless media device in the wireless network based on the bit position in those bitmaps.
  • a method for initializing a transceiver that is part of an apparatus for use in a wireless communication system for communicating with WirelessHD devices in a wireless network
  • the apparatus comprises a host processor; a transceiver; a physical interface coupling the host processor and the transceiver; and a memory accessible by the host processor and the transceiver to exchange information between the host processor and the transceiver
  • the initialization method comprising resetting the transceiver by initializing internal hardware and software subsystems of the transceiver; after resetting the transceiver, the transceiver entering a configuration state to configure the transceiver; configuring the transceiver, such that the transceiver is configured as part of initialization; and after configuration, the transceiver entering a wait enable state during which the transceiver waits for its wireless interface to be enabled before wireless operation of the transceiver becomes active.
  • a device discovery process is used in a wireless communication system having an apparatus for communicating with WirelessHD devices in a wireless network, where the apparatus comprises a host processor; a transceiver; a physical interface coupling the host processor and the transceiver; and a memory accessible by the host processor and the transceiver to exchange information between the host processor and the transceiver, and the device discovery process comprises: discovering a remote wireless device in the wireless network; notifying, by the transceiver, the host processor of the remote wireless device; requesting, under control of the transceiver, capability information from the remote wireless device prior to receiving a request from the host processor for the capability information; buffering, under control of the transceiver, the capability information before the capability information is requested by the host processor; receiving a capability request from the host processor; and providing the host processor access to the capability information.
  • an apparatus is used in a wireless communication system for communicating with a wireless network, and the apparatus comprises a host processor, a transceiver, a physical interface coupling the host processor and the transceiver; and a memory accessible by the host processor and the transceiver to exchange information between the host processor and the transceiver.
  • the memory has multiple banks that include: a first bank to store information being transferred from the host processor to the transceiver, and a second bank to store information being transferred from the transceiver to the host processor, the second bank being different than the first bank, to facilitate full-duplex communication of packet data between the host processor and the transceiver.
  • Figure 1 illustrates a software architecture of host and transceiver.
  • Figure 2 illustrates a host system protocol stack needed to drive
  • Figure 3 illustrates a standard packet format.
  • Figure 4 illustrates a physical interface between host and transceiver.
  • Figure 5 illustrates a packet format of host AVC messages.
  • Figure 6 illustrates an example Connect Request message packet.
  • Figure 7 illustrates a WirelessHD Connect Request format.
  • Figure 8 illustrates a Feature Abort message format.
  • Figure 9 illustrates a state machine diagram for initialization.
  • Figure 10 is a flow diagram of a wireless transceiver initialization sequence.
  • Figure 11 illustrates a field description of Reset register.
  • Figure 12 illustrates a Location 0 of Status register being set to T by the transceiver when transceiver is loaded.
  • Figure 13 illustrates a field description of a System status register.
  • Figure 14 illustrates a host setting bit location 0 to '1' to clear status register bit location 0.
  • Figure 15 illustrates a set bit location 0 of Host Control register to ' 1 ' to enable WIHD.
  • Figure 16 illustrates bit location 1 is set to T by the transceiver when
  • WIHD is enabled.
  • Figure 17 illustrates a host must set bit location 1 to ' 1 ' to clear status register bit location 1.
  • Figure 18 illustrates a transceiver chip information.
  • Figure 19 illustrates a host capabilities block of AVC Information
  • Figure 20 illustrates a host must set bit location 1 of Host Control register to '1' to set host device capabilities.
  • Figure 21 illustrates bit location 2 being set to '1' to set host input format data.
  • Figure 22 illustrates a three stages of the device discovery process.
  • Figure 23 illustrates a device discovery state-machine.
  • Figure 24 illustrates a Device Detect stage of discovery process.
  • Figure 25 illustrates a device list index to bitfield mapping.
  • Figure 26 illustrates an example Device List with three active devices detected.
  • Figure 27 illustrates Location 2 is set to T by the transceiver when device list is altered.
  • Figure 28 illustrates an example device list update based on system of
  • Figure 29 illustrates a host setting bit location 2 to ' 1 ' to clear status register bit location 2.
  • Figure 30 illustrates a Capability Request stage of discovery process.
  • Figure 31 illustrates a payload structure of a Capabilities Request message.
  • Figure 32 illustrates a Capabilities Request message.
  • Figure 33 illustrates bit location being set 3 to '1' to indicate that TX data is ready for the transceiver.
  • Figure 34 illustrates Location 4 being set to T by the transceiver after it finishes extracting the TX message.
  • Figure 35 illustrates bit location 4 being set to '1' to clear status register bit location 4.
  • Figure 36 illustrates a Capability Response stage of discovery process.
  • Figure 37 illustrates a payload structure of a Capabilities Response message.
  • Figure 38 illustrates a Capabilities Response message as it would appear in register bank 0xA8.
  • Figure 39 illustrates Location 5 being set to T by the transceiver after it finishes writing to the RX bank.
  • Figure 40 illustrates bit location 5 being set to '1' to clear status register bit location 5.
  • Figure 41 illustrates a WirelessHD compliant connection/disconnection control sequence.
  • Figure 42 illustrates a sink host connection control state-machine.
  • Figure 43 illustrates a source host connection control state-machine.
  • Figure 44 illustrates an AVC Connect sequence.
  • Figure 45 is a flow diagram of a wireless transceiver connect sequence.
  • Figure 46 illustrates a payload structure of a Connect Request message.
  • Figure 47 illustrates a Connect Request message as it would appear in the TX (OxAC) or RX (0xA8) register bank.
  • Figure 48 illustrates bit location 3 being set to ' 1 ' to indicate that TX data is ready for the transceiver.
  • Figure 49 illustrates Location 4 being set to T by the transceiver after it finishes extracting the TX message.
  • Figure 50 illustrates bit location 4 being set to ' 1 ' to clear status register bit location 4.
  • Figure 51 illustrates Location 5 being set to T by the transceiver after it finishes writing to the RX bank.
  • Figure 52 illustrates bit location 5 being set to '1' to clear status register bit location 5.
  • Figure 53 illustrates a payload structure of a Connect Response message.
  • Figure 54 illustrates a Connect Response message as it would appear in the TX(OxAC) or RX(0xA8) register bank.
  • Figure 55 illustrates Location 3 being set to T by the transceiver after it finishes writing the input format data.
  • Figure 56 illustrates bit location 3 being set to '1' to clear status register bit location 3.
  • Figure 57 illustrates a payload structure of an Output Format Request message.
  • Figure 58 illustrates an Output Format Request message as it would appear in the TX(OxAC) or RX(0xA8) register bank.
  • Figure 59 illustrates a payload structure of an Output Format Response message.
  • Figure 60 illustrates an Output Format Response message as it would appear in the TX(OxAC) or RX(0xA8) register bank.
  • Figure 61 illustrates a payload structure of a Start Stream Notify message.
  • Figure 62 illustrates a Start Stream Notify message as it would appear in the RX(0xA8) register bank.
  • Figure 63 illustrates an AVC Disconnect sequence.
  • Figure 64 is a flow diagram of a wireless transceiver disconnect sequence.
  • Figure 65 illustrates a payload structure of a Disconnect Notify message.
  • Figure 66 illustrates a Disconnect Notify message as it would appear in the TX(OxAC) or RX(0xA8) register bank.
  • Figure 67 illustrates bit location 3 being set to '1' to indicate that TX data is ready for the transceiver.
  • Figure 68 illustrates Location 4 being set to T by the transceiver after it finishes extracting the TX message.
  • Figure 69 illustrates bit location 4 being set to '1' to clear status register bit location 4.
  • Figure 70 illustrates Location 5 being set to T by the transceiver after it finishes writing to the RX bank.
  • Figure 71 illustrates bit location 5 being set to ' 1 ' to clear status register bit location 5.
  • Figure 72 illustrates a payload structure of a Stop Stream Notify message.
  • Figure 73 illustrates a Stop Stream Notify message as it would appear in the RX(0xA8) register bank.
  • Figure 74 illustrates a payload structure of a Device Control message.
  • Figure 75 illustrates a Device Control message as it would appear in the
  • RX(0xA8) or TX(OxAC) register bank RX(0xA8) or TX(OxAC) register bank.
  • Figure 76A is a block diagram of a host coupled to a transceiver.
  • Figure 76B illustrates a register bank summary.
  • Figure 77 illustrates a register map of AVC Info Registers (1/4).
  • Figure 78 illustrates a register map of AVC Info Registers (2/4).
  • Figure 79 illustrates a register map of AVC Info Registers (3/4).
  • Figure 80 illustrates a register map of AVC Info Registers (4/4).
  • Figure 81 illustrates a bit-description of register 0x06.
  • Figure 82 illustrates a bit-description of register 0x07.
  • Figure 83 illustrates a bit-description of register 0x22.
  • Figure 84 illustrates a Control Register space format.
  • Figure 85 illustrates a field description of Reset register.
  • Figure 86 illustrates a field description of Power Mode register.
  • Figure 87 illustrates a field description of Interface Control register.
  • Figure 88 illustrates a field description of Ready register.
  • Figure 89 illustrates a field description of Host Control register.
  • Figure 90 illustrates a field description of Status register.
  • Figure 91 illustrates a field description of Clear register.
  • Figure 92 illustrates a field description of System status register.
  • Figure 93 illustrates a bit-map layout of Devcap HRRX registers.
  • Figure 94 illustrates a bit-map layout of Devcap HRTX registers.
  • Figure 95 illustrates a bit-map layout of Device Index registers.
  • Figure 96 illustrates a SoC version label resides in the Control register bank (0xA4), offsets 0xF7-0xFB.
  • Figure 97 illustrates a bit-description of register 0xF7.
  • Figure 98 illustrates System Tick registers residing in the Control register bank (0xA4), offsets OxFC - OxFF.
  • Figure 99 illustrates a register space format of a receiver.
  • Figure 100 illustrates a format of sequence field.
  • Figure 101 illustrates a Device Capabilities Message.
  • Figure 102 illustrates a Requested Types bit-field.
  • Figure 103 illustrates a Capabilities Response message.
  • Figure 104 illustrates a Feature Abort message indicating a failure to obtain Capabilities Request information.
  • Figure 105 illustrates a Connect Request message.
  • Figure 106 illustrates a Feature Abort message indicating a failure to obtain a Connect Response.
  • Figure 107 illustrates a Connect Response message.
  • Figure 108 illustrates a Feature Abort message indicating a failure to send the Connect Response.
  • Figure 109 illustrates an Output Format Request message.
  • Figure 110 illustrates an Output Format Response message.
  • Figure 111 illustrates a Stream Start Notify message.
  • Figure 112 illustrates a Disconnect Notify message.
  • Figure 113 illustrates a Stream Stop message.
  • Figure 114 illustrates a Feature Abort message indicating a failure to send the Disconnect Notify.
  • Figure 115 illustrates Device Control messages.
  • Figure 116 illustrates a Feature Abort message indicating a failure of a
  • Figure 117 illustrates a HDMI Pass-Through Request message.
  • Figure 118 illustrates a Feature Abort message indicating a failure to obtain an HDMI Pass-Through Response.
  • Figure 119 illustrates an HDMI Pass-Through Response message.
  • Figure 120 illustrates a Feature Abort message indicating a failure to send the HDMI Pass-Through Response.
  • Figure 121 illustrates an EDID Request message.
  • Figure 122 illustrates a Feature Abort message indicating a failure to obtain an EDID Response.
  • Figure 123 illustrates an EDID Response message.
  • Figure 124 illustrates a Feature Abort message indicating a failure to send the EDID Response.
  • Figure 125 illustrates a Data Island Notify message.
  • Figure 126 illustrates a Feature Abort message indicating a failure to send the Data Island Notify.
  • Figure 127 illustrates a CEC Notify message.
  • Figure 128 illustrates a Feature Abort message indicating a failure to send the CEC Notify.
  • Figure 129 illustrates a CEC NAK message.
  • Figure 130 illustrates a Feature Abort message indicating a failure to send the CEC NAK.
  • Figure 131 illustrates a Logical Address Table Notify message.
  • Figure 132 illustrates definitions of the logical address bitmap.
  • Figure 133 illustrates a Feature Abort message indicating a failure to send the Logical Address Table Notify
  • Figure 134 illustrates an HPD Notify message.
  • Figure 135 illustrates a Feature Abort message indicating a failure to send the HPD Notify.
  • Figure 136 illustrates a Feature Abort message indicating unrecognized opcode.
  • Figure 137 is a block diagram of one embodiment of a radio chip.
  • Figure 138 is a block diagram of one embodiment of a communication system.
  • Figure 139 is a block diagram of one embodiment of a receiver device that is part of a display.
  • Figure 140 is a block diagram of one embodiment of a transmitter device and a receiver device that are part of an adaptive beam forming multiple antenna radio system containing of Figure 138.
  • Figure 141 is a block diagram of a computer system.
  • Figure 142 is a flow diagram of one embodiment of a bitmap device identification process.
  • Figure 143 is a flow diagram of one embodiment of a device discovery process for use in a wireless communication system.
  • Figure 144 illustrates a connection control flow through transmit and receive register banks.
  • Figure 145 illustrates a connection control flow through transmit and receive register banks with a separate data exchange through the AVC information register bank.
  • the present invention also relates to apparatus for performing the operations herein.
  • This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer.
  • a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
  • ROMs read-only memories
  • RAMs random access memories
  • EPROMs electrically erasable programmable read-only memories
  • EEPROMs electrically erasable programmable read-only memory
  • magnetic or optical cards or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
  • a machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer).
  • a machine-readable medium includes read only memory (“ROM”); random access memory (“RAM”); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.); etc.
  • ROM read only memory
  • RAM random access memory
  • magnetic disk storage media includes magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.); etc.
  • AVC Host Interface are described.
  • a host controller device to interface with a WirelessHD transceiver in a wireless network is also described.
  • an Audio/Video Controller is an embedded component that interfaces between the host system and a wireless network.
  • Consumer Electronics CE refers to a term referring to any of various electronic devices that a typical consumer might own such as a television, DVD player, etc.
  • a Host Audio/Video Controller (Host AVC) is a component on the host system that understands how to communicate with the embedded AVC component.
  • the Host AVC initiates and controls communications on the wireless network.
  • the I 2 C Protocol an Inter-Integrated Circuit Protocol, is a multi-master serial bus used to enable low-speed communications between processors or computers.
  • the WirelessHD transceiver transfers high-definition audio- video (AV) content wirelessly between devices. From the host's perspective, there are several control operations that can be affected, including initialization of the transceiver; discovering remote WirelessHD devices on the network; connecting to/disconnecting from a remote WirelessHD device; executing device control commands on a remote WirelessHD device; and interfacing wireless controls and behavior.
  • initialization of the transceiver discovering remote WirelessHD devices on the network
  • connecting to/disconnecting from a remote WirelessHD device executing device control commands on a remote WirelessHD device
  • interfacing wireless controls and behavior One embodiment of the interface to a WirelessHD transceiver to achieve the described operations is described herein.
  • Figure 1 is a block diagram of one embodiment of the system model.
  • the host software represents the host protocol stack that enables the consumer electronics (CE) device to interface with the transceiver.
  • Figure 2 illustrates one embodiment of a host system protocol stack.
  • system control 201 exercises high level system control and interface to the user, serving a similar role as the Application layer of the OSI model. In one embodiment, all wireless specific information is hidden from this layer.
  • Host control 202 serves a similar role as the Presentation and Session layers of the OSI model by managing the state-machine associated with connection/disconnection and control dialogue.
  • Host AVC 203 encapsulates WirelessHD and other specific packet formats and communication sequences in an API library for the layer of host control 202.
  • Communication (comm) driver 204 has the capability to format messages properly and in proper sequence on the bus connecting the host system to the WirelessHD transceiver.
  • Hardware Abstraction Layer (HAL) 205 is the physical driver of the interface.
  • transceiver uses the standard 8-bit addressing mode described in "The I 2 C-BuS Specification v.2.1, January 2000 (9398-393-40011)" with the transceiver being the slave device and the host being the master.
  • Figure 3 illustrates generic read and writes sequences for I 2 C.
  • the generic read and write sequences used for I 2 C bus are the same protocol as used in HDMI. .
  • FIG. 4 illustrates interface between a host and a transceiver.
  • host 401 and transceiver 402 are interfaced using 4 bus drivers: SDA 410, clock 411, Interrupt (INT) 412, and Reset 413.
  • SDA 410 and clock 411 represent the two communication pins.
  • Two communication pins 410 and 411, an INT (interrupt) pin 412 and RESET# (reset, active low) pin 413 exist as part of the interface.
  • the RESET# pin 413 is an input into the transceiver that allows the host to force a hardware reset of the transceiver at certain times (e.g., in the event of a serious system failure).
  • the INT pin 412 is an output of the transceiver which is asserted whenever the transceiver needs to notify host 411 of an event.
  • an event is indicated by a non-zero status of the status register which resides in bank 0xA4, offset 0x05.
  • the INT 412 and RESET# 413 functionality is available by polling the status register or reset register directly.
  • the wireless communication system includes an apparatus to communicate with remote wireless devices (e.g., WirelessHD devices) in the wireless network, where the apparatus comprises: a host processor having an I 2 C interface; a transceiver having an I 2 C interface; and a physical interface coupling the host processor and the transceiver that includes an I 2 C bus coupled to the I 2 C interfaces of both the host processor and the transceiver, and where the host processor maps a message -based communication protocol to a register-based communication protocol of an HDMI controller device to communicate with that device using the I 2 C bus.
  • remote wireless devices e.g., WirelessHD devices
  • the host processor that uses a message-based protocol to communicate can interface with the HDMI device over the I C bus.
  • the host processor controls the transceiver using the physical interface as an AVC host.
  • the apparatus includes an HDMI device coupled to the I 2 C bus, wherein the host processor communicates with both HDMI device and the transceiver as an AVC host using the I 2 C bus. Note that this I 2 C bus is not the I 2 C bus that runs from the HDMI controller to the HDMI player (e.g., DVD player, TV, etc.). This is shown in Figure 137.
  • HDMI controller interface Because the HDMI controller interface is used, there is no need for a separate GPIO to be used by the host to communicate to the controller; it canuse the same interface it uses to communicate with the transceiver. Thus, for a party at an HDMI device, the host doesn't need to set up a new driver on their host in order to talk to that device. By allowing the WirelessHD controller interface codes using the same bus as the HDMI device, and no extra pins are required to support WIHD controller interface and the host's support of HDMI
  • actions and communications on the wireless network are initiated by the host system in one of two ways - writing to specific control registers that enable specific action, or by sending packet data through the wireless network.
  • Packet formats and register definitions are described in detail.
  • the format of packet messages maintains the same packet format described in Section 10 of the WirelessHD specification, "WirelessHD Specification rev.1.0, December 12, 2007” for connection control and device control messages.
  • Figure 5 illustrates one embodiment of the packet format of host AVC messages.
  • the packet format includes the following fields:
  • Figure 6 describes the packet format of one embodiment of a Connect Request message from a host system, which sends this message in order to initiate a connection sequence to a remote device. Contrast this format with the WirelessHD format for AVC shown in Figure 7.
  • a "Feature Abort" message is sent back to the host from the transceiver to indicate that the operation is rejected. A reason for the rejection will also be available in the abort message.
  • Figure 8 illustrates one embodiment of a Feature Abort message format.
  • the Feature Abort message format has the following fields:
  • Device Index Device list index that the host attempted to send a message to, but the transceiver needs to reject.
  • the WirelessHD transceiver undergoes an initialization sequence in order to operate properly on the network.
  • the initialization sequence differentiates between the "on” state vs. the "active" state and allows the configuration of the chip as part of the initialization stage.
  • the transceiver when the transceiver powers on, the transceiver sends an interrupt to the host indicating that it is on line. The transceiver comes up in the configuration mode where the host can set specific parameters.
  • Figure 9 illustrates the three states involved in one embodiment of the initialization process. These states include reset 901, configuration (config) 902, and wait enable 903.
  • the transceiver begins in reset state 901 where the transceivers initializes all internal hardware and software subsystems. Once this completes, the transceiver enters config state 902 where wireless activity is still unavailable, but configuration of the wireless system and debug diagnostics are available via register bank access, which is described in more detail below.
  • the wireless interface is enabled before wireless operation become active. During this time, the transceiver is in wait enable state 903. Once the wireless interface is enabled, the transceiver is initialized (904).
  • FIG 10 is a flow diagram of one embodiment of a wireless transceiver initialization process.
  • the process is performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both.
  • processing logic may comprise hardware (e.g., circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both.
  • FIG. 11 illustrates a field description of a reset register. Referring to Figure 11, in one embodiment, writing 0x01 to register 0x00 of bank 0xA4 ( Figure 76B) will cause a hardware reset to occur. Similarly, writing 0x02 to this register causes a software reset.
  • processing logic After reset 1001, processing logic performs a test to determine if the chip status is ready for use.
  • the transceiver When the transceiver is reset, none of the registers or banks are available for use until the transceiver completes re-initialization of its own internal states.
  • the transceiver When the transceiver completes the re-initialization process, the transceiver indicates to the host system that the re-initialization is complete by updating the value of a special control register called the status register. This register resides in bank 0xA4 ( Figure 76B), offset 0x05.
  • Figure 12 illustrates Location 0 of Status register being set to T by the transceiver when transceiver is loaded
  • the least-significant bit (bit 0) will be logic ' 1 ' in this read-only register when the transceiver completes its own re-initialization process.
  • the optional hardware interrupt pin (412) will also assert to indicate to the host system that the status register is non-zero. The interrupt pin (412) stays asserted until the host clears all asserted bits of this register.
  • the host detects a "CHIP LOAD" event, it should then read the contents of register bank 0xA4 ( Figure 76B), offset 0x07 (the system status register) to monitor whether any system failures occurred.
  • Figure 13 is a field description of a System status register. Referring to
  • the host determines that the transceiver status is ok, the host clears the status register. This may be performed by writing a value of 0x01 to the write-only register in bank 0xA4, offset 0x06. As shown in Figure 14, this action causes the "CHIP LOAD" bit in register 0x05 to clear.
  • the status register (bank 0xA4, offset 0x05) is a read-only register, and attempting to clear bits on this register by writing directly to offset 0x05 will have no effect.
  • the chip is now in a "configuration" state where wireless configurations and settings can be modified. Test and debug diagnostics settings can also be altered at this time. The wireless interface itself, however, is not active yet.
  • processing logic enables the wireless interface (WIHD) by causing a value of 0x01 to be written to the write-only register in bank 0xA4, offset 0x04 (the host control register).
  • Figure 15 illustrates bit location 0 of the Host Control register being set to '1' to enable WIHD.
  • the wireless interface activation is controlled by the host.
  • set-up routines occur on the transceiver device to initialize and activate the radio. Once the radio is activated, the transceiver will join or initialize a
  • the transceiver is considered to be enabled.
  • the status register in bank 0xA4, offset 0x05 indicates that the wireless interface is available by setting bit 1 to '1'.
  • Figure 16 illustrates bit location 1 is to be set to T by the transceiver when WIHD is enabled.
  • Figure 17 illustrates bit location 1 that the host sets to '1' to clear status register bit location 1
  • the chip information consists of 3 bytes and is stored in register bank OxAO, offsets 0x00-0x03.
  • Figure 18 illustrates the transceiver chip information.
  • the device ID is a bit field which will return 0x01, if the transceiver is configured for Sink devices, 0x02, if the transceiver is configured for Source devices, and 0x03 if the transceiver is configured to be either Sink or Source devices.
  • the device revision provides version information of the software revision resident in the transceiver, and the vendor ID reveals the manufacturer of the transceiver.
  • Set Capabilities (1006)
  • the host first communicates its capabilities information to the transceiver.
  • the transceiver uses the capabilities information provided by the host in order to advertise itself as a node on the WirelessHD network to other host systems. More specifically, according to the WiHD specification on the AVC layer, the transceiver makes its presence known by communicating the capabilities of the host system that it is attached to. As a result, the transceiver cannot advertise itself (and thus, cannot be visible) unless it first receives information from the host describing this information.
  • the capabilities consist of 29 bytes of information and are stored in register bank OxAO, offsets 0x04-0x20.
  • Figure 19 illustrates host capabilities block of AVC information register bank.
  • the host After populating the information of the host capabilities registers, the host notifies the transceiver that the information is ready. To achieve this, the host writes a value of 0x02 to the write-only register in bank 0xA4 ( Figure 76B), offset 0x04 (the host control register). Until this action is performed, the transceiver does not parse or use any of the values written to the host capabilities registers.
  • Figure 20 illustrates bit location 1 of Host Control register that the host sets to ' 1 ' to set host device capabilities.
  • the transceiver When the host indicates that the host device capabilities fields are ready via the host control register, the transceiver then parses the fields and makes itself visible on the wireless network using the information provided by the host. The transceiver automatically engages in device discovery services and notifies the host asynchronously as remote devices are detected.
  • sink devices perform one more operations in order to complete the initialization procedure.
  • the sink host provides the input format data to the transceiver, so that it can be made available to remote source devices.
  • input format data is similar to EDID formatting data which is used in some wired connections, and consists of 222 bytes of information and is stored in register bank OxAO ( Figure 76B), offsets 0x21-OxFE as shown in Figure 77 through 80 described in more detail below.
  • the host After populating the information of the input format registers, the host notifies the transceiver that the information is ready. To achieve this, the host writes a value of 0x04 to the write-only register in bank 0xA4 ( Figure 71), offset 0x04 (the host control register). Figure 21 illustrates bit location 2 that the host sets to '1' to set host input format data. Until this action is performed, the transceiver does not parse or use any of the values written to the input format registers.
  • the transceiver When the sink host indicates that the host input format fields are ready via the host control register, the transceiver then parses the fields and makes the information available to any remote device requesting the input format of the sink device. Note that in one embodiment setting the "INPUT FORMAT DONE" bit on a source device has no effect.
  • Device discovery is the operation whereby a system can detect remote devices on a WirelessHD network.
  • the transceiver receives the first stimulus to begin the device discovery process. Through the mechanisms provided by WirelessHD (which have not been included to avoid obscuring the invention), the transceiver discovers a remote device and indicates to the host that there is a change in the status of the network.
  • the device discovery state machine begins in the idle state 2301. When a new device is detected, the state machine transitions from 2301 to capabilities needed state 2302. When at the capabilities needed state 2302, a capabilities request is sent, at which time a state machine transitions to wait for connect state 2303. It remains in this state until the transitions back to the capabilities needed state 2302 with a capabilities response when a capabilities response is received or to idle state 2301 when all devices are up to date. The state machine remains in idle state 2301 until a new device is detected.
  • the transceiver detects a failure, the transceiver indicates this to the host by issuing a "Feature Abort" command (opcode OxFFOO) to the host with an appropriate reason code. If the host receives a "Feature Abort” for a particular device, the host returns the state variables back to the "IDLE" state for that device.
  • a "Feature Abort" command opcode OxFFOO
  • a "Capabilities Request” is not issued from the transceiver to the host. It is unnecessary for the transceiver to request capabilities from the host because this information was already communicated to the transceiver during the initialization phase as discussed herein. For this reason, when a remote device requests capabilities, the transceiver responds without involving the host system.
  • the following discussion describes each of the stages of the device discovery process in greater detail.
  • FIG. 24 illustrates one embodiment of a device detect stage of the discovery process.
  • the transceiver receives the first stimulus to begin the device discovery process.
  • the transceiver discovers remote devices in the wireless network 2400 in real-time (2401).
  • transceiver sends an interrupt 2402 to the host.
  • This interrupt includes a device list.
  • the interrupt may comprise interrupt 412 of Figure 4.
  • the host reads the device list directly from the transceiver's I C register bank.
  • the host sends a clear interrupt 2405 to the transceiver.
  • the transceiver notifies the host through an indexed bitmap table resident in the control register space.
  • One embodiment of the detect process flow is as follows: New Device Detected
  • the transceiver When the transceiver detects a new WirelessHD device, the transceiver assigns an index value to that device and then makes this information available to the host via the control register bank 0xA4, offsets 0x08-0xlF. These 24 registers operate as 3 64-bit bitfields with each bit location representing an index value. Figure 25 illustrates one embodiment of device list index to bitfield mapping. [00203] In one embodiment, Registers 0x08 through OxOF indicate which device indices are HRRX capable; and registers 0x10-0x17 indicate which device indices are HRTX capable. Registers 0xl8-0xlF indicate all devices without filtering on HRRX or HRTX capability.
  • Figure 26 shows an example device list with three active devices detected. Referring to Figure 26, the table indicates that there are 3 discovered devices in the wireless network at indices 0x02, 0x03, and 0x2C.
  • Device index 0x02 is HRRX capable only
  • device 0x03 is simultaneously HRRX capable and HRTX capable
  • device 0x2C is both HRRX and HRTX capable. In one embodiment, these register locations are read-only to the host system.
  • the system uses bitmap device identification in a wireless HD network.
  • 64 devices can be included in a wireless HD network.
  • capabilities requests would have to be sent when discovering a new device to get the capability response obtained.
  • the array in Figure 25 makes it possible to know the characteristics and device idea remote devices based on good position memory. The network stairs can be immediately known without needing to query capabilities of all possible device IDs.
  • the position in the array indicates what the device does (sink, transmitter, position also allows to know what the id of the device is as the bitmap location is its ID.
  • the array of Figure 25 is stored in the bank of the I 2 C.
  • the transceiver sends an interrupt to the host which prompts the host to read the 64 bits and parks that information.
  • the host is only interested in connecting to transmitter devices, and quickly scans the array to determine which those are by the position of the array and then sends capabilities requests to get the information.
  • the transceiver whenever the transceiver updates the device list, the transceiver also simultaneously asserts the interrupt pin (412 of Figure 4) of the transceiver chip (2402 of Figure 24) and updates bit 0x02 of the status control register which resides in register bank 0xA4 ( Figure 76B), offset 0x05.
  • Figure 27 illustrates location 2 being set to '1' by the transceiver when device list altered. Recall, that an action that requires the attention of the host system asserts the interrupt pin (412) and updates control register 0x05.
  • the transceiver whenever the transceiver updates the device list, the transceiver also asserts the interrupt pin (412 of Figure 4) of the transceiver chip (2402 of Figure 24) substantially at the same time and updates bit 0x02 of the status control register which resides in register bank 0xA4 ( Figure 76B), offset 0x05.
  • the host When the host detects a device list change, either by polling the status register shown in Figure 27 or waiting for the INT pin to assert and then reading the status register, the host needs to determine which devices are new. This determination is largely dependent on the constraints of the host system. In one embodiment, there are two methods in which the device list determination can be accomplished. [00207] One approach is for the host to renew the device list information each time a device list change is indicated. Specifically, when the "DEVCAP RXD" bit is set as shown in Figure 27, the host can request device capabilities for all active indices every time. So, in the example device list of Figure 26, the host would assume indices 0x02, 0x03, and 0x2C are new devices and request capabilities for all these devices.
  • the host can filter out device indices that it already has capabilities information for by comparing it against its own local copy. For example, the example of Figure 26 would result in device capabilities being requested of index 0x02, 0x03, and 0x2C.
  • the host retrieves the device list shown in Figure 28, it would recognize that the only new device added is index 0x06 and that capabilities do not need to be re- requested for the others.
  • FIG. 142 illustrates one embodiment of the bitmap device identification. The process is performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both.
  • the process begins by processing logic storing the one or more bit maps in a first bank of memory (processing block 14201) and processing logic storing device capability information in a second bank of memory separate from the first bank of memory (processing block 14202).
  • one or more bitmaps are stored as 24 registers that operate as 3 64-bit bitfields.
  • the access of these memory banks is through an I 2 C bus.
  • processing logic accesses the first bank of memory to obtain one or more bitmaps that map each bit location in the bitmap to an index value, where one index value is assigned to each remote wireless media device of a wireless network in a wireless communication system (processing block 14203).
  • processing logic examines the bitmap(s) and determines at least one characteristic of a remote wireless media device and a device identifier that identifies the remote wireless media device in the wireless network based on bit position in the one or more bitmaps (processing block 14204).
  • processing logic selects, based on information specified in the one or more bitmaps, one or more of the remote wireless media devices in the wireless network for which to obtain device specific information (processing block 14205) and obtains the device specific information from the second bank of memory (processing block 14206).
  • the processing logic selects, based on information specified in the one or more bitmaps, the one or more of the remote wireless media devices by comparing the one or more bitmaps with a previously received and stored version of the one or more bitmaps to identify which bit locations in the one or more bitmaps are different, and filtering out, based on results of comparing the one or more bitmaps to the previously received and stored version, device indices for which device specific information has already been obtained.
  • the device specific information comprises device capabilities information.
  • a first portion of the one or more bit maps is reserved for a first type of remote wireless device (e.g., a HRRX-capable only device) and a second portion of the one or more bit maps, different than the first portion, is reserved for a second type of remote wireless device (e.g., a HRTX-capable only device), where the first and second types of remote wireless device are different.
  • a third type of remote wireless device e.g., a both HRRX-capable and HRTX-capable device
  • a fourth type of remote wireless device (e.g., a neither HRRX-capable nor HRTX-capable device) has a characteristic of neither the first nor second type of remote wireless device and has a device identifier only in the third portions of the one or more bit maps.
  • the last step of the device detection stage is for the host to confirm that the device list information has been read.
  • the transceiver will not update the device list again until the host confirms the receipt of the existing list. Stated another way, the transceiver will not notify the host of new device list changes, if previous device list changes are not acknowledged.
  • FIG. 30 illustrates one embodiment of the capabilities request stage of discovery process.
  • the host when performing the capabilities request, the host sends the capabilities request 3001 to the transceiver.
  • the transceiver sends the capabilities request 3002 to the wireless network.
  • the transceiver After sending the capabilities request 3002, the transceiver sends an interrupt 3003 to the host indicating that the transmission has been completed, and thereafter, the host sends a clear interrupt 3004 to the transceiver to complete the capabilities stage of the discovery process.
  • a capabilities request is made by utilizing the TX packet register bank OxAC.
  • the appropriate payload follows the format described in Figure 5. So, for the capabilities request, the host constructs a payload message adhering to the structure depicted in Figure 31.
  • the definition of each field is consistent with the definition listed in the WirelessHD specification for the corresponding message.
  • the only field that is unique is the "Device Index" field which corresponds to the index described in the device detect process.
  • Figure 32 illustrates the capabilities request message as it would appear in register bank OxAC (the I 2 C register bank). The portions of the register data that contain I C header information are the first three rows, whereas the actual payload is the remainder.
  • the capabilities request message includes a bus identifier (bus ID) that identifies the wireless device (e.g., WirelessHD device) in the wireless network. Packets are encapsulated with the bus ID and with the payload being the actual message.
  • bus ID bus identifier
  • the use of the bus ID in Figure 31 provides the ability to read at the same memory region for multiple purpose/applications (e.g., there are different application or models that want to talk to disparate applications for different purposes). That is, the use of the bus ID allows for dispatch capability using the single physical interface that is between the host and the transceiver device and the same location in memory can be used at different times to store data for multiple wireless devices. Thus, the bus ID allows for packeting interface to be used in a memory protocol.
  • the host should clear status flags promptly. Until the host clears a particular status flag, the transceiver cannot assume that the host is aware of the status change.
  • FIG 36 illustrates one embodiment of capability response stage of discovery process.
  • the capabilities response stage of the discovery process begins with the transceiver receiving capabilities response 3601 from the wireless network.
  • the transceiver generates an interrupt 3602 (e.g., interrupt 412) to notify the host.
  • the host reads the status register to determine the cause of interrupt 3603 and subsequently reads the receive message 3604 corresponding to the capabilities response.
  • the host sends a clear interrupt signal 3605 to the transceiver to clear the interrupt and complete the capability response stage of the discovery process.
  • the transceiver receives a capabilities request from the host, the transceiver will obtain the requested information from the remote device.
  • the transceiver Once the transceiver gets the information from the network, it formulates an RX message in register bank 0xA8 consistent with the definition listed in Figure 5. So, for the Capabilities Response, the transceiver constructs a payload message adhering to the structure depicted in Figure 37. The definition of each field is consistent with the definition listed in the WirelessHD specification for the corresponding message. The only field that is unique is the "Device Index" field which corresponds to the index described in the device detect process of section 0.
  • the single physical interface between the host processor and the transceiver provides for dispatch capability. That is, the host processor and the transceiver use the single physical interface to gain access to a memory (e.g., 4 banks of memory) that is reusable by the host processor and the transceiver to exchange data, particularly with respect to remote wireless devices (e.g., WirelessHD devices).
  • a memory e.g., 4 banks of memory
  • remote wireless devices e.g., WirelessHD devices.
  • the memory is reusable in that regardless of the application involved, data that is stored in the memory corresponding to one of the remote wireless devices is identified with the use of two identifiers (e.g., BusID and Device Index) that identifies the function of the message and the remote wireless device.
  • the memory is not assigned to a particular message format or remote device.
  • Information can be moved into the memory as long as the function (and hence, structure of the message packet) and wireless device index is identified.
  • the host processor can notify the transceiver that data is available for it in memory using one of two options. As one option, the host processor can use the interrupt signal. The second option is to periodically poll the status register (Bank 0xA4, offset 0x05). All stimulus which would cause the interrupt signal to assert also corresponds to a bit getting set in the status register, as discussed in the paragraph below.
  • Capabilities Response message is written to the receive register bank 0xA8, the transceiver notifies the host that the message is ready by simultaneously asserting interrupt pin 412 and the "RX READY" status flag of register bank 0xA4, offset 0x05. Note that a "Capabilities Response” never needs to be generated by a host system (only received) since the transceiver can automatically issue a "Capabilities Response” to remote devices from the information provided by the host during the initialization phase.
  • Figure 39 illustrates Location 5 being set to T by the transceiver after it finishes writing to the RX bank.
  • the host writes a value of 0x20 to register bank 0xA4, offset 0x06 (the status clear register).
  • Figure 40 illustrates the host setting bit location 5 to '1' to clear status register bit location 5.
  • the contents of the receive register bank (0xA8) should be read prior to clearing the "RX READY" bit. While the bit is set, the transceiver freezes the contents of the receive register bank. After the bit is cleared, the transceiver may alter the data in the receive registers.
  • Figure 143 is a flow diagram of one embodiment of a device discovery process for use in a wireless communication system.
  • the process is performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both.
  • the communication system in which the device discovery process occurs is a wireless communication system having an apparatus for communicating with WirelessHD devices in a wireless network, where the apparatus comprises a host processor; a transceiver; a physical interface coupling the host processor and the transceiver; and a memory accessible by the host processor and the transceiver to exchange information between the host processor and the transceiver.
  • the process begins by processing logic in the transceiver discovering a remote wireless device in the wireless network (processing block 14301) and updates the list of devices in response to discovering the remote wireless device has been added to the wireless network (processing block 14302).
  • processing logic in the transceiver notifies the host processor of the remote wireless device (processing block 14303).
  • notifying the host processor of the remote wireless device comprises asserting an interrupt to the host processor.
  • notifying the host processor of the remote wireless device is performed through an indexed bitmap table resident in the memory. This may occur by asserting the interrupt or setting a bit in a status register (Bank 0xA4, offset 0x05). Thus, this bit indicates to the host that the list of devices is available.
  • the host processor accessing memory to obtain the indexed bitmap table, comparing the indexed bitmap table with a previously stored table to determine any changes, and sending a capabilities request from the host processor to the transceiver for the remote wireless device if the host processor determines the remote wireless device is new based on results of comparing the indexed bitmap table with a previously stored table.
  • processing logic in the transceiver requests capabilities information from the remote wireless device prior to receiving a request from the host processor for the capabilities information (processing block 14304) and buffers the capabilities information before the capabilities information is requested by the host processor (processing block 14305).
  • processing logic in the transceiver receives a capabilities request from the host processor which requests the capabilities of the remote wireless device (processing block 14306).
  • processing logic in the transceiver provides access to the capabilities information (processing block 14307).
  • receiving the capabilities request from the host processor comprises the host processor storing a capabilities request message in a first bank of the memory, the host process sending a control message to a second bank of the memory, the control message indicating to the transceiver that the information exists in the first bank for the transceiver, and the transceiver reading the capabilities request message from the first buffer.
  • a connection sequence is performed between the two devices.
  • the protocol is consistent with WirelessHD, which is the underlying technology of this interface.
  • the host processor and the transceiver use the memory banks to perform connection control, particularly for exchanging information for connection control information. More particularly, a first bank stores information being transferred from the host processor to the transceiver, and a second bank stores information being transferred from the transceiver to the host processor, to facilitate full-duplex communication of packet data between the host processor and the transceiver. In one embodiment, the full-duplex communication conforms to the WiHD packet structure.
  • the host processor is operable to store data in the first bank while the transceiver stores data in the second bank.
  • the information stored by the host processor into the first bank of memory includes a connect request message for use in a connection control process
  • the information stored by the transceiver into the second bank of memory includes a connect response message for use in a connection control process. This is shown in Figure 144.
  • the memory includes a third bank, different than the first and second banks, having audio-video information registers to store AV information obtained by the transceiver from the wireless network regarding one or more devices in the wireless network, and the transceiver stores a message (e.g., a Capabilities Response message) indicating that AV information associated with the one or more devices is available and stores the AV information (e.g., input format structure information) in the third bank for access by the host processor.
  • a message e.g., a Capabilities Response message
  • Figure 41 illustrates one embodiment of the complete end-to-end message flow between a Sink and Source device for the connection and disconnection sequences. All connection control operations use the device indices generated as part of the device discovery process. Before connections can be established, the device discovery process described is performed. [00247]
  • a corresponding state-machine of the connection control process is shown in Figures 42 and 43 and for Sink and Source connection control state-machines, respectively.
  • the transceiver indicates this to the host by issuing a "Feature Abort" command (opcode OxFFOO) to the host with an appropriate reason code. If the host receives a "Feature Abort" for a particular device, it returns the state variables back to the "IDLE" state for that connection.
  • Figure 42 illustrates the sink host connection control state machine.
  • the state process of the sink host connection control starts at idle state 4201 and remains there until there is a connection request from the host or a remote connection request detected from a remote system on the wireless network.
  • the connection request can come from either the host that we are directly connected to or from a remote host on the wireless network.
  • the state machine transitions from idle state 4201 to wait-for-connection- confirm state 4202.
  • the state machine waits in wait-for-connection-confirm state 4202 until a connect response is detected, at which time the state machine transitions to wait- for-stream-start state 4203. If in idle state 4201 and a remote connect request is detected, the state machine transitions directly to wait-for-stream-start state 4203. At wait-for-stream-start state 4203, the sink host waits for an indication that the stream has started.
  • the state machine transitions from wait-for-stream-start state 4203 to connected state 4204. Once at connected state 4204, the state machine transitions to idle state 4201 if a disconnect request initiated by a remote host is detected. If at connect state 4204 and a disconnect request is issued by the host that is connected to the transceiver, the state machine transitions to wait-for- stream-stop state 4205. When a stream stop is detected, the state machine transitions from wait-for-stream-stop state 4205 to idle state 4201.
  • Figure 43 illustrates the source host connection control state machine.
  • the state process of the source host connection control starts at idle state 4301 and remains there until there is a connection request or a remote connection request detected.
  • the state machine transitions from idle state 4301 to wait-for-connection-confirm state 4302.
  • the state machine waits in wait-for-connection-confirm state 4302 until a connect response is detected, at which time the state machine transitions to wait-for-output-format(fmt)- response(resp) state 4303. If in idle state 4301 and a remote connect request is detected, the state machine transitions directly to wait-for-output-fmt-resp state 4303.
  • the source host waits until the output format response, and upon being received, the state machine transitions to wait-for-stream-start state 4204.
  • the source host waits for an indication that the stream has started.
  • the state machine transitions from wait-for-stream-start state 4303 to connected state 4305. Once at connected state 4305, the state machine transitions to idle state 4301 if a disconnect request initiated from a remote wireless device is detected. If in connect state 4305 and a disconnect request is issued by the host that is connected to the transceiver, the state machine transitions to wait-for-stream-stop state 4306. When a stream stop is detected, the state machine transitions from wait-for-stream-stop state 4306 to idle state 4301. [00252] The following discussion describes the connection control state flow in greater detail.
  • FIG. 44 shows one embodiment of the end-to-end communication sequences which occurs to establish a connection between two devices.
  • the "Connect Request” and “Connect Response” are bold-faced to highlight the fact that these messages are bi-directional and can be initiated from either the Sink or Source device.
  • Figure 45 is a flow diagram of one embodiment of a wireless transceiver connect process. A portion is applicable only to a Source device and a portion applicable only to a Sink device, as indicated below.
  • processing logic may comprise hardware (e.g., circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both.
  • the process begins with the source and sink devices disconnected at processing block 4501. Thereafter, processing logic test whether there has been a connection initiated (processing block 4502). If not, processing logic tests whether a remote connection has occurred (processing block 4503). If not, the process transitions to processing block 4502 where the process repeats. [00255] If processing logic determines a connection has been initiated at processing block 4502, the process transitions to processing block 4504 where processing logic of the source sends a connection request.
  • processing logic tests whether there has been a connection response (processing block 4505). If not, the process repeats at processing block 4504 until a connection response is received. When one does occur, process transitions to processing block 4507. [00256] If processing logic determines a remote connection has occurred at processing block 4503, the process transitions to processing block 4506 where processing logic of the device receiving the connect request (a source or a sink) sends the connection response and the process transitions to processing block 4507 for source devices and transitions to processing block 4510 for sink devices. [00257] At processing block 4507, processing logic tests whether the input format is available in the A/V registers Bank OxAO, offset 0x21-0xFE.
  • Processing logic reads Bank 0xA4, offset 3, location 3 shown in Figure 88 to determine if the Input Format is available. If not, the process at processing block 4507 repeats until the input format is ready. Once the input format is ready, processing logic sends the output format request (processing block 4508) and processing block checks whether the output format has been received (processing block 4509). If it has not, the process waits until the output format has been received, at which time the process transitions to processing block 4510. At processing block 4510, processing logic tests whether the start stream indication is provided by the transceiver. The start stream message indicates that the bandwidth to transmit the streaming content wirelessly is available. If the bandwidth is not available, the process repeats until the bandwidth for the stream is obtained.
  • the flow begins from a "disconnected" state.
  • the device must wait for an event, either triggered by a local event (i.e., user initiates a connection to a remote device) or by a remote connection request. Once this occurs, information is passed between the two devices to establish a suitable connection.
  • a local event i.e., user initiates a connection to a remote device
  • a remote connection request i.e., user initiates a connection to a remote device
  • the host issues a Connect Request message to initiate a connection to a remote device.
  • a connect request is initiated by utilizing the TX packet register bank OxAC.
  • the appropriate payload follows the format described in conjunction with Figure 5.
  • the host constructs a payload message adhering to the structure depicted in Figure 46.
  • the definition of each field is consistent with the definition listed in the WirelessHD specification for the corresponding message.
  • the only field which is unique is the "Device Index" field which corresponds to the index described above in conjunction with the device detect process.
  • the transceiver makes the input format information of one remote device available to the (Source) host via direct register access (bank OxAO).
  • the "RF" (Read Format) bit is set to '1' when initiating a connection from a Source host.
  • Figure 47 illustrates a connect request message as it would appear in the TX (OxAC) or RX (0xA8) register bank I 2 C register bank. The portions of the register data that contain I 2 C header information are in the first three rows and the last row, whereas the actual payload is the remainder.
  • the host notifies the transceiver that the message is ready to be sent. In one embodiment, this is accomplished by the host writing a value of 0x08 to control register bank 0xA4.
  • Figure 48 illustrates the host setting bit location 3 to '1' to indicate that TX data is ready for the transceiver.
  • Figure 45 also indicates that the connection can be initiated by the remote device, rather than the local host device.
  • the process flow of a remotely initiated Connect Request is similar to the flow described above.
  • the transceiver populates the receive register bank (0xA8) as shown in Figure 47 and then notifies the host that the message is ready by simultaneously asserting interrupt pin 412 and the "RX READY" status flag of register bank 0xA4, offset 0x05.
  • Figure 51 illustrates Location 5 being set to T by the transceiver after it finishes writing to the RX bank. [00265] To acknowledge receipt of the "RX READY" flag and to clear the
  • the host can now parse and use the information contained in the connect request to prepare a connection and issue an appropriate response.
  • Connect Request message When a Connect Request message is received from the transceiver, the host responds to the sender of the Connect Request with an appropriate Connect Response message as indicated in Figure 45.
  • a Connect Response message can be generated by utilizing the TX packet register bank OxAC.
  • the appropriate payload follows the format described in conjunction with Figure 5.
  • the host constructs a payload message adhering to the structure depicted in Figure 53.
  • the definition of each field is consistent with the definition listed in the WirelessHD specification for the corresponding message.
  • the only field which is unique is the "Device Index" field which corresponds to the index described above in conjunction with the device detect process.
  • Figure 54 illustrates Connect Response message as it would appear in the TX(OxAC) or RX(0xA8) register bank (I 2 C register bank).
  • the portions of the register data that contain I 2 C header information are the first three rows, whereas the actual payload is in the remaining rows.
  • the host notifies the transceiver that the message is ready to be sent by observing basic transmit handshaking rules outlined in conjunction with Figure 48- Figure 50.
  • the transceiver populates the receive register bank (0xA8) as shown in Figure 54. The portions of the register data that contain I C header information are in the first three rows and the last row, whereas the actual payload is the remainder. It will then follow the same receive handshaking protocol as shown in Figure 51 - Figure 52.
  • the Source host is ready to send the output format notification.
  • the transceiver refreshes the input format information in the register bank. This is discussed in more detail below. Once it successfully refreshes the input format information, it notifies the host by simultaneously asserting interrupt pin 412 and the "INPUT FORMAT RXD" status flag of register bank 0xA4, offset 0x05.
  • Figure 55 illustrates Location 3 being set to T by the transceiver after it finishes writing the input format data.
  • the host clears the "INPUT FORMAT RXD" flag once this status is detected since the transceiver will not alter the input format register data until it is specifically requested to do so by the host.
  • the host writes a value of 0x08 to register bank 0xA4, offset 0x06 (the status clear register).
  • Figure 56 illustrates the host setting bit location 3 to '1' to clear status register bit location 3.
  • the Source host can access this information to make a determination about the appropriate output format to establish between the Source and Sink devices. Once this determination is made, the Source issues an appropriate Output Format Request message as shown in the flow diagram of Figure 45.
  • a Connect Response message can be generated by utilizing the TX packet register bank OxAC.
  • the appropriate payload follows the format described in conjunction with Figure 5.
  • the host constructs a payload message, referred to as the Output Format Request message adhering to the structure depicted in Figure 57.
  • the definition of each field is consistent with the definition listed in the WirelessHD specification for the corresponding message.
  • the only field which is unique is the "Device Index" field which corresponds to the index described above in conjunction with the device detect process.
  • Figure 58 illustrates Output Format Request message as it would appear in the TX(OxAC) or RX(0xA8) register bank (I 2 C register bank).
  • the portions of the register data that contain I 2 C header information are in the first three rows and the last row, whereas the actual payload is the remainder.
  • the host writes a value of 0x40 to register bank 0xA4, offset 0x06 (the status clear register).
  • Output Format data is sent by the Source; 1) to establish a connection between two devices, and 2) to update settings of an existing connection.
  • the Source-side transceiver automatically generates an Output Format Response on behalf of the Sink host based on the information it receives in the Output Format Request, Input Format information, and the ability to obtain bandwidth from the wireless network. After reviewing these pieces of information, the transceiver generates the appropriate Output Format Response message as indicated in Figure 45.
  • An Output Format Response message can be generated by utilizing the TX packet register bank OxAC. The appropriate payload follows the format described in conjunction with Figure 5.
  • Figure 60 illustrates Output Format Response message as it would appear in the TX(OxAC) or RX(0xA8) register bank (I 2 C register bank). The portions of the register data that contain I 2 C header information are in the first three rows, whereas the actual payload is in the remaining rows.
  • the source transceiver will populate the receive register bank (0xA8) as shown in Figure 60.
  • the portions of the register data that contain I C header information are in the first three rows and the last row, whereas the actual payload is the remainder. It then follows the same receive handshaking protocol as in Figure 51- Figure 52.
  • Output Format requested by the Source is denied due to wireless bandwidth restrictions or other limitation. For this reason, the Source host is prepared to re-negotiate a different Output Format if a requested Format is denied.
  • the Source transceiver sends a Start Stream Notify message to both the Source and the Sink hosts.
  • Figure 61 illustrates a Payload structure of a Start Stream Notify message. The definition of each field is consistent with the definition listed in the WirelessHD specification for the corresponding message. The only field which is unique is the "Device Index" field which corresponds to the index described above in conjunction with the device detect process.
  • Figure 62 illustrates Start Stream Notify message as it would appear in the RX(0xA8) register bank.
  • the portions of the register data that contain I 2 C header information are in the first three rows and the last row, whereas the actual payload is the remainder.
  • the transceiver After the transceiver writes this message to bank 0xA8, the transceiver asserts the "RX READY" bit of the control bank 0xA4, offset 0x05. The host must then follow the same receive handshaking protocol as in Figure 51 - Figure 52. At this point, the host can consider the connection successful.
  • Figure 63 shows the end-to-end communication sequences which must occur to disconnect a connection between two devices.
  • the "Disconnect Indication" is bold-faced to highlight the fact that this message is bi-directional and can be initiated from either the Sink or Source device.
  • Figure 64 is a flow diagram of one embodiment of a wireless transceiver disconnect process.
  • the flow begins from a "connected" state. The device waits for an event, either triggered by a local event (i.e.- user initiates a disconnect to a remote device), by a remote disconnect request, or if the transceiver itself detects a wireless event that requires it to intervene (i.e.- unexpected loss of device on the wireless network). Once this occurs, information is passed between the two devices to perform a mutual disconnection of the AV stream.
  • a local event i.e.- user initiates a disconnect to a remote device
  • a remote disconnect request i.e.- unexpected loss of device on the wireless network
  • Notify message to initiate a disconnection from a remote device. This is accomplished by utilizing the TX packet register bank OxAC.
  • the appropriate payload follows the format described above in conjunction with Figure 5.
  • the host constructs a payload message adhering to the structure depicted in Figure 65.
  • the definition of each field is consistent with the definition listed in the WirelessHD specification for the corresponding message.
  • the only field which is unique is the "Device Index" field which corresponds to the index described in the device detect process of section 0.
  • Figure 66 illustrates Disconnect Notify message as it would appear in the TX(OxAC) or RX(0xA8) register bank (the I 2 C register bank).
  • the portions of the register data that contain I 2 C header information are in the first three rows and the last row, whereas the actual payload is the remainder.
  • Disconnect Notify message is written to the transmit register bank OxAC, the host notifies the transceiver that the message is ready to be sent. This is accomplished by writing a value of 0x08 to control register bank 0xA4, offset 0x04.
  • Figure 67 illustrates the host setting bit location 3 to ' 1 ' to indicate that TX data is ready for the transceiver.
  • Figure 68 illustrates Location 4 being set to T by the transceiver after it finishes extracting the TX message. Until the transceiver indicates status of "TX DONE", the register contents of bank OxAC (the transmit bank) is not be altered. [00288] To acknowledge receipt of the "TX DONE" flag and to clear the
  • the host writes a value of 0x10 to register bank 0xA4, offset 0x06 (the status clear register).
  • Figure 69 illustrates the host setting bit location 4 to '1' to clear status register bit location 4.
  • Figure 64 also indicates that the connection can be initiated by the remote device, rather than the local host device.
  • the process flow of a remotely initiated Connect Request is similar to the flow described above.
  • the transceiver populates the receive register bank (0xA8) as shown in Figure 47. It then notifies the host that the message is ready by simultaneously asserting INTERRUPT pin 412 and the "RX READY" status flag of register bank 0xA4, offset 0x05.
  • Figure 70 illustrates Location 5 being set to T by the transceiver after it finishes writing to the RX bank. [00290] To acknowledge receipt of the "RX READY" flag and to clear
  • the Source transceiver When the Source transceiver detects a Disconnect Notify message, it initiates a bandwidth release process. When this process completes, the Source transceiver sends a Stop Stream Notify message to both the Source and the Sink hosts.
  • Figure 73 illustrates Stop Stream Notify message as it would appear in the RX(0xA8) register bank (I C register bank).
  • the portions of the register data that contain I 2 C header information are in the first three rows and the last row, whereas the actual payload is the remainder.
  • Device control permits high-level control over any device in a
  • WirelessHD network initiated by any of the constituent devices in the network.
  • the device control messages are sent/received on the same RX/TX packet medium that device discovery and connection control messages use.
  • a primary difference is that the function type for device control messages is 0x01, whereas it is 0x00 for device discovery and connection control messages.
  • Figure 74 illustrates Payload structure of a Device Control message. The opcode and parameters correspond to those described in the WirelessHD specification.
  • Figure 75 illustrates a Device Control message as it would appear in the
  • RX(0xA8) or TX(OxAC) register bank The portions of the register data that contain I 2 C header information are in the first three rows and the last row, whereas the actual payload is the remainder.
  • the wireless communication system includes an apparatus to communicate with remote wireless devices (e.g., WirelessHD devices) in the wireless network.
  • the apparatus comprises: a host processor having an I 2 C interface; a transceiver having an I 2 C interface; a physical interface coupling the host processor and the transceiver, the physical interface comprising an I C bus coupled to the I 2 C interface of both the host processor and the transceiver; and multiple separate banks of memory in the transceiver and accessible by the host processor and the transceiver to exchange information between the host processor and the transceiver, where the host processor accesses the memory banks via its I 2 C interface.
  • the multiple memory banks comprise: a first bank to store information being transferred from the host processor to the transceiver; a second bank to store information being transferred from the transceiver to the host processor; a third bank to store control registers to control interactions between the host processor and the transceiver; and a fourth bank to store audio- video information registers to store information obtained by the transceiver from the wireless network regarding one or more devices in the wireless network and for use by the host processor.
  • one or more of the control registers indicate when communications are ready and in which memory locations in the banks the data may be read or written to.
  • the third bank stores one or more bitmaps that provide information on a device list of devices in the wireless network.
  • the four banks of memory are accessed through the SDA and CLK lines ( Figure 4). This is shown in Figure 76 A where the I 2 C bus (SDA and elk) runs between two I 2 C interfaces, I 2 C master controller 7601 and I 2 C slave controller 7612. The reset and interrupt lines have not been shown to avoid obscuring the invention.
  • CPU 7620 interfaces to the four blocks of memory through direct memory bus 7621, while slave controller 7612 interfaces the other sides of the memory banks to the I 2 C bus (and the host processor).
  • the host processor places the capabilities information as above described in the AVC information registers.
  • the Sink side host places the Input Format in the AVC information registers, whereas the Source side host reads the Input Format from the AVC information registers.
  • WirelessHD transceiver exposes four register banks to the host system to control and communicate on the wireless network.
  • Figure 76B illustrates one embodiment of the register blocks.
  • the four register blocks comprise AVC information registers 7601, control registers 7602, receive registers 7603 and transmit registers 7604.
  • each of the banks have a unique I 2 C device address (OxAO-OxAC) to distinguish the bank and each of the banks are 256 bytes deep allowing for the standard 8-bit addressing mode of I 2 C. Each of these will be described in more detail below.
  • I 2 C information is particularly useful. It allows the host system to optimize interference to the radio and optimizes/reduces memory requirements of the whole system. More specifically, the host accesses these banks through the same I 2 C interface. The memory requirements are reduced by allowing contextual information to be stored in the AVC information registers bank and does not have to be passed on to the other entity.
  • the transceiver can have information about a wireless device in the wireless network stored in the AVC information registers and then can notify the host system that the information is there, instead of sending the information to the host itself. The host thereafter can access the information directly and only the portions that are applicable to that specific host.
  • the transceiver notifies the host at the same time the information being put in the AVC registers. Therefore, the host can optimize what they need to look at and if the host does not need to access any of the information in the memory, there is no communication bandwidth wasted in providing access to the information for the host.
  • the AVC Information registers constitute a 256 byte region which is used to store information that does not change or rarely changes during the course of normal operation. As a result, this section can be useful to the host to retrieve data on an as-needed basis.
  • Figure 77-80 illustrate Register map of AVC Info Registers. The registers in this bank would be understood by those skilled in the art.
  • Figure 81 illustrates the Bit-description of register 0x06.
  • Figure 82 illustrates the Bit-description of register 0x07.
  • Figure 83 illustrates the Bit-description of register 0x22.
  • the control register space is a 256 byte region that is used to control interactions between the Host and transceiver.
  • I 2 C is a Master/Slave interface so the transceiver cannot use the bus itself to throttle the Host communications.
  • the value of specific registers in this register space are used to indicate when communications are ready and in which sections of the I 2 C register space the data can be read or written to.
  • Figure 84 illustrates Control Register space format. The following will describe these registers.
  • the reset register is used to cause the system to reset.
  • a software reset causes the system software to invoke the sequences to re-initialize the embedded software code.
  • a hardware reset causes the software to assert a hardware signal which causes the hardware (and software) to reset.
  • Figure 85 illustrates a Field description of one embodiment of a Reset register. Referring to Figure 85, the fields may be sent as follows:
  • the power mode register makes it possible to override the normal operational mode of the wireless system. Increasing the power savings operational mode can cause a degradation of the performance on the wireless link.
  • the interface control register makes it possible to configure the behavior of the Host interface with the transceiver.
  • Figure 87 illustrates field description of
  • the ready state register is a read-only register that the Host can use to get high-level state information about the status of the wireless device.
  • Figure 88 illustrates a field description of Ready register. Fields in the Ready register may be set as follows:
  • INPUT_FORMAT_READY - '0' input format is not populated on this device
  • WIHD_READY - '0' WiHD is off
  • WiHD chip is ready to take commands
  • the host control register is a write-only register that makes it possible for the Host to invoke various operations on the transceiver. In order to invoke any operation controlled by this register, a logic ' 1 ' is written to the corresponding bit location.
  • Figure 89 illustrates a field description of Host Control register. Fields in the
  • Host Controls may be set as follows:
  • RX_D0NE - '1' indicates that the Host has finished reading the data in the RX registers.
  • TX_READY - '1' indicates there is data waiting for the transceiver in the TX registers.
  • INPUT_FORMAT_DONE - '1' indicates that the Host finished writing to Input
  • the status register is a read-only register that notifies the Host of an asynchronous event that needs to be serviced.
  • any bit in the state of logic ' 1 ' indicates that the event associated with the bit needs to be serviced. Whenever any bit is non-zero, the hardware interrupt pin to the Host will also assert.
  • status registers cannot be cleared by the Host by writing to this register. Bits in this register can only be cleared by writing to the Clear register (0x06).
  • Figure 90 illustrates a field description of Status register. Fields in the Host Controls may be set as follows:
  • RX_READY - ' 1 ' indicates that data in the RX registers needs to be serviced by Host.
  • TX_DONE - T indicates that transceiver finished servicing data in TX registers.
  • INPUT_FORMAT_RXD - T indicates that the transceiver finished receiving Input
  • CHIP_LOAD - T indicates that the transceiver finished reset sequence and is ready to accept commands. When this bit is asserted, the host should read register 0x07 to detect any system issues.
  • the Clear register is a write-only register which allows the Host to clear interrupt sources listed in register 0x05, the status register.
  • Figure 91 illustrates a field description of Clear register. Fields in the Host Controls may be set as follows: CLR_RX_READY - '1' clears RX_READY bit (register 0x05). CLR_TX_DONE - '1' clears TX_DONE bit (register 0x05).
  • CLR_INPUT_FMT_RXD - '1' clears INPUT_FORMAT_RXD bit (register 0x05).
  • CLR_DEVCAP_RXD - '1' clears DEVCAP_RXD bit (register 0x05).
  • CLR_WIHD_ON - '1' clears WIHD_0N bit (register 0x05).
  • CLR_WIHD_LOAD - '1' clears WIHD_ONLINE bit (register 0x05).
  • the system status register is a read-only register that notifies the Host of any system level failures. Whenever a failure occurs, the system will assert the "WiHD Load" bit in the status (0x05) register. At that time, the Host monitors the system status register for additional details.
  • Figure 92 illustrates a field description of System status register. Fields in the Host Controls may be set as follows: MEM0RY_F AILURE - ' 1 ' indicates that a memory failure has occurred. AVC_F AILURE - T indicates that an error occurred in the AVC subsystem. MAC_F AILURE - '1' indicates that an error occurred in the MAC subsystem. RADIO_F AILURE - ' 1 ' indicates that an error occurred in the radio hardware. DRIVER_F AILURE - T indicates that an error occurred in a peripheral driver.
  • the devcap table is constructed of three 64-bit bitmaps which provide information on the device list stored within the transceiver hardware.
  • the Host can use the information contained in these bitmaps to determine which devices, if any, to filter in obtaining device capabilities information of remote devices.
  • Figure 93 illustrates a Bit-map layout of Devcap HRRX registers.
  • This bit-map indicates a logic ' 1 ' for each of the 64 entries in the device list of the transceiver which are HRRX capable. For example, if the 64-bit map was read as, "0x0000000000080014", this immediately indicates that there are 3 valid entries in the device list. The entries correspond to index 19, 4, and 2 of the transceiver's internal device list. If the Host needs to obtain the device capabilities for any of these entries, requests this information from the transceiver using the packet registers.
  • Figure 94 illustrates a Bit-map layout of Devcap HRTX registers.
  • the registers (0x10-0x17) can be used to determine which device indices are HRTX capable. This bit- map will indicate a logic ' 1 ' for each of the 64 entries in the device list of the transceiver which are HRTX capable. Note, this bit-map needs to be used in conjunction with the "Devcap HRRX" bit-map. It is possible for a device index to represent a device capable of both HRRX and HRTX.
  • Figure 95 illustrates a Bit-map layout of Device Index registers.
  • the registers (0xl8-0xlF) indicate all devices in the network regardless of whether it is HRTX capable, HRRX capable, both, or neither.
  • the devcap table is a particularly important array since addressing any device on the wireless network is based on the index entry in the devcap table array. For example, if there are three devices discovered on the wireless network, three corresponding entries will be flagged in the devcap table. In order to address any of those devices, the host system must use the index into the table to address that specific device.
  • FIG 96 illustrates the SoC version label resides in the Control register bank (0xA4), offsets 0xF7-0xFB.
  • Figure 97 illustrates a Bit-description of register 0xF7.
  • the System Tick registers are comprised of four registers that are concatenated to form a 32-bit system clock value of the transceiver. This value is stored as a little-endian value with the least significant byte residing in register OxFC and the most significant byte residing in register OxFF.
  • Figure 98 illustrates System Tick registers reside in the Control register bank (0xA4), offsets OxFC - OxFF. The tick registers are updated approximately every half-second. It is useful for diagnostics and also can be used as a system heartbeat monitor. Receive (0xA8/0xB8)/Transmit (OxAC/OxBC) Bank
  • the receive/transmit register space is a 256 byte region that is provided to the host as a receive buffer. That is, when the transceiver needs to send packetized information to the Host, it places the packet in this register space and asserts a control flag to the Host.
  • the format of this register space has the capability to handle fragmented data. This makes the use of this register space versatile providing a wide range of possible applications.
  • Figure 99 illustrates a Register space format of receiver.
  • Bus ID indicates the recipient application to receive the payload message. Though a major purpose of the TX/RX register banks is to convey AVC messages, the format has been designed for generic use. In one embodiment, bus ID definitions are as follows:
  • the length field indicates the total number of payload bytes in this message. Due to header/checksum overhead, the maximum number of bytes possible is 252 bytes.
  • the sequence field (address 0x02), which is a byte, is divided into two sections, a frame identifier and a sequence number as shown in Figure 100.
  • the frame identifier indicates which frame of a fragment this packet is associated with.
  • the sequence identifier indicates the sequential order of the fragment.
  • SEQUENCE - indicates the sequential order of the fragmented data. Note that if a frame identifier of a packet is '11' (no fragment) this field is 'don't care'.
  • the payload data is application specific information.
  • the I 2 C layer simply forwards this data.
  • the checksum is a simple 8-bit checksum of the entire payload region of the packet. For example, if the payload data is: 0x1122334455667788, the checksum of this data is 0x65. The location of the checksum byte is at the end of the payload data.
  • the following contains a description of all AVC messages that can be issued by a host to the radio transceiver in one embodiment.
  • the expected response, timeout scenario, and failure cases are described for each message.
  • Figure 101 illustrates a device capabilities message. This command issues a request to obtain capabilities information from a remote WirelessHD compliant device.
  • Function Type Indicates the function type of the opcode. This value is 'OxOO' to indicate the Connection Control function type.
  • Device Index Indicates the device index to request capabilities for.
  • Opcode The opcode corresponding to Capabilities Request. This value must be 0x0000 for Capabilities Request.
  • the requested types is a bit- field that indicates which capabilities should be provided by the remote device. By asserting one or more of the bits in this bit-field, the host can requested specific capabilities information from a remote device. The remote device will package the requested information in a series of "type-length- value” (TLV) packets which are packaged in the "Capabilities Response” message.
  • TLV type-length- value
  • Figure 102 illustrates field locations for the Requested Types bit-field.
  • Total Length Indicates the total number of octets used by the Capabilities Request message to send "type-length- value" (TLV) data. Currently, this is a reserved feature so this value should be set to "0".
  • the expected response to this message is a Capabilities Response message.
  • the remote host does not need to generate the Capabilities Response message since the transceiver on the remote side has already obtained all the necessary information from the host during the initialization process.
  • Figure 103 illustrates a capabilities response message.
  • the parameters of the message are:
  • Function Type Indicates the function type of the opcode. This value is 'OxOO' to indicate the Connection Control function type.
  • Device Index Indicates the device index of the sender of the Capabilities Response message.
  • Opcode - The opcode corresponding to Capabilities Response. In one embodiment, this value is 0x0001.
  • Total Length - Indicates the total number of octets used by the Capabilities Response message to send "type-length- value" (TLV) data.
  • Type-Length- Value packets A series of "type-length- value” packets are appended to the end of the Capabilities Response message. These correspond to the "Requested
  • Types field in the Capabilities Request message.
  • the numerical value of the "type” corresponds to the bit position of the requested type shown in Figure 102.
  • the type value "2" corresponds to MAC address whereas a type value of "3" corresponds to Input Format.
  • Capabilities Request message For a properly formatted Capabilities Request message, the transceiver responds with a Capabilities Response almost immediately. If, for some reason, the transceiver is unable to obtain the capabilities of the remote device, a Feature Abort message will be generated and sent to the host indicating a timeout.
  • Figure 104 illustrates a Feature Abort message indicating a failure to obtain Capabilities Request information. The parameters of the message are:
  • Function Type Indicates the function type of the opcode. This value is 'OxOO' to indicate the Connection Control function type.
  • Device Index Indicates the device index of the remote unit that Capabilities are being requested from.
  • Opcode - The opcode corresponding to the Feature Abort message. This value is
  • Reason Code This field will provide an indication of why the message has failed. In this case, a reason code of 0x06 will be issued to denote a timeout.
  • a failure will be indicated by the transceiver with a Feature Abort message.
  • the two possible causes of failure correspond to the following reason codes: Not in correct mode to respond (0x02) - If the message was sent before the transceiver was initialized, a Feature Abort message with this reason code will be issued. Invalid Operand (0x04) - If the device index or requested types field is invalid, a Feature Abort message with this reason code will be issued.
  • Figure 105 illustrates a Connect Request message. This command issues a request to establish a streaming connection to a remote WirelessHD compliant device.
  • Function Type Indicates the function type of the opcode. This value is 'OxOO' to indicate the Connection Control function type.
  • Device Index Indicates the device index to connect to.
  • Opcode - The opcode corresponding to Connect Request. This value is 0x0002.
  • Port - The port is the local identifier on the local host that the remote device must connect to.
  • the host can use any scheme to assign local identifiers. Port numbering becomes critical in systems that can support multiple streams simultaneously.
  • VP - Indicates that the port identified in this message will carry video data.
  • Total Length - Indicates the total number of octets used by the Connect Request message to send "type-length- value" (TLV) data. Currently, this is a reserved feature so this value should be set to "0".
  • the expected response to this message is a Connect Response message.
  • FIG. 106 illustrates a Feature Abort message indicating a failure to obtain a Connect Response. Its parameters are: Function Type - Indicates the function type of the opcode. This value is 'OxOO' to indicate the Connection Control function type.
  • Device Index Indicates the device index of the remote unit that a connection is being attempted on.
  • Opcode - The opcode corresponding to the Feature Abort message. This value is
  • Reason Code This field will provide an indication of why the message has failed. In this case, a reason code of 0x06 will be issued to denote a timeout.
  • a failure will be indicated by the transceiver with a Feature Abort message.
  • the two possible causes of failure correspond to the following reason codes: Not in correct mode to respond (0x02) - If the message was sent before the transceiver was initialized, a Feature Abort message with this reason code will be issued.
  • Figure 107 illustrates a Connect Response message. This command issues a confirmation response to establish a streaming connection to a remote WirelessHD compliant device. This message is only sent in response to a Connect Request message.
  • Function Type Indicates the function type of the opcode. This value is 'OxOO' to indicate the Connection Control function type.
  • Device Index Indicates the device index to send response to.
  • Opcode - The opcode corresponding to Connect Response. This value is 0x0003.
  • Result Code - This field indicates the result of the connection request. A value of "0" indicates success, whereas "1" indicates failure.
  • Port - There are two ports associated with any connection - the logical port on the sink and the logical port of the source device. If the remote device indicated that the remote device is the sink device via the Connect Request message, then the recipient of the
  • Connect Request message should serve as the Source for this connection sequence.
  • the Port specified in the Connect Request message should be returned in the
  • VP - Indicates that the port identified in this message will carry video data.
  • Total Length - Indicates the total number of octets used by the Connect Response message to send "type-length- value" (TLV) data. Currently, this is a reserved feature so this value should be set to "0".
  • the transceiver For a properly formatted Connect Response message, the transceiver should not need to provide any further feedback to the host to indicate a success condition. If, for some reason, the transceiver is unable to send the message to the destination, a Feature Abort message will be generated and sent to the host indicating a timeout.
  • Figure 108 illustrates a Feature Abort message indicating a failure to send the
  • Function Type Indicates the function type of the opcode. This value is 'OxOO' to indicate the Connection Control function type.
  • Device Index Indicates the device index of the remote unit that the message is being sent to.
  • Opcode - The opcode corresponding to the Feature Abort message. This value is
  • Reason Code This field will provide an indication of why the message has failed. In this case, a reason code of 0x06 will be issued to denote a timeout.
  • a failure will be indicated by the transceiver with a Feature Abort message.
  • the three possible causes of failure correspond to the following reason codes:
  • Figure 109 illustrates an Output Format Request message. This command issues a request to the transceiver to obtain wireless bandwidth to begin streaming data. This message is only valid from the Source device.
  • Function Type Indicates the function type of the opcode. This value is 'OxOO' to indicate the Connection Control function type.
  • Device Index Indicates the device index to establish stream to.
  • Opcode - The opcode corresponding to the Output Format Request message. This value must be 0x0007.
  • Port - There are two ports associated with any connection - the logical port on the Sink and the logical port of the Source device. The values of these fields and the determination of which device will perform Sink vs. Source role has already been established during the Connect Request/Response. This message must use values that were established at the time of the Connect Request/Response messages.
  • VP - Indicates that the port identified in this message will carry video data.
  • AP Indicates that the port identified in this message will carry audio data.
  • Total Length Indicates the total number of octets used by the Output Format Request message to send "type-length- value" (TLV) data.
  • TLV type-length- value
  • Output Format Response message This message will indicate whether the corresponding bandwidth associated with the request can be obtained.
  • the result code will indicate success (0) or failure (1). If the bandwidth reservation fails, the host must issue a new Output Format Request to attempt to reserve stream bandwidth.
  • the host may need to request lower resolution video or decreased resolution in audio.
  • Figure 110 illustrates an Output Format Response message. Its parameters are:
  • Function Type Indicates the function type of the opcode. This value is 'OxOO' to indicate the Connection Control function type.
  • Device Index Indicates the device index of the remote device to which a stream is being established.
  • Opcode - The opcode corresponding to Output Format Response. This value is
  • Port - There are two ports associated with any connection - the logical port on the Sink and the logical port of the Source device, he values of these fields and the determination of which device will perform Sink vs. Source role has already been established during the Connect Request/Response. This message must use values that were established at the time of the Connect Request/Response messages.
  • VP - Indicates that the port identified in this message will carry video data.
  • FIG. 111 illustrates a Stream Start Notify message. Its parameters are:
  • Function Type Indicates the function type of the opcode. This value is 'OxOO' to indicate the Connection Control function type.
  • Device Index Indicates the device index of the remote device to which a stream is being established.
  • Opcode - The opcode corresponding to Stream Start Notify. This value is 0x0005.
  • the transceiver assigns every stream with a unique index. This can be used by the host to uniquely identify the active streams, particularly if the host is capable of supporting multiple streams.
  • Port - There are two ports associated with any connection - the logical port on the Sink and the logical port of the source device. The values of these fields and the determination of which device will perform sink vs. source role has already been established during the Connect Request/Response. This message must use values that were established at the time of the Connect Request/Response messages.
  • VP - Indicates that the port identified in this message will carry video data.
  • Total Length - Indicates the total number of octets used by the Stream Start Notify message to send "type-length- value" (TLV) data. Currently, this is a reserved feature so this value should be set to "0".
  • a response will be available upon performing a bandwidth check.
  • a failure will be indicated by the transceiver with a Feature Abort message.
  • the three possible causes of failure correspond to the following reason codes: Not in correct mode to respond (0x02) - If the message was sent before the transceiver was initialized, a Feature Abort message with this reason code will be issued. Invalid Operand (0x04) - If the device index field is invalid, a Feature Abort message with this reason code will be issued. This message is also generated if the Port and VP/ AP information does not match the values that were set during the Connect Request/Response dialogue.
  • Out of Sequence (0x07) - If the Output Format Request message is sent by a device that is not the source, or is sent by a source that has not successfully undergone the Connect Request/Response dialogue, the Out of Sequence reason code is sent to the host.
  • Figure 112 illustrates a Disconnect Notify message. This command notifies the remote device that the stream needs to be terminated.
  • Function Type Indicates the function type of the opcode. This value is 'OxOO' to indicate the Connection Control function type.
  • Device Index Indicates the device index to notify.
  • Opcode - The opcode corresponding to the Disconnect Notify message. This value is
  • Port - There are two ports associated with any connection - the logical port on the sink and the logical port of the source device. The values of these fields and the determination of which device will perform sink vs. source role has already been established during the Connect Request/Response. This message must use values that were established at the time of the Connect Request/Response messages.
  • VP - Indicates that the port identified in this message will carry video data.
  • Figure 113 illustrates a Stream Stop message. Its parameters are:
  • Function Type Indicates the function type of the opcode. This value is 'OxOO' to indicate the Connection Control function type.
  • Device Index Indicates the device index of the remote device to which a stream is being established.
  • Opcode - The opcode corresponding to Stream Stop message. This value is 0x0006.
  • the host was tracking the active streams using this index, it can be used here to perform any necessary cleanup associated with this stream.
  • Port - There are two ports associated with any connection - the logical port on the sink and the logical port of the source device. These fields and which device will perform sink vs. source role have already been established during the Connect
  • This message must use values that were established at the time of the Connect Request/Response messages.
  • VP - Indicates that the port identified in this message will carry video data.
  • the transceiver does not provide any further feedback to the host to indicate a success condition. If, for some reason, the transceiver is unable to send the message to the destination, a Feature
  • FIG. 114 illustrates a Feature Abort message indicating a failure to send the Disconnect Notify.
  • Function Type Indicates the function type of the opcode. This value is 'OxOO' to indicate the Connection Control function type.
  • Device Index Indicates the device index of the remote unit that the message is being sent to.
  • Opcode - The opcode corresponding to the Feature Abort message. This value is
  • OxFFOO Rejected Opcode - The opcode of the message that failed. In this case, the Disconnect Notify has failed, so the value is 0x0004.
  • Reason Code This field will provide an indication of why the message has failed. In this case, a reason code of 0x06 will be issued to denote a timeout.
  • a failure will be indicated by the transceiver with a Feature Abort message.
  • the three possible causes of failure correspond to the following reason codes:
  • Figure 115 illustrates a Device Control message.
  • Device Control commands are largely treated as pass-through messages by the transceiver.
  • Function Type Indicates the function type of the opcode. This value is 'OxOl' to indicate the Device Control function type.
  • Device Index Indicates the device index to send message to.
  • Opcode - The opcode corresponding to the specific Device Control message to be sent.
  • the WirelessHD specification provides greater details on the available commands.
  • Param - The parameters associated with a specific Device Control message.
  • the transceiver does not provide any further feedback to the host to indicate a success condition. If, for some reason, the transceiver is unable to send the message to the destination, a Feature Abort message will be generated and sent to the host indicating a timeout.
  • Figure 116 illustrates a Feature Abort message indicating a failure of a Device Control message.
  • Function Type Indicates the function type of the opcode. This value is 'OxOl' to indicate the Device Control function type.
  • Device Index Indicates the device index of the remote unit that the message is being sent to.
  • Opcode - The opcode corresponding to the Feature Abort message. This value is
  • Reason Code This field will provide an indication of why the message has failed. In this case, a reason code of 0x06 will be issued to denote a timeout.
  • a failure will be indicated by the transceiver with a Feature Abort message.
  • the two possible causes of failure correspond to the following reason codes: Not in correct mode to respond (0x02) - If the message was sent before the transceiver was initialized, a Feature Abort message with this reason code will be issued. Invalid Operand (0x04) - If the device index field is invalid, a Feature Abort message with this reason code will be issued.
  • Figure 117 illustrates a HDMI Pass-Through Request message. This command issues a request to provide a pass-through connection of HDMI messages between two WirelessHD compliant devices.
  • Function Type Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
  • Device Index Indicates the device index to enable an HDMI Pass-Through link.
  • Opcode - The opcode corresponding to the HDMI Pass-Through Request. This value must be 0x0000.
  • PT - Indicates whether to enable (1) or disable (0) Pass-Through.
  • the expected response to this message is an HDMI Pass-Through
  • the transceiver For a properly formatted HDMI Pass-Through Request message, the transceiver should respond with a HDMI Pass-Through Response message. If, for some reason, the transceiver is unable to obtain the response of the remote device, a Feature Abort message will be generated and sent to the host indicating a timeout.
  • Figure 118 illustrates a Feature Abort message indicating a failure to obtain an HDMI Pass- Through Response. Its parameters include:
  • Function Type Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
  • Device Index Indicates the device index of the remote unit that the Pass-Through message could not be sent to.
  • Opcode - The opcode corresponding to the Feature Abort message. This value is OxFFOO.
  • Reason Code This field will provide an indication of why the message has failed. In this case, a reason code of 0x06 will be issued to denote a timeout.
  • a failure will be indicated by the transceiver with a Feature Abort message.
  • the two possible causes of failure correspond to the following reason codes: Not in correct mode to respond (0x02) - If the message was sent before the transceiver was initialized, a Feature Abort message with this reason code will be issued. Invalid Operand (0x04) - If the device index field is invalid, a Feature Abort message with this reason code will be issued.
  • Figure 119 illustrates an HDMI Pass-Through Response message. This command issues a confirmation response to establish a pass-through connection of HDMI messages between two WirelessHD compliant device. This message is only sent in response to an HDMI Pass-Through Request message.
  • Function Type Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
  • Device Index Indicates the device index to issue a response.
  • Opcode - The opcode corresponding to the HDMI Pass-Through Response. This value is 0x0001.
  • the transceiver does not provide any further feedback to the host to indicate a success condition. If, for some reason, the transceiver is unable to send the message to the destination, a Feature Abort message will be generated and sent to the host indicating a timeout.
  • Figure 120 illustrates a Feature Abort message indicating a failure to send the
  • Function Type Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
  • Device Index Indicates the device index of the remote unit that the original message was being sent to.
  • Opcode - The opcode corresponding to the Feature Abort message. This value is
  • Reason Code This field will provide an indication of why the message has failed. In this case, a reason code of 0x06 will be issued to denote a timeout.
  • a failure will be indicated by the transceiver with a Feature Abort message.
  • the three possible causes of failure correspond to the following reason codes:
  • Figure 121 illustrates a DID Request message. This command issues a request for EDID information from a Sink device.
  • Function Type Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
  • Device Index Indicates the device index to request EDID information from.
  • Opcode - The opcode corresponding to the HDMI Pass-Through Request. This value is 0x0002.
  • the expected response to this message is an EDID Response message.
  • the transceiver For a properly formatted EDID Request message, the transceiver should respond with an EDID Response message. If, for some reason, the transceiver is unable to obtain the response of the remote device, a Feature Abort message will be generated and sent to the host indicating a timeout.
  • Figure 122 illustrates a Feature Abort message indicating a failure to obtain an EDID Response. Its parameters are:
  • Function Type Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
  • Device Index Indicates the device index of the remote unit that the Pass-Through message could not be sent to.
  • Opcode - The opcode corresponding to the Feature Abort message. This value is
  • Reason Code This field will provide an indication of why the message has failed. In this case, a reason code of 0x06 will be issued to denote a timeout.
  • a failure will be indicated by the transceiver with a Feature Abort message.
  • the two possible causes of failure correspond to the following reason codes:
  • Figure 123 illustrates an EDID Response message. This command provides EDID information to a Source device. It is only sent when prompted by an EDID Request message.
  • Function Type Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
  • Device Index Indicates the device index to send EDID information to.
  • Opcode - The opcode corresponding to the HDMI Pass-Through Request. This value is 0x0003.
  • the transceiver For a properly formatted EDID Response message, the transceiver doesn't provide any further feedback to the host to indicate a success condition. If, for some reason, the transceiver is unable to send the message to the destination, a Feature
  • FIG. 124 illustrates a Feature Abort message indicating a failure to send the EDID Response. Its parameters are:
  • Function Type Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
  • Device Index Indicates the device index of the remote unit that the original message was being sent to.
  • Opcode - The opcode corresponding to the Feature Abort message. This value is
  • Reason Code This field will provide an indication of why the message has failed. In this case, a reason code of 0x06 will be issued to denote a timeout.
  • a failure will be indicated by the transceiver with a Feature Abort message.
  • the three possible causes of failure correspond to the following reason codes:
  • Figure 125 illustrates a Data Island Notify message. This command provides EDID information to a Source device. It is only sent when prompted by an EDID Request message.
  • Function Type Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
  • Device Index Indicates the device index to send the Data Island packet to.
  • Opcode - The opcode corresponding to the Data Island Notify message. This value is
  • Port - There are two ports associated with any connection - the logical port on the sink and the logical port of the source device. These fields and which device will perform sink vs. source role have already been established during the Connect
  • VP - Indicates that the port identified in this message will carry video data.
  • AP Indicates that the port identified in this message will carry audio data.
  • Frame Frame number that the Data Island Notify message should apply to.
  • Total Length Indicates the total number of octets used by the Data Island Notify message to send "type-length- value" (TLV) data.
  • the transceiver does not need to provide any further feedback to the host to indicate a success condition. If, for some reason, the transceiver is unable to send the message to the destination, a Feature Abort message will be generated and sent to the host indicating a timeout.
  • Figure 126 illustrates a Feature Abort message indicating a failure to send the
  • Function Type Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
  • Device Index Indicates the device index of the remote unit that the original message was being sent to.
  • Opcode - The opcode corresponding to the Feature Abort message. This value is
  • Reason Code This field will provide an indication of why the message has failed. In this case, a reason code of 0x06 will be issued to denote a timeout.
  • a failure will be indicated by the transceiver with a Feature Abort message.
  • the two possible causes of failure correspond to the following reason codes: Not in correct mode to respond (0x02) - If the message was sent before the transceiver was initialized, a Feature Abort message with this reason code will be issued. This message will also be issued for two other cases: 1) the appropriate Pass-Through Request/Response handshake has not been established between the two devices, 2) a successful connection control link has not been established between the two WirelessHD devices.
  • Figure 127 illustrates a CEC Notify message. This command forwards a
  • Function Type Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
  • Device Index Indicates the device index to send the CEC packet to.
  • Opcode - The opcode corresponding to the CEC Notify message. This value is
  • Fragment Length Indicates the length in octets of the "Fragment Data" block of this message.
  • LF - Zero (0) typically. Set to one (1) if current fragment is the last fragment of a message.
  • Fragment Data The entire CEC message (or fragment), unprocessed.
  • Timeout For a properly formatted CEC Notify message, the transceiver does not provide any further feedback to the host to indicate a success condition. If, for some reason, the transceiver is unable to send the message to the destination, a Feature Abort message will be generated and sent to the host indicating a timeout.
  • Figure 128 illustrates a Feature Abort message indicating a failure to send the CEC Notify. Its parameters are:
  • Function Type Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
  • Device Index Indicates the device index of the remote unit that the original message was being sent to.
  • Opcode - The opcode corresponding to the Feature Abort message. This value is
  • Reason Code This field will provide an indication of why the message has failed. In this case, a reason code of 0x06 will be issued to denote a timeout.
  • a failure will be indicated by the transceiver with a Feature Abort message.
  • the two possible causes of failure correspond to the following reason codes:
  • Figure 129 illustrates a CEC NAK message. This command notifies a remote device that a CEC message sent by that remote device was not accepted (NAK) on the local CEC bus.
  • NAK NAK
  • Function Type Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
  • Device Index Indicates the device index to send the NAK packet to.
  • Opcode - The opcode corresponding to the CEC NAK message. This value is 0x0006.
  • This number must correspond to the Message Number of the CEC Notify message that cannot be placed on the CEC bus.
  • the transceiver should not need to provide any further feedback to the host to indicate a success condition. If, for some reason, the transceiver is unable to send the message to the destination, a Feature
  • Abort message will be generated and sent to the host indicating a timeout.
  • Figure 130 illustrates a Feature Abort message indicating a failure to send the CEC NAK.
  • Function Type Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
  • Device Index Indicates the device index of the remote unit that the original message was being sent to.
  • Opcode - The opcode corresponding to the Feature Abort message. This value is
  • Reason Code This field will provide an indication of why the message has failed. In this case, a reason code of 0x06 will be issued to denote a timeout.
  • a failure will be indicated by the transceiver with a Feature Abort message.
  • the two possible causes of failure correspond to the following reason codes: Not in correct mode to respond (0x02) - If the message was sent before the transceiver was initialized, a Feature Abort message with this reason code will be issued. This message will also be issued if the appropriate Pass-Through Request/Response handshake has not been established between the two devices.
  • Figure 131 illustrates a Logical Address Table Notify message. This command notifies a remote device of the logical addresses occupied on the local CEC bus.
  • Function Type Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
  • Device Index Indicates the device index to send the Logical Address bitmap to.
  • Opcode - The opcode corresponding to the Logical Address Table Notify message.
  • This value must be 0x0007.
  • Logical Address Bitmap The 16-bit bit-field indicates the HDMI logical addresses occupied on the local CEC bus. The definitions of each bit location are defined in the
  • Figure 132 illustrates fields for definitions of the logical address bitmap.
  • Timeout For a properly formatted Logical Address Table Notify message, the transceiver should not need to provide any further feedback to the host to indicate a success condition. If, for some reason, the transceiver is unable to send the message to the destination, a Feature Abort message will be generated and sent to the host indicating a timeout.
  • Figure 133 illustrates a Feature Abort message indicating a failure to send the Logical Address Table Notify. Its parameters are:
  • Function Type Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
  • Device Index Indicates the device index of the remote unit that the original message was being sent to.
  • Opcode - The opcode corresponding to the Feature Abort message. This value is
  • Reason Code This field will provide an indication of why the message has failed. In this case, a reason code of 0x06 will be issued to denote a timeout.
  • a failure will be indicated by the transceiver with a Feature Abort message.
  • the two possible causes of failure correspond to the following reason codes:
  • Figure 134 illustrates an HPD Notify message. This command notifies a remote device of the Hot Plug Detect state of the HDMI bus.
  • Function Type Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
  • Device Index Indicates the device index to send the HPD Notify message to.
  • Opcode - The opcode corresponding to the HPD Notify message. This value is
  • HPD - The state of the Hot-Plug Detect signal. A one (1) indicates that the HPD signal is asserted. A zero (0) indicates that the HPD signal is not asserted.
  • the transceiver does not provide any further feedback to the host to indicate a success condition. If, for some reason, the transceiver is unable to send the message to the destination, a Feature Abort message will be generated and sent to the host indicating a timeout.
  • Figure 135 illustrates a Feature Abort message indicating a failure to send the HPD Notify. Its parameters are:
  • Function Type Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
  • Device Index Indicates the device index of the remote unit that the original message was being sent to.
  • Opcode - The opcode corresponding to the Feature Abort message. This value is
  • Reason Code This field will provide an indication of why the message has failed. In this case, a reason code of 0x06 will be issued to denote a timeout.
  • a failure will be indicated by the transceiver with a Feature Abort message.
  • the two possible causes of failure correspond to the following reason codes: Not in correct mode to respond (0x02) - If the message was sent before the transceiver was initialized, a Feature Abort message with this reason code will be issued. This message will also be issued if the appropriate Pass-Through Request/Response handshake has not been established between the two devices.
  • Figure 136 illustrates a Feature Abort message indicating unrecognized opcode.
  • the response to failure cases for each category of messages has been described in the previous sections. In general, a message failure will result in a Feature Abort message. Messages received by the transceiver that do not contain valid opcodes will also result in a Feature Abort with the corresponding Reason Code.
  • Figure 138 is a block diagram of one embodiment of a communication system.
  • the system comprises media receiver 100, a media receiver interface 102, a transmitting device 140, a receiving device 141, a media player interface 113, a media player 114 and a display 115.
  • Media receiver 100 receives content from a source (not shown).
  • media receiver 100 comprises a set top box.
  • the content may comprise baseband digital video, such as, for example, but not limited to, content adhering to the HDMI or DVI standards.
  • media receiver 100 may include a transmitter (e.g., an HDMI transmitter) to forward the received content.
  • Media receiver 101 sends content 101 to transmitter device 140 via media receiver interface 102.
  • media receiver interface 102 includes logic that converts content 101 into HDMI content.
  • media receiver interface 102 may comprise an HDMI plug and content 101 is sent via a wired connection; however, the transfer could occur through a wireless connection.
  • content 101 comprises DVI content.
  • the transfer of content 101 between media receiver interface 102 and transmitter device 140 occurs over a wired connection; however, the transfer could occur through a wireless connection.
  • Transmitter device 140 wirelessly transfers information to receiver device 141 using two wireless connections.
  • One of the wireless connections is through a phased array antenna with adaptive beam-forming.
  • the other wireless connection is via wireless communications channel 107, referred to herein as the back channel.
  • wireless communications channel 107 is uni-directional.
  • wireless communications channel 107 is bi-directional.
  • the back channel can use some or all of the same antennas as the forward beam-formed channel (part of 105).
  • the two sets of antennas are disjoint.
  • Receiver device 141 transfers the content received from transmitter device 140 to media player 114 via an interface such as a media player interface 113.
  • the transfer of the content between receiver device 141 and media player interface 113 occurs through a wired connection; however, the transfer could occur through a wireless connection.
  • media player interface 113 comprises an HDMI plug.
  • the transfer of the content between media player interface 113 and media player 114 occurs through a wired connection; however, the transfer could occur through a wireless connection. The transfer could also occur through a wired or wireless data interface that was not a media player interface.
  • Media player 114 causes the content to be played on display 115.
  • the content is HDMI content and media player 114 transfer the media content to display via a wired connection; however, the transfer could occur through a wireless connection.
  • Display 115 may comprise a plasma display, an LCD, a CRT, etc.
  • transmitter 140 and media receiver interface 102 are part of media receiver 100.
  • receiver 140, media player interface 113, and media player 114 are all part of the same device.
  • receiver 140 media player interface 113, media player 114, and display 115 are all part of the display.
  • transmitter device 140 comprises a processor 103, an optional baseband processing component 104, a phased array antenna 105, and a wireless communication channel interface 106.
  • Phased array antenna 105 comprises a radio frequency (RF) transmitter having a digitally controlled phased array antenna coupled to and controlled by processor 103 to transmit content to receiver device 141 using adaptive beam-forming.
  • RF radio frequency
  • receiver device 141 comprises a processor 112, an optional baseband processing component 111, a phased array antenna 110, and a wireless communication channel interface 109.
  • Phased array antenna 110 comprises a radio frequency (RF) transmitter having a digitally controlled phased array antenna coupled to and controlled by processor 112 to receive content from transmitter device 140 using adaptive beam- forming.
  • RF radio frequency
  • processor 103 generates baseband signals that are processed by baseband signal processing 104 prior to being wirelessly transmitted by phased array antenna 105.
  • receiver device 141 includes baseband signal processing to convert analog signals received by phased array antenna 110 into baseband signals for processing by processor 112.
  • the baseband signals are orthogonal frequency division multiplex (OFDM) signals.
  • transmitter device 140 and/or receiver device 141 are part of separate transceivers.
  • Transmitter device 140 and receiver device 141 perform wireless communication using a phased array antenna with adaptive beam-forming that allows beam steering. Beam-forming is well known in the art.
  • processor 103 sends digital control information to phased array antenna 105 to indicate an amount to shift one or more phase shifters in phased array antenna 105 to steer a beam formed thereby in a manner well-known in the art.
  • Processor 112 uses digital control information as well to control phased array antenna 110. The digital control information is sent using control channel 121 in transmitter device 140 and control channel 122 in receiver device 141.
  • the digital control information comprises a set of coefficients.
  • each of processors 103 and 112 comprises a digital signal processor.
  • Wireless communication link interface 106 is coupled to processor 103 and provides an interface between wireless communication link 107 and processor 103 to communicate antenna information relating to the use of the phased array antenna and to communicate information to facilitate playing the content at the other location.
  • the information transferred between transmitter device 140 and receiver device 141 to facilitate playing the content includes encryption keys sent from processor 103 to processor 112 of receiver device 141 and one or more acknowledgments from processor 112 of receiver device 141 to processor 103 of transmitter device 140.
  • Wireless communication link 107 also transfers antenna information between transmitter device 140 and receiver device 141. During initialization or tuning of the phased array antennas 105 and 110, wireless communication link 107 transfers information to enable processor 103 to select a direction for the phased array antenna 105.
  • the information includes, but is not limited to, antenna location information and performance information corresponding to the antenna location, such as one or more pairs of data that include the position of phased array antenna 110 and the signal strength of the channel for that antenna position.
  • the information includes, but is not limited to, information sent by processor 112 to processor 103 to enable processor 103 to determine which portions of phased array antenna 105 to use to transfer content.
  • wireless communication link 107 transfers an indication of the status of communication path from the processor 112 of receiver device 141.
  • the indication of the status of communication comprises an indication from processor 112 that prompts processor 103 to steer the beam in another direction (e.g., to another channel). Such prompting may occur in response to interference with transmission of portions of the content.
  • the information may specify one or more alternative channels that processor 103 may use.
  • the antenna information comprises information sent by processor 112 to specify a location to which receiver device 141 is to direct phased array antenna 110. This may be useful during initialization when transmitter device 140 is telling receiver device 141 where to position its antenna so that signal quality measurements can be made to identify the best channels.
  • the position specified may be an exact location or may be a relative location such as, for example, the next location in a predetermined location order being followed by transmitter device 140 and receiver device 141.
  • wireless communications link 107 transfers information from receiver device 141 to transmitter device 140 specifying antenna characteristics of phased array antenna 110, or vice versa. In one embodiment, communications link 107 transfers information from receiver device 141 to transmitter device 140 that can be used to control phased array antenna 105.
  • the transceiver includes transmit and receive paths for a transmitter and receiver, respectively.
  • the transmitter for use in communication with a receiver, comprises a processor and a phased array beamforming antenna.
  • the processor controls the antenna to perform adaptive beam steering using multiple transmit antennas in conjunction with receive antennas of the receiver by iteratively performing a set of training operations.
  • One of the training operations comprises the processor causing the phased array beamforming antenna to transmit a first training sequence while a receive antenna-array weight vector of the receiver is set and a transmitter antenna-array weight vector switches between weight vectors with a set of weight vectors.
  • the receiver for use in communication with a transmitter, comprises a processor and a phased array beamforming antenna.
  • the processor controls the antenna to perform adaptive beam steering using multiple receive antennas in conjunction with transmit antennas of the transmitter by iteratively performing a set of training operations.
  • One of the training operations comprises the processor setting a receive antenna-array weight vector during a process for estimating a transmit antenna-array weight vector by having the transmitter transmit a first training sequence while the receive antenna- array weight vector is set.
  • Another of the training operations comprises the processor calculate the receive antenna-array weight vector when the transmitter transmits a second training sequence while the transmitter antenna-array weight vector is set.
  • FIG 140 is a block diagram of one embodiment of a transmitter device and a receiver device that are part of an adaptive beam forming multiple antenna radio system containing of Figure 138.
  • Transceiver 300 includes multiple independent transmit and receive chains and performs phased array beam forming using a phased array that takes an identical RF signal and shifts the phase for one or more antenna elements in the array to achieve beam steering.
  • digital baseband processing module e.g., a digital baseband processing module
  • Digital Signal Processor (DSP)) 301 formats the content and generates real time baseband signals.
  • Digital baseband processing module 301 may provide modulation, FEC coding, packet assembly, interleaving and automatic gain control. [00413]
  • Digital baseband processing module 301 then forwards the baseband signals to be modulated and sent out on the RF portion of the transmitter.
  • the content is modulated into OFDM signals in a manner well known in the art.
  • Digital-to-analog converter (DAC) 302 receives the digital signals output from digital baseband processing module 301 and converts them to analog signals. In one embodiment, the signal outputs from DAC 302 are between 0-1.7 GHz.
  • Analog front end 303 receives the analog signals and filters it with an appropriate low- pass image-rejection filter and amplifies it accordingly.
  • the IF module 304 receives the output of analog front end 303 and up-converts it to the IF frequency. In one embodiment, the IF frequency is between 2-15 GHz.
  • RF mixer 305 receives signals output from IF amplifier 304 and combines them with a signal from a local oscillator (LO) (not shown) in a manner well- known in the art.
  • the signals output from mixer 305 are at an intermediate frequency.
  • the intermediate frequency is between 2-15 GHz.
  • Multiplexer 306 is coupled to receive the output from mixer 305 to control which phase shifters 307 1-N receive the signals.
  • phase shifters 307j_ N are quantized phase shifters.
  • phase shifters 307i_ N may be replaced by IF or RF amplifiers with controllable gain and phase.
  • digital baseband processing module 201 also controls, via control channel 360, the phase and magnitude of the currents in each of the antenna elements in phased array antenna to produce a desired beam pattern in a manner well-known in the art.
  • digital baseband processing module 201 controls the phase shifters 307]_ N of phased array antenna to produce the desired pattern.
  • Each of phase shifters 307 1- ⁇ produce an output that is sent to one of power amplifiers 308 I _ N , which amplify the signal.
  • the amplified signals are sent to an antenna array that has multiple antenna elements 309 I _ N -
  • the signals transmitted from antennas 309 I _ N are radio frequency signals between 56-64 GHz.
  • antennas 310 I _ N receive the wireless transmissions from antennas 309i_ N ⁇ and provide them to phase shifters 312i_ N, via low- noise amplifiers 311 I _ N, respectively.
  • phase shifters 312i_ N comprise quantized phase shifters.
  • phase shifters 312i_ N may be replaced by complex multipliers.
  • Phase shifters 312j_ N receive the signals from antennas 310i_ N , which are combined by RF combiner 313 to form a single line feed output.
  • a multiplexer is used to combine the signals from the different elements and output the single feed line. The output of RF combiner 313 is input to RF mixer 314.
  • Mixer 314 receives the output of the RF combiner 313 and combines it with a signal from a LO (not shown) in a manner well-known in the art.
  • the output of mixer 314 is a signal with the IF carrier frequency of 2-15 GHz.
  • the IF module then down-converts the IF signal to the baseband frequency.
  • Analog-to-digital converter (ADC) 316 receives the output of IF 315 and converts it to digital form.
  • the digital output from ADC 316 is received by digital baseband processing module (e.g., DSP) 318.
  • Digital baseband processing module 318 restores the amplitude and phase of the signal.
  • Digital baseband processing module 318 may provide demodulation, packet disassembly, de-interleaving and automatic gain.
  • each of the transceivers includes a controlling microprocessor that sets up control information for the digital baseband processing module (e.g., DSP).
  • the controlling microprocessor may be on the same die as the digital baseband processing module (e.g., DSP).
  • the DSPs implement an adaptive algorithm with the beam forming weights being implemented in hardware. That is, the transmitter and receiver work together to perform the beam forming in RF frequency using digitally controlled analog phase shifters; however, in an alternative embodiment, the beam- forming is performed in IF.
  • Phase shifters 307 I _ N and 312 I _ N are controlled via control channel 360 and control channel 370, respectfully, via their respective DSPs in a manner well known in the art.
  • digital baseband processing module (e.g., DSP) 301 controls phase shifters 307 I _ N to have the transmitter perform adaptive beam- forming to steer the beam while digital baseband processing module (e.g., DSP) 318 controls phase shifters 312i_ N to direct antenna elements to receive the wireless transmission from antenna elements and combine the signals from different elements to form a single line feed output.
  • DSP digital baseband processing module
  • a multiplexer is used to combine the signals from the different elements and output the single feed line.
  • processors e.g., DSPs
  • control channels 360 and 370 could be coupled to control channels 360 and 370, respectively, could be used to control phase shifters 307 I _ N and 312 1-N .
  • Digital baseband processing module (e.g., DSP) 301 performs the beam steering by pulsing, or energizing, the appropriate phase shifter connected to each antenna element.
  • the pulsing algorithm under digital baseband processing module (e.g., DSP) 301 controls the phase and gain of each element.
  • Performing DSP controlled phase array beam-forming is well known in the art.
  • the adaptive beam forming antenna is used to avoid interfering obstructions. By adapting the beam forming and steering the beam, the communication can occur avoiding obstructions which may prevent or interfere with the wireless transmissions between the transmitter and the receiver.
  • the adaptive beam-forming antennas they have three phases of operations.
  • the three phases of operations are the training phase, a searching phase, and a tracking phase.
  • the training phase and searching phase occur during initialization.
  • the training phase determines the channel profile with predetermined sequences of spatial patterns ⁇ Al ⁇ and ⁇ Bj ⁇ .
  • the searching phase computes a list of candidate spatial patterns ⁇ AT ⁇ , ⁇ Bj ⁇ and selects a prime candidate [ Ao Bo ⁇ for use in the data transmission between the transmitter of one transceiver and the receiver of another.
  • the tracking phase keeps track of the strength of the candidate list. When the prime candidate is obstructed, the next pair of spatial patterns is selected for use.
  • the transmitter sends out a sequence of spatial patterns ⁇ A; ⁇ .
  • the receiver projects the received signal onto another sequence of patterns ⁇ B] ⁇ .
  • a channel profile is obtained over the pair ⁇ A; ⁇ , ⁇ Bj ⁇ .
  • an exhaustive training is performed between the transmitter and the receiver in which the antenna of the receiver is positioned at all locations and the transmitter sending multiple spatial patterns. Exhaustive training is well-known in the art. In this case, M transmit spatial patterns are transmitted by the transmitter and N received spatial patterns are received by the receiver to form an N by M channel matrix.
  • the transmitter goes through a pattern of transmit sectors and the receiver searches to find the strongest signal for that transmission. Then the transmitter moves to the next sector.
  • a ranking of all the positions of the transmitter and the receiver and the signals strengths of the channel at those positions has been obtained.
  • the information is maintained as pairs of positions of where the antennas are pointed and signal strengths of the channels.
  • the list may be used to steer the antenna beam in case of interference.
  • subspace training is used in which the space is divided in successively narrow sections with orthogonal antenna patterns being sent to obtain a channel profile.
  • DSP digital baseband processing module 301
  • the DSP will have a set of coefficients that it sends to the phase shifters.
  • the coefficients indicate the amount of phase the phase shifter is to shift the signal for its corresponding antennas.
  • digital baseband processing module 301 (DSP) sends a set digital control information to the phase shifters that indicate the different phase shifters are to shift different amounts, e.g., shift 30 degrees, shift 45 degrees, shift 90 degrees, shift 180 degrees, etc.
  • the signal that goes to that antenna element will be shifted by a certain number of degrees of phase.
  • the end result of shifting, for example, 16, 32, 36, 64 elements in the array by different amounts enables the antenna to be steered in a direction that provides the most sensitive reception location for the receiving antenna. That is, the composite set of shifts over the entire antenna array provides the ability to stir where the most sensitive point of the antenna is pointing over the hemisphere.
  • the appropriate connection between the transmitter and the receiver may not be a direct path from the transmitter to the receiver. For example, the most appropriate path may be to bounce off the ceiling.
  • the wireless communication system includes a back channel 320, or link, for transmitting information between wireless communication devices (e.g., a transmitter and receiver, a pair of transceivers, etc.).
  • the information is related to the beam-forming antennas and enables one or both of the wireless communication devices to adapt the array of antenna elements to better direct the antenna elements of a transmitter to the antenna elements of the receiving device together.
  • the information also includes information to facilitate the use of the content being wirelessly transferred between the antenna elements of the transmitter and the receiver.
  • back channel 320 is coupled between digital baseband processing module (DSP) 318 and digital baseband processing module (DSP) 301 to enable digital baseband processing module (DSP) 318 to send tracking and control information to digital baseband processing module (DSP) 301.
  • back channel 320 functions as a high speed downlink and an acknowledgement channel.
  • the back channel is also used to transfer information corresponding to the application for which the wireless communication is occurring (e.g., wireless video). Such information includes content protection information.
  • the back channel is used to transfer encryption information (e.g., encryption keys and acknowledgements of encryption keys) when the transceivers are transferring HDMI data. In such a case, the back channel is used for content protection communications.
  • encryption is used to validate that the data sink is a permitted device (e.g., a permitted display).
  • a permitted device e.g., a permitted display
  • Blocks of frames for the HD TV data are encrypted with different keys and then those keys have to be acknowledged back on back channel 320 in order to validate the player.
  • Back channel 220 transfers the encryption keys in the forward direction to the receiver and acknowledgements of key receipts from the receiver in the return direction.
  • encrypted information is sent in both directions.
  • the use of the back channel for content protection communications is beneficial because it avoids having to complete a lengthy retraining process when such communications are sent along with content. For example, if a key from a transmitter is sent alongside the content flowing across the primary link and that primary link breaks, it will force a lengthy retrain of 2-3 seconds for a typical HDMI/HDCP system. In one embodiment, this separate bi-directional link that has higher reliability than the primary directional link given its omni-directional orientation. By using this back channel for communication of the HDCP keys and the appropriate acknowledgement back from the receiving device, the time consuming retraining can be avoided even in the event of the most impactful obstruction.
  • the back channel is used to allow the receiver to notify the transmitter about the status of the channel. For example, while the channel between the beam-forming antennas is of sufficient quality, the receiver sends information over the back channel to indicate that the channel is acceptable.
  • the back channel may also be used by the receiver to send the transmitter quantifiable information indicating the quality of the channel being used. If some form of interference (e.g., an obstruction) occurs that degrades the quality of the channel below an acceptable level or prevents transmissions completely between the beam-forming antennas, the receiver can indicate that the channel is no longer acceptable and/or can request a change in the channel over the back channel.
  • the receiver may request a change to the next channel in a predetermined set of channels or may specify a specific channel for the transmitter to use.
  • the back channel is bi-directional.
  • the transmitter uses the back channel to send information to the receiver.
  • Such information may include information that instructs the receiver to position its antenna elements at different fixed locations that the transmitter would scan during initialization.
  • the transmitter may specify this by specifically designating the location or by indicating that the receiver should proceed to the next location designated in a predetermined order or list through which both the transmitter and receiver are proceeding.
  • the back channel is used by either or both of the transmitter and the receiver to notify the other of specific antenna characterization information.
  • the antenna characterization information may specify that the antenna is capable of a resolution down to 6 degrees of radius and that the antenna has a certain number of elements (e.g., 32 elements, 64 elements, etc.).
  • communication on the back channel is performed wirelessly by using interface units. Any form of wireless communication may be used.
  • OFDM is used to transfer information over the back channel.
  • CPM is used to transfer information over the back channel.
  • Figure 141 is a block diagram of an exemplary computer system that may perform one or more of the operations described herein.
  • computer system 14100 may comprise an exemplary client or server computer system.
  • Computer system 14100 comprises a communication mechanism or bus 14111 for communicating information, and a processor 14112 coupled with bus 14111 for processing information.
  • Processor 14112 includes a microprocessor, but is not limited to a microprocessor, such as, for example, PentiumTM, PowerPCTM, AlphaTM, etc.
  • System 14100 further comprises a random access memory (RAM), or other dynamic storage device 14104 (referred to as main memory) coupled to bus 14111 for storing information and instructions to be executed by processor 14112.
  • RAM random access memory
  • main memory main memory
  • Main memory 14104 also may be used for storing temporary variables or other intermediate information during execution of instructions by processor 14112.
  • Computer system 14100 also comprises a read only memory (ROM) and/or other static storage device 14106 coupled to bus 14111 for storing static information and instructions for processor 14112, and a data storage device 14107, such as a magnetic disk or optical disk and its corresponding disk drive. Data storage device 14107 is coupled to bus 14111 for storing information and instructions.
  • Computer system 14100 may further be coupled to a display device
  • cursor control 14123 such as a mouse, trackball, trackpad, stylus, or cursor direction keys, coupled to bus 14111 for communicating direction information and command selections to processor 14112, and for controlling cursor movement on display 14121.
  • Another device that may be coupled to bus 14111 is hard copy device
  • bus 14111 Another device that may be coupled to bus 14111 is a wired/wireless communication capability 14125 to communication to a phone or handheld palm device.

Abstract

A method and apparatus for exchanging information between components. In one embodiment, the apparatus is for use in a wireless communication system for communicating with a wireless network and comprises a host processor having an I2C interface, a transceiver having an I2C interface, a physical interface coupling the host processor and the transceiver, the physical interface having an I2C bus coupled to the I2C interface of both the host processor and the transceiver and multiple separate banks of memory accessible by the host processor and the transceiver to exchange information between the host processor and the transceiver, where the host processor and the transceiver access the plurality of banks of memory via their respective I2C interfaces.

Description

EXCHANGING INFORMATION BETWEEN COMPONENTS
FIELD OF THE INVENTION
[0001] The present invention relates to the field of communicating information between devices in a wireless communication system; more particularly, the present invention relates to a host and transceiver in a wireless communication system, including their interaction, communication, and/or initialization.
BACKGROUND OF THE INVENTION
[0002] WirelessHD™ is an industry-led effort to define a specification for the next generation wireless digital network interface specification for wireless high- definition (HD) signal transmission for consumer electronics products. [0003] The WirelessHD™ (WiHD™) standard allows for uncompressed digital transmission of HD video and audio and data signals, with a goal of being the same or higher quality as wired HDMI. The specification has been designed and optimized for wireless display connectivity, achieving high-speed rates up to 4 Gbit/s. [0004] The signal will operate on the 60 GHz band and support the bandwidth required to support both current and future HD signals. Operation in the 60 GHz band previously required line of sight to communicate between two devices. However, the WiHD standard overcomes this limitation through the use of beamforming at both the receiver and transmitter to achieve non line of sight communication.
SUMMARY OF THE INVENTION
[0005] A method and apparatus for exchanging information between components. In one embodiment, the apparatus is for use in a wireless communication system for communicating with a wireless network and comprises a host processor having an I C interface, a transceiver having an I C interface, a physical interface coupling the host processor and the transceiver, the physical interface having an I2C bus coupled to the I C interface of both the host processor and the transceiver and multiple separate banks of memory accessible by the host processor and the transceiver to exchange information between the host processor and the transceiver, where the host processor and the transceiver access the plurality of banks of memory via their respective I2C interfaces. [0006] In one embodiment, the apparatus is used in a wireless communication system for communicating with a wireless network, and includes a host processor having an I C interface, a transceiver having an I C interface, and a physical interface coupling the host processor and the transceiver. The physical interface comprises an I C bus coupled to the I C interfaces of both the host processor and the transceiver, and is compatible with HDMI.
[0007] In one embodiment, the apparatus is for use in a wireless communication system for communicating with a wireless network and comprises a host processor, a transceiver, a physical interface coupling the host processor and the transceiver, and a memory accessible by the host processor and the transceiver to exchange information between the host processor and the transceiver. The transceiver is operable to store data in the memory for the host processor to send data to the host processor using the memory and asserts a control signal to the host processor to notify the host processor that the memory contains data for the host processor, and the host processor is operable to access the memory to obtain the data thereafter. The data is associated with a remote device in the wireless network and is stored as one or more packets at a first storage location in the memory with a first identifier identifying the remote device. [0008] In one embodiment, the method comprises: accessing a memory to obtain one or more bitmaps that map each bit location in the bitmap to an index value, where one index value is assigned to each remote wireless media device of a wireless network in a wireless communication system; and examining those bitmaps and determining at least one characteristic of a remote wireless media device and a device identifier that identifies the remote wireless media device in the wireless network based on the bit position in those bitmaps.
[0009] In one embodiment, a method for initializing a transceiver that is part of an apparatus for use in a wireless communication system for communicating with WirelessHD devices in a wireless network, where the apparatus comprises a host processor; a transceiver; a physical interface coupling the host processor and the transceiver; and a memory accessible by the host processor and the transceiver to exchange information between the host processor and the transceiver, the initialization method comprising resetting the transceiver by initializing internal hardware and software subsystems of the transceiver; after resetting the transceiver, the transceiver entering a configuration state to configure the transceiver; configuring the transceiver, such that the transceiver is configured as part of initialization; and after configuration, the transceiver entering a wait enable state during which the transceiver waits for its wireless interface to be enabled before wireless operation of the transceiver becomes active.
[0010] In one embodiment, a device discovery process is used in a wireless communication system having an apparatus for communicating with WirelessHD devices in a wireless network, where the apparatus comprises a host processor; a transceiver; a physical interface coupling the host processor and the transceiver; and a memory accessible by the host processor and the transceiver to exchange information between the host processor and the transceiver, and the device discovery process comprises: discovering a remote wireless device in the wireless network; notifying, by the transceiver, the host processor of the remote wireless device; requesting, under control of the transceiver, capability information from the remote wireless device prior to receiving a request from the host processor for the capability information; buffering, under control of the transceiver, the capability information before the capability information is requested by the host processor; receiving a capability request from the host processor; and providing the host processor access to the capability information. [0011] In one embodiment, an apparatus is used in a wireless communication system for communicating with a wireless network, and the apparatus comprises a host processor, a transceiver, a physical interface coupling the host processor and the transceiver; and a memory accessible by the host processor and the transceiver to exchange information between the host processor and the transceiver. The memory has multiple banks that include: a first bank to store information being transferred from the host processor to the transceiver, and a second bank to store information being transferred from the transceiver to the host processor, the second bank being different than the first bank, to facilitate full-duplex communication of packet data between the host processor and the transceiver.
BRIEF DESCRIPTION OF THE DRAWINGS
[0012] The present invention will be understood more fully from the detailed description given below and from the accompanying drawings of various embodiments of the invention, which, however, should not be taken to limit the invention to the specific embodiments, but are for explanation and understanding only. [0013] Figure 1 illustrates a software architecture of host and transceiver. [0014] Figure 2 illustrates a host system protocol stack needed to drive
WirelessHD transceiver.
[0015] Figure 3 illustrates a standard packet format.
[0016] Figure 4 illustrates a physical interface between host and transceiver.
[0017] Figure 5 illustrates a packet format of host AVC messages.
[0018] Figure 6 illustrates an example Connect Request message packet.
[0019] Figure 7 illustrates a WirelessHD Connect Request format.
[0020] Figure 8 illustrates a Feature Abort message format.
[0021] Figure 9 illustrates a state machine diagram for initialization.
[0022] Figure 10 is a flow diagram of a wireless transceiver initialization sequence.
[0023] Figure 11 illustrates a field description of Reset register.
[0024] Figure 12 illustrates a Location 0 of Status register being set to T by the transceiver when transceiver is loaded.
[0025] Figure 13 illustrates a field description of a System status register.
[0026] Figure 14 illustrates a host setting bit location 0 to '1' to clear status register bit location 0.
[0027] Figure 15 illustrates a set bit location 0 of Host Control register to ' 1 ' to enable WIHD.
[0028] Figure 16 illustrates bit location 1 is set to T by the transceiver when
WIHD is enabled.
[0029] Figure 17 illustrates a host must set bit location 1 to ' 1 ' to clear status register bit location 1.
[0030] Figure 18 illustrates a transceiver chip information.
[0031] Figure 19 illustrates a host capabilities block of AVC Information
Register Bank.
[0032] Figure 20 illustrates a host must set bit location 1 of Host Control register to '1' to set host device capabilities.
[0033] Figure 21 illustrates bit location 2 being set to '1' to set host input format data.
[0034] Figure 22 illustrates a three stages of the device discovery process.
[0035] Figure 23 illustrates a device discovery state-machine.
[0036] Figure 24 illustrates a Device Detect stage of discovery process.
[0037] Figure 25 illustrates a device list index to bitfield mapping. [0038] Figure 26 illustrates an example Device List with three active devices detected.
[0039] Figure 27 illustrates Location 2 is set to T by the transceiver when device list is altered.
[0040] Figure 28 illustrates an example device list update based on system of
Figure 26.
[0041] Figure 29 illustrates a host setting bit location 2 to ' 1 ' to clear status register bit location 2.
[0042] Figure 30 illustrates a Capability Request stage of discovery process.
[0043] Figure 31 illustrates a payload structure of a Capabilities Request message.
[0044] Figure 32 illustrates a Capabilities Request message.
[0045] Figure 33 illustrates bit location being set 3 to '1' to indicate that TX data is ready for the transceiver.
[0046] Figure 34 illustrates Location 4 being set to T by the transceiver after it finishes extracting the TX message.
[0047] Figure 35 illustrates bit location 4 being set to '1' to clear status register bit location 4.
[0048] Figure 36 illustrates a Capability Response stage of discovery process.
[0049] Figure 37 illustrates a payload structure of a Capabilities Response message.
[0050] Figure 38 illustrates a Capabilities Response message as it would appear in register bank 0xA8.
[0051] Figure 39 illustrates Location 5 being set to T by the transceiver after it finishes writing to the RX bank.
[0052] Figure 40 illustrates bit location 5 being set to '1' to clear status register bit location 5.
[0053] Figure 41 illustrates a WirelessHD compliant connection/disconnection control sequence.
[0054] Figure 42 illustrates a sink host connection control state-machine.
[0055] Figure 43 illustrates a source host connection control state-machine.
[0056] Figure 44 illustrates an AVC Connect sequence.
[0057] Figure 45 is a flow diagram of a wireless transceiver connect sequence.
[0058] Figure 46 illustrates a payload structure of a Connect Request message. [0059] Figure 47 illustrates a Connect Request message as it would appear in the TX (OxAC) or RX (0xA8) register bank.
[0060] Figure 48 illustrates bit location 3 being set to ' 1 ' to indicate that TX data is ready for the transceiver.
[0061] Figure 49 illustrates Location 4 being set to T by the transceiver after it finishes extracting the TX message.
[0062] Figure 50 illustrates bit location 4 being set to ' 1 ' to clear status register bit location 4.
[0063] Figure 51 illustrates Location 5 being set to T by the transceiver after it finishes writing to the RX bank.
[0064] Figure 52 illustrates bit location 5 being set to '1' to clear status register bit location 5.
[0065] Figure 53 illustrates a payload structure of a Connect Response message.
[0066] Figure 54 illustrates a Connect Response message as it would appear in the TX(OxAC) or RX(0xA8) register bank.
[0067] Figure 55 illustrates Location 3 being set to T by the transceiver after it finishes writing the input format data.
[0068] Figure 56 illustrates bit location 3 being set to '1' to clear status register bit location 3.
[0069] Figure 57 illustrates a payload structure of an Output Format Request message.
[0070] Figure 58 illustrates an Output Format Request message as it would appear in the TX(OxAC) or RX(0xA8) register bank.
[0071] Figure 59 illustrates a payload structure of an Output Format Response message.
[0072] Figure 60 illustrates an Output Format Response message as it would appear in the TX(OxAC) or RX(0xA8) register bank.
[0073] Figure 61 illustrates a payload structure of a Start Stream Notify message.
[0074] Figure 62 illustrates a Start Stream Notify message as it would appear in the RX(0xA8) register bank.
[0075] Figure 63 illustrates an AVC Disconnect sequence. [0076] Figure 64 is a flow diagram of a wireless transceiver disconnect sequence.
[0077] Figure 65 illustrates a payload structure of a Disconnect Notify message.
[0078] Figure 66 illustrates a Disconnect Notify message as it would appear in the TX(OxAC) or RX(0xA8) register bank.
[0079] Figure 67 illustrates bit location 3 being set to '1' to indicate that TX data is ready for the transceiver.
[0080] Figure 68 illustrates Location 4 being set to T by the transceiver after it finishes extracting the TX message.
[0081] Figure 69 illustrates bit location 4 being set to '1' to clear status register bit location 4.
[0082] Figure 70 illustrates Location 5 being set to T by the transceiver after it finishes writing to the RX bank.
[0083] Figure 71 illustrates bit location 5 being set to ' 1 ' to clear status register bit location 5.
[0084] Figure 72 illustrates a payload structure of a Stop Stream Notify message.
[0085] Figure 73 illustrates a Stop Stream Notify message as it would appear in the RX(0xA8) register bank.
[0086] Figure 74 illustrates a payload structure of a Device Control message.
[0087] Figure 75 illustrates a Device Control message as it would appear in the
RX(0xA8) or TX(OxAC) register bank.
[0088] Figure 76A is a block diagram of a host coupled to a transceiver.
[0089] Figure 76B illustrates a register bank summary.
[0090] Figure 77 illustrates a register map of AVC Info Registers (1/4).
[0091] Figure 78 illustrates a register map of AVC Info Registers (2/4).
[0092] Figure 79 illustrates a register map of AVC Info Registers (3/4).
[0093] Figure 80 illustrates a register map of AVC Info Registers (4/4).
[0094] Figure 81 illustrates a bit-description of register 0x06.
[0095] Figure 82 illustrates a bit-description of register 0x07.
[0096] Figure 83 illustrates a bit-description of register 0x22.
[0097] Figure 84 illustrates a Control Register space format.
[0098] Figure 85 illustrates a field description of Reset register. [0099] Figure 86 illustrates a field description of Power Mode register.
[00100] Figure 87 illustrates a field description of Interface Control register.
[00101] Figure 88 illustrates a field description of Ready register.
[00102] Figure 89 illustrates a field description of Host Control register.
[00103] Figure 90 illustrates a field description of Status register.
[00104] Figure 91 illustrates a field description of Clear register.
[00105] Figure 92 illustrates a field description of System status register.
[00106] Figure 93 illustrates a bit-map layout of Devcap HRRX registers.
[00107] Figure 94 illustrates a bit-map layout of Devcap HRTX registers.
[00108] Figure 95 illustrates a bit-map layout of Device Index registers.
[00109] Figure 96 illustrates a SoC version label resides in the Control register bank (0xA4), offsets 0xF7-0xFB.
[00110] Figure 97 illustrates a bit-description of register 0xF7.
[00111] Figure 98 illustrates System Tick registers residing in the Control register bank (0xA4), offsets OxFC - OxFF.
[00112] Figure 99 illustrates a register space format of a receiver.
[00113] Figure 100 illustrates a format of sequence field.
[00114] Figure 101 illustrates a Device Capabilities Message.
[00115] Figure 102 illustrates a Requested Types bit-field.
[00116] Figure 103 illustrates a Capabilities Response message.
[00117] Figure 104 illustrates a Feature Abort message indicating a failure to obtain Capabilities Request information.
[00118] Figure 105 illustrates a Connect Request message.
[00119] Figure 106 illustrates a Feature Abort message indicating a failure to obtain a Connect Response.
[00120] Figure 107 illustrates a Connect Response message.
[00121] Figure 108 illustrates a Feature Abort message indicating a failure to send the Connect Response.
[00122] Figure 109 illustrates an Output Format Request message.
[00123] Figure 110 illustrates an Output Format Response message.
[00124] Figure 111 illustrates a Stream Start Notify message.
[00125] Figure 112 illustrates a Disconnect Notify message.
[00126] Figure 113 illustrates a Stream Stop message. [00127] Figure 114 illustrates a Feature Abort message indicating a failure to send the Disconnect Notify.
[00128] Figure 115 illustrates Device Control messages.
[00129] Figure 116 illustrates a Feature Abort message indicating a failure of a
Device Control message.
[00130] Figure 117 illustrates a HDMI Pass-Through Request message.
[00131] Figure 118 illustrates a Feature Abort message indicating a failure to obtain an HDMI Pass-Through Response.
[00132] Figure 119 illustrates an HDMI Pass-Through Response message.
[00133] Figure 120 illustrates a Feature Abort message indicating a failure to send the HDMI Pass-Through Response.
[00134] Figure 121 illustrates an EDID Request message.
[00135] Figure 122 illustrates a Feature Abort message indicating a failure to obtain an EDID Response.
[00136] Figure 123 illustrates an EDID Response message.
[00137] Figure 124 illustrates a Feature Abort message indicating a failure to send the EDID Response.
[00138] Figure 125 illustrates a Data Island Notify message.
[00139] Figure 126 illustrates a Feature Abort message indicating a failure to send the Data Island Notify.
[00140] Figure 127 illustrates a CEC Notify message.
[00141] Figure 128 illustrates a Feature Abort message indicating a failure to send the CEC Notify.
[00142] Figure 129 illustrates a CEC NAK message.
[00143] Figure 130 illustrates a Feature Abort message indicating a failure to send the CEC NAK.
[00144] Figure 131 illustrates a Logical Address Table Notify message.
[00145] Figure 132 illustrates definitions of the logical address bitmap.
[00146] Figure 133 illustrates a Feature Abort message indicating a failure to send the Logical Address Table Notify
[00147] Figure 134 illustrates an HPD Notify message.
[00148] Figure 135 illustrates a Feature Abort message indicating a failure to send the HPD Notify. [00149] Figure 136 illustrates a Feature Abort message indicating unrecognized opcode.
[00150] Figure 137 is a block diagram of one embodiment of a radio chip.
[00151] Figure 138 is a block diagram of one embodiment of a communication system.
[00152] Figure 139 is a block diagram of one embodiment of a receiver device that is part of a display.
[00153] Figure 140 is a block diagram of one embodiment of a transmitter device and a receiver device that are part of an adaptive beam forming multiple antenna radio system containing of Figure 138.
[00154] Figure 141 is a block diagram of a computer system.
[00155] Figure 142 is a flow diagram of one embodiment of a bitmap device identification process.
[00156] Figure 143 is a flow diagram of one embodiment of a device discovery process for use in a wireless communication system.
[00157] Figure 144 illustrates a connection control flow through transmit and receive register banks.
[00158] Figure 145 illustrates a connection control flow through transmit and receive register banks with a separate data exchange through the AVC information register bank.
DETAILED DESCRIPTION OF THE PRESENT INVENTION [00159] In the following description, numerous details are set forth to provide a more thorough explanation of the present invention. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the present invention. [00160] Some portions of the detailed descriptions which follow are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. [00161] It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as "processing" or "computing" or "calculating" or "determining" or "displaying" or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
[00162] The present invention also relates to apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus. [00163] The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the present invention is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the invention as described herein. [00164] A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium includes read only memory ("ROM"); random access memory ("RAM"); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.); etc.
Overview
[00165] Methods, physical interface, and protocol of one embodiment of an
AVC Host Interface are described. A host controller device to interface with a WirelessHD transceiver in a wireless network is also described. [00166] For purposes herein an Audio/Video Controller (AVC) is an embedded component that interfaces between the host system and a wireless network. Consumer Electronics (CE) refers to a term referring to any of various electronic devices that a typical consumer might own such as a television, DVD player, etc. A Host Audio/Video Controller (Host AVC) is a component on the host system that understands how to communicate with the embedded AVC component. The Host AVC initiates and controls communications on the wireless network. The I2C Protocol, an Inter-Integrated Circuit Protocol, is a multi-master serial bus used to enable low-speed communications between processors or computers.
System Overview
[00167] The WirelessHD transceiver transfers high-definition audio- video (AV) content wirelessly between devices. From the host's perspective, there are several control operations that can be affected, including initialization of the transceiver; discovering remote WirelessHD devices on the network; connecting to/disconnecting from a remote WirelessHD device; executing device control commands on a remote WirelessHD device; and interfacing wireless controls and behavior. One embodiment of the interface to a WirelessHD transceiver to achieve the described operations is described herein.
[00168] Figure 1 is a block diagram of one embodiment of the system model.
Referring to Figure 1, the host software represents the host protocol stack that enables the consumer electronics (CE) device to interface with the transceiver. Figure 2 illustrates one embodiment of a host system protocol stack. Referring to Figure 2, system control 201 exercises high level system control and interface to the user, serving a similar role as the Application layer of the OSI model. In one embodiment, all wireless specific information is hidden from this layer. Host control 202 serves a similar role as the Presentation and Session layers of the OSI model by managing the state-machine associated with connection/disconnection and control dialogue. Host AVC 203 encapsulates WirelessHD and other specific packet formats and communication sequences in an API library for the layer of host control 202. Communication (comm) driver 204 has the capability to format messages properly and in proper sequence on the bus connecting the host system to the WirelessHD transceiver. Hardware Abstraction Layer (HAL) 205 is the physical driver of the interface. In one embodiment, transceiver uses the standard 8-bit addressing mode described in "The I2C-BuS Specification v.2.1, January 2000 (9398-393-40011)" with the transceiver being the slave device and the host being the master. [00169] Figure 3 illustrates generic read and writes sequences for I2C. In one embodiment, the generic read and write sequences used for I2C bus are the same protocol as used in HDMI. .
[00170] Figure 4 illustrates interface between a host and a transceiver. Referring to Figure 4, host 401 and transceiver 402 are interfaced using 4 bus drivers: SDA 410, clock 411, Interrupt (INT) 412, and Reset 413. SDA 410 and clock 411 represent the two communication pins. Two communication pins 410 and 411, an INT (interrupt) pin 412 and RESET# (reset, active low) pin 413 exist as part of the interface. The RESET# pin 413 is an input into the transceiver that allows the host to force a hardware reset of the transceiver at certain times (e.g., in the event of a serious system failure). The INT pin 412 is an output of the transceiver which is asserted whenever the transceiver needs to notify host 411 of an event. In one embodiment, an event is indicated by a non-zero status of the status register which resides in bank 0xA4, offset 0x05. Optionally, the INT 412 and RESET# 413 functionality is available by polling the status register or reset register directly.
[00171] Use of interrupt pin 412 controls the packet interface. The interrupt is incorporated here to eliminate the need of a poll driven architecture and the host. [00172] In one embodiment, this physical interface between the host and the transceiver is HDMI compatible. That is, in one embodiment, the wireless communication system includes an apparatus to communicate with remote wireless devices (e.g., WirelessHD devices) in the wireless network, where the apparatus comprises: a host processor having an I2C interface; a transceiver having an I2C interface; and a physical interface coupling the host processor and the transceiver that includes an I2C bus coupled to the I2C interfaces of both the host processor and the transceiver, and where the host processor maps a message -based communication protocol to a register-based communication protocol of an HDMI controller device to communicate with that device using the I2C bus. Thus, while an HDMI interface is register-based, the host processor that uses a message-based protocol to communicate can interface with the HDMI device over the I C bus. In one embodiment, the host processor controls the transceiver using the physical interface as an AVC host. In another embodiment, the apparatus includes an HDMI device coupled to the I2C bus, wherein the host processor communicates with both HDMI device and the transceiver as an AVC host using the I2C bus. Note that this I2C bus is not the I2C bus that runs from the HDMI controller to the HDMI player (e.g., DVD player, TV, etc.). This is shown in Figure 137. Because the HDMI controller interface is used, there is no need for a separate GPIO to be used by the host to communicate to the controller; it canuse the same interface it uses to communicate with the transceiver. Thus, for a party at an HDMI device, the host doesn't need to set up a new driver on their host in order to talk to that device. By allowing the WirelessHD controller interface codes using the same bus as the HDMI device, and no extra pins are required to support WIHD controller interface and the host's support of HDMI
[00173] In one embodiment, actions and communications on the wireless network are initiated by the host system in one of two ways - writing to specific control registers that enable specific action, or by sending packet data through the wireless network. Packet formats and register definitions are described in detail. In one embodiment, the format of packet messages, for the most part, maintains the same packet format described in Section 10 of the WirelessHD specification, "WirelessHD Specification rev.1.0, December 12, 2007" for connection control and device control messages.
[00174] Figure 5 illustrates one embodiment of the packet format of host AVC messages. Referring to Figure 5, the packet format includes the following fields:
• Function Type (byte 0) - As defined in the WirelessHD specification, this field describes the function of this operation:
- connection control = 0x00
- device control = 0x01 - content protection = 0x03
- HDMI pass-through = 0x04
• Device Index (byte 1) - The index of the device as provided by the transceiver in the device list. For more information, see section 0.
• Opcode (bytes 2 and 3) - The opcode mirrors exactly the definitions outlined in the WirelessHD specification for audio/video control
• Parameters (byte 4 - byte 4 and 8) - These follow the parameter definition and ordering shown in the WirelessHD specification for audio/video control opcodes.
[00175] Example usages of this packet format are shown herein, but for completeness, a brief example is shown in Figure 6. Figure 6 describes the packet format of one embodiment of a Connect Request message from a host system, which sends this message in order to initiate a connection sequence to a remote device. Contrast this format with the WirelessHD format for AVC shown in Figure 7. [00176] In one embodiment, in the event that a message sent by the host is rejected by the transceiver, a "Feature Abort" message is sent back to the host from the transceiver to indicate that the operation is rejected. A reason for the rejection will also be available in the abort message.
[00177] Figure 8 illustrates one embodiment of a Feature Abort message format.
Referring to Figure 8, the Feature Abort message format has the following fields:
• Function Type - function of the opcode being rejected
• Opcode - the Feature Abort opcode is OxFFOO
• Device Index - device list index that the host attempted to send a message to, but the transceiver needs to reject.
• Rejected Opcode - the value of the rejected opcode
• Reason Code - the cause of rejection
- Reserved = 0x00 (reason code reserved for Success)
- Unrecognized Opcode = 0x01
- Not in correct mode to respond = 0x02
- Cannot provide source = 0x03
- Invalid operand = 0x04
- Refused = 0x05 - Timeout = 0x06
- Out of Sequence = 0x07
Initialization
[00178] In one embodiment, the WirelessHD transceiver undergoes an initialization sequence in order to operate properly on the network. The initialization sequence differentiates between the "on" state vs. the "active" state and allows the configuration of the chip as part of the initialization stage. In one embodiment, when the transceiver powers on, the transceiver sends an interrupt to the host indicating that it is on line. The transceiver comes up in the configuration mode where the host can set specific parameters.
[00179] Figure 9 illustrates the three states involved in one embodiment of the initialization process. These states include reset 901, configuration (config) 902, and wait enable 903. Referring to Figure 9, the transceiver begins in reset state 901 where the transceivers initializes all internal hardware and software subsystems. Once this completes, the transceiver enters config state 902 where wireless activity is still unavailable, but configuration of the wireless system and debug diagnostics are available via register bank access, which is described in more detail below. After completing any necessary configurations, in one embodiment, the wireless interface is enabled before wireless operation become active. During this time, the transceiver is in wait enable state 903. Once the wireless interface is enabled, the transceiver is initialized (904).
[00180] Figure 10 is a flow diagram of one embodiment of a wireless transceiver initialization process. The process is performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both.
Reset WIHD (1001)
[00181] In one embodiment, there are a number of methods available to reset the transceiver chip. One method to reset the transceiver and all wireless state information is to assert the hardware reset pin. [00182] In one embodiment, if the reset pin is not connected, a reset can be invoked by writing to register bank 0xA4 (Figure 76B), offset 0x00 (a complete description of the registers is provided below). Figure 11 illustrates a field description of a reset register. Referring to Figure 11, in one embodiment, writing 0x01 to register 0x00 of bank 0xA4 (Figure 76B) will cause a hardware reset to occur. Similarly, writing 0x02 to this register causes a software reset.
Chip OK status (1002)
[00183] After reset 1001, processing logic performs a test to determine if the chip status is ready for use. When the transceiver is reset, none of the registers or banks are available for use until the transceiver completes re-initialization of its own internal states. When the transceiver completes the re-initialization process, the transceiver indicates to the host system that the re-initialization is complete by updating the value of a special control register called the status register. This register resides in bank 0xA4 (Figure 76B), offset 0x05.
[00184] Figure 12 illustrates Location 0 of Status register being set to T by the transceiver when transceiver is loaded As shown in Figure 12, the least-significant bit (bit 0) will be logic ' 1 ' in this read-only register when the transceiver completes its own re-initialization process. Note that the optional hardware interrupt pin (412) will also assert to indicate to the host system that the status register is non-zero. The interrupt pin (412) stays asserted until the host clears all asserted bits of this register. In one embodiment, when the host detects a "CHIP LOAD" event, it should then read the contents of register bank 0xA4 (Figure 76B), offset 0x07 (the system status register) to monitor whether any system failures occurred.
[00185] Figure 13 is a field description of a System status register. Referring to
Figure 13, if all the bits of the system status register are zero, then all modules in the transceiver have been initialized and are operating normally.
[00186] When the host determines that the transceiver status is ok, the host clears the status register. This may be performed by writing a value of 0x01 to the write-only register in bank 0xA4, offset 0x06. As shown in Figure 14, this action causes the "CHIP LOAD" bit in register 0x05 to clear. In one embodiment, the status register (bank 0xA4, offset 0x05) is a read-only register, and attempting to clear bits on this register by writing directly to offset 0x05 will have no effect. [00187] At this point, the chip is now in a "configuration" state where wireless configurations and settings can be modified. Test and debug diagnostics settings can also be altered at this time. The wireless interface itself, however, is not active yet.
Enable (1003)
[00188] After the chip is ok (1002), the physical hardware is now online, but the wireless interface is not active until it is explicitly enabled by the host. In one embodiment, processing logic enables the wireless interface (WIHD) by causing a value of 0x01 to be written to the write-only register in bank 0xA4, offset 0x04 (the host control register). Figure 15 illustrates bit location 0 of the Host Control register being set to '1' to enable WIHD.
Enabled Status (1004)
[00189] In one embodiment, the wireless interface activation is controlled by the host. When activated, set-up routines occur on the transceiver device to initialize and activate the radio. Once the radio is activated, the transceiver will join or initialize a
WirelessHD network. At this point, the transceiver is considered to be enabled. The status register in bank 0xA4, offset 0x05 indicates that the wireless interface is available by setting bit 1 to '1'. Figure 16 illustrates bit location 1 is to be set to T by the transceiver when WIHD is enabled.
[00190] The host acknowledges this status by clearing the corresponding bit in the clear register. Figure 17 illustrates bit location 1 that the host sets to '1' to clear status register bit location 1
Get Chip Info (1005)
[00191] With the chip enabled, all register banks are now active. In one embodiment, the chip information consists of 3 bytes and is stored in register bank OxAO, offsets 0x00-0x03. Figure 18 illustrates the transceiver chip information. Referring to Figure 18, the device ID is a bit field which will return 0x01, if the transceiver is configured for Sink devices, 0x02, if the transceiver is configured for Source devices, and 0x03 if the transceiver is configured to be either Sink or Source devices. The device revision provides version information of the software revision resident in the transceiver, and the vendor ID reveals the manufacturer of the transceiver. Set Capabilities (1006)
[00192] In order for the transceiver to be visible on the wireless network as an
A/V device, the host first communicates its capabilities information to the transceiver. As per the WiHD specification, the transceiver uses the capabilities information provided by the host in order to advertise itself as a node on the WirelessHD network to other host systems. More specifically, according to the WiHD specification on the AVC layer, the transceiver makes its presence known by communicating the capabilities of the host system that it is attached to. As a result, the transceiver cannot advertise itself (and thus, cannot be visible) unless it first receives information from the host describing this information. In one embodiment, the capabilities consist of 29 bytes of information and are stored in register bank OxAO, offsets 0x04-0x20. Figure 19 illustrates host capabilities block of AVC information register bank. [00193] After populating the information of the host capabilities registers, the host notifies the transceiver that the information is ready. To achieve this, the host writes a value of 0x02 to the write-only register in bank 0xA4 (Figure 76B), offset 0x04 (the host control register). Until this action is performed, the transceiver does not parse or use any of the values written to the host capabilities registers. Figure 20 illustrates bit location 1 of Host Control register that the host sets to ' 1 ' to set host device capabilities.
[00194] When the host indicates that the host device capabilities fields are ready via the host control register, the transceiver then parses the fields and makes itself visible on the wireless network using the information provided by the host. The transceiver automatically engages in device discovery services and notifies the host asynchronously as remote devices are detected.
Set Input Format (Sink Only - 1007)
[00195] In one embodiment, sink devices perform one more operations in order to complete the initialization procedure. The sink host provides the input format data to the transceiver, so that it can be made available to remote source devices. In one embodiment, input format data is similar to EDID formatting data which is used in some wired connections, and consists of 222 bytes of information and is stored in register bank OxAO (Figure 76B), offsets 0x21-OxFE as shown in Figure 77 through 80 described in more detail below.
[00196] After populating the information of the input format registers, the host notifies the transceiver that the information is ready. To achieve this, the host writes a value of 0x04 to the write-only register in bank 0xA4 (Figure 71), offset 0x04 (the host control register). Figure 21 illustrates bit location 2 that the host sets to '1' to set host input format data. Until this action is performed, the transceiver does not parse or use any of the values written to the input format registers.
[00197] When the sink host indicates that the host input format fields are ready via the host control register, the transceiver then parses the fields and makes the information available to any remote device requesting the input format of the sink device. Note that in one embodiment setting the "INPUT FORMAT DONE" bit on a source device has no effect.
Device Discovery
[00198] Device discovery is the operation whereby a system can detect remote devices on a WirelessHD network. In one embodiment, there are three stages to the discovery process which are illustrated in Figure 22. Referring to Figure 22, the three stages are:
• device detect 2201 - The transceiver receives the first stimulus to begin the device discovery process. Through the mechanisms provided by WirelessHD (which have not been included to avoid obscuring the invention), the transceiver discovers a remote device and indicates to the host that there is a change in the status of the network.
• capability request 2202 - The host can then make the determination of whether it needs to request information on a remote device.
• capability response 2203 - If the host needed to make a capability request, then a response stage is necessary to receive the requested information.
[00199] One embodiment of a corresponding state-machine of the device discovery process is shown in Figure 23. Referring to Figure 23, the device discovery state machine begins in the idle state 2301. When a new device is detected, the state machine transitions from 2301 to capabilities needed state 2302. When at the capabilties needed state 2302, a capabilities request is sent, at which time a state machine transitions to wait for connect state 2303. It remains in this state until the transitions back to the capabilities needed state 2302 with a capabilities response when a capabilities response is received or to idle state 2301 when all devices are up to date. The state machine remains in idle state 2301 until a new device is detected. At any point in the device discovery process, if the transceiver detects a failure, the transceiver indicates this to the host by issuing a "Feature Abort" command (opcode OxFFOO) to the host with an appropriate reason code. If the host receives a "Feature Abort" for a particular device, the host returns the state variables back to the "IDLE" state for that device.
[00200] Note that in one embodiment, a "Capabilities Request" is not issued from the transceiver to the host. It is unnecessary for the transceiver to request capabilities from the host because this information was already communicated to the transceiver during the initialization phase as discussed herein. For this reason, when a remote device requests capabilities, the transceiver responds without involving the host system. The following discussion describes each of the stages of the device discovery process in greater detail.
Device Detect
[00201] Figure 24 illustrates one embodiment of a device detect stage of the discovery process. The transceiver receives the first stimulus to begin the device discovery process. Through the mechanisms enabled by WirelessHD, the transceiver discovers remote devices in the wireless network 2400 in real-time (2401). After the transceiver discovers a remote devices in the wireless network, transceiver sends an interrupt 2402 to the host. This interrupt includes a device list. The interrupt may comprise interrupt 412 of Figure 4. After receiving the interrupt 2402, the host reads the device list directly from the transceiver's I C register bank. When the device detection process is complete, the host sends a clear interrupt 2405 to the transceiver. As each new device is detected or existing devices leave the network, the transceiver notifies the host through an indexed bitmap table resident in the control register space. One embodiment of the detect process flow is as follows: New Device Detected
[00202] When the transceiver detects a new WirelessHD device, the transceiver assigns an index value to that device and then makes this information available to the host via the control register bank 0xA4, offsets 0x08-0xlF. These 24 registers operate as 3 64-bit bitfields with each bit location representing an index value. Figure 25 illustrates one embodiment of device list index to bitfield mapping. [00203] In one embodiment, Registers 0x08 through OxOF indicate which device indices are HRRX capable; and registers 0x10-0x17 indicate which device indices are HRTX capable. Registers 0xl8-0xlF indicate all devices without filtering on HRRX or HRTX capability. Note that it is possible for a single device to be both HRRX capable and HRTX capable just as it is possible for a single device to be neither HRRX capable nor HRTX capable. Figure 26 shows an example device list with three active devices detected. Referring to Figure 26, the table indicates that there are 3 discovered devices in the wireless network at indices 0x02, 0x03, and 0x2C. Device index 0x02 is HRRX capable only, device 0x03 is simultaneously HRRX capable and HRTX capable, and device 0x2C is both HRRX and HRTX capable. In one embodiment, these register locations are read-only to the host system.
[00204] Thus the system uses bitmap device identification in a wireless HD network. In Figure 25, 64 devices can be included in a wireless HD network. In a wireless HD network in prior art wireless HD networks, capabilities requests would have to be sent when discovering a new device to get the capability response obtained. To handle 64 different devices it would take extra bandwidth and force a lot of extra work when a single or new or subset of the 64 devices have been added to the network. The array in Figure 25 makes it possible to know the characteristics and device idea remote devices based on good position memory. The network stairs can be immediately known without needing to query capabilites of all possible device IDs. The position in the array indicates what the device does (sink, transmitter, position also allows to know what the id of the device is as the bitmap location is its ID. The array of Figure 25 is stored in the bank of the I2C. When the system wants to notify the host that there is at least one new device that has been discovered or detected, the transceiver sends an interrupt to the host which prompts the host to read the 64 bits and parks that information. The host is only interested in connecting to transmitter devices, and quickly scans the array to determine which those are by the position of the array and then sends capabilities requests to get the information.
[00205] In one embodiment, whenever the transceiver updates the device list, the transceiver also simultaneously asserts the interrupt pin (412 of Figure 4) of the transceiver chip (2402 of Figure 24) and updates bit 0x02 of the status control register which resides in register bank 0xA4 (Figure 76B), offset 0x05. Figure 27 illustrates location 2 being set to '1' by the transceiver when device list altered. Recall, that an action that requires the attention of the host system asserts the interrupt pin (412) and updates control register 0x05. In another embodiment, whenever the transceiver updates the device list, the transceiver also asserts the interrupt pin (412 of Figure 4) of the transceiver chip (2402 of Figure 24) substantially at the same time and updates bit 0x02 of the status control register which resides in register bank 0xA4 (Figure 76B), offset 0x05.
Host Retrieval of New Device List
[00206] When the host detects a device list change, either by polling the status register shown in Figure 27 or waiting for the INT pin to assert and then reading the status register, the host needs to determine which devices are new. This determination is largely dependent on the constraints of the host system. In one embodiment, there are two methods in which the device list determination can be accomplished. [00207] One approach is for the host to renew the device list information each time a device list change is indicated. Specifically, when the "DEVCAP RXD" bit is set as shown in Figure 27, the host can request device capabilities for all active indices every time. So, in the example device list of Figure 26, the host would assume indices 0x02, 0x03, and 0x2C are new devices and request capabilities for all these devices. This approach is inherently inefficient, since the next time a device list update occurs, it will repeat capability requests to devices it already knew about. For example, if the example system of Figure 26 received another device list update with the data shown in Figure 28 (an example device list update based on the system of Figure 26), the method described above would request capabilities of indices 0x02, 0x03, 0x06, and 0x2C. This is valid, but inefficient since the host already had the information for devices 0x02, 0x03, and 0x2C from the previous device list update notification. [00208] An alternate approach is for the host to store its own local copy of the
64-bit device list. On each subsequent device list update, the host can filter out device indices that it already has capabilities information for by comparing it against its own local copy. For example, the example of Figure 26 would result in device capabilities being requested of index 0x02, 0x03, and 0x2C. When the next device list update occurs and the host retrieves the device list shown in Figure 28, it would recognize that the only new device added is index 0x06 and that capabilities do not need to be re- requested for the others.
[00209] To further enhance processing efficiency, both 64-bit tables do not need to be read if the host is only concerned about HRRX devices or only HRTX devices. In this case, the host may process only the bit table of interest and ignore the other table. [00210] Figure 142 illustrates one embodiment of the bitmap device identification. The process is performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both. [00211] Referring to Figure 142, the process begins by processing logic storing the one or more bit maps in a first bank of memory (processing block 14201) and processing logic storing device capability information in a second bank of memory separate from the first bank of memory (processing block 14202). In one embodiment, one or more bitmaps are stored as 24 registers that operate as 3 64-bit bitfields. In one embodiment, the access of these memory banks is through an I2C bus. [00212] Subsequently, processing logic accesses the first bank of memory to obtain one or more bitmaps that map each bit location in the bitmap to an index value, where one index value is assigned to each remote wireless media device of a wireless network in a wireless communication system (processing block 14203). [00213] Next, processing logic examines the bitmap(s) and determines at least one characteristic of a remote wireless media device and a device identifier that identifies the remote wireless media device in the wireless network based on bit position in the one or more bitmaps (processing block 14204).
[00214] Using the information obtained from the bitmap(s) based on bit position therein, processing logic selects, based on information specified in the one or more bitmaps, one or more of the remote wireless media devices in the wireless network for which to obtain device specific information (processing block 14205) and obtains the device specific information from the second bank of memory (processing block 14206). In one embodiment, the processing logic selects, based on information specified in the one or more bitmaps, the one or more of the remote wireless media devices by comparing the one or more bitmaps with a previously received and stored version of the one or more bitmaps to identify which bit locations in the one or more bitmaps are different, and filtering out, based on results of comparing the one or more bitmaps to the previously received and stored version, device indices for which device specific information has already been obtained. In one embodiment, the device specific information comprises device capabilities information.
[00215] In one embodiment, a first portion of the one or more bit maps is reserved for a first type of remote wireless device (e.g., a HRRX-capable only device) and a second portion of the one or more bit maps, different than the first portion, is reserved for a second type of remote wireless device (e.g., a HRTX-capable only device), where the first and second types of remote wireless device are different. In another embodiment, a third type of remote wireless device (e.g., a both HRRX-capable and HRTX-capable device) has a characteristic of both the first and second type of remote wireless device and has a device identifier in both the first and second portions of the one or more bit maps. In a fourth embodiment, a fourth type of remote wireless device (e.g., a neither HRRX-capable nor HRTX-capable device) has a characteristic of neither the first nor second type of remote wireless device and has a device identifier only in the third portions of the one or more bit maps.
Confirm Receipt of Device List
[00216] The last step of the device detection stage is for the host to confirm that the device list information has been read. In one embodiment, the transceiver will not update the device list again until the host confirms the receipt of the existing list. Stated another way, the transceiver will not notify the host of new device list changes, if previous device list changes are not acknowledged.
[00217] To acknowledge the receipt of a device list update, the host clears the
"DEVCAP RXD" flag of the status register (register bank 0xA4, offset 0x05) after reading the device list, and applicable supplemental information. To clear the "DEVCAP RXD" flag, the host writes the value 0x04 to register bank 0xA4, offset 0x06 (the status clear register). Figure 29 illustrates the host setting bit location 2 to '1' to clear status register bit location 2. [00218] Note that in one embodiment actions mentioned above in device detection stage should be performed prior to clearing the "DEVCAP RXD" bit. While the bit is set, the transceiver freezes the contents of the device list registers. After the bit is cleared, the transceiver may alter the data in the device list registers and it can no longer be assumed to reflect the state of the network (until the next time the transceiver asserts the "DEVCAP RXD" bit).
Capability Request
[00219] After completing the Device Detect stage, the host will have determined whether there are any new devices discovered on the wireless network. For each new device, the host can choose to send a capabilities request message to obtain additional information about that remote device. Figure 30 illustrates one embodiment of the capabilties request stage of discovery process. Referring to Figure 30, when performing the capabilties request, the host sends the capabilities request 3001 to the transceiver. In response to receiving the capabilities request 3001 from the host, the transceiver sends the capabilities request 3002 to the wireless network. After sending the capabilities request 3002, the transceiver sends an interrupt 3003 to the host indicating that the transmission has been completed, and thereafter, the host sends a clear interrupt 3004 to the transceiver to complete the capabilities stage of the discovery process.
[00220] In one embodiment, a capabilities request is made by utilizing the TX packet register bank OxAC. The appropriate payload follows the format described in Figure 5. So, for the capabilities request, the host constructs a payload message adhering to the structure depicted in Figure 31. The definition of each field is consistent with the definition listed in the WirelessHD specification for the corresponding message. The only field that is unique is the "Device Index" field which corresponds to the index described in the device detect process. [00221] Figure 32 illustrates the capabilities request message as it would appear in register bank OxAC (the I2C register bank). The portions of the register data that contain I C header information are the first three rows, whereas the actual payload is the remainder.
[00222] The capabilities request message includes a bus identifier (bus ID) that identifies the wireless device (e.g., WirelessHD device) in the wireless network. Packets are encapsulated with the bus ID and with the payload being the actual message. The use of the bus ID in Figure 31 provides the ability to read at the same memory region for multiple purpose/applications (e.g., there are different application or models that want to talk to disparate applications for different purposes). That is, the use of the bus ID allows for dispatch capability using the single physical interface that is between the host and the transceiver device and the same location in memory can be used at different times to store data for multiple wireless devices. Thus, the bus ID allows for packeting interface to be used in a memory protocol.
[00223] Once the Capabilities Request message is written to the transmit register bank OxAC, the transceiver is notified that a message is ready. This is accomplished by writing a value of 0x08 to control register bank 0xA4, offset 0x04. Figure 33 illustrates the host setting bit location 3 to '1' to indicate that TX data is ready for the transceiver. [00224] When the "TX READY" flag is asserted, the transceiver extracts the capabilities request from the register region. The transceiver then simultaneously asserts INTERRUPT pin 412 and the "TX DONE" status flag of register bank 0xA4, offset 0x05. Figure 34 illustrates location 4 is set to T by the transceiver after it finishes extracting the TX message. Until the transceiver indicates status of "TX DONE", the register contents of bank OxAC (the transmit bank) should remain unchanged.
[00225] To acknowledge receipt of the "TX DONE" flag and to clear
INTERRUPT pin 412, the host writes a value of 0x10 to register bank 0xA4, offset 0x06 (the status clear register). Figure 35 illustrates the setting bit location 4 to '1' to clear status register bit location 4.
[00226] In the Device Detection example of Figure 26, the capabilities request process would need to be performed three times, once for each device index (i.e.- 0x02, 0x03, 0x2C).
[00227] In one embodiment, the host should clear status flags promptly. Until the host clears a particular status flag, the transceiver cannot assume that the host is aware of the status change.
Capability Response
[00228] Figure 36 illustrates one embodiment of capability response stage of discovery process. Referring to Figure 36, the capabilities response stage of the discovery process begins with the transceiver receiving capabilities response 3601 from the wireless network. In response, the transceiver generates an interrupt 3602 (e.g., interrupt 412) to notify the host. Thereafter, the host reads the status register to determine the cause of interrupt 3603 and subsequently reads the receive message 3604 corresponding to the capabilities response. Thereafter, the host sends a clear interrupt signal 3605 to the transceiver to clear the interrupt and complete the capability response stage of the discovery process. When the transceiver receives a capabilities request from the host, the transceiver will obtain the requested information from the remote device. Once the transceiver gets the information from the network, it formulates an RX message in register bank 0xA8 consistent with the definition listed in Figure 5. So, for the Capabilities Response, the transceiver constructs a payload message adhering to the structure depicted in Figure 37. The definition of each field is consistent with the definition listed in the WirelessHD specification for the corresponding message. The only field that is unique is the "Device Index" field which corresponds to the index described in the device detect process of section 0.
[00229] The properly formatted message as it would appear in the I2C register bank (bank 0xA8) is shown in Figure 38. The portions of the register data that contain I2C header information are in the first three rows and the last row, whereas the actual payload is the remainder.
[00230] Note that, in one embodiment, using the properly formatted messages, the single physical interface between the host processor and the transceiver (as shown in Figure 4) provides for dispatch capability. That is, the host processor and the transceiver use the single physical interface to gain access to a memory (e.g., 4 banks of memory) that is reusable by the host processor and the transceiver to exchange data, particularly with respect to remote wireless devices (e.g., WirelessHD devices). The memory is reusable in that regardless of the application involved, data that is stored in the memory corresponding to one of the remote wireless devices is identified with the use of two identifiers (e.g., BusID and Device Index) that identifies the function of the message and the remote wireless device. Thus, the memory is not assigned to a particular message format or remote device. Information can be moved into the memory as long as the function (and hence, structure of the message packet) and wireless device index is identified. The host processor can notify the transceiver that data is available for it in memory using one of two options. As one option, the host processor can use the interrupt signal. The second option is to periodically poll the status register (Bank 0xA4, offset 0x05). All stimulus which would cause the interrupt signal to assert also corresponds to a bit getting set in the status register, as discussed in the paragraph below.
[00231] Once the Capabilities Response message is written to the receive register bank 0xA8, the transceiver notifies the host that the message is ready by simultaneously asserting interrupt pin 412 and the "RX READY" status flag of register bank 0xA4, offset 0x05. Note that a "Capabilities Response" never needs to be generated by a host system (only received) since the transceiver can automatically issue a "Capabilities Response" to remote devices from the information provided by the host during the initialization phase. Figure 39 illustrates Location 5 being set to T by the transceiver after it finishes writing to the RX bank.
[00232] To acknowledge receipt of the "RX READY" flag and to clear the
INTERRUPT pin, the host writes a value of 0x20 to register bank 0xA4, offset 0x06 (the status clear register). Figure 40 illustrates the host setting bit location 5 to '1' to clear status register bit location 5.
[00233] Note that the contents of the receive register bank (0xA8) should be read prior to clearing the "RX READY" bit. While the bit is set, the transceiver freezes the contents of the receive register bank. After the bit is cleared, the transceiver may alter the data in the receive registers.
[00234] Figure 143 is a flow diagram of one embodiment of a device discovery process for use in a wireless communication system. The process is performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both.
[00235] In one embodiment, the communication system in which the device discovery process occurs is a wireless communication system having an apparatus for communicating with WirelessHD devices in a wireless network, where the apparatus comprises a host processor; a transceiver; a physical interface coupling the host processor and the transceiver; and a memory accessible by the host processor and the transceiver to exchange information between the host processor and the transceiver. [00236] Referring to Figure 143, the process begins by processing logic in the transceiver discovering a remote wireless device in the wireless network (processing block 14301) and updates the list of devices in response to discovering the remote wireless device has been added to the wireless network (processing block 14302). [00237] Next, processing logic in the transceiver notifies the host processor of the remote wireless device (processing block 14303). In one embodiment, notifying the host processor of the remote wireless device comprises asserting an interrupt to the host processor. In another embodiment, notifying the host processor of the remote wireless device is performed through an indexed bitmap table resident in the memory. This may occur by asserting the interrupt or setting a bit in a status register (Bank 0xA4, offset 0x05). Thus, this bit indicates to the host that the list of devices is available. In response, the host processor accessing memory to obtain the indexed bitmap table, comparing the indexed bitmap table with a previously stored table to determine any changes, and sending a capabilities request from the host processor to the transceiver for the remote wireless device if the host processor determines the remote wireless device is new based on results of comparing the indexed bitmap table with a previously stored table.
[00238] Then, processing logic in the transceiver requests capabilities information from the remote wireless device prior to receiving a request from the host processor for the capabilities information (processing block 14304) and buffers the capabilities information before the capabilities information is requested by the host processor (processing block 14305).
[00239] At this point, after beginning to receive the capabilities information from the remote wireless device, processing logic in the transceiver receives a capabilities request from the host processor which requests the capabilities of the remote wireless device (processing block 14306).
[00240] Thereafter, processing logic in the transceiver provides access to the capabilities information (processing block 14307).
[00241] In one embodiment, receiving the capabilities request from the host processor comprises the host processor storing a capabilities request message in a first bank of the memory, the host process sending a control message to a second bank of the memory, the control message indicating to the transceiver that the information exists in the first bank for the transceiver, and the transceiver reading the capabilities request message from the first buffer. Connection Control
[00242] In order to appropriately establish streaming video/data between two wireless devices, a connection sequence is performed between the two devices. In one embodiment, the protocol is consistent with WirelessHD, which is the underlying technology of this interface. In one embodiment, the host processor and the transceiver use the memory banks to perform connection control, particularly for exchanging information for connection control information. More particularly, a first bank stores information being transferred from the host processor to the transceiver, and a second bank stores information being transferred from the transceiver to the host processor, to facilitate full-duplex communication of packet data between the host processor and the transceiver. In one embodiment, the full-duplex communication conforms to the WiHD packet structure. In one embodiment, the host processor is operable to store data in the first bank while the transceiver stores data in the second bank. [00243] In one embodiment, the information stored by the host processor into the first bank of memory includes a connect request message for use in a connection control process, and the information stored by the transceiver into the second bank of memory includes a connect response message for use in a connection control process. This is shown in Figure 144.
[00244] In one embodiment, the memory includes a third bank, different than the first and second banks, having audio-video information registers to store AV information obtained by the transceiver from the wireless network regarding one or more devices in the wireless network, and the transceiver stores a message (e.g., a Capabilities Response message) indicating that AV information associated with the one or more devices is available and stores the AV information (e.g., input format structure information) in the third bank for access by the host processor. This is shown in Figure 145.
[00245] The discussion below describes the connection control process in more detail.
[00246] Figure 41 illustrates one embodiment of the complete end-to-end message flow between a Sink and Source device for the connection and disconnection sequences. All connection control operations use the device indices generated as part of the device discovery process. Before connections can be established, the device discovery process described is performed. [00247] One embodiment of a corresponding state-machine of the connection control process is shown in Figures 42 and 43 and for Sink and Source connection control state-machines, respectively. In one embodiment, at any point in the state- machine, if the transceiver detects a failure, the transceiver indicates this to the host by issuing a "Feature Abort" command (opcode OxFFOO) to the host with an appropriate reason code. If the host receives a "Feature Abort" for a particular device, it returns the state variables back to the "IDLE" state for that connection. [00248] Figure 42 illustrates the sink host connection control state machine.
Referring to Figure 42, the state process of the sink host connection control starts at idle state 4201 and remains there until there is a connection request from the host or a remote connection request detected from a remote system on the wireless network. Note that the connection request can come from either the host that we are directly connected to or from a remote host on the wireless network. In response to a connect request, the state machine transitions from idle state 4201 to wait-for-connection- confirm state 4202. The state machine waits in wait-for-connection-confirm state 4202 until a connect response is detected, at which time the state machine transitions to wait- for-stream-start state 4203. If in idle state 4201 and a remote connect request is detected, the state machine transitions directly to wait-for-stream-start state 4203. At wait-for-stream-start state 4203, the sink host waits for an indication that the stream has started.
[00249] When the start of the stream detected, the state machine transitions from wait-for-stream-start state 4203 to connected state 4204. Once at connected state 4204, the state machine transitions to idle state 4201 if a disconnect request initiated by a remote host is detected. If at connect state 4204 and a disconnect request is issued by the host that is connected to the transceiver, the state machine transitions to wait-for- stream-stop state 4205. When a stream stop is detected, the state machine transitions from wait-for-stream-stop state 4205 to idle state 4201.
[00250] Figure 43 illustrates the source host connection control state machine.
Referring to Figure 43, the state process of the source host connection control starts at idle state 4301 and remains there until there is a connection request or a remote connection request detected. In response to a connect request, the state machine transitions from idle state 4301 to wait-for-connection-confirm state 4302. The state machine waits in wait-for-connection-confirm state 4302 until a connect response is detected, at which time the state machine transitions to wait-for-output-format(fmt)- response(resp) state 4303. If in idle state 4301 and a remote connect request is detected, the state machine transitions directly to wait-for-output-fmt-resp state 4303. At wait-for-output-fmt-resp state the source host waits until the output format response, and upon being received, the state machine transitions to wait-for-stream-start state 4204. At wait-for-stream-start state 4204, the source host waits for an indication that the stream has started.
[00251] When the start of the stream detected, the state machine transitions from wait-for-stream-start state 4303 to connected state 4305. Once at connected state 4305, the state machine transitions to idle state 4301 if a disconnect request initiated from a remote wireless device is detected. If in connect state 4305 and a disconnect request is issued by the host that is connected to the transceiver, the state machine transitions to wait-for-stream-stop state 4306. When a stream stop is detected, the state machine transitions from wait-for-stream-stop state 4306 to idle state 4301. [00252] The following discussion describes the connection control state flow in greater detail.
Connect Procedure
[00253] The transceiver host interface closely follows the connection sequence described in the WirelessHD specification. Figure 44 shows one embodiment of the end-to-end communication sequences which occurs to establish a connection between two devices. The "Connect Request" and "Connect Response" are bold-faced to highlight the fact that these messages are bi-directional and can be initiated from either the Sink or Source device. Figure 45 is a flow diagram of one embodiment of a wireless transceiver connect process. A portion is applicable only to a Source device and a portion applicable only to a Sink device, as indicated below. [00254] Referring to Figure 45, the process is performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both. The process begins with the source and sink devices disconnected at processing block 4501. Thereafter, processing logic test whether there has been a connection initiated (processing block 4502). If not, processing logic tests whether a remote connection has occurred (processing block 4503). If not, the process transitions to processing block 4502 where the process repeats. [00255] If processing logic determines a connection has been initiated at processing block 4502, the process transitions to processing block 4504 where processing logic of the source sends a connection request. Then processing logic tests whether there has been a connection response (processing block 4505). If not, the process repeats at processing block 4504 until a connection response is received. When one does occur, process transitions to processing block 4507. [00256] If processing logic determines a remote connection has occurred at processing block 4503, the process transitions to processing block 4506 where processing logic of the device receiving the connect request (a source or a sink) sends the connection response and the process transitions to processing block 4507 for source devices and transitions to processing block 4510 for sink devices. [00257] At processing block 4507, processing logic tests whether the input format is available in the A/V registers Bank OxAO, offset 0x21-0xFE. Processing logic reads Bank 0xA4, offset 3, location 3 shown in Figure 88 to determine if the Input Format is available. If not, the process at processing block 4507 repeats until the input format is ready. Once the input format is ready, processing logic sends the output format request (processing block 4508) and processing block checks whether the output format has been received (processing block 4509). If it has not, the process waits until the output format has been received, at which time the process transitions to processing block 4510. At processing block 4510, processing logic tests whether the start stream indication is provided by the transceiver. The start stream message indicates that the bandwidth to transmit the streaming content wirelessly is available. If the bandwidth is not available, the process repeats until the bandwidth for the stream is obtained. Once a stream start indication has been received, the sink and source are connected (processing block 4511) and the streaming content can be transmitted wirelessly. [00258] The flow begins from a "disconnected" state. The device must wait for an event, either triggered by a local event (i.e., user initiates a connection to a remote device) or by a remote connection request. Once this occurs, information is passed between the two devices to establish a suitable connection. The following sub-sections describe each operation of the flow diagram in greater detail. Connect Request
[00259] As indicated in Figure 45, the host issues a Connect Request message to initiate a connection to a remote device. In one embodiment, a connect request is initiated by utilizing the TX packet register bank OxAC. The appropriate payload follows the format described in conjunction with Figure 5. For the Connect Request, the host constructs a payload message adhering to the structure depicted in Figure 46. The definition of each field is consistent with the definition listed in the WirelessHD specification for the corresponding message. The only field which is unique is the "Device Index" field which corresponds to the index described above in conjunction with the device detect process.
[00260] The transceiver makes the input format information of one remote device available to the (Source) host via direct register access (bank OxAO). To ensure that the input format data stored in the register bank corresponds with the current connecting device, the "RF" (Read Format) bit is set to '1' when initiating a connection from a Source host. Figure 47 illustrates a connect request message as it would appear in the TX (OxAC) or RX (0xA8) register bank I2C register bank. The portions of the register data that contain I2C header information are in the first three rows and the last row, whereas the actual payload is the remainder.
[00261] Once the Connect Request message is written to the transmit register bank OxAC, the host notifies the transceiver that the message is ready to be sent. In one embodiment, this is accomplished by the host writing a value of 0x08 to control register bank 0xA4. Figure 48 illustrates the host setting bit location 3 to '1' to indicate that TX data is ready for the transceiver.
[00262] When the "TX READY" flag is asserted, the transceiver extracts the
Connect Request from the register region. It then simultaneously asserts INTERRUPT pin 412 and the "TX DONE" status flag of register bank 0xA4 (Figure 76B), offset 0x05. Figure 49 illustrates Location 4 being set to T by the transceiver after it finishes extracting the TX message. Until the transceiver indicates status of "TX DONE", the register contents of bank OxAC (the transmit bank) are not altered. [00263] To acknowledge receipt of the "TX DONE" flag and to clear
INTERRUPT pin 412, the host writes a value of 0x10 to register bank 0xA4, offset 0x06 (the status clear register). Figure 50 illustrates the host setting bit location 4 to '1' to clear status register bit location 4. [00264] Figure 45 also indicates that the connection can be initiated by the remote device, rather than the local host device. The process flow of a remotely initiated Connect Request is similar to the flow described above. The transceiver populates the receive register bank (0xA8) as shown in Figure 47 and then notifies the host that the message is ready by simultaneously asserting interrupt pin 412 and the "RX READY" status flag of register bank 0xA4, offset 0x05. Figure 51 illustrates Location 5 being set to T by the transceiver after it finishes writing to the RX bank. [00265] To acknowledge receipt of the "RX READY" flag and to clear the
INTERRUPT pin 412, the host writes a value of 0x20 to register bank 0xA4, offset 0x06 (the status clear register). Figure 52 illustrates the host setting bit location 5 to '1' to clear status register bit location 5.
[00266] The host can now parse and use the information contained in the connect request to prepare a connection and issue an appropriate response.
Connect Response
[00267] When a Connect Request message is received from the transceiver, the host responds to the sender of the Connect Request with an appropriate Connect Response message as indicated in Figure 45. A Connect Response message can be generated by utilizing the TX packet register bank OxAC. The appropriate payload follows the format described in conjunction with Figure 5. For the Connect Response, the host constructs a payload message adhering to the structure depicted in Figure 53. The definition of each field is consistent with the definition listed in the WirelessHD specification for the corresponding message. The only field which is unique is the "Device Index" field which corresponds to the index described above in conjunction with the device detect process.
[00268] Figure 54 illustrates Connect Response message as it would appear in the TX(OxAC) or RX(0xA8) register bank (I2C register bank). The portions of the register data that contain I2C header information are the first three rows, whereas the actual payload is in the remaining rows.
[00269] The host notifies the transceiver that the message is ready to be sent by observing basic transmit handshaking rules outlined in conjunction with Figure 48- Figure 50. [00270] It is also possible to receive a Connect Response message from a remote device as shown in Figure 45. The handling is similar to the flow described above and the description of remote vs. local initiated messages discussed herein. The transceiver populates the receive register bank (0xA8) as shown in Figure 54. The portions of the register data that contain I C header information are in the first three rows and the last row, whereas the actual payload is the remainder. It will then follow the same receive handshaking protocol as shown in Figure 51 - Figure 52.
Output Format Request
[00271] Once both sides involved in a connection sequence are aware that a connection is being attempted (via the Connect Request/Response exchange described above), the Source host is ready to send the output format notification. If input format information is requested during the connect control sequence, the transceiver refreshes the input format information in the register bank. This is discussed in more detail below. Once it successfully refreshes the input format information, it notifies the host by simultaneously asserting interrupt pin 412 and the "INPUT FORMAT RXD" status flag of register bank 0xA4, offset 0x05. Figure 55 illustrates Location 3 being set to T by the transceiver after it finishes writing the input format data. [00272] The host clears the "INPUT FORMAT RXD" flag once this status is detected since the transceiver will not alter the input format register data until it is specifically requested to do so by the host. To clear the status and interrupt pin 412, the host writes a value of 0x08 to register bank 0xA4, offset 0x06 (the status clear register). Figure 56 illustrates the host setting bit location 3 to '1' to clear status register bit location 3.
[00273] With the input format information available in the AVC information register bank (bank OxAO), the Source host can access this information to make a determination about the appropriate output format to establish between the Source and Sink devices. Once this determination is made, the Source issues an appropriate Output Format Request message as shown in the flow diagram of Figure 45. A Connect Response message can be generated by utilizing the TX packet register bank OxAC. The appropriate payload follows the format described in conjunction with Figure 5. For the Output Format Request, the host constructs a payload message, referred to as the Output Format Request message adhering to the structure depicted in Figure 57. The definition of each field is consistent with the definition listed in the WirelessHD specification for the corresponding message. The only field which is unique is the "Device Index" field which corresponds to the index described above in conjunction with the device detect process.
[00274] Figure 58 illustrates Output Format Request message as it would appear in the TX(OxAC) or RX(0xA8) register bank (I2C register bank). The portions of the register data that contain I2C header information are in the first three rows and the last row, whereas the actual payload is the remainder. To clear the status and the interrupt pin, the host writes a value of 0x40 to register bank 0xA4, offset 0x06 (the status clear register).
Output Format Response
[00275] According to the WirelessHD specification, there are two situations in which Output Format data is sent by the Source; 1) to establish a connection between two devices, and 2) to update settings of an existing connection. During connection control operations, the Source-side transceiver automatically generates an Output Format Response on behalf of the Sink host based on the information it receives in the Output Format Request, Input Format information, and the ability to obtain bandwidth from the wireless network. After reviewing these pieces of information, the transceiver generates the appropriate Output Format Response message as indicated in Figure 45. An Output Format Response message can be generated by utilizing the TX packet register bank OxAC. The appropriate payload follows the format described in conjunction with Figure 5. For the Output Format Response, the host constructs a payload message, referred to as the Output Format Response message adhering to the structure depicted in Figure 59. The definition of each field is consistent with the definition listed in the WirelessHD specification for the corresponding message. The only field which is unique is the "Device Index" field which corresponds to the index described above in conjunction with the device detect process. [00276] Figure 60 illustrates Output Format Response message as it would appear in the TX(OxAC) or RX(0xA8) register bank (I2C register bank). The portions of the register data that contain I2C header information are in the first three rows, whereas the actual payload is in the remaining rows. [00277] The source transceiver will populate the receive register bank (0xA8) as shown in Figure 60. The portions of the register data that contain I C header information are in the first three rows and the last row, whereas the actual payload is the remainder. It then follows the same receive handshaking protocol as in Figure 51- Figure 52.
[00278] Note the "Result Code" field of Figure 59. It is possible that a particular
Output Format requested by the Source is denied due to wireless bandwidth restrictions or other limitation. For this reason, the Source host is prepared to re-negotiate a different Output Format if a requested Format is denied.
Connection Complete
[00279] Once both sides of a connection agree upon a common Output Format setting, the Source transceiver sends a Start Stream Notify message to both the Source and the Sink hosts. Figure 61 illustrates a Payload structure of a Start Stream Notify message. The definition of each field is consistent with the definition listed in the WirelessHD specification for the corresponding message. The only field which is unique is the "Device Index" field which corresponds to the index described above in conjunction with the device detect process.
[00280] Figure 62 illustrates Start Stream Notify message as it would appear in the RX(0xA8) register bank. The portions of the register data that contain I2C header information are in the first three rows and the last row, whereas the actual payload is the remainder.
[00281] After the transceiver writes this message to bank 0xA8, the transceiver asserts the "RX READY" bit of the control bank 0xA4, offset 0x05. The host must then follow the same receive handshaking protocol as in Figure 51 - Figure 52. At this point, the host can consider the connection successful.
Disconnect Procedure
[00282] Figure 63 shows the end-to-end communication sequences which must occur to disconnect a connection between two devices. The "Disconnect Indication" is bold-faced to highlight the fact that this message is bi-directional and can be initiated from either the Sink or Source device. Figure 64 is a flow diagram of one embodiment of a wireless transceiver disconnect process. [00283] The flow begins from a "connected" state. The device waits for an event, either triggered by a local event (i.e.- user initiates a disconnect to a remote device), by a remote disconnect request, or if the transceiver itself detects a wireless event that requires it to intervene (i.e.- unexpected loss of device on the wireless network). Once this occurs, information is passed between the two devices to perform a mutual disconnection of the AV stream. The following sub-sections describe each step of the flow diagram in greater detail.
Clearing Connection
[00284] As indicated in Figure 63, the Source or Sink host issues a Disconnect
Notify message to initiate a disconnection from a remote device. This is accomplished by utilizing the TX packet register bank OxAC. The appropriate payload follows the format described above in conjunction with Figure 5. For the Disconnect Notify, the host constructs a payload message adhering to the structure depicted in Figure 65. The definition of each field is consistent with the definition listed in the WirelessHD specification for the corresponding message. The only field which is unique is the "Device Index" field which corresponds to the index described in the device detect process of section 0.
[00285] Figure 66 illustrates Disconnect Notify message as it would appear in the TX(OxAC) or RX(0xA8) register bank (the I2C register bank). The portions of the register data that contain I2C header information are in the first three rows and the last row, whereas the actual payload is the remainder.
[00286] Once the Disconnect Notify message is written to the transmit register bank OxAC, the host notifies the transceiver that the message is ready to be sent. This is accomplished by writing a value of 0x08 to control register bank 0xA4, offset 0x04. Figure 67 illustrates the host setting bit location 3 to ' 1 ' to indicate that TX data is ready for the transceiver.
[00287] When the "TX READY" flag is asserted, the transceiver extracts the
Connect Request from the register region. It then simultaneously asserts INTERRUPT pin 412 and the "TX DONE" status flag of register bank 0xA4, offset 0x05. Figure 68 illustrates Location 4 being set to T by the transceiver after it finishes extracting the TX message. Until the transceiver indicates status of "TX DONE", the register contents of bank OxAC (the transmit bank) is not be altered. [00288] To acknowledge receipt of the "TX DONE" flag and to clear the
INTERRUPT pin, the host writes a value of 0x10 to register bank 0xA4, offset 0x06 (the status clear register). Figure 69 illustrates the host setting bit location 4 to '1' to clear status register bit location 4.
[00289] Figure 64 also indicates that the connection can be initiated by the remote device, rather than the local host device. The process flow of a remotely initiated Connect Request is similar to the flow described above. The transceiver populates the receive register bank (0xA8) as shown in Figure 47. It then notifies the host that the message is ready by simultaneously asserting INTERRUPT pin 412 and the "RX READY" status flag of register bank 0xA4, offset 0x05. Figure 70 illustrates Location 5 being set to T by the transceiver after it finishes writing to the RX bank. [00290] To acknowledge receipt of the "RX READY" flag and to clear
INTERRUPT pin 412, the host writes a value of 0x20 to register bank 0xA4, offset 0x06 (the status clear register). Figure 71 illustrates the host setting bit location 5 to '1' to clear status register bit location 5.
Disconnect Complete
[00291] When the Source transceiver detects a Disconnect Notify message, it initiates a bandwidth release process. When this process completes, the Source transceiver sends a Stop Stream Notify message to both the Source and the Sink hosts.
This message follows the payload structure depicted in Figure 72. The definition of each field is consistent with the definition listed in the WirelessHD specification for the corresponding message. The only field which is unique is the "Device Index" field which corresponds to the index described above in conjunction with the device detect process.
[00292] Figure 73 illustrates Stop Stream Notify message as it would appear in the RX(0xA8) register bank (I C register bank). The portions of the register data that contain I2C header information are in the first three rows and the last row, whereas the actual payload is the remainder.
[00293] After the transceiver writes this message to bank 0xA8, the transceiver asserts the "RX READY" bit of the control bank 0xA4, offset 0x05. The host then follows the same receive handshaking protocol as in Figure 70 - Figure 71. At this point, the host can consider the disconnect complete. Device Control
[00294] Device control permits high-level control over any device in a
WirelessHD network initiated by any of the constituent devices in the network. The device control messages are sent/received on the same RX/TX packet medium that device discovery and connection control messages use. A primary difference is that the function type for device control messages is 0x01, whereas it is 0x00 for device discovery and connection control messages. Figure 74 illustrates Payload structure of a Device Control message. The opcode and parameters correspond to those described in the WirelessHD specification.
[00295] Figure 75 illustrates a Device Control message as it would appear in the
RX(0xA8) or TX(OxAC) register bank. The portions of the register data that contain I2C header information are in the first three rows and the last row, whereas the actual payload is the remainder.
Re2ister Banks
[00296] In one embodiment, the wireless communication system includes an apparatus to communicate with remote wireless devices (e.g., WirelessHD devices) in the wireless network. The apparatus comprises: a host processor having an I2C interface; a transceiver having an I2C interface; a physical interface coupling the host processor and the transceiver, the physical interface comprising an I C bus coupled to the I2C interface of both the host processor and the transceiver; and multiple separate banks of memory in the transceiver and accessible by the host processor and the transceiver to exchange information between the host processor and the transceiver, where the host processor accesses the memory banks via its I2C interface. [00297] In one embodiments, the multiple memory banks comprise: a first bank to store information being transferred from the host processor to the transceiver; a second bank to store information being transferred from the transceiver to the host processor; a third bank to store control registers to control interactions between the host processor and the transceiver; and a fourth bank to store audio- video information registers to store information obtained by the transceiver from the wireless network regarding one or more devices in the wireless network and for use by the host processor. In one embodiment, one or more of the control registers indicate when communications are ready and in which memory locations in the banks the data may be read or written to. In one embodiment, the third bank stores one or more bitmaps that provide information on a device list of devices in the wireless network. In one embodiment, the four banks of memory are accessed through the SDA and CLK lines (Figure 4). This is shown in Figure 76 A where the I2C bus (SDA and elk) runs between two I2C interfaces, I2C master controller 7601 and I2C slave controller 7612. The reset and interrupt lines have not been shown to avoid obscuring the invention. CPU 7620 interfaces to the four blocks of memory through direct memory bus 7621, while slave controller 7612 interfaces the other sides of the memory banks to the I2C bus (and the host processor). The host processor places the capabilities information as above described in the AVC information registers. The Sink side host places the Input Format in the AVC information registers, whereas the Source side host reads the Input Format from the AVC information registers.
[00298] In one embodiment, WirelessHD transceiver exposes four register banks to the host system to control and communicate on the wireless network. Figure 76B illustrates one embodiment of the register blocks. Referring to Figure 76B, the four register blocks comprise AVC information registers 7601, control registers 7602, receive registers 7603 and transmit registers 7604. In one embodiment, each of the banks have a unique I2C device address (OxAO-OxAC) to distinguish the bank and each of the banks are 256 bytes deep allowing for the standard 8-bit addressing mode of I2C. Each of these will be described in more detail below.
[00299] Note that use of bank separation of I2C information is particularly useful. It allows the host system to optimize interference to the radio and optimizes/reduces memory requirements of the whole system. More specifically, the host accesses these banks through the same I2C interface. The memory requirements are reduced by allowing contextual information to be stored in the AVC information registers bank and does not have to be passed on to the other entity. For example, the transceiver can have information about a wireless device in the wireless network stored in the AVC information registers and then can notify the host system that the information is there, instead of sending the information to the host itself. The host thereafter can access the information directly and only the portions that are applicable to that specific host. In one embodiment, the transceiver notifies the host at the same time the information being put in the AVC registers. Therefore, the host can optimize what they need to look at and if the host does not need to access any of the information in the memory, there is no communication bandwidth wasted in providing access to the information for the host.
AVC Information Bank (OxAO/OxBO)
[00300] The AVC Information registers constitute a 256 byte region which is used to store information that does not change or rarely changes during the course of normal operation. As a result, this section can be useful to the host to retrieve data on an as-needed basis. Figure 77-80 illustrate Register map of AVC Info Registers. The registers in this bank would be understood by those skilled in the art. Figure 81 illustrates the Bit-description of register 0x06. Figure 82 illustrates the Bit-description of register 0x07. Figure 83 illustrates the Bit-description of register 0x22.
Control Bank (0xA4/0xB4)
[00301] The control register space is a 256 byte region that is used to control interactions between the Host and transceiver. I2C is a Master/Slave interface so the transceiver cannot use the bus itself to throttle the Host communications. As a result, the value of specific registers in this register space are used to indicate when communications are ready and in which sections of the I2C register space the data can be read or written to. Figure 84 illustrates Control Register space format. The following will describe these registers.
Reset Register
[00302] The reset register is used to cause the system to reset. There are two reset types available to the developer, namely software reset and hardware reset. A software reset causes the system software to invoke the sequences to re-initialize the embedded software code. A hardware reset causes the software to assert a hardware signal which causes the hardware (and software) to reset. Figure 85 illustrates a Field description of one embodiment of a Reset register. Referring to Figure 85, the fields may be sent as follows:
CLR_INPUT_FORMAT - write '1' to clear input format buffer CLR_TX - write '1' to clear transmit register space CLR_RX - write ' 1 ' to clear receive register space SW_RST - write ' 1 ' to invoke software reset HW RST - write '1' to invoke hardware reset
Power Mode
[00303] The power mode register makes it possible to override the normal operational mode of the wireless system. Increasing the power savings operational mode can cause a degradation of the performance on the wireless link. Figure 86 illustrates Field description of Power Mode register. Referring to Figure 86, the PWR_M0DE field may be set as follows: PWR_M0DE - OO' = Full
Ol' = Wake
'10' = Sleep
'11' = Standby
Interface Control
[00304] The interface control register makes it possible to configure the behavior of the Host interface with the transceiver. Figure 87 illustrates field description of
Interface Control register. Referring to Figure 87, the RST_POL, INT_POL and
BAUD fields may be set as follows:
RST_POL - '0' = active high
' 1 ' = active low INT_POL - '0' = active high
' 1 ' = active low BAUD - '00' = 100kHz
'01' = 40OkHz
'10' = 3.4MHz
'11' = Reserved Ready State
[00305] The ready state register is a read-only register that the Host can use to get high-level state information about the status of the wireless device. Figure 88 illustrates a field description of Ready register. Fields in the Ready register may be set as follows:
INPUT_FORMAT_READY - '0' = input format is not populated on this device
'1' = input format is populated on this device
DEVCAP_READY - '0' = device capabilities are not ready on this device
'1' = device capabilities are ready on this device WIHD_READY - '0' = WiHD is off
'l' = WiHD is on WIHD_LOADED - '0' = WiHD chip is undergoing reset
' 1 ' = WiHD chip is ready to take commands
Host Control
[00306] The host control register is a write-only register that makes it possible for the Host to invoke various operations on the transceiver. In order to invoke any operation controlled by this register, a logic ' 1 ' is written to the corresponding bit location. Figure 89 illustrates a field description of Host Control register. Fields in the
Host Controls may be set as follows:
RX_D0NE - '1' indicates that the Host has finished reading the data in the RX registers.
TX_READY - '1' indicates there is data waiting for the transceiver in the TX registers.
INPUT_FORMAT_DONE - '1' indicates that the Host finished writing to Input
Format register space. Applies only to Sink. Source reserves this bit. DEVCAP_DONE - '1' indicates that the Host finished writing to Device Capabilities region of register space. INIT_WIHD - '1' causes transceiver to activate wireless operations. Status
[00307] The status register is a read-only register that notifies the Host of an asynchronous event that needs to be serviced. In one embodiment, any bit in the state of logic ' 1 ' indicates that the event associated with the bit needs to be serviced. Whenever any bit is non-zero, the hardware interrupt pin to the Host will also assert. In one embodiment, status registers cannot be cleared by the Host by writing to this register. Bits in this register can only be cleared by writing to the Clear register (0x06). Figure 90 illustrates a field description of Status register. Fields in the Host Controls may be set as follows:
RX_READY - ' 1 ' indicates that data in the RX registers needs to be serviced by Host. TX_DONE - T indicates that transceiver finished servicing data in TX registers. INPUT_FORMAT_RXD - T indicates that the transceiver finished receiving Input
Format information from a remote Sink device and it is now ready in the register space. Applies only to Source. Sink reserves this bit. DEVCAP_RXD - '1' indicates that the transceiver received an update to device capabilities list. WIHD_0N - ' 1 ' indicates that the transceiver finished initializing WiHD and is fully operational.
CHIP_LOAD - T indicates that the transceiver finished reset sequence and is ready to accept commands. When this bit is asserted, the host should read register 0x07 to detect any system issues.
Clear
[00308] The Clear register is a write-only register which allows the Host to clear interrupt sources listed in register 0x05, the status register. Figure 91 illustrates a field description of Clear register. Fields in the Host Controls may be set as follows: CLR_RX_READY - '1' clears RX_READY bit (register 0x05). CLR_TX_DONE - '1' clears TX_DONE bit (register 0x05).
CLR_INPUT_FMT_RXD - '1' clears INPUT_FORMAT_RXD bit (register 0x05). CLR_DEVCAP_RXD - '1' clears DEVCAP_RXD bit (register 0x05). CLR_WIHD_ON - '1' clears WIHD_0N bit (register 0x05). CLR_WIHD_LOAD - '1' clears WIHD_ONLINE bit (register 0x05). System Status
[00309] The system status register is a read-only register that notifies the Host of any system level failures. Whenever a failure occurs, the system will assert the "WiHD Load" bit in the status (0x05) register. At that time, the Host monitors the system status register for additional details. Figure 92 illustrates a field description of System status register. Fields in the Host Controls may be set as follows: MEM0RY_F AILURE - ' 1 ' indicates that a memory failure has occurred. AVC_F AILURE - T indicates that an error occurred in the AVC subsystem. MAC_F AILURE - '1' indicates that an error occurred in the MAC subsystem. RADIO_F AILURE - ' 1 ' indicates that an error occurred in the radio hardware. DRIVER_F AILURE - T indicates that an error occurred in a peripheral driver.
Devcap Table
[00310] The devcap table is constructed of three 64-bit bitmaps which provide information on the device list stored within the transceiver hardware. The Host can use the information contained in these bitmaps to determine which devices, if any, to filter in obtaining device capabilities information of remote devices. Figure 93 illustrates a Bit-map layout of Devcap HRRX registers.
[00311] Each time a "DEVCAP RXD" interrupt occurs, the Host reads registers
0x08-0x0F to obtain the device index of all wireless devices capable of receiving high- rate data. This bit-map indicates a logic ' 1 ' for each of the 64 entries in the device list of the transceiver which are HRRX capable. For example, if the 64-bit map was read as, "0x0000000000080014", this immediately indicates that there are 3 valid entries in the device list. The entries correspond to index 19, 4, and 2 of the transceiver's internal device list. If the Host needs to obtain the device capabilities for any of these entries, requests this information from the transceiver using the packet registers. Figure 94 illustrates a Bit-map layout of Devcap HRTX registers.
[00312] The registers (0x10-0x17) can be used to determine which device indices are HRTX capable. This bit- map will indicate a logic ' 1 ' for each of the 64 entries in the device list of the transceiver which are HRTX capable. Note, this bit-map needs to be used in conjunction with the "Devcap HRRX" bit-map. It is possible for a device index to represent a device capable of both HRRX and HRTX. Figure 95 illustrates a Bit-map layout of Device Index registers. [00313] The registers (0xl8-0xlF) indicate all devices in the network regardless of whether it is HRTX capable, HRRX capable, both, or neither. This table is useful when a host is trying to ascertain the general state of the wireless network or when looking for devices that include systems that have neither HRTX or HRRX capabilities. [00314] In one embodiment, the devcap table is a particularly important array since addressing any device on the wireless network is based on the index entry in the devcap table array. For example, if there are three devices discovered on the wireless network, three corresponding entries will be flagged in the devcap table. In order to address any of those devices, the host system must use the index into the table to address that specific device.
Wireless Control [00315] Reserved
SoC S/W Version
[00316] The SoC system software which resides on the digital chip of the
WirelessHD radio makes its version available for read access. Figure 96 illustrates the SoC version label resides in the Control register bank (0xA4), offsets 0xF7-0xFB. Figure 97 illustrates a Bit-description of register 0xF7.
System Tick
[00317] The System Tick registers are comprised of four registers that are concatenated to form a 32-bit system clock value of the transceiver. This value is stored as a little-endian value with the least significant byte residing in register OxFC and the most significant byte residing in register OxFF. Figure 98 illustrates System Tick registers reside in the Control register bank (0xA4), offsets OxFC - OxFF. The tick registers are updated approximately every half-second. It is useful for diagnostics and also can be used as a system heartbeat monitor. Receive (0xA8/0xB8)/Transmit (OxAC/OxBC) Bank
[00318] The receive/transmit register space is a 256 byte region that is provided to the host as a receive buffer. That is, when the transceiver needs to send packetized information to the Host, it places the packet in this register space and asserts a control flag to the Host. The format of this register space has the capability to handle fragmented data. This makes the use of this register space versatile providing a wide range of possible applications. Figure 99 illustrates a Register space format of receiver. These registers are described in more detail below.
Bus ID
[00319] The Bus ID indicates the recipient application to receive the payload message. Though a major purpose of the TX/RX register banks is to convey AVC messages, the format has been designed for generic use. In one embodiment, bus ID definitions are as follows:
• GENERIC BUS = 0x00
• AVC BUS = 0x01
• MAC BUS = 0x02
• DEBUG BUS = 0x04
Length
[00320] The length field indicates the total number of payload bytes in this message. Due to header/checksum overhead, the maximum number of bytes possible is 252 bytes.
Sequence ID
[00321] The sequence field (address 0x02), which is a byte, is divided into two sections, a frame identifier and a sequence number as shown in Figure 100. The frame identifier indicates which frame of a fragment this packet is associated with. The sequence identifier indicates the sequential order of the fragment. These two fields allow a recipient to reconstruct fragmented data. In one embodiment, the fields may be set as follows: FRAME - OO' = first fragment '01 ' = middle fragment '10' = last fragment ' 11 ' = no fragment
SEQUENCE - indicates the sequential order of the fragmented data. Note that if a frame identifier of a packet is '11' (no fragment) this field is 'don't care'.
Payload
[[0000332222]] The payload data is application specific information. The I2C layer simply forwards this data.
Checksum
[00323] The checksum is a simple 8-bit checksum of the entire payload region of the packet. For example, if the payload data is: 0x1122334455667788, the checksum of this data is 0x65. The location of the checksum byte is at the end of the payload data.
Description of AVC Messages
[00324] The following contains a description of all AVC messages that can be issued by a host to the radio transceiver in one embodiment. The expected response, timeout scenario, and failure cases are described for each message.
Device Discovery Messages
Device Capabilities Request
[00325] Figure 101 illustrates a device capabilities message. This command issues a request to obtain capabilities information from a remote WirelessHD compliant device.
Input Parameters: Function Type - Indicates the function type of the opcode. This value is 'OxOO' to indicate the Connection Control function type. Device Index - Indicates the device index to request capabilities for. Opcode - The opcode corresponding to Capabilities Request. This value must be 0x0000 for Capabilities Request.
Requested Types - The requested types is a bit- field that indicates which capabilities should be provided by the remote device. By asserting one or more of the bits in this bit-field, the host can requested specific capabilities information from a remote device. The remote device will package the requested information in a series of "type-length- value" (TLV) packets which are packaged in the "Capabilities Response" message. Figure 102 illustrates field locations for the Requested Types bit-field. Total Length - Indicates the total number of octets used by the Capabilities Request message to send "type-length- value" (TLV) data. Currently, this is a reserved feature so this value should be set to "0".
Expected Response:
[00326] The expected response to this message is a Capabilities Response message. The remote host does not need to generate the Capabilities Response message since the transceiver on the remote side has already obtained all the necessary information from the host during the initialization process.
[00327] Figure 103 illustrates a capabilities response message. The parameters of the message are:
Function Type - Indicates the function type of the opcode. This value is 'OxOO' to indicate the Connection Control function type.
Device Index - Indicates the device index of the sender of the Capabilities Response message.
Opcode - The opcode corresponding to Capabilities Response. In one embodiment, this value is 0x0001.
Total Length - Indicates the total number of octets used by the Capabilities Response message to send "type-length- value" (TLV) data.
Type-Length- Value packets - A series of "type-length- value" packets are appended to the end of the Capabilities Response message. These correspond to the "Requested
Types" field in the Capabilities Request message. The numerical value of the "type" corresponds to the bit position of the requested type shown in Figure 102. For example, the type value "2" corresponds to MAC address whereas a type value of "3" corresponds to Input Format.
Timeout:
[00328] For a properly formatted Capabilities Request message, the transceiver responds with a Capabilities Response almost immediately. If, for some reason, the transceiver is unable to obtain the capabilities of the remote device, a Feature Abort message will be generated and sent to the host indicating a timeout. Figure 104 illustrates a Feature Abort message indicating a failure to obtain Capabilities Request information. The parameters of the message are:
Function Type - Indicates the function type of the opcode. This value is 'OxOO' to indicate the Connection Control function type.
Device Index - Indicates the device index of the remote unit that Capabilities are being requested from.
Opcode - The opcode corresponding to the Feature Abort message. This value is
OxFFOO.
Rejected Opcode - The opcode of the message that failed. In this case, the Capabilities
Request has failed, so the value is 0x0000.
Reason Code - This field will provide an indication of why the message has failed. In this case, a reason code of 0x06 will be issued to denote a timeout.
Failure Case Response:
[00329] A failure will be indicated by the transceiver with a Feature Abort message. The two possible causes of failure correspond to the following reason codes: Not in correct mode to respond (0x02) - If the message was sent before the transceiver was initialized, a Feature Abort message with this reason code will be issued. Invalid Operand (0x04) - If the device index or requested types field is invalid, a Feature Abort message with this reason code will be issued.
Connection Control Messages Connect Request
[00330] Figure 105 illustrates a Connect Request message. This command issues a request to establish a streaming connection to a remote WirelessHD compliant device.
Input Parameters:
Function Type - Indicates the function type of the opcode. This value is 'OxOO' to indicate the Connection Control function type.
Device Index - Indicates the device index to connect to.
Opcode - The opcode corresponding to Connect Request. This value is 0x0002.
Port - The port is the local identifier on the local host that the remote device must connect to. The host can use any scheme to assign local identifiers. Port numbering becomes critical in systems that can support multiple streams simultaneously.
VP - Indicates that the port identified in this message will carry video data.
AP - Indicates that the port identified in this message will carry audio data.
S - Indicates that the port identified in this message will function as a sink device.
RF - Indicates that the source device in this connection needs the Input Format information to be sent from the sink.
Total Length - Indicates the total number of octets used by the Connect Request message to send "type-length- value" (TLV) data. Currently, this is a reserved feature so this value should be set to "0".
Expected Response:
[00331] The expected response to this message is a Connect Response message.
This message is described in detail above.
Timeout:
[00332] For a properly formatted Connect Request message, the transceiver should responds with a Connect Response message. If, for some reason, the transceiver is unable to obtain the response of the remote device, a Feature Abort message will be generated and sent to the host indicating a timeout. Figure 106 illustrates a Feature Abort message indicating a failure to obtain a Connect Response. Its parameters are: Function Type - Indicates the function type of the opcode. This value is 'OxOO' to indicate the Connection Control function type.
Device Index - Indicates the device index of the remote unit that a connection is being attempted on.
Opcode - The opcode corresponding to the Feature Abort message. This value is
OxFFOO.
Rejected Opcode - The opcode of the message that failed. In this case, the Connect
Request has failed, so the value is 0x0002.
Reason Code - This field will provide an indication of why the message has failed. In this case, a reason code of 0x06 will be issued to denote a timeout.
Failure Case Response:
[00333] A failure will be indicated by the transceiver with a Feature Abort message. The two possible causes of failure correspond to the following reason codes: Not in correct mode to respond (0x02) - If the message was sent before the transceiver was initialized, a Feature Abort message with this reason code will be issued.
Invalid Operand (0x04) - If the device index field is invalid, a Feature Abort message with this reason code will be issued.
Connect Response
[00334] Figure 107 illustrates a Connect Response message. This command issues a confirmation response to establish a streaming connection to a remote WirelessHD compliant device. This message is only sent in response to a Connect Request message.
Input Parameters:
Function Type - Indicates the function type of the opcode. This value is 'OxOO' to indicate the Connection Control function type.
Device Index - Indicates the device index to send response to.
Opcode - The opcode corresponding to Connect Response. This value is 0x0003.
Result Code - This field indicates the result of the connection request. A value of "0" indicates success, whereas "1" indicates failure. Port - There are two ports associated with any connection - the logical port on the sink and the logical port of the source device. If the remote device indicated that the remote device is the sink device via the Connect Request message, then the recipient of the
Connect Request message should serve as the Source for this connection sequence. As a result, the Port specified in the Connect Request message should be returned in the
Connect Response as the Sink Port, and a numeric identifier should be generated by the local device as the Source Port.
VP - Indicates that the port identified in this message will carry video data.
AP - Indicates that the port identified in this message will carry audio data.
RF - Indicates that the source device in this connection needs the Input Format information to be sent from the sink.
Total Length - Indicates the total number of octets used by the Connect Response message to send "type-length- value" (TLV) data. Currently, this is a reserved feature so this value should be set to "0".
Expected Response:
None. No response is explicitly expected in response to a Connect Response message.
Timeout:
[00335] For a properly formatted Connect Response message, the transceiver should not need to provide any further feedback to the host to indicate a success condition. If, for some reason, the transceiver is unable to send the message to the destination, a Feature Abort message will be generated and sent to the host indicating a timeout. Figure 108 illustrates a Feature Abort message indicating a failure to send the
Connect Response. Its parameters are as follows:
Function Type - Indicates the function type of the opcode. This value is 'OxOO' to indicate the Connection Control function type.
Device Index - Indicates the device index of the remote unit that the message is being sent to.
Opcode - The opcode corresponding to the Feature Abort message. This value is
OxFFOO.
Rejected Opcode - The opcode of the message that failed. In this case, the Connect
Response has failed, so the value is 0x0003. Reason Code - This field will provide an indication of why the message has failed. In this case, a reason code of 0x06 will be issued to denote a timeout.
Failure Case Response:
[00336] A failure will be indicated by the transceiver with a Feature Abort message. The three possible causes of failure correspond to the following reason codes:
Not in correct mode to respond (0x02) - If the message was sent before the transceiver was initialized, a Feature Abort message with this reason code is issued.
Invalid Operand (0x04) - If the device index field is invalid, a Feature Abort message with this reason code will be issued.
Out of Sequence (0x07) - If the Connect Response is sent to a recipient that has not issued a Connect Request, the Out of Sequence reason code will be sent to the host.
Output Format Request
[00337] Figure 109 illustrates an Output Format Request message. This command issues a request to the transceiver to obtain wireless bandwidth to begin streaming data. This message is only valid from the Source device.
Input Parameters:
Function Type - Indicates the function type of the opcode. This value is 'OxOO' to indicate the Connection Control function type.
Device Index - Indicates the device index to establish stream to.
Opcode - The opcode corresponding to the Output Format Request message. This value must be 0x0007.
Result Code - This field is unused for the Output Format Request.
Port - There are two ports associated with any connection - the logical port on the Sink and the logical port of the Source device. The values of these fields and the determination of which device will perform Sink vs. Source role has already been established during the Connect Request/Response. This message must use values that were established at the time of the Connect Request/Response messages.
VP - Indicates that the port identified in this message will carry video data.
AP - Indicates that the port identified in this message will carry audio data. Total Length - Indicates the total number of octets used by the Output Format Request message to send "type-length- value" (TLV) data. As per the WirelessHD specification, the host needs to send video and/or audio information to the transceiver so that it can determine the appropriate bandwidth to reserve on the wireless channel.
Expected Response:
[00338] There are two responses that follow the Output Format Request message. The first is the Output Format Response message. This message will indicate whether the corresponding bandwidth associated with the request can be obtained. The result code will indicate success (0) or failure (1). If the bandwidth reservation fails, the host must issue a new Output Format Request to attempt to reserve stream bandwidth.
In order to increase the likelihood of success, the host may need to request lower resolution video or decreased resolution in audio.
[00339] Figure 110 illustrates an Output Format Response message. Its parameters are:
Function Type - Indicates the function type of the opcode. This value is 'OxOO' to indicate the Connection Control function type.
Device Index - Indicates the device index of the remote device to which a stream is being established.
Opcode - The opcode corresponding to Output Format Response. This value is
0x0008.
Result Code - This field indicates the result of the Output Format Request. A value of
"0" indicates success, whereas "1" indicates failure.
Port - There are two ports associated with any connection - the logical port on the Sink and the logical port of the Source device, he values of these fields and the determination of which device will perform Sink vs. Source role has already been established during the Connect Request/Response. This message must use values that were established at the time of the Connect Request/Response messages.
VP - Indicates that the port identified in this message will carry video data.
AP - Indicates that the port identified in this message will carry audio data.
[00340] Once the transceiver determines that sufficient bandwidth exists in order to establish a stream, the actual reservation process will be executed. When this successfully completes, a Stream Start message will be generated by the transceiver and sent to the host on both sides of the connection. [00341] Figure 111 illustrates a Stream Start Notify message. Its parameters are:
Function Type - Indicates the function type of the opcode. This value is 'OxOO' to indicate the Connection Control function type.
Device Index - Indicates the device index of the remote device to which a stream is being established.
Opcode - The opcode corresponding to Stream Start Notify. This value is 0x0005.
Result Code - This field indicates the result of the Stream Start Notify message. A value of "0" indicates success, whereas "1" indicates failure.
Stream Index - The transceiver assigns every stream with a unique index. This can be used by the host to uniquely identify the active streams, particularly if the host is capable of supporting multiple streams.
Port - There are two ports associated with any connection - the logical port on the Sink and the logical port of the source device. The values of these fields and the determination of which device will perform sink vs. source role has already been established during the Connect Request/Response. This message must use values that were established at the time of the Connect Request/Response messages.
VP - Indicates that the port identified in this message will carry video data.
AP - Indicates that the port identified in this message will carry audio data.
Total Length - Indicates the total number of octets used by the Stream Start Notify message to send "type-length- value" (TLV) data. Currently, this is a reserved feature so this value should be set to "0".
[00342] In general, the Stream Start message will not fail since it implies that the
Output Format Request succeeded. Though unlikely, it is possible that the Output
Format Request succeeds but then bandwidth becomes unavailable due to an unexpected reason. Should this occur, the Stream Start message will fail (via Result
Code). If this happens, the host issues a new Output Format Request message.
Timeout:
[00343] None. A timeout does not exist for the Output Format Request message.
A response will be available upon performing a bandwidth check.
Failure Case Response:
[00344] A failure will be indicated by the transceiver with a Feature Abort message. The three possible causes of failure correspond to the following reason codes: Not in correct mode to respond (0x02) - If the message was sent before the transceiver was initialized, a Feature Abort message with this reason code will be issued. Invalid Operand (0x04) - If the device index field is invalid, a Feature Abort message with this reason code will be issued. This message is also generated if the Port and VP/ AP information does not match the values that were set during the Connect Request/Response dialogue.
Out of Sequence (0x07) - If the Output Format Request message is sent by a device that is not the source, or is sent by a source that has not successfully undergone the Connect Request/Response dialogue, the Out of Sequence reason code is sent to the host.
Disconnect Notify
[00345] Figure 112 illustrates a Disconnect Notify message. This command notifies the remote device that the stream needs to be terminated.
Input Parameters:
Function Type - Indicates the function type of the opcode. This value is 'OxOO' to indicate the Connection Control function type.
Device Index - Indicates the device index to notify.
Opcode - The opcode corresponding to the Disconnect Notify message. This value is
0x0004.
Port - There are two ports associated with any connection - the logical port on the sink and the logical port of the source device. The values of these fields and the determination of which device will perform sink vs. source role has already been established during the Connect Request/Response. This message must use values that were established at the time of the Connect Request/Response messages.
VP - Indicates that the port identified in this message will carry video data.
AP - Indicates that the port identified in this message will carry audio data.
Expected Response:
[00346] The expected response of the Disconnect Notify message is the Stream
Stop message. This message is not generated by the remote host, but is issued by the transceivers once the streams are terminated. Figure 113 illustrates a Stream Stop message. Its parameters are:
Function Type - Indicates the function type of the opcode. This value is 'OxOO' to indicate the Connection Control function type.
Device Index - Indicates the device index of the remote device to which a stream is being established.
Opcode - The opcode corresponding to Stream Stop message. This value is 0x0006.
Result Code - This field indicates the result of the Stream Stop message. A value of
"0" indicates success, whereas "1" indicates failure.
Stream Index - The unique stream index was assigned during the Stream Start process.
If the host was tracking the active streams using this index, it can be used here to perform any necessary cleanup associated with this stream.
Port - There are two ports associated with any connection - the logical port on the sink and the logical port of the source device. These fields and which device will perform sink vs. source role have already been established during the Connect
Request/Response. This message must use values that were established at the time of the Connect Request/Response messages.
VP - Indicates that the port identified in this message will carry video data.
AP - Indicates that the port identified in this message will carry audio data.
Timeout:
[00347] For a properly formatted Disconnect Notify message, the transceiver does not provide any further feedback to the host to indicate a success condition. If, for some reason, the transceiver is unable to send the message to the destination, a Feature
Abort message will be generated and sent to the host indicating a timeout. Figure 114 illustrates a Feature Abort message indicating a failure to send the Disconnect Notify.
Its parameters are:
Function Type - Indicates the function type of the opcode. This value is 'OxOO' to indicate the Connection Control function type.
Device Index - Indicates the device index of the remote unit that the message is being sent to.
Opcode - The opcode corresponding to the Feature Abort message. This value is
OxFFOO. Rejected Opcode - The opcode of the message that failed. In this case, the Disconnect Notify has failed, so the value is 0x0004.
Reason Code - This field will provide an indication of why the message has failed. In this case, a reason code of 0x06 will be issued to denote a timeout.
Failure Case Response:
[00348] A failure will be indicated by the transceiver with a Feature Abort message. The three possible causes of failure correspond to the following reason codes:
Not in correct mode to respond (0x02) - If the message was sent before the transceiver was initialized, a Feature Abort message with this reason code will be issued.
Invalid Operand (0x04) - If the device index field is invalid, a Feature Abort message with this reason code will be issued. This message will also be generated if the Port and VP/ AP information does not match the values that were set during the Connect
Request/Response dialogue.
Out of Sequence (0x07) - If the Disconnect Notify message is sent by a host that is not currently connected, the Out of Sequence abort message will be issued.
Device Control Messages
[00349] Figure 115 illustrates a Device Control message. Device Control commands are largely treated as pass-through messages by the transceiver.
Input Parameters:
Function Type - Indicates the function type of the opcode. This value is 'OxOl' to indicate the Device Control function type.
Device Index - Indicates the device index to send message to.
Opcode - The opcode corresponding to the specific Device Control message to be sent.
The WirelessHD specification provides greater details on the available commands.
Param - The parameters associated with a specific Device Control message.
Expected Response:
[00350] None. It is possible for specific Device Control messages to have Timeout:
[00351] For a properly formatted Device Control message, the transceiver does not provide any further feedback to the host to indicate a success condition. If, for some reason, the transceiver is unable to send the message to the destination, a Feature Abort message will be generated and sent to the host indicating a timeout. Figure 116 illustrates a Feature Abort message indicating a failure of a Device Control message.
Its parameters are:
Function Type - Indicates the function type of the opcode. This value is 'OxOl' to indicate the Device Control function type.
Device Index - Indicates the device index of the remote unit that the message is being sent to.
Opcode - The opcode corresponding to the Feature Abort message. This value is
OxFFOO.
Rejected Opcode - The opcode of the message that failed.
Reason Code - This field will provide an indication of why the message has failed. In this case, a reason code of 0x06 will be issued to denote a timeout.
Failure Case Response:
[00352] A failure will be indicated by the transceiver with a Feature Abort message. The two possible causes of failure correspond to the following reason codes: Not in correct mode to respond (0x02) - If the message was sent before the transceiver was initialized, a Feature Abort message with this reason code will be issued. Invalid Operand (0x04) - If the device index field is invalid, a Feature Abort message with this reason code will be issued.
HDMI Pass-Through Messages
HDMI Pass-Through Request
[00353] Figure 117 illustrates a HDMI Pass-Through Request message. This command issues a request to provide a pass-through connection of HDMI messages between two WirelessHD compliant devices. Input Parameters:
Function Type - Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
Device Index - Indicates the device index to enable an HDMI Pass-Through link.
Opcode - The opcode corresponding to the HDMI Pass-Through Request. This value must be 0x0000.
PT - Indicates whether to enable (1) or disable (0) Pass-Through.
Expected Response:
[00354] The expected response to this message is an HDMI Pass-Through
Response message. This message is described in detail further below.
Timeout:
[00355] For a properly formatted HDMI Pass-Through Request message, the transceiver should respond with a HDMI Pass-Through Response message. If, for some reason, the transceiver is unable to obtain the response of the remote device, a Feature Abort message will be generated and sent to the host indicating a timeout. Figure 118 illustrates a Feature Abort message indicating a failure to obtain an HDMI Pass- Through Response. Its parameters include:
Function Type - Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
Device Index - Indicates the device index of the remote unit that the Pass-Through message could not be sent to.
Opcode - The opcode corresponding to the Feature Abort message. This value is OxFFOO.
Rejected Opcode - The opcode of the message that failed. In this case, the HDMI Pass-Through Request has failed, so the value is 0x0000.
Reason Code - This field will provide an indication of why the message has failed. In this case, a reason code of 0x06 will be issued to denote a timeout.
Failure Case Response:
[00356] A failure will be indicated by the transceiver with a Feature Abort message. The two possible causes of failure correspond to the following reason codes: Not in correct mode to respond (0x02) - If the message was sent before the transceiver was initialized, a Feature Abort message with this reason code will be issued. Invalid Operand (0x04) - If the device index field is invalid, a Feature Abort message with this reason code will be issued.
HDMI Pass-Through Response
[00357] Figure 119 illustrates an HDMI Pass-Through Response message. This command issues a confirmation response to establish a pass-through connection of HDMI messages between two WirelessHD compliant device. This message is only sent in response to an HDMI Pass-Through Request message.
Input Parameters:
Function Type - Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
Device Index - Indicates the device index to issue a response.
Opcode - The opcode corresponding to the HDMI Pass-Through Response. This value is 0x0001.
Result Code - This field indicates the result of the HDMI Pass-Through request. A value of "0" indicates success, whereas "1" indicates failure.
Expected Response:
[00358] None. No response is explicitly expected in response to a HDMI Pass-
Through Response message.
Timeout:
[00359] For a properly formatted HDMI Pass-Through Response message, the transceiver does not provide any further feedback to the host to indicate a success condition. If, for some reason, the transceiver is unable to send the message to the destination, a Feature Abort message will be generated and sent to the host indicating a timeout. Figure 120 illustrates a Feature Abort message indicating a failure to send the
HDMI Pass-Through Response. Its parameters are:
Function Type - Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type. Device Index - Indicates the device index of the remote unit that the original message was being sent to.
Opcode - The opcode corresponding to the Feature Abort message. This value is
OxFFOO.
Rejected Opcode - The opcode of the message that failed. In this case, the HDMI
Pass-Through Response has failed, so the value is 0x0001.
Reason Code - This field will provide an indication of why the message has failed. In this case, a reason code of 0x06 will be issued to denote a timeout.
Failure Case Response:
[00360] A failure will be indicated by the transceiver with a Feature Abort message. The three possible causes of failure correspond to the following reason codes:
Not in correct mode to respond (0x02) - If the message was sent before the transceiver was initialized, a Feature Abort message with this reason code will be issued.
Invalid Operand (0x04) - If the device index field is invalid, a Feature Abort message with this reason code will be issued.
Out of Sequence (0x07) - If the HDMI Pass-Through Response is sent to a recipient that has not issued a HDMI Pass-Through Request, the Out of Sequence reason code will be sent to the host.
EDID Request
[00361] Figure 121 illustrates a DID Request message. This command issues a request for EDID information from a Sink device.
Input Parameters:
Function Type - Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
Device Index - Indicates the device index to request EDID information from.
Opcode - The opcode corresponding to the HDMI Pass-Through Request. This value is 0x0002. Expected Response:
[00362] The expected response to this message is an EDID Response message.
This message is described in detail in section 0.
Timeout:
[00363] For a properly formatted EDID Request message, the transceiver should respond with an EDID Response message. If, for some reason, the transceiver is unable to obtain the response of the remote device, a Feature Abort message will be generated and sent to the host indicating a timeout. Figure 122 illustrates a Feature Abort message indicating a failure to obtain an EDID Response. Its parameters are:
Function Type - Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
Device Index - Indicates the device index of the remote unit that the Pass-Through message could not be sent to.
Opcode - The opcode corresponding to the Feature Abort message. This value is
OxFFOO.
Rejected Opcode - The opcode of the message that failed. In this case, the EDID
Request has failed, so the value is 0x0002.
Reason Code - This field will provide an indication of why the message has failed. In this case, a reason code of 0x06 will be issued to denote a timeout.
Failure Case Response:
[00364] A failure will be indicated by the transceiver with a Feature Abort message. The two possible causes of failure correspond to the following reason codes:
Not in correct mode to respond (0x02) - If the message was sent before the transceiver was initialized, a Feature Abort message with this reason code will be issued. This message will also be issued if the appropriate Pass-Through Request/Response handshake has not been established between the two devices.
Invalid Operand (0x04) - If the device index field is invalid, a Feature Abort message with this reason code will be issued.
EDID Response [00365] Figure 123 illustrates an EDID Response message. This command provides EDID information to a Source device. It is only sent when prompted by an EDID Request message.
Input Parameters:
Function Type - Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
Device Index - Indicates the device index to send EDID information to.
Opcode - The opcode corresponding to the HDMI Pass-Through Request. This value is 0x0003.
Result Code - This field indicates the result of the EDID request. A value of "0" indicates success, whereas "1" indicates failure.
Number of Blocks - Number of 128-octet EDID blocks are contained in this message.
Expected Response:
[00366] None. No response is explicitly expected in response to an EDID
Response message.
Timeout:
[00367] For a properly formatted EDID Response message, the transceiver doesn't provide any further feedback to the host to indicate a success condition. If, for some reason, the transceiver is unable to send the message to the destination, a Feature
Abort message will be generated and sent to the host indicating a timeout. Figure 124 illustrates a Feature Abort message indicating a failure to send the EDID Response. Its parameters are:
Function Type - Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
Device Index - Indicates the device index of the remote unit that the original message was being sent to.
Opcode - The opcode corresponding to the Feature Abort message. This value is
OxFFOO.
Rejected Opcode - The opcode of the message that failed. In this case, the EDID
Response has failed, so the value is 0x0003. Reason Code - This field will provide an indication of why the message has failed. In this case, a reason code of 0x06 will be issued to denote a timeout.
Failure Case Response:
[00368] A failure will be indicated by the transceiver with a Feature Abort message. The three possible causes of failure correspond to the following reason codes:
Not in correct mode to respond (0x02) - If the message was sent before the transceiver was initialized, a Feature Abort message with this reason code will be issued. This message will also be issued if the appropriate Pass-Through Request/Response handshake has not been established between the two devices.
Invalid Operand (0x04) - If the device index field is invalid, a Feature Abort message with this reason code will be issued.
Out of Sequence (0x07) - If the EDID Response is sent to a recipient that has not issued a HDMI EDID Request, the Out of Sequence reason code will be sent to the host.
Data Island Notify
[00369] Figure 125 illustrates a Data Island Notify message. This command provides EDID information to a Source device. It is only sent when prompted by an EDID Request message.
Input Parameters:
Function Type - Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
Device Index - Indicates the device index to send the Data Island packet to.
Opcode - The opcode corresponding to the Data Island Notify message. This value is
0x0004.
Port - There are two ports associated with any connection - the logical port on the sink and the logical port of the source device. These fields and which device will perform sink vs. source role have already been established during the Connect
Request/Response. This message uses values that were established at the time of the
Connect Request/Response messages.
VP - Indicates that the port identified in this message will carry video data.
AP - Indicates that the port identified in this message will carry audio data. Frame - Frame number that the Data Island Notify message should apply to. Total Length - Indicates the total number of octets used by the Data Island Notify message to send "type-length- value" (TLV) data.
Expected Response:
[00370] None. No response is explicitly expected in response to a Data Island
Notify message.
Timeout:
[00371] For a properly formatted Data Island Notify message, the transceiver does not need to provide any further feedback to the host to indicate a success condition. If, for some reason, the transceiver is unable to send the message to the destination, a Feature Abort message will be generated and sent to the host indicating a timeout. Figure 126 illustrates a Feature Abort message indicating a failure to send the
Data Island Notify. Its parameters are:
Function Type - Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
Device Index - Indicates the device index of the remote unit that the original message was being sent to.
Opcode - The opcode corresponding to the Feature Abort message. This value is
OxFFOO.
Rejected Opcode - The opcode of the message that failed. In this case, the Data Island
Notify message has failed, so the value is 0x0004.
Reason Code - This field will provide an indication of why the message has failed. In this case, a reason code of 0x06 will be issued to denote a timeout.
Failure Case Response:
[00372] A failure will be indicated by the transceiver with a Feature Abort message. The two possible causes of failure correspond to the following reason codes: Not in correct mode to respond (0x02) - If the message was sent before the transceiver was initialized, a Feature Abort message with this reason code will be issued. This message will also be issued for two other cases: 1) the appropriate Pass-Through Request/Response handshake has not been established between the two devices, 2) a successful connection control link has not been established between the two WirelessHD devices.
Invalid Operand (0x04) - If the device index field is invalid, a Feature Abort message with this reason code will be issued. This message will also be generated if the Port and VP/ AP information does not match the values that were set during the Connect Request/Response dialogue.
CEC Notify
[00373] Figure 127 illustrates a CEC Notify message. This command forwards a
CEC message to a remote device on the WirelessHD network.
Input Parameters:
Function Type - Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
Device Index - Indicates the device index to send the CEC packet to.
Opcode - The opcode corresponding to the CEC Notify message. This value is
0x0005.
Message Number - Host generated sequential numbering scheme for CEC messages.
Fragment Number - In the event that a single CEC message needs to be fragmented into multiple pieces, this field will allow the remote device to distinguish between retransmissions and sequential fragments.
Fragment Length - Indicates the length in octets of the "Fragment Data" block of this message.
LF - Zero (0) typically. Set to one (1) if current fragment is the last fragment of a message.
Fragment Data - The entire CEC message (or fragment), unprocessed.
Expected Response:
[00374] None. No response is explicitly expected in response to a CEC Notify message. Certain CEC messages will provide a response message, but the responsibility of maintaining state information of the CEC application layer is on the host system.
Timeout: [00375] For a properly formatted CEC Notify message, the transceiver does not provide any further feedback to the host to indicate a success condition. If, for some reason, the transceiver is unable to send the message to the destination, a Feature Abort message will be generated and sent to the host indicating a timeout. Figure 128 illustrates a Feature Abort message indicating a failure to send the CEC Notify. Its parameters are:
Function Type - Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
Device Index - Indicates the device index of the remote unit that the original message was being sent to.
Opcode - The opcode corresponding to the Feature Abort message. This value is
OxFFOO.
Rejected Opcode - The opcode of the message that failed. In this case, the CEC Notify message has failed, so the value is 0x0005.
Reason Code - This field will provide an indication of why the message has failed. In this case, a reason code of 0x06 will be issued to denote a timeout.
Failure Case Response:
[00376] A failure will be indicated by the transceiver with a Feature Abort message. The two possible causes of failure correspond to the following reason codes:
Not in correct mode to respond (0x02) - If the message was sent before the transceiver was initialized, a Feature Abort message with this reason code will be issued. This message will also be issued if the appropriate Pass-Through Request/Response handshake has not been established between the two devices.
Invalid Operand (0x04) - If the device index field is invalid, a Feature Abort message with this reason code will be issued.
CEC NAK
[00377] Figure 129 illustrates a CEC NAK message. This command notifies a remote device that a CEC message sent by that remote device was not accepted (NAK) on the local CEC bus. Input Parameters:
Function Type - Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
Device Index - Indicates the device index to send the NAK packet to.
Opcode - The opcode corresponding to the CEC NAK message. This value is 0x0006.
Result Code - This field indicates the result of the CEC request. A value of "0" indicates success, whereas "1" indicates failure.
Message Number - Host generated sequential numbering scheme for CEC messages.
This number must correspond to the Message Number of the CEC Notify message that cannot be placed on the CEC bus.
Expected Response:
[00378] None. No response is explicitly expected in response to a CEC NAK message.
Timeout:
[00379] For a properly formatted CEC NAK message, the transceiver should not need to provide any further feedback to the host to indicate a success condition. If, for some reason, the transceiver is unable to send the message to the destination, a Feature
Abort message will be generated and sent to the host indicating a timeout. Figure 130 illustrates a Feature Abort message indicating a failure to send the CEC NAK.
Function Type - Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
Device Index - Indicates the device index of the remote unit that the original message was being sent to.
Opcode - The opcode corresponding to the Feature Abort message. This value is
OxFFOO.
Rejected Opcode - The opcode of the message that failed. In this case, the CEC NAK message has failed, so the value is 0x0006.
Reason Code - This field will provide an indication of why the message has failed. In this case, a reason code of 0x06 will be issued to denote a timeout.
Failure Case Response: [00380] A failure will be indicated by the transceiver with a Feature Abort message. The two possible causes of failure correspond to the following reason codes: Not in correct mode to respond (0x02) - If the message was sent before the transceiver was initialized, a Feature Abort message with this reason code will be issued. This message will also be issued if the appropriate Pass-Through Request/Response handshake has not been established between the two devices.
Invalid Operand (0x04) - If the device index field is invalid, a Feature Abort message with this reason code will be issued. This message will also be sent if the CEC NAK message is sent to a device that did not issue the CEC message.
Logical Address Table Notify
[00381] Figure 131 illustrates a Logical Address Table Notify message. This command notifies a remote device of the logical addresses occupied on the local CEC bus.
Input Parameters:
Function Type - Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
Device Index - Indicates the device index to send the Logical Address bitmap to.
Opcode - The opcode corresponding to the Logical Address Table Notify message.
This value must be 0x0007.
Logical Address Bitmap - The 16-bit bit-field indicates the HDMI logical addresses occupied on the local CEC bus. The definitions of each bit location are defined in the
HDMI specification which should be referred to for detailed information. Figure 132 illustrates fields for definitions of the logical address bitmap.
Expected Response:
[00382] None. No response is explicitly expected in response to a Logical
Address Table Notify message.
Timeout: [00383] For a properly formatted Logical Address Table Notify message, the transceiver should not need to provide any further feedback to the host to indicate a success condition. If, for some reason, the transceiver is unable to send the message to the destination, a Feature Abort message will be generated and sent to the host indicating a timeout. Figure 133 illustrates a Feature Abort message indicating a failure to send the Logical Address Table Notify. Its parameters are:
Function Type - Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
Device Index - Indicates the device index of the remote unit that the original message was being sent to.
Opcode - The opcode corresponding to the Feature Abort message. This value is
OxFFOO.
Rejected Opcode - The opcode of the message that failed. In this case, the Logical
Address Table Notify message has failed, so the value is 0x0007.
Reason Code - This field will provide an indication of why the message has failed. In this case, a reason code of 0x06 will be issued to denote a timeout.
Failure Case Response:
[00384] A failure will be indicated by the transceiver with a Feature Abort message. The two possible causes of failure correspond to the following reason codes:
Not in correct mode to respond (0x02) - If the message was sent before the transceiver was initialized, a Feature Abort message with this reason code will be issued. This message will also be issued if the appropriate Pass-Through Request/Response handshake has not been established between the two devices.
Invalid Operand (0x04) - If the device index field is invalid, a Feature Abort message with this reason code will be issued.
HPD Notify
[00385] Figure 134 illustrates an HPD Notify message. This command notifies a remote device of the Hot Plug Detect state of the HDMI bus.
Input Parameters: Function Type - Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
Device Index - Indicates the device index to send the HPD Notify message to.
Opcode - The opcode corresponding to the HPD Notify message. This value is
0x0008.
HPD - The state of the Hot-Plug Detect signal. A one (1) indicates that the HPD signal is asserted. A zero (0) indicates that the HPD signal is not asserted.
Expected Response:
[00386] None. No response is explicitly expected in response to an HPD Notify message.
Timeout:
[00387] For a properly formatted HPD Notify message, the transceiver does not provide any further feedback to the host to indicate a success condition. If, for some reason, the transceiver is unable to send the message to the destination, a Feature Abort message will be generated and sent to the host indicating a timeout. Figure 135 illustrates a Feature Abort message indicating a failure to send the HPD Notify. Its parameters are:
Function Type - Indicates the function type of the opcode. This value is '0x04' to indicate the HDMI Pass-Through function type.
Device Index - Indicates the device index of the remote unit that the original message was being sent to.
Opcode - The opcode corresponding to the Feature Abort message. This value is
OxFFOO.
Rejected Opcode - The opcode of the message that failed. In this case, the HPD Notify message has failed, so the value is 0x0008.
Reason Code - This field will provide an indication of why the message has failed. In this case, a reason code of 0x06 will be issued to denote a timeout.
Failure Case Response:
[00388] A failure will be indicated by the transceiver with a Feature Abort message. The two possible causes of failure correspond to the following reason codes: Not in correct mode to respond (0x02) - If the message was sent before the transceiver was initialized, a Feature Abort message with this reason code will be issued. This message will also be issued if the appropriate Pass-Through Request/Response handshake has not been established between the two devices.
Invalid Operand (0x04) - If the device index field is invalid, a Feature Abort message with this reason code will be issued.
Other Messages
[00389] Figure 136 illustrates a Feature Abort message indicating unrecognized opcode. The response to failure cases for each category of messages has been described in the previous sections. In general, a message failure will result in a Feature Abort message. Messages received by the transceiver that do not contain valid opcodes will also result in a Feature Abort with the corresponding Reason Code.
An Example of a Communication System
[00390] Figure 138 is a block diagram of one embodiment of a communication system. Referring to Figure 130, the system comprises media receiver 100, a media receiver interface 102, a transmitting device 140, a receiving device 141, a media player interface 113, a media player 114 and a display 115.
[00391] Media receiver 100 receives content from a source (not shown). In one embodiment, media receiver 100 comprises a set top box. The content may comprise baseband digital video, such as, for example, but not limited to, content adhering to the HDMI or DVI standards. In such a case, media receiver 100 may include a transmitter (e.g., an HDMI transmitter) to forward the received content. [00392] Media receiver 101 sends content 101 to transmitter device 140 via media receiver interface 102. In one embodiment, media receiver interface 102 includes logic that converts content 101 into HDMI content. In such a case, media receiver interface 102 may comprise an HDMI plug and content 101 is sent via a wired connection; however, the transfer could occur through a wireless connection. In another embodiment, content 101 comprises DVI content. [00393] In one embodiment, the transfer of content 101 between media receiver interface 102 and transmitter device 140 occurs over a wired connection; however, the transfer could occur through a wireless connection.
[00394] Transmitter device 140 wirelessly transfers information to receiver device 141 using two wireless connections. One of the wireless connections is through a phased array antenna with adaptive beam-forming. The other wireless connection is via wireless communications channel 107, referred to herein as the back channel. In one embodiment, wireless communications channel 107 is uni-directional. In an alternative embodiment, wireless communications channel 107 is bi-directional. In one embodiment, the back channel can use some or all of the same antennas as the forward beam-formed channel (part of 105). In another embodiment, the two sets of antennas are disjoint.
[00395] Receiver device 141 transfers the content received from transmitter device 140 to media player 114 via an interface such as a media player interface 113. In one embodiment, the transfer of the content between receiver device 141 and media player interface 113 occurs through a wired connection; however, the transfer could occur through a wireless connection. In one embodiment, media player interface 113 comprises an HDMI plug. Similarly, the transfer of the content between media player interface 113 and media player 114 occurs through a wired connection; however, the transfer could occur through a wireless connection. The transfer could also occur through a wired or wireless data interface that was not a media player interface. [00396] Media player 114 causes the content to be played on display 115. In one embodiment, the content is HDMI content and media player 114 transfer the media content to display via a wired connection; however, the transfer could occur through a wireless connection. Display 115 may comprise a plasma display, an LCD, a CRT, etc. [00397] Note that the system in Figure 1 may be altered to include a DVD player/recorder in place of a DVD player/recorder to receive, and play and/or record the content. The same techniques can be used in non-media data applications as well. [00398] In one embodiment, transmitter 140 and media receiver interface 102 are part of media receiver 100. Similarly, in one embodiment, receiver 140, media player interface 113, and media player 114 are all part of the same device. In an alternative embodiment, receiver 140, media player interface 113, media player 114, and display 115 are all part of the display. An example of such a device is shown in Figure 139. [00399] In one embodiment, transmitter device 140 comprises a processor 103, an optional baseband processing component 104, a phased array antenna 105, and a wireless communication channel interface 106. Phased array antenna 105 comprises a radio frequency (RF) transmitter having a digitally controlled phased array antenna coupled to and controlled by processor 103 to transmit content to receiver device 141 using adaptive beam-forming.
[00400] In one embodiment, receiver device 141 comprises a processor 112, an optional baseband processing component 111, a phased array antenna 110, and a wireless communication channel interface 109. Phased array antenna 110 comprises a radio frequency (RF) transmitter having a digitally controlled phased array antenna coupled to and controlled by processor 112 to receive content from transmitter device 140 using adaptive beam- forming.
[00401] In one embodiment, processor 103 generates baseband signals that are processed by baseband signal processing 104 prior to being wirelessly transmitted by phased array antenna 105. In such a case, receiver device 141 includes baseband signal processing to convert analog signals received by phased array antenna 110 into baseband signals for processing by processor 112. In one embodiment, the baseband signals are orthogonal frequency division multiplex (OFDM) signals. [00402] In one embodiment, transmitter device 140 and/or receiver device 141 are part of separate transceivers.
[00403] Transmitter device 140 and receiver device 141 perform wireless communication using a phased array antenna with adaptive beam-forming that allows beam steering. Beam-forming is well known in the art. In one embodiment, processor 103 sends digital control information to phased array antenna 105 to indicate an amount to shift one or more phase shifters in phased array antenna 105 to steer a beam formed thereby in a manner well-known in the art. Processor 112 uses digital control information as well to control phased array antenna 110. The digital control information is sent using control channel 121 in transmitter device 140 and control channel 122 in receiver device 141. In one embodiment, the digital control information comprises a set of coefficients. In one embodiment, each of processors 103 and 112 comprises a digital signal processor.
[00404] Wireless communication link interface 106 is coupled to processor 103 and provides an interface between wireless communication link 107 and processor 103 to communicate antenna information relating to the use of the phased array antenna and to communicate information to facilitate playing the content at the other location. In one embodiment, the information transferred between transmitter device 140 and receiver device 141 to facilitate playing the content includes encryption keys sent from processor 103 to processor 112 of receiver device 141 and one or more acknowledgments from processor 112 of receiver device 141 to processor 103 of transmitter device 140.
[00405] Wireless communication link 107 also transfers antenna information between transmitter device 140 and receiver device 141. During initialization or tuning of the phased array antennas 105 and 110, wireless communication link 107 transfers information to enable processor 103 to select a direction for the phased array antenna 105. In one embodiment, the information includes, but is not limited to, antenna location information and performance information corresponding to the antenna location, such as one or more pairs of data that include the position of phased array antenna 110 and the signal strength of the channel for that antenna position. In another embodiment, the information includes, but is not limited to, information sent by processor 112 to processor 103 to enable processor 103 to determine which portions of phased array antenna 105 to use to transfer content.
[00406] When the phased array antennas 105 and 110 are operating in a mode during which they may transfer content (e.g., HDMI content), wireless communication link 107 transfers an indication of the status of communication path from the processor 112 of receiver device 141. The indication of the status of communication comprises an indication from processor 112 that prompts processor 103 to steer the beam in another direction (e.g., to another channel). Such prompting may occur in response to interference with transmission of portions of the content. The information may specify one or more alternative channels that processor 103 may use.
[00407] In one embodiment, the antenna information comprises information sent by processor 112 to specify a location to which receiver device 141 is to direct phased array antenna 110. This may be useful during initialization when transmitter device 140 is telling receiver device 141 where to position its antenna so that signal quality measurements can be made to identify the best channels. The position specified may be an exact location or may be a relative location such as, for example, the next location in a predetermined location order being followed by transmitter device 140 and receiver device 141. [00408] In one embodiment, wireless communications link 107 transfers information from receiver device 141 to transmitter device 140 specifying antenna characteristics of phased array antenna 110, or vice versa. In one embodiment, communications link 107 transfers information from receiver device 141 to transmitter device 140 that can be used to control phased array antenna 105.
An Example of a Transceiver Architecture
[00409] One embodiment of a transceiver is described below. The transceiver includes transmit and receive paths for a transmitter and receiver, respectively. In one embodiment, the transmitter, for use in communication with a receiver, comprises a processor and a phased array beamforming antenna. The processor controls the antenna to perform adaptive beam steering using multiple transmit antennas in conjunction with receive antennas of the receiver by iteratively performing a set of training operations. One of the training operations comprises the processor causing the phased array beamforming antenna to transmit a first training sequence while a receive antenna-array weight vector of the receiver is set and a transmitter antenna-array weight vector switches between weight vectors with a set of weight vectors. Another of the training operations comprises the processor causing the phased array beamforming antenna to transmit a second training sequence while a transmitter antenna-array weight vector is set as part of a process to calculate the receive antenna-array weight vector. [00410] In one embodiment, the receiver, for use in communication with a transmitter, comprises a processor and a phased array beamforming antenna. The processor controls the antenna to perform adaptive beam steering using multiple receive antennas in conjunction with transmit antennas of the transmitter by iteratively performing a set of training operations. One of the training operations comprises the processor setting a receive antenna-array weight vector during a process for estimating a transmit antenna-array weight vector by having the transmitter transmit a first training sequence while the receive antenna- array weight vector is set. Another of the training operations comprises the processor calculate the receive antenna-array weight vector when the transmitter transmits a second training sequence while the transmitter antenna-array weight vector is set.
[00411] Figure 140 is a block diagram of one embodiment of a transmitter device and a receiver device that are part of an adaptive beam forming multiple antenna radio system containing of Figure 138. Transceiver 300 includes multiple independent transmit and receive chains and performs phased array beam forming using a phased array that takes an identical RF signal and shifts the phase for one or more antenna elements in the array to achieve beam steering.
[00412] Referring to Figure 140, digital baseband processing module (e.g.,
Digital Signal Processor (DSP)) 301 formats the content and generates real time baseband signals. Digital baseband processing module 301 may provide modulation, FEC coding, packet assembly, interleaving and automatic gain control. [00413] Digital baseband processing module 301 then forwards the baseband signals to be modulated and sent out on the RF portion of the transmitter. In one embodiment, the content is modulated into OFDM signals in a manner well known in the art.
[00414] Digital-to-analog converter (DAC) 302 receives the digital signals output from digital baseband processing module 301 and converts them to analog signals. In one embodiment, the signal outputs from DAC 302 are between 0-1.7 GHz. Analog front end 303 receives the analog signals and filters it with an appropriate low- pass image-rejection filter and amplifies it accordingly. The IF module 304 receives the output of analog front end 303 and up-converts it to the IF frequency. In one embodiment, the IF frequency is between 2-15 GHz.
[00415] RF mixer 305 receives signals output from IF amplifier 304 and combines them with a signal from a local oscillator (LO) (not shown) in a manner well- known in the art. The signals output from mixer 305 are at an intermediate frequency. In one embodiment, the intermediate frequency is between 2-15 GHz. [00416] Multiplexer 306 is coupled to receive the output from mixer 305 to control which phase shifters 3071-N receive the signals. In one embodiment, phase shifters 307j_N are quantized phase shifters. In an alternative embodiment, phase shifters 307i_N may be replaced by IF or RF amplifiers with controllable gain and phase. In one embodiment, digital baseband processing module 201 also controls, via control channel 360, the phase and magnitude of the currents in each of the antenna elements in phased array antenna to produce a desired beam pattern in a manner well-known in the art. In other words, digital baseband processing module 201 controls the phase shifters 307]_N of phased array antenna to produce the desired pattern. [00417] Each of phase shifters 3071-κ produce an output that is sent to one of power amplifiers 308I_N, which amplify the signal. The amplified signals are sent to an antenna array that has multiple antenna elements 309I_N- In one embodiment, the signals transmitted from antennas 309I_N are radio frequency signals between 56-64 GHz. Thus, multiple beams are output from the phased array antenna. [00418] With respect to the receiver, antennas 310I_N receive the wireless transmissions from antennas 309i_Nκ and provide them to phase shifters 312i_N, via low- noise amplifiers 311 I_N, respectively. As discussed above, in one embodiment, phase shifters 312i_N comprise quantized phase shifters. Alternatively, phase shifters 312i_N may be replaced by complex multipliers. Phase shifters 312j_N receive the signals from antennas 310i_N, which are combined by RF combiner 313 to form a single line feed output. In one embodiment, a multiplexer is used to combine the signals from the different elements and output the single feed line. The output of RF combiner 313 is input to RF mixer 314.
[00419] Mixer 314 receives the output of the RF combiner 313 and combines it with a signal from a LO (not shown) in a manner well-known in the art. In one embodiment, the output of mixer 314 is a signal with the IF carrier frequency of 2-15 GHz. The IF module then down-converts the IF signal to the baseband frequency. In one embodiment, there are I and Q signals, which are between 0-1.7 GHz. [00420] Analog-to-digital converter (ADC) 316 receives the output of IF 315 and converts it to digital form. The digital output from ADC 316 is received by digital baseband processing module (e.g., DSP) 318. Digital baseband processing module 318 restores the amplitude and phase of the signal. Digital baseband processing module 318 may provide demodulation, packet disassembly, de-interleaving and automatic gain.
[00421] In one embodiment, each of the transceivers includes a controlling microprocessor that sets up control information for the digital baseband processing module (e.g., DSP). The controlling microprocessor may be on the same die as the digital baseband processing module (e.g., DSP).
DSP-controlled Adaptive Beam Forming
[00422] In one embodiment, the DSPs implement an adaptive algorithm with the beam forming weights being implemented in hardware. That is, the transmitter and receiver work together to perform the beam forming in RF frequency using digitally controlled analog phase shifters; however, in an alternative embodiment, the beam- forming is performed in IF. Phase shifters 307I_N and 312I_N are controlled via control channel 360 and control channel 370, respectfully, via their respective DSPs in a manner well known in the art. For example, digital baseband processing module (e.g., DSP) 301 controls phase shifters 307I_N to have the transmitter perform adaptive beam- forming to steer the beam while digital baseband processing module (e.g., DSP) 318 controls phase shifters 312i_N to direct antenna elements to receive the wireless transmission from antenna elements and combine the signals from different elements to form a single line feed output. In one embodiment, a multiplexer is used to combine the signals from the different elements and output the single feed line. Note that processors (e.g., DSPs) that control the digital baseband processing modules, such as shown in the transmitters and receivers of Figure 1, could be coupled to control channels 360 and 370, respectively, could be used to control phase shifters 307I_N and 3121-N.
[00423] Digital baseband processing module (e.g., DSP) 301 performs the beam steering by pulsing, or energizing, the appropriate phase shifter connected to each antenna element. The pulsing algorithm under digital baseband processing module (e.g., DSP) 301 controls the phase and gain of each element. Performing DSP controlled phase array beam-forming is well known in the art. [00424] The adaptive beam forming antenna is used to avoid interfering obstructions. By adapting the beam forming and steering the beam, the communication can occur avoiding obstructions which may prevent or interfere with the wireless transmissions between the transmitter and the receiver. [00425] In one embodiment, with respect to the adaptive beam-forming antennas, they have three phases of operations. The three phases of operations are the training phase, a searching phase, and a tracking phase. The training phase and searching phase occur during initialization. The training phase determines the channel profile with predetermined sequences of spatial patterns { Al } and { Bj } . The searching phase computes a list of candidate spatial patterns { AT }, { Bj } and selects a prime candidate [ Ao Bo } for use in the data transmission between the transmitter of one transceiver and the receiver of another. The tracking phase keeps track of the strength of the candidate list. When the prime candidate is obstructed, the next pair of spatial patterns is selected for use.
[00426] In one embodiment, during the training phase, the transmitter sends out a sequence of spatial patterns { A; }. For each spatial pattern { A; }, the receiver projects the received signal onto another sequence of patterns { B] }. As a result of the projection, a channel profile is obtained over the pair { A; }, { Bj }. [00427] In one embodiment, an exhaustive training is performed between the transmitter and the receiver in which the antenna of the receiver is positioned at all locations and the transmitter sending multiple spatial patterns. Exhaustive training is well-known in the art. In this case, M transmit spatial patterns are transmitted by the transmitter and N received spatial patterns are received by the receiver to form an N by M channel matrix. Thus, the transmitter goes through a pattern of transmit sectors and the receiver searches to find the strongest signal for that transmission. Then the transmitter moves to the next sector. At the end of the exhaustive search process, a ranking of all the positions of the transmitter and the receiver and the signals strengths of the channel at those positions has been obtained. The information is maintained as pairs of positions of where the antennas are pointed and signal strengths of the channels. The list may be used to steer the antenna beam in case of interference. [00428] In an alternative embodiment, subspace training is used in which the space is divided in successively narrow sections with orthogonal antenna patterns being sent to obtain a channel profile.
[00429] Assuming digital baseband processing module 301 (DSP) is in a stable state and the direction the antenna should point is already determined. In the nominal state, the DSP will have a set of coefficients that it sends to the phase shifters. The coefficients indicate the amount of phase the phase shifter is to shift the signal for its corresponding antennas. For example, digital baseband processing module 301 (DSP) sends a set digital control information to the phase shifters that indicate the different phase shifters are to shift different amounts, e.g., shift 30 degrees, shift 45 degrees, shift 90 degrees, shift 180 degrees, etc. Thus, the signal that goes to that antenna element will be shifted by a certain number of degrees of phase. The end result of shifting, for example, 16, 32, 36, 64 elements in the array by different amounts enables the antenna to be steered in a direction that provides the most sensitive reception location for the receiving antenna. That is, the composite set of shifts over the entire antenna array provides the ability to stir where the most sensitive point of the antenna is pointing over the hemisphere. [00430] Note that in one embodiment the appropriate connection between the transmitter and the receiver may not be a direct path from the transmitter to the receiver. For example, the most appropriate path may be to bounce off the ceiling.
The Back Channel
[00431] In one embodiment, the wireless communication system includes a back channel 320, or link, for transmitting information between wireless communication devices (e.g., a transmitter and receiver, a pair of transceivers, etc.). The information is related to the beam-forming antennas and enables one or both of the wireless communication devices to adapt the array of antenna elements to better direct the antenna elements of a transmitter to the antenna elements of the receiving device together. The information also includes information to facilitate the use of the content being wirelessly transferred between the antenna elements of the transmitter and the receiver.
[00432] In Figure 140, back channel 320 is coupled between digital baseband processing module (DSP) 318 and digital baseband processing module (DSP) 301 to enable digital baseband processing module (DSP) 318 to send tracking and control information to digital baseband processing module (DSP) 301. In one embodiment, back channel 320 functions as a high speed downlink and an acknowledgement channel.
[00433] In one embodiment, the back channel is also used to transfer information corresponding to the application for which the wireless communication is occurring (e.g., wireless video). Such information includes content protection information. For example, in one embodiment, the back channel is used to transfer encryption information (e.g., encryption keys and acknowledgements of encryption keys) when the transceivers are transferring HDMI data. In such a case, the back channel is used for content protection communications.
[00434] More specifically, in HDMI, encryption is used to validate that the data sink is a permitted device (e.g., a permitted display). There is a continuous stream of new encryption keys that is transferred while transferring the HDMI datastream to validate that the permitted device hasn't changed. Blocks of frames for the HD TV data are encrypted with different keys and then those keys have to be acknowledged back on back channel 320 in order to validate the player. Back channel 220 transfers the encryption keys in the forward direction to the receiver and acknowledgements of key receipts from the receiver in the return direction. Thus, encrypted information is sent in both directions.
[00435] The use of the back channel for content protection communications is beneficial because it avoids having to complete a lengthy retraining process when such communications are sent along with content. For example, if a key from a transmitter is sent alongside the content flowing across the primary link and that primary link breaks, it will force a lengthy retrain of 2-3 seconds for a typical HDMI/HDCP system. In one embodiment, this separate bi-directional link that has higher reliability than the primary directional link given its omni-directional orientation. By using this back channel for communication of the HDCP keys and the appropriate acknowledgement back from the receiving device, the time consuming retraining can be avoided even in the event of the most impactful obstruction.
[00436] In the active mode, when the beam-forming antennas are transferring content, the back channel is used to allow the receiver to notify the transmitter about the status of the channel. For example, while the channel between the beam-forming antennas is of sufficient quality, the receiver sends information over the back channel to indicate that the channel is acceptable. The back channel may also be used by the receiver to send the transmitter quantifiable information indicating the quality of the channel being used. If some form of interference (e.g., an obstruction) occurs that degrades the quality of the channel below an acceptable level or prevents transmissions completely between the beam-forming antennas, the receiver can indicate that the channel is no longer acceptable and/or can request a change in the channel over the back channel. The receiver may request a change to the next channel in a predetermined set of channels or may specify a specific channel for the transmitter to use.
[00437] In one embodiment, the back channel is bi-directional. In such a case, in one embodiment, the transmitter uses the back channel to send information to the receiver. Such information may include information that instructs the receiver to position its antenna elements at different fixed locations that the transmitter would scan during initialization. The transmitter may specify this by specifically designating the location or by indicating that the receiver should proceed to the next location designated in a predetermined order or list through which both the transmitter and receiver are proceeding. [00438] In one embodiment, the back channel is used by either or both of the transmitter and the receiver to notify the other of specific antenna characterization information. For example, the antenna characterization information may specify that the antenna is capable of a resolution down to 6 degrees of radius and that the antenna has a certain number of elements (e.g., 32 elements, 64 elements, etc.). [00439] In one embodiment, communication on the back channel is performed wirelessly by using interface units. Any form of wireless communication may be used. In one embodiment, OFDM is used to transfer information over the back channel. In another embodiment, CPM is used to transfer information over the back channel.
An Example of a Computer System
[00440] Figure 141 is a block diagram of an exemplary computer system that may perform one or more of the operations described herein. Referring to Figure 141, computer system 14100 may comprise an exemplary client or server computer system. Computer system 14100 comprises a communication mechanism or bus 14111 for communicating information, and a processor 14112 coupled with bus 14111 for processing information. Processor 14112 includes a microprocessor, but is not limited to a microprocessor, such as, for example, Pentium™, PowerPC™, Alpha™, etc. [00441] System 14100 further comprises a random access memory (RAM), or other dynamic storage device 14104 (referred to as main memory) coupled to bus 14111 for storing information and instructions to be executed by processor 14112. Main memory 14104 also may be used for storing temporary variables or other intermediate information during execution of instructions by processor 14112. [00442] Computer system 14100 also comprises a read only memory (ROM) and/or other static storage device 14106 coupled to bus 14111 for storing static information and instructions for processor 14112, and a data storage device 14107, such as a magnetic disk or optical disk and its corresponding disk drive. Data storage device 14107 is coupled to bus 14111 for storing information and instructions. [00443] Computer system 14100 may further be coupled to a display device
14121, such as a cathode ray tube (CRT) or liquid crystal display (LCD), coupled to bus 14111 for displaying information to a computer user. An alphanumeric input device 14122, including alphanumeric and other keys, may also be coupled to bus 14111 for communicating information and command selections to processor 14112. An additional user input device is cursor control 14123, such as a mouse, trackball, trackpad, stylus, or cursor direction keys, coupled to bus 14111 for communicating direction information and command selections to processor 14112, and for controlling cursor movement on display 14121.
[00444] Another device that may be coupled to bus 14111 is hard copy device
14124, which may be used for marking information on a medium such as paper, film, or similar types of media. Another device that may be coupled to bus 14111 is a wired/wireless communication capability 14125 to communication to a phone or handheld palm device.
[00445] Note that any or all of the components of system 14100 and associated hardware may be used in the present invention. However, it can be appreciated that other configurations of the computer system may include some or all of the devices. [00446] Whereas many alterations and modifications of the present invention will no doubt become apparent to a person of ordinary skill in the art after having read the foregoing description, it is to be understood that any particular embodiment shown and described by way of illustration is in no way intended to be considered limiting. Therefore, references to details of various embodiments are not intended to limit the scope of the claims which in themselves recite only those features regarded as essential to the invention.

Claims

CLAIMSWe claim:
1. An apparatus for use in a wireless communication system for communicating with a wireless network, the apparatus comprising: a host processor having an I2C interface; a transceiver having an I2C interface; a physical interface coupling the host processor and the transceiver, the physical interface comprising an I C bus coupled to the I C interface of both the host processor and the transceiver; and a plurality of separate banks of memory accessible by the host processor and the transceiver to exchange information between the host processor and the transceiver, wherein the host processor accesses the plurality of banks of memory via its I2C interface.
2. The apparatus defined in Claim 1 wherein the plurality of banks of memory comprises: a first bank to store information being transferred from the host processor to the transceiver; a second bank to store information being transferred from the transceiver to the host processor; a third bank to store control registers to control interactions between the host processor and the transceiver; and a fourth bank to store audio- video information registers to store information obtained by the transceiver from the wireless network regarding one or more devices in the wireless network and for use by the host processor.
3. The apparatus defined in Claim 2 wherein one or more of the control registers indicate when communications are ready and in which memory locations in the plurality of banks the data may be read or written to.
4. The apparatus defined in Claim 3 wherein the third bank stores one or more bitmaps that provide information on a device list of devices in the wireless network.
5. The apparatus defined in Claim 4 wherein the host processor is operable to access the one or more bitmaps to determine which of the one or more devices specified in the device list to filter to obtain device capability information.
6. The apparatus defined in Claim 2 wherein, in order for the transceiver to send data to the host processor using the second bank, the transceiver stores one or more packets in one or more registers in the second bank and asserts a control signal to the host processor, and further wherein the host processor accesses the one or more registers in second bank to obtain the one or more packets in response to the control signal.
7. The apparatus defined in Claim 6 wherein the transceiver stores the one or more packets in the one or more registers simultaneously with asserting the control signal to the host processor.
8. The apparatus defined in Claim 1 wherein each bank in the plurality of banks of memory has an address that is unique with respect to other banks in the plurality of banks.
9. The apparatus defined in Claim 1 wherein the physical interface further comprises a reset signal line and an interrupt signal line, wherein the interrupt signal line is used by the transceiver to send an interrupt to the host processor and the reset signal line is used by the host processor to reset the transceiver.
10. The apparatus defined in Claim 1 wherein the transceiver interfaces to the plurality of the banks via a direct memory bus.
11. A wireless communication system comprising: a remote wireless media device in a wireless network; and an apparatus for use in communicating with the remote wireless media device, the apparatus comprising a host processor having an I C interface; a transceiver having an I2C interface; a physical interface coupling the host processor and the transceiver, the physical interface comprising an I2C bus coupled to the I2C interface of both the host processor and the transceiver; and a plurality of separate banks of memory accessible by the host processor and the transceiver to exchange information between the host processor and the transceiver, wherein the host processor accesses the plurality of banks of memory via its I2C interface.
12. The wireless communication system defined in Claim 11 wherein the plurality of banks of memory comprises: a first bank to store information being transferred from the host processor to the transceiver; a second bank to store information being transferred from the transceiver to the host processor; a third bank to store control registers to control interactions between the host processor and the transceiver; and a fourth bank to store audio- video information registers to store information obtained by the transceiver from the wireless network regarding one or more devices in the wireless network and for use by the host processor.
13. The wireless communication system defined in Claim 12 wherein one or more of the control registers indicate when communications are ready and in which memory locations in the plurality of banks the data may be read or written to.
14. The wireless communication system defined in Claim 13 wherein the third bank stores one or more bitmaps that provide information on a device list of devices in the wireless network.
15. The wireless communication system defined in Claim 14 wherein the host processor is operable to access the one or more bitmaps to determine which of the one or more devices specified in the device list to filter to obtain device capabilities information.
16. The wireless communication system defined in Claim 12 wherein, in order for the transceiver to send data to the host processor using the second bank, the transceiver stores one or more packets in one or more registers in the second bank and asserts a control signal to the host processor, and further wherein the host processor accesses the one or more registers in second bank to obtain the one or more packets in response to the control signal.
17. The wireless communication system defined in Claim 16 wherein the transceiver stores the one or more packets in the one or more registers nearly simultaneously with asserting the control signal to the host processor.
18. The wireless communication system defined in Claim 11 wherein each bank in the plurality of banks of memory has an address that is unique with respect to other banks in the plurality of banks.
19. The wireless communication system defined in Claim 11 wherein the physical interface further comprises a reset signal line and an interrupt signal line, wherein the interrupt signal line is used by the transceiver to send an interrupt to the host processor and the reset signal line is used by the host processor to reset the transceiver.
20. The wireless communication system defined in Claim 11 wherein the the transceiver interfaces to the plurality of banks via a direct memory bus.
21. An apparatus for use in a wireless communication system for communicating with a wireless network, the apparatus comprising: a host processor having an I2C interface; a wireless transceiver having an I C interface; a physical interface coupling the host processor and the transceiver, the physical interface comprising an I C bus coupled to the I C interface of both the host processor and the transceiver, and wherein the host processor maps a message -based communication protocol to a register-based communication protocol of an HDMI device to communicate with the HDMI device using the I C bus.
22. A wireless communication system comprising: a remote HDMI wireless media transceiver in a wireless network; and an apparatus for use in a wireless communication system for communicating with a wireless network, the apparatus comprising a host processor having an I2C interface; a wireless transceiver having an I C interface; a physical interface coupling the host processor and the transceiver, the physical interface comprising an I2C bus coupled to the I2C interface of both the host processor and the transceiver, and wherein the host processor maps a message-based communication protocol to a register-based communication protocol of the HDMI device to communicate with the HDMI device using the I2C bus.
23. An apparatus for use in a wireless communication system for communicating with a wireless network, the apparatus comprising: a host processor; a transceiver; a physical interface coupling the host processor and the transceiver; and a memory accessible by the host processor and the transceiver to exchange information between the host processor and the transceiver, wherein the transceiver is operable to store data in the memory for the host processor to send data to the host processor using the memory and asserts a control signal to the host processor to notify the host processor that the memory contains data for the host processor, and further wherein the host processor is operable to access the memory to obtain the data thereafter, and wherein the data is associated with a remote device in the wireless network and is stored as one or more packets at a first storage location in the memory with a first identifier identifying the remote device.
24. A wireless communication system comprising: one or more remote wireless media devices in a wireless network; and an apparatus for use in a wireless communication system for communicating with a wireless network, the apparatus comprising: a host processor; a transceiver; a physical interface coupling the host processor and the transceiver; and a memory accessible by the host processor and the transceiver to exchange information between the host processor and the transceiver, wherein the transceiver is operable to store data in the memory for the host processor to send data to the host processor using the memory and asserts a control signal to the host processor to notify the host processor that the memory contains data for the host processor, and further wherein the host processor is operable to access the memory to obtain the data thereafter, wherein the data is associated with one of the remote wireless devices in the wireless network and is stored as one or more packets at a first storage location in the memory with a first identifier identifying the one remote wireless device.
25. A method comprising: accessing a memory to obtain one or more bitmaps that map each bit location in the bitmap to an index value, wherein one index value is assigned to each remote wireless media device of a wireless network in a wireless communication system; and examining the one or more bitmaps and determining at least one characteristic of a remote wireless media device and a device identifier that identifies the remote wireless media device in the wireless network based on bit position in the one or more bitmaps.
26. The method defined in Claim 25 further comprising: selecting, based on information specified in the one or more bitmaps, one or more of the remote wireless media devices in the wireless network for which to obtain device specific information; and obtaining the device specific information.
27. The method defined in Claim 26 wherein selecting, based on information specified in the one or more bitmaps, the one or more of the remote wireless media devices comprises: comparing the one or more bitmaps with a previously received and stored version of the one or more bitmaps to identify which bit locations in the one or more bitmaps are different; and filtering out, based on results of comparing the one or more bitmaps to the previously received and stored version, device indices for which device specific information has already been obtained.
28. The method defined in Claim 26 wherein the device specific information comprises device capability information.
29. The method defined in Claim 28 further comprising: storing the one or more bit maps in a first bank of memory; storing device capability information in a second bank of memory separate from the first bank of memory; and after examining the one or more bit maps, accessing the second bank of memory to obtain the device capability information.
30. The method defined in Claim 29 wherein accessing the second bank of memory to obtain the device capability information is performed using an I2C bus.
31. The method defined in Claim 25 wherein a first portion of the one or more bit maps is reserved for a first type of remote wireless device and a second portion of the one or more bit maps, different than the first portion, is reserved for a second type of remote wireless device, where the first and second types of remote wireless device are different.
32. The method defined in Claim 31 wherein the first type of remote wireless device corresponds to HRRX-capable only devices, the second type of remote wireless device corresponds to HRTX-capable only devices, and a third portion of the one or more bit maps is reserved for a third type of remote wireless device that corresponds to devices which are neither HRRX-capable nor HRTX-capable..
33. The method defined in Claim 31 wherein a fourth type of remote wireless device has a characteristic of both the first and second type of remote wireless device and has a device identifier in both the first and second portions of the one or more bit maps.
34. The method defined in Claim 33 wherein the fourth type of remote wireless device corresponds to devices that are both HRRX-capable and HRTX- capable.
35. The method defined in Claim 25 wherein the one or more bitmaps are stored as 24 registers that operate as 3 64-bit bitfields.
36. An apparatus for use in a wireless communication system for communicating with a wireless network, the apparatus comprising: a host processor; a transceiver; a physical interface coupling the host processor and the transceiver; and a memory accessible by the host processor and the transceiver to exchange information between the host processor and the transceiver, wherein the host processor is operable to access the memory to obtain one or more bitmaps stored therein that map each bit location in the bitmap to an index value, wherein one index value is assigned to each remote wireless media device of the wireless network in the wireless communication system, and further wherein the host processor examines the one or more bitmaps to determine at least one characteristic of a remote wireless media device and a device identifier that identifies the remote wireless media device in the wireless network based on bit position in the one or more bitmaps.
37. The apparatus defined in Claim 36 wherein the host processor selects, based on information specified in the one or more bitmaps, one or more of the remote wireless media devices in the wireless network for which to obtain device specific information and accesses access memory to obtain the device specific information.
38. The apparatus defined in Claim 37 wherein the host processor selects, based on information specified in the one or more bitmaps, the one or more of the remote wireless media devices by: comparing the one or more bitmaps with a previously received and stored version of the one or more bitmaps to identify which bit locations in the one or more bitmaps are different; and filtering out, based on results of comparing the one or more bitmaps to the previously received and stored version, device indices for which device specific information has already been obtained.
39. The apparatus defined in Claim 36 wherein the device specific information comprises device capability information.
40. The apparatus defined in 39 wherein the memory comprises a plurality of banks, wherein a first bank is operable to store the one or more bit maps in a first bank of memory, and a second bank of memory, different than the first bank of memory, is operable to store the device capability information, and further wherein the host processor, after examining the one or more bit maps, accesses the second bank of memory to obtain the device capability information.
41. The apparatus defined in Claim 40 wherein the host processor accesses the sec oonndd bbaannkk ooff mmeemmoorryy ttoo oobbttaaiinn tthhee ddeevviiccee ccaappaabbility information using an I2C bus coupled between the host processor and a transceiver.
42. The apparatus defined in Claim 1362 wherein a first portion of the one or more bit maps is reserved for a first type of remote wireless device and a second portion of the one or more bit maps, different than the first portion, is reserved for a second type of remote wireless device, where the first and second types of remote wireless device are different.
43. The apparatus defined in Claim 42 wherein the first type of remote wireless device corresponds to HRRX-capable only devices, the second type of remote wireless device corresponds to HRTX-capable only devices, and a third portion of the one or more bit maps is reserved for a third type of remote wireless device that corresponds to devices which are neither HRRX-capable nor HRTX-capable.
44. The apparatus defined in Claim 42 wherein a fourth type of remote wireless device has a characteristic of both the first and second type of remote wireless device and has a device identifier in both the first and second portions of the one or more bit maps.
45. The apparatus defined in Claim 44 wherein the fourth type of remote wireless device corresponds to devices that are both HRRX-capable and HRTX- capable.
46. The apparatus defined in Claim 25 wherein the one or more bitmaps are stored as 24 registers that operate as 3 64-bit bitfields.
47. A method for initializing a transceiver that is part of an apparatus for use in a wireless communication system for communicating with WirelessHD devices in a wireless network, where the apparatus comprises a host processor; a transceiver; a physical interface coupling the host processor and the transceiver; and a memory accessible by the host processor and the transceiver to exchange information between the host processor and the transceiver, the initialization method comprising: resetting the transceiver by initializing internal hardware and software subsystems of the transceiver; after resetting the transceiver, the transceiver entering a configuration state to configure the transceiver; configuring the transceiver, such that the transceiver is configured as part of initialization; and after configuration, the transceiver entering a wait enable state during which the transceiver waits for its wireless interface to be enabled before wireless operation of the transceiver becomes active.
48. An apparatus for use in a wireless communication system for communicating with WirelessHD devices in a wireless network, the apparatus comprising: a host processor; a transceiver; a physical interface coupling the host processor and the transceiver; and a memory accessible by the host processor and the transceiver to exchange information between the host processor and the transceiver, wherein the transceiver and host processor operate together to initialize the transceiver by resetting the transceiver by initializing internal hardware and software subsystems of the transceiver; after resetting the transceiver, the transceiver entering a configuration state to configure the transceiver; configuring the transceiver, such that the transceiver is configured as part of initialization; and after configuration, the transceiver entering a wait enable state during which the transceiver waits for its wireless interface to be enabled before wireless operation of the transceiver becomes active.
49. A device discovery process for use in a wireless communication system having an apparatus for communicating with devices in a wireless network, where the apparatus comprises a host processor; a transceiver; a physical interface coupling the host processor and the transceiver; and a memory accessible by the host processor and the transceiver to exchange information between the host processor and the transceiver, the device discovery process comprising: discovering a remote wireless device in the wireless network; notifying, by the transceiver, the host processor of the remote wireless device; requesting, under control of the transceiver, capability information from the remote wireless device prior to receiving a request from the host processor for the capability information; buffering, under control of the transceiver, the capability information before the capability information is requested by the host processor; receiving a capability request from the host processor; and providing the host processor access to the capability information.
50. The method defined in Claim 49 wherein notifying the host processor of the remote wireless device comprises asserting an interrupt to the host processor.
51. The method defined in Claim 49 wherein notifying the host processor of the remote wireless device is performed through an indexed bitmap table resident in the memory.
52. The method defined in Claim 51 further comprising: sending a message from the transceiver to the host processor indicating that a list of devices in the wireless network is available; and the host processor accessing memory to obtain the indexed bitmap table; comparing the indexed bitmap table with a previously stored table to determine any changes; sending a capabilities request from the host processor to the transceiver for the remote wireless device if the host processor determines the remote wireless device is new based on results of comparing the indexed bitmap table with a previously stored table.
53. The method defined in Claim 52 further comprising the transceiver updating the list of devices in response to discovering the remote wireless device has been added to the wireless network.
54. The method defined in Claim 49 wherein receiving the capability request from the host processor comprises: the host processor storing a capabilities request message in a first bank of the memory; the host process sending a control message to a second bank of the memory, the control message indicating to the transceiver that the information exists in the first bank for the transceiver; and the transceiver reading the capabilities request message from the first buffer.
55. The method defined in Claim 49 wherein the devices are WirelessHD devices.
56. An apparatus for use in a wireless communication system for communicating with devices in a wireless network, the apparatus comprising: a host processor; a transceiver; a physical interface coupling the host processor and the transceiver; and a memory accessible by the host processor and the transceiver to exchange information between the host processor and the transceiver, wherein the transceiver and the host processor cooperate to perform a device discovery process that includes discovering a remote wireless device in the wireless network; notifying, by the transceiver, the host processor of the remote wireless device; requesting, under control of the transceiver, capability information from the remote wireless device prior to receiving a request from the host processor for the capability information; buffering, under control of the transceiver, the capability information before the capability information is requested by the host processor; receiving a capability request from the host processor; and providing the host processor access to the capability information.
57. The apparatus defined in Claim 56 wherein notifying the host processor of the remote wireless device comprises asserting an interrupt to the host processor.
58. The apparatus defined in Claim 56 wherein notifying the host processor of the remote wireless device is performed through an indexed bitmap table resident in the memory.
59. The apparatus defined in Claim 58 further comprising: sending a message from the transceiver to the host processor indicating that a list of devices in the wireless network is available; and the host processor accessing memory to obtain the indexed bitmap table; comparing the indexed bitmap table with a previously stored table to determine any changes; sending a capabilities request from the host processor to the transceiver for the remote wireless device if the host processor determines the remote wireless device is new based on results of comparing the indexed bitmap table with a previously stored table.
60. The apparatus defined in Claim 59 further comprising the transceiver updating the list of devices in response to discovering the remote wireless device has been added to the wireless network.
61. The apparatus defined in Claim 56 wherein receiving the capability request from the host processor comprises: the host processor storing a capabilities request message in a first bank of the memory; the host process sending a control message to a second bank of the memory, the control message indicating to the transceiver that the information exists in the first bank for the transceiver; and the transceiver reading the capabilities request message from the first buffer.
62. The apparatus defined in Claim 56 wherein the devices are WirelessHD devices.
63. An article of manufacture having one or more computer-readable storage media storing instructions thereon which, when executed by an apparatus having a transceiver and a host processor in a wireless communication system, causes the apparatus to perform a device discovery process comprising: discovering a remote wireless device in a wireless network in the communication system; notifying, by the transceiver, the host processor of the remote wireless device; requesting, under control of the transceiver, capability information from the remote wireless device prior to receiving a request from the host processor for the capability information; buffering, under control of the transceiver, the capability information before the capability information is requested by the host processor; receiving a capability request from the host processor; and providing the host processor access to the capability information.
64. An apparatus for use in a wireless communication system for communicating with a wireless network, the apparatus comprising: a host processor; a transceiver; a physical interface coupling the host processor and the transceiver; and a memory accessible by the host processor and the transceiver to exchange information between the host processor and the transceiver, the memory having a plurality of banks that include: a first bank to store information being transferred from the host processor to the transceiver, and a second bank to store information being transferred from the transceiver to the host processor, the second bank being different than the first bank, to facilitate full-duplex communication of packet data between the host processor and the transceiver.
65. The apparatus defined in Claim 64 wherein the host processor is operable to store data in the first bank while the transceiver stores data in the second bank.
66. The apparatus defined in Claim 64, wherein the information stored by the host processor into the first bank of memory includes a connect request message for use in a connection control process, and the information stored by the transceiver into the second bank of memory includes a connect response message for use in a connection control process.
67. The apparatus defined in Claim 64 wherein the physical interface comprises an I2C bus.
68. The apparatus defined in Claim 64 wherein the full-duplex communication conforms to the WiHD packet structure.
69. The apparatus defined in Claim 64 wherein the memory includes a third bank, different than the first and second banks, to contain audio- video information registers to store AV information obtained by the transceiver from the wireless network regarding one or more devices in the wireless network and for use by the host processor.
70. The apparatus defined in Claim 69 wherein the transceiver stores a message indicating that AV information associated with the one or more devices is available and stores the AV information in the third bank for access by the host processor.
71. The apparatus defined in Claim 70 wherein the AV information comprises input format structure information and the message is a response regarding capabilities of the one or more devices.
72. The apparatus defined in Claim 69 further comprising a fourth bank to store control registers to control interactions between the host processor and the transceiver.
73. The apparatus defined in Claim 64 wherein, in order for the transceiver to send data to the host processor using the second bank, the transceiver stores one or more packets in one or more registers in the second bank and asserts a control signal to the host processor, and further wherein the host processor accesses the one or more registers in second bank to obtain the one or more packets in response to the control signal.
74. The apparatus defined in Claim 73 wherein the transceiver stores the one or more packets in the one or more registers simultaneously with asserting the control signal to the host processor.
75. The apparatus defined in Claim 64 wherein the physical interface further comprises a reset signal line and an interrupt signal line, wherein the interrupt signal line is used by the transceiver to send an interrupt to the host processor and the reset signal line is used by the host processor to reset the transceiver.
76. The apparatus defined in Claim 64 wherein the host processor and the transceiver have an I2C interface, and the physical interface coupling the host processor and the transceiver has an I2C bus coupled to the I2C interface of both the host processor and the transceiver.
77. A wireless communication system comprising: a remote wireless media device in a wireless network; and an apparatus for use in communicating with the remote wireless media device, the apparatus comprising a host processor; a transceiver; a physical interface coupling the host processor and the transceiver; and a memory accessible by the host processor and the transceiver to exchange information between the host processor and the transceiver, the memory having a plurality of banks that include: a first bank to store information being transferred from the host processor to the transceiver, and a second bank to store information being transferred from the transceiver to the host processor, the second bank being different than the first bank, to facilitate full-duplex communication of packet data between the host processor and the transceiver.
78. The wireless communication system defined in Claim 77 wherein the host processor is operable to store data in the first bank while the transceiver stores data in the second bank.
79. The wireless communication system defined in Claim 77 wherein the information stored by the host processor into the first bank of memory includes a connect request message for use in a connection control process, and the information stored by the transceiver into the second bank of memory includes a connect response message for use in a connection control process.
80. The wireless communication system defined in Claim 77 wherein the physical interface comprises an I C bus.
81. The wireless communication system defined in Claim 77 wherein the full-duplex communication conforms to the WiHD packet structure.
82. The wireless communication system defined in Claim 77 wherein the memory includes a third bank, different than the first and second banks, to contain audio-video information registers to store AV information obtained by the transceiver from the wireless network regarding one or more devices in the wireless network and for use by the host processor.
83. The wireless communication system defined in Claim 82 wherein the transceiver stores a message indicating that AV information associated with the one or more devices is available and stores the AV information in the third bank for access by the host processor.
84. The wireless communication system defined in Claim 83 wherein the AV information comprises input format structure information and the message is a response regarding capabilities of the one or more devices.
85. The wireless communication system defined in Claim 82 further comprising a fourth bank to store control registers to control interactions between the host processor and the transceiver.
86. The wireless communication system defined in Claim 77 wherein, in order for the transceiver to send data to the host processor using the second bank, the transceiver stores one or more packets in one or more registers in the second bank and asserts a control signal to the host processor, and further wherein the host processor accesses the one or more registers in second bank to obtain the one or more packets in response to the control signal.
87. The wireless communication system defined in Claim 86 wherein the transceiver stores the one or more packets in the one or more registers simultaneously with asserting the control signal to the host processor.
88. The apparatus defined in Claim 77 wherein the physical interface further comprises a reset signal line and an interrupt signal line, wherein the interrupt signal line is used by the transceiver to send an interrupt to the host processor and the reset signal line is used by the host processor to reset the transceiver.
89. The apparatus defined in Claim 77 wherein the host processor and the transceiver have an I2C interface, and the physical interface coupling the host processor and the transceiver has an I2C bus coupled to the I2C interface of both the host processor and the transceiver.
PCT/US2008/070093 2008-06-30 2008-07-15 Exchanging information between components WO2010002412A1 (en)

Applications Claiming Priority (14)

Application Number Priority Date Filing Date Title
US12/165,494 2008-06-30
US12/165,472 US8897719B2 (en) 2008-06-30 2008-06-30 Initializing a transceiver in a wireless communication system
US12/165,468 2008-06-30
US12/165,468 US9531986B2 (en) 2008-06-30 2008-06-30 Bitmap device identification in a wireless communication system
US12/164,907 US9264762B2 (en) 2008-06-30 2008-06-30 Dispatch capability using a single physical interface
US12/165,472 2008-06-30
US12/164,757 US20090327572A1 (en) 2008-06-30 2008-06-30 Exchanging information between components coupled with an a i2c bus via separate banks
US12/164,810 2008-06-30
US12/164,757 2008-06-30
US12/164,907 2008-06-30
US12/165,494 US20090327547A1 (en) 2008-06-30 2008-06-30 I2c bus compatible with hdmi
US12/164,810 US8116333B2 (en) 2008-06-30 2008-06-30 Connection control in a wireless communication system
US12/164,849 2008-06-30
US12/164,849 US8341271B2 (en) 2008-06-30 2008-06-30 Device discovery in a wireless communication system

Publications (1)

Publication Number Publication Date
WO2010002412A1 true WO2010002412A1 (en) 2010-01-07

Family

ID=39862998

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2008/070093 WO2010002412A1 (en) 2008-06-30 2008-07-15 Exchanging information between components

Country Status (1)

Country Link
WO (1) WO2010002412A1 (en)

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997036772A1 (en) * 1996-04-03 1997-10-09 Telectronics, Inc. Wide area vehicular control system operating over paging networks for foiling fleet and individual vehicle thefts and carjacking
US20030120763A1 (en) * 2001-12-20 2003-06-26 Volpano Dennis Michael Personal virtual bridged local area networks
EP1450515A2 (en) * 2003-02-18 2004-08-25 Hewlett-Packard Development Company, L.P. Wireless device imaging
WO2004086623A1 (en) * 2003-03-28 2004-10-07 Koninklijke Philips Electronics N.V. Electronically controllable rf switch
US20060128428A1 (en) * 2004-12-13 2006-06-15 Rooyen Pieter Gert W V Method and system for a mobile architecture that supports a cellular or wireless network and broadcast utilizing an integrated single chip cellular and broadcast silicon solution
EP1689126A1 (en) * 2005-02-08 2006-08-09 Alcatel Location service for use in a Wireless LAN
US20070050240A1 (en) * 2005-08-30 2007-03-01 Sensact Applications, Inc. Wireless Parking Guidance System
US20070171881A1 (en) * 2004-11-05 2007-07-26 Tao Zhang Autonomous and heterogeneous network discovery and reuse
US20080062178A1 (en) * 2006-09-11 2008-03-13 Aamod Khandekar Voip group resource management

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997036772A1 (en) * 1996-04-03 1997-10-09 Telectronics, Inc. Wide area vehicular control system operating over paging networks for foiling fleet and individual vehicle thefts and carjacking
US20030120763A1 (en) * 2001-12-20 2003-06-26 Volpano Dennis Michael Personal virtual bridged local area networks
EP1450515A2 (en) * 2003-02-18 2004-08-25 Hewlett-Packard Development Company, L.P. Wireless device imaging
WO2004086623A1 (en) * 2003-03-28 2004-10-07 Koninklijke Philips Electronics N.V. Electronically controllable rf switch
US20070171881A1 (en) * 2004-11-05 2007-07-26 Tao Zhang Autonomous and heterogeneous network discovery and reuse
US20060128428A1 (en) * 2004-12-13 2006-06-15 Rooyen Pieter Gert W V Method and system for a mobile architecture that supports a cellular or wireless network and broadcast utilizing an integrated single chip cellular and broadcast silicon solution
EP1689126A1 (en) * 2005-02-08 2006-08-09 Alcatel Location service for use in a Wireless LAN
US20070050240A1 (en) * 2005-08-30 2007-03-01 Sensact Applications, Inc. Wireless Parking Guidance System
US20080062178A1 (en) * 2006-09-11 2008-03-13 Aamod Khandekar Voip group resource management

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
CHAO-HUANG WEI, YUN-CHUNG LIN: "Implementation of Local Area Digital Audio Broadcasting System upon 12C Network", THE 47TH IEE INTERNATIONAL MIDWEST (CAESAR WONT ACCEPT JOURNAL NAME INVALID INPUT), 2004, XP002501659, Retrieved from the Internet <URL:http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=1354395&isnumber=29745> *
JEFFREY M. GILBERT CHINH H. DOAN SOHRAB EMAMI C. BERNARD SHUNG: "A 4-GBPS UNCOMPRESSED WIRELESS HD A/V TRANSCEIVER CHIPSET", IEEE MICRO, April 2008 (2008-04-01), XP002501657, Retrieved from the Internet <URL:http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=4523359&isnumber=4523348> [retrieved on 20081027] *
JEFFREY M. GILBERT, CHINH H. DOAN, SOHRAB EMAMI, C. BERNARD SHUNG: "A 4 Gbps Wireless True Uncompressed 1080p-Capable HD A/V Transceiver Using 60 GHz", HOT CHIPS 2007, 2007, XP002501658, Retrieved from the Internet <URL:http://www.hotchips.org/archives/hc19/3_Tues/HC19.06/HC19.06.01.pdf> [retrieved on 20081028] *

Similar Documents

Publication Publication Date Title
US8341271B2 (en) Device discovery in a wireless communication system
US8116333B2 (en) Connection control in a wireless communication system
US20090327572A1 (en) Exchanging information between components coupled with an a i2c bus via separate banks
US9264762B2 (en) Dispatch capability using a single physical interface
US9942379B2 (en) Wireless docking
US9426184B2 (en) Dockee-centric wireless docking
US6493104B1 (en) Data processing system and method for permitting a computer to automatically detect a presence of and establish a communications link with a printer
US10091826B2 (en) Wireless LAN connection handover by docking system and generic network device driver
JP4536827B2 (en) COMMUNICATION DEVICE, TELEVISION RECEIVER, AND REPRODUCTION DEVICE
WO2010107565A1 (en) Service discovery functionality utilizing personal area network protocols
US20140068727A1 (en) Wi-fi credential sharing using images
US9398065B2 (en) Audio/video streaming in a topology of devices with native WiGig sink
US6944704B2 (en) Method and apparatus for utilizing extended AV/C command frames including status inquiry, notify inquiry and control inquiry command types
US20110179462A1 (en) Communication device, communication method, recording medium, and integrated circuit
US9531986B2 (en) Bitmap device identification in a wireless communication system
US8897719B2 (en) Initializing a transceiver in a wireless communication system
US20090327547A1 (en) I2c bus compatible with hdmi
CN110113209B (en) MIPI (Mobile industry processor interface) protocol-based inter-device communication method and equipment topological structure
WO2010002412A1 (en) Exchanging information between components
JP2003102067A (en) Wireless communication device with state model
US8000278B2 (en) De-activation, at least in part, of receiver, in response, at least in part, to determination that an idle condition exists
WO2001031459A9 (en) Wireless universal serial bus system
US6757773B1 (en) System and method for determining support capability of a device coupled to a bus system
US20140177612A1 (en) Scalable wireless communication service discovery
WO2023004702A1 (en) Transmission rate determination method and communication apparatus

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08817425

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08817425

Country of ref document: EP

Kind code of ref document: A1