從 IC流程中探索數位工程師的風格--III

在上述的 IC流程中，還有其他工程師也是參與其中；而你是數位工程師，你對其他工程師的責任是什麼你有清楚嗎？

案例分享：

在這個 IC流程中，數位工程師會需要類比工程師的幫忙部份，絕大部份是在synthesis LIB的參考和simulation時的模型建立。曾經遇過類比工程師需要數位工程師幫忙驗證他們建立的LIB是否正確？在這個IC流程中，確實可以幫類比工程師驗證LIB。但是當初在規劃行程時，有把這個時間算進去嗎？而且整個design在進入synthesis階段時，在很多的synthesis條件都沒有穩定的情況下，拿去幫類比工程師驗證 LIB是否是正確的選擇？所得到的結果是否會是正確？不正確的話，又需要多少時間收斂？所以類比工程師的LIB 驗證，應該是要在他自己的環境下去完成，而不應該在整合的環境中去做驗證。

IC流程裏，它不是幫類比工程師驗證LIB，它是依據類比工程師提供正確的LIB來做合成的工作。所以在synthesis之前，數位工程師就應要求類比工程師提供正確的LIB，不然就無法合出最合適的netlist。

為什麼synthesis時，要有正確的LIB？

DC-compiler依據LIB上的資訊，利用它的演算法，計算出哪一個gate是最合適的，計算出所有path的timing，告訴你哪一個是很緊的。依據這種概念，合出來的netlist才會是最接近真實的情況。

以下是案例的分享: 

類比工程師進度落後，告訴數位工程師，你用設delay方法來收斂 timing，類比工程師會按規格要求，處理好 interface timing，之後就可以tape-out。LIB部份，類比工程師會用手動的方式建立，讓整個 synthesis 流程順暢。 結果晶片回來後，在某些頻率下，會容易出錯。問題查了很多，原因是data出錯；所以數位工程師不可避免的成為主要的負責人。從design到synthesis，然後再到primetime check，之後還check floor-plan。結果發現，是類比工程師在設計介面時，使用推力不足的cell，所以在頻率快的情形下，setup-time violation。但這完全查不出來，因為LIB是非常完美的LIB，它不是擷取類比電路所計算出來的。它是人工的，所以在這個流程中，數位工程師當然查不到setup-time violation的報告。

合成時為什麼需要LIB？當然是想要在最接近真實的情況下，合出適合的netlist。因為LIB太過理想，所以合出來的netlist當然也是太過理想。

為什麼國外大廠的晶片穩定度高？技術好是一個原因。另外一個是他們嚴格要求IC流程的模擬要符合真實情況。所以他們一定用軟體來擷取類比電路，計算出正確timing後，才會公佈 LIB給數位工程師使用。儘量讓所有的數據都是最接近真實情況。

說完IC流程後。我大約分類一下風格，大家或許就可以知道我所說的是什麼意思。希望藉由這些分類，可以更了解你的工程師伙伴在想什麼？

1. Front-end RTL level數位工程師：遇到問題時，想盡辦法在RTL-level解決，並在RTL-simulation確保function的正確性。其寫出來的RTL code都是synthesizable，了解RTL code限制，也知道如何在DC環境下，寫出適合的constrain，也知道怎麼看懂的所有的timing report。其程式風格像前面RTL code的解決方式一.

2.Front-end post-level數位工程師：程式的風格像前面的RTL code的解決方式二，需要CAD的工程師幫忙保證 timing，無法在RTL-level就保證其timing和正確性。

3.Front-end artificial數位工程師，程式的風格像前面的 RTL code的 interrupt machine的原始範例，用人腦推論；對於DC-compiler提出來的 timing violation時，人工確認是否為假錯( false-error )。

4. cell-base數位工程師：使用verilog語法並參照standard cell/customized cell，畫出電路，不是用寫程式的觀念來寫程式的。

5. Back-end數位工程師: 熟悉DC的指令、primetime指令。對做ATPG, IO scan非常清楚，但是對RTL-coding觀念比較薄弱，因為對DC和 primetime指令熟悉，所以較適合做IP整合工作。

其實還有其他種類的數位工程師，在此就不一 一敘述，我就針對以後我的分享風格做一個說明，讓大家知道我為什麼這樣做，我的原因有在哪裏？我的要求在哪裏？

