2. 階層およびチーム・ベース・デザインのためのQuartus II ......2–2 Altera...

Altera Corporation 2–12008年 5月

この資料は英語版を翻訳したもので、内容に相違が生じる場合には原文を優先します。こちらの日本語版は参考用としてご利用ください。設計の際には、最新の英語版で内容をご確認ください。

2. 階層およびチーム・ベース・デザインのためのQuartus IIインクリメンタル・コンパイル

概要今日の高集積、高性能 FPGAデザインでは、デザイン・ステージおよびデバッグ・ステージにおける迅速なイタレーション能力が不可欠です。Quartus® II ソフトウェアは、高集積 FPGA のデザインを作成する先進のテクノロジを提供します。アルテラは、FPGA 業界で初めて、真のインクリメンタル・デザインおよびコンパイル・フローを導入し、以下のような利点をもたらしました。

■ デザインでロジックを変更するとき、変更されないロジックのコンパイル結果と性能を維持します。

■ デザインのイタレーション時間を最大70%短縮し、これによって1日あたりのデザインのイタレーション回数を増やし、タイミング・クロージャをより効率的に達成できます。

■ グラフィック・ユーザー・インタフェース（GUI）により使いやすさを提供。

■ Tclスクリプト、コマンドライン、makefileサポートが含まれます。■ サードパーティ合成ソフトウェアのインクリメンタル・シンセシス・フローと統合。

■ トップダウンまたはボトムアップ手法を使用し、モジュラー階層ベースおよびチーム・ベースのデザイン・フローを容易にします。

■ Arria™ GXデバイス、Stratix®およびCyclone®シリーズ・デバイスをサポート。HardCopy® II デバイスのインクリメンタル・コンパイル・フローを一部サポート（詳細は 2–88ページの「HardCopyコンパイル・フローおよび移行フロー」を参照）。

Quartus II ソフトウェアのインクリメンタル・コンパイルは、オプションのコンパイル・フローです。2–3ページの「Quartus IIコンパイル・フローの選択」に、インクリメンタル・コンパイルがある場合とない場合の Quartus IIデザイン・フローの概要を説明します。これにより、プロジェクトでこの機能を使用するかどうかを判断することができます。この章にはその他に、以下の項があります。

■ 2–11ページの「クイック・スタート・ガイド—インクリメンタル・コンパイル・フローのステップの概要」

■ 2–19ページの「デザイン・パーティションの選択および作成」、サードパーティ合成ツールとの統合を含み、Quartus II Design PartitionPlannerを使用。

■ 2–28ページの「デザイン・パーティションの Netlist Typeの設定」■ 2–38ページの「LogicLockロケーション・アサインメントによるデザイン・フロアプランの作成」

QII51015-8.0.0

2–2 Altera Corporation2008年 5月

Quartus IIハンドブック Volume 1

■ 2–43ページの「ボトムアップ・デザイン・フローのためのパーティションのエクスポートとインポート」

■ 2–61ページの「Incremental Compilation Advisor」■ 2–63ページの「推奨されるデザイン・フローおよびコンパイルのアプリケーション例」

■ 2–80ページの「インクリメンタル・コンパイルの制約」■ 2–107ページの「スクリプトのサポート」

インクリメンタル・コンパイルを活用するには、デザインを合成とフィッティングのためのロジカル・パーティション（およびオプションでフィジカル領域）に編成します。インクリメンタル・コンパイルでは、デザインで変更されていないパーティションのコンパイル結果と性能が維持され、新しいコンパイルを変更されたデザイン・パーティションにのみ集中させることによって、デザインのイタレーション時間を大幅に短縮します。新しいコンパイル結果は、変更されていないデザイン・パーティションの前のコンパイル結果と併合されます。さらに、フィジカル・シンセシスなどの最適化手法のターゲットを特定のデザイン・パーティションに絞り、他のパーティションは変更しないでおくことも可能です。

インクリメンタル・コンパイルは、1 人の設計者がデザインのプロジェクトを管理するトップダウン・デザインおよび各デザイン・ブロックを独立して開発可能なボトムアップの 2つのデザイン手法とそれらの組み合わせをサポートします。ボトムアップ手法には、デザイン・パーティションが別の場所のチーム・メンバ、またはサードパーティ IP（Intellectual Property）プロバイダによって作成されるチーム・ベースのデザイン・フローも含まれます。ボトムアップ・フローの場合、別のQuartus II プロジェクトでコンパイルされた下位レベルのデザイン・ブロックに制約を渡すスクリプトを、トップレベルのデザインから生成できます。

この章では、以下の目標を達成するための情報を提供します。

■ インクリメンタル・コンパイルを使用すべきかどうか判断できるように、Quartus IIコンパイル・フローの概要を説明します。

■ クイック・スタート・ガイドと詳細な情報を提供して、Quartus IIインクリメンタル・コンパイル機能の使用方法について説明します。

■ デザインのイタレーションをスピード・アップしながら、タイミング・クロージャを達成するための適切なデザイン決定に必要な知識レベルを提供します。

■ インクリメンタル・コンパイルに推奨されるいくつかのデザイン・フローをサンプル形式で提示し、同時にそれらの根拠とタスクの実行に必要なステップについて説明します。● 2–64ページの「1つのパーティションに対するソース・ファイル変更時のコンパイル時間の短縮」

● 2–67ページの「タイミング・クリティカルなパーティションの配置を最適化する」


Quartus IIコンパイル・フローの選択

● 2–65ページの「他のパーティションを追加する前に一部のパーティションの結果を維持する」

● 2–69ページの「チーム・ベースのボトムアップ・デザイン・フローの実行」

● 2–74ページの「ボトムアップ・デザイン・フローでのデザインのイタレーションの実行」

● 2–75ページの「IP再利用のためのハード・ワイヤード・マクロの作成」


Quartus II インクリメンタル・コンパイルは、以前のコンパイルで得られた満足な結果を再利用し、コンパイル時間を短縮することで、標準のQuartus IIデザイン・フローを機能強化します。この項では、デザイン・パーティションを含まないフラット・コンパイル・フローとインクリメンタル・フローを概説し、その違いについて説明します。また、コンパイル・フローで満足できる場合を説明し、デザイン・パーティションの作成やインクリメンタル・フローの使用が必要になる理由をいくつか説明します。

Quartus II ソフトウェアでは、フル・インクリメンタル・コンパイル・オプションはデフォルトでオンになっているため、プロジェクトではインクリメンタル・コンパイルのためのデザイン・パーティションをすぐに作成できます。デザイン・パーティションを作成しない場合、ソフトウェアはフラット・コンパイル・フローを使用します。



デザイン・パーティションを含まないフラット・コンパイル・フロー図 2–1に、デザイン・パーティションを含まないコンパイル・フローを示します。

図 2–1.デザイン・パーティションを含まないQuartus IIコンパイル・フロー

図 2–1の注 :(1) サードパーティ EDA合成ツールで作成された EDIFまたは VQMネットリストを使用

する場合、Analysis & Synthesisがデザイン・データベースを作成しますが、ブラック・ボックスとアルテラ・メガファンクションに対してのみロジック合成およびテクノロジ・マッピングが実行されます。

デフォルトのフラット・コンパイル・フローでは、ソース・コードはすべて Analysis & Synthesisモジュールで処理され、デザインの一部が変更された後でリコンパイルされるたびに、すべてのロジックが Fitter モ

FitterPlace-and-Route

VerilogHDL(.v)

VHDL(.vhd)

AHDL(.tdf)

BlockDesign

File(.bdf)

EDIFNetlist(.edf)

VQMNetlist(.vqm)

Analysis & SynthesisSettings &

Assignments

Post-Fit Netlist

Post-SynthesisNetlist

Assembler

Settings & Assignments

Make Design & AssignmentModifications

Timing Analyzer

RequirementsSatisfied?

Yes

No

Program/Configure Device

(1)



ジュールによって配置配線されます。この動作の理由の一つは、最適な品質の結果を得ることです。コンパイラはデザイン全体を処理することによって、グローバルな最適化を実行し、面積および性能を改善することができます。

プッシュ・ボタン式コンパイルによりタイミング要件を容易に満たすことができる場合は、CPLDデバイスまたは低集積度 FPGAデバイスでのデザインなど、小さなデザインに対してフラット・コンパイル・フローを使用することができます。コンパイル時間およびタイミング・クロージャの結果の維持が問題でない場合、フラット・デザインは満足できるものです。

Quartus IIのスマート・コンパイル

Quartus II ソフトウェアにはスマート・コンパイルと呼ばれる機能もあります。スマート・コンパイルをインクリメンタル・コンパイルと混同しないでください。Quartus II コンパイル・フローでは、スマート・コンパイルを使用できます。これによって、コンパイラは、最後のスマート・コンパイルの後でデザインに対して行われた変更に基づき、どのコンパイラ・ステージが必要かを判断し、不要なステージをスキップすることができます。例えば、スマート・コンパイルがオンのとき、デザイン・ソース・ファイルが変更されていない場合、コンパイラは Analysis& Synthesis モジュールをスキップします。スマート・コンパイルがスキップできるのは、全体のコンパイラ・ステージのみです。スマート・コンパイルは、コンパイル・フローのステージ内ではインクリメンタル変更を実行できないため、インクリメンタル・デザイン・フローとはみなされません。スマート・コンパイラをオンにするには、Assignmentsメニューの Settingsをクリックします。Categoryリストの CompilationProcess Settingsを選択し、Use Smart Compilationをクリックします。

デザイン・パーティションを含むインクリメンタル・コンパイル・フロー単純なフラット・コンパイル・フローよりもインクリメンタル・コンパイル・フローの使用が好ましい状況が数多くあります。デザインでロジックを変更するとき、インクリメンタル・フローを使用することによって、変更されないロジックの結果と性能を維持することができます。デザインのイタレーション時間を最大 70%短縮し、これによって 1日あたりのデザインのイタレーション回数を増やし、タイミング・クロージャをより効率的に達成できます。大規模なデザイン、高集積デバイス、およびデバイス・アーキテクチャの速度に対して高性能が要求されるデザインでは、インクリメンタル・コンパイルが推奨されます。この機能によりチーム・ベースのデザイン環境も容易に実現でき、設計者はデザイン・ブロックを独立して作成および最適化することができます。



前の項で説明しているように、従来の FPGAデザインでは、ロジック合成とフィッティングの前に階層構造デザインがフラット化されて 1つのネットリストになり、デザインが変更されるたびにデザイン全体がリコンパイルされます。Quartus II インクリメンタル・コンパイル・フローを使用するには、デザインをその階層境界に沿ってデザイン・パーティションと呼ばれるブロックに分割します。詳細は、2–19ページの「デザイン・パーティションの選択および作成」を参照してください。Quartus II ソフトウェアは、階層構造デザインの個々のパーティションを個別に合成し、ついでコンパイル・フローの以降のステージで、パーティションを完全なネットリストにマージします。デザインをリコンパイルするときに、パーティションごとにソース・コード、合成後の結果、またはフィッティング後の結果を使用できます。Fitter の結果を維持する場合は、Fitter のネットリストのみを維持、配置結果を維持、配置と配線の両方の結果を維持することができます。

デザインのほとんどの部分でそれ以上改善する必要がなく、特定の 1つのブロックを変更または最適化する場合は、デザイン・サイクルの後の方でインクリメンタル・コンパイルを使用できます。この場合、変更されていないモジュールの性能を維持し、以降の繰り返しに要するコンパイル時間を短縮することができます。インクリメンタル・コンパイルが、コンパイル時間の短縮とタイミング・クロージャの達成のいずれにも有効な状況もあります。例えば、以降のインクリメンタル・コンパイルで維持する必要があるパーティションを指定し、高度な最適化を有効にした状態で他のパーティションをリコンパイルすることができます。

デザインの一部を未完了にしておき、完了済みパーティションをコンパイルしながら空パーティションを作成し、デザインの新しい部分を作業しながら完了したパーティションの結果を保存することもできます。あるいは、別々の設計者や IP プロバイダがチーム・ベース手法を使用して、デザインの異なるブロックで作業して、それらをボトムアップ・コンパイル・フローで結合することができます。これらの場合、Fitter は各パーティションの配置と配線を個別に実行することができます。インクリメンタル・コンパイル機能を活用する場合に推奨されるデザイン・フローの詳細な例については 2–63 ページの「推奨されるデザイン・フローおよびコンパイルのアプリケーション例」を参照してください。

デザイン・フローの任意のポイントでインクリメンタル・コンパイル機能を使用する場合、デザイン開発の当初からインクリメンタル・コンパイルを計画する必要があります。デザイン・サイクルの初めから計画する場合は、フロアプランの分割および作成についてのガイドラインへの対応が容易になります。

詳細は、「Quartus II ハンドブック Volume 1」の「Best Practices forIncremental Compilation Partitions and Floorplan Assignments」を参照してください。

http://www.altera.com/literature/hb/qts/qts_qii51017.pdf




図 2–2に、インクリメンタル・コンパイルを使用した、デザイン・パーティションを含むQuartus IIデザイン・フローのブロック図を示します。

図 2–2.インクリメンタル・コンパイルを使用したQuartus IIデザイン・フロー

図 2–2の注 :(1) サードパーティEDA合成ツールで作成された EDIFまたは VQMネットリストを

使用する場合、Analysis & Synthesisがデザイン・データベースを作成しますが、ブラック・ボックスとアルテラ・メガファンクションに対してのみロジック合成

VerilogHDL(.v)

VHDL(.vhd)

AHDL(.tdf)

BlockDesign File

(.bdf)

EDIFNetlist(.edf)

VQMNetlist(.vqm)

Analysis & SynthesisSynthesize Changed Partitions,

Preserve Others

Partition MergeCreate Complete Netlist Using Appropriate Source Netlists for Each

Partition (Post-Fit, Post-Synthesis, or Imported Netlist)

Single Netlist forComplete Design

One Post-FitNetlist perPartition

One Post-SynthesisNetlist per Partition

Single Post-Fit Netlist for Complete Design

FitterPlace-and-Route Changed Partitions,

Preserve Others

Create Individual Netlists andComplete Netlists

Assembler


Make Design &Assignment Modifications


Design Partition Assignments

FloorplanLocation

Assignments

Timing Analyzer

RequirementsSatisfied?

Yes

No

Program/Configure Device

Partition Top

Partition 1

Partition 2

(1)



およびテクノロジ・マッピングが実行されます。

図 2–2の図では、トップレベルのパーティションと、下位レベルの 2つのパーティションを示しています。デザインの一部が変更された場合、Analysis and Synthesisは変更されたパーティションを処理し、未変更のパーティションのために既存のネットリストを維持します。Analysisand Synthesisのコンパイル後は、パーティションごとに合成後のネットリストが 1つあります。

パーティション・マージ・ステップでは、各パーティションに指定したネットリスト・タイプに応じて、合成後のネットリスト、フィッティング後のネットリスト、および下位レベルのプロジェクトからインポートされたネットリストで構成される完全なネットリストが 1つ作成されます。

次にFitterはマージされたネットリストを処理し、未変更のパーティションの配置または配置配線を維持し、変更されたパーティションのみを再フィッティングします。Fitter は、タイミング解析およびプログラミング・ファイル生成など、コンパイル・フローの後のステージで使用するための完全なネットリストを生成します。また、各パーティションに対して個別のネットリストも生成します。これによって、以降のコンパイルでパーティションの配置配線を指定する場合は、パーティション・マージ・ステップでフィッティング後のネットリストを使用してこの配置配線を維持できます。

デザインがその要件（機能、タイミング、エリア）に適合しない場合、デザインを変更しリコンパイルできます。Quartus II ソフトウェアは、合成後またはフィッティング後のネットリストの使用を指定するネットリスト・タイプのアサインメントを持つ未変更のパーティションについては、それぞれ再合成または再フィッティングは行いません。

インクリメンタル・コンパイル機能の使用について詳しくは、2–11ページの「クイック・スタート・ガイド—インクリメンタル・コンパイル・フローのステップの概要」を参照してください。



表 2–1に、インクリメンタル・コンパイルがコンパイル結果に及ぼす影響の要約を示します。

トップダウンとボトムアップのコンパイル・フローQuartus II のインクリメンタル・コンパイル機能は、トップダウンとボトムアップ両方のコンパイル・フローをサポートします。

トップダウン・コンパイルでは、1 人の設計者がソフトウェアのデザイン全体をコンパイルします。デザインの残りの部分を追加する前に、トップダウン・フローを使用して、デザインの全ブロックをまとめて最適化するか、あるいは 1つまたは複数のクリティカルなデザイン・ブロックまたは IPコアを最適化できます。デザインの他の部分は変化しますが、完了したブロックのフィッティング結果および性能を維持することができ、各デザインのイタレーションのためのコンパイル時間も短縮されます。複数の設計者または IPプロバイダが、HDLコードを別々に作成および検証できますが、一人（一般的にはプロジェクト・リーダーまたはシステム設計者）が 1つのトップレベル・プロジェクトとしてデザインをコンパイルおよび最適化します。

ボトムアップ・デザイン・フローにより、個々の設計者または IPプロバイダは個別のプロジェクトでのそれぞれのデザインの最適化を完了し、下位レベルの各プロジェクトを 1つのトップレベルのプロジェクトに統合できます。インクリメンタル・コンパイルには、このような設計手法を可能にするエクスポート機能とインポート機能があります。下位レベル・ブロックの設計者は、LogicLock 領域などの一連のアサインメントとともに、自分のデザインのために最適化した配置配線ネットリストを

表 2–1.フル・インクリメンタル・コンパイルの影響の要約

特性フル・インクリメンタル・コンパイルの影響

コンパイル時間の節約

フィッティング後のネットリストが維持される場合は、通常コンパイル時間の 50-70% を節約。Quartus IIの統合された合成と Fitterの両方で節約可能。

性能維持未変更のパーティションについてはフィッティング後の情報を維持できるため、1つのパーティション内に複数のクリティカル・パスが含まれる場合は優れた性能維持が可能。

ノード名の維持未変更パーティションのフィッティング後ノード名を維持。

エリアの変化境界間最適化の実行が不可能であり、配置とレジスタ・パッキングが制限されるため、場合によってエリア（ロジック・リソース使用率）が増加。

fM A X の変化境界間最適化は不可能なため、場合によりデザインの最大周波数が減少。デザインが適切に分割され、フロアプランのロケーション・アサインメントが適切に作成されている場合、fM A X への悪影響はない。

フロアプランの作成

デザインを変更するとき、結果の最高品質を保証するためにクリティカル・パーティションに推奨。配置衝突を回避するためにボトムアップ・フローで必要。



エクスポートできます。次に、プロジェクト・リーダーはトップレベル・プロジェクトで、各デザイン・ブロックをデザイン・パーティションとしてインポートします。

ボトムアップ・デザイン・フローでは、以下の 2つの利点が得られます。

■ チーム・ベースの開発が容易になります。■ 性能の維持およびコンパイル時間の短縮を最終目標として、別のプロジェクトのコンパイル結果を再利用できます。

ボトムアップ・デザイン・フローには、計画の際に注意が必要な以下の潜在的な欠点もあります。

■ 完全なデザインのタイミング・クロージャを達成するのが困難な場合があります。これは下位レベルのブロックを互いに関する情報なしで個別にコンパイルするためです。この問題は、入念なタイミング・バジェットの作成により、またモジュール境界で必ずポートを登録するなどの特別なデザイン・ルールによって回避することができます。

■ 同じ理由で、リソースの衝突および過剰な使用を回避するのに、リソース・バジェットとリソース割り当てが必要になる場合があります。フロアプランの作成は、通常はボトムアップ・フローで非常に重要です。

ボトムアップ・デザイン・フローでは、トップレベルのプロジェクト・リーダーはデザイン計画の大部分を行ってから下位レベル・ブロックの設計者に制約を渡すことができます。エクスポート操作とインポート操作、およびデザイン・プランニングを支援するためのデザイン・パーティション・スクリプトの使用方法について詳しくは、2–43ページの「ボトムアップ・デザイン・フローのためのパーティションのエクスポートとインポート」を参照してください。

フル・インクリメンタル・コンパイル・フローを使用するときは、性能の維持という理由だけで、これまでボトムアップ手法に依存してきたユーザーが、トップダウン手法を採用しても同じ目標を達成することができます。この能力は以下の 2つの理由により重要です。

■ トップダウン・フローは、一般にボトムアップ・フローを実行するよりも簡単です。例えば、下位レベルのデザインをエクスポートおよびインポートする必要はありません。

■ トップダウン手法では、配置配線のグローバルな最適化の実行のために、デザイン全体に関する情報がデザイン・ソフトウェアに提供されます。したがって、ボトムアップ・フローよりもトップダウン・フローを使用したほうが、優れた結果の品質を得やすい場合がよくあります。


クイック・スタート・ガイド—インクリメンタル・コンパイル・フローのステップの概要

Quartus IIインクリメンタル・コンパイル機能は、非常に柔軟性が高く、多くのデザイン手法をサポートします。1つのプロジェクトの中でトップダウン手法とボトムアップ手法を併用することができます。トップレベル・デザインに別の設計者または IPプロバイダが最適化した 1つまたは複数のデザイン・ブロックが含まれている場合、それらのブロックを（ボトムアップ手法を使用して）トップダウン・インクリメンタル手法のパーティションを含むプロジェクトにインポートすることができます。また、デザインのタイミング・クロージャを実行するときに、別の Quartus IIプロジェクトで別の設計者が最適化するデザインの1ブロックに対するサブプロジェクトを作成し、そのサブプロジェクトにデザインの残りの部分に関する情報を渡して、最高の結果を得ることができます。混在したデザイン手法に従って、デザイン・ロジックの大部分でトップダウン・フローの利点を維持しながら、ボトムアップ・フローのチーム・ベース機能を利用することができます。

ボトムアップ・インクリメンタル・コンパイルは、マイグレーション・デバイス設定がある場合、HardCopy&regi;II またはFPGA コンパニオン・デバイスのコンパイルではサポートされません。HardCopy ASIC に移行する場合、ボトムアップ手法は使用できません。詳細は、2–88ページの「HardCopyコンパイル・フローおよび移行フロー」を参照してください。


この項では、インクリメンタル・コンパイル・フローの実行に必要なステップの概要を示します。これらの一部のステップについては、この章の後の項で詳細に説明しています。インクリメンタル・コンパイル機能を活用するデザイン・フローの例については、2–63ページの「推奨されるデザイン・フローおよびコンパイルのアプリケーション例」を参照してください。デザイン・パーティションおよびフロアプラン・アサインメントの選択方法のガイドラインについては、「Quartus IIハンドブックVolume 1」の「Best Practices for Incremental Compilation Partitions andFloorplan Assignment」の章を参照してください。

トップダウン・インクリメンタル・コンパイル・フロー図 2–3のフロー・チャートは、トップダウン手法を使用した完全なインクリメンタル・コンパイル・フローを示しています（すべてのパーティションは 1つのトップレベル・プロジェクトに含まれています）。フローの各ステップについては、以下の項で説明しています。最初に、インクリメンタル・コンパイルのためのデザインを準備し、フル・コンパイルを実行します。次に、デザインを検証またはデバッグし、必要に応じて変更します。追加のデザイン・イタレーションを実行し、デザインをリコンパイルするときは、再使用するネットリストを選択してインクリメンタル・コンパイルを実行します。





図 2–3.トップダウン・インクリメンタル・コンパイル・フローの概要

Perform Analysis & Elaboration

Repeat as NeededDuring Design, Verification,& Debugging Stages

(Optional) Create Floorplan LocationAssignments using LogicLock Regions

Perform Complete Compilation(All Partitions are Compiled)

Set Netlist Type for Each Partition

Make Changes to Design

Perform Incremental Compilation(Partitions are Compiled if Required)

Create Design Partitions



トップダウン・インクリメンタル・コンパイルのためのデザインの準備

インクリメンタル・コンパイルのためにデザインを設定するには、以下の一般的な手順を実行します。

1. デザインを詳細設定します。Processing メニューで Start をポイントし Start Analysis & Elaboration をクリックするか、このステップを含むコンパイル・フローを実行します。Elaborationは、デザインの階層を識別する合成プロセスの一部です。

2. 特定のインスタンスをデザイン・パーティションとして指定することにより、デザインにパーティションを作成します。

デザイン・パーティションおよびデザイン・パーティションとして指定できるデザイン部分、そしてデザイン・パーティションのアサインメントについて詳しくは、2–19ページの「デザイン・パーティションの選択および作成」を参照してください。

3. デザイン・フローに必要な場合、LogicLock 領域を使用して各パーティションにロケーション・アサインメントを作成し、デザイン・フロアプランを作成します。デザイン・フローおよび要件に応じて、各パーティションをデバイスのフィジカル領域に割り当てる必要がある場合もあります。これらのアサインメントについて詳しくは、2–38ページの「LogicLockロケーション・アサインメントによるデザイン・フロアプランの作成」の項を参照してください。

4. デザインをコンパイルするには、Processingメニューの StartCompilationをクリックします。パーティション・アサインメントおよび LogicLockアサインメント後の最初のコンパイルは、以降のインクリメンタル・コンパイルのためのデザインを準備する完全なコンパイルになります。



インクリメンタル・コンパイルを使用したデザインのコンパイル

デザインのコンパイル後に変更を行った場合、インクリメンタル・コンパイルを利用すると、変更していないパーティションの結果を維持しながら、デザインの変更された部分をリコンパイルして、以降のコンパイルに要する時間を節約することができます。これを行うには、以下の一般的な手順を実行します。

1. 各パーティションで再利用する以下のコンパイル結果のいずれかを選択します。

● パーティションで以前に行った配置結果を維持するには、そのパーティションのNetlist Typeアサインメントを Post-Fitに設定します。

● 配線情報も維持するには、Fitter Preservation Levelを Placementand Routingに設定します。

● 合成結果のみ保存する場合は、当該パーティションの NetlistTypeアサインメントを Post-Synthesisに設定します。

デザインが変更されたパーティションは、これらの Netlist Type設定で自動的にリコンパイルされます。また、Source Fileネットリスト・タイプ選択して、ソフトウェアでソース・コードからリコンパイルすることもできます。特定のパーティションをコンパイルしない場合は、そのNetlist Typeを Emptyに設定します。

上記のパーティションのプロパティの設定について詳しくは、2–28ページの「デザイン・パーティションの Netlist Typeの設定」を参照してください。

2. デザインをコンパイルします。インクリメンタル・コンパイルをオンにして分割したデザインのコンパイルを開始した場合、Quartus II ソフトウェアはインクリメンタル・コンパイル・フローを使用し、ステップ 1で規定したとおり結果を維持します。

ボトムアップ・インクリメンタル・コンパイル図 2–4のフロー・チャートは、ボトムアップ手法を使用するインクリメンタル・コンパイル・フローを示しています（下位レベル・パーティションは、別々にコンパイルされてからトップレベル・プロジェクトにインポートされます）。フローのステップについては、それぞれ以下の項で説明しています。



最初に、インクリメンタル・コンパイルのためのトップレベル・デザインを準備します。次に、下位レベル・プロジェクトを設計、最適化、検証、およびデバッグします。下位レベル・プロジェクトをエクスポートし、ついでトップレベル・デザインにインポートします。最後に、トップレベル・デザイン全体をコンパイルします。

図 2–4.ボトムアップ・インクリメンタル・コンパイル・フローの概要

ボトムアップ・インクリメンタル・コンパイルのためのデザインの準備

ボトムアップ・デザイン手法を成功させるには、プロジェクト・リーダーまたはトップレベル設計者は以下のステップを実行しなければなりません。

1. 最終的に全体のデザインに組み込まれるトップレベルQuartus IIプロジェクトを作成し、プロジェクト・ワイドの設定とグローバル・アサインメントを適用します。

a. 下位レベル・デザインに対して階層とポート・インタフェースを定義するデザイン全体の“スケルトン”のソース・コードを定義します。トップレベル・デザイン・ファイルには、別のQuartus II プロジェクトでのコンパイルを予定している、下位レベルのブロックをインスタンス化するトップレベルのエンティティを含める必要があります。

Prepare Top-Level Project for Bottom-Up Incremental Compilation

Repeat as NeededDuring Design, Verification,& Debugging Stages

Design, Compile, & OptimizeLower-Level Project(s)

Export Lower-Level Project(s)

Import Lower-Level Project(s) into Top-Level Project

