digrf standard v3.09

© DigRF Working Group

DigRF DUAL-MODE 2.5G / 3G BASEBAND / RF IC INTERFACE STANDARD

22 November 2006 Version: 3.09


REVISION HISTORY Version Change Summary Date Author 3.03 Imported from “framework v003”, updated

after Apr 05 meeting 28/04/2005 AF

3.04 Membership list updated, internal reference corrected

09/05/2005 AF

3.05 Updated during 16/17 May meeting and subsequently

23/05/2005 AF

3.06 Updated during 15/16 June meeting and subsequently; logos included; final draft

21/06/2005 AF

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.

25/07/2005 AF

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.

07/07/2006 WK1

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.

14/11/2006 WK1

Internal reference : DOCMAN - #34227

CONTENTS PAGE

1 INTRODUCTION 10

1.1 Background 10

1.2 Purpose 10

1.3 Scope 10

1.4 References 11

2 INTELLECTUAL PROPERTY 12

2.1 Working Group 12

2.2 Terms of Use of this Specification 13

2.3 Disclaimer 13

2.4 Cross-Licensing Terms 13

2.5 Source and Validity 13

2.6 Corrections and Improvements 13

3 GLOSSARY AND ABBREVIATIONS 14

4 OVERVIEW 17

4.1 General 17

4.2 Scope 17

4.3 Applications 18

4.4 Principles 19

4.5 Signals 19

4.6 Physical Layer 20

4.7 Protocol 20

5 PHYSICAL LAYER 22

5.1 General 22

CONTENTS PAGE

5.2 Block Diagrams 23

5.2.1 Basic Handset 23

5.2.2 Diversity 24 5.2.2.1 Local (Handset) Diversity 24 5.2.2.2 Remote Rx 26 5.2.2.3 MIMO (for future use) 27

5.3 Pin Visible Signals 28

5.3.1 Output Voltage Swings 28

5.3.2 SysClkEn/InterfaceEn 28 5.3.2.1 SysClkEn Function 28 5.3.2.2 InterfaceEn Function 28 5.3.2.3 Electrical Characteristics of Single-Ended

Signals 29

5.3.3 SysClk 29 5.3.3.1 Function 29 5.3.3.2 Clock Characteristics 30

5.3.4 TxData 30 5.3.4.1 Function 30 5.3.4.2 Waking Up the TxData Interface 31

5.3.5 RxData 31 5.3.5.1 Function 31 5.3.5.2 Waking Up the RxData Interface 32

5.3.6 TxData/RxData Common Characteristics 32 5.3.6.1 Sleep Mode 36 5.3.6.2 Shutdown Mode 36

5.4 Internal Interface Blocks 37

5.4.1 High Speed Clock Generator 37 5.4.1.1 Function 37 5.4.1.2 Electrical Characteristics 37

5.4.2 Receive Time Alignment 38 5.4.2.1 Function 38

CONTENTS PAGE

6 PROTOCOL 40

6.1 Overview 40

6.2 Frame Structure 40

6.2.1 General 40

6.2.2 Sync Field 40

6.2.3 Frame Type Field 40

6.2.4 Payload Size Coding 40

6.2.5 Logical Channel Type Coding 40

6.2.6 CTS Bit 40

6.2.7 Payload Field 40

6.2.8 Link Startup 40

6.2.9 Synchronisation – Low-Speed Mode 40

6.2.10 Synchronisation – Medium-Speed Mode 40

6.2.11 Synchronisation – High-Speed Mode 40

6.2.12 Clock Mode Change 40 6.2.12.1 Slow to Fast 40 6.2.12.2 Fast to Slow 40

6.2.13 Interface Control Logical Channel 40

6.2.14 Time Accurate Strobe Logical Channel 40

6.2.15 Interface delay requirements 40 6.2.15.1 TAS command 40 6.2.15.2 Interface Control 40 6.2.15.3 Interface startup 40

