Timing Synchronization in WUSB Devices

INTRODUCTION

Wireless USB is an asynchronous Wireless standard which supports a high data transfer rate up to 480Mbps. WUSB Host-Device communication is based on DRP (Distributed Reservation Protocol) for TDMA type data communication. So Host gives the instructions to device along with the ‘time’ when that instruction has to be performed, such as transmission or reception. So in order to follow the timings of all the timing crucial instructions there should be synchronization between device and the host.

DETAILS ABOUT MMCs

Wireless USB defines a Wireless USB Channel which is encapsulated within a set of MAC Layer MAS reservations. The Wireless USB Channel is continuous sequence of linked application-specific control packets, called MMCs (Micro-scheduled Management Commands), which are transmitted by the host. MMCs contain time reference to the next MMC in the sequence. These links provide a continuous thread of control which can be simply followed by devices that join the Wireless USB Cluster. This encapsulated channel provides the structure that serves as the transmission path for data communication between a host and devices in a Wireless USB Cluster. The linked stream of MMCs is used primarily to dynamically schedule channel time for data communications between host applications and WUSB endpoints. An MMC specifies the sequence of micro scheduled channel time allocations (MS-CTAs) up to the next MMC within a reservation instance. It can be followed by another MMC without the existence of MS-CTAs between two MMCs in which the MMC is only used to convey command and control information.

TRANSACTION GROUP TIMING

The host orders individual transactions within transaction groups to minimize the number of ‘bus turns’ (e.g. turning the host’s radio from Transmit to Receive). A transaction group is constructed to have all the host Transmit protocol time slots immediately after the MMC, followed by a ‘bus turn’ and then all Device Transmit protocol time slots. Note there is another ‘bus turn’ between the last Device Transmit time slot and the next scheduled MMC packet.

An inter-slot time is the time between the end of the last packet transmission of one protocol time slot to the start of the next protocol time slot (or transmission of an MMC packet). In general, the intent of the inter-slot time is to ensure that transmissions between protocol time slots do not overlap. Inter-slot times must be long enough in duration to guard against the maximum clock drift between a device’s local clock and the ideal clock, which also provides general the method for calculating a guard time (tGUARDTIME).)

The ppm (parts per million) term depends on the clock rate of the PHY and the maximum drift is a function of the elapsed time since the last synchronization event (i.e. the interval). In order to minimize the effects of Guard Time on the available bandwidth, Wireless USB uses MMCs as clock synchronization reference points.

The first two protocol time slots indicate OUT (host to device) transmissions. Protocol time slots in a transaction group must be ordered OUT then INs, so the host is the transmitter of all the packets beginning from an MMC until the first IN protocol time slot. This looks in many respects like a burst transfer (supported in many PHY standards), although the recipient devices in adjacent protocol slots may be different for this application. For adjacent OUT protocol time slots, the minimum inter-slot time must be tINTERSLOTTIME. There is no need to add guard times between these consecutive OUT transactions (or between the MMC and the first OUT,) since the host is the transmitter of all these packets. The receiving device, however, must start listening at least a calculated guard time (tGUARDTIME) before the anticipated packet start time.

During device to host (IN) transactions, the minimum inter-slot time between successive IN transactions must be tINTERSLOTTIME plus tGUARDTIME since the IN time slots could potentially be used by different transmitters with drifting clocks.

When an MMC or OUT protocol time slot is followed by an IN protocol time slot, or an IN protocol time slot is followed by an MMC, then the minimum inter-slot time must be equal to the calculated guard time (tGUARDTIME) plus the host’s bus switch time (tBUSTURNTIME) which is a PHY-related timing parameter. The sum of these is the bus turn inter-slot time (tBUSTURNINTERSLOTTIME).The final components in calculating protocol slot time durations are the inter-packet gaps and size of preambles between packets in slots where multiple packets are transmitted. PHY standards may (or may not) define a minimum and maximum value for burst-mode inter-packet gaps and the use of streaming preambles (which can be shorter than standard preambles). When necessary, Wireless USB does define a maximum requirement for the streaming mode inter-packet gaps. The availability of streaming preambles is also a PHY-specific parameter.

PROTOCOL SYNCHRONIZATION

All Wireless USB Protocol timings are specified relative to the beginning of the preamble for the MMC packets.

