參考ug906.
• 邏輯延遲百分比過高（邏輯延遲 (logic delay)）
○ 邏輯層次是否過多？ （邏輯級數 (logic levels)）
○ 是否存在阻礙邏輯最優化的任何約束或屬性？ （don't touch 或 mark debug）
○ 路徑是否包含具有高邏輯延遲的單元， 例如 ramb 或 dsp 等？
○ 當前路徑拓撲結構的路徑要求是否過於苛刻？ （要求 (requirement)）
• 高訊號線延遲百分比（訊號線延遲 (net delay)）
○ 在路徑中是否有任何高扇出訊號線？ （「高扇出 (high fanout)」或「累積扇出 (cumulative fanout)」 ）
○ 分配給多個 pblock 的單元布局能否拉開距離？ (pblock)
○ 單元布局能否拉開距離？ （「邊框大小 (bounding box size)」或「時鐘區域距離 (clock region distance)」 ）
○ 對於 ssi 器件， 是否存在跨 slr 邊界的訊號線？ （slr 交匯 (slr crossings)）
○ 在布局看似正確的情況下， 是否有 1 個或多個訊號線延遲值遠高於預期？ 請參閱擁塞 (congestion) 部分。
• ramb 或 dsp 單元中缺少流水線暫存器（而路徑中存在此暫存器）
○ 檢查路徑， 確認針對 ramb 或 dsp 單元是否已啟用流水線暫存器
• 高偏差（建立 <-0.5 ns， 保持 > 0.5 ns）（時鐘偏差 (clock skew)）
○ 此路徑是時鐘域交匯路徑嗎？ （「起點時鐘 (start point clock)」和「端點時鐘 (end point clock)」 ）
○ 時鐘是同步時鐘還是非同步時鐘？ （時鐘關係 (clock relationship)）
○ 此路徑是否跨多個 i/o 列？ （io 交匯 (io crossings)）
常在實際工作中遇到如下兩種時序違例：
1.同時鐘域中暫存器到暫存器間的組合邏輯延遲過大，導致下一級暫存器的建立時序違例。
解決方法：通過時序報告，在延遲大的組合邏輯間加入一級暫存器。
2.不同時鐘域間的時序違例。
解決方法：跨時鐘域的資料傳輸可以用非同步fifo，或者用目的時鐘打拍，至少兩拍，並在約束檔案中set_flase_path。
亂碼的解決思路
推薦文章 1.理解清楚字元 字元集合 字元編碼方式 2.ucs 是通用字符集的簡稱，同unicode字符集是一套字元集合，ucs是iso組織的.3.亂碼的原因是，字元編碼方式 和 解碼方式不一致.a.先檢查putty或者secucecrt的字元編碼方式 如 指定為utf 8 b.其次檢查系統的語言環...
Android OOM解決思路
android oom主要有兩個方面導致 1.記憶體洩漏。2.短時間內顯示的過多過大。記憶體洩漏可以使用leakcancry進行檢測，主要注意內部類的洩漏，往往是洩漏整個activity 一定要進行壓縮，壓縮一定要解析度和質量都進行壓縮。如果本身不大比如10k,但解析度為2000 2000，那一樣會...
解決Too many open files思路
一 產生原因 too many open files是linux系統中常見的錯誤，從字面意思上看就是說程式開啟的檔案數過多，不過這裡的files不單是檔案的意思，也包括開啟的通訊鏈結 比如socket 正在監聽的埠等等，所以有時候也可以叫做控制代碼 handle 這個錯誤通常也可以叫做控制代碼數超出...