階層構造の記述方法
VHDL では他の回路をインスタンスとして呼び出して階層構造を構築することが出来ます。
ここではその記述の例を、次のような回路を呼び出す場合で、紹介します。
library ieee;
use ieee.std_logic_1164.all;
entity sub is
generic (
W : integer
);
port(
I : in std_logic_vector(W-1 downto 0);
O : out std_logic_vector(W-1 downto 0)
);
end sub;
component 宣言を使う方法
インスタンスとして呼び出す前に component 宣言しておきます。
library ieee;
use ieee.std_logic_1164.all;
entity main is
end main;
architecture model of main is
signal i : std_logic_vector(9 downto 0);
signal o : std_logic_vector(9 downto 0);
component sub
generic (
W : integer
);
port(
I : in std_logic_vector(W-1 downto 0);
O : out std_logic_vector(W-1 downto 0)
);
end component;
begin
u: sub generic map(W => 10) port map (I => i,O => o);
end model;
entity を使う方法
次のように entity を使って呼び出します。library名.entity名で指定する必要があります。
library ieee;
use ieee.std_logic_1164.all;
entity main is
end main;
architecture model of main is
signal i : std_logic_vector(9 downto 0);
signal o : std_logic_vector(9 downto 0);
begin
u: entity work.sub generic map(W => 10) port map (I => i,O => o);
end model;
それぞれの方法の特長
entity を使う方法の利点と注意点
entity を使う方法では、いちいち component 宣言をしなくても良いという利点があります。
ですが、entity を使う方法は処理系によってはファイルを読み込む順番に注意が必要な場合があります。
と言うのも、インスタンスとして呼び出す"前"に、対象となる entity 宣言をライブラリに取り込んでおく必要があるのです。
例えば、ghdl の場合、いきなり main2.vhd を読み込むと次のようなエラーが出ます。
$ ghdl -a --work=work main2.vhd
main2.vhd:9:20: primary unit "sub" not found in library "work"
エラーが出ないようにするには、sub.vhd を読み込んでから main2.vhd を読み込みます。
$ ghdl -a --work=work sub.vhd
$ ghdl -a --work=work main2.vhd
このように、entity を使うにはファイルを読み込む順番に気を使う必要があります。
同様の注意が必要な処理系には Mentor Graphics社の modelsim があります。
一方、このような注意が必要の無い処理系には、Xilinx 社の Vivado があります。
Vivado はプロジェクトにVHDLファイルを登録する際、軽くアナライズをして階層構造を認識します。
そのおかげか、適当な順番でファイルを登録しても、ちゃんとアナライズできます。
さらに、処理系の組み合わせにも注意が必要です。
例えば、プロジェクトは Vivado で作り、シミュレーションだけは modelsim を使うような場合です。
Vivado から modelsim を使う場合、Vivado は modelsim 用のスクリプトファイルを生成して modelsim にファイルを読み込ませます。
その際、そのファイルを読み込む順番によっては読み込み時にエラーが出ることがあります(経験談)。
component 宣言を使う方法の利点と欠点
component 宣言を使う場合は、entity を使う方法と違って、ファイルを読み込む順番に気を使う必要がありません。
ソースファイルが多くなればなるほど、ソースファイルを矛盾無く順番に読み込むのが難しくなります。
特にたくさんのチームでの大規模な開発やオープンソースなど外部のライブラリを使用する時は、component 宣言を使った方が良い場合があります。
component 宣言を使う方法の欠点は、何と言っても、いちいち component 宣言を記述しておく必要があることでしょう。
記述量が増えるばかりか、entity 宣言と component 宣言の2箇所でインターフェースを管理しなければならず、たいへん面倒です。