|
EDA365欢迎您登录!
您需要 登录 才可以下载或查看,没有帐号?注册
x
; U9 M) W. g5 r
9 ]& Q% K/ [2 H) |$ `5 U7 T做了5年的FPGA了。手中经历的项目也不在少数。就在此刻又一个FPGA项目宣告结题,好多感受趁着现在还新鲜着,写出来和大家一起分享。不对之处,希望得到大家的指正。另外1234并没有绝对顺序,都是有感而发,随性而写。" o* @: s. K" N$ q% [$ N9 Q! Q! t
$ \9 f9 k4 n0 y: p1. 要和人配合。( r1 f4 Q$ p$ [6 |0 p
1 Q! H, v5 G* w1 V
以我们做硬件的工程师为例,测试的时候一般都需要软件的配合,一个对硬件来说无比复杂的工作,可能在软件工程师看来就是几行简单的代 码。所以要和人配合,多听听别人的意见,这样必然可以产生新know-how 从而加快测试和开发的速度,退一步讲,至少没有坏处。
4 k7 c% h. s x( k: b& W, g/ K. U3 X' @+ u: a: S
2. 测试还是要别人来做。
; A9 `8 d* x/ g( e( N" i6 G, f/ A
% M" K8 f8 l+ y& x, u开发者看待自己的产品有如看待自己,大多是没有勇气去发现缺点的。一是源自自尊心,二是为了避免额外的工作。所以就算有问题,如果不严重就藏着掖着。但是这对项目来说是不行的,所以测试,verification,一定要旁人来做。
8 q! R- J, a6 ~" B) J( L% ~
, V/ P) W& h) \! J. O3. 多点时间思考。: X7 U- u/ m, o+ A* ~+ l
$ C; `# S" N9 C. b! B8 N
出现问题后,不要急着修改。要思考推测可能的原因,想清楚后把这些可能的原因都用debug pin或者chipscope引出来。
" @# l% a0 q# Y# v6 U6 S p L [7 f2 |& P4 j" o1 f. U
4. 注意复用已有的debug pin。 O; ~) R3 |! e! Y0 w; E
, ^( H' ^0 t; u
很多时候,在测试过程中产生了一大堆测试信号,但是时间一长就忘了复用。实际上,当一个问题产生的时候,通过反复观察已有的debug-pin或许足以发现问题根源,而无需再引出新的pin,并浪费时间去综合和PAR。0 \& i* {' m, J4 U
8 p. Q0 T3 w! \) v2 f5. 仿真加时序足矣。
( I# q6 [- i; G& I+ g/ j, P9 l& U$ K+ L. B+ N8 M2 ?
数字电路在时钟同步的设计原则下,其功能通过simulation就可以验证。simulation的结果和PAR后产生的 FPGA-image完全等价。当然FPGA也要遵循同样的设计原则:即时钟同步。所以对于PAR的结果首先就要确保其时钟同步的特性。体现为寄存器之间 的path必须在一个时钟周期内完成。(当然有其他约束的例外。)% \" }5 P, Y0 \" }! a
3 |$ n3 j2 M7 W* z' l8 V& @
同时要满足FPGA器件的setup和hold要求。一旦出现timing-error 必须通过各种途径消除error,因为error的存在,意味着时钟同步的大前提已经被破坏,这时,simulation取得的结果和FPGA是不等价的,继续测试也毫无意义了。5 w' Y: Z7 Z* Z5 r
6. 注意不可控的接口部分。% [4 {+ y, T2 X3 r9 _) z3 [
/ i: Q! d6 o0 K; k. H
FPGA内部的寄存器之间的timing完全可以通过PAR报告来确认是否有问题。但是和外界的接口部分却充满了疑问。我们 一般通过假定的input-delay和output-delay来对接口部分进行约束。由于从一开始就施加的是假定的delay,所以即使没有 timing-error,其结果也存在诸多疑问。) L8 S4 N0 M; S; g$ L
: q8 v* H+ x# o8 Q' t* h, l以我正在进行的测试为例,模块内部loopback测试完全正常,但是一过cable,传到对方FPGA,则马上产生很多误码。由于simulation没有问题,所以必然是我们的某个假定出现了问题,尤其是时钟同步的假定会得不到满足。这时候,就要想尽一切办法,使接口也满足假定的条件,或者调整设计,将不理想的接口adapting成理想的接口。1 h9 p% `$ b8 [* P& n* |6 Z
4 A% s2 W' c5 E! y$ ^: i/ |4 M5 V7 s
7. 向直接上司汇报情况,寻求各种可能的许可。
" w! V3 E- X7 q: V3 t' P# p) ~ i4 S$ _. l& B8 l- e' V
懒得向直接上司汇报情况时,万一出现进度或者结果不符,所有责任都需要本人承担。如果提前向上司汇报情况 并取得许可,则一切后果都在可控范围内。比如,工作繁忙时又被派给新的任务,则不能一味逆来顺受。应该向上司说明困难,并提前想好一个可行的解决方案供上司参考。
# A/ M2 J3 A* o. z2 D
4 a- Y2 _ B2 V# v# T0 o8. 外部接口是最大障碍。5 v+ u) M' x1 q& z' r% ?" Y( Z
8 t! A" X9 t* o
如前所述,FPGA内部如果timing没有问题的话,一般和仿真结果是一致的,问题是外部的接口,包括cable连线等,不 在我们确切控制的范围内,比如其延时特性在40Mhz下仍然正常,但是在80Mhz时可能出现不可预料的情况。 S4 R b& R( f+ a6 t2 u0 C
2 y# H3 b$ C- u6 f: F2 q所以应该尽量使用经过验证的 “cable--frequency”组合。或者通过设备测量并确认外部接口的延时特性。这样可以进行有针对性的调整。我最近的教训就是花了整整一个月调 整并测试内部的结构,但是仍然失败。结果发现由于cable的问题,80Mhz的信号(数据+使能+others)无法正常并行传输。如果换成40Mhz 的信号就通过了。
! U! x7 C2 U5 Q4 X0 b. O7 F8 c3 w$ [( g8 W
9. 综合PR后的结果要和代码等价。
; z( r, C& H5 N
5 H; u' Y! ]& b/ C) x" K7 u& r6 Z前面提到仿真加时序足矣,这里面的前提是PR的结果和原始代码要等价。为了确认这一点,就要把握syn和pr过程中的所有warning以及error,warning的内容不是完全可以忽略的。要特别关注综合报表中的以下内容:unused ports, removal of redundant logic, latch inference,simulation mismatch 等等。 |
: Y* g0 O8 v/ I# O; }- q& E |
|