最近在調試burst_read_master讀sdram的時候遇到了一個問題，大概是現在水平太差，才后知后覺的遇上這個問題，因為網上搜索沒有碰到同樣問題的，廢話少說直接說事。
一、涉及類容：
avalon總線，sdram control，burst_read_master，sdram；
二、結構圖
三、簡述
quartus II的這個sdram control不支持突發讀寫，而我的sdram是支持突發讀寫的，這一點一定要分清楚。還有就是burst_read_master這個是avalon總線里面的連續讀（也叫突發讀吧），這個的效率比latency_aware_read_master的效率要高很多，原因就是burst_read_master給一次地址可以讀多個（可設置的突發長度）數據，latency_aware_read_master給一個地址讀取一個數據效率相對較低，同理burst_write_master也是比write_master的效率高很多。
四、問題點
在使用突發時，首地址連續讀出兩次對應地址的值，直接上圖，說可能說不清楚。備注：向sdram 0-639事先寫入值0-639，突發長度設置為8，設置讀取總長度640。
理論上在第一次讀有效產生后，讀的是地址0-7的數據，maste_readdata輸出0-7八個有效數據，master_adress會加8然后讀8-15地址的數，對應值輸出值8-15.實際是在第一次讀有效后master_adress沒有加8，導致maste_readdata在第二次輸出的值還是0-7，后面地址正常累加，輸出的值也符合預期，實際最后多出了八個數，fifo中有648個數。多出的數據是地址0-7讀了兩次的那幾個數。
五、原因
反復查看burst_read_master文件，對比avalon總線協議：
一開始以為是burst_read_master里面邏輯問題，查看代碼發現邏輯正常，經過一段時間思考，發現有可能是master_waitrequest==0的時候，設備在下一個時鍾上升沿沒有正常的獲取到這個變化。導致這次master_adress沒有累加。最后想到avalon總線上的時鍾我給的是100MHZ，而控制control_go的時鍾是24MHZ，在burst_read_master中持續了兩個周期，導致第一個master_waitrequest==0的時候，control_go還是高電平，address沒有累加。
六、總結
從這次調試中發現，時鍾真的很關鍵，要小心應用，希望為后面同樣遇到問題的你提供一個參考(菜雞的第一次分享，歡迎吐槽)。