今年过完年回到学校,大概二月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,没有用美光的模型(这个还没学习..),以后调程序还得从仿真着手,那样快些。不过这次,所想的方法,或改进在纸上写出来了,就像贴吧里那个一样,这个习惯我感觉倒是挺好,以后继续坚持,~~附上手稿,留个忧桑而又兴奋的纪念: