目次
1. はじめに
このドキュメントはAIに読み込ませてコードを自動生成することを目標としています。
パイプライン回路の設計において、テストベンチは動作確認とデバッグの重要な要素です。本ドキュメントでは、パイプライン回路の動作を確実に検証するためのテストベンチ設計手法について説明します。
パイプライン回路のテストでは、以下の点が重要です：
- Ready/Validハンドシェイクの動作確認
- ストール動作の検証
- バブル動作の検証
- データの整合性確認
2. テストベンチの設計方針
2.1 テスト記述の構成
テスト回路は以下の構成で実装されます：
-
テストパターン生成回路
上流側からテストパターンを流し込む回路 -
下流側Ready制御回路
最も下流のReady信号をランダムに制御してストールを発生させる回路 -
テスト結果確認回路
下流の回路を模擬しかつ流れてきたデータを確認する回路 -
シーケンス確認回路
Ready、Valid、Dataのシーケンス異常をチェックする回路
2.2 テストパターン生成回路
- Dataと入力するDataの数はパラメータ指定とします。
- Dataは0から始まって指定された数までインクリメントするデータを順番に流すものとします。
- Dataと次のデータの間にランダムにバブルが入ります。バブルの期間のValidはL、データは不定とします。バブルのサイクル数は0~3の乱数とします。0の頻度を高くしたいので、-N~3の乱数を発生させて0未満の時は0とします。Nはパラメータとします。まずこのデータとValidを配列の初期値として用意します。配列の全体の長さはデータの個数+バブルの合計個数となります。配列はSystemVerilogの記述を使ってください。
- 先の配列で用意したデータをReadyの状態にしたがって流します。ひとつづ出力します。ReadyがLになると、データをホールドして次のサイクルの値が現在のサイクルの値と同じになります。
- 期待値データは有効データのみを配列に格納し、バブルは含めません。
2.3 下流側Ready制御回路
- 最も下流のReadyをランダムにネゲートしてストールさせます。ストールのサイクル数は0~3の乱数とします。0の頻度を高くしたいので、-N~3の乱数を発生させて0未満の時は0とします。Nはパラメータとします。
- リセット解除後5クロック間はReadyをLに保持します。
2.4 テスト結果確認回路
- ReadyがHかつValidがHの時が有効なデータです。上流側から流したデータが最下流で同じか確認します。
- 期待値は配列から取得し、テストカウントが最大値に達したら成功メッセージを表示してシミュレーションを終了します。
2.5 シーケンス確認回路
- ReadyがLの場合その次のサイクルのデータの値が同じになっているか確認します。
- ReadyがHかつValidがHの時にデータに不定値が無いことを確認します
- この回路を２つ用意して、上流側のpipeline_insertの入力と下流側のpipeline_insertの出力のシーケンス確認を行います
2.6 デルタ遅延問題の回避
シミュレーションにおいて、複数のinitial文で信号の生成とチェックを行った場合、デルタ遅延と呼ばれる問題が発生することがあります。これは、同じシミュレーション時間内での信号の変化順序が不定になることで、予期しない動作を引き起こす原因となります。
この問題を回避するため、以下の設計方針を採用しています：
-
信号出力の
always文使用: 信号を出力する記述にはalways文を使用し、initial文での信号出力を避けています。 -
配列初期化以外の分離: 配列の初期化以外は、同じ信号の値を別の
initial文や別のalways文で値の代入を行わないようにしています。 -
モジュール化された制御: 各機能（クロック生成、リセット生成、テストパターン生成、Ready制御、結果チェック）を独立した
initial文やalways文に分離し、信号の競合を防いでいます。
この設計により、シミュレーションの再現性が向上し、デバッグが容易になります。
2.7 その他
- クロックは10nsサイクル100MHzとします。
- リセットは5クロックとします
- DUT(Design Under Test)はパイプラインの上流から下流にpipeline_insert->pipeline->pipeline_insertの接続とします。
- テストでエラーを見つけた場合はエラーの箇所から1クロック実行して停止しします
- エラー発生時は時刻と信号名を表示し、ストールエラーの場合は期待値と実際の値を表示します。
3. コード
コード: pipeline_tb.sv
4. 実行用スクリプトの生成
シミュレータのコンパイル・実行スクリプトは以下のように指示して自動生成させます
modelsim用にコンパイルと実行を行うスクリプトを作成してください。スクリプト名はテストベンチ名に合わせます。
5. デルタ遅延
5.1 デルタ遅延とは
デルタ遅延（Delta Delay）で発生する問題の解析は人もAIも苦手とするところです。デルタ遅延は、Verilog/SystemVerilogシミュレーションにおいて、同じシミュレーション時間内で複数の信号変化が発生する際の同一時刻での代入順序が不定になる問題です。複数のinitial文で'='によるブロッキング代入を行った場合、シミュレータがどちらのinitial文から実行するかは事前に特定できません。この問題は、テストベンチの設計において予期しない動作を引き起こす原因となり、シミュレーションの再現性を損なう可能性があります。そのため、最初からルールで問題が発生しないようにしておく必要があります。
5.2 回避方法
デルタ遅延問題は、テストベンチの設計において重要な考慮事項です。以下の原則に従うことで、この問題を効果的に回避できます：
- 信号出力には
always文を使用 - 非ブロッキング代入（<=）を活用
- テストベンチを機能別に構造化
- 信号の変化を段階的に行う
- シミュレーション結果の再現性を確認
ライセンス
Licensed under the Apache License, Version 2.0 - see LICENSE file for details.