SMBus ARP流程分析（spec v3.3）

术语

• ARP Controller
  负责执行ARP并为ARP功能的目标设备分配地址的SMBus控制器（硬件、软件或两者的组合）。通常由SMBus主机担任，但在某些情况下，其他SMBus控制器也可能承担此角色。任何时候只有一个活动的ARP controller
• Device

分类	描述
ARP-capable Device	支持所有ARP命令，除了可选的主机通知命令。目标地址是可分配的。设备支持两种重置命令。
Fixed and Discoverable Device	支持“准备ARP”、“定向获取UDID”、“通用获取UDID”和“分配地址”命令。目标地址是固定的；设备将接受“分配地址”命令，但不允许重新分配地址。设备支持两种重置命令。
Fixed, not Discoverable Device	支持“定向获取UDID”命令。目标地址是固定的。
Non-ARP-capable Device	不支持任何ARP命令。目标地址是固定的。

• AV: Address Valid flag
  状态标志，用于表示设备的从地址是否有效；当AV Flag被设置为“SET”时，表示设备的从地址是有效的；当AV Flag被清除为“CLEAR”时，表示设备的从地址无效

• AR: Address Resolved flag
  状态标志，用于指示设备的从地址是否已经被controller解析并分配

• FTA: Fixed Target Address
  指设备的固定目标地址，这个地址不能被更改。非ARP功能的SMBus设备通常使用FTA,ARP controller不能将已使用的FTA地址分配给ARP功能的设备

• PTA: Persistent Target Address
  指设备在断电后仍然保留的目标地址。这种地址是通过设备的非易失性存储器（NVR）保存的，因此在设备重新上电后，它会继续使用这个地址，直到被ARP控制器解析和分配新的地址

• DTA: Default Target Address
  指设备在上电后从只读存储器（ROM）中加载的默认目标地址。这个地址是制造商分配的，通常在设备上电时使用

流程

device流程

初始化(1-5)

是否具有永久（默认）地址 并且进行有效性检查，有效则将AV置位；并将AR（标识此地址是否由ARP机制分配）复位

发起“Notify ARP Controller”报文(6)(可选)

SMBus Host Notify protocol

“Notify ARP Controller”报文为“standard SMBus Host Notify protocol"的例化

• SMBus Host Notify protocol
  “standard SMBus Host Notify protocol”报文为"Write Word protocol"的例化
  
  注意：分析可知，device设备实现此功能的前提是该设备具备产生start/stop信号的能力，即可作为master

  • SMBus Host Address:
    为最小有效地址0x08，用于标识从设备发起通知事件
    
  • Device Address
    从设备地址，其中0x61为默认地址
    

等待SMBus packet(7)

地址检查(8-10)

若收到报文中Targe Address不是0x61(SMBus ARP Address/SMBus Device Default Address)，则判定其地址是否和
自身（Target Address Filed）地址匹配，如果仍不相同则则继续等待报文。

正常逻辑处理(11)

若接收报文的地址与自身（Target Address Filed）地址匹配，则应答(Ack)此报文，并正常处理此报文，处理完成后继续等待其他报文。

报文处理

Prepare To ARP Command(12-13)

“Prepare To ARP Command”报文报文为“standard SMBus Send Byte Protocol"的例化
ARP流程初始化报文，用于通告所有devices，ARP Controller发起ARP流程
协议规定所有devices：

• 必须应答此报文
• 复位AR标志
• 取消正准备发送的“Notify ARP Controller"报文

若ARP Controller未收到Ack，则认为此总线上无ARP-capable设备；协议推荐未收到Ack时重传报文（次数未推荐）以避免噪声干扰。

General Reset Device Command(14-15)

“General Reset Device Command”报文报文为“standard SMBus Send Byte Protocol"的例化
此报文用于通告所有non-PTA, ARP-capable设备返回其初始状态，即ARP-capable devices：

• 必须应答此报文
• 复位AR标志
• 使用随机数作为UDID的设备重新生成随机数
• 复位AV标(non-PTA设备)
• 配置自身地址为Default Target Addresses(支持DTA的设备)

若ARP Controller未收到Ack，则认为此总线上无ARP-capable设备；此报文仅用于ARP功能复位，而非设备复位。

Assign Address Command(16-18)

“Assign Address Command”报文报文为“standard SMBus Block Write Protocol"的例化

地址分配机制为ARP Controller利用UDID的唯一性，确定唯一设备获得此地址，具体流程如下：