Perform Incremental Compilationin Top-Level Project

Create Lower-Level Project(s)



b. 最終的なデザインが要件を満たすように、デバイス・アサインメント、ピン・ロケーション・アサインメント、タイミング・アサインメントを含むすべてのグローバル・アサインメントを作成します。下位レベル・プロジェクトの設計者は、必要に応じてパーティションに独自の制約を追加し、後でトップレベルの設計者に提供できますが、衝突を回避し、下位レベル・プロジェクトで正しいアサインメントが使用されるように、基本的な制約をトップレベルから継承することもできます。

2. 各下位レベル・デザインにデザイン・パーティション・アサインメントを作成し、インポートされる各デザイン・パーティションのNetlist Typeを Emptyに設定します。詳細は、2–19ページの「デザイン・パーティションの選択および作成」および 2–28ページの「デザイン・パーティションのNetlist Typeの設定」を参照してください。

3. 下位レベルの各パーティションに LogicLock領域を作成し、デザイン・フロアプランを作成します。2–38ページの「LogicLockロケーション・アサインメントによるデザイン・フロアプランの作成」を参照してください。

4. オプション：スケルトン・デザインのフル・コンパイルを実行して、アサインメントを下位レベルの設計者に渡すためのスクリプトを作成します。コンパイル後、Projectメニューの Generate Bottom-UpDesign Partition Scriptsをクリックします。詳細は、2–52ページの「プロジェクト管理のためのボトムアップ・デザイン・パーティションのスクリプトの生成」を参照してください。下位レベルの各設計者に、適切な制約でプロジェクトを作成するために生成された Tclファイルを配布します。デザイン環境で makefile を使用する場合、各パーティションにmakefileを提供します。



下位レベル・プロジェクトの作成とコンパイル

下位レベル・デザインの各設計者は、個別の Quartus IIプロジェクトでデザインを作成およびコンパイルする必要があります。

プロジェクトを手動で作成する場合、必要なすべての設定を行ったQuartus II サブデザイン用の新しいプロジェクトを作成します。プロジェクト・リーダーが指定したように、LogicLock 領域アサインメントおよびグローバル・アサインメント（クロック設定を含む）、およびトップレベル・モジュールの外部デバイス・ピンの代わりに、コア・ロジックへの接続を表すポートに仮想ピン・アサインメントを作成します。

トップレベルの設計者からのボトムアップ・デザイン・パーティションのスクリプトがある場合、Tclスクリプトを使用して、必要なすべての設定およびトップレベル・デザインからのアサインメントを考慮したQuartus IIプロジェクトを作成します。

makefileを使用する場合、makeコマンドおよびプロジェクト・リーダーが提供するmakefileを使用して、必要なすべての設定およびアサインメントを考慮した Quartus IIプロジェクトを作成し、プロジェクトをコンパイルします。makefileで依存性を指定して、どのソース・ファイルをどのパーティションに関連付けるかを示します。

下位レベルの各デザインを個別のQuartus IIプロジェクトとしてコンパイルおよび最適化します。

下位レベル・プロジェクトのエクスポート

下位レベル・デザインのデザイン要件を達成したら、各デザインをトップレベル・デザインのパーティションとしてエクスポートします。

makefileを使用しない場合、Projectメニューの Export Design Partitionダイアログ・ボックスを使用して、下位レベルの各デザインをエクスポートします。2–44ページの「トップレベル・プロジェクトで使用される下位レベル・パーティションのエクスポート」を参照してください。下位レベル・プロジェクトのデザインの一部のみをエクスポートする方法は、2–47ページの「プロジェクト内の下位レベル・ブロックのエクスポート」を参照してください。下位レベルの各設計者は、プロジェクト・リーダーに Quartus II Exported Partitionファイル（.qxp）を提出する必要があります。

デザイン・チームがmakefileを使用している場合、プロジェクト・リーダーは master_makefile で make コマンドを使用して、下位レベルのパーティションをエクスポートし、Quartus II Exported Partitionファイルを作成し、これらをトップレベル・デザインにインポートすることができます。



下位レベル・プロジェクトのトップレベル・プロジェクトへのインポート

プロジェクト・リーダーは、次に下位レベルの各サブデザイン・パーティションの設計者から提出されたファイルをインポートします。

makefileを使用しない場合、Projectメニューの Import Design Partitionをクリックして、サブデザインの .qxp ファイルで表されるトップレベル・プロジェクト内のパーティションを指定します。詳細は、2–48ページの「下位レベル・パーティションのトップレベル・プロジェクトへのインポート」を参照してください。デザインの各パーティションに対して、インポート・プロセスを繰り返します。

makefile を使用する場合、master_makefileコマンドで各パーティションをトップレベル・デザインにインポートします。ソース・ファイルが変更された場合でもソフトウェアがプロジェクト再構築できるよう、必ずどのソース・ファイルをどのパーティションに関連付けるかを指定します。

インポートするアサインメントおよび衝突の回避方法について詳しくは、2–49ページの「アサインメントおよび高度なインポート設定のインポート」を参照してください。

トップレベル・プロジェクトでのインククリメンタル・コンパイルの実行

トップレベル・プロジェクトを構成するデザイン・パーティションをインポートした後、フル・コンパイルを実行することができます。ソフトウェアは、インポートされたパーティションをトップレベル・プロジェクトで定義されたパーティションと同じ方法でコンパイルします。ソフトウェアは、最後のコンパイル以降にインポートされたパーティションのみリコンパイルします。


デザイン・パーティションの選択および作成


一般的なデザイン方法は、モジュラー・デザインまたは階層構造デザインを作成することです。この方法では、各デザイン・エンティティを個別に作成し、そのエンティティをより上位レベルのエンティティでインスタンス化して、完全なデザインを形成します。インクリメンタル・コンパイルの場合、各デザイン・エンティティまたはインスタンスが自動的にデザイン・パーティションとなるようには考慮されないため、トップレベルのプロジェクトの下にある 1つまたは複数のデザイン階層をデザイン・パーティションに指定する必要があります。 2–23ページの「デザイン・パーティションがデザイン最適化に与える影響」で説明するとおり、パーティションを作成すると、コンパイラはパーティション境界を越えて最適化を行うことはできません。ただし、パーティションの作成により、合成と配置をパーティションごとに個別に実行でき、インクリメンタル・コンパイルが可能になります。

パーティションは、階層構造エンティティ内のロジックの一部になることはできないため、デザイン内の階層構造ブロックと同じ境界を持っている必要があります。パーティションを宣言した場合、そのパーティション内のすべての階層構造インスタンスは同じパーティションに属すようになります。既存のパーティション内の階層構造インスタンスに新しいパーティションを作成できます。この場合、以下の例で説明するように、新しいパーティション内のインスタンスは、上位レベルのパーティションに所属できなくなります。

図 2–5では、階層構造インスタンス Bと Fは、インスタンス A、B、C、D、E、Fから構成される完全なデザインのパーティションを形成します。Representation Aの影付きボックスは、「ツリー」表示された階層のデザイン・パーティションを示します。Representation B では、下位レベルのインスタンスは上位レベルのインスタンスの内部に示され、パーティションは異なる色の影付きで図示されています。Top という名前のトップレベル・パーティションには、デザインのトップレベル・エンティティと、別のパーティションの一部として定義されていない任意のロジックが含まれます。トップレベルのデザイン・ファイルは、その下にある階層構造インスタンスの単なるラッパーになることも、独自のロジックを含むこともできます。この例では、トップレベルのエンティティ A のパーティションには、下位レベルのインスタンスの 1つ Cのロジックも含まれています。インスタンス Fは専用のパーティション内にあるため、トップレベル・パーティションの一部として扱われません。もう一つの独立したパーティション B には、インスタンス B、D、および E のロジックが含まれます。



図 2–5.階層構造デザインのパーティション

どのデザイン・インスタンスに対してもパーティション・アサインメントを作成できます。インスタンスは、HDLまたは回路図デザインで定義するか、あるいは VQM または EDIF ネットリスト・インスタンスとして、サードパーティ合成ツールで作成することができます。ソース・ファイルの変更時にインクリメンタル・コンパイルを利用するには、各パーティションに対して個別のデザイン・ファイルを作成します。別々のパーティションに 2つの異なるエンティティを定義したが、それらが同じデザイン・ファイルにある場合、デザイン・ファイル内のいずれかのエンティティを変更した場合は、両方のパーティションをリコンパイルする必要があるため、インクリメンタル・コンパイルを維持することはできません。同様に、2つのパーティションが同じ下位レベルのエンティティ定義に依存している場合は、その以下レベルでの変更は両方のパーティションに影響を及ぼします。

フル・インクリメンタル・コンパイルを有効にしていない場合、最初のパーティションを指定するときに、インクリメンタル・コンパイルを有効にするかどうかを確認するダイアログ・ボックスが表示されます。インクリメンタル・コンパイルをオンにするには、Assignmentsメニュー

Partition Top

Representation A

Representation B

Partition B Partition F

D

D

E

B

B C

A

A

F

C

E EF



の Settingsをクリックします。Categoryリストで、Compilation ProcessSettings を選択します。Compilation Process Settings で、IncrementalCompilation を選択します。Incremental Compilation ページで、Fullincremental compilationをオンにします。

Settingsダイアログ・ボックスの Incremental Compilationページでインクリメンタル・コンパイルをオフにしても、パーティション・アサインメントは削除されません。インクリメンタル・コンパイルがオフの場合、パーティション・アサインメントはデザインに影響しません。

サードパーティ合成ツールでのパーティションの使用インクリメンタル・コンパイルはサードパーティ合成ツールで正しく動作します。サードパーティ合成ツールを使用する場合は、ツールを設定して階層構造パーティションごとに個別の VQM または EDIF ネットリストを作成します。Quartus II ソフトウェアで、各ネット・リストからのトップレベル・エンティティがデザイン・パーティションになるように割り当てます。VQMまたは EDIFネットリスト・ファイルは、QuartusII ソフトウェアでのパーティション用のソース・ファイルとして扱われます。

Synplicity社 Synplify Proおよび Mentor Graphics社 Precision RTL Plus

Synplify Pro ソフトウェアは、MultiPoint 合成機能を備えており、ユーザー・インタフェースまたはスクリプトで Compile Pointとして割り当てられた各デザイン・ブロックのためのインクリメンタル合成を実行します。Precision RTL Plusソフトウェアは、ソースHDLコードの Partitionアサインメントに基づくブロック・ベース合成を実行するインクリメンタル合成機能を備えています。これらの機能は、自動化されたブロック・ベースのインクリメンタル・シンセシス・フローを提供し、アルテラ・デバイスのセットアップ時に各ブロック用の異なる出力ネットリスト・ファイルを作成します。

合成ツール内でインクリメンタル・シンセシスを使用すると、デザインのコンパイル時に更新されたデザインのセクションのみ再合成され、合成実行時間が短縮され、未変更ブロックの結果が保持されます。デザインの他のセクションに影響を与えずに、デザインの 1つのセクションを変更して再合成することができます。

これらのインクリメンタル・シンセシス・フローについて詳しくは、ツール・ベンダのドキュメントを参照してください。



その他の合成ツール

トップレベルを含めて、各パーティションに対して個別のプロジェクトまたは実装を作成することにより、Synplify ソフトウェア（non-Pro）、Precision RTLソフトウェア（non-Pro）、またはその他のサポートされている合成ツールを用いて、手動でデザインを分割し、異なるネットリスト・ファイルを作成することもできます。上位レベルの各プロジェクトを設定し、下位レベルの VQM/EDIF ネットリストをブラックボックスとしてインスタンス化します。Synplify、Precision、および大部分の合成ツールは、プロジェクトにロジック定義がない場合は、デザイン・ブロックを自動的にブラック・ボックスとして扱います。各ツールには、デザイン・ブロックをブラック・ボックスとして扱われなければならないことを指定するオプションまたは属性も含まれており、これを使用して欠落ロジックに関する警告を回避することができます。

フィジカル配置アサインメントと比較したデザイン・パーティションのアサインメントインクリメンタル・コンパイルのデザイン・パーティションは、ロジカル・パーティションであり、デバイス・フロアプランの物理的な配置アサインメントとは異なります。ロジカル・デザイン・パーティションは、デバイスの物理エリアを参照せず、インスタンスの配置を直接制御しません。ロジカル・デザイン・パーティションは、デザイン階層間に仮想境界を設定するため、各パーティションは個別にコンパイルされ、パーティション間で論理的な最適化が発生するのを防止します。ソフトウェアは各パーティションに個別の合成後のネットリストとフィッティング後のネットリストを作成します。これにより、ソフトウェアは以降のコンパイルで合成結果またはフィッティング結果（配置配線情報を含む）を再利用することができます。

Post-Fit ネットリストを使用してコンパイル結果を維持する場合、特定のロジック・ノードのロケーション・アサインメントをバック・アノテーションまたは作成する必要はありません。インクリメンタル・コンパイルとアサインメント・バック・アノテーション機能を、同じ Quartus IIプロジェクトで使用してはなりません。インクリメンタル・コンパイル機能は、配置“アサインメント“を使用して配置結果を維持するのではなく、配置情報を含むネットリスト・データベースを再利用するだけです。

LogicLock アサインメントを使用して、デザイン・パーティションをデバイス・フロアプランのフィジカル領域に割り当てることができます。Quartus II ソフトウェアでは、LogicLock 領域を使用して、デザインのブロックをデバイスの特定領域に制限します。インクリメンタル・コンパイルを実行するとき、アルテラでは一部のケースで結果の品質を改善し、配置衝突を回避するために、LogicLock 領域を使用することを推奨しています。LogicLock 領域を使用したデザイン・パーティションへの



フロアプランのロケーション・アサインメントの作成については、2–38ページの「LogicLock ロケーション・アサインメントによるデザイン・フロアプランの作成」で説明しています。

デザイン・フロアプランの作成時期および作成理由について詳しくは、「Quartus II ハンドブック Volume 1」の「Best Practices for Incremental

Compilation Partitions and Floorplan Assignments」の章を参照してください。

デザイン・パーティションがデザイン最適化に与える影響デザイン・パーティションの境界は、結果のデザインの品質に影響を与えることがあります。パーティションを作成すると、コンパイラはパーティション境界を越えてロジックの最適化を行わないため、ソフトウェアが各パーティションをインクリメンタル・フローで個別に合成および配置できます。したがって、パーティション境界の影響を抑えるために、パーティショニングのガイドラインを考慮に入れてください。

可能な場合は、各パーティションのすべての入力および出力を登録します。これによって、パーティション境界を通過する信号の遅延ペナルティを回避でき、最適化のために各レジスタ間タイミング・パスが 1つのパーティション内で維持されます。さらに、パーティション境界をまたがるパスの数を最小限に抑えます。タイミング・クリティカル・パスがパーティション間をまたがっている場合は、パーティションを再編成して、パーティション間にパスが形成されないようにします。パーティション内でできるだけ多くのタイミング・クリティカルな接続をインクルードすることにより、デザインの残りを変更しないで最適化をそのパーティションに効果的に適用して、タイミングの改善を図ることができます。さらに、持続的なパーティションの入力および出力を回避します。これは、インクリメンタル動作を維持するために、ソフトウェアはパーティション境界のいずれの側でも、定数値を使用してロジックを最適化することができないためです。

Partition Merge Partition Statisticsコンパイル・レポートおよびDesignPartitions Propertiesダイアログ・ボックスの Statisticsタブで、I/O接続数および未登録または定数値でドライブされる I/O接続数など、デザイン・パーティションに関する統計を表示することができます。

クリティカル・タイミング・パスがパーティション境界をまたがる場合は、タイミング・バジェットを実行し、タイミング・アサインメントを作成して、タイミング・パス全体が必要条件を満たすように各パーティションのロジックを制限することができます。さらに、各パーティションは合成中に個別に最適化されるため、何らかのリソース・バラシングを実行して、各パーティションが適切な数のデバイス・リソースを使用するようにしなければならない場合があります。





パーティショニングのガイドラインおよび一般的なデザイン問題を解決するための具体的な推奨事項、そしてリソース・バランシングおよびタイミング・バジェットに関する情報については、「Quartus IIハンドブック Volume 1」の「Best Practices for Incremental Compilation Partitionsand Floorplan」の章を参照してください。

Design Partition Plannerでのデザイン・パーティションの作成Design Partition Plannerを使用すれば、ユーザーはデザインの接続性および階層を表示でき、アルテラのガイドラインに従った効果的なデザイン・パーティションを作成することができます。

以下のステップでは、デザインを表示し、デザイン・パーティションを作成する方法の要点を説明しています。

1. フラットな（パーティションに分割されていない）デザインをコンパイルするか、少なくとも解析および合成を実行します。

2. Toolsメニューで、Design Partition Plannerをクリックします。デザインは、ボックスとして下位レベル・インスタンスを含む 1つのトップレベル・デザイン・ブロックとして表示されます。

3. ブロック間の接続性を表示するには、トップレベル・デザイン・ブロックからのインスタンスの抽出を開始します。デザイン・クロックをクリックし、それを周囲の白いスペース内にドラッグするか、エンティティを右クリックし、Shortcut メニューの Extract fromParentをクリックします。エンティティの抽出時に、エンティティ間に接続バンドルが描かれ、エンティティ・ペア間に存在する接続数を示します。

4. 接続性表示モードと階層表示モードを切り替えるには、Viewメニューの Hierarchy Display をクリックします。あるいは、一時的に閲覧のみの階層表示に切り替えるには、どれかのエンティティの左上隅の階層アイコンをクリックして保持します。

5. デザイン・パーティションとして設定したいデザイン・ブロックをすでに抽出しているときは、そのデザイン・ブロックを右クリックして、Create Design Partitionを選択します。

Design Partition Plannerの使用方法について詳しくは、Quartus II Helpの Using the Design Partition Plannerを参照してください。





図 2–6 に、1 つのインスタンスに対してデザイン・パーティション・アサインメントを作成し、同じパーティション内のトップレベル・ブロックから別のインスタンスをドラッグして移動した後の Design PartitionPlannerを示します。図は、各パーティション間の接続数と各デザイン・インスタンスのサイズに関する情報を示しています。

図 2–6. Design Partition Planner

Design Partition Planner外でのデザイン・パーティションの作成デザイン・パーティションは、メイン Quartus II GUIの Design Partitionsウィンドウまたは Project Navigatorを使用して作成できます。インクリメンタル・コンパイルのためのデザイン階層をプラニングし、どのデザイン・ブロックが効果的なデザイン・パーティションを作成するかが分かっているときには、これらの方法のいずれかを使用します。

AssignmentsメニューのDesign Partitions Window（図 2–7）をクリックします。以下のいずれかの方法でパーティションを作成します。



■ 1 つまたは複数のインスタンスに新しいパーティションを作成する場合は、Project NavigatorのHierarchyタブから Design Partitionsウィンドウに、インスタンスをドラッグ・アンド・ドロップします。この方法を使用する場合、複数のパーティションを一度に作成できます。

■ Partition Nameカラムで <<new>>セルをダブル・クリックし、新しいパーティションを作成します。Create New Partitions ダイアログ・ボックスで、デザイン・インスタンスを選択し、OK をクリックします。

Design Partitions ウィンドウでパーティションを削除するには、パーティションを右クリックし Deleteをクリックするか、パーティションを選択してDeleteキーを押します。

図 2–7. Design Partitionsウィンドウ

また、Project NavigatorのHierarchyタブ内のインスタンスのリストを使用して、デザイン・パーティションの作成および削除を行うこともできます。Project Navigatorでインスタンスを右クリックし、Set as DesignPartitionをクリックします。

パーティションとして設定された各インスタンスの横に、デザイン・パーティションのアイコンが表示されます（図 2–8）。

既存のパーティション・アサインメントを削除するには、ProjectNavigatorでインスタンスを右クリックし、Set as Design Partitionを再度クリックします。（このプロセスによってオプションがオフになります。）



図 2–8.デザイン・パーティションを示す Project Navigator

パーティション・シンボルパーティションを作成すると、インスタンス名と階層パスに基づいて自動的に名前が作成されます。名前を変更するには、Design Partitionsウィンドウでパーティション名をダブル・クリックするか、パーティションを右クリックして Rename をクリックします。あるいは、DesignPartitionsウィンドウでパーティションを右クリックし、Propertiesをクリックして、Design Partition Properties ダイアログ・ボックスを開いて変更することもできます。General タブで、Name フィールドに新しい名前を入力します。

パーティション名を変更することによって、階層パス（場合によっては長くなることもある）を使ってパーティション名を参照するのを回避できます。これは、コマンドラインのコマンドやアサインメントを使用するときには特に重要です。パーティション名は、長さが 1～ 1024文字の固有のものでなければなりません。名前に使用できるのは、英数字、パイプ（ |）、コロン（ :）、アンダースコア（ _）だけです。



デザイン・パーティションの Netlist Typeの設定

2–14ページの「インクリメンタル・コンパイルを使用したデザインのコンパイル」の説明に従って、Netlist Type プロパティでインクリメンタル・コンパイル・プロセスを制御します。Netlist Type は各デザイン・パーティションのプロパティであり、コンパイラが各パーティションの入力として使用するネットリストやソース・ファイルのタイプを指定することができます。このプロパティは、次のコンパイルのPartition Mergeステージで使用されるネットリストを指定します。

Netlist Typeを表示して変更する場合は、AssignmentメニューのDesignPartition Window をクリックします。エントリの Netlist Type をダブル・クリックします。あるいは、エントリを右クリックし、DesignPartition Properties をクリックしてから、Compilation タブの NetlistTypeを変更します。



表 2–2 で、Netlist Type プロパティの各種設定および各設定におけるQuartus II ソフトウェアの動作について説明し、各設定をいつ使用するかについてのガイダンスを提供します。

表 2–2. Netlist Typeの設定（１ /３）

Partition Netlist Type コンパイル時のパーティションに対する Quartus IIの動作

Source File 常に関連するデザイン・ソース・ファイルを使用して、パーティションをコンパイルします。

新しい合成設定または Fitter設定を使用して、ソース・コードからパーティションをリコンパイルする場合は、このネットリスト・タイプを使用します。

関連するネットリストがパーティションにインポートされた場合、ネットリスト・タイプをSource Fileに設定してパーティションをコンパイルすると、インポートされたネットリストが削除されます。したがって、別のプロジェクトからインポートされた結果を使用しないで、この設定を使用してトップレベル・プロジェクト内でソース・ファイルからのパーティションをリコンパイルすることができます。

Post-Synthesis 以下の条件が満足される限り、パーティションの合成後の結果を維持し、合成後のネットリストを再使用します。● 前の合成から合成後のネットリストが利用できる● 前の合成以降に、パーティションに対して自動再合成を実行する変更が行われていない。詳細は、2–35 ページの「パーティションの自動再合成を実行するのはどのような変更でしょうか？」を参照してください。

再合成が実行される場合または合成後のネットリストが使用できない場合は、ソース・ファイルからパーティションをコンパイルします。

ソース・ファイルが変更されていない場合は、このネットリスト・タイプを使用して、合成結果を維持することができます。ただし、Fitterが新しい Fitter設定を使用して、パーティションを再フィッティングできるようにします。

関連するネットリストがパーティションにインポートされている場合、この設定は使用できません。



Post-Fit 以下の条件が満足される限り、パーティションのフィッティング後の結果を維持し、フィッティング後のネットリストを再使用します。● 前のフィッティングからフィッティング後のネットリストが利用できる● 前のフィッティング以降に、パーティションに対して自動再合成を実行する変更が行われていない。詳細は、2–35 ページの「パーティションの自動再合成を実行するのはどのような変更でしょうか？」を参照してください。

ポスト・フィット・ネットリストが使用できない場合、ソフトウェアは合成後のネットリストが使用できる場合はそれを再使用し、使用できない場合はソース・ファイルからコンパイルします。再合成が実行される場合は、ソース・ファイルからパーティションをコンパイルします。

フィッティング後のネットリストのどのレベルの情報が維持されるかは、Fitter PreservationLevelで指定されます。詳細は、2–32ページの「Fitter Preservation Level」を参照してください。

変更を行わないとき、Fitterの結果を維持する場合は、このネットリスト・タイプを使用します。このネットリスト・タイプは、他のパーティションのフィッティング結果を維持しながらフィジカル・シンセシス最適化などのグローバルな最適化を特定のパーティションに適用する場合にも使用できます。


Post-Fit (Strict) 前のフィッティングからフィッティング後のネット・リストが使用できる限り、常にパーティションのフィッティング後の結果を維持します。前のフィッティング以降に、関連するソース・ファイルに変更が行われている場合でも、フィッティング後のネットリストを使用します。詳細は、2–38ページの「パーティションが変更されたときのフィッティング後のネットリスト使用の強制」を参照してください。

フィッティング後のネットリストが使用できない場合、ソフトウェアは合成後のネットリストが使用できる場合はそれを再使用し、使用できない場合はソース・ファイルからコンパイルします。

フィッティング後のネットリストのどのレベルの情報が維持されるかは、 Fitter PreservationLevelで指定されます。詳細は、2–32ページの「Fitter Preservation Level」を参照してください。


表 2–2. Netlist Typeの設定（２ /３）




Imported .qxp ファイルからインポートされたネットリストを使用して、パーティションをコンパイルします。

インポートされた元のネットリストは、コンパイル中に変更されたり、上書きされることはありません。インポートされたネットリストへの変更（インポートされた LogicLock 領域の移動など）を維持するには、インポートされたネットリストによるコンパイルに成功した後で、Post-Fit (Import-based)設定を使用します。詳しくは、2–43ページの「ボトムアップ・デザイン・フローのためのパーティションのエクスポートとインポート」を参照してください。

インポートされたネットリストのどのレベルの情報が維持されるかは、 Fitter PreservationLevelで指定されます。詳細は、2–32ページの「Fitter Preservation Level」を参照してください。

Import Design Partitionコマンドを使用してこのパーティションのネットリストをインポートしていない場合、この設定は使用できません。

Post-Fit (Import-based)

以下の条件が満足される限り、パーティションのフィッティング後の結果を維持し、フィッティング後のネットリストを再使用します。● 前のフィッティングからフィッティング後のネットリストが利用できる● 前のフィッティング以降に、インポートされた関連するネットリストへの変更が行われていない

インポートされたネットリストが変更されている（すなわち、ネットリストが再インポートされている）場合、またはフィッティング後のネットリストが利用できない場合、インポートされたネットリストからパーティションをコンパイルします。アサインメントを変更してもリコンパイルは行われません。

フィッティング後のネットリストのどのレベルの情報が維持されるかは、　FitterPreservation Levelで指定されます。詳細は、「Fitter Preservation Level」を参照してください。

インポートされたネットリストの配置配線への変更を維持するには、このネットリスト・タイプを使用できます。

関連するネットリストがパーティションにインポートされていない場合、この設定は使用できません。

Empty パーティションに空のプレースホルダ・ネットリストを使用し、パーティション境界で仮想ピンを使用します。

このネットリスト・タイプは、下位レベルのパーティションのコンパイルをスキップする場合に使用します。Empty設定について詳しくは、2–34ページの「Emptyパーティション」を参照してください。

表 2–2. Netlist Typeの設定（３ /３）




Fitter Preservation LevelFitter Preservation Levelプロパティは、フィッティング後のネットリストまたはインポートされたネットリストのどの情報をコンパイラが使用するかを指定します。このプロパティは、Netlist Type が、Post-Fit、Post-Fit (Strict)、Imported、または Post-Fit (Import-based)に設定されている場合にのみ使用できます。

AssignmentsメニューのDesign Partitions Windowをクリックします。Fitter Preservation Levelを表示し変更するには、エントリをダブル・クリックします。または、エントリを右クリックし、Properties をクリックしてから、CompilationタブでFitter Preservation Levelを編集します。

表 2–3で、Fitter Preservation Levelの設定について説明します。

表 2–3. Fitter Preservation Levelの設定（１ /２）

Fitter Preservation

Levelコンパイル時のパーティションに対する Quartus IIの動作

Netlist Only デザイン・パーティションのネットリストの素子を維持しますが、デザイン・パーティションを再配置および再配線します。素子が維持されたフィッティング後のネットリストには、前のフィッティング中にフィジカル・シンセシスによって複製されたレジスタなど、Fitter による最適化データが含まれるため、合成後のネットリストとは異なることがあります。

