0

私は現在 MUX を実装しています。これをテストするために、入力としてデータを適切に生成し、その出力を監視するためのジェネレーターとモニターを作成しました。

MUX は Avalon Streaming インターフェイスを入力および出力として使用するため、バック プレッシャもサポートされます。

私の質問はです。テスト ベンチは立ち下がりエッジで実行され、DUT と入力データは立ち上がりエッジで生成されます。入力クロックと入力データの両方がデルタ サイクル 0 で生成されます。ただし、DUT から返され、ジェネレータを制御するバック プレッシャ レディ信号はデルタ 3 に設定されています。発生器からの時間データ (デルタ 0) は有効で、DUT の準備は有効です (デルタ 3 の背圧信号)。

ここで、DUT 入力クロックを 1 ピコ秒でスキューすると、問題が修正されます。しかし、それは間違ったアプローチのように感じます。ここでの正しい設計原則は何ですか。?

クロックを 1 ps ずらすか、少なくとも 4 デルタ移動して、すべての信号が raise_edge の前に設定されていることを確認します。

また

生成したデータを移動して、DUT の出力準備完了信号に合わせますか?

また

テストベンチからテストベンチへの決定だけですか?

また、テスト ベンチのクロックはデルタ 0 で生成し、他のすべてのクロックはその後に生成する必要があると考えていました。

Riviera-proでシミュレーションしています

4

1 に答える 1

0

さまざまな選択肢があります:

i) すべてを同期させます。つまり、入力を駆動し、DUT が使用するのと同じクロックのエッジで出力をサンプリングします。結局、DUT は競合の問題に悩まされることはないので、クロッキング ストラテジをテストベンチに拡張するだけで、すべてがうまく機能します。RTL では、ゲートレベルではありません。したがって、ゲート レベルのシミュレーションを行っている場合 (そうするべきです)、この戦略は適切ではありません。

ii) テストベンチ内のすべてのクロックを、DUT が使用するクロックの反対側のエッジから外します。繰り返しますが、RTL では問題ありませんが、ゲート レベルで問題がないかどうかは、デザイン全体の遅延によって異なります。

iii) クロック エッジの直後に DUT への入力を駆動し、その直前に DUT 出力をサンプリングします。クロック エッジは、DUT が使用するエッジです。繰り返しますが、これは RTL では問題なく、ゲートレベルでも最も堅牢です。

iv) 各 DUT インターフェイスに現実的なタイミングを実装します。これは RTL とゲート レベルで機能するはずですが、ゲート レベルで機能しない場合は、テストベンチではなく DUT に問題があります。

于 2016-12-21T09:06:05.030 に答える