标题:
工程师肺腑之言谈FPGA项目
[打印本页]
作者:
yuchengze
时间:
2016-11-24 18:18
标题:
工程师肺腑之言谈FPGA项目
1.
要和人配合。以我们做硬件的工程师为例,测试的时候一般都需要软件的配合,一个对硬件来说无比复杂的工作,可能在软件工程师看来就是几行简单的代码。所以要和人配合,多听听别人的意见,这样必然可以产生新的
know-how
从而加快测试和开发的速度,退一步讲,至少没有坏处。
2.
测试还是要别人来做。开发者看待自己的产品有如看待自己,大多是没有勇气去发现缺点的。一是源自自尊心,二是为了避免额外的工作。所以就算有问题,如果不严重就藏着掖着。但是这对项目来说是不行的,所以测试,
verification
,一定要旁人来做。
3.
多点时间思考。出现问题后,不要急着修改。要思考推测可能的原因,想清楚后把这些可能的原因都用
debug pin
或者
chipscope
引出来。
4.
注意复用已有的
debug pin
。很多时候,在测试过程中产生了一大堆测试信号,但是时间一长就忘了复用。实际上,当一个问题产生的时候,通过反复观察已有的
debug-pin
或许足以发现问题根源,而无需再引出新的
pin
,并浪费时间去综合和
PAR
。
5.
仿真加时序足矣。数字电路在时钟同步的设计原则下,其功能通过
simulation
就可以验证。
simulation
的结果和
PAR
后产生的
FPGA-image
完全等价。当然
FPGA
也要遵循同样的设计原则:即时钟同步。所以对于
PAR
的结果首先就要确保其时钟同步的特性。体现为寄存器之间的
path
必须在一个时钟周期内完成。(当然有其他约束的例外。)同时要满足
FPGA
器件的
setup
和
hold
要求。一旦出现
timing-error
必须通过各种途径消除
error
,因为
error
的存在,意味着时钟同步的大前提已经被破坏,这时,
simulation
取得的结果和
FPGA
是不等价的,继续测试也毫无意义了。
6.
注意不可控的接口部分。
FPGA
内部的寄存器之间的
timing
完全可以通过
PAR
报告来确认是否有问题。但是和外界的接口部分却充满了疑问。我们一般通过假定的
input-delay
和
output-delay
来对接口部分进行约束。由于从一开始就施加的是假定的
delay
,所以即使没有
timing-error
,其结果也存在诸多疑问。以我正在进行的测试为例,模块内部
loopback
测试完全正常,但是一过
cable
,传到对方
FPGA
,则马上产生很多误码。由于
simulation
没有问题,所以必然是我们的某个假定出现了问题,尤其是时钟同步的假定会得不到满足。这时候,就要想尽一切办法,使接口也满足假定的条件,或者调整设计,将不理想的接口
adapting
成理想的接口。
7.
向直接上司汇报情况,寻求各种可能的许可。懒得向直接上司汇报情况时,万一出现进度或者结果不符,所有责任都需要本人承担。如果提前向上司汇报情况并取得许可,则一切后果都在可控范围内。比如,工作繁忙时又被派给新的任务,则不能一味逆来顺受。应该向上司说明困难,并提前想好一个可行的解决方案供上司参考。
8.
外部接口是最大障碍。如前所述,
FPGA
内部如果
timing
没有问题的话,一般和仿真结果是一致的,问题是外部的接口,包括
cable
连线等,不在我们确切控制的范围内,比如其延时特性在
40Mhz
下仍然正常,但是在
80Mhz
时可能出现不可预料的情况。所以应该尽量使用经过验证的
"cable--frequency"
组合。或者通过设备测量并确认外部接口的延时特性。这样可以进行有针对性的调整。我最近的教训就是花了整整一个月调整并测试内部的结构,但是仍然失败。结果发现由于
cable
的问题,
80Mhz
的信号(数据
+
使能
+others
)无**常并行传输。如果换成
40Mhz
的信号就通过了。
9.
综合
PR
后的结果要和代码等价。前面提到仿真加时序足矣,这里面的前提是
PR
的结果和原始代码要等价。为了确认这一点,就要把握
syn
和
pr
过程中的所有
warning
以及
error
,
warning
的内容不是完全可以忽略的。要特别关注综合报表中的以下内容:
unused ports, removal of redundant logic, latch inference
,
simulation mismatch
等等。在报表中输入关键字查找即可。
欢迎光临 电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛 (http://bbs.eccn.com/)
Powered by Discuz! 7.0.0