首先我们来看一下交流机对数据的处理流程，网络测试仪发出的数据首先经由接口进入分流模块，我们的交流机支持TT业务（韶光触发）和ET业务（普通以太网），本文就ET业务进行剖析。以太网帧进入MAC核进行CRC校验，
并将8位输入数据转32位输出，转换模块将数据转换为128位总线数据，并支持反压。接着数据经由轮询进入分组处理模块，分组处理模块一方面将数据帧传入吸收总线，另一方面根据帧信息提取结果和流分类信息将接管帧信息传入入队模块进行逻辑入队，逻辑入队模块管理着一个虚拟的存储块，每一个虚拟的存储块对应着真实的物理数据，也便是数据帧。缓存管理模块根据入队和出队情形更新存储块信息，同时更新的还有行列步队的长度等信息。数据帧出队时首先由逻辑预出队模块根据优先级轮询行列步队，并给出出队号，逻辑出队模块根据端口号查询出队信息，然后掌握总线发送数据，数据经由转换模块转32位然后经mac核输出。
粗略理解了交流机的构造，言归正传，数据溢出为什么会导致交流机“假性卡去世”？
首先我们须要深入理解一下逻辑出队预出队模块，这个模块会产生出队号，并将出队号传入schedule_dequeue模块，然后schedlue_dequeue模块根据出队号得到出队帧首地址，并查询虚拟块地址，从而得到数据的物理存储地址，进行数据搬移。
现在我们说一下征象，上板时，交流机4个口接到testcenter，每个口打1Gbps数据流，固定帧长为64Bytes，个中1、2口打对流，3、4口打对流。当testcenter准备好后直接给交流机4个口同时打数据流，这时有两个口正常事情，但是其余两个口卡去世，没有帧出来。如果在一开始将数据流速率掌握在90%，打一阵流之后在将4个口速率提升到100%，则不会涌现上述卡去世征象。我们经由剖析，认为交流机是能够处理每个端口1Gbps速率的数据流，否则其余两个正常事情的行列步队便无法阐明。那么问题出在哪里了？
我们根据履历，首先对入队和出队关于帧长信息的更新，入队与出队产生冲突时行列步队头部和尾部信息的更新等等进行了检讨，经由仿真和比拟更新数据，确实创造了一些小bug，本以为这便是终极bug，结果兴冲冲的跑了一版程序去上板测试，创造还是上述征象！
这解释我们没有找到关键点。
创造问题
这里要为大家先容一种调试代码的方法，便是计数法。为了找出问题出在哪里，我们对逻辑入队、物理入队的各行列步队帧数进行统计，将其与逻辑出队、物理出队的各行列步队帧数进行比拟。这时我们创造，逻辑入队和物理入队帧数目同等，
逻辑出队和物理出队帧数目同等，但是入队和出队数目不一致，两者相差256，但是行列步队里显示有255个帧，这是由行列步队门限决定的，那么实在有履历的你就能大概猜到这个差值256有点问题。是的没错，问题就出在这里。
我们查看代码创造，
这里的port_state_data_in_b会根据优先级更新相应行列步队的帧数目，顾名思义，它的低8位代表的是优先级为0帧的数目。当入队的行列步队号为00并且入队成功后，其低8位会加1，出队成功则减1，上图展示的便是出队时的代码。但是我们要知道，优先级为0的行列步队最多有8个，由于行列步队号是由{端口号，优先级}的形式组成的，也便是说一个优先级对应8个端口号。前面我们说了一个行列步队的门限是256，也便是0-255。那么当优先级为0的a行列步队已满，这时优先级为0的b行列步队再来一个帧，port_state_data_out_b的值就会达到256，由于其只有8位，以是port_state_data_out_b的值实在是0！
这就很麻烦了，由于机器不足智能，只能够按照你的代码按部就班的实行。
以是卡去世的缘故原由出来了，由于port_state_data_out_b溢出置0，导致pri_val一贯为0，以是状态机一贯在进行一个循环，不能完成正常跳转！
而这个模块供应了出队号，当其没有供应出队号时，schedule_dequeue模块就无法产生出队指令，总线也没办法进行数据搬移，从而对外显示为“卡去世状态”。
创造了问题，办理起来就很大略了，我们只须要将优先级对应的行列步队计数器计数上限设置到八个端口的最大值2048即可，也便是12位的数据位宽。如下图：
写在末了，每每最微不足道的问题最不随意马虎让人创造。这个位宽不敷所导致的问题笔者找了良久，检讨过很多模块，虽然这个中创造了一些其他bug，但是办理这个大bug的过程却是费时费力的，但是设计者在设计代码时只须要负责考虑承载功能所须要的位宽，便能为后续调试减轻许多麻烦！
原我们都养成一个良好的习气。
全文完。
