01signal.com

電子悪魔祓い: FPGAs が所有されているかのように振る舞うことがある理由

中文 | 日本語 | 한국어 | English

物事が奇妙になったとき

FPGAs は一般的に非常に信頼性の高いコンポーネントと言われていますが、他のテクノロジと同様に、正しく使用しないとうまく機能しません。

残念ながら、利用可能な FPGA design ツールは、人間が過ちを犯さないように導くのにはまったく役に立ちません。より具体的には、 FPGA ツールは、特定の design practices に従っている場合にのみ信頼性の高い操作を保証し、何をしているかを知っているという根本的な前提があります。 source codeにエラーがある場合に executable code の生成を拒否する software compilersとは異なり、 FPGA ツールは次のように言います。 「これが bitstreamです。よろしければ試してみてください。ところで、ここに 200 warningsがあります。 warning #143 の意味を理解すれば、修正が必要な深刻な問題があることも理解できるでしょう」.

FPGAs を使用している人々が、電子機器が何らかの魔法の力に取り憑かれていると感じ、何も意味がないと感じるのは珍しいことではありません。まったく無関係な変更の結果として、問題が発生したり消えたりする可能性があり、合理的な説明は見えません。多くの適切な教育を受けたエンジニアは、この奇妙な動作の説明を見つけようとして、 FPGAs に関するナンセンスな理論を採用する傾向があります。

これが「Black Magic モード」です。 分別のある人が、自分の問題には合理的な説明があると信じるのをやめ、代わりに自分の経験に基づいた解決策を探すとき。 FPGA が本当に寒いとき、すべてが正常に動作しますか?よし、巨大な heatsinkを入れろ。問題は一部の boards でのみ発生し、他の boards では発生しませんか? OK、各 boardをテストし、そうでないものは破棄します。等々。

それはどのようなものか

これは、エンジニアに不合理な考え方をさせる可能性がある問題の部分的なリストです。それは常に「...の場合を除いて、すべて正常に動作します」となります。

これには、電子機器自体に欠陥があり、 datasheetに対応していないという信念が伴うことがよくあります。大企業が欠陥のあるコンポーネントを出荷する方法についての陰謀論は珍しいことではありません。

したがって、これは単なるバグではありません。確かに、バグは人を狂わせる可能性がありますが、ある程度の再現性がある傾向があり、空調のために現れたり消えたりすることはありません.ソフトウェア エンジニアが PC コンピューター自体のバグを非難するのを聞いたことがありません (実際には非常にまれなケースですが)。対照的に、 FPGA design のミスは、ハードウェア レベルで確実に誤動作を引き起こす可能性があります。そこから全世界を責めるまでの距離は短い。

論理的な説明があります。本当。

しかも手の届く範囲です。必ずしも簡単ではありません。

この分野でフリーランサーとしてかなり長い間働いており、時々このような状況を解決してきました。 非常にまれなケースを除いて、 FPGA は問題なく、問題はおそらく bitstreamにあります。

悪いニュースは、 FPGA designには複数の欠陥があることが非常に多く、これらの欠陥が目に見える問題の原因である可能性があることです。その結果、修正することがたくさんあるかもしれません。かなりの回数、「ほとんど動く」 FPGA designを修正するように依頼されましたが、すぐに「この小さな問題」がすぐに修正されるという非現実的な期待に直面していることに気付きました。 design を安定させることは、多くの場合、目に見える進歩なしに多くの作業を行うことを意味します。

どっちにしろ、仕方がない。このページでは、とりわけ電子機器の幽霊のように見えるものの考えられる理由をリストすることにより、合理的な思考を取り戻そうとします.

もちろん、最善の方法は、最初からこのような状況を回避することです。別のページに記載されているゴールデン ルールに従うことは、良い出発点です。

なぜ物事が奇妙になるのか

簡単に言えば、 FPGA designに問題があるということです。その場合、原則として 2 つの可能性があります。比較的幸運な可能性は、 FPGA の機能に目に見える安定した機能不全がある場合です。これはソフトウェアのバグのようなものです: それを見つけて修正し、修正後に動作することを確認してください。

