1

動作中のバス機能モデルを編成し、一般的に使用される手順 (CPU サブルーチンのように見える) をパッケージにプッシュして、メインの CPU モデルから取り出したいのですが、行き詰まっています。

プロシージャは、パッケージにプッシュされている場合、ハードウェア ビットにアクセスできません。Verilog では、一般的に使用される手順をインクルード ファイルに入れ、特定のテスト スイートの必要に応じてそれらを CPU モデルにリンクします。

詳細:

シミュレーション テスト ベンチ用に、CPU の動作するバス機能モデルがあります。「ユーザー インターフェイス」レベルでは、「メイン」と呼ばれるプロセスが CPU モデル内で実行され、次のように定義済みの「命令セット」を呼び出します。

cpu_read(address, read_result);

cpu_write(address, write_data);

これらの呼び出しのグループを、次のようなより高いレベルの手順にまとめます

configure_communication_bus;

clear_all_packet_counters; 

次のレイヤーで、これらの汎用関数は、デザインのインターフェイス タイミングを認識しているよりハードウェア固有のバージョンを呼び出します。これらのプロシージャは、入力レコードと出力レコードを使用してハードウェア モジュール ポートに接続し、必要に応じて CPU バス信号を揺らします。

cpu_read 呼び出しhardware_cpu_read(cpu_input_record, cpu_output_record, address);

このようなもの:

procedure cpu_read (address : in std_logic_vector(15 downto 0);
                    read_result : out std_logic_vector(31 downto 0));
    begin
        hardware_cpu_read(cpu_input_record, cpu_output_record, address, read_result);
    end procedure;

およびは、cpu モデルの vhdl ファイルでタイプ nnn_record の信号として宣言されていますcpu_input_recordcpu_output_record

したがって、これはすべて機能していますが、これらのプロシージャはすべて cpu VHDL モジュール ファイルに格納され、すべてプロシージャ宣言セクションに格納されているため、すべてが同じスコープ内にあります。

チーム メンバーとモデルを共有する場合、チーム メンバーは独自のテスト サブルーチンを追加する必要があり、それらもすべてファイル内の同じ場所にあり、シミュレーション テスト コードは私のものと一緒に「メイン」プロセスに入る必要があります。 .

モデルの外部からさまざまなテストをリンクし、モデル固有の手順のみをモデル ファイルに保持したいと思います。

皮肉なことに、最下位レベルのハードウェア プロシージャをパッケージにプッシュし、それらのプロシージャを「メイン」プロセス内から呼び出すことはできますが、上位レベルのプロセスは、そのパッケージまたは他のパッケージに配置することはできません。cpu_read_recordおよびへのアクセスcpu_write_record

このコードをクリーンアップしてモジュール化する簡単な方法が必要だと思いますが、明らかに何かが欠けています。

ちなみに、コマンド インタープリターを作成し、テスト コードをビヘイビアー ROM にロードすることが正しい方法だとは思いません。Cプログラムを接続するためにシミュレータインターフェースと戦っているわけでもありませんが、故障してこれを試すかもしれません..

4

3 に答える 3

4

答えの簡単なスケッチ(あなたが尋ねていると思う質問に対して!:-)私はオフビームかもしれませんが...

BFM サブプログラムを再利用可能なパッケージに移動するには、実行スコープから独立している必要があります。これは通常、それぞれの長いパラメータ リストを意味します。そのため、テストベンチでそれらを使用すると、現在使用しているパラメーターなし (またはパラメーター ライト) のバージョンと比較して、すぐに退屈になります..

通常の回避策は、長いパラメーター リストを使用して BFM をパッケージに実装することです。

次に、すべてのパラメーターを明示的に提供するパッケージ バージョンを呼び出すだけのパラメーター ライト ローカル同等物 (ラッパー) を実行スコープに記述します。

これは単なるボイラープレートです。きれいではありませんが、BFM をパッケージに移動できます。これらのラッパーは、テストベンチ、その中のプロセス、またはそのプロセス内のサブプログラムに対してローカルにすることができます。

(パラメーターの型は整理のためのレコードにすることができます。これらはおそらく 3 番目のパッケージで宣言され、BFM、TB、およびテスト対象の合成可能なデバイス間で共有されます...)

オーバーロードのおかげで、ローカルと BFM パッケージのバージョンの間にあいまいさがなくなるため、実際のテストベンチは可能な限りシンプルなままです。

ラッパー関数の例:

function cpu_read(address : unsigned) return slv_32 is
begin
   return BFM_pack.cpu_read ( 
      address     => address,
      rd_data_bus => tb_rd_data_bus,
      wait        => tb_wait_signal,
      oe          => tb_mem_oe,
      -- ditto for all the signals constants variables it needs from the tb_ scope
      );
end cpu_read;
于 2013-09-12T21:03:56.527 に答える