做為一個數位工程師，你會遇到的問題和困難一定會很多，有時候你無法保證一定可以在RTL level就把它解決，這其中包括 timing。 而 timing的部份，你可能需要別人的協助，才能把問題解決。但是我希望所有的問題盡量在RTL-level就解決完，除非不能解決時，才會請CAD幫忙保證 timing。之後如果我有分享程式時，你會看到我程式都會在RTL-level解決問題。每個程式也都一定會知道怎麼寫 timing constrain和看它的 timing report。 

從 IC流程中探索數位工程師的風格--II

就Back-end而言：

就Back-end的工作內容，主要的負責單位是CAD部們，數位工程師只是輔助的角色。如果是輔助的角色，那麼應該要注意哪些細節呢？

1. 建立primetime環境來驗證CAD做完APR後的netlist是否是符合自己的需求。

2. 請CAD給一套和他工作環境相同的primetime環境，做為最後驗證timing的path的依據。

3. 任何因為timing不符合時，需要修改netlist時，請CAD重做一份，數位工程師不代勞。

4.任何因為bug問題，需要修改netlist時，數位工程師要做，但是再請CAD工程依修改的netlist做出一份新的post netlist及timing model。不用數位工程師修改的版本來做primetime check。要用CAD的版本做primetime check。

5. 數位工程師要跑post-level simulation，驗證post-netlist是否是正確的？

6. 如果都驗證無誤時，要用CAD部門的版本當成是對外要tapeout的版本。

或許你會覺得有些地方是多餘的，像是第一點和第二點，就是要一套primetime來做timing check，誰建的還不都一樣。曾經遇到CAD拿到錯的timing constrain，結果CAD報一大堆timing violation，我用CAD的primetime環境查半天才發覺。所以當CAD報有timing無法收斂時，第一個要先確認是不是環境設定問題。畢竟你給出去netlist時，在DC都是timing收斂。很少有機會到primetime時，發散，除非 margin留得不夠，不然前後應該是一致的。所以為了確保CAD的環境的同步，就只好自己先建一個primetime，兩邊同步在相同的認知上，再開始工作。

另外，對於為什麼要堅持CAD部門提供tapeout的netlist？以及發現timing violation時，數位工程師為什麼不能自己修改？我舉一個案例分享。

有人曾經遇到，project leader發現bug和timing violation時，而為了趕上當初承諾的行程，project leader自己修正bug和timing後，自己用primetime check static timing以及formal check比對RTL和netlist。發現都沒有問題後，就直接tapeout。晶片回來後，發現有部份的設計，有hold-time violation的疑慮，project leader不敢說自己有修正netlist，直說是CAD的版本有問題，CAD部門查了半天，都查不出來。重做第二版時，就用新的RTL code合成，也真的是用CAD部門的netlist tapeout，結果第二版的晶片出現和第一版本的錯誤完全不同。總經理就疑惑，「不是沒有改RTL code為什麼會這樣子？」工程師在第一顆晶片查到的有些問題，都無法在第二顆晶片上得到解釋。Project leader也無法在第一顆和第二顆晶片實驗中，得到他完滿的解釋。最後是誰背黑鍋，還是CAD。因為hold-time violation沒有再出現，但是新的問題又出現，而從頭到尾第一顆晶片和第二顆晶片的RTL都是一樣的，只是第一顆的RTL是在tapeout前才底定。

Back-end這個階段，數位工程師只是輔助的角色，那就做好輔助的工作，一切都是CAD說了算，project leader也沒有能力去修正netlist，數位工程師的本份就是盡力幫CAD版本的netlist做最大的驗證；發現任何問題，就是要讓大家都知道，然後再跑一次流程。每個計劃中，有很多的成員加入，尊重每個領域的專業，並讓他確實的負責，這樣子才會讓加入的工程師有參與感和使命感，才能留住工程師的心。

token的轉移和劃分的概念，不光是用在design上，還可以用在IC的流程上，實際上，它很多其他的地方。整個project的規劃也可以用這個概念，只不過當方法和規則建立後，你願意嚴格遵守並確實的執行嗎？

有的數位工程師會嚴格遵守並確實執行，有的不會。我們都知道，事實上是很難，因為project leader有schedule(行程)壓力，project leader怕別人知道做錯的壓力等等，總是可以找到合理解釋，來縮減IC流程中的步驟。運氣好的話，沒事，運氣不好的呢？

