在做这个虚拟项目之前虽然也有参加有关的培训,但如此完整、正规的进行还是第一次。
对于testbench来说,首先要明确它的功能:首先是机遇源代码激励信号;其次是检验执行过程是否有误。前者通过initial和always块完成,后者则通过各式各样的task来实现,目标明确才能做好。这里主要想说一点就是对于某个信号的控制及波形的选择最好是在一个块里完成,以便在执行的过程中不冲突,也便于之后的检查。
首先来说一说我所做项目的要求,简单来讲就是在各种条件允许的情况下控制一个寄存器进行向上或向下的计数。当达到门限值的时候进入报警系统,产生一个信号输出持续八个单位并清零寄存器。这个项目的难点在于满足文档要求的同时还要使得报警装置与其相配。再有一个就是testbench的书写,要考虑各种可能出现的错误(源代码与testbench的书写风格完全不同)。
下面说一下在做项目过程中所得到的一些经验。
在写源代码的过程中:尽量用状态机写,刚开始本以为这么简单的功能只用一个always块就够了而且当时用的是quartus写的(quartus不同always块触发条件相同时就报错,这样就没法写状态机了)。但在老师的要求下用状态机重写的时候发现了很多问题:首先状态机的时序与组合逻辑是分离开的,这样有利于条件执行步骤的分离。而只是一个always块只是按着时间的顺序走,很容易遗漏东西,而且在以后的检查过程中很难检查出来;在定下基本的书写风格之后,要仔细研究要求文档,尽量做到完成每一步之后该怎么办,同时确认每一步的执行是否符合要求。直到最后的波形检验的时候仍然能发现与同队其他人功能上有出入的地方;在删减某个变量的时候用查找功能确认逻辑遗漏,不然很容易就发现波形走到莫名其妙。对于testbench来说,首先要明确它的功能:首先是机遇源代码激励信号;其次是检验执行过程是否有误。前者通过initial和always块完成,后者则通过各式各样的task来实现,目标明确才能做好。这里主要想说一点就是对于某个信号的控制及波形的选择最好是在一个块里完成,以便在执行的过程中不冲突,也便于之后的检查。
最后就是对于波形的检测,通过对testbench和被测代码的仿真通过波形图来确认功能的实现,在遇到问题后要考虑其中的问题,既可能是原来代码有问题也有可能是testbench的问题,这里要想一个侦探一样的通过蛛丝马迹开确定问题所在,并找到解决方法。在检验的过程中我习惯于把所有的信号都列出来以便于查找的过程中没有遗漏,但考虑到之后功能的复杂化,想到的办法是对各个块进行命名,这样便能准确的拉出所有想要的信号,其可行性还有待实践。
计数器代码:
<span style="font-family: Arial