新規のクロックを用意するべきか？イネーブルを設けるべきか？

Question

前提

module hoge(CLK, RESET, INPUT, OUTPUT);
のようなIPモジュールを使いこなしたいと考えております。
このIPはVerilogで記述されていて、やや規模の大きな順序回路、パイプラインになっています。
毎クロックINPUT端子からデータを取り込みます。4096回繰り返します。
数クロックのレイテンシが発生したのち、
毎クロックOUTPU端子からデータを吐き出します。4096回繰り返します。

実現したいこと

実現したいことは、このIPモジュールを上位の回路よりも低周波(1/256)で動作させたい、という内容になります。
しかしながら、このIPがイネーブル信号を持っていないため、上位の回路と同じクロックを供給すると同じ周波数で動作してしまいます。そこで、1/256のクロックを新規に用意するべきなのか？もしくはIPに手を加えてイネーブル信号を設けるべきか？(上位の回路がカウンターを持って256カウントに1回だけイネーブルをアサートすることで1/256動作にする、という方法。)

安易にクロックドメインを増やすことは推奨されない？
検証済みのIPの中に手を加えることはあまり良いことではない？

簡単かつ安全に実現するにはどのように考えるべきでしょうか？どのような方法がおすすめでしょうか？

該当のソースコード

IPモジュールの中では、以下のように、すべてのFFが毎クロックposedgeで動作してしまう記述になっていることが問題の発端だと思っています。

always@(posedge CLK or negedge RESET)
begin
 if(!RESET)
    begin
     FF1   <= 16'h0000;
    end
 else
   begin
     FF1   <= INPUT;

補足情報（FW/ツールのバージョンなど）

この実装作業はXilinx FPGAのzynq上で行っており、ツールはVivado v2019.1 (64-bit)を使用しています。

[補足]そもそもなぜ上記のことをやりたかったのか
先に作ってしまった上位の回路が速い動作クロックで動いているためです。
特に、他のモジュールとのやり取りにおいて、同一のデータを取り扱いますが、データラインのbit lengthが違ったりします。シリアルでデータをやりとりしているブロックも存在します。それに対して、本題のIPモジュールはINPUT/OUTPUTはパラレルで構成されています。
そういった、スループットの違いから待ち時間が発生する、このブロックについては遅い周期でサンプリングしたい、といった背景から質問させていただきました。

Comments

[ozwk]

どちらもあまりやりたくないので、そもそもなんでそれがやりたいのかを教えて下さい

Answer 1

レイテンシが既知で固定値なら
入力データとともにValid（データ有効）信号を渡すようにして
出力データとレイテンシが合うようにValid信号を遅延させて出力に出します

module hogeWrapper(
input wire CLK,
input wire RESET,
input wire INPUT,
input wire VALID_IN,
output wire OUTPUT,
output wire VALID_OUT
);

hoge inst(CLK, RESET, INPUT, OUTPUT);

assign VALID_OUT = /** VALID_INを遅延させたもの **/

endmodule

Comments

[porkpie]

>レイテンシが既知で固定値なら
はい、レイテンシは既知です。固定値です。

>入力データとともにValid（データ有効）信号を渡す
これを行うには、IPがValid信号を受け取れるように、IPに手を加えることになりますでしょうか？

[ozwk]

IPに手を加えずに
ラップするモジュールを作ればいいです

[porkpie]

なるほど！！ありがとうございます。
IPに手を加えずにラッパーでレイテンシ対策ができるのは素晴らしいアイデアですね。

ただ、当初の問題、
IP側がINPUTデータ×4096を取り込む周期が、CLK周期だけで決まってしまう、
この問題は上位回路と同一のCLKしか持ち合わせていない場合、上位回路と同じ周期になってしまいますね。

[ozwk]

すみません、何が問題なのかわかりません。
IPの上流が256回に一回Validを発行して、下流がValidを確認するだけでは?
問題のIPは256回中255回は無駄な計算をすることにはなりますが、消費電力を問題にしていますか?

それともIPの処理が出力が入力の履歴に影響されるような処理ですか?

私はパイプライン処理と書いてあったので
定数倍や加算回路のような各入力が独立している処理を想像していました。

[porkpie]

