検証に関する不具合というのは、そもそもどういう括りをすれば良いか、そこから悩むものです。
重複するところもありますが、まぁ大きくはこの２つに分けれます。
・仕様不具合
・実装不具合
仕様不具合とは、仕様そのものの間違いです。「顧客要求VS製品仕様書」や「製品仕様書VS外部仕様書」で違いがある等ですね。実装不具合は、RTLの動作と仕様書で動作が異なる等です。不具合の分類をざっくり書くとこのようになります。
| 不具合分類 | 内容 |
|---|---|
| 仕様不具合 | 顧客要求と乖離 製品仕様と乖離 外部仕様と乖離 |
| 実装不具合 | 外部仕様と乖離 内部仕様との乖離 |
仕様不具合は次のようなものです。
顧客要求や製品仕様等の乖離
顧客要求から製品仕様に展開する際の間違いや、製品仕様から外部仕様に展開する際の間違いを指します。実機・FPGA・システム検証などで実際にアプリを動かすときに見つかります。もっと小規模な単位の検証でも、リファレンスを使うプロジェクトでは、リファレンスの作成段階でこの不具合に気づく事が割とあります。
外部仕様と乖離
外部仕様から内部仕様へ展開したときに発生した間違いを指します。ちなみに、この外部仕様とは内部（実装）仕様・検証仕様のベースとなる仕様の事です。システムが大きいほど外部仕様もシステム仕様、サブシステム仕様、モジュール仕様と段階がいくつもわかれます。
一方実装不具合については簡単に書くと下記です。
外部仕様と乖離
外部仕様と実装の動作の違いになります。
内部仕様と乖離
内部仕様と実装の動作の違いになります。
上記不具合の検証による検出状況により、そのプロジェクトが抱える問題が見えてきます。
・内部仕様（実装仕様とも呼ばれます）とRTL実装の間の不具合が多い場合
RTL実装担当者もしくは内部仕様作成担当者のどちらかのレベルが低い時に発生します。この不具合が頻繁に出ているプロジェクトでは実装に問題があることが分かります。ちなみに初期デバッグ時のバグは普通ここに含めません
一般的にRTL技術者が熟練してくるとこの不具合がほとんど出ないため、不具合検出が無くても、心配は無用です。White Box検証をしている場合、開発期間の関係上、内部仕様作成とRTL実装・検証が同時に進みますので、検証が終わった時には内部仕様、実装も同時に終わっています。その過程で不具合を検出しても即座にFeedbackがかかります。そのため、大体、報告にはあがってこないものです。
・外部仕様とRTL実装の間の不具合が多い場合
外部仕様の記述担当者もしくはRTL実装担当者のレベルが低いと発生します。これはRTL実装担当者が熟練しても、外部仕様の記述が曖昧等その内容に問題がある場合、この不具合が頻繁に発生します。
不具合が見つかるうちは、検証がよく機能している証拠となります。
外部仕様とRTL実装の間の不具合がみつからない場合は深刻な事態が起きている可能性があります。検証が機能していない可能性です。外部仕様をベースに検証する場合は、Black Box検証が原則になります。その場合RTL実装と内部仕様書は見てはいけないのが常識です。
しかし、リファレンスやアサーションを内部仕様書・もしくはRTL実装を元に作成している可能性があります。その場合、いくら検証しても不具合は見つかりません。そしてシステム検証・ソフトウェアのデバッグ等で見つかるケースが出てきます。最悪、製品での不具合発覚となる可能性があります。
・要求仕様・製品仕様とRTL実装の間の不具合が多い場合
外部仕様の不具合がほとんどのケースです。システム検証やFPGA検証で見つかるケースが多いです。システム検証やFPGA検証の目的自体が、ユースケースで動作しない不具合の検出なので、検証が機能している状況と言えます。より小規模なRTL検証でもリファレンスを使った検証では、リファレンス作成の際に、外部仕様のミスを見つけるケースが割とあります。外部仕様のミスを見つける検証技術者はレベルが高い人が多いです。一方、システム検証で初期バグが見つかるケースでは、大体検証品質が低いです。大半が、システム検証の前段階のより小規模な検証がほとんど機能していない証拠です。検証のレベルが低い事を示しており、そのプロジェクトでは、大体、製品になってからも不具合が残ります。
検証の格差の目安を、不具合のカテゴリーとその検出状況で記載してみました。まぁ何かの参考になればと思います。
（2018/10/29 記）