FPGA が動作する可能性はそれほど幸運ではありませんが、ほとんどの場合は幸運な偶然です。したがって、いくつかの条件が変化すると、 FPGA は突然正常に動作しなくなり、その後正常に動作するように戻る場合があります。しかし、なぜこれが起こるのですか？

だからここにポイントがあります： FPGA は電子部品であるため、製造中に不正確な点があります。さらに重要なことは、 silicon の温度が変化すると、 transistors の状態が変化する速度も変化し、同じことが logic fabricで信号が伝搬する速度にも当てはまります。 supply voltage の変更は、 FPGA内での処理速度にも影響します。

したがって、 FPGA が少し暖かくなったり涼しくなったりすると、信号は clockに比べて、 flip-flop に少し遅れて、または少し早く到達する可能性があります。これだけでも、この flip-flop がサンプリングすべき信号を見逃したり、 flip-flop が通常見逃している信号をサンプリングしたりする可能性があります。 silicon の局所的な加熱でさえ、 chip 上の隣接する (おそらく関係のない) logic がより少なくまたはよりアクティブになると、これを引き起こす可能性があります。

同様に、 FPGAs には製造上の不正確さがあります。工場から出荷されるすべての FPGAs は、仕様との互換性を保証するテストに合格していますが、一部の FPGAs は他のものよりも高速な silicon を搭載している場合があります。これが、不適切に作成された logic design が 1 つの FPGA で動作し、他の FPGA では動作しない可能性がある理由です。

これらのランダムなパラメーターはすべて、 logic fabricで小さなコンポーネントの状態が変化するときに影響を与えます。このタイミングの違いにより、完全に機能するものと大惨事との間の違いが生じる可能性があります。したがって、製造、温度、および電圧のわずかな偏差が目に見える違いを生む可能性があります。

では、 FPGA はどのように信頼できるのでしょうか? FPGA design が正しく作成されている場合、 FPGA design ツールはすべてが常に定義どおりに機能することを確認します。より正確には、製造テストに合格し、 datasheetの要件内で使用されるすべての FPGA ですべてが機能すること。これは要するに、周囲温度を必要な範囲内に保ち (必要に応じて冷却して)、 FPGAのピンの電圧を修正することです。

ただし、必要な FPGA design プラクティスに従わない場合、ツールも適切な操作を保証しません。つまり、違いを生むべきではないパラメーターが重要になり、 board 全体が動作を停止し、まったく問題にならないものに応じて動作を再開します。奇妙なものが手に入る方法に制限はありません。

繰り返しになりますが、いくつかの例を次に示します。

これは何度も繰り返す価値があります: FPGA design が適切に処理されている場合、このようなことはまったく起こりません。または、少なくとも非常にまれです。 datasheets を読んでフォローし、 FPGA も正しく使用したときに、電子機器の信頼性がどれほど高いかを理解している人はほとんどいません。

しかし、このページを読んでいる人にとって、この説教は少し遅すぎると思います。問題はすでにそこにあります。そこで、私自身の経験に基づいて、 FPGAが幽霊のように見える一般的な理由をいくつかリストアップしました。このような問題に直面している場合は、これらのいずれかである可能性が高くなります。

理由 #1: Timing

ツールは、提供されたtiming constraintsを実現することにより、 FPGA の安定した動作を保証します。これは、あなたとツールの間の取り決めです: タイミング要件を正確に表現すると、 FPGAが許容温度と電圧の範囲内で動作する限り、ツールは、使用するすべての FPGA でそれらが達成されることを確認します。

timing constraints が、 reference clockの周波数を含む単一の constraintであることは珍しいことではありません。これで十分かもしれませんが、この行を他の design からコピーしただけで動作する場合は、レビューする十分な理由があります.

実際、これは一般的に timing を正しく実行することに関するものです。これは、最も経験豊富な FPGA designerにとっても簡単な作業ではありません。これは、 design 内のすべての signal path が constraint によって制御され、最後の flip-flop が常に信号を正しく受信できるようにすることを意味します。 constrainingを必要としない paths を除きます。

