"MIPI RFFE规范3.0详解：RF前端控制接口（RFFESM）版本3.0"

5星 · 超过95%的资源需积分: 45 45 浏览量更新于2024-03-21 6 收藏 2.64MB PDF 举报

The MIPI Alliance, Inc. has developed the RF Front-End Control Interface (RFFE) Specification version 3.0, which was released on 1 December 2019. This specification is a confidential document, and all rights are reserved by the MIPI Alliance. The purpose of the RFFE specification is to define a standardized interface for controlling RF front-end components in mobile devices. The RFFE specification includes detailed information on the communication protocol, electrical interfaces, and register structure for interacting with RF front-end components such as power amplifiers, filters, and switches. By providing a common interface, the RFFE specification enables seamless interoperability between different vendors' RF front-end components, reducing integration complexity and time to market for mobile device manufacturers. Key features of the RFFE specification 3.0 include support for multiple device configurations, improved power management capabilities, and enhanced error handling mechanisms. The specification also defines a standardized set of RF front-end control commands and status registers, allowing for efficient communication between the baseband processor and RF front-end components. Implementers of the RFFE specification must adhere to the rights and obligations outlined in the MIPI Membership Agreement and Bylaws. This ensures that all member companies comply with the terms of the specification and maintain confidentiality of the information contained within. Overall, the RFFE specification 3.0 provides a robust framework for controlling RF front-end components in mobile devices, promoting consistency and interoperability across different hardware platforms. By following the guidelines set forth in this specification, mobile device manufacturers can benefit from increased design flexibility, reduced development costs, and accelerated time to market for new products.

Specification for RFFE Version 3.0

01-Dec-2019

Confidential

The RFFE Specification was originally based on a subset of the MIPI Alliance Specification for System

Power Management Interface (SPMI) [MIPI03], developed by the MIPI SPM Working Group. However, 49

RFFE-specific features have also been added to that basic subset. Thus, all of the relevant parts of 50

[MIPI03] have been copied into this document to make it a complete stand-alone Specification. As the 51

needs specific to the differing applications addressed by these two Specifications evolve, it may be likely 52

that they will diverge, such that each one may continue to properly address their primary targeted 53

applications with optimal feature sets. 54

This new version of the RFFE Specification seeks to enhance prior versions of RFFE by adding additional 55

features to the basic feature set introduced first in the RFFE v1.x versions, as represented by [MIPI01]. The 56

RFFEv1 Specifications were then augmented by the v2.x versions, [MIPI08] and [MIPI09], for RFFE v2.0 57

and v2.1, respectively. The continuing intent is to be backward-compatible with all earlier versions, and 58

therefore most of the new features introduced are optional for implementations. This helps to ensure that 59

Slave devices designed to the earlier RFFE v1.x and v2.x Specifications do not become prematurely 60

obsoleted, and may continue to be utilized in newer RFFE v3.x system designs, albeit generally without 61

support of newer features. It is a goal to allow support for the newer features to occur in Slave device 62

designs, and in systems, based on a desire of end-users to enhance the capabilities previously achieved 63

using the earlier versions of the RFFE Specification. A high-level summary of the major functional 64

additions in RFFE v3.x, along with further references, may be found in Annex B.1. 65

The key pillars of the RFFE RF Front-End Control Interface Specification include the following: 66

• Minimize the wiring interconnect demands in the RF front-end of a mobile terminal 67

• Minimize pin count for control in the RF front-end 68

• Optimization of control flow and ease of implementation 69

• Ensure minimal EMI contributions in applications due to RFFE bus activity 70

• Minimize complexity for Slave devices 71

• Add flexibility and scalability, allowing use of advanced RF front-end architectures such as 72

diversity and/or MIMO configurations 73

• Development of a standardized interface targeted to the needs of RF front-end control, providing a 74

well-defined feature set, protocol, and electrical layer so as to foster interoperability and a basis 75

for reuse, while also providing flexible options for growth 76

Version 3.0 Specification for RFFE

01-Dec-2019

Confidential

1.1 Scope 77

The scope of this document is to specify the RFFE control interface for RF front-end devices. Analog 78

signal paths required between front-end devices, and other elements which may control and/or utilize these 79

devices not using the RFFE bus, are outside the scope of this document. 80

A voltage reference is included as part of the RFFE control interface. The implementation of this voltage 81

source is not specified, although a set of electrical characteristics are defined, thus allowing for flexibility 82

in system topologies. This document further defines interface-specific procedures, and also provides 83

alternative means to perform certain actions. Implementers may determine which optional procedures and 84

