MIPI MPHY学习

cy413026

已于 2024-01-08 11:22:33 修改

阅读量1.9k

点赞数 25

分类专栏：高速接口文章标签： MPHY

于 2023-12-20 18:03:14 首次发布

本文链接：https://blog.csdn.net/cy413026/article/details/135108319

版权

高速接口专栏收录该内容

5 篇文章 4 订阅

订阅专栏

本文参考MPHY v0.8 r0.01版本

1.burst之间是否一定进入save状态?

2.和CDPHY有哪些区别

CDPHY的line可以是双向的，MPHY的line都是单向的，两个相反方向组成一个双单工lane，原因在于MPHY的应用场景是双向传输是等价的，所以CDPHY那种不合适

MPHY的HS和LS之间切换不会有电压幅度的变化，MPHY的LS也是差分传输

3.PAYLOAD在LANE上的分配

和CDPHY的数据分配由PHY决定不同，这里是由协议层确定的。比如UniPro和DigRF使用MPHY时，都是不同的分配策略。

4.Bit SYNC

4.1 HS-MODE

只有HS-Mode才有sync sequence，用来做数据和CDR恢复时钟的位同步。

先说一下什么是位同步，位同步是为了在RX端能够用clk正确采样bit流的过程。换句话说就是调整clk与数据bit流之间的相位。

首先要恢复出正确的时钟，8b10b编码就是为了恢复时钟，所以SYNC序列本身是可以恢复时钟的。然后需要bit同步，那RX端就需要知道发送的SYNC序列是什么。

首先10bit数据最多"0101010101"9个变化沿，SYNC用了7个变化沿及以上的序列。可以快速的恢复clk并做位同步

4.2 PWM-BURST

对于TYPE-I型的PWM-BURST，PWM信号的是self-clocked

关键问题是self-clocked的不仅能恢复出正确的采样频率，同时恢复的clk的相位和PWM下降沿相位是可控的。

所以才不需要SYNC序列

从上图来看，下降沿间隔就是一个bit周期，但是如何用这个下降沿产生能够正确采样pwm的clk呢？

另外如果要正确分辨当前是1还是0，需要的采样clk频率要比bit周期至少高1倍。

用输入信号的下降沿做寄存器的clk，可以产生一个周期为 $2T_{clk\_bit}$ 的时钟，在对这个clk进行多倍频之后就可以采样PWM信号。

$T_{PWM\_MAJOR}:T_{PWM\_MINOR}=2:1$

所以TX端要产生这样的信号，最好的方法就是有一个高频的clk_h=3clk_bit.也就是clk_h的工作频率是bit率的3倍。这样就容易产生 $2T_{clk\_h}$ 的 $T_{PWM\_MAJOR}$ 和 $T_{clk\_h}$ 的 $T_{PWM\_MINOR}$ 。

4.3 SYS-BURST

对于TYPE-II型的SYS-BURST，TX和RX用的是同步时钟，所以不需要专门的位同步

5.BURST同步

有了bit同步，但是需要知道当前burst的开头和结尾，这样才能知道PAYLOAD在哪里。

MK0就用于HEAD-OF-BURST

MK2就表示TAIL-OF-BURST

6.时钟恢复

TYPE-I ：PWM的时钟恢复，PWM脉冲宽度调制信号本身就自带时钟信息，下降沿间隔就是时钟周期【4.1节给出了一种恢复时钟的电路】，可以认为是有固定频率的，但每个周期内的高电平和低电平比例不确定，用高低电平的比例来发送0和1.

8b10b编码就是为了clk recovery。SYNC有7个及以上的变化沿更能够快速的恢复clk，并进行位同步

TYPE-II：TX和RX共用一个refclk，要么来自TX要么来自RX

HS mode：利用8b10b编码和CDR电路恢复时钟

7.HS和LS的速率

7.1 HS的档位划分

可以看出来单lane最高速率可达5.8Gbps【HDMI 2.0单lane6Gbps；DPHY 2.0 单lane 4.5Gbps CPHY1.2 单trio 3.5x2.28 Gbps】

7.2 PWM的档位

可以看出来LS的最高档位速率达到576Mbps

7.3 SYS-Burst的速率

SYS-Burst没有多个传输速率的档位划分，只有一种速率是和共享参考时钟频率相等,为 $f_{sys\_ref}$

8. 8b10b编码的作用

MPHY的spec明确给出了8/10b编码的作用：

频谱调节(扩频)
时钟恢复
带内控制

9.Disparity和run-disparity

TODO

10.PWM型MPHY的状态机

下面只以PWM为例，给出状态机。

上面所有的状态分为了下面几类：

SAVE States

包括STALL,SLEEP,HIBERN8,DISABLED和UNPOWERED。但是只有STALL，SLEEP和HIBERN8状态是可以将shadow寄存器更新到effective 寄存器上的。

Burst States General

HS-MODE和LS-MODE各有一个Burst，即HS-BURST和PWM-BURST/SYS-BURST

Burst States Individual

各个Burst的独特状态，和传输速率的档位有关，参考第7章

Break States

也是一类功能状态，这类状态是要经过和正常传输数据特性【多bit0或多bit1等】不一样的序列才能进入

包括：

LINE-RESET
LINE-CFG(Type-I only)

line-cfg下面单独讲解

11. SAP和原语(primitives)

11.1 SAP和原语的概念

SAP：server access point

SAP和原语只是描述protocol与PHY之间的交互概念或者说是事件【包括参数条件】，然后把控制接口和数据接口做了分类。实际上接口(interFace)和没有SAP及原语概念的MIPI CDPHY接口没啥区别。

原语分为以下几类，看起来和信号一样有req/rdy/res/cfm的区别，但实际上往往在模块之间并不是直接传递原语这样的数据结构或者原语包【当然我认为也可以把原语以数据包的形式传递】

