現代の高度な SV RTL シミュレーターでは、パックされた配列と比べてアンパックされた配列を使用すると、シミュレーションのフットプリントが増加する可能性があるというのは本当ですか? もしそうなら、これは問題であり、検証チームはパックされた配列を使用するルールを主張しますか? ティア。サンジャイ
1 に答える
「アンパックされた配列とパックされた配列を使用すると、シミュレーションのフットプリントが増加する可能性がありますか?」
シミュレーターがメモリを割り当ててアクセスするかどうかによって異なります。ほとんどの場合、パックされた配列は、アンパックされた配列よりもメモリ フットプリントが小さくなります。通常、フットプリント サイズの違いは十分ではありません。シミュレータがメモリから配列にアクセスする場合、パックされた配列は配列全体を実行し、アンパックされた配列は一部にアクセスします。配列が大きく、一度に配列全体にアクセスする必要がない場合は、パックされていない配列の方がパフォーマンスが優れています。
「これは問題であり、設計チームはパックド配列を使用する設計ルールを主張していますか?」
シミュレータを実行しているマシンにシミュレーションを実行するのに十分なメモリがある場合、それは問題ではありません。それでも、メモリ フットプリントの制限は設計ルールであってはなりません。デザイン ルールは、品質、パフォーマンス、シリコン/FPGA の制限、および読みやすさに重点を置く必要があります。配列構造を調整することで実際のデザイン ルールを満たすことができる場合、メモリ フットプリントの削減は副次的なメリットです。
限られたシステム メモリ (または非常に長いシミュレーション時間) を扱う場合、テスト ベンチと合成不可能なモデルは別の話です。パックされた配列とアンパックされた配列のキャリブレーションは、調査すべき多くの要因の 1 つです。多くの商用シミュレータには、最良のシミュレーション結果を得るためのガイドラインに関するドキュメントが付属しています。
一般的なアレイのガイドライン:
- パックされた配列-合成可能- 配列全体のアルゴリズム操作にアクセスする場合に最適で、ビット選択と部分選択をサポートします ( LRM § 7.4.1)
- 例:
reg [31:0] packed_array;
- 例:
- アンパック配列-合成可能- 配列が巨大な場合、または各エントリに個別にアクセスする必要がある場合に最適 ( LRM § 7.4.2)
- 例
reg unpacked_array [31:0]; reg [31:0] unpacked_array_of_packed_arrays [15:0];
- 例
- 連想配列-合成可能ではありません- すべてのエントリへのアクセスが必要であり、シミュレーションでほとんどのエンティティにアクセスする可能性が低い場合に最適です ( LRM § 7.8)
- 例
int associative_wildkey [*]; logic [127:0] associative_keytype [int];
- 例
- キュー-合成不可- エントリ数が不明で、データ アクセスがパイプラインのような場合に最適 ( LRM § 7.10)
- 例
bit [7:0] queue [$];
- 例
- 動的配列-合成可能ではありません- その場で配列全体を作成する必要がある場合に最適です。配列を使用してシミュレーションが完了していない場合は、配列を削除することをお勧めします ( LRM § 7.5)
- 例
int dynamic_array[]; initial dynamic_array = new[8];
- 例
- ベクトル化されたネット- (シンセサイザーのマニュアルを確認してください) - パックされたエントリ全体にのみアクセスする場合に最適です。ビット選択と部分選択は許可されません (このため、メモリ フットプリントが小さくなる可能性があります)。ネットタイプに限定 ( LRM § 6.9.2)
- 例
wire vectored [7:0] vec;
- 例