7 APPLICATIONS 40

7.1 General: 3GPP Data Formats 40

7.1.1 3G Rx Data 40

7.1.2 2.5G Rx Data 40

CONTENTS PAGE

7.1.3 3G Tx Data 40

7.1.4 2.5G Tx Data 40

7.2 3GPP Profiles 40

8 SUPPLEMENTARY INFORMATION 40

8.1 High Reliability Link Strategy 40

8.2 Payload Construction 40

8.3 Power Saving in Sleep Mode 40

8.4 RF IC FIFO Size Recommendations 40

8.5 RxData Interface Scheduling 40

8.6 TxData/RxData Interface Mode State Machines 40

8.7 Frequency Plan 40

8.8 RxData/TxData Driver Design 40

8.9 Interface Data Rate Transitions 40

8.10 Interface Signal Order Recommendation 40

of 66

INTRODUCTION 3G DigRF v3.09


1 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 public-domain 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

of 66

INTRODUCTION 3G DigRF v3.09


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

of 66

INTELLECTUAL PROPERTY 3G DigRF v3.09


2 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.

of 66

INTELLECTUAL PROPERTY 3G DigRF v3.09


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 .

of 66

GLOSSARY AND ABBREVIATIONS 3G DigRF v3.09


3 GLOSSARY AND ABBREVIATIONS

Baseband (BB) The IC or subsystem which has overall control of the terminal’s 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.

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

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.

of 66

OVERVIEW 3G DigRF v3.09


4 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:

of 66



DigR

F_3GInterface

TX Symbol I&Q

RX Symbol I&Q

Configuration and Control

RFIC responses Dig

RF_

3G

Inte

rface

SRRC Bandlimiting

SRRC Matched Filter

BaseBand RFIC(s )

TX path

RX path

SysClk

SysClkEn

2GTX

3GRX

Crystal

2GRX

Mod’n

3GTX

filter

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

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.

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 Data rate Operating Mode TxData SysClk/4 Startup/fallback, 2.5G Tx TxData 312Mbps 3G/2.5G Tx RxData SysClk/4 Startup/fallback RxData SysClk 2.5G Rx RxData 312Mbps 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:

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 IC-specific; this standard places constraints on the content of the payload field only where necessary to achieve interface compatibility.

of 66

PHYSICAL LAYER 3G DigRF v3.09


5 PHYSICAL LAYER

5.1 General

Clock is distributed between the baseband and RF IC’s 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.

of 66



5.2 Block Diagrams

5.2.1 Basic Handset

Baseband RFIC

SysClk

SysClkEn SysClkdriver

LD

LRLD

LR

T A

T A

Clk mult

TX Stream

TX Data

RX StreamRX Stream(Data + Status)

d

(Data + Control)

ControlDe-MUX

Clk mult

TA : Time AlignmentLD : Line DriverLR : Line Receiver

Baseband RFIC

SysClk

SysClkEn SysClkdriver

LD

LRLD

LR

T A

T A

Clk mult

TX Stream

TX Data

RX StreamRX Stream(Data + Status)

d

(Data + Control)

ControlDe-MUX

Clk mult


(Data + Control)

ControlDe-MUX

Clk mult


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.

of 66



5.2.2 Diversity

5.2.2.1 Local (Handset) Diversity

Baseband RFIC

SysClk

SysClkEn SysClk driver

LD

LRLD

LR

T A

T A


Clk mult

TX Stream 1TX Data

RX Stream 1 RX Stream 1

d1

(Data + Control) Control 1

De - MUX

Clk mult

LDLR RX Stream 2 RX Stream 2

T A

Control 2 LRLD

T A

TX Stream 2(Control)

InterfaceEn

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 receiver’s 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.

of 66



For diversity receivers the second Tx port will typically operate at low (SysClk/4) rate for control purposes only.

Baseband Dual - RX RFIC

SysClk


LRLD

T A

Clk mult

TX Stream TX Data

RX Stream 1RX Stream 1

d1

(Data + Control) Control

De - MUX

Clk mult

LDLR RX Stream 2RX Stream 2

T A Control

MUX De - MUX

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.

of 66



5.2.2.2 Remote Rx

Baseband RFIC

SysClk


LDLR

T A

TA : Time Alignment LD : Line Driver LR : Line Receiver

Clk mult

TX Data


d1

LRLD

T A

TX Stream(Data + Control)

LRLD

T A

TX Stream(Data + Control)

ControlDe - MUX

Clk mult


T A

LRLD T A

Control Stream

Clk mult

d2

Control

RemoteRX

SysClk / 4 InterfaceEn

d3

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.

of 66



5.2.2.3 MIMO (for future use)

Baseband RFIC

SysClk


LDLR

T A

Clk mult

TX Data


d1

LRLD

T A

TX Stream1

(Data + Control)

ControlDe - MUX

Clk mult


T A

LRLD T A Clk mult

d2

RemoteTRX

TX Data

ControlDe - MUX

(Data + Control)

TX Stream2

InterfaceEn

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.

of 66



5.3 Pin Visible Signals

5.3.1 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 SysClkEn/InterfaceEn

5.3.2.1 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).

of 66



5.3.2.3 Electrical Characteristics of Single-Ended Signals

SysClkEn and InterfaceEn are single-ended CMOS. Levels as follows:

Limits Symbol Parameter Test Condition Min Max

Unit

Inputs VIH Input high voltage - 0.65VDD* VDD*+0.3 V VIL Input low voltage - -0.3 0.35VDD* V CIN Input capacitance - 6 pF

Outputs VOH Output high voltage IOH=-100µA VDD*-0.1 V VOH Output high voltage IOH=-2mA 0.75VDD* V VOL Output low voltage IOL=100µA 0.1 V VOL Output low voltage IOL=2mA 0.25VDD* V tR, tF Rise/Fall time 10% to 90%

CLOAD=15pF 5 ns

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 SysClk

5.3.3.1 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).

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 Min Max Unit Frequency error** -1 +1 % Duty Cycle 45 55 % Vout Peak to peak 0.8 VDD* V Load impedance Parallel C Parallel R

10

10

pF kΩ

19.2MHz -58 dBc 26MHz -55 dBc

Integrated (single sideband) phase noise in 10KHz-10MHz***

38.4MHz -52 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 TxData

5.3.4.1 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.5G-only data transfer

• high-speed mode (bit rate 312Mbps) for Tx data transfer and, typically, multiplexed RF IC control information.

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 RxData

5.3.5.1 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.

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:

of 66



LR Specification Condition/Note Min Max Unit Line impedance implementation-specific Terminating resistor optional, differential resistor

between the input terminals of the receiver

100-5% Ω

Absolute single-ended input voltage limits**

-0.2 VDD*+0.2 V

Peak-to-peak differential voltage swing

Unterminated 0.9 V

DC common-mode voltage range

0.1 VDD*-0.6 V

Acceptable AC component of common-mode voltage

Peak-to-peak (including DC transients)

50 mV

Slew rate 10%-90% of swing (driven by EMC at receiver)

+/- 2 V/ns

Minimum differential voltage for 55% of bit period*** 100 mV RMS sampling edge jitter **** 50 ps Differential input impedance Parallel R

between differential pins 2

kΩ

Parallel C 0.5 pF Single-ended input impedance Parallel R

From each pin to ground 100

kΩ

Parallel C 2 pF LD Specification Condition/Note Min Max Unit Return loss observed at the line driver

output up to 156 MHz (312 MHz/2) with source impedance equivalent to the termination load resistance

-10 dB

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

of 66



Interface Voltage Limits

VDD+200mV absolute upper limitVDD 1.08V - 1.98V

VDD-600mV upper common-mode limit (Vcm max)

