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等等。在报表中输入关键字查找即可。
