【USB3.0协议学习】Topic1·USB3.0Hub的一些机制
一、USB3.0 Hub的单播（非广播）机制
Hub通过解析下行packet header中的Route String字段识别packet要传递的终点，其中4'b0000代表hub本身，4'b0001-4'b1111分别代表hub的各downstream port，由于USB3.0规定Host Controller最多级联5级hub，所以每个packet header中的Route String字段共有4x5=20bit。Packet中Route String字段位于Downstream Packet Header的DW0中，如图1所示。
对于上行Packet，由于都是传递给Host Controller的Packet，因此没有Route String字段，如图2所示。
图3是Hub的链接拓扑和Route String的映射关系，通过Route String可以明确指定该Packet要传递到的位置。
二、USB3.0 Hub的存储转发机制
Hub的两种下行数据包：
Hub本身可以作为一个device，其在usb的拓扑结构中也拥有地址，所以host传递给hub的包分两种情况：
1. host传递给Hub本身的数据包。例如 SetHubAddress或者GetPortStatus操作，这些数据包的终点就是Hub本身，这种是会牵扯到hub的protocol layer。如图4所示，host传递了一个packet给hub，hub的协议层对数据包处理后对downstream port0进行了设置
2. host通过hub透传给device的数据包。这些包是link to link级别传递的，不会牵扯到hub的protocol layer；
Hub的buffer需求
Hub中分为两类buffer：Header buffer和Data Buffer，前者用于缓存packet header，后者用于缓存data payload。Header 的大小是16Bytes，hub的每个downstream port和upstream port都分别有4个tx buffer和4个rx buffer（每个buffer只存一个packet header）。一个hub只有一个下行data buffer和一个上行data buffer，如图6所示。
关于上图的解释：
1.payload很大，所有payload全部存下来浪费资源，因此hub收到payload的第一时间就会传递，但是前提是header已经传递了（因为header必须在payload之前发送）。在header还没传递之前的小部分Data payload会被data buffer缓存下来。
2.左边downstream port1的Data15的header还在buffer中没有传递，所以Date15的payload会在hub的downstream data buffer中先缓存住，直到DATA15的header传给了对应的device，则Date15的payload往下传递；
3.右边同理，DATA31的header在upstream port的header buffer里还没传递，在upstream Data Buffer中会缓存住Data30的payload；
注意：Hub往device发的packet顺序必须和host给hub发的packet顺序一致
三、Hub的Deferred（推迟机制）
上图是一个deferred的示意图，解释如下：
- Host起初试图发起In Transfer，于是给Device B发送了ACK。此时Downstream Port4的LTSSM状态机处于U1状态，不能立马传递信息，对应步骤①②；
- Downstream port4给Host传回ACK（将Deferred bit，Delayed Bit和Hub Depth在ACK packet的Link Control Word中进行了设置，如下图所示），对应步骤③；
-
Host收到该消息后，暂时将该任务放一边，并发起Device A的传输任务，对应步骤④；
-
Hub的Downstream Port4把之前deferred的ACK存下来了，等到LTSSM状态机恢复到U0状态后再把ACK传递给Device B，然后Device B传回ERDY，对应步骤⑤⑥；
-
该ERDY收到后，Host会重新给Device B发起ACK，完成之前被推迟的传输。
四、Hub的错误检测和重传机制
Hub的错误检测是通过对packet中的CRC进行校验完成的：
- 对于header错误会执行链路级的重传，并丢弃掉对应的data payload。例如，Hub的downstream port发送了header后，该header仍然会存在对应port的header buffer中，直到收到device传回的LGOOD_n。这个机制跟host和device的链路重传是一样的）
- 若header没错，但payload错误则hub不会进行处理（它把该packet继续传下去，因为payload没有链路级别的重传机制）
