bug  review會

近幾天公司內部開了個IC設計前端的bug review會議，總結了經常出現的問題，很有意思，特記錄一下。

1. 在驗證的時候，不僅僅只從RTL角度考慮test case，也應該結合應用場景考慮test case。

      一方面，應用場景提出的要求可以幫助設計者檢查自己的設計是否符合能夠滿足實際需求；

      另一方面，也有助於功能驗證的完備性。

2. 同步設計中不允許在sdc約束中加入multicycle或者false path，如果綜合出現timing violation則

   可以通過修改設計插入register解決。設定了multicycle或者false path之後，STA工具就不會檢查

  這部分同步設計了。如果需要在前仿中加入對multicycle的模擬，可以通過加delay的方式模擬後仿。

3.  在涉及到RAM的設計中，一定要注意在某個時鐘週期內部，是否可能會存在同時讀/寫RAM而造成

     衝突的問題。

4. 在有明顯的週期性的處理過程(如多媒體中以幀為單位的處理），在當前週期處理完成或者下個週期開始處理

    之前要有自己回覆成原始狀態的功能。不能依賴於reset訊號回覆原始狀態。即系統 soft reset是當系統出現問題

    時恢復用的，在正常功能中不應該存在復位行為。

5. 在多媒體的驗證中，不能僅僅為了方便驗證單幀case。多幀的case也要佔到一定的比例。

6. 中斷報告的時機。考慮以下場景，假設A要通過fifo向C發資料，只有A真正的將資料全部寫入FIFO之後，才能報

    中斷給C。這是中斷報告的基本原則。以AXI匯流排寫為例，不能僅僅發出最後一筆AXI_WR的command就報中斷，準確來說應該等到

    全部BRESP回來再報中斷。

7. 設計AXI_master寫時，要等到一個burst全部資料都準備好（快取在一個FIFO中）之後才能發出burst write command，這樣子資料

   在下一個週期開始傳送。這種設計不會由於自身的設計問題拖累AXI BUS的效能。

8. 設計AXI_master讀時，要等到有足夠的空間能接受全部讀的資料（或者隨著時間推移，總是保證有足夠空間儲存資料，而不至於RREADY

   拉低）時，才能發出AXI read burst command。這種設計不會由於自身的設計問題而拖累AXI BUS的效能。

9. 當做UVM驗證時，最好不要單純做黑盒測試。為了測試的完備性，應考慮至少做到灰盒測試。

10. 寫sdc檔案時，一定要保證每一條約束都是有明確目的的，一定要在完全清楚該約束的含義及可能導致的後果的前提下，才能寫該約束。因為

     sdc設定問題而導致的晶片bug會很嚴重，且難於驗證出來。

11. 一般來說，軟體給硬體分配的空間是地址對齊的。但是由於硬體多以32bit為基準操作，所以硬體多是以word對齊的。這樣在驅動端就會導致軟硬體

     對齊方式的不一致。直接後果是：驅動為了匹配二者，從而徒勞的做一次資料搬運，而且可能會佔用一個靜態陣列，導致該空間被永久佔用。

that is all。