したがって、最初に確認することは次のとおりです。 design は timing constraintsを達成しましたか?これは本当に基本的なことですが、ほとんどの FPGA ツールが bitstream を生成するため、 FPGA newbies はこの単純な間違いに陥る可能性があります。

次は timing constraintsのレビューです。このような検査について説明している別のページがありますが、簡単に言うと次のとおりです。 timing constraints の意味を正確に理解していますか?それらの意味は正確にあるべきですか？選択的な timing constraints がある場合、つまり、一部の paths を特に filter conditions でカバーしている場合、それらは実際に正しい pathsで機能しますか?

そして、 timing report を注意深く読む必要があります。繰り返しになりますが、この別のページでは、このトピックについて詳しく説明しています。

他に注目すべきは clock domain crossingsです。ある clock domain から別の clock domain に危険な信号が送られていますか?これは、どの logic が各 clockに関連付けられているかについての注意が不足していることが原因である可能性があります。 clock domain crossings は、 FPGA ツールによって作成された FIFOs だけで行われますか?そうでない場合、 crossings は正しく安全に行われていますか?

理由 2: 不適切な resets

関連性がないように見えるかもしれませんが、 logicの初期状態が保証されていない場合、 black magic の動作が発生する可能性があります。

ルールは簡単です: resets と logicのウェイクアップについて真剣に考えていない場合は、間違っている可能性があります。

特に、次の例を検討してください。

always @(posedge clk or negedge resetn)
     if (!resetn)
       the_reg <= 0;
     else
       the_reg <= [ ... ] ;

resets をこのように記述し、 @resetn が非アクティブになったとき (つまり、この例ではhighに変更) に何が起こるかを明示的に考慮しない場合は、必ずこのページを参照してください。

いずれにせよ、 resets があるべき場所にあり、適切に機能していることを確認することをお勧めします。これが何を意味するかは、このトピックに関する一連の短いページで説明されています。

理由 #3: Clocking

clocks の品質は、おそらく digital designで最も過小評価されているトピックです。よく「うん、ハイ ロー バック clockにしよう」みたいな感じです。

FPGA logic で使用される clocks は、安定していて、十分な jitter パフォーマンスを備えている必要があります。 clock から FPGA への物理的な接続は、安定して信頼できるものでなければなりません。

したがって、このようなステートメントでは、

always @(posedge clk)

@clk として使用されるものは、細心の注意を払って取り扱う必要があります。理想的には、この clock は専用の clock generator コンポーネント (oscillator) に由来します。これにより、 clock が安定し、 jitterが低くなります。一般的に言えば、この外部 clock を logicに直接接続するよりも、 reference clock から PLLとして使用する方が適切です。これは、 PLL が clockの周波数を変更しない場合でも当てはまります。

これは、 PLL を使用すると、 PLLの lock detectorを監視できるためです。したがって、この clock に依存する logic は、 PLL のロックが解除されたときに reset 状態に保持できます。そうすることで、 reference clock に安定性の問題がある場合 (特に powerupの直後) に問題が発生する可能性が大幅に減少します。

PLL はトラブルメーカーと間違われる可能性があり、散発的に lock を失うため、明らかに不要な resets を引き起こす可能性があります。 PLL を取り外し、外部 clock を logicに直接接続すると、誤って「修正」される可能性があり、その後はすべて正常に動作しているように見えます。このような場合、 reference clockに問題がある可能性があります。この場合、 PLL を取り外しても問題は解決しませんが、 logic fabricに押し込み、 black magic の状況を引き起こす可能性があります。

これまで、専用の oscillatorsから clocks について説明してきましたが、これは非常に簡単なケースです。他の情報源ではさらに悪化します: processor またはその周辺機器の 1 つによって作成された Clocks は、使用する場合でも慎重に使用する必要があります。このような clocks は、 processorによって一時的に停止されたり、不正な waveforms が生成されることがあります。これは、おそらく無関係なタスクの一部として、ソフトウェアが関連する hardware registersに書き込むことが原因である可能性があります。このような短いイベントは、 oscilloscopeで clock を調べたときに表示されない場合がありますが、それでも、これらの短いイベントは奇妙な誤動作を引き起こします。

