【W(wǎng)ord版本下載可任意編輯】跨時(shí)鐘域信號(hào)處理中同步通信的設(shè)計(jì)的重要性及解決方法elsebegin

case（addr_bus）

4’h0：data_bus《=counter;

4‘h1：……;

……

default：;

endcase

end

咋一看，可能你會(huì)覺得這個(gè)代碼也沒什么問題，功能似乎都實(shí)現(xiàn)了。而且你會(huì)覺得這個(gè)代碼簡(jiǎn)潔，也不需要消耗多少邏輯就能實(shí)現(xiàn)。但是，對(duì)于這種時(shí)鐘滿天飛的設(shè)計(jì)，存在著諸多亞穩(wěn)態(tài)危害爆發(fā)的可能。脈沖信號(hào)和由CPU控制總線產(chǎn)生的選通信號(hào)是來自兩個(gè)異步時(shí)鐘域的信號(hào)。它們作為內(nèi)部的時(shí)鐘信號(hào)時(shí)，一個(gè)寫存放器counter，一個(gè)讀存放器counter。那么，很明顯的，存在著發(fā)生沖突的可能。換句話說，如果存放器正處于改變狀態(tài)（被寫）時(shí)被讀取了，問題就隨著而來，如圖3所示。

圖3數(shù)據(jù)沖突

脈沖信號(hào)pulse和CPU讀選通信號(hào)cpu_cs是異步信號(hào)，pulse什么時(shí)候出現(xiàn)上升沿和cpu_cs什么時(shí)候出現(xiàn)下降沿是不可控的。所以，如果它們很不幸的一起觸發(fā)了，那么，結(jié)果可想而知。計(jì)數(shù)器counter［15:0］正在加一，這個(gè)自增的過程還在開展中，CPU數(shù)據(jù)總線data_bus［15:0］來讀取counter［15:0］，那么到底讀取的值是自增之前的值還是自增之后的值呢？或者是其它的值呢？

所示，它是一個(gè)計(jì)數(shù)器的近似模型。當(dāng)計(jì)數(shù)器自增一的時(shí)候，如果位為0，那么自增的結(jié)果只會(huì)使位翻轉(zhuǎn)；當(dāng)位為1，那么自增一的后果除了使位翻轉(zhuǎn)，還有可能使其它任何位翻轉(zhuǎn)，比方4’b1111自增一的后果會(huì)使4個(gè)位都翻轉(zhuǎn)。由于每個(gè)位之間從發(fā)生翻轉(zhuǎn)到翻轉(zhuǎn)完***需要經(jīng)過一段邏輯延時(shí)和走線延時(shí)，對(duì)于一個(gè)16位的計(jì)數(shù)器，要想使這16位存放器的翻轉(zhuǎn)時(shí)間一致，那是不可能做到的。所以，對(duì)于之前的設(shè)計(jì)中出現(xiàn)了如圖3的沖突時(shí)，被讀取的脈沖值很可能是完全錯(cuò)誤的。

圖4計(jì)數(shù)器模型

上面的代碼是典型的組合邏輯實(shí)現(xiàn)方式，是很不可行的。也許很多朋友會(huì)提出異議，也許還會(huì)提出很多類似的組合邏輯方案。但是，如果沒有同步設(shè)計(jì)的思想，不把這兩個(gè)異步時(shí)鐘域的信號(hào)同步到一個(gè)時(shí)鐘域里開展處理，沖突的問題在無法得到有效解決的。

那么，這個(gè)設(shè)計(jì)該如果同步呢？實(shí)現(xiàn)的方案其實(shí)上提到FPGA與MCU通信的文里已經(jīng)給出了答案。它的設(shè)計(jì)思想可以如圖5所示。圖5先是使用脈沖檢測(cè)法把脈沖信號(hào)與系統(tǒng)時(shí)鐘信號(hào)clk同步，然后依然使用脈沖檢測(cè)法得到一個(gè)系統(tǒng)時(shí)鐘寬度的使能脈沖作為數(shù)據(jù)鎖存信號(hào)，也將CPU的控制信號(hào)和系統(tǒng)時(shí)鐘信號(hào)clk同步了。如此處理后，兩個(gè)異步時(shí)鐘域的信號(hào)就不存在任何讀寫沖突的情況了。

圖5同步處理