今年過完年回到學校，大概二月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，沒有用美光的模型（這個還沒學習..），以后調程序還得從仿真着手，那樣快些。不過這次，所想的方法，或改進在紙上寫出來了，就像貼吧里那個一樣，這個習慣我感覺倒是挺好，以后繼續堅持，~~附上手稿，留個憂桑而又興奮的紀念：