この設定は以下の用途に使用できます。● Fitter最適化を維持しながら、ソフトウェアに再び配置配線を実行させる● 配置をロックダウンしたときは不可能になる特定の Fitter最適化（すなわちフィジカル・シンセシス）を再度適用

● ボトムアップ・デザイン・フローでインポートされた 2つのパーティションのリソースの衝突を解決

Placement デザイン・パーティションでのネットリストの素子とその配置を維持します。デザイン・パーティションを再配線します。

この設定では、Fitter がパーティションのノードを再フィッティングする必要がないため、コンパイル時間が大幅に短縮されます。インポートされたネットリストまたは空のパーティションが前のフィッティング後のネットリストを再使用するように設定されているため、2つのノードが同じ位置に割り当てられる場合、Fitterは影響を受けるノードを再フィッティングすることに注意してください。

ネットリスト・タイプが Imported に設定され、インポートされたネットリストに配置データが含まれていない場合、この設定は使用できません。



Placement and Routing

デザイン・パーティションのネットリストの素子とその配置配線を維持します。フィッティング後のネットリストおよびデザインに追加されるSignalProbeピンに対するECOの変更を維持するのに必要な最小維持レベルです。

この設定では、Placementのみの場合よりもコンパイル時間が短縮されます。適用性の理由から、Fitterによる配線の変更が必要になる場合があります。

ネットリスト・タイプが Imported に設定され、インポートされたネットリストに配線データが含まれていない場合、この設定は使用できません。

Placement、Routing、および Tile

デザイン・パーティションで、デザイン・パーティションのネットリストの素子とその配置配線、およびパワー・タイルの高速または低速の設定を維持します。

適用性の理由から、Fitterによる配線の変更が必要になる場合があります。

この設定は、コンフィギュレーション可能なパワー・タイルを持つデバイスに対してのみ使用できます。

表 2–3. Fitter Preservation Levelの設定（２ /２）

Fitter Preservation

Levelコンパイル時のパーティションに対する Quartus IIの動作



EmptyパーティションEmpty設定を使用すると、不完全な、またはトップレベルのデザインで欠落した下位レベルのパーティションのコンパイルをスキップすることができます。またこの設定は、最適化中またはあるパーティションのコンパイル時間が長く、これを除外したい場合など、デザインの一部のパーティションのみコンパイルする場合にも使用できます。この設定は、IPコアなどのタイミング・クリティカルなブロックの配置を最適化し、トップダウン・デザイン・フローで残りのカスタム・ロジックを追加する前に配置をロックする場合に有用です。

Netlist Typeを Emptyに設定するには、AssignmentsメニューでDesignPartitions Window をクリックするか、エントリをダブル・クリックするか、またはエントリを右クリックして Design Partition Propertiesをクリックし、Emptyを選択します。この設定は、パーティションに空のプレースホルダ・ネットリストを使用するように Quartus II Compilerに指定します。

パーティションNetlist Typeが Emptyと定義されている場合、パーティションの境界で仮想ピンが自動的に作成されます。これは、ソフトウェアがコンパイル中に下位レベル・デザイン・エンティティの I/Oピンを、ピンではなく内部セルに一時的にマッピングすることを意味します。

デザイン階層で空のパーティションより下位の子パーティションは自動的に、それらの設定に関係なくすべて空として処理されます。

Empty設定をフルに利用する場合は、階層ツリーから外れたデザイン・ロジックを最高の柔軟性を提供するように維持することが重要です。ある階層レベルにロジックが存在し、子階層に別のロジックが存在する場合、空のパーティションのトップレベル・ロジックを分離すると、下位レベルのパーティションも空として扱われます。

ボトムアップ・デザイン・フローのバリエーションで、一部のパーティションが Empty に設定されたデザイン・フローを使用できます。ここで、デザインを部分的に個別に開発し、後でトップレベルで結合します。

プロジェクトの他の部分に関する情報なしで、デザインの一部を実装する場合、コンパイラがグローバル配置最適化を実行することは不可能です。この影響を軽減するには、適切なパーティショニング・ガイドラインに従い、可能な限りパーティションの入力ポートと出力ポートが確実に登録されるようにすることによって、パーティションをまたがる I/Oを最小にします。



デザイン・パーティションを Emptyに設定すると、パーティションをデザインの他のロジックおよびパーティションに正しく接続できるように、Analysis & Synthesis でポート・インタフェース情報を指定するためのデザイン・ファイルが要求されます。パーティションがインポートされる場合、.qxp ファイルにはこの情報が含まれています。デザイン・エンティティを表す .qxpファイルまたはデザイン・ファイルがない場合は、デザイン・ブロックを定義し、入力、出力、双方向ポートを指定するラッパー・ファイル（ブラック・ボックス、スタブまたは中空体ファイルと呼ばれる）を作成する必要があります。例えば、Verilog HDL ではモジュール宣言を含め、VHDL ではエンティティおよびアーキテクチャ宣言を含めなければなりません。

プロジェクト・データベースに、変更されない Emptyパーティションに以前生成された合成後またはフィッティング後のネットリストが含まれる場合、Emptyから Post-Synthesisまたは Post-FitにNetlist Typeを直接設定することができます。この場合、ソフトウェアは前のネットリスト情報を再使用し、ソース・コードからリコンパイルする必要はありません。

パーティションの自動再合成を実行するのはどのような変更でしょうか？前の合成から使用できる合成後のネットリストがない場合、またはNetlist Typeが Source Fileに設定されている場合、パーティションはそのソース・ファイルから合成されます。また、デザイン・パーティションへの特定の変更は、Netlist Typeが Post-Synthesisまたは Post-Fitのときに、パーティションの自動再合成を実行します。ソフトウェアはこれらのケースでパーティションを再合成して、デザイン記述が配置配線後のプログラミング・ファイルに一致するようにします。この再合成を自動的に発生させたくない場合は、Netlist Typeを Post-Fit (Strict)に設定します。2–38 ページの「パーティションが変更されたときのフィッティング後のネットリスト使用の強制」を参照してください。

以下のリストは、Netlist Typeが Post-Synthesisまたは Post-Fitに設定されているときに、パーティションの自動再合成を実行する変更について説明しています。

■ デバイス・ファミリの設定が変更された。■ 依存ソース・デザイン・ファイルが変更された。詳細は、2–37ページの「ソース・コードの変更により再合成されるパーティションの決定」を参照してください。

■ 下位レベル・パーティション（つまり、このパーティション内の下位レベル・インスタンスに対して定義されたパーティション）のポート境界に対する追加、削除、または変更によってパーティション境界が変更された。



■ 依存ソース・ファイルが異なるライブラリ内にコンパイルされた（そのため、異なる -library引数を持っている）。

■ 依存ソース・ファイルが追加または削除された。すなわち、パーティションが異なるソース・ファイル・セットに依存している。

■ パーティションのルート・インスタンスに異なるエンティティ結合が存在する。VHDLでは、あるインスタンスが特定のエンティティおよびアーキテクチャに結合されることがある。ターゲットのエンティティまたはアーキテクチャが変更される場合は、再合成が実行されます。

■ パーティションのルート階層上または内部AHDL階層上に異なるパラメータがある場合（AHDLは自動的にその親階層からパラメータを継承します）。これは、階層上のパラメータを直接修正した場合、または親デザイン階層のパラメータを変更することにより間接的にそれらを変更した場合に発生します。

ソフトウェアは、合成後の結果を再使用しますが、同一デバイス・ファミリ内でデバイス設定を変更する場合はデザインを再フィッティングします。デバイスのスピード・グレードのみを変更する場合、ソフトウェアはフィッティング後のネットリストを再使用します。

最適化設定、タイミング・アサインメント、またはピン・アサインメントを含む Fitter ロケーション・アサインメントなどの合成および Fitterアサインメントでは、インクリメンタル・コンパイル・フローで自動リコンパイルを実行してはなりません。LogicLock 領域で配置に与える影響について詳しくは、2–42 ページの「どの LogicLock 領域の変更が再フィッティングを実行するか」を参照してください。新しいアサインメントのあるパーティションをリコンパイルするには、そのパーティションのNetlist Typeアサインメントを次のいずれかに変更します。

■ すべての新しい設定で Source Fileをリコンパイル■ 既存の合成結果と新しい Fitter設定を使用して Post-Synthesisをリコンパイル

■ Fitter Preservation LevelでPost-FitをPlacementに設定し、新しい配線設定（遅延チェイン設定など）を除く、既存の配置結果を使用して配線を再実行

プロジェクト・データベース・フォルダ（\db）には、以前のコンパイルのすべてのネットリスト情報が含まれています。不必要なリコンパイルを避けるために、データベース・ファイルの変更や削除を行わないでください。

プロジェクトを別の場所でアーカイブまたは再現する場合、Quartus IIArchive ファイル（.qar）を使用できます。コンパイル結果を維持するためにコンパイル・データベースをインクルードします。詳細は、2–82ページの「Quartus II Archive ファイルによるインクリメンタル・コン



パイルの使用」を参照してください。コンパイル・データベース全体を維持することなく、コンパイル結果を維持するプロジェクト・アーカイブを手動で作成するために、すべてのソース・ファイルおよび設定ファイルを維持し、デザインの各パーティション用の .qxpファイルを作成および保存することができます。詳細は、2–47ページの「プロジェクト内の下位レベル・ブロックのエクスポート」を参照してください。

ソース・コードの変更により再合成されるパーティションの決定

Quartus IIソフトウェアは、内部チェックサムを使用して、ソース・ファイルの内容が変更されたかどうかを判断します。ソース・ファイルはデザインの作成に使用されるデザイン・ファイルで、VHDL ファイル、Verilog HDLファイル、AHDLファイル、ブロック・デザイン・ファイル（.bdf）、EDIF ネットリスト、VQM ネットリスト、およびメモリ初期化ファイルで構成されています。シミュレーション用のベクタ波形ファイルなど、他のファイルが変更された場合、リコンパイルは行われません。パーティションのデザイン・ファイルに他のファイルへの依存性がある場合、1 つのファイルを変更すると別のファイルの自動リコンパイルが実行される場合があります。Analysis & Synthesis レポートのPartition Dependent Filesテーブルは、各デザイン・パーティションのためのデザイン・ファイルを示します。このテーブルを使用して、特定のファイルが変更されたときにリコンパイルされるパーティションを決定することができます。

例えば、エンティティ aを含む a.v、エンティティ bを含む b.v、およびエンティティ c を含む c.v の各ファイルがデザインに使用されている場合、エンティティ aを含むパーティションの Partition Dependent Filesテーブルにはファイル a.vが、エンティティ bを含むパーティションのテーブルにはファイル b.v が、エンティティ cを含むパーティションのテーブルにはファイル c.v がそれぞれリストされます。いずれの依存性も推移的なので、ファイル a.vが b.vに依存し、b.vが c.vに依存する場合、ファイル a.vのエンティティはファイル b.vと c.vに依存します。この場合、ファイル b.v と c.v は、エンティティ a を含むパーティションの依存ファイルとしてレポート・テーブルにリストされます。

上位レベルのモジュールでモジュール・パラメータを定義する場合、Quartus II ソフトウェアは、パラメータ値をチェックして再合成が必要なパーティションを決定します。下位レベルのモジュールに影響を与える上位レベルのモジュールのパラメータを変更すると、下位レベルのモジュールが再合成されます。パラメータの依存性は、ソース・ファイルの依存性とは別に追跡されます。したがって、パラメータ定義はPartitionDependent Filesリストには含まれません。



各エンティティでコマンド ‘include includes.vにより参照されるincludes.v ファイルなどの共通ファイルがデザインに含まれる場合、すべてのパーティションはこのファイルに依存します。includes.v を変更すると、デザイン全体がリコンパイルされます。通常、VHDL 文 usework.all は、作業ライブラリのすべてのエンティティを現在のエンティティに表示し、その結果現在のエンティティはデザインの他のすべてのエンティティに依存するため、不必要なリコンパイルになります。

この種の問題を回避するには、共通のインクルード・ファイルなど、すべてのエンティティに共通のファイルには、真にすべてのエンティティに共通な情報セットのみ格納するようにしてください。VHDLファイルの use work.all 文を削除するか、各エンティティに必要な特定のデザイン・ユニットのみを含めることによって use work.all文を置換してください。

パーティションが変更されたときのフィッティング後のネットリスト使用の強制

ソース・ファイルの内容が変更されたとき、フィッティング後のネットリストの使用を強制するオプションは、パーティションのリコンパイルが必要なタイミングを理解している上級ユーザーにのみ推奨されます。このアサインメントは、ソース・コードを変更しても別のパーティションのデバッグが完了するまでリコンパイルを実行したくない場合などに使用できます。ソース・ファイルを変更したときに、以前に生成されたフィッティング後のネットリストの使用を Fitterに強制するには、Post-Fit (Strict) Netlist Typeアサインメントを使用できます。

Post-Fit (Strict) Netlist Type を誤って使用すると、ソース・デザイン・ファイルの変更時に、機能的に不正なネットリストが生成される可能性があります。このアサインメントを使用するときは注意が必要です。

LogicLockロケーション・アサインメントによるデザイン・フロアプランの作成

フロアプランはデバイス上のフィジカル・リソースのレイアウトを表します。“デザイン・フロアプランの作成”および“フロアプランニング”という表現は、ロジカル・デザイン階層をデバイス・フロアプランのフィジカル領域にマッピングするプロセスを記述したものです。フル・インクリメンタル・コンパイル・フローを使用して結果の品質を高める場合は、デザインを分割した後、ここで述べるように、デザインにフロアプラン・ロケーション・アサインメントを作成します。インクリメンタル・コンパイル・フローを使用する場合、デザイン・フロアプランの作成は必要条件ではありませんが、特定のケースでは強く推奨されます。以下の 2つの理由から、フロアプラン・ロケーションの計画は、フル・インクリメンタル・コンパイルを使用するデザインにとって重要になります。

■ パーティション間でリソースの衝突を回避するため（主としてボトムアップ・フローで）



■ トップダウン・フローで、個々のパーティションをリコンパイルする場合に、高品質の結果を保証するため

トップダウン・コンパイル・フローでは、タイミング・クリティカルでないロジックはデバイス中を移動できるため、フロアプラン・アサインメントが不要になる場合があります。

分割したデザインにフロアプランを作成する最も簡単な方法は、パーティションごとに（トップレベルのパーティションを含めて）LogicLockレジスタを 1つ作成することです。最初は、各領域に自動サイズおよび非固定位置にデフォルト設定を使用し、Quartus IIソフトウェアがそれらの領域の最適なサイズおよび位置を決定できるようにします。次に、コンパイル後に、Fitterで決定されたサイズおよび元の位置をデザイン・フロアプランの開始点として使用します。フロアプランのロケーション・アサインメント用に取得した結果の品質をチェックし、必要に応じて領域を変更します。あるいは、合成を実行し、続いて領域をリソースの見積もりに基づく必要なサイズに設定することもできます。この場合、パーティション間の接続に関する知識を活用して、領域をフロアプランに配置してください。

初期フロアプランを作成したら、Quartus II ソフトウェアのツールを使用して領域を改良することができます。子の LogicLock領域をネスティングさせることによって、非矩形領域を作成するといった高度な手法を使用することも可能です。

デザイン・フロアプランの作成が重要になる時期およびフロアプランの作成ガイドラインについて詳しくは、「Quartus IIハンドブック Volume 1」の「Best Practices for Incremental Compilation Partitions and Floorplan」の章を参照してください。

2–61ページの「Incremental Compilation Advisor」で説明する IncrementalCompilation Advisorを使用して、LogicLock領域がアルテラのガイドラインに準拠しているかどうかチェックできます。

各デザイン・パーティションに LogicLock領域を作成するには、以下の一般的な手法を使用します。

1. Assignment メニューの Design Partitions Window をクリックし、すべてのパーティションの Netlist Type が Source または Post-Synthesisに設定されているか確認します。Netlist Typeが Post-Fitに設定されている場合、デザインのリコンパイル時にフロアプラン・ロケーション・アサインメントは使用されません。




2. 以下のいずれかの方法を使用して、各パーティション（自動的にパーティションとみなされるトップレベルのエンティティを含む）に対して、LogicLock領域を作成します。

● Toolsメニューで、Design Partition Plannerをクリックします。パーティションを表す色付きボックス内でパーティションを右クリックし、Create New LogicLock Regionをクリックします。Design Partitions ウィンドウのパーティションを右クリックし、Create New LogicLock Regionをクリックします。

● Project NavigatorのCompilation Hierarchy内で、パーティションとして表示されている各インスタンスを右クリックし、Create New LogicLock Region をクリックします。DesignPartitions ウィンドウでパーティションの行を右クリックし、Create New LogicLock Regionを選択します。

これらのいずれの方法でも、Ctrlキーを押したまま各パーティションをクリックして、複数（またはすべての）パーティションをハイライトすることができます。次に、ハイライトされた各パーティションに LogicLock領域を作成するためのオプションを選択できます。

Project Navigatorの LogicLock領域として設定された各インスタンスの横に、LogicLock 領域のアイコンが表示されます（図 2–9）。

図 2–9. LogicLock領域を示す Project Navigator



3. 自動サイズの非固定位置LogicLock領域を配置するには、Processingメニューの Start をポイントし、Start Early Timing Estimate をクリックします。

Early Timing Estimateを実行する前に、Analysis & Synthesisおよび Partition Mergeを実行する必要があります。

Early Timing Estimateの代わりにフル・コンパイルを実行するには、Processing メニューの Start Compilation をクリックします。

4. Assignments メニューの LogicLock Regions Window をクリックし、Ctrlキーを押したまま、各 LogicLock領域をクリックし、（トップレベルの領域を含む）すべての領域を選択します。

5. 最後に選択したLogicLock領域を右クリックし、Set Size and Originto Previous Fitter Resultsをクリックします。

Fitter で選択されたロケーションは開始点としてのみ使用し、固定サイズおよび固定位置の領域を作成します。一般に、サイズと位置が固定された領域は、自動サイズの領域よりも fMAXが改善されます。

領域の内容はバック・アノテーションしないで、サイズと原点を保存してください。バック・アノテーションされたコンテンツ・アサインメントではなく、フィッティング後のネットリストを使用して配置を維持します。

6. 必要に応じて、LogicLock Regions Window または Chip Plannerを使用してサイズと位置を変更します。例えば、領域を拡大してデバイスの容量を増やし、将来のロジック変更を可能にすることができます。

7. 上記の LogicLock領域を使用してデザインのタイミング性能を見積もるには、Processing メニューの Start をポイントし、Start EarlyTiming Estimateをクリックします。

8. デザイン・フロアプランの結果の品質に満足するまで、ステップ 6とステップ 7繰り返します。

9. Processing メニューの Start Compilation をクリックして、フル・コンパイルを実行します。



自動サイズおよび非固定位置領域を使用しない場合は、ステップ 3–5で、合成後の領域のサイズを見積もることができます。Processingメニューの Start をポイントして、 Start Analysis & Synthesis を選択します。LogicLock Regionsダイアログ・ボックスの領域を右クリックし、Set toEstimated Sizeを選択します。次に、ステップ 6に進み、必要に応じて各領域のサイズと原点を変更します。

Early Timing Estimatorの利用優れたフロアプランを作成する方法では、Early Timing Estimator を活用して、アサインメントを作成する間にデザインを迅速にコンパイルできるようにしています。Early Timing Estimator 機能は、フル・コンパイルを実行する場合よりも 45倍速い速度で、デザインのタイミングを見積もりますが、平均では最終的なデザインのタイミングの 11%以内と推定されます。Chip Planner を使用すると、この Early Timing Estimatorで作成した“配置見積もり”を表示し、タイミング解析レポートからクリティカル・パスを特定し、必要に応じてフロアプランの制約を追加または変更することができます。次に、Early Timing Estimator を再実行してフロアプラン・ロケーション・アサインメントまたはロジック変更の影響をすばやく評価し、デザイン・バリエーションでの迅速なイタレーションを可能にして、最良のソリューションを見つけるよう支援します。この高速な配置は結果の品質に影響を与えます。デザインのイタレーションで最高品質の結果を得ることが重要な場合は、Early TimingEstimate 機能を使用しないで、Fitter によるフル・コンパイルを実行します。

どの LogicLock領域の変更が再フィッティングを実行するか2–35ページの「パーティションの自動再合成を実行するのはどのような変更でしょうか？」で説明するとおり、Netlist Type および FitterPreservation Levelの設定でFitterの結果を維持するよう指定されている場合、ほとんどのアサインメントの変更ではパーティションのリコンパイルは実行されません。例えば、ピン・アサインメントを変更してもリコンパイルは実行されないため、Netlist Type を Post-Synthesis またはSource Fileに変更しない限り、デザインで新しいピン・アサインメントは使用されません。

同様に、パーティションの配置が維持される場合、またパーティションが LogicLock 領域に割り当てられる場合、Fitter は常にフィッティング後ネットリストに指定された対応する LogicLock領域のサイズを再使用します。すなわち、Post-Fit Netlist Type 設定またはフィッティング後


ボトムアップ・デザイン・フローのためのパーティションのエクスポートとインポート

の情報を含むインポートされたパーティションでパーティションの配置が維持される場合は、LogicLock Size設定を変更しても再フィッティングは実行されません。

ただし、LogicLock の Origin 位置アサインメントを使用して、以前のFitterの結果を変更するか微調整することができます。ある領域のOrigin設定を変更すると、Fitter は当該領域のメンバーに対してどのように配置が維持されるかに応じて、以下の方法で領域を移動することができます。

■ 新しい領域の原点を設定すると、Fitter は新しい原点を使用し、ロジックを再配置して、メンバー・ロジックの相対的な配置を維持します。

■ 領域の原点を可動に設定すると、以下の条件が適用されます。● 領域のメンバーの配置がインポートされたパーティションで維持された場合、Fitter は新しい原点を選択し、ロジックを再配置して、領域内のメンバー・ロジックの相対的な配置を維持します。

● 領域のメンバーの配置が Post-Fit Netlist Type で維持された場合、Fitter は原点の位置を変更しないで、前の配置の結果を再使用します。


ボトムアップ・フローとは、1 つのプロジェクトが最初に小さなサブデザインに分割され、これらを別の設計者が個別プロジェクトとして実装できるデザイン手法のことです。これら下位レベルのプロジェクトのコンパイル結果は、エクスポートされて設計者（すなわち、プロジェクト・リーダー）に渡され、この設計者がトップレベルのプロジェクトへのインポート、および完全に機能するデザインの作成に責任を負います。

ボトムアップ・デザイン・フローでは、トップレベルのプロジェクト・リーダーはデザイン計画の大部分を行ってから下位レベル・ブロックの設計者に制約を渡すことができます。Quartus II ソフトウェアで生成されるボトムアップ・デザイン・パーティション・スクリプトにより、ボトムアップ・デザインの計画が容易になり、個別のデザインを統合する際に生じる問題を限定できる可能性があります。詳細は、2–52ページの「プロジェクト管理のためのボトムアップ・デザイン・パーティションのスクリプトの生成」を参照してください。

フロー全体の概要については、クイック・スタート・ガイドの 2–14ページの「ボトムアップ・インクリメンタル・コンパイル」の項を参照してください。チーム・ベースのシナリオの例については、2–69 ページの「チーム・ベースのボトムアップ・デザイン・フローの実行」を参照してください。2–80ページの「インクリメンタル・コンパイルの制約」で説明するとおり、Quartus II ソフトウェアのボトムアップ・フローに関連するその他の制限があります。



この項では、ボトムアップ・コンパイル・フローをサポートするエクスポートおよびインポート機能について説明します。この項では、以下の内容について説明します。

■ 「Quartus II Exported Partitionファイル」■ 2–44ページの「トップレベル・プロジェクトで使用される下位レベル・パーティションのエクスポート」

■ 2–47ページの「プロジェクト内の下位レベル・ブロックのエクスポート」

■ 2–48ページの「下位レベル・パーティションのトップレベル・プロジェクトへのインポート」

■ 2–49ページの「アサインメントおよび高度なインポート設定のインポート」

■ 2–52ページの「プロジェクト管理のためのボトムアップ・デザイン・パーティションのスクリプトの生成」

Quartus II Exported Partitionファイルボトムアップ・インクリメンタル・コンパイル・フローでは、QuartusII Exported Partition（.qxp）ファイルを使用して、下位レベルのデザイン・パーティションを表します。.qxpファイルは、エクスポートされたデザイン・パーティションのコンパイル結果を含むバイナリ・ファイルで、フィッティング後または合成後のネットリスト、LogicLock 領域、および一連のアサインメントが含まれます。.qxpファイルには、下位レベル・デザインのオリジナル・ソース・デザイン・ファイルは含まれていません。

以下の項では、下位レベル・デザイン・パーティション用の .qxpファイルの生成方法、および .qxpファイルをトップレベル・プロジェクトにインポートする方法について説明します。

トップレベル・プロジェクトで使用される下位レベル・パーティションのエクスポート下位レベルの各サブデザインは、個別の Quartus IIプロジェクトとしてコンパイルされます。各プロジェクトで、以下のガイドラインに従ってエクスポートおよびインポート・プロセスを改善します。

■ トップレベルからのボトムアップ・デザイン・パーティション・スクリプトがある場合、Tclスクリプトを使用してトップレベル・デザインからプロジェクトおよびすべてのアサインメントを作成します。これにより、以下で説明するアサインメントの多くを作成できます。LogicLock 領域が、トップレベルのプロジェクト・リーダーによって割り当てられたリソースのみ使用していることを確認します。



■ トップレベルのデザインでリソース衝突が生じないように、グローバル配線リソースにどのクロックを割り当てるかを認識していることを確認します。詳細は、「Quartus II ハンドブック Volume 1」の「Best Practices for Incremental Compilation Partitions and Floorplan

Assignments」を参照してください。● グローバル配線ラインへの配線が必要な高ファンアウト信号については、Global Signalアサインメントを Onにします。

● グローバル配線ラインに他の信号が配置されないように、Assignmentsメニューの Settingsをクリックし、Settingsダイアログ・ボックスの Fitter ページの More Settings で、AutoGlobal Clock and Auto Global Register Controlsをオフにします。

● または、グローバル配線ラインへの配置が不要な信号については、Global Signal アサインメントを Off に設定できます。また、LABの配置は、LAB内のロジック・セルへの入力でグローバル・クロックが使用されるかどうかに依存します。下位レベルのデザインでグローバル・ラインを使用せず、トップレベルのデザインでグローバル配線を使用する信号の場合、問題が発生する可能性があります。

■ トップレベル・デザインでピンをドライブしないサブデザインのピンを指定する場合は、Virtual Pinアサインメントを使用します。これは、サブデザインにターゲット・デバイスで使用できるピン数よりも多い出力ポートがある場合は重要です。仮想ピンの使用は、ロケーション・アサインメントやタイミング・アサインメントなど、サブデザインのポートに関する情報をより多く提供できるため、完全なデザインでパーティションをまたがるパスを最適化するのにも役立ちます。

■ サブデザインは互いの情報なしに個別にコンパイルされるため、トップレベル・デザインで他のパーティションから影響を受ける可能性のあるタイミング・パスについて、より多くの情報を提供する必要があります。トップレベルのデザインに組み込まれた後、ポート接続をどこに配置するかを指定するために、各ピンにロケーション・アサインメントを適用することができます。また、説明するタイミング・バジェットを実行するために、サブデザインの I/Oポートにタイミング・アサインメントを適用することも可能です。

タイミング・バジェットの作成について詳しくは、「Quartus II ハンドブック Volume 1」の「Best Practices for Incremental CompilationPartitions and Floorplan Assignments」を参照してください。








上記のガイドラインに基づいてサブデザインのパーティションがコンパイルされ、トップレベルのデザインに組み込む準備が整ったら、以下のステップに従って、サブデザインをパーティションとしてエクスポートします。

1. サブデザイン・プロジェクトで、以下の方法のいずれかを使用してExport Design Partitionダイログ・ボックスを開きます。

● Design Partition Planner（Toolメニューから使用可能）で、パーティションを表す色付きボックス内でパーティションを右クリックし、Export Design Partitionをクリックします。

● Projectメニューの Export Design Partitionをクリックします。

2. Export fileボックスで、.qxpのファイル名を入力します。デフォルトでは、ディレクトリ・パスとファイル名は現在のプロジェクト名になります。

