電子回路わからん日記

にゃーんと言いながら電子回路いじってます

タイミング制約でどこまで遅延調整が働くのか試してみた

どうもです。

突然ですが皆さん、FPGAと周辺デバイスで通信するとき、クロックとデータの関係ってどうなってます?

AUDIYはI2CとかSPIのイメージで「クロックの1→0への変化に合わせてデータも変化する」というイメージがあるのですが、肝心のFPGAはそういった通信をクロックの「立ち上がり」でデータを読み取るので、FPGAから出力するときにどうすればいいか迷った時期がありました。

実際に過去に質問したことがあるのですが、

当時は知識がなく上記の選択肢くらいしか思いつきませんでしたが、その中で出てきた返答が

当初は「シングルエンドなのにDDR?」と思いながら調べたところ、なんと「2つのデータ入力に0と1を入力しておいて、実際のクロックと逆位相を出力する」というもの。

AMDでも紹介があるので、ごくごく一般的な方法なのだと思います。

docs.amd.com

ちなみに上記のような「データウィンドウの中心にクロックの読み取りエッジが来る」信号を「センターアライン」と呼ぶそうです。

monoist.itmedia.co.jp


その一方・・・

下記記事ではDDR出力を利用せずに、センターアラインの通信においてクロックの読み取りエッジ付近でセットアップ/ホールドを制約する方法が記載されています。

monoist.itmedia.co.jp

この記事の書いていることが本当であれば「逆位相のクロックを作らなくてもセンターアラインの通信において制約を満たす設計が可能な場合もある」ということになります。

と同時に、AUDIYの中で一種の疑問が湧きます。

「どの程度までなら遅延を加えることが可能なんだ?」

実際にタイミング制約をいじって複数のFPGAバイスで確認してみることにします。


実験に用いたデザイン

なんてことはない、8bitのアップカウンタです。

8bitアップカウンタ

FPGAボード上の水晶発振器からのクロックをPLLで分周し、PLL出力の立ち上がりエッジに同期して数値を1ずつ増加させていきます。

PLL出力の周波数は使用するオシロスコープ(Analog Discovery 3)の性能も考慮して2MHzとし、出力クロックの立ち上がりエッジとカウンタ出力の最下位ビット(実質出力クロックの2分周)との時間差を計測します。

時間差を確認しながらタイミング制約のset_output_delayの値をいろいろいじってみて、実際に遅延を付加できるのか、付加できる遅延量の最大値はどの程度なのか確認してみます。


タイミング制約

以下、出力遅延に関するタイミング制約です。

set_output_delay -clock { o_clk } -min -15.000 [get_ports {o_count[0] o_count[1] o_count[2] o_count[3] o_count[4] o_count[5] o_count[6] o_count[7]}]
set_output_delay -clock { o_clk } -max   5.000 [get_ports {o_count[0] o_count[1] o_count[2] o_count[3] o_count[4] o_count[5] o_count[6] o_count[7]}]

クロックの立ち上がりエッジに同期してカウントアップすることを考えると、センターアラインと仮定したときにカウンタの出力を受けるデバイスにとってシビアになるのは「ホールドタイム」になります。

以下記事に記載の内容の通りに捉えるとホールドタイムに関する制約は-minの数値で規定できるので、今回は配置配線結果をなるべく揃えると言う意味でも-maxの値は5nsで維持しておき、-minの値を0nsから負の方向にシフトさせていきたいと思います。

monoist.itmedia.co.jp


DE0-Nano (Altera Cyclone IV E EP4CE22F17C6N)での確認結果

ホールドタイム0ns

Ch1がクロック、Ch2がデータになります。

実遅延時間は389.1psです。

ホールドタイム5ns

実遅延時間は6.926nsでした。

ホールドタイム10ns

実遅延時間14.55nsでした。

ホールドタイム15ns

実遅延時間23.27nsでした。

入力した制約値に応じてデータが遅延していることがわかります。
また、制約の値を-16nsにした時点でタイミング制約違反が発生しました。

 

別デバイスでも同様に確認してみます。


Efinix Trion T20 BGA256 Development Kit (T20F256I4)での確認結果

だめです。まったく変化しません。時間を広げれば広げるだけその差分がタイミング制約違反となって現れます。DE0-Nanoのように「ある程度遅延が付加される」ということはありませんでした・・・。


よくよく考えると・・・

というか当たり前のことなんですが、タイミング制約って遅延調整をするためのものではなくて、あくまで「設計したデザインが周辺デバイスのセットアップ/ホールドを満たせるか」を確認するツールなので、Alteraみたく「ある程度調整してくれる」とは限らないんですよね。

ということは下記の記事は「センターアラインのソースシンクロナスでもたまたまセットアップ/ホールドを満たせたらそのデザインを使えますよ」と言っているだけに過ぎません。

monoist.itmedia.co.jp

個人的には「こんな危ない橋をわたるくらいならハードウェアリソースを活用してDDRで反転出力するかな」と思いました。

malt.zendesk.com

それにしてもAltera FPGAはやはり柔軟性が高いですね。
今回AMDは手持ちのFPGAのMMCM/PLLで2MHz出力できなかったのでスキップしましたが、どこまでの柔軟性があるか試してみたいです。