問題タブ [cocotb]

Cocotb のEndian Swapper の例を拡張して、テスト対象デバイス (DUT) によって出力されたパッケージの内容もチェックできるようにしたいと考えています。提供されているコード例では、予想される出力を生成するmodel関数が、変更されていない入力トランザクションを予想される出力のリストに追加します。このリストは、スコアボードへのパラメータとして与えられます。

スコアボードがどのように機能するか、および関数がバイト スワップされたトランザクションをmodel追加しなかった理由を理解するために、DUT に設計エラーを導入しました。endian_swapper.vhdlの次のコード ブロック内

if最初の行の条件を次のように反転しただけです(byteswapping /= '0')。

テストベンチを再実行した後、テストが失敗すると予想していましたが、それでも成功します。

スコアボードの作成で比較機能が欠落しているようです:

の呼び出しには 3 番目のパラメーターが必要ですがadd_interface、このパラメーターは文書化されていません。

では、この比較関数を指定して、パッケージの内容もチェックするにはどうすればよいでしょうか?

シミュレーションに QuestaSim を使用し、 でテストベンチを実行しましたmake SIM=questa。また、実行の間にビルド ディレクトリをクリーンアップしました。

現在、Cocotb ベースの検証環境をセットアップしています。

私のシミュレーターには FLI (外国語インターフェース) がないため、VHDL を使用している場合、Cocotb で提供されているサンプルが私のケースでは機能しないことがわかりました。次のメッセージが表示されます。

エラー (抑制可能): (vsim-FLI-3155) このバージョンの ModelSim では FLI が有効になっていません。

(私は ModelSim の Altera Starter バージョンを持っていますが、実際には FLI は含まれていません)。

私が驚いたのは、この例が Verilog で動作することです。私の理解では、Verilog は FLI ではなく VPI を使用しています。

FLI の必要性が必須かどうか、また Cocotb でそれを有効にできる機能は何か教えてください。

もう 1 つの質問: トップが Verilog で、残りのデザインが VHDL の場合はどうなりますか? それはうまくいくはずですか？

Cocotb を検証環境としてセットアップしようとしています。便利な例を見てきましたが、進むべき方向がわかりません。

私のブロックは次のように見ることができます：

• 入力に ​​4 つのバス
• 入力として 1 つのクロックと 1 つのリセット
• 出力に 2 つのバス

出力は、入力信号の組み合わせおよび順次処理の結果です。

さらに先に進むのに欠けている部分は、(私が理解している限り) AvalonST に準拠していない入力バスと出力バスのモニターを正しく定義する方法です。

Cocotb で提供されている例を見ましたが、インスピレーションを得るのを妨げているのは、次のいずれかが提供されていることです。

• モニターがない (加算器など)
• AvalonST ドライバーを使用する (endianswapper など)

現時点での質問は次のとおりです。

• 平均的な例を見ると、その人が独自の を定義しているStreamBusMonitorことがわかります。私の理解では、同じことを行う必要があります (参照モデルにフィードするために 4 つの入力を監視するため)。私は正しいですか？
• StreamBusMonitor信号の名前が次の行でどのように一致するか
  dut_out = StreamBusMonitor(dut, "o", dut.clk)
  わかりません。しかし、「o」の目的と、StreamBusMonitor のどこで使用されているかがわかりません。誰かが私を助けることができますか？
• Cocotb の公式フォーラムは見つかりませんでした。Cocotb について、StackOverflow よりも公式に質問できる場所はありますか?

ご協力ありがとうございます。

デザイン用の Cocotb 検証環境のセットアップに成功しました。RTL (私の場合は VHDL) での動作に満足しています。

私のデザインはジェネリックを使用しており、テンプレートに従って、Python コードのいくつかの場所 (主に run_test とモデル) でこれらのジェネリックの値を取得しています:
my_generic = dut.GEN_NAME.value

残念ながら、これはゲート レベル シミュレーションの場合には機能しません。これは、合成済みデザインにジェネリックがないため、dut.GEN_NAME.value が存在しないためです。

シミュレーション フロー (Cocotb の makefile) からパラメーター/ジェネリック値を取得する方向にすべて移動する必要がありますか?

もしそうなら、そうする最もクリーンな方法は何ですか? 環境変数を使用していますか?

(ちなみに、この側面がシミュレーターに依存するとは思わなくても、私は Questa を使用しています...)

あなたの助けとアドバイスをありがとう...

cocotb v1.0 と ghdl 0.35-dev (llvm と gcc バックエンド) を使用しています。

最上位には、単純な for generate ステートメントが含まれています。

「dut.gen_pe[1]」を使用して、cocotb テストベンチで最初に生成されたモジュールにアクセスしようとしました。次のエラーが発生します。

dut をループすると、generate ステートメントから次のサブモジュールが検出されます。

残念ながら、有効な Python 構文ではないため、"dut.(1)" でそれらにアクセスすることはできません。

次に、cocotb/tests/test_cases/test_array からテスト配列 testcase を実行しようとしました:

ほとんどすべてのテストが失敗しています。

test_gen_loop の出力は次のとおりです。

それは私の設計でのエラーに似ています。したがって、モジュールの命名に問題があると思います。

有効なモジュール名を取得する方法、またはエラーを完全に修正する方法はありますか?

編集：最小限の例

フォルダ：/home/Programme/cocotb/examples/generate

/home/Programme/cocotb/examples/generate/hdl/top.vhd:

/home/Programme/cocotb/examples/generate/tests/top_cocotb.py:

/home/Programme/cocotb/examples/generate/tests/Makefile:

で実行した後、代わりにmakegpi-module 名がコンソールに出力されます。(1) ... (4)gen_pe(1) ... gen_pe(4)

アップデート：

gpi モジュール名は、最新バージョンの ghdl で修正されています。ただし、cocotb テスト配列のテストケースはまだ失敗しています。