alternative means are supported by a given device. 85

1.2 Purpose 86

RFFE provides a low-complexity solution to meet the cost and performance targets of RF front-end 87

components. It offers extensibility from simple configurations with one Slave on a single bus, all the way to 88

complex configurations with many Slaves on a single bus, or perhaps distributed on multiple buses. 89

Further, in RFFEv2+ there is optionally the potential for multiple Masters on a single bus, along with the 90

option for multiple Slaves. Added to this is the fact that all of these devices may be participating in the 91

activities of multiple buses via separate interface entities embodied in any of the devices. Despite the 92

complexities possible via RFFE interconnections in various systems topologies, the relatively minimal set 93

of features and physical pin set requirements offers the possibility for fairly simple configurations. Thus, 94

RFFE continues to ease both the RF and front-end device design by necessitating a mobile terminal to 95

support only a single control interface, but it also enables even more complex RF front-end control 96

topologies. Ideally, this will lead to a broader range of control-compatible components based on the RFFE 97

Specification, and hence to even larger markets for RF front-end devices. 98

Specification for RFFE Version 3.0

01-Dec-2019

Confidential

2 Terminology 99

The MIPI Alliance has adopted Section 13.1 of the IEEE Specifications Style Manual, which dictates use of 100

the words “shall”, “should”, “may”, and “can” in the development of documentation, as follows: 101

The word shall is used to indicate mandatory requirements strictly to be followed in order 102

to conform to the Specification and from which no deviation is permitted (shall equals is 103

required to). 104

The use of the word must is deprecated and shall not be used when stating mandatory 105

requirements; must is used only to describe unavoidable situations. 106

The use of the word will is deprecated and shall not be used when stating mandatory 107

requirements; will is only used in statements of fact. 108

The word should is used to indicate that among several possibilities one is recommended 109

as particularly suitable, without mentioning or excluding others; or that a certain course 110

of action is preferred but not necessarily required; or that (in the negative form) a certain 111

course of action is deprecated but not prohibited (should equals is recommended that). 112

The word may is used to indicate a course of action permissible within the limits of the 113

Specification (may equals is permitted to). 114

The word can is used for statements of possibility and capability, whether material, 115

physical, or causal (can equals is able to). 116

All sections are Normative, unless they are explicitly indicated to be Informative: 117

• The Normative parts of this Specification contain the information needed to correctly implement 118

this Specification, i.e. all specified technical requirements (‘shall’), recommendations (‘should’), 119

and options (‘may’). The Normative parts are all Sections and Annexes not marked 120

“(Informative)”, including text, Figures, and Tables. 121

• The Informative parts of this Specification present supplemental material not directly needed to 122

correctly implement this Specification but intended for information only, such as examples, 123

guidance, or further explanation such as boundary cases. The Informative parts are: Sections and 124

Annexes marked “(Informative)” (including text, Figures, and Tables), and front matter. 125

Numbers are decimal unless otherwise indicated. A prefix of 0x indicates a hexadecimal number, while a 126

prefix of 0b indicates a binary number. In some cases single-bit binary values may alternately be designated 127

in the Specification as ‘0’ or ‘1’. 128

The convention used herein for multi-bit designations in vectored signals is, from left-to-right, the most 129

significant bit-to-the least significant bit which are to be considered as a part of that entity, with the use of a 130

colon (“:”) as a separator. 131

A designation using [...] indicates absolute bit positions within a byte-wide entity, and within full bytes as 132

transmitted as part of an RFFE bit stream. Entities designated using <...> for bit field designation are used 133

to provide information regarding bit positions within whatever size bit field is defined for a given entity, or 134

argument, and relative only to the size of that bit field. 135

Thus a Register_A[7:0], which has a Function_X<3:0> defined to exist using Register_A[7:4] may be 136

referred to as being transmitted in, and/or stored in, Register_A[7:4], or equivalently, it may be defined and 137

referred to as Function_X<3:0>. Alternatively, if that function consists of a sub-field of the 8-bit register, it 138

may be referred to by another name while still using the [....] notation. An example of this is that 139

PWR_MODE[1:0] is defined to consist of PM_TRIG[7:6]. Note that this alternative representation is only 140

potentially suitable for sub-fields of a single register. 141

Specification for RFFE Version 3.0

01-Dec-2019

Confidential

2.1 Definitions 157

Address Frame (AF): A series of nine bits with eight bits representing address information and a single 158

parity bit. The frame structure for an Address Frame is identical to that for a Data Frame, with the only 159

difference being in the purpose of the data being carried in the frame. The frame boundaries are delineated 160

