fpga项目开发除了技术过硬之外，还需要一些合作的心态去看待项目，下面是我操刀过这么多的fpga项目外包服务的体会：
1. 要和人配合。
以我们做硬件的工程师为例，测试的时候一般都需要软件的配合，一个对硬件来说无比复杂的工作，可能在软件工程师看来就是几行简单的代码。
所以要和人配合，多听听别人的意见，这样必然可以产生新的 know-how 从而加快测试和开发的速度，退一步讲，至少没有坏处。
开发者看待自己的产品有如看待自己，大多是没有勇气去发现缺点的。一是源自自尊心，二是为了避免额外的工作。
所以就算有问题，如果不严重就藏着掖着。但是这对项目来说是不行的，所以测试，verification，一定要旁人来做。
出现问题后，不要急着修改。要思考推测可能的原因，想清楚后把这些可能的原因都用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是不等价的，继续测试也毫无意义了。
FPGA内部的寄存器之间的timing完全可以通过PAR报告来确认是否有问题。但是和外界的接口部分却充满了疑问。
我们一般通过假定的input-delay和output-delay来对接口部分进行约束。由于从一开始就施加的是假定的delay，所以即使没有timing-error，其结果也存在诸多疑问。
以我正在进行的测试为例，模块内部loopback测试完全正常，但是一过cable，传到对方FPGA，则马上产生很多误码。
由于simulation没有问题，所以必然是我们的某个假定出现了问题，尤其是时钟同步的假定会得不到满足。这时候，就要想尽一切办法，使接口也满足假定的条件，或者调整设计，将不理想的接口adapting成理想的接口。
懒得向直接上司汇报情况时，万一出现进度或者结果不符，所有责任都需要本人承担。
如果提前向上司汇报情况并取得许可，则一切后果都在可控范围内。比如，工作繁忙时又被派给新的任务，则不能一味逆来顺受。应该向上司说明困难，并提前想好一个可行的解决方案供上司参考。
前面提到仿真加时序足矣，这里面的前提是PR的结果和原始代码要等价。为了确认这一点，就要把握syn和pr过程中的所有warning以及error，warning的内容不是完全可以忽略的。要特别关注综合报表中的以下内容：unused ports, removal of redundant logic, latch inference，simulation mismatch等等。在报表中输入关键字查找即可。
温馨提示：明德扬除了培训学习还有项目承接业务，擅长的项目主要包括的方向有以下几个方面：
1. MIPI视频拼接
2. SLVS-EC转MIPI接口(IMX472 IMX492)
3. PCIE采集系统
4. 图像项目
5. 高速多通道ADDA系统
6. 基于FPGA板卡研发
7. 多通道高灵敏电荷放大器
8.射频前端
http://old.mdy-edu.com/xmucjie/2023/0201/1865.html