原语是一种抽象的，独立于现实的表示方法，表示服务提供者和服务使用者之间的交互。

下面定义的原语结构看起来像个函数或者结构体，这只是为了描述一个原语。或许在软件代码中可以直接使用下面的结构体或者类，但在硬件中都是通过信号来传输的。

下面我们以实例把原语和信号时序结合起来说明原语和实际电路动作的关系。

11.1.1 DATA SAP的prepare原语与时序

request原语是TX protocol发起，请求M-TX从save状态进入到BURST状态

indication原语是M-RX检测到Prepare状态之后，向RX protocol上报

confirm原语是M-TX已经进入PREPARE的状态后上报protocol。

PREPARE状态可以说是PHY开始传输数据的开始，那么电路上是如何开始进入BURST传输状态的呢？过程如下：

protocol拉起TX_BURST信号----对应M-LANE-PREPARE.request
M-TX收到TX_BURST后将Lane状态驱动为DIF-P，持续 $T_{HS\_PREPARE}$
M-RX检测到Lane的状态由DIF-N转到DIF-P并持续了给定时间，M-RX进入PREPARE状态，同时拉高RX_Burst信号----对应M-LANE-PREPARE.indication
M-TX在驱动DIF-P指定时间后，拉高TX_PhyDIRdy信号，告诉protocol可以发送SYNC或payload------对应M-LANE-PREPARE.confirm

所以原语在protocol和PHY内部实现就是一个状态机，而不是以某种数据结构出现。

11.1.2 CTRL SAP的CFGSET/CFGREADY原语及时序

request原语是T/RX protocol想要配置MIBattribute的值为MIBvalue

confirm原语就表示属性值已经配置到对应寄存器【可以是shadow寄存器或者effective寄存器】

接着配置寄存器什么时候有效还要依赖PHY的状态，反应到M-CTRL-CFGRDY原语。

这个request原语就是表示T/RX的protocol在配置完所有的MIBattribute属性值之后要求T/Rxupdata这些配置并产生实际效果。如果此时PHY正处在BURST状态，会被protocol控制尽快转到save状态。

confirm这个原语就表示这些配置已经全部updata。

将原语与电路时序联系起来如下：

protocol拉高T/RX_cfgEnbl，T/RX_attrWRn，根据原语参数MIBattribute和MIBvalue来驱动T/RX_AttrID及T/RX_AttrWrVal-----对应原语M-CTRL-CFGSET.request
对于写shadow寄存器，在除了DISABLE，UNPOWERED之外都可以，此时可以认为confirm为1；当要写effective寄存器时，protocol在步骤1的基础上拉高T/RX_InLnCfg。如果T/RX_CfgRdyN=0则认为写入effective寄存器----对应原语M-CTRL-CFGSET.confirm
对于写在shadow寄存器的配置，protocol需要这些配置effective时，拉高T/RX_CfgUpdt----对应原语M-CTRL-CFGREADY.request
当T/RX_CfgRdyN=0时，对应的T/RX_CfgUpdt才会起作用----对应原语M-CTRL-CFGREADY.confirm

11.2 M-T/RX-DATA SAP时序

11.3 M-T/RX-CTRL SAP时序

11.3.1 RESET和LINERESET原语

区别M-CTRL-RESET.xxx和M-CTRL-LINERESET.xxx这两个原语的不同。

LineReset会同时复位RX，且有专门的LINE-RESET状态

LineReset时TX会发送对应信号给RX【DIF-P持续时间超过 $T_{line\_reset\_detect}$ 】，RX接收到之后会产生M-CTRL-LINERESET.indication给RX的protocol。所以M-RX是不会主动发起LineReset的

lineReset之后TX和RX的链接是否还存在？

而M-CTRL-Reset是TX/RX分别独立由本地发起的，由对应的protocol拉高T/RX_Reset信号。Reset.request时，处于DISABLE状态，Reset.confirm时，处于HIBERN8状态。

虽然T/RX_reset是两边各自控制，一旦有一方发生LocalReset，对端都应该能够感知。具体是通过检测Lane上电平状态还是通过双单工Lane来向对端发送相关信息这个待确认。

从DISABLE的描述来看，DISABLE就断了TX和RX的通路，但不能确定RX的protocol是否可以主动发起M-CTRL-RESET操作。

12.LINE-CFG

LINE-CFG只有PWM类型的MPHY才有该状态。目前已知的唯一用途是当LANE上包含Media Converter的时候,MPHY用该状态来读写Media Converter的配置属性。

没有见到M-TX和M-RX直接用line-cfg通信，但从LCC来说我觉得M-TX和M-RX可以使用line-cfg来协商BURST的Gear。但这里后面的描述都是假设带有OMC的。如上图这里面有一个O-TX和O-RX。

linecfg包含以下几个过程：

LINE-INIT
LCC(Line control command)
Line-read和Line-write Frame
RCT(Re-Configuration Trigger)

第一步：LINE-INIT是M-TX发起

当BURST状态发送9个1'b1之后，M-TX进入line-cfg的init。O-TX/O-RX/M-RX接收到超过9个1之后分别进入line-cfg的line-init子状态。也就是说DIF-P是在O-TX/O-RX上透传

第二步：开始发送LCC的命令

LCC一共有以下几种

对于OMC来说还会单独定义几个LCC，如下：

相比于普通LCC，OMC的LCC定义了READ-CUSTOM-OTX/READ-CUSTOM-ORX和WRITE-CUSTOM-OTX/WRITE-CUSTOM-ORX。也就是说普通的LCC命令都是会被O-TX/O-RX/M-RX一起解析并起作用，但READ/WRITE-CUSTOM-OTX只会被O-TX解析并起作用。

note：