only by occurring at the proper time during a Command Sequence. 161

Broadcast: A procedure of sending a Command Sequence to multiple recipients simultaneously using 162

either Broadcast Slave ID (BSID) or another Group Slave ID (GSID). 163

Broadcast Slave ID (BSID): A unique Group Slave ID (GSID), defined as a Slave Address of 0b0000, 164

which addresses all Slaves on an RFFE bus instance simultaneously. 165

Bus Clocked Condition (BCC): The RFFE bus is in a Bus Clocked Condition when the SDATA line is 166

held at a logic ‘0’ level, while the SCLK signal is issuing normal SCLK pulses. The BCC may occur 167

anytime that a BIC would normally occur, but not before the initiation of RFFE traffic on a newly 168

initialized RFFE bus. Thus, a BCC may exist between the end of a Command Sequence and the beginning 169

of the next Command Sequence, and may be interspersed with BICs. 170

Bus Idle / Bus Idle Condition (BIC): The RFFE bus is idle when both the SCLK and SDATA are held at a 171

logic ‘0’ level between the end of a Command Sequence and the beginning of the next Command 172

Sequence. An RFFE bus may also said to be in a BIC upon initialization, prior to the issuance of an RFFE 173

Command Sequence. 174

Bus Handover / Bus Handover Cycle (BHC): The process by which the current BOM Master transfers 175

bus control/ownership to another Master device, or next BOM, on the RFFE bus. The Bus Handover Cycle 176

is a specific clock cycle denoting when the bus handover occurs. 177

Bus Owner Master (BOM): The Master device which, at any given time, is in control of an RFFE bus. 178

This is also characterized by which Master device is the source for SCLK, and thus is in control of all bus 179

traffic and operations. In a single-Master RFFE system, such as is defined in RFFE v1.x, the sole Master is, 180

by definition, the Bus Owner Master at all times. 181

Bus Park Cycle (BPC): A single clock cycle that occurs when the control, or sourcing, of the SDATA 182

signal may change between devices during, or at the end of, a Command Sequence. An RFFE bus is also 183

‘parked’ – i.e. SDATA driven to a ‘0’ logic level to allow the bus pull-down to hold it there – prior to 184

entering into a Bus Idle Condition. Bus Park Cycles may be further differentiated as either a Master-185

initiated Bus Park Cycle (M-BPC), or a Slave-initiated Bus Park Cycle (S-BPC), depending on which 186

device is driving SDATA and thus is releasing the SDATA line. A further variant of an M-BPC is that of a 187

‘silent’ Master-initiated Bus Park Cycle (sM-BPC), in which a BOM Master drives the SDATA line as in an 188

M-BPC, but does so without any activity on the SCLK line. 189

Byte: A collection of eight bits of data. RFFE is a byte-oriented interface, with 8 bits of data defined to 190

exist at each specific register address location. 191

Command Frame (CF): A series of thirteen bits with four bits representing a Master or Slave address, 192

eight bits representing an RFFE command and a single parity bit. The frame boundaries are delineated only 193

by occurring at the proper time during a Command Sequence. 194

Command Sequence (CS): A bus transaction on the RFFE bus that begins with a Sequence Start 195

Condition, follows this with a Command Frame, and then potentially one or more Data / Address Frames, 196

and is then typically ended with a Bus Park Cycle. 197

Context: A collection of information passed between Masters in a Multi-Master configuration. The context 198

information may contain a variety of information such as RF band usages, indications of current front-end 199

configuration, current power levels, and other relevant information. This is defined for a given 200

configuration, as determined by the Master implementer. 201

剩余273页未读，继续阅读

Zoe1799

粉丝: 0
资源: 3

"MIPI RFFE规范3.0详解：RF前端控制接口（RFFESM）版本3.0"

MIPI_RFFE_协议.pdf

MIPI_RFFE_Specification_v1-10.pdf

mipi_rffe_specification_v1-00-00a.pdf

mipi_rffe_specification_v3-0.pdf

MIPI_D-PHY 、mipi-DSI、MIPI_CSI-2_specification.pdf

MIPI_D-PHY_Specification.pdf

MIPI_DCS_specification_v1.02.00.zip_DCS_DCS MIPI_MIPI DCS_mipi_m

mipi_CSI-2_specification_v1_mipi_CSI2资料_mipicsi2_mipi_MIPIcsi_mi

mipi_CSI-2_specification_v1.3.pdf

MIPI_DCS_specification_v1.02.00.rar_DCS MIPI_MIPI DCS_MIPI的DCS列表

最新资源