3. Partition hierarchy to exportを選択することもできます。デフォルトでは、Topパーティション（プロジェクト全体）がエクスポートされますが、2–47ページの「プロジェクト内の下位レベル・ブロックのエクスポート」で説明するように、プロジェクトの任意のパーティション階層のコンパイル結果をエクスポートするように選択することもできます。プルダウン・リストからパーティション階層を選択します。

4. Netlist to export で、Post-fit netlist か Post-synthesis netlist を選択します。デフォルトは Post-Fit netlistです。フィッティング後のネットリストの場合、必要に応じて Export routingオプションをオンまたはオフにします。

5. OK をクリックします。Quartus II ソフトウェアにより、指定されたディレクトリに .qxpファイルが作成されます。

あるいは、デザインをコンパイルするたびにエクスポート・プロセスが実行されるようにプロジェクトを設定することもできます。

1. Assignmentsメニューの Settingsをクリックします。

2. Settingsダイアログ・ボックスの Compilation Process Settingsで、Incremental Compilationページを選択します。

3. Automatically export design partition after compilation をオンにします。



4. デフォルトのエクスポート設定を表示または変更する場合、ExportDesign Partition Settingsボタンをクリックします。

5. Export Design Partition Settingsダイアログ・ボックスで、上記のエクスポート手順のステップ 2-4 に従い、必要に応じて設定を変更します。OKをクリックします。

6. OK をクリックして、Settings ダイアログ・ボックスを閉じます。次のフル・コンパイル時に、Quartus II ソフトウェアにより、指定されたディレクトリに .qxpファイルが作成されます。

プロジェクト内の下位レベル・ブロックのエクスポート「トップレベル・プロジェクトで使用される下位レベル・パーティションのエクスポート」のステップ 3 を実行して、Quartus II プロジェクト内の下位レベル・ブロック用の .qxpファイルを作成できます。これを行うと、コマンドにより指定したパーティションの階層全体が .qxpファイルにエクスポートされます。

この機能を使用して、トップレベル・デザインのデザイン・パーティションとしてエクスポートされる下位レベル・ブロック周辺にテスト・ロジックを追加することができます。また、トップレベル・デザイン環境に適合するよう、下位レベル・プロジェクトで追加デザイン・コンポーネントをインスタンス化することも可能です。例えば、トップレベル PLLを下位レベル・プロジェクトに含めて、周波数マルチプライヤ、位相シフト、補正遅延、およびその他の PLLパラメータに関する情報によってデザインを最適化することができます。ソフトウェアは次に、下位レベル・プロジェクトでタイミング解析が確実に完了し正確な結果が得られるようにしながら、タイミングおよびリソース要件をより正確にキャプチャします。補助コンポーネントをエクスポートしないで、下位レベル・パーティションをトップレベル・デザインにエクスポートすることができます。

さらに、この機能をトップダウン・デザイン・フローで使用して、完成した特定のデザイン・パーティション用の .qxpファイルを作成することができます。次に、以下の項で説明するとおり、.qxp ファイルをプロジェクトにインポートして Imported ネットリスト・タイプを使用することができます。ここで、.qxpファイルは 1つのファイルにネットリストと配置配線情報を含むパーティションのアーカイブとして機能します。パーティションのソース・コードを変更する場合は、ネットリスト・タイプを Source File に戻して、インポートされた情報の代わりにソースを使用しなければなりません。



下位レベル・パーティションのトップレベル・プロジェクトへのインポートインポート・プロセスには、.qxpファイルからのデザイン・ネットリストのインポートと、トップレベル・プロジェクトのデータベースへのネットリストの追加が含まれます。また、インポートにより、サブデザインからのアサインメントがフィルタされ、トップレベル・プロジェクトに適切なアサインメントが作成されます。

サブデザイン・パーティションをトップレベル・デザインにインポートするには、以下のステップを実行します。

1. トップレベル・プロジェクトで、以下の方法のいずれかを使用してImport Design Partitionダイログ・ボックスを開きます。

● Design Partition Plannerで、パーティションを表す色付きボックス内でパーティションを右クリックし、Import DesignPartitionをクリックします。

● Design Partitions ウィンドウでインポートするパーティションを右クリックし、Import Design Partitionをクリックします。

● Projectメニューの Import Design Partitionをクリックします。

2. Partition(s)ボックスで、必要なパーティションを表示します。パーティションを選択するには、Select Partition(s)ダイアログ・ボックスでパーティション名をハイライトし、適切なボタンを使用して該当するパーティションを選択または選択解除します。

トップレベルのデザインに、サブデザイン・パーティションの複数のインスタンスが含まれ、インポートされた同じネットリストを使用する場合は、複数のパーティションを選択できます。

3. Import file で、.qxp ファイルの名前を入力するか、選択したパーティションにインポートするファイルを参照します。このファイルはインポート中にのみ必要で、パーティションを再インポートしない限り、以降のコンパイルでは使用されません。



このパーティションに1回以上 .qxpファイルをインポートしている場合、ファイル名を再度指定しないで、前回のインポートと同じロケーションを使用できます。このためには、Reimport using the latest import files at previouslocationsをオンにします。このオプションは、すでに 1回以上インポートしている複数のパーティションに、新しいQuartus II Exported Partitionファイルをインポートする場合に特に役立ちます。Partitionボックスで、インポートするすべてのパーティションを選択し、Reimport usinglatest import files at previous locationsオプションを使用して、個々のファイル名を指定しないで、前回のロケーションを使用してすべてのパーティションをインポートすることができます。

4. 選択した .qxpファイルの内容を表示するには、Load Propertiesをクリックします。表示されるプロパティには、Netlist Type、Entityname、Device、およびパーティション・サイズとポートに関する統計が含まれます。

5. Advanced Import Settingsをクリックし、適宜に選択を行い、サブデザインのアサインメントと領域をトップレベルのデザイン・パーティションに統合する方法を制御します。インポート中に、一部の領域のサイズが変更されたり、わずかに移動する場合があります。OKをクリックして、設定を適用します。

高度な設定について詳しくは、2–49ページの「アサインメントおよび高度なインポート設定のインポート」を参照してください。

6. インポートを開始するには、Import Design Partitionダイアログ・ボックスで、OKをクリックします。指定した .qxpファイルが、現在のトップレベル・プロジェクトのデータベースにインポートされます。

アサインメントおよび高度なインポート設定のインポートサブデザイン・パーティションをトップレベル・デザインにインポートする場合、デフォルトでは特定のアサインメントが設定され、サブデザインからトップレベル・デザインに関連するアサインメントがインポートされます。

インポート後のデザイン・パーティションのプロパティ

サブデザイン・パーティションをインポートするとき、インポート・プロセスによりパーティションのネットリスト・タイプが Imported に設定されます。



デザインをコンパイルし、配置配線結果に変更を加える場合は、以降のコンパイルでネットリスト・タイプに Post-Fit (Import-based)を使用します。インポートしたネットリストを廃棄し、ソース・コードからリコンパイルするには、ネットリスト・タイプを Source Fileに設定してパーティションをコンパイルし、必ずトップレベル・プロジェクトに関連するソース・コードをインクルードします。

インポート・プロセスにより、パーティションの Fitter Preservation Levelが、インポートされたネットリストでサポートされる最高レベルの維持に設定されます。例えば、フィッティング後のネットリストが配置情報とともにインポートされる場合、レベルはPlacementに設定されますが、これをNetlist Only値に変更できます。

Netlist Typeと Fitter Preservation Levelの設定について詳しくは、2–28ページの「デザイン・パーティションの Netlist Typeの設定」を参照してください。

サブデザイン内のデザイン・パーティション・アサインメントのインポート

サブデザイン・プロジェクト内で定義されたデザイン・パーティション・アサインメントは、トップレベル・プロジェクトにインポートされません。サブデザインのすべてのロジックは、1 つのパーティションとして.qxpファイルにインポートされます。

Quartus II TimeQuestタイミング・アナライザの Synopsys Design Constraintsファイル

Synopsys Design Constraint（.sdc）ファイルの Quartus II TimeQuestタイミング・アナライザ用のタイミング・アサインメントは、トップレベル・プロジェクトにインポートされません。トップレベル・プロジェクトに、プロジェクト全体のタイミング要件がすべて含まれていることを手動で確認します。

下位レベルの .sdcファイルをトップレベル・プロジェクトにコピーする場合、デザイン階層の変数により下位レベルの制約にプリフィックスを付けることを検討してください。また、ファイルをトップレベル・デザインにコピーする場合は、トップレベル・デザインの下位レベル・パーティションに階層パスが提供されるように変数を設定できます。

LogicLockアサインメントのインポート

LogicLock 領域は、インポート時に固定サイズに設定されます。トップレベル・デザインでサブデザインの複数のインスタンスをインスタンス化する場合、インポートされる LogicLock領域は非固定位置に設定され



ます。それ以外の場合は、固定位置に設定されます。LogicLock 領域のロケーションはインポート後に変更できます。あるいは、非固定位置に変更して、ソフトウェアが各領域を配置しても、可能な限り領域内のノードの相対位置を維持可能なようにすることができます。コンパイル後にパーティションに行った変更を維持するには、Netlist Type Post-Fit(Import-Based)を使用します。

LogicLock Member Stateアサインメントは Lockedに設定され、維持された領域であることを表します。

LogicLock バック・アノテーションおよびノード・ロケーションのデータは、Quartus II Exported Partitionファイルに関連するすべての配置情報が含まれているためインポートされません。アルテラでは、インポートされた LogicLock領域のメンバの追加や削除を行わないように強く推奨しています。

その他のインスタンス・アサインメントのインポート

これまでに説明したように、デザイン・パーティション・アサインメント、SDC制約、および LogicLockアサインメントを除き、すべてのインスタンス・アサインメントがインポートされます。

グローバル・アサインメントのインポート

グローバル・アサインメントはインポートされません。プロジェクト・リーダーは、トップレベル・デザインでグローバル・アサインメントを行う必要があります。Quartus II クラシック・タイミング・アナライザのクロック設定はグローバル・アサインメントであり、インポートされません。

高度なインポート設定

Advanced Import Settingsダイアログ・ボックスでは、アサインメントと領域を統合する方法と、サブデザイン・パーティションをトップレベル・デザインにインポートするときのアサインメントの衝突を解決する方法のオプションを指定できます。これらのオプションについては、それぞれ以下の項で説明しています。

Allow Creation of New Assignmentsインポート・コマンドにより、インポートされたプロジェクトの新しいアサインメントをトップレベル・プロジェクトに追加できます。

このオプションをオフにすると、既存のアサインメントはインポートされますが、新しいアサインメントはインポートできません。



Promote Assignments to all Instances of the Imported Entityサブデザインのエンティティ・レベルのアサインメントを変換し、トップレベル・デザインのインスタンス・レベルのアサインメントにプロモートします。

Assignment Conflict Resolution: LogicLock領域以下のオプションのいずれかを選択して、衝突する LogicLockアサインメント（すなわち、トップレベル・アサインメントに一致しないサブデザイン・アサインメント）を処理する方法を指定します。

■ Always replace regions in the current project（デフォルト）—既存の領域を削除し、新しいサブデザイン領域に置き換えます。アサインメントのインポート後に LogicLock領域に行った変更もすべて削除されます。

■ Always update regions in the current projects—新しいサブデザインのアサインメントを反映して、既存の領域アサインメントを上書きしますが、プロジェクト・リーダーがトップレベル・デザインで、フロアプラン・ロケーション・アサインメントを行っている場合は、LogicLockの原点は上書きから除外されます。

■ Skip conflicting regions—トップレベル・デザインに存在するアサインメントと衝突するサブデザイン・アサインメントを無視し、インポートしません。

アサインメント競合の解消：その他のアサインメント以下のオプションのいずれかを選択して、他のタイプのアサインメントとの衝突（すなわち、サブデザイン・アサインメントがトップレベル・アサインメントと一致しない）を処理する方法を指定します。

■ Always replace assignments in the current project（デフォルト）—既存のインスタンス・アサインメントを新しいサブデザイン・アサインメントで上書きするか更新します。

■ Skip conflicting assingments—トップレベル・デザインに存在するアサインメントと衝突するサブデザイン・アサインメントを無視し、インポートしません。

プロジェクト管理のためのボトムアップ・デザイン・パーティションのスクリプトの生成ボトムアップ・デザイン・パーティションのスクリプトは、トップレベル・プロジェクト情報の下位レベル・モジュールへの転送プロセスを自動化します。Quartus II ソフトウェアには、トップレベル・デザインでリソースおよびタイミング・バジェットを管理するためのインタフェースが備わっています。このインタフェースを使用すると、下位レベル・モジュールの設計者は、容易にプロジェクト・リーダーからの指示を実装でき、またプロジェクトをトップレベル・デザインにインポートおよ



び組み込むときに、プロジェクト間の衝突を回避できるようになります。これによって、統合後にデザインをさらに最適化する必要性が低減され、設計者の生産性とチーム・コラボレーションが全体的に改善されます。

ボトムアップ・デザイン・パーティションのスクリプトの生成は、ボトムアップ・デザイン手法ではオプションです。

これらのスクリプトを使用したデザイン・シナリオ例については、2–69ページの「チーム・ベースのボトムアップ・デザイン・フローの実行」を参照してください。通常のボトムアップ・デザイン・フローでは、プロジェクト・リーダーはサブプロジェクトの統合を成功させるために、以下のタスクの一部またはすべてを実行する必要があります。

■ どのアサインメントをトップレベルからボトムレベルに伝播するかを手動で指定します。これには、下位レベル・プロジェクトのセットアップに必要な Quartus IIアサインメントに関して、詳細な知識が必要になります。

■ トップレベル・アサインメントを下位レベル・プロジェクトに手動で伝達します。これには、プロジェクトの制約を効率的に伝達するために、Tcl またはその他のスクリプト言語の詳細な知識が必要です。

■ ボトムアップ・デザインの制約の克服に役立つ、適切なタイミング・アサインメントおよびロケーション・アサインメントを手動で指定します。これには、下位レベルでロジックを調べ、適切なタイミング制約を決定する作業が必要になります。

■ 最終的なタイミング・クロージャとリソース衝突回避策をトップレベルで実行します。下位レベルのプロジェクトには互いに関する情報がないため、下位レベルで制約を満たしても、トップレベルでの統合時に同じ制約が満たされる保証はありません。この場合、下位レベルの実装に関する情報が入手できない場合でも、プロジェクト・リーダーが責任を持って問題の解決にあたることになります。

Quartus II ソフトウェアを使用してトップレベルのデザインからボトムアップ・デザイン・パーティションのスクリプトを生成すると、これらのタスクが容易になり、プロジェクト・リーダーと下位レベルの設計者の対話で誤りが発生する機会も減少します。パーティション・スクリプトがトップレベル・デザインで作成されたアサインメントに渡されると、配置の手引きとなる新しいアサインメントがいくつか作成され、デザインが他のパーティションに接続されるプロセスを下位レベルの設計者が確認するのを支援します。必要に応じて、特定のデザイン・パーティションを除外することができます。

デザイン・パーティションのスクリプトは、トップレベル・デザインのコンパイルが成功した後で生成されます。Project メニューの GenerateBottom-Up Design Partition Scriptsをクリックします。デザインには下



位レベル・ブロックのプレースホルダとして、空のパーティションが含まれている場合があり、フル・コンパイルの代わりに Early TimingEstimationを実行して、コンパイル時間を短縮することができます。

以下の項で、ボトムアップ・デザイン・パーティションの Tcl スクリプトに含めることができる情報について説明しています。GenerateBottom-Up Design Partition Scriptsダイアログ・ボックスのオプションを使用して、下位に渡し、下位レベル・パーティションのプロジェクトで作成するアサインメントのタイプを選択します。スクリプト生成プロセスを再実行するたびに、Quartus II ソフトウェアはファイルを再作成して、古いバージョンを置き換えます。

ボトムアップ・パーティション・スクリプトの現在の制約については、2–91ページの「ボトムアップ・デザイン・パーティションのスクリプトの制限」を参照してください。

プロジェクトの作成

パーティション・スクリプトに Create lower-level project if one doesnot existオプションを使用すると、必要に応じて下位レベル・プロジェクトを作成できます。下位レベルの各プロジェクトの Quartus II プロジェクト・ファイルには、対応するデザイン・パーティションのエンティティ名と同じ名前が付けられています。

このプロジェクト作成機能により、スクリプトは自ら動作して新しいプロジェクトを作成したり、既存のプロジェクトでアサインメントを作成するためのソースとして使用できます。

除外されるパーティション

ダイアログ・ボックス下部の Excluded partition(s)オプションを使用すると、Tclスクリプト生成プロセスから特定のパーティションを除外できます。ブラウズ・ボタンを使用して Select Partition(s)ダイアログ・ボックスでパーティション名をハイライトし、適切なボタンを使用して該当するパーティションを選択または選択解除します。

トップレベル・デザインからのアサインメント

デフォルトでは、トップレベルで行われたアサインメント（デフォルト・アサインメントやプロジェクト情報アサインメントは含まない）は、スクリプトで適切な下位レベル・プロジェクトに渡されます。ソフトウェアはアサインメント変数を使用し、アサインメントが関係するロジカル・パーティションを決定します。これには、グローバル・アサインメント、インスタンス・アサインメント、エンティティ・レベルのアサインメントが含まれます。次に、ソフトウェアはアサインメントを変更し、トッ



プレベル・エンティティとしてターゲット・パーティションのロジックを持つプロジェクトで、変更後のアサインメントが構文上有効になるようにします。

特定のパーティションに適用されるデザイン・ファイルの名前が下位レベルの各プロジェクトに追加されます。スクリプトでは、トップレベル・プロジェクトで指定されたファイル名が使用されます。トップレベル・プロジェクトで、下位レベル・プロジェクトのデザイン・ファイルとは異なる名前のプレースフォルダ・ラッパー・ファイルが使用された場合、必ず適切なファイルを下位レベル・プロジェクトに追加する必要があります。

スクリプトはワイルドカード・アサインメントを正しく処理しますが、使用するワイルドカードは 1つのみとします。複数のワイルドカードを使用したアサインメントは無視され、ワーニング・メッセージが発行されます。

以下のオプションを使用して、下位レベル・プロジェクトに渡すアサインメントのタイプを指定します。

■ Timing assignments—このオプションをオンにした場合、tCO、tSU、fMAXの各制約を含め、下位レベル・プロジェクトのクラシック・タイミング・アナライザのすべてのグローバル・タイミング・アサインメントがスクリプトに含まれます。さらに、TimeQuest .sdcファイルが下位レベル・プロジェクトに渡され、クロック制約と最小または最大遅延を提供します。このオプションで、内部パーティション接続のタイミング制約を含めることもできます。

■ Design partition assignments—このオプションをオンにすると、下位レベル・プロジェクトのデザイン・パーティションに関連するスクリプト・アサインメントと、LogicLock 領域に関連するアサインメントが含まれます。

■ Pin location assignments—このオプションをオンにすると、トップレベル・デザインのピンに接続される下位レベル・プロジェクト・ポートのすべてのピン・ロケーション・アサインメントがスクリプトに含まれ、統合フェーズでのトップレベルの I/Oの過剰使用を制御し、配置を維持します。



仮想ピン・アサインメントWhen Create virtual pins at low-level ports connected to other designunits をオンにした場合、Quartus II ソフトウェアはパーティション・ネットリストを検索し、パーティション間で依存性を持つすべてのポートを識別します。別のパーティションまたはトップレベル・プロジェクトの内部ポートに関連付けられる下位レベル・プロジェクトの各ピンについて、スクリプトは仮想ピン・アサインメントを生成し、より正確な配置を維持します。これは仮想ピンがトップレベル・プロジェクトの I/Oポートに直接接続されないためです。これらのピンは、トップレベル・デザインに下位レベルのネットリストがインポートされると、このリストから削除されます。

仮想ピンのタイミングおよびロケーション・アサインメントボトムアップ・デザイン手法の大きな問題の 1 つは、個々のデザイン・ブロックに他のデザイン・ブロックへの接続方法に関する情報が含まれていないことです。仮想ピン・アサインメントを記述するオプションをオンにした場合、これらの仮想ピンを制約するオプションをオンにし、下位レベル・パーティションがトップレベルで統合された後にタイミング性能を向上させることができます。

Place created virtual pins at location of at top-level source/sinkをオンにすると、スクリプトは作成された各仮想ピンに対するロケーション制約をインクルードします。仮想出力ピンがトップレベル・プロジェクトの接続先のロケーションに割り当てられ、仮想入力ピンがトップレベル・プロジェクトの接続元のロケーションに割り当てられます。トップレベル・デザインが空のパーティションを使用している場合、接続の最終的なロケーションは不明ですが、ピンは接続元または接続先を含むLogicLock領域に割り当てられたままです。

その結果、これらの仮想ピンは下位レベル・プロジェクトの LogicLock領域内に配置されなくなりますが、トップレベル・デザインのそれぞれの位置に配置され、下位レベル・プロジェクトのリソース消費が排除され、下位レベル・プロジェクトとそのポート依存性に関するより多くの情報が提供されます。これらのロケーション制約は、トップレベル・プロジェクトにインポートされません。

Add maximum delay to/from created virtual pinsまたはAdd maximumdelay from created virtual output pins、あるいはこれらの両方をオンにすると、作成された各仮想ピンのタイミング制約がスクリプトに含まれます。ダイアログ・ボックスに入力する値は、仮想ピン間のすべてのパスに許容される最大遅延であり、完全なデザインのタイミング要件を満足するのに役立ちます。制約を適用するために、INPUT_MAX_DELAYアサインメントまたは OUTPUT_MAX_DELAYアサインメントが使用されます。



このオプションにより、プロジェクト・リーダーはすべての下位レベルの内部ピン接続に一般的なタイミング・バジェットを指定できます。下位レベルの設計者は、必要に応じて特定のピンにノード・レベルのアサインメントを個別に適用して、上記の制約を上書きできます。

LogicLock領域アサインメント

Copy LogicLock region assignments from top-levelをオンにした場合、スクリプトには、パーティションの LogicLockアサインメントを識別するアサインメントが含まれます。

スクリプトはまた、他のすべてのパーティションに LogicLock領域を作成するアサインメントを渡すこともできます。Include all LogicLockregions in lower-level projectsをオンにした場合、各パーティションのスクリプトには、トップレベル・プロジェクトと下位レベルの各パーティションのすべての LogicLock領域アサインメントが含まれ、各パーティションでの完全なデザインのフロアプランを明示します。他のパーティションに属しない領域には、パーティション間接続の接続元と接続先のポートを表す仮想ピンが含まれます。これによって、各設計者はトップレベルのデザインで、各設計者のパーティションと他のパーティションの接続性をより簡単に確認できるようになるため、トップレベルでのリソース衝突を最小限に抑えるのに役立ちます。

Remove existing LogicLock regions from lower-level projectsをオンにした場合、スクリプトにはスクリプトの実行前に下位レベルのプロジェクトで定義された LogicLock領域を削除するコマンドが含まれます。これにより、トップレベル・プロジェクトに含まれない LogicLock領域が完全なデザインの一部になることはなく、下位レベルのデザインにトップレベルで指定された LogicLock領域を使用させるようにして、ロケーションの衝突を回避します。

グローバル信号プロモーション・アサインメント

プロジェクトをトップレベル・デザインにインポートするときに、グローバル信号の使用が衝突しないように、信号を下位レベル・パーティションのグローバル配線リソースにプロモートする方法を制御するアサインメントを記述するよう選択できます。これらのオプションは、グローバル配線リソースのリソース・バランシングに役立つ場合があります。

Promote top-level global signals in lower-level projectsをオンにした場合、Quartus IIソフトウェアはパーティション・ネットリストを検索し、クロック信号を含むグローバル・リソースを識別します。次にスクリプトには、関連するパーティションについてのグローバル信号プロモーション・アサインメントがインクルードされ、グローバル・リソース割り当てに関する情報が下位レベルのプロジェクトに提供されます。



Disable automatic global promotion in lower-level projects をオンにした場合、スクリプトには下位レベル・プロジェクトのすべての自動グローバル・プロモーション設定オフにするアサインメントが含まれます。これらの設定には、Auto Global Memory Control Signalsロジック・オプション、出力イネーブル・ロジック・オプション、クロックおよびレジスタ・コントロール・プロモーションが含まれます。Promote top-levelglobal signals in lower-level projects オプションと同時に Disableautomatic global promotion in lower-level projectsオプションを選択した場合、トップレベルのグローバル・リソースにプロモートされた信号のみが下位レベル・プロジェクトでプロモートされます。

makefileの生成

makefileを生成した場合、コンピュータにmakeユーティリティをインストールしていれば、make コマンドによりボトムアップ・プロジェクトを最新の状態に維持できます。 Generate makefiles to maintainlower-level and top-level projects オプションを選択した場合、トップレベル・デザインの各デザイン・パーティションに makefile が作成され、さらに下位レベル・プロジェクトのmakefileを実行できるマスターmakefileも作成されます。Quartus IIソフトウェアは、マスターmakefileをトップレベル・ディレクトリに配置し、パーティションmakefileを下位レベル・プロジェクトの対応するディレクトリに配置します。

makefile で依存性を指定して、どのソース・ファイルをどのパーティションに関連付けるか指定する必要があります。makefile は、Createlower-level project if one does not existオプションを使用して生成されたディレクトリ・ロケーションを使用します。このオプションを使用しないで下位レベル・プロジェクトを作成している場合、makefileの先頭の変数を変更して、下位レベルの各プロジェクトのディレクトリ・ロケーションを指定する必要があります。

makefile を実行するには、スクリプト出力ディレクトリの make -fmaster_makefile.makなどのコマンドを使用します。マスターmakefileはまず下位レベルの各makefileを実行します。下位レベルのmakefileはその Tclスクリプトに基づき、デザイン・パーティションとしてプロジェクトをエクスポートするQuartus II Exported Partitionファイルを生成します。次に、新しく生成されたこれらの .qxp ファイルを、トップレベル・プロジェクトで対応するパーティションのインポート・ファイルとして指定するトップレベルの makefile を実行します。トップレベルのmakefileは次に、下位レベルの結果をインポートし、フル・コンパイルを実行して最終的なデザインを作成します。



特定のパーティションをコンパイルから除外するには、ファイルの指示に従って、master_makefile.makの EXCLUDE_FLAGSセクションを編集し、適切なオプションを指定します。また一部のパーティションの構築、エクスポート、インポートをmakeコマンドを使用して禁止することも可能です。パーティションを除外するには、以下の例に示す GNU のmake ユーティリティのようなコマンドを使用して、makefile を実行します。

gnumake –f master_makefile.mak exclude_<partition directory>=1 ↵ r

このコマンドは、<partition directory> に出力ファイルがあるパーティションを構築しないように指示します。複数の exclude_<partitiondirectory>コマンドを追加することによって、複数のディレクトリを除外できます。コマンドライン・オプションは、makefileのどのオプションよりも優先されます。

makefileのもう 1つの特長として、複数のプロセッサを備えたシステムで、マスターmakefile に複数の下位レベル makefile を呼び出させる機能があります。このオプションは、設計者が複数の CPU を使用する際に役立ち、コンパイル時間を大幅に短縮できます。GNU の make ユーティリティの場合、make コマンドに -j<N> フラグを追加します。値<N>はビルドの実行に使用できるプロセッサの数です。

makefileには、メイク・クリーン・オプションが含まれないため、makeを再度実行して、.qxpファイルが既に存在する場合は、デザインをリコンパイルすることができます。



パーティション統計レポート

デザイン・パーティションに関する統計は、Partition Merge PartitionStatisticsコンパイル・レポートと、Design Partitions Propertiesダイアログ・ボックスの Statisticsタブで確認できます。

Compilation ReportのPartition Merge フォルダ内のPartition Statisticsページに、各パーティションに関する統計がリストされます。各パーティション（テーブル内の各ロウ）の統計には、パーティション内のロジック・セルの数、およびパーティション内の入力ピンと出力ピンの数、および登録数または未接続数が示されます。このレポートが役に立つのは、デザイン・パーティションをトップダウン・コンパイル・フローで最適化するとき、またはパーティションが 2–19 ページの「デザイン・パーティションの選択および作成」および「Quartus IIハンドブック Volume1」の「Best Practices for Incremental Compilation Partitions andFloorplan Assignments」の章に示すガイドラインに確実に従うように、ボトムアップ・コンパイル・フローでトップレベルのデザインをコンパイルする場合です。図 2–10に、レポート・ウィンドウを示します。

