先就事论事，说说特权同学如何守株待兔，再岔开来总结下最近的工作。

仿真是FPGA开发过程中必不可少的一步，甚至是需要在整个开发过程中反反复复进行的一步。因为很显然，那么一大摞逻辑关系，光靠解读代码很容易让人眼花 缭乱、思维混乱。编写一套实用的测试脚本，在仿真工具的帮助下，就可以直观快速的定位问题，尽早根除。

特权同学遇到了这么个问题，做一个指令控制器，在CPU发出清屏指令的时候，需要以单点写SDRAM的方式将SDRAM的某一片地址空间（最终映射到液晶 显示区域）全部清为特定的数据。由于这片SDRAM已经肩负着视频读写以及叠加数据读的任务，这里添加的就是叠加数据写的任务，因此SDRAM的读写仲裁 逻辑的设计就有那么一些杂乱了。清屏只是众多叠加写SDRAM指令中的一个，但是发现了一些问题，指令是执行了，但是刷刷的很规律又不那么规律的在液晶的 这层显示中出现了没有完全被清屏的杂点。CPU端的指令发送时间不同，那么杂点的规律也随着稍有改变。在初步的该部分功能仿真过程中，特权偷懒就看波形瞄 着时序看看没问题就拉倒了，没想到遇上这么个问题，于是静下心来，一面好好的把添加的一些新的代码的结构重新理顺，另一面就是支招好好写段测试脚本。

话说用ModelSim的做仿真还真不能光看波形，虽然特权同学也养成了不看波形不放心的习惯，但是要更全面更高效的做验证，必须采取更加高明的手段。打 印输出也是一个偷懒的好办法，把在特定的条件下有用的数据（待观察的数据）输出，不用再去花花绿绿的波形中海找了，需要的结果直接可以观察。说到这，当然 还有更偷懒的方法，那就是让机器继续帮我们干活——自动判读，此偷懒办法条件只有一个，你必须清楚激励产生的预期结果。然后，让ModelSim Run起来，然后你可以在旁边泡杯茶小憩一下——守株待兔！哈哈，特权同学的这回收效显著，直接把问题逮个正着。

问题很严重，都让我抓一把出来了，测试中简单的遍历地址写入相同的数据0x00aa，一旦发现数据不对或者地址不是递增直接就stop。逮着一个保存一下 就着run，当然了这一步也可以写到脚本里，也省得你复制粘贴，只不过特权想停在这看看波形做点分析而已。

图1

揪出了一串问题点，罗列出来做了一下比较和分析，和板级调试的现象还确实有几分相像（在解决问题前真不好直接下定论，严谨一点低调一点是必须的~-~）。

# 585275 SDRAM_ADDR = 3,802,72; SDRAM_DATA = 00aa;

# 585535 SDRAM_ADDR = 3,802,74; SDRAM_DATA = 00aa;

# 647525 SDRAM_ADDR = 3,803,31; SDRAM_DATA = 00aa;

# 648235 SDRAM_ADDR = 3,803,33; SDRAM_DATA = 00aa;

# 690245 SDRAM_ADDR = 3,803,71; SDRAM_DATA = 00aa;

# 690475 SDRAM_ADDR = 3,803,73; SDRAM_DATA = 00aa;

# 720185 SDRAM_ADDR = 3,803,a0; SDRAM_DATA = 00aa;

# 720845 SDRAM_ADDR = 3,804,00; SDRAM_DATA = 00aa;

# 1023065 SDRAM_ADDR = 3,806,89; SDRAM_DATA = 00aa;

# 1023775 SDRAM_ADDR = 3,806,8b; SDRAM_DATA = 00aa;

# 1144575 SDRAM_ADDR = 3,807,a0; SDRAM_DATA = 00aa;

# 1144665 SDRAM_ADDR = 3,808,00; SDRAM_DATA = 00aa;

# 1485265 SDRAM_ADDR = 3,80b,24; SDRAM_DATA = 00aa;

# 1487145 SDRAM_ADDR = 3,80b,26; SDRAM_DATA = 00aa;

最后在仔细分析一下波形，确实有那么一段两次读FIFO，但是其中一次的数据没有被写入SDRAM，也就是说某些清屏的点被漏了。发现了问题，认真做了一番思考，定位到工程中的某段代码，SDRAM写入仲裁的某个控制逻辑确实有待商榷。

图2

接着，修改代码，重新编译，下载验证，OK！

本想接着整理下最近的工作思路，看看篇幅差不多了，就不在这里滥竽充数，待另起一篇，过些天再和大家分享。