vhdl
解決関数、未解決および解決型
サーチ…
前書き
VHDLタイプは未解決または解決できます。たとえば、 std.standard
パッケージによって宣言されたbit
タイプは、 std.standard
パッケージによって宣言されたstd_logic
タイプが解決されているieee.std_logic_1164
は解決されieee.std_logic_1164
。
タイプが解決されていない信号は、複数のVHDLプロセスによって駆動(割り当て)できませんが、タイプが解決された信号は解決できます。
備考
解決された型の使用は、複数のハードウェア回路によって駆動されるハードウェアワイヤ(またはワイヤセット)を実際にモデル化することが意図されている状況に予約する必要があります。必要とされる典型的な例は、メモリの双方向データバスである。メモリが書き込まれるとき、それはバスを駆動する書き込み装置であり、メモリが読み出されるときにはバスを駆動するメモリである。
他の状況で解決された型を使用すると、頻繁に遭遇する習慣の中で、望ましくない複数のドライブ状況が誤って作成されたときに非常に有用なコンパイルエラーが抑制されるため、悪い考えです。
ieee.numeric_std
パッケージsigned
、 unsigned
signed
およびunsigned
ベクトル型を宣言し、それらの算術演算子をオーバーロードします。これらの型は、同じデータに対して算術演算とビット単位演算が必要な場合によく使用されます。 unsigned
signed
およびunsigned
型は解決されます。以前のVHDL2008では、 ieee.numeric_std
とその型を使用しているため、誤った複数のドライブ状況によってコンパイルエラーが発生することはありませんでした。 VHDL2008は、新しいタイプの宣言を追加しますieee.numeric_std
: unresolved_signed
とunresolved_unsigned
(別名はu_signed
とu_unsigned
)。これらの新しいタイプは、複数のドライブ状況が望ましくないすべての場合に優先されるべきである。
タイプ「ビット」の同じ信号を駆動する2つのプロセス
以下のVHDLモデルは、2つの異なるプロセスから信号s
を駆動します。 s
の型はbit
であるため、未解決型ですが、これは許されません。
-- File md.vhd
entity md is
end entity md;
architecture arc of md is
signal s: bit;
begin
p1: process
begin
s <= '0';
wait;
end process p1;
p2: process
begin
s <= '0';
wait;
end process p2;
end architecture arc;
例えばGHDLを使ってコンパイル、精緻化、シミュレートしようとするとエラーが発生する:
ghdl -a md.vhd
ghdl -e md
./md
for signal: .md(arc).s
./md:error: several sources for unresolved signal
./md:error: error during elaboration
この例のように、すべてのドライバーが運転価値に同意しても、エラーは発生します。
解決関数
タイプが解決された信号には、関連する解像度機能があります 。これは、複数のVHDLプロセスによって駆動することができます。解決関数は、ドライバが新しい値を割り当てるたびに、結果の値を計算するために呼び出されます。
解決関数は、1つのパラメーターを取り、解決する型の値を返す純粋な関数です。このパラメータは、解決する型の要素の1次元で制約のない配列です。たとえば、タイプbit
場合、パラメータはbit_vector
タイプにすることができます。シミュレーション中、必要に応じて分解能関数が呼び出され、結果として得られる値を計算して多重駆動信号に適用します。すべてのソースによって駆動されるすべての値の配列が渡され、結果の値が返されます。
次のコードは、型の解決関数の宣言示すbit
有線のように振る舞うand
。また、タイプbit
解決されたサブタイプの宣言方法とその使用方法を示します。
-- File md.vhd
entity md is
end entity md;
architecture arc of md is
function and_resolve_bit(d: bit_vector) return bit is
variable r: bit := '1';
begin
for i in d'range loop
if d(i) = '0' then
r := '0';
end if;
end loop;
return r;
end function and_resolve_bit;
subtype res_bit is and_resolve_bit bit;
signal s: res_bit;
begin
p1: process
begin
s <= '0', '1' after 1 ns, '0' after 2 ns, '1' after 3 ns;
wait;
end process p1;
p2: process
begin
s <= '0', '1' after 2 ns;
wait;
end process p2;
p3: process(s)
begin
report bit'image(s); -- show value changes
end process p3;
end architecture arc;
例えばGHDLを使ってコンパイル、精緻化、シミュレートしてもエラーは発生しません:
ghdl -a md.vhd
ghdl -e md
./md
md.vhd:39:5:@0ms:(report note): '0'
md.vhd:39:5:@3ns:(report note): '1'
1ビット通信プロトコル
センサのような非常に簡単で低コストのハードウェアデバイスの中には、1ビット通信プロトコルを使用するものがあります。 1つの双方向データラインがデバイスを一種のマイクロコントローラに接続します。プルアップ抵抗によって頻繁にプルアップされます。通信装置は、情報を他の装置に送信するために、所定の期間、ラインをローに駆動する。下の図はこれを示しています:
この例は、 ieee.std_logic_1164.std_logic
解決型を使用してこれをモデル化する方法を示しています。
-- File md.vhd
library ieee;
use ieee.std_logic_1164.all;
entity one_bit_protocol is
end entity one_bit_protocol;
architecture arc of one_bit_protocol is
component uc is
port(
data_in: in std_ulogic;
set_low: out std_ulogic
);
end component uc;
component sensor is
port(
data_in: in std_ulogic;
set_low: out std_ulogic
);
end component sensor;
signal data: std_logic; -- The bi-directional data line
signal set_low_uc: std_ulogic;
signal set_low_sensor: std_ulogic;
begin
-- Micro-controller
uc0: uc port map(
data_in => data,
set_low => set_low_uc
);
-- Sensor
sensor0: sensor port map(
data_in => data,
set_low => set_low_sensor
);
data <= 'H'; -- Pull-up resistor
-- Micro-controller 3-states buffer
data <= '0' when set_low_uc = '1' else 'Z';
-- Sensor 3-states buffer
data <= '0' when set_low_sensor = '1' else 'Z';
end architecture arc;