図 2–10. Partition Mergeパーティション統計レポート

特定のパーティションのリソースとポート接続に関する統計は、DesignPartition Properties ダイアログ・ボックスの Statistics タブでも確認できます。Assignments メニューの Design Partitions Window をクリックします。パーティションを右クリックし、Propertiesをクリックして、ダイアログ・ボックスを開きます。Show All Partitions をクリックし、同じレポート内のすべてのパーティションを表示します（図 2–11）。




Incremental Compilation Advisor

図 2–11. Design Partitions Propertiesダイアログ・ボックスのStatisticsタブ

Incremental Compilation Advisor

Incremental Compilation Advisorを使用して、デザイン・パーティションおよびフロアプラン・ロケーション・アサインメントを作成するために、アルテラの推奨事項にデザインが準拠しているかどうかチェックできます。Tools メニューの Advisors をポイントし、IncrementalCompilation Advisorをクリックします。

図 2–12に示すように、推奨事項はすべてのコンパイル・フローに適用される General Recommendationsと、ボトムアップ・デザイン手法に適用される Bottom-Up Design Recommendationsに分かれています。各推奨事項では、推奨事項の影響を説明し、推奨される変更を行うために必要な処置を示しています。一部のケースでは、適切な Quartus II設定ページへのリンクがあるため、アサインメントまたは設定に対して推奨される変更を行うことができます。



図 2–12. Incremental Compilation Advisor

デザインが推奨事項に従っているかどうかをチェックするには、TimingIndependent Recommendations ページまたは Timing DependentRecommendationsページに移動し、Check Recommendationsをクリックします。大きなデザインの場合、これらの操作に数分かかる場合があります。チェックを実行すると、図 2–12に示すとおり、各推奨事項の横にデザインまたはプロジェクト設定が推奨事項に従っていることを示すシンボルか、あるいは一部またはすべてのデザインまたはプロジェクト設定が推奨事項に従っていないことを示すシンボルが表示されます。詳細は、アドバイザのHow to use the Incremental Compilation Advisorページのキャプションを参照してください。

アドバイザの一部の項目について、デザインが推奨事項に従っていない場合、Check Recommendations によってデザインで改善可能な部分がリストされます。例えば、Register All Ports 推奨事項に従っていないパーティション I/Oポートがある場合は、アドバイザに未登録のポートのリストがパーティション名および当該ポートに関連するノード名と共に表示されます。

アドバイザからノードのリストが提供されると、ノードを右クリックし、Locateをクリックして、RTL Viewer、Chip Planner、またはテキスト・エディタでのデザイン・ソース・コードなど、Quartus II の他の機能へのクロス・プローブが可能です。


推奨されるデザイン・フローおよびコンパイルのアプリケーション例

RTLまたは Technology Map Viewerを初めて開いたときは、プリプロセッサ・ステージが実行されます。このプリプロセッサは、 Incremental Compilation Advisor をリセットするので、Check Recommendations プロセスを再実行する必要があります。あるいは、ビューワでノードを検索したい場合は、適当なネットリスト・ビューワを開いてから Incremental CompilationAdvisorを使用することもできます。また、新しい TimeQuestレポートを開くと、Incremental Compilation Advisorの結果がリセットされます。


この項では、インクメンタル・コンパイルを使用して、タイミング・クロージャおよびチーム・ベース・デザインの一般的な問題を解決するためのデザイン・フローを示します。各フローで、それを使用する状況を例示し、フローを実装するのに必要なコマンドをステップごとに説明します。

以下の 4つのトップダウン・インクリメンタル・デザイン・フローの例では、デザインにインクリメンタル変更を行いながら、コンパイル時間を短縮します。以下のデザイン・フローの例では、いくつかのデザイン・パーティションに対する結果を最適化または維持することによって、タイミング・クロージャをより迅速に達成することもできます。

■ 「1つのパーティションに対するソース・ファイル変更時のコンパイル時間の短縮」

■ 2–65ページの「他のパーティションを追加する前に一部のパーティションの結果を維持する」

■ 2–67ページの「タイミング・クリティカルなパーティションの配置を最適化する」

■ 2–67ページの「タイミング・クリティカルなパーティションの配置を最適化する」

すべての例は、ユーザーが 2–11ページの「クイック・スタート・ガイド—インクリメンタル・コンパイル・フローのステップの概要」で説明したステップに従って、フル・インクリメンタル・コンパイル・フローを使用するプロジェクトをセットアップしているものと想定しています。

以下の 4つのボトムアップ・デザイン・フローの例では、チーム・ベースのデザイン手法およびデザインの再利用について説明します。

■ 2–69ページの「チーム・ベースのボトムアップ・デザイン・フローの実行」

■ 2–74ページの「ボトムアップ・デザイン・フローでのデザインのイタレーションの実行」

■ 2–75ページの「IP再利用のためのハード・ワイヤード・マクロの作成」



■ 2–78ページの「エクスポートされたパーティションを使用したソース・ファイルをインクルードしないデザインの送信」

1つのパーティションに対するソース・ファイル変更時のコンパイル時間の短縮

このフローを使用して、デザインの他の部分をリコンパイルすることなく、1 つのパーティションのソース・ファイルを更新します。コンパイル時間を短縮するには、変更されていないパーティションに対するフィッティング後のネットリストを維持します。これにより、当該ブロックの性能も維持され、余分なタイミング・クロージャ作業が軽減されます。

例のバックグランド：複数パーティションを含むデザインについて、長く完全なコンパイルを実行しました。あるパーティションの HDL ソース・ファイルにエラーが見つかり、修正されています。現在デザインはタイミング要件を満たし、修正がタイミング性能に影響するとは予測されないため、影響を受けたパーティションのみコンパイルし、デザインの残りのパーティションを維持することが理にかなっています。

以下のステップを実行し、1つのソース・ファイルを更新します。

1. HDLソース・ファイルを修正し、保存します。

2. Assignments メニューの Design Partitions Window をクリックします。

3. 維持するパーティションについては、Netlist Type を Post-Fitに変更します。Fitter Preservation Levelは Placementか Placement andRoutingに設定できます。修正を含めるパーティションについては、ネットリスト・タイプを Source Fileに変更できます。（ソース・ファイルで変更が検出された場合、Quartus II ソフトウェアはパーティションをリコンパイルするため、Source Fileの設定はオプションです。）

4. Start Compilationをクリックして、修正済みHDLコードをインクリメンタルにコンパイルします。このコンパイルに要する時間は、最初のフル・コンパイルよりもかなり短くなります。

5. シミュレーションを再実行し、バグが修正されたか確認し、タイミング・アナライザ・レポートでタイミング結果が悪化していないことを確認します。



他のパーティションを追加する前に一部のパーティションの結果を維持する

このフローを以下の 2つのバリエーションで使用します。

■ 分離されている 1つのパーティション・セットを最適化し、ユーザーがデザインの残りの部分を完成させる間、配置を固定して結果を維持します。例えば、カスタム・ロジックの残りを組み込む前に最適化を実行する命令と併せて、いくつかの IPのパーティションを作成することができます。

■ 長いコンパイル時間を必要とするパーティションを含まないデザインをコンパイルし、最終的なデザイン・ブロックを追加するときにデザインの残りの部分をロック・ダウンします。

例のバックグランド：コンパイル前に、配置配線の実行後にどのパーティションが最もタイミング・クリティカルになるか、あるいはどのパーティションがコンパイルに長い時間を要するかをある程度予想していました。コンパイル時間を短縮し、タイミング・クロージャを達成するために、以下のコンパイル・フローの 1つを使用することにしました。

最初の検証では、すべての最適化をオンにすると（手動またはデザイン・スペース・エクスプローラを使用）、クリティカル・パーティションは自動的に配置配線されます。このパーティションに対してタイミング・クロージャが達成された後、その内容と配置が維持され、残りのパーティションはコンパイル時間を短縮できるように、通常または低い最適化レベルでフィッティングされます。

2 番目の検証では、高速コンパイル・パーティションのみ最初に通常または低い最適化レベルで配置配線され、フロアプラン・ロケーション・アサインメントを使用して、将来追加するパーティションのフロアプランにスペースを確保します。これらの高速コンパイル用パーティションが確保されるため、最後のパーティションが Fitterに導入されるときに、さまざまな最適化をオンにして（手動またはデザイン・スペース・エクスプローラを使用）リコンパイルする必要はありません。

一般に、このフローは各クリティカル・パスが 1つのパーティション内に含まれている場合にのみ効果があります。これが各パーティションの入力と出力の両方を登録しなければならない理由です。

このデザイン・フローでは、以下のステップを実行します。

1. デザインを分割して、フロアプラン・ロケーション・アサインメントを作成します。



2. 最初にコンパイルされるパーティションについては、AssignmentsメニューのDesign Partitions Windowをクリックし、Netlist Typeを Source Fileに設定します。

3. 残りのパーティションについては（ステップ 2のパーティションの直接または間接的な親を除く）、Netlist Typeを Emptyに設定します。

4. 希望の最適化を有効にしてコンパイルするには、Start Compilationをクリックします。

5. タイミング・アナライザ・レポートをチェックし、タイミング要件を満たしていることを確認します。要件を満たしている場合は、ステップ 6に進みます。それ以外の場合は、要件を満たすまで、ステップ 4と 5を繰り返します。

6. 最初のパーティションについては、Design Partition Window で、Netlist Typeを Post-Fitに設定します。タイミング・クリティカルなブロックの結果を維持するのに必要な場合に限り、FitterPreservation Levelを Placement and Routingに設定し、それ以外の場合は、Placementを使用して最も柔軟な配線を可能にします。

7. 残りのパーティションについては、Netlist TypeをEmptyからSourceFileに変更します。

8. 適切な最適化のレベルを設定し、デザインをコンパイルします。この時点で最適化を変更しても、フィッティングされたパーティションに影響しません。これはそれぞれの Netlist Typeが Post-Fitに設定されているためです。

9. タイミング・アナライザ・レポートをチェックし、タイミング要件を満たしていることを確認します。満たしていない場合は、デザインまたはオプションを変更し、要件を満たすまでステップ8とステップ 9を繰り返します。

このフローは、モジュールが個別に実装され、後でデザインの残りにマージされるボトムアップ・デザイン・フローに類似しています。潜在的な問題について詳しくは、2–34ページの「Empty パーティション」を参照してください。プロジェクトに欠けているデザイン・ファイルを表すパーティションが存在する場合は、ポート・インタフェースを定義するプレースホルダ・ラッパーを作成しているか確認します。



タイミング・クリティカルなパーティションの配置を最適化する

デザインの他のパーティションが要件を満たしているとき、1 つのパーティションの結果を最適化する場合に、このフローを使用します。

例のバックグランド：複数パーティションを含むデザインについて、長いフル・コンパイルを実行しました。タイミング・アナライザは、クロック・タイミング要件を満たしていないとレポートしています。いくつかの解析の後、特定のパーティションの配置を改善できれば、タイミング・クロージャを達成できると判断しました。少なくとも 3つの最適化技法、すなわち Placement Effort Multiplier の立ち上げ、フィジカル・シンセシスの有効化、およびデザイン・スペース・エクスプローラの実行を考慮に入れています。これらの技法はすべて長いコンパイル時間を要するため、該当するパーティションにのみ（あるいは、そのうち 1つにのみ）適用するのが適切です。

以下のステップを実行して、Placement Effort Multiplier を立てるか、フィジカル・シンセシスを有効にします。


2. 当該パーティションに対して、Netlist Typeを Post-Synthesisに設定します。この設定により、次のコンパイル時にパーティションは新しい Fitter設定で配置配線されます（再合成は行われません）。

3. （トップレベル・エンティティを含む）残りのパーティションでは、Netlist Typeを Post-Fitに設定します。Fitter Preservation LevelをPlacementに設定し、最も柔軟な配線を可能にします。これらのパーティションは、次のコンパイル中も維持されます。

4. 必要な最適化設定を適用します。

5. Start Compilationをクリックし、新しい設定でデザインをインクリメンタルにコンパイルします。このコンパイル中に、Partition Mergeステージではクリティカル・パーティションの合成後のネットリストが、残りのパーティションのフィッティング後のネットリストに自動的にマージされます。この “ マージされた ” ネットリストは、Fitter に送られます。Fitter は 1 つのパーティションのみ再フィッティングします。最初のフル・コンパイルと比べて少ない作業で済むため、コンパイル時間も短縮されます。

デザイン・スペース・エクスプローラを使用するには、以下のステップに従います。

1. 前回のステップ 1–3を繰り返します。



2. プロジェクトを保存し、デザイン・スペース・エクスプローラを実行します。

SignalTapIIロジック・アナライザによるインクリメンタル・デバッグ

インクリメンタル・コンパイルでは、オリジナル・デザインの合成およびフィッティングの結果を保持し、オリジナル・ソース・コードをリコンパイルすることなく、デザインに SignalTap® IIロジック・アナライザを追加することができます。

ロジック・アナライザを追加してデザインをデバッグする場合、またはロジック・デザインやその配置を修正することなく、SignalTap II ファイルのコンフィギュレーションを修正する場合は、このフローでコンパイル時間を短縮することができます。

SignalTap II インクリメンタル・コンパイル機能を使用するために、デザイン・パーティションを作成する必要はありません。デザインがフル・インクリメンタル・コンパイルを使用するように設定されているとき、SignalTap IIロジック・アナライザは独自の個別デザイン・パーティションとして機能します。

インクリメンタル・コンパイル・フローで SignalTap II ロジック・アナライザを使用するには、以下のステップを実行します。


2. この配置を維持するすべてのパーティションでは、Netlist Type をPost-Fitに設定します。

トップレベル・パーティションのネットリスト・タイプは、デフォルトで Source Fileになるため、作成したデザイン・パーティションのほかに、このトップ・パーティションも必ず変更してください。

3. まだ現在のパーティション・セットでデザインをコンパイルしていない場合は、フル・コンパイルを実行します。デザインがすでに現在のパーティション・セットでコンパイルされている場合、そのデザインはSignalTap IIロジック・アナライザに追加できる状態になっています。



4. Node Finder の SignalTap II: post-fitting フィルタを使用して、SignalTap IIファイルを設定します。これにより、Fitterはデザインの結果を変更することなく、SignalTap II ロジックをフィッティング後ネットリストに追加できます。

5. 合成前ネットリストからの信号を追加するには、パーティションのNetlist Typeを Source Fileに設定し、Node Finderの SignalTap II:pre-synthesisフィルタを使用します。これにより、ソフトウェアはパーティションを再合成し、選択した合成前のノード名に直接タップすることができます。この場合、パーティションが再フィッティングされるため、配置は一般に以前のフィッティング結果とは異なります。

SignalTap II ロジック・アナライザでは、ネットリスト・タイプ Post-Synthesisを使用しないでください。

SignalTap IIロジック・アナライザの設定について詳しくは、「Quartus IIハンドブック Volume 3」の「SignalTap IIエンベデッド・ロジック・アナライザを使用したデザインのデバッグ」の章を参照してください。

チーム・ベースのボトムアップ・デザイン・フローの実行

この例では、ボトムアップ・デザイン・フローでインクリメンタル・コンパイルを使用する方法について説明します。

例のバックグランド：プロジェクトは、異なる設計者が別々に実装する複数の下位レベル・サブデザインから構成されます。トップレベルのプロジェクトは、これらのサブデザインをそれぞれ 1回だけインスタンス化します。サブデザインの設計者は、それぞれのデザインを独立して最適化し、結果をプロジェクト・リーダーに渡したいと希望しています。

このシナリオのプロジェクト・リーダーは、以下のステップを実行して、ボトムアップ・デザイン手法を成功させるためにデザインを準備します。

1. 最終的に、デザイン全体の完全な実装を含む新しい Quartus IIプロジェクトを作成します。

2. ボトムアップ手法のために準備するには、別々の設計者が実装するサブデザインに対して階層を定義するデザインの“スケルトン”を作成します。トップレベルのデザインは、デザインにトップレベル・エンティティを実装し、実装ではなくポート・インタフェースのみを定義することによって、各サブデザインを表すラッパー・ファイルをインスタンス化します。

http://www.altera.co.jp/literature/hb/qts/qts_qii53009_j.pdf

http://www.altera.co.jp/literature/hb/qts/qts_qii53009_j.pdf



3. プロジェクト全体の設定を行います。デバイスを選択し、クロックとデバイス I/Oポートにグローバル・アサインメントを作成し、グローバル信号の制約を作成して、グローバル配線リソースを使用できる信号を指定します。

4. 各サブデザインにデザイン・パーティション・アサインメントを作成し、Design Partitions ウィンドウで、インポートされる各デザイン・パーティションの Netlist Typeを Emptyに設定します。

5. 下位レベルの各パーティションに LogicLock領域を作成し、デザイン・フロアプランを作成します。このフロアプランは、パーティション間の接続性を考慮し、最初の実装数とデザイン仕様の知識に基づいて、各パーティションのサイズを見積もります。

6. ProjectメニューのGenerate Bottom-Up Design Partition Scriptsをクリックするか、Tclまたはコマンド・プロンプトからスクリプト・ジェネレータを起動します。

7. 必要に応じて、デフォルトのスクリプト・オプションに変更を加えます。アルテラでは、すべてのパーティションおよび仮想ピン・ロケーション・アサインメントについて、LogicLock 領域を含むすべてのデフォルト制約を渡すことを推奨しています。さらにアルテラでは、各パーティションに仮想 I/O接続用の最大遅延タイミング制約を追加し、トップレベルでの統合中のタイミング・クロージャの達成を支援することを推奨しています。他の設計者がより下位レベルのプロジェクトを作成していない場合は、パーティション・スクリプトを使用してプロジェクトをセットアップし、makefileを簡単に活用できるようにします。

8. 下位レベルのすべての設計者に、適切な制約でプロジェクトを作成するための Tcl ファイルを配布します。makefile を使用している場合、各パーティションにmakefileを提供します。

この例の下位レベル・サブデザインの設計者は、デザイン・チームでmakefile を使用しているかどうか、あるいはデザインを手動でエクスポートおよびインポートしているかどうかに関わらず、適切なステップを実行してデザインを正しくエクスポートする必要があります。



makefileを使用している場合は、以下のステップに従います。

1. make コマンドおよびプロジェクト・リーダーが提供する makefileを使用して、すべてのデザイン制約を考慮した Quartus IIプロジェクトを作成し、プロジェクトをコンパイルします。

2. どのソース・ファイルをどのパーティションに関連付けるかに関する情報が、自動的にソフトウェアに通知されないため、makefileでこの情報を指定する必要があります。makefileの最初の呼び出しの後、ソフトウェアがプロジェクトを再構築する前に、依存性を指定する必要があります。

3. 希望のコンパイル結果を達成し、デザインをトップレベル・デザインにインポートする準備が整ったら、プロジェクト・リーダーはmaster_makefile コマンドを使用して、この下位レベル・パーティションをエクスポートし、.qxpファイルを作成して、これをトップレベル・デザインにインポートします。

makefileを使用していない場合は、以下のステップに従います。

1. Quartus IIサブデザイン用の新しいプロジェクトを作成します。

2. プロジェクト・リーダーの指定に従って、LogicLock 領域アサインメントとグローバル・アサインメント（クロック設定を含む）を作成します。

3. トップレベル・モジュールの外部デバイス・ピンの代わりに、コア・ロジックへの接続を表すポートに、仮想ピン・アサインメントを作成します。

4. 仮想ピンへのフロアプラン・ロケーション・アサインメントを作成し、トップレベル・モジュールでの決定に従って、これらのピンが対応する領域に配置されるようにします。これによって、Fitter により多くのモジュール間のタイミング制約に関する情報が提供されます。あるいは、タイミング I/O制約を仮想ピンに接続されるパスに適用することができます。

5. 必要に応じてデザインのコンパイルと最適化に進みます。

6. 希望のコンパイル結果を達成したら、Project メニューの ExportDesign Partition をクリックします。Export Design Partition ダイアログ・ボックスが表示されます。



7. Netlist to export で、ネットリスト・タイプ Post-fit netlist を選択し、サブデザインの配置と性能を維持して、Export routing をオンにし、必要に応じて配線情報をインクルードします。配置または性能の維持が要求されない場合は、代わりに Post-Synthesisネットリストをエクスポートできます。

8. プロジェクト・リーダーに .qxpファイルを提供します。

最後に、この例のプロジェクト・リーダーとして、適切なステップを実行し、下位レベル・サブデザインの各パーティションの設計者が送信したファイルをインポートします。

makefileを使用している場合は、以下のステップに従います。

1. master_makefile コマンドを使用して、下位レベルの各パーティションをエクスポートし、.qxpファイルを作成し、これらをトップレベル・デザインにインポートします。

2. どのソース・ファイルをどのパーティションに関連付けるかに関するすべての情報がソフトウェアで得られない場合は、makefileにこの情報を指定する必要があります。依存性を指定していないと、ソース・ファイルが変更された場合にソフトウェアはプロジェクトを再構築できません。

makefileを使用していない場合は、以下のステップに従います。

1. チームの他の設計者から、各サブデザインの .qxpファイルを取得した後、Projectメニューで Import Design Partitionをクリックして、サブデザインの .qxpファイルで表されるトップレベル・プロジェクト内のパーティションを指定します。

2. デザインの各パーティションに対して、ステップ 1で説明したインポート・プロセスを繰り返します。各パーティションを 1回だけインポートした後、すべてのデザイン・パーティションを選択し、Reimport using latest import files at previous locationsオプションを使用して、すべてのファイルを前回の位置から一度にインポートします。

インポート時のアサインメント衝突の解決サブデザインをインポートする場合、プロジェクト・リーダーはアサインメントの衝突に気付くことがあります。これはサブデザインの設計者がそれぞれの LogicLock領域を変更し、ロジックまたは配置の追加制約を明らかにする場合、または設計者がプロジェクト・リーダーによってトップレベル・プロジェクトに追加された制約とは異なる I/Oポート・



タイミング制約を適用した場合に発生する可能性があります。このような衝突に対処するために、プロジェクト・リーダーは以下のいずれかまたは両方を行うことができます。

■ 新しいアサインメントのインポートを可能にする。■ 既存のアサインメントの再配置または更新を許可する。

LogicLock 領域のアサインメント衝突が発生した場合、プロジェクト・リーダーは以下のいずれかを実行できます。

■ インポートされた領域で、既存の領域を再配置できるようにする。■ インポートされた領域で、既存の領域を更新できるようにする。■ 衝突の発生した領域では、アサインメントのインポートをスキップします。

プロジェクト・リーダーは、2–49ページの「アサインメントおよび高度なインポート設定のインポート」の説明に従って、Advanced ImportSettingsを使用してこれらのすべての状況に対処できます。

異なるサブデザインの配置が衝突する場合、プロジェクト・リーダーはパーティションの Fitter Preservation Levelを Netlist Onlyに設定できます。これによってソフトウェアは、インポートされたネットリストを使用して、配置配線を再実行できます。

複数回インスタンス化されるパーティションのインポートこのバリエーションのシナリオでは、サブデザインの 1つがトップレベル・デザインで 2回以上インスタンス化されます。サブデザインの設計者は、下位レベル・プロジェクトでエンティティを一度コンパイルおよび最適化し、次にトップレベル・プロジェクトで複数のパーティションとして結果をインポートできます。

この場合、2–72 ページの「インポート時のアサインメント衝突の解決」で説明するような配置衝突の解決が必須になります。これはトップレベル・パーティションがインポートされた同じフィッティング後のネットリストを共有するためです。トップレベル・デザインでサブデザインの複数のインスタンスをインポートする場合、インポートされるLogicLock領域は自動的に非固定ステータスに設定されます。

手動で衝突を解決する場合、インポート・オプションと手動によるLogicLock アサインメントを使用して、トップレベル・デザインの各インスタンスの配置を指定することができます。



ボトムアップ・デザイン・フローでのデザインのイタレーションの実行

ボトムアップ・コンパイルで、統合されたトップレベル・デザインからの追加制約を取り込んで、下位レベルのパーティションの最適化を再実行する場合は、このフローを使用します。

例のバックグランド：プロジェクトは、個別の Quartus IIプロジェクトからエクスポートされ、ボトムアップ・コンパイル・フローのトップレベル・デザインにインポートされた複数の下位レベル・サブデザインから構成されています。この例では、タイミング要件を満たしていないため、トップベルでの統合は失敗しています。タイミング要件は下位レベルの個々のプロジェクトでは満たされていますが、トップレベルのクリティカル・パーティション間パスによりタイミング要件に適合しなくなっています。

トップレベルで様々な最適化を試みた後、プロジェクト・リーダーはインポートされた現在の下位レベルのパーティション配置では、デザインがタイミング要件を満たすことができないと判断しています。プロジェクト・リーダーは、下位レベル・プロジェクトに追加制約を渡し、配置を改善することにしました。

このデザイン・フローでは、以下のステップを実行します。

1. トップレベル・デザインの Project メニューで、Generate Bottom-Up Design Partition Scriptsをクリックするか、Tclまたはコマンドラインからスクリプト・ジェネレータを起動します。

2. 各パーティションに下位レベルのプロジェクトが作成されているため、Create lower-level project if one does not existオプションをオフにします。

3. 必要に応じて、デフォルトのスクリプト・オプションに変更を加えます。アルテラでは、すべてのパーティションおよび仮想ピン・ロケーション・アサインメントについて、LogicLock 領域を含むすべてのデフォルト制約を渡すことを推奨しています。またアルテラでは、各パーティションでの仮想 I/O接続用に、最大遅延タイミング制約を追加することも推奨しています。

4. Quartus II ソフトウェアはすべてのパーティションに Tcl スクリプトを生成しますが、このシナリオではパーティション間のクリティカル・パスを構成するパーティションに重点を置くことにします。スクリプトの重要なアサインメントを以下に示します。

● トップレベル・デザインのデバイス I/Oポートに接続されていないモジュール・ピンへの仮想ピン・アサインメント。



● ピンの接続元または接続先の最初のトップレベル配置を反映した、仮想ピンのロケーション制約。これらの制約により、下位レベルの配置がトップレベルで周囲を認識するのを支援し、トップレベルでの統合時にタイミング・クロージャの機会を高めることになります。

● パーティションのI/Oピンとのパスに対するINPUT_MAX_DELAYおよびOUTPUT_MAX_DELAYタイミング制約これらはピンがピンとの間のタイミング・パスを最適化するのに制約を課します。

5. 下位レベルの設計者がプロジェクト・リーダーから提供されたファイルをソースします。

● Quartus II GUIから Tclスクリプトをソースするには、Toolsメニューの Utility Windows をクリックし、Tcl コンソールを開きます。スクリプトのディレクトリに移動し、以下のコマンドを入力します。

source <filename> ↵r

● システム・コマンド・プロンプトで Tclスクリプトをソースするには、以下のコマンドを入力します。

quartus_cdb -t <filename>.tcl ↵r

6. 下位レベルの設計者は、新しいアサインメントで各自のデザインをリコンパイルし、内部タイミング要件を満たしていることを確認します。

7. 下位レベルの設計者は、各自の結果を再エクスポートします。

8. トップレベルの設計者は、その結果を再インポートします。

9. ここでデザインを解析し、タイミング要件が達成されたかどうかを判断します。下位レベルのパーティションが、トップレベルでより多くの接続性に関する情報を提供してコンパイルされているため、パーティション間パスにより配置が改善されている可能性が高く、タイミング要件の適合を促します。

IP再利用のためのハード・ワイヤード・マクロの作成

トップレベル・デザインでインスタンス化できるハード・ワイヤード・マクロまたは IPロジックを作成するには、このデザイン・フローを使用します。このフローでは、合成後または配置（およびオプションで配線）情報を含むデザイン・ブロックをエクスポートし、この配置済みマクロのコピーを必要な数だけ別のデザインにインポートする機能を提供します。



例のバックグランド：IPプロバイダは、上位レベルのシステムで使用されるコンポーネント用のIPコアを生産および販売することを希望しています。IPプロバイダは、特定のアルテラ・デバイスで最高性能を達成するためにブロックの配置を最適化し、配置情報を最終顧客に渡したいと考えています。また、IP を維持するために、HDL ソース・コードの代わりにコンパイルされたネットリストを顧客に提供することを希望しています。

