第二版tapout

先说说上次流回来的芯片的测试情况。

4月23日， 芯片采用裸片直接切片， bond在板子上，外面加了一个小塑料壳来保护，我们就直接拿回来测试了。

测试的主要分为模拟和数字两部分， 数字部分的模块基本都工作正常， 模拟的芯片不一致性很成问题，一共就回来了两片芯片，可是模拟部分的参数不同，同时设置的寄存器给出的可调参数也起不到作用，很让人困惑。于是，查到了5月2日又有一次流片计划，于是急急忙忙的就开始准备了。

很匆忙的， sky1301再次流出一版，其实有三个版本， v01主要就是模拟根据3月2日流出的芯片测试情况改变了模拟部分的一些电路，数字部分就是纠正了之前版本的一些问题，比如clear_fifo 命令， rx的parity的错误问题， tx的取crc的时机；v02则是数字部分添加了提速模块和防碰撞的cl_rx模块；v03就是typeA没提速，没加anti-collision加上了typeB的数字收发模块，能完成最基本的通信流。这三个版本的模拟部分是一模一样的。

1周时间，老实说还是挺紧的。其中的提速模块由于之前dr写的也测试过很久的时间了，基本已经定下来了，我主要负责是防碰撞的测试，由华老师来负责改代码，测试中还是发现了不少的问题的，比如总是在发生碰撞的时候会多往fifo里面多写1byte的无效数据，当碰撞bit是0或是1的时候就不能正常工作等问题。
基本在测试的工程中，问题也都暴露了出来，结果最后的模块我觉得鲁棒性还是不错的，还是等芯片回来好好测试吧。

接着是v03的芯片，加上了typeB协议的实现，tx方面用的是之前我写的发送模块，rx方面用的是杜主任写的一个模块，最后时间测试的还真的是很紧张的，不过在基本测试完anti-collision的时候，就开始了typeB的测试，杜主任的模块犯了一个错误就是threshold的初值是0，而他翻转的invert_pulse的高有效，正好是counter == threshold的时候，结果在reset完到配置到正常工作的threshold值的时候就会发生错误的翻转，于是就不能正常解得所要的数据。当把门限的初值改成非0，比如说正常工作的值是12，改成12，在reset后到正常配置钱的时候就不会发生不正常的翻转，数据就可以正常的解得。

封装好的第一版芯片估计还还得一周左右回来，芯片回来肯定还得好好测试吧。接着再有一个半月，这次5月2日的芯片就又要回来了，新一轮的测试就要开始了，拭目以待。

再接着说说这次后仿的问题，后仿也就是一天多一点的时间跑完的，由于后端做的东西基本就是基于上一版的，问题不是很多，主要呢就是碰到了两个问题。

第一个问题就是关于reset的问题，就比如像下面的波形图所致，reset肯定是异步的，但是后端的工具在生成器件之后拿给我们进行仿真，在器件库里data所在的dff对reset上升沿那里的时序是有一个recovery time的要求的，就是b和c之间的时间，为什么呢，可以这么理解，当你在reset的时候前一级的dff和本级的dff同时被复位，而此时你想将reset的电平抬起，脱离reset的状态，如果这样的话，前一级的D端的数据就会反映到Q端，使得本级的D端的数据无法满足和本级的CP端的时序要求，从而使得仿真会红，报出violation。所以如果想避免这种情况，就要使reset的上升沿与本级的clock上升沿离的足够远，按我的理解就应该至少比本级D端与CP的setup time要远（实际考虑上一级的Q端与本级的D端之间的组合逻辑延时与线延时就要更长）。这样就应该可以了。

第二个问题就是比如现在的case，我要仿真的是tx，结果rx模块会报一些不会红的violation，这是什么原因的呢，还是我们的rst_n起到的作用，就是说你在下达SPI_cmd(CMD_SW_RST)的时候，结果你由于rst会传递到各个模块的各个寄存器，结果有一些模块虽然没工作但是依然处于工具检查的状态，虽然最后不影响结果但是依然会红，会有影响，通常这种情况只要有异步的rst信号，就会有可能发生这种情况，如果真的是不用care的问题，那么可以在仿真的时候简单的加一个延时，让rst_n posedge 和clk posedge相隔的远一些就好了，基本就没有问题。同时，如果是可能产生的影响的话，虽然是异步的rst信号，就都要重新弄一个同步的版本给后面的模块！