标签：物理 仿真 导致 自己的 span val 工程 错误 接口
最近半个月，做个的项目。开始做测试，机器跑着，整个项目前后做了半年，有些小想法，分享于诸位：
1.前期的设计工作应该做到面面俱到，否则在未来的开发中，大概率将会遇到一些问题：
一，性能不满足需求，然后为了提升性能，资源又成了瓶颈；
二，功能设计频繁变更；
三，各个模块之间的耦合性问题，导致系统大了之后，bug无法及时收敛。然后就是不断的返工。
2.及时沟通。
与pcb的制作人员多沟通，减少外部走线对FPGA开发的负面影响；与软件测试人员沟通，一个对于FPGA需要加N个模块综合三四个小时才可以测试的单元，对于软件人员来说可能就十几行代码二十秒钟load进去就可以完成工作；一个算法人员的新思路，可能帮你在开发FPGA时节省一半的资源消耗。
3. 多思考，再动手。
出现bug一定不要慌，先找原因：
一.看物理模型这样的bug可能产生的原因；
二.看仿真，是否有没想到的特殊情况导致一些逻辑的实现偏离自己的设计；
三.看布线，是否是设计电路时组合逻辑使用不当、寄存器扇出问题等。
思考完之后，再去想办法验证问题，使用debug手段。
4.数字电路在时钟同步的设计原则下，其功能通过simulation就可以验证。
这也是为什么各种入门的FPGA书籍里面推荐大家使用时序逻辑，并且关注时钟同步性。因为这是为了保证仿真结果和最后实现结果的一致性。正因为有这样的一致性，才可以进行测试调试。
5.压力上移。
leader将任务分解下发是一种压力下移，而对于具体的执行者来说，在适当的时候也需要压力上移。
当发现出现的问题自己已经无法cover的时候，及时汇报，寻求资源、探讨方案甚至是修改既定计划，是非常必要的。但是要注意，不可以推卸责任，而是提前想好可行性方案之后，再寻求上级的支持。
6.关注外部接口以及器件本身。
FPGA工程师不能仅关注自己的芯片，当设计外部接口时，因为仿真困难，没有工具分析外部器件的情况，会导致在这方面的调试经常陷入困境。
这就需要工程师仔细阅读器件的datasheet，关注其瓶颈、性能、接口电气属性等，我们一般通过假定的 input-delay和output-delay来对接口部分进行约束。
有时甚至可以去官网寻找该器件的仿真module，然后加入到自己的仿真中，通过仿真来保证设计的可控。
7.对于一些大的工程，最后的编译报告可能会有大量信息，不但要关注error，因为error的存在，意味着时钟同步的大前提已经被破坏，这时，simulation取得的结果和FPGA是不等价的。另外还需要关注warning的情况，其中大部分的warning的确是可以忽略不计的，关键的是以下几个：：unused ports, removal of redundant logic, latch inference，simulation mismatch等等。在报表中输入关键字查找即可。
8.测试应该充斥整个开发周期。
包括方案设计时，对整个框架选用接口带宽性能的测试；编写模块时，对小模块的自测（一般在仿真时完成），生成可执行文件后的demo测试，集成测试。
建议所有的模块由专门的测试人员进行测试，因为一些出现自己思维盲区的错误部分，有可能很容易被别人通过测试发现。
但是对于一些小公司可能只有一到两个FPGA开发人员，那么我建议由软件开发人员或者系统测试人员协助进行测试 。
原则起始很简单，就是尽量避免自己即当运动员又当裁判员。
版权所有权归卿萃科技 杭州FPGA事业部，转载请注明出处
作者：杭州卿萃科技ALIFPGA
原文地址：杭州卿萃科技FPGA极客空间 微信公众号
扫描二维码关注杭州卿萃科技FPGA极客空间
标签：物理 仿真 导致 自己的 span val 工程 错误 接口
原文地址：https://www.cnblogs.com/alifpga/p/9162957.html
