Tech Blog
「動いているから大丈夫」と思っていませんか？RTLコード検証サービス 「RTL Valid™」その2
小野です！
よろしくお願いします！！
よろしくお願いします！！
こんにちは、小野です。
今回も、OKIアイディエスのRTLコードの品質を確保するRTLコード検証サービス 「RTL Valid™」をご紹介します。前回をまだご覧になっていない方はこちらをご覧ください。
小野君がいつも書いているブログ記事を読んだよ。修正のポイントがしっかり反映されているね。
はい。前回ボスに指摘された後、さらに3回ほど修正が入りました。多分今回のブログも色々指摘が入るんだろうなぁ…。チェックと修正ってめんどくさいですが、キチンとしたものを世の中に出すには避けては通れませんね。
チェックつながりで、前回のブログでは、RTLコード検証サービス「RTL Valid」で実施するLINT検証について解説したね。
実はまだ「RTL Valid」はLINT検証だけで終わらず、続きがあるんですよね。
それが「CDC検証」だよ。
そう、それです。今日はそれをやってみたいと思います。
CDC検証とは
LINT検証では、STARCルールに則り、コードの文法違反や構文エラーなどがないかを検証しました。それに対してCDC検証って何を検証するんですか？
CDC検証の“CDC”は“Clock Domain Crossing”の略。FPGA内部の部品、つまり論理ブロックやモジュールは、それぞれ異なる周波数（クロック）で動作しているんだ。ある部品が他の部品と同期するタイミングをクロックドメインと呼んでいるよ。複数のクロックドメイン間で信号が正しく転送されているかを確認するプロセスがCDC検証なんだ。
ふぅん。部品の役割や用途に応じて、クロックドメインを使い分けているってことですね。でも、部品ごとにクロックが違うとなると合わせるタイミングを考えるのが複雑になりそうです。だから、多くなればなるほど複雑になってエラーになることもあるんじゃないですか？
その通り。クロックドメインが異なる部分でデータや信号のやりとりをすると、やっぱりメタステーブル（一時的に不安定な状態に陥ること）になったり、データ化け、データ落ちといったエラーが起こりやすいんだ。そしてこれらは非常に見つけにくい。
そんな。どうして見つけづらいんですか？
実はランダムで発生することがあるんだよね。だからエラーを再現しづらいんだよ。
なるほど、ランダムだと厄介ですね。こうしたリスクは、設計段階でしっかりと未然に防ぎたいですね。そこで、CDC検証！というわけですね！！
CDC検証についてわかってもらえたところで、CDC検証にチャレンジだ！
CDC検証
さて、CDC検証のプロセスの紹介が今回の目玉だから張り切っていくよ。今回もまた、サンプルのRTLコードプロジェクトを用意したからこれで検証してみよっか。
よし、頑張るぞ！まずはRTLってフォルダを見てみます。これらが、今回CDC検証するRTLコードですね。
検証の前準備をしようか。プロジェクトにはVerilogで書かれたRTLコードとVHDLで書かれたRTLコードの2種類がある。CDC検証ツールに認識させるためには、まず“verilog_files.list”と“vhdl_files.list”の各ファイルに、検証対象のRTLコードのファイル名を相対パスで記述するんだ。
今回は、Verilogで書かれたRTLコードを使用するよ。
今回は、Verilogで書かれたRTLコードを使用するよ。
まずは言われた通りやってみます。
タイプミスしないようにな。（笑）次はCDC検証の設定・実行ファイルを用意する。cdc1.doというファイルとcdc2.doというファイルがある。
先にcdc1.doを編集しますね。へぇ、なるほど。FPGAのベンダーや合成ツールの情報が必要なんですね。他に編集が必要なものはありますか？
FPGAのトップモジュールの名前も入力しておこう。
ところで、トップモジュールってなんですか？
FPGAの核となる構成要素で、その中に多様な機能のモジュールを繋いで動作させるものだよ。モジュール同士の配線も、設計者の役割だね。
おっけー、できました。
次は、この開発用Linux PCで、QverifyというツールでいよいよCDC検証を実施するんだ。さっき作ったcdc1.doを実行してごらん。
はい、Enterキーをぽちっとな。お、動いたぞ。
うまくいっていれば、cdc_const.tclというファイルが生成されているはずだよ。これは次の手順で必要となるFPGAに入力される外部インターフェースや信号の情報が含まれたファイルだよ。ここが次のポイントだ！
内容を見ると、色々な信号の定義がされているようですね。
その通り。ここには、次のような信号の定義が書かれている。これを検証に向けてアレンジしていくんだ。
- Clock信号の定義
- Input信号の定義
- Output信号の定義
- InOut信号の定義
- Reset信号の定義
アレンジ…？せっかく自動で出力されたファイルなんだからこれをそのまま検証に使うことはできないんですか？
ここからがFPGA技術者の腕の見せどころなんだ！FPGAが搭載される装置や基板回路の仕様をしっかり理解していないと、正しく設定はできないんだ。だから、技術者が仕様に合わせてファイルを修正していく必要があるんだ。
そうなんですね。修正ができたので、cdc2.doを実行すると…。結果出てきましたよ。
LINT検証の時と同じように、CDC検証では次のような指摘が表示される。
- 「Violation」：CDC対策ができていないので修正が必要な箇所
- 「Caution」：場合によってはCDC対策が必要な箇所
- 「Evaluation」：CDC対策ができているので修正不要な箇所
また場合によっては修正が必要な箇所があるんですか。どうやって見極めているんですか？
動作の不具合の原因になるかどうかという視点で直していく。たとえば、「リコンバージェンス」という現象がある。これは、異なるクロックに属する信号が複数の独立した経路（複数の同期回路）を通って伝わった後、信号が遅延して同じクロックドメイン内で合流（論理演算や合成）してしまうというものなんだ。
それが信号のズレや不一致といった不具合の原因になるってことなんですか。じゃあ、遅延が大きい場合は、そうならないように対策しないといけないんですね。
その通り！逆に、同期化回路を通った後の信号の遅延差が十分に小さければ、「リコンバージェンス」は発生しない。つまり不具合として現れることはない。このように「Caution」判定の場合は、回路の使われ方や信号の送受信の仕方から、発生の有無を見極める必要があるんだ。
CDC検証レポート
CDC検証の結果をレポートにまとめていきます。「Violation」、「Caution」、「Evaluation」といった区分ごとに、さらにその内容を分類して整理するとこんな感じです。指摘の件数が今回も多いですね。
それぞれの指摘について、どんな内容なのかをこのようにまとめていくよ。また、下図のようにそれぞれ回路のどの部分での指摘なのかを図示して、OKIアイディエスの見解もあわせてまとめます。
図で示してくれると、どこが不足しているか、どこを修正すべきかがわかりやすいですね。問題箇所が明確なら、後はそれを修正するだけです！
ツール自体は修正が必要な箇所を教えてくれるけれど、具体的にどのように修正すべきかについては、提示してくれない。そこで、OKIアイディエスのFPGA技術者の開発の経験や知見をもとに修正案をまとめています。
LINT検証の結果と合わせて、RTLの問題点を「RTL Valid」1回で全て洗い出して修正をかければ、それだけで品質が大きく向上すること間違いなしだよ。
最後に
今回は「RTL Valid」というサービスを体験させてもらいました。LINT検証とCDC検証、それぞれの重要性がわかりました。
FPGAを実装した後の実機検証の工程で、不具合が検出されて対応する、ということが今でも実際の開発現場では多いんだ。でも、CDC検証で見つかる不具合はいくら正しいコーディングができていたとしても、コードを見ただけではわからないこともある。
後工程で不具合に気づいても、原因の切り分けが大変ですよね。長い時間がかかってしまうこともあります。だからこそ、RTLコードの論理合成や基板や装置としての評価の前にCDC検証を実施することが大切なのですね。
そういうことだ。「RTL Valid」のメリットをおさらいしよう。
- 自社で全バイオレーションを判定・改修方針決定する手間が不要
- 高度な業界標準（STARCルール）でのRTLコードの品質チェックを一括実施
- OKIアイディエスから検証レポートで適切な修正案を提示。ノウハウ共有で“属人化”を防止
- 後工程での不具合、トラブル予防とトラブル対応による納期遅延の防止
- 開発現場は本来業務（新機能実装や最適化）に集中可能
- RTLコードの設計品質の向上と検証レポートによる設計ナレッジの蓄積
RTLコードの文法間違いや構文エラーを抽出できるLINT検証。データ化け・データ消失やメタステーブル発生のリスクを洗い出しできるCDC検証。この2つの検証でRTLコードの品質を高めることができるんですね。
LINT検証やCDC検証は、FPGA開発における検証の一部なんだ。「RTL Valid」としてはこの2つの検証サービスを提供しているけど、必要な検証はこれですべてではないよ。
たとえば、カバレッジ検証やシミュレーション検証や実機検証など、様々な検証があるけど、また別の機会に紹介するね。
たとえば、カバレッジ検証やシミュレーション検証や実機検証など、様々な検証があるけど、また別の機会に紹介するね。
「動いているけど本当に大丈夫？」そんな不安を抱えている人だっているはず。設計品質を高めれば、余裕と安心が生まれるはずです。
そういえば先月から、RTL検証サービス「RTL Valid」 無償点検キャンペーンをやっているんだっけ。
はい。初回限定で、お客様からRTL設計データをお預かりし、LINT／CDC検証・一次診断・簡易レポートを無償で提供します。前回と今回のブログでご紹介したようなレポート形式で検証結果を報告しますよ。下記のページもぜひチェックしてください。
お問い合わせをお待ちしています！
次回のブログ更新は12月を予定しています。
お楽しみに！
お楽しみに！
- ※記載されている会社名、製品名は、各社の商標または登録商標です。
- ※ここに記載されている仕様、デザインなどは予告なしに変更する場合があります。