顧客は最初に、このプロジェクトで使用されているアルテラ・デバイスを指定し、デザイン仕様を提供します。

この例の IPプロバイダは、以下のステップを実行して配置済み IPコア（またはマクロ）をエクスポートします。

1. IPコアのポート・インタフェースを定義するドキュメントを作成し、そのファイルをトップレベル・デザインで空のパーティションとしてインスタンス化するために顧客に提供します。

2. IPコア用の Quartus IIプロジェクトを作成します。

3. エクスポートするデザイン階層に LogicLock領域を作成します。

.qxp ファイルの生成時および使用時には必要ありませんが、LogicLock 領域を使用してフロアプランを作成することを推奨します。IPコアに LogicLock領域を使用すれば、空のプレースホルダ領域を作成して、デザイン・フロアプランに IP用スペースを確保できます。これにより、トップレベル・デザイン・ロジックとの衝突が回避され、IPコアがトップレベル・デザインの他のロジックのタイミング性能に影響を与えることはありません。

LogicLock領域は、リソースの使用率の衝突を効果的に低減し、性能維持を可能にすることができます。また、LogicLock 領域がない場合、絶対的な方法でしか配置を維持することができません。LogicLock 領域を使用すれば、関連する領域の原点に対する絶対的または相対的配置を維持できます。これは .qxpファイルを同じプロジェクト内の複数のパーティション階層にインポートする場合に重要です。その理由は、この場合にはトップレベル・プロジェクトの少なくとも1つのインスタンスのロケーションがIPプロバイダが使用するロケーションと一致しないためです。



4. 必要に応じて、エクスポートされるデザイン階層の周辺にロジック（PLLまたは顧客のトップレベル・デザインで定義される他のロジックなど）を追加します。ロジックを追加すると、IPコアとしてエクスポートされるデザイン階層にデザイン・パーティションが作成されます。

詳細は、2–47ページの「プロジェクト内の下位レベル・ブロックのエクスポート」を参照してください。

5. デザインを最適化し、タイミングを閉じてデザイン仕様を満たします。

6. 適切なレベルの階層を 1つの .qxpファイルにエクスポートします。プロジェクトのコンパイルに成功したら、GUI、コマンドラインから、または Tclコマンドを使用して .qxpファイルを生成できます。

● Quartus II GUIを使用する場合は、Export Design Partitionコマンドを使用します。

● コマンドラインの実行コマンドを使用する場合は、--incremental_compilation_export オプションを指定して quartus_cdbを実行します。

● Tclコマンドを使用する場合は、以下のコマンドを使用します。execute_flow -incremental_compilation_export.

7. 顧客に .qxpファイルを提供します。顧客にデザイン・ソース・コードを提供する必要はありません。この 1 本のファイルにデザイン・ネットリストおよび配置配線情報が含まれています。

この例の顧客は、以下のステップを実行して IPコアをデザインに組み込みます。

1. 同じデバイスをターゲットにし、IPコアの 1つまたは複数のコピーをインスタンス化するトップレベル・デザイン用の Quartus IIプロジェクトを作成します。

2. Processing メニューで Start をポイントし、Perform Analysis &Elaborationをクリックしてデザイン階層を識別します。

3. Netlist Typeを Emptyに設定して（2–28ページの「デザイン・パーティションの Netlist Type の設定」を参照）、IP コアの各インスタンスにデザイン・パーティションを作成します（2–108ページの「デザイン・パーティションの作成」を参照）。

4. デザインで担当部分について作業を継続し、IPコアが入手可能になったら IPプロバイダから IPコアの提供を受けることができます。



5. 適切なパーティション階層のために、IPプロバイダから提供された.qxpファイルをインポートします。GUI、コマンドラインから、または Tclコマンドを使用して .qxpファイルをインポートすることができます。

● Quartus II GUIを使用する場合は、Import Design Partitionコマンドを使用します。

● コマンドラインの実行コマンドを使用する場合は、--incremental_compilation_import オプションを指定して quartus_cdb を実行します。

● Tclコマンドを使用する場合は、以下のコマンドを使用します。execute_flow -incremental_compilation_import.

6. インポートした LogicLock領域を、領域内容の相対的な位置を維持したまま、可動に設定するか新しいロケーションに移動することができます。配線情報は、可能な限り維持されます。

Fitter は、トップレベル・デザインの LogicLock 領域のロケーションに.qxpファイルにエクスポートされたロケーションとの互換性がない場合、相対的な配置アサインメントを無視します。

7. Fitter Preservation Level で、インポートされたネットリストのみ、配置、または配置配線（配置または配置配線情報が .qxpファイルにエクスポートされている場合）のいずれを維持するかコントロールできます。

デフォルトでは、配置配線を維持するよう選択した場合、インポートされたネットリストのすべてのノードの絶対配置および配線が維持されます。ただし、同じプロジェクトで複数のパーティションに同じ .qxpファイルを使用する場合、インポートされた各モジュールの相対的な配置（LogicLock領域の原点に対して相対的）が維持されます。

IPプロバイダが、エクスポートされたパーティションでLogicLock領域を定義していない場合、絶対的配置ロケーションが維持され、複数のインスタンスに対してパーティションがインポートされると配置衝突が発生します。

エクスポートされたパーティションを使用したソース・ファイルをインクルードしないデザインの送信

このフローを使用して、デザイン全体を 1つのファイルにまとめて最終顧客または別のデザイン・ロケーションに送信します。



例のバックグランド：設計者はデザイン・ブロックを生成したいと考えており、デザインを送信する必要がありますが、IP を保持するために、HDLソース・コードではなく合成されたネットリストを受信者に提供することを希望しています。

この例では送信者として、デザイン・ブロックをエクスポートするために、以下の手順を実行します。

1. 送信者にデバイス・ファミリ名を提供します。配置情報を合成ネットリストと一緒に送信する場合は、正確なデバイス選択も提供して、同等なプロジェクトを設定できるようにします。

2. デザイン・ブロックのポート・インタフェースを定義するドキュメントを作成して、受信者に提供します。受信者はトップレベル・デザインで、空のパーティションとしてデザイン・ブロックをインスタンス化することができます。

3. デザイン・ブロック用の Quartus IIプロジェクトを作成して、デザインを完成させます。

4. 適切なレベルの階層を 1つの .qxpファイルにエクスポートします。Quartus II GUIを使用する場合は、Export Design Partitionコマンドを使用します（2–44ページの「トップレベル・プロジェクトで使用される下位レベル・パーティションのエクスポート」を参照）。

5. 配置情報を送信する必要がない場合は、Post-synthesis ネットリストのみをインクルードするオプションを選択します。受信者が正確な Fitterの結果を復元したい場合は、Post-fittingネットリストオプションを選択し、オプションで Export routingをイネーブルすることができます。

6. 受信者に .qxpファイルを提供します。デザインのソース・コードを送信する必要はありません。

この例で受信者は、以下のステップを実行してデザイン・ブロックをトップレベル・デザインに組み込みます。

1. トップレベル・デザイン用の Quartus IIプロジェクトを作成し、プロジェクトが送信者が指定したのと同じデバイス（あるいは、.qxpファイルに配置情報が含まれていない場合は、少なくとも同じデバイス・ファミリ）をターゲットにしていることを確認します。

2. 提供されたポート情報を使用して、デザイン・ブロックをインスタンス化します。



3. Processing メニューで Start をポイントし、Perform Analysis &Elaborationをクリックしてデザイン階層を識別します。

4. Netlist Typeを Emptyに設定して（ 2–28ページの「デザイン・パーティションのNetlist Typeの設定」を参照）、デザイン・ブロックのインスタンスにデザイン・パーティションを作成します（2–19ページの「デザイン・パーティションの選択および作成」を参照）。

5. 適切なパーティション階層のために、IPプロバイダから提供された.qxpファイルをインポートします。Quartus II GUIを使用する場合は、Import Design Partition コマンドを使用し、提供された .qxpファイル（2–48ページの「下位レベル・パーティションのトップレベル・プロジェクトへのインポート」を参照）を表示します。

6. 送信者が Fitter情報を提供する場合は、Fitter Preservation Levelで、インポートされたネットリストのみ、配置、または配置配線のいずれを維持するかコントロールできます。

インクリメンタル・コンパイルの制約

ここでは、他の Quartus II機能との相互作用を含めて、インクリメンタル・コンパイルを使用する際に直面する可能性がある制約と制限について述べています。制約によっては、トップダウンとボトムアップの両方のデザイン・フローに適用されるもの、ボトムアップ・デザイン・フローにのみ適用されるものがあります。

以下の制約と制限について説明します。

■ 2–82 ページの「Quartus II Archive ファイルによるインクリメンタル・コンパイルの使用」

■ 2–83ページの「フォーマル検証のサポート」■ 2–83ページの「ボトムアップ・フローのMegaCoreファンクションのための OpenCore Plus機能」

■ 2–83ページの「暗号化された IPコアのボトムアップ・フローへのインポート」

■ 2–84ページの「SignalProbeピンおよびChip PlannerによるEngineeringChange Management」

■ 2–86ページの「ボトムアップ・コンパイル・フローの SignalTap IIエンベデッド・ロジック・アナライザ」

■ 2–87ページの「ボトムアップ・コンパイル・フローのロジック・アナライザ・インタフェース」

■ 2–87ページの「JTAG機能を使用する下位レベル・パーティションのエクスポート」

■ 2–88ページの「デザイン・パーティションを持つプロジェクトの異なるデバイスへの移行」

■ 2–88ページの「HardCopyコンパイル・フローおよび移行フロー」



■ 2–89ページの「ボトムアップ・フローの HDLソース・コードで作成されるアサインメント」

■ 2–90ページの「フィジカル・シンセシス最適化を行う場合のコンパイル時間」

■ 2–90ページの「メガファンクション・パーティションの制約」■ 2–91ページの「配線の維持」■ 2–91 ページの「TimeQuest タイミング・アナライザの Synopsys

Design Constraintsファイル」■ 2–91ページの「ボトムアップ・デザイン・パーティションのスクリプトの制限」

■ 2–94ページの「レジスタ・パッキングおよびパーティション境界」■ 2–94ページの「I/Oレジスタ・パッキング」

フル・インクリメンタル・コンパイルに代わるインクリメンタル・シンセシスのみの使用インクリメンタル・コンパイルは、インクリメンタル配置配線なしで、インクリメンタル・シンセシスを実行するコンパイルの合成ステージに対してのみ有効にできます。このモードは、フォーマル検証やインクリメンタル SignalTap II 検証など、Quartus II の特定のデザイン・フローと互換性がないため、新規プロジェクトには推奨されません。

インクリメンタル・シンセシスのみ使用するには、フル・インクリメンタル・コンパイルのステップに従うことができますが、Settingsダイアログ・ボックスの Compilation Process Settings にある IncrementalCompilation ページの Incremental synthesis only (Can reducecompilation time for a design with partition assignments) オプションをオンにします。

このモードでは、Fitter はパーティション境界を含まないフラット化されたネットリストを使用するため、デザインは常に再配置および再配線されます。このフローと2–7ページの図 2–2に示すフローの違いは、Fitterにより生成されたフィッティング後のネットリストがパーティション・マージ・ステージで受け入れられず、Fitter がパーティションを個別にコンパイルしないことです。以下の違いは、フル・インクリメンタル・コンパイルと比較した場合、インクリメンタル・シンセシスの影響にのみ見られます。

■ コンパイル時間の短縮は、合成ツールがQuartus IIのQISに限定されます。

■ 配置および配線を維持できないため、この機能でパーティションのタイミング性能を維持することはできません。



■ パーティションは、ソース・コードまたは合成アサインメントを変更すると再合成されます（フル・インクリメンタル・コンパイルでは、合成アサインメントまたはフィッティング・アサインメントを変更しても自動的にリコンパイルされません）。

正確なタイミング性能の維持トップレベル・デザインでは、個別のパーティションとフル・デザインの違いのために、すべてのパーティションが組み込まれた場合、タイミング性能がわずかに変化する場合があります。例えば、デザインの一部のみに対する最初のコンパイルにはなかった寄生効果またはクロストークが発生する場合があります。また、配線ラインの追加ファンアウトによりタイミング性能が低下する可能性もあります。すべてのパーティションが存在する場合にデザインが性能を満たすようにするには、約 2%のマージンが必要になることがあります。これはボトムアップおよびトップダウンの両方の手法に当てはまります。Fitter は、デザインをコンパイルする場合、2%以上のマージンを自動的に付加します。

Quartus II Archiveファイルによるインクリメンタル・コンパイルの使用各デザイン・パーティションの合成後およびフィッティング後のネットリスト情報は、プロジェクト・データベースに保存されています。プロジェクトをアーカイブした場合、データベース情報は（.qar）ファイルにデータベース・ファイルをインクルードしている場合を除き、アーカイブにインクルードされません。

アルテラでは、コンパイル結果を維持するために、Archive Projectダイアログ・ボックスでデータベース・ファイルをインクルードすることを推奨しています。使用可能な場合は、Version-compatible database files(for future versions of the Quartus II software)オプションを選択して、最大限の柔軟性を提供します。プロジェクトを復元した後、Project メニューで、Import database を選択して、このデータベース情報をプロジェクトにインクルードします。プロジェクトの設定にバージョン互換オプションが使用できない場合は、Compilation and simulationdatabase files (For current versions of the Quartus II software) を選択します。ただし、このデータベースを別のソフトウェア・バージョン（サービス・パック・リリースを含む）にインポートすることはできません。

インポートされたパーティションのネットリスト情報は、すでに対応する .qxp ファイルに保存されています。インポートされた .qxpファイルは、imported_partitionsという名前のサブディレクトリに自動的に保存されるため、プロジェクト・データベースをアーカイブして、インポートされたパーティションの結果を保持する必要はありません。プロジェ



クト・アーカイブを復元するとき、パーティションはこのディレクトリ内の .qxp ファイル（使用可能な場合）から自動的に再インポートされます。

フォーマル検証のサポートフォーマル検証ツール用のネットリストを作成する場合、デザイン・パーティションは使用できません。

ボトムアップ・フローのMegaCoreファンクションのための OpenCore Plus機能トップダウン・インクリメンタル・コンパイル・フローで、OpenCorePlus MegaCore®ファンクションのためのOpenCore Plusハードウェア評価機能を使用することができます。OpenCore Plus 機能を使用するMegaCore ファンクションを含むパーティションをエクスポートすることはできません。ボトムアップ・デザイン・フローを使用する場合、トップレベルのQuartus IIプロジェクトでOpenCore Plus機能を使用する IPファンクションをインクルードします。OpenCore Plusハードウェア評価機能が必要ない場合は、この機能をディセーブルすることができます。Assignments メニューの Settings を選択します。Compilation ProcessSettingsページで、More Settingsをクリックします。Disable OpenCorePlusハードウェア評価オプションをOnに設定します。

暗号化された IPコアのボトムアップ・フローへのインポート暗号化された IPコアをコンパイルするには、適切なライセンス情報が必要です。デザインを .qxp ファイルとしてインポートすると、ライセンス・アサインメントがトップレベル・プロジェクトにインポートされます。ただし、ライセンス・アサインメントには、ライセンス供与されたIPソース・ファイルへの絶対パスが含まれています。したがって、.qxpファイルは、下位レベル・プロジェクトと同じコンピュータ上のトップレベル・プロジェクトにインポートされるか、両方のコンピュータ上の同じディレクトリ・パスの場所に IPファイルがインストールされた場合にのみ正常に動作します。

通常プロジェクト・チームの設計者が IPコアをさらに変更する必要はないので、このパーティションをインポートする代わりにトップレベル・プロジェクトにインクルードすることによって、この問題を回避できます。パーティションは以降のコンパイルでは変更されないため、最初のコンパイルの後にコアを含むパーティションを Post-Fit に設定して、それ以降のコンパイル時間を短縮できます。また、パーティションをEmptyに設定して、デザイン全体をコンパイルする準備が整うまで、データベースから IPコアを除外することも可能です。



暗号化された IP コアをインポートしたくない場合は、暗号化された IPソース・ファイルをトップレベル・プロジェクトのコンピュータに、完全に同じパス構造でコピーします。例えば、暗号化された IP ソース・ファイルが d:/work/my_encrypted_file.vhdの場合、.qxpファイルをインポートするトップレベルの設計者は同じフォルダを作成して、そこにファイルを入れなければなりません。

SignalProbeピンおよび Chip PlannerによるEngineering Change Managementフル・コンパイル実行後、SignalProbe ピンを作成するか ResourceProperty Editorを使用して ECO（Engineering Change Order）による変更を行う場合、デザイン全体をリコンパイルする必要はありません。このような変更は、新しい配置配線を実行しないで、直接ネットリストに対して行われます。これらの変更は、配置配線を実行し、フィッティング後のネットリストを使用して維持できます。パーティションをリコンパイルすると、影響を受けていないパーティションの SignalProbe ピンおよび ECOによる変更が維持されます。

デザインをデバッグするための SignalProbe 機能の使用について詳しくは、「Quartus II ハンドブック Volume 3」の「Quick Design DebuggingUsing the SignalProbe」の章を参照してください。ECOを行うための ChipPlanner および Resource Property Editor の使用について詳しくは、「Quartus IIハンドブック Volume 2」の「Engineering Change Management

with Chip Planner」の章を参照してください。

SignalProbeピンまたは ECOの変更を維持するには、Fitter PreservationLevel を Placement and Routing に設定して、パーティションのネットリスト・タイプを Post-fitに設定する必要があります。SignalProbeピンまたは ECO の変更を含むパーティションが、配線なしのフィッティング後またはネットリストのみに設定されている場合、ソフトウェアはワーニングを発行し、配置配線を行ったフィッティング後のネットリストを内部で使用します。パーティションがソース・コードまたは合成後のネットリストを使用するよう設定されている場合、ソフトウェアはワーニングを発行し、新しいコンパイルにフィッティング後のSignalProbeピンまたは ECOの変更はインクルードされません。ただし、以下に示すように、パーティションは SignalProbeピンまたは ECOの変更によりリンクできるようになります。この場合、リンクされているすべてのパーティションは、最高レベルの維持が設定されているリンク済みパーティションからネットリスト・タイプを継承します。







SignalProbeピンまたは ECOの変更のためリンクされているパーティション

ECO の変更が複数のパーティションまたはパーティション間の接続に影響を与える場合、当該パーティションはリンクされます。最も近い共通の親まで上位レベルのすべての “親 ”パーティションもリンクされます。この場合、パーティション間の接続は、直ちに影響を受ける 2つのパーティションの外部で実際に定義されるため、すべてのパーティションをまとめてコンパイルする必要があります。リンクされているすべてのパーティションは同じネットリスト・タイプを使用し、最高レベルの維持が設定されているリンク済みパーティションからネットリスト・タイプを継承します。

SignalProbeピンが作成されると、プローブされるノードを含むパーティションに影響を与えます。また、ノードがプローブされると、同じパーティションにパイプライン・レジスタが作成されます。SignalProbe 出力ピンは、トップレベル・パーティションに割り当てられます。したがって、トップレベル・パーティションとプローブされる下位レベル・パーティションの間に新しい接続が形成されます。この接続により、プローブされる下位レベル・パーティションとトップレベルまでのすべての上位レベルの“親“パーティションがリンクされます。リンクされているすべてのパーティションは同じネットリスト・タイプを使用し、最高レベルの維持が設定されているリンク済みパーティションからネットリスト・タイプを継承します。

パーティションがリンクされると、以下に示すように、デザインをリコンパイルしたときに維持されるネットリストを変更することができます。

■ リンクされているすべてのパーティションがソース・コードまたは合成後のネットリストを使用するよう設定されている場合、パーティションは通常どおり再フィットされます。この場合、SignalProbeピンまたは ECOの変更は新しいネットリストには含まれないため、Change Manager での変更を再適用する必要があります。

■ リンクされているパーティションのいずれかが Post-Fit ネットリスト・タイプに設定され、ソース・コードが変更されていない場合、ソフトウェアはワーニングを発行し、すべてのリンク済みパーティションに対して配置配線を行ったフィッティング後のネットリストを内部で使用します。ソフトウェアは、適切なフィッティング後のネットリストを維持することにより、SignalProbeピンまたは ECOの変更を維持できます。



■ リンクされているパーティションのいずれかが Post-Fit（Strict）ネットリスト・タイプに設定されている場合、ソフトウェアはワーニングを発行し、ソース・コードが変更されているかどうかに関わらず、すべてのリンク済みパーティションに対して配置配線を行ったフィッティング後のネットリストを内部で使用します。ソフトウェアは、適切なフィッティング後のネットリストを維持することにより、SignalProbeピンまたは ECOの変更を維持できます。この場合、リンクされているパーティションでのソース・コードの変更は、新しいネットリストには含まれません。

■ ソース・コードの変更のためにリンクされているパーティションがリコンパイルされると、ソフトウェアはワーニングを発行し、他のリンク済みパーティションもリコンパイルします。これが起こると、SignalProbeピンまたは ECOの変更は新しいネットリストに含まれないため、Change Managerでの変更を再適用する必要があります。

エクスポートされたパーティション

ボトムアップ・インクリメンタル・コンパイルでは、エクスポートされたネットリストに現在保存されているすべての SignalProbe ピンまたはECOの変更が含まれます。これには子プロジェクトで下位レベル・パーティションをフラット化または組み合わせて、トップレベルでの境界違反を防がなければならない場合があります。このネットリストをインポートした後、下位レベル・パーティションで行った変更は、トップレベルの Change Managerには表示されません。

下位レベル・パーティションへのインタフェースに影響を与える ECOの変更を行った場合、ソフトウェアはエクスポート・プロセス中に、このネットリストはトップレベル HDL コードを変更して下位レベルの変更を反映しない場合はトップレベル・デザインで動作しない旨のワーニングを発行します。

ボトムアップ・コンパイル・フローの SignalTap IIエンベデッド・ロジック・アナライザSignalTap II エンベデッド・ロジック・アナライザは、コンパイルしてアルテラ・デバイスにプログラムすることができるプロジェクトで使用できます。

ボトムアップ・インクリメンタル・コンパイル・フローでは、SignalTap IIロジック・アナライザ用の SignalTap IIファイル（.stp）を使用する下位レベル・プロジェクトをエクスポートすることはできません。デザインをパーティションとしてエクスポートする前に、SignalTap II機能をディセーブルして、デザインをリコンパイルする必要があります。



下位レベル・デザインで SignalTap II メガファンクションを直接インスタンス化し（.stpファイルを使用する代わりに）、デザイン全体をボトムアップ・フローのトップレベルにエクスポートできます。ただし、2–87ページの「JTAG 機能を使用する下位レベル・パーティションのエクスポート」で説明するとおり、インスタンス化された SignalTap IIメガファンクションを含むプロジェクト内の下位レベル・パーティションをエクスポートすることはできません。

他のプロジェクトからインポートしたノードを含め、Quartus IIプロジェクトでは任意のノードをタップすることができます。Node Finder で適切なフィルタを使用してノード名を検索します。Netlist Typeが Post-Fitの場合、SignalTap II: post-fittingを使用して、フィッティング後のデータベースでノード名をインクリメンタルにタップします。Netlist TypeがSource Fileに設定されているときにソース・コードからパーティションを合成する場合、SignalTap II: pre-synthesisを使用して、ソース・ファイル（合成前）ノード名への接続を確立します。

インクリメンタル・フローにおける SignalTap IIロジック・アナライザの使用方法について詳しくは、「Quartus II ハンドブック Volume 3」の「Design Debugging Using the SignalTap II Embedded Logic Analyzer」の章を参照してください。

ボトムアップ・コンパイル・フローのロジック・アナライザ・インタフェースロジック・アナライザ・インタフェースはどのプロジェクトでも使用でき、コンパイルしてアルテラ・デバイスにプログラムすることができます。ボトムアップ・インクリメンタル・コンパイル・フローでは、ロジック・アナライザ・インタフェースを使用する下位レベル・プロジェクトをエクスポートすることはできません。デザインをパーティションとしてエクスポートする前に、ロジック・アナライザ・インタフェース機能をディセーブルして、デザインをリコンパイルする必要があります。

ロジック・アナライザ・インタフェースについて詳しくは、「Quartus IIハンドブック Volume 3」の「In-System Debugging Using External LogicAnalyzers」の章を参照してください。

JTAG機能を使用する下位レベル・パーティションのエクスポート2–47ページの「プロジェクト内の下位レベル・ブロックのエクスポート」では、プロジェクトのトップレベル・エンティテイではない下位レベルのパーティションをエクスポートする方法を説明しています。この機能







は、In-System Memory Content Editor、Nios® II OCI Debugおよび NiosII JTAG UART、Virtual JTAG Interface、MAX® II Serial Flash Loaderおよび Parallel Flash Loader、インスタンス化された SignalTap IIメガファンクションなど、デバイス JTAGインタフェースを使用する機能を持つパーティションに対してはサポートされていません。

ボトムアップ・インクリメンタル・コンパイル・フローでこれらの機能を使用するには、下位レベルの設計者が必ず Quartus IIプロジェクトのトップ・レベル・エンティテイをエクスポートするようにします。

デザイン・パーティションを持つプロジェクトの異なるデバイスへの移行パーティション・アサインメントは、異なるデバイス集積度またはデバイス・ファミリに移行した場合でも有効です。同じファミリのデバイスに移行した場合、LogicLock領域のサイズは有効ですが、Originの位置は無効になります。特定のフロアプラン・アサインメントは、異なるデバイスまたはデバイス・ファミリでは無効になります。これはデバイス間で位置座標が異なるためです。

同じファミリで異なるサイズのデバイスに移行した場合、合成後のネットリストは有効です。フィッティング後のネットリストは、異なるデバイス集積度またはデバイス・ファミリに移行した場合は、無効になります。

HardCopyコンパイル・フローおよび移行フロー

HardCopy APEXおよび HardCopy Stratixデバイス

Quartus II ソフトウェアを使用したインクリメンタル・コンパイルは、HardCopy APEXまたは HardCopy Stratixデザイン・フローではサポートされていません。

HardCopy ASIC移行フロー

トップダウン・インクリメンタル・コンパイルは、FPGA を最初に設計するフローおよび HardCopy を最初に設計するフローの両方のHardCopy移行フローにおけるベース・ファミリに対してサポートされています。デザイン・パーティション・アサインメントはコンパニオン・デバイスに移行されます。デザイン・パーティションには LogicLock領域が推奨されますが、デバイス・アーキテクチャが異なるため LogicLock領域はコンパニオン・デバイスには移行されません。ただし、デザインがベース・ファミリのコンパイル結果と一致しなくなるため、移行した



後でデザインを変更することはできません。したがって、1 つのデバイス・ファミリでトップダウン・インクリメンタル・コンパイルを実行できますが、移行後はインクリメンタル・コンパイルは実行できません。

マイグレーション・デバイスが指定されているとき（つまり、FPGA マイグレーション・デバイスによる HardCopy ASIC デバイスのコンパイル、または HardCopy ASIC マイグレーション・デバイスによる FPGAデバイスのコンパイル）には、FPGAまたはHardCopy ASICデバイス・コンパイル用のフィッティング後のネットリストでは Netlist Only維持レベルはサポートされません。

ボトムアップ・インクリメンタル・コンパイルは、マイグレーション・デバイス設定がある場合、HardCopy ASIC または FPGA デバイスのコンパイルではサポートされません。Revision Compare機能を使用するには、HardCopy ASIC および FPGA ネットリストが同じでなければなりません。したがって、1 つのリビジョンで実行されるすべての操作を別のリビジョンでも行う必要があります。これは、すべての操作を記録しておき、それを別のリビジョンで再生することによって行われます。ボトムアップ・フローの使用およびパーティションのインポートでは、この要件はサポートされません。コンパイル間でどのグローバル・アサインメントも変更しない限り、Emptyパーティションでトップダウン・フローを使用して、ボトムアップ・フローに似た動作を実現できる場合がよくあります。すべてのグローバル・アサインメントはコンパイルされたすべてのパーティションで同じはずなので、移行後にコンパニオン・デバイスでアサインメントを再生成できます。

HardCopy ASICスタンドアロン・コンパイル

トップダウンおよびボトムアップ・インクリメンタル・コンパイルの両方を、スタンドアロン HardCopy ASICコンパイルに使用できます。