工程師是做科學驗證的工作，希望能嚴格遵守並確實執行，提昇晶片的穩定度及品質。或許有著各式各樣的壓力，但是能堅持下去，就是知行合一實踐。不然光說不練，對於管理上也是一種很大的傷害。

程式中邏輯內涵的用意? ( 用If-else和case的舉例 )

程式中邏輯內涵的用意? ( 用If-else和case的舉例 )

程式應該要有邏輯的內涵，並非是表面所寫的面貌的。有邏輯內涵的程式可以讓程式便於看懂，對於後來接手的工程師而言，他可以藉由這些邏輯內涵和以前的工程師神交，瞭解前人的邏輯維思。

今天以if-else和case為例，來說明邏輯內涵是什麼？

我們都知道，if-else的寫法是和優先順序有相關的，而case是沒有優先順序關係的。但是，這是否是絕對的定律。我們來看一下下面的程式。

always@(*)

begin

    if(value==2’b00)

       A = 2’b00;

    else if(value==2’b01)

        A = 2’b01;

    else if(value==2’b10)

        A = 2’b10;

else

        A = 2’b11;

    end

end

以下是case的例子

case(value)

2’b00:   A= 2’b00;

2’b01:   A= 2’b01;

2’b10:   A= 2’b10;

default:  A= 2’b11;

endcase

在if-else的程式中，我們看到value=2’b00時的優先權最高，再來是value=2’b01 -> value=2’b10 -> value=2’b11。但我們想想value=00的最高優先權有意義嗎？value=00和value11會同時發生嗎？不會。那麼用下面的case來取代，是否是可行的？答案我想大家都是知道的。當一個數位工程師，我們要知道數位的內涵，而不是就表面的東西來解釋，然後就講一些沒有錯的道理來爭論。為什麼這麼說？就上面if-else的程式而言，這位工程師希望value=00的優先順序是最高的，然後依次是01 -> 10 -> 11，但是當每個值都不會同時發生時，那麼你排優先順序有什麼意義嗎？電路上的邏輯不會有任何錯誤，但是卻會造成你在合成電路時，電路實際上的latency以及gate count有所不同。

每個程式的寫法、意義，都是在代表你對事物的邏輯思考。而工程師本身必須對邏輯思考要精準到位，用你的程式來告訴別人你的思考邏輯是什麼？而不是只是結果是對的。因為當你的結果和別人一樣，但是推理過程和別人完全不同時，那麼在討論的過程中，如何培養默契？如何讓別人知道你的邏輯思緒是清晰？

因為邏輯只有0(錯)和1(對)，當他的結果是對的，但內涵卻是不同時，你會怎麼做？舉例來說：如果有家長想抱孫子，而父母雙方有某種程度上不容易受孕，這時長家不管雙方父母，就是一定要抱孫子，此時，應該怎麼做？有人領養、有人做人工。但是如果有人是強抱別人家的小孩，你會怎麼想？當然會覺得是錯的。就算你是當事者的家長，應該也不會鼓勵這種行為。還是說，很好，有孫子抱就好，就算是犯法也不管。(PS: 或許例子舉得不是那麼好，希望能多多見諒 ! )

結果很重要，但是邏輯的內涵也同樣重要。因為這些都是代表邏輯思緒上的合理性。這種合理性是給後來的工程師去了解程式的一種方法。如果程式沒有合理性，就算結果是對的，對後來接手的工程師而言，無異是一場災難的開始。

一個全方位的數位工程師在寫程式時，不應只是考慮 latency和 gate count，你還要考慮它的邏輯內涵；讓別的工程師在看你的程式時，有前後一貫性，知道你的邏輯思維。當他看不懂你的程式碼時，他才能有所依據，按照你的邏輯思維來推演你的程式碼，慢慢地讀懂你的程式。

希望下次當你在寫 verilog 程式時，不是只是把它當成是電路來做，而是把它當成「程式」來看待，畢竟它的名稱還是叫做 verilog code，而不是叫做 verilog circuit。

從 IC流程中探索數位工程師的風格--I

今天想跟大家提一下IC 流程。因為我未來的分享也是和它有關。先溝通認知的部份，才能繼續下去。

我認為數位工程師的風格有很多，就像軟體工程師的風格也有很多種類。數位工程師的風格的分類，我是依據 IC流程來做分類的。每位數位工程師專精的地方有所不同，所以解決問題的思維也就不同。了解清楚 IC流程的權則劃分後，我會舉一些案例，讓大家去思考流程中的關鍵是什麼？初學者藉由這樣子的思索，探索想成為什麼樣子風格的數位工程師。

