riple

在硬件设计、硬件验证完成后，和软件集成测试的工作，也应该记入硬件开发的Schedule。软件集成测试中的硬件debugging往往会被硬件工程师忽略。对于硬件工程师来说，软件的集成测试会发现许多硬件通过仿真和硬件调试、甚至是软件配置调试都发现不了的问题。解决这些问题

能够记住别人所说的原句，有利于加深对谈话内容的理解。这一点同样适用于汉语。当前我和美国工程师交流的困难不在于听力和语法，而在于记忆。Kevin很聪明，发明了边说边打字的交流方法。一来减缓了他的语速，二来有助于我回过头去重新理解某些长句。背诵课文是我们从小

对于没有标准或者标准尚未确定的功能，一定要详细地列出其测试方法。这样才有利于后期对该功能可靠性和验证完整性的评估。

对于每一个硬件信号的状态，都可以通过寄存器的一位来反映给软件。如果硬件开发中没有考虑采用状态机来实现硬件握手，就可以通过这种方法用软件来弥补。

与其让FW工程师采用“试错法”，或者让HW工程师给FW工程师提供培训，还不如由HW工程师来写Driver，或者完成Driver开发的部分工作——寄存器定义。

采用替换法确认bug，需要确认替换与被替换对象的等价性。最容易忽略的就是配置差异。基于不等价替换方法确认的bug，是不可靠的。两台仪表之间是如此，在调试程序和应用程序之间，这一问题表现得更为突出。相关链接：Swansongforswap-outstrategy

原计划两周的调试，现在延长到了三周。初到RSR，见到的每一个人都说，你们这次两周可能不够，要延长。所以我们就抓紧时间，每天工作12个小时以上，一周干6天。为的是把所有已知的bug解掉。直到昨天早上，我们还决定两天后如期返回。前天加班吃晚饭的时候，SW的ManagerIr

原本已经解决的bug，到了SW手里又出现了。经过一番查找，才发现，SW用的并不是我们最新的MemoryMap。MemoryMap一直用Word写，现在暴露出很多问题。1.无法比较版本，版本控制工具比出来的全是读不懂的乱码，SW只能手工更新寄存器的定义，失去同步是难免的。2.格式不兼容

当前的仿真测试平台采用了自发自收、收发对比的自动结果检查功能。这一方法充分利用了现有的代码，在没有专门安排仿真测试程序开发时，工作量大为减少，但是存在一个很大的问题：收发是耦合在一起的。一些兼容性问题不能通过这种方法检验；一些收发共有的错误检验不出来

虽然FPGA的I/O时序是可以在一定范围内调整的，但是在PCB制板的过程中也要给以充分的考虑。当前的设计整体上没有问题，就是在个别关键点上出了问题，导致FPGA调试和整个系统的时序收敛很困难。PCB要充分考虑时序、要考虑FPGA专用引脚的使用、要考虑FPGA的功能扩展。FPGA

除了HW的仿真，在软硬件集成开始后，对于产品原型的回归测试也不应该忽略。回归测试最好自动化。仿真回归测试自动化还好说，产品回归测试的自动化就需要多花些功夫考虑了。海外捉虫记—设计流程的哪些阶段需要回归测试

把自己开发的模块lock得太固定，是不是有些霸道。

CPU接口涉及到大量的译码逻辑。如果能够不经过动态仿真，采用一种工具静态地验证memorymap与hdl代码之间的对应关系，软硬件联调就会快很多。进一步，如果可以由memorymap直接生成hdl代码就更好了。

线性状态机是最简单的状态机，但是对时序要求最严格，容易出现小错误。其实就是流水线。如果能够用simulink对其建模，一定可以提高开发效率。

好的模型可以用于解释、改进算法。更简单、更安全、更高效。当前的带宽控制模块就需要一个好的算法模型。