不改程式碼的前提下進行時序最佳化還是比較難的
1.只能透過工具的各種最佳化選項去試試了，各種組合，廣撒網，如果在時序只是差一點的情況下，應該可以找到一種比較好的策略來收斂。
2.當然還可以透過pblock的方式來進行約束，不過這個如果是大專案，是非常費時間的，因為按照你的想象或者原來跑出來的好的結果上的佈局的方式進行劃塊的話，未必能夠取得好的效果,大部分的時間是比原來差，做這個事情這個要非常有耐心才行。
3.還有就是看看有沒有非同步路徑，非同步路徑可以先falsepath掉，這樣讓工具取抓重點。
4.還有就是一些配置訊號，如果是在同一個時鐘域，而平常根本不切換，或者切換的很少，或者切換出來一個亂的值，對系統不造成影響，系統可以快速的恢復，這樣可以設定falsepath掉，減輕工具負擔。
5.復位，對於有些資料流水的路徑復位可以去掉。如果程式碼都可以不依賴復位，就是不需要系統賦值一個初始狀態，系統業務照樣可以跑起來，就可以全部幹掉。如果嫌這個改程式碼麻煩的話，直接透過約束來進行falsepath，不過這樣還是要佔用了很多佈線資源，個人還是喜歡刪除復位，感覺很爽。
6.再看看扇出落，在程式碼裡面加些降低扇出的約束。
7.有些塊ram和分散式ram之間可以互換，透過部分的分散式ram替換塊ram，降低塊ram的資源佔用率。
8.再看看這塊的效能是不是有冗餘的，什麼是效能冗餘，比如說有塊的處理的效能很低本來可以很低，10m的時鐘就可以處理過來，你非得要用100m的時鐘，那不是自己給自己找麻煩麼，有效能冗餘的地方可以降頻率處理。
基本就是把大家前面答得總結了一下
改程式碼的話，整體的思路就是retiming和pipline，就是把關鍵路徑進行拆分。這裡大家都講了很多了
不改程式碼的前提下進行時序最佳化還是比較難的
1.只能透過工具的各種最佳化選項去試試了，各種組合，廣撒網，如果在時序只是差一點的情況下，應該可以找到一種比較好的策略來收斂。
2.當然還可以透過pblock的方式來進行約束，不過這個如果是大專案，是非常費時間的，因為按照你的想象或者原來跑出來的好的結果上的佈局的方式進行劃塊的話，未必能夠取得好的效果,大部分的時間是比原來差，做這個事情這個要非常有耐心才行。
3.還有就是看看有沒有非同步路徑，非同步路徑可以先falsepath掉，這樣讓工具取抓重點。
4.還有就是一些配置訊號，如果是在同一個時鐘域，而平常根本不切換，或者切換的很少，或者切換出來一個亂的值，對系統不造成影響，系統可以快速的恢復，這樣可以設定falsepath掉，減輕工具負擔。
5.復位，對於有些資料流水的路徑復位可以去掉。如果程式碼都可以不依賴復位，就是不需要系統賦值一個初始狀態，系統業務照樣可以跑起來，就可以全部幹掉。如果嫌這個改程式碼麻煩的話，直接透過約束來進行falsepath，不過這樣還是要佔用了很多佈線資源，個人還是喜歡刪除復位，感覺很爽。
6.再看看扇出落，在程式碼裡面加些降低扇出的約束。
7.有些塊ram和分散式ram之間可以互換，透過部分的分散式ram替換塊ram，降低塊ram的資源佔用率。
8.再看看這塊的效能是不是有冗餘的，什麼是效能冗餘，比如說有塊的處理的效能很低本來可以很低，10m的時鐘就可以處理過來，你非得要用100m的時鐘，那不是自己給自己找麻煩麼，有效能冗餘的地方可以降頻率處理。
基本就是把大家前面答得總結了一下
改程式碼的話，整體的思路就是retiming和pipline，就是把關鍵路徑進行拆分。這裡大家都講了很多了