Devices reset their protocol clocks to zero at the beginning of an MMC preamble. All channel time offsets (Next MMC and WXCTA time slot allocations) in the MMC are specified by the host relative to the start of the preamble for the current MMC. A device may idle its radio after the MMC packet and the Start Time for time slots it is designated to be either a Transmitter or Receiver. When designated as a Transmitter, the device (or host) must begin transmitting its preamble at the point it determines the start of the time slot (or MMC), measured from the beginning of the last MMC packet based on its local clock. When designated as a Receiver, the device (or host) must begin listening at least a calculated guard time (tGUARDTIME) before the point it determines the start of the time slot, based on its local clock Wireless USB devices preserve the integrity of allocated time slots. For IN protocol time slots, this means that the device must not transmit before its local clock indicates the start of its time slot. For OUT protocol time slots, the device may turn off its receiver when its local clock indicates the adjacent protocol slot start time (unless the adjacent slot time is for a different endpoint on the same device). Devices derive the slot boundaries from the WCTA_IE information in the IE. The WXCTAs must always be provided in order, which means the device can derive the slot boundaries based on its WXCTA’s wStart field and the wStart field of the next (adjacent) WXCTA. This means that the host must always provide an ‘end of list’ WXCTA in an MMC, which always provides a termination of WXCTA. Wstart fields for ‘real’ endpoint transaction.

The ‘end of list’ WXCTA must be the last WXCTA block in a WCTA_IE. The ‘end of list’ WXCTA block must not be interpreted as a WXCTA for use with a valid Function Endpoint. In the case were the last WXCTA before the EOL WXCTA is a WDRCTA then the next MMC time must be at least a calculated guard time (tGUARDTIME) larger than the wStart value of the EOL WXCTA. In the case of a WDTCTA before the EOL WXCTA, the next MMC time must be at least tBUSTURNTIME + tGUARDTIME larger than the wStart value of the EOL WXCTA. Note that larger in this context must accommodate appropriately for channel time rollover conditions.

ARCHITECTURE

• PHY ACTIVE TIMER
  This block performs the task of calculating the delay since the Phy is active i.e. Phy has received the packet till MMC found is detected and asserted by the MMC decoding logic present in the Protocol Engine. Phy Active asserts every time the Transmission or Reception is there at the Phy End. So, in the case of reception if the received packet is an MMC, then this counter maintains the time since the packet was received at the Phy end till the detection of that particular frame as MMC.
• TIMING COMPONENT
  Once the frame type is confirmed by the Protocol Engine, the role of Timing Component starts, the counted value of the Phy Active timer is loaded to Timing Component and now it is the responsibility of Timing Component to provide the timing with reference to beginning of the MMC.
• WUSB TIMER
  This timer maintains the global timings as issued by the HOST in every MMC in terms of Channel Timestamp. Every time the new Channel Timestamp is issued, the new value is loaded and counting will begin from that value.
• TRUST TIMEOUT COUNTER
  Device must not trust the data communications with its host whenever it loses communications for greater than Trust Timeout. When a device does not observe WUSB broadcast packets (e.g. MMCs) from its host for a trust timeout period, it must cease responding to any data transactions and transition to the re-connecting device state. Every time the mmc_found signal is asserted by the PE, then this counter refreshes else the process of counting the number of milliseconds is continued. This counter is used to count the time since the reception of Authenticated Data. After this time is expired the Device should not trust the Host.
• MAS SLOT
  The duty of the MAS slot block is to compare all the timing related parameters issued in the MMC and by comparing them with their respective timer to produce enables to other functional blocks of the Device as MAC and Protocol Engine. Sensing these enables, the other blocks start their mentioned process like transmission, reception, channel switch and channel stop at the time decided by the Host.

Timing Handover Mechanism Between different Counters:

Timing Hand over Technique
There are two timing handovers happen till the WUSB counter is updated. First hand over mechanism occurs between PhyActive Timer and TimingComponent counter whenever the assertion of MMC found is sensed, second occurs between TimingComponent and WUSB counter whenever the assertion of Valid_timestamp is sensed. So, it may happen that at the instant MMC found or valid timestamp is sensed, the value of timer count may be having a microsecond and some residual clocks. So, these values may create trouble in synchronization if left un-added.

But the adder specially to add Pclk means increasing hardware, so there is one possible solution to this problem.

Technique to reduce the hardware by avoiding the adders
As soon as the mmc found or valid timestamp is asserted see if the values given by them are proper without having any residues. If not then let the counter counting until it reaches to a proper value without any residues, once it reaches to a proper value then only the handover mechanism should occur.

This method avoids adders specially for adding residual Pclk values.

CONCLUSION

With the help of Device Timer block design can achieve Protocol Timing synchronization and also reduction in the complexity and thus the hardware of other blocks because all the timing enables generations are dedicated to this block, which further makes a ease of debugging the design.

Feedback