+100mV lower common-mode limit (Vcm min)

0V-200mV absolute lower limit

±450mV max differential centred on

Note: thisdiagram illustratesthe signals seenon ONE receiver

pin

Figure 7: Interface Voltage Limits

bit period, Tmin open time 0.55T

min diffopening100mV

NO GO AREA

actual signal trajectories

This diagram shows BOTH receiver pins

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.

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).

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 inter-frame 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 pull-down 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.

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 Internal Interface Blocks

5.4.1 High Speed Clock Generator

5.4.1.1 Function

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.

of 66



Parameter Min Nominal Max Units Comments SysClk frequency, Fsys

38.4 26.0 19.2

MHz

Clock frequency, Fclk

312 MHz =26*48/4 = 19.2*65/4 = 38.4*65/8 (nominal)

Fclk multiplication error

±1.0 ppm error in multiplication of SysClk relative to exact value

Clock jitter 600 ps pk-pk all inclusive Data jitter 600 ps pk-pk all inclusive, sender side Time alignment operation

Sync search

enable/disable controlled by protocol

Time alignment accuracy

±0.25 clock period

measured from the closest edge of the line receiver output

Synth. pushing peak transient

±0.05 clock period

maximum cycle slip with respect to a steady-state clock during a ±250mV VCO-pushing 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 Receive Time Alignment

5.4.2.1 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

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.

of 66

PROTOCOL 3G DigRF v3.09


6 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).

of 66



6.2 Frame Structure

6.2.1 General

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

p1 p0

end of frame0=normal, 1=sleep

payloadheaderCTS (RxData only)

start of frame; sync

PS LCTPSPS LCT LCT LCT

PS=payload size, LCT=logical channel typealways 0 before SOF

T0

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 “Profile-Defined” 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.72µs 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: 1 0 1 0 1 0 0 0 0 1 0 0 1 0 1 1 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.

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: Payload size in this frame b4..b1: Logical Channel Type of this frame b0: (TxData interface) reserved for future use; (RxData interface) CTS bit. 6.2.4 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

of 66



6.2.5 Logical Channel Type Coding

b4..b1 Logical Channel Type 0000 Interface Control (both directions) 0001 Time Accurate Strobe Message (TxData i/f only); RF IC Unsolicited

Status (RxData i/f only) 0010 RF IC Control (TxData i/f); RF IC Read (RxData i/f) 0011 Reserved for future use (TxData i/f); CTS Transfer (RxData i/f) 0100 Data Channel A 0101 Data Channel B 0110 Data Channel C 0111 Data Channel D 1000 Data Channel E 1001 Data Channel F 1010 Data Channel G 1011 Data Channel H 1100 Reserved for future use 1101 Reserved for future use 1110 Reserved for future use 1111 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

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 baseband’s 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.

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

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.

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:

of 66



Value (hex) Function Comment (no code) Enable SysClk Reset/slow clocking hardware sequencing

asserts SysClkEn to do this function but it’s logically part of Interface Control

01 Reserved for future use 02 RF IC clock multiplier start Preparation for high-speed mode 04 RF IC clock multiplier stop After fallback to low-speed mode 08 Select TxData slow Switch from high-speed mode to low-speed 10 Select TxData fast Switch from low-speed to high-speed mode 20 Select RxData slow Switch from other mode to low-speed 40 Select RxData medium Switch from other mode to medium-speed 80 Select RxData fast Switch from other mode to high-speed 31 Enable RxData interface 32 Disable RxData interface 34 Turn clock test mode on 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

FF Turn frame loopback on RF IC loops back incoming frames until cancelled by cycling SysClkEn/InterfaceEn or frame contains “test mode off” command

38 Turn test mode off Cancels either clock test mode or frame loopback mode if they are active. The implementation of this function is optional.

00 “Ping” 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

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 32-bit 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.

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).

of 66

APPLICATIONS 3G DigRF v3.09


7 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

Rx Data Tx Data

