基于共享缓存的架构的系统“假性卡死”问题分析

作者：高志凯

一次常规调试中发现上电后交换机多个口同时打流会导致卡死的现象，最后一步步分析问题出现的原因是位宽不够导致的溢出。这让我回想起团队已经量产的某款芯片，也是因为某个寄存器位宽设置过小的原因，导致组播组设置的时候不能超过31，否则就会溢出，只能想办法通过软件来解决这个问题。这次出现问题的交换机是基于共享缓存的架构，希望后面引以为戒，设计每个小的寄存器时都要考虑全面。

背景

在使用verilog进行程序设计时，尤其需要注意数据位宽问题。当我们将程序烧入fpga的时候电路已经固定，不能像C语言那样动态改变数组长度，因此数据位宽设计不恰当会引入意想不到的问题。例如我们使用二进制进行计数时，位宽为5的数据表示范围为0-31，当数据为32时由于位宽不够，实际显示则为0，如果此时你需要对这个数进行大小判断，那么可能会得到错误的结果。笔者在交换机功能调试、解决bug的过程中对此深有体会。

首先我们来看一下交换机对数据的处理流程，网络测试仪发出的数据首先经过接口进入分流模块，我们的交换机支持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的过程却是费时费力的，但是设计者在设计代码时只需要认真考虑承载功能所需要的位宽，便能为后续调试减轻许多麻烦！原我们都养成一个良好的习惯。

编辑：hfy