Fig: IC design flow

簡單說明一下流程。流程的開始是從規格的制定開始。確定規格後，開始規劃晶片的架構及功能。分配完工作後，就開始RTL coding。一邊coding一邊跑RT-level模擬。如果有錯誤，就回去修改RTL. 驗證所有的Design後，就去FPGA平台驗證，確認無誤後就可以合成netlist。Netlist和RTL做比對，確認兩者是相等的，就跑Gate-level 模擬。如果結果不是自己想要話，就是回到DC重新合成或是到修改RTL。都沒有錯，就給後段工程師APR. APR後，就跑Post-level 模擬。如果有錯，回到gate-level修正，或是RTL-level修正。如果都沒有錯，CAD工程師把後段的所有工作檢查完。然後就tape-out. 每個步驟都代表階段工作已驗證完畢後，才可以往下一個階段進行。

從Fig圖，我們看到，IC流程被分為front-end和back-end兩個階段。

先說Front-end：　

我相信每位數位工程師都知道front-end的工作內容，在此就不贅述。數位工程師是否知道front-end階段中，他應該注意哪些細節，才會產出高品質的netlist。我提出幾點來供大家參考，如果你還有更好的想法，歡迎你也提出來分享!

1.RTL code都要是synthesizable(可被合成的)，而且知道自己每個constrain的條件以及interface的timing要符合60/40原則。(60/40原則: 留給別人60%的timing margin。自己只用40%, 也有人說是40-20-40比例，40%自己用，40%是別的工程師用, 最後20%是留給CAD工程師做APR使用。)

2. RTL-level simulation coverage 要到90%以上。

3. FPGA驗證到錯誤時，必須把這個錯誤的情況重新複製到RTL-level simulation，建立完整的驗證資料庫，下一位工程師在改程式時，就不用在FPGA驗證時，才發現舊問題。混淆FPGA工程師驗證的流程。

4.合成時，確認每個D-flip-flop都有timing report可讀；每個path都有timing constrain；interface的delay都很完整。Clock的宣告都是符合你的設計想法。

5.做好clock tree和reset tree的說明，讓CAD工程師了解你的設計想法。

6.確認給CAD工程師的tcl檔案是對的，而且和你的DC tcl檔案是相符合的。

7.確認合成出來的netlist是對的後，才交給CAD工程師。

以上七點，相信大家都是認同的，但是有嚴格要求做到嗎？

舉例來說。相信大家一定看過 Interrupt的機制。如果沒有看過也沒有關係，下面是常見的Interrupt的機制。

原始範例：

always@(posedge clki or negedge rstni)

begin

    if(~rstni)

        IRR00 <=0;

    else if(B==1) //error happend

        IRR00 <=1;

    else

        IRR00<=0;

end

assign IR_EN00 = IRR00 & (REG_IRR_EN[0]);