もう 1 つの一般的な問題の原因は、 source-synchronous clockの扱いの悪さです。つまり、外部コンポーネントが clock 信号と 1 つまたは複数のデータ信号を供給すると、データは clockと同期します。通常、データ信号は、 clockの rising edges (または falling edgesのみ) と一緒にのみ値を変更できます。

source-synchronous clock を FPGA内の application logicに直接接続するのは、一般的ですが、かなり危険な方法です。これに関する問題の一部は、 source-synchronous clock が連続した clockとして使用されることを意図していないことが多いため、一時的に停止したり、 spurious pulsesを使用したりする可能性があることです。

もう 1 つの考えられる問題は、 source-synchronous インターフェイスが物理コネクタを介して FPGA に接続されることが多いことです。たとえば、データ ソースがケーブルを介して main board に接続されているカメラである場合です。コネクタは通常信頼性がありますが、振動によって物理的な接触が 1 ナノ秒失われただけでも、 clock 信号で不正な pulse が発生する可能性があります。もちろん、これはデータ信号でも発生する可能性がありますが、特にデータソースがカメラの場合、通常はそれほど重要ではありません。ただし、そのような clock 信号が application logic に直接接続されている場合、1 ナノ秒の pulse は間違いなく混乱を招く可能性があります。

したがって、 clock およびデータとの source-synchronousインターフェイスの最適なソリューションは、 clock と data の両方を通常の信号として扱うことです。したがって、 source-synchronous clock とデータ信号の両方が flip-flopsでサンプリングされ、安定した安全な非常に高速な clock が使用されます。これは、 I/O pinsに隣接する専用の flip-flops を使用して行うことが望ましいです。

source-synchronous clock がローからハイに変化すると、これは、この信号をサンプリングしている flip-flop の output の同様の変化によって反映されます。したがって、 source-synchronous clock の rising edges は、この flip-flop の output がローからハイに変化するという単純な事実によって、同期 logicで検出できます。この logic はもちろん、より高速で安定した clockに基づいています。この logic がこのような rising edge を検出すると、データを有効としてマークします。つまり、 data inputs の値を含む flip-flops の outputs は、有効なデータとしてマークされます。

01-signal sampling でのこの方法の明らかな利点は、 clock 信号に何が起こっても、 FPGAの logic は安全な clockに依存し続けることです。 source-synchronous clock が狂った場合に適切に応答するために edges を検出するのは、 logic 次第です。

この手法は、 source-synchronous clock の比較的低い周波数 ( FPGAの速度に応じて、 DDR sampling が使用されている場合は通常、 200-300 MHzまで) で可能です。

より高速なソースの場合、推奨される解決策は、 PLLにソースの clockを供給し、 PLLの output を application logicで使用することです。前述のように、 PLL がロックされていないことを示している場合は、 logic をリセットする必要があります。これは、別の理由でも正しい解決策である可能性があります。 前述のように 01-signal sampling の周波数が高すぎる場合、適切な sampling を保証する唯一の方法は、 clockの phase shifting によってタイミングを見つけることです。これは、サンプリングされた信号でエラーが検出されなくなるまで、タイミングが logic によって自動的に調整されることを意味します。とにかく、この手法では PLL を使用する必要があります。

理由 4: RTL designのルール違反

synthesis 用の適切な Verilog (または VHDL) コードは、いくつかの厳密な規則、特に RTL paradigm (Register Transfer Level) に従わなければなりません。とりわけ、これは、何らかの種類のメモリ (たとえば、 flip-flop) である logic element は、 clock edgeの結果としてのみ値を変更することを意味します。これに対する唯一の例外は asynchronous resetで、これは単なる信号ではありません。

synthesizer は、これらの規則に違反する Verilog コードに遭遇すると、通常は協調的になろうとし、シミュレーションが示すものと同じように動作しない可能性がある logic を生成します。もう 1 つの可能性は、 synthesis の結果がほとんどの場合、期待される動作を満たしていることですが、ランダムに失敗する可能性があります。

たとえば、 0 と 14の間のカウンタに対して、次の間違った design を考えてみましょう。

reg [3:0] counter;
wire      reset_cnt;

