记录两个Debug方面的事件，有点启发
1. 我自己的A模块的验证环境编译问题
今天debug了A模块的IT环境，上周五卡在了编译上，就显示设计代码里lib库里有个什么不匹配的问题，直觉上也知道肯定不是当前这个文件错误。但是就是找不到问题所在，内心里的归因是“可能是设计的代码有一些问题”。并且，拉来了leader一块看，她也大概看了一下，大面儿上也没有啥问题 ，并且恰好另外一个模块的设计过来说A模块的综合还没过，这更加让自己“笃定”是设计RTL的问题比较多，所以最后就是等待设计人员休假回来。
然而，今天设计回来之后，一顿线上review，给了一点指引，最后根因真的就是在自己，而且就是因为一个文件的ifdef endif 配对的问题，因为自己之前自己Review不细致以及对自己的盲目自信，以致于因为实际上比较明显的疏漏导致的编译问题，就这么硬生生地卡了半天。
回顾一下定位的思路，发现自己debug能力还真是有待提高：自己遇到了lib里报了配对的错误之后，就有点手足无措了，抓不到根因，看见奇怪的问题，就顺着RTL往里面追，结果越追可能越是迷糊，中间到是也会遇到“明明是ldata下面的路径但是最终会link到RO的sdata上”的“意外收获”，但明显自己的思考方向就错了。虽然自己也发现了诸如宏定义的问题，但是还是缺少了比较全面、灵活的定位思路。
设计给自己的指引：
（1）首先排除RTL版本的问题。这一点上，自己倒是开始有这个意识，也是按照顶层的filelist挨个模块的更新代码。但是，今天线上设计怀疑自己NOC代码没有更新，一更新发现还真是，这是为什么？是周末NOC的设计更新了代码，还是自己当时就疏漏了？
（2）解耦设计和验证的代码。设计可以只带着RTL的filelist就可以跑编译的。这是一个自己不常用的手段，以前也没这样用过。而面对A模块这样大的一个IT，自己没有这样的debug手段和意识，就说明水平还不够。果不其然，单独跑设计的filelist，把自己没更新的代码都对齐到了最新，之后就编译过了，至此就说明设计的RTL实际上没问题。
（3）验证环境的单独编译。接着（2），既然单独设计已经没有问题，那么就要看环境，这里单独DEBUG环境就又是一个新的经验了，好在自己按照设计的指引，找到了A的Dummy RTL，挂到环境上，编译就跑的很快了，很快就暴露了错误。在这个过程中，也是大概用“二分法”或者“层层递进”“地毯式”地排查就比较高效了。
最后发现，就是自己手动新增修改的macro的define文件，最后没有加endif，导致了不配对，最后导致了后面很长的奇怪的错误。而且，很容易误导人，让人去改RTL的各种文件。说白了，根因也是很简单的一个错误，只是因为文件层次稍微多那么几个，自己就疏漏了，总是觉得“自己这么认真，写的应该都没啥问题吧”
2. 帮助新人解决问题
今天一个隔壁组的刚工作两年的小伙过来找我请教我接手的一个IP的问题。我听他说了半天，也听不懂他说的东西，以致于最后跑到他的座位上对着他的波形和代码，现场给他讲解了一番。自己当了一把小小的“FAE”最终给他讲明白了，自己竟然还有点小小的成就感了，因为自己从来没带过徒弟，所以感受还挺明显的：
（1）看到这个入职两年的小伙的状态，想到了当年的自己。这小伙脑子智商不低，名校毕业，但是明显思路不对，而且整个感觉也不对，有点自己当年的感觉。
（2）新人的问题之一是：描述问题描述不清楚，不能厘清和被请教人的界面，上来就问“这个怎么回事”，但是却不能提供足够的基础信息，需要别人猜。
（3）新人的问题之二：对业务、系统级电路不熟悉，没有经验，且没有正确的思路。代码层次一多、向上集成的一多，就慌了，思路乱，没有清晰的主线，所以一直左找右找各种其他原因，肯定是找不到的。自己确实也是经验丰富了，在没有预先看文档的情况下，直接就看到了问题层次所在，直接波形上讲解给其思路，最终解决问题。
结合自己今天乌龙般地debug和帮助新人解决问题，有一些启发：
（1）“顶层”信息的对齐首先是第一步，需求、基本东西（宏、filelist、版本）等首先先明确，和相关人员对齐，不要一上来就开始咣咣跑代码，未必高效。
（2）遇到不那么好弄的BUG，思路一定要清晰、灵活，不要按照惯常的做法就“硬抗”，进行不下去了就轻易放弃，今天设计人员把“设计和验证环境单独编译”的思路就帮了大忙，人员这一点自己做为一个验证没有首先想到，就是水平和经验不够，下次必须先想起来。
（3）总结、沉淀、积累经验，很重要。看到新人的乱定位一气，还讲不明白结构，自己就突然感受到其实自己已经是某些方面很多有经验了，所以就很有那个感觉，因为足够熟悉。那么自己的经验和感觉哪里来的呢？肯定是这么几年自己不断的做不经意间总结的。所以，总结和沉淀很重要，经验多了甚至就会形成直觉了。
网友评论