Data Channel A 2.5G Primary 2.5G Data Channel B 2.5G Diversity Reserved Data Channel C 3G Primary 3G 12 Bit Data Channel D 3G Diversity Reserved Data Channel E Reserved 3G 16 Bit Data Channel F-H Reserved 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.

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.)

of 66



3 MS bits LS bit Coding 000 0 GMSK '0' 001 0 GMSK '1' 010 0 reserved for future use 011 0 reserved for future use 100 0 reserved for future use 101 0 reserved for future use 110 0 reserved for future use 111 0 End Of Data symbol (see text) d3i+2, d3i+1, d3i 1 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.

of 66



Profile # Rx Diversity? Speed Conditions 2GR.1 No Medium - 2GR.2 No High - 2GR.3 Yes High -

Table 11: 2.5G Single Mode Rx, Single Interface

Profile # Speed Conditions 2GT.1 Low - 2GT.2 High -

Table 12: 2.5G Single-Mode Tx, Single Interface

Profile # Rx Diversity? I/faces Conditions 3G.1 No 1 - 3G.2 Yes 1 Recommendation: use 32-bit payload for

control packets, one every 50µs max, to ease design of BBs with synchronous Rx processing

3G.3 Yes 2 Multiple copies of 3G.1

Table 13: 3G Single Mode, High-Speed Interface(s)

Profile # 2.5G Rx

Div? 3G Rx Div?

I/faces Conditions

DNC.1 No No 1 - DNC.2 No No 2 One copy each of 2G.1 and 3G.1 DNC.3 No Yes 1 Recommendation: use 32-bit payload for


DNC.4 No Yes 2 DNC.1 + 3G.1 (others possible) DNC.5 Yes Yes 1 Very tight – will need very careful

scheduling – not recommended DNC.6 Yes Yes 2 Two copies of DNC.1 (others possible)

Table 14: 2.5G + 3G Dual Mode, High-Speed Interfaces, Non-Compressed Mode

of 66



Profile # 2.5G Rx

Div? 3G Rx Div?

I/faces Conditions

DC.1 No No 1 - DC.2 No Yes 1 Recommendation: use 32-bit payload for


DC.3 No Yes 2 DC.1 + 3G.1 (others possible) DC.4 Yes Yes 1 Alternating periods of 2GR.3 and 3G.2 DC.5 Yes Yes 2 Two copies of DC.1

Table 15: 2.5G + 3G Dual Mode, High-Speed Interfaces, Compressed Mode

of 66

SUPPLEMENTARY INFORMATION 3G DigRF v3.09


8 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.

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.

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.

FrN FrN+2FrN+1

<= 16 Chips (1300 interface cycles)

1 2 3 4 5 6 7 8 9 A B C D E F0 1 2 3 4 5 6 7 8 9 A B C D E F01 2 3 4 5 6 7 8 9 A B C D E F0

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.

FrN FrN+2FrN+1

<= 8 symbols

1 2 3 4 5 6 70 1 2 3 4 5 6 701 2 3 4 5 6 70

Figure 11: RxData Interface Scheduling 2.5G

System / interface speed Max delay Max delay in interface

periods 3G 16 chips 1300high speed clock cycles 2.5 G high speed clock 8 symbols 9216high speed clock cycles 2.5 G medium speed clock, 38.4 MHz 8 symbols 283.56medium speed clock cycles 2.5 G medium speed clock, 26 MHz 8 symbols 192medium speed clock cycles 2.5 G medium speed clock, 19.2 MHz 8 symbols 141.78medium speed clock cycles

Table 16: RxData Interface Scheduling

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.

Shut down

Tx_interface ON low speed

Tx interface High speed

PLL ON

Tx sleep low

Loop back mode

Tx sleep High

Message_interface_ctrl


“1” in frame_guard

1x“0” inframe_guard

“1” in frame_guard

8x“0” inframe_guard

