検証の方法

FPGAの検証方法は各社でまちまちです。
同じアプリケーション製品を作っている競合企業間でも検証方法は異なります。
隣の企業がどのような検証を行っているのかは分かりづらいですね。

例えば、A社は製品の歩留まりが低く、対象部品をメーカで解析しても良品判定がほとんど。不具合原因を不明のままにしていると、後から様々な不具合が起こります。
そして、幾つかの不具合を深く解析してみると、原因や対策は同じであることも多いです（不具合が起きたら、簡単には原因を認めずに、更に“なぜなに”を考えましょう）。
反対に、B社は製品の歩留まりが高く、仕様変更があっても開発期間が短く、スムーズな開発を行っていることがあります。

A社に聞く事は…

A社に対して、最初に聞くのは下記の３点です。
（1）自社でオリジナルの設計や検証フローを持っていますか？
（2）自社で設計や検証のルールを持っていますか？
（3）設計者と検証者は別の担当者ですか？

（1）と（2）を担当者やツール任せにしている企業は、設計者が移動すると不具合が起こるかもしれません。
自社でフローやルールを持っていても「見直し」を行っているかどうかも重要です。
たとえ、社内でレジェントと呼ばれる設計者が作ったゴールデン・フローやルールがあっても、数年経ったら見直しが必要です。
そして、設計と検証のフローやルールは、組織で管理しましょう。

（2）が重要なのは皆さんご存知ですが、国内では1人の担当者に任せていることも多いようです。
問題が起きなければラッキーですが、バグが見つかった際に設計者を責めるのは酷です。
ぜひ、海外の設計のように組織でカバーしていただければと思います。

設計者と検証者を別にした方が良い理由

設計者と検証者を別にした方が良い理由は下記です。

設計者は仕様を理解して「自分が思った通り」に動く回路を作ります。
逆に、検証者は設計者の「仕様の認識違い」や設計者が気づかない「想定外の動き」を見つけ出します。

このように設計と検証では考え方が逆なので、設計経験（失敗経験？）を多く持つベテラン設計者が検証を担い、
経験の浅い担当者が設計を担うように分担すると、チーム全体の技術レベルが向上します。
または、経験を多く持っている検証を専門とした業者に依頼してみる方法もあります。

どうしても、担当者を分けるのが困難なら、少なくともABV（アサーション・ベース検証）を使ったランダム検証にて、
「想定外の動き」を検証される事をお勧めします。