FC2ブログ

[VEEK]カメラの映像を表示したい(3)(ピンアサインエラー)

NEEK時代の回路をそのままVEEKに実装しようとして、ピンアサインエラーが
消えず、困った。結局tPAD_Picture_Viewerのqsfを利用することに。

元々ピンアサインを全て真似して修正していったのだが、全て同じ配置、電圧
にしてもエラーが消えない。デモ回路の方はコンパイルパスする。

違いが分からず、NEEK用qsfを土台にするのを諦め、tPAD_Picture_Viewer
のqsfを土台にして、必要最小限だけ自分の回路構成に合わせて修正。
これでやっっとQuartusIIコンパイルパス。

跡で何が違うのか確認してみよう。
それにしても、コンパイルパスした時の時間、異常に早い。

Compile Design: 1:18
 - Analysis & Synthesis: 0:47
 - Fitter: 0:22
 - Assembler: 0:04
 - TimeQuest: 0:05



よくよく見るとLE使用率とか1%になってる。何かおかしい。

(2011/12/25追記)
デモ回路のtPAD_Picture_Viewer.vを見ると以下のように
外部非同期リセットはH固定にしてるみたい。

assign reset_n = 1'b1;

nios_simple nios_simple_ins(
// 1) global signals:
.clk_ext(CLOCK_50),
.reset_n(reset_n),



元々Openになってしまっていたリセット信号を、同じくH固定で
やり直したら、結果がかなり変わった。
1分半で終わっていたコンパイル時間が4分弱まで増えた。
そして、Total Logic elementsも1%から10%へ増加した。

Compile Design: 3:50
 - Analysis & Synthesis: 1:25
 - Fitter: 2:00
 - Assembler: 0:10
 - TimeQuest: 0:15


Openにしてた時は、確かQuartusIIが勝手にOpen信号をLかHに
固定してくれるものと記憶してるが、おそらくL固定にされたんだと思う。
それで、リセットアクティブ固定だから、大半の回路は冗長論理となり、
自動的に論理圧縮をされたものと予想。

リセットをH固定にした事で、使用LE数は10倍になったが、やっぱり、
コンパイル時間が早い事に違和感を感じる。
NEEKのPicture Viewerデモのような構成で回路作っていた時は、
22000LE/Total 25000LEくらい使っていて、LE使用率が100%近かった。
LE使用率に加えて、全回路100MHzでインプリすると違反が多数出て、
それを改善するのに、Fitter EffortなどをHighにしてたから、どんどん
コンパイル時間が延びていったのと思う。

LE使用率に余裕ある母体で、今は周波数最大50MHzだから、おそらくほとんど
配置配線やり直す必要がないと、こんなに早くなるとは。

画像出力のDOTクロック等は周波数固定なので仕方ないが、それ以外は、
なるべく遅い周波数で一度システムを完成させてから、それからパフォーマンス
UPのチューニングをして行くのが効率良い気がする。
パフォーマンスのノルマがある訳でも無いし、なんとかタイミングMETさせようと
時間使い過ぎてしまった・・・
スポンサーサイト



カレンダー
11 | 2011/12 | 01
- - - - 1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
累積訪問者
現在の訪問者
現在の閲覧者数:
最新記事
最新トラックバック
最新コメント
月別アーカイブ
カテゴリ
プロフィール

bobgosso

Author:bobgosso
FPGAのブログへようこそ!

検索フォーム
RSSリンクの表示
リンク
ブロとも申請フォーム

この人とブロともになる

QRコード
QRコード