这个设计做的比较痛 苦，前前后后利用业余时间调试了应该是不下一个星期了。咬咬牙挺过来了，伴随着成功的喜悦而来的，更多的是自己在调试verilog代码过程中对HDL语言更深的认识和感 悟。

其实对于IIC通信协议自己早已是牢记在心，就是C语言的单片机读写AT24C02也是做过的。但是现在 要做的是用硬件语言去读写AT24C02，可就不像软件驱动一样容易了。

开始的时候我总是趋向于独立思考，结合协议来完成verilog的初稿，然后调试，不行 就得参考别人的代码，反反复复琢磨修改，直到成功。第一次程序完成显然不会成功，参考代码，做修改，但是又不愿意照抄别人的代码，毕竟每个人的思路是不一 样的，而且不管是硬件语言软件语言，一千个人可以有一千种的编程方式。当然了，话说回来，有些公认的经典的套路那还是应该尽量借鉴。关于这个IIC的程序我参考了两个程 序代码风格截然不同，当然我的思路和他们的也不太一样，但最终的结果是一样的——读写EEPROM。

做得最困惑的一段莫过于功能仿真出来的时序和标准协议几乎是一模一样（和参考代码仿真的结果也是一模一样），但是下 载仍然无法成功通过验证。然后想说一下这个后仿真（也就是布局布线后仿真），其实这个我想说的问题之前好像也有所涉及，有时下载到板子上明明可以正确无误 的运行的程序在后仿真时的波形图里却乱得一塌糊涂，我就怀疑这个布局布线后仿真到底有什么用，既然他和下载后的实际情况相差悬殊那做这个后仿又有什么意义 呢？带着这个困惑我在edacn.bbs上发帖了，当晚就有回帖道：我一般不做后仿，但是综合后的每一条warning我都不放过。这句话给 了我很大启示，确实我该把更多的精力放在解决综合后的warning上，于是问题慢慢的就浮出水面了。那条警告显然是告诉我那个always语句里的敏感变量表不 完全，这是个很值得探讨的问题，为什么呢？我想起来了在哪本书上看过关于敏感变量表不完全的问题，这是个应该尽量避免的情况，因为如果你试图想通过增加或 者减少敏感变量来控制这个always的执行情况那么你就大错特错了。在仿真时也许结果似乎大多会和你预想的一样，但是下载到板子以后确实另 一番景象，你认为不触发的变量其实都会触发的。就是说即使你每写全敏感变量表，最终下载后硬件执行起来也许会是以一个完全的敏感变量表在执行，这样只能得 到一个你意想不到的结果了。所以要么把敏感变量表写全，要么采用时序逻辑设计，我的组合逻辑里涉及的敏感变量太多了如果综合考虑以后设计难度加大，所以只 能是改成时序逻辑设计了。这算是这个实验下来的两大感悟吧，当然调试过程中还有很多细节上的问题要注意，这个只有每个人在实践中自己慢慢体会。

老规矩，感慨完发图发程序：

往24C02写一个字节的仿真时序图：（蓝线表示高阻态，说明sda口此时作为输入口）

从24C02任意指定地址读一个字节的仿真时序图：（sda口连续的10高阻脉冲表示两个应答 输入和一个字节8bit的输入数据）

代码打包上传：

实现功能是往指定地址写一个数据，然后读出这个数据，再把这个数据的低4位表现在4个LED上。