assign IR_RST00 = (clr_id==4'h0);

  always @(posedge IR_EN00 or negedge IR_RST00)

  if(~ IR_RST00)

      IRR_00_Z1    <= 0;

  else

      IRR_00_Z1    <= 1'b1;

  else

      IRR_00_Z1    <= IRR_00_Z1;

就IRR_00_Z1這個D-flip-flop而言，合成時，你有特別宣告IR_EN00為clock嗎？IR_RST00位於reset tree上，在做ATPG時，DRC不會過，DC-compiler會幫你修正，但是你怎麼知道它會幫你做？它做的修正是你想要的嗎？是對的嗎？

或許你想反駁，這些的 timing不是很重要，所以不用管。ATPG會幫你修正reset或是clock時，tool不會錯。這樣子的想法和上述哪幾點相衝突?

第一點 timing constrain不曉得要怎麼寫？

第四點 沒有每個D-flip-flop都有timing report，因為 clock無法宣告。

第七點 無法確認合成出來的所有 timing是對的，因為timing report無法全部產生。

如果程式改成下面的情況時，是不是就做到我們的要求？

解決方式一：

always@(posedge clki or negedge rstni)

begin

    if(~rstni)

        IRR00 <=0;

    else if(B==1 & REG_IRR_EN[0]) //error happend

        IRR00 <=1;

    else

        IRR00<=0;

end

always@(posedge clki or negedge rstni)

begin

    if(~rstni)

        IRR00_sync <=0;

    else if(IRR00==1) //error happend

        IRR00_sync <=~IRR00_sync;

    else

        IRR00_sync<=IRR00_sync;

end

     

always@(posedge nosleep_clki or negedge rstni)

begin

    if(~rstni)

    begin

        IRR_00_Z1_pre_sync1 <=0;

        IRR_00_Z1_pre_sync2 <=0;

    end

    else

    begin

        IRR_00_Z1_pre_sync1 <=IRR00_sync;

        IRR_00_Z1_pre_sync2 <=IRR_00_Z1_pre_sync1;

        IRR_00_Z1_pre_sync3 <=IRR_00_Z1_pre_sync2;

    end

end

assign IRR_00_Z1_pre_sync4 = IRR_00_Z1_pre_sync2 ^ IRR_00_Z1_pre_sync3;

     

always@(posedge nosleep_clki or negedge rstni)

begin

    if(~rstni)

    begin

        IRR_00_Z1 <= 0;

    end

    else if(IRR_00_Z1_pre_sync4)

    begin

        IRR_00_Z1 <= 1;

    end

    else if(clr_id==4'h0)

        IRR_00_Z1 <= 0;

    else

        IRR_00_Z1 <= IRR_00_Z1;

End

clki和 nosleep_clki是我們一定會宣告。跨clock domain設false-path。IRR_00_Z1的 timing是不是就可以報告出來。

那原來的那段程式，是不是就不要再用？當然不是，我們是要符合七點的要求，design沒有做錯，為什麼要放棄？只要做些修正，重新合成，還是可以用。

解決方式二：

module interrupt_machine (

input clki

,input rstni

,input B

,input [3:0] clr_id

,input scan_mode

,output IRR_00_Z1

)

reg IRR00;

wire IR_EN00;

wire IR_RST00;

reg IRR_00_Z1;

always@(posedge clki or negedge rstni)

begin

    if(~rstni)

        IRR00 <=0;

    else if(B==1) //error happend

        IRR00 <=1;

    else

        IRR00<=0;

end

assign IR_EN00 = IRR00 & (REG_IRR_EN[0]);

assign IR_RST00 =scan_mode?rstni : (clr_id==4'h0);

  always @(posedge IR_EN00 or negedge IR_RST00)

  if(~ IR_RST00)

      IRR_00_Z1    <= 0;

  else

      IRR_00_Z1    <= 1'b1;

  else

      IRR_00_Z1    <= IRR_00_Z1;

     

endmodule

將 Interrupt_machine單獨合成，請CAD工程師幫忙做成 Macro，確保 timing都是你想要的，以call macro方式來合成全部的電路；而 IR_RST00部份，你也修正到適合ATPG情況。當你在跑模擬或是 formal check時，都可以確保你的 reset沒有做錯。

這兩種做法都可以達到你的要求，但是它的差別是什麼你知道嗎？

第一種解決的情況是工程師自己可以解決，可以在RD團隊中解決問題。

第二種是需要CAD工程師幫忙保證你的 interrupt timing，這需要跨部門的合作。

這就是我所說的數位工程師的風格。你是要成為只相信tool的工程師；或是每個module都需要別人幫忙的工程師；亦或是自己可以處理每個bug，並想辦法驗證它的正確性以及 timing constrain的工程師。但是不管是哪一種，都希望你都能符合上述的七個要求。

producer and consumer concept ( II )

上一回，我們談到生產者與消費者的關係和資料前後一致性的特性。
在一個系統中，因為存取的動作複雜，產生許許多多不同的死結。因為有人試著把存取的動作規劃出優先順序，減少存取時會發生的死結。
在把優先順序說出來以前，我們要先把存取的動作歸納出基本的含意。然後才能把順序制定出來。
名詞解釋：
PMW: 這是一個posted write的動作。也就是說master 發出一筆 write data到slave。當送出這個動作後，master就不管是否真的會到slave。也就是說master在發出 write data後，就不負有任何的責任。
DRR:這是一個non-posed read的動作。也就是說master發出一筆 read data到slave。當送出這個動作後，master還是繼續等待slave的回覆。也就是說master在發出 read data後，還負對資料回來的責任。
DWR:這是一個non-posed write的動作。也就是說master發出一筆 write data到slave。當送出這個動作後，master還是繼續等待slave的回覆，確保資料是真的被寫到slave。也就是說master在發出 write data後，還負有對正確寫入的責任。
DRC: 這是一個回覆read的動作，也就是如果master有發出一筆 read data 到slave，那他就會等到slave回覆的DRC封包，得到它想要的資料及狀態。
DWC: 這是一個回覆 write 的動作，也就是如果master有發出一筆 write data 到slave，那他就會等到slave回覆的DWC封包，得到它想要的資料及狀態。
Posted: 指 master 送出去的命令後，即失去對它的責任。它有沒有正確到達目的地是別人的責任，不是 master的。
Non-posted:指 master 送出去的命令後，還負有對它的責任。它有沒有正確到達目的地是 master關心的事情。

Fig: system with complex devices.

PCI ordering rule. 

Tab: PCI ordering rule

Row是指隨後而來的的命令。而Col是指先前發出的命令。所以(Col, Row)則是指Col指令排在Row之前。所以我們來看看這個表格。

Rule1: 指(Col 2，Row 1)，指一個PMW和PMW的順序，也就是說兩個相同的posted write指令，後面的posted write是否可以超前posted write。答案是不行。如果接受端對於收到資料是有順序性的，隨便違反順序是會讓系統出錯的。

Rule2: 指(Col 2，Row 2)，指non-posted read是否可以超前posted write，答案是不行。如果這兩筆是指向相同的位址，那non-posted read超前posted write，不就讀到不正確的資料。

Rule3: 指(Col 2，Row 3)，指non-posted write是否可以超posted write，答案是不行。就如同之前提過的生產者與消費者的模型。當生產者寫完資料後，還要把status清除為0。如果清除的動作超前寫入的動作時，此時消費者在讀status時，不就會誤認資料已經寫完，以致於讀到舊的資料。

Rule4: 指(Col 2，Row 4)，non-posted read是否可以超前posted write，答案是不行。就如同rule3一樣，如果把讀status的動作超前生產者的寫入動作，那麼消費者就無法得到從系統中得到正確的訊息，以致消費者就會發生錯誤。

Rule5: 指(Col 3，Row 1)或是(Col 4, Row 1)，指posted write是否可以超non-posted read或是non-posted write。答案是可以的。不超前的話，會有死結產生。請看Fig，如果master1  發出一筆non-posted read到bridge , master3送出一筆non-posted read到bridge，當這兩筆同時被bridge Y接受時，因為兩邊bus都被佔住，所以無法執行這兩筆non-posted。之後master1又發出一筆posted write時，這一筆要能超前non-posted read，不然整個匯流排就會被這兩筆non-posted read卡住，而無法執行。如果posted write可以超前non-posted read，則就有可能等到所有的命令均被執行後，non-posted read才能有機會得到被執行的機會。

Rule6: 指(Col 3，Row 4)，指剛剛發出的read，目的端已經回覆回來，是否可以超前non-posted read或是non-posted write。答案是可以的，因為既然正確的答案已經回傳回來，當然是要讓它儘快回到發送端，以便讓發送端再送出下一筆的命令。

Rule7: 指(Col 5，Row 1)，是指posted write是否可以超前回覆的命令，答案是可以的。以生產者-消費者模型為例，如果data buffer和flag, status是不在相同的bus上，consumer發出一筆讀取status和flag的命令出來，在得到正確的訊息後，producer正要把資料寫入data buffer，所以這兩筆的資料都是正確的，沒有順序相依關係。所以超前是不會讓系統造成錯誤發生。

Others:其他的格子裏是寫Yes/No，是指超前可以，不超前也可以，要自己判斷。也就是說，如果命令間是沒有相關性的，那你就超前，如果有相關的，那你就不可以超前。這牽涉到系統規劃，以及和軟體間的溝通，所以沒有特別的答案，一切看自己。

其實，在這7個規則裏，都是因為存取動作的順序會造成資料的錯誤或是死結產生，所以才會特別告訴工程師，在遇到這些情況時，是可以超前，或是不可以超前。我沒有把會造成死結的情況詳細說明，這是因為，從Fig圖中，我們已經知道Bridge有三個，其中兩個是支援2.1版前的，另一個是支援2.1版的。因為版本的不同，造成命令在處理中，會有死結產生。

要詳細知道死結產生的情況，是要對 PCI 的規格了解。我怕有些人是不知道，所以用另一種方式來解答，是從命令上的意義來解答。如果想知道更周全的，建議詳讀 PCI 規格，就可以讓你能更了解為什麼要制定這些規則。