IC验证工作随笔--工作4个月

以前总是想看看别人的工作经验贴，一直没找到，只好自己写一下，给以后的自己看看和还没有参加工作的同学分享一点经验，避避坑。目前，参加工作成为IC验证工程师已经满4个月了，说实话，工作和在学校里面确实不一样。接下来会从以下几个方面进行对比：住房、身体、精神、工作。最后才是工作（笑），工作在我这的排序是最低的。
1、住房
工作之后，可能会面临的几种情况有，在老家工作，在外地工作这两种情况。据我观察，IC行业主要集中在北上广深一线城市，和苏州、南京、无锡、武汉、成都杭州等新一线超市，大部分人都会在外地工作，租房就是刚工作面临的最大的一个问题了。好在，目前大部分新一线城市都有公租房（不确定），以苏州为例，zf会有3年的优租房可以申请，不过由于博主是本地人，免去的租房的问题。所以对这方面的考虑并不深入，但看身边的同事并没有为租房烦恼过，说明zf在这方面做的不错。但是，3年之后仍然需要面临买房问题。这方面，需要同学们好好思考，你第一份工作是为了什么，是为了工作经验？钱？还是可以留下？
2、身体&精神
身体和精神在我看来就是互补的，身体和精神哪方面出了问题，都会影响工作（虽然就是工作让身体和精神状态变差的），在工作之后，精神真的会沉沦的！在学校时，始终有一个目标，中考，高考，考研，找工作（考编）。但是当你踏上社会的那一刹那，你以往所有的目标都失去的，没人再能逼着你干你可能不喜欢的事情，但是你真的有目标吗？哪怕是虚假的目标。在这建议找一个可以坚持的体育运动或者别的爱好。当身体强健时会带动精神的升华，博主想要完成尾崎八项，不过不知道这辈子能不能命完成了。用身体和精神来对抗，岁月的沉沦。
3、工作
对于IC验证工程师这个岗位，可能会被外界宣传或者说培训班的一些言论误导。因为培训班只能训练你的代码能力这些可以量化的东西，而削弱了如何根据SPEC制定TEST plan，TEST case，如何设计UVM验证环境架构等无法量化的在我看来更为重要的东西。以我举例，当我接触项目时，我其实是有一些懵的，验证的flow是什么，我需要去做什么，已有的验证环境是什么这些问题都不清楚。并且其实不是每个人都知道应该做什么，而是被项目push推着走的，这其实表示的是对项目的掌控很无力。而且这些东西，别人无法帮助你，可能别人也没有一套合适的验证的flow，或者说还没有一套行之有效的flow。
我也只能以我目前的验证思路进行一个总结。
1、当接到一个项目的时候，第一步永远不是直接看验证环境，每个人根据工作时间和习惯而言，代码风格千变万化。第一步先看需要验证的IP或SOC的SPEC，根据这个文档介绍IP的feature，看其实现的功能。但是很不幸的是，会出现以下问题，对于新IP而言，SPEC是没有的，甚至说只有IP的feature，你不知道interface，register，而是只有需求（笑）。这就导致了一个问题，设计无法和验证同步进行，得先设计个大概，由设计出SPEC或者说写一个介绍interface，register的文档。大部分情况能写个文档就已经是极限了，能将所有的内容都清晰介绍的SPEC如果有的话，感恩上天吧，你遇到的不是老项目，就是设计是个非常有经验的designer。
2、因为设计和验证无法同时进行，但是deadline却是同一个deadline，那导致你验证的时间会很短，或者说，即使你之前将验证环境搭建完成了，但是如果是一个新的IP，会出现interface，register，feature都发生翻天覆地改变的情况。你的验证环境如果复用性很差，其实也不是复用性差，当interface，register，feature都变了，本身就可以看成一个新的IP了，也谈不上什么复用性了。所以到这步也别看验证环境，你心态会发生巨大改变的！
3、在看完设计文档或者说SPEC之后，了解清楚项目的时间节点，这对你安排工作有很大的意义，别认为领导会帮你安排好该干什么，领导可以比你更忙，所以改变学生时代，很多事情让老师或者学校安排的思想，开始依靠自己吧。
4、当作完以上的工作之后，就到了最重要，但是培训班或者学校没教的部分了，那就是制定TEST plan。这也许是最麻烦的部分了，你需要根据功能需要的interface，register理清自己的TEST方案，而理清这些内容对于工作中需要的register和interface而言，绝对是一个灾难，对于IP而言，有30+个register很合理，甚至可能更多，有一些功能需要这些register，有一些则需要另外一些register，他们之间有交叉，有互斥，有依赖关系，想想就可怕。
5、当你制定完TEST plan之后，到了你期待的验证平台了，你可以开始看代码了，是不是很开心，先别开心的太早了。因为大部分的项目你都不是第一个做的人了，也就是说，你会看到一堆代码，先去烧烧香，保佑自己看到的不是Shit Mountain。也暂时先不要去攀登这座“山”，先看看有没有之前的验证SPEC，请为了后来者或者自己，写一下验证的SPEC吧。当然你大概率是找不到这个SPEC的，先去找找看原来负责这个项目的同事是不是还在，还在的话，至少还能去直接问相关的细节，要是不在了，那就只能自求多福了。当了解完这些之后，先运行一下验证环境，可千万别让别人给你一个带着bug的环境，那你就陷入了一个艰难的处境了。运行完验证环境，了解一下，如果你需要对环境compile需要修改哪几个地方，大概应该有filelist，还有dut，如果Makefile写的不好，或者说没有，用的是shell编译的，那可能会需要修改。所以别一上来就吭哧吭哧地看验证平台的代码，你改了甚至不知道是改错了还是compile出问题了。
6、当知道验证平台的compile和run之后，再开始看你的验证环境的代码吧，深呼吸，先告诉自己稳住心态，因为你可能会看见，少的可怜的注释，一个.sv上万行的代码，大量的注释掉的代码，以及没有层次可言的模块。请不要幻想可以看见标准的UVM环境，第一，根据项目不同，也可能会出现不需要的UVM组件，第二，可能上一个同事也是个新手，而且是没有具体规划的新手，这就导致环境的恶化。
7、这个时候你已经看到代码了，先抒发一下对代码的感受吧。抒发完感受，从top开始看这堆代码吧，虽然是可能不是标准的UVM环境，但是只要用来UVM整个环境的大框架还是看的出来的，内部组件可能就是shit。先搞清楚需要用到的接口，因为有一些接口不用也不会注释掉，可能你改了半天，然后一运行什么都没有改变。
8、在你review代码之后，也先不要对他进行修改，先和designer讨论一下register model是否需要重新修改，以及你对功能的理解，因为你的理解大概率是有问题的，设计和验证介入的时间不同，designer已经把项目做的差不多了才给你验证，所以很可能你的理解有问题。理解清楚功能，先写reference model，因为这个需要的是你去实现功能，生成golden data，先不要去找designer确定register constraint的事情，这个可以在之后进行。
9、当你写完reference model之后，scoreboard checker就变得很容易了，当然这是需要你把数据整理好比较的情况。在这之后，和designer去讨论register constraint的事情吧，让环境可以在你不修改东西的情况下random跑起来，根据你之前的TEST plan来写相关的TEST case。
10、最后当然是写需要的coverage啦，这一部分完全就是写代码的问题了，同样也是根据TEST plan进行。其实这一步已经很靠后了，在项目中，应该是最后进行的，毕竟如果designer有bug，或者验证环境有bug，都不能random的运行起来，也谈不上coverage了。

还有最重要的一点就是，写代码的同时一定一定要写注释，在项目的结尾一定一定要写验证文档，可能这会花时间，在领导看来也没有意义，因为这和培训班不教如何制定TEST plan是一样的，这不是可以量化的东西。但是，只有这些无法量化的东西，才是你作为IC验证工程师的经验所在。