一個(gè)req-ack接口引發(fā)的問題分析

最近定位了一個(gè)bug，代碼是以前的同事留下的，沒有經(jīng)過太多充分的測(cè)試，且沒有仿真平臺(tái)，定位的過程是相當(dāng)?shù)耐纯?，前后花了差不多一個(gè)星期。但是解決這個(gè)bug后，回頭看，其實(shí)也是一個(gè)很簡單的問題，就是請(qǐng)求應(yīng)答（req_ack）接口處理不正確造成的……

問題現(xiàn)象

項(xiàng)目在上板測(cè)試過程中必現(xiàn)報(bào)文被丟棄的現(xiàn)象，方案不是很復(fù)雜。FPGA從CPU獲取報(bào)文索引，然后根據(jù)索引讀取CPU內(nèi)存的報(bào)文（為了描述簡單，這里省去項(xiàng)目相關(guān)信息）。

定位過程

1、該模塊以前沒有問題，后繼模塊工作頻率降低后，給該模塊反壓了，才會(huì)出現(xiàn)該問題，首先是各種統(tǒng)計(jì)，上板測(cè)試沒有發(fā)現(xiàn)問題，說明邏輯內(nèi)部處理報(bào)文的時(shí)候沒有丟包；

2、這里省略1萬字各種懷疑各種測(cè)試，多方位證實(shí)了邏輯內(nèi)部處理報(bào)文的時(shí)候確實(shí)是沒有丟包的；

3、懷疑是不是CPU丟了索引，或者FPGA丟了索引？但是都不太好證實(shí)，因?yàn)閬G棄報(bào)文的時(shí)候FPGA本身不感知，也不知道軟件下發(fā)了多少索引。

4、在和同事一起討論懷疑點(diǎn)，檢視代碼的時(shí)候，看到CPU告知FPGA描述符的時(shí)候，通過寫寄存器的方式來告知，F(xiàn)PGA處理采用的是req_ack接口。如下圖所示：其實(shí)這也不是一個(gè)標(biāo)準(zhǔn)的req_ack接口，因?yàn)檎?qǐng)求方只給一拍的wen信號(hào)，req和ack的處理都是應(yīng)答方內(nèi)部的一種處理方式。

所以有一個(gè)大膽猜想，會(huì)不會(huì)是上一次req還沒有處理完，CPU又來了下一個(gè)req導(dǎo)致有索引丟棄，從而導(dǎo)致了報(bào)文丟棄了？這個(gè)現(xiàn)象很好監(jiān)測(cè)，當(dāng)wen和req同時(shí)為1時(shí)，即為錯(cuò)誤，監(jiān)測(cè)代碼如下所示：

always@(posedge clk_sys or posedge rst)
begin
    if(rst == 1'b1) begin
        error <= 1'b0;
    end
    else if((wen == 1'b1) && (req == 1'b1)) begin
        error <= 1'b1;
    end
end

增加error信號(hào)后，再次測(cè)試的過程中，果然error信號(hào)拉高了。

解決方案

首先CPU在寫寄存器的過程中，并不知道FPGA是否正確處理上一個(gè)索引，其次FPGA處理一個(gè)索引和報(bào)文的時(shí)間是未知的，和后繼模塊的性能有關(guān)。所以解決這個(gè)問題的方案就是先緩存CPU寫入的索引，然后再讀出來慢慢處理。如下圖所示：

CPU寫入索引后，先不處理，全部緩存到一個(gè)fifo中，然后再從fifo中讀出每一個(gè)索引依次處理。修改后的方案再次做穩(wěn)定性測(cè)試，上述問題不再出現(xiàn)。

這里會(huì)有一個(gè)問題，該fifo不會(huì)溢出嗎？在這個(gè)項(xiàng)目中，是不會(huì)的，因?yàn)镃PU連續(xù)寫入索引的最大個(gè)數(shù)是32個(gè)，所以只要fifo的深度大于32即可。那如果CPU連續(xù)寫入索引的個(gè)數(shù)沒有限制呢？上述方案也就無效了，必須和CPU之間建立一個(gè)發(fā)壓的機(jī)制，保證CPU寫入的索引不會(huì)丟失。

總結(jié)

本案例中的問題，是使用req_ack接口時(shí)，常見的一個(gè)問題，請(qǐng)求方和應(yīng)答方要保持好握手，在上一個(gè)任務(wù)處理結(jié)束前，不可以發(fā)起下一個(gè)任務(wù)。

另外這種接口在高性能場(chǎng)景下，是有一定的性能損耗，盡可能采用流式接口來處理。