守株待兔,收效显著
先就事论事,说说特权同学如何守株待兔,再岔开来总结下最近的工作。
仿真是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!
本想接着整理下最近的工作思路,看看篇幅差不多了,就不在这里滥竽充数,待另起一篇,过些天再和大家分享。
文章评论(0条评论)
登录后参与讨论