SysClkEn = “0”

SysClkEn = “1”

SysClkEn = “0”

SysClkEn = “0”

“0” inframe_guard

“0” inframe_guard


SysClkEn = “0”


Message_interface_ctrlLoopback_onTest_mode_off

Loopback_onTest_mode_off

Figure 12: Transmit End State Machine

of 66



Figure 13: Receive End State Machine

of 66



8.7 Frequency Plan

38.4 MHz

26.0 MHz

19.2 MHz

1248 MHz

6.5 MHz

InternalSynthesizer

x48x65

1/4

4.8 MHz

Low Speed Mode(e.g. at Startup)

SysClk to Baseband

312 MHzHigh Speed ModeCrystal

Frequencies(one of these)

9.6 MHz

1/2

1/4

1/4

1/4

Figure 14: RF IC Using 1248MHz internal oscillator

of 66



38.4 MHz

26.0 MHz

19.2 MHz

InternalSynthesizer

x48x65


SysClk to Baseband

312 MHzHigh Speed ModeCrystal

Frequencies(one of these)

1/2

1/4

1/4

1/4

6.5 MHz

4.8 MHz

9.6 MHz

1/2

1/4

1/4

1/4

6.5 MHz

4.8 MHz

9.6 MHz

Note: An on-frequency VCO can be subjected to injection locking effects from the interface

Figure 15: RF IC Alternate Scheme

38.4 MHz

26.0 MHz19.2 MHz

1248 MHz

Internal Synthesizer

x48

x65

1/4


312 MHzHigh Speed Mode

SysClkFrequency

(one of these)from the RFIC

1/2

1/4

1/4

1/4

6.5 MHz

4.8 MHz

9.6 MHz

Figure 16: BB Using 1248MHz Oscillator

of 66



38.4

MHz

26.0 MHz19.2 MHz

InternalSynthesizer

x48


312 MHzHigh Speed Mode

SysClkFrequency

(one of these)from the RFIC

1/2

1/4

1/4

1/4

6.5 MHz

4.8 MHz

9.6 MHz

x65

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.

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

Note: all of these diagrams illustrate the signals seen on ONE receiver pin

VDD 1.8V

0V

Vcm+200mV

Vcm 1.2VVcm-200mV

1.8V both ends

LVDS, terminated

VDD 1.2V

0V

Vcm+200mV

Vcm-200mV

Vcm 600mV

1.2V both ends, or 1.8V driverconfigured for 1.2V receiver

Possible 1.2V unterminatedimplementation

SLVS terminated

VDD 1.2Vor 1.8V

0V

Vcm+100mV

Vcm-100mVVcm 200mV

VDD 1.2Vor 1.8V

0V

Vcm+200mV

Vcm-200mV

Vcm 200mV

SLVS unterminated

Typical Cases

Note: all of these diagrams illustrate the signals seen on ONE receiver pin

VDD 1.8V

0V

Vcm+200mV

Vcm 1.2VVcm-200mV

1.8V both ends

LVDS, terminated

VDD 1.2V

0V

Vcm+200mV

Vcm-200mV

Vcm 600mV

1.2V both ends, or 1.8V driverconfigured for 1.2V receiver

Possible 1.2V unterminatedimplementation

SLVS terminated

VDD 1.2Vor 1.8V

0V

Vcm+100mV

Vcm-100mVVcm 200mV

VDD 1.2Vor 1.8V

0V

Vcm+200mV

Vcm-200mV

Vcm 200mV

SLVS unterminated

Figure 18: Typical driver voltage levels

Properly designed JESD96, sub-LVDS or SLVS (JESD 8-13) drivers should fulfil the requirements for these drivers.

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.

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)

TxDataP

TxDataN

RxDataP

RxDataN

SysClkEn

SysCllk

BB IC(Top View)

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

Documents

added minor

3g digrf v3

input threshold

digrf working

prevailing

logical channel

time alignment

simplify payload