HardCopy ASICでは、配線の維持はサポートされません。したがって、Placement and Routing維持レベルは使用できず、ボトムアップ・フローで配線をエクスポートすることはできません。

ボトムアップ・フローの HDLソース・コードで作成されるアサインメント下位レベル・パーティションでの I/Oプリミティブまたは altera_attribute HDL合成属性付きで作成されたアサインメントは、ボトムアップ・フローのトップレベルでは現在サポートされていません。これらのアサインメントはトップレベルで処理されますが、インポート後にネットリスト・データベースに適用できない場合があります。Fitter関連のアサインメント（I/Oターミネーション設定など）は、合成後の .qxpファイルを使用すると正しく適用できます。



フィジカル・シンセシス最適化を行う場合のコンパイル時間フィジカル・シンセシスをオンにすると、フィッティング後のネットリストで固定されていないパーティションの配置があると最適化が実行されます。例えば、SignalTap II ロジック・アナライザを使用すると、配置が維持されていない SignalTap II インスタンスに対して自動的にパーティションが作成されます。

フィジカル・シンセシスはフィッティング後のネットリストを使用するパーティションのロジックを最適化しないため、デザインの多くがフィッティング後のネットリストを使用するときには、コンパイル時間が短縮されます。

タイミング利用またはリソース利用の目標を満たすのにフィジカル・シンセシスの最適化を必要としないパーティションをリコンパイルする場合は、フィジカル・シンセシスをオフにして余分なコンパイル時間をなくすことができます。例えば、すべてのパーティションでフィッティング後のネットリストを使用するデザインで、SignalTap II ロジック・アナライザを使用するときは、フィジカル・シンセシスをオフにしてコンパイル時間を短縮することができます。フィジカル・シンセシスを最初に実行する必要があるクリティカル・パーティションをコンパイルし、それらのパーティションのタイミングを閉じることも可能です。これらのパーティションでロジックを変更する必要がない場合は、クリティカル・パーティションを Post-Fit に設定します。これにより、以降のコンパイルではフィジカル・シンセシスをオフにすることができます。タイミング・クリティカルなパーティションを変更し、フィジカル・シンセシスを最適化した新しいロジックをリコンパイルする場合は、必ずオプションをオンにしてください。

メガファンクション・パーティションの制約Quartus II ソフトウェアは、パーティションのメガファンクション・インスタンス化はサポートしません。MegaWizard® Plug-In Managerを使用してメガファンクション・バリエーションをカスタマイズする場合、MegaWizard で生成されたラッパー・ファイルは、メガファンクションをインスタンス化します。MegaWizard で生成されたメガファンクション・カスタム・バリエーション・ラッパー・ファイルに対して、パーティションを作成できます。

Quartus II ソフトウェアは、推測されたメガファンクションに対するパーティションの作成をサポートしていません（すなわち、ここではソフトウェアはデザインにロジックを実装するためのメガファンクションを推測します）。ロジックに対するモジュールまたはエンティティが推測される場合、デザインのその階層レベルにパーティションを作成できます。



Quartus II ソフトウェアは、コンパイル中にダイナミックに生成されるQuartus II 内部階層に対しては、メガファンクションの内容を実装するためのパーティションの作成はサポートしていません。

配線の維持デバイス・アーキテクチャの適法性のために、特にボトムアップ・コンパイルで配線情報が正確に維持されない場合があります。例えば、複数のパーティションをインポートすると、各下位レベル・ブロックに事前に配線を割り当てることができないため、配線衝突が発生する場合があります。さらに、トップレベル・デザインでインポートされた LogicLock領域が移動すると、ノードの相対的な配置は維持されますが、配線は維持されない場合があります。

TimeQuestタイミング・アナライザの Synopsys Design Constraintsファイル2–49ページの「アサインメントおよび高度なインポート設定のインポート」で説明したように、.sdcファイルの TimeQuestタイミング・アナライザ用のタイミング・アサインメントは、トップレベル・プロジェクトにインポートされません。トップレベル・プロジェクトに、プロジェクト全体のタイミング要件がすべて含まれていることを手動で確認する必要があります。

下位レベルの .sdcファイルをトップレベル・プロジェクトにコピーする場合は、デザイン階層での制約の位置を記述する変数を持つ下位レベルの制約にプリフィックスを付けることを考慮してください。また、ファイルをトップレベル・デザインにコピーする場合は、トップレベル・デザインの下位レベル・パーティションに階層パスが提供されるように変数を設定できます。

ボトムアップ・デザイン・パーティションのスクリプトの制限Quartus II ソフトウェアには、ボトムアップ・デザイン・パーティションのスクリプトに関連するいくつかの制限があります。

ボトムアップ・デザイン・パーティション・スクリプトでのTimeQuestタイミング・アナライザの Synopsys Design Constraintsファイル

2–52 ページの「プロジェクト管理のためのボトムアップ・デザイン・パーティションのスクリプトの生成」で説明するように、デザイン・パーティション・スクリプトには、TimeQuestタイミング・アナライザのク



ロック制約と最小および最大遅延設定のみ含まれています。PLL設定およびタイミング例外は、スクリプトで下位レベルのデザインに渡されないことに注意してください。

ボトムアップ・デザイン・パーティションのスクリプトのワイルドカード・サポート

ワイルドカードの制約を適用する場合、ワイルドカードは階層境界を越えて解析されません。例えば、以下のノードに対してアサインメントTop|A:inst|B:inst|* を作成できます。Aと Bは下位レベル・パーティション、階層 Bは Aの子、すなわち Bは階層 Aでインスタンス化されています。このアサインメントはモジュール A、B、および Bのすべての子インスタンスに適用されます。ただし、アサインメントTop|A:inst|B:inst*は階層 Aに適用されますが、Bのインスタンスには適用されません。これは B:inst* で表される単一レベルの階層が、複数の階層レベルに拡大されないためです。この問題を回避するために、階層境界が複数の階層レベルを表す場合は、必ず階層境界にワイルドカードを適用してください。

ワイルドカードを使用して 1 レベルの階層を表す場合は、1 つのワイルドカードのみサポートされます。これは、Top|A:inst|*|B:inst|* などのアサインメントがサポートされないことを意味します。このような場合、Quartus IIソフトウェアはワーニングを出します。

ボトムアップ・デザイン・パーティションのスクリプトの派生クロックおよび PLL

トップレベルのクロックが下位レベル・パーティションのピンに直接接続されていない場合、下位レベルのパーティションはデザイン・パーティション・スクリプトでトップレベル・ピンからアサインメントも制約も受け取りません。

この問題は、タイミング制約とクロック・グループ設定を必要とするクロック・ピンに特に重要です。デザインでクロック入力ピンから新しいクロックを派生させるために、ロジックまたは反転を使用している場合に、問題が発生する可能性があります。制約なしのクロックにならないために、下位レベル Quartus IIプロジェクトで適切なタイミング・アサインメントを作成します。



また、トップレベル・デザインで PLL を使用し、PLL を下位レベル・パーティションに接続する場合、下位レベル・パーティションは PLLの乗算係数または位相シフト係数に関する情報を受け取りません。制約なしのクロックにならないため、あるいは不正な周波数で制約されないために、下位レベル Quartus IIプロジェクトで適切なタイミング・アサインメントを作成します。あるいは、完全かつ正確なタイミング解析のために、乗算係数または位相シフト係数、補正遅延および他の PLL パラメータが正しくなるように、下位レベル・デザイン・ファイルにあるトップレベルの派生クロック・ロジックまたは PLL を手動で複製します。トップレベルにエクスポートされる下位レベル・デザイン・ロジックの残りのためにデザイン・パーティションを作成します。下位レベル・デザインが完成したら、2–47ページの「プロジェクト内の下位レベル・ブロックのエクスポート」の機能を使用して、関連ロジックを含むパーティションのみエクスポートします。

ボトムアップ・デザイン・パーティションのスクリプトの GXBおよび LVDSブロックに対するピン・アサインメント

スクリプトには、高速 GXB トランシーバおよびハード LVDS ブロックに対するピン・アサインメントは記述されません。下位レベル・プロジェクトに手動でこれらのハード IPブロックに対するピン・アサインメントを追加する必要があります。

ボトムアップ・デザイン・パーティションのスクリプトの仮想ピン・タイミング・アサインメント

デザイン・パーティションのスクリプトでは、INPUT_MAX_DELAYアサインメントと OUTPUT_MAX_DELAYアサインメントを使用して、通常はプロジェクトから見えない入力ピンおよび出力ピンに関連するパーティション間遅延を指定します。これらのアサインメントでは、ソフトウェアがアサインメントのクロック・ドメインを指定し、このクロック・ドメインを ‘*’に設定する必要があります。

このクロック・ドメインは、タイミング解析エンジンにより制約されレポートされる、不要なパスがいくつか存在する場合があることを意味します。

クロック・ドメインがこれらのアサインメントに含まれるのを制限するために、生成されたスクリプトを編集するか、下位レベル Quartus IIプロジェクトでのアサインメントを変更します。さらに、遅延アサインメントに関連する既知のクロックがないので、ソフトウェアはワースト・ケース・スキューを想定するため、パスはトップレベル・デザインの場合よりもタイミング・クリティカルに見えます。よりタイミング・クリティカルでないパスにするには、スクリプトの遅延値を小さくします。必要に応じて、入力および出力遅延値に負数を入力します。



ボトムアップ・デザイン・パーティションのスクリプトでの複数の下位レベル・ピンを供給するトップレベル・ポート

下位レベル・モジュールで 1つのトップレベルの I/Oポートで複数のピンをドライブする場合、下位レベルの合成と配置の品質は必ずしも制限されません。これが起こるのは、下位レベルのデザインでは、ソフトウェアが階層境界を維持する必要があり、トップレベルでは論理上同等のピンに関する情報を使用できないためです。さらに、I/O制約はトップレベルのピンからそれぞれの子に渡されるため、トップレベルよりも多くのピンを下位レベルで持つことができます。これらのピンはトップレベルの I/O制約および配置オプションを使用するため、下位レベルでは配置できない場合があります。ソフトウェアは可能な限りこの状況を回避しますが、このようなデザイン手法を使用しないで、これらの潜在的な問題を回避することが得策です。1つの I/Oポートがデザイン・パーティション境界に信号を供給し、下位レベル・パーティション内で接続が複数の信号に分割されるようにデザインを再構築します。

レジスタ・パッキングおよびパーティション境界Quartus II ソフトウェアは、コンパイル中にレジスタ・パッキングを自動的に実行します。ただし、インクリメンタル・コンパイルが有効な場合、異なるパーティションのロジックを一緒にパッキングすることはできません。これはパーティション境界により境界間最適化が阻止されるためです。この制限は、I/Oセル、DSPブロック、シーケンシャル・ロジック、無関係なロジックを含むすべてのタイプのレジスタ・パッキングに適用されます。

I/Oレジスタ・パッキングI/Oレジスタのパーティション間レジスタ・パッキングは、トップレベル階層（およびトップ・パーティション）に入力ピンと出力ピンが存在するが、対応する I/Oレジスタが他のパーティションに存在する特定の状況で許容されます。

入力ピンのパーティション間レジスタ・パッキングには、以下の状況が要求されます。

■ 入力ピンが 1個のレジスタのみを供給する。■ 入力ピンとレジスタ間のパスに、それぞれ1ファンアウトを持つパーティションの入力ポートのみが含まれている。



出力レジスタのパーティション間レジスタ・パッキングには、以下の状況が要求されます。

■ レジスタが 1本の出力ピンのみ供給する。■ 出力ピンが 1つの信号でのみ供給される。■ レジスタと出力ピン間のパスに、それぞれ1ファンアウトを持つパーティションの出力ポートのみが含まれている。

出力イネーブル信号を持つ出力ピンは、出力イネーブル・ロジックが出力レジスタと異なるパーティションに含まれている場合、デバイス I/Oセルにパッキングできません。出力イネーブル信号を持つ出力ピンのレジスタ・パッキングを可能にするには、レジスタとトライステート・ロジックが同じパーティションで定義されるように、HDLコードまたはデザイン・パーティション・アサインメントを構築します。

双方向ピンは、出力イネーブル信号付きの出力ピンと同様に処理されます。パッキングが必要なレジスタがトライ・ステート・ロジックと同じパーティションにある場合、レジスタ・パッキングを実行できます。

トライ・ステート・ロジックの制約は、I/O素子（デバイス・プリミティブ）がトライ・ステート・ロジックを含むパーティションの一部として作成されるために課されます。I/O レジスタとそのトライ・ステート・ロジックが同じパーティションにある場合、レジスタは常にトライ・ステート・ロジックと一緒に I/O 素子にパッキングできます。同じパーティション間レジスタ・パッキング制約が、入力ピンと出力ピンの I/O素子にも適用されます。I/O素子は正確に 1つの信号を I/Oピンに直接供給しなければなりません。I/O素子と I/Oピン間のパスに、それぞれ1ファンアウトを持つパーティションの出力ポートのみが含まれている。

パーティション境界をまたがる I/Oレジスタ・パッキングの例

以下の例で、各種 I/Oおよびパーティション・コンフィギュレーションを詳細に説明しています。これらの例では、デザイン・ロジックを示すのにブロック・デザイン・ファイル（BDF）回路図を使用しています。

例 1—出力ピンに供給するパーティションの出力レジスタこの例では、図 2–13に示すように、サブデザインに 1個のレジスタが含まれています。



図 2–13. 1個のレジスタを持ち、個別のパーティションとして指定されたサブデザイン

図 2–14に示すように、トップレベルのデザインは、出力ピンに直接供給する 1ファンアウトを持つサブデザインをインスタンス化し、このサブデザインを個別のデザイン・パーティションとして指定します。

図 2–14.図 2–13のサブデザインを出力レジスタとしてインスタンス化するトップレベル・デザイン

Quartus IIソフトウェアは、ピン outに Fast Output Registerアサインメントが作成されている場合は、パーティション間レジスタ・パッキングを実行します。このタイプのパーティション間出力レジスタ・パッキングが許可されるのは、サブデザインのパーティションのポート・インタフェースを変更する必要がなく、パーティション・ポートが出力ピンに直接供給されるためです。

例 2—複数の出力ピンに供給するパーティションの出力レジスタこの例では、個別のパーティションとして指定されたサブデザインには、図 2–13に示すレジスタがあります。トップレベルのデザインは、図 2–15に示すように、複数のファンアウト信号を持つ出力レジスタとしてサブデザインをインスタンス化します。



図 2–15.図 2–13の 2つの出力ピンを持つサブデザインをインスタンス化するトップレベル・デザイン

この場合、ソフトウェアは出力レジスタ・パッキングを実行しません。ピンoutにFast Output Registerアサインメントが作成されている場合、ノードと I/Oセルがデザイン・パーティション境界を越えて接続されているため、Fitter がノードを I/O ピンにパッキングできないことを知らせるワーニングが I/Oピンに発行されます。

このタイプのパーティション間レジスタ・パッキングは、サブデザイン・パーティションのインタフェースへの変更が必要になるため許可されません。インクリメンタル・コンパイルを実行するには、デザイン・パーティションのインタフェースを維持する必要があります。

図 2–13 のサブデザインのレジスタを図 2–15 の出力ピン out と一緒にパッキングさせるには、以下の変更のいずれかを行います。

■ サブデザインへのデザイン・パーティション・アサインメントを削除します。これにより、Fitter はすべての階層間最適化を実行できます。ただし、階層のこのブロックに対するインクリメンタル・コンパイルは使用できなくなります。適切なデザイン・パーティションでは、Fitter が境界間最適化を実行する必要がないように、インタフェースが正しく定義されている必要があります。

■ HDLコードを再構築し、レジスタを出力ピンと同じパーティションに配置します。最も簡単な方法は、サブデザイン・パーティションのレジスタを出力ピンを含むパーティションに移動することです。これにより、Fitter はパーティション境界に違反しないで、2 つのノードを確実に最適化できます。

■ レジスタが 1本の出力ピンのみ供給するように、HDLコードを再構築します。Analysis & Synthesis設定 Remove Duplicate Registersをオフにします。図 2–16に示すように、各レジスタが 1本のピンにのみ供給するように、サブデザイン HDL のレジスタを複製し、次に図 2–17に示すように、余分な出力ピンをトップレベル・デザイン



の新しいポートに接続します。これによって、パーティション間レジスタ・パッキングはレジスタが 1つのファンアウトを持つ最も簡単なケースに変換されます。

図 2–16. 2個の出力レジスタおよび 2個の出力ポートで変更した図 2–13のサブデザイン

図 2–17. 2個の出力ポートを 2本の出力ピンに接続した図 2–15の変更後トップレベル・デザイン

例 3—出力ピンに供給するパーティションの出力レジスタ、出力イネーブル・レジスタおよびトライ・ステート・ロジックこの例では、個別パーティションとして指定されたサブデザインには、図 2–18に示すように、出力レジスタ、出力イネーブル・レジスタ、および出力ピンをドライブするトライ・ステート・ロジックがあります。トップレベル・デザインは、図 2–19に示すように、出力ピンに直接供給する単一ファンアウトを持つサブデザインをインスタンス化します。



図 2–18.別のパーティションとして指定された、出力レジスタ、出力イネーブル・レジスタ、およびトライ・ステート・ロジックを含むサブデザイン

図 2–19.図 2–18のサブデザインをインスタンス化するトップレベル・デザイン

Quartus IIソフトウェアは、ピン outに Fast Output Enable Registerアサインメント、Fast Output Register アサインメント、またはその両方が作成されている場合は、パーティション間レジスタ・パッキングを実行します。このタイプのパーティション間出力レジスタ・パッキングが許可されるのは、サブデザインのパーティションのポート・インタフェースを変更する必要がなく、パーティション境界を越えてロジックを最適化する必要がなく、またパーティション・ポートが出力ピンに直接供給されるためです。

例 4—トライ・ステート出力ピンに供給するパーティションの出力レジスタと出力イネーブル・レジスタこの例では、個別パーティションとして指定されたサブデザインに、図 2–20に示す 2個のレジスタがあります。トップレベル・デザインは、図 2–21に示すように、出力をドライブするレジスタと、出力ピンのための出力イネーブル信号を含むサブデザインをインスタンス化します。




図 2–21.図 2–22 のサブデザインをインスタンス化し、出力イネーブル・ロジックをドライブするトップレベル・デザイン

この場合、ソフトウェアはレジスタ・パッキングを実行できません。ピンoutにFast Output RegisterアサインメントまたはFast Output EnableRegisterアサインメントが作成されている場合、ノードと I/Oセルがデザイン・パーティション境界を越えて接続されているため、Fitterがノードを I/Oピンにパッキングできないことを知らせるワーニングが発行されます。

同じ制約は、トップレベル・デザインに出力レジスタまたは出力イネーブル・レジスタ、およびトライ・ステート・ロジックが含まれている場合に適用されます。ソフトウェアは、サブデザイン・パーティションを構成するレジスタを I/Oレジスタにパッキングすることはできません。

このタイプのレジスタ・パッキングは、デザイン・パーティション境界を越えてロジックを移動し、単一の I/Oデバイス素子に配置する必要があるため許可されません。レジスタ・パッキングを実行するには、レジスタをサブデザイン・パーティションの外に移動するか、トライ・ステート・ロジックをサブデザイン・パーティション内に移動する必要があります。以降のインクリメンタル・コンパイルでデザインの正確性を保証するために、デザイン・パーティションの内容を維持する必要があります。



図 2–20のサブデザインの出力レジスタと出力イネーブル・レジスタまたはその両方を、図 2–21の出力ピン outでソフトウェアにパッキングさせるには、以下の変更のいずれかを行います。

■ サブデザインへのデザイン・パーティション・アサインメントを削除します。これにより、Fitter はすべての階層間最適化を実行できます。ただし、階層のこのブロックに対するインクリメンタル・コンパイルは使用できなくなります。適切なデザイン・パーティションでは、Fitter が境界間最適化を実行する必要がないように、インタフェースが正しく定義されている必要があります。

■ HDLコードを再構築し、レジスタを出力ピンと同じパーティションに配置します。最も簡単な方法は、サブデザイン・パーティションのレジスタを出力ピンを含むトップレベルのパーティションに移動することです。これにより、Fitter はパーティション境界に違反しないで、2つのノードを確実に最適化できます。

■ レジスタとトライ・ステート・ロジックが同じパーティションに含まれるように、HDLコードを再構築します。図 2–18に示すように、トライ・ステート・ロジックをトップレベル・ブロックから 2つのレジスタを含むサブデザインに移動します。次に、図 2–19に示すように、トップレベル・デザインの出力ピンにサブデザインを接続します。

例 5—双方向ピンに供給するパーティションの双方向ロジック双方向ピンの動作は、出力イネーブル信号付きの出力ピンの動作に似ています。レジスタ・パッキングを可能にするために、レジスタを双方向ピンをドライブするトライ・ステート・ロジックと同じパーティションに含める必要があります。

この例では、個別パーティションとして指定されたサブデザインには、図 2–22に示すように、3個のレジスタと双方向ピンのためのトライ・ステート・ロジックが含まれています。トップレベル・デザインは、図 2–23に示すように、双方向ピンと出力ピンに供給するポートを含むサブデザインをインスタンス化します。



図 2–22. 3 個のレジスタおよびトライ・ステート・ロジックを持ち、個別のパーティションとして指定されたサブデザイン

図 2–23.図 2–25のサブデザインをインスタンス化するトップレベル・デザイン

Quartus IIソフトウェアは、ピン bidirに Fast Output Registerアサインメント、Fast Output Enable Register アサインメント、または FastInput Register アサインメントが作成されている場合は、パーティション間レジスタ・パッキングを実行します。このタイプのパーティション間出力レジスタ・パッキングが許可されるのは、サブデザインのパーティションのポート・インタフェースを変更する必要がなく、パーティション・ポートが双方向ピンに直接供給されるためです。

異なるパーティションにレジスタとトライ・ステート・ロジックを持つデザインでは、レジスタをパッキングできません。2–99 ページの「例4—トライ・ステート出力ピンに供給するパーティションの出力レジスタと出力イネーブル・レジスタ」で説明する状況は、トップレベル・デザインで出力ピン outを双方向ピンに置き換えている場合には、双方向ピンにも同様に適用されます。



例 6—入力ピンにより供給されるパーティションの入力レジスタこの例では、図 2–24に示すように、サブデザインに 1個のレジスタが含まれています。トップレベル・デザインは、図 2–25に示すように、入力ピンによって直接供給される1つのfaninを持つサブデザインをインスタンス化し、サブデザインを個別のデザイン・パーティションとして指定します。


図 2–25.図 2–24のサブデザインを入力レジスタとしてインスタンス化するトップレベル・デザイン

Quartus IIソフトウェアは、ピン inに Fast Input Registerアサインメントが作成されている場合は、パーティション間レジスタ・パッキングを実行します。このタイプのパーティション間入力レジスタ・パッキングが許可されるのは、サブデザインのパーティションのポート・インタフェースを変更する必要がなく、入力ピンがパーティション・ポートに直接供給されるためです。

例 7—複数のファンアウトを持つ入力により供給されるパーティションの入力レジスタ

この例では、個別のパーティションとして指定されたサブデザインには、図 2–24に示すレジスタがあります。トップレベル・デザインは、入力レジスタとしてサブデザインをインスタンス化しますが、図 2–26に示すように、入力ピンによって別のデスティネーションにも供給されます。



図 2–26. 2 つのデスティネーションを持つピンの入力レジスタとして、図 2–24 のサブデザインをインスタンス化するトップレベル・デザイン

この場合、ソフトウェアは入力レジスタ・パッキングを実行しません。ピン in に Fast Input Register アサインメントが作成されている場合、ノードと I/Oセルがデザイン・パーティション境界を越えて接続されているため、Fitter がノードを I/O ピンにパッキングできないことを知らせるワーニングが I/Oピンに発行されます。

このタイプのパーティション間レジスタ・パッキングは、サブデザイン・パーティションのインタフェースへの変更が必要になるため許可されません。インクリメンタル・コンパイルを実行するには、デザイン・パーティションのインタフェースを維持する必要があります。

図 2–24のサブデザインのレジスタを図 2–26の出力ピンinと一緒にパッキングさせるには、以下の変更のいずれかを行います。

■ サブデザインへのデザイン・パーティション・アサインメントを削除します。これにより、Fitter はすべての階層間最適化を実行できます。ただし、階層のこのブロックに対するインクリメンタル・コンパイルも使用できなくなります。適切なデザイン・パーティションでは、Fitter が境界間最適化を実行する必要がないように、インタフェースが正しく定義されている必要があります。

■ HDLコードを再構築し、レジスタを入力ピンと同じパーティションに配置します。最も簡単な方法は、サブデザイン・パーティションのレジスタを入力ピンを含むパーティションに移動することです。これにより、Fitter はパーティション境界に違反しないで、2 つのノードを確実に最適化できます。

例 8—入力ピンにより供給されるパーティションの反転入力レジスタこの例では、個別のパーティションとして指定されたサブデザインには、図 2–27に示す反転レジスタが含まれています。トップレベル・デザインは、図 2–28に示すように、入力レジスタとしてサブデザインをインスタンス化します。



図 2–27. 1個の反転レジスタを持ち、個別のパーティションとして指定されたサブデザイン

図 2–28.図 2–27のサブデザインを入力レジスタとしてインスタンス化するトップレベル・デザイン

Quartus IIソフトウェアは、ピン inに Fast Input Registerアサインメントが作成されている場合は、パーティション間レジスタ・パッキングを実行します。このタイプのパーティション間入力レジスタ・パッキングが許可されるのは、パーティション内の入力レジスタとの反転のためのロジックを実装できるので、入力ピンがパーティション・ポートに直接供給されるためです。

例9—反転入力ピンにより供給されるパーティションの入力レジスタ、または反転出力ピンに供給するパーティションの出力レジスタ

この例では、個別のパーティションとして指定されたサブデザインには、図 2–29に示すレジスタがあります。図 2–30のトップレベル・デザインは、入力ピンが反転した入力レジスタとしてサブデザインをインスタンス化します。図 2–31のトップレベル・デザインは、出力ピンに供給する前に信号が反転した出力レジスタとしてサブデザインをインスタンス化します。




図 2–30.反転した入力ピンを持つ入力レジスタとして、図 2–29 のサブデザインをインスタンス化するトップレベル・デザイン

図 2–31.反転した出力ピンに供給する出力レジスタとして図 2–30 のサブデザインをインスタンス化するトップレベル・デザイン

この場合、ソフトウェアはレジスタ・パッキングを実行しません。図 2–30のピン inに Fast Input Registerアサインメントが作成されている場合、または図 2–31のピン outに Fast Output Register アサインメントが作成されている場合、ノードと I/Oセルがデザイン・パーティション境界を越えて接続されているため、Fitter がノードを I/O ピンにパッキングできないことを知らせるワーニングが I/Oピンに発行されます。

このタイプのレジスタ・パッキングは、デザイン・パーティション境界を越えてロジックを移動し、単一の I/Oデバイス素子に配置する必要があるため許可されません。レジスタ・パッキングを実行するには、レジスタをサブデザイン・パーティションの外に移動するか、インバータをレジスタに実装するサブデザイン・パーティション内に移動する必要があります。以降のインクリメンタル・コンパイルでデザインの正確性を保証するために、デザイン・パーティションの内容を維持する必要があります。


スクリプトのサポート

図 2–29のサブデザインのレジスタを図 2–30の入力ピンinまたは図 2–31の出力ピン outと一緒にパッキングさせるには、以下の変更のいずれかを行います。

■ サブデザインからのデザイン・パーティション・アサインメントを削除します。これにより、Fitter はすべての階層間最適化を実行できます。ただし、階層のこのブロックに対するインクリメンタル・コンパイルは使用できなくなります。適切なデザイン・パーティションでは、Fitter が境界間最適化を実行する必要がないように、インタフェースが正しく定義されている必要があります。

■ HDLコードを再構築し、レジスタをピンと同じパーティションに配置します。最も簡単な方法は、サブデザイン・パーティションのレジスタをピンを含むトップレベルのパーティションに移動することです。これにより、Fitterはパーティション境界に違反しないで、2つのノードを確実に最適化できます。

■ レジスタとインバータが同じパーティションに含まれるように、HDLコードを再構築します。インバータをトップレベル・ブロックから入力ピンの図 2–27に示すサブデザインに移動します。次に、入力ピンの図 2–28に示すように、トップレベル・デザインのピンにサブデザインを接続します。


