原创 MB,再忘了把68013.Reserve接地我就剁手！

昨天发现68013的slwr，不管内部firmwre怎么写，只要把slwr拉低就肯定死机，pc完全检测不到usb设备，查了一圈发现是reserve忘了接地了，明明DS里提到了的。。

明明1年前犯过同样的错误的。。不过当年是连i2c上拉都没接，现在好歹记得了。。

看来调试记录太重要了！

想起来当年做68013的时候用fpga做fifomaster，外接一个idt的dc fifo做缓冲，也是一波三折了。。
当时是需要大量数据采集+少量控制信号接收，
但是不会根据需要切换fifo address，也不会通过ep0再bulk传输的时候收发指令，于是用了2片68013分别完成这两个工作。
负责指令发送的68013，用了好久才发现必须工作在autoout=0的方式下，也就是manual out

不然每次都等512byte才发一个bulk，延时太大了

指令长度又不统一，不好通过调整length的方式来解决。

数据采集部分，最开始用fpga产生了累加数据送给fifo作为测试手段，通过这个手段发现，68013接收到的数据有时候会重复第512bytge，有时候则会丢掉某些数据。

检查发现是控制idt的fifo的oe与68013的slwr的时序有问题。

那时候写状态机写的还是相当混乱的。。。最后把某个寄存器操作延时了一个clk把问题解决了。

说到这个延时clk还有另外一个事情

前几天做一个fpga直接控制phy片输出udp包的板，fpga采集到的数据先送到了一个megacore生成的dcram里，dcram in的时钟是fpga主时钟分频，dcram out的时钟则是来自phy片的txc。

但是出来的数据死活不对。。

比如给ram写入01234567

出来的则是70563412

反复分析过2进制的每一位，没有任何问题。。。

之后发现是metacore的dc ram的output，我选择了clk register，使发送出来的数据延时了一位

于是第address位的data变成了address-1的。。。