非同期クロックのタイミング制約について(迷走中)
特にこれといって答えは出ていないのですが、非同期クロックの扱いに嵌っているので、少し経過を整理しておきます。
普段はあまり複数のクロックソースを混ぜることは無いのと、混ぜても局所的であまり嵌った事が無かったのですが、今回は迷走中です。
Zybo Z7 にて、PSから生成したクロックと、PLに直接入力されている125MHzからMMCMで生成したクロックとをそれぞれ、システムで使っていましたところ、タイミングエラーが取れないという状況になっています。
現在、非同期のクロックを使うにあたって、例えば低速なバスクロックから書き換えるレジスタを、高速のクロックで動く演算コアで参照していたり、自作の非同期FIFOを使っていたりするわけです。
UG903などには set_clock_groups で -asynchronous指定するようにかかれていますが、
https://japan.xilinx.com/support/answers/44651.html
を読むと「それぞれ set_false_path 制約が設定されている場合と実質的には同じです。」などと書かれていたりします。
自作の非同期FIFOなどは、グレイコードを利用しており、少なくとも同時に1bitしかメタステーブル状態に入らず、ダブルラッチ後に安定さえしてくれれば0と1のどちらに倒れても整合が取れることを前提に書いております。が、200MHz級の回路だと、下手すると普通に同期回路でも制約をミスすると動かない世界なので、 set_false_path だと1サイクルの幅を超えて2bit以上がメタステーブルに入る危険が出てきます(非同期FIFO以外も似た思想でデータ渡しているので同じ問題が出ます)。
で、set_max_delay での制約が正解なのかとおもいきや、どういう値を設定するべきなのか悩み中です。
単純にクロック周期では不足な気もします。
また、単純にクロック周期で指定しても下記のようなありさまです。
Requirement は set_max_delay -datapath_only で指定した 5ns 指定が確かに入ったのですが、 Clock Skew -4.613ns などが入り込んできてエラーになっているわけです。
もちろんクロックスキューも計算に入れる必要があるわけですが、結局のところ「クロックスキューも含めて、すべての配線ばらつきの相対値が、別サイクルと混入しない範囲に収めたい」というのが要件でして、これを正しく指定する手はあるのだろうかというところで嵌っています。そもそもみんな揃ってずれるなら 5ns 以上の遅延があっても良いわけでして、単に max_delay だけで縛ると厳しすぎて制約が満たし難くなる気もします。
いやまあ、これが目的じゃないし、時間ももったいないので、いつものように、「動いているから気にしない!」で次に行くと思うんですが、イマイチ腑に落ちない状況です (^^;;
(後日談 2018/05/04)
上記のタイミングエラーは、コピペミスで似た名前の別のクロックに対して制約していたことが判明しました m(_ _)m
クロックスースが別で非同期なのでですが、たまたま周期があっていて自動計算されたRequirementが設定した値と同じだったので設定が効いている物とばかり思い込んで嵌っていました。いい勉強にはなりました。
« Zybo Z7 への Raspberry Pi Camera V2 接続(MIPI CSI-2受信) | トップページ | Zybo Z7 への Raspberry Pi Camera V2 接続 (1000fps動作) »
「FPGA」カテゴリの記事
- LUT-Networkの蒸留とMobileNet風構成とセマンティックセグメンテーション(2020.03.09)
- LUT-Networkの蒸留(Distillation)について(2019.12.29)
- FPGAでのDNN(Deep Neural Network)の整理(LUT-Netまとめ)(2019.12.15)
- LUT-NetのFPGAリソースについて(2019.12.08)
- MNIST認識のリアルタイム動作環境更新(2019.09.02)
この記事へのコメントは終了しました。
« Zybo Z7 への Raspberry Pi Camera V2 接続(MIPI CSI-2受信) | トップページ | Zybo Z7 への Raspberry Pi Camera V2 接続 (1000fps動作) »
コメント