作者：FPGA的现今未
在RGMII接口的设计中，除了上述2个方面外，还有一个重要的方面就是接口的时钟和复位方案。为什么会有这个问题呢？最重要的原因就是有网口的插拔。因为网口的插拔会导致随路时钟的丢弃，从而会引起一系列需要考虑的问题……
时钟方案
RGMII接口数据的采样是采用的随路时钟。对于简单的系统，比如RGMII接口接收数据后简单处理就发送出去，这种简单系统的系统时钟可以就采用RGMII接口的随路时钟。对于复杂的系统，往往有单独的系统时钟，和RGMII接口随路时钟是不一样的，这个时候就需要好好考虑时钟方案了。这里主要讨论系统时钟和RGMII接口随路时钟不一致的场景。
如上图所示，是MAC的一个方案图，随路时钟到系统时钟域的转换往往在MAC中完成。上图中MAC是工作在随路时钟，数据流经过MAC后，最后通过时钟域转换进入到系统时钟域。当然MAC也可以工作在系统时钟域，如下图所示，数据流从RGMII接口转GMII接口后，先经过时钟域转换进入系统时钟域，然后经过MAC处理。
无论哪一种方案，都是可以的，但是关键的问题是考虑网线拔掉后，没有了随路时钟，MAC应该做哪些处理，从而保证功能的稳定可靠。这里主要考虑的问题就是残报。我们拔掉网线后，报文可能只传输了一半，可能会形成一个残报，或者说超短包。
对于第一种时钟方案，这个报文可能已经写入时钟转换的FIFO中，由于写时钟（RGMII随路时钟）丢失，从系统时钟域读出的报文不但是超短包可能还没有EOP，那么在系统时钟域必须做容错处理，保障这样的报文丢弃，或者等待和下一个有效报文合并。
对于第二种时钟方案，由于MAC工作在系统时钟域，同样从时钟域转换FIFO中读出的报文是超短包，刚好MAC有过滤功能，可以解决这个问题。但是这里有一个问题需要注意，RGMII接口传输一个完整的报文是通过数据有效信号de来指示的，de信号下降沿表示一个报文的结束，因此在时钟域转换的时候，要保证整包的传输。
复位
RGMII接口的复位方案，主要就考虑一个问题，拔掉网线后是否复位？这就看系统时钟的来源。
如果系统时钟是由RGMII接口随路时钟分频得到的，那随路时钟丢失后，系统时钟也会丢失，整个FPGA没有时钟，这个时候FPGA最好处于复位状态。
第二种方案就是系统时钟是由外部晶振或者其它时钟分频得到，网线拔掉后，RGMII接口的随路时钟丢失，但是不影响系统时钟，我们在实际项目中遇到的大部分的场景也是这种情况。如果整个系统的数据处理的唯一通路就是这个网口，那拔掉网线后，FPGA处于复位状态也无可厚非。如果是多个网口，或者还有其他和网口无关的功能，那拔掉网线后整个FPGA肯定是不能处于复位状态的，只需要由上文提到的，解决插拔网线后引起的残报即可。
不管是哪种场景，还是建议拔掉网线后不要复位整个系统，从定位问题的角度，如果反复插拔网线这个功能上有问题，复位系统后可能就不太方便定位问题了……
总结
虽然这里讨论的是RGMII接口的场景，但是这种随路时钟的处理，在其他场景中也会遇到，比如采用行场同步信号的视频接口，也是采用随路时钟，拔掉视频线后，时钟丢失，也会引起视频残帧。
同理，对于随路时钟域的复位，在其他领域也有同样的问题，比如视频接口的随路时钟域，也需要同样的考虑如何有效的复位。
