2

私は現在、2 回目または 3 回目の VHDL の学習段階に入っています。(今回は、非常に優れた無料の電子書籍で武装しています) そして、私はついにそのかなりの量を「取得」し始めています. 今、私は行動スタイルとプロセスステートメントについて学んでおり、そのほとんどは理にかなっています. ただし、特定の場合を除いてプロセスを回避する必要があることを多くの場所で読みました。つまり、理論的には、行動ではなくデータフローですべてを実装することはできないのでしょうか?

プロセス ステートメントを使用する必要があることを明確にする必要があるのは、正確にはいつですか?

4

3 に答える 3

7

プロセス ステートメントは非常に便利です。使用しないように言われたのはどのような状況ですか?

プロセス ステートメントを使用するケースはさまざまありますが、そのいくつかを以下に概説します。

process ステートメント (合成用) の最も一般的な使用法の 1 つは、クロック信号に同期するロジックを記述することです。

DATA_REGISTER : process(CLOCK)
begin
  if rising_edge(CLOCK) then
    if RESET = '1' then
      COUNTER <= (others => '0');
    else
      COUNTER <= COUNTER + 1; --COUNTER is assumed to be of type 'unsigned'
    end if;
  end if;
end process;

設計がより複雑になるにつれて、必然的にある時点でステート マシンを実装することになります。実装するステート マシンのスタイルに応じて、1 つまたは複数のプロセスが使用されます。

動作コードの場合、プロセスを待機ステートメントと組み合わせて使用​​して、テスト ベクトルを生成したり、実際のシステムの動作をモデル化したりできます。以下は、私のテストベンチの 1 つから取った 100MHz クロック ジェネレーターの非常に基本的な例です。

architecture BEH of ethernet_receive_tb is  
  signal  s_clock : std_logic := '0'; --Initial assignment to clock kicks off the process.
begin
  CLOCKGEN : process(s_clock)
  begin
    s_clock <= not s_clock after 5 NS;
  end process CLOCKGEN;

...

プロセスで非同期ロジックを記述することもできます。この場合、プロセスで読み取られるすべてのシグナルをセンシティビティ リストに含める必要があり、推論されたラッチを回避するために出力が常に定義されていることを確認する必要があります。

IF_ELSE: process (SEL, A, B)
begin
  F <= B; -- Default assignment
  if SEL = '1' then
    F <= A;
  end if;
end process;

process ステートメントが非常に便利で、さまざまな状況で使用できることを理解していただければ幸いです。これがあなたの質問に答えたことを願っています！

于 2012-04-19T15:59:02.093 に答える
4

Process blocks are your friend.

They provide a way of saying "This block of code is related. It's inputs are X,Y,Z and it drives A,B,C". The inputs are documented by the sensitivity list (unless it's a clocked process in which case it should be in your comments). If anything else drives the same signals then you'll get warnings, errors, X's in simulation (depending on your tools). Whatever you get it's pretty obvious.

Personally I would be quite happy writing multiple processes in a single entity, but everyone has their styles. For example, if I have multiple pipe-line stages, each stage is a process. If I have parallel non-interfering paths each will be in a separate process. By doing it this way the code is structured in small, easy to read blocks. Small simple logic synthesizes into small fast blocks (in general).

You could view my style as using them as lightweight entities.

于 2012-04-19T17:58:11.977 に答える
2

合成可能なコードでは、あるクロックサイクルから別のクロックサイクルまで情報を保持する必要があるときはいつでもプロセスが必要です。専門用語で「状態を保存する」。

（プロセスは、次のようなコードによって暗示される可能性があることに注意してください

d <= q when rising_edge(clk);

）。

合成できないコードの場合、プロセスはイベントを特定の順序で発生させるのに役立ちます。

p1: process
begin
   data <= "--------";
   WE <= '0';
   wait until reset = '1';
   wait until processor_initialised = '1';
   assert ACK = '0' report "ACK should be low!" severity error;
   data <= X"16";
   WE <= '1';
   wait until ACK = '1';
end process;

私のコードのほとんどは、エンティティごとに1つのプロセスを持っています。各エンティティは、いくつかの有用で明確に定義された、テスト可能な小さなタスクを実行します

于 2012-04-19T15:55:14.420 に答える