【犄角旮旯的bug】文件和接口怎么就对不上呢？

一口Linux

事故现场事故的经过呢也比较简单，就是验证环境里需要随机出一个若干笔数的dat文件为input.dat，而后会把dat文件转为二进制文件input.bin文件作为对比模型的输入，同时input.dat中的数据写入到DDR中作为DUT后续的输入数据。而后在进行随机测试时，发现input.bin文件中显示的数据就是和DDR中读到的数对比上，做个简图表示下：

wto554uupqt64024565058.jpg

事故排查看这个图就知道，最大的疑似事故点就出在了input.dat转input.bin这一步了，于是对这里的函数进行了旷日持久的排查共计5天括号包括周末，但是在各种努力下始终没有找到函数中的问题。后面又怀疑是不是由旧文件残留，删除目录更新代码各种重新尝试，均告失败。最后甚至多个人在本地目录跑同一个用例，有人的bin文件和波形可以对上有人对不上，事情也是扑朔迷离。
然后非常偶然的一下，我和同事分别打开了同一个bin文件然后令人瞠目结舌的一幕出现了：显示的文件内容竟然不一样？！
事故原因于是我们就对比了下为啥会不一样，我是用gvim打开的，打开时是这样：

szfhy221azx64024565158.jpg

而后通过Tools - Convert to HEX转为十六进制文件：

rpoa5ulaaqs64024565258.jpg

经过我们的一番对比，发现是gvim转换时给转错了！换句话说就是同一个二进制文件，两个工作站下的gvim转换出来的内容是不同的，所以人家根本就是能对上的只是我看的时候误以为没对上！

hrvy5lyxmja64024565358.jpg

在骂了gvim两个半小时之后我觉得有必要深入探究下为啥会转换错，毕竟不能白骂人家嘛。最后找到了罪魁祸首，在转换时报了这个错误而没当回事：

xy43uev4mjo64024565458.jpg

估摸着，应该是我瞎搞gvim的插件把环境哪里啥的搞乱了(灬? ?灬)emmm怎么说呢，好像也不能全怪人家工具，责任91开吧它九我一。
事故解决gvim被搞坏了我也没有能力修复，可是还得看这个bin文件怎么办呢？linux提供了若该方法，比如hexdump -C xxx.bin：
00000000  10 db f7 07 69 ec fb 8e  52 11 fa a7 26 7f b8 16  |....i...R...&...|
00000010  d7 47 b5 c3 d7 91 86 e9  59 9b b9 44 e9 7a e1 c0  |.G......Y..D.z..|
00000020  16 02 78 44 63 9b bb 7a  a0 e6 df f0 21 a6 50 72  |..xDc..z....!.Pr|
00000030  d3 7a 12 10 fe 9a 24 29  4c c4 bf 4c 39 31 e2 55  |.z....$)L..L91.U|
00000040  61 b2 dd d4 e4 7d 8c 49  5b 3d 88                 |a....}.I[=.|
0000004bxxd xxx.bin：
0000000: 10db f707 69ec fb8e 5211 faa7 267f b816  ....i...R...&...
0000010: d747 b5c3 d791 86e9 599b b944 e97a e1c0  .G......Y..D.z..
0000020: 1602 7844 639b bb7a a0e6 dff0 21a6 5072  ..xDc..z....!.Pr
0000030: d37a 1210 fe9a 2429 4cc4 bf4c 3931 e255  .z....$)L..L91.U
0000040: 61b2 ddd4 e47d 8c49 5b3d 88              a....}.I[=.或者用vscode去看也是不错的选择。
事故后感果然啊，当我们验出一个问题时，第一可能性是RTL的错误，第二可能性是软件的错误，没有可能性是自己环境的错误。当我们的代码被验出问题时，第一可能性是环境的错误，第二可能性是软件的错误，没有可能性是自己RTL的错误。
你就谨记。