• 所有ARP-capable设备监听UDID报文字段，一旦发现某一字节与自身UDID不匹配，则不应答此字节以及接下来的字节
• ARP Controller在此报文的任意字节未收到Ack，则认为目标设备不存在；同时建议重传此报文以避免噪声干扰
• 全匹配此UDID的设备则：
  • 必须立即接受此地址(Bit 0无效忽略)
  • 更新PTA
  • 支持DTA的设备：
    • 存储此地址
    • 置位AV标志
    • 置位AR标志（意味着除非重新接收到"Prepare To ARP"或"Reset Device"报文或者设置重启，否则不需要再应答”Get UDID"报文）
      注意：即便AR标志置位，从设备仍需处理此报文，若设备计算出的PEC与报文中不相同，则：不应答PEC、忽略此报文

General Get UDID Command(19,21-25)

“General Get UDID Command”报文报文为“standard SMBus Block Read Protocol"的例化

UDID(Unique Device IDentifier)

顾名思义，是为了给设备分配地址，区分设备唯一性的需要，定义16Byte的UDID
组成如下：
其中Device Capabilities字段用于描述设备特性，而且Address Type用于保证ARP机制
由于线与逻辑，“0”优先于“1”，故而Address Type优先级(相似的理解静态路由优于动态路由)为：
FA>DPA>DVA>RND

Get UDID(general)用于ARP Controller发现设备（单次报文只能发现一个设备，多次报文可发现总线上全部设备），ARP-captable设备接收报文后执行：

• 若AR=1，不应答并丢弃报文
• 若AR=0

  • 发送自身UDID，同时监听总线，若有冲突（按位比较）则立即停止发送

  • 若AV=1, 将报文的Data17(Device Target Address)字段充填为当前地址（Current Target Address）

  • 若AV=0,将Data17(Device Target Address)字段充填为0xFF

• ARP Controller在此报文的前三字节的任何一个字节未收到Ack，则认为当前总线上无ARP-capable/可被发现的设备或者所有ARP-capable设备已经分配了有效地址

注意：

• Data17(Device Target Address)的bit0必须充填1
• AV标志复位的设备必须将Dtata17的地址位充填0x7F

Directed Reset Command(26)

相比于“Reset device ARP(general)"，不同点仅在接收者广度差异，响应策略相同。
“Reset device ARP(directed)”报文报文为“standard SMBus Send Byte Protocol"的例化
此报文用于通告一个特定的non-PTA, ARP-capable设备返回其初始状态，即ARP-capable devices：

• 必须应答此报文
• 复位AR标志
• 使用随机数作为UDID的设备重新生成随机数
• 复位AV标(non-PTA设备)
• 配置自身地址为Default Target Addresses(支持DTA的设备)

若ARP Controller未收到Ack，则认为此总线上无ARP-capable设备；此报文仅用于ARP功能复位，而非设备复位。

Directed Get UDID Command(27、29)

“Directed Get UDID Command”报文报文为“standard SMBus Block Read Protocol"的例化

Get UDID(directed)用于ARP Controller获取Targeted Device Address设备的UDID
与此地址相同的设备执行：

• 若AV=0，不应答并丢弃报文
• 若AV=1，返回UDID和当前地址
• ARP Controller在此报文的前三字节的任何一个字节未收到Ack，则认为当前总线上无此地址的ARP-capable设备

注意：

• Data17(Device Target Address)的bit0必须充填1

controller流程

初始化(1)

初始化Used Address Pool，添加SMBus的保留地址

Send “Prepare To ARP”(2)

"Prepare To ARP"报文见device流程–>报文处理–>Prepare To ARP Command

Packet ACKed?(3)

根据是否收到”Prepare To ARP"报文应答，判断总线上是否存在ARP-capable设备

地址分配(6-14)

6-14步骤为地址分配流程，其中：

• 通过步骤7判断所发送的”Get UDID"报文回复情况判定总线上ARP地址分配是否已完成
• 通过步骤8——“Get UDID”中Device Target Address字段是否为0xFF判定此UDID设备地址是否已分配
• 通过步骤9——UDID的Device Capabilities字段是否为00b(固定地址设备)决定分配给此UDID设备的地址
  • 若设备类型为FAD，则使用其上报地址，将其地址加入Used Address Pool（地址冲突如何解决？）
  • 若设备类型不为FAD，则判断其地址是否存在Used Address Pool中，存在则重新生成地址分配，不存在则使用其上报地址

注意：设备类型为FAD则不对地址判重，将有地址冲突风险，使用前手动规划解决？

报文接收处理

5、15-16步骤为接收报文处理流程

报文分类

实例

详见SMBus ARP实例流程分析