原创 【博客大赛】利用SignalTap II调试ALTERA器件一例

调试工具： Altera的SignalTap II

目标器件：Altera的ArriaGX

主要功能模块：Altera的FIFO函数

          由于项目中使用到了很多的FIFO，而且需要将两组相互独立的FIFO里的数据读出来进行组合并存入下一级FIFO，这个应用在我之前的有关FIFO"读空"和"写满"的博文里有过介绍，并给出了简单的仿真波形。最近上板调试项目这部分功能，其实FIFO的操作没有问题，只是在系统测试的时候总是觉得数据“失配”，查很多地方都正常，最后怀疑是否是在最起始的FIFO“组合”的时候出现了问题。花了两天时间调试，确实发现有偶发的FIFO失配问题，只是不太清楚是什么原因造成这种失配。

         首先来解释一下这里所谓的“失配”问题，举个例子，有两个功能模块A和B，它们处理完的数据分别存放在FIFO-A和FIFO-B中，只有当这两个FIFO同时非空的时候才从这两个FIFO里各读出一个数据并组合成一个新的数据存入下一个FIFO，我们称其为FIFO-C，FIFO-C里的数据用于下一级处理，这里不做介绍。也就是说FIFO-A和FIFO-B中的数据是一一对应的.

         系统能确保，当有信号时，功能模块A和B总是能各产生一个数据并存入各自FIFO，所以写FIFO-C的时候应该不会出现“失配”问题，即FIFO-A的第一数据和FIFO-B的第二个数据组合并写入FIFO-C，这就是失配。实际调试发现确实出现了这种失配问题。

图1：FIFO的数据写入控制时序

         图1是一开始抓取的模块B的数据输出，也即对应的FIFO-B的写数据端口控制，比如图1明明显示当前写入的“143EB”，而实际读出的数据表现为“C4”。由于抓取的信号不够，所以似乎是告诉我图1所示的写时序存在问题，我一开始就怀疑是否逻辑中数据走线延时太长，导致写信号到达FIFO的写控制端口的时候，而数据却未到达，所以导致错误地将“C4”写入到了FIFO。我之所以这样怀疑是因为我抓取的是FIFO第一个数据。

         经过不断的测试，我开始怀疑自己的上述怀疑。没有办法只得拉出更多的信号到SignalTapII里进行观察验证。确实，我的上述怀疑是错误的，FIFO的读写控制经过了严格仿真，不应该轻易出现错误的，问题的实质是在我认为的“第一个”数据写入FIFO-B之前，FIFO被意外的写入的了一个不需要的数据，即FIFO的写请求上“意外”地出现了另一个写请求，在图1所示的时刻之前将“C4”写入到FIFO-B。

     图2显示了这个意外被写入的数据完整过程，由于一开始没有拉出FIFO的empty信号，其实如果有了这个信号，我应该在做图1所示的测试的时候就不应该首先怀疑是FIFO的写操作控制问题，因为在FIFO写第一个数据之前，FIFO已经是非空了，说明已经有另外一个数据被写入到FIFO了，那么就应该查为什么有这么一个不应该写入的数据被写入到了FIFO。可惜当时并没有观测empty，所以导致多纠结了半天（实际上，由于工程太大，添加过多的信号会导致meomory的消耗，并每次修改SignalTap需要重新编译，所以一开始并没有添加那么多“非关键”信号进入SignalTap）。

图2：被意外地插入到FIFO开头的数据

            图2清晰地显示了当系统刚刚进入正常操作模式的时候模块B即出现一个“伪有效”数据，并被处理后写入到FIFO-B。而此时模块A并没有这样的数据，所以模块C在不知情的情况下从FIFO-A和FIFO-B中组合失配的数据到FIFO-C，而且就是这样一个意外的数据导致后面所有的有效数据都失配。

          由于这种意外情况发生几率很低，所以测试的时候很花了一番精力才抓取的该“事件”，并最终在系统上进行了规避。