assign reset_cnt = (counter == 15); // This is so wrong!

always @(posedge clk or posedge reset_cnt)
  if (reset_cnt)
    counter <= 0;
  else
    counter <= counter + 1;

恐ろしい間違いは、 @reset_cnt を asynchronous resetとして使用することです。

しかし、これがシミュレーションでどのように機能するかを説明することから始めましょう。 @counter は @clkの rising edges でカウントアップします。しかし、 @counter が値 15に達すると、 @reset_cnt は '1' に変化し、 @counter は非同期的にゼロにリセットされます。したがって、 @counter が @clkでサンプリングされると、 0 から 14の値が表示されます。

ハードウェアでは、これは機能しない場合があります。問題は、 @reset_cnt が @counterの combinatorial function であることです。したがって、 @counter の値が 7 から 8 に変わると、 @reset_cnt を計算する logic は、 @counter の値を一時的に 15 と見なす場合があります。これは、 7 が binary codeの 0111 であり、 8 が 1000としてエンコードされるためです。したがって、 bit 3 が @reset_cntを計算する logic に最短の propagation delay を持っている場合、この信号は簡単に '1' になる可能性があります。その結果、 @counter は 0 から 14 までカウントする場合もあれば、 0 から 7までカウントする場合もあります。温度やその他の無関係な要因は、どのオプションが観察されるかに影響を与える可能性があります。

ただし、この例が間違っている理由の説明は非常に単純化されています。これらのツールは combinatorial logic を最も独創的な方法で自由に実装できるため、実質的に clock edges間であらゆることが起こります。ツールが保証する唯一のことは、宛先の flip-flops のタイミング要件 (setup time および hold time) に従って信号が安定していることです。

したがって、 logic design が RTL designに関する規則に厳密に従っていない限り、奇妙なことが確実に発生する可能性があります。

理由 5: 温度と power supplies

これはトラブルの一般的な理由ではなく、簡単に確認できます。それでも、温度と power supplies が奇妙な問題の根本的な原因になる可能性があります。

当然のことながら、 siliconの温度が許容範囲外の場合、動作が保証されるものは何もありません。最も一般的な理由は、不十分なサーマル プランニングによる過熱、またはほこりに悩まされているファンです。

power suppliesに関しては、さまざまな理由で output に欠陥がある可能性があります。 oscilloscope を使用した簡単なチェックで、電圧が指定範囲内にあるかどうかがわかることがよくあります。ただし、電圧は常にこの範囲内にある必要があります。平均電圧が正しいだけでは不十分です。 switching power supplies が常に作成するノイズも、時折 spikes が制限を超えることも許されません。

1 μs より長くない spike は無害に見えるかもしれませんが、 FPGA内の数十から数百の clock cycles であるため、これは FPGA に不適切な電圧が供給されるかなりの期間であることに注意してください。 FPGA に近い decoupling capacitors で電圧を測定して、実際に到達する電圧を確認することをお勧めします。また、 oscilloscopeの trigger を電圧の上限と下限に設定し、 oscilloscope がこれらに反応しないようにしてください。 oscilloscopeのディスプレイで短い spikes に気付くのは簡単ではありませんが、 trigger はそれらをキャッチします。

power supply の問題は、 board designの不具合の直接的な結果である場合があります。多くの power supply modules には、見落とされがちな minimal current があります。この minimal current が power supply moduleから放電されていない場合、不安定になり、仕様を満たさない電圧が発生するか、さらに悪いことに oscillationsが時々発生する可能性があります。

もう 1 つのよくある間違いは、 voltage regulator が必要な場所に switching power supply を配置することです。特に、非常にクリーンな inputを必要とする low-jitter clock oscillators があります。そのような oscillator がノイズの多い power supplyによって供給される場合、このノイズは clock output上の jitter に反映されます。 Gigabit transceiver がこの clock ( PCIe、 USB 3.x、 fiber optics など) を使用すると、 data linkの信頼性が低下することがよくあります。

