我以前在xilinx上遇過報出來的timing不準
假使你的critical path相較clock之下很長
可能切個pipeline看看有沒有改善
這種condition 就算你拿tool吐出來.vm來跑post sim也根本跑不出來有問題
因為tool本身就是靠那些在算critical path跟timing violation
※ 引述《Trai (Trai)》之銘言：
: 感謝各位的回答
: 我還是持續在試驗不同的方法
: 不過目前有幾個試驗的結果
: 1. buffer部分，把array展開為16個獨立的register，並用一個MUX來選擇它們
: 作為OP。實驗後的結果錯誤率與使用array一樣。我猜應該說明了兩者合成
: 的結果是相同的，也就是register前後合成了很大的MUX。
: 2. 原本做為array index 的counter，後來發現quartusII 自動把它map到自己的IP
: 還是library "lpm_counter"，為了避免使用它的counter我用gate自己組counter
: 的加法器，成功避免他map到lpm_counter。換掉counter之後錯誤率明顯下降。
: 1200次運算約錯0~20次，所以我覺得問題可能出在餵OP這邊。
: 目前還在將程式移到modelsim，與撰寫testbench，RTL sim完成後會繼續做synthesis
: 後的simulation，但不知道這樣做意義大不大，很擔心做白工，問題最後還是沒解決。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 203.69.97.52