まずは通常のコンパイル・フローをおさらい

下図は、通常 Quartus Prime が行うコンパイル・フローを示したものです。
主なプロセスは以下の4工程です。

このうち、Analysis & Synthesis（論理合成）と Fitter（配置配線）がコンパイラーのメイン作業です。

この2つの工程において、通常のデフォルト・コンパイルではプロジェクトの “すべてのデザイン” が実行の対象になります。

そのためプロジェクトに対して再コンパイルを要求すると、各モジュールはデザイン修正の有無やオプション設定の変更の有無に関係なく再コンパイルが実行されます。

どうして再コンパイルをするのか

ユーザーが再コンパイルをする理由には、このような状況にあることが考えられます。

• デザインの一部に変更があった（モジュールの追加・削除を含む）
• 制約に変更があった（ピンレイアウト、オプションなど）
• タイミングがメットできなかった →タイミングを収束させるため

再コンパイルに対してユーザーが持つ懸念点は？

再コンパイルと聞くと、このようにイメージしている人が大半ではないでしょうか。

「（大規模なデザインだから、また）コンパイル時間がかかってヤダな」
「タイミングがメットした部分がくずれちゃったらヤダな」

再コンパイルの際に、何も対策を取らずにデフォルトのままコンパイルを実行した場合、デザイン内のすべてのモジュールに対して論理合成と配置配線が再び行われます。つまり、変更のなかったモジュールにもコンパイルが実行され、この “二度手間” にも時間は消費されます。

また、デバイス内部のレイアウトが変更する可能性も増えます。

レイアウトが変更されてもユーザーの希望するタイミング要求を満足できる結果であれば良いのですが、レイアウト変更により、前回のコンパイルでタイミングが満たせていたブロックの一部がメットできなくなるなどのリスクも考えられます。

その不安、Quartus® Prime のインクリメンタル・コンパイルなら解消できます！

デザインや制約に変更のあった部分だけを再コンパイルするメソッドがあるんです。それが “インクリメンタル・コンパイル” です。
追加したデザインだけをコンパイルするので、既存デザインの再コンパイルに要する時間は削減されます。

しかも、既存デザインの前回のコンパイル（論理合成や配置配線）情報をそのまま再コンパイルに適用するので、論理合成の度にネットリスト名が変わってしまうとか、配置場所が変更したことでタイミングがメットしなくなるなどのリスクを軽減できるテクニックです。

では、この機能の概要を下記のページで見ていきましょう。（※ Arria® 10 ユーザーは、次項をご覧ください。）

インクリメンタル・コンパイルを使ってみよう

Arria 10 はインクリメンタル最適化機能

Arria 10 の場合には、Quartus Prime Pro Edition が提供する “インクリメンタル最適化機能（Incremental Optimization）” をご利用ください。名称が非常に似ていますのでご注意ください。

[参考: インクリメンタル最適化機能に関する情報]
早期配置ステージによるフルデザインの繰り返し回数の低減 （メーカーサイト）

無料オンライン・トレーニング（メーカーサイト）
Quartus® Prime プロ・エディションによるインクリメンタル最適化（英語版）