同様に、 DDR memories が designの一部である場合、 reference voltage power supply が必要です。この電圧は、 FPGA と DDR memories の両方で、 '0' と '1' の間の電圧しきい値として、これら 2 つのコンポーネント間を通るワイヤで使用されます。この電圧が switching power supplyによって生成される場合、 voltage supply noise によって、 FPGA と DDR memoriesの間でエラーなしでデータを送信することが難しくなるか、不可能になる可能性があります。

理由 #6: 私をからかってるの？

black magic の状況の原因は、非常に大きな欠陥である場合があり、何かがどのように機能したのか不思議に思うことがあります。たとえば、 PCB の配線が関連する FPGA pinから完全に切り離されている場合でも、 crosstalk または parasitic capacitanceによって正しい信号が FPGA に到達します。

これは特に clocksで発生する傾向があります。これは、 board全体に配線されていることが多く、定期的な信号であるという事実により、 FPGA に到達する可能性が高くなり、問題がないように見えます。

そのため、必ず oscilloscope を使用して、すべての clocks を FPGAのできるだけ近くで確認してください。 clock用の AC coupling capacitor がある場合は、特に capacitor が見つからない場合があるため、確認するのに適した場所です。

理由 7: 単純なバグ

またはより正確には： design は機能するように作られたことはありません。 logic がどのように機能することが保証されているかを理解した人はいませんでした。代わりに、コードは trial and errorで、一部はシミュレーションで、一部はハードウェアで徐々に書かれました。このプロセスは正常に動作しているように見えたときに終了しましたが、コードを見ると、まったく機能していたことが奇跡のように思えます。 その小さなことを修正するために何度もパッチが適用されているため、変更を加えることはもちろん、何が起こっているのかを追跡することは不可能です.

これは実際には black magic の動作ではないため、この理由を最後に記載しました。それは非常に迷惑なバグです。それにもかかわらず、これが FPGA プロジェクトが動かなくなる最も一般的な理由です。

それでも FPGAのせいだと思う場合

時にはそれはあなたのせいではありません。 FPGA 自体またはベンダーのソフトウェアにバグがある可能性があります。これは、人々が FPGAのベンダーを非難する傾向があるよりもはるかに少ない頻度で発生しますが、まれに、これが実際に当てはまる場合があります。

他の誰かのせいにしたいという自然な誘惑があるため、自分自身に有利に働き、 FPGAのせいにしてエクソシズム セッションを締めくくらないでください。

これらのいずれも行わずに終了し、何とか問題を回避できた場合、後で再び問題に遭遇する可能性が高くなります。

FPGA 自体のバグについて私が持っている最良の例は、ずっと前の Xilinxの Virtex-4の hardware FIFO でした。つまり、 FIFO の control logic が silicon に直接実装された (つまり、 logic fabricには実装されていない) dual clock FIFO です。

その FIFO を通るデータ フローは、ときどきスタックしました。調査の結果、 FIFO はしばらくの間正常に動作した後、 empty 信号と full 信号の両方を同時にアクティブに保持していたことが判明しました。 FIFO が resetに保持されていない限り、これは不正な状態です。そのため、正しい信号を観測していることを完全に確認した後、バグがあるという結論でケースを閉じました

FPGAの FIFO。そして、代わりに logic fabric に実装されている FIFOs を選びました。

数か月後、これらの FIFOs に errata record が搭載されているのを見つけました。これは、事前に問題を知っていなければ理解できなかったでしょう。しかし、説明を注意深く読んだ後、それが私の観察を裏付けていると結論付けることができました.

これは、問題を「私のせいではない」と宣言する前に、 FPGAのバグがどれほど明白でなければならないかを示す例にすぎません。

概要

FPGA が自然の法則に逆らっているように見えるとき、常識から逸れた説明を採用したくなる。とはいえ、合理的な説明を探すことは重要です。この説明は、超能力を必要とせずに見つかることがよくあります。

ただし、その理由を突き止めるには、 designの徹底的なレビューが必要になる場合がありますが、これは必ずしも悪いことではありません。このような狩りはイライラするかもしれませんが、 designの品質に大きく貢献する可能性があります。

このページは英語から自動翻訳されています。 不明な点は元のページを参照してください。
Copyright © 2021-2024. All rights reserved. (b4b9813f)