今年过完年回到学校，大概二月19日，开始调SDRAM这个实验，目的是想做最后的那个数码相框的项目。特权使用的SDRAM是三星的K4S641632（64M），而我板子上是海力士的H57V1262GTR（128M），由于不知道二者时序是否兼容，于是乖乖的按照特权的建议，仔仔细细的把《SDRAM-高手进阶,终极内存技术指南——完整进阶版.pdf》一文读了个遍，结果感觉时序是一样的，又从网上查资料，得到的结论也是二者兼容。于是不打算动其中大的时序过程。检查程序，修改程序，进行了许多尝试，下到我的板子上进行验证，反复进行了有10多天左右的时间，依然是输出仍旧全FF ，还有别的任务，于是就先放下了，但心里真的不爽，因为这个程序自己尽力了，真诚的想把它调出来。
8月15日开始，学习TimeQuest，Nios，有个Nios例程外挂SDRAM的，提示错误，varified failed in(某一地址)，在system.h中根据地址找到了这个器件，是SDRAM。再去网上查找这个错误，列出的原因竟然有一条是：SDRAM坏掉了或者引脚短路。一下子就开始怀疑我这个板子上的SDRAM是不是真的有恙了。黑金整合篇实验十八也讲到了SDRAM，于是借来仲的板子，结果程序在它上面直接可以跑的，而我的无论如何不行。还不够确定，又借来支的板子，天，又是直接可以运行！这下算可以下定论了，原来我板子上的SDRAM果然有问题。伴随着的也是一种苦涩的心情：难道年初我调SDRAM程序那么几天没成，原因竟是我板子SDRAM有问题？（没经验，真可怕）
然后就拿支的核心板以及我的母板，开始调试。刚开始进行串口试验时有个发现，那就是，程序还没下进去，串口助手就一直高频率的收到00，而当我用手触摸板子上排针时就没有这个情况。我纠结了，如果万一程序是好的，因为另外这个原因，怎么验证得了呢？昨天周五晚，回到青云门，忽然想起USB转TTL不也是个串口么，于是果断换上小板，问题彻底解决（方法果然比困难要多的啊！），目前还不知道，是USB转串口线出问题了，还是板子接地什么的问题，这个问题以后再解决。到这一步，真正的调试开始了。
其实，我对特权的时序有信心以及对问题更具有针对性是因为，网友，http://bbs.eeworld.com.cn/thread-344070-1-1.html，所做的说明。第一步更改是让UDQM和LDQM接地。意外出现了，竟然直接就是1988的实验现象，感慨了，年初的时候，我板子上那个坏SDRAM害我不浅啊！接下来是增加地址线，这个好操作，就是把地址扩一位就好了，但要注意全部相关的都要扩，包括data_gene模块里的moni_addr，这次实验现象没有变化。于是开始按照1988网友所说，重点查找两个FIFO的读写地址。看使能信号有没有问题，就要对程序读写过程，以及写完数据后，数据何时能写入，读完数据后，数据何时才能读出等了然于心。这个又有点耗时了，毕竟大半年没看时序了。最后了解到：
1.读命令发出后（已经经过active命令），要经过CL个潜伏期，一般是2，然后数据才会出现在总线上。
2.写命令发出时（同上），对，就是要和写命令同步，要写入的数据就该出现在总线上。
3.TRcd的含义：在发送列读写命令时必须要与行有效命令有一个间隔，这个间隔被定义为tRCD。
4.还应该发现，特权的程序中工作状态跳转到下一个状态时，计数器cnt_clk_r是从0开始的，这个也很重要。
最后做如下修改，
顶层文件中添加：assign sdram_udqm=0; assign sdram_ldqm=0;
sdram_ctrl中修改：assign sdram_wr_ack = (work_state == `W_WRITE) | ((work_state == `W_WD) & (cnt_clk_r < 9'd8)& (cnt_clk_r >= 9'd0)); //写 SDRAM响应信号,作为wrFIFO的输出有效信号
assign sdram_rd_ack = (work_state_r == `W_RD) & (cnt_clk_r >= 9'd0) & (cnt_clk_r < 9'd8);
sdram_wr_data中修改：else if((work_state == `W_WRITE) | ((work_state == `W_WD)&(cnt_clk < 9'd8)& (cnt_clk >= 9'd0)))
至此，锁定完引脚就可以看到正确的实验结果了。年初的经历真的… 淡淡的疼，不过总算出来了。整个实验有点急于求成，没有用sigaltap，没有用美光的模型（这个还没学习..），以后调程序还得从仿真着手，那样快些。不过这次，所想的方法，或改进在纸上写出来了，就像贴吧里那个一样，这个习惯我感觉倒是挺好，以后继续坚持，~~附上手稿，留个忧桑而又兴奋的纪念：