"パイプライン処理"はレイテンシの発生理由しか表せていませんでした。

>各入力が独立している処理を想像していました
たいへん失礼しました。
IPの処理内容が、複数の入力データに基づいて１つの出力データが算出されるタイプのもの(デジタルフィルタ的な処理)であるため、256回中255回空振りのサンプリングをさせるわけにはいかない内容となります。

[ozwk]

でしたらIPに手を加えられそうなら加えますね。

[porkpie]

なるほど、ありがとうございます。
やや規模が大きいIPなので、編集でバグを生み出さないか心配ではありますが、検討してみたいと思います。

[ozwk]

上流側でデータをバッファリングして連続して渡せるようにするという手もあります

[porkpie]

それも良い手ですね！！
FIFOのようなものに連続データをためこんでから、いっきにIPに処理をさせる。
スループットの違いを吸収するのに良い手段ですね。ありがとうございます。

Answer 2

1/256のクロックを新規に用意する

といっても、上位回路のクロックと非同期にするのはありえないでしょう? 上位クロックを分周、あるいは同じソースからPLLで生成してクロックとして供給するのであれば、実質的には

256カウントに1回だけイネーブルをアサートする

のと等価です。

すべてのFFが毎クロックposedgeで動作してしまう記述になっていることが問題の発端

そうでないとしたらどういう構成がありうるのでしょうか?

Comments

[porkpie]

>上位回路のクロックと非同期にするのはありえない
>PLLで生成してクロックとして供給するのであれば、実質的には等価
ありがとうございます。
この考え方に確証を持ちたくて、投稿しました。

すみません、ひとつ教えてください。
>上位クロックを分周、あるいは
ここで言う"分周"は、FFの出力をFFのクロックに入力する分周回路を指していますか？
大昔にASICの現場で、ローカルのユーザーロジック内でFFの出力をFFのクロックに入力するタイプの分周回路を作成することが禁止されていました。FPGAではよく使用されている手法ですか？

>すべてのFFが毎クロックposedgeで動作してしまう記述になっていることが問題の発端
>そうでないとしたらどういう構成がありうるのでしょうか?
これは単に、INPUTデータ取り込みのリードイネーブルのようなものが付いていてくれればよかったのにな、というつぶやきです。

[thkana]

FFを多段で分周するのは遅延が出てだめでしょうね。

[porkpie]

やはりそう考えるのですね。おかげさまで、この考え方も確証が持てました。
ありがとうございます。

Answer 3

たんに1/256の分周回路かませてCLKに供給するだけで済むのでは

うーん、遅延が問題になるってならクロックに同期させればいいだけ、ってのはでてこないですか。

Comments

[porkpie]

そうなんです。以前、遅延が問題になるという理由で、分周回路で新規のクロックを作りだすことはASICの設計現場では御法度になっていたのです。
クロックツリー生成ツールが遅延を管理している正規のクロック信号しか使ってはいけない、と考えるようです。

xilinx FPGAの場合はやはりVivadoのツールが持ち合わせているPLLで1/256クロックを作るべきか、という考えになってまいりました。この場合は、元になっているクロックと位相が合い、同期回路の扱いをしてよいのかと思われます。

[y_waiwai]

なにも考えずにリップルカウンタで分周ってならそりゃ問題にもなろうもんですが、同期カウンタってのもありますし、それより以前にその回路構成、設計によってなにが最適かってのは変わるもんでしょう
それにより、リップルカウンタでも済むならそれでいいし、同期させても問題があるってなら、設計が悪い、ってなってくるかと。
いったい、なにが問題なのか、ってのをはっきりさせましょう

＃そもそも質問文からは同期の必要があるのかってのが読み取れんのは横に置いといて

[porkpie]

言葉足らずですみません。

普通なら(私なら)、
同期カウンタを使用して、データサンプリングの周期を制御します。たとえば今回のケースであれば、基準クロックに対して1/256に一回だけサンプリングされるようにデータ取り込みイネーブル信号を制御します。
というのが前提になっていました。

それに対して、
他人の作ったブロック(IPモジュール)がデータ取り込みイネーブル端子を持ち合わせてない場合、どのように対処するのがおすすめですか？という質問でした。