この章で説明する手順の実行と設定は Tcl スクリプトで行うことができます。また、一部の手順はコマンド・プロンプトでも実行できます。スクリプティング・コマンド・オプションについて詳しくは、Quartus IICommand-Lineおよび Tcl API Helpブラウザを参照してください。このHelpブラウザを使用するには、コマンド・プロンプトで次のコマンドを入力します。

quartus_sh --qhelp ↵r

「Quartus II Scripting Reference Manual」には、同じ情報が PDF形式で付属しています。

Tclスクリプトについて詳しくは、「Quartus IIハンドブック Volume 2」のTcl スクリプトの章を参照してください。Quartus II ソフトウェアにおける設定および制約について詳しくは、「Quartus II Settings FileReference Manual」を参照してください。コマンドライン・スクリプトについて詳しくは、「Quartus IIハンドブック Volume 2」の「Command-Line Scripting」の章を参照してください。

http://www.altera.com/literature/manual/TclScriptRefMnl.pdf


http://www.altera.co.jp/literature/hb/qts/qts_qii52003_j.pdf0

http://www.altera.com/literature/manual/mnl_qsf_reference.pdf

http://www.altera.com/literature/manual/mnl_qsf_reference.pdf





Generate Incremental Compilation Tcl Scriptコマンドフル・インクリメンタル・コンパイルのためにテンプレート Tcl スクリプトを作成するには、Generate Incremental Compilation Tcl Script機能を使用します。Design Partitions Window を右クリックし、GenerateIncremental Compilation Tcl Scriptをクリックします。

ユーザー・インタフェースでパーティション・アサインメントを作成している場合、このスクリプトにはアサインメントの Tcl 記述が含まれています。Tclアサインメントについては、以下の項で説明しています。

インクリメンタル・コンパイルのためのデザインの準備インクリメンタル・コンパイルの現在のモードを設定または変更するには、以下のコマンドを使用します。

set_global_assignment -name INCREMENTAL_COMPILATION \<value>

インクリメンタル・コンパイルの <value> の設定は、以下の値のいずれかでなければなりません。

■ FULL_INCREMENTAL_COMPILATION— フル・インクリメンタル・コンパイル（これがデフォルトです）

■ INCREMENTAL_SYNTHESIS—インクリメンタル・シンセシスのみ■ OFF—インクリメンタル・コンパイルは実行されない

デザイン・パーティションの作成パーティションを作成するには、以下のコマンドを使用します。

set_instance_assignment -name PARTITION_HIERARCHY \<file name> -to <destination> -section_id <partition name>

<destination>はエンティティの短縮階層パスになります。短縮階層パスは、完全な階層パスからトップレベル名を除いたものです（クオーテーション・マークを含む）。以下に例を示します。

"ram:ram_unit|altsyncram:altsyncram_component"

トップレベル・パーティションでは、トップレベル・エンティティの表現にパイプ（|）シンボルを使用できます。



階層ネーミング規則について詳しくは、「Quartus II ハンドブックVolume 1」の「Quartus II Integrated Synthesis」の章の「Node-NamingConventions in Quartus II Integrated Synthesis」を参照してください。

<partition name> は、ユーザー指定のパーティション名で、1024 文字未満の固有の名前とします。名前に使用できるのは、英数字、パイプ（ |）、コロン（ :）、アンダースコア（ _）だけです。アルテラでは名前をダブル・クォーテーション・マーク（" "）で囲むことを推奨しています。

<file name> は、インクリメンタル・コンパイル中に内部で生成されるネットリスト・ファイルに使用される名前です。ユーザー・インタフェースでパーティションを作成する場合に、ネットリスト名はインスタンス名に基づいて Quartus II ソフトウェアで自動的に設定されます。Tcl を使用してパーティションを作成している場合、すべてのパーティションで固有のカスタム・ファイル名を割り当てる必要があります。トップレベル・パーティションでは、指定されたファイル名は無視され、ダミー値を使用できます。名前の保護およびプラットフォーム独立性を確保するために、ファイル名は状況に関係なく固有でなければなりません。例えば、パーティションがファイル名 my_file を使用している場合、他のパーティションはファイル名MY_FILEを使用することはできません。簡潔にするために、アルテラではパーティションの対応するインスタンス名に基づいてファイル名を指定することを推奨しています。

すべてのネットリストは、\dbコンパイル・データベース・ディレクトリに保存されます。

デザイン・パーティションのプロパティの設定パーティションが作成された後、以下のコマンドを使用してNetlist Typeを設定します。

set_global_assignment -name PARTITION_NETLIST_TYPE <value> -section_id \<partition name>

ネットリスト・タイプの <value>の設定は、以下の値のいずれかです。

■ SOURCE—Source File■ POST_SYNTH—Post-Synthesis■ POST_FIT—Post-Fit■ STRICT_POST_FIT—Post-Fit (Strict)■ IMPORTED—Imported■ IMPORT_BASED_POST_FIT—Post-Fit (Import-based)■ EMPTY—Empty




以下のコマンドを使用して、フィッティング後またはインポート後のネットリストに Fitter Preservation Levelを設定します。

set_global_assignment -name PARTITION_FITTER_PRESERVATION_LEVEL <value>\-section_id <partition name>

Fitter Preservation Levelの <value>の設定は、以下の値のいずれかになります。

■ NETLIST_ONLY—Netlist only■ PLACEMENT—Placement■ PLACEMENT_AND_ROUTING—Placement and routing■ PLACEMENT_AND_ROUTING_AND_TILE— Placement and routing,

as well as the power tile setting of high-speed or low-power

上記のパーティションのプロパティについて詳しくは、「デザイン・パーティションのプロパティの設定」を参照してください。

適切なフロアプラン・ロケーション・アサインメントの作成—特定のデバイス・エレメント（RAMブロックまたはDSPブロックなど）の除外またはフィルタリングリソースのフィルタリングは、LogicLock Tclパッケージのset_logiclock_contents関数の Tcl引数-exclude_resources（オプション）を使用します。指定しない場合、リソース・フィルタは作成されません。

引数は入力として除外リソースのリストを使用します。リストは以下のキーワードから成るコロン区切りの文字列です。

表 2–4.除外されるリソースのキーワード

キーワードリソースREGISTER ロジック・セルの任意のレジスタ。

COMBINATIONAL ロジック・セルの組み合わせエレメント。

SMALL_MEM 小容量のTriMatrixメモリ・ブロック(M512またはMLAB)

MEDIUM_MEM 中容量の TriMatrixメモリ・ブロック（M4Kまたは M9K）

LARGE_MEM 大容量の TriMatrix メモリ・ブロック（M-RAM またはM144K）

DSP 任意の DSPブロック

VIRTUAL_PIN 任意の仮想ピン



例えば、以下のコマンドはすべての DSPブロックとM512ブロックを除く、alu:alu_unit内のすべての項目を ALU領域に割り当てます。

set_logiclock_contents -region ALU -to alu:alu_unit -exceptions \"DSP:SMALL_MEM"

QSFで、リソース・フィルタリングは LL_MEMBER_RESOURCE_EXCLUDEと呼ばれる特別な LogicLockメンバーシップ・アサインメントを使用します。例えば、QSF の以下の行は、ALU 領域に割り当てられるalu:alu_unit エンティティにリソース・フィルタを指定するのに使用されます。アサインメントの値は、以前の Tclコマンドで使用されたリソース・リスト文字列と同じ形式をとります。

set_instance_assignment -name LL_MEMBER_RESOURCE_EXCLUDE "DSP:SMALL_MEM" \-to "alu:alu_unit" -section_id ALU

ボトムアップ・デザイン・パーティション・スクリプトの生成スクリプトを生成するために、Tclプロンプトでは以下の Tclコマンドを入力します。

generate_bottom_up_scripts <options> ↵r

コマンドはコマンドが使用される前に、以下のコマンドを使用してロードする必要がある database_managerパッケージの一部です。

load_package database_manager

スクリプトを生成する前に、プロジェクトを開く必要があります。

Tclオプションは GUIで使用できるものと同じです。各オプションの正確なフォーマットは表 2–5に規定されています。

表 2–5. Tclコマンドでボトムアップ・パーティション・スクリプトを生成するためのオプション（１ /２）

オプションデフォルト-include_makefiles <on|off> オン

-include_project_creation <on|off> オン

-include_virtual_pins <on|off> オン

-include_virtual_pin_timing <on|off> オン

-include_virtual_pin_locations <on|off> オン



以下の例では、Tclコマンドの使用方法を示しています。

load_package database_managerset project test_projproject_open $projectgenerate_bottom_up_scripts -bottom_up_scripts_output_directory test \

-include_virtual_pin_timing on -virtual_pin_delay 1.2project_close

コマンドライン・サポート

コマンド・プロンプトでスクリプトを生成するには、以下のコマンドを入力します。

quartus_cdb <project name> --generate_bottom_up_scripts=on <options> r

この場合も、オプションは GUIで作成したスクリプトと同じものにマップされます。オプションを追加する場合は、コマンドライン・コールに“--<option_name>=<val>”を追加します。

-include_logiclock_regions <on|off> オン

-include_all_logiclock_regions <on|off> オン

-include_global_signal_promotion <on|off> オフ

-include_pin_locations <on|off> オン

-include_timing_assignments <on|off> オン

-include_design_partitions <on|off> オン

-remove_existing_regions <on|off> オン

-disable_auto_global_promotion <on|off> オフ

-bottom_up_scripts_output_directory <output directory> 現在のプロジェクト・ディレクトリ

-virtual_pin_delay <delay in ns> (1)

表 2–5の注 :(1) デフォルトなし。

表 2–5. Tclコマンドでボトムアップ・パーティション・スクリプトを生成するためのオプション（２ /２）

オプションデフォルト



コマンド・プロンプト・オプションは GUI で使用できるものと同じです。表 2–6に表記されています。

トップレベル・プロジェクトで使用されるパーティションのエクスポートquartus_cdb 実行コマンドは、以下のコマンドを使用してボトムアップ・インクリメンタル・コンパイル・フローのファイルをエクスポートする場合に使用します。

quartus_cdb --INCREMENTAL_COMPILATION_EXPORT=<file> \[--incremental_compilation_export_netlist_type=<POST_SYNTH|POST_FIT>] \[--incremental_compilation_export_partition_name=<partition name>] \[--incremental_compilation_export_routing=<on|off>]

<file> 引数はエクスポートされたファイルのファイル・パスです。<partition name>は、階層パスではなくパーティションの名前です。オプションを指定しない場合、実行コマンドは QSFファイルの任意の設定を使用します。オプションを指定した場合はデフォルト値を使用します。

表 2–6.ボトムアップ・パーティション・スクリプトを生成するためのオプション

オプションデフォルト--include_makefiles_with_bottom_up_scripts=<on|off> オン

--include_project_creation_in_bottom_up_scripts=<on|off> オン

--include_virtual_pins_in_bottom_up_scripts=<on|off> オン

--include_virtual_pin_timing_in_bottom_up_scripts=<on|off> オン

--bottom_up_scripts_virtual_pin_delay=<delay in ns> (1)

--include_virtual_pin_locations_in_bottom_up_scripts=<on|off> オン

--include_logiclock_regions_in_bottom_up_scripts=<on|off> オン

--include_all_logiclock_regions_in_bottom_up_scripts=<on|off> オン

--include_global_signal_promotion_in_bottom_up_scripts=<on|off> オフ

--include_pin_locations_in_bottom_up_scripts=<on|off> オン

--include_timing_assignments_in_bottom_up_scripts=<on|off> オン

--include_design_partitions_in_bottom_up_scripts=<on|off> オン

--remove_existing_regions_in_bottom_up_scripts=<on|off> オン

--disable_auto_global_promotion_in_bottom_up_scripts=<on|off> オフ

--bottom_up_scripts_output_directory=<output directory> 現在のプロジェクト・ディレクトリ

表 2–6の注 :(1) デフォルトなし。仮想ピン・タイミングを含める場合は、このオプションを指定する必要があります。



デフォルトのパーティションは、プロジェクトのトップレベルのパーティションで、デフォルトのネットリスト・タイプはポスト・フィット、配線のデフォルトはオンです（エクスポートされた配線をサポートするすべてのデバイス・ファミリ）。

このコマンドはアサインメント INCREMENTAL_COMPILATION_EXPORT_NETLIST_TYPEを読み出して、エクスポートするネットリストのタイプを決定します。デフォルトは Post-Fitです。

また、flowTcl パッケージに含まれる execute_flowTcl コマンドで、フローINCREMENTAL_COMPILATION_EXPORTを使用することもできます。

以下のコマンドを使用して特定のパーティションに.qxpファイルをエクスポートし、ネットリスト・タイプを選択して、配線をエクスポートするかどうかを指定します。

load_package flowset_global_assignment –name INCREMENTAL_COMPILATION_EXPORT_FILE <filename>set_global_assignment –name INCREMENTAL_COMPILATION_EXPORT_NETLIST_TYPE \<POST_FIT|POST_SYNTH>set_global_assignment -name \INCREMENTAL_COMPILATION_EXPORT_PARTITION_NAME <partition name>set_global_assignment -name INCREMENTAL_COMPILATION_EXPORT_ROUTING \<on|off>execute_flow –INCREMENTAL_COMPILATION_EXPORT

デフォルトのパーティションは、プロジェクトのトップレベルのパーティションで、デフォルトのネットリスト・タイプはポスト・フィット、配線のデフォルトはオンです（エクスポートされた配線をサポートするすべてのデバイス・ファミリ）。

コンパイル後に必ずエクスポートを実行するオプションをオンにするには、以下の Tclコマンドを使用します。

set_global_assignment -name AUTO_EXPORT_INCREMENTAL_COMPILATION ON

下位レベル・パーティションのトップレベル・プロジェクトへのインポートquartus_cdb実行コマンドは、以下のコマンドを使用して下位レベル・パーティションをインポートする場合に使用します。

quartus_cdb -- INCREMENTAL_COMPILATION_IMPORT ↵r



また、flowTcl パッケージに含まれる execute_flowTcl コマンドで、INCREMENTAL_COMPILATION_EXPORTと呼ばれるフローを使用することもできます。

以下のスクリプト例は、Tclスクリプトを使用してパーティションをインポートする方法を示しています。

load_package flow# commands to set the import-related assignments for each partitionexecute_flow --INCREMENTAL_COMPILATION_IMPORT

PARTITION_IMPORT_FILE アサインメントを使用して、インポートされたファイルの位置を指定します。このアサインメントで指定されるファイルは、インポート中にのみ読み出されます。例えば、プロジェクトはインポート後には下位レベル・プロジェクトのすべてのファイルから完全に独立しています。コマンドラインと Tclの flowでは、このアサインメントを空以外の値に設定しているパーティションはすべて無視されます。

以下のアサインメントでは、パーティションをインポートする方法を指定しています。

PARTITION_IMPORT_PROMOTE_ASSIGNMENTS = <on|off>PARTITION_IMPORT_NEW_ASSIGNMENTS = <on|off>PARTITION_IMPORT_EXISTING_ASSIGNMENTS = \replace_conflicting | skip_conflictingPARTITION_IMPORT_EXISTING_LOGICLOCK_REGIONS = \replace_conflicting | update_conflicting | skip_conflicting

makefilesボトムアップ・デザイン・フローの一部として、makefileでインクリメンタル・コンパイルを使用する方法の例については、/qdesigns/incr_comp_makefileサブディレクトリ内の incr_comp例に付属する read_me.txt ファイルを参照してください。ボトムアップ・インクリメンタル・コンパイル・フローを使用する場合、Generate Bottom-Up Design Partition Scripts機能は、デザイン・ファイルが変更されるたびに下位レベルのデザイン・パーティションを自動的にエクスポートし、トップレベル・プロジェクトにインポートするmakefileを作成できます。



推奨されるデザイン・フローおよびコンパイルのアプリケーション例—スクリプトおよびコマンドライン動作この項では、章の主要なセクションで説明したいくつかのトピックに関するスクリプト例を示します。

例 2–1に示すスクリプトは、AB_projectと呼ばれるプロジェクトを開き、最初に 2つのパーティション、エンティティAと Bをセットアップし、最初の完全なコンパイルを実行します。

例 2–1. AB_project (1)set project AB_project

package require ::quartus::flowproject_open $project

# Ensure that incremental compilation is turned onset_global_assignment -name INCREMENTAL_COMPILATION \FULL_INCREMENTAL_COMPILATION

# Set up the partitionsset_instance_assignment -name PARTITION_HIERARCHY \db/A_inst -to A –section_id "Partition_A"

set_instance_assignment -name PARTITION_HIERARCHY \db/B_inst -to B –section_id "Partition_B"

# Set the netlist types to post-fit for subsequent# compilations (all partitions are compiled during the# initial compilation since there are no post-fit# netlists)set_global_assignment –name PARTITION_NETLIST_TYPE \POST_FIT –section_id "Partition_A"

set_global_assignment –name PARTITION_NETLIST_TYPE \POST_FIT –section_id "Partition_B"

# Run initial compilation:export_assignmentsexecute_flow -full_compile

project_close

1つのパーティションに対するソース・ファイル変更時のコンパイル時間の短縮—コマンドライン例

例のバックグランド：前項のスクリプト例に示す、最初のコンパイルを実行しました。パーティション A の HDL ソース・ファイルを変更し、リコンパイルする予定です。



標準フロー・コンパイル・コマンドを以下のTclスクリプトで実行します。

execute_flow –full_compile

または、システム・コマンド・プロンプトで以下のコマンドを入力します。

quartus_sh --flow compile AB_projectr↵

パーティション Bのソース・ファイルは、Aに依存していないと仮定し、Aのみをリコンパイルします。Bの配置とそのタイミング性能は維持され、コンパイル時間が大幅に短縮されます。

タイミング・クリティカルなパーティションの配置を最適化する

例のバックグランド：2–116 ページの「推奨されるデザイン・フローおよびコンパイルのアプリケーション例—スクリプトおよびコマンドライン動作」のスクリプト例に示す、最初のコンパイルを実行しました。フィジカル・シンセシスなどの Fitter最適化を、パーティション Aにのみ適用する予定です。HDLファイルは変更していません。

パーティション B に対する以前のコンパイル結果が維持されるように、また Fitter最適化がパーティションAの合成後のネットリストに適用されるように、B のネットリスト・タイプを Post-Fit に設定し（最初のコンパイルですでに設定済み、ただし念のためにここでも設定）、Aのネットリスト・タイプを Post-Synthesisに設定します。例 2–2にこれを示します。

例 2–2. AB_project (2)set project AB_project

package require ::quartus::flowproject_open $project

# Turn on Physical Synthesis Optimizationset_global_assignment -name \PHYSICAL_SYNTHESIS_REGISTER_RETIMING ON

# For A, set the netlist type to post-synthesisset_global_assignment –name PARTITION_NETLIST_TYPE POST_SYNTH \–section_id "Partition_A"

# For B, set the netlist type to post-fitset_global_assignment –name PARTITION_NETLIST_TYPE POST_FIT \–section_id "Partition_B"

# Run incremental compilation:



export_assignmentsexecute_flow -full_compile

project_close

まとめこの章で説明したQuartus IIのインクリメンタル・コンパイル機能では、デザインのロジックを変更した場合、変更されていないロジックの結果と性能を維持できます。インクリメンタル・コンパイルのさまざまなアプリケーションにより、トップダウンまたはボトムアップ・デザイン手法を使用して、高集積度 FPGAを設計しながら生産性を高めることができます。

参考資料この章では以下のドキュメントを参照しています。

■ 「Best Practices for Incremental Compilation Partitions and FloorplanAssignments」の章（Quartus IIハンドブック Volume 1）

■ 「Command-Line Scripting」の章（Quartus IIハンドブック Volume 2）■ 「Design Debugging Using the SignalTap II Embedded Logic

Analyzer」の章（Quartus IIハンドブック Volume 3）■ 「Engineering Change Management with the Chip Planner」の章（Quartus IIハンドブック Volume 2）

■ 「In-System Debugging Using External Logic Analyzers」の章（Quartus IIハンドブック Volume 3）

■ 「Quartus II Integrated Synthesis」の章（Quartus II ハンドブックVolume 1）

■ Quartus II Settings File Reference Manual■ 「Quick Design Debugging Using SignalProbe」の章（Quartus IIハンドブック Volume 3）

■ 「Tcl Scripting」の章（Quartus IIハンドブック Volume 2）



http://www/literature/hb/qts/qts_qii52002.pdf





http://www/literature/manual/mnl_qsf_reference.pdf




改訂履歴

改訂履歴表 2–7に、本資料の改訂履歴を示します。

表 2–7.改訂履歴（１ /４）

日付およびドキュメント・バージョン

変更内容概要

2008年 5月v8.0.0

● Best Practices for Incremental Compilation Partition andFloorplan Assignmentsの章へいくつか参照を追加。

● 「Quartus IIコンパイル・フローの選択」の項を簡略化。● 「トップダウンとボトムアップのコンパイル・フロー」の項の資料を明確化し、“混在 ”デザイン・フローに関する情報を追加し、HardCopy ASICフローに関する注を追加。

● 表 2–1 から “ デザインの再合成時 ” および “ デザインの再フィッティング時 ”を削除。

● 「デザイン・パーティションの選択および作成」の項を再編成。

● Design Partition Plannerの使用方法を追加。● 「デザイン・パーティションの Netlist Typeの設定」の表 2–2にデザイン変更に関する情報を追加。

● インポートされる空のパーティションに対する HDL ラッパー・ファイルの要件を削除。

● 「パーティションの自動再合成を実行するのはどのような変更でしょうか？」の項に詳細を追加。

● 「どの LogicLock 領域の変更が再フィッティングを実行するか」の項を追加。

● 既存の項である “ 適切なデザイン・パーティションおよびLogicLock領域を作成するためのガイドライン ”を削除。これは「Best Practices for Incremental Compilation Partitions andFloorplan Assignments」の章で扱われており、一部の資料がドキュメントの他の項に移動したため。

● アプリケーション例の名称を変更し、再編成。● 「トップダウン・コンパイル・フローの複数パーティション・デザインの 1 つのを除くすべてのクリティカル・パーティションの配置および前出の例との組み合わせ」の例を削除。

● アーカイブ時にバージョン互換のデータベース使用の推奨を追加。

● ボトムアップ・フローでの HardCopy ASIC制約を明確化。● ボトムアップ・フローでの SDC 制約のエクスポートとインポートを明確化。

● 「タイミング・クリティカルなパーティションの配置を最適化する」の項を追加。

● 「エクスポートされたパーティションを使用したソース・ファイルをインクルードしないデザインの送信」の項を追加。

Quartus IIソフトウェアv8.0のための更新。



2007年 10月v7.2.0

● 2–1ページの “はじめに ”を更新。● 2–3ページの “Quartus IIコンパイル・フローの選択 ”を更新。● タイトルを変更し、“インクリメンタル・コンパイルのためのデザインの準備 ”の項を 2–11ページの “クイック・スタート・ガイド –インクリメンタル・コンパイル・フローのステップの概要 ”に更新。

● 以下を更新“HDLまたは回路デザインのインスタンス、あるいは（サードパーティ合成ツールで作成した）VQMまたはEDIFネットリスト・インスタンスに対して、パーティション・アサインメントを行うことができます。ソース・ファイルの変更時にインクリメンタル・コンパイルを利用する場合、各パーティションのトップレベルのデザイン・エンティティは、固有のデザイン・ファイルを保持している必要があります。別々のパーティションに 2つの異なるエンティティを定義したが、それらが同じデザイン・ファイルにある場合、デザイン・ファイル内のいずれかのエンティティを変更した場合は、両方のパーティションをリコンパイルする必要があるため、インクリメンタル・コンパイルを維持することはできません（2–18ページ）。

● 2–19ページの “デザイン・パーティションの作成 ”を更新。● 2–30ページの“LogicLockロケーション・アサインメントによるデザイン・フロアプランの作成 ”を更新。

● 2–33ページの“ボトムアップ・デザイン・フローのためのパーティションのエクスポートとインポート ”を更新。

● 2–47 ページの “ 適切なデザイン・パーティションおよびLogicLock領域を作成するためのガイドライン ”を更新。

● 2–77ページの “インクリメンタル・コンパイルの制約 ”を更新。

Quartus IIソフトウェアv7.2のための更新。

表 2–7.改訂履歴（２ /４）


変更内容概要


改訂履歴

2007年 5月v7.1.0

● ページ 2–3の “Quartus IIコンパイル・フローの選択 ”を更新。ページ 2–10の “インクリメンタル・コンパイルのためのデザインの準備 ”を更新。

● 表 2–1と表 2–3を更新。● 2–61ページの “推奨されるデザイン・フローおよびコンパイルのアプリケーション例 ”のデザインを更新。

● 2–72の “デザイン・フロー7— IPの再利用のためのハード •ワイヤード・マクロの作成 ”に新しい例を追加。

● 2–76ページの “フル・インクリメンタル・コンパイルに代わるインクリメンタル・シンセシスのみの使用 ”を移動し、簡略化。

● 2–81ページの “HardCopyのコンパイル・フロー&drq;を更新。● 2–81 ページの “TimeQuest タイミング・アナライザおよび

SDC制約のサポート ”を更新。● 2–98ページの “デザイン・パーティションのプロパティの設定 ”を更新。

● 2–106ページの “参考資料 ”を追加。

いくつかのダイアログ・ボックスの図を削除。Arria GX デバイスのサポートを追加。Fitter PreservationLevel の Post-Fit 配置、配線、およびタイトルを追加。

2007年 3月v7.0.0

内容の変更はなし。 —

2006年 11月 v6.1.0 バージョン 6.0.0の 1章を 2章に変更。章を再編成して、推奨事項とガイドラインをまとめてグループ化。Quartus IIソフトウェア v6.1のための更新。● Stratix IIIデバイスのサポートを追加。● Incremental Compilation Advisorの情報を追加。● これでフル・インクリメンタル・コンパイル・オプションがデフォルトでオンに設定される。

● プロジェクト内で下位レベル・ブロックをエクスポートする新機能を追加。

● Automatically export design partition after compilationオプションの場所を変更。

● HardCopyコンパイル・フローのサポートを追加。● ボトムアップ・フローに配線のエクスポート機能を追加。● 適切なデザイン・パーティションを作成するためのI/Oポートのガイドラインを追加。

● SignalProbe ピンの制限および Chip Planner によるEngineering Change Managementを更新。

Stratix III デバイスのサポートを追加。Quartus IIソフトウェアv6.1 の新機能および更新に関する情報を追加。

表 2–7.改訂履歴（３ /４）


変更内容概要



2006年 5月 v6.0.0 階層およびチーム・ベース・デザインのための Quartus II インクリメンタル・コンパイルに名称を変更。Quartus IIソフトウェア v6.0のための更新。 ● 新規デバイス・サポート情報を追加。● トップダウンとボトムアップのデザイン・フロー情報を追加。

● インクリメンタル・コンパイルを使用したデザインのコンパイル情報を追加。

● 適切なフロアプラン・ロケーション・アサインメントを作成するための推奨事項を追加。

● レジスタ・パッキングおよびパーティション境界情報を追加。

● Chip Editorを使用した ECOを追加。● SignalProbe 再適用のためのチェックおよび保存方法の情報を追加。

● ユーザー・シナリオを追加。

—

2005年12月 v5.1.1 マイナーな表記規則の更新。 —

2005年10月 v5.1.0 Quartus IIソフトウェア v5.1のための更新。 —

2005年 8月 v5.0.1 クロス・パーティション・レジスタ・パッキングの資料を追加。

—

2005年 5月 v5.0.0 初版 —

表 2–7.改訂履歴（４ /４）


変更内容概要

2. 階層およびチーム・ベース・デザインのためのQuartus II ......2–2 Altera...

Documents

Transcript of 2. 階層およびチーム・ベース・デザインのためのQuartus II ......2–2 Altera...

2. 階層およびチーム・ベース・デザインのため のQuartus II ......2–2 Altera...

Documents

Transcript of 2. 階層およびチーム・ベース・デザインのため のQuartus II ......2–2 Altera...

2. 階層およびチーム・ベース・デザインのためのQuartus II ......2–2 Altera...

Transcript of 2. 階層およびチーム・ベース・デザインのためのQuartus II ......2–2 Altera...