TLM HW 設計・検証

JEDA

OSCI TLM2.0には、１つの関数でアクセスするLT(Loosely Timed)とリクエスト、レスポンスと２つの関数に分けてアクセスする(Approximately timed)の２つの形式があります。LTは、時間を全く考慮しない場合、あるいは時間精度が多少ずれてもよい場合に使用します。一方、ATは、時間精度を向上させたい場合に使用します。

LTでは、transport関数内部にアドレスでコーダを記述します。様々なバスからのトランザクションによってレジスタのread/writeを行ないます。モデルの機能部分は、モデル内部にプロセスと呼ばれる自律動作を定義し、その中で動作させます。バスからあるレジスタにアクセスしたことによって、プロセスは起動され、動作します。この動作は それぞれのTLMモデルで自律して動作します。様々な部品が平行に動作することによってハードウエア的な問題を検証します。ATになるとトランザクションは、２つの関数に分かれ、数回交互にアクセスします。ATの動作は複雑なためATのモデル作成には時間がかかります。プラットホームベースの設計を始めるならまずはLTモデルだけで始めた方がよいでしょう。

作成したTLMモデルの検証は、様々な段階にわけて検証することができます。TLMモデルをあるアプリケーションから動作させる場合、ドライバと呼ばれるソフトウエアを作成します。ドライバは、read/writeの命令を複数回繰り返す ことによって、必要な機能を実現します。このようなソフトウエア制御に近い領域は、CPUモデル上にソフトウエアコードを記述することで検証していきます。

ハードウエアは、どのようなアクセスタイミングでも動作しなければなりません。微妙なアクセスタイミングを作り出す検証はバスに接続する部品を詳細な時間精度で様々にアクセスすることで検証します。

バスアクセスに対する問題を検証する時は、様々なバスの動作を再現し、バスのアクセス仕様に合っているかを検証するモデルで検証します。検証は、アプリケーションに関するもの、バスのトランザクションに関するもの、バスのアクセスタイミングに関するものと観点を分けると効率化できます。

検証は、パターンを生成し、アクセス結果を見るだけでなく、カバレッジと呼ばれる検証の指標を考えます。
カバレッジには、ラインカバレッジと機能カバレッジがあります。ラインカバレッジは、すべてのソースのラインが実行されたかどうかを示すものです。実行されていないラインがあれば、その部分は未検証あるいは冗長な記述と判断できます。もう１つのカバレッジは、ある関数、あるいは変数がどれだけ実行されたかを示します。たとえば検証によって、ある変数は、すべての値が出現したのなら、その変数についてはすべて調べていることになります。カバレッジは、最近、RTL検証で普及してきた考え方ですが、TLM設計検証にも導入し、できるだけ上位の段階でのテスト性を高めた方がよいでしょう。