modelsim模擬中的 vsim-3601錯誤

這幾天一直為這個問題頭疼，幾天終於解決了！可能快熬到頭了或者是中午belinda給我帶來的好運！反正是解決了~
出現問題是在所有的demux模塊combination的過程中，原來每個模塊的testbench驗證表明ok；但通過的demux的testbench發現在功能模擬中，出現問題。
情況如下：
模擬開始后
# ** Fatal: (vsim-3603) Zero-delay oscillation loop detected at time 11175 ns.
通過查詢verror 3603指令
verror 3603
#
# Message # 3603:
# The simulator detected a connectivity loop in the design that is
# oscillating due to the delays being zero, and the loop not settling
# out to a stable state. The pathnames to each instance in the
# connectivity loop should be displayed along with this message.
# The simulation cannot be continued after this error occurs.
 
這個解釋說明，代碼中出現了“死鎖“現象，最主要是the loop not settling out to a stable state。說明存在0延時的震蕩，是由於不能建立一個穩定的狀態。但是如何查找呢？首先對testbench進行測查，修改之後發現只能改變出現問題的時間；看來和這個無關，再分析memory interface和datamux的部分，發現啟動這兩個模塊就有問題。懷疑memory的FIFO，因為內部的雙埠RAM是採用xilinx的
core generator生成的，因為潛意識裡好像有人在論壇上說過類似PLL引起的問題。結果被誤導，一無所獲。今天仔細分析code和中斷時的wave graph，終於發現問題所在。
這是memory 內部的狀態：
該狀態機的敏感量
always @(fifoRd_fsm or reset or DemuxReq  )
 
 fifoGrant:                                        // complete one time cycle  FIFO read of demux
                    begin
                    if( DemuxReq == 1'b0)
                       begin
                       DemuxGrant = 1'b0;
                       fifoRd_next_fsm = RdCounterAdd ;
                       end
                    else
                      DemuxGrant = 1'b1;
                    end
 
 
同時ES slice模塊的一個狀態：
該狀態敏感量
always @(  reset or ES_fsm  or ESRDGrant or ESValid or ESRDValid or ESWRGrant or ESsliceValid )
 
CodeStartReq:                           // request
             begin
                 if(ESRDGrant == 1'b1)
                      begin
                      ESRDReq =1'b0;
                      ES_next_fsm = prefixCodeDo;
                      end
                  else
                      ESRDReq = 1'b1;
             end
 
這兩個通過wire連接即ESRDgrant = demuxgrant;ESRDReq = DemuxReq。
同時躍遷的clk一樣。
問題因此而產生，本來採用握手協議，保證數據可靠傳輸。
但由於潛意識減少狀態變遷次數，採用了不成熟的代碼風格。
導致
 
step1: DemuxReq =1;
         則
          Demuxgrant =1;  // A fsm
 
step2:ESRDGrant = 1: // B fsm ,敏感量 ESRDGrant
        則
         ESRDReq =0;
 
step3: DemuxReq =0;  // A fsm,敏感量 DemuxReq
         則
         Demuxgrant =0;
step4:ESRDGrant = 0: // B fsm ,敏感量 ESRDGrant
        則
         ESRDReq =1;
重新返回step1，構成loop；從而clk無法形成穩定的狀態。
通過synplify分析發現,REQ和Grant信號都是有一個多路選擇和鎖存器構成，哦累了，下次再用RTL來分析