DigRF Standard v3.09

DigRF DUAL-MODE 2.
5G / 3G BASEBAND / RF IC INTERFACE STANDARD
22 November 2006 Version: 3.09
DigRF Working Group
DigRF Working Group
REVISION HISTORY
Version Change Summary 3.03 Imported from framework v003, updated after Apr 05 meeting 3.04 Membership list updated, internal reference corrected 3.05 Updated during 16/17 May meeting and subsequently 3.06 Updated during 15/16 June meeting and subsequently; logos included; final draft 3.07 Updated with corrections needed (mostly editorial and formatting) after 15/16 June meeting. Panasonic and Sirific logos corrected, M/A-Com and NEC logos added. 3.08 Updated with corrections needed after 8 June meeting. Updated sections 5.1, 5.3.1, 5.3.7.1, 5.4.1.2, 6.2.13, 6.2.14 and 7.1. Added section 5.3.4. Removed section 5.3.2.3. Added minor clarifications throughout the document. Removed TTPCom and Tropian Logos. 3.09 Updated with corrections needed after 9/10 November meeting. Updated sections 1.4, 2, 4.3, 5.3.1, 5.3.3.2, 5.3.4, 5.3.7, 5.3.7.1, 5.3.7.2, 6.2.13, 6.2.14, 7.1, 8.6. Added sections 6.2.15, 8.5, 8.10. Added minor clarifications throughout the document. Updated logos.
Date 28/04/2005 09/05/2005 23/05/2005 21/06/2005 25/07/2005
Author AF AF AF AF AF
07/07/2006
WK1
14/11/2006
WK1
Internal reference : DOCMAN - #34227
DigRF Working Group
CONTENTS
PAGE
INTRODUCTION 1.1 1.2 1.3 1.4 Background Purpose Scope References
10 10 10 10 11 12 12 13 13 13 13 13 14 17 17 17 18 19 19 20 20 22 22
INTELLECTUAL PROPERTY 2.1 2.2 2.3 2.4 2.5 2.6 Working Group Terms of Use of this Specification Disclaimer Cross-Licensing Terms Source and Validity Corrections and Improvements
3 4
GLOSSARY AND ABBREVIATIONS OVERVIEW 4.1 4.2 4.3 4.4 4.5 4.6 4.7 General Scope Applications Principles Signals Physical Layer Protocol
PHYSICAL LAYER 5.1 General
CONTENTS
PAGE
5.2
Block Diagrams 5.2.1 5.2.2 Basic Handset Diversity 5.2.2.1 5.2.2.2 5.2.2.3 Local (Handset) Diversity Remote Rx MIMO (for future use)
23 23 24 24 26 27 28 28 28 28 28 29 29 29 30 30 30 31 31 31 32 32 36 36 37 37 37 37 38 38
5.3
Pin Visible Signals 5.3.1 5.3.2 Output Voltage Swings SysClkEn/InterfaceEn 5.3.2.1 SysClkEn Function 5.3.2.2 InterfaceEn Function 5.3.2.3 Electrical Characteristics of Single-Ended Signals SysClk 5.3.3.1 5.3.3.2 TxData 5.3.4.1 5.3.4.2 RxData 5.3.5.1 5.3.5.2 Function Clock Characteristics Function Waking Up the TxData Interface Function Waking Up the RxData Interface
5.3.3
5.3.4
5.3.5
5.3.6
TxData/RxData Common Characteristics 5.3.6.1 Sleep Mode 5.3.6.2 Shutdown Mode
5.4
Internal Interface Blocks 5.4.1 High Speed Clock Generator 5.4.1.1 Function 5.4.1.2 Electrical Characteristics Receive Time Alignment 5.4.2.1 Function
5.4.2
CONTENTS
PAGE
PROTOCOL 6.1 6.2 Overview Frame Structure 6.2.1 6.2.2 6.2.3 6.2.4 6.2.5 6.2.6 6.2.7 6.2.8 6.2.9 General Sync Field Frame Type Field Payload Size Coding Logical Channel Type Coding CTS Bit Payload Field Link Startup Synchronisation Low-Speed Mode
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40
6.2.10 Synchronisation Medium-Speed Mode 6.2.11 Synchronisation High-Speed Mode 6.2.12 Clock Mode Change 6.2.12.1 Slow to Fast 6.2.12.2 Fast to Slow 6.2.13 Interface Control Logical Channel 6.2.14 Time Accurate Strobe Logical Channel 6.2.15 Interface delay requirements 6.2.15.1 TAS command 6.2.15.2 Interface Control 6.2.15.3 Interface startup 7 APPLICATIONS 7.1 General: 3GPP Data Formats 7.1.1 7.1.2 3G Rx Data 2.5G Rx Data
CONTENTS
PAGE
7.1.3 7.1.4 7.2 8
3G Tx Data 2.5G Tx Data
40 40 40 40 40 40 40 40 40 40 40 40 40 40
3GPP Profiles
SUPPLEMENTARY INFORMATION 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9 8.10 High Reliability Link Strategy Payload Construction Power Saving in Sleep Mode RF IC FIFO Size Recommendations RxData Interface Scheduling TxData/RxData Interface Mode State Machines Frequency Plan RxData/TxData Driver Design Interface Data Rate Transitions Interface Signal Order Recommendation
Page 10 of 66
INTRODUCTION
1.1
Background
In June 2003 the DigRF Working Group published the first version of the DigRF standard, defining an interface between next-generation baseband and RF ICs for 2.5G (EGPRS) GSM terminals. A slightly revised version was published in February 2004. It was stated in those versions of the standard that later editions would move on to address 3G; that is the objective of this new edition. The Working Group continues to believe that a publicdomain standard is in the best interests of all concerned, and hopes (encouraged by the interest in the 2.5G version of the standard) that once again sufficient companies will use the interface to make it the de facto standard for dual-mode or pure 3G systems. As can be seen from Section 2, membership of the group has expanded considerably for this new effort, thereby demonstrating the level of support in the industry for this endeavour. 1.2 Purpose
The purpose of this document is to describe the logical, electrical and timing characteristics of the "DigRF" 3G Digital BB/RF Interface with sufficient detail to allow physical implementation of the interface, and with sufficient rigour that implementations of the interface from different suppliers are "plug and play" compatible at the physical level. This version of the document addresses dual-mode 3GPP 3G/2.5G (UMTS/EGPRS) implementations; later versions of the document will extend the coverage to later versions of 3G and perhaps to other standards. Every effort has been made to retain flexibility where this does not compromise compatibility or cost, thus leaving many design choices within the baseband and RF IC implementations. 1.3 Scope
This specification confines its attention to the physical interface between the baseband and the RF IC. This specification does not attempt to be a system design specification for mobile terminals; the Working Group acknowledges that there are system-level design choices which could prevent the plug and play objective from being achieved. However, to attempt to specify at that level would stifle technical innovation between vendors and in any case was beyond the resources of the group. This specification therefore does not prescribe anything within either chip, save for the minimum necessary to ensure compatibility at the physical level. For instance, the control interface between
INTRODUCTION
3G DigRF v3.09 DigRF Working Group
Page 11 of 66
baseband and RF IC is assumed to be register-based, but in most modes of operation nothing is specified about the use of the frame payload and so there is great flexibility in the design of the RF IC. The intention is to leave chip designers the freedom to seek competitive advantage within the chips, while ensuring that chips compliant with this specification can always work together when correctly configured. 1.4 References
www.3GPP.org 3GPP TS 25.101: UE Radio transmission and reception (FDD) 3GPP TS 25.133: Requirements for support of radio resource management (FDD) 3GPP TS 25.211: Physical channels and mapping of transport channels onto physical channels (FDD) 3GPP TS 25.212: Multiplexing and channel coding (FDD) 3GPP TS 25.213: Spreading and Modulation (FDD) 3GPP TS 25.214: Physical layer procedures (FDD) 3GPP TS 25.215: Physical Layer Measurements (FDD) 3GPP TS 25.302: Services provided by the Physical Layer 3GPP TS 25.331: RRC Protocol Specification www.digrf.com DigRF 2.5G Interface Standard www.jedec.org JESD96 (Radio Front End-Baseband (RF-BB) Interface Spec) JESD8-13 (Scalable Low-Voltage Signaling for 400 mV (SLVS-400)) www.eia.org TIA/EIA-644-A (Electrical Characteristics of Low Voltage Differential Signaling (LVDS) Interface Circuits
INTRODUCTION
Page 12 of 66
INTELLECTUAL PROPERTY
2.1
Working Group
The Working Group consists of representatives of the following companies (in alphabetical order, no priority implied): Agere Systems Agilent Technologies Analog Devices Axiom Micro Devices BitWave Semiconductor Broadcom ChipIdea Semiconductors Freescale Semiconductor Inc. Icera Inc. Infineon Technologies Intel M/A-Com Semiconductor Company, Matsushita Electric (Panasonic) Marvell Maxim Integrated Products Motorola NEC Nokia NXP Renesas Technology Corp RF Micro Devices Rohde & Schwarz Sequoia Communications Silicon Laboratories Sirific Wireless Skyworks Solutions Inc. Sony Semiconductor and Electronic Solutions Division Stepmind ST Microelectronics Texas Instruments Inc.
Page 13 of 66
2.2
Terms of Use of this Specification
The Working Group, as a group, makes no charge for the use of this standard by designers and manufacturers. No rights to the content of the standard accrue to the user. This specification is provided "as is", and users employ it at their own risk. 2.3 Disclaimer
No guarantee is made or implied by the member companies of the Working Group jointly or severally that this document does not infringe any Intellectual Property rights. If any infringement occurs and is pursued, each user of the specification must make their own commercial arrangements with the IP holder. The Working Group companies accept no liability of any kind arising from the use of this specification, to the extent that such exclusion is allowed by applicable law. 2.4 Cross-Licensing Terms
Cross-licensing terms can be found in the IPR agreements on the Web at www.digrf.com . 2.5 Source and Validity
The master copy of this document is available on the Web at www.digrf.com from where it may be downloaded. Copies or derivatives of this document from any other source are not authoritative. It is the user's responsibility to ensure that they are using the latest version of the standard as a basis for design and implementation. 2.6 Corrections and Improvements
In the event that a user discovers an error in the specification, or has a suggestion for improvement in future versions of the specification, the Working Group would be pleased to be informed. Contact information can be found on the Web at www.digrf.com .
Page 14 of 66
GLOSSARY AND ABBREVIATIONS
Baseband (BB) The IC or subsystem which has overall control of the terminals air interface and is responsible for transmit data generation and receive data demodulation and processing. CTS Bit (CTS = Clear To Send) A bit in frame headers on the RxData interface used for transmit data flow control on the TxData interface. Frame One complete unit of information transmission across either the TxData interface or the RxData interface. A frame consists of a Sync Word, a Header and a Payload. Header The third byte of a Frame, containing information on Logical Channel Type and Payload Size for this frame, plus in the RxData interface a flow control bit. InterfaceEn The wire (signal) used to enable second and subsequent sets of Tx/RxData interfaces in chipsets providing more than one set. This signal is single-ended and active high. Line Driver (LD) The element in the Baseband (TxData interface) or the RF IC (RxData interface) that electrically drives the interface wires. Line Receiver (LR) The element in the RF IC (TxData interface) or the Baseband (RxData interface) that converts the differential analog signal arriving on the interface wires to a single-ended digital signal. Logical Channel Type The TxData and RxData interfaces are unidirectional physical interfaces, both of which carry several logically distinct information flows multiplexed together in time. The Logical Channel Type of a Frame defines what type of information it contains. Payload All but the first three bytes of a Frame; the part of the Frame which carries the information being sent across the interface.
Page 15 of 66
RF IC The IC or subsystem responsible for translating transmit data from the digital representation supplied by the Baseband into an analog RF signal for transmission, and for converting the incoming RF signal received at the antenna into a digital form suitable for processing in the Baseband. RxDataN One of the two wires (signals) in the RxData interface. When RxDataN is at a higher voltage than RxDataP, a logic 0 is being signalled. RxDataP One of the two wires (signals) in the RxData interface. When RxDataP is at a higher voltage than RxDataN, a logic 1 is being signalled. Sync Word The first two bytes of a Frame, containing a fixed bit pattern used for clock phase acquisition in the Line Receiver. SysClk The wire (signal) which carries the System Clock from the RF IC to the Baseband. SysClkEn The wire (signal) from the Baseband to the RF IC that instructs the RF IC to drive System Clock to the Baseband. It also has some ancillary functions. This signal is single-ended and active high. System Clock The fundamental clock signal from which the interface clocking and many other system clocks are derived. Generated in the RF IC. TAS Abbreviation for Time Accurate Strobe (Logical Channel). TxDataN One of the two wires (signals) in the TxData interface. When TxDataN is at a higher voltage than TxDataP, a logic 0 is being signalled. TxDataP
Page 16 of 66
One of the two wires (signals) in the TxData interface. When TxDataP is at a higher voltage than TxDataN, a logic 1 is being signalled. VDD The variable VDD is used to calculate output voltage swing and input threshold specifications. Note that VDD does not necessarily refer to the supply Voltage.
Page 17 of 66
OVERVIEW
4.1
General
This version of the DigRF standard covers dual-mode 3GPP 3G/2.5G (UMTS/EGPRS) mobile terminals where both modes of operation are supported over a common interface. It can of course be used for single-mode 3G terminals; single-mode 2.5G terminals are covered by v1.12 of the standard but can also use this standard. The standard defines the interface between the baseband IC and the RF IC(s) in a mobile terminal. The interface is intended to be efficient and flexible, accommodating many variations in the overlying system design while providing guaranteed interworking at the interface level between compliant ICs. 4.2 Scope
The standard covers the electrical, logical and protocol aspects of the interface; it attempts to define all aspects of the interface that need to be specified to allow ICs from different vendors to interoperate, given suitable RF IC driver software on the baseband. The standard is not a system design specification; it avoids defining anything inside either the baseband or RF ICs that does not need to be specified to ensure correct operation of the interface (and only of the interface). This does not preclude the possibility that basebands and RF ICs from different vendors may be incompatible at the system level, but such concerns are beyond the scope of this document. It is explicitly expected that different RF ICs will require different driver software on the baseband IC, sometimes very different. As the Working Group began the development of this version of the standard, backwards compatibility with the 2.5G version was stated to be desirable. However, as work progressed, it became clear that in order to accommodate the simultaneous transmit and receive that is part of 3G, together with 3G data rates, the data part of the interface would need very significant changes compared to the 2.5G spec. Pin count considerations then motivated removal of the 3-wire control interface and multiplexing of control information into the data interfaces. Many 2.5G implementations made no use of the Strobe signal, so pin count considerations again motivated its removal. This means that this version of the standard is not backwards compatible with v1.12, but the Working Group believes that this is a price worth paying to achieve a very efficient dual-mode design. Here is a top-level block diagram of the interface and system arrangement:
OVERVIEW
Page 18 of 66
BaseBand Modn TX Symbol I&Q Configuration and Control RX Symbol I&Q RFIC responses Interface DigRF_3G
TX path
RFIC(s) 2GTX 3GTX
SRRC Bandlimiting
RX path
DigRF_3G Interface
SRRC Matched Filter
3GRX 2GRX
SysClk SysClkEn
filter
Crystal
Figure 1: Top-Level Block Diagram
For dual-mode 2.5G / 3G applications the SRRC filters are located in the RF IC in both the transmit and receive paths. This configuration was chosen to yield a well-defined interface between the baseband and the RF IC with optimised data precision.
4.3
Applications
This version of the DigRF standard is designed to support the following features: 2.5G GPRS/EGPRS (all multi-slot classes) Release 5, 6, 7 FDD UMTS: o HSDPA (downlink data, 16QAM mode) o HSUPA (E-DCH) o Non Compressed Mode o Compressed Mode o RX diversity (2+ receivers) 19.2, 26.0 and 38.4MHz fundamental system clocks
OVERVIEW
Page 19 of 66
As the 3GPP standards for these items stabilise, this standard will also be updated to support: MIMO LTE Wi-Max
The standard attempts not to preclude later development to incorporate other wireless communication standards as they become relevant. 4.4 Principles
The Working Group applied the following criteria to proposals for the design of the interface: Subject to the need to support the features listed above, minimise interface pin count minimise overall interface power consumption provide a very reliable physical layer so error correction and detection are not needed specify only what is needed to achieve interface physical layer compatibility between basebands and RF ICs from different manufacturers. 4.5 Signals
The interface requires six physical signals (wires): SysClk (RF IC to BB) SysClkEn/InterfaceEn (BB to RF IC) TxDataP (BB to RF IC) TxDataN (BB to RF IC) RxDataP (RF IC to BB) RxDataN (RF IC to BB)
More details of these will be given in later Sections of this document, but in summary SysClk is the fundamental system clock from the master oscillator in the RF subsystem, SysClkEn is the enable line for SysClk driven by the baseband when SysClk is required, TxDataP/N are the differential Tx control/data interface from the baseband to the RF IC and RxDataP/N are the differential Rx status/data interface from the RF IC to the baseband. See the block diagrams in Section 5.2.
OVERVIEW
Page 20 of 66
4.6
Physical Layer
The TxData and RxData interfaces are low-swing controlled-impedance differential pairs. They are designed to provide very reliable data transfer at high data rates while minimising power consumption and unwanted emissions. These interfaces support the following data rates: Interface TxData TxData RxData RxData RxData Data rate SysClk/4 312Mbps SysClk/4 SysClk 312Mbps Operating Mode Startup/fallback, 2.5G Tx 3G/2.5G Tx Startup/fallback 2.5G Rx 3G Rx, 2.5G/3G dual-mode Rx, 2.5G/3G Rx diversity, 2.5G Rx
Table 1: Interface Data Rates and Operating Modes
The SysClk signal is a single-ended signal, as is SysClkEn/InterfaceEn (see Sections 5.3.2 and 5.3.3). The interface allows both terminated and unterminated operation of the TxData and RxData interfaces. Unterminated operation is generally used when the physical interface is short (a few cm); terminated operation is primarily intended for use when the physical interface has to traverse a relatively large distance (tens of cm, say, as for instance in the case of diversity receivers located on opposing corners of a laptop PC), but may be used whenever the designer requires it. Where basebands provide more than one TxData/RxData interface pair, one pair shall be designated as the primary data interface. The RF subsystem shall always enable the primary TxData interface each time SysClkEn is asserted, to allow initialisation of the RF subsystem. Secondary TxData/RxData interface pairs provide the InterfaceEn signal rather than SysClkEn this is explained later in the document. 4.7 Protocol
The interface protocol uses a simple frame structure providing the following:
OVERVIEW
Page 21 of 66
a fixed synchronisation sequence for interface clock phase recovery at the start of every frame a fixed-size frame type field to allow optimisation of the frame length and its handling a payload field.
The frame type field has three subfields: a Logical Channel type for the frame, which indicates the purpose of the frame to the IC receiving it a payload length code (which also defines the length of the whole frame) a signalling bit (in the Rx interface only). Except in the case of the Interface Control Logical Channel type and the Data Logical Channels, how the payload field is used for any given Logical Channel type is RF ICspecific; this standard places constraints on the content of the payload field only where necessary to achieve interface compatibility.
OVERVIEW
Page 22 of 66
PHYSICAL LAYER
5.1
General
Clock is distributed between the baseband and RF ICs at the System Clock frequency to minimize the generation of spurious signals. High speed clock signals are generated locally within each IC, to be used for both transmission and reception of information across the high speed interface. To maintain high speed interface robustness, the relative frequency error allowed is limited. Synthesizing both high speed clocks from the same reference (see section 8.7) assures this. There will be no hardware Strobe signal in the 3G DigRF interface accurate timing will be conveyed via the Tx data interface by means of a suitable frame-scheduling algorithm (implementation is vendor-specific in both the baseband and the RF IC) (see Section 6.2.14). Some implementations of v1.12 of this standard (2.5G DigRF) used accurate control interface message timing rather than employing the Strobe signal so there is precedent for this. The baseband shall be able to transmit frames on the data interface in precise timing so as to not use up the entire overall timing error budget. The implementation method for this is baseband-specific.
PHYSICAL LAYER
Page 23 of 66
5.2 5.2.1
Block Diagrams Basic Handset

RX Stream (Data + Status) LR LD RX Stream
TA DeMUX Control TX Data
TX Stream (Data + Control)
LD
LR
TA
Clk mult
SysClk SysClkEn
Clk mult SysClk driver
Baseband
d
RFIC
TA : Time Alignment LD : Line Driver LR : Line Receiver
Figure 2: Basic Handset
The handset format is envisioned as a physically small, compact implementation, with the baseband within a few cm of the RF IC. In situations where only the Rx chain is operational it shall be possible to run the Tx interface at low (SysClk/4) rate irrespective of the prevailing data rate on the Rx interface.
PHYSICAL LAYER
Page 24 of 66
5.2.2 5.2.2.1
Diversity Local (Handset) Diversity

RX Stream 2 LR TA TX Stream 2 (Control) LD
InterfaceEn
LD
RX Stream 2
LR TA
Control 2
RX Stream 1
LR TA
LD
RX Stream 1
TX Stream 1 (Data + Control)
LD
LR TA
DeMUX
Control 1 TX Data
Clk mult
SysClk SysClkEn
Clk mult
Baseband
d1
SysClk driver
RFIC
Figure 3: Local (Handset) Diversity, Separate Interfaces
Where the baseband supports Rx diversity via two (or more) separate RxData interfaces it shall provide a corresponding full-spec physical Tx interface for each physical Rx interface, plus an InterfaceEn signal for each of the second and subsequent Tx interfaces. Where the RF IC provides a diversity receiver as well as a full transceiver it is permissible for the diversity receivers control and data streams to be multiplexed over a single Tx and a single Rx interface (see Figure 4). In situations where only the Rx chain is operational it shall be possible to run the Tx interface at low (SysClk/4) rate irrespective of the prevailing data rate on the Rx interface.
PHYSICAL LAYER
Page 25 of 66
For diversity receivers the second Tx port will typically operate at low (SysClk/4) rate for control purposes only.
RX Stream 2 RX Stream 1
DeMUX
LR TA
LD
MUX
RX Stream 2 RX Stream 1 Control
LD
LR TA
DeMUX
Control TX Data
Clk mult
SysClk SysClkEn
Clk mult
Baseband
d1
SysClk driver
Dual-RX RFIC
Figure 4: Local (Handset) Diversity, Multiplexed Interface
For the avoidance of doubt, if a single RF IC provides a diversity receiver in addition to a full transceiver, it is permissible for such an IC to use a single Tx interface and a single Rx interface for both receivers, as in this case the two receivers will have distinct register address maps.
PHYSICAL LAYER
Page 26 of 66
5.2.2.2
Remote Rx
RX Stream 2
LR TA d2
LD
RX Stream 2
Remote
LR Control Clk mult d3 LD RX Stream 1
Control Stream
LD
InterfaceEn
RX
TA
SysClk / 4 RX Stream 1 LR TA De MUX
Control TX Data
LD
LR TA
Clk mult
SysClk SysClkEn
Clk mult
Baseband
SysClk driver
d1
RFIC
Figure 5: Remote Rx Diversity
The remote receiver format is envisioned as a physically large, distributed implementation where a diversity receiver is remotely located some distance away from the primary transceiver, for example in a laptop computer. Since long digital links are preferable to long antenna connections, this configuration implies the use of two separate RF ICs and two sets of Rx/Tx Data interfaces.
PHYSICAL LAYER
Page 27 of 66
5.2.2.3
MIMO (for future use)

RX Stream 2 LR TA TX Stream2 LD
InterfaceEn
LD d2 LR TA
RX Stream 2 De MUX Clk mult Control TX Data
(Data + Control)
Remote TRX
RX Stream 1
LR TA
LD
RX Stream 1
TX Stream1 (Data + Control)
LD
LR TA
De MUX
Control TX Data
Clk mult
SysClk SysClkEn
Clk mult
Baseband
d1
SysClk driver
RFIC
Figure 6: MIMO Configuration Future terminals may employ Tx diversity as well as Rx diversity (MIMO). Even in the 2.5G case this will require the Tx interface(s) to operate at full data rate. Full details of interface operation for MIMO applications have not yet been decided; the figure is given to illustrate the physical configuration that may apply. Note that the RF IC and Remote transceiver may be a large distance from each other as well as from the Baseband.
PHYSICAL LAYER
Page 28 of 66
5.3 5.3.1
Pin Visible Signals Output Voltage Swings
The variable VDD is used to calculate output voltage swing and input threshold specifications. Baseband and RF ICs may be compliant with VDD = 1.2 +/- 5% and/or 1.8 +/- 5%. The system designer must ensure that the specifications are consistent among the integrated circuits used. Output logic swing and input threshold specifications may be revised in future versions of this standard to track technology changes. 5.3.2 5.3.2.1 SysClkEn/InterfaceEn SysClkEn Function
This signal is a control from the baseband to the RF IC to enable the SysClk signal on the interface. This signal will typically be generated by the reset / startup sequencing circuitry in the baseband. The primary TxData interface line receiver on the RF IC shall always be enabled when SysClkEn is asserted (active high). Negation of SysClkEn shall cause the RF IC to leave Loopback mode (see Section 6.2.13 ), Clock Test Mode (see Section 6.2.13 ) and Sleep mode (see Section 5.3.6.1) if it was previously in any of those modes, and shall force the RxData and TxData interfaces into Shutdown mode (see Section 5.3.6.2). SysClkEn is associated with the primary TxData/RxData interface pair only. 5.3.2.2 InterfaceEn Function
This signal has identical functionality to SysClkEn save that it does not enable or disable SysClk. It is provided and associated with all TxData interfaces other than the primary one. Basebands must provide a separate InterfaceEn signal for all TxData interfaces other than the primary one; however, RF ICs may optionally use other methods to enable and disable secondary receivers/transceivers (for example, control via the primary TxData interface).
PHYSICAL LAYER
Page 29 of 66
5.3.2.3
Electrical Characteristics of Single-Ended Signals
SysClkEn and InterfaceEn are single-ended CMOS. Levels as follows: Symbol Inputs VIH VIL CIN Outputs VOH VOH VOL VOL tR, tF Parameter Test Condition IOH=-100A IOH=-2mA IOL=100A IOL=2mA 10% to 90% CLOAD=15pF Limits Min 0.65VDD* -0.3 Max VDD*+0.3 0.35VDD* 6 V V pF V V V V ns Unit
Input high voltage Input low voltage Input capacitance Output high voltage Output high voltage Output low voltage Output low voltage Rise/Fall time
VDD*-0.1 0.75VDD* 0.1 0.25VDD* 5
Table 2: Single-Ended Voltage Levels * Note: VDD may be 1.2 +/- 5% or 1.8 +/- 5%; see section 5.3.1
5.3.3 5.3.3.1
SysClk Function
SysClk is the master reference clock for both the baseband and RF IC, from which all other interface clocks (as well as, in practice, most system clocks and local oscillators) are derived. SysClk is provided to the baseband continuously while SysClkEn is asserted. The RF subsystem (irrespective of how many receivers or transmitters it contains) shall always provide a single SysClk signal to the baseband. SysClk generation and distribution within multiple Rx/Tx RF subsystems is vendor-specific. The RF IC designer shall choose which single SysClk frequency it uses from the three permitted options (see next Section); the baseband must support all three of the allowed frequencies (with appropriate initialisation at startup).
PHYSICAL LAYER
Page 30 of 66
5.3.3.2
Clock Characteristics
The SysClk signal shall be single-ended and slew-rate limited. Nominal frequencies: 19.2, 26.0, 38.4MHz SysClk Specification Condition/Note Frequency error** Duty Cycle Vout Peak to peak Load impedance Parallel C Parallel R Integrated (single sideband) phase 19.2MHz noise in 10KHz-10MHz*** 26MHz 38.4MHz Min -1 45 0.8 Max +1 55 VDD* 10 10 -58 -55 -52 Unit % % V pF k dBc dBc dBc
Table 3 Clock Characteristics at SysClk buffer output * ** *** Note: VDD may be 1.2 +/- 5% or 1.8 +/- 5%; see section 5.3.1 Note that other system considerations may require better accuracy than this. Note that this is to comply with the 312Mbps mode jitter specification to ensure reliable interface operation; other system considerations may mandate better performance.
It is recommended that SysClk is slew rate limited. 5.3.4 5.3.4.1 TxData Function
The TxData interface carries both transmit data and RF IC control information from the BB to the RF IC, in appropriate Logical Channels in each case (see Section 6). There is no separate control interface. Support of legacy 2.5G RF ICs requires the separate provision of a v1.12 DigRF interface on the baseband; this is optional. The TxData interface has two speed modes: low-speed mode (bit rate SysClk/4) for startup, control-only operation, and 2.5Gonly data transfer high-speed mode (bit rate 312Mbps) for Tx data transfer and, typically, multiplexed RF IC control information.
PHYSICAL LAYER
Page 31 of 66
Both RF IC and baseband shall initialise the interface in low-speed mode. For the avoidance of doubt, while the low-speed interface bit rate is SysClk/4, SysClk itself shall continue to run at the standard rate, providing 4x oversampling of the data interface (8x if both clock edges are used) with no need for clock multiplication. Where more than one TxData interface is provided on a baseband, one instance shall be designated the primary TxData interface; this instance shall be associated with the SysClkEn signal. All other instances of the TxData interface shall provide a corresponding InterfaceEn signal. See Section 5.3.2. 5.3.4.2 Waking Up the TxData Interface
The line receiver on the RF IC shall always be enabled when SysClkEn/InterfaceEn is asserted. The data decoder behind the receiver need not be enabled at this point; it can be enabled when the first transition on the data lines is detected by the receiver. The receiver in this mode is only required to operate at SysClk/4. This allows the BB to program and activate the RF IC at any time while SysClk is running. TxData interface speed changes shall be commanded by the baseband. Exit from Sleep mode, where implemented, is triggered by the assertion of 0 before the start of the new frame as described in Section 5.3.6.1. 5.3.5 5.3.5.1 RxData Function
The RxData interface transfers received data from the RF IC to the baseband. If the RF IC supports register read functions or provides unsolicited status information, or uses a higher-level two-way control protocol, the RxData interface also carries such information from the RF IC to the baseband in exactly the same way as the TxData interface is shared between Tx data and RF IC control transfer. Again, see Section 6 for the Logical Channels to be used. The RxData interface has three speed modes: low-speed mode (bit rate SysClk/4) for startup and status-only operation medium-speed mode (bit rate SysClk) for 2.5G-only operation high-speed mode (bit rate 312Mbps) for 3G or dual-mode Rx data transfer and, typically, multiplexed RF IC status information.
PHYSICAL LAYER
Page 32 of 66
Both RF IC and baseband shall initialise the interface in low-speed mode. For the avoidance of doubt, while the low-speed interface bit rate is SysClk/4, SysClk itself shall continue to run at the standard rate, providing up to 8x oversampling of the data interface with no need for clock multiplication. For the medium-speed mode, basebands shall implement a means to select the SysClk edge used to sample the data, to accommodate possible clock skews between the RF IC and the baseband caused by differing delays between the SysClk and RxData interface drivers. The clock polarity used by the baseband in any given system shall be determined during terminal design and configured during initialisation. 5.3.5.2 Waking Up the RxData Interface
Except for Sleep mode, the operating mode of the RxData interface shall always be controlled by commands from the baseband sent via the corresponding TxData interface. Entry and exit from Sleep mode are exactly the same as for the TxData interface and are controlled by the RF IC based on its local knowledge of when data will next need to be transmitted. For the avoidance of doubt, while the Rx Data interface is enabled by the baseband, the RF IC may generate and send unsolicited frames; the interface hardware in the baseband shall accommodate this, and the RF IC driver software shall handle such frames correctly. This might apply in particular to CTS state transfer; see Section 6.2.6. 5.3.6 TxData/RxData Common Characteristics
The TxData and RxData interfaces are differential interfaces. In each case, the line driver is not specified (i.e. except for the return loss); however, the signal delivered to the TxData and RxData line receivers by the corresponding line drivers shall comply with the following limits and requirements:
PHYSICAL LAYER
Page 33 of 66
LR Specification Line impedance Terminating resistor
Condition/Note implementation-specific optional, differential resistor between the input terminals of the receiver
Min 100-5%
Max
Unit
Absolute single-ended input voltage limits** Peak-to-peak differential voltage swing DC common-mode voltage range Acceptable AC component of common-mode voltage Slew rate Minimum differential voltage RMS sampling edge jitter **** Differential input impedance Parallel R Parallel C Single-ended input impedance Parallel R Parallel C LD Specification Return loss
-0.2 Unterminated 0.1 Peak-to-peak (including DC transients) 10%-90% of swing (driven by EMC at receiver) for 55% of bit period*** between differential pins 2
VDD*+0.2 0.9 VDD*-0.6 50 +/- 2
V V V mV V/ns mV ps k pF k pF Unit dB
100 50
0.5 From each pin to ground 100 Condition/Note observed at the line driver output up to 156 MHz (312 MHz/2) with source impedance equivalent to the termination load resistance Min 2 Max -10
Table 4: RxData/TxData Common Electrical Characteristics VDD may be 1.2 +/- 5% or 1.8 +/- 5%; see section 5.3.1 Note that some combinations of permissible input swing and common-mode voltage may appear to break this; the single-ended limits must be complied with always. *** Note that the minimum eye opening includes any common-mode voltage offset **** Note that the RMS sampling edge jitter is a requirement for the LR sampling timer (i.e. "TA" in Figure 2); it is independent from the Clock jitter defined in 5.4.1.2 * **
PHYSICAL LAYER
Page 34 of 66
Interface Voltage Limits VDD+200mV absolute upper limit VDD 1.08V - 1.98V 450mV max differential centred on Note: this diagram illustrates the signals seen on ONE receiver pin
VDD-600mV upper common-mode limit (Vcm max) +100mV lower common-mode limit (Vcm min) 0V -200mV absolute lower limit
Figure 7: Interface Voltage Limits
This diagram shows BOTH receiver pins
actual signal trajectories min diff opening 100mV
NO GO AREA
min open time 0.55T bit period, T
Figure 8: Eye Diagram Mask Limits
If the interface requires a terminating resistor at the line receiver, it shall be external to the receiving chip to facilitate the provision of an accurate and stable impedance match. This means that a given implementation of the interface shall always be terminated or unterminated dynamic switching between modes is neither allowed nor possible.
PHYSICAL LAYER
Page 35 of 66
There shall be no line receiver configuration changes between terminated / unterminated modes. Line drivers may be configurable to optimise performance; however, all line drivers shall be capable of driving the minimum terminating impedance given above. For maximum compatibility between basebands and RF ICs it is strongly recommended (but not required) that line drivers using a VDD value of 1.8 make provision for driving line receivers using a VDD value of 1.2. This can be achieved by careful choice of the driven common-mode voltage and differential swing. See Section 8.8. Unless Sleep mode is about to be used (see Section 5.3.6.1) the interface shall be held in the 0 state between frames for a minimum of one bit period of the currently configured clock rate to allow clock phase detection to initialise. The high-speed data rate in 3G or dual-system mode on both the TxData and RxData interfaces will be 312Mbps (1248MHz/4 = 38.4M x 65/8, 26M x 12 or 19.2M x 65/4). The 312MHz clocks at the two ends of each link shall be in nominal phase lock with each other, however they are generated, and attention is drawn to the need for adjustable sampling phase relative to the 312Mbps data. The low-speed data rate on both the TxData and RxData interfaces will be at SysClk/4 to avoid clock skew problems. That is, SysClk will still be sent at its normal rate, but data will be sent in either direction as if generated by SysClk/4. This gives 4x oversampling (8x if both clock edges are used), allowing choice of a correct clock phase at the receiving end. The low data rate shall be used in both directions at startup. At all other times low speed mode may be used whenever it provides enough bandwidth (in either direction, usually Tx; use of high-speed Tx and low-speed Rx is not expected but not excluded). On the Rx Data interface (only) a medium-speed mode shall be provided for 2.5G-only operation, with a bit rate equal to SysClk. Again, high-speed Tx with medium-speed Rx is not expected, but is not excluded. If a higher data rate is needed, an appropriate duty cycle of high-speed mode shall be used (driven by data framing, etc). Interface rate changes shall always be commanded by the baseband (the RF IC may of course request a change).
PHYSICAL LAYER
Page 36 of 66
5.3.6.1
Sleep Mode
The line drivers and receivers on both the TxData and RxData interfaces may optionally implement Sleep mode in order to save power. Sleep mode may be used during interframe gaps that are long compared to the frame durations but not long enough to allow the interface(s) or high-speed clock generators to be powered down completely. If implemented, this mode shall be available at all interface operating speeds. In the following description, references to bit periods mean bit periods of the currently configured clock for the interface. To enter Sleep mode, the line driver shall assert a 1 for the bit period immediately following the last bit of the frame, instead of the usual 0. Following this, the line driver shall enter a low-power state in which the common mode voltage of the interface is maintained but the differential voltage is reduced to between 5mV and +20mV (T/RxDataP relative to T/RxDataN). The mechanism for doing this is vendor-specific. Hysteresis in the line receiver shall ensure that it continues to present a 1 to the internal circuitry of the receiving IC. Entry into the low-power state at the driver shall be arranged to ensure that this condition is fulfilled. The receiving IC may detect the 1 driven in the bit after the frame end to trigger power saving; the measures used are vendor specific, but for example might include disabling sync searching. To exit Sleep mode, the line driver shall actively drive a 0 for at least 8 bit periods (high speed clock) or 1 bit period (low or medium speed clocks) before the start of the first bit of the sync sequence of the new frame. The line receiver shall detect this to enable sync searching. Because support for Sleep mode is optional, those devices choosing to implement sleep mode shall disable sleep mode on their line driver by default. Those devices supporting this mode of operation shall provide a means to enable/disable the sleep mode via a configuration setting. 5.3.6.2 Shutdown Mode
An interface driver (TxData LD or RxData LD) in shutdown mode shall provide a pulldown to 0V on both differential pins to ensure that the signals are held in a well-defined state. TxData and RxData interfaces will both enter shutdown mode after SysClkEn/InterfaceEn is deasserted. TxData interface will exit shutdown mode after SysClkEn/InterfaceEn is asserted.
PHYSICAL LAYER
Page 37 of 66
RxData interface will enter shutdown mode by Interface Control Logical Channel command disable RxData. RxData interface will exit shutdown mode by Interface Control Logical Channel command enable RxData.
5.4 5.4.1
Internal Interface Blocks High Speed Clock Generator Function
5.4.1.1
A high speed interface clock generator is needed in both the RF IC and the baseband in order to generate the 312MHz data clock that is used in the high speed mode of the Rx Data and Tx Data interfaces from SysClk. The implementation is vendor-specific but might typically be a PLL. When to enable or disable the high-speed clock generators for high-speed operation is system architecture dependent, vendor specific, and implemented in baseband scheduling actions. 5.4.1.2 Electrical Characteristics
Data link performance is specified by a peak-to-peak jitter spec on data edges given as a percentage of the clock period either side of the perfect edge position, and corresponding BER (short and long term) limits for received data looped back out of the transmit port.
PHYSICAL LAYER
Page 38 of 66
Parameter SysClk frequency, Fsys Clock frequency, Fclk Fclk multiplication error Clock jitter Data jitter Time alignment operation Time alignment accuracy Synth. pushing peak transient
Min
Nominal Max 38.4 26.0 19.2 312 1.0 600 600 Sync search
Units MHz
Comments
MHz ppm ps pk-pk ps pk-pk
0.25
clock period 0.05 clock period
=26*48/4 = 19.2*65/4 = 38.4*65/8 (nominal) error in multiplication of SysClk relative to exact value all inclusive all inclusive, sender side enable/disable controlled by protocol measured from the closest edge of the line receiver output maximum cycle slip with respect to a steady-state clock during a 250mV VCOpushing recovery
Table 5: High Speed Clock Parameters Note that the Clock jitter specified in Table 5 is the Peak-to-Peak Jitter (i.e. over infinite time period). The Effective Jitter - jitter over 1 DigRF frame period (i.e. up to 536 bits) directly affects the reliability of the interface. The Effective Jitter depends on both the Peak-to-Peak Jitter and the PLL loop-filter-bandwidth. Pattern Dependent Jitter adds to the Effective Jitter. Recommended maximal values for operation at 8x oversampling are 60 ps for the Effective Jitter and 0.2T for the Pattern Dependent Jitter. Manufacturers can refer to the Effective Jitter specification and Pattern Dependent Jitter specification as figures of merit when validating the operation of the interface. The Effective Jitter and Pattern Dependent Jitter are not specified in the standard, because they cannot be measured on the interface with standard test equipment. 5.4.2 5.4.2.1 Receive Time Alignment Function
The receiving end of the Tx Data and Rx Data interfaces shall provide a means of adjusting the sample phase of the high-speed clock so as to centre the sampling point in the eye opening of the data and hence ensure reliable communication. Implementation is
PHYSICAL LAYER
Page 39 of 66
vendor-specific; however, analysis has shown that eight nominally equally-spaced sample phases within a bit period will certainly be sufficient, and four may suffice depending on the jitter performance of the high-speed clock generators.
PHYSICAL LAYER
Page 40 of 66
PROTOCOL
6.1
Overview
The same protocol is used on both TxData and RxData interfaces for transfer of transmit and receive data and control/status information. The basic design philosophy has been to engineer the electrical properties of the link for extremely reliable data transmission, such that no error correction or detection is needed. This simplifies logic in the RF IC and removes latency issues that would arise from any kind of retransmission scheme. Transmission across both interfaces is divided into frames. Each frame consists of three fields: Sync, Header and Payload. The Sync field is transmitted first and contains a synchronisation pattern to allow the receiving end of the link to select the optimum clock phase for sampling the incoming data (see 6.2.2). The Header field is transmitted second and contains information about Payload size, the Logical Channel Type of the frame, and a signalling bit that has different functions in the TxData and RxData directions (see 6.2.3 - 6.2.6). The Payload field is transmitted third. Except for the Interface Control Logical Channel and Data Logical Channel payloads, the format and usage of the payload is RF IC specific. (see 6.2.7). Basebands shall implement a scheduling mechanism on the TxData interface that allows frames that must be transmitted at precise times (Time Accurate Strobe Logical Channel messages) to be sent at the correct instant, delaying less critical frames (see 6.2.14).
PROTOCOL
Page 41 of 66
6.2 6.2.1
Frame Structure General

p(N-1)... p1 p0
s15 s14 s13 s12 s11 s10 s9 s8 s7 s6 s5 s4 s3 s2 s1 s0 h7 h6 h5 h4 h3 h2 h1 h0 pN

PS PS PS LCT LCT LCT LCT
start of frame; sync

always 0 before SOF
header
CTS (RxData only)
payload T0
end of frame 0=normal, 1=sleep
PS=payload size, LCT=logical channel type
Figure 9: Frame Structure The total length of a frame is always 16 bits of Sync plus 8 bits of Header plus the Payload size. The Payload size will be one of 8, 32, 64, 96, 128, 256, or 512 bits, unless ProfileDefined is selected in which case the size is RF IC specific (So N in Figure 9 is 7, 31, 511). Thus the shortest possible frame is a total of 32 bits long and takes 102.6ns to send, and the longest defined frame is a total of 536 bits long and takes 1.72s to send, in high speed mode. (If interface clock stability is good enough at both ends of an interface, the Protocol-Defined frame length may exceed this, but this is vendor- and chipset-specific; basebands are not required to support payloads longer than 512 bits.) Except when Sleep mode is used (see Section 5.3.6.1), there shall be a guard time of a minimum one bit period between the end of the last bit of any frame and the start of the first bit of the next frame, during which a logic 0 shall be transmitted. 6.2.2 Sync Field
The Sync field is a 16-bit pattern designed to facilitate clock phase selection in the interface receivers. The bit pattern is as follows: 1010100001001011 The bits are transmitted in order from left to right so that the pattern begins with three cycles of clock/2. This pattern has been chosen for good autocorrelation properties balanced against a reasonable number of transitions to aid some clock sync schemes. The same pattern is used for all interface speeds.
PROTOCOL
Page 42 of 66
6.2.3
Frame Type Field
The frame type field is 8 bits long and is transmitted most significant bit (b7) first. The usage is as follows: b7..b5: b4..b1: b0: 6.2.4 Payload size in this frame Logical Channel Type of this frame (TxData interface) reserved for future use; (RxData interface) CTS bit. Payload Size Coding
b7..b5 Payload size (bits) Total frame size (bits) Protocol overhead, % 000 8 32 75.0 001 32 56 42.9 010 64 88 27.3 011 96 120 20.0 100 128 152 15.8 101 256 280 8.6 110 512 536 4.7 111 Profile-defined Protocol overhead = % of total frame length occupied by sync field plus header Note that this excludes inter-frame gaps Table 6: Payload/Frame Size and Protocol Overhead vs b7..b5
PROTOCOL
Page 43 of 66
6.2.5 b4..b1 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111
Logical Channel Type Coding Logical Channel Type Interface Control (both directions) Time Accurate Strobe Message (TxData i/f only); RF IC Unsolicited Status (RxData i/f only) RF IC Control (TxData i/f); RF IC Read (RxData i/f) Reserved for future use (TxData i/f); CTS Transfer (RxData i/f) Data Channel A Data Channel B Data Channel C Data Channel D Data Channel E Data Channel F Data Channel G Data Channel H Reserved for future use Reserved for future use Reserved for future use Reserved for future use Table 7: Logical Channel Type vs b4..b1
Note the distinction between the RF IC Read Logical Channel and the RF IC Unsolicited Status Logical Channel. The former shall only be used to provide responses to the RF IC Control Logical Channel; the latter shall always be used for status information from the RF IC that has not been requested by the baseband, which will typically be urgent or unexpected in nature. Note that unsolicited status from the RF IC may cause exception processing or otherwise disrupt normal baseband processing, and so the Unsolicited Status Logical Channel should be used with discretion. Data Channel usage definitions for various types of data (eg 3G primary, 3G diversity, 2.5G primary, 2.5G diversity) are specified in the Profile for each defined combination of data. See Section 7. Proprietary use of reserved Logical Channel Types is not permitted. The RF IC shall schedule any Rx Data Channel Frames of the same type such that a baseband FIFO with a depth of 2 times the in coming payload can average out delays in
PROTOCOL
Page 44 of 66
the Rx Data transfer. Note that RF IC Read Frames and RF IC Unsolicited Status frames can cause irregular delays in the Rx Data transfer 6.2.6 CTS Bit
In the RxData interface (and not in the TxData interface) b0 of the Header is the CTS bit (Clear To Send). In RF ICs using data pull to perform flow control on their transmit data buffer, the CTS bit is asserted when the baseband may send more data and negated when the BB should not send more data. The CTS bit is expected to operate like a wire, so any relevant latencies in data pull RF ICs must be specified, and the baseband shall always check the most recent CTS state before initiating the transmission of any Data Logical Channel frame on the TxData interface. RF ICs using data push for flow control (that is, the baseband knows how big the RF IC buffer is and works out all the timings open-loop) shall assert CTS continuously (that is, in all frames) so that the basebands CTS check always succeeds. This is to facilitate compatibility of basebands with both modes of RF IC operation. The CTS bit is asserted (the baseband may send data) when set to 1 and negated when set to 0. Note that the CTS bit applies to Data Logical Channels sent by the baseband only the baseband may send frames in other Logical Channels at any time, this being necessary for control of the RF IC. If there are limits to the rate at which an RF IC can receive non-data frames they shall be documented and published, and it is the responsibility of the driver software in the baseband to comply with them. RF ICs shall set the CTS bit correctly in every frame they transmit. RF ICs may send frames in the RF IC CTS Transfer Logical Channel for the purpose of transferring CTS state to the baseband when no suitably-timed frame is available in any other Logical Channel. An 8-bit payload frame would be the logical choice (to conserve bandwidth) but the actual usage is RF IC specific. Basebands shall discard the payload of frames in the CTS Transfer Logical Channel. RF ICs may not send any frame on the Rx Data interface until the baseband has enabled it via the TxData interface. Any timing or sequencing constraints in the RF IC applying while the RxData interface is disabled shall be documented and published. The corresponding header bit (b0) in the TxData interface is reserved for future use. Basebands shall set this bit to 0.
PROTOCOL
Page 45 of 66
6.2.7
Payload Field
The Payload field is used to transport the content of the frame. Except for the Interface Control Logical Channel (see Section 6.2.13), the Time Accurate Strobe Logical Channel (see Section 6.2.14) and the Rx and Tx Data Channel payloads (see Section 7.1), where hardware compatibility needs to be ensured, this specification does not constrain the usage of the Payload field; RF ICs may choose the Payload size and format of its contents freely for each message they require. However, to assist with hardware compatibility, basebands and RF ICs shall all be designed to send and interpret Payload content most significant bit first. For example, if a 32-bit Payload contains a message that was built in a 32-bit register in the baseband, b31 of the register (the msb) shall be the first bit of Payload transmitted and b0 (the lsb) shall be the last. Larger Payloads should be built up according to the same principle. It is strongly recommended that RF IC designs bear in mind that most baseband DSPs and microprocessors use 32-bit registers, and specify their message formats to simplify Payload construction; see Section 8.2. Note that with the exception of the 8-bit Payload size, all Payload sizes are a multiple of 32 bits! 6.2.8 Link Startup
Both ICs shall be ready to receive frames whenever SysClkEn (or InterfaceEn, as appropriate) is asserted. Each time SysClkEn (or InterfaceEn) is asserted the associated TxData interface shall initialise in low-speed mode with the high-speed clock generators turned off (and the RxData interface disabled). Subsequent speed and mode changes shall be commanded by the baseband, except for Sleep mode on the RxData interface, where implemented, which is controlled by the RF IC. Except when using Sleep mode (see Section 5.3.6.1), both links shall default to the logic 0 state while dormant and between frames. Note also the handling of RxData CTS status in Section 6.2.6. 6.2.9 Synchronisation Low-Speed Mode
Each frame begins with the Sync field. The receiving IC should detect the rising edge of the initial 1 of the Sync field to trigger clock phase selection (ie the choice of which of the available SysClk edges to use to sample the rest of the frame). Clock phase selection is done afresh at the start of every frame neither baseband nor RF IC may assume that the other IC will maintain data phasing between frames. The receiving IC shall use the Sync pattern to determine which clock phase is best for the current frame, and also to determine the start time of the frame relative to the local clock. Algorithms to decide when to search for Sync are vendor-specific; however, note that the Payload size for each
PROTOCOL
Page 46 of 66
frame is given in the first three bits of the Header field immediately after the Sync field, and that a minimum of one zero bit will always be present between consecutive frames unless Sleep mode is about to be used. 6.2.10 Synchronisation Medium-Speed Mode This mode applies to the RxData interface only. In this case (beyond choosing the correct clock edge to use for sampling the data) no clock oversampling is available, so in a strict sense no synchronisation occurs, but the operation should be logically identical to the low- and high-speed modes. Basebands shall be able to sample using either edge of the clock, and shall set the correct edge of SysClk to use for sampling the incoming data during initialisation. 6.2.11 Synchronisation High-Speed Mode Synchronisation in the high-speed mode is identical to low-speed mode, save that the bit clock and oversampling are generated by the high-speed clock generators. 6.2.12 Clock Mode Change As a general principle, after a mode change the baseband should request a read access from the RF IC (where the RF IC supports this) to stimulate a frame whose correct receipt confirms that the mode change was successful. The Ping function in the Interface Control Logical Channel might be useful here. 6.2.12.1 Slow to Fast Note that this could apply to only one of the interfaces, or to both at the same time; both clock multipliers are needed when either interface is to run at high speed. (If the RxData interface is not enabled but needs to be) Baseband sends enable RxData interface. RF IC enables RxData interface if necessary. (If the RF IC clock multiplier is not already running) Baseband sends turn on clock multiplier to RF IC at low speed. Baseband enables its own clock multiplier if it is not already running. RF IC enables its clock multiplier if necessary. After the proper settling time, Baseband sends select high speed (Tx, Rx or both interfaces) to RF IC at the currently configured speed for the TxData interface. RF IC switches the requested interface(s) to high speed.
PROTOCOL
Page 47 of 66
Baseband switches the requested interface(s) to high speed. Baseband sends a frame to the RF IC requiring a response, at the currently configured speed for the Tx interface. RF IC responds with a frame (meaningful or not, at the currently configured rate for the RxData interface) to confirm mode change has worked. Note: In order to select high speed for both Rx and Tx interfaces the Baseband should send "select high speed" for the Rx interface first and then for the Tx interface. 6.2.12.2 Fast to Slow This is the converse of the slow-to-fast transition, bearing in mind that both clock multipliers must be running for either interface to operate in high-speed mode. Once both interfaces no longer require the clock multipliers they can be turned off, using the appropriate Interface Control payload values to command the switch in the RF IC. 6.2.13 Interface Control Logical Channel This Section defines the Interface Control Logical Channel payload content. This is to ensure interoperability of the DigRF interface across ICs from different vendors. The Interface Control Logical Channel shall always use the 8-bit Payload size. The Payload value is sent most significant bit (b7) first. The following Payload values are defined:
PROTOCOL
Page 48 of 66
Value (hex) (no code)
Function Enable SysClk
01 02 04 08 10 20 40 80 31 32 34
RF IC clock multiplier start RF IC clock multiplier stop Select TxData slow Select TxData fast Select RxData slow Select RxData medium Select RxData fast Enable RxData interface Disable RxData interface Turn clock test mode on
Comment Reset/slow clocking hardware sequencing asserts SysClkEn to do this function but its logically part of Interface Control Reserved for future use Preparation for high-speed mode After fallback to low-speed mode Switch from high-speed mode to low-speed Switch from low-speed to high-speed mode Switch from other mode to low-speed Switch from other mode to medium-speed Switch from other mode to high-speed
FF
Turn frame loopback on
38
Turn test mode off
00
Ping
Send 101010 on RxData continuously using the currently configured RxData clock rate; cancelled by cycling SysClkEn/InterfaceEn, or, if implemented, by issuing the test mode off command RF IC loops back incoming frames until cancelled by cycling SysClkEn/InterfaceEn or frame contains test mode off command Cancels either clock test mode or frame loopback mode if they are active. The implementation of this function is optional. RF IC sends back a fixed, known result, if it supports status transmission on RxData
Table 8: Interface Control Logical Channel Functions All other Payload values in this Logical Channel are reserved for future use. Basebands shall not send reserved Payload values; RF ICs shall take no action if they receive a reserved Payload value in this Logical Channel. Proprietary use of reserved Payload values in the Interface Control Logical Channel is not permitted. The frame loopback on function instructs the RF IC to echo the incoming frames arriving on the TxData interface back to the baseband via the RxData interface, using the currently configured clock rate, without applying further processing internally. Implicitly this means that the transmit and receive RF chains shall be disabled. The looped-back frame should have b7..b1 of the header set to the same as in the incoming frame and the
PROTOCOL
Page 49 of 66
CTS bit (b0) asserted. The only exception to this is the optional test mode off function, in which case it should not loop this frame back (so that the baseband can tell the command has been received) and should re-initialise itself for normal operation, retaining whichever interface clock rates are currently configured. The frame loopback on function is provided to allow the baseband to verify correct operation of the physical interface. The RF IC shall support the frame loopback on function, if the Rx Data interface is operated at the same speed as the Tx Data interface. Support for the frame loopback on function is optional for all other speed mode combinations. Note: "loopback" frame delay is not necessarily constant. Loopback mode and clock test mode are also cancelled by cycling SysClkEn (or InterfaceEn, as appropriate). (This implies that basebands shall have an autonomous hardware mechanism for re-asserting SysClkEn that does not rely on SysClk; this is of course not needed for InterfaceEn.) Note that the loopback on function has been intentionally coded at a large Hamming distance from the other codes (minimum of 5, usually 7, thus requiring at least 5 bit errors in the Header for another function to be corrupted into loopback on). RF ICs wishing for particular security may optionally require this message to be sent more than once consecutively before it will be executed. 6.2.14 Time Accurate Strobe Logical Channel The Time Accurate Strobe Logical Channel shall use either the 8-bit payload size or the 32bit payload size in order to facilitate transmission scheduling in the baseband. The choice of size and the payload coding is RF IC specific; RF ICs are permitted to use both. The baseband shall be able to time the placement of TAS messages with an accuracy of one 3G quarter-chip period or better, or one 2.5G quarter-symbol period or better. This pertains only to the interface budget. 6.2.15 Interface delay requirements 6.2.15.1 TAS command RF ICs shall specify for each TAS message, a constant and known delay based on the payload from the arrival of the timing sync point on the TxData interface to the actual execution of the command.
PROTOCOL
Page 50 of 66
The delay is specified from a nominal reference time, T0, which is the theoretical centre of the bit transition from the last bit of the header field to the first bit of the payload (see Figure 9). 6.2.15.2 Interface Control RF ICs shall specify for each Interface Control command a worst-case delay from the arrival of the timing sync point on the data interface to the actual execution of the command. The delay is specified from a nominal reference time, T0, which is the theoretical centre of the bit transition from the last bit of the header field to the first bit of the payload (see Figure 9). In the case of RF IC clock multiplier start command the actual execution of the command is defined as the RF IC high-speed clock generator output stabilising to within +/- 20 degrees of final phase. Basebands shall specify the worst-case delay from the internal enable operation to the baseband high-speed clock generator output stabilising to within +/- 20 degrees of final phase. 6.2.15.3 Interface startup RF ICs shall specify the worst-case delay from assertion of SysClkEn to the time SysClk signal is meeting the electrical characteristics in section 5.3.3.2. RF ICs shall specify the worst-case delay from assertion of SysClkEn and InterfaceEn to the time the relevant interface link startup has been completed (section 6.2.8).
PROTOCOL
Page 51 of 66
APPLICATIONS
In this Section we define Profiles for various use cases, in which the Logical Channels and payload formatting to be used for various data types and data combinations are specified. 7.1 General: 3GPP Data Formats
The specifications in this Section apply to all Profiles defining combinations of 3GPP Rx or Tx data. Logical Channel Type Data Channel A Data Channel B Data Channel C Data Channel D Data Channel E Data Channel F-H Rx Data 2.5G Primary 2.5G Diversity 3G Primary 3G Diversity Reserved Reserved Tx Data 2.5G Reserved 3G 12 Bit Reserved 3G 16 Bit Reserved
Table 9: 3GPP Data Channels Note that the usage of different Data Channel Types for primary and diversity data applies whether the physical interfaces are separate or shared (primary and diversity data multiplexed on a single physical interface). The Rx interface shall transfer I and Q data at twice the symbol rate (2.5G) or twice the chip rate (3G) on average. Some channel filtering is performed in the RF IC in the 2.5G case. SRRC filtering is performed in the RF IC in the 3G case. The Tx interface shall transfer baseband data at symbol rate (2.5G) or chip rate (3G) on average. Modulation is performed in the RF IC in the 2.5G case. The BB transfers encoded bits to the RF IC (see Table 10). Modulation is performed in the BB in the 3G case (including multiplication by beta-C, Beta-D etc.) and the SRRC filtering is performed in the RF IC.
APPLICATIONS
Page 52 of 66
7.1.1
3G Rx Data
3G Rx data is 8 bits of I data and 8 bits of Q data, at 2x oversampling (so all channel selectivity is implemented in the RF IC). The data shall be transmitted as alternating I and Q samples, most significant bit first. The first sample transmitted in a frame shall be an I sample. The samples shall be packed into a 256-bit payload, using Data Channel Type C for Primary Rx data and Data Channel Type D for Diversity Rx Data. 7.1.2 2.5G Rx Data
2.5G Rx data is 16 bits of I data and 16 bits of Q data at 2x oversampling. The data shall be transmitted as alternating I and Q samples, most significant bit first. The first sample transmitted in a frame shall be an I sample. The samples shall be packed into a 256-bit payload, using Data Channel Type A for Primary Rx data and Data Channel Type B for Diversity Rx data. 7.1.3 3G Tx Data
3G Tx data is 12 bits of I data and 12 bits of Q data, 1x oversampling. The data shall be transmitted most significant bit first, with alternate I and Q samples. The first sample transmitted in each frame shall be an I sample. The samples shall be packed into a 96-bit payload, using Data Channel Type C. (Eventual MIMO solutions should use Data Channel Type D for diversity Tx data.) 3G 16 bit Tx data is 16 bits of I data and 16 bits of Q data, 1x oversampling. The data shall be transmitted most significant bit first, with alternate I and Q samples. The first sample transmitted in each frame shall be an I sample. The samples shall be packed into a 128-bit payload, using Data Channel Type E. Note that this channel allows the error free transport of HSUPA Tx data. Implementation of the 12 bit Tx Data channel is mandatory. Implementation of the 16 bit Tx Data channel is optional. 7.1.4 2.5G Tx Data
2.5G Tx data is a stream of nibbles (four-bit groups) using almost the same coding as 2.5G DigRF (see below). The data shall be sent most significant bit first with symbols in transmit order, packed into a 256-bit payload, using Data Channel Type A. One frame shall not carry data for more than one air-interface timeslot. (2.5G MIMO extensions are not currently envisaged.)
APPLICATIONS
Page 53 of 66
3 MS bits 000 001 010 011 100 101 110 111 d3i+2, d3i+1, d3i
LS bit 0 0 0 0 0 0 0 0 1
Coding GMSK '0' GMSK '1' reserved for future use reserved for future use reserved for future use reserved for future use reserved for future use End Of Data symbol (see text) 8PSK modulated data shall be transferred as raw unmapped bits. The Symbol mapping that is specified in chapter 3.2 in 3GPP TS 45.004 shall be performed on the RF IC side. Table 10: 2.5G Tx Data Bit Coding
The baseband shall not generate the reserved patterns and the RF IC shall ignore them. The symbol 1110 represents End Of Data and, when the RF IC requires it, is used for the symbol immediately following the last actual data symbol of the burst currently being transferred in order to indicate the end of the valid data in the frame; all subsequent bits in the frame are to be discarded. (So for instance it might often be used as the 157th or 158th symbol transferred.) The End Of Data symbol is valid for both GMSK and 8PSK data. Use of the End Of Data symbol in the RF IC is optional other methods for controlling the transfer of the correct number of symbols for a timeslot via the RF IC Control Logical Channel are possible and permitted. For the avoidance of doubt, the GMSK symbols represent the burst content prior to differential encoding; differential encoding shall be performed in the GMSK modulator in the RF IC. 7.2 3GPP Profiles
The following tables set out the combinations of 2.5G, 3G and control/status data that have been identified as of practical use, which we have dubbed Profiles. The formatting requirements set out in Section 7.1 apply to all cases; where additional remarks, recommendations or requirements apply to particular cases, they are noted. Basebands and RF ICs shall declare which of the Profiles they support. The existing Profiles do not include Tx diversity use cases.
APPLICATIONS
Page 54 of 66
Profile # 2GR.1 2GR.2 2GR.3
Rx Diversity? No No Yes
Speed Conditions Medium High High -
Table 11: 2.5G Single Mode Rx, Single Interface
Profile # 2GT.1 2GT.2
Speed Low High
Conditions -
Table 12: 2.5G Single-Mode Tx, Single Interface
Profile # 3G.1 3G.2
Rx Diversity? No Yes
I/faces 1 1
3G.3
Yes
Conditions Recommendation: use 32-bit payload for control packets, one every 50s max, to ease design of BBs with synchronous Rx processing Multiple copies of 3G.1
Table 13: 3G Single Mode, High-Speed Interface(s)
Profile # DNC.1 DNC.2 DNC.3
2.5G Rx 3G Rx Div? Div? No No No No No Yes
I/faces 1 2 1
Conditions One copy each of 2G.1 and 3G.1 Recommendation: use 32-bit payload for control packets, one every 50s max, to ease design of BBs with synchronous Rx processing DNC.1 + 3G.1 (others possible) Very tight will need very careful scheduling not recommended Two copies of DNC.1 (others possible)
DNC.4 DNC.5 DNC.6
No Yes Yes
Yes Yes Yes
2 1 2
Table 14: 2.5G + 3G Dual Mode, High-Speed Interfaces, Non-Compressed Mode
APPLICATIONS
Page 55 of 66
Profile # DC.1 DC.2
2.5G Rx 3G Rx I/faces Div? Div? No No 1 No Yes 1
Conditions Recommendation: use 32-bit payload for control packets, one every 50s max, to ease design of BBs with synchronous Rx processing DC.1 + 3G.1 (others possible) Alternating periods of 2GR.3 and 3G.2 Two copies of DC.1
DC.3 DC.4 DC.5
No Yes Yes
Yes Yes Yes
2 1 2
Table 15: 2.5G + 3G Dual Mode, High-Speed Interfaces, Compressed Mode
APPLICATIONS
Page 56 of 66
SUPPLEMENTARY INFORMATION
This Section contains subsections (usually referenced from the main text) giving background information, suggestions on usage, and other useful but non-normative information. 8.1 High Reliability Link Strategy
The strategy the Working Group has adopted for the Tx and Rx Data interfaces is to construct a very reliable link (looking for BERs approaching 10-13) in order to remove any need for error detection or correction. Since the link is galvanic and fairly short this is believed to be reasonable and achievable. This strategy also avoids possible latency problems with any kind of error detect/retry scheme in a tightly-controlled real-time system. The fundamental building blocks are: Low noise clocks, phase locked between RF IC and baseband, leading to stable sampling even at high clock rates Resynchronisation of the sampling phase using the sync sequence at the start of every frame Restrict frame lengths to those yielding a sufficiently low probability of a phase slip or similar catastrophic event during the duration of a frame. (Investigation showed that the 512-bit payload already requires good, but achievable, clock stability.)
A loopback mode is mandatory in the RF IC for system test/debug purposes. Means to facilitate BER testing in the RF IC or baseband are vendor-specific. 8.2 Payload Construction
Here are some recommendations intended to help simplify payload construction in the host processor or DSP, and thus ease frame filling in the interface: minimise shifting and masking try to use 32-bit building blocks use the msbs of a 32-bit register for short control words so RF IC can ignore trailing pad bits (usually zeros) for longer payloads, (zero-)pad at the end of the payload, not the start.
Page 57 of 66
8.3
Power Saving in Sleep Mode
The primary objective in Sleep mode is to reduce line driver current in the case where a terminating resistor is in use. By reducing the differential voltage across the resistor to nominally zero the line driver current requirement will reduce to internal bias currents only (and even these could perhaps be removed or greatly reduced). The common-mode voltage, however, should be maintained (i.e. within the tolerance for "acceptable AC component of common mode voltage" defined in 5.3.6) by the line driver, to avoid the risk of transients when full drive is restored. Although the actual line receiver must remain active during Sleep mode, it is envisaged that any interface logic behind the receiver (except for an edge detector to trigger restart) will be powered off, or at least not clocked, so that power savings can be made on the receiving end of the interface also. In unterminated mode Sleep mode will make less difference, owing to the much higher differential input impedance of the line receiver; in unterminated mode, drive current is only consumed by transitions on the interface. 8.4 RF IC FIFO Size Recommendations
Considerations of TxData interface scheduling and timing in both baseband and RF IC suggest that a Data FIFO size in the RF IC of at least 1256 bits is advisable. This contains 314 2G symbols, or two complete timeslots (actually with one symbol spare), and allows every 2.5G burst to be uploaded in three consecutive frames in one event. This allows great flexibility in baseband scheduling. Although smaller Data FIFOs are theoretically possible (as few as 20 symbols was discussed), smaller FIFOs imply increasingly tight timing and scheduling constraints in the baseband. Whether the RF IC uses a single FIFO for all incoming frames irrespective of Logical Channel Type, or uses multiple FIFOs, is RF IC specific. However, RF IC designers should consider the effect of their choices on baseband timing and scheduling, in particular with regard to the transmission of Control frames as well as Data, and the need to be able to schedule the sending of TAS frames in very precise timing.
Page 58 of 66
8.5
RxData Interface Scheduling
If there is variable delay between three consecutive 3G rx data frames, then the maximum delay between the beginning of the frame N and the beginning of frame N+2 in the interface shall always be less than 16 chips.
01 2 3 4 5 6 7 8 9 A B C D EF 01 2 3 4 5 6 7 8 9 A B C D EF 01 2 3 4 5 6 7 8 9 A B C D EF
FrN <= 16 Chips (1300 interface cycles)
FrN+1
FrN+2
Figure 10: RxData Interface Scheduling 3G
If there is variable delay between three consecutive 2.5G rx data frames, then the maximum delay between the beginning of the frame N and the beginning of frame N+2 in the interface shall always be less than 8 symbols.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
FrN <= 8 symbols
FrN+1
FrN+2
Figure 11: RxData Interface Scheduling 2.5G
System / interface speed

3G 2.5 G high speed clock 2.5 G medium speed clock, 38.4 MHz 2.5 G medium speed clock, 26 MHz 2.5 G medium speed clock, 19.2 MHz
Max delay
16 chips 8 symbols 8 symbols 8 symbols 8 symbols
Max delay in interface periods 1300high speed clock cycles 9216high speed clock cycles 283.56medium speed clock cycles 192medium speed clock cycles 141.78medium speed clock cycles
Table 16: RxData Interface Scheduling
Page 59 of 66
8.6
TxData/RxData Interface Mode State Machines
Figure 12 and Figure 13 depict the possible states of the transmit and receive ends of the TxData and RxData interfaces respectively, and a possible set of transitions between them. These diagrams are given to illustrate how it is expected that these interfaces will work and are not normative.
SysClkEn = 0 SysClkEn = 0
Shut down
SysClkEn = 1
SysClkEn = 0 Message_interface_ctrl
1 in frame_guard Tx sleep low 1x0 in frame_guard Message_interface_ctrl Tx_interface ON low speed
Test_mode_off
Loopback_on
0 in frame_guard
PLL ON
Message_interface_ctrl 0 in frame_guard
8x0 in frame_guard Tx sleep High
Tx interface High speed
Message_interface_ctrl
1 in frame_guard SysClkEn = 0 Message_interface_ctrl

Test_mode_off Loopback_on
Loop back mode
Figure 12: Transmit End State Machine
Page 60 of 66
Figure 13: Receive End State Machine
Page 61 of 66
8.7
Frequency Plan
Internal Synthesizer
1248 MHz 1/4 312 MHz
Crystal Frequencies (one of these) 38.4 MHz 1/2 26.0 MHz 19.2 MHz 1/4 1/4 1/4
x48
x65
High Speed Mode
SysClk to Baseband
9.6 MHz 6.5 MHz 4.8 MHz Low Speed Mode (e.g. at Startup)
Figure 14: RF IC Using 1248MHz internal oscillator
Page 62 of 66
312 MHz Crystal Frequencies (one of these) 38.4 MHz 1/2 26.0 MHz 19.2 MHz 1/4 1/4 1/4 9.6 MHz 6.5 MHz 4.8 MHz Note: An on-frequency VCO can be subjected to injection locking effects from the interface Low Speed Mode (e.g. at Startup) SysClk to Baseband Internal Synthesizer x48 x65 High Speed Mode
Figure 15: RF IC Alternate Scheme
1248 MHz Internal Synthesizer x48 x65 SysClk Frequency (one of these) from the RFIC
z MH .4 1/2 38 26.0 MHz 19 .2 M H z 1/4
1/4 312 MHz High Speed Mode
1/4 9.6 MHz 6.5 MHz 4.8 MHz Low Speed Mode (e.g. at Startup)
1/4
Figure 16: BB Using 1248MHz Oscillator
Page 63 of 66
Internal Synthesizer
M H z
312 MHz High Speed Mode
x48 1/2 1/4 1/4 1/4 9.6 MHz 6.5 MHz 4.8 MHz Low Speed Mode (e.g. at Startup) x65
SysClk Frequency (one of these) from the RFIC
38 .4
19
26.0 MHz
M Hz
.2
Note: An on-frequency VCO can be subjected to injection locking effects from the interface
Figure 17: BB Alternative Scheme
This frequency plan is designed for integer-multiplier compatibility with all of the allowed SysClk frequencies. Note that these figures show only a nominal implementation; the use of (for instance) a 1248MHz PLL locked to SysClk followed by division by 4 to get 312MHz at perfect duty cycle is not excluded, and nor is any other method for deriving 312MHz from SysClk.
Page 64 of 66
8.8
RxData/TxData Driver Design
The following diagrams illustrate some sets of voltage levels that might typically be used in the RxData and TxData interfaces.
Typical Cases LVDS, terminated Possible 1.2V unterminated implementation VDD 1.2V Vcm+200mV Vcm 600mV Vcm-200mV 0V 1.8V both ends 0V 1.2V both ends, or 1.8V driver configured for 1.2V receiver
VDD 1.8V Vcm+200mV Vcm 1.2V Vcm-200mV
SLVS terminated VDD 1.2V or 1.8V Vcm+100mV Vcm 200mV Vcm-100mV 0V
SLVS unterminated VDD 1.2V or 1.8V Vcm+200mV Vcm 200mV Vcm-200mV 0V
Note: all of these diagrams illustrate the signals seen on ONE receiver pin
Figure 18: Typical driver voltage levels Properly designed JESD96, sub-LVDS or SLVS (JESD 8-13) drivers should fulfil the requirements for these drivers.
Page 65 of 66
8.9
Interface Data Rate Transitions
Designers should note that RF ICs and BBs need to be able to change interface data rate on both the TxData and RxData interfaces without losing data. This implies either that the timings associated with the changes are such that they can always be fitted in while the interface is not carrying data, or that suitable buffering should be provided (notably in the RF IC on the RxData interface) to ensure that data will not be lost during a speed change. This might be particularly important in the slow-to-fast case, where the higher speed mode is being engaged precisely in order to cope with an increased data flow. The interfaces in this standard have been designed to offer very reliable data transfer. Interface rate change failures should therefore be very rare. However, in the unusual event that a rate change failure occurs, this constitutes a fatal error in the system, and the usual action should be to drop the call if there is one in progress, reset the RF subsystem (negating SysClkEn) and restart. The specific action to be taken is RF IC- and BB-specific, and will typically be embodied in the RF subsystem driver software.
Page 66 of 66
8.10 Interface Signal Order Recommendation In order to facilitate ease in integration and to achieve the best possible transmission line quality it is recommended, although not required, that the following signal ordering be obtainable from the solutions implemented for DigRF 3G components.
PCB/Substrate (Top View)
BB IC
(Top View) TxDataP TxDataN RxDataP RxDataN SysClkEn SysCllk
RF IC / Module
(Top View)
Diversity Path (Non-Muxed)

(Top View) TxDataP (Control) TxDataN (Control) RxDataP RxDataN InterfaceEn
Figure 19: Interface Signal Order Recommendation SysClkEn & InterfaceEn are less crucial in ordering, and may deviate from the signal ordering shown without serious penalty. They are shown here for completeness. The non-multiplexed diversity RF path may be on the same IC, or on a separate IC. If multiplexed diversity is implemented the second set of RxData and TxData links will not be present.

DigRF Standard v3.09

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DigRF Standard v3.09

Uploaded by

Copyright:

Available Formats

DigRF DUAL-MODE 2.

5G / 3G BASEBAND / RF IC INTERFACE STANDARD

22 November 2006 Version: 3.09

DigRF Working Group

DigRF Working Group

Date 28/04/2005 09/05/2005 23/05/2005 21/06/2005 25/07/2005

Internal reference : DOCMAN - #34227

DigRF Working Group

INTRODUCTION 1.1 1.2 1.3 1.4 Background Purpose Scope References

PHYSICAL LAYER 5.1 General

TxData/RxData Common Characteristics 5.3.6.1 Sleep Mode 5.3.6.2 Shutdown Mode

7.1.3 7.1.4 7.2 8

3G Tx Data 2.5G Tx Data

3G DigRF v3.09 DigRF Working Group

3G DigRF v3.09 DigRF Working Group

3G DigRF v3.09 DigRF Working Group

Terms of Use of this Specification

3G DigRF v3.09 DigRF Working Group

GLOSSARY AND ABBREVIATIONS

GLOSSARY AND ABBREVIATIONS

3G DigRF v3.09 DigRF Working Group

GLOSSARY AND ABBREVIATIONS

3G DigRF v3.09 DigRF Working Group

GLOSSARY AND ABBREVIATIONS

3G DigRF v3.09 DigRF Working Group

3G DigRF v3.09 DigRF Working Group

RFIC(s) 2GTX 3GTX

SRRC Matched Filter

Figure 1: Top-Level Block Diagram

3G DigRF v3.09 DigRF Working Group

3G DigRF v3.09 DigRF Working Group

Table 1: Interface Data Rates and Operating Modes

3G DigRF v3.09 DigRF Working Group

3G DigRF v3.09 DigRF Working Group

3G DigRF v3.09 DigRF Working Group

Block Diagrams Basic Handset

TA DeMUX Control TX Data

TX Stream (Data + Control)

Clk mult SysClk driver

Figure 2: Basic Handset

3G DigRF v3.09 DigRF Working Group

Diversity Local (Handset) Diversity

TX Stream 1 (Data + Control)

Figure 3: Local (Handset) Diversity, Separate Interfaces

3G DigRF v3.09 DigRF Working Group

RX Stream 2 RX Stream 1 Control

TX Stream (Data + Control)

Figure 4: Local (Handset) Diversity, Multiplexed Interface

3G DigRF v3.09 DigRF Working Group

SysClk / 4 RX Stream 1 LR TA De MUX

TX Stream (Data + Control)

Figure 5: Remote Rx Diversity

3G DigRF v3.09 DigRF Working Group

MIMO (for future use)

RX Stream 2 De MUX Clk mult Control TX Data

TX Stream1 (Data + Control)

3G DigRF v3.09 DigRF Working Group

Pin Visible Signals Output Voltage Swings

3G DigRF v3.09 DigRF Working Group

Electrical Characteristics of Single-Ended Signals

VDD*-0.1 0.75VDD* 0.1 0.25VDD* 5

3G DigRF v3.09 DigRF Working Group

3G DigRF v3.09 DigRF Working Group

VDD-0.1 0.75VDD 0.1 0.25VDD* 5

VDD+0.2 0